MCP（Model Context Protocol）は、生成AIを組み込んだアプリケーションと外部のデータや機能を、共通の手順で接続するためのオープンなプロトコルです。
MCPサーバーは、その接続先として、読み取れる情報や実行できる操作をアプリケーションに提示します。
MCPはRAGの後継ではありません。
MCPは接続方法をそろえる仕組みであり、RAGは検索した情報を回答の材料にする設計です。
目的が異なるため、どちらか一方を選ぶだけでなく、組み合わせて使うこともできます。
MCPサーバーの役割
MCPの全体像を理解するには、ホスト、クライアント、サーバーを分けて考えるとわかりやすくなります。
| 構成要素 | 役割 |
|---|---|
| MCPホスト | 利用者が操作するアプリケーションです。接続先の管理、利用許可、取得結果の受け渡しなどを担います。 |
| MCPクライアント | ホスト内でMCPサーバーとの接続を維持し、利用できる機能の確認やメッセージ交換を担います。 |
| MCPサーバー | 外部システムにつながり、利用可能なデータや操作を定義して公開します。 |
サーバーが公開する主な機能は次の三つです。
- ツール：ファイル検索、データベース照会、予定の登録など、呼び出すと処理を実行する機能です。
- リソース：ファイルの内容やデータベースのレコードなど、回答の文脈として読み取る情報です。
- プロンプト：特定の作業を進めるために再利用できる指示や入力のひな型です。
これらの情報はJSON-RPCに基づくメッセージでやり取りされます。
ただし、MCPサーバーが生成AIモデルそのものになるわけではありません。
モデルを利用するアプリケーションと外部システムの間に、共通の接続口を設けるのがMCPの役割です。
生成AIが情報を読み、必要に応じて操作する流れを先に理解したい場合は、AIエージェントの仕組みと安全な運用も参考になります。
予定表を使った動作例
社内の予定表を参照するMCPサーバーを例にすると、役割の違いが具体的に見えてきます。
- 利用者がホストに「来週の空き時間を三つ挙げて」と依頼します。
- ホストは接続済みサーバーが公開するツールを確認します。
- クライアントが予定の読み取りに必要な引数を送り、サーバーが予定表システムを照会します。
- サーバーが構造化した結果を返し、ホストが利用者向けの回答に整えます。
この例で予定を読む操作と会議を登録する操作は、同じ権限にまとめないほうが安全です。
登録や削除のように外部状態を変える操作では、実行前に利用者の確認を求める設計が適しています。
MCPとRAGの違い
RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に関係する情報を文書群などから検索し、その情報を回答時の文脈に加える設計です。
MCPとRAGは比較されやすいものの、解決する問題が異なります。
| 比較項目 | MCP | RAG |
|---|---|---|
| 主な目的 | アプリケーションと外部データや機能の接続方法をそろえる | 質問に関係する情報を検索し、回答の材料に加える |
| 扱う対象 | ツール、リソース、プロンプト | 検索対象の文書やデータと、検索結果 |
| 外部操作 | サーバーが公開したツールを通じて実行できる | 検索と情報取得が中心で、操作機能は別途設計する |
| 情報の新しさ | 接続先が返すデータと更新方法に左右される | 検索対象と索引の更新方法に左右される |
| セキュリティ | 接続、認証、権限、確認手順を実装して確保する | 検索権限、文書の分離、入力と出力の管理によって確保する |
| 代表的な用途 | 予定の取得、チケット操作、データベース照会など | 社内文書検索、FAQ、問い合わせ回答の根拠提示など |
たとえば、社内文書を検索するRAG機能をMCPサーバーのツールとして公開できます。
この構成では、RAGが関連文書を探し、MCPがホストから検索機能を呼び出すための接続方法をそろえます。
MCPを導入するメリット
MCPの利点は、生成AIモデルの性能を自動的に高めることではなく、外部システムとの接続を整理しやすくすることにあります。
- 接続仕様を共通化しやすい：ホストごとに別々の連携方法を用意する負担を減らせる場合があります。ただし、接続先の業務処理や既存APIまで不要になるわけではありません。
- 利用可能な機能を示しやすい：サーバーがツールやリソースを定義するため、読み取りと更新の境界を設計しやすくなります。
- 複数の接続先を組み合わせやすい：ホストは、用途の異なる複数のMCPサーバーから必要な機能を利用できます。
- 接続方式を選べる：同じ端末で動かすローカル接続と、ネットワーク越しに利用するリモート接続を用途に応じて使い分けられます。
一方で、導入しただけで運用コストが下がるとは限りません。
サーバーの保守、権限管理、障害対応、利用状況の監視は引き続き必要です。
ローカル接続とリモート接続
MCPサーバーは、利用場所によって大きく二つの形に分けられます。
| 接続形態 | 概要 | 確認したい点 |
|---|---|---|
| ローカル | ホストと同じ端末でサーバープロセスを動かし、標準入出力で通信します。 | 実行ファイルの入手元、端末内の権限、参照できるファイル範囲 |
| リモート | ネットワーク上のサーバーにHTTPで接続します。 | 認証、通信経路、利用者ごとの権限、障害時の扱い |
「ローカルだから安全」「クラウドだから危険」とは一律に決められません。
安全性は、サーバーの実装、運用主体、付与した権限、認証方法、利用者の確認手順によって変わります。
安全に導入するための設計
MCPはセキュリティを自動的に保証する仕組みではありません。
外部システムへ接続する以上、公開する機能とデータを必要最小限に絞る必要があります。
- 読み取り権限と登録、更新、削除の権限を分ける
- 送信、購入、削除など影響の大きい操作は、実行前に利用者へ確認する
- 認証情報を設定ファイルや会話本文に直接書かず、適切な秘密情報管理を使う
- リモート接続では、利用者とクライアントを認証し、操作ごとに権限を確認する
- 入力値と返却データを検証し、必要以上の個人情報や機密情報を渡さない
- 誰が何を実行したか確認できるログを残し、異常な操作を監視する
- 第三者のMCPサーバーは、提供元、更新状況、要求権限、データの送信先を確認してから接続する
組織での責任分担やログ管理まで含めて整理する場合は、生成AI導入で最初に決めるべき運用ルールもあわせて確認してください。
MCPサーバーの導入手順
製品ごとの設定方法は異なりますが、導入判断は次の順序で進めると整理しやすくなります。
- 利用目的を一つに絞る：最初は「社内文書を読む」「予定を検索する」など、結果を評価しやすい用途を選びます。
- データと操作の境界を決める：読んでよい情報、変更してよい項目、実行前に承認が必要な操作を明文化します。
- 対応するホストとサーバーを選ぶ：必要な機能、接続形態、運用主体、更新方針を確認します。
- ツールとリソースを最小構成にする：初期段階では読み取り専用から始め、必要性を確認してから更新権限を追加します。
- 認証と秘密情報を設定する：リモート接続では認証と認可を分け、利用者ごとの権限を設定します。
- 正常系と失敗時を試す：誤った入力、権限不足、接続切断、外部サービス停止時の挙動も確認します。
- ログを見ながら範囲を広げる：利用実績とエラーを確認し、必要な機能だけを段階的に追加します。
よくある疑問
MCPを導入すればRAGは不要ですか
不要にはなりません。
文書検索と回答の根拠づけにはRAGが適しており、その検索機能をMCP経由で利用する構成も可能です。
MCPなら誤回答を防げますか
MCPは外部情報へ接続する方法をそろえますが、取得した情報の正しさや回答の妥当性までは保証しません。
データの品質、ツールの実装、権限、出力確認を別々に設計する必要があります。
既存のAPIは不要になりますか
不要になるとは限りません。
MCPサーバーが既存APIを呼び出し、その機能をMCPのツールとして公開する構成も一般的に考えられます。
導入前に確認したいこと
MCPサーバーは、生成AIを外部データや業務機能につなぐ共通の接続口です。
RAGとは競合する仕組みではなく、検索はRAG、接続はMCPという形で役割を分けられます。
導入時は、対応製品の数よりも、誰がどのデータを読み、どの操作を実行できるかを先に決めてください。
小さな読み取り用途から始め、承認、ログ、障害時の動作を確認してから更新操作へ広げると、安全性と実用性を評価しやすくなります。