RAG評価で回答以外に測るもの — 検索・権限・更新・棄却

結論 — 良い回答と，答えてよい状態を分けて測る

RAG（Retrieval-Augmented Generation，検索拡張生成）の評価では，回答が正しいか，質問に答えているか，取得した根拠に忠実かが注目されます．いずれも重要ですが，企業の業務で使うには，それだけでは足りません．

質問には正しく答えた．しかし，その回答は本人に閲覧権限のない文書から生成されていた．

回答の正確性だけを見れば成功でも，システムとしては重大な失敗です．

回答は取得文書に忠実だった．しかし，現在の規程を尋ねたのに，半年前に失効した旧版を使っていた．

この場合も，根拠への忠実性が高いことと，業務上の正しさは両立しません．「良い回答を生成できたか」と「その根拠を使い，その利用者へ回答してよい状態だったか」を別々に測る必要があります．

本稿では，検索・認可・更新と有効時点・生成・棄却の五つを独立した契約として整理します．評価データと公開判定の例は設計案であり，CoRISEの実測結果や，そのまま適用できる安全性の保証ではありません．

五つの評価軸は，単純な処理順序ではない

RAGを「質問 → 検索 → 根拠 → LLM → 回答」とだけ捉えると，利用者や時点の条件が抜け落ちます．実際には，誰が，どの組織・権限で，いつの情報を尋ねているのかが，検索対象と回答可能性を変えます．

これは五つの評価軸であって，「検索してから認可すればよい」という実装順序ではありません．認可と有効時点の条件は検索範囲を制約し，生成前や回答を返す前にも確認が必要です．

1．検索 — 必要な根拠を取得できたか

回答が悪いと，プロンプトやLLMを調整したくなります．しかし，必要な文書や段落が入力に含まれていなければ，その根拠に基づく回答は生成側だけでは回復できません．モデルの内部知識で正解を推測できても，検証可能なRAGの成功とは区別します．

検索では，Precision@k，Recall@k，MRR，nDCGなどを使います．評価単位は文書，文書の版，チャンク，主張のどれなのかを先に固定します．同じ文書を細かく分割しただけで得点が変わる評価では，比較が困難です．

Ragasの指標名が似ていても，文書IDで測る再現率と，参照回答の主張で測る再現率を同じ数字として比較してはいけません．利用する版，指標クラス，評価モデル，参照情報を記録します．[1][2]

例えば「海外出張の宿泊費上限はいくらか」という質問では，古い規程，別部署の規程，FAQが意味的に近いことがあります．また，チャンク分割によって金額と適用条件が離れると，関連文書を取得しただけでは十分ではありません．

候補検索，権限・時点による絞り込み，キーワードとベクトルの検索結果の統合，再順位付け，最終的な根拠の選択を分け，どの段階で必要な情報が落ちたかを追います．ハイブリッド検索は候補生成の一方式であり，必ず独立した後段処理になるわけではありません．RAGCheckerも，検索と生成を分解して診断する評価を提案しています．[4]

2．認可 — その根拠を扱ってよかったか

意味的に近い文書と，閲覧してよい文書は別です．認可は，認証済みの利用者，所属テナント，グループ，文書のアクセス制御リスト（ACL），適用するポリシーに基づいて強制します．テナントIDやグループを，利用者が入力した検索条件だけから信用してはいけません．

特に注意したいのは，「上位20件を取得し，アプリケーションでACLを確認してから5件をLLMへ渡す」構成です．フィルター前の内容が外部の再順位付けモデル，共有キャッシュ，通常の追跡ログ，会話履歴へ流れれば，最終回答が安全でも漏洩は成立します．

ただし，検索基盤内部で候補を扱うことと，利用者の権限で使う後段へ候補を公開することは同じではありません． 全文書を扱う権限を持つ検索サービスの信頼境界内で候補を絞り込み，許可された結果だけを外へ返す設計は成立します．前段フィルターか後段フィルターかという名前だけで判断せず，誰がどの内容を扱える境界なのかを定義します．

