MCPアーキテクチャ：図解による技術的な徹底解説

MCPアーキテクチャとは、MCP（Model Context Protocol）を実現するための基盤となるコンポーネントと通信ルールの集合です。MCPはオープンソースの標準規格であり、MCPアーキテクチャはそれを動かす基盤インフラです。

MCPアーキテクチャはいずれも、ホスト、クライアント、サーバーという3つのコアコンポーネントで構成され、それらを中心に構築されています。MCPの通信フレームワークは、データレイヤーとトランスポートレイヤーで構成されると説明されることがよくあります。データレイヤーは、メッセージのフォーマット方法に関するルールの集合です（MCPのリクエストはJSON-RPC 2.0で送信されます）。トランスポートレイヤーはそれらのメッセージを伝送し、外部接続にはStreaming HTTPを使用します。

MCPアーキテクチャは、Model Context Protocolを実装するサーバーフレームワークです。Model Context Protocolは、AIモデルをツールに接続したり、データベースなどのリソースや入力コンテキストを拡張するプロンプトに接続したりするためのオープン標準です。これらは総称して「プリミティブ」と呼ばれます。最終的に、MCPアーキテクチャによって、LLMは利用可能なツールを検出し、ワークフローを実行できるようになります。しかも、クライアント側で定期的なアップデートを行う必要はありません。

MCPアーキテクチャの図：AIアプリケーションがMCPサーバーとリクエストをやり取りし、MCPサーバーがツール、リソース、プロンプトを提供しています。

Anthropicによって導入されて以来、MCPアーキテクチャはAIワークフローで広く使われるようになりました。その主な理由は、複数のAPI接続を中心に構築されたシステムなど、メンテナンス負担の大きい仕組みを、パフォーマンスを犠牲にすることなく置き換えられるためです。利用可能な機能はすべてMCPサーバーの背後にあるため、必要な接続は1つだけで済み、アップデートや追加機能はクライアントアプリケーションですぐに利用できるようになります。

MCPは、ホストアプリケーションのローカルシステム上、または外部プロバイダーから利用可能なツール、プロンプト、リソースを、LLMが検出して呼び出すための手段を提供します。

外部の機能へのアクセスを提供するツールの場合、ディスカバリーでは、ホストがMCPサーバーにtools/list呼び出しを行い、利用可能なツールを確認します。その後、LLM（場合によってはホスト）が利用可能なツールの説明を読み取り、必要に応じてそれらをリクエストします。プロンプトとリソースも同様のプロセスを使用します。

MCPアーキテクチャのコンポーネントの図：LLM、オーケストレーター、クライアントを含むホストが、ディスカバリー、次にリクエストという2つのステップでMCPサーバーに接続し、MCPサーバーがツール、リソース、プロンプトを公開しています。

これは、これまでソフトウェア開発で標準とされてきた、個別に作り込まれたAPIベースのアーキテクチャとは対照的です。そうしたアーキテクチャでは、アプリ外部の機能を呼び出すために、専用の接続と厳密にフォーマットされたリクエストを使う必要がありました。

ホストアプリケーションは中心的なオーケストレーションプラットフォームであり、LLMに接続します。PerplexityやClaude Desktopなどのよく知られたツールは、MCPシステム内でホストとして機能できます。

シンプルなワークフローでは、ユーザーはチャットインターフェースから質問します。次に、ホストのオーケストレーターコンポーネントが質問にコンテキストを追加し、利用可能なMCPプリミティブとその機能の説明をLLMに伝えます。

クライアントは、AIアプリケーション内のソフトウェアコンポーネントです。MCPは、ホストまたはLLMの指示に基づいて、クライアントが内部および外部のMCPサーバーと通信するための標準インターフェースを提供します。クライアントの役割は、接続を確立し、JSON-RPCメッセージをフォーマットし、リクエストを送信し、レスポンスを受信することです。

「MCPホスト」と「MCPクライアント」という用語は、同じ意味で使われることもあります。しかし、Perplexityのようなホストは複数のMCPクライアントを同時にオーケストレーションする場合があるため、この区別は有用です。複雑なAIワークフローでは、数十、場合によっては数百もの個別のMCPサーバーへのアクセスが必要になることがあり、それぞれが個別の接続を使用します。

