ケーススタディ: 社内ナレッジ Agent(RAG 運用)

注記: 本記事は、本ライブラリの設計判断を 1 つの物語で通すために構成した**架空の事例(構成事例)**です。登場する組織・数値は実在のものではありませんが、各段階の判断と失敗は実際のプロジェクトで広く観察されるものに基づいています。

この記事の目的

「社内の文書に何でも答える Q&A Agent」という定番の題材を通して、RAG を作る話ではなく運用し続ける話 — 権限反映検索と知識源の鮮度管理 — の設計判断を実例で掴みます。経費精算アシスタントの事例が技術構成の育て方、カスタマーサポート Agent の事例が案件推進に重心を置くのに対し、本記事は「知識源という資産の運用」に重心を置きます。

対象読者

社内ナレッジ検索・Q&A への Agent 導入を設計・運用するエンジニア
RAG の PoC は動いたが、権限と情報の陳腐化への対処に確信が持てない人

前提知識

データ漏えい対策 — 権限を越えた情報流出の経路と対策

本文

背景: 題材と出発点

題材は従業員数千人規模の企業の社内ナレッジ Agent です。規程・申請手順・製品ドキュメント・過去の議事録が wiki・ファイルサーバー・各部門のツールに散在し、「どこに書いてあるか分からない」「情シスと人事に同じ質問が繰り返し来る」状態でした。経営層の期待は「社内のことを何でも答える AI」でしたが、着手時にこの期待をそのまま要件にせず、2 つの制約から範囲を決めました(ユースケース発見と要件定義)。

答えの検証可能性: 「出典文書を必ず提示し、出典のない回答はしない」を仕様にしました。回答の正しさを利用者と文書オーナーが検証できることが、後の改善ループの前提になります
知識源の統制可能性: 「何でも」ではなく、オーナー(管理責任者)と公開範囲がはっきりしている文書だけをインデックスに入れると決めました。誰も保守していない文書は、間違っていても直す人がいないためです

設計: 第 1 段階 — 全社公開文書だけで始める

最初のリリースの知識源は「全社員が閲覧できる文書」(全社規程・共通手順・社内 FAQ)に限定しました。部門限定文書を最初から入れなかったのは、権限反映検索が未実装の段階では権限が必要な文書をそもそもシステムに存在させないことが、唯一壊れようのない分離だからです。機能を絞る代わりに、構成は本番前提で作りました。

取り込みはチャンキング + メタデータ(文書 ID・オーナー・最終更新日・公開範囲)を必須とし、メタデータが埋まらない文書はインデックスに入れない(RAG 実装パターン)
回答には出典(文書名・該当箇所・最終更新日)を常に表示する。更新日を出すのは、利用者自身が「古いかもしれない」と判断できるようにするためです
評価は検索(必要な文書が上位に来るか)と生成(出典に忠実か)を分離して測り、リリース判定はログ由来 + 想定質問の評価セットで行いました(評価データセットの構築と保守)

設計: 第 2 段階 — 権限反映検索

利用が定着すると「部門の手順書も検索したい」という要求が来ました。ここで初めて権限反映検索(ユーザーごとのアクセス権を検索結果に反映する仕組み)を実装しました。設計の要点は 4 つです。

検索段でのフィルタ: 利用者の所属・グループを検索クエリの必須フィルタとして検索基盤の層で強制します。「全部検索して、答えるときに権限外を伏せる」方式は、権限外の内容がプロンプトに載った時点で漏えいリスクになるため採用しませんでした(データ漏えい対策)
誰の権限で検索するかの明確化: Agent はサービスアカウントで広く読むのではなく、質問した本人の権限の範囲で検索する構成にしました(ユーザー代理型。エージェントの認証・認可)
権限同期の遅延への対処: 元システム(wiki・ファイルサーバー)の ACL とインデックス側のコピーは同期のたびにずれます。異動・剥奪が反映されるまでの窓を許容できるか法務・情報セキュリティ部門と合意し、機微度の高い文書カテゴリは「検索ヒット後、回答前に元システムで権限を再確認する」二段構えにしました
存在の秘匿: 権限のない文書は「アクセスできません」ではなく「存在しない」と同じ振る舞いにしました。文書のタイトルや存在自体が情報(例: 組織再編の計画書)だからです