Azure AI Searchの資料も，問い合わせ時の強制と，同期済みの権限情報を区別しています．確認した資料では，文字列によるセキュリティフィルターと，ACL / RBAC，Purview，SharePointのプレビュー機能は別の選択肢です．プレビューにはSLAが適用されず，本番利用は推奨されていません．機能名だけで同じ運用保証を想定せず，採用するAPI版と同期方式を固定します．検索時に認可していても，古いACLを参照すれば元システムの変更は直ちに反映されません．[5]

複数段階の検索では，最初の候補に権限があるだけでは足りません．グラフ展開や追加取得のたびに，新たに取得する根拠を認可します．arXivのプレプリントとして参照する2026年のRetrieval Pivot Attacksは，ベクトル検索からグラフ展開への境界で，別テナントの情報へ到達する危険を扱っています．特定の実験結果を一般的な安全性の保証には使えませんが，構成要素の接続点を評価する理由になります．[6]

認可は，露出の監査と非干渉性を組み合わせて評価する

未許可情報の露出件数は，認可違反が起きた場所を特定するために必要です．本文，文書名，抜粋，引用URL，件数を，生成，キャッシュ，ログ，会話状態などの出力先ごとに確認します．ただし，出口の列挙だけでは，未発見の経路や間接的な影響を捉えきれません．

そこで，Goguen–Meseguerの非干渉性の考え方を，RAGの観測可能な振る舞いへ適用します．[10] 利用者が参照できる情報を固定したまま，参照できない文書だけを変えても，その利用者が観測できる結果は変わらないことを設計上の目標にします．ポリシーが明示的に公開を認める集計情報などは，許可された情報として別に定義します．

利用者 $p$ に許可された内容・メタデータが等しい文書集合を $C \equiv_p C'$，利用者の観測を $O_p$ とします．質問，現在のポリシー，時点，モデルと初期状態を固定したとき，確率的なシステムでは次が目標になります．

$\mathcal{L}$は結果の分布です．これは元の非干渉性を本稿のRAG設計へ拡張した条件であり，LLMを一度ずつ実行して同じ文章が出るかという検査ではありません．回答，引用，棄却判定，件数，エラー，応答開始までの時間やストリーミングの進み方まで，何を観測に含めるかを明記します．ログの閲覧者や外部の評価器には，それぞれの権限に応じた観測範囲を定義します．

検証には，入力を変形して期待する関係が保たれるかを調べるメタモルフィック評価を使います．これは二つ以上の実行を比較する評価です．

決定論的な経路は完全一致を比較できますが，LLMの出力は温度0や同じ乱数種でも再現されるとは限りません．確率的な比較では，標本数，比較項目，許容差と信頼区間，多重比較の扱いを先に定めます．有意差が出なかったことは，同等性や非干渉性の証明ではありません． 許容差付きの判定も，厳密な分布一致とは区別します．

カナリアの未検出も安全性の証明ではありません．要約・言い換え・符号化による流出や，未観測の出口は別に残ります．本番の秘密を入れず，合成データと管理された出力先で実施する評価案です．本稿では実験を実行した結果を示していません．

検索統計，チャンク，グラフの接続点も認可境界に含める

禁止文書が本文として返らなくても，全文書から計算したBM25のIDF，スコア正規化，共有の近似近傍探索インデックス，キャッシュ，計算資源の競合を通じて，順位や遅延へ影響する可能性があります．これらは設計から導かれる検証対象であり，すべての検索器で同じ漏洩が起きるという実測結果ではありません．

テナント単位の分離は一つの対策ですが，同じテナント内でもACLが異なれば十分ではありません．要求する秘匿範囲に合わせたインデックス・統計の分離，許可範囲に基づく計算，公開を承認した固定統計などを比較します．遅延についても後段のフィルターだけでなく，候補生成と共有資源まで対象にします．

文書のACLや機密ラベルは，取得単位である各チャンクへ引き継ぐ必要があります．Azure AI SearchのPurview連携の資料も，ラベルを子チャンクへ射影しないと適切にフィルターされないと説明しています．この機能はプレビューであり，本番利用条件は別途確認します．[13]

