社内AIの回答を確認できる形にする｜RAGの出典と更新日の表示

回答のどの部分を、どの出典で確かめるか

本稿では、回答を確認可能にする単位を「回答全体」ではなく「業務上の判断を含む記述」とすることを提案します。例えば、経費申請の質問に対して申請期限と承認経路を答える場合、それぞれに根拠となる文書の箇所を対応させます。末尾に文書をまとめて並べるだけでは、期限の根拠がどこにあるのか利用者が探し直すことになります。表示は、回答の記述、短い根拠抜粋、文書名、章やページ、原文を開く操作を一組とし、複数文書を組み合わせた箇所はその関係も示す設計です。

検索で見つかった文書と、回答を実際に支える文書は分けて扱います。例えば、申請期限を示す規程は見つかっても例外時の承認者が不明なら、承認者を推測して補うのではなく、その部分を確認待ちとして表示します。生成結果は構造化し、出典識別子が検索結果に存在するか、参照箇所が取得できるかをアプリ側で検証する案です。ただし、識別子の整合だけでは記述内容の裏付けまで確認できないため、原文との意味の対応は別に評価します。出力の表示前検証と構造化は[2]で挙げられています。[2]

• 回答の重要な記述から、対応する根拠箇所へ移動できるか。
• 検索候補と採用した出典を区別し、根拠不足の記述を明示しているか。

更新日は何の時点を表すのか

本稿では、原文の更新日時、検索用データへの反映日時、回答生成日時を分けて保持することを提案します。原文が更新されても検索用データが旧版のままなら、回答画面に新しい更新日だけを表示すると、最新の内容を使ったように見えてしまいます。例えば、申請手順が改訂された直後に取り込みが失敗した場合は、回答が参照した版と反映状況を表示し、最新版への反映が確認できていないことを知らせます。日時を取得できない文書では空欄を現在日時で埋めず、「更新日時不明」と版の識別情報を使います。

文書の更新日と業務上の施行日は別に扱います。例えば、来月から適用する手順が今月公開された場合、更新日が新しいという理由だけで現在の申請に適用する設計は避けます。質問の対象日と文書の適用期間を照合し、対象日が不明なら利用者に確認する案です。新旧の規程が同時に見つかったときも、単純に新しい文書を優先せず、適用対象や有効期間を確認します。画面には回答時点で使用した版を残し、原文リンク先だけが最新版に置き換わる場合は、過去回答の根拠と一致しない可能性を区別します。

• 更新日時の取得元とタイムゾーンを決め、反映日時と混同していないか。
• 旧版、施行前、更新日時不明の場合に表示と回答方針を切り替えられるか。

原文へのアクセス権限を回答とどうそろえるか

本稿では、利用者が参照できる範囲を検索対象にも適用し、検索結果から回答を組み立てる前にアプリ側で権限を確認することを提案します。例えば、人事担当向け文書から個人の処遇情報を取得し、原文リンクだけを一般利用者に非表示にしても、回答や抜粋に内容が残れば保護になりません。文書名自体に個人情報が含まれる場合もあるため、本文だけでなくタイトルや候補一覧も対象にします。モデルの出力だけに認可を依存させず、実行側で制御する考え方は[2]に基づきます。[2]

検索用データに保持する権限情報と原文側の権限がずれる場面も設計対象です。例えば、部署異動後に過去の回答履歴を開く利用者には、保存当時の表示内容を無条件に再表示しない方針を提案します。履歴を開く際と原文を取得する際に現在の参照可否を確認し、確認できなければ内容を表示せず、その状態を区別します。共有キャッシュについても質問文だけをキーにせず、利用者ごとの参照範囲を考慮します。利用者やセッション間の文脈分離と最小権限は[2]で示されており、ここでは履歴とキャッシュの設計に応用しています。[2]

• 閲覧権限の異なる利用者で、回答、文書名、抜粋、履歴の表示を比較したか。
• 原文側の権限を確認できない場合の扱いと、キャッシュの分離条件を定めたか。

参照文書に命令が書かれていたらどう扱うか

出典として表示する文書であっても、その中の指示をAIの動作命令として扱うべきではありません。OWASPは、取得文書など外部コンテンツに埋め込まれた指示による間接的なプロンプトインジェクションを扱っています。[1] 本稿では、手順書に「別の文書を送信せよ」といった文が混入しても、業務上の参考データとして処理し、権限変更や外部送信の指示には使わない構成を提案します。指示と文書データを分離した入力形式にし、文書に出典があることと、その内容を実行してよいことを切り離します。

表示部分では、回答や抜粋に含まれる装飾やリンクも確認対象です。例えば、取得文書のリンク文字列をそのまま採用すると、原文を開く操作のつもりで別の送信先へ誘導する表示を作る可能性があります。本稿では、出典リンクをアプリが管理する文書識別子から組み立て、許可した参照先だけを使う設計を提案します。HTMLやMarkdownの表示対策は[1]でも挙げられています。確認には機密情報ではなくダミー文書を使い、怪しい指示が回答に出なかったことだけでなく、不要な外部アクセスが発生していないかも観察します。[1]

• 文書中の指示を実行命令として扱わず、参照データとして分離しているか。
• 表示リンクの行き先と外部通信を、ダミーデータによる確認対象に含めたか。

