MCP時代:Model Context Protocolは2026年のAIアプリをいかに静かに作り変えたか

Anthropicは2024年末にModel Context Protocolを公開しました。ほとんどの人は「また新しい標準か」とファイルに放り込んで忘れました。18か月後の今、MCPはAIアプリスタックの事実上の配管レイヤーです。Claude CodeはMCPファーストです。Cursorは1つのセッションで複数のサーバーを動かします。Linear、Figma、Notion、GitHub、Slack、Stripeはみな公式サーバーを出荷しています。プロトコルは勝ちました。

これは実践入門と、プロトコルの現状レポートです。MCPがワイヤ上で何なのか、なぜ先行する標準に勝てたのか、本番の定番サーバー、どう使うべきか、そしてどこでまだ転ぶのかを扱います。

MCPは、ようやくぴったり合ったケーブル

Model Context Protocolは、あらゆるAIクライアントが標準サーバーを通じてあらゆるツールやデータソースと話せるようにします。MCP以前は、統合はすべて一点物でした。各クライアントが独自のツール形式を発明し、各ツールがクライアントごとにカスタムアダプターを書いていました。組み合わせコストは壊滅的で、多くのビルダーは諦めて少数の統合をハードコードしました。

MCPはそれを一気に畳みました。サーバーを一度作れば、どのMCPクライアントでも使えます。クライアントを一度作れば、どのMCPサーバーにも届きます。適切な時に適切なプリミティブを、オープンに運営する。Anthropicがプロトコル作業を担いながら、標準を所有はしていません。

MCPがワイヤ上で実際に何なのか

MCPは、トランスポートの上で動くJSON-RPCと、少数の標準プリミティブです。サーバーはresources(モデルが読めるデータ)、tools(呼び出せるアクション)、プロンプト(ユーザーが呼び出せるテンプレート)を公開します。クライアントはどのサーバーに対しても同じメソッド、つまりlist、read、callで話します。抽象化はこれで全部です。

JSON-RPCは退屈で、よく理解されていて、curlでデバッグでき、これまで作られたあらゆるファイアウォールを通ります。プリミティブの分割は、サーバーに画一的なスキーマを強いることなく、モデルがサーバーにできることを推論するのに十分な構造を与えます。

3つのトランスポートとその重要性

MCPは3つのトランスポートで出荷されます。stdio、HTTP plus SSE、WebSocketsです。stdioはサーバーをクライアントの子プロセスとして動かし、Claude Desktopのようなデスクトップクライアントのデフォルトです。HTTP plus SSEはサーバーをリモートサービスとして動かし、クライアントがポーリングとストリーミングを行います。クラウドMCPサーバーに適した形です。WebSocketsは、リモートサーバーから全二重通信が必要なまれなケースをカバーします。

トランスポートは主にデプロイの選択であり、機能の選択ではありません。同じサーバーロジックが3つすべてで動きます。チームはローカルでstdioを使ってプロトタイプを作り、プロトコル層を書き直さずに、認証ゲートウェイの背後でHTTP plus SSEとして出荷できます。

先行する標準が負けた場所で、MCPが勝った理由

ChatGPTプラグイン、function-callingの仕様、OpenAPI-for-LLMsは、いずれもエージェントツール標準になろうとしました。3つとも失速しました。MCPが勝ったのは、適切な時に、適切なガバナンスで、適切なプリミティブを選んだからです。

ChatGPTプラグインは1つのクライアントと1つの課金モデルに縛られ、マニフェストはステートレスなHTTPエンドポイントとOpenAPI仕様を前提にしていましたが、それをきれいに公開できる実際のプロダクトはほとんどありません。各ラボのfunction-calling仕様は、標準の顔をしたベンダー独自形式でした。OpenAPI-for-LLMsはドキュメント形式を実行時の契約に後付けしようとし、インピーダンスミスマッチに潰されました。

正しいプリミティブ:プラグインではなくサーバー