Retrieval Pivot AttacksのLeakage@kは，最終文脈に含まれる未許可項目の個数です．Pivot Depthは，漏洩したケースにおける検索の起点から最初の未許可ノードまでの最短距離です．本稿では，露出先ごとの件数と，グラフ展開の深さ別の評価に利用できます．同論文のPD=2はチャンク → エンティティ → チャンクという二部グラフの構造に由来し，任意の構成で深さ2まで調べれば十分という基準にはなりません．より深い経路や別の接続形態も評価します．[6]

同論文は部品の接続によって情報が流出する実験例を示しますが，非干渉性の合成に関する一般的な不可能性定理を証明したものではありません．部品ごとの保証を組み合わせるには，共通のポリシー，観測者，状態の共有方法と接続条件が必要です．取得の起点だけでなく，展開・統合・再利用の各境界を検査します．

代替可能な根拠は，和集合のRecallではなく充足で測る

通常のRecall@kは，固定した関連集合のどれだけを取得したかを診断する指標として残します．ただし，複数の根拠が代替可能な場合，それらの和集合を分母にしても回答可能性は表せません．

利用者 $p$，質問 $q$，対象時点 $t$，知識のスナップショット $s$ と現在の認可条件の下で，回答に十分な最小根拠集合の族を $\mathcal{S}(p,q,t,s)$ とします．各集合は，許可され，有効で，互いに両立する根拠だけから構成します．例えば「現行規程」だけで十分な場合と，「承認済みFAQ＋適用条件」の組み合わせで十分な場合を，別の選択肢として表します．

$R_k$は後段へ渡した上位k件の集合です．いずれか一つの十分な組み合わせを含めば1，含めなければ0とします．回答可能なケース上の平均を充足率として報告します．複数の選択肢を全部取得する必要はありません．

回答不能なケースは空の集合族として表し，空集合を「十分な根拠」として入れません．そのケースは棄却評価へ回します．文書・版・チャンクの単位を揃え，kやトークン上限でいずれかの組み合わせを取得可能かも記録します．部分的な根拠の不足は主張別の網羅率などで診断します．

充足率が1でも，禁止根拠や未解決の矛盾を同時に渡していれば別の契約違反です．十分性，認可，矛盾の処理，生成の正確性を独立に判定します．

権限失効は，インデックスだけでは完結しない

昨日まで読めた文書が今日読めなくなった場合，元のACL，インデックスの権限情報，グループ情報やトークン，共有キャッシュ，会話履歴，生成待ちの処理に，古い許可が残る可能性があります．

評価では，失効後の新しい質問だけでなく，失効前に始まった長時間処理や，生成途中の応答，過去の会話を使った追加質問も含めます．キャッシュのキーを利用者別にするだけでは，同じ利用者の権限変更には追従できません．ポリシーの版や権限世代を結び付け，無効化または利用時の再認可を行います．

強い失効要件がある場合は，検索前の確認に加え，生成や回答の受け渡し時点での再確認，失効イベントによる進行中処理の中止も検討します．ストリーミングで既に利用者へ送った内容は，後から取り消せません．

反映時間の目標を決めても，その時間内の未許可アクセスが自動的に許容されるわけではありません．権限を確認できない間は回答を保留するなど，遅延中の扱いを別に定めます．認可サービスの停止や同期失敗時に，絞り込みを外して処理を続けない設計が必要です．

失効は，反映遅延に加えて順序の契約を定める

失効のp99が短くても，ACLと本文の更新順序が逆転すれば漏洩します．Zanzibarが扱うnew enemy problemには，利用者をACLから外した後に追加した内容を，古いACLで読めてしまう問題が含まれます．[11]

同論文は単なる定期同期ではなく，外部整合性とスナップショット読み取りを使い，ACLと内容の更新の因果順序を守ります．内容の版と不透明な整合性トークンzookieをアプリケーション側で原子的に保存し，その版の読み取り時には，トークンが示す時点以上に新しい認可スナップショットを要求します．自作の時刻やインデックス世代を一つ追加するだけで，同じ保証が得られるわけではありません．

