Amazon AWSがステートレスMCPをサポート、だが真の試練は互換性にある

Amazon AWSは、仕様史上最大のアーキテクチャ改訂が安定版として公開されてから2日後、AgentCore GatewayにMCP 2026-07-28のサポートを追加した。既存のゲートウェイでも、UpdateGatewayを1回呼び出すだけで新しいプロトコルバージョンを有効化できる。ただし、この簡単なコントロールプレーンの変更の背後には、クライアント、サーバー、そしてエンタープライズのセキュリティチームにとって、より難しい移行が隠れている。

新しいModel Context Protocol改訂版では、プロトコルレベルのセッションが廃止され、すべてのリクエストが自身のバージョンとクライアント機能を記述する方式となった。MCPは、AIアプリケーションをツール、データソース、その他のサービスに接続するためのオープンスタンダードである。ステートレスな設計により、ゲートウェイのスケーリング、ルーティング、復旧は容易になるはずだ。

その利点には、互換性という試練が伴う。クライアントは新しいリクエストメタデータを採用し、サーバーはディスカバリーを実装する必要があり、従来のセッション前提はもはや通用しない。Amazon Bedrock AgentCore Gatewayは現在、この2つのプロトコル世代の間に位置し、アクセス制御を単一のマネージドエンドポイントで適用しながら、エンタープライズサービスをMCPツールへと変換している。

したがって本質は、単なるバージョン選択のチェックボックスより大きい。Amazon AWSは、マネージドゲートウェイがプロトコルの変化を各アプリケーションチームに到達する前に吸収できると見込んでいる。それが機能するかは、バージョンネゴシエーション、認可の正確性、そして混在するクライアント群の挙動にかかっている。

Amazon AWS、MCPの大規模改訂を1回のゲートウェイ更新に集約

AWSはインフラ側の手順を1回のAPI操作にまで簡素化したが、アプリケーションは依然として改訂後のプロトコルを正しく扱う必要がある。

MCPのメンテナーは、5月に始まったリリース候補期間を経て、7月28日に安定版の2026-07-28仕様を公開した。安定版MCPリリースは、プロトコルの初期成長期に確立された複数の前提を置き換えるものだ。

AWSは続いてAmazon Bedrock AgentCore Gatewayでのサポートを提供した。同社のAgentCore更新情報によると、ゲートウェイ所有者はUpdateGatewayを通じて新しい改訂版を追加できる。このリクエストにより、ゲートウェイのMCPプロトコル設定とサポート対象バージョンの一覧が更新される。

該当するコントロールプレーンのオブジェクトはprotocolConfiguration.mcp.supportedVersionsである。AWSはこのフィールドを、ゲートウェイが使用できるMCPバージョンの配列として文書化している。サービスが更新を受理すると、UpdateGatewayはHTTPステータス202を返し、その後ゲートウェイは更新中の状態に移行する。

この区別は運用上重要である。呼び出しが受理されたからといって、接続済みのすべてのクライアントでリクエストが成功したわけではない。チームはゲートウェイがready状態に戻るのを待ち、実際のエンドポイントに対して適合性テストとワークロードテストを実行すべきだ。

この変更により、組織がゲートウェイの背後にあるすべてのLambda関数、OpenAPIサービス、Smithyサービスを作り直す必要はない。AgentCore Gatewayはすでに、それらのリソースをMCP互換ツールに変換している。ターゲット設定に応じて、リモートMCPターゲットやその他のHTTPサービスもサポートする。

このアーキテクチャにより、AWSは下流の各業務サービスに同一の変更を求めることなく、プロトコルと向き合う層を変更できる。たとえばカスタマーサポートAPIはAPIのままでありながら、ゲートウェイを通じて互換性のあるエージェントに対して操作をツールとして公開できる。

AgentCore Gatewayは、受信認証、送信認証情報、ツールディスカバリー、ルーティング、ポリシー適用も処理する。複数の社内チームが所有するサービスを1つのエンドポイントで扱う場合、これらの制御はさらに価値を増す。

