AWS、Elastic Memory と高速コールドスタートのために Bedrock AgentCore ランタイムを再設計

Amazon Web Services 発表した 2026年9月18日に新しい AgentCore ランタイムを、これは Amazon Bedrock AgentCore の管理されたコンピュート層の再設計版であり、同社はエージェントセッションがメモリを解放するたびにメモリを回収し、コンテナイメージのサイズや同時実行数に関係なく一貫したコールドスタート時間を提供すると述べています。

AgentCore ランタイムは、開発者がインフラを構築または維持することなくエージェントをデプロイおよび実行できる、完全に管理されたコンピュート層です。AWS は、ローンチ以来何千ものチームがこれを使用して本番エージェントを実行しており、最初のバージョンはセッション分離、スケール・トゥ・ゼロ動作、従量課金価格というサーバーレス基盤を確立したと述べています。この消費モデルは引き続き適用され、課金はリソース使用量に基づき、I/O 待機中のアイドル CPU には料金が発生せず、エージェントに作業がない場合はプラットフォームがゼロまでスケールダウンします。

リリースが対処する課題

元のランタイムでは、セッションは割り当てられたメモリを割り当て時からセッションが終了するまで保持し続けます。途中でメモリを回収する仕組みがなかったためです。AWS は、これにより長時間稼働するエージェントやバースト的に動作するエージェントが、メモリが使用されなくなった後も 24 時間体制でハイウォーターマークに対して料金を支払い続けることになり、特に時折スパイクするがほとんどの時間はアイドル状態のエージェントにとって大きな課題となっていると述べました。

起動動作が二つ目の課題でした。AWS は、すでに初期化済みの環境に配置されたセッションは 100 ミリ秒未満で開始すると述べていますが、これを保証するために環境を暖めておくにはコンピュートリソースを確保しておく必要があり、結果として多くのセッションは新しい環境を起動し、イメージを取得し、最初のリクエストが実行される前にエージェントを初期化するコールドスタートから始まります。そのレイテンシはイメージサイズと同時実行数に比例して増加し、特にセッションが集中し、利用可能な環境が少ないバーストトラフィック時に最も悪化します。AWS によると、顧客は余剰環境を常備し、メモリ割り当てを最適化し、容量を削減することで両方の問題を回避してコストを抑えているとのことです。

AWS が測定したこと

プラットフォーム自体がコールドスタートに追加する要素を分離するため、AWS は入力を返すだけの空のエコーエージェントをテストし、モデルやツールは呼び出しませんでした。us-west-2 の Amazon EC2 インスタンス上の Python クライアントが、VPC ピアリングなしでパブリックインターネット経由で us-east-1 のエージェントを boto3 SDK を使用して呼び出したため、各クライアント側測定にはプラットフォーム固有の起動時間に加えて、2 つの AWS リージョン間の往復遅延が含まれます。同社は、デフォルトのアカウントクォータ内で、両方のランタイムバージョンと 5 種類のイメージサイズに対して、エージェントあたり 5,000 回のコールド呼び出しを送信しました。

この測定方法により、AWS は新しいランタイムが 200 MB から 2 GB のイメージに対して P75 のコールドスタートレイテンシが約 2 秒であると報告しました。イメージサイズは影響しません。一方、元のランタイムはイメージサイズが増えるにつれてレイテンシが約 5.4 秒からほぼ 30 秒まで上昇しました。エコーテストでは、エージェント自身のコードは P75 で約 34 ミリ秒で実行され、測定時間のほぼ全てがプラットフォームの起動時間であることが分かりました。AWS は、インタラクティブエージェントの起動時間を隠すために、ユーザーがチャットを開くなどしてエージェントとやり取りを開始した瞬間にセッションを開始し、最初のリクエスト入力中に環境を暖めることを推奨しています。

新しいランタイムの仕組み

