Analyzegear
生成AIを利用したシステム開発では、「RAG（Retrieval-Augmented Generation）」と「MCP（Model Context Protocol）」という言葉を目にする機会が増えています。
どちらもLLM（大規模言語モデル）と外部情報を組み合わせる際に利用できますが、両者の役割は異なります。
簡単に整理すると、RAGは「外部から必要な情報を取得し、その情報を使ってLLMに回答を生成させる仕組み・設計パターン」です。一方、MCPは「AIアプリケーションと外部のデータやツールを接続するためのプロトコル」です。
そのため、「RAGとMCPのどちらを使うか」という二者択一ではありません。MCPを利用して情報検索を行い、その結果を使ってRAGを構成することも可能です。
この記事では、RAGとMCPの違い、MCPとAPIの関係、RAGとMCPを組み合わせた場合の処理、認証・認可との違いについて解説します。
RAGとは
RAGは「Retrieval-Augmented Generation」の略で、日本語では「検索拡張生成」などと呼ばれます。
LLMが回答を生成する前に、質問に関連する情報を外部のデータソースから検索・取得し、その情報をLLMのコンテキストとして与える手法です。
基本的な流れは次のようになります。
ユーザーが質問する
↓
質問に関連する情報を検索する
↓
関連情報を取得する
↓
取得した情報をLLMに渡す
↓
LLMが情報を参照して回答を生成する
RAGを構成する重要な要素は「Retrieval」「Augmentation」「Generation」の3つです。
Retrieval（検索・取得）
ユーザーの質問に関連する情報を検索し、必要な情報を取得します。
検索対象としては、社内文書、データベース、検索エンジン、ベクトルデータベースなど、さまざまなデータソースを利用できます。
Augmentation（情報の追加）
検索によって取得した情報を、ユーザーの質問などとともにLLMが利用できるコンテキストへ追加します。
LLMは、自身が事前学習した知識だけではなく、この追加情報も踏まえて回答を生成できるようになります。
Generation（生成）
LLMが与えられた質問と取得情報を基に回答を生成します。
この「検索・取得 → 情報の追加 → 回答生成」という一連の処理がRAGの基本的な考え方です。
MCPとは
MCPは「Model Context Protocol」の略で、AIアプリケーションと外部システムを接続するためのオープンなプロトコルです。
MCPでは、MCP ClientとMCP Serverなどの仕組みを通じて、AIアプリケーションが外部から提供されるツールやデータなどを利用できます。
概念的には次のような構成になります。
LLMを利用するAIアプリケーション
↓
MCP Client
↓
MCP Server
↓
外部システム
MCP Serverの先には、データベース、ファイル、検索システム、既存APIなど、さまざまな仕組みを配置できます。
そのため、AIアプリケーションから「文書を検索する」「データを取得する」「外部サービスの機能を実行する」といった処理を行うための接続方法として利用できます。
RAGとMCPの違い
RAGとMCPの大きな違いは「何を実現するためのものなのか」という目的です。
RAGは、外部情報を取得してLLMの回答生成に利用するための手法です。
一方のMCPは、AIアプリケーションと外部のデータやツールを接続するためのプロトコルです。
両者の役割を比較すると、次のようになります。
| 比較項目 | RAG | MCP |
|---|---|---|
| 正式名称 | Retrieval-Augmented Generation | Model Context Protocol |
| 主な役割 | 外部情報を検索・取得し、LLMの回答生成に利用する | AIアプリケーションと外部のデータやツールを接続する |
| 分類 | 手法・アーキテクチャパターン | プロトコル |
| 主な目的 | LLMに必要な情報を追加して回答を生成する | 外部機能やデータへの接続方法を標準化する |
| 主な対象 | 文書、データベース、検索システムなどから取得した情報 | ツール、リソース、外部システムなど |
| 情報検索 | RAGの中心的な処理 | 検索機能をMCP経由で提供することが可能 |
| LLMへの情報提供 | 取得情報をコンテキストに追加して回答生成に利用する | 外部から取得した情報をAIアプリケーションへ提供できる |
| 外部システムの操作 | 基本的な目的ではない | ツールとして外部処理を実行できる |
| APIとの関係 | APIなどを利用して検索・取得を実装できる | MCP Serverが既存APIを利用して機能を提供できる |
| MCPとの関係 | MCPを利用してRAGの検索処理を実装することも可能 | RAG以外のツール実行やデータ取得にも利用できる |
| 認証・認可 | RAGそのものの役割ではない | MCPそのものがユーザー管理を意味するわけではなく、システムとして適切な認証・認可が必要 |
| 具体例 | 社内文書を検索して、その内容を基にLLMが回答する | AIから社内検索、DB、外部サービスなどの機能を利用する |
つまり、簡潔に表現すると次のようになります。
RAG：LLMが外部情報を利用して回答するための仕組み・設計パターン
MCP：AIアプリケーションと外部のデータやツールを接続するためのプロトコル
この違いを理解すると、「RAGとMCPは競合する技術ではない」ということも分かります。
MCPを使った場合、どこがRAGになるのか
MCPを利用して社内文書を検索するシステムを考えてみましょう。
処理の流れは次のようになります。
ユーザー
↓
LLMを利用するAIアプリケーション
↓
MCP Client
↓
MCP Server
↓
社内文書を検索
↓
関連文書を取得
↓
取得した情報をLLMのコンテキストに追加
↓
LLMが関連文書を参照して回答
↓
ユーザーへ回答
この構成では、「MCP Server」がそのままRAGなのではありません。
RAGに相当するのは、質問に関連する情報を検索・取得し、その情報をLLMに与えて回答を生成する一連の処理です。
具体的には、
社内文書を検索
↓
関連文書を取得
↓
取得情報をLLMのコンテキストに追加
↓
LLMが情報を基に回答
という部分がRAGの中心になります。
MCPは、そのRAGに必要な検索機能などへAIアプリケーションがアクセスするための接続方法として利用できます。
RAGにMCPは必須ではない
RAGを実現するためにMCPが必須というわけではありません。
例えば、AIアプリケーションから独自の検索処理やAPIを直接利用して関連文書を取得し、その結果をLLMへ渡す構成でもRAGを実現できます。
AIアプリケーション
↓
検索APIなど
↓
データベース・文書検索
↓
関連情報を取得
↓
LLMへ追加
↓
回答生成
これもRAGです。
MCPを利用する場合は、検索機能などをMCP経由でAIアプリケーションから利用できるようにします。
AIアプリケーション
↓
MCP Client
↓
MCP Server
↓
検索システム
↓
関連情報を取得
↓
LLMへ追加
↓
回答生成
つまり、RAGを実装する方法の一つとしてMCPを組み合わせることができます。
MCPはAPIなのか
MCPを理解する際に混同しやすいのがAPIとの違いです。
MCPは特定サービスのAPIそのものではなく、AIアプリケーションと外部システムを接続するためのプロトコルです。
APIは一般に、あるソフトウェアやサービスが別のソフトウェアから機能やデータを利用できるように提供するインターフェースです。
例えば、あるサービスが独自のAPIを提供している場合、通常はそのAPIの仕様に従ってリクエストを送信する必要があります。
MCP Serverは、そのような既存APIを内部で利用し、AIアプリケーション側にMCPを通じて機能を提供する構成を取ることもできます。
例えば次のような構成です。
AIアプリケーション
↓
MCP Client
↓
MCP Server
↓
外部サービスのAPI
↓
外部サービス
この場合、MCP Serverが既存APIとの橋渡しをしています。
ただし、MCP Serverが必ずAPIを呼び出すわけではありません。ローカルファイル、データベース、検索システムなどに接続することもできます。
そのため、「MCP＝API」と考えるよりも、「AIアプリケーションが外部のデータやツールを利用するための共通プロトコル」と考えたほうが理解しやすいでしょう。
MCP Serverでは何を提供するのか
MCP Serverでは、AIアプリケーションから利用できる機能や情報を提供できます。
例えば社内システム向けのMCP Serverであれば、次のような機能が考えられます。
社内文書を検索する
顧客情報を取得する
商品情報を取得する
問い合わせチケットを作成する
業務システムの処理を実行する
このうち、「社内文書を検索して取得し、その結果をLLMの回答生成に利用する」という処理はRAGとして利用できます。
一方、「問い合わせチケットを作成する」という処理は、外部ツールの実行であり、それ自体はRAGではありません。
MCPはRAGよりも用途が広く、情報取得だけでなく、外部システムの機能をAIから利用するためにも使えます。
MCP Serverでユーザーや組織を制御するのか
企業システムでMCPを利用する場合、ユーザーや組織ごとのアクセス制御は非常に重要です。
例えば、複数企業が利用するサービスでは、A社のユーザーがB社の社内文書を取得できてはいけません。
そのため、システム全体として適切な認証・認可を実装する必要があります。
ただし、「MCP Serverですべてのユーザー管理や組織管理を行う」と決まっているわけではありません。
実際のシステムでは、認証基盤、AIアプリケーション、MCP Server、検索サービス、データアクセス層などを組み合わせてアクセス制御を実現することがあります。
例えば次のような構成です。
ユーザー
↓
認証
↓
AIアプリケーション
↓
MCP Client
↓
MCP Server
↓
検索サービス
↓
データベース
このとき、ユーザーの所属組織や権限に応じて、アクセス可能なデータだけを検索・取得できるようにします。
特に複数組織を扱うマルチテナントシステムでは、データアクセス層を含めてテナント境界を適切に強制することが重要です。
認証・認可とRAG・MCPは別の概念
RAG、MCP、認証、認可はそれぞれ役割が異なります。
RAGは「必要な情報を検索・取得してLLMの回答生成に利用する」という考え方です。
MCPは「AIアプリケーションと外部のデータやツールを接続するためのプロトコル」です。
認証（Authentication）は、「そのユーザーが誰なのか」を確認する仕組みです。
認可（Authorization）は、「そのユーザーが何を利用できるのか」を判断する仕組みです。
企業向け生成AIシステムを設計する場合は、これらを一つの技術として考えるのではなく、それぞれ別の役割として設計する必要があります。
RAGとMCPを組み合わせた具体例
例えば、社内規程について回答するAIを考えてみましょう。
ユーザーが「国内出張の日当はいくら？」と質問します。
AIアプリケーションは、社内規程を検索する必要があると判断し、MCP Serverが提供する検索機能を利用します。
MCP Serverの先にある検索システムでは、ユーザーがアクセス可能な社内文書を検索します。
検索結果として「国内出張の日当は3,000円とする」という規程が取得されたとします。
この情報がLLMのコンテキストに追加され、LLMは取得した規程を基に「国内出張の日当は3,000円です」と回答します。
この例では、MCPが検索機能へアクセスするための接続方式として使われ、RAGが検索結果を回答生成に利用する方式として使われています。
RAGとMCPを混同しないことが重要
RAGとMCPは、どちらも生成AIシステムで外部情報を扱う場面に登場するため混同されやすい技術です。
しかし、それぞれの役割を分けると理解しやすくなります。
RAGは、外部から関連情報を取得してLLMの回答生成に利用するための手法です。
MCPは、AIアプリケーションと外部のデータやツールを接続するためのプロトコルです。
したがって、「RAGかMCPか」ではなく、「RAGをどのように実装するか」「外部の検索機能やツールへの接続にMCPを利用するか」という観点で考えることが重要です。
さらに、企業システムでは認証や認可も別途設計する必要があります。
生成AIシステム全体を考える場合は、
RAG＝外部情報を取得して回答生成に利用する仕組み・設計パターン
MCP＝AIアプリケーションと外部システムを接続するプロトコル
API＝ソフトウェア同士が機能やデータをやり取りするためのインターフェース
認証＝ユーザーが誰なのかを確認する仕組み
認可＝ユーザーが何を利用できるのかを制御する仕組み
と整理すると、それぞれの役割を明確に理解できます。
