TITLE

AWS Bedrock AgentCore Runtime GA、AIエージェントのコールドスタートが単純計算で最大15倍近くに

投稿日：2026.09.21

AWS Bedrock AgentCore Runtime GA、AIエージェントのコールドスタートが単純計算で最大15倍近くに

AWSは2026年9月18日、Amazon Bedrock AgentCoreの新ランタイム「AgentCore Runtime」(次世代版、以下V2)を正式提供(GA)したと発表しました。最大の変更点はコールドスタート時間です。従来のV1が5.4〜30秒かかっていたのに対し、V2はコンテナイメージのサイズ(200MB〜2GB)や同時実行数によらず、P75で1.9〜2.0秒まで縮みました。単純計算で最大15倍近い短縮です。ただしV1側の「5.4〜30秒」は観測レンジ、V2側の「1.9〜2.0秒」はP75(パーセンタイル点推定)であり、同じ統計量同士の比較ではありません。V1の最も遅いケースとV2の典型ケースを単純に割った参考値として読んでください。

AIエージェントを本番のサービスに組み込む際、呼び出すたびに数秒〜数十秒待たされるのはよくある壁でした。今回のアップデートは、その壁の実測値を大きく動かすものです。

なぜ最大15倍近く速くなったのか — ゼロから組み立てず、スナップショットを複製する

V1とV2の違いは、起動のたびに何をするかにあります。AWS Japanチームの技術解説によれば、V2はランタイムの作成・更新時に環境をスナップショット化しておき、新しいセッションが来るたびにそのスナップショットから復元する設計に変わりました。V1が呼び出しのたびにゼロから環境を組み立てていたのに対し、V2は「あらかじめ用意した型から複製する」方式に切り替えた、という理解が近いです。AgentCore RuntimeのCreateAgentRuntime / UpdateAgentRuntime / GetAgentRuntime APIにはplatformVersionフィールド(V1 | V2)が追加されており、V2を指定すると準備済みスナップショットからエージェントが起動します。

V1はコンテナイメージ取得→起動→ランタイム初期化→モデル/ツール接続の4ステップをゼロから組み立てる一方、V2はあらかじめ用意したスナップショットを1ステップで復元するだけで済むことを対比させた図。V1は観測レンジ5.4〜30秒、V2はP75で1.9〜2.0秒という数値も併記。

検証数値もこの設計転換を裏付けています。AWS Japanチームの計測では、コンテナベースのエージェント(V2)は平均起動2.1秒・標準偏差261ミリ秒で安定していたのに対し、V1は起動時間が二峰性(速い時と遅い時にはっきり分かれる分布)を示し、最大4.6秒の差がありました。さらに1.12GBの大きめのイメージを使う常駐型エージェントでは、接続確立までの時間がV1で約33秒、V2で約2秒(いずれもp50)という差が確認されています。

速さの副産物 — セッションごとの完全分離と、使った分だけの課金

V2の変更は速度だけにとどまりません。各セッションは独立したmicroVM上で実行され、CPU・メモリ・ファイルシステムが完全に分離されます。複数の顧客・複数のワークロードを1つの基盤に相乗りさせるマルチテナント環境で、この分離は安全性の土台になります。

並んだ複数の密閉ガラスカプセルのうち1つだけが内部から緑色に光っているフラットイラスト。各セッションが独立したmicroVMとして完全に分離されて実行されることを表す。

課金の設計も変わりました。「elastic memory management」と呼ばれる仕組みで、セッション中に不要になったメモリを随時回収し、ピーク使用量ではなく実際の使用量に対して課金されるようになっています。

軽量な仮想化技術でエージェントの実行環境を隔離するという発想自体は、AIエージェント基盤に限った話ではありません。私たちも自律型エージェントの実行環境をどこまで隔離すべきか検討した際、プロセス隔離(Seatbelt/bubblewrap)からgVisor、Firecracker microVM、開発コンテナ、フルVMまでの5段階を整理し、隔離の強度を上げるほど安全性は増す一方でオーバーヘッドも増えるというトレードオフを確認したことがあります。V2は、microVMで分離しつつコールドスタートを1〜2秒台に抑えるという形で、このトレードオフに正面から取り組んでいます。

導入前に押さえておきたい4つの注意点

AWS Japanチームの技術解説は、V2への移行や新規採用の際に設計上気をつけたい点として、次の4つを挙げています。

モジュールスコープとリクエストごとの処理を分ける: V2はスナップショットのライフサイクルに対応する必要があります。起動時に1回だけ実行すべき処理(モジュールスコープ)と、呼び出しのたびに新規実行すべき処理(乱数生成・タイムスタンプ取得・トークンリフレッシュなど)を明確に分離しないと、複数のmicroVM間で同じ値が使い回されてしまう不具合が起こり得ます。
CI/CDのタイムアウト設定を見直す: ランタイムの作成・更新にかかる時間が「秒単位」から「分単位」に変わります。デプロイパイプラインのタイムアウトが短いままだと、正常な処理でも失敗と判定されるおそれがあります。
環境変数のサイズ上限引き下げに注意する: V2では環境変数のサイズ上限が1.5〜2.5KB程度に引き下げられています。既存の設定を移行する前に、上限を超えていないか確認が要ります。
周辺エコシステムはまだ発展途上: GA直後の時点でCloudFormation/CDKは未対応、boto3はバージョン1.43.95以上が必須です。Infrastructure as Codeで運用している場合は、対応状況を確認してから移行時期を決めるほうが安全です。

まとめ

V2は「毎回組み立てる」設計から「あらかじめ用意したものを複製する」設計へ転換しました。速度・分離・課金の3つが同じ設計判断から同時に改善されているのは、対症療法でなく基盤の作り方を変えた結果です。AWSリージョンは現時点でus-east-1・us-east-2・us-west-2・eu-west-1・ap-northeast-1(東京を含む)の5つに限られているため、対象リージョンで動かしている、あるいは動かす予定があるチームから確認するのが最初の一歩です。