Amazon Bedrock AgentCoreに新オプション「Runtime Instances」が登場、最長14日間の実行とGPU・ファイル共有に対応

要点

• 米AWSは、AIエージェントのホスティング基盤「Amazon Bedrock AgentCore」において、新コンピュートオプション「Runtime Instances」を発表した。

• 従来のサーバーレス構成（MicroVM）のセッション上限8時間に対し、最長14日間の長時間稼働とAmazon EBSによる永続ストレージに対応した。

• 1台のEC2インスタンス上で複数エージェントを稼働させ、同一のファイルシステムやGPUを共有しながら協調動作させることが可能となった。

• 音楽生成AIモデルをGPUで実行するエージェントと解析エージェントが連携する音楽制作パイプラインなどの構築手法が示されている。

• 米Amazon Web Services（AWS）は2026年9月30日、生成AIエージェントのホスティング基盤「Amazon Bedrock AgentCore」において、長期間にわたるワークフローに対応する新コンピュートオプション「Runtime Instances」を発表した。従来のサーバーレス型実行環境に加え、AWSが管理するEC2インスタンスを活用した実行基盤が提供される。これにより、複数日にわたるセッションの維持やGPUの利用、複数エージェント間でのインスタンス共有が可能になるという。

複数エージェントによる長時間ワークフローへの対応

AWSによると、AIエージェントの活用が単一目的のタスクから複数エージェントによる協調システムへと移行するにつれて、インフラストラクチャに対する要件が変化しているという。顧客からの問い合わせ対応など単発のエージェントであれば、実行時間が短くセッションが独立したサーバーレス環境で十分に処理できる。しかし、複数のエージェントが数日間にわたってコンテキストを共有し、互いの生成物を積み重ねながら共同作業を行うクリエイティブワークフローなどでは、数時間で上限に達する従来のサーバーレスセッションでは対応が難しかったと説明している。

今回発表されたRuntime Instancesは、こうした長期間かつ継続的な処理を必要とするエージェントワークフローに向けて設計された実行基盤である。

サーバーレス「MicroVM」と「Runtime Instances」の違い

Amazon Bedrock AgentCoreでは、従来のサーバーレスオプションである「MicroVM」と、新オプションである「Runtime Instances」の2つのコンピュート環境が選択可能となる。

両環境とも、主要なエージェントフレームワーク（CrewAI、LangGraph、LlamaIndex、Strands Agents）や任意の基盤モデルに対応し、エージェント間連携規格「A2A」やツール連携プロトコル「MCP（Model Context Protocol）」、共通のAgentCore Runtime APIをサポートする点、およびコンテナイメージとAmazon S3ソースからのデプロイに対応する点は共通している。

一方で、基盤となるコンピュートモデルには以下のような明確な違いがある。

• セッション期間: MicroVMが最大8時間であるのに対し、Runtime Instancesでは最長14日間の連続稼働が可能。
• インスタンスあたりのエージェント数: MicroVMは1つのランタイムに対して1つのエージェント（1対1）が割り当てられるが、Runtime Instancesは1台のEC2インスタンスで複数エージェント（1対多）をホストできる。
• GPUの利用: MicroVMは非対応だが、Runtime Instancesでは対応するインスタンスファミリーを選択することでGPUへのアクセスが可能。
• ストレージと永続性: MicroVMがセッション単位の一時的なスコープであるのに対し、Runtime InstancesはAmazon EBSによる永続ストレージを利用できる。
• 課金とリソース管理: MicroVMが従量課金であるのに対し、Runtime Instancesはユーザーのアカウント内でEC2インスタンスが実行される。AWS Savings Plansやオンデマンドキャパシティ予約（ODCR）の適用が可能で、スケーリングはキャパシティプロバイダーによって管理される。

同一インスタンス配置によるデータ共有とエージェント間協調

Runtime Instancesにおけるエージェントは、セッション内で実行されるワークロードとして扱われる。同一のキャパシティプロバイダーを共有するエージェントランタイムであれば、共通のセッション識別子（runtimeSessionId）を指定して呼び出すことで、複数のエージェントを同一のEC2インスタンス上に配置（コロケーション）できる仕組みとなっている。

同じインスタンスに配置されたエージェント同士はローカルのファイルシステムを共有できるため、ネットワーク経由でのデータ転送を介さずに、同一のファイルや成果物を直接読み書きしながらタスクを共同で進められる点が特徴だという。

具体例：GPUと共有ボリュームを用いた音楽制作パイプライン

AWSは本機能の実装例として、1台のGPUインスタンスとセッションを共有する3つの特化型エージェント（Compose、Deliver、Screen）による音楽制作パイプラインの構築例を紹介している。

このシステムでは、まず「Composition agent（作曲エージェント）」がプロデューサーからの制作リクエストを受け取り、基盤モデル「Claude Sonnet 4.6」を用いて楽曲の指示書（ミュージカルブリーフ）を作成する。続いて、インスタンス自体のGPUを活用してオープンソースの音楽生成基盤モデル「ACE-Step」を実行し、実際の音声ファイル（.wav）を生成して共有ボリュームに書き出す。

その後、残る2つのエージェント（DeliverおよびScreen）が同じ共有ボリューム上の.wavファイルを直接開き、後続の配信処理や検査レポートの作成などを並行して行う。これにより、プロデューサーのリクエストから再生可能な楽曲データおよび3種類のレポートを出力する一連の流れが、数日間にわたって永続化された単一の共有セッション上で完結できるとしている。