RAGとMCPの関係とは？RetrieverとLLMの役割分担を明確にする設計法｜LLM入門 6.1

6.1 MCPとの関連性と役割分担

RAG（Retrieval-Augmented Generation）は、その名の通り「検索（Retrieval）」と「生成（Generation）」という2つの工程を組み合わせる設計手法です。
しかし、実際のシステム設計においては、この二者をただ機械的に接続するだけでは、十分な成果は得られません。

このセクションでは、RAGの内部にある役割の分離と責任の設計を明確にするための考え方として、Model Context Protocol（MCP）という視点を紹介します。MCPは、本書の姉妹編『MCP入門』で詳述されている概念ですが、ここではRAGにおける文脈設計とプロンプト構造の整理軸として応用的に捉えていきます。

RetrievalとGenerationを「明確に分ける」理由

一般的なRAG構成では、以下のような処理が行われます。

1. Retriever がユーザーの質問に関連する文書（チャンク）を検索

2. LLM（Generator） がそれらを参考に自然な言語で回答を生成

このとき、以下のような不整合がしばしば発生します：

• 検索結果が曖昧で、生成側が不要な情報まで参照してしまう

• LLMが「自分で考えるべき」部分までRetriever側で誘導してしまい、回答が偏る

• システムの改善時に「検索が悪いのか」「生成が悪いのか」が不明確になる

これを防ぐために有効なのが、「RetrieverとGeneratorの役割を分離して定義する」という設計思想です。
ここで、MCP（Model Context Protocol）の発想が活用できます。

MCP：モデルとの“文脈契約”という考え方

MCPとは、LLMのような生成モデルに対して、「何をどのような形で渡すか」を定義する設計プロトコルです。
以下の3つの要素を区別することで、モデルの応答を制御し、再現性を高める設計が可能になります：

1. 指示（Instruction）：何をすべきかを明示する（例：「以下の情報をもとに質問に答えてください」）

2. コンテキスト（Context）：参照すべき知識や条件（例：Retrieverが取得した文書チャンク）

3. 入力（Input）：ユーザーからの問いそのもの（例：「退職後の社会保険について教えてください」）

この3つを明示的に設計することで、以下のような効果が得られます：

• Retrieverは「Contextの生成」を担当し、選別と整形に集中できる

• Generatorは「ContextとInputをもとにInstructionに従って出力する」役割に専念できる

• 各コンポーネントが独立して改善可能になり、保守性が上がる

RAGにおけるMCP的役割分担

MCPの構成をRAGに適用すると、次のように整理できます：

このように役割を明示的に分けることで、たとえば「Retrieverの文書整形を変えても、プロンプト構造は維持する」といった試行錯誤が可能になります。

設計実務で起こる「責任の曖昧さ」

実務ではしばしば以下のような混乱が起こります：

• 検索結果が不十分なとき、プロンプト側で無理やり補足しようとして整合性が崩れる

• LLMが勝手に推論してしまい、検索していない情報を“創作”する（＝幻覚）

• チーム内で「誰が何を改善するのか」が不明確になる

MCP的な分離を行うことで、設計・検証・改善の責任範囲が整理され、LLMアプリケーションの運用に耐える構造を作ることができます。

質問の正規化とドキュメントマッチング

RAG構成においてRetrieverの品質は非常に重要ですが、Retrieverが正しく動作するためには、そもそも「入力される質問文」が適切である必要があります。
次のセクション「6.2 質問の正規化とドキュメントマッチング」では、ユーザーからの自然文をいかに整形・解釈し、適切に文書とマッチさせるかという「質問正規化とマッチング」について掘り下げていきます。