とはいえ、UpdateGatewayの呼び出しで変わるのはゲートウェイが宣言するサポート対象だけだ。2026年改訂版を使うクライアントは、依然として必要なメタデータとヘッダーを送信しなければならない。古いクライアントは、相互にサポートされる改訂版をネゴシエートするか、互換性のあるフォールバック経路を使用する必要がある。

これがAWSの簡潔なアップグレードメッセージの背後にある最初の制約だ。マネージドサービスはプラットフォーム作業を減らせるが、古いSDKに新しいワイヤーフォーマットを出力させることはできない。

第2の制約はテストに関わる。ゲートウェイ所有者は、サポート対象の各バージョンで、ツール一覧、ツール呼び出し、認証失敗、ストリーミングの挙動、キャッシュ制御を検証する必要がある。1つの最新クライアントで成功しても、エンタープライズ全体のクライアント群に対する互換性が証明されるわけではない。

そのため、実践的な展開はインベントリの作成から始まる。チームは、どのエージェントアプリケーションがゲートウェイに接続しているか、どのSDKバージョンを使用しているか、それらのSDKがMCP 2026-07-28をサポートしているかを特定する必要がある。

検索可能なエンジニアリングナレッジベースで技術的な意思決定とテスト証跡を管理している組織は、クライアントおよびプロトコルバージョンごとに結果を記録できる。この記録は、障害が特定のフレームワークやデプロイチャネルでのみ発生する場合に重要となる。

AWSはコントロールプレーンでの操作を小さくした。アプリケーションレベルの検証こそが、依然として本当の移行プロジェクトである。

ステートレスMCPがゲートウェイの方程式を変える理由

ステートレスMCPは互換性情報をすべてのリクエストに移し、水平ルーティングを簡素化する一方、各メッセージが単独で成立することを求める。

従来のMCP改訂版では、プロトコル詳細と機能を確立するために初期化のやり取りを使用していた。クライアントがinitializeを送信し、サーバーが応答した後、クライアントがnotifications/initializedでシーケンスを完了する。Streamable HTTPでは、後続トラフィックをプロトコルレベルのセッションに関連付けるためにMcp-Session-Idヘッダーも使用できた。

MCPの主な変更点では、新しい改訂版でこのライフサイクルが廃止されている。プロトコルレベルのセッション識別子も削除された。呼び出しをまたいで状態を必要とするサーバーは、クライアントが通常のツール引数として渡す明示的なハンドルを発行しなければならない。

新しい形式の各リクエストは、プロトコルバージョンとクライアント機能を_meta内に含める。クライアントも同じ場所で自らを識別すべきである。サーバーは結果メタデータ内で自身のIDを返すため、各やり取りはより自己記述的になる。

新しいserver/discoverメソッドにより、クライアントは他の作業を始める前に、サポート対象バージョン、機能、サーバーIDを確認できる。2026-07-28改訂版を使用するサーバーは、このリモートプロシージャコールを実装しなければならない。

この設計は、ゲートウェイが記憶する必要のある内容を変える。1つの接続を通じて完了した初期化のやり取りに依存したり、後続のプロトコルトラフィックを不透明なMCPセッションに関連付けたりする必要はなくなる。

ロードバランサーは、プロトコルレベルのアフィニティを維持せずに個別のリクエストをルーティングできる。10回目の呼び出しを受け取ったゲートウェイインスタンスも、最初のインスタンスが受け取ったのと同じ重要な互換性情報を確認できる。

このモデルはマネージドクラウドゲートウェイに適している。ステートレスサービスは、ワーカー間でスケールし、不健全なキャパシティを置き換え、すべてのリクエストを解釈する前にMCPセッションレコードを復元することなくトラフィックを分散できる。