内容に結び付いた鮮度の下限は，その内容より後に起きた失効まで自動的に含むものではありません．強い失効要件には，最新の失効を参照する認可経路や，認可と送信を協調させる仕組みが別に必要です．「送信直前に再確認する」だけでも，確認と送信の間の競合は残り得ます．既に送った情報は回収できません．

評価では，失効確定 → 本文更新 → 読み取り，本文更新 → 失効確定 → 読み取り，両者の同時実行を作ります．さらに，ACLイベントの遅延・欠落・重複・逆順到着，古いキャッシュ，グループからの脱退，進行中の応答を組み合わせます．各イベントの確定順序，内容の版，認可に使った版，送信時刻を記録し，最終的に同期できたかとは別に順序違反を判定します．

AzureのSharePoint連携では，子が継承するサイト・ライブラリ・フォルダーなどの権限変更は，通常の後続インデクサー実行だけでは自動反映されず，明示的な権限リフレッシュ等が必要です．固有権限を持つ項目の変更とは扱いが異なります．対象のプレビューAPIと同期方式を固定して評価する実例になります．[12]

3．更新 — 「最新」より「質問時点に有効」を確かめる

RAGを使っていることは，最新情報を使っていることの保証にはなりません．元文書が更新されても，取得，解析，チャンク分割，埋め込み，インデックス，キャッシュのどこかに古い内容が残れば，旧版を回答へ使います．

さらに，updated_atが新しい文書を選ぶだけでは不十分です．規程の改定日，施行日，取り込み時刻は別です．将来施行の規程や，誤字だけを訂正した旧版もあります．

上の例で「2025年10月時点の上限」を尋ねたならv2，「2026年10月現在の上限」ならv3が対象です．有効期間は開始を含み，終了を含まない区間として定義すると，境界時刻での重複を避けられます．実際の規程では地域・対象者・条項ごとの適用関係も確認します．

2026年9月公開のTimelyRAGは，改定前後の文書が強い意味的重複を持つ環境で，質問時点に合った版を選ぶ課題を扱っています．意味的な関連性だけでは有効な版を選べない，という設計上の論点を補強する研究です．[7]

過去の情報を尋ねる時点と，閲覧権限を判定する時点は分けます． 過去の規程が必要だからといって，その当時の権限を現在の利用者へ復活させてよいわけではありません．通常は，質問対象の時点には過去の日付を使い，認可には現在の利用権限を使います．

有効時間と記録時間を分け，質問からの時点抽出も評価する

時間は少なくとも二つあります．有効時間は規程が業務上いつ適用されるか，記録時間はシステムがその情報をいつ記録し，どの履歴を保持していたかです．これはSnodgrassが整理する双時間モデルの考え方です．[14]

例えば10月1日に，9月1日から有効だった規程の訂正を取り込んだ場合，「9月15日に適用される正しい規程」と「9月15日のシステムが把握していた規程」は異なり得ます．評価では有効時点と，参照できる記録の締切を別々に持ちます．

as_ofは有効時点を指定できますが，corpus_snapshotというIDだけで記録時間を表現できるとは限りません．そのスナップショットが含む取り込み・訂正・削除の履歴と確定点を定義して初めて，「いつの知識状態か」を再現できます．元システムの更新時刻，取り込み時刻，検索可能になった時刻も区別します．認可の判定時点は，これらとは別です．

現在の権限をどの対象へ適用するかも固定します．本稿の例では，過去版を独立したオブジェクトとして扱い，その版の現在のACLを確認します．版へ権限を継承する設計なら，文書系列の現在のACLと版固有の制限をどう合成するかを別に定義します．最新版への権限から過去版への権限を推測したり，昔のACLを復活させたりしません．

評価用に正しいas_ofを直接渡すだけでは，自然言語からの抽出工程を評価できません．生の質問，要求時刻，タイムゾーン，言語，必要なら会計年度の定義を入力し，期待する時点・期間・追加確認の要否を正解にします．「今の」「去年の」「改定前」や日付境界を含め，抽出単体と検索以降を含む全体を分けて測ります．曖昧な期間を一つの時点へ黙って丸めません．

