MCPの新仕様公開後、連携と受け入れテストで何を確認すべきか

MCPの変化の軸は、ツールをモデルに見せることから、ツール連携を長期的に保守できるサービスにすることへと移りつつあります。開発者にとって最も重要なのは、設定内のプロトコル日付を最新のものに書き換えることではなく、クライアント、サーバー、その間のネットワークが実際にどの挙動をサポートしているかを確認することです。

本記事では、MCP 2026-07-28仕様とその後に公開されたロードマップを分析します。データは2026年9月5日時点で確認したものです。これはEveryInfraのアップグレード告知ではありません。また、本文で触れた変更がEveryInfraやお使いのクライアントですでに提供されていることを意味するものでもありません。

まず区別すべき点：リリース済みの仕様とロードマップ上の計画

MCPのメンテナーは、7月28日のリリース告知で2026-07-28版を正式にリリースしました。主な変更の一つがプロトコルコアのステートレス化です。これはサービスが移行を完了したこととは別の話です。仕様は実装者が従うべき内容を示し、サービスのバージョンノートと実際のレスポンスは、利用者がいま何を使えるかを示します。

2026年8月22日の新しいロードマップ（https://blog.modelcontextprotocol.io/posts/mcp-roadmap/）では、エージェントのアイデンティティ、結果の表現、段階的なツール探索といった今後の方向性が示されました。これらをすべて「最新のMCPがサポートする機能」の一覧に入れてしまうと、連携する側が判断を誤ります。ロードマップはプロジェクトの方向性を理解する助けになりますが、未リリースのクライアント機能の代わりにはなりません。

このロードマップをめぐるHacker Newsの議論（https://news.ycombinator.com/item?id=49399591）でも、各サービスが新しい要件をどこまで実装するのか、段階的なツール読み込みをどう扱うのかといった疑問が出ています。これらは検討すべき論点を見つける手がかりとして有益ですが、エコシステムでの採用状況を調査したものではありません。私たちが重視するのは、より実務的な問いです。MCP対応をうたう2つのエンドポイントは、実際に同じプロトコルで通信できるのでしょうか。

ステートレス化によるプロトコルセッションの廃止と、残る業務上の責任

公式の変更一覧（https://modelcontextprotocol.io/specification/2026-07-28/changelog）によると、新バージョンでは従来の初期化ハンドシェイクとプロトコルレベルのセッション識別子が廃止されました。呼び出しをまたいで状態を保持する必要があるアプリケーションは、業務を識別する明示的なハンドルを使用できます。つまり、プロトコルは、接続にひも付いた暗黙のセッションにすべてのコンテキストを保持させることを前提としなくなりましたが、アプリケーションは引き続き独自のタスク、リソース、状態を持てます。

連携設計で押さえるべき点は、アクティブな接続を、タスクの所有者を明確にする仕組みの代わりにしないことです。時間のかかる操作では、少なくとも、誰が開始したか、どのユーザーに照会権限があるか、現在の状態はどうか、ネットワーク切断後に結果をどう確認するかを明確にできる必要があります。

仮のシナリオを考えてみます。エージェントがレポート生成タスクを開始した後、クライアントの接続が切れたとします。再接続したユーザーが知りたいのは、再接続できるかどうかだけではなく、元のレポートが生成されたかどうかです。タスク識別子と結果の照会手段がなければ、プロトコル上の接続が簡単になっても、ユーザーは同じ作業を再送信してしまうかもしれません。

そのため、プロトコルのリクエスト番号、業務タスクの識別子、重複実行を防ぐ仕組みは、それぞれ別に設計することをおすすめします。これらは互いに関連していてもかまいませんが、1つがあるからといって残りの2つの問題も解決済みとは限りません。これはアプリケーション層での設計判断であり、MCPがあらゆる業務に対して自動的に冪等性を保証するものではありません。

HTTPによる管理の容易化とリクエストヘッダーの限界

新バージョンのStreamable HTTP仕様（https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http）では、Mcp-Methodなどのリクエストメタデータヘッダーが定義され、該当するメソッドではMcp-Nameを使います。ヘッダーとボディの対応するフィールドは一致している必要があります。仕様では引き続きリクエスト単位のSSEレスポンスが認められているため、この変更を「MCPはストリーミングレスポンスを使わなくなった」と単純化することはできません。

これらの設計によってミドルウェアはリクエストを区別しやすくなりますが、利用者には引き続き2種類のチェックが必要です。1つ目はプロトコルのチェックで、ヘッダーの欠落、未対応のバージョン、ヘッダーとボディの不一致に対して明確なエラーが返るかを確認します。2つ目は業務のチェックで、ツール呼び出しと判別された後、現在のユーザーにこのツールを実行し、この対象にアクセスする権限があるかを確認します。

照会専用のアカウントが、リクエストヘッダーでは照会を指定し、ボディでは変更を要求したとします。ミドルウェア層とアプリケーション層の双方が、相手側の検証を当てにして必要なチェックを省くと、システムに不整合が生じるおそれがあります。実際のテストでは、正しいリクエストヘッダーが通るかだけを確かめるのではなく、こうした不整合を含む無害なリクエストを作成し、拒否されることを確認してください。

