RAG 対 MCP：それぞれの役割と、両方を併用すべき場面

RAG（Retrieval Augmented Generation）は、データから関連性の高い文書を抽出し、LLMの応答を裏付けます。 MCP（Model Context Protocol）は、LLMがツールと連携し、外部システム上でアクションを実行するための標準化された手段を提供します。 RAGはモデルの知識のギャップを埋め、MCPはその行動のギャップを埋めます。 実用化されているAIシステムのほとんどは、その両方が必要です。

エンタープライズ・アーキテクチャに関する議論では、「RAGとMCPのどちらを使うべきか」という疑問が繰り返し浮上しています。 それは間違った質問です。

検索強化生成（RAG）とモデルコンテキストプロトコル（MCP）は、異なるレイヤーで動作します。 RAGは、ドキュメントからデータを抽出します。 MCPは外部システムに対して処理を実行します。 「どちらを選ぶべきか」と問うのは、図書館と電話のどちらが必要か、と問うようなものです。

RAGの初期の共同著者の一人であり、Contextual AIのCEOであるDouwe Kiela氏は次のように説明しています。「現在では、MCPやRAGを含むこの分野は『コンテキスト・エンジニアリング』として再定義されていると思います。」 RAGを開発した人物の一人が彼らを競合と見なしていないのなら、あなたもそう考えるべきではないでしょう。

本当の疑問は、あなたのデータインフラが両方をサポートしているかどうかです。 最新のAIシステムでは、関連する文書を検索するためにRAGを、その情報に基づいてアクションを実行するためにMCPを活用することがよくあります。 エージェント型AIを大規模に導入している組織は、すでにその両方を実践しています。

RAGは、LLMの応答をモデルの学習データではなく、自社のデータに基づいて生成するという特定の課題を解決します。

カスタマーサポート用のチャットボットを例に挙げてみましょう。 あるユーザーが「膝の手術に向けて、どのように準備すればよいですか？」と質問しています。

RAGを使用しない場合、モデルは内部の知識に基づいて、一般的な回答を返します。 RAGを活用することで、システムはナレッジベースから関連する文書を抽出し、その内容に基づいた正確な回答を生成します。

コンテンツは、段落や短いセクションといった単位に分割されます。 埋め込みモデルは、各チャンクをベクトル、つまりその意味的な内容を数値的に表現したものに変換します。 類似したコンテンツは、類似したベクトルを生成します。 これらはベクトルデータベースに格納されます。

ユーザーからのクエリが届くと、システムはそれをベクトル化し、意味的に最も類似したスニペットを検索して、それらをクエリとともにプロンプトにまとめます。 ドンはこれを「プロンプト以前のプロンプト」と呼んでいます。 LLMは、与えられた文脈のみに基づいて応答を生成し、トレーニングデータ全体に基づいて生成するわけではありません。

Anthropic（20万トークン）とGoogle（100万トークン以上）が開発した長文処理モデルを巡り、RAGは衰退しつつあるのではないかという憶測が飛び交っています。 この現象が解消されない4つの理由：

1. 大規模なトークンの利用 クエリごとに20万トークンを送信するのは、処理量が多いアプリケーションにとってはコストがかかりすぎます。 対象となる5つのチャンクを取得する方が、桁違いにコストが低い。
2. 検索の質 関連する段落を5つ程度に絞った方が、モデルにすべての情報を一度に与えてしまうよりも、LLMからの応答の質が高くなる場合が多い。 「精度」は「量」に勝る。
3. データの鮮度 ベクトルデータベースは、基となるデータが変更されるたびに段階的に更新されます。 コンテキストウィンドウ方式では、データの完全な再取り込みが必要となります。
4. プライバシーとコンプライアンス。 RAGインデックスは、個別に暗号化およびアクセス制御を行うことができます。 一部のコンテンツが規制されている規制産業においては、すべてのコンテンツをLLM層に同時に送信することは問題となります。

医療分野では、RAGの導入が最も進んでおり、ここでの成果は具体的なものとなっています。 放射線医学における臨床意思決定支援に関する研究によると、RAGの導入によ り幻覚の発生率が8％から0％へと減少したことが明らかになりました。 臨床栄養学の分野において、RAGを活用したシステムが、EHRの看護記録から臨床栄養データを要約し、 99.25％の精度を達成しました。 厳選された教科書を活用したRAGシステムは、放射線腫瘍学の専門医試験において 91.5%の精度を達成しました。