また、短命なクラウドインフラと接続指向のプロトコル挙動の間にあった扱いにくい不整合も軽減する。サーバーレス関数や分散ゲートウェイは一般に、独立した処理に必要な情報をリクエストに含める場合に最も機能する。

ただし、ステートレスであってもエージェントの作業に状態がないわけではない。購買ワークフローでは、承認情報、取引参照、あるいは以前のやり取りで収集したデータが依然として必要になる可能性がある。この仕様では、こうした状態をトランスポートセッション内に隠すのではなく、明示的なアプリケーションレベルのハンドルへ移している。

この移行は可視性を高め得る。ツール引数とサーバー発行のハンドルは、接続から推測される状態より明確な所有権の境界を生み出す。また、クライアントがリクエストを再試行したり古いハンドルを提示したりする可能性があるため、慎重な設計も求められる。

新しい改訂版では、Last-Event-IDとサーバー送信イベント識別子を通じたStreamable HTTPの再開可能性も廃止された。リクエスト中に応答ストリームが切断された場合、クライアントは新しいリクエストIDを使用して新たなリクエストを送らなければならない。

この規則は重要な運用上の問いを生む。ツールがストリーム障害前に副作用を実行していた場合、アプリケーションが冪等性を実装していなければ、無条件の再試行によって同じ操作が繰り返される可能性がある。

サポートチケットを作成するエージェントを考えてみよう。応答ストリームが消失しても、チケットサービスはレコードを正常に保存しているかもしれない。再試行時には、アプリケーションレベルの冪等性キーを付与するか、新たなチケットを作成する前に先行する操作を照会すべきだ。

AWSは、下流にあるすべての冪等性の問題をプロトコル境界で解決することはできない。ゲートウェイのログとトレースは繰り返された呼び出しを示せるが、ターゲットサービスは安全な再試行の挙動を定義しなければならない。

この改訂版では、個別のサーバー開始呼び出しをMulti Round-Trip Requestsに置き換えている。このパターンでは、サーバーがまだ必要とする情報を記述したinput_required結果を返す。クライアントは、要求された応答を付けて元のリクエストを再試行する。

このアプローチでは、制御をリクエストと再試行のシーケンス内に維持する。別のゲートウェイインスタンスが所有している可能性のある接続を通じて、独立したサーバーからクライアントへのリクエストが到着する事態を避けられる。

すべての結果には現在、通常はcompleteまたはinput_requiredであるresultTypeが含まれる。古いサーバーと通信するクライアントは、値が省略されている場合を完了済みの結果として扱う必要があり、限定的な互換性の橋渡しが維持される。

この仕組みは、明らかに分散インフラを優先している。その代償として、SDKとアプリケーションは、より明示的なメタデータ、再試行ロジック、状態管理を採用しなければならない。

SDKと混在するクライアント群にかかる圧力

AgentCore Gatewayは2つのプロトコル世代をサポートできるが、各組織は自らのクライアントが正しいバージョンをネゴシエートすることを証明する必要がある。

直接的な圧力の対象は、ゲートウェイの背後に隠れたAPIではない。MCPエンドポイントに接続するクライアントソフトウェアである。

2026-07-28改訂版を名乗るクライアントは、各リクエストでプロトコルバージョンとその機能を送信しなければならない。server/discover、必須の結果タイプ、複数ステップのやり取りにおける改訂後の処理を理解する必要もある。

HTTPクライアントは、Mcp-MethodとMcp-Nameを含む標準MCPリクエストヘッダーも使用しなければならない。これらのヘッダーにより、インフラはすべてのJSON-RPCボディを解析せずにトラフィックを検査し、ルーティングできる。

この変更は、ゲートウェイ、可観測性システム、セキュリティ制御にとって有用である。同時に、ツール実行前に不完全なクライアントが失敗し得る、別の検証ポイントも生む。

MCPは、この新しい境界に対する固有のエラーを定義している。ヘッダーの不一致にはコード-32020、必要なクライアント機能の欠落には-32021、サポートされないプロトコルバージョンには-32022を使用する。

