Amazon Bedrock AgentCore MCP Apps、インタラクティブAIをプレーンテキストの先へ
Amazon Web Servicesは、1つのMCPサーバーを複数のAIホスト向けインタラクティブインターフェースへと変える、完全なAmazon Bedrock AgentCore MCP Appsパターンを公開した。9月11日のリリースは、基盤となるサービスを単一のチャット製品に縛ることなく、会話型統合をテキスト応答の域から広げるという点で重要だ。
AWSのサンプルでは、ユーザーは架空のレンタル在庫を閲覧し、予約を行い、有効なレンタルを確認し、返却を完了できる。一部の応答は会話内にインタラクティブなHTMLカードとして表示される。一方、インターフェースの価値が小さい場合はプレーンテキストのままとなる。
より大きな競争は、AWSと他のクラウドプロバイダーの対決ではない。開発者が現在ChatGPT、Claude、その他のAIクライアント向けに構築しているカスタム統合に対し、ホスト中立のアプリケーションレイヤーが挑む構図だ。AWSはマネージドなランタイムインフラを提供し、MCP Apps拡張は互換ホストがインターフェースを検出・表示する方法を定義する。
この分離は魅力的な約束を生む。サーバーとウィジェットを一度構築すれば、拡張機能がサポートされる場所ならどこでも一貫した体験を提供できる。同時に、中心的な不確実性も生じる。プロトコルの移植性は、同一のホスト動作、本番環境のセキュリティ、幅広いユーザー採用を自動的に保証するものではない。
Amazon Bedrock AgentCore MCP Apps、ツールとウィジェットを接続
この新しいAWSパターンは、モデルが呼び出すツールを、ユーザーがAI会話内で確認・操作できるインターフェースと結び付ける。
Unicorn Rentalsと呼ばれるサンプルアプリケーションは、利用可能なレンタルを表示する自然言語リクエストから始まる。テキストによる在庫一覧を返す代わりに、ホストは画像、名前、説明、時間料金、空き状況を含むカードを表示する。
ユーザーは特定のユニコーンを予約するよう依頼できる。アプリケーションは取引を記録し、予約識別子とレンタル詳細を含む確認を表示する。別のリクエストでは有効なレンタルを取得でき、最後のリクエストでは返却処理と合計料金の計算が行われる。
架空の題材によってデモは親しみやすくなっているが、この対話モデルは一般的な業務ソフトウェアにも適用できる。旅行サービスなら航空便の選択肢を表示でき、サポートシステムならチケットやステータス操作を表示できる。分析ツールなら、すべてのデータポイントを文章で説明する代わりに、フィルター付きのグラフを返せる。
MCP Appsは、AIホストが外部ツールを検出して呼び出すための標準であるModel Context Protocolの拡張機能だ。従来のMCP応答にも、テキスト、画像、リソース、構造化データを含めることはできる。この拡張機能は、それらの結果とともにインタラクティブなインターフェースを提供するための標準化された手法を追加する。
MCP Apps specificationによると、ツールは対応ホストがサンドボックス化されたフレーム内で取得・レンダリングするユーザーインターフェースリソースを識別できる。ホストはツール結果をそのインターフェースへ渡し、その後の通信を仲介する。
AWSの実装では、_meta.ui.resourceUriフィールドを通じてツールをウィジェットに関連付ける。ツール結果にはstructuredContentが含まれ、ウィジェットにレンダリングに必要なデータを提供する。この構成により、各応答にインターフェース全体を埋め込むことなく、インターフェースの宣言をツールと結び付けられる。
ウィジェットはMCPリソースとして登録される。ホストは標準プロトコル呼び出しを通じて利用可能なツールとリソースを検出し、インターフェースを提示する必要がある際に適切なHTMLリソースを読み込む。
AWSは、このサーバーを公式MCP SDKおよび@modelcontextprotocol/ext-apps拡張機能を使用するTypeScriptアプリケーションとしてパッケージ化している。これはAgentCore Runtime上のNode.js 22環境でExpress.jsサーバーとして実行される。
同社のreference implementationは、在庫一覧、レンタル予約、予約確認、レンタル返却という4つの主要ツールを公開している。視覚的な応答に必要なウィジェットリソースも含まれる。
これは単なるチャットボット出力の視覚的処理ではない。インターフェースはエージェントが仲介するワークフローの一部であり続ける。モデルがリクエストを解釈してツールを選択し、タスクの進行を支援する一方で、ウィジェットはユーザーに結果をより正確に確認するための画面を提供する。
この組み合わせは、チャットのみのソフトウェアにおける基本的な弱点に対応する。説明や短い確認にはテキストが適している。しかし、複数の項目を比較したり、構造化された記録を確認したり、重要な結果を伴う選択を行ったりする場合には、非効率になる。
Thin Adapterこそがアーキテクチャ上の賭け
AWSはMCPサーバーを薄いプロトコルアダプターとして扱い、ビジネスルールと永続的な記録を従来型のバックエンドサービスに残している。
このサンプルでは、すべてのアプリケーション責務をAgentCoreデプロイメント内に置いていない。専用のAWS Lambda関数が在庫照会と予約処理を担い、Amazon DynamoDBがアプリケーションデータを保存する。
MCPサーバーは、AIホストとそのビジネスレイヤーの間を変換する。ツールを公開し、利用可能なインターフェースリソースを記述し、バックエンドへリクエストを送り、構造化された結果を返す。
この境界は設計の中核だ。既存のビジネスサービスは、MCP、ウィジェット検出、ホストレンダリングを理解する必要がない。アダプターの背後で、標準APIやSDK操作を引き続き公開できる。
企業は、デモ用のLambda関数をAmazon ECSまたはAmazon EKS上で稼働するサービスに置き換えられる。また、サーバーがそれらに到達でき、適切に認証できる限り、アダプターをAWS外のシステムへ接続することも可能だ。
これにより、会話プロトコルに結び付くアプリケーションロジックの量を抑えられる。在庫ルール、取引検証、データ永続化は、Webサイト、モバイルアプリケーション、社内ダッシュボード、その他のクライアントでも再利用できる。
ウィジェットレイヤーも独立して変更できる。チームは、基盤となるビジネスプロセスをホストへ移すことなく、製品カードを再設計したり、グラフを導入したり、レビュー用フォームを追加したりできる。
この分離は採用に実務的な影響を与える。多くの企業は、新しいAIインターフェースを中心に既存の取引システムを再構築しないだろう。それよりも、すでに運用しているサービスの前に、制御されたプロトコルレイヤーを置く可能性が高い。
同じ考え方はナレッジワークフローにも当てはまる。チームは、すべてのソースを1つのインターフェースに移すことなく、文書、ツール出力、ユーザーの判断を組み合わせる必要があることが多い。検索可能なナレッジベースはソース資料を保持しつつ、インタラクティブなエージェントがその上に焦点を絞ったアクションを提示できる。
AgentCore Runtimeは、アダプターのためのマネージド実行環境を提供する。AWSによれば、このランタイムはインフラのプロビジョニング、スケーリング、ヘルス管理、セッション分離を処理する。すべてのリクエストを汎用Webトラフィックとして扱うのではなく、MCPをネイティブなプロトコルモードとしてサポートする。
AWSのドキュメントは、MCPデプロイメントが通常0.0.0.0:8000/mcpで待ち受けると説明している。アプリケーションに複数ステップのプロトコル機能が必要かどうかに応じて、ランタイムはステートレスまたはステートフルなStreamable HTTPサーバーをサポートできる。
ステートレスな運用は、呼び出しを単独で完結できるツールに適している。ステートフルな運用は、継続中のセッションに依存するelicitation、sampling、進捗通知、その他の対話を含むワークフローを支える。
この違いはインタラクティブアプリケーションにとって重要だ。検索結果を表示するカードには、永続的なプロトコル状態がほとんど必要ない場合がある。一方、複数ステップの承認や設定プロセスでは、複数のユーザー操作にまたがる継続性が必要になることがある。
AgentCore Runtimeは、リクエストにMCPセッション識別子が含まれていない場合にそれを追加する。これにより関連するリクエストを同じランタイムセッションへ送る助けにはなるが、ユーザーIDに対するアプリケーションの責任をなくすものではない。
AWSは、AgentCoreがユーザーとセッション識別子の対応付けを強制しないと明示的に警告している。クライアントバックエンドはその関連付けを維持し、あるユーザーが別のユーザーのセッション値を提示することを防ぐ必要がある。
したがって、Thin Adapterアプローチはプロトコルの結合を減らすものの、アプリケーションアーキテクチャを不要にするわけではない。チームには依然として、認可ルール、入力検証、監査記録、バックエンドのエラー処理、取引上の安全策が必要だ。
ホスト中立のインターフェースがカスタム統合に圧力をかける
主な競争圧力は、開発者にAIクライアントごとに類似したインターフェースの再構築を求める、ホスト固有のアプリケーションレイヤーにかかる。
MCP Apps以前にも、複数のプロジェクトが異なるスキーマやSDKを通じて会話型インターフェースに取り組んでいた。開発者はあるホスト向けのアプリを構築できたが、別のホストでは異なるメタデータ、レンダリングルール、通信手法が必要になる可能性があった。
MCPコミュニティは、共有されたインターフェースモデルを作るためにApps拡張を導入した。その当初の提案は、MCP-UI、OpenAIのApps SDK、OpenAIとAnthropicの両方に関係するコントリビューターの取り組みを基にしている。
extension proposalでは、インタラクティブなインターフェースは頻繁に要望される機能として説明された。また、標準化の理由として相互運用性と一貫したセキュリティパターンも挙げられた。
AWSは現在、この仕様をマネージドデプロイメントの経路へと変換している。そのサンプルはMCPサーバーをAgentCore Runtime上に配置し、AgentCore Gateway経由で公開する。互換ホストはAWS固有リソースの集合ではなく、単一のエンドポイントを受け取る。
これは、インフラの選択と配布の選択の間に意味のある違いを生む。チームはAWS上にサーバーをデプロイしながら、AWSモデルやAWS所有の会話ホストを選ぶ必要はない。
AgentCore自体は複数のフレームワークとモデルをサポートしている。AWSは、そのランタイムをStrands Agents、LangGraph、CrewAI、その他の開発スタックといったフレームワークで構築されたエージェント向けインフラとして位置付けている。
しかしMCP Appsにおいて、より重要な中立性はプロトコル境界にある。AIホストは、Lambda関数やDynamoDBテーブルへ直接アクセスせずにツールを呼び出し、インターフェースリソースを要求する。
AWSは、同じUnicorn RentalsサーバーがChatGPT、Claude、その他この拡張機能をサポートするホストで動作するとしている。この条件は重要だ。ホスト中立性は、すべてのチャットインターフェースではなく、互換性のあるクライアントに適用される。
サポート状況は、クライアントのリリース、実行環境、有効化された機能によっても異なり得る。開発者は、1つのインターフェースがあらゆる場所に表示されると約束する前に、最新のホスト対応状況を確認する必要がある。
互換ホスト間であっても、同一のプロトコルメッセージが同一の表示を保証するわけではない。ホストは、コンテナとなるレイアウト、サンドボックス、権限、アクセシビリティの動作、対話モデルの一部を制御する。
サーバーは同じウィジェットコードと構造化データを提供できる。しかし、ユーザーが接続を認可する方法、アプリを見つける方法、ツール呼び出しを承認する方法、チャットとインターフェース操作の間を移動する方法は、周囲の製品によって決まる。
このため、この発表はカスタム統合に圧力をかける一方で、すぐに置き換えるものではない。ホスト固有のSDKは、共有拡張機能では利用できない機能を提供できる。また、ホストのナビゲーション、IDシステム、配布チャネルとのより密接な統合を提供する場合もある。
中立的な経路は別の利点をもたらす。ホストごとにコンポーネントを複製するのではなく、アプリケーションへの投資をサーバー、データ契約、ウィジェットへ集中させられる。
開発者やエンタープライズ購買担当者の交渉力を高める可能性がある。アプリケーションが複数のホストで有用性を維持できれば、会話型フロントエンドの切り替えコストは低下する。バックエンドやインターフェースの大部分はそのまま維持できる。
その効果は、ホストベンダーが今後もこの拡張機能に足並みをそろえるかどうかに左右される。標準が影響力を得るのは、公開されたこと自体ではなく、互換性のある実装、信頼できる挙動、有用なアプリケーションがそろったときだ。
マネージドゲートウェイが解決するのは到達性であり、信頼ではない
AgentCore Gateway は、1つのマネージドエンドポイントを通じて MCP サーバーへの到達を可能にするが、このサンプルのアクセスパターンを本番運用するには、意図的な堅牢化が必要になる。
AWS のアーキテクチャでは、外部の AI ホストとランタイムの間に AgentCore Gateway が置かれる。ゲートウェイは、実行ロールを用いた AWS Signature Version 4 認証接続を通じて、リクエストをランタイムへ転送する。
このサンプルでは、ゲートウェイへの受信リクエストに認証は用いられていない。代わりに AWS Web Application Firewall が、公開エンドポイントに対して IP アドレス許可リスト、マネージド脅威検知ルール、レート制限を適用する。
この構成により、外部ホストは AWS 認証情報なしで利用でき、デモは簡素になる。ただし、これを汎用的な本番環境向け認証設計と解釈すべきではない。
サンプルリポジトリには、適切なセキュリティレビュー、テスト、堅牢化なしに本番利用することを意図していないという明確な免責事項がある。この警告は、アプリケーションが検索だけでなくアクションも実行するため重要だ。
読み取り専用の商品カタログであれば、想定される損害は抑えられる。しかし、予約、返品、購入、設定変更、操作承認は、永続データに影響し、金銭面または運用面の結果を生じさせる可能性がある。
IP アドレス許可リストはアクセスを限定できるが、エンドユーザーの本人性を確立するものではない。共有された送信インフラでは、IP ベースのルールはアカウント単位やユーザー単位の認可より精度が下がる場合もある。
本番チームは、認証の終点と認可の始点を決める必要がある。ホスト接続はリクエストの送信元サービスを証明できるかもしれないが、各レコードを閲覧または変更できるユーザーを最終的に判断するのはアプリケーションでなければならない。
サーバーは、モデルが安全なリクエストを生成したと仮定するのではなく、すべてのツール引数を検証すべきだ。また、ウィジェットによって利用できない操作を隠すことに頼らず、バックエンド側で認可を強制する必要がある。
ウィジェットのコードも、他の Web アプリケーションコードと同じ厳密さで検証すべきである。MCP ホストはこれらのインターフェースをサンドボックス化されたフレーム内でレンダリングし、ホストページへの直接アクセスを制限する。ただし、サンドボックス化はアプリケーションの業務ロジックやデータ処理を検証するものではない。
ウィジェットは構造化されたツール出力を受け取り、ホスト仲介型のブリッジを通じて通信できる。チームは、コンテンツ、ネットワークの送信先、ツールアクセスを、インターフェースが実際に必要とする範囲に限定しなければならない。
モデルがツールの選択や呼び出し前に信頼できないテキストへ接触する可能性があるため、プロンプトインジェクションも引き続き重要である。適切に設計されたインターフェースでも、安全でないツールを安全にはできない。機密性の高い操作には、決定論的な検証と、適切な場合には明示的な確認が引き続き必要だ。
AWS のセキュリティガイダンスによると、サーバーレスランタイムセッションには専用の microVM が用意される。ドキュメントによれば、各セッションには分離されたコンピューティング、メモリ、ファイルシステムのリソースが割り当てられる。
同ガイダンスは、責任共有の境界も明確にしている。アプリケーション所有者は、IAM のスコープ、依存関係のセキュリティ、認証情報の取り扱い、入力検証、ネットワークルール、セッションとユーザーの紐付けについて、引き続き責任を負う。
ランタイムセッション内の実行ロール認証情報も慎重に扱う必要がある。microVM 内で実行されるコードは、その環境に提供された認証情報へアクセスできる。そのため、最小権限ポリシーは引き続き不可欠である。
ゲートウェイには、意図したランタイムを呼び出す権限だけを与えるべきだ。ランタイムのリソースポリシーは、無関係なプリンシパルによる直接呼び出しを拒否する必要がある。バックエンドサービスもまた、ランタイムが要求できる内容を個別に制限すべきである。
オブザーバビリティはこれらのレイヤーを横断しなければならない。機密コンテンツを露出させることなく、ホストリクエスト、ゲートウェイトランザクション、ランタイムセッション、ツール呼び出し、バックエンド操作、ユーザーIDを結び付けられるだけのログがチームには必要だ。
これは、1つの会話型リクエストが複数のツール呼び出しを生む場合に特に重要になる。予約の失敗は、ホストの挙動、プロトコル処理、ゲートウェイポリシー、ランタイムコード、バックエンド検証、データ競合のいずれによっても生じ得る。
マネージドコンポーネントはインフラ作業を軽減するが、これらの責任を単一のコントロールに集約するものではない。本番運用への対応可否は、チームが各境界をどれだけ明確に定義し、テストできるかにかかっている。
ポータビリティは依然としてホストの挙動に左右される
プロトコルレベルで説明される MCP Apps はポータブルなリソースだが、真のポータビリティは検出、権限、レンダリング、更新における差異を乗り越えなければならない。
AWS のデモは、ポータビリティに関する主張の最も強い形を裏付けている。1つのサーバーがツール、リソース識別子、ウィジェット HTML、構造化された結果を公開し、対応ホストは同じプロトコルを通じてそのパッケージを利用する。
サーバーは、ホストごとに業務ロジックを別実装する必要がない。また、ユーザーが別の互換クライアントからタスクを開始したという理由だけで、異なるウィジェットバンドルを提供する必要もない。
しかし、共有された転送形式は互換性の第一層に過ぎない。ユーザーは、ウィジェットが表示される前に製品体験全体を経験する。
ユーザーはサーバーへ接続し、認証し、要求される権限を理解し、関連する機能を見つけ、アクションを言語化または開始しなければならない。レンダリング後は、インターフェースを理解し、ワークフローを完了する必要がある。
ホストごとに、これらの段階の感じ方は異なり得る。会話による発見を重視するものもあれば、アプリケーションディレクトリを提供するものもある。外部アクションごとに確認を求めるものもあれば、承認をまとめて処理するものもある。
レスポンシブレイアウトも別の試金石となる。幅広いデスクトップ上の会話には収まるウィジェットでも、モバイルでは窮屈に感じられる可能性がある。キーボード操作、スクリーンリーダー、色のコントラスト、フォーカス挙動も、ホストのフレーム内で機能しなければならない。
失敗時の処理には特別な注意が必要だ。バックエンドリクエストがタイムアウトした場合、インターフェースは操作が成功したかのように示すことなく状態を説明すべきである。再試行したアクションが、誤って重複トランザクションを作成してはならない。
バージョニングはさらなる複雑さをもたらす。サーバーがウィジェットとツールのスキーマを更新する一方で、一部のホストはリソースをキャッシュしたり、古い拡張機能リリースをサポートしたりする可能性がある。互換性テストでは、計画的なアップグレードと部分的なロールアウト状態の両方を扱う必要がある。
公式の拡張機能ドキュメントによると、ホストはインターフェースリソースをサンドボックス化された iframe 内でレンダリングし、App Bridge を通じてメッセージを交換する。これにより、通信とポリシー適用のための共通基盤が提供される。
ただし、あらゆる視覚的な詳細まで規定するものではない。これはオープンな拡張機能として妥当な境界だが、複数のクライアント実装で同じアプリをテストする責任は開発者に残る。
したがって問うべきなのは、同一のコードが移動できるかどうかではない。各ホストに届いた後も、そこで生じるタスクが理解しやすく、安全で、信頼できるものとして維持されるかどうかである。
AWS のサンプルも、コンパクトなデータモデルを持つ架空のレンタルサービスを用いている。実際のアプリケーションでは、より大きな結果セット、アカウント権限、規制対象データ、ローカリゼーション、複雑な例外処理が持ち込まれる。
こうした要件は、隠れたホスト依存を明らかにし得る。ある設計が、別のホストにはない特定のビューポート、認証フロー、ファイルピッカー、ブラウザ機能、承認パターンに依存している場合がある。
開発者は、ポータビリティを二値的なプロトコル上の主張ではなく、テスト済みのサービスレベルとして定義すべきだ。中核となるツール契約は一貫して動作し、ホスト固有の表示差異は限定され、文書化されるべきである。
有用なテストプログラムでは、サポートするすべてのホストで同じ重要タスクを実行する。チームは、完了率、エラー時の挙動、認可プロンプト、レンダリング性能、アクセシビリティ、バックエンドへの副作用を比較すべきだ。
その結果、大半のワークフローでは共有ウィジェットを、少数の専門機能ではホスト固有の体験を採用することが正当化されるかもしれない。その場合でも、共通サーバーの価値の多くは維持される。
AgentCore MCP Apps の賭けを試す3つのシグナル
次の段階は、本番導入、ホスト間の一貫性、公開サンプルを超えるセキュリティパターンによって決まる。
第一のシグナルは、組織がこのアーキテクチャを実際のトランザクションサービスへ適応させるかどうかだ。デモはコンポーネントが接続できることを示す。本番導入では、アイデンティティ、認可、オブザーバビリティ、レイテンシー、バージョニング、障害復旧が一体となって試される。
アカウント固有のデータを扱う公開事例は、この主張をより強く裏付けるだろう。大幅なバックエンド変更を強いることなく、既存サービスの前面に MCP アダプターを置く実装も同様である。
本番利用の証拠は、AWS の薄いアダプターというテーゼを支持する。チームが繰り返しアプリケーションロジックをカスタムホスト層へ移すなら、この拡張機能が体験を十分に表現できていないことを示唆するだろう。
第二のシグナルは、主要 AI ホスト間で一貫したサポートが得られるかどうかである。開発者は、クライアントの互換性リスト、拡張機能バージョンのサポート状況、複数環境で同一ウィジェットを動かすチームからの報告を注視すべきだ。
ホストの対応マトリクスが広がれば、MCP Apps が配布レイヤーになり得るという主張は強まる。各クライアントが技術的には互換であっても、挙動に大きな差があれば、この主張は弱まる。
重要な指標はチェックボックスではなく、タスク完了である。ユーザーは、ホスト固有のトレーニングなしに、同じワークフローへ接続し、発見し、理解し、完了できるべきだ。
第三のシグナルは、再現可能な本番向けセキュリティ設計の登場である。これらは、ユーザー認証、セッション紐付け、アクション認可、ウィジェットポリシー、監査証跡、信頼できないモデルコンテキストからの保護を対象とすべきだ。
AWS は、AgentCore Runtime の呼び出しに IAM と OAuth の両方の選択肢を文書化している。そのサンプルは利用しやすいデモを優先する一方、本番ガイダンスではアプリケーション所有者に相当な責任を課している。
認証済みの公開 MCP Apps 向けに明確なリファレンスアーキテクチャがあれば、その隔たりを縮められる。独立したセキュリティレビューと導入テンプレートは、インフラに関する主張だけよりも強い証拠となる。
開発者は、AgentCore Gateway セッションがどのように進化するかにも注目すべきだ。AWS のドキュメントによると、ゲートウェイ管理の MCP セッションは状態を保持し、繰り返しの初期化を減らせる。ステートフルな機能には、慎重なアイデンティティ管理とライフサイクル制御が必要である。
エンタープライズの購買担当者にとって、差し迫った判断は、すべてのインターフェースをチャットに置き換えるべきかどうかではない。対話的な会話型画面が、別の孤立したアプリケーションスタックを生み出さずに、確立済みの業務サービスを再利用できるかどうかである。
開発者にとって AWS のサンプルは、その仮説を検証する具体的な出発点となる。架空の Lambda サービスを管理された内部 API に置き換え、最初のツールを読み取り専用に保ち、互換ホスト間で挙動を比較するとよい。
ウィジェットがホストについて置いている前提をすべて文書化する。ツール呼び出しは信頼できない入力として扱い、セッションを認証済みユーザーに紐付け、認可はデータを所有するシステムの近くに置く。
Amazon Bedrock AgentCore MCP Apps には、プロトコル図だけではない、信頼できるデプロイパターンが今や存在する。未解決の問いは、実際のアイデンティティ、トランザクション、ホスト差異がシステムに入ってきたとき、チームがそのポータビリティを維持できるかどうかだ。
妥当な次の一手は、テキストでは扱いにくい構造化ワークフローを1つ選び、エンドツーエンドで検証することだ。対話型ウィジェットは、制御を弱めることなく、複数のホストでユーザーの負担を減らせるのか。その結果は、さらに洗練されたデモよりも、このモデルについて多くを語るだろう。