統合を、ステートレスなプラグインマニフェストではなく、型付きの契約を公開する長時間稼働のサーバーにしたMCPの選択が、他のすべてがそこから導かれるアーキテクチャ上の判断です。サーバーはデータベース接続を保持し、リソースをキャッシュし、認証トークンを管理し、レスポンスをストリーミングし、クライアントを壊さずに更新を出荷できます。ステートレスなプラグインにはそのほとんどができません。本物の統合には、状態、リトライ、可観測性、レート制限の処理が必要です。サーバーはそれを担います。プラグインはそれと戦います。

正しいタイミング:ツール利用の後、エージェントスタックの前

MCPが出荷されたのは、ビルダーたちがツール利用が重要かどうかの議論をやめ、リリースのたびに書き直さずに10個のツールを1つのエージェントにどう配線するかを議論し始めた、まさにその時でした。ツール利用は決着済みでした。次の問題はオーケストレーションでした。MCPはオーケストレーション層にきれいな抽象化を与えました。

ガバナンスも効きました。Anthropicは仕様をオープンソース化し、GitHub組織を公開し、初日から外部コントリビューションを受け入れ、他のラボが許可なくクライアントを実装することを認めました。2026年半ばまでに、OpenAIはAssistantsスタックでMCPサポートを出荷しました。GeminiはGemini API経由でサポートしています。この大きなテントが、サイドプロジェクトを標準に変えました。

本番で稼働する定番MCPサーバー

短いリストが大半の仕事をこなします。2026年のエージェントスタックの多くは、この9つの何らかの組み合わせです。

Figmaはフレーム、コンポーネント、変数、レイヤーツリーを公開するので、モデルは開発者が仕様書を読むようにフレームを読みます。Linearはissue、プロジェクト、サイクルを公開し、Claude Codeをプロジェクトを理解するコーダーに変えます。Notionはページ、データベース、ブロックを公開し、万能のコンテキストストアになります。GitHubはリポジトリ、issue、プルリクエスト、actionsを公開する、定番のコードコンテキストの入口です。Slackはチャンネル、スレッド、検索を公開します。Stripeは顧客、サブスクリプション、課金、メトリクスを公開し、財務や運用のエージェントが帳簿を読む手段です。

Postgresはスキーマ、テーブル、クエリを、読み取り専用または読み書きのスコープで公開します。Filesystemはサンドボックス化されたディレクトリを公開し、Claude Codeがリポジトリを読み書きする手段です。BrowserbaseはホスティングされたChromiumの群れをMCP経由で公開し、エージェントがインフラを管理せずにブラウザを操作する手段です。9つのサーバーで、エージェント作業の9割です。

主役を張るMCPファーストのクライアント

Claude Codeは定番のMCPクライアントです。すべての統合がMCPサーバーです。ツールの追加は、設定ファイルを編集してサーバーのバイナリかURLを指すだけです。Claude Desktopは同じモデルに、ワークスペースごとにサーバーを設定するUIを付けて出荷しています。Cursorは2026年初めにMCPサポートを追加し、今では1つのセッションで複数のサーバーを動かします。だからコードを編集する同じCursorのペインが、Figmaのフレームを引っ張り、Linearのissueを起票し、Postgresにクエリを投げられるのです。

Continue.devはMCPファーストで出荷しています。JetBrains AIはMCPサポートを追加しました。ZedもMCPを出荷しました。真剣に扱われたいIDEやAIクライアントは、今やすべてMCPサポートを出荷しており、MCPの話がないプロダクトは古く感じられ始めています。

デザイナーがMCPで実際にやるべきこと

Figmaのスクリーンショットはやめましょう。ツールをMCPワークスペースとして公開するのです。Figma MCPサーバーは、画像から推測したピクセル値ではなく、本物のフレーム座標、本物の変数、本物のコンポーネントインスタンスをモデルに渡します。