これらのコードにより、プラットフォームチームは障害をより明確に分類できる。-32022応答の増加はバージョンネゴシエーションの問題を示し、-32020はHTTPヘッダーと内部のリクエスト間の不一致を示す。

SDKの移行は、言語間で同時には進まない。公式実装が安定仕様を採用する時期はそれぞれ異なり、アプリケーションでは新しいリリースが登場した後も長期間にわたってライブラリのバージョンを固定することが多い。

エンタープライズには、完全には制御できないクライアントもある。従業員は、承認済みのデスクトップアシスタント、社内のコマンドラインエージェント、別チームが開発したIDE拡張機能を使用するかもしれない。それぞれが異なる方法でMCPをネゴシエートする可能性がある。

AgentCoreのサポート対象バージョン一覧は、この混在するクライアント群への橋渡しとなる。ゲートウェイは、すべてのクライアントに新しいワイヤーフォーマットへの即時移行を強いるのではなく、複数の改訂版を通知できる。

そのサポートは、同一の動作を保証するものではなく、移行の仕組みとして扱うべきです。2026年コアから削除された機能は、古いプロトコルフローには依然として存在します。古いリビジョンのネゴシエーション後にテストが通っても、ステートレスな経路についてはほとんど分かりません。

Roots、Sampling、Loggingは、仕様全体から即時削除されるのではなく、現在は非推奨となっています。新規実装ではこれらの採用を避けるべきであり、既存実装には定められた移行期間が与えられます。

MCPの新しい機能ライフサイクルポリシーでは、最低12か月の非推奨期間が定められています。このガバナンス変更により、実装者は非公式な非推奨表現よりも予測可能な事前通知を得られます。

プロトコルは代替手段を示しています。アプリケーションはRootsの代わりに、ツールパラメータまたはリソース識別子を通じてディレクトリを渡せます。サーバーはSamplingに依存する代わりに、モデルプロバイダーのAPIを直接呼び出せます。実装ではプロトコルのLoggingの代わりに、OpenTelemetryまたは標準エラーストリームを使用できます。

これらの置き換えは、単なる構文ではなくアーキテクチャを変えます。従来はMCPクライアントを通じてモデルのサンプリングを要求していたサーバーが、プロバイダーとの直接統合、個別の認証情報、新たなコスト管理ポリシーを必要とする場合があります。

したがって、その影響はセキュリティチームと財務チームにも及びます。モデルへのアクセスをクライアント機能からサーバー側へ移すことで、認証情報の保管場所と利用状況の把握場所が変わるためです。

ゲートウェイの所有者は、クライアントを3つのグループに分類すべきです。第1のグループは2026年リビジョンを完全にサポートします。第2のグループは以前の安定版でのみ動作します。第3のグループは挙動が不明確であり、テスト完了まで隔離が必要です。

テスト対象は tools/list だけでは不十分です。有用なマトリクスには、検出、認証済みツール呼び出し、拒否されるスコープ、レスポンスストリーミング、中断されたリクエスト、リストキャッシュ、追加のユーザー入力を必要とするアプリケーションが含まれます。

チームは、ネゴシエートされたバージョンがテレメトリーに記録されていることも確認すべきです。このシグナルがなければ、リクエストの成功が、以前のプロトコルへの予期しないダウングレードを隠している可能性があります。

新しい経路が代表的な本番ワークロードを処理できて初めて、移行は成功したといえます。ゲートウェイが更新済みの supportedVersions フィールドを受け入れるだけでは成功とはいえません。

拡張機能がコアから離れる中で認可はより厳格に

MCP 2026-07-28は、オプション機能をガバナンスされたネゴシエート型の拡張システムへ移行する一方、認証情報に関する曖昧さを縮小します。

改訂された認可ルールは、エージェントが多数のサーバーに接続する際にリスクとなるアイデンティティ境界に焦点を当てています。MCPクライアントは、それぞれ異なるツールやデータを保護する複数の認可サーバーから認証情報を取得する場合があります。

