AIエージェントに古い社内知識を信じさせないために: Source of Truth、鮮度、矛盾解決ルール

1. 概要: 古い真実は、知識がないことより危険

多くのチームは、AIエージェントが存在しないことを作り出すのではないかと心配します。それは正しい心配です。しかし会社運用では、もっと静かな失敗があります。エージェントが実在する文書を見つけ、正しく読んだのに、その文書自体が古い、廃止済み、または下書きだったために間違った答えを出すケースです。

検索ツールは社内知識を使いやすくします。OpenAI file search、Microsoft Copilot Studioのknowledge sources、Google groundingのような仕組みは、モデルを文書やデータソースに接続できます。ただし、三つの資料が矛盾したときに、どれが正式なルールかを自動で決めてくれるわけではありません。

公開作業の例で考えると分かりやすいです。ブログ記事がローカルのリポジトリにあっても、ライブサイトでは古い記事一覧しか見えないなら、公開は終わっていません。読者にとってのSource of Truthは、デプロイされたサイト、ライブURL、sitemapです。会社のAIにも同じ規律が必要です。実際の運用面で確認できるまで、完了とは言えません。

2. やさしい用語整理: Source of Truth、鮮度、RAG、grounding、MCP

Source of Truthとは、チームが最終版として信頼すると決めた場所です。簡単に言えば、他のメモや文書が食い違ったときに勝つ文書、データベース、システムです。返金ポリシーが議事録より優先されることもあり、署名済み契約書が営業メモより優先されることもあります。

鮮度とは、そのルールがまだ有効かどうかを示す信号です。ただの日付ではありません。最終レビュー日、担当者、更新トリガー、失効ルールの組み合わせです。昨日担当者が確認したポリシーは、一年間誰も触っていないWikiページより強い根拠になります。

RAGはretrieval-augmented generationの略です。AIが回答する前に関連する社内知識を検索する方式です。Groundingは、回答が検索された情報源に結び付いているという意味です。MCP、Model Context Protocolは、AIツールが外部システムにつながるための標準プラグのようなものです。しかし、これらの技術は情報源の優先順位、鮮度確認、エスカレーションルールの代わりにはなりません。

• Source of Truth: 文書が食い違ったときに勝つ正式ルール。
• 鮮度: そのルールがまだ有効で担当者がいることを示す信号。
• RAG: 回答前に社内知識を検索する方式。
• Grounding: 回答を検索された根拠に結び付けること。
• MCP: AIとツールを接続する標準であり、接続先データの正しさを保証するものではない。

3. 文書の数はよい指標ではない

大きなナレッジベースは成熟して見えます。しかし古い提案書、議事録、オンボーディング資料、Slack要約、Notionページ、PDFエクスポートには、似ているが違うルールが混ざりがちです。AIがそれらをすべて検索できても、現在の答えを見つけられるとは限りません。

RAGの考え方は重要です。外部知識を検索して回答を根拠に結び付けられるからです。同時に、Lost in the Middleの研究は有用な警告を与えています。コンテキストを増やしても、モデルが正しい情報をうまく使うとは限りません。実務では、より小さく権威ある検索単位を設計する必要があります。

RedditやAIエージェント開発者コミュニティでも、context selection、provenance、trustがモデル品質と同じくらい重要だという声が繰り返し出ています。これらは証拠ではなく現場シグナルとして扱います。それでも運用上の結論は明確です。所有者が明確な少数の最新情報源は、巨大な過去文書の山より強いです。

4. 情報源の優先順位: エージェントが読む前に勝者を決める

情報源の優先順位は、ツールを接続する前に書いておくべきです。顧客対応なら、署名済み契約書、現在の公開ポリシー、社内SOP、CRMステータス、承認済みテンプレート、議事録の順になるかもしれません。財務なら、会計システム、請求書、銀行記録、スプレッドシートの順になるかもしれません。順番は会社ごとに違いますが、順番そのものは必要です。