さらに大きな一手は、単一のMCPワークスペースを作ることです。Figma、Notion、そしてデザイントークンのリポジトリを、3つのサーバーとしてClaude Codeに配線します。「この仕様どおりにコンポーネントを作って」と頼む同じプロンプトが、Figmaのフレームを読み、Notionから根拠を引き、トークンファイルを参照し、コードを書きます。デザインシステムが、AIワークフローの中で本当に1つの連続した成果物として振る舞うのは、これが初めてです。同じパターンはClaude Skillsにも当てはまり、Skillがペルソナで、MCPがワークスペースです。

ビルダーがMCPで実際にやるべきこと

チームが持つ社内ツールすべてに、社内MCPサーバーを出荷しましょう。Claude Codeをそこに向けます。コードを書く同じエージェントが、運用を始めるのを眺めてください。2026年に勝つパターンは「Xのための AIアシスタント」ではありません。「チームが使うすべてのツールをMCPサーバーとして公開し、1つのクライアントがオーケストレーションする」です。

認証モデルで四半期を失うことなくMCPをチームのツールに配線したい、あるいは本番で耐える社内MCPサーバースタックを出荷したいなら、Brainyを雇ってください。ClaudeBrainyはMCPサーバーのテンプレートとプロンプトライブラリを出荷し、AppBrainyは、エージェントにスクリーンショットではなく本物のワークスペースを共有させたいチーム向けに、フルのプロダクト構築を出荷します。

構築は華やかではありません。社内MCPサーバーの多くは、既存APIの薄いラッパーに、認証と、リソースとツールのリストを足したものです。数百行のコードで、チームのデプロイダッシュボード、エラートラッカー、課金コンソール、管理画面が、エージェントの使える新しいツールになります。10個のサーバーが揃えば、エージェントはチャットボットではなく、チームメイトです。

MCPがまだ負けている場所

マルチサーバーオーケストレーションのレイテンシ、認証の複雑さ、モバイルの物語の欠如。この3つがMCPがまだ転ぶ場所で、これらを隠すデモは無視すべきデモです。

マルチサーバーオーケストレーションのレイテンシは本物です。1ターンでFigma、Notion、Postgresに触れるプロンプトは、モデルが答えるのに十分なコンテキストを得るまでに3往復を払うことがあり、遅いトランスポートでは累積の待ち時間が5秒を超えます。キャッシュは効きます。コネクションプーリングも効きます。しかしレイテンシが消えることはありません。

認証の複雑さが2つ目の穴です。MCPは認証を標準化していません。各サーバーが独自のモデルを選びます。OAuth、APIキー、スコープ付きトークン、時には何もなしです。15個のサーバーを1つのクライアントに配線すれば、15個の認証情報ストア、15個のリフレッシュポリシー、15個の監査証跡が生まれます。顧客データのサーバーが顧客以外のコンテキストに漏れる最初の瞬間まで、ほとんどのチームはこれを過小評価します。

モバイルの物語は欠けています。MCPは、ローカルプロセスを起動し、ネットワーク接続を保持し、サーバーのライフサイクルを管理できる長時間稼働のクライアントを前提にしています。モバイルの実行モデルはそのどれでもありません。2026年半ばの時点で、使えるMCP-on-iOSはありません。いくつかのチームがリモート専用プロファイルに取り組んでいますが、プロトコルはまだそこに達していません。

誇大なMCPデモが隠す3つの失敗モード

2026年のMCPの後悔の多くは、同じ3つの穴に行き着きます。

1つ目。認証ごまかしデモ。発表者は顧客のCRMにつながれたサーバーを見せ、エージェントが答え、拍手。認証はデモアカウントの個人トークンでした。同じ構成をマルチテナントの本番システムに向けるには、スコープ付き認証情報、OAuthフロー、テナント分離で認証を作り直す必要があります。対策:サーバーを出荷した後ではなく、出荷する前に認証モデルを決めること。

2つ目。ローカル限定デモ。サーバーがローカルのファイルシステムと個人のデータベースを使ってstdioで動くので、発表者のノートPCではすべてが動きます。HTTP plus SSEと共有認証情報が必要なチームには、何も出荷できません。対策:stdioでプロトタイプを作り、認証ゲートウェイの背後でHTTP plus SSEとして出荷し、チームが信頼する前にデプロイの流れをテストすること。

