所内文書を対象にしたRAGは、顧問先からの照会に対する回答案を短時間で出せます。ただし、その回答がどの所内文書に基づいているかが示されないと、読んだ職員はその内容の当否を自分で判定できません。文章が整っているほど、確認を経ないまま次の工程へ渡る余地が残ります。
根拠の所在が分からないままだと、後で内容を確認するときに、結局すべての所内文書を自分で読み直すことになります。AIを入れた目的が調査の手間を減らすことだったとすると、手間が別の場所へ移っただけになります。
論点はAIそのものではなく、回答と根拠を業務の中でどう結びつけるかの設計にあります。本稿は、引用元の表示が業務にもたらす違い、主要なツールの仕様、確認の流れを業務に組み込む例を整理します。
回答と根拠が切り離されていると、業務の中で何が起きるか
士業の業務は、結論そのものより、結論に至った根拠が問われる場面の多い職種です。顧問先への助言、申請書類、契約書ドラフトのいずれでも、後から「この記述はどの資料に基づいているのか」を説明する場面が出てきます。
回答と根拠が切り離されている状態で運用していると、現場でいくつかの動きが起きやすくなります。
一つは、回答の正否を確認しようとした職員の方が、結局すべての所内文書を自分で読み直すことになる動きです。引用元がなければ、AIがどの文書を見て回答を組み立てたのかが分かりません。「AIに任せて手間を減らす」目的とは逆の動きになります。
もう一つは、回答が流暢に整っていることで、確認の手順を間に置かずに使ってしまう動きです。実在しない判例・条文・通達がもっともらしい体裁で混ざる場面は、AIを使った業務で繰り返し見られます。引用元が空であることや、引用先を開いても該当箇所が見当たらないことは、確認の入口になりますが、引用元そのものが無いと、その入口が存在しないことになります。
三つ目は、後から経緯を説明できなくなる動きです。顧問先からの照会、行政庁とのやり取り、所内のレビューのいずれでも、「この記述はどの所内資料に基づきますか」と問われる場面があります。引用元のない回答は、職員の方が個人的に書いたメモと外形上の区別がつきにくく、レビュー記録としても説明資料としても扱いにくい形になります。
AnthropicのClaude APIドキュメントのCitationsページには、機能の利点として「引用は応答形式にパースされ cited_text が抽出されるため、提供文書への有効なポインタを含むことが保証される」と記述されています。プロンプトで「引用してください」とお願いする実装と、APIが構造化された引用を返す実装では、後から検証できるかどうかが変わってくる、という整理です。
引用元の表示3つの形と、確認の手間の差
「引用元を表示する」 と言っても、表示の形によって、職員の方が確認する手間が変わります。本稿では代表的な3つの形を並べてご紹介します。
文中に番号を埋め込んで、末尾に出典を並べる形
「相続税の基礎控除は3,000万円 + 600万円 × 法定相続人数です [1]」 のように、文中に番号を埋め込み、末尾でリンクや出典名を展開する形です。Microsoft Copilotでは、応答の根拠にした情報への引用が応答に含まれる扱いになっています (Microsoft Learn「Data, Privacy, and Security for Microsoft Copilot」より)。回答を読みながら、根拠の箇所をそのまま確認しやすい形です。
末尾にまとめて参考文献を並べる形
回答の最後に「参考にした文書: 所内マニュアルv3.2 / 顧問先X議事録2025-12-05」 のように一覧で並べる形です。実装そのものは易しいのですが、文中のどの記述がどの文書に対応するのかが分かりにくくなります。試しに動かす段階では使えても、日々の業務に組み込んで運用する段階では、もう一段細かな表示があると確認が進めやすくなります。
根拠文を引用ブロックとして表示する形
回答の下に、根拠文書から抜粋した実際の文章を引用ブロックとして表示する形です。ClaudeのCitations機能は cited_text フィールドで、実際に引用された原文テキストを返す設計になっています。職員の方は原文を直接読んで、AIの解釈が原文から離れていないかを判断しやすくなります。
実務の場面では、下書き作成のときは番号埋め込みの形、最終確認のときは根拠文ブロックの形、という二段構えにしている事務所もあります。
主要なツールが引用元をどう扱っているか
主要なツールが引用元をどう扱っているかを、公式のドキュメントを基に並べてみます。
| ツール | 引用元の扱い | 原文の表示 | 権限の扱い |
|---|---|---|---|
| Microsoft 365 Copilot (Premium) | 仕様 (応答に引用が含まれる) | 引用先の文書に誘導 | 閲覧権限のある組織内データに限定 |
| Anthropic Claude (Citations API) | 仕様 (構造化された引用フィールド) | cited_text で原文返却 | 実装する側で設計 |
| 自前で組むRAG | 実装次第 (プロンプトに依存しがち) | 実装次第 | 実装する側で設計 |
Microsoft Learn「Data, Privacy, and Security for Microsoft Copilot」(2026-09-08参照) には、保存される対話履歴に「応答の根拠にした情報への引用」が含まれる旨と、Copilotが表示する組織内データは利用者本人が閲覧権限を持つものに限られる旨が記載されています。見られないはずの文書が引用される場面は、仕様の側で抑えられている整理です。
ただし、組織内データを根拠にできるかどうかは、契約するプランによって変わります。Microsoft Learn「What is Microsoft Copilot?」(2026-09-08参照) には、Copilot Chat (Basic) とMicrosoft 365 Copilot (Basic) の利用者はMicrosoft Graphを利用できず、組織内データを使う場面ではファイルを添付するなどの操作が要る旨、Microsoft 365 Copilot (Premium) はMicrosoft Graph経由で組織内データを自動的に参照する旨が書かれています。所内文書を根拠にした引用元表示を前提にする場面では、プランの側を先に確認しておきたいところです。
Claude APIにはCitationsの機能があり、PDF・プレーンテキスト・カスタムコンテンツの3種類のドキュメントを渡すと、回答テキストに対して文書のインデックス・文字位置 (PDFではページ番号)・引用された原文を、構造化された形で返してくれます。Anthropicのドキュメントでは、同社自身の評価として、プロンプトベースの手法と比較して「文書から最も関連性の高い引用を返す確率が有意に高い」 と記述されています。
自前で組む場合は、引用元の表示は実装する側で設計することになります。検索のステップで取得したチャンクの文書ID・チャンクID・原文を保持したままLLMに渡し、回答生成のプロンプトで根拠を出力に含めるよう指示する形になります。ただしプロンプトに頼る形は、指示に従わず引用が省略されることや、存在しない引用が混ざることがあります。後段で「LLMが出した引用IDが、実際の検索結果に含まれているか」 をプログラムで確認する仕組みを置く事務所もあります。
ツールを選ぶ場面では、引用元表示の有無だけでなく、原文ベースで構造化されているか、クリックして原文に当たれるか、プロンプトの工夫ではなく仕様としてサポートされているか、という観点を並べておくと、後の運用が組みやすくなります。
引用元を確認する手順を業務の流れに置く
引用元が表示されていても、それを確認する手順が業務の中に置かれていないと、形だけになりやすくなります。事務所で標準化している例をいくつか並べてご紹介します。
- 回答を読む前に引用元を見る場面を作る。引用元が空、または不自然に少ない場面では、回答そのものを一度立ち止まって見るようにする
- 引用先を開いて原文に当たる場面を間に置く。表示された引用先が実在しているか、回答と原文が整合しているかを確認する
- 根拠と主張のズレを見る場面を置く。AIが原文を拡大解釈していないか、原文にない条件を補っていないかを並べて読む
- 引用された文書の更新日を見る場面を置く。改正前のひな型・失効した通達でないかを確認する
- 顧問先・案件の文脈との整合を見る場面を置く。別の顧問先のメモが混ざっていないかを確認する
「全件で必ず行う」 ではなく、「外部に出るアウトプットでは必ず行い、内部用途ではサンプリングで点検する」 のように、業務のリスクに応じて確認の深さを変えている事務所もあります。
セキュリティ・コンプライアンスから見た引用元
引用元の表示は、業務の使い勝手だけでなく、セキュリティやコンプライアンスの要件にも関わります。
個人情報保護委員会は2023年6月2日付で「生成AIサービスの利用に関する注意喚起等について」 を公表しています。その別添1では、応答結果に不正確な内容が含まれることがあるため、生成AIサービスを利用して個人情報を取り扱う際には、そのリスクを踏まえた上で適切に判断することが求められています。引用元のないRAGでは、出力された内容を後から確認する手順を組みにくくなります。
弁護士法・税理士法・社労士法等の守秘義務との関係でも、引用元の表示があれば、AIがどの顧問先のどの文書を使って回答を組み立てたかが見える形になります。誤って別の顧問先の情報が混ざった場合に、検知の手がかりが残ります。引用元がない実装では、混ざった事実そのものに気付きにくい形になります。
利用ログ (誰が・いつ・何を聞いたか) と引用元ログ (その回答が何の文書を根拠にしたか) はペアで保管しておく形を取る事務所もあります。ベンダー側で「引用元の情報がログとして保持されるか」「保持期間」「管理者が監査用に取り出せるか」 は、契約前にベンダー公式のドキュメントで確認しておきたい項目です。画面に引用元が出ても、後から一括で取り出せないと、監査の運用が組みにくくなります。
引用元つきで回答を出す仕組みとして設計する
所内RAGを入れる場面では、回答を出す仕組みとしてだけでなく、根拠つきで回答を出す仕組みとして設計しておくと、後の運用が組みやすくなります。引用元のない回答は、文章が流暢であるほど確認の手間が増えやすい形を持つので、士業の業務では再設計の対象になりやすいところです。
本稿で仕様を確認したMicrosoft CopilotとClaude APIは、いずれも引用元の表示を仕様の側でサポートしています。ツールを選ぶ段階で引用元の有無と質を見ておき、運用に入ってからは引用元を確認する手順を業務の流れに置いておくと、AIが業務に入った後でも、後から経緯を説明できる状態を保ちやすくなります。「機能として保証されている」 と 「プロンプトでお願いしている」 の違いは、運用に入ってから差が出るため、選定の段階で見ておきたい観点です。
RAGの引用元の設計は、表示の有無だけでなく、構造化・確認の流れ・監査ログの3つで論点が分かれます。現状の運用で迷う場面があれば、設計の段階からお気軽にご相談ください。
参考
- Anthropic「Citations」(Claude APIドキュメント / 2026-09-08参照): https://platform.claude.com/docs/en/build-with-claude/citations
- Microsoft Learn「Data, Privacy, and Security for Microsoft Copilot」(2026-09-08参照): https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-privacy
- Microsoft Learn「What is Microsoft Copilot?」(2026-09-08参照): https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-overview
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」別添1 (2023年6月2日): https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf