AWS、AgentCore Runtimeセッション内のウェブアプリ実時間プレビューを紹介、ポート許可と毎回認証が必要

Published · AI Daily — AI-assisted deep research, methodology & disclosure

AWSは2026年10月30日、Amazon Bedrock AgentCore runtimeのセッション内でコーディングエージェントがウェブアプリを編集する間、開発者が変更をライブでプレビューする手順を紹介した。例ではViteの開発サーバーをエージェントと同じセッションで動かし、ローカル画面の左側にチャット、右側にサイトを表示する。ファイルが保存されると画面も変わる。

AWSは2026年10月30日、Amazon Bedrock AgentCore runtimeのセッション内でコーディングエージェントがウェブアプリを編集する間、開発者が変更をライブでプレビューする手順を紹介した。例ではViteの開発サーバーをエージェントと同じセッションで動かし、ローカル画面の左側にチャット、右側にサイトを表示する。ファイルが保存されると画面も変わる。これは開発とレビューのための例で、セッションのURLが一般公開の本番ホスティング先になるという話ではない。表題のpreviewはプレビュー操作であり、サービスの提供段階を告げる発表ではない。

Session endpointは一つのruntimeセッションに対応する。runtimeを作る際、開発者は許可するポートを一つから五つの項目で指定し、各項目には単一ポートか範囲を入れる。例では8090がVite、8081がエージェントの状態表示である。呼び出し用のエージェントは8080で動くが、このポートはSession endpointの許可リストにはない。プロンプトは別のInvokeAgentRuntime API経由で届く。そのAPIの応答ヘッダーからSession endpointのURLを取得する。外側の接続はHTTPSの443番を使い、ホスト名の先頭部分で内部の対象ポートを選ぶ。HTTP/1.1、HTTP/2、SSEやgRPC、WebSocketの通信を中継できる。

Session endpointへの各リクエストには認証が必要である。IAM設定ではSigV4署名、インバウンドJWT認可機能の設定ではbearer tokenを使う。ブラウザーがページ内のすべてのリソース要求やWebSocket接続に自力で資格情報を加えることはできない。そこで例はSDKのクライアントでlocalhost:8088にローカルの転送先を開く。このプロセスが開発者の資格情報を付け、遠隔セッションの8090へ送る。プレビュー画面自体はlocalhost:8087で提供される。二つのローカルポートは役割が異なり、いずれも無認証の公開入口ではない。

手順には、対応するAWSリージョンのアカウント、IAMロールとS3とruntimeを作成する権限、Python 3.10以上と所定のAgentCore・boto3版、Node.js 22以上、BedrockでのClaude Haiku 5.5利用権限が必要と記される。サンプルはNodeのエージェントとサイトをzipにまとめてS3へ送り、直接コードデプロイでruntimeを作る。Viteはセッション内の0.0.0.0で待ち受け、Session endpointから届くようにする。NotebookはInvokeAgentRuntimeでセッションを起動し、応答のURLを使ってローカル転送とプレビューを開く。

利用者の変更依頼はInvokeAgentRuntimeを通り、ウェブ用ポートの中継を通らない。例のエージェントのファイルツールはサイトのフォルダー内に読み書きを限定する。保存後はViteがWebSocketでホット更新を送り、認証されたSession endpointとローカル転送を通って開いているページを更新する。許可された8081番では状態表示にもアクセスできる。許可外ポートは403、資格情報の欠落は403または401、許可ポートに待受先がなければ502、終了済みセッションは404になる。これらruntime側の拒否はアプリ自身のエラーと区別できる。

AWSによれば、runtimeは転送前に自身の認証ヘッダーを取り除き、CloudTrailのデータイベントとしてInvokeAgentRuntimeProxyを記録できる。ただしデータイベントは既定では記録されず、Event historyにも表示されない。記録にはtrailまたはevent data storeを作成し、AWS::BedrockAgentCore::Runtimeを対象とするadvanced event selectorを設定する必要がある。ただしサイトとエージェントは同じセッションを共有し、両者を別々の権限領域に分けるわけではない。実行ロールは必要最小限にすべきだ。セッションの計算資源が置き換われば接続は切れ、永続ストレージがなければ編集内容も残らない可能性がある。URLはセッション期間中だけ有効で毎回認証を要する。利用者向けに配信するアプリは別途デプロイし、サンプルのruntimeやS3・IAM資源は使い終えたら削除して課金を止める。

Sources

FAQ

例の8080、8081、8090、ローカル8087、8088はそれぞれ何ですか?

8080は別のInvokeAgentRuntime APIで呼ばれるエージェント用で、Session endpointの許可ポートではない。セッション内の8090はVite、8081は状態表示である。ローカルの8088はSDKによる認証付き転送、8087はチャットとサイトを並べたプレビュー画面を提供する。外側の接続はHTTPSの443番を使う。

変更依頼とViteのホット更新はそれぞれどの経路を通りますか?

利用者の依頼はInvokeAgentRuntime経由でエージェントに届き、エージェントがサイト内のファイルを編集する。保存をViteが検知し、WebSocketのホット更新を認証されたSession endpointとローカル8088番経由で8087番のプレビューへ送る。エージェント呼び出しとウェブ表示の経路は別である。

Session endpointは公開本番サイトに使えますか。アクセスと永続性の限界は何ですか?

直接の公開本番サイトには使えない。端点は一つのセッション期間だけ有効で、毎回認証とポート許可が必要だ。許可外ポートは403、待受先がない許可ポートは502、終了したセッションは404になる。計算資源が置き換わると接続が切れ、永続ストレージがなければ編集も失われ得る。利用者向けには別途デプロイする。