「GraphRAG」と呼ばれるその派生版は、エンティティや関係をフラットな文書チャンクではなくナレッジグラフとしてモデル化し、 複雑な慢性疾患の管理に向けたマルチホップ検索ロジックを可能にしています。

MCPは、AIモデルが外部システム上でアクションを実行するための標準化された方法を提供するという、別の課題を解決します。

MCPが登場する前は、ツールごとに独自の統合コードが必要であり、パラメータ、プロトコル、応答形式がそれぞれ異なっていました。 MCPはツールへのアクセスを標準化しました。 MCPに関する自身の動画の中で、ドンは次のように定義しています：

MCPサーバーは、1つ以上のツール（内部API、外部データベース、または呼び出し可能なサービスなど）をラップし、以下の2つのメソッドを実装します：

1. ツールのリスト- LLMが「どんなツールを持っていますか？」と尋ねます
2. 呼び出しツール- LLMは「このツールをこれらの引数で呼び出してください」と述べています

以上です。 MCPクライアント（ホストアプリケーションまたはエージェントフレームワークに組み込まれているもの）は、この標準プロトコルを使用して、あらゆるMCPサーバーと通信する方法を知っています。

ドンは次のような例えを挙げています：

「私たちの業界では、これをFHIRサーバーに少し似ていると考えてもよいでしょう。」 FHIRサーバーは単なるRESTサーバーですが、患者情報の取得や更新を行う際には、特定の方法に従う必要があります。 返ってきた回答には一定の形式があり、それをどう解釈すべきかはわかっているはずです。 「MCPも同様で、ツールを参照し、結果を得ることができる標準化された手法です。」

FHIRｈは医療データ交換を標準化しました。 MCPはAIツールへのアクセスを標準化します。 研究者たちは、 MCPとFHIRを統合するためのフレームワークを開発しています。

ドン氏は、エンタープライズ組織にとってMCPが重要である5つの理由を次のように説明しています：

1. ツールのポートフォリオは相乗効果を生みます。 最初のプロジェクトで3つのツールを使うだけでは、その手間をかける価値はありません。 ツールを100個規模に拡大すれば、標準化の効果が発揮されます。

2. 特定の技術に依存しません。 このツールは、どの言語でも作成できます。 クライアントは、まったく別のものになる可能性もあります。 この独立した関係により、ツールは現在の技術スタックよりも長く使い続けることができます。

3. 標準化は変更を容易にします。 LLMプロバイダーを切り替えます。 チェンジ・エージェント・フレームワーク MCPツールを書き直す必要はありません。

4. ベンダー各社はMCPサーバーを出荷しています。 Salesforce、Jira、および各カテゴリーにわたるエンタープライズプラットフォームでは、現在、MCPサーバーがバンドルされています。 医療分野において、GenomOncology社は2025年4月、臨床試験、ゲノム変異、医薬品、および公表された文献にまたがる12の生物医学データエンティティを網羅した 「BioMCP」を立ち上げました。

5. インターネットネイティブ MCPサーバーはローカルで実行する必要はありません。 天気API、ドキュメントサービス、外部データベースなど、あらゆるインターネットリソースをMCPサーバーとしてラップすることができます。

MCPサーバーは、信頼できるユーザーがCRMレコードの更新、リアルタイムデータの取得、ワークフローの起動など、予測不可能な方法で構造化データとやり取りする必要がある社内ツールにおいて、特に有用です。

Anthropicは2024年11月にMCPをリリースしました。 OpenAIは2025年3月にこれを採用しました。 2025年4月には、Google DeepMindが続きました。 2025年12月、AnthropicはM CPを、BlockおよびOpenAIと共同で設立したLinux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈し、ChatGPT、Cursor、Gemini、Microsoft Copilotなどのプラットフォームを合わせて、1万台以上のアクティブな公開MCPサーバーが存在すると報告しました。

関数呼び出しとは、LLM内部において、モデルが「ツールを呼び出したい」という信号を送る仕組みのことです。 プラットフォームごとに実装方法が異なります。 MCPは最上位に位置し、どのLLMを使用する場合でも、ツールの記述や呼び出し方法を標準化します。 関数の呼び出しが目的です。 MCPは、意図を移植可能にするためのインフラストラクチャです。

