AIエージェントの品質を語るとき、私たちはつい「どんなモデルを使うか」「どんなプロンプトを与えるか」に目を奪われる。だが実運用でエージェントの回答精度をじわじわと蝕むのは、多くの場合そのどちらでもない。エージェントが実行時に参照する外部知識——社内文書コーパスやRAGインデックスである。ここが古びていれば、最新のモデルに最良のプロンプトを与えても、返ってくるのは「昨年の就業規則」「廃止された料金表」「すでに差し替えられた手順書」に基づいた、もっともらしい誤答だ。
やっかいなのは、この劣化が静かに進むことである。モデルは落ちていない。プロンプトも壊れていない。テストも通る。それでも、参照している知識が現実からずれた瞬間、エージェントは「自信を持って古い答えを返す」状態に陥る。誰も気づかないまま、顧客対応や社内問い合わせの精度が数パーセントずつ削れていく。これは障害としてアラートに乗らない、もっとも検知しづらい種類の品質劣化だ。
筆者は25年以上にわたりエンタープライズITの運用現場（NOC／TAC）に携わり、現在は独立コンサルタントとしてAIエージェントの運用設計を支援している。本稿は、先日公開したPromptOps編（”指示資産”の版管理）の姉妹編として、エージェントのもう一つの可変資産＝“参照する知識”を、版管理・鮮度・評価の対象として運用する専業ディシプリンを扱う。対象読者は、RAGやナレッジベースを本番投入したものの「入れたあとの運用」が属人化している、情報システム部門・AI導入担当・SREの方々である。
本稿の位置づけ——”覚えたこと”ではなく”参照するもの”の運用
混同されやすいので、既存の論点との境界を先に引いておく。エージェントの「知識」にはいくつかのレイヤーがあり、それぞれ運用の作法が違う。
- メモリ（長期記憶）との違い：以前扱った「エージェントが”覚えた”エピソード記憶（mem0など）」は、エージェント自身が対話を通じて蓄積・忘却する内部の記憶だった。本稿が扱うのは外部の”参照知識”——組織が管理する社内文書コーパスとRAGインデックスである。「覚えたこと」ではなく「参照するもの」の運用だ。
- コンテキストエンジニアリングとの違い：あちらは実行時に、限られたコンテキストウィンドウへ「何を・どれだけ載せるか」の予算管理だった。本稿は実行前の、知識ベース側の鮮度・整合・評価の運用である。載せる中身そのものの信頼性を担保する話だ。
- トレーニングタイム・ポイズニングとの違い：あちらはRAGインデックス更新を”攻撃”から守るセキュリティの話だった。本稿は平時の”品質・鮮度・整合”の信頼性運用を扱う。悪意がなくても知識ベースは劣化する、という前提に立つ。
- PromptOps編との連続性：あちらは”指示資産”の版管理。本稿はその知識版＝”参照資産”の版管理という位置づけになる。プロンプトとナレッジは、エージェントを構成する二つの可変資産であり、どちらも「設定」ではなく「運用対象の資産」として扱うべきだ、というのが両稿を貫く主張である。
言い換えれば、リリース時に定義した知識・データ面のリリース資産を、投入後もライフサイクルとして回し続けるための運用設計——それが本稿のテーマだ。
なぜ”入れて終わり”の知識ベースは静かに劣化するのか
RAGの構築ガイドは世に多いが、その大半は「文書をチャンク分割し、埋め込みを作り、ベクトルDBに入れる」までで終わる。しかし本番のナレッジベースは生き物だ。放置すれば、次のような形で劣化が始まる。
- 原本の更新がインデックスに反映されない：社内Wikiや共有ドライブの元文書は更新されているのに、再インデックスが走らず、エージェントは古いスナップショットを参照し続ける。
- 矛盾する文書が同居する：新旧の手順書、部署ごとに異なるルール、下書きと確定版が同じインデックスに入り、検索のたびに「どれが正か」がぶれる。
- 陳腐化・重複の堆積：一度も参照されない文書、内容がほぼ同じ重複文書がインデックスを膨らませ、検索ノイズと運用コストを増やす。
- 権限ドリフト：元文書のアクセス権は絞られたのに、インデックス側には古い全文が残り、本来見せてはいけない情報がエージェント経由で漏れる。
これらはいずれも「システム障害」としては現れない。だからこそ、知識ベースを”監視・評価・棚卸しの対象”として明示的に運用する規律が要る。以下、その具体像を五つの柱で示す。
第1の柱：知識レジストリ——版・鮮度・出所・所有者・失効を台帳化する
運用の出発点は、「どの知識が、いつの時点の、誰の管理下にある、いつまで有効な情報か」を一覧できる台帳を持つことだ。個々の文書やチャンクに対して、最低限このメタデータを付与する。
| 項目 | 意味 | 運用上の使いどころ |
|---|---|---|
| 版（version） | その知識のバージョン識別子 | 回答の根拠追跡・ロールバック |
| 鮮度（last-updated） | 原本の最終更新日時 | 鮮度SLA違反の検知 |
| 出所（source / lineage） | 元文書のパス・URL・取得元 | データ来歴の担保・再取得 |
| 所有者（owner） | その知識に責任を持つ人・部署 | 更新・失効の判断者を明確化 |
| 失効（TTL / expiry） | 有効期限・見直し期日 | 陳腐化の自動フラグ立て |
ポイントは「所有者」と「失効」を必須にすることだ。所有者のない知識は誰も更新しないし、失効期日のない知識は永遠に棚卸しされない。台帳がなければ、後述する鮮度SLAも整合性チェックも回しようがない。まずここを土台に据える。
第2の柱：鮮度SLAと再インデックス運用——更新検知・差分反映・再構築
知識には「どれだけ新しくあるべきか」の要求水準がある。料金表や在庫情報は日次、就業規則は改定のたび、製品マニュアルは月次——というように、知識の種類ごとに”鮮度SLA”を定義する。そのうえで、SLAを守るための再インデックスを三段階で回す。
- 更新検知：原本側の変更をどう捕まえるか。ファイルのハッシュ・更新日時の監視、CMSやWikiのWebhook、定期クロールなどで「変わった文書」を特定する。
- 差分反映（増分インデックス）：変わった文書だけを再チャンク・再埋め込みして更新する。全件再構築はコストが高いため、平時は差分反映を基本にする。
- 再構築（フルリインデックス）：埋め込みモデルの入れ替え、チャンク戦略の変更、破損の疑いがあるときは全件を作り直す。実行時期とロールバック手順をあらかじめ決めておく。
そして必ず、「鮮度SLA違反」を可観測にする。「更新から○日以上経過し、かつ再インデックス未実施の文書がN件」といったメトリクスをダッシュボードに出し、閾値を超えたらアラートを上げる。障害にならない劣化を、あえてアラート化するのがこの柱の勘所だ。
第3の柱：整合性チェック——重複・矛盾・権限ドリフト
鮮度が保たれていても、インデックスの中身が矛盾していれば回答はぶれる。定期的に、次の三点を機械的に点検する。
- 重複：埋め込みの近傍探索で「ほぼ同一」の文書ペアを洗い出し、正本を一つに寄せる。重複は検索ノイズとコストの両方を増やす。
- 矛盾：同じ問いに対して相反する記述を持つ文書を検出する（例：旧料金と新料金、旧手順と新手順）。完全自動化は難しいが、ゴールデン質問（後述）に対して複数文書が食い違う根拠を返すケースを拾えば、矛盾の多くは炙り出せる。
- 権限ドリフト：原本のアクセス権とインデックス側の可視範囲を突き合わせ、「原本では閲覧制限されたのにインデックスに残っている」文書を検出・除去する。これはセキュリティ・コンプライアンス上もっとも見落とされやすいため、鮮度チェックと同じ頻度で回すことを勧める。
第4の柱：知識評価——”その文書は回答精度に効くか”を測る
ここが、単なる「RAG構築」と「KnowledgeOps（知識運用）」を分ける最大のポイントだ。知識ベースに文書を足すことは誰でもできる。だが「その文書が実際に回答成功率へ寄与しているか」を測っている組織はほとんどない。評価の骨格はこうなる。
- ゴールデン質問セット：現場の代表的な問い合わせを、正解付きの評価用データセットとして固定する。プロンプトの回帰テストと同じ発想を、知識側に持ち込む。
- 寄与度計測：ある文書がインデックスに「ある場合／ない場合」で、ゴールデン質問への回答成功率がどう変わるかを測る。回答に一度も引かれない文書、あっても精度が変わらない文書は、”効いていない知識”だ。
- 回帰の監視：再インデックスや差分反映のあとで、ゴールデン質問の成功率が下がっていないかを毎回チェックする。知識の追加が既存の回答を壊す「知識のデグレ」を、リリースの都度検出する。
この評価を回すと、「量を増やすほど賢くなる」という思い込みが崩れる。実際には、効かない文書・ノイズになる文書を”減らす”ことで精度が上がる局面が多い。知識評価は、次の棚卸しに直結する。
第5の柱：棚卸しと失効——陳腐化・重複・参照されない文書を捨てる
最後の柱は、「捨てる」ための規律だ。知識ベースは足し算だけで運用すると必ず肥大化し、劣化する。定期的な棚卸しで、次の文書を失効（アーカイブ／削除）候補に挙げる。
- 陳腐化：失効期日（TTL）を過ぎ、所有者が更新も延長もしていない文書。
- 重複：整合性チェックで正本に寄せた結果、不要になった文書。
- 非参照：知識評価で「一定期間、回答に一度も引かれていない・引かれても精度に寄与しない」と判明した文書。
削除は必ず所有者の承認と、ゴールデン質問での事前・事後評価をセットにする。「消したら精度が落ちた」を避けるためだ。棚卸しをリリースサイクルに組み込み、四半期に一度など定例化することで、知識ベースは”太り続ける負債”ではなく”手入れされた資産”として維持できる。
まとめ——要点は3つ
本稿の主張を、三点に畳んでおく。
- 知識は「設定」ではなく「資産」である。エージェントが参照する社内文書コーパス／RAGインデックスは、プロンプトと並ぶ可変資産だ。版・鮮度・出所・所有者・失効を台帳化し、ライフサイクルとして運用する。
- 劣化は障害にならない。だから可観測にする。鮮度SLA違反、矛盾、権限ドリフト、非参照文書——これらは放置しても落ちない。あえてメトリクス化し、アラートに乗せることで初めて手当てできる。
- 「効くか」を測り、増やすより減らす。ゴールデン質問による寄与度計測と回帰監視を回し、効かない知識は棚卸しで失効させる。知識運用の巧拙は、足す力ではなく”捨てる規律”に出る。
“覚えさせて終わり”にしない。参照する知識を運用対象として設計しておくこと——それが、「いつの間にか古い答えを返す」エージェントを防ぐ、もっとも地味で確実な一手である。
よくある質問（Q&A）
Q1. 小規模なRAGでも、ここまでの運用は必要ですか？
まずは「知識レジストリ（台帳）」と「鮮度SLA」の二つだけで十分です。所有者と失効期日を持つだけで、劣化の大半は防げます。評価や棚卸しは、規模と重要度が上がってから段階的に足してください。
Q2. 鮮度SLAはどう決めればよいですか？
知識の種類ごとに「古い答えが返ると誰がどれだけ困るか」で決めます。料金・在庫は日次、規程は改定即時、一般解説は月次、といった具合に、影響度の高いものほど短く設定します。
Q3. 差分反映とフルリインデックスはどう使い分けますか？
平時は差分反映（変わった文書だけ）が基本です。埋め込みモデルの入れ替え、チャンク戦略の変更、破損の疑いがあるときだけフルリインデックスを計画実行します。
Q4. 知識評価の「ゴールデン質問」は何件くらい用意すべきですか？
最初は現場の頻出問い合わせ20〜50件からで構いません。正解付きで固定し、再インデックスのたびに回帰確認に使います。運用の中で「取りこぼした問い」を追加し、育てていきます。
Q5. 文書を消すのが怖いのですが、安全に棚卸しする方法は？
いきなり削除せず、まず「アーカイブ（インデックスから外すが原本は残す）」にします。ゴールデン質問で事前・事後の成功率を比較し、下がらないことを確認してから正式に失効させれば、リスクは最小化できます。
参考リンク
※本稿は一般的な運用設計の考え方を示すものであり、特定の製品・構成における動作や成果を保証するものではありません。実装にあたっては、自組織の要件・セキュリティポリシー・関連法令に照らしてご判断ください。
コメント