Amazon Bedrock AgentCore RuntimeのAG-UIプロトコルについて整理したい

はじめに

AG-UIは、AIエージェントとフロントエンドをつなぐイベントベースのプロトコルです。

現在、AWSのAmazon Bedrock AgentCore Runtimeでもサポートが進んでいます。

Amazon Bedrock AgentCore には、RuntimeというAIエージェントなどをコンテナでホストできる機能があります。

このRuntimeは、MCPサーバーなら「MCP」、AIエージェントなら「HTTP」のように用途に応じてプロトコルを選択することができます。

その中に「AG-UI」というプロトコルが3月頃に追加されたので、何に使うプロトコルなのかを調べたいと思います。

AWSメインのAIエージェント構築する場合

AWSメインでAIエージェントを構築しようとすると、有力パターンとしては「StrandsAgetns + Amazon Bedrock AgentCore」構成があるかなと思います。

ユースケースによって、フロントエンドなどUIを必要としないアンビエントエージェントのようなパターンもありますが、今回はWebアプリケーションを前提に考えてみます。

Strands Agents とは

Strands Agents は、AWSが2025年5月に発表したオープンソースのAIエージェントSDKです。
数行のコードでAIエージェントを実行できるシンプルさが推しポイントです。

Amazon Bedrock AgentCore とは

Amazon Bedrock AgentCore は、AIエージェントの構築・デプロイ・運用を一貫してサポートするAWSのプラットフォームです。プラットフォームというだけあって、なかなかに多機能です。

主なサービスとして、コンテナでホスティングの Runtime、
会話履歴の管理ができる Memory、
既存APIなどをエージェントのツールとして公開する Gateway、
エージェント向けのID管理(APIキーとか)を行う Identity
などがあります。

Amazon Bedrock AgentCore Runtime とは

Amazon Bedrock AgentCore Runtime は、AIエージェントをコンテナとしてホスティングするための実行環境を提供してくれます。
エージェントのコードをパッケージングしてデプロイすると、Runtimeが呼び出しエンドポイントを提供します。
つまり、先ほどのStrands Agentsでエージェントを実装して、Runtimeにデプロイしたら、あっと言う間にエージェントを構築できます。

この辺りは、詳細は網羅的にまとめられている以下の神資料をご参照ください。

AG-UIの登場

AG-UIはフロントエンド と AIエージェントをつなぐプロトコル

AG-UIは、2025年5月にCopilotKitが発表したオープンソースのプロトコルであり、
AIエージェントとフロントエンド間でJSON形式のメッセージをリアルタイムに通信することで実現します。

CopilotKitは、AIエージェントをアプリケーションに組み込むためのオープンソースのフレームワークです。

https://www.copilotkit.ai

これをアプリケーションに落とし込むと、以下のような構成になります。

ここでは通信方式として、一方向通信である「サーバ送信イベント(SSE)」 を前提とします。
なお、AG-UIは通信方式に依存しないため、WebSocketなどでも動作します。

さらにフロントエンドとAIエージェントのつなぐために、「AG-UIクライアント」が必要になります。

前回、AG-UIとAWSのStrands Agentsの関係性については記事にしました。

Amazon Bedrock AgentCoreのサポート状況

AgentCore + Strands AgentsでAG-UIを使ったAIエージェントを実装する場合、大きく以下の2点の考慮が必要です。

レイヤー	内容
AgentCore Runtime	RuntimeのプロトコルにHTTPまたはAGUIを設定する
Strands Agents側の実装	ag_ui_strands などのアダプタを使い、Strands Agents の出力を AG-UI イベントへ変換する

ポイントは、Runtimeのプロトコルに AGUI を指定しても、Strands Agents の出力が自動で AG-UI イベントに変換されるわけではない、という点ですかね。
AG-UI イベントへの変換は、エージェント実装側で行う必要があります。

とうわけで、Runtime側のサポート状況から見ていきます。

Amazon Bedrock AgentCore RuntimeでAG-UIがサポート

AgentCore Runtimeは、ユースケースに応じて複数のプロトコルをサポートしています。そして、2026年3月13日頃に「AGUI」もサポートしました。

プロトコル	ポート	役割
HTTP	8080	RuntimeでAIエージェントやHTTP/SSE アプリケーションをホストする場合
AGUI	8080	RuntimeでAIエージェントをホストし、アプリケーションとAG-UIでやり取りする場合
MCP	8000	RuntimeでMCPサーバーをホストし、AIエージェントがツールとして呼び出す場合
A2A	9000	RuntimeでAIエージェントをホストし、他のAIエージェントとやり取りする場合

IaCの対応状況
2026/5/10時点でCloudFormation対応済み、CDKはPRがマージでリリース待ちです。
https://github.com/aws/aws-cdk/pull/37570

Runtimeに従来のHTTPを指定してもAG-UIは動作する

AG-UIは、通信プロトコルに依存せず、HTTP/SSEやWebSocket上で流れるイベントベースのプロトコルです。
そのため、RuntimeがAGUIをサポートする前から、HTTPでAG-UI対応のAIエージェントを動作させることができます。

AG-UI形式のイベント変換などもStrands Agentsの中のロジックでやります。

ドキュメントを見ると、AgentCore Runtime の AGUIプロトコルは、ポートやパスなど HTTPと大体一緒です。
違いとしては、ユースケースやリクエスト/レスポンス周りの実装の話です。