有効期間と適用条件が信頼できる構造化データとして揃う場合は，決定論的な適格性判定を必須条件にします．順位付けの高得点で無効な版を採用してはいけません．認可と同様，除外の位置は信頼境界と検索の完全性を踏まえて選びます．

TimelyRAGは，最初に取得した候補を意味と時間の適合度で再順位付けする枠組みです．候補集合にない正解文書は回復できず，時間に合う版を常に選べる保証でもありません．[7] 有効性が条項ごとに異なる，または抽出が不完全な場合の補助として評価し，不確かな根拠は確認や棄却へ回します．VersionRAGも，版の系列，内容の境界，変更をグラフで表現する先行研究として参照できます．[16] どちらも認可や適用条件の強制を代替しません．

更新で測るもの — 反映遅延と版の正しさ

例えば更新遅延は，次の差です．

平均だけでなく，p95・p99，最大値，未反映件数を記録します．まだ反映していない更新を集計から落とすと，停止した処理ほど数字に現れなくなります．時刻同期と起点の定義も必要です．

削除は，検索結果からの利用停止と，チャンク・埋め込み・キャッシュ・バックアップからの物理的な消去を分けます．保持義務のあるバックアップまで即時消去できるとは限りませんが，保持するデータを通常の回答経路で再利用しないことは別に強制できます．削除済み文書の再取り込みや，旧キャッシュの復活も評価します．

4．生成 — 根拠から逸脱せず，質問に答えたか

生成では，回答の正確性，質問への関連性，根拠への忠実性，引用の正しさ，必要事項の網羅性を評価します．例えば宿泊費上限の金額だけでなく，通貨，地域，適用日，例外，対象者が回答に含まれるかを確認します．

RagasのFaithfulnessは，回答に含まれる主張が取得した根拠から支持されるかを測る指標です．[3] 有用ですが，根拠自体が古い，誤っている，または利用を許可されていなければ，その内容に忠実な回答もシステムとしては失敗です．

また，引用の正しさは「リンクが存在する」だけでは足りません．文書IDと版，該当箇所，回答中の主張との対応，利用者がその引用先を閲覧できることを確かめます．引用だけ安全に見えても，回答本文に別の文書の内容が混ざっていないかは別の確認です．

5．棄却 — 答えない判断も品質に含める

ここでの棄却とは，質問を捨てることではなく，利用可能な根拠では回答を確定できないと判断することです．根拠がない，対象業務の範囲外，権限がない，有効な版がない，根拠が矛盾する，という理由を区別します．状況によっては追加質問や担当者への引き継ぎを選びます．

UAEval4RAGは，回答不能な質問を六つの種類に整理し，回答可能な質問への対応と棄却の両方を評価します．[8] 2025年に初版が公開されたCRUMQsも，必要情報の欠落や複数文書をまたぐ推論を含む質問によって，RAGの限界を調べます．[9] これらの評価枠組みが，そのまま企業固有の権限や時点を網羅するわけではありません．

通常の検索処理では，許可された範囲だけを調べ，例えば次の内部コードを使います．

INSUFFICIENT_AUTHORIZED_EVIDENCE
OUT_OF_SCOPE
STALE_ONLY
CONFLICTING_EVIDENCE
INSUFFICIENT_CONFIDENCE

ここでの版や矛盾の判定も，認可された情報の中で行います．禁止文書の存在を調べてNO_EVIDENCEとUNAUTHORIZEDを区別する処理は，通常の回答経路へ追加しません．「権限不足」と断定しなくても，「利用可能な情報からは確認できません」と返せます．

UNAUTHORIZEDは，隔離した評価環境で特権を持つ正解判定器が付けるラベルに限定します．本番の通常ログやトレースへ転記すれば，そこが機密の出力先になります．明示的なアクセス拒否を特権監査へ記録する場合も，対象の存在を知ってよい主体，保存先，保持期間を別に定めます．評価用ラベルを生成器への入力にもしません．

棄却の指標は，分母と回答可能性の定義を揃える