3つ目。単一サーバーデモ。エージェントが1つのサーバーを見事に使い、発表者はマルチサーバーオーケストレーションを設定1行の話のように扱います。本番では、2つ目と3つ目のサーバーがレイテンシ、認証の衝突、プロンプトの混乱をもたらします。対策:サーバーのセットをリストではなくシステムとして設計すること。境界をドキュメント化すること。

役割別の最初の一手

チームの各役割にとって、MCPの最初の一手は違います。作業は均等には分配されません。

パターン。デザイナーとフロントエンド開発者がワークスペースの組み立てを担います。バックエンド開発者がサーバーの契約と認証モデルを担います。創業者がレーンを選びます。

FAQ

Model Context Protocolとは何ですか?

MCPは、あらゆるAIクライアントが標準サーバーを通じてあらゆるツールやデータソースと話せるようにするオープンプロトコルです。サーバーはresources、tools、promptsを公開します。クライアントはstdio、HTTP plus SSE、WebSocketsの上でJSON-RPCを話します。Anthropicは2024年末に仕様を公開し、2026年半ばまでに、事実上のエージェントツール統合標準になりました。

MCPはClaude専用ですか?

いいえ。Cursor、Continue.dev、JetBrains AI、Zed、OpenAIのAssistantsスタックはすべて、MCPをサポートしています。GeminiはGemini API経由でサポートしています。Anthropicはプロトコルを公開しましたが、所有してはいません。

自分でMCPサーバーを書く必要はありますか?

定番ツールについては、おそらく不要です。Figma、Linear、Notion、GitHub、Slack、Stripe、Postgres、Filesystem、Browserbaseは、いずれも公式または定番のサーバーを出荷しています。自作するのは、社内ツール、カスタムデータベース、独自APIのときです。社内MCPサーバーの多くは、数百行のコードと認証モデルです。

MCPはツール利用とどう違いますか?

ツール利用は、構造化された入力と出力で関数を呼び出すという、モデル側の能力です。MCPは、どのクライアントからでもツールをどう発見し、記述し、呼び出すかを定義するプロトコルです。ツール利用はエンジンで、MCPは配線です。クリーンに呼べるAPIがない場合の3本目の柱は、コンピュータ操作エージェントの入門で扱っています。

MCPが意味をなさないのはどんなときですか?

ツールが1つ、クライアントが1つで、すでに動いているハードコードの統合があるときです。勝ち筋は、マルチツール、マルチクライアントの世界にあります。1つのエージェントと1つのAPIなら、素のツール利用で十分です。

MCPが本当に解き放つ転換

MCPはより賢いエージェントではありません。エージェントがついにワークスペースを共有できるようにしたプロトコルであり、そのワークスペースを自らの中核サーフェスとして扱うプロダクトが、次のラウンドを制します。

ほとんどのチームは、いまだにAI統合をプロダクトに後付けする機能として扱っています。抜け出しつつあるチームは、AIクライアントとMCPサーバー群をワークスペースとして扱い、プロダクトはその縁に現れるものだと考えます。前者はチャットタブをもう1つ出荷します。後者は、チームが実際に使うツールを出荷します。同じ転換は、AIコードエディタ比較やビルダーのためのClaude 4.7の分解記事にも現れています。

あなたのスタックに今四半期MCPの話がなければ、顧客が使うエージェントはあなたを素通りします。あれば、そのエージェントはあなたのプロダクトをチームメイトのように扱い始めます。ワークフローを選び、サーバーを出荷し、ワークスペースを配線しましょう。

認証モデルで四半期を失うことなくMCPをチームのツールに配線したい、あるいは本番で耐える社内MCPサーバースタックを出荷したいなら、Brainyを雇ってください。ClaudeBrainyはSkillパックとMCPサーバーのテンプレートを出荷します。AppBrainyは、エージェントにスクリーンショットではなく本物のワークスペースを共有させたいチーム向けに、フルのプロダクト構築を出荷します。