Model Context Protocol（MCP）とは何か — AIエージェントと世界をつなぐ「USB-C」の全貌【2026年版】

17ヶ月でAI業界の配線図を書き換えた「AIのUSB-C」

2025年11月、Anthropicが静かに公開した1つのGitHubリポジトリが、わずか17ヶ月でAI業界の配線図そのものを書き換えました。月間9,700万回のSDKダウンロード、1万を超えるアクティブサーバー、そして2025年12月にはLinux Foundation傘下のAgentic AI Foundation（AAIF）の創設プロジェクトに——これがLinux FoundationがAAIFの設立を発表した時点のMCPの現在地です。

Model Context Protocol、略してMCPという名前を、この半年で何度耳にしたでしょうか。ChatGPTにもClaudeにもCursorにもGeminiにも組み込まれ、Shopifyとcommercetoolsは自社のコマース機能をMCPサーバー経由で提供し始めました。それでも「で、結局これは何なのか」という問いに、すっきり答えられる記事はまだ多くありません。本稿では、MCPを技術仕様としてだけでなく、エージェンティックコマースの土台として整理していきます。

Model Context Protocol（MCP）とは何か

MCPは、AnthropicがOSSとして公開した、AIアプリケーションと外部ツール・データソースを接続するためのオープン標準プロトコルです。公式ドキュメントでは「AI向けのUSB-C」と表現されており、この比喩が示す通り、接続口を1つに揃えることで「どのAIからでも、どのツールやデータへも」アクセスできるようにする共通規格です。

Anthropicの公式アナウンスは、MCPを「AI搭載ツールとデータソースの間に、安全で双方向の接続を構築するためのオープン標準」と定義しています。ここで重要なのは、MCPは特定のLLMに紐づくものではないという点です。仕様上はモデル非依存であり、Claudeでも、GPTでも、Geminiでも、同じサーバーを呼び出せます。

実際、2025年3月26日にはOpenAIがMCPのサポートを公式表明しました。AnthropicのライバルであるOpenAIが、Anthropic発の仕様を自社のAgents SDK・Responses API・ChatGPTデスクトップに取り込むという事件は、TechCrunchが「ライバルの標準を採用した」と報じたように、MCPが特定ベンダーの囲い込みではない証でした。

なぜMCPが必要なのか — N×M問題という配線の悪夢

結論から言えば、MCPが解こうとしているのはN×M問題です。AIモデルがN個あり、接続したいツールやデータソースがM個あるとき、それぞれを個別に繋ぐと必要な統合の数はN×Mになります。モデルが5つ、ツールが20個なら、100通りの組み合わせを誰かが書き、メンテナンスし続ける必要があります。

MCPはこれをN+Mに圧縮します。モデル側はMCPクライアントを1回実装すればすべてのMCPサーバーと話せます。ツール側はMCPサーバーを1回実装すればすべてのMCPクライアントから呼ばれます。足し算の計算量で済むということは、エコシステム全体の開発コストが桁違いに下がるということです。

MCPの発案者であるDavid Soria ParraとJustin Spahr-Summersがプロトタイプを作った背景も、この「配線の悪夢」への苛立ちでした。2024年7月、Davidは自分のIDEとClaude Desktopの間で手動でコンテキストをコピペし続けることに限界を感じ、6週間の試作でMCPの原型を作り上げます。個人のフラストレーションが、AIインフラのデファクトスタンダードを生んだという点は、単なる逸話以上の意味を持っています。現場の不便から生まれたからこそ、仕様が実用志向で削ぎ落とされているのです。

MCPアーキテクチャ — Host、Client、Serverの三層構造

MCPのアーキテクチャは、Host、Client、Serverという3つの役割に分かれます。Hostは人間が触るAIアプリケーション本体で、Claude Desktop、Cursor、VS Code、ChatGPTデスクトップなどが該当します。Hostは内部でMCPサーバーごとに1つずつMCPクライアントを生成し、それぞれがサーバーと1対1の接続を維持します。

MCP Server側が提供するのは、いわば「道具箱」です。公式仕様では3つのプリミティブが定義されています。Tools（実行可能なアクション）、Resources（参照可能なコンテキストデータ）、Prompts（再利用可能なテンプレート）。たとえばGitHubのMCPサーバーなら、「プルリクエストを作る」というToolと、「README.mdを読む」というResourceを提供するイメージです。

