MCPサーバーを使って業務効率化を図っている方も、最近かなり増えてきたのではないでしょうか。
私自身も最近、FigmaのMCPサーバーを使ってフロントエンドのコーディングを試してみたのですが、「これは確かに便利だな」と感じました。
一方で、実際に使ってはいるものの、「MCPサーバーって内部的にはどういう仕組みなんだっけ？」と聞かれると、正直あまりちゃんと説明できていないことに気づきました。
そこで本記事では、MCPサーバーを使う側のエンジニア視点で、MCPサーバーの仕組みを整理してみた内容をまとめていきます。
MCPって何？
MCPは Model Context Protocol の略で、AI（ChatGPT / Claude など）と外部ツール・データ・ワークフローを安全かつ統一的につなぐためのオープン標準プロトコルです。
MCPは、しばしば「AIにとってのUSB-Cポート」に例えられます。USB-Cがさまざまなデバイスを共通の規格で接続できるように、MCPもクラウドサービスやローカルシステム、データベース、業務アプリケーションなどを共通のインターフェースでつなぎます。これにより、AIは個別実装に依存することなく、多様なシステムと柔軟に連携できるようになります。
出典: https://norahsakal.com/blog/mcp-vs-api-model-context-protocol-explained/
従来との比較
（従来のAI × 外部ツール連携）
- AIアプリケーションを外部ツールに接続する際には、ツールごとに個別のAPI連携を実装する必要があった
- APIの仕様や認証方式はサービスごとに異なり、実装や保守のコストが高くなりがちだった
- 利用するLLMモデルを変更した場合、連携部分の実装を見直す必要が生じるケースも多かった
（MCP導入後の連携）
- 外部ツール側にMCPサーバーが用意されていれば、個別のAPI連携を意識せずに利用できる
- 最小限の設定だけで、複数のツールを共通の方法で接続できる
- LLMモデルを変更しても、追加の連携実装を行うことなく利用できる
（ひと目で分かる比較）
| 観点 | 従来 | MCP導入後 |
|---|---|---|
| 連携方法 | ツールごとに個別API実装 | 共通インターフェース |
| 実装コスト | 高い | 低い |
| モデル変更時の対応 | 再実装が必要 | 原則不要 |
| 保守性 | 低い | 高い |
MCPを導入することで、AIと外部ツールの連携を標準化でき、実装や保守にかかるコストを大きく削減できる。
MCPの全体構成
MCPの全体構成はMCPホスト、MCPクライアント、MCPサーバーの３つの層に分けることができます。
それぞれの役割をざっくり説明する下記のようになります。
- MCPホスト：ユーザーと対話するAIエージェントの司令塔(ChatGPT,Cursorなど）
- MCPクライアント：ホストとサーバーをつなぐ仲介役
- MCPサーバー：実際に外部リソースへアクセスする実行役
出典: https://modelcontextprotocol.io/docs/learn/architecture
上記のアーキテクチャをみたところで、それぞれの役割を詳しくみていきたいと思います。
MCPホスト（司令塔）
MCPホストは、ユーザーと直接対話するAIエージェント本体の「司令塔」です。ユーザーからのプロンプト（命令文）を受け取り、「どのツール・データが必要か」を判断し、適切なMCPクライアントに処理を依頼します。
（MCPホストの主な機能）
- ユーザーのプロンプト内容を解析
- 必要なツール・リソースを特定
- MCPサーバーに対する実行リクエストの指示
- 各クライアントからの結果を整理・統合し、ユーザーに返答
MCPクライアント（仲介役）
MCPクライアントは、ホストアプリケーションによってインスタンス化・管理され、特定のMCPサーバーと1対1で通信を行う仲介コンポーネントです。Claude.ai や IDE などのホストアプリは複数のMCPクライアントを管理し、それぞれを異なるMCPサーバーとの通信に割り当てます。ユーザーの指示にもとづき、MCPクライアントは適切なMCPサーバーへ実行指示を送信し、サーバーから得られた実行結果をLLMにコンテキストとして渡すことで、ホスト側での最終的な返答テキスト生成をトリガーします。
（※ テキスト生成そのものはホスト／LLMが行います）
（MCPクライアントの主な機能）
MCPクライアントは、MCPサーバーとの通信を仲介するにあたり、以下のような仕組み・機能を提供します。
ルート（Roots）
ルートは、アクセス可能な範囲を限定する仕組みです。LLMが必要な情報のみにアクセスできるようにし、不要・危険なデータへのアクセスを防ぎます。
例）
- 旅行予約用サーバーには、特定のカレンダーディレクトリのみを許可
- ユーザーのカレンダー情報だけを読み取れるよう制限
→ セキュリティと最小権限の実現
サンプリング（Sampling）
サンプリングは、MCPクライアントを介してLLMに対し、同じ問いについて複数回の応答生成を要求できる仕組みです。MCPクライアントは、異なるコンテキストや条件を付加しながらLLM呼び出しを仲介することで、より精度が高く、文脈に適した回答を引き出します。
また、MCPサーバーはMCPクライアントを通じてLLMのサンプリングを要求でき、判断をLLMに委ねることも可能です。
例）
- 「このデータをどう解釈すべき？」
- 「次に何をすべき？」
- フライト一覧をLLMに渡し、「ユーザーにとって最適な便を選んで」と依頼する
エリシテーション（Elicitation）
エリシテーションは、ユーザーに追加の確認を求める仕組みです。
例）
- 「本当に削除しますか？」
- 「どちらの方法がよいですか？」
- 座席の種類、部屋タイプ、連絡先情報などを予約確定前にユーザーへ確認
MCPサーバー（実行役）
MCPサーバーは、MCPクライアントから受け取った指示をもとに、実際に外部リソースへアクセスする「実行役」です。
（MCPサーバーの主な機能）
MCPサーバーは、MCPプロトコルに従って、クライアントから利用可能な機能として、
以下の要素を公開します。
ツール（Tools）
ツールは、LLMが外部とやり取りするためのアクションを提供します。
例）
- 外部APIの呼び出し
- 関数計算
- ファイル操作
- 外部システムとの通信
→ 「文章生成だけでは足りない」場面を補う存在
リソース（Resources）
リソースは、LLMの回答生成に必要なコンテンツを提供する読み取り専用データです。
例）
- ファイル内容
- データベースのレコード
- データベーススキーマ
- APIドキュメント
→ 文脈情報を提供する受動的なデータソース
プロンプト（Prompts）
プロンプトは、LLMの応答をテンプレート化し、対話を構造化するための仕組みです。外部アクション（ツール実行など）を伴わずに、質問の前提や文脈をあらかじめ定義できます。
あらかじめ用意されたプロンプトを利用することで、
- 質問をコンテキスト化する
- 異なる形式のデータを統合する
- 特定のツールやリソースを使うようLLMに指示する
といったことを、毎回同じ指示を書かずに実現できます。
例）
- 英訳タスク
- 通常：「以下の文章を英訳してください」と毎回入力
- MCPプロンプト使用時：英訳したい本文だけ入力すればOK
まとめ
本記事では、MCPについて、MCPサーバーを利用するエンジニアの視点から、その全体像と仕組みを整理しました。
MCPは単なる「便利な連携手段」ではなく、AIと外部ツールを標準化された形で安全につなぐためのアーキテクチャとして設計されていることが分かります。
特に、MCPホスト、MCPクライアント、MCPサーバーのそれぞれの役割分担を意識してアーキテクチャをイメージすると、「なぜこの構成になっているのか」「どこで何が起きているのか」が理解しやすくなるはずです。