MCP新ロードマップとは。CI/CDで確認すべき変更点3つ

AIエージェントとツールをテスト対象のCI/CDパイプラインに組み込んでいる方、あるいはこれから組み込もうとしている方に向けた話です。Model Context Protocol（MCP、AIとツール・データソースを接続するための通信プロトコル）の運営団体が、今後の開発方針を示すロードマップを公開しました。テスト戦略やリリースサイクルの観点で何を見直すべきか、整理しておきます。

MCPはもともと2024年11月にAnthropic（Claudeを開発する企業）が提唱した仕組みです。2025年12月にLinux Foundation（オープンソースプロジェクトを運営する非営利団体）へ移管され、現在はAgentic AI Foundation（AAIF）という組織が仕様策定を担っています。ChatGPTやClaudeなどのAIが外部のAPIやデータベースに接続する際の「共通言語」のような役割を担っており、すでに事実上の業界標準になっています。

今回のロードマップでは5つの優先分野が示されました。この中でCI/CDやテスト運用に直接関わるのは、通信方式の統一と、AIエージェント向けメッセージングの2点です。順番に見ていきます。

通信方式のHTTP統一がテスト設計に与える影響

MCPは当初、WebSocket・stdio（標準入出力を使うローカル接続）・HTTPなど複数の通信方式が混在していました。テストコードを書く側からすると、これは地味に厄介な問題です。

ローカル接続用のモック（テスト用の代替実装）と、リモート接続用のモックを別々に用意する必要があったからです。2026-07-28版の仕様でリモートMCPサーバーもHTTP経由の接続に対応し、今後は完全にHTTPベースへ統一・強化していく方針が示されました。

これはテスト自動化にとって単純化のチャンスです。通信方式が1つに揃うということは、E2Eテスト（システム全体を通した結合テスト）で使うHTTPクライアントのモックライブラリが、そのままMCPサーバーのテストダブル（代替の疑似実装）として再利用できる可能性が高まります。curlやPostmanのようなHTTPベースの検証ツールで、MCPサーバーの疎通確認ができるようになる点も、CIパイプラインへの組み込みやすさに直結します。

加えて2026年7月の仕様更新では、接続がステートレス（サーバー側が接続状態を保持しない方式）になったことも見逃せません。ステートフルな接続は、テストのたびにセッション状態をリセットする手間がかかります。ステートレス化によって、テストケース同士の依存を減らし、並列実行しやすいテストスイートを組みやすくなります。

AIエージェント向けメッセージングとテストの非同期化

もう1つの優先分野が「Agentic messaging primitives」です。MCP登場当初のAIは、チャットで質問して答えが返ってくる単純な往復処理が前提でした。

しかしAIエージェントがバックグラウンドで長時間タスクを処理するようになった今、この前提は崩れています。ロードマップでは、サーバーが結果をストリーミングでプッシュする仕組みや、クライアントがポーリング（定期的に問い合わせる方式）せずにサーバー発のイベントを受け取れる仕組み（server-initiated events）の整備が挙げられています。

テストの観点で言うと、これは「同期的な単体テスト」から「非同期イベントを検証する結合テスト」への移行を意味します。たとえば、AIエージェントが数分かかるタスクを実行中に、途中経過のイベントが正しい順序・タイミングで届くかを検証するテストが必要になります。

従来のHTTPリクエスト・レスポンス型のテストでは、こうした非同期性を扱いにくいのが実情です。WebSocketやSSE（Server-Sent Events、サーバーからクライアントへ一方向にイベントを送る仕組み）のテストで使われてきた手法、たとえばイベントの受信タイムアウトを設定したアサーション（検証条件）の書き方が、MCPサーバーのテストにも応用できそうです。

品質保証の観点で見る他の3分野

残り3つの優先分野は直接テスト設計を変えるものではありませんが、CI/CDの運用ポリシーには影響します。

Agent identity and enterprise-ready security: AIエージェント自身がアイデンティティ（識別情報）を持ち、人間の承認なしに権限を取得・委譲する仕組み。トークン交換の認可フローが変わるため、認証系の統合テストは仕様更新のたびに見直しが必要
Improved primitives: ツールの発見・呼び出しを段階的に絞り込む方式へ整理する取り組み。ツール一覧をモックしているテストは、カテゴリ階層の変更に追随できる設計にしておくと安全
Improved SDK developer experience: クライアント・サーバSDKの一貫性向上。SDKのマイナーバージョン更新でAPIの挙動が変わるリスクがあるため、SDKバージョンをCI上で固定し、更新時は専用ブランチで検証する運用が無難

MCPは仕様更新の頻度が高いプロトコルです。SDKやサーバーのバージョンをテスト環境で明示的に固定し、更新は計画的な検証を通してから本番に反映する運用が安全です。

今日確認できること

自分のプロジェクトがMCPを使っているかどうかは、まず依存関係を確認するのが早道です。

# Node.js プロジェクトの場合
grep -r "@modelcontextprotocol" package.json
npm ls @modelcontextprotocol/sdk

# Python プロジェクトの場合
pip show mcp
grep -r "mcp" requirements.txt pyproject.toml

MCPサーバーの通信方式がstdioかHTTPかは、サーバー設定ファイル（mcp.jsonやclaude_desktop_config.jsonなど、利用しているクライアントの設定ファイル）内のtransportやcommandの指定を見れば分かります。stdio前提で組んだテストがある場合、HTTP統一が進んだ際に接続方式の切り替えテストが増える点は覚えておいて損はありません。

CIパイプライン上でMCPサーバーの疎通テストを組んでいるなら、AAIF（Agentic AI Foundation）の公開する仕様バージョン番号（例: 2026-07-28）をテストログに出力しておくと、後から「どの仕様バージョンで通っていたテストか」を追跡しやすくなります。仕様が数ヶ月おきに更新される前提で、リグレッションテスト（既存機能が壊れていないかの回帰確認）にバージョン情報を紐づけておく運用が、後々のトラブルシューティングを楽にします。

まとめ

MCPのロードマップは、テスト戦略に直接関わる変更を2つ含んでいます。

通信方式のHTTP統一とステートレス化により、E2Eテストのモック再利用性と並列実行性が上がる見込み
AIエージェントの非同期処理拡大により、ストリーミング・イベント駆動型のテスト設計が必要になる
認証・SDK・ツール発見の変更は直接テストを変えないが、バージョン固定と計画的な検証運用が欠かせない

まずは自分のプロジェクトの依存関係とtransport設定を確認し、どの仕様バージョンに依存しているかを把握することから始めてみてください。