評価上の回答可能性は，「モデルが答えられそうか」ではなく，固定した文書集合・現在の権限・質問対象の時点・業務範囲の下で，十分な根拠が存在するかから定義します．その判定を，評価対象の検索器自身に任せないことが重要です．

この二値判定では，指標を次のように定義できます．

最後の指標は，この二値判定では1から誤棄却率を引いた値であり，独立した情報ではありません．また，aに分類された回答が内容まで正しいとは限りません．回答したケースに限定した誤りの割合と，回答率も別に測り，両者の関係を確認します．分母が0の場合は未定義として表示します．

正解集合には十分な根拠があるのに検索で落とした場合，システム全体では誤棄却です．一方，生成器が「実際に渡された根拠だけでは答えない」と判断したことは適切な場合があります．この二つを分けると，検索の失敗を生成器へ押し付けずに診断できます．

追加質問，担当者への引き継ぎ，タイムアウトは，回答／棄却とは別の結果として件数を報告します．停止を棄却成功に数えたり，失敗した要求を母数から黙って除外したりしてはいけません．

棄却の閾値は，risk–coverage曲線で比較する

混同行列は一つの動作点です．回答を選ぶ基準を変えたときの関係には，選択的分類で使われるrisk–coverage曲線を利用できます．[15] これは閾値をなくす方法ではなく，複数の閾値で回答率と，回答したケースの誤りを比べる方法です．

評価ケース $i$ で閾値 $\tau$ の下で回答したかを $a_i(\tau)$，あらかじめ定義した回答の損失を $\ell_i$，全ケース数を $N$ とすると，例えば次で集計します．

回答不能な質問への断定や，根拠と矛盾した回答をどう損失へ数えるかを先に固定します．回答が0件ならリスクは未定義です．タイムアウトや引き継ぎは別に件数を報告し，回答率の母数から黙って除外しません．閾値の調整用データと最終評価用データを分け，用途別の曲線と不確かさを示します．

認可違反や無効な版の利用は，回答率と引き換えに緩める閾値ではありません．必須条件を満たすケースに対して回答選択を評価し，条件違反は別途公開を止めます．元論文の分類器に対する保証が，このRAGへそのまま適用されるとも扱いません．

評価単位を，質問と回答のペアから広げる

評価ケースには，少なくとも次を固定します．

同じ質問でも，一般社員と役員，所属テナント，過去時点か現在かによって期待値が変わります．正解となる根拠は，すべての利用者で同じではありません．

評価用データの例

以下は独自形式の例であり，特定の評価ライブラリへそのまま投入する設定ではありません．文書・利用者は架空で，グループ情報は信頼できる評価条件です．request_timeは「今」の解釈に使う入力，expected.resolved_as_ofは時点抽出の正解です．後者を入力へ渡すときは，検索以降だけの評価として区別します．

id: travel-policy-2026-001
corpus_snapshot: travel-fixture-2026-10-01
knowledge_cutoff: "2026-10-01T09:00:00+09:00"
policy_snapshot: policy-fixture-017
authorization_scope: version-object-current-acl
request_time: "2026-10-01T09:00:00+09:00"
timezone: Asia/Tokyo
locale: ja-JP
principal:
  tenant: example-corp
  user: user-123
  groups: [employees]
query: "現在の海外出張の宿泊費上限はいくらですか"
metamorphic_variants:
  - forbidden-document-added
  - forbidden-document-removed
  - forbidden-document-modified
expected:
  resolved_as_of: "2026-10-01T09:00:00+09:00"
  action: answer
  allowed_evidence:
    - travel-policy-v3
    - approved-travel-faq-v3
    - travel-scope-v3
  acceptable_evidence_sets:
    - [travel-policy-v3]
    - [approved-travel-faq-v3, travel-scope-v3]
  superseded_evidence: [travel-policy-v1, travel-policy-v2]
  expected_claims: [claim-hotel-limit-current]
  citation_rule: support-claims-with-used-permitted-evidence
oracle_only:
  forbidden_evidence: [executive-travel-policy-v3]