MCPホスト（Perplexityなど）が3つのMCPクライアントをオーケストレーションしている図。各クライアントは、データベース、ファイル、外部APIなど、それぞれ専用のMCPサーバーに接続しています。

サーバーは、AIベースのツールが使用できるすべてのツールを公開します。アーキテクチャの観点から見ると、MCPサーバーは受信したリクエストを解釈し、必要に応じて、リクエストされたプリミティブに接続します。

MCPサーバーは、次の3つのカテゴリのプリミティブへのアクセスを提供できます。

ツール：これらは基本的に、外部ソフトウェアの機能です。従来のAPIベースのアプローチで考えると、Web分析アプリケーションは、外部サーバーへのフォーマット済みリクエストを使ってデータを取得することがあります。MCPアーキテクチャでは、プロバイダーが提供するサードパーティの機能はすべて単一の接続で利用でき、リクエストは標準のフォーマットルールに従って作成されます。
リソース：リソースは、読み取り専用のコンテキストを提供するデータソースです。データベーススキーマがその好例です。MCPサーバーは、ホストが利用できるさまざまな情報源を公開します。LLMが生成したSQL検索などでホストがデータベースにクエリを実行する場合、これはツールリクエストと見なされます。
プロンプト：LLMが特定のタスクを実行するのに役立つ、再利用可能なプロンプトテンプレートです。ユーザーやホストは、タスクを完了するために既成の指示が必要な場合、ツールではなくプロンプトを呼び出します。多くの場合、ホストアプリケーションに用意された「コードをレビュー」や「データを分析」といったオプションなどのプリセットタスクは、ユーザーが選択できるプロンプトとして保存されています。

また、MCPとAPIは互いに排他的な技術ではないという点も注目に値します。MCPサーバーは、ディスカバリーリクエストへの応答として利用可能なAPI呼び出しを公開する場合があります。重要なのは、それらを維持管理するのはクライアントではなく、MCPプロバイダーだという点です。

MCPアーキテクチャにおけるデータレイヤーとは、リクエスト、レスポンス、通知のフォーマット方法を定義するルールの集合です。メッセージの標準言語はJSON-RPCです。

すべてのMCPアーキテクチャは、(1) ホストによる初期化とディスカバリー、(2) MCPサーバーによるレスポンス、(3) ホストによる呼び出し（LLMが判断する場合もあります）という基本プロセスに従い、各段階はそれぞれ個別のJSONメッセージで表されます。

MCPデータレイヤーの図：ユーザーがホストアプリケーションにプロンプトを送信し、ホストアプリケーション内ではLLMがMCPクライアントと連携します。クライアントはMCPサーバー（ツール、リソース、プロンプト）にリクエストを送信して結果を受け取り、ホストがユーザーにレスポンスを返します。

ツールのディスカバリーの仕組みを、2つの例で見てみましょう（これらはリソースやプロンプトにも当てはまります）。

LLMの生成前にツールを検出する：ホストがMCPクライアントを起動し、MCPクライアントがtools/listリクエスト（MCPサーバーで利用可能なツールのリスト）を送信します。LLMは生成プロセス中にこれを確認し、特定のツール、リソース、プロンプトが必要かどうかを判断します。
検索を実行するオプションをLLMに提供する：エージェント型システムでは、ホストがsearch-tools などのディスカバリーオプションをコンテキスト入力に追加し、LLMは必要に応じて検索をリクエストできます。

ツールは概して外部アプリケーションの機能であり、通常はLLMまたはホストによって選択されます。リソースとプロンプトは通常、ユーザーの求めに応じて、またはホストによってリクエストされます。

架空のメモアプリケーションからMCPサーバーへのtools/listリクエストは、次のようになります。

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

この例では、“id”:101がIDによってリクエストを識別し、クライアントがレスポンスを照合できるようにしています。また、“params”フィールドには、クライアント名（notes-app-client）や機能など、クライアントに関する追加情報が含まれています。

