AWS AgentCore Runtime、セッションの大容量化とファイルシステムのマウントに対応

Amazon Web Servicesは2026年11月12日、次世代のAmazon Bedrock AgentCore Runtimeを拡張し、エージェントセッションの大容量化、確約ベースライン料金、動的なファイルシステムのマウントに対応した。AWSによると、ハードウェア分離を維持しながら、セッションの起動を最大15倍高速化できるという。

更新されたランタイムは、北米、南米、欧州、アジア太平洋地域のAWSリージョンで利用できる。AgentCore Runtimeは、さまざまなフレームワークやモデルを使ったエージェントの構築を支援するAWSのプラットフォーム、AgentCoreに含まれるマネージドコンピューティングレイヤーだ。プラットフォーム全体では、認証、アクセス制御、可観測性も提供している。

今回のリリースは、2026年9月18日に発表されたAgentCore Runtime V2に続くものだ。V2では、スナップショットを使った起動とメモリの解放が導入された。AWSは当時、コンピューティングとストレージの拡張、確約ベースライン料金を今後提供する機能として挙げていた。今回のアップデートでは、ファイルシステムのマウントとともに、これらの機能の多くが利用可能になった。

ウォームプール不要でセッションを大容量化

各セッションで最大8 vCPU、32 GBのメモリを利用できるようになり、最大10 GBのコンテナイメージにも対応した。AWSによると、これは前バージョンの4倍のコンピューティング能力に相当する。また、イメージのサイズや同時実行数にかかわらず、セッションは2秒未満で起動するため、コールドスタート対策として顧客がウォームプールを管理したり、クラスターを事前にプロビジョニングしたりする必要がなくなる。

起動時には、初期化を繰り返すのではなく、スナップショットを復元する。AgentCoreは一度、正常なコンテナ環境を準備して初期化済みの状態を取得し、新しいインスタンスごとにそのスナップショットを復元する。そのため、モデルのアーティファクトの読み込みや静的設定の取得といった作業を、コールドスタートのたびに繰り返す必要がない。

Coinbaseのエンジニアリング担当VP、Siwei Shen氏は、本番環境での成果について次のように述べた。「次世代のAgentCoreランタイムに移行したことで、エージェントセッションのコールドスタートが、ピーク時のトラフィックでも約1分から5秒未満に短縮されました。また、30秒を超える起動遅延がなくなり、週あたりのエージェント利用量が2倍以上に増えた状況でも、これを実現できました」

Mission Cloudによると、両バージョンのランタイムで同じ自然言語クエリのワークロードを実行した初期比較では、推論リクエストのコールドスタートが35％、ヘルスチェックの起動が77％高速化し、測定されたランタイムの呼び出しあたりのコストが17％低下した。同社のエージェントは、ユーザーが複雑なデータシステムを操作しなくても、不動産や販売に関するインサイトを取得する。

メモリの解放とベースライン料金

AWSは、アイドル時間中のメモリ料金の仕組みも変更する。エージェントがメモリを解放すると、ランタイムは数分以内にそれを回収し、アイドル状態のエージェントの使用量をゼロまで縮小する。AWSによると、自然な間隔を挟んで複数ターンにわたる処理を行うエージェントでは、セッションあたりのメモリ消費量を最大68％削減できる。この変更により、メモリを使わなくなった後も、セッションのピーク割り当て量に基づいて課金される従来の仕組みが改善される。

常時稼働するエージェント向けの確約ベースライン料金では、セッションごとにメモリのベースラインを設定し、その量を最低料金として課金する。必要に応じて、ベースラインの4倍まで利用量を増やせる。AWSによると、安定したワークロードに適用されるこの予測可能な料金は、AWS Lambda MicroVMの料金を基準としている。一方、利用量に変動が大きいワークロードや、使用量をゼロまで縮小するワークロードには、従量課金が引き続き適用される。

Zuoraによると、新しいランタイムでは、多くのユースケースで呼び出しあたりのメモリ使用量が約60％削減された一方、レイテンシーを安定させたまま、より多くのトラフィックを処理できた。

ストレージ、分離、デプロイの制限

各セッションは引き続き、ハードウェアレベルで分離された専用のFirecracker microVM上で実行され、独自のID、アクセスポリシー、監査証跡を持つ。エージェントは、FUSEに対応したAmazon S3バケットなどのファイルシステムを動的にマウントし、作業内容を保存できるようになった。AWSによると、ジョブの実行中、データは一貫した制御のもとでセッションの信頼境界内にとどまる。これにより、分離の対象がコンピューティング環境だけでなく、さらに広がる。

セッションごとにストレージフォルダーを限定する機能は、今回の発表時点ではまだ提供されていない。AWSによると、re:Inventまでにセッション単位の認証情報を導入し、各セッションを専用のストレージフォルダーに紐付ける予定だ。これにより、マウント機能に、よりきめ細かな制御が加わる。

現行のV2ドキュメントには、デプロイに関する違いも記載されている。V1がデフォルトであるため、V2はオプトイン方式となっている。ただし、 platformVersion に設定されている場合を除き V2。V2ランタイムの作成または更新には、AWSがスナップショットを準備する間、数分かかる。また、コンテナは自身の /ping エンドポイントを通じて、120秒以内に正常な状態を報告する必要がある。これらのセットアップ時間は、セッションのコールドスタートのレイテンシーとは別のものだ。

セッションは最大8時間継続できるが、15分間操作がない場合、セッションの有効期間の上限に達した場合、または正常な状態でなくなった場合には終了する。セッションの状態は一時的なもので、終了時にはmicroVMが破棄され、メモリがサニタイズされる。

今回のリリースにより、セッションのコンピューティング、メモリ料金、ジョブデータが、1つのマネージドランタイムモデルに統合された。未完了なのは、ストレージをきめ細かく分離する機能だ。セッションごとのストレージ限定は、実行環境から保存済みのエージェント作業にまでランタイムの分離保証を広げるために残された最後の段階となる。