新しいランタイムは、完全にプロビジョニングされたフットプリントではなく、小さなメモリプロファイルから各セッションを開始し、ワークロードが必要とするたびに追加メモリをオンデマンドで割り当ててページインします。エージェントがリクエストごとのバッファを解放したり、リクエスト間でキャッシュデータの有効期限が切れたりすると、プラットフォームはセッション終了までメモリを保持させるのではなく、メモリを回収します。AWS は、数十億のセッションにわたる割り当てパターンの分析に基づいて回収動作を調整したと述べています。

コールドスタートは、各エージェントが一度ロードされ、その後スナップショットから実行されるため変化します。ランタイムが作成または更新されると、AgentCore はコンテナを起動し、ヘルスレポートが出るのを待って実行環境のスナップショットを取得します。そのため、モデルアーティファクトのロードや静的設定の取得といった一度きりの初期化は既に完了しています。新しいインスタンスはゼロから初期化するのではなく、このスナップショットを復元します。AWS は、ランタイムがスナップショットからキャッシュと一時メモリを除去するため、コンテナイメージが大きくなってもサイズは概ね一定に保たれ、幅広いイメージサイズで復元レイテンシが安定すると述べています。

課金はメモリモデルに合わせて変わります。新しいランタイムは、エージェントが実際に使用しているメモリに対して、オンデマンドでロードされアイドル時に回収される分だけ課金し、セッション期間中にコンテナイメージ全体をメモリに保持する従来の方式とは異なります。AWS は、この変更を「はるかに少ない GB 時間に対して高いレートが適用される」ものと位置付け、ほとんどのエージェントではフットプリントの減少がレート上昇を上回るため、請求額は減少すると述べました。

プラットフォームのバージョン、リージョン、制限

開発者は、ランタイムを作成または更新する際に platformVersion フィールドを V2 に設定することで新しいランタイムを有効にします（AgentCore 開発者ガイド参照）。V1 がデフォルトで、作成時にフィールドを省略すると V1 ランタイムが生成され、更新時に省略するとランタイムの現在のプラットフォームバージョンが維持されます。V2 は us-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-1 で利用可能です。

V2で作成または更新すると環境が準備されスナップショットが取られるため、ランタイムがREADYになるまで数分かかります。一方、V1ランタイムは数秒で準備完了します。AgentCoreはコンテナの /ping エンドポイントから最初にヘルシーな応答が返ってきた時点でスナップショットを取得し、起動後120秒以内にコンテナがヘルシーと報告しない場合、作成はヘルスチェックエラーで失敗します。また、ガイドによれば、V2は直接コードデプロイ時の環境変数サイズ上限を1.5 KB、コンテナエージェントの場合は2.5 KBに制限しており、V1の4 KBと比較されます。さらに、AWS CloudFormation と AWS CDK は現在 platformVersion の設定をサポートしていません。

スナップショットはランタイムのバージョンとエンドポイントに従って管理され、直接操作されません。AgentCoreはエンドポイントがバージョンを指すときにスナップショットを作成し、エンドポイントが指さなくなると削除します。削除には最大セッション存続時間である8時間かかることがあります。これは、スナップショット上で既に実行中のセッションが終了するまで継続するためです。セッションは専用の microVM で実行され、CPU、メモリ、ファイルシステムが分離され、最大8時間持続し、15分間非アクティブになると終了します。その後 microVM は終了し、メモリはサニタイズされます。

ロードマップと開始

ローンチ以降、AWSは以下の機能を順次提供すると発表しています。セッションごとにメモリの下限を確保し、オンデマンドでバーストできるコミットベースの割引（常時アクティブなセッション向け）、より大容量のRAM、vCPU、セッションストレージ、x86 microVMのサポート、メモリスナップショットによるサスペンド・リジューム機能と、アクティブセッションが終了する前に状態をシリアライズするランタイムフック、そして無人エージェント向けに各セッションにスコープされたIDを付与するセッションコンテキストキーです。

AWSは開発者に対し、AgentCore Developer Guide、GitHubのAgentCoreサンプルリポジトリ、そしてユーザー自身のAWSアカウント内で新しいランタイムのコールドスタートレイテンシを実証するロードテスト例への参照を案内しています。