このほか、見落としやすい点として派生データの権限があります。チャンク・埋め込み・要約・キャッシュされた回答は原本の ACL を引き継ぐ必要があり、原本より緩い場所に置いた瞬間に権限反映は破れます。

結果: 運用で判明した最大の失敗モード — 鮮度

権限よりも高頻度で起きた問題は、廃止・改定済みの文書を出典に、自信のある回答が返ることでした。旅費規程の改定後に旧規程で答える、統合済みの旧手順を案内する、といった失敗です。モデルにも検索にも非はありません — インデックスに古い文書が残っていることが原因で、これは技術の問題ではなく運用の問題でした。対処は次の順で効きました。

文書のライフサイクルをメタデータ化: 最終更新日に加えて「有効/廃止」「後継文書へのポインタ」を持たせ、廃止文書はインデックスから除外(または明示的な格下げ)
再インデックスの二本立て: 全体は定期(夜間)、規程などの重要文書は更新イベントで即時反映
「古い」ボタンによる還流: 回答画面に「情報が古い/違う」の報告ボタンを付け、報告は文書オーナーへの更新依頼として起票する運用にしました。Agent の改善(検索・プロンプト)ではなく文書の改善に還流させるのがポイントです(フィードバックループの運用)
新旧混在の検知: 同一トピックで更新日が大きく離れた文書が同時に検索上位に来たら、回答内で新しい方を優先し、古い方の存在を注記する挙動にしました

この運用を回した副産物として、「どの文書に誰が責任を持ち、いつ更新されたか」の台帳が整備されていきました。振り返ると、Agent の品質改善の実体は文書資産の整備であり、Agent 導入がドキュメント整備を進める強制力(フォーシング関数)として働いた形です。

設計判断: この事例の教訓

権限は「入れない」が最強の分離 — 権限反映検索が実装されるまでは、権限が必要な文書をインデックスに入れないという段階設計にしたことで、未実装期間の漏えいリスクが構造的にゼロでした。機能の段階導入とリスクの段階導入を一致させる考え方です
鮮度は技術ではなく運用の問題 — 検索アルゴリズムをいくら改善しても、古い文書がインデックスにあれば古い回答が返ります。文書のライフサイクル管理とオーナー制度が、リランキングより先に効きました
回答品質の還流先は Agent とは限らない — 「悪い回答」の報告の多くは、Agent ではなく文書の修正で解決しました。フィードバックの宛先を「Agent チーム」と「文書オーナー」に振り分ける設計が、改善速度を決めました

実務での注意点

アンチパターン

とにかく全文書を一括インデックスしてから考える → オーナー不在・権限不明・廃止済みの文書が混入し、誤答と漏えいの温床になる → 公開範囲とオーナーが明確な文書から段階的に取り込む
権限フィルタを生成段(プロンプトへの指示)でかける → 権限外の内容がコンテキストに載った時点で漏えい経路になる → 検索基盤の層で、付け忘れられない形のフィルタとして強制する
鮮度メタデータなしでインデックスする → 廃止規程を出典にした自信満々の誤答が続き、利用者の信頼を失う → 最終更新日・有効/廃止・後継ポインタを取り込みの必須条件にする
「アクセスできない文書があります」と表示する → 文書の存在自体が機微情報として漏れる → 権限外は「存在しない」と同じ振る舞いにする
架空事例の構成(段階の切り方・対処の順序)を唯一解として引用する → 組織の文書事情・権限モデルにより最適な段階は変わる → 判断根拠(検証可能性・統制可能性・段階とリスクの一致)の方を持ち帰る

チェックリスト

インデックス対象を「オーナーと公開範囲が明確な文書」に限定する基準がある
出典(文書名・箇所・最終更新日)のない回答を返さない仕様になっている
権限フィルタが検索段・基盤層で強制されている(生成段の指示に依存していない)
誰の権限で検索するか(ユーザー代理/サービスアカウント)を明示的に決めた
権限同期の遅延幅を関係部門と合意し、機微カテゴリの再確認手順がある
チャンク・埋め込み・キャッシュなど派生データが原本の ACL を引き継いでいる
廃止・改定のライフサイクルがメタデータ化され、再インデックスの経路(定期 + 即時)がある
「情報が古い」報告が文書オーナーへの更新依頼として還流する運用がある

参考資料

Building Effective Agents(Anthropic) — シンプルから始めて計測しながら広げる進め方の原典(アクセス日: 2026-07-07)

TODO・未確認事項

なし