MCP 2026 ロードマップまとめ — Linux Foundation化したAIツール標準プロトコルの進化

MCP 2026 ロードマップまとめ — Linux Foundation化したAIツール標準プロトコルの進化

作成日:
読了:約9分
更新日:
MCPModel Context ProtocolAIAIエージェントプロトコルLinux Foundation
この記事を読む人におすすめPR / Amazonアソシエイト
書籍PR
リーダブルコード

読みやすいコードの原則。全エンジニアの基礎。

Amazonで見る
書籍PR
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

通称「徳丸本」。Webセキュリティの定番教科書。

Amazonで見る
ガジェットPR
HHKB Professional HYBRID Type-S

打鍵感で選ぶ定番キーボード。長時間の実装に。

Amazonで見る

当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。

MCP（Model Context Protocol） は、AIモデルとツール／データソースをつなぐためのオープン標準で、Claude / Cursor / Windsurf / Zed などの主要AI製品がネイティブ対応しています。2026年現在、コミュニティMCPサーバーは 200+ 公開されており、AIインテグレーションの 事実上の標準 になりつつあります。

2025年に Linux Foundation 配下のプロジェクトとなった MCP は、2026年に体制を組み替え、「日付ベースのリリース計画」から「Working Group ベースの開発」 へ進化しました。この記事では、2026 ロードマップの重点と、開発者として何をウォッチすればよいかを整理します。

MCP の基本

項目内容
仕様の最新版2025-11-25（2025年11月公開。追記: 2026年7月に 2026-07-28 版が公開）
ガバナンスLinux Foundation 配下のプロジェクト
メッセージ形式JSON-RPC 2.0
プリミティブResources（データ）／ Tools（関数）／ Prompts（テンプレ）
サーバー数200+ コミュニティ実装（2026年3月時点）
主な対応クライアントClaude / Cursor / Windsurf / Zed ほか

「AIモデルが、外部のツール・データに 統一された方法でアクセスできる ようにする」という発想で、各AI製品ごとに違っていた接続方式を共通化するのが狙いです。

なぜ標準化が重要なのか

LLM単体ではできることが限られます。実際のサービスでは、

  • データベースを参照
  • GitHub / Slack / Notion を操作
  • Web ブラウザを動かす
  • ファイルシステムを読み書き

といった連携が前提になります。各AIアプリ（Claude / Cursor / Zed など）がそれぞれ独自に統合方式を作ると、ツールベンダー側が N×M の対応 を強いられます。MCP はそこを 1×M に圧縮 する標準で、エコシステム全体の効率を一気に押し上げています。

2026 ロードマップ — 4つの重点領域

1. トランスポートの進化とスケーラビリティ

Streamable HTTP トランスポートを改良し、ステート管理なしで水平スケール できるようにする方向です。サーバー側が状態を持たないため、ロードバランサーで素直にスケールアウトできます。

加えて、.well-known を使ったサーバー能力のディスカバリ が標準化される見込み。ライブ接続を貼らなくてもサーバーの提供能力が分かる仕組みで、運用が大きく楽になります。

2. エージェント間通信（Tasks primitive の強化）

Tasks プリミティブに対して、リトライセマンティクスや有効期限ポリシー が強化されます。プロダクション運用での信頼性向上が狙いです。長時間タスク・非同期タスクを安全に流す設計が、より自然に書けるようになります。

3. セキュリティ・認可

OAuth 2.1 ベースの認可フローが標準化され、スコープ単位でツール呼び出しを許可 するようなきめ細かな制御が可能に。エンタープライズ用途で大きな意味を持ちます。

4. 仕様の安定化と相互運用性

主要クライアント（Claude / Cursor / Windsurf / Zed）と主要サーバーが 同じスペックで噛み合う こと自体が課題で、Working Group 体制によって相互運用性を継続的に検証していく構えです。

クライアント・サーバー側エコシステム

クライアント（AIアプリ）側：

クライアントMCP対応補足
Claude Desktop / Code◎Anthropic がMCP発案元
Cursor / Cursor 3◎エージェントウィンドウから利用
Windsurf◎デフォルト統合
Zed◎エディタネイティブ統合
ChatGPT Desktop（一部）△ベンダー側の動向次第

サーバー側（一部のみ）：

サーバー用途
github / gitリポジトリ操作
slack / teams / chatworkチャット連携
postgres / mysql / sqliteDB アクセス
filesystemローカルFS操作
browser-use / playwrightブラウザ自動化
google-sheets / google-driveドキュメント連携

公式・コミュニティ合わせて 200を超える サーバーが公開されており、自前で書かなくても "ある" 状態が普通になりつつあります。

クラウド運用 — Streamable HTTP が推奨に

2026年は、クラウドにMCPサーバーをデプロイする際の 推奨トランスポート が Streamable HTTP に集約されつつあります。

理由：

  • HTTPで素直に動く ため、ロードバランサー／CDN／WAF と相性が良い
  • 長時間ストリーミング が可能で、進捗通知や分割応答に強い
  • ステートレスにスケール できる設計に向かっている

stdio モードは依然としてローカル開発向けに有効ですが、本番運用は Streamable HTTP が主流になっていきます。

開発者として何を準備するか

1. MCPクライアント／サーバーのSDK選定