同様に、HTTP 200はレスポンスを正常に取得できたことを示すだけで、目的の業務が完了したとは限りません。ツールは業務エラーを返したり、入力待ちになったり、途中段階の結果を出力したりすることがあります。すべてのレスポンスを一律に成功として表示するより、こうした状態をユーザーに伝えることのほうが重要です。エラー分類の設計を詳しく知りたい場合は、当サイトのAPIエラー処理と自己修復の方法（https://everyinfra.com/build/api-errors-self-healing）を参照してください。

キャッシュ可能なカタログと、キャッシュ情報からの推測に頼れない権限管理

新仕様ではカタログのレスポンスにttlMsとcacheScopeが導入され、それぞれ鮮度の目安と共有キャッシュのスコープを表します。具体的な適用対象は、変更一覧のキャッシュに関する注記（https://modelcontextprotocol.io/specification/2026-07-28/changelog）に記載されています。これは不要な再探索を減らす助けになりますが、ツールの一覧が今後も変わらないことを約束するものではありません。

連携する側は、カタログをタイムスタンプと適用対象のアイデンティティが付いた地図として扱えます。地図はモデルがツールを選ぶ助けになりますが、最終的な実行時には改めて権限とパラメータのチェックを通す必要があります。ユーザーが一度ツールを目にしたからといって、そのツールを永続的に使う権利があることにはなりません。

別途検証しておきたいシナリオがあります。ユーザーの権限が取り消された後も、クライアントが古いカタログを保持しているケースです。理想的なユーザー体験とは、ツールが黙って消えたり、呼び出しが通知なく失敗したりするのではなく、実行エンドポイントが明示的に拒否し、クライアントが理由を説明したうえで、適切なタイミングでカタログを更新することです。キャッシュ時間を延ばして権限の変更を見えにくくしないでください。

独自の機能カタログを構築する場合は、リアルタイムの機能カタログに検証可能性が必要な理由（https://everyinfra.com/build/live-capability-catalog）もあわせてお読みください。当サイトのこの記事では、カタログと実際の挙動の関係を扱っていますが、新しいキャッシュの仕組みをすべて実装済みであることを示すものではありません。

接続状態では隠せないアイデンティティの問題

認可サーバーの識別情報の検証も、今回の仕様変更に含まれています。RFC 9207（https://www.rfc-editor.org/info/rfc9207/）はissパラメータを定義しています。これにより、クライアントは認可レスポンスが想定した発行者から返されたものかを確認でき、認可サーバーの取り違えを防げます。

プロダクトの観点では、アイデンティティには少なくとも3つの異なる問いが含まれます。現在操作しているのはどのユーザーか、今回の実行でどのタスクを行うことをユーザーが許可しているか、そしてタスク実行中にサービスが実際にどの権限を公開しているか、という問いです。ユーザーがログインを完了したからといって、その後のすべての外部送信、削除、リソース購入に同意したことにはなりません。

影響の大きいアクションでは、実行前に主要な対象と実行した場合の影響を改めて表示することをおすすめします。たとえば設定を変更する場合はどの環境のどのフィールドかを、メッセージを送信する場合は宛先と内容を明示します。モデルは操作の準備を手伝えますが、認可を曖昧なツール説明の中に埋もれさせてはいけません。

そのため、サービスがOAuthに対応していること、クライアントがMCPをサポートしていること、ツールを一覧表示できることは、いずれも単独では本番統合の受け入れ可否を判断する根拠にはなりません。プロトコルの検出、アイデンティティと認可、業務の完了について、それぞれ検証可能な根拠が必要です。

アップグレード前の小規模で明確な受け入れマトリクスの作成

公式のバージョンと互換性に関する説明（https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning）と照らして実装を検証するときは、「MCP対応」を1行で登録するのではなく、実際の利用の組み合わせを1つずつ分けて列挙してください。各項目には、クライアントとそのバージョン、サーバーが対応するプロトコルバージョン、使用するトランスポートと認証方式、検証済みの操作、未検証の機能を含めます。

初回の検証ですべてのツールをテストする必要はありませんが、出荷可否の判断を左右するシナリオは必ずカバーしてください。

• 読み取り専用のタスクが、現在のユーザーおよび対象に正しくひも付いた、分かりやすい結果を返します。
• 未対応のバージョン、誤ったパラメータ、期限切れの認証情報は、一見成功したような空の結果になるのではなく、明示的に拒否されます。
• ユーザーが影響の大きい操作を拒否した場合、サービスはそのアクションを実行しません。
• リクエストが中断されても元のタスクの状態を特定でき、結果が不明な場合は副作用のある操作が自動的に繰り返されません。
• 権限の変更後は、古いカタログや接続を介して、取り消された権限が引き続き付与されることはありません。

これらは、当社が提案する統合時の受け入れ項目であり、特定の製品について実施済みのテストレポートではありません。EveryInfraへの既存のアクセス手順は、「リモートMCPアクセスの受け入れ」（https://everyinfra.com/build/remote-mcp-setup）に記載されています。内容を読む際は、対象となる具体的なバージョンとテストの適用範囲を踏まえ、2026-07-28との互換性を証明するものとして扱わないでください。

アップグレードするかどうかの判断は、最終的には具体的な問いに立ち返るべきです。新しいバージョンは現在のデプロイや利用における明確な課題を解決するのか、そして主要なクライアントの組み合わせは安定して動作するのか。答えがまだ明確でなければ、まず互換性の検証を済ませてください。明確であれば、移行とロールバックを計画してください。プロトコル日付の更新は出発点にすぎず、ユーザーが継続してタスクを完了できることが成果です。