仕様では現在、クライアントは保存した認証情報を、その認証情報を発行した発行者に紐付けなければならないと定めています。クライアントは認証情報を別の認可サーバーで再利用してはならず、発行者が変わった場合は再登録が必要です。

このルールは認証情報の混同に対処します。似たサーバー名、リダイレクト、変化するメタデータによって、あるサービスのクライアント認証情報が別の認可境界へ渡ってはなりません。

認可サーバーは、認可レスポンスに iss 値も含めるべきです。このフィールドが存在する場合、クライアントは認可コードを交換する前に、記録済みの発行者に対してその値を検証しなければなりません。

この検証は、認可サーバーの取り違え攻撃を防ぐために設計されたInternet Engineering Task Forceの標準、RFC 9207に従うものです。1つのクライアントが複数の発行者とやり取りする場合や、認可メタデータを動的に検出する場合に、この確認は重要です。

動的クライアント登録についても、より厳しい指針が示されています。MCPクライアントは適切なアプリケーションタイプを指定する必要があり、ネイティブアプリケーションとWebアプリケーションのリダイレクトURIルールをめぐる競合を減らします。

これらの要件によって、すべてのデプロイが自動的に安全になるわけではありません。SDKオプションは依然として正しく設定する必要があり、保存された認証情報レコードには適切なキー設定が必要で、アイデンティティプロバイダーは一貫した発行者情報を返さなければなりません。

AgentCore Gatewayは、受信側の呼び出し元を認証し、送信側の認証情報を個別に管理できるため、有用な強制適用ポイントになります。AWSのドキュメントによれば、このサービスはカスタムJSON Web Token認可、AWS Identity and Access Management、その他の設定済み認可モードをサポートしています。

この分離は不可欠です。ゲートウェイの呼び出しを許可されたアイデンティティが、その背後にあるすべてのターゲットに対する無制限の認証情報を自動的に取得してはなりません。

AgentCoreでは、ゲートウェイにポリシーエンジンを関連付けることもできます。このエンジンはエージェントのツール呼び出しを評価し、設定済みポリシーに基づいて各アクションを許可または拒否します。

ゲートウェイモデルによって、最小権限の必要性がなくなるわけではありません。管理対象のアイデンティティサービスに保存されていても、広範なスコープを持つターゲット認証情報は、依然として広範なスコープを持ちます。

チームは成功する呼び出しと同じくらい慎重に、失敗するケースをテストすべきです。スコープが不足するクライアントには、無関係なプロトコルエラーや隣接ツールへのアクセスではなく、制御された認可レスポンスが返される必要があります。

拡張システムは、並行するガバナンス上の変化を生み出します。オプション機能は、標準化された識別子、機能宣言、ネゴシエーションを使用しながら、コアプロトコルの外部で開発できるようになりました。

拡張フレームワークでは、公式の識別子に io.modelcontextprotocol プレフィックスを使用します。サードパーティは、自らが所有する逆順ドメインを使用すべきであり、無関係な機能間の衝突を減らします。

クライアントはリクエストごとの機能情報の中で、対応する拡張機能を通知します。サーバーは server/discover を通じて対応機能を通知します。両者は明示的にオプトインする必要があり、拡張機能はデフォルトで無効のままです。

公式拡張機能には、非同期Tasks、対話型MCP Apps、OAuthクライアント認証情報、エンタープライズ管理の認可が含まれます。実装者が利用する前に、コアが個々の専門機能をすべて取り込む必要はなくなりました。

この構造はコアの複雑さを抑えられます。一方で、プラットフォームチームはクライアント、サーバー、ゲートウェイ、SDKバージョンにまたがるサポートマトリクスを追跡する必要があります。

対話型インターフェース拡張機能をサポートするクライアントは、サーバーが適切に縮退できる場合、意味のあるテキストレスポンスも処理すべきです。特定の認可拡張機能を必要とするサーバーは、互換性のないクライアントを拒否できます。