API・Webhook・再実行で根拠をずらさないには

本稿では、画面とAPIで共通の回答識別子を使い、出典の文書識別子、版、該当箇所、反映日時を構造化して返すことを提案します。例えば、AI回答を別の業務画面へ送る際に本文だけを渡すと、受け取り側では根拠を確認できません。一方、Webhookへ原文抜粋や個人情報を無条件に同梱すると、送信先に不要な情報を広げます。受け取り側の用途に応じて項目を絞り、必要な利用者が認証後に根拠を取得する構成を検討します。APIやツールを通じた情報流出と権限範囲の制限は[2]の対象です。[2]

再実行は、同じ回答の再配信と、最新の文書で回答を作り直す処理を区別します。例えば、通知失敗を理由に再送しただけなのに再検索まで走ると、最初の画面とは別の版に基づく回答が配信されることがあります。本稿では、再配信は元の回答識別子を維持し、再生成は新しい識別子と生成日時を付ける案とします。送信直前の権限確認、重複送信の識別、失敗回数の上限も個別に定めます。参照専用の処理に更新用権限を与えず、無制限な再試行を避ける方針は、最小権限と再試行制限を示す[2]に基づきます。[2]

• 再配信と再生成を別の操作とし、回答識別子と文書版を追跡できるか。
• Webhookの送信項目、送信先の権限、重複時と失敗時の処理を決めたか。

公開前の確認表で何を残すか

本稿では、公開判断に使う確認表を、試した条件と実際の観察結果を対にして残す形式にすることを提案します。例えば、通常の質問で出典が表示されても、権限を失った後の履歴表示や、更新処理が途中で失敗した場合まで確認したことにはなりません。以下は確認項目のひな型であり、結果はすべて未実施です。実施時には対象のアプリ版、モデル、検索設定、使用したダミー文書、確認担当を別途記録します。OWASPも確認結果の証拠と構成情報を残し、観測不足を成功扱いしないことを求めています。[1][2]

• 未実施、期待どおり、期待と相違、判定不能を分けて記録する。
• 未解決項目ごとに、公開範囲を狭めるか公開を見送るかを判断する。

本番公開後は誰が何を保守するか

本稿では、文書内容の管理担当と、取り込み・検索・表示を保守する担当を分け、問い合わせの引継ぎ条件を決めることを提案します。例えば「回答が古い」という連絡では、原文自体が古いのか、取り込みが止まったのか、別の適用期間の文書を選んだのかで調査先が変わります。受付時には回答識別子と発生時点を集め、まず処理状態を確認し、内容の解釈が必要な場合に文書管理担当へ引き継ぎます。問い合わせ本文へ原文や個人情報を大量に貼る運用ではなく、必要な担当だけが参照できる経路を用意します。

保守用ログには、回答識別子、参照文書の識別子、版、認可結果、処理状態など、原因の切り分けに必要な項目を選びます。質問文や全文抜粋を無条件に保存せず、個人情報の除外と保管範囲を決める案です。機微情報を除外したログと監視は[1]、個人情報や資格情報を平文で記録しない方針は[2]に示されています。また、検索設定やプロンプトを変更するときは確認表の関連項目を再実施し、問題が続く場合に対象文書の検索停止や回答機能の一時停止を選べるよう、操作担当と復帰条件も引き継ぎます。[1][2]

• 文書内容、取り込み失敗、表示不具合ごとに引継ぎ先を決めたか。
• ログの閲覧範囲と保管方針、機能停止の操作担当と復帰条件を定めたか。

よくある質問

文書の管理担当が不在の場合、その文書を公開対象にできますか。

本稿では、内容の有効性を判断する代替担当が決まらない文書は、新規の回答対象へ追加しない案を提案します。既存文書については業務影響を確認し、対象から外すか、確認待ちとして利用範囲を限定します。アプリの保守担当が内容の正しさまで代わって承認した扱いにはしません。

本番と同じ権限構成の確認環境がない場合はどうしますか。

ダミー文書と参照権限の異なる検証用利用者を用意し、再現できた範囲だけを結果として残す案です。原文サービスとの権限連動など再現できない項目は判定不能とし、対象文書や利用者を限定する判断につなげます。本番の個人情報を検証環境へ複製して不足を埋める方法は採りません。

期限付きの例外として古い版を使いたい場合はどうしますか。

本稿では、例外を認める担当、対象業務、使用する版、終了日、解除条件を記録する案を提案します。画面にも通常の最新情報とは異なることを表示し、期限後は自動で通常扱いへ戻さず、最新版への切替確認を行います。どの版でもよいという包括的な例外にはしません。

原文が一時的に開けないだけなら、回答を使い続けてもよいですか。

本稿では、単なる取得障害と権限確認の失敗を区別する案を提案します。権限が確認できない場合は内容を表示しない方針とし、取得障害だけの場合も、根拠確認ができない状態を明示します。確認が業務判断の前提となる用途では回答の利用を止め、復旧後の再確認へ回します。

参考・関連資料

• [1] LLM Prompt Injection Prevention - OWASP Cheat Sheet Series ↗
• [2] AI Agent Security - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-25。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。