これに応答して、MCPサーバーはツール定義を返します。ツール定義には、利用可能なツールの名前とその関連情報が含まれます。たとえば、リストにはadd-taskツールが含まれる場合があります。このツールを使うと、メモアプリケーションは接続されたタスク管理アプリケーションやカレンダーアプリケーションにタスクを作成し、各タスクにタイトルと優先度を割り当てることができます。

リクエストは次のようになります。

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method”フィールドはツール呼び出しであることをMCPサーバーに伝え、“name”は呼び出すツールを指定し、“arguments”は必要な入力を提供します。

データレイヤーがクライアントとMCPサーバー間の接続における「何を」だとすれば、トランスポートレイヤーは「どのように」にあたります。トランスポートレイヤーは、メッセージがどのように伝わるか、つまり具体的なチャネルと、リクエストとレスポンスの配信方法を規定するルールを定義します。

MCPには2つのトランスポート経路があります。

標準入出力：MCPサーバーがホストアプリと同じローカル環境で実行される場合に使用されます。クライアントはJSONリクエストをサーバーの標準入力に書き込みます。サーバーはそれを読み取り、リクエストされた操作を実行して、レスポンスを標準出力に書き込みます。
Streamable HTTP：MCPサーバーがホストアプリケーションの外部で実行される場合、MCPクライアントはHTTP POSTを使用してサーバーにリクエストを送信します。サーバーは、単一のJSONメッセージ、またはServer-Sent Events（SSE）ストリームのいずれかで応答します。SSEストリームは持続的な「リスニング」チャネルであり、これによってサーバーは時間をかけて複数のメッセージを返すことができます。

MCPマルチテナントアーキテクチャは、複数のユーザー（テナント）に同時にサービスを提供できる実装形態です。

ここでいうテナントとは、個人、個人のグループ、または組織を指します。実装方法としては、テナントごとに個別のMCPサーバーを実行する方法、単一の共有サーバーへのアクセスを提供する方法、中央のゲートウェイの背後に一連のサーバーを配置する方法があります。ゲートウェイを使用する場合、ゲートウェイはユーザーのIDやリクエストの性質に基づいて、リクエストを適切なエンドポイントにルーティングします。

基本的な原則は標準的なMCPアーキテクチャと同じですが、個々のユーザーのリクエストはそれぞれ独自のワークスペース内で処理され（共有リソースを伴う場合でも）、個別に認証されます。エンタープライズ環境で一般的であり、複数のMCPサーバーを実行すると不必要にコストがかかるため、共有リソースが好まれることがよくあります。

エンドツーエンドのMCPリクエストは、実際にはどのように行われるのでしょうか？主要な段階は8つあり、それぞれに異なるアーキテクチャコンポーネントが関わります。

エンドツーエンドのMCPリクエストを8つのステップで示したフローチャート：ツールのディスカバリー、ユーザー入力、モデルによる処理、ツールの選択、リクエスト、ツールの実行、結果、回答の生成。

先ほどの、タスク管理サービスに接続されたメモアプリケーションの例を使って、MCPツール呼び出しが実際にどのように行われるかを見てみましょう。

ツールのディスカバリー：メモアプリケーション（ホスト）は、MCPクライアントを使用し、tools/listリクエストを通じてサーバーで利用可能なツールをリクエストします。サーバーは、add-taskツールを含む各ツールの名前、説明、想定される入力を返します。これは、プロンプトを送信する前に行われる場合があります。
ユーザー入力：アプリ内のチャットボットを使って、LLMベースのメモアプリケーションにリクエストを送信します。たとえば「新しい下書きをレビューするタスクを、優先度『中』でカレンダーに作成して」といったリクエストです。
モデルによる処理：ホストは、あなたのリクエストと関連するツール定義をLLMに送信します。
ツールの選択：LLMは、ツールとその入力を指定した構造化ツールリクエストを生成します。この例では、add-task（title: Review the draft、priority: Medium）です。ホストはそのアクションが許可されているかを確認したうえで、リクエストをMCPクライアントに渡し、MCPクライアントがJSON-RPCメッセージを送信します。
リクエスト：MCPクライアントは、MCPサーバーにtools/callリクエストを送信します。
ツールの実行：MCPサーバーはタスク管理アプリケーションのAPIを呼び出し、指定されたタイトルと優先度で新しいタスクを作成します。
結果の返却：サーバーは結果をMCPクライアントに返し、MCPクライアントはそれをホストに渡します。ホストは、LLMに提供する情報にその結果を追加します。
回答の生成：LLMはその結果を使ってユーザーへの回答を生成します。たとえば「下書きをレビューするタスクを、優先度『中』で作成しました。」といった回答です。

