MCP vs RAG：違い、使い分け、組み合わせ方を解説

MCP と RAG は競合する選択肢ではありません。RAG（検索拡張生成）は手法です。ナレッジベースを検索し、最も関連性の高い文章をプロンプトに入れ、モデルにそれを根拠として答えさせます。MCP（Model Context Protocol）はプロトコルです。AI アプリケーションが外部のツールやデータソース（モデルが操作できるライブシステムを含む）に接続するための標準的な方法です。RAG が答えるのは「ドキュメントには何と書いてある？」、MCP が答えるのは「今の実際の状態は？それに対して何かできる？」です。そして優れたシステムの多くは、RAG を MCP 経由で公開しています。

RAG とは

RAG は 2020 年の論文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks で提案されました。このパターンは 3 つのステップで構成されます。

1. インデックス作成 ——ドキュメントをチャンクに分割し、各チャンクを embedding に変換してベクトルインデックスに保存します（キーワードインデックスを併用することも多い）。
2. 検索 ——質問が来たら embedding に変換し、最も類似した上位 k 件のチャンクを取得します。必要に応じてリランキングします。
3. 生成 ——取得したチャンクをプロンプトに挿入し、それを使って回答するようモデルに指示します。理想的には引用付きで。

知識量が多く、主にテキストで、変化が遅く、出典を示す必要がある場合は RAG が適しています。製品ドキュメント、ポリシー、サポートチケット、契約書、論文などです。弱点も明確です。回答の鮮度は最後のインデックス作成時点に依存し、検索品質はチャンク分割と embedding に大きく左右され、古典的な RAG はアクションを実行できません。

MCP とは

MCP は modelcontextprotocol.io で仕様が公開されているオープンプロトコルで、ホストアプリケーション（Claude、ChatGPT、Cursor、Codex、自作のエージェント）が、コンテキストや機能を提供するサーバーに接続する方法を標準化します。サーバーは 3 種類のものを公開できます。

• ツール（Tools） ——モデルが制御する関数。いつ呼び出すかはモデルが決めます（データベースのクエリ、チケット作成、メッセージ送信）。
• リソース（Resources） ——URI で識別され、アプリケーションが主導するデータ。どう取り込むかはホストが決めます（ファイル、スキーマ、レコード）。
• プロンプト（Prompts） ——ユーザーが制御する再利用可能なテンプレート。スラッシュコマンドなど。

MCP はサーバーがどうやってデータを探すかについては何も規定しません。ライブ API を呼んでも、SQL を実行しても、ファイルを読んでも、RAG パイプラインを動かしてもかまいません。最初の 2 つのプリミティブについては MCP のリソースとツールの違いで詳しく解説しています。

MCP vs RAG 比較表

RAG を使うべきとき

• 大量で変化の遅いテキスト ——数千記事のヘルプセンター、社内 Wiki、契約書アーカイブなど。すべてをコンテキストに入れることはできず、質問が意味的（「年払いプランの返金ポリシーは？」）なのでライブ API での検索も役に立ちません。
• 回答に引用が必要 ——コンプライアンス、法務、サポートの回答は、出典となる文章を示す必要があります。
• 完全一致より意味検索が有効 ——ユーザーの質問の言い回しがドキュメントの書き方と異なる場合です。

MCP を使うべきとき（RAG なし）

• 答えが業務システムにある ——「注文 4521 のステータスは？」は 1 週間前のインデックスではなく注文システムに問い合わせるべきです。Postgres MCP のようなデータベースサーバーなら現在の行を返します。
• エージェントがアクションを実行する必要がある ——Issue の作成、CRM レコードの更新、Slack への投稿、ワークフローの実行。RAG には書き込みの経路がありませんが、MCP のツールにはあります。例は 営業・マーケティング向け MCP サーバー一覧をご覧ください。
• 構造化データや小さなデータ ——データベーススキーマ、設定ファイル、単一のレコード。embedding するより直接取得するほうが安く正確です。
• 1 つの統合を多くのクライアントで使いたい ——サーバーを一度作れば、Claude Code、Cursor、Codex、ChatGPT から使えます（クライアント一覧）。

MCP と RAG の組み合わせ方

この 2 つは積み重なる関係です。RAG は MCP インターフェースの裏側にある実装で、MCP はあらゆるエージェントがそれを使えるようにするインターフェースです。よくある形は 3 つあります。