逆にClient側もサーバーへ能力を提供します。SamplingはサーバーがホストのLLMに推論を依頼する仕組みで、これによってサーバー側はモデル非依存のまま複雑なワークフローを組めます。Elicitationはサーバーがユーザーに追加入力を求める機構で、Loggingはサーバーがクライアント側にログを流す仕組みです。

データ層のベースはJSON-RPC 2.0で、リクエスト・レスポンス・通知の3種類のメッセージをやり取りします。トランスポートは大きく2種類です。ローカル実行ならstdio——サブプロセスの標準入出力を使う最も軽量な方式。リモート実行ならStreamable HTTPで、HTTP POSTをベースに必要に応じてSSEを使うストリーミング送受信が可能です。かつてはHTTP+SSEのみの方式でしたが、Streamable HTTPへ統一されました。

層	役割	具体例
Host	ユーザー接点となるAIアプリ	Claude Desktop / Cursor / VS Code / ChatGPT Desktop
Client	Host内で各Serverと1対1接続	Host内部のMCPクライアント実装
Server	Tools/Resources/Promptsを提供	GitHub Server / Postgres Server / Shopify MCP

この三層構造のシンプルさが、MCPが急速に広まった最大の理由です。公式のアーキテクチャドキュメントを見ると、仕様の大部分が10ページ程度に収まっていることが分かります。複雑さで殴るのではなく、最小限の共通語彙を決めて残りはエコシステムに委ねる——この設計判断が、OpenAIやGoogleのような競合すら引き寄せました。

MCPが「USB-Cの瞬間」を迎えるまで — 誕生からLinux Foundation移管まで

MCPの歴史はまだ1年半しかありません。しかし、その1年半の濃度は異常です。

最初の公開は2024年11月25日。Anthropicは自社発表と同時に、Google Drive、Slack、GitHub、Git、Postgres、Puppeteerの6つの参考実装サーバーを公開しました。このタイミングでBlock、Apollo、Zed、Replit、Codeium、Sourcegraphが早期パートナーとして名を連ねており、開発者向けツール業界からの反応は即座でした。

年明けからはコミュニティ主導でSDKが拡張されていきます。Python、TypeScriptに続き、Java、C#、Kotlin、Swift、Ruby、Goのオフィシャル実装が登場。Smitheryやmcp.soといったサードパーティのサーバーレジストリも立ち上がり、エコシステムが自己増殖していきました。

転機は2025年3月です。OpenAIのSam AltmanがTwitter上でMCPのサポートを発表し、Agents SDK、Responses API、ChatGPTデスクトップアプリがMCP対応を表明しました。続けてGoogle Cloudが自社サービスへのMCP対応を公言し、MicrosoftもGitHub CopilotとCopilot Studio、VS CodeでMCPをサポートします。AIの「御三家」がそろって同じ規格に乗ったというのは、業界の歴史を振り返ってもそうそう起きないイベントです。

そして決定打が2025年12月9日。Anthropicは自らMCPをLinux FoundationのAgentic AI Foundation（AAIF）へ寄贈すると発表しました。AAIFの創設プラチナメンバーには、AWS、Anthropic、Block、Bloomberg、Cloudflare、Google、Microsoft、OpenAIの8社が名を連ねています。同時に公表された統計は衝撃的でした。月間9,700万回のSDKダウンロード、1万を超えるアクティブサーバー、そしてChatGPT・Claude・Cursor・Gemini・Microsoft Copilotを含む主要AIプラットフォーム全体でのファーストクラス対応。

この「プロジェクトを手放す」という意思決定こそが、MCPを単なるAnthropic製の仕様から、業界横断のニュートラルなインフラへと変えた瞬間でした。2026年4月2〜3日にニューヨークで初のMCP Dev Summit North Americaが開催され、95を超えるセッションが行われたのは、この移管が象徴的に結実した光景と言っていいでしょう。

エージェンティックコマース・スタックにおけるMCPの位置づけ

ここからが本題です。コマース業界にとって、MCPは何を意味するのでしょうか。

