チームの AI 知識基盤がエージェント性能を決定する

オリジナル記事：テックメディア「騰訊プログラマー」より

2026年8月17日 17時36分 広東省

チームの AI 知識基盤構築の実践

著者：danteyang

エージェントがチームの現場で生産力として定着するにつれ、知識供給の課題が浮き彫りになりました。検索精度の低さ、注入効率の悪化、そして古い情報が積み重なる問題です。この記事では、安全センターチームが目標設定から体系構築、知識の飛輪を回すまでの全過程を記録します。そこには重要な判断の背景にある思考や、経験した失敗、そしてすぐにでも活用できる手法が含まれています。

エージェントを使って開発や運用を行うようになると、すぐに一つの課題が見えてきます。それは、エージェントの出力品質は、提供できる知識の質に直接依存するという点です。「作れる」「正確に見つかる」「適切に供給される」「不要なものは淘汰される」知識をどう実現するか。これは、エージェントを導入するチームが必ず直面するエンジニアリング上の課題です。本稿では、AI 向け知識体系の構築に取り組んだ実践に基づき、その思考プロセスや失敗事例、そして再利用可能な手法について解説します。

なぜ AI 時代には知識ベースの再構築が必要なのか

これまでのチームにおける知識は、要件定義書、レビュー記録、コードレビューのコメント、あるいは個人の経験といった場所に散在していました。新人が特定のモジュールに関する過去の意思決定を理解しようとすると、iWiki を検索し、ベテランに聞き込み、さらにコードリポジトリでコミットメッセージを調べる必要があります。これには通常、1〜2 日かかってしまうのです。

それ以上に厄介なのは、同じ失敗を異なるメンバーが繰り返してしまう点です。その教訓は、変更要求（MR）を作成した個人の頭の中だけにあり、他の人がそれを知らないからです。

従来の知識管理は「人が書く→人が探す→人が読む」という流れでした。

しかし、エージェントが現場で使われるようになると、状況は一変しました。問題なのは、Agent が長い文章を読めないことではありません（大規模モデルのコンテキストウィンドウであれば 2000 字程度なら全く問題ありません）。真にボトルネックとなっているのは、以下の二点です。

第一に、検索精度の問題です。2000 篇ものドキュメントがある中で、エージェントは具体的な質問に対して、関連する数篇だけを正確に引き出すことができるのでしょうか？自然言語で書かれた長い文章では意味の境界が曖昧になりやすく、検索結果が意図から外れてしまう（ドリフトする）リスクがあります。

第二に、注入効率の問題です。たとえ正しいドキュメントが見つかったとしても、その中に含まれる復習レポートの結論は、現在のシナリオに関連する部分だけかもしれません。毎回、全文をコンテキストとして読み込ませることはできません。トークンコストがかかるだけでなく、文脈がノイズで埋もれてしまうからです。

「適用条件」「核心となる結論」「実施すべきことと避けるべきこと」を明記した構造化された知識（カード形式）は、これらの課題を解決するものです。ただし、一つ注意が必要です。「人間向け」と「Agent 向け」の知識を別々に作ってはいけません。優れた構造化知識とは、人間が開いても理解でき、メンテナンスも容易なものです。良いスキルドキュメントやプロンプトと同様に、人間が読んでも明確であるべきです。逆に、人間が見ても意味不明な知識であれば、その維持品質は決して高くならず、時間が経つにつれて腐敗してしまいます。したがって、私たちの原則は「人間と機械の共読」です。一つの知識ベースを構築し、人間も Agent もその消費者となるのです。

さらに根本的な変化が求められています。Agent が知識の主要な消費者となった今、知識を生産する仕組みや品質基準、そして流通のロジックもすべて見直さなければなりません。

具体的には以下の通りです。

❌ 従来の模式：人が書き、人が読む。長文ドキュメントは人間の可読性のみを重視し、静的なストレージに保存され「入るだけ」で更新されない。

✅ AI 時代の模式：プロセスが自動的に生産し、Agent が消費し、人間が意思決定と修正を行う。構造化されたデータにより検索精度と注入効率が向上し、人間にも読みやすくメンテナンスしやすい設計とする。知識の規模が大きくなると古い情報が Agent の判断を妨げるため、有効期限による鮮度管理や自動的な淘汰・復活メカニズム（フライングホイール）を導入する。