1. RAG を MCP ツールにする（エージェント型 RAG）

検索器を search_docs ツールでラップします。いつ検索するか、どんなクエリを書くか、より良いクエリで再検索するかをモデルが判断するため、多段階の質問では常時検索よりも良い結果になることが多いです。ディレクトリにある多くのサーバーがすでにこのパターンを採用しています。Context7 と DeepWiki は最新のライブラリドキュメントを検索し、Exa は Web 全体を検索します。

2. 検索したドキュメントを MCP リソースとして公開する

検索結果は軽量な参照だけを返し、各ドキュメントの全文は docs://refund-policy のような URI を持つリソースとして公開します。ホストやユーザーは必要なときだけ全文を取得できるので、コンテキストウィンドウを小さく保てます。リソーステンプレートを使えば、1 つのサーバーでコーパス全体をカバーできます。

3. ハイブリッド：知識は RAG、ライブデータとアクションは MCP ツール

サポートエージェントがヘルプセンターを検索し（MCP 経由の RAG）、顧客の現在のサブスクリプションを確認し（MCP 経由の課金 API）、返金チケットを作成します（MCP 経由のチケットツール）。それぞれに適した手法を使いながら、エージェントからは一貫したツールインターフェースに見えます。

構成例：MCP サーバーの裏側に RAG パイプラインを置く

公式の MCP Python SDK（uv add "mcp[cli]" でインストール）を使った最小構成のサーバーです。search_index と load_document は既存のベクトルストアとドキュメントストアの代わりです。

from mcp.server import MCPServer

from my_rag import search_index, load_document  # your existing pipeline

mcp = MCPServer("docs-rag")


@mcp.tool()
def search_docs(query: str, k: int = 5) -> list[dict]:
    """Semantic search over the product docs. Returns titles, snippets and URIs."""
    hits = search_index(query, k=k)
    return [
        {"title": h.title, "snippet": h.text[:500], "uri": f"docs://{h.doc_id}"}
        for h in hits
    ]


@mcp.resource("docs://{doc_id}")
def get_doc(doc_id: str) -> str:
    """Full text of one document."""
    return load_document(doc_id)


if __name__ == "__main__":
    mcp.run()  # stdio by default

まず uv run mcp dev server.py で MCP Inspector を使ってテストし（手順は MCP Inspector ガイド）、その後クライアントに登録します。Claude Code の場合：

claude mcp add docs-rag -- uv run --directory /absolute/path/to/docs-rag server.py

クライアントごとの詳しい手順は Claude Code MCP ガイドをご覧ください。

このパターンの設計のコツ：

• ドキュメント全体ではなく、スニペットと URI を返す。 スニペットで足りないときだけ、モデルに全文リソースを読ませます。
• ツールの説明はモデルに向けて書く。 どのコーパスを検索するのか、どんなときに使うべきでないかを書いておけば、ライブのアカウントデータをドキュメントから探すような誤用を防げます。
• 権限はサーバー側で強制する。 結果を返す前に呼び出しユーザーのアクセス権でフィルタリングします。ドキュメントを隠す役目をモデルに任せてはいけません。
• 検索したテキストは信頼できないものとして扱う。 ドキュメントにはプロンプトインジェクションが含まれている可能性があります。MCP セキュリティのベストプラクティスを読んでおきましょう。

よくある誤解

• 「MCP は RAG を置き換える」 ——置き換えません。MCP はアプリごとに個別の統合を作る手間をなくしますが、大規模なテキストを意味検索する必要性はなくしません。
• 「コンテキストウィンドウが巨大になったので RAG は時代遅れ」 ——長いコンテキストは中規模のコーパスには役立ちますが、コスト、レイテンシ、非常に長い入力での再現率の問題から、大規模なナレッジや権限でフィルタリングが必要なナレッジでは今でも検索が有効です。
• 「メモリサーバーは RAG だ」 ——Memory（ナレッジグラフ） のようなサーバーは、エージェント自身が書き込んだ事実を保存・想起するものです。密接に関連していますが、既存ドキュメントの検索ではなくエージェントの記憶です。

次のステップ

すでに RAG パイプラインがあるなら、それを MCP サーバーの裏側に置き、社内のすべてのエージェントから使えるようにしましょう。ゼロから始めるなら、まずデータソース向けのサーバーがすでに存在しないか確認してください。作る前に MCP サーバーディレクトリをチェックしましょう。