所内文書を参照するRAGで、顧問先への回答案に引用元が付いた。その回答を、そのまま説明に使ってよいのでしょうか。
引用元は確認の入口です。引用された原文が結論を支えているか、その文書が今回の案件に使える版か、利用者が参照してよい範囲かまで見てから判断しましょう。この記事では、引用の付いた回答を確認する順序と、導入前の試用に使える点検例を示します。
引用先が存在すれば、回答も正しいと判断できるか
例えば、次の架空の所内マニュアルと回答案を比べてください。
- 原文：「標準案件は担当者が確認する。例外案件は所長の承認を得る」
- AIの回答案：「案件は担当者の確認だけで進められます」
- 引用先：上記の所内マニュアル
この想定例では、引用先が実在する設定でも、回答案から例外案件の条件が抜けています。文書名が合っていることと、回答の内容が原文に沿っていることは、別に点検する必要があります。
Claude APIのCitationsについて、公式資料は、引用原文を直接抽出し、提供文書内の有効な参照位置を返す仕様を説明しています。ここで説明されている参照位置の保証を、文書の最新性や、回答全体が個別案件に適用できる保証へ広げて解釈しないようにしましょう。ClaudeのCitations仕様で確認できます。
引用元を開いた後、何を確認するか
以下は、回答を所内で確認するためのチェック表の設計例です。確認できない項目があれば、その回答の利用を保留し、どの資料や判断が不足しているかを残す運用を提案します。
| 点検するもの | 原文と突き合わせる箇所 | 利用を保留する例 |
|---|---|---|
| 回答と根拠の対応 | 結論ごとに、根拠となる段落を指せるか | 参考文献の一覧だけで、結論の根拠が見つからない |
| 条件・例外 | 対象者、案件の範囲、前提条件を落としていないか | 原文では条件付きなのに、回答では無条件になっている |
| 文書の版 | 適用日、改訂履歴、現在の正本を確認できるか | 旧版と新版が食い違い、どちらを使うか不明 |
| 案件との関係 | 顧問先、対象業務、対象期間が合っているか | 別の顧問先や過年度のメモだけで結論を出している |
| 閲覧できる範囲 | 原文・抜粋・回答を、確認者が見てよいか | 本来扱えない案件の情報が回答に混ざっている |
すべての文を同じ深さで点検する代わりに、まず相手の行動を変える結論や条件を拾い、対応する原文を確認する手順を決めておくとよいでしょう。根拠が足りない箇所を、確認者の推測で埋めて「確認済み」にしないことも運用ルールに含めます。
原文を確認しやすい引用表示は、どう作るか
画面の設計では、回答の結論から原文の該当箇所へ移れるようにすることを提案します。例えば、回答中の番号を押すと、文書名、版・適用日、該当ページ、短い原文抜粋を確認できる形です。末尾の文書一覧は補助に使い、結論との対応が分かる表示を優先します。
Claude APIのCitationsでは、PDFはページ範囲、プレーンテキストは文字位置、カスタムコンテンツはブロック位置で引用箇所を表します。引用原文は cited_text に含まれます。一方、画像の引用は対象外です。スキャン画像のPDFも同じように引用できると決めつけず、利用する文書形式で確認してください。公式の文書形式別の説明に仕様があります。
自前でRAGを作る場合には、回答に付いた引用IDが実際の検索結果に含まれるかを検査する設計も候補になります。ただし、その検査に通った後も、上のチェック表に沿って、回答と原文の意味を突き合わせる工程を残しましょう。引用IDの一致だけを合格条件にしないためです。
引用表示と閲覧権限は、どこで分けて確認するか
Microsoftの組織向けCopilotは、利用者に閲覧権限がある組織データを提示する設計です。Microsoftは、SharePoint等の権限モデルを使い、適切な利用者が適切な内容へアクセスできるよう管理する必要も説明しています。組織データとアクセス権の公式説明を参照してください。
この仕様を前提にしても、所内で広く共有しすぎたフォルダの設定を、引用表示が直してくれると考えるべきではありません。導入時には、まず元文書の共有範囲を点検することを提案します。
自前のRAGでは、検索で取り出す段階、AIへ渡す段階、回答・引用抜粋を表示する段階、ログを保管する段階のそれぞれについて、誰に何を見せるかを設計してください。リンク先だけを開けなくしても、回答や抜粋に内容を表示する設計では閲覧制限の目的を満たしません。実際の顧問先資料を使う前の確認は、顧問先情報をAIに入力する前の確認手順も併せて使えます。
試用では、どんな質問で引用の不備を探すか
最初の試用には、機密情報を含まない架空の文書を使い、期待する原文と回答条件を先に用意する方法を提案します。次の表はテストの設計例であり、特定製品で実測した結果ではありません。
| 用意する文書・質問 | 確かめたい動作 | 不備として残す例 |
|---|---|---|
| 答えが書かれた架空の文書を渡し、その手順を尋ねる | 結論と対応する原文を示せるか | 文書名は正しいが、別の段落を根拠にしている |
| 文書にない手順を尋ねる | 根拠不足を伝え、確認先や追加資料を求めるか | 根拠のない手順に、無関係な引用を付ける |
| 条件付きの手順について、例外案件の扱いを尋ねる | 条件と例外を回答に残すか | 例外を省き、通常案件と同じ回答をする |
| 内容の異なる旧版・新版を渡す | 適用日を使い分け、不明なら判断を保留するか | 旧版を根拠にしながら、最新版と説明する |
| 権限の異なる試用アカウントから同じ質問をする | 許可された文書だけで回答するか | 閲覧不可の文書名・内容が回答や抜粋に現れる |
記録には、質問、期待する原文の位置、実際の回答と引用、確認者の判断、未解決の理由を残す形が考えられます。本文や抜粋を保存する場合は、試用記録の閲覧者と保存先も先に決めてください。
「引用が付いた回答の割合」だけで導入を決めず、誤った回答をそのまま採用しないための確認ができるかを点検しましょう。資料の取り込み段階で困っている場合は、PDFをAI検索で読み取れないときの文書チェックで切り分け、この記事の表で回答と根拠の対応を確かめる順序にすると、確認対象を分けられます。