このルールはよくある罠を防ぎます。議事録には「返金ルールの変更を検討中」と書かれ、ポリシーページには「この金額以上は承認が必要」と書かれているかもしれません。優先順位がなければ、エージェントは二つを混ぜて、もっともらしいが正式ではない答えを作ることがあります。

• 業務ごとに情報源の階層を書く。
• 下書きや議事録は正式ルールではなく背景資料として扱う。
• 顧客向けの約束より、契約書と現在のポリシーを優先する。
• エージェントに使用した情報源の階層を示させる。
• 上位情報源がない場合は回答せずエスカレーションする。

5. 鮮度: 担当者、最終レビュー日、失効条件、更新トリガー

鮮度には四つの項目が必要です。担当者は誰がルールを保守するかを示します。最終レビュー日は人がいつ確認したかを示します。レビュー周期はどれくらいの頻度で確認するかを示します。更新トリガーは、価格変更、契約変更、ポリシー変更、新しい法的要件、レビュー担当者による同じ修正の繰り返しなど、何が起きたら必ず見直すかを示します。

多くのAIナレッジベースはここで静かに古くなります。エージェントは意味的に関連しているからそのページを取得します。しかし、関連していることと今も正しいことは別です。よく書かれた古いページは公式に見えるため、空の検索結果より危険なことがあります。

NIST AI RMFが役立つのもここです。AIリスクを一度の設定ではなく、組織とライフサイクルで管理する問題として見ているからです。小さな会社向けに言えば、重要な知識資産には担当者とレビューのループが必要です。

6. 矛盾ルール: エージェントは推測せず止まるべき

最も価値のある行動が、回答しないことになる場合があります。エージェントが関連性の高い二つの情報源を見つけ、その内容が違うなら、両方を示して担当者に渡すべきです。入力自体が矛盾しているときに自信を持って合成するのは、間違った動きです。

よい矛盾対応はこう言います。「矛盾しているように見える二つのルールを見つけました。現在のポリシーページはAと言い、より新しい会議決定はBと言っています。どちらが正式か判断できません。Source of Truthを確認してください。」この停止が、社内の曖昧さを外部の被害に変えないための防波堤になります。

• 同じテーマの情報源が違うルール、基準値、日付、担当者を示していないか検出する。
• 最上位の情報源でも、十分に新しい場合だけ優先する。
• 鮮度や権威が不明なら、根拠を示してエスカレーションする。
• 解決した矛盾はSOPとevalケースに変える。

7. Guildex式の知識準備チェックリスト

AIに社内知識を読ませる前に、一つの業務について小さな知識統制シートを作りましょう。巨大なプラットフォームは不要です。Notion、Google Sheets、GitHub、Obsidianの表でも、項目が守られていれば始められます。

このチェックリストは、エージェントの出力をレビューする人がすぐ見られる必要があります。レビュー担当者が、AIが最新ルールを使ったのか古いメモを使ったのかを推測する状態にしてはいけません。

• Workflow: この知識が支える業務。
• Allowed sources: エージェントが検索してよい情報源。
• Source priority: 情報源が食い違ったときに何が勝つか。
• Owner: 各ルールを保守する人。
• Freshness: 最終レビュー日、レビュー周期、失効トリガー。
• Citation rule: いつ情報源を表示するか。
• Conflict rule: いつ止まり、人に渡すか。
• Eval cases: 情報源の優先順位、鮮度、矛盾処理をテストする例。

8. 結論: 知識アクセスは保存場所ではなく保守システム

AI導入は、エージェントがより多く読めるだけでは安定しません。どの情報源が勝つか、どのルールが最新か、誰が所有するか、知識が曖昧なときにエージェントが何をすべきかをチームが決めたときに安定します。

ナレッジベースを保存フォルダではなく、保守システムとして扱ってください。一つの業務から始め、情報源の階層、鮮度ルール、矛盾時の行動、担当者、evalケースを書きます。その後でエージェントに読ませます。この順番が、よいデモを高くつく反復ミスに変えないための基本です。