生成AI（LLM）を使っていると、「どうやって自分のデータや最新情報を使わせるか」という疑問にぶつかります。最近のChatGPT、Gemini、ClaudeといったメジャーどころのLLMではWeb検索機能がデフォルトでONになっていたりして、現在の天気や株価なども取得できるようになってはいますが、以前はそういうことはできませんでした。ただ、公開されていない情報の場合には、ChatGPTに「うちの会社の売上データは？」と聞いても答えられないのは当然となります。
こういった、問題を解決する主要な手法としてRAG（Retrieval-Augmented Generation）とMCP（Model Context Protocol）が注目されています。MCPは厳密にいえば少し違うものではありますが、その柔軟性からMCPを使ってRAG的な文書検索を行うことも可能となっています。
MCPを使用したRAG的な動作例
つまり、MCPの方がより広い概念で、その中でRAG的な使い方ができるといえます。
今回は、学び直し中の方や技術に関わる方向けに、この2つの手法の仕組みと特徴を分かりやすく学んでいこうと思います。もし内容が間違っていたらご指摘いただけると幸いです🙇
RAGとMCPの基本概念
RAG（Retrieval-Augmented Generation）とは
RAG（Retrieval-Augmented Generation）は「検索拡張生成」と呼ばれる手法で、事前に準備した文書データベースなどから関連情報を検索し、その結果をLLMに渡して回答を生成する仕組みです。
MCP（Model Context Protocol）とは
MCP（Model Context Protocol）は「モデル・コンテキスト・プロトコル」の略で、生成AIが外部のツールやデータソースとリアルタイムで連携するための技術規格です。
以前の私のブログでもClaude DesktopでのMCPサーバーの設定について書いています。
以降ではそれぞれの技術について詳しくみていきます。
RAGを理解する
RAGのシステム構成と処理フロー
RAGは処理は大きく事前準備フェーズと実行時フェーズに分かれます。それぞれのフェーズでは以下の処理が行われます。
事前準備フェーズ
- 文書コレクション（文章データ群）をチャンク（小さな断片）に分割
- 各チャンクをベクトル化（埋め込み表現に変換）
- ベクトルデータベースに格納
実行時フェーズ
- ユーザーの質問をベクトル化
- 前述のベクトルデータベース内部のデータとの類似度検索
- 関連する文書を取得
- 質問と関連文書を組み合わせたプロンプトを構築
- LLMに送信して回答生成
上記を組み合わせることで、ユーザーの質問に対して関連情報を参照しながら回答を生成することができます。 図にすると以下のような流れになります。
RAGの実際の動作例
ユーザー … 新しいマーケティング戦略について教えて
システムでの処理
- 「マーケティング戦略」でベクトル検索実行
- 関連する社内資料を何件か（例えば3件）取得
- プロンプト構築：「以下の社内資料を参考にして...」
- LLMに1回アクセスして回答生成
実際のプロンプト例
この動作例でLLMへのプロンプトにすると以下のようになります。
ユーザーは新しいマーケティング戦略について教えてと書くのですが、その他の部分についてはシステム側（APIプログラミングを行う場合にはプログラム）で情報を組み立てます。
以下の情報を参考にして質問に答えてください： 参考情報: [検索で取得された関連文書] 質問: 新しいマーケティング戦略について教えて
RAGの主な役割
| 処理項目 | 担当者・方法 |
|---|---|
| データ準備 | 開発者が事前準備（文書収集・チャンク分割・ベクトル化） |
| 情報選択 | 開発者が検索ロジック構築（類似度計算・ランキング） |
| プロンプト生成 | 開発者が組み立て（テンプレート作成・文書結合） |
| LLMへのアクセス | 1回で完結（検索結果込みで一度に送信） |
| コンテキスト管理 | 開発者が設計（会話履歴の保持方法） |
RAGの良いところ・気になるところ
良いところ
- 仕組みがシンプルで理解しやすい
- 実装が比較的楽
- 1回のLLMアクセスで素早く処理
気になるところ
- 静的データのみ（リアルタイム情報は苦手がち）
- 事前準備に手間がかかる
- 情報の更新作業が面倒
- 事前に情報整理をする必要がある
- チャンク分割の品質が結果に大きく影響
MCPを理解する
MCPのシステム構成と処理フロー
MCPの処理は階層的になっている点やリアルタイムでの双方向通信を行う点が特徴です。
システム階層
そして、各レイヤーでMCPの処理は以下のようになっています。
処理フロー
- ツール情報準備 … 利用可能なMCPツール情報をシステムプロンプトに注入
- 1回目のLLMアクセス … どのツールを使うかAIが判断
- ツール実行 … MCPサーバー経由で外部リソースにアクセス
- 結果統合 … ツール実行結果をまとめる
- 2回目※のLLMアクセス … ツール結果を踏まえて最終回答生成
※2回とは限らず、必要に応じて複数回のプロンプト生成が行われることもありますが、今回は2回としています。
重要なポイント … MCPでは複数回のプロンプト生成が行われます。
- 1回目 … システムがツール情報をシステムプロンプトに自動注入
- 2回目 … システムがツール実行結果を会話履歴に自動統合
MCPの実際の動作例
ユーザー … 今日の売上と先月比較して報告書を作成して
システムの処理
1.1回目LLMアクセス
システム側が登録されているMCPの機能情報を含むプロンプトを自動生成
システムプロンプト: [ツール情報を自動注入] ユーザー: 今日の売上と先月比較して報告書を作成して AI応答: 売上データ取得ツールとレポート作成ツールを使います
2.MCP処理の実行
AI応答からツールを選択し、MCPサーバーが以下の処理を実行します。
- 売上データベースから今日のデータ取得
- 先月データと比較分析
3.2回目LLMアクセス
システムがツール結果を含むプロンプトを自動生成
[会話履歴 + ツール実行結果] システム: 以下のツール実行結果を踏まえて最終回答を生成してください ツール結果: [売上データと分析結果]
自動生成されるシステムプロンプトの例（実際のものとは異なります）
あなたはAIアシスタントです。以下のツールを使用できます： ## 利用可能なツール ### sales_data_query - 説明: 売上データベースから情報を取得 - パラメータ: date_range (期間), filters (絞り込み条件) ### report_generator - 説明: データを基にレポートファイルを作成 - パラメータ: data (データ), format (形式) 適切なツールを選択して使用してください。
MCPの主な役割
| 処理項目 | 担当者・方法 |
|---|---|
| データ準備 | 自動取得（MCPサーバーがリアルタイム取得） |
| 情報選択 | AIが動的判断（状況に応じてツール選択） |
| 1回目プロンプト生成 | システムが自動生成（ツール情報をシステムプロンプトに注入） |
| 2回目プロンプト生成 | システムが自動生成（ツール結果を会話履歴に統合） |
| LLMへのアクセス | 複数回の自動処理（ツール判断→実行→最終回答） |
| コンテキスト管理 | クライアントが自動管理（MCPクライアントが履歴保持） |
MCPの良いところ・気になるところ
良いところ
- リアルタイム情報が取得できる
- 複数のツールを組み合わせて使える
- 他の人が作ったMCPサーバーを活用できる
- 柔軟で高機能な処理が可能
- AIが自動的にツールを選択・実行
気になるところ
- 仕組みが少し複雑
- LLMを複数回使うので費用が増える可能性が高い
- APIを使用してプログラミングをする場合、プロンプト・コンテキスト管理が大変
- 問題が起きた時の原因特定が難しい
- ツールの品質が結果に大きく影響
- 内部処理が見えにくい（Claude Desktopでは思考の過程で処理をみることができるが、実際のプロンプトは確認できない）
- セキュリティリスク（外部ツールへの認証情報管理、データ漏洩リスクなどには注意）
RAGとMCPの比較
RAGとMCPはそれぞれ異なるアプローチでLLMを活用しますが、同じようなことに使用することが可能です。
特徴の一覧比較
| 観点 | RAG | MCP |
|---|---|---|
| データ性質 | 静的・事前インデックス | 動的・リアルタイム |
| 処理フロー | 線形（検索→生成） | 非線形（対話的） |
| 情報鮮度 | インデックス作成時点 | 最新情報 |
| 操作可能性 | 読み取りのみ | 読み書き両方 |
| 複雑性 | シンプル | 複雑だが柔軟 |
| LLMアクセス回数 | 1回 | 2回以上 |
| 実装の難易度 | 比較的簡単 | 複雑 |
| コスト予測 | しやすい | 変動的かも |
| 透明性・デバッグ | プロンプトが見える | 内部処理が見えにくい |
どんな時にどちらを選ぶ？
RAGが向いている場面
- 社内文書検索システム
- FAQ自動応答
- 過去データ分析
- 規程・マニュアル参照
- 速くて安定した応答が欲しい時
- コストを抑えたい時
- シンプルに始めたい時
- 内部処理を確認・調整したい時
ローカルなデータを使った検索や、過去ログなどの情報を参照する場合にはRAGが適しています。 特に、社内のドキュメントやFAQなど、静的な情報を扱う場合に効果的です。 また、比較的カンタンな実装で実現できます。
MCPが向いている場面
- リアルタイムデータ分析
- 外部API連携
- 複数システム操作
- 柔軟な作業フロー
- 最新情報が重要な時
- 複雑なタスクの自動化
- ツール連携が必要な時
外部のAPIやデータベースと連携してリアルタイムで情報を取得・操作する場合にはMCPが適しています。 特に、最新のデータを扱う必要がある場合や、複数のサービスにまたがる場合もこちらのほうが向いているでしょう。
実際の使用時に見える・見えないもの
これは技術選択時に意外と重要なポイントになるかもしれません。
RAG（自作システム）の場合
ユーザー: マーケティング戦略について教えて [確認できるプロンプト] 参考情報: [検索された文書内容] 質問: マーケティング戦略について教えて
→ どんなプロンプトが送られているか開発者は確認可能
MCP（Claude Desktop）の場合
ユーザー: 今日の売上データを教えて [見えない内部処理] - システムプロンプト: ツール情報が自動注入 - 1回目LLM: ツール使用判断 - ツール実行: データ取得 - 2回目LLM: 最終回答生成 Claude: 本日の売上は150万円です...
→ 内部のプロンプトは確認できない（ブラックボックス的になっている）
私的まとめ
全くの個人的な意見になりますが、RAGは開発者がどのようなプロンプトを送っているかを確認しやすく、調整もしやすいと思います。一方で、MCPは内部処理が見えにくく、特にAPIを直接利用する場合には自分で全てのプロンプト生成やツール実行を管理する必要があります。 個人的にはテストとしてはRAG、実システムとしてはMCPを使うのがよいのではと考えます。
- RAG: 何をしているか分かりやすい、調整しやすい
- MCP: 便利だが内部で何が起きているかが見えにくい
おわりに
RAGとMCPについて詳しく調べてみると、理論的にはわかってるんだけど、実装する際はどうするんだろうなという隠れた点に気付きました。どちらも素晴らしい技術ですが、使い方や目的によって選択するのがよいかなと感じます。
個人的な使い分け？
MCPは多機能さとともに複雑さもありますが非常に便利な仕組みですし、企業側も色々な機能を持つMCPサーバーの開発を行っています。一方で、RAGのシンプルさも魅力的で、プロトタイプとして使ってみるのもいいと感じます。今後の技術の進歩も早いので、どんどん新しい手法が出てくるかもしれません。その時々、試しながら適切な手法を見つけるのが大切かもしれません。
参考文献
