AI MCPのアーキテクチャは、1つの標準プロトコルでAIアプリケーションを外部のデータやツールに接続するクライアント・サーバーモデルです。AIアプリケーションとデータソースの組み合わせごとに個別の連携を構築する（N × M問題）のではなく、データソースごとにMCPサーバーを1つ構築すれば、MCPに対応したどのアプリケーションからでも利用できます。
このアーキテクチャは、ホスト（host、ユーザーが操作するAIアプリケーション）、クライアント（client、ホスト内の接続レイヤー）、サーバー（server、データソースやツールを公開するプログラム）の3つで構成されます。サーバーはツール（tools）、リソース（resources）、プロンプト（prompts）の3つのプリミティブ（primitives）を提供します。AIアプリケーションとデータアクセス層を分けることで、連携を複数のアプリケーションで再利用でき、企業は自社システムのアクセス制御を自ら管理できます。
概要については、AI MCPとは？Model Context Protocol、AIの「USB-C」をご覧ください。
AI MCPアーキテクチャの3つの構成要素
MCPは処理を3つの構成要素に分担します。それぞれの責任範囲を把握することが、保守しやすい連携への第一歩です。
MCPホスト
ホストは、Claude Desktop、CursorやVS CodeなどのIDE、企業独自のエージェントなど、ユーザーが操作するAIアプリケーションです。ホストは言語モデルに接続し、会話のコンテキストとユーザーインターフェースを管理し、モデルの出力に基づいて、どのツール呼び出しを実行し、どれにユーザーの承認が必要かを判断します。また、接続するサーバーごとにMCPクライアントを1つ作成し、管理します。
MCPクライアント
クライアントは、ホスト内で接続を担うコンポーネントです。各クライアントは1つのMCPサーバーと1対1で接続します。この分離は意図的なもので、あるデータソースの認証、エラー、トランスポート設定が他のデータソースに影響しないようにしています。クライアントはJSON-RPC 2.0メッセージを処理し、リクエストごとにプロトコルバージョンと自身の機能（capabilities）を送信します。
MCPサーバー
サーバーは、特定のデータソースやツールをAIアプリケーションに公開するプログラムです。MCPのリクエストを、REST、SQL、GraphQLなど、基盤となるシステム固有の呼び出しに変換します。たとえばPostgreSQLのMCPサーバーは、tools/callリクエストをSQLクエリに変換します。
ローカルサーバー（stdio）は起動したユーザーの権限で動作し、リモートサーバー（Streamable HTTP）は通常はOAuthでクライアントを認可します。MCPのアーキテクチャは2つの層で構成されます。JSON-RPC 2.0メッセージ、ライフサイクル、プリミティブを定義するデータ層（data layer）と、クライアントとサーバー間の通信を担うトランスポート層（transport layer）です。トランスポートには、ローカルサーバーではstdio、リモートサーバーではStreamable HTTPを使用します。
MCPのプリミティブ：ツール、リソース、プロンプト
MCPサーバーは3つのプリミティブを公開します。MCPの仕様では、誰が制御するかによって区別されています。ツールはモデル、リソースはアプリケーション、プロンプトはユーザーが制御します。
| プリミティブ | 制御する側 | 目的 | 例 |
|---|---|---|---|
| ツール | モデル | 必要に応じてデータを取得したりアクションを実行したりする | Jiraチケットの作成、SQLクエリの実行 |
| リソース | ホストアプリケーション | 読み取り専用のコンテキストを提供する | ログファイル、データベースのレコード |
| プロンプト | ユーザー | 定型のワークフローを開始する | 「このプルリクエストをレビュー」テンプレート |
リソース：コンテキスト層
リソースは、ホストがコンテキストとして添付できる読み取り専用のデータです。これにより、モデルは推測ではなく実際のデータに基づいて動作します。
- URIによる識別： 各リソースにはfile:///var/log/syslogやpostgres://db/users/123のようなURIがあり、ホストはどのサーバーでも同じ方法でデータを要求できます。
- MIMEタイプ： リソースはテキストでもバイナリでも構いません。サーバーがMIMEタイプ（text/plain、application/json、image/pngなど）を宣言するため、ホストは内容を正しく処理できます。
- サブスクリプション（任意）： サーバーが対応していれば、クライアントはリソースをサブスクライブし、ポーリングの代わりに、変更時にnotifications/resources/updatedメッセージを受け取れます。
ツール：アクション層
ツールにより、モデルはコードの実行、外部APIの呼び出し、データの変更を行えます。AIが「読む」だけでなく「動く」段階に入る部分なので、ツール設計には明確な制限が必要です。
- 名前、説明、入力スキーマ： すべてのツールは引数のJSON Schemaを宣言します。モデルはツールの名前、説明、スキーマをもとに、いつどのように呼び出すかを判断します。
- 実行の安全性： ツールを実行するのはサーバーです。本番環境のサーバーは、タイムアウト、権限チェック、必要に応じてサンドボックス化を実施すべきです。データを変更する呼び出しについては、ホストがユーザーに承認を求めるべきです。
- 結果とエラー： サーバーは結果をコンテンツ項目（テキスト、画像、構造化データ）として返します。ツール自体が失敗した場合は、結果にisError: trueと説明が付き、モデルは内容を調整して再試行できます。JSON-RPCエラーは、未知のツールなどプロトコル上の問題に使われます。
プロンプト：インタラクション層
プロンプトは、サーバーが提供しユーザーが選ぶ再利用可能なテンプレートで、スラッシュコマンドやメニュー項目として表示されることが多くあります。どのツールとリソースを組み合わせればよいか知らなくても、複雑な作業を始められます。
- 引数： プロンプトは、リポジトリ名や日付範囲など、定義された引数を受け取ります。
- メッセージの組み立て： 呼び出されると、プロンプトは会話用のメッセージを1つ以上返し、リソースをコンテキストとして埋め込むこともできます。
- ディスカバリー： クライアントはprompts/listで利用可能なプロンプトを一覧表示し、ユーザーにすぐに使えるワークフローのメニューを提示します。
AI MCPアーキテクチャ図
AI MCPアーキテクチャ図（AI MCPダイアグラム）は、リクエストがユーザーから外部システムへ届き、結果が戻ってくるまでの経路を示します。この図のポイントは、1つのホストがサーバーごとに別々のクライアントを動かしていることです。
要約すると、ホストが利用可能なツールの一覧をモデルに渡し、モデルがツールを選び、ホストが対応するクライアントを通じて呼び出しを送り、サーバーが外部システムに対して実行して構造化された結果を返します。各段階については、次のライフサイクルで説明します。
MCP接続のライフサイクル：構成要素の接続方法
MCPはステートレス（stateless）なリクエストモデルを採用しており、各リクエストには処理に必要なプロトコルバージョンとクライアントの機能が含まれます。クライアントは、リクエストを送信する前に、サーバーが対応するバージョンと機能を確認できます。以前のバージョンとは異なり、現在のプロトコルでは接続単位の初期化ハンドシェイクは不要で、プロトコルレベルのセッションも維持しません。
1. ディスカバリー
クライアントはリクエストを送信する前にserver/discoverを呼び出し、サーバーが対応するプロトコルバージョン、サーバーの識別情報、提供する機能を確認できます。これにより、クライアントは互換性のあるプロトコルバージョンを選択できます。続いて、クライアントはtools/list、resources/list、prompts/listで利用可能な機能を問い合わせます。サーバーは、各項目の名前、説明、ツールの場合は入力スキーマを含む一覧を返します。
2. 運用
クライアントは、選択したプロトコルバージョンと自身の機能を、io.modelcontextprotocol/protocolVersionとio.modelcontextprotocol/clientCapabilitiesを使って_metaに含め、リクエストを送信します。また、io.modelcontextprotocol/clientInfoで自身を識別することが推奨されます。
モデルがツールを選ぶと、ホストは対応するMCPクライアントを通じてtools/callでリクエストを送信します。また、resources/readでデータを取得することもできます。サーバーは各リクエストを処理し、結果のメタデータに自身の識別情報を含めて結果を返します。
継続的な変更通知が必要な場合、クライアントはsubscriptions/listenでオプトインできます。このストリームは、ツール・プロンプト・リソースの一覧の変更通知と、リソースのサブスクリプションに対応しており、従来のresources/subscribeとresources/unsubscribeメソッドに代わるものです。データベースのタイムアウトなどツール実行の失敗はisError: trueの結果として返され、モデルが対処または再試行できます。JSON-RPCエラーは、プロトコルレベルまたはリクエストレベルの問題を示します。
3. 終了
MCPには終了専用のメッセージも、終了すべきプロトコルレベルのセッションもありません。通信が完了すると、クライアントとサーバーは基盤となるトランスポートを閉じます。stdioでは、クライアントがサーバーの入力ストリームを閉じ、サーバープロセスが終了できるようにします。Streamable HTTPでは、クライアントが該当するHTTP接続またはレスポンスストリームを閉じます。サーバーは、必要に応じてデータベース接続やファイルロックなどの一時的なリソースを解放すべきです。
後方互換性： 古いMCPサーバーやクライアントでは、以前のプロトコルバージョンで定義されたinitialize / notifications/initializedハンドシェイクが引き続き使われている場合があります。
アーキテクチャのトレードオフ
ホスト・クライアント・サーバーの分離は、複数のAIアプリケーションが同じシステムを必要とする場合に効果を発揮しますが、コストもあります。
- 構成要素が増える： サーバーごとに、デプロイ、監視、更新が必要なプロセスやサービスが増えます。1つのアプリケーションが1つの安定したAPIを呼ぶだけなら、直接連携のほうがシンプルな場合が多くあります。
- コンテキストの消費： 各ツールの名前、説明、スキーマはモデルに渡されます。多くのツールを持つサーバーを複数接続すると、コンテキストウィンドウを消費し、ツール選択の精度が下がることがあるため、用途に必要なツールだけを公開しましょう。
- 信頼境界： サーバーのツール結果はそのままモデルのコンテキストに入ります。サードパーティ製サーバーは検証してバージョンを固定し、各サーバーには最小権限のアカウントを与えましょう。
事例：1つのホストで複数の業務システムを利用
Haposoftは、Hapo ERP（ファスナーメーカー向けERP）、Hapo SMS、Hapo OKRなど自社製品向けにMCPサーバーを構築しています。各システムにそれぞれサーバーがあり、1つのホストであるClaudeが別々のクライアントを通じてすべてに接続します。ユーザーは1か所から、製造オーダーや在庫の確認、営業パイプラインや支払い状況の確認、OKRのチェックイン提出が行えます。サーバーはリモートで稼働し、各ユーザーがOAuthでサインインするため、アクセスはそのユーザー自身の権限に従います。レコードの削除や承認を行うツールは公開しておらず、データの変更には必ず確認が必要です。
AI MCPアーキテクチャに関するよくある質問
MCPホストとMCPクライアントの違いは？
ホストは、IDEやチャットアプリなど、ユーザーが作業するAIアプリケーションです。クライアントは、そのホスト内で1つのMCPサーバーとの接続を担うコンポーネントです。ホストはインターフェース、モデル、承認を管理し、各クライアントは担当するサーバーとの通信を担います。
1つのMCPホストで複数のサーバーに接続できますか？
はい。ホストはサーバーごとにクライアントを1つ作成するため、1つのアプリケーションから複数のデータソース（たとえばローカルのファイルシステム用サーバーとリモートのPostgreSQL用サーバー）に同時に接続できます。
AI MCPアーキテクチャ図はどう読めばよいですか？
リクエストの流れを追いましょう。ホストはクライアントを通じてtools/callやresources/readなどのリクエストを送り、サーバーは構造化された結果を返します。図では、AIアプリケーション（ホストとモデル）とデータアクセス層（サーバーとその先のシステム）が分かれています。
ツール、リソース、プロンプトのどれを使うべきですか？
モデル自身にアクションの実行や必要に応じたデータ取得を判断させたい場合はツール、アプリケーション側で既知のコンテキストを添付したい場合はリソース、ユーザーが繰り返し使える定型ワークフローが必要な場合はプロンプトを使います。
まとめ
AI MCPのアーキテクチャは、AIアプリケーションを外部のデータやツールに接続するための標準的な方法を提供します。ホストがユーザーとモデルのやり取りを管理し、クライアントがそれぞれ1つの接続を担い、サーバーがツール、リソース、プロンプトを公開します。この分離により、連携を複数のAIアプリケーションで再利用でき、自社システムのアクセス制御も維持できます。仕様の詳細は、Model Context Protocolの公式ドキュメントをご覧ください。
自社システム向けのMCPサーバーをご検討中ですか？クラウドでもオンプレミスでも、安全なMCP連携についてHaposoftのAI MCPチームにご相談ください。