結論を先に言うと、MCPはコマースプロトコルではありません。MCPはあくまでAIエージェントがツールやデータにアクセスするための土台——配管層です。そして商取引の業務フローやお金の動きを扱うためには、この上にもう一段階、コマース特化のレイヤーが必要になります。この区別を曖昧にしたまま「MCPさえあればエージェント経由で物が売れる」と解釈するのは、典型的な誤読です。

commercetoolsの整理を借りると、スタックは以下のように積み上がります。

層	主なプロトコル	役割
決済承認	AP2（Google + Mastercard/Visa/PayPal）	エージェント決済の暗号学的な「mandate」
コマースワークフロー	ACP（Stripe + OpenAI） / UCP（Shopify + Google）	商品検索・カート・チェックアウト・注文
エージェント間通信	A2A（Google）	エージェント同士の水平的な協調
ツール・データ接続	MCP（Anthropic→AAIF）	AIからツール・データへの垂直な接続

MCPは最下層の垂直方向の接続を担当し、A2Aは水平方向のエージェント協調を担当します。ACPとUCPは商取引のワークフローをAIサーフェス上で標準化するレイヤーで、AP2は決済の信頼性を担保するレイヤーです。これらは競合ではなく補完関係にあり、本格的にエージェンティックコマースに取り組む事業者は、通常この中の複数を組み合わせて実装することになります。プロトコル全体の整理はエージェンティックAIプロトコル一覧の解説記事で俯瞰できます。

実例を見るとこの階層構造がよく分かります。Shopifyは現在、Dev MCP（開発者向け）、Storefront MCP（商品検索・カート操作）、Checkout MCP（決済フロー）という複数のMCPサーバーを提供しており、さらにその上でUCPにも対応しています。MCPで「どの商品データをどうやって取ってくるか」を解決し、UCPで「どうチェックアウトに繋げるか」を解決する、という明確な役割分担です。commercetoolsも同様に、Commerce MCPをエージェント対応インフラとして位置づけ、UCPとの組み合わせを推奨しています。Shopifyの4種MCPサーバーの詳細や実装上の意味合いは、Commerce MCPの実装ガイドで踏み込んで解説しています。

ここで押さえておきたいのは、MCPはエージェンティックコマース全体の基礎工事にあたるということです。エージェンティックコマース完全ガイドで示した通り、AIエージェント経由の商取引はもはや実験段階ではなく、複数のプロトコルが具体的なユースケースごとに役割を分担し始めています。MCPを理解することは、この分担表の読み方を覚えることでもあります。

プロダクション利用を支える認証とスケーラビリティ

MCPを「ローカルPCでClaude Desktopが使う便利機能」と捉えていると、2026年の現場像を見誤ります。2025年以降の主戦場は、リモートで認証付き、エンタープライズに導入されるプロダクションMCPです。

認証面での大きな転換点は2025年3月のスペック更新でした。MCPの公式仕様は、Streamable HTTPトランスポートにおける認可フレームワークとしてOAuth 2.1を採用しました。PKCE、Dynamic Client Registration、.well-knownメタデータによるディスカバリといった現代的な要素を全て取り込んだ形で、Auth0の解説記事が詳しいように、この変更はセキュリティ面でのプロダクション投入の前提を整えました。

エンタープライズ現場では、これに加えてSSO、監査ログ、ゲートウェイなどの運用要件が必要になります。ここは仕様本体ではなく拡張として扱う方針がMCPコミュニティの合意事項で、2026年のロードマップでは「中核仕様をシンプルに保ちつつ、エンタープライズ要件は拡張で解決する」という設計判断が明確に示されました。

スケーラビリティ面では、Streamable HTTPのステートレス化が鍵を握ります。現在のMCPはセッション指向で設計されており、同じクライアント・サーバー間で状態を保持します。これは便利な反面、水平スケールの妨げになります。2026年のロードマップでは、ステートレスなStreamable HTTPパターンの標準化が優先課題として挙げられており、ロードバランサ配下で複数インスタンスに分散できる本格的な商用ワークロードへの対応が進行中です。

MCPを始めるには — SDK、レジストリ、参考実装

