AIエージェントを使ってチームの「生きたナレッジベース」を維持する方法

過去6か月間、私はある実験を続けてきました。チームにドキュメントを書かせるのではなく、AIエージェントに「聞かせる」ことにしたのです。

その結果、生きたナレッジベースができました。2スプリントで腐っていくような静的ウィキではなく、私たちが作業するのに合わせて自ら更新される仕組みです。仕組みの概要、何が壊れたか、そしてなぜこれがチームの記憶（メモリ）の未来だと思うのかを説明します。

問題: ドキュメントは静かに死ぬ

私がこれまで関わってきたあらゆるエンジニアリングチームには、同じサイクルがあります。

1. 誰かが、美しいオンボーディング用ドキュメントを書く。
2. 6か月後、アーキテクチャが変わる。
3. そのドキュメントは罠になる。信頼できそうなくらい正確なのに、日を無駄にするくらい間違っている。

新しく入った人が不整合を指摘する頃には、最初に書いた人は別のチームに移るか、会社を辞めています。知識は消えてしまいます。

転換: 「書き留める」から「流れを捉える」へ

ドキュメントを別タスクとして扱う代わりに、私はAIエージェント（ローカルLLM＋MCPスタックで構築）を用意し、自然な作業の流れを観察するようにしました。

• Slackスレッド（アーキテクチャ判断について議論する場所）
• PRの説明文（変更の「なぜ」を説明するもの）
• ミーティングの議事録（技術的な議論の記録）
• コードコメントとコミットメッセージ

エージェントは単にアーカイブするだけではありません。統合（synthesize）します。

パイプラインの仕組み

1. 取り込み（Ingestion）

毎日、エージェントは新しいメッセージ、PR、議事録を取り込みます。会話全体をそのまま保存するのではなく、セマンティック・チャンク（意味に基づく分割）を使って、トピックごとの断片に切り分けます。

2. 分類（Classification）

軽量な分類器が、各断片にタグを付けます。

• architecture-decision
• onboarding-relevant
• api-contract
• incident-postmortem
• deprecated

3. 統合（Synthesis）

週に1回、エージェントが「生きたページ（living pages）」を生成します。関連する断片をまとめて、筋の通った説明になるよう構造化されたドキュメントです。これらのページは元のソースへリンクします。なので、常に文脈を検証できます。

4. 古さ検知（Stale Detection）

エージェントは、30日間新しいソースで強化（reinforced）されていないページを警告します。認証フローに関するページで、1か月間、関連するPRやSlackスレッド、ミーティングが見つからない場合、それは潜在的に古い（potentially stale）とマークされます。削除ではなく、ラベル付けです。

5. 人のレビュー・ループ

毎週月曜日、エージェントはチームのチャンネルに要約を投稿します。

• 新しく生成されたページ 3件
• 古い可能性としてフラグが立ったページ 2件
• 矛盾する説明が1つ検出された（キャッシュについて、2つのソースが異なることを言っている）

レビューにかけるのは10分です。以上。

実際に何が変わったのか

新入社員のオンボーディングは、3日から4時間へ。ドキュメントが長くなったからではありません。最新だからです。「なぜPostgresをMongoより選んだの？」と聞かれたとき、答えには元のSlackでの議論、最終決定を行ったPR、移行について話し合ったミーティングがすべてリンク付きで含まれます。

意思決定のスピードが上がった。すでに答えが出ているはずの疑問を、何度も議論し直すのをやめました。エージェントは、新しい議論で似たキーワードを検出したときに、過去の決定を提示します。

ドキュメントの罪悪感が消えた。システムが私たちの自然な説明を取り込むので、エンジニアは「ドキュメントを書けないから気まずい」と感じなくなりました。すでに書いていたPRの説明文が、そのままナレッジページの種（seed）になります。

何が壊れた（そしてどう直したか）

ノイズ過多。初期バージョンでは、取り込みすぎていました。Slackの冗談も、あらゆる「LGTM」コメントも。そこで、最低限の文字数に加えて、技術的キーワードを少なくとも1つ含むことを条件にする重要度フィルタを追加しました。

矛盾する真実。2人のエンジニアが、異なるチャンネルで同じシステムを別の説明で語っていました。エージェントは矛盾を検出し、「勝ち」を選ぶのではなく、人間が解決できるように提示するようにしました。

プライバシー上の懸念。すべてを記録するべきではありません。明示的な除外リスト（チャンネル、DM、特定のキーワード）を維持し、パイプライン全体をローカルで実行します。データが私たちのインフラの外へ出ることはありません。

「完全性の錯覚」の問題。生きたナレッジベースは、あまりに権威的に感じられることがあります。そこで、各ページが一次ソースによって最後に強化された時点を示す明確なマーカーを追加し、読者が深掘りすべきタイミングを分かるようにしました。

構成（これを作るなら）

• LLM: Ollama経由のLocal Llama 3.1（すべてをオンプレに保持）
• ベクターストア: セマンティック検索用のChromaDB
• コネクタ: Slack、GitHub、Zoom議事録用のMCPサーバ
• スケジューラ: パイプラインを起動するシンプルなcronジョブ
• フロントエンド: 生きたページから生成した静的サイトを社内でホスティング

総セットアップ時間: 週末1回で完了。保守: ほぼゼロです。

なぜドキュメント以上に重要なのか

これは単にドキュメントの話ではありません。組織の記憶（organizational memory）の話です。

多くの企業では、離職などによって2〜3年ごとに文脈的な知識の50%が失われます。静的なドキュメントは劣化を遅らせますが、止めることはできません。実際の作業成果物によって供給される生きたナレッジベースは、個々の貢献者を超えて残り続ける記憶システムを作ります。

エージェントは人間の判断を置き換えません。むしろ増幅します。私たちが忘れたものを思い出し、見落としていたものを提示し、集団の知識が自分自身の鮮度について正直でいられるように保つのです。

自分でも試してみる

小さく始めましょう。

1. 1つの情報ストリームを選ぶ（GitHub PRが一番簡単です）
2. 週次の統合ジョブを設定する
3. 出力をチームのチャンネルで共有する
4. 実際に人が読んでいるものに基づいて改善する

「完全性」を目指さないでください。目指すべきは有用性です。

チームの知識を生かし続けるために、これまでどんなシステムを使ってきましたか？うまくいったこと、うまくいかなかったことを、ぜひあなたの経験として聞かせてください。