MCPと従来のAPIアーキテクチャは混同されがちですが、両者は補完し合う技術です。MCPは、AIベースのアプリケーション向けに特別に設計されました。ハードコードされた複数のAPI接続を実装・管理するという、大きなメンテナンス負担を解消します。

MCPは、機能プロバイダーや内部リソースごとに単一の接続をホストアプリケーションに提供することで、コンテキスト入力の肥大化（すべてのAPIを列挙すること）や、APIベースのアプリケーションスクリプトの制約といった問題の解決に役立ちます。

代わりに、MCPはツールリストの一部としてAPI（より正確には、APIを呼び出す機能）を公開できます。プロバイダーがアプリを更新して新しいAPIが追加されたり、ドキュメントが変更されたりした場合でも、プロバイダーはMCPサーバーを更新するだけで済みます。ホストアプリ側でコードを変更する必要はありません。

MCPのセキュリティは、登場以来、大きな議論の的となってきました。一般的には安全な技術と考えられていますが、いくつかのセキュリティリスクがあり、その多くは複雑なアーキテクチャの実装でより顕著になります。

MCPアーキテクチャには、次のような潜在的な弱点があります。

プロンプトインジェクション：ユーザーが外部データに悪意のあるプロンプトを埋め込み、AIモデルがそれを指示として誤って解釈してしまいます。
過剰な権限によるアクセス：MCPサーバーはAIモデルに多数のツールを公開する可能性があり、セキュリティ問題が生じた場合の影響範囲（ブラスト半径）が拡大するおそれがあります。
偶発的なデータ漏洩：設定が不適切な実装では、APIキーやデータベースの認証情報などの機密情報がLLMに渡されてしまう可能性があります。
ローカルシステムの改ざん：ローカルMCPサーバーは、他のアプリケーションと同様に、悪意のあるスクリプトなどのローカルシステムの問題に対して脆弱です。さらに、エージェント型AIシステムの下流に有害な影響を及ぼす可能性があるという問題もあります。

これらの問題はいずれも克服できないものではありません。多くの場合、システムの安全性を確保するには確立された対策だけで十分です。人間が介在する仕組み（ヒューマン・イン・ザ・ループ）の導入、機密データに関する厳格な管理の徹底、サーバー攻撃への防御といった対策は、いずれも一般的な手法です。

MCPは、開発者にとって有用かつ人気のあるオープン標準であることが証明されています。LLMベースのアプリケーションにおけるハードコードされたAPIの問題の多くを解消し、開発者のコーディング負担を大幅に軽減します。

今後も、MCPの基盤となるホストとサーバーのアーキテクチャは、ほぼ確実に変わらないでしょう。今後のイノベーションは、マルチステップのワークフロー全体にわたる高度なエージェント機能が中心になるでしょう。

さらに、こうしたエージェント機能の実装が進むにつれてより強固なセキュリティ対策が必要になり、AIシステムがより大規模かつ複雑になるにつれて、特にトランスポートレイヤーにおいてスケーラブルなアーキテクチャが求められるようになるでしょう。

MCPアーキテクチャとは？

MCPアーキテクチャのコンポーネント：ホスト、クライアント、サーバー

ホスト

クライアント

サーバー

MCPアーキテクチャにおけるデータレイヤーとは？

MCPアーキテクチャにおけるトランスポートレイヤーとは？

MCPマルチテナントアーキテクチャとは？

MCPアーキテクチャ図：ステップごとの解説

MCPアーキテクチャと従来のAPIアーキテクチャの違いとは？

MCPアーキテクチャは安全ですか？

MCPアーキテクチャの今後は？