RAGとMCPサーバーは、生成AIに社内文書などの外部情報を渡す仕組みを整えるうえで役立ちます。
ただし、接続しただけで回答が正しくなるわけではありません。
ハルシネーションとは、生成AIが根拠のない内容や、参照資料と一致しない内容を、もっともらしい文章として出力することです。
生成AIのハルシネーションの原因と見分け方を押さえたうえで、この記事ではRAGとMCPを併用する場合の設計と運用に焦点を当てます。
先に結論を示すと、誤回答を減らすには、情報源を増やすだけでは足りません。
正しい資料を検索できる状態、必要な資料だけを渡す接続設計、回答と根拠を照合する運用を一続きで整える必要があります。
RAGとMCPサーバーの役割
RAG（Retrieval-Augmented Generation）は、質問に関係する情報を文書群から検索し、その検索結果を回答生成の材料として渡す構成です。
処理は大きく「検索」と「生成」に分かれます。
- 検索：質問に近い文書や段落を探す
- 生成：見つけた情報を文脈として回答を組み立てる
MCP（Model Context Protocol）は、生成AIを利用するアプリケーションが、外部のデータや機能へ接続するための標準的な取り決めです。
MCPサーバーは、参照用のリソースや実行可能なツールなどを、決められた形式でアプリケーションへ公開します。
RAGが「質問に合う情報をどう探すか」を担うのに対し、MCPは「外部の情報源や機能へどう接続するか」を担います。
詳しい構成は、MCPサーバーの仕組みとRAGとの違いでも確認できます。
| 要素 | 主な役割 | 単独では保証しないこと |
|---|---|---|
| RAG | 質問に関係する情報を検索し、回答の材料として渡す | 検索結果や回答内容の正しさ |
| MCPサーバー | 外部のデータや機能を共通の方法で公開する | 接続先データの品質や利用権限の妥当性 |
| データと運用の管理 | 版管理、公開範囲、更新、監査、確認手順を定める | 生成AIが常に資料どおりに答えること |
MCPそのものは、文書管理製品やアクセス制御機能の名称ではありません。
どのデータを公開するか、誰に利用を許可するか、操作をどう記録するかは、MCPサーバーと接続先システムの実装および運用で決まります。
誤回答が生まれる経路
RAGとMCPを併用した構成では、入力データから最終回答までの各段階に誤りの入口があります。
原因を分けて考えると、対策を置く場所も明確になります。
関連性の低い情報を検索する
ベクトル検索は意味の近さを手掛かりにしますが、「似た言葉を含むこと」と「質問への正しい答えであること」は同じではありません。
たとえば、顧客向けの手順を尋ねたのに、同じ製品名を含む社内報告書が上位に出れば、回答が質問の対象から外れるおそれがあります。
長い文書から必要な範囲を切り出せない
一つの検索単位に複数の話題や条件が混ざっていると、必要な前提と結論が離れたり、別の対象に関する記述が一緒に渡されたりします。
その結果、生成AIが条件を取り違え、資料の一部だけに合う回答を作ることがあります。
古い版と現行版が混在する
旧版と現行版の両方を検索できる状態では、文章の似ている旧版が選ばれる可能性があります。
更新日、適用範囲、文書の状態を検索条件に使えなければ、検索結果を見ただけで現行情報か判断するのも困難です。
メタデータと権限の設計が足りない
部署、対象製品、文書種別、更新日などのメタデータが不足すると、検索対象を適切に絞れません。
一方、権限を広く設定しすぎると、本来は回答に使うべきでない情報まで候補に入ります。
検索結果があっても回答が根拠から外れる
適切な資料を取得できても、最終回答が資料の表現や条件を正しく反映するとは限りません。
検索の成否と回答の妥当性は別々に確認する必要があります。
失敗の例：利用者が最新の解約手順を質問したとします。
検索が名称のよく似た旧版を選び、MCPサーバーがその文書を問題なく返しても、得られるのは古い手順に基づく回答です。
この場合、接続は成功していますが、版管理と検索条件が不足しています。
ハルシネーションを抑える実務対策
回答の合格条件を先に決める
最初に、どの情報源を根拠として認めるか、根拠が見つからない場合にどう応答するかを決めます。
「関連文書がないときは推測せず、確認できないと伝える」「重要な回答には出典を示す」といった条件が、設計と評価の基準になります。
検索対象を現行情報にそろえる
- 文書の責任者と更新日を管理する
- 旧版を通常の検索対象から外し、必要な場合だけ明示的に参照する
- 見出しと段落を整え、一つの検索単位に一つの話題を収める
- 対象部署、製品、文書種別など、絞り込みに使う属性を付ける
文書を短く分割すれば必ず改善するわけではありません。
条件と結論が別々の断片に分かれると意味を失うため、内容のまとまりを保てる単位で区切ります。
検索方法を質問の性質に合わせる
意味の近さを使うベクトル検索だけでなく、製品名や文書番号などの一致を扱いやすいキーワード検索も組み合わせます。
さらに、メタデータで対象を絞り、関係の薄い文書が生成段階へ渡る量を減らします。
検索結果は、上位に並んだという理由だけで採用しません。
質問への適合性、文書の状態、適用範囲を確認できる情報も一緒に渡す設計が必要です。
MCPの接続範囲を必要最小限にする
- 用途に必要なリソースとツールだけを公開する
- 接続先システムの利用権限をMCP経由でも保つ
- 参照した情報源や実行結果を追跡できるようにする
- 読み取りと更新を伴う操作を区別し、確認手順を設ける
「MCPで接続できたこと」は、「安全で正確な情報だけを取得できること」を意味しません。
接続先の品質、権限、記録方法まで含めて確認します。
回答と根拠を照合できる形にする
回答には、参照した文書名やURLなど、利用者が根拠へ戻れる手掛かりを添えます。
ただし、出典の表示だけでは十分ではありません。
回答中の主張が実際にその出典で支えられているかを確認できる画面と運用が必要です。
医療、法律、金融など、誤りの影響が大きい用途では、生成結果だけで判断を完了させず、担当分野の専門家が原資料を確認する手順を残します。
検索と回答を分けて評価する
評価では、「必要な文書を取得できたか」と「取得した文書に沿って回答したか」を分けます。
前者に問題があればデータや検索を見直し、後者に問題があれば回答条件や確認処理を見直せます。
代表的な質問だけでなく、名称が似た文書を取り違えやすい質問、旧版が存在する質問、根拠がない質問も試します。
実際に起きた誤回答を評価例へ追加すると、再発の有無を継続して確認できます。
導入前後の確認項目
- 回答に使ってよい情報源が明文化されているか
- 現行版と旧版を検索時に区別できるか
- 文書の分割単位が内容のまとまりを壊していないか
- 質問に応じてキーワード検索とベクトル検索を使い分けられるか
- MCPサーバーが公開するリソースとツールを必要な範囲に絞っているか
- 利用者の権限が接続先でも保たれているか
- 回答から参照元をたどれるか
- 根拠がない場合に推測を止める応答を確認したか
- 検索結果と最終回答を別々に評価しているか
- 影響の大きい判断に人の確認を残しているか
RAGとMCPを組み合わせるときの要点
RAGは関連情報を探して回答へ渡し、MCPサーバーは外部の情報源や機能への接続方法を整えます。
役割が異なるため、両者を導入しただけでハルシネーションが解消されるわけではありません。
誤回答を減らすには、現行データの管理、検索対象の絞り込み、必要最小限の接続権限、出典を確かめられる回答、検索と生成を分けた評価が必要です。
仕組みと運用のどちらか一方に任せず、情報が登録されてから利用者が回答を確認するまでの流れ全体を点検してください。