一言でまとめれば、従来のナレッジベースは「倉庫」であり、いかに多く保存できるかが重視されました。しかし AI 時代の知識基盤は「供給システム」であり、「正確にマッチングし」「高速に注入され」「古くなったものが自動的に淘汰される」ことが求められます。

三大パラダイムシフト：人からプロセスへ、知識からデータへ、そして静的なものから進化するものへ。

知識基盤は誰のためにあり、何を詰め込み、どうすれば成功と言えるのか——その範囲（SCOPE）を定義することが不可欠です。

知識基盤の構築に失敗するケースの多くは技術的な問題ではなく、「何を目指しているか」が明確でないことに起因します。いきなりツール選定やプラットフォーム構築から始めてしまうと、結局誰も使わないシステムができてしまうリスクがあります。そのため、着手前に以下の 4 つの質問に答えておくべきです。

🎯 質問 1：どのシナリオを支援するのか？

「知識ベースを構築する」ではなく、「XX シナリオにおける YY の非効率性を解決する」という形で目標を業務上の課題に固定します。

🤖 質問 2：誰がどのように消費するのか？

消費者は人間と Agent の両方です。重要なのは、知識の構造が「人間にとって理解・維持可能」であり、「Agent による検索・注入が正確かつ効率的」という二つの要件を同時に満たすことです。

📦 質問 3：知識ベースに何を格納するのか？

以下の 4 レベルで整理します。L1（共通基盤）→ L2（業務領域）→ L3（シナリオ戦略）→ L4（イベント増分）。各レベルについて、内容、責任者、鮮度維持の頻度を明確に定義します。

📊 質問 4：成功の基準は何か？

観測可能な指標を設定します。例えば、注入ヒット率、プロファイルカバレッジ、盲索（検索失敗）の減少率、手戻りの削減率、会話採用率などです。

当社の AI エンドツーエンド開発プラットフォームを例に挙げると、4 つの質問に対する答えは以下のようになります。

• どのシナリオを支援するのか？：エンドツーエンドの要件納品。要件レビューから技術設計、コーディング、コードレビュー、そしてリリースに至るまでの全工程です。
• 誰が消費するのか？：12 の開発 Agent（要件レビュー、設計案作成、自動開発、コードレビューなど）が第一消費者となります。開発担当者は審査・修正役であり、新人は過去の意思決定を学習するために知識ベースを利用します。
• 何を格納するのか？：技術設計の骨子、過去のトラブルシューティング、要件テンプレート、経験の振り返り、リポジトリアーキテクチャなど。知識タイプごとに分類し、コードリポジトリと紐付けます。
• 成功の基準は何か？：要件納品を日次から時間単位へ短縮。コードレビューの回数を 2〜4 回から 1.1 回に削減。知識ソースの 99% 以上がプロセスによる自動蓄積であり、人手による記述ではないこと。

目標が明確になれば、その後の設計もスムーズに進みます。「人が手作業で蓄積しようとするのは失敗する」という判断は、知識の蓄積を開発プロセスの 5 つのノードに固定するという方針へと直結します。コードが実行されれば、自動的に知識として残る仕組みです。

ここには明確なルールがあります。未公開またはリポジトリと紐付いていない知識はすべて一時保存とし、Agent の参照プールへ即時反映させないことです。後で正式に公開されたら自動的に登録します。もしこのゲートが機能しなければ、知識ベースはすぐに未完成品や無効なドキュメントで溢れてしまいます。

💡 移行のアドバイス

あなたのチームはどうでしょうか？

開発でも運用でも、考え方は同じです。プロセス内の「必須ノード」（テスト通過、リリース完了、イベントクローズなど）を見つけ、そこに知識の蓄積を結びつけます。知識をプロセスの副産物として位置づけ、追加業務にしないことが重要です。5 つのノードにおける具体的なトリガータイミングと蓄積内容は、前述の表をベースに適宜調整してください。「客観的な信号による検証のみがプールへの登録を許可する」という二重の門番ロジックは、どのチームでも通用します。