公式SDK（TypeScript / Python ほか）が提供されており、自前ツールをMCPサーバーとして公開する敷居は急速に下がっています。社内ツールをMCPでラップしておくと、Claude / Cursor / Zed どこからでも呼べるようになります。

2. 認可・スコープ設計

OAuth ベースのスコープ設計を、社内のIDP（Okta / Auth0 / Entra ID）と整合する形で先に決めておくと、後から楽です。

3. ロギング／監査

MCP経由のツール呼び出しを 「誰が」「何を」「いつ」呼んだか を記録する基盤を整備。EU AI Act の監査ログ要件にも繋がります。

4. テナント分離・コスト管理

外部ユーザーに開放するMCPサーバーは、テナント単位での分離・レート制限・課金 が前提に。Streamable HTTP の水平スケールが活きるのはこの領域です。

似た領域とのすみ分け

標準主な目的
MCPAIモデル ↔ ツール／データの接続
A2A（Agent-to-Agent）エージェント同士の対話・協調
OpenAPI / GraphQL一般的なAPI仕様
Function Calling（各社独自）モデル単独でのツール呼び出し

MCP は 「LLMアプリのツール統合の入口」 という位置で、A2A はその上で エージェント同士の協調 を扱います。両者を併せて使う運用が増えていく見込みです。

その後の動き（2026年10月時点）

2026年7月28日付で、2025-11-25 版に続く仕様 2026-07-28 が公開され、現行バージョン（Current）になりました。本記事で触れたロードマップのうち「ステートレスな水平スケール」「Tasks の見直し」が、かなり踏み込んだ形で仕様に入っています。公式の変更点一覧から主なものを抜き出すと次のとおりです。

  • Streamable HTTP からプロトコルレベルのセッション（Mcp-Session-Id ヘッダ）を削除。状態が必要なサーバーは、サーバーが発行するハンドルをツール引数で受け渡す形に
  • initialize / notifications/initialized のハンドシェイクを廃止し、各リクエストの _meta にプロトコルバージョンとクライアント能力を載せるステートレスな方式へ
  • サーバーの対応バージョン・能力・識別情報を返す server/discover RPC を追加（サーバー側は実装必須）
  • サーバーからクライアントへの変更通知は、HTTP GET エンドポイントと resources/subscribe に代えて subscriptions/listen に一本化
  • 実験的だった Tasks をコアから外し、公式拡張（io.modelcontextprotocol/tasks）として再設計
  • サーバー発のリクエスト（sampling/createMessage や elicitation/create など）を、input_required の結果を返してクライアントに再送してもらう Multi Round-Trip Requests（MRTR）パターンに置き換え

既存のサーバー・クライアントに影響する変更が多いため、SDK の対応状況を確認しながら移行計画を立てるのが現実的です。

まとめ

  • MCP は Linux Foundation 配下、200+ サーバー、主要AIアプリがネイティブ対応
  • 2026年は Working Group ベース の開発体制に移行
  • ロードマップの軸は トランスポート進化／エージェント通信／認可／相互運用性
  • クラウド運用の主役は Streamable HTTP に
  • 開発者側は SDK選定／認可設計／監査ログ／テナント分離 を整えておくのが吉

エージェント時代のインフラとしてMCPはすでに「当たり前に存在する」存在になりつつあります。社内ツール／業務システムのMCP化は、2026年中に進めておきたい投資です。

参考リンク

関連記事

MCP 2026-07-28 仕様リリース候補 — ステートレス化とMCP Apps/Tasksで何が変わるか

MCP 2026-07-28 仕様リリース候補 — ステートレス化とMCP Apps/Tasksで何が変わるか

約19分

Model Context Protocolの2026-07-28仕様が現在リリース候補（RC）段階です。セッションとMcp-Session-Idヘッダを廃したステートレス化、Extensionsフレームワーク、MCP Apps、Tasks拡張、認可ハードニング、正式な非推奨ポリシーまで、RC本文の一次情報をもとに主要変更と移行の考え方を整理します。

MCPModel Context ProtocolAIエージェントプロトコルステートレス
プロンプトインジェクションがRCEになる日 - AIエージェントとMCPが攻撃対象になった2026年

プロンプトインジェクションがRCEになる日 - AIエージェントとMCPが攻撃対象になった2026年

約12分

2026年春に相次いだAIエージェントフレームワークとMCPの脆弱性を整理します。Semantic Kernelのプロンプトインジェクション→RCE（CVE-2026-26030 / CVE-2026-25592）や、MCPのSTDIOトランスポート設計に起因するRCE群を題材に、「LLMはセキュリティ境界ではない」という原則と、いま打つべき防御策をまとめます。

セキュリティAIエージェントMCPプロンプトインジェクションRCEAI
Claude Opus 5.5 リリース - 値下げと4つの破壊的変更、effort デフォルト medium の移行ポイント

Claude Opus 5.5 リリース - 値下げと4つの破壊的変更、effort デフォルト medium の移行ポイント

約27分

2026年9月22日、AnthropicがClaude Opus 5.5をリリースしました。モデルIDはclaude-opus-5-5、価格は入力$4/出力$20でOpus 5から値下げ、キャッシュ読み取りは$0.20。思考の無効化不可・強制ツール使用の廃止など4つの破壊的変更、effortデフォルトのmedium化、Fable 5.1との比較ベンチ、提供プラットフォームと移行手順を公式情報で整理します。

ClaudeAnthropicLLMAIAIエージェント