AIエージェントの返答が遅いとき、モデルだけが原因とは限りません。停止中の実行環境を立ち上げるコールドスタートも、最初の待ち時間に加わります。
AWSは2026年9月18日、新しいAmazon Bedrock AgentCore Runtimeを発表しました。メモリーを必要に応じて割り当て・回収する仕組みと、初期化済み環境のスナップショット復元が中心です。AWS公式発表
<style> .ar-summary,.ar-note{padding:1.2rem;margin:1.5rem 0;border:1px solid #cbd8e8;border-radius:16px;background:#eef5ff;color:#172e47}.ar-summary p:last-child,.ar-note p:last-child{margin-bottom:0}.ar-cards{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,210px),1fr));gap:12px;margin:1.5rem 0}.ar-card{padding:1.1rem;border:1px solid #cbd8e8;border-radius:14px;background:#fff;color:#172e47}.ar-card strong{font-size:1.55rem;color:#12637a}.ar-chart{padding:1.2rem;margin:1.5rem 0;border:1px solid #cbd8e8;border-radius:16px;background:#fff;color:#172e47}.ar-row{margin:1rem 0}.ar-track{height:25px;background:#e7edf3;border-radius:3px;overflow:hidden}.ar-bar{height:100%;background:#2d619c}.ar-bar.new{background:#087a64}.ar-axis{display:flex;justify-content:space-between;font-size:.85rem;color:#455b70}.ar-table{overflow-x:auto;margin:1.5rem 0}.ar-table table{border-collapse:collapse;width:100%;min-width:650px}.ar-table th,.ar-table td{padding:.85rem;border:1px solid #cbd8e8;text-align:left}.ar-table th{background:#e7effa;color:#172e47}.ar-note{background:#fff6e7;border-left:5px solid #995b00}.ar-steps li{margin:.7rem 0} </style>① AWSの空エージェント試験では、新RuntimeのP75起動時間は200MB～2GBで約2秒。
② これはモデル呼び出しやツール実行を含む、回答全体の時間ではありません。
③ V2へ切り替える前に、自社のイメージ・負荷・コストで新旧を比較します。
AWSは、モデルもツールも呼ばず入力を返す空のecho agentを使用。旧版と新版、5種類のイメージサイズについて、各エージェント5,000回のコールド起動を測定したと説明しています。クライアントはus-west-2のEC2、エージェントはus-east-1で、公開インターネット越しの往復も測定値に含まれます。測定条件
P75は、測定値を速い順に並べたとき75%がその値以下に収まる境界です。平均でも、最悪値でもありません。
各エージェントのコールド呼び出し
200MBから2GBまで
75%点で比較
旧Runtime・200MB：約5.4秒
旧Runtime・2GB：30秒近く
新Runtime・200MB～2GB：約2秒
出典：AWS。棒は同一の線形スケール。「約」「近く」は提供元の表現で、独立検証値ではありません。
約2秒＝回答時間ではありません。 AWSも、これはエージェントコードが最初の要求を処理する前の環境準備時間であり、本番ではエージェントループやモデル呼び出しが利用者の待ち時間の多くを占め得ると説明しています。
従来版はセッションが一度確保したメモリーを、使わなくなっても終了まで保持する設計でした。新版は小さな常駐量から始め、必要なページを取り込み、解放または使われなくなったメモリーを回収するとAWSは説明しています。
起動では、コンテナを一度初期化して正常性を確認し、その実行環境をスナップショット化。新しいインスタンスは起動・初期化を繰り返す代わりに、その状態を復元します。さらに一時的なキャッシュなどを除き、スナップショットを小さく保つ設計です。仕組みの説明
| 観点 | 従来版 | 新版 | 自社で確認 |
|---|---|---|---|
| メモリー | セッションの高水準を保持 | 利用に応じ割当・回収 | 実利用量と請求額 |
| 起動 | 環境を起動・初期化 | 初期化済みsnapshotを復元 | P50/P75/P95と失敗率 |
| 指定 | 既存設定 | `platformVersion: V2` | 対応リージョン・依存関係 |
AWSは新版について、単価は高くても課金対象GB-hoursが減り、多くのエージェントでは請求が下がると説明しています。ただし公開記事だけから、自社の削減率は算出できません。長時間ほぼ一定量を使う処理と、短いピークの後に待機する処理では効果が異なります。
以下は本稿の検証提案です。記事制作時にAgentCore環境でベンチマークを実行した結果ではありません。
公式発表では、Runtime作成または更新時にplatformVersionをV2へ設定すると案内しています。実際のCLI/API形式、利用可能状況、価格はAgentCore Developer Guideで実行時に確認してください。
{
"platformVersion": "V2"
}開発者は、巨大なイメージを放置してよいと解釈せず、依存関係・初期化・モデル呼び出しを個別計測します。保守担当は、snapshot作成時と実行時で変わる設定や認証情報を分類します。
運用担当は起動時間だけでなく、処理完了時間、タイムアウト、再試行、費用を同じセッションIDで追います。企業やコンサルは、提供元ベンチマークの「空agent」と自社業務の差を明記し、削減見込みではなく小規模実測を導入判断に使います。
公開値はAWS自身の測定であり、第三者による再現結果ではありません。2リージョン間の公開通信を含む一方、モデル・ツール・VPC接続・実業務コードは含みません。P75だけでは遅い側25%の分布も分かりません。
またAWS記事の「coming soon」にあるbaseline pricing、x86、より大きな計算資源、セッション中断・再開、scoped identityは、9月18日に提供済みの機能と混同しないでください。将来予定は変更される可能性があります。
今回の記事は、9月17日のAgentCoreプロンプト最適化記事の続報ではありますが、評価対象は別です。前回は回答品質、今回は実行基盤の起動・メモリーです。品質向上とインフラ高速化を同じ指標にまとめないことが重要です。
利用可能リージョン、正式な価格、V1からの互換性、P95/P99、実業務でのメモリー課金、将来機能の提供状況を確認します。
今日の一歩は、利用者の待ち時間を「起動・モデル・ツール・後処理」に分解すること。 V2が改善する場所を切り分けてから、移行効果を測りましょう。
最終確認日：2026年9月19日（日本時間）。数値と仕組みはAWSの発表、検証手順は本稿の提案です。