目標設定が終わったので、次は構築について話しましょう。

どうやって作るか——AI 知識基盤の6 つのステップ HOW TO BUILD

いきなりツールを選ばないでください。これまでの経験から、以下の6 つのステップがスムーズだとわかりました。各ステップを完了するごとに明確な成果物があり、プロジェクトが中途半端に終わるリスクも低くなります。

Step 1：知識の棚卸し——今、何を持っているか

まずは現状把握です。4 つの層に分けて、実際に手元にあるものを整理しましょう。

• レベル：内容 / 具体例
• L1 共通基盤：チーム全体で通用する開発規範やコーディング規約 / ログ/ストレージ/RPC/認証など 100 以上のコードサンプル
• L2 ビジネス領域：ビジネスラインごとに整理されたドメイン知識 / プラットフォームドキュメント、接続ガイド、ビジネスアーキテクチャ
• L3 シナリオ戦略：特定シナリオにおける意思決定ルールと戦略 / リスク管理处置基準 200 以上、制御用 Prompt テンプレート
• L4 イベント増分：日常イベントから抽出された新ルールや新経験 / タワー攻略後の处置で蓄積された新基準、リリース後に自動抽出された失敗事例カード（6 月新規 716 件）

棚卸しをすれば、空白箇所や重複箇所が明確になります。最終的に「1+7+N」の構造を確立しました。つまり、MCP 能力基盤 1 つ、知識ベース 7 つ、そして Agent コンシューマー N です。あなたのチームが必ずしも 7 つの庫を持つ必要はありませんが、この層別棚卸しの方法はそのまま流用可能です。

image棚卸しの結果：1 つの MCP 基盤が上層に位置し、7 つの主要な知識ベースを支え、N の Agent が必要に応じて購読・消費する

Step 2：ツール選定——どのような知識ベースが必要か

知識ベースには主に3つの形態があり、それぞれ得意とするシナリオが異なります。重要な経験則として、「1 つだけ作る」のではなく、組み合わせて使うことをお勧めします。

• タイプ：適したシナリオ / 具体例
• ドキュメント型：長文の背景知識、チュートリアル、アーキテクチャ説明 / iWiki ドキュメント、新人向け专区、振り返りの長文記事
• 構造化ストレージ：ルールが明確で正確なマッチングが必要、かつ人間が見ても維持しやすい / Git, MySQL による構造化保存、Markdown/YAML/JSON の保存、知識カードのレンダリング（人間と Agent が直接消費可能）
• RAG ベクトル型：知識量が膨大で、意味的なマッチングが中心となる場合

TRAG 存储（ベクトル検索）

ステップ 3：ツールプラットフォームの選定は「中台優先＋アダプター層」

考え方はシンプルです。中台があればそれを使い、なければ自前で構築します。Agent のツールレイヤーには、基盤となるデータ能力を標準化されたツールとして包み込むアダプター層が必要です。現在、MCP（Model Context Protocol：モデルコンテキストプロトコル）が主流の協議となっています。

私たちのアプローチでは、プラットフォームの基盤データ能力（データベース照会、ログ検索、モデル呼び出しなど）を業務領域ごとに分割し、複数の独立した MCP Server として構築しています。重要な設計ポイントとして、すべてのツールを単一の Server に詰め込まないことが挙げられます。大規模言語モデルは、1 つの Server で扱えるツールの数に上限があり、ツールが多すぎるとトークン消費が増加します。また、業務間の分離も必要です。分割した後は、チーム内の各 Agent が必要なツールだけを按需で接続し、不要なツールは読み込まないため、互いに干渉しません。

用語解説：MCP と RAG について

MCP（Model Context Protocol）とは、Agent が外部ツールを呼び出すための標準プロトコルであり、Agent 世界における USB インターフェースのようなものです。RAG（Retrieval-Augmented Generation：検索拡張生成）は、まず知識ベースを検索し、その結果に基づいて大規模言語モデルが回答を生成する手法です。

ステップ 4：知識生産——4 つのモードを並行して実行

鉄則があります。「人が自発的に書くことを期待しない」ことです。以下の 4 つの生産モードを並行して稼働させます。