次元	RAG	MCP
主な機能	データソースから関連するコンテキストを取得する	AIエージェント向けの標準化されたツールアクセス
データ型	非構造化データ（文書、記事、マニュアルなど）	構造化データ（API、データベース、本番システム）
データフロー	一方向：取得 → 注入 → 生成	双方向：クエリ → アクション → 結果 → 次のステップ
状態の変化	いいえ - 読み取り専用	はい - 書き込み、更新、アクションのトリガーが可能です
スケーリング	ベクトルの保存容量と再インデックス処理能力を向上させる	新しいサーバーエンドポイントと接続を追加する
根本的な問題	LLMはあなたの個人情報を把握していません	LLMは外部システムに対して一貫した処理を行うことができない
こんな方に最適	予測可能な質問が寄せられる一般向けアプリ	相互作用が予測できない内部ツール

マイクロソフト・リサーチの社長であるピーター・リー博士は、エージェント型AIを、記憶、権限、行動、推論という4つの相互に関連した能力として説明しました。 RAGは、エージェントが必要とする外部コンテキストであるメモリを扱います。 MCPでは、エージェントがアクセスできる対象や実行できる操作といった権限やアクションを規定しています。 推論を行うのはLLMそのものです。

以下の3つの質問が、その決定を明確にします。

知識が、臨床ガイドライン、ポリシーマニュアル、製品ドキュメントなどの静的で構造化されていないデータに含まれている場合、RAGはクエリ実行時にその知識を取得し、プロンプトに組み込みます。

知識が、最新の検査結果、リアルタイムの在庫状況、保留中の注文ステータスなどのライブで構造化されたデータである場合、MCPはソースに直接クエリを実行します。

ユースケースが質問応答、要約、または文書検索である場合は、RAGだけで十分である可能性が高いです。

AIがレコードを更新したり、アポイントメントをスケジュールしたり、ワークフローを起動したりする必要がある場合は、MCPが必要となります。

1つのユースケースでは、RAGから開始し、必要に応じて関数呼び出しを追加することができます。 しかし、部門をまたいで複数のAIワークフローを計画している場合は、今すぐMCPインフラへの投資を検討してください。 金型用コンパウンド

シナリオ	建築	なぜ
顧客向けFAQチャットボット	RAGのみ	読み取り専用；内部ナレッジベースから情報を取得します。
技術文書の検索	RAGのみ	非構造化データに対するセマンティック検索
薬物相互作用の検索	GraphRAG	複雑なエンティティ間の関係には、マルチホップ推論が必要となる
事前承認アシスタント	RAG + MCP	ポリシーに関する知識が必要（RAG）であり、リクエストを送信できる（MCP）
臨床意思決定支援	エージェント型RAG + MCP	外部データソースにわたる多段階の検索とアクション
CRM／EHRの受付業務の自動化	MCP一次選挙	データベースへの書き込み、スケジュール設定、通知の送信を行います
リアルタイムデータダッシュボード	MCP プライマリー	複数のソースから構造化されたリアルタイムデータを取得します

患者紹介のワークフローは、この2つがどのように連携しているかを示しています：

1. MCPは、EHR内の患者の最新記録（リアルタイムの構造化データ）を確認します。
2. RAGは、ナレッジベースから関連する臨床ガイドラインを検索します（文書検索）。
3. MCPは、その依頼をスケジューリングシステムに送信する（アクション）
4. MCPは紹介医に通知を送信します（アクション）
5. LLMは、あらゆる情報を統合して回答と監査証跡を生成します

RAGは制約を通じて安全性を確保します。 このシステムは、事前にコンテンツを組み込み、インデックスを作成しておき、クエリが実行された際には、関連するスニペットのみを取得します。 稼働中のシステムとは直接接続されていないため、攻撃対象領域が限定されます。

規制対象業界の組織では、通常、RAGをオンプレミスまたはプライベートクラウドに導入しています。 ベクトルデータベースは組織のインフラストラクチャ内で稼働し、埋め込み表現はローカルで生成されるため、機密データが企業の境界外に出ることはありません。

MCPがアクションを実行できるという特性により、読み取り専用のRAGアーキテクチャでは生じないリスクが生じます。 MCPにより、AIが人間の代わりに行動できるようになりますが、これにより、サーバーが侵害されたり、設定が不適切であったりする場合、セキュリティ上のリスクが生じます。 OWASPは2025年、M CPに特化した「トップ10」を発表しました：

トークンの不適切な管理。 MCPの設定にハードコーディングされた認証情報や有効期間が長いトークンが存在すると、侵害された場合に接続されたシステムが危険にさらされる可能性があります。 このプロトコルでは認証にOAuth2が規定されていますが、その適用は実装に依存します。