MCPに実際に触れる方法は、開発者にとって驚くほど整っています。

最も手軽な入り口は、Claude Desktopを起動して設定ファイルに既存のMCPサーバーを1つ追加することです。たとえばGitHubのサーバーを設定すれば、その瞬間からClaudeが自分のリポジトリを読み書きできるようになります。この「1ファイル編集でAIの能力が拡張される」という体験がMCPの入門として最も効果的です。

サーバーを自分で作る場合は、公式SDKの選択肢が豊富です。PythonとTypeScriptが最初期から存在し、現在はJava、C#、Kotlin、Swift、Ruby、Goも公式にサポートされています。GitHubのmodelcontextprotocol Organizationに参考実装とSDKが集約されており、inspectorツールを使えばサーバーの挙動をGUIでデバッグすることもできます。

既存のサーバーを探す場合は、公式のregistry.modelcontextprotocol.ioのほか、mcp.so、Smithery、Glama、PulseMCPといった第三者レジストリから選べます。2026年4月時点でmcp.soは約19,687件、Glamaは約18,042件のサーバーを掲載しており、GitHub・Slack・Postgres・Stripe・Shopify・Notion・Linearなど、主要なSaaSはほぼ網羅されています。

コマース文脈に絞れば、Shopifyの開発者向け公式ドキュメントがDev MCP・Storefront MCP・Checkout MCPの具体的な使い方を解説しています。commercetoolsのCommerce MCPローンチ記事も、エンタープライズEC向けにMCPをどう位置づけるかという観点で非常に参考になります。

2026年ロードマップと「溝を越えた」MCPの次の課題

2026年3月9日に公表されたMCPの2026年ロードマップは、4つの優先領域を示しています。トランスポートの進化とスケーラビリティ、エージェント間通信、ガバナンス、エンタープライズ対応です。

特に注目すべきは、Tasksプリミティブの成熟（SEP-1686）です。これまでのMCPは基本的に同期的な要求応答モデルでしたが、Tasksが導入されれば、長時間実行されるジョブや非同期の結果返却がプロトコルレベルでサポートされます。エージェンティックコマースの文脈で言えば、「3日後に価格が下がったら自動で買う」といったシナリオを、セッションを張り続けずに実現できるようになります。

認可方面では、DPoP（SEP-1932）とWorkload Identity Federation（SEP-1933）という2つのSEPが進行中です。前者はトークンの盗難耐性を高める仕組みで、後者はサービス間認証を現代的なアイデンティティ連携に合わせる試みです。いずれも企業利用での採用を後押しする変更で、「MCPはもはや個人開発者の玩具ではない」という方向性が明確に打ち出されています。

一方で、ロードマップはやらないことも明記しています。今期は新しい公式トランスポートを追加しない、エンタープライズ拡張は仕様本体に取り込まない、といった方針です。これは成熟したOSS仕様によくある判断で、「足すより削ぐ」ことで中核の安定性を守ろうという意思表明として読めます。

まとめ — 配管からインフラへ

冒頭の問いに戻りましょう。Model Context Protocolとは何か。

技術的には、JSON-RPC 2.0の上に構築された、Host・Client・Serverの三層モデルからなるオープンな接続プロトコルです。エコシステム的には、Anthropicが生み出し、OpenAI・Google・Microsoftが乗り、Linux Foundation AAIFに寄贈された業界横断インフラです。そしてコマース的には、エージェンティックコマース・スタックの最下層——データとツールへの配管を担う基礎工事です。

2024年11月から2026年4月までの17ヶ月で、MCPは個人の苛立ちから生まれたサイドプロジェクトから、ChatGPTもClaudeもShopifyもcommercetoolsも採用する事実上の標準へと変わりました。そしていま、仕様の次の章はプロダクション運用・エンタープライズ・スケーラビリティへと向かっています。

コマース事業者が2026年に決めるべきことは、「MCPを理解するかどうか」ではなく、「MCPをどのコマースプロトコルと組み合わせて採用するか」です。MCPは配管であり、ACPもUCPもAP2もその上に載る業務層だという構造を掴めば、あとは自社のユースケースに合わせてレイヤーを選ぶだけです。配管は決まりました。次は、そこに何を流すかの選択の時間です。