⚙️ モード A：プロセスに紐付いた自動蓄積

知識生産は、開発や運用の重要ノードに組み込まれており、人手を介さずに自動的に蓄積されます。実際のデータでは、知識の 99.7% がこのプロセスによって自動生成されています。

🔄 モード B：復習 Agent による更新駆動

Agent は毎週会話記録を分析し、ヒットしなかった盲点を自動的に Git MR（Merge Request）として作成します。ユーザーとの会話は、知識の質に対する暗黙的な検証となります。

🤖 モード C：Agent による自動生成

運用担当者がイベントの背景情報を入力すると、Agent が自動的に構造化された知識と精度評価を生成します。これにより、知識の公開までの期間が数日から 30 分へと短縮されました。

⚡ モード D：運用対応時の即時蓄積

新しい事象への対応を行うと同時にルールを蓄積し、同様の事象が発生した際に Agent が即座に活用できるようにします。最短で 2 時間以内にデータベースへ登録可能です。

ステップ 5：知識ガバナンス——「流入と流出」が鮮度を保つ鍵

流入するものだけを管理し、流出を許さない知識ベースは、3 ヶ月もすればゴミ捨て場同然になります。効果的なガバナンスには以下の 4 つの施策が必要です。

1. 准入の二重ゲート：正式に Agent 引用プールへ組み込むには、「公開済み」かつ「関連リポジトリへの紐付け完了」の両条件を満たす必要があります。
2. 3 レベルの品質分级：利用可能、確認待ち、検証待ちの 3 つに分類し、信頼度に応じて自動的に振り分けます。
3. 有効期限による鮮度維持：デフォルトで 90 日ごとに再検証が行われます。期限切れかつ引用ゼロの場合は自動的にアーカイブされます。
4. 自動退場と復活のセーフティネット：引用ゼロで期限が切れたものはアーカイブされますが、依然として引用がある場合や「いいね」がついた場合は自動的に復活します。これにより、価値ある知識が誤って削除されるのを防ぎます。

数ヶ月の実運用データによると、アーカイブされた項目は 101 件、整理候補は 11 件あり、期限切れによるガバナンスの完了率は 90.2% に達しています。人手で監視する必要はなく、システムが自動的に代謝を担っています。

以下に、実際のガバナンスワークbench の画面を示します。知識オーナーは、審査待ち、期限間近、改善が必要な知識を確認でき、人間が行うべき作業は高価値な項目の再確認に集中できます。

imageガバナンスワークベンチ：システムが自動的に審査待ち、期限間近、改善が必要な知識を識別し、人間は高価値な項目の再確認に集中する

ステップ 6：配布と消費——知識が利用者に届く仕組みへ

最終ステップは、知識を必要な場所に届けることです。従来の手法では Agent が自ら検索を行い、見つからなければ意味がありませんでした。しかし私たちは考えを変え、プラットフォーム側が能動的に知識を注入するアプローチを採用しました。これにより、Agent がタスクを開始する前に、システムがすでにそのシーンに応じた関連知識をパッケージ化して格納しておくことができます。

従来の模式では、Agent 自身が検索を行い（呼び出しの確実性に欠ける）、長文ドキュメントは Agent が処理しきれず、利用履歴も記録されませんでした。一方、能動的注入モードでは、プラットフォームが確実に知識を送り届け（100% の到達率）、構造化されたカードや YAML、プロンプトテンプレートとして提供します。また、各知識の消費状況を追跡・記録できるため、透明性が高まります。

現在、12 以上の Agent がそれぞれ独自の知識サブスクリプションを持っています。例えば、要件レビュー用の Agent は要件テンプレートと過去の失敗事例のみを参照し、世論監視用の Agent は判定基準や悪用例のルールのみを対象とします。知識パッケージは配布のコンテナとして機能しており（現在 40 種類）、網羅的なプッシュではなく、専用リポジトリ用と公共用の 2 つに分類して提供しています。

12 以上の専用 Agent が要件の全ライフサイクルと運用の全シーンをカバーし、それぞれの Agent は特定の知識ベースと MCP ツールを消費します。

⚠️ 何可以直接搬用し、何をカスタマイズすべきか

