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サーバーのそれぞれの役割分担を意識してアーキテクチャをイメージすると、「なぜこの構成になっているのか」「どこで何が起きているのか」が理解しやすくなるはずです。