AgentCore Gatewayの第一の責務は、コアプロトコルを正しく動作させることです。2026年リビジョンのサポートは、現在または将来のすべての拡張機能を普遍的にサポートすることを意味するものではありません。

これはAWSの発表における重要な不確実性です。ゲートウェイは拡張機能の情報を伝達できますが、顧客には、自身のワークフローが依存する拡張機能ごとに明確なドキュメントとテストが必要です。

認可の変更と拡張フレームワークは、1つの原則を共有しています。認証情報の発行者、クライアント機能、オプションの挙動に関するものであれ、隠れた前提が明示化されつつあります。

この明示性はエンタープライズの統制にとって有益です。同時に、許容的な統合環境では見えにくかった不完全な設定が、より明確に失敗することも意味します。

Amazon AWSの顧客がなお検証すべきこと

次に注目すべき3つのシグナルは、ネゴシエート済みバージョンのテレメトリー、認可失敗の品質、実際のワークロードにおける拡張機能のサポートです。

最初のシグナルは、本番クライアントが実際にMCP 2026-07-28をネゴシエートしているかどうかです。ゲートウェイの設定だけでは、その問いに答えられません。

チームは段階的ロールアウト後、リクエストメタデータとプロトコル関連エラーを監視すべきです。結果をクライアント名、クライアントバージョン、フレームワーク、デプロイチャネル別に比較する必要があります。

未対応バージョンやヘッダー不一致エラーの発生率が低下すれば、AWSのマネージド移行に関する主張を補強できます。エラーが継続するなら、ボトルネックはゲートウェイの可用性ではなく、クライアントSDKの導入であることを示します。

ダウングレードにも同等の注意が必要です。クライアントが古いリビジョンへ暗黙にフォールバックすると、未解決の移行問題を隠したままワークフローを継続できてしまいます。

組織は、テスト対象の各クライアントに期待するリビジョンを定義すべきです。そうすればアラートで、承認済みの互換性フォールバックと意図しないダウングレードを区別できます。

2つ目のシグナルは、複数のアイデンティティプロバイダーとターゲットにまたがる認可失敗の挙動です。チームは発行者の変更、無効な iss 値、期限切れトークン、不十分なスコープ、認証情報の再利用の試みをテストする必要があります。

最も安全な結果は、ターゲットが実行される前に正確に拒否されることです。ログには、呼び出し元に秘密情報を公開せず、関与したポリシーまたは認可境界を示す必要があります。

明確なネガティブテストの結果は、AgentCoreがカスタムセキュリティ作業を減らすという主張を裏付けます。失敗が分かりにくい場合や発行者の処理に一貫性がない場合は、特に複数の事業部門にまたがるゲートウェイでは、その主張を弱めます。

3つ目のシグナルは、拡張機能の相互運用性です。Tasks、MCP Apps、認可拡張機能を使用するワークフローでは、拡張固有の挙動を呼び出す前に機能を検証すべきです。

テストには適切な縮退も含める必要があります。UIをサポートしないクライアントでも、サーバーがフォールバックを約束する場合は、有用なコアコンテンツを受け取るべきです。

逆のケースも重要です。安全な運用に拡張機能が必須であるなら、サーバーは部分的なワークフローを試みるのではなく、リクエストを明確に拒否すべきです。

これら3つの優先事項の下には、より広範な運用上のシグナルがあります。新しいリビジョンではストリーム再開性がなくなるため、チームは中断された副作用を伴う呼び出しで重複アクションが発生していないかを監視すべきです。

キャッシュも検討する必要があります。リストおよびリソースの結果には現在、ミリ秒単位の鮮度ヒントである ttlMs と、パブリックとプライベートのキャッシュ可能性を分ける cacheScope が含まれます。

決定論的なツール順序は、クライアント側およびモデルプロンプトのキャッシュを改善できます。しかし、古いツール記述によってエージェントが旧式のスキーマを呼び出す可能性があるため、ターゲット更新時にはキャッシュ動作をテストする必要があります。