コンテキストおよびプロンプトの注入。 MCPエコシステムにおいて、プロンプトインジェクションにより、自動化されたアクションがトリガーされたり、ユーザーが送信したメッセージに埋め込まれた指示が、過剰な権限を持つエージェントによって本番システムに対して実行されたりすることがあります。 冗長なコンテキストウィンドウが問題をさらに悪化させます。モデルが、無関係な情報や矛盾する情報に基づいて動作してしまう可能性があるからです。データの流出とスキーマの発見

悪意のある攻撃者は、接続されたデータベースから機密データを抽出するためのプロンプトを作成したり、さらなる攻撃を計画するためにデータベーススキーマ全体を把握したりする可能性があります。 権限が過剰に付与されたエージェントは、これらのリスクの両方を増幅させます。

推奨される緩和策：暗号による検証を伴うMCPサーバーの許可リスト登録、最小権限のアクセス制御、高リスクな操作に対する人的承認プロセス、サンドボックス環境、および監査ログの記録

医療機関にとって、OAuth2 を採用した SMART on FHIR などの FHIR の既存の認証フレームワークは、MCP に接続されたエージェントに対して自然なセキュリティ層を提供します。

MCP ツールとしてラップされた FHIR サーバーを介して患者データにアクセスする AI エージェントは、その FHIR サーバーの認証、認可、および監査インフラを継承します。

InterSystems HealthShareまたは InterSystems IRIS for Healthを運用している組織は、すでに HITRUST r2 認証を取得した FHIR ネイティブのインフラストラクチャを保有しており、これにより AI エージェントに既存のコンプライアンス基盤が提供されます。

最先端のAIシステムは、マルチエージェントアーキテクチャ内でRAGとMCPを組み合わせています。 LLMへの各呼び出しは、それぞれ固有の役割を持つエージェントとなります。 すべてのエージェントがLLMというわけではありません。中にはツールもあります。 オーケストレーターは、ワークフローを動的に制御します。

エージェント型パターンは、単一のLLMには欠けている「修正ループ」をAIに提供します。

ドンがマイクロソフトリサーチのピーター・リー博士に行ったインタビューの中で、リー博士は、スタンフォード大学医学部と共同で開発した、腫瘍症例検討会向けの医療オーケストレーター・エージェントについて説明しました。

このエージェントは、患者記録（MCP）を取得し、放射線診断および病理診断のAIモデル（MCP）を呼び出し、外部データソース（RAG）から公開されている研究情報にアクセスし、会議での決定事項（MCP）を記録します。 RAGとMCPは、それぞれが設計された役割を果たしています。

マイクロソフトのMAI-DXOシステムはこれをさらに発展させています。異なる役割を持つ複数のエージェント――主要な診断エージェント、あらゆる結論に異議を唱える反論エージェント、あらゆる検査依頼に疑問を呈するコスト意識の高いエージェント――で構成されています。

このシステムは「議論の連鎖」を通じて、NEJMに掲載された症例報告において85.5％の診断精度を達成しました。これは、同じ条件下でテストされた経験豊富な医師の精度の4倍以上にあたります。

1. 基礎となるデータを検証する。 RAGは、データソースに含まれる情報を取得します。 ドキュメントに一貫性がなかったり、ポリシー文書間で矛盾があったりする場合、RAGはそうした問題を大規模に洗い出します。 InterSystems IRISのような統合データプラットフォームは、トランザクション処理、分析処理、ベクトル検索を単一のエンジンに統合しており、これにより検索品質を低下させるデータの断片化を軽減します。

2. APIの導入準備状況を評価してください。 既存のRESTエンドポイント（医療機関向けの FHIR APIを含む）は、MCPサーバーラッパーの最適な対象となります。 OAuth2認証を備えた、十分にドキュメント化された内部APIがすでにあれば、MCPの準備は思っている以上に整っていると言えます。

3. まずはRAGのパイロット版から始めましょう。 顧客向けチャットボット、ドキュメント検索、およびポリシーに関するQ&Aは、範囲が明確で適切に管理されたデータソースを備えた、実績のある導入ポイントです。

4. ツールへのアクセスを許可する前に、MCPのガバナンス体制を確立してください。 エージェントが本番システムとやり取りを行う前に、ホワイトリスト登録、アクセス制御、人的承認プロセス、および監査ログの記録を適切に整備しておく必要があります。 ハートフォード・ヘルスのCIO、ジョエル・ヴェンコ氏は、マリオ・アンドレッティの言葉を引用してこう述べた。「本当に優れたブレーキがあれば、より速く走れるのだ。」 ガバナンスはスピードを制限するものではなく、自信を持ってデプロイを行うためのものです。