項目	HTTP	AGUI
ユースケース	通常の REST API 的なリクエスト/レスポンス JSON/SSE によるストリーミング WebSocket による双方向通信	ユーザー向けアプリケーションと AI エージェントをつなぐ AG-UI 通信 SSE または WebSocket で AG-UI イベントをやり取りする
コンテナ	ホスト：0.0.0.0 ポート：8080 プラットフォーム：ARM64コンテナ	ホスト：0.0.0.0 ポート：8080 プラットフォーム：ARM64コンテナ
パス	/invocations /ws /ping	/invocations /ws /ping
リクエスト形式	JSON	AG-UI 準拠なら RunAgentInput 形式の JSON
レスポンス形式	非ストリーミング：JSON レスポンス ストリーミング：SSE	SSEでAG-UIイベントを返す
認証	OAuth 2.0 / SigV4	OAuth 2.0 / SigV4

つまるところ、AGUIを指定することで、「このAIエージェントはAG-UIでアプリケーションとやり取りするよ」と明示できるところが肝かなと思います。
これにより、開発者はAGUIの仕様を前提に、リクエスト/レスポンス周りを意識して実装を行うことができます。

Strands AgentsなどSDK側のサポート状況

Strands Agents + AgentCore でAG-UI対応のAIエージェントを構築する場合、SDK側では以下を考慮する必要があります。

1. (Must) AG-UIが提供するag_ui_strandsを使用する
2. (Choose) エンドエンドポイント実装として、以下のいずれかを使用する
   • bedrock_agentcore.runtime.が提供するAG-UI向けStarletteヘルパーを使用する
   • ag_ui_strands が提供する FastAPIヘルパーを使用する
   • 特にヘルパーを使用せず、bedrock_agentcore.runtime.BedrockAgentCoreAppの標準機能を使用する

1のag_ui_strandsは、StrandsAgensのレスポンスをAG-UIイベントに変換するため実質必須になります。

Starletteは、Python製のASGI(Asynchronous Server Gateway Interface)フレームワークです。ASGIは、非同期WebアプリとWebサーバーをつなぐためのものです。

1. Strands AgentsにおけるAG-UIサポート

前述したとおり、AG-UIに対応するためStrands Agentsにag_ui_strandsを追加する必要があります。
これはGitリポジトリ的にAG-UI側に存在するため、AWSが提供するものではないです。

再掲になりますが、以下の記事にまとめているので、詳細はこちらをご参照ください。

2. Bedrock AgentCore SDKにおけるAG-UIサポート

Strands AgentsがAgentCoreと連携するためにbedrock-agentcoreというSDKがあります。
RuntimeにHTTPを指定する場合、BedrockAgentCoreAppを使うことになると思います。

またAG-UI向けの機能も提供されています。提供元がAWS or AG-UIで分かれています。

• bedrock_agentcore.runtimeが提供するStarletteヘルパー(AWS提供)
• ag_ui_strands が提供するFastAPIヘルパー(AG-UI提供)

観点	bedrock_agentcore.runtime.AGUIApp	ag_ui_strands FastAPIヘルパー
提供元	AWSのBedrock AgentCore SDK	AG-UIのag_ui_strands
ベース	Starlette	FastAPI
AgentCore 前提か	YES	NO(汎用)
作られる主な endpoint	/invocations /ping /ws	/invocations /ping
カスタム処理の入れやすさ	高い /invocations に来たときの処理の中で自由に差し込める	低い /invocations の処理はヘルパー内部で定義される

なので、AgentCore Runtimeにエージェントをデプロイする前提であれば、カスマイズ性も高いAGUIAppを使用しておくのが良いのかなと思います。

bedrock-agentcore.runtimeには、AGUIAppを抽象化した以下の関数も提供されています。

• build_ag_ui_app
• serve_ag_ui

AGUIAppのソースコード

上記PR(使い方のサンプルも載ってます)

ag_ui_strands FastAPIヘルパーのソースコード

まとめ

ざっくりとですが、気になってたRuntimeのHTTPとAG-UIの違いを整理してみました。

AG-UIに対応するAIエージェントを実装したい場合、どちらかというとStrandsAgents側の実装が全てになりそうです。

この辺りの開発者の実装量も今後減ったり、現時点で乱立しているSDK周りの実装も整理されてくると嬉しいなーと思ってます。

AgentCore自体はAWSとしても力を入れているサービスであるとは思うですが、AG-UIがどんどん使われないと整備の優先度は下がりそうですよね...

おまけ： AG-UIの登場からAWSでサポートされるまでの流れ by CloudeCode

誰得情報ですが...

日付	主体	説明
2025-05-12	CopilotKit	AG-UI発表。JSONイベントをストリームするイベントベース・軽量・フレームワーク非依存なプロトコルとして登場
2025-05-28	AG-UIコミュニティ	Issue #35「Add AWS Strands Agent Support」作成。AWSからではなくAG-UI側からの働きかけ
2025-11-04	コミュニティ	Issue #151「Add support for AG-UI Protocol」作成（AWS SDK repo）。AWS SDKへのAG-UIシリアライズ処理の追加要望
2025-12-03	AG-UI repo	PR #675 merge。StrandsAgent wrapper追加。Strands→AG-UIイベント変換のフレームワークアダプターが完成
2026-01-14	AWS	Issue #151 close。「AgentCore SDKはfoundational building blocksでありagent frameworkではない」としてclose。Strands側を案内
2026-03-13	AWS	AgentCore Runtime AG-UI正式サポート発表。インフラレベルでAG-UIをデプロイプロトコルの1つとして位置づけ。認証・セッション分離・スケーリングを担う
2026-03-16	AG-UI repo	AG-UI docs更新（PR #1315）。AgentCore Runtimeが「Infrastructure / Deployment」として追加。AWS Strandsとは別レイヤーで整理
2026-03-17〜18	AWS	PR #350 open → merge。AGUIApp・serve_ag_ui・build_ag_ui_appをSDKに追加。目的はフレームワークアダプターではなくボイラープレート削減