オブザーバビリティには分散トレースコンテキストを含めるべきです。仕様は traceparent、tracestate、baggage の _meta 規約を文書化しており、チームがクライアント、ゲートウェイ、ターゲットをまたぐ処理を追跡する助けになります。

このトレーシングは、リトライ時に特に有用です。オペレーターは、これらを1つのJSON-RPCリクエストIDとして扱うことなく、元の失敗したストリームと新しく発行されたリクエストを結び付ける必要があります。

マネージドゲートウェイの最大の価値は、こうした懸念が集約される場所で現れます。1つのエンドポイントで、呼び出し元の認証、ポリシーの適用、プロトコルトラフィックの変換、ツールの選択、ターゲット認証情報の注入、監査証跡の生成を実行できます。

主なリスクもそこにあります。ゲートウェイは大きな影響力を持つ制御点となるため、設定ミスが多数のエージェントやサービスに同時に影響を及ぼす可能性があります。

慎重なロールアウトは、重要度の低いゲートウェイまたは限定されたクライアント群から始めるべきです。チームは新しいサポート対象バージョンを追加し、準備完了ステータスを待ってから、バージョン固有のテストスイートを実行できます。

次の段階では、明示的なハンドルを使用する代表的なステートフルワークフローを導入すべきです。中断されたリクエストを1件、安全にリトライされた副作用を1件含める必要があります。

認可テストは、成功する呼び出しと拒否される呼び出しの両方を対象に、その後実施すべきです。拡張機能に依存するワークフローは、コアプロトコルの挙動が安定してから最後に導入すべきです。

ロールバック計画も引き続き必要です。対応バージョンの一覧に以前の安定版リビジョンを残しておくことで、チームが不具合を調査する間、互換性のあるクライアントにフォールバックを提供できます。

ただし、フォールバックが恒久的な曖昧さになってはなりません。組織には、残存する古いクライアントを見直す期日と、現在も使用している非推奨機能に関する計画が必要です。

開発者が注意すべきなのは、このリビジョンが状態の置き場所とリトライ方法を変えるためです。プラットフォームチームが注意すべきなのは、互換性がゲートウェイ境界で観測可能になるためです。

エンタープライズの購入者が注意すべきなのは、マネージドプロトコルサポートによって重複するインフラを削減できるためです。ただし、どの拡張機能、SDK、リージョン、アイデンティティ構成、ターゲットタイプが本番環境での検証を完了しているかは、引き続き確認すべきです。

ナレッジワーカーは、その成果を間接的に享受することになるでしょう。アシスタントは接続失敗を減らしながらより多くのツールに接続できる可能性がありますが、それはツール間でアイデンティティと同意が明確に維持される場合に限られます。

Amazon AWSは、最初の移行アクションを異例なほど小さくしました。より重要なのは、安全性、互換性、可視性を損なうことなく、チームがすべてのリクエストを自己完結型にできるかどうかです。

今後1〜3か月は、ネゴシエートされたバージョンのデータ、認可拒否の品質、主要SDKにおける拡張機能の準拠状況に注目してください。これらのシグナルは、ステートレスMCPが本番標準となったのか、それともクライアントの対応を待つゲートウェイ機能にとどまるのかを示すでしょう。

すでにAgentCore Gatewayを運用しているチームにとって、実務上の次のアクションは、管理された互換性監査です。1つのゲートウェイを更新し、対応するすべてのクライアントをテストし、ネゴシエートされたリビジョンを記録したうえで、アクセスを拡大する前に障害ケースを強制的に検証してください。

この証拠は、1回のAPI呼び出しが見かけ上どれほどシンプルかよりも重要です。Amazon AWSは現在、MCP 2026-07-28への橋渡しを提供していますが、各組織は自社のエージェントがそれを安全に渡れることを証明しなければなりません。