そのまま再利用可能な要素：目標設定のための「4 つの問い」フレームワーク、プロセス連携のための「5 つのノード」アプローチ、入場審査における二重ゲート（客観的信号による検証のみでプールへ追加）、3 段階の品質分级、有効期限と退場・復活メカニズム、知識パッケージを配布コンテナとして利用する仕組み、注入時の即時記録機能です。

現場に合わせて調整が必要な要素：具体的なトリガーノードは自社の重要業務フローに置き換える必要があります。また、知識カードのフィールド構造は各 Agent の消費シーンに合わせて設計し、MCP ツールの分割は自社の事業領域划分に基づいて行います。さらに、鮮度維持の頻度（当社ではデフォルト 90 日）も、自社の知識更新速度に応じて調整してください。

知識を回転させるための飛輪 THE FLYWHEEL

知識ベースを整備することは第一歩です。それを自律的に回すことで初めて真に機能します。「納品が増える→知識が厚くなる→Agent が強化する→納品が加速する」という循環が一度始まれば、チームの能力は利用量とともに向上していきます。

「知識の飛輪」は、生産→抽出→注入→消費→フィードバック→鮮度維持という 6 つの工程から成り立ち、これらが自走する強化サイクルを形成します。

この飛輪が回り続けるためには、いくつかの設計上の工夫が必要です。

一つ目は「利用こそが蓄積である」という考え方です。例えば、セキュリティセンターで運用されている総合 Q&A ボット「O3 Buddy」の振り返り用エージェントは、週に一度会話記録をスキャンします。回答できない問題に出会った場合、自動的に Git の MR（Merge Request）を作成して知識を追加します。ユーザーとの対話一つひとつが、実質的にナレッジベースの穴埋め作業となっています。6 月の実績では月間平均 1,097 件の対話があり、そのうち 92% が採用されました。

二つ目は「注入こそが記録である」という原則です。どの知識を誰が、何回利用したかは、人手による報告に頼らずシステムが自動で記録します。どの知識が人気を集めているか、あるいは一度も参照されていないかなどは、ダッシュボードを開けば一目瞭然です。

三つ目は「蓄積しない勇気」を持つことです。多くの要件対応後には、特に蓄積する価値のある成果物がない場合もあります。システムはそれを判断してスキップします。非同期の蒸留（distillation）によるノイズ低減を通じて、知識コンテンツの生成自体を抑制し、ナレッジベースにおいては「量」よりも「密度」が重要だと考えています。

運用側で直面するもう一つの課題は、「いかに人々に参加してもらうか」です。試行錯誤の結果、最も効果的だったのは管理手段による強制ではなく、ツールの整備でした。知識の蓄積という行為自体に追加作業を感じさせない仕組みを作るのです。例えば、ある要件のエンドツーエンド開発中に、人間と AI の対話・相互作用が行われる過程で、自動的に知識が蓄積され、対応する担当者に紐付けられます。また、貢献度ランキングも生成し、関連データは自己評価にも反映されます。これらは付加価値ではありますが、核心となるのはプロセスの自動化によって業務を完結させる点にあります。

知識貢献ランキング：

下の図は、私たちが日常的に運用しているフライング・ホイール（飛輪）のダッシュボードです。知識の規模、品質、鮮度、AI の呼び出し効果という 4 つの指標をワン画面で把握できるようになっています。すべてのデータは、「注入＝即時記録」の仕組みによって自動的に生成されます。

「フライング・オペレーション」ダッシュボードでは、知識の規模・品質・鮮度、そして AI の呼び出し頻度の4つの次元をリアルタイムで可視化し、すべてのデータが自動的に生成されます。

避けるべき4つの反パターン（アンチパターン）：

✕ KPI を強制的に押し付け、貢献を迫る

無理やり書かされた知識は品質が低く、維持する意欲も低下します。

→ 主軸はプロセスによる自動的な蓄積とし、インセンティブは補助的に活用すべきです。

知識の無限膨張と質の低下への対策

「入力のみで出力しない」状態が続き、知識が蓄積される一方で、有用な情報とノイズの比率（信噪比）は低下する傾向があります。これを解決するには、「有効期限による鮮度管理」と「自動的な退場・復活メカニズム」が必要です。