次は棄却のケースです．oracle_onlyは隔離した評価器だけが読む領域で，RAGへの入力，本番ログ，通常の追跡情報から除外します．

id: confidential-policy-001
corpus_snapshot: confidential-fixture-001
knowledge_cutoff: "2026-10-01T09:00:00+09:00"
policy_snapshot: policy-fixture-017
authorization_scope: version-object-current-acl
request_time: "2026-10-01T09:00:00+09:00"
timezone: Asia/Tokyo
locale: ja-JP
principal:
  tenant: example-corp
  user: user-456
  groups: [general]
query: "M&A検討中の企業を教えてください"
expected:
  action: abstain
  allowed_evidence: []
  acceptable_evidence_sets: []
  runtime_reason: INSUFFICIENT_AUTHORIZED_EVIDENCE
  public_response_class: insufficient_available_information
oracle_only:
  forbidden_evidence: [confidential-ma-project]
  reason: UNAUTHORIZED

十分な根拠の選択肢はacceptable_evidence_setsへ列挙し，文書の版とチャンクへ対応付けます．metamorphic_variantsは，許可された集合を変えずに禁止文書だけを変形する対の定義です．別に失効・本文更新の確定順序と配信順序を持つ時系列ケースを用意します．これらのIDや正解判定も機密性を持ち得るため，評価器の権限，保存範囲，保持期間を定めます．

文書集合に，意図的な難所を入れる

簡単な質問だけでは，境界の失敗を見つけにくくなります．合成文書や利用許可のある文書を使い，次の条件を作ります．

例えば一般社員向けの旅費規程と，文章がよく似た役員向け規程を置きます．後者の類似度が高くても，一般社員の回答経路へ渡してはいけません．利用者だけを変えた対になるケースや，ポリシーだけを失効させたケースを作ると，条件変更の影響を追いやすくなります．

LLMによる判定と，決定論的な検査を分ける

LLMを評価器として使う方法は，回答と根拠の意味的な対応，質問への関連性，参照回答との意味の一致を調べる際に役立ちます．ただし，評価器も誤り得るため，人が付けたラベルとの照合や，判断が割れたケースの確認が必要です．

ACLの適用，有効期間，削除状態，テナント境界は，固定したメタデータと正解ポリシーから検査します．評価対象と同じ誤った認可実装を正解判定にも使うと，失敗を見逃します．認可要件に基づいて別途定義した期待値を用意します．

評価モデルの版，プロンプト，生成条件を固定し，順序依存や再判定の揺れも記録します．評価用プロンプトへ渡す取得文書も信頼できる命令ではありません．判定を誘導する文書に対する耐性と，外部の評価サービスへ送信できるデータの範囲を確認します．

公開前の固定評価と，本番の観測を分ける

公開前は，固定した文書集合，ポリシー，質問群を使い，変更前後を同じ条件で比べます．プロンプト調整に使う集合と，最終判断に使う保留集合を分け，評価への過適合を抑えます．権限失効や削除などの時系列ケースは，状態の遷移を再現できる形にします．

本番では，文書や権限，質問の分布，モデルが変わります．固定評価に加え，検索・生成の遅延，検索結果の分布，更新待ち件数，権限同期の失敗，棄却率，旧版の引用率，キャッシュの経過時間，費用，利用者の訂正を継続的に観測します．棄却率の上昇だけでは，安全性の改善か検索障害かは判断できません．

利用者の質問にも機密情報が含まれます．「評価のため」という理由で全文保存を標準にせず，必要最小限の記録と，許可された抽出評価を組み合わせます．本番のすべての要求に正解ラベルがあるわけではないため，代理指標と人による確認を区別します．

公開判定を，一つのRAGスコアへまとめない

回答品質が0.92でも，未許可情報の露出が1件あれば公開を止めるべき状況があります．検索，認可，有効時点，生成，棄却，運用を別々の条件として扱います．

閾値と比較の許容差は用途ごとに事前定義するものであり，本稿の実測値ではありません．全体平均だけでなく，テナント，文書種別，権限，言語，質問時点，棄却理由ごとにも確認します．評価件数と不確かさを示し，少数の評価から過大な結論を出さないようにします．

