AgentCore Runtime V2がメモリ回収とスナップショット起動を導入、公式テストのコールドスタートは約2秒

AWSは9月18日、Amazon Bedrock AgentCore Runtime V2をリリースし、エージェントセッションのメモリ管理とコールドスタートの方式を更新した。新版でもmicroVMによるセッションの分離を維持しつつ、必要に応じてメモリを読み込み、解放済みのページやアクセス頻度が低下したページを回収する方式に変更した。これにより、長時間のタスクが一時的なピークを過ぎてもリソースを占有し続ける状況を減らす。初期提供は東京を含む5リージョンとなる。[公式発表](https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/)

起動プロセスでは、初期化をスナップショットの作成段階に移している。プラットフォームがコンテナを起動し、ヘルスチェックの成功を待ってから実行環境を保存する。新しいインスタンスはスナップショットから復元されるため、パッケージや静的な設定を繰り返し読み込む処理を減らせる。AWSによると、不要な一時状態を取り除くことで、コンテナイメージの拡大に伴ってスナップショットのサイズも膨らむことを防ぐという。[アーキテクチャの解説](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

この設計では、初期化時に取得した設定を再取得する必要があるか、復元後にネットワーク接続を再確立できるかといった点が、アプリケーションのテスト項目となる。公式の数値自体は、こうしたワークロードの特性を検証したものではない。また、利用者が実際に感じる改善を判断するには、環境の準備が整うまでの時間と、最初の有効な応答が返るまでの時間を分けて計測する必要がある。

公式テストでは、モデルやツールを呼び出さず、入力をそのまま返すだけのエージェントを使い、プラットフォーム自体のオーバーヘッドを切り分けた。クライアントは米国西部から米国東部へリージョンをまたいで呼び出しを行い、バージョンとイメージサイズの組み合わせごとに、コールドスタートを伴う呼び出しを5,000回実行した。イメージサイズが200 MBから2 GBの範囲では、75パーセンタイルのレイテンシは新版が約2秒、旧版が約5.4〜30秒だった。この数値にはリージョン間のネットワーク往復時間が含まれる一方、推論やツールの実行は含まれないため、エージェントのタスク全体の応答時間として扱うことはできない。[テスト方法](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

利用するには、Runtimeの作成時または更新時に、`platformVersion`を`V2`に指定する。AWSのGo SDKでは、9月15日のリリースノートでこのフィールドの追加が記載されており、Runtimeの作成、更新、取得に対応する。これにより、デプロイ用プログラムからプラットフォームのバージョンを明示的に選択し、確認できる。既存システムでは、まず使用中のSDKがこのフィールドに対応していることを確認し、そのうえで代表的なタスクを使って起動時間の分布とメモリ使用量を比較するべきだ。[有効化の方法](https://aws.amazon.com/about-aws/whats-new/2026/09/new-agentcore-runtime-generally-available/)、[SDKのリリースノート](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-09-15)

コストも再計算する必要がある。AWSは、新版ではメモリの単価が高くなる一方、GB-hoursの削減によって総額が下がることを見込んでいると説明している。そのため、常駐データ量の多いエージェントでは、同じ効果が得られるとは限らない。x86対応、セッションの一時停止と再開、より細かなライフサイクル制御は、引き続き今後の機能として挙げられている。[機能上の制約](https://aws.amazon.com/blogs/machine-learning/the-new-agentcore-runtime-elastic-optimized-and-consistently-fast-starts/)

現行ドキュメントでも、セッションの状態は一時的なものとされており、終了後も保持するには別途永続化への対応が必要となる。初期化時のスナップショットはタスクの進捗を保存するバックアップではないため、エンジニアは現時点で利用できる機能に基づいて復旧手順を設計するべきだ。[セッションのドキュメント](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html)