また、暗黙知を形式知化できないという課題も存在します。ベテランが退職することで、組織からノウハウが失われるリスクです。これには「振り返り（リフレクション）の専門化」「異動時の引き継ぎリストの整備」「エキスパートによる知識抽出」が有効な対策となります。

さらに、「貢献者と組織の権限・責任の不均衡」という問題もあります。多くの貢献があっても評価されなければ、モチベーションは低下します。これを解決するには「貢献度の可視化（ランキング化）」「自己評価の引用機能の導入」「管理者による評価指標への反映」が有効です。

運用開始後の変化：何が変わったか

知識システムの構築後、具体的に何が変わったのでしょうか。一言で言えば、「重複した検索や同じ失敗を繰り返す作業から人を解放し、より多くの意思決定と創造的な活動にリソースを割けるようにした」ことです。

具体的には以下の4つの価値が生まれました。

🧠 組織の記憶

人員の流動性に関わらず、重要な知識が失われません。11件以上の障害振り返り（フォールト・レポーティング）が「失敗集め」として蓄積され、行動の基準となりました。新人は先輩たちの知見の上に立って成長できます。

🚀 新入社員の加速

3段階の育成体系（入門期 → 成長期 → 成果創出期）を確立しました。これにより、新人が戦力として活躍するまでの期間が従来の30日から10日に短縮されました。

⚖️ 知識への平等なアクセス権

どの部署に所属していようとも、入社してどれほど時間が経とうとも、エージェント（Agent）が取得できる知識は同じです。「誰に聞けば答えが出るか」という情報非対称性が解消され、必要な情報が誰でも得られるようになりました。

♻️ 自己強化のフライング・ホイール

「利用が増える → 知識が厚くなる → エージェントが強くなる → 成果が高まる → さらに多くの人に使われる」という好循環が生まれました。これは持続的に加速する正のループです。

具体的な数値での変化

これらの変化は数字にも表れています。要件定義から納品までの期間が「日単位」から「時間単位」に短縮されました。コードレビューの所要時間は、従来の30分〜2時間から平均3.4分にまで短縮されています。また、ソーシャルメディア監視チームでは徹夜勤務が不要となり、リスク事象の日間処理量は400件から1,200件へと増加しました。

継続的な運用の重要性

重要なのは、このシステムを一度きりの「知識キャンペーン」で終わらせず、持続的に稼働させることです。そのための指標は以下の通りです。

継続稼働指標

• 知識の月間増加数: 5月は86件 → 6月は716件 → 7月前9日間で154件と、着実に増加傾向にあります。
• カバー対象者数: エンドツーエンドの開発に参加したのは69人（部署全体の57.5%）。O3 Buddyの月間アクティブユーザーは50人、知識貢献者は80人以上に達しています。
• 自動化率: 99.7%がプロセスやAIによって自動的に蓄積されており、メンバーが追加の作業負担を感じることほぼありません。
• 知識の鮮度維持: 振り返り用エージェントが毎週自動更新され、期限切れ情報の整理完了率は90.2%に達しています。
• エージェントの利用状況: 月間平均利用回数は2,000件超（OK: 840件 + O3 Buddy: 1,097件）で、知識が実際に消費されていることが確認できます。

人の役割の変化

メンバーの役割も変化しました。単なる知識の搬送者ではなく、「知識の質を担保する管理者」へとシフトしています。エージェントが重複作業の80%を担い、人間は判断と修正に注力する20%を担当します。

メンバーの精神的負担は極めて低く、通常の要件対応やリリースをこなすだけで、自動的に知識が蓄積されます。「ドキュメントを書く」という追加アクションを意識する必要はありません。

組織で知識体系を構築するためのアドバイス

もしあなたのチームでも知識体系の構築を検討しているなら、まずは特定のシナリオにおけるクローズドループ（完結したサイクル）から始めることをお勧めします。すべてを一度にやろうとせず、一つ成功させてから横展開していくのがコツです。フライング・ホイールが回り始めた状態を作ることが、単に速く回るよりも重要です。

WeChat での閲覧には、リンク先へ遷移してください。