0件という観測と，評価の網羅性を区別する

未許可情報の露出は，評価セットで0件を必須条件とします．ただし，共通の発生率 $p$ を持つ独立なベルヌーイ試行を $n$ 回行って0件だった場合でも，片側95%信頼上限は次の値です．

例えば独立な1,000試行で0件なら，上限は約0.3%です．これは許容する漏洩率ではなく，限られた観測から言える範囲です．同じ質問の反復や同じ失効事象を複数の出口で数えることは，そのまま独立な試行数にはなりません．意図的に選んだ攻撃ケースから，本番分布の発生率を推定することもできません．

件数とともに，利用者の権限 × 文書・チャンク × 出口経路 × 更新順序 × キャッシュ状態 × グラフ深さの網羅表を残します．二因子の組合せ網羅は規模を抑える手段ですが，三つ以上の条件が重なる障害を保証しません．重要な権限境界と攻撃経路は明示的に追加し，未評価の組合せを報告します．非干渉性の比較とカナリア探索は，この網羅表を補完します．

トレードオフと，この評価が保証しないこと

認可と時点の制約は検索対象を狭め，再順位付けや再認可は遅延と実装負担を増やします．キャッシュは費用を抑えますが，権限失効や更新への追従を複雑にします．棄却を増やせば根拠のない回答を減らせる一方，利用者が必要とする情報を得にくくなります．回答率100%を一律の最適化目標にはしません．

本稿は評価方法と受入条件の設計です．特定のモデル・検索器・製品の優劣や，CoRISEのRAG導入実績，測定済みの性能を示していません．認可基盤，元文書の正しさ，データ利用の契約，プロンプトインジェクション対策，運用体制のレビューを置き換えるものでもありません．

参照した研究はそれぞれ異なる対象と前提を持ちます．それらの指標を集めただけで企業システムの保証が完成するのではなく，自分たちの権限・データ・時点・障害条件へ対応付けて使います．

答えられることから，答えてよいと判断できることへ

RAGで難しいのは，LLMに文章を書かせることだけではありません．どの情報を取得し，誰が利用でき，いつの版を適用し，どの根拠なら回答を確定するかを，システムとして定義することです．

CoRISEでは，RAG評価を回答品質の採点にとどめず，知識を扱うシステム全体の契約を確かめる工程として考えます．正しい根拠を，適切な権限と時点の下で取得し，答えるべきときだけ答える． 本番で信頼できるRAGを目指すなら，そこまでを評価の対象に含めます．

参考資料

1. Ragas: Context Precision
2. Ragas: Context Recall
3. Ragas: Faithfulness
4. RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation
5. Azure AI Search: Document-level access control
6. Retrieval Pivot Attacks in Hybrid RAG
7. TimelyRAG: Semantic-Temporal Hybrid Retrieval for Time-Critical Question Answering in Overlapping-Evolving Documents
8. Unanswerability Evaluation for Retrieval Augmented Generation — UAEval4RAG
9. Investigating Retrieval-Augmented Generation Systems on Unanswerable, Uncheatable, Realistic, Multi-hop Queries — CRUMQs
10. Goguen and Meseguer: Security Policies and Security Models (1982)
11. Zanzibar: Google’s Consistent, Global Authorization System — USENIX ATC 2019
12. Azure AI Search: SharePoint ACL ingestion and permission synchronization (preview)
13. Azure AI Search: Purview sensitivity labels and chunk projection (preview)
14. Richard T. Snodgrass: Developing Time-Oriented Database Applications in SQL, §2.3 Bitemporal Tables
15. Geifman and El-Yaniv: Selective Classification for Deep Neural Networks (2017)
16. VersionRAG: Version-Aware Retrieval-Augmented Generation for Evolving Documents (2025)

関連事例

• レガシーAPIのモダナイゼーション

この事例はAPIの境界設計とデータ連携の文脈です．本稿のRAG評価をその案件で実施したことや，評価結果を示すものではありません．