Session endpointsを使い、コーディングエージェントが動かすViteアプリをブラウザーで確認する手順を公開しました。HTTPとWebSocketの通信をセッション内へ転送します。 編集と画面確認の往復を短くする構成です。セッションの認証、公開ポート、寿命を管理し、利用者向けの配信とは別に設計する必要があります。 作成中の画面を同じセッションで見る AWSは10月30日、AgentCore runtimeでエージェントが作るウェブアプリを確認する実装例を公開しました。通常、作ったアプリを別の場所へ配置してから見ると、変更のたびに待ち時間が発生します。記事ではViteのサイトをエージェントのセッションで動かし続け、チャットとプレビューを並べます。ファイル保存に伴う変化をブラウザーで確認する構成です。各セッションは独立したmicroVMで実行されます。Session endpointsは、その中で動くサーバーへ認証付きの経路を設けます。コードの生成結果を、利用者が操作できる状態で確かめるための手順です。 開発者とレビュー担当の往復を変える 対象は、ダッシュボードや製品ページ、試作品を作るコーディングエージェントの開発者です。例では配色の変更を依頼し、作業の進行と画面の変化を一緒に確認します。接続先として許可するポートを指定し、HTTPのメソッドやパス、本文などを転送します。WebSocketも扱うため、開発サーバーの更新通知を利用できます。ブラウザー自体が認証情報を付けられない通信は、SDKのローカルエンドポイントが署名などを加えて中継します。レビューする側には、完成物の画像だけでは分からない操作を試せる可能性があります。ただし画面を開けることが、機能や安全性の検証を完了したことにはなりません。試作品の評価項目と、エージェントの作業を続ける条件を定めることが論点になります。 接続許可とセッションの寿命を管理する URLを知るだけではアクセスできず、各リクエストに認証が必要です。IAM構成では署名とプロキシ呼び出し権限を使い、JWTの構成ではトークンを使います。許可ポートを指定してもサーバーは自動起動しないため、アプリ側の待受設定も必要です。セッションのURLはその寿命に結び付き、作成、試験、レビューに使うものと説明しています。一般利用者へ提供するアプリは別のホスティングへ配置します。運用では、誰がどのセッションを閲覧できるか、終了後にどう接続を閉じるかが論点になります。開発サーバーの公開範囲と実行資源の利用時間も確認対象です。プレビューの便利さと、恒久的なサービスの配信条件を分けて設計することで、試作段階の権限を本番へ持ち越す問題を避けやすくなると見られます。 公開サンプルで接続の境界を確かめる 記事はサンプルのリポジトリーも案内し、別のポートへの接続と拒否されるリクエストを確認する流れを示します。導入時には、正常に表示される画面だけでなく、許可外の接続が実際に拒否されるかを検証することが論点です。複数人で試作品を見る場合は、それぞれの認証と閲覧の範囲を整理する必要があると見られます。セッションが終わった場合の画面や復帰方法も、レビュー手順に影響します。公開サンプルの成功を、自社の権限設計の確認に置き換えないことが重要です。