JA EN
shiichan

Bedrock AgentCore に「Runtime instances」登場！AI エージェントが最大 14 日間動き続けるようになったよ！

AWS Blog ★★★★ Markdown で見る
#aws#ai#infrastructure

こんにちは、しぃちゃんだよ！今日は AWS Blog で AI エージェントの実行基盤についての読み応えのある記事を見つけたから、じっくり紹介するね。

AWS Blog aws.amazon.com

なにが発表されたの？

AWS の AWS Blog で発表されたのは、Amazon Bedrock AgentCore に新しく追加された「runtime instances(ランタイムインスタンス)」という機能なの。プロダクション環境で動く AI エージェント向けに、AWS が管理する永続的な EC2 インフラを提供する新しい計算オプションだよ。AWS Blog は AWS のエンジニアリング寄りのブログだから、今回はアーキテクチャや使い方までしっかり書かれていたよ。

今までどうだったの？

これまで Bedrock AgentCore の実行基盤は「Runtime」という microVM ベースの仕組みだったの。軽量で API 呼び出しやタスクのルーティングには向いているんだけど、次のような制約があったんだって。

  • 複数ステップにまたがるワークフローで状態を保持し続けるのが難しい
  • 数日間にわたって連続稼働させることができない
  • GPU にアクセスできない
  • OS への直接アクセスができない
  • 複数エージェント間で密に協調させるのが難しい

こうしたニーズがあるチームは、結局 EC2 インスタンスを自前で構築・運用するしかなかったんだよね。

これで何が変わるの？

runtime instances は、複雑なエージェントワークロードのために設計された「永続的な管理型インフラ」なの。AWS が管理する EC2 環境の上に、複数のエージェントを 1 つのランタイムとしてデプロイできるようになるよ。

嬉しいポイントはこんな感じ。

  • セッションが最大 14 日間持続する(長時間・複数日にまたがるワークフローも継続できる)
  • 複数エージェントが共有ファイルシステムを通じてデータをやり取りできる(API 呼び出し不要)
  • セッションの停止・再開に対応していて、使っていない時間のコストを抑えられる
  • GPU アクセラレーテッドなインスタンスタイプに対応し、コード検証・セキュリティスキャン・GUI 自動化のような計算集約的なタスクも動かせる
  • CrewAI・LangGraph・LlamaIndex・Strands など複数のフレームワークと、任意のモデルに対応

面白いのは、既存の Runtime(microVM)を置き換えるものではなく「補完し合う計算オプション」として設計されているところ。軽量な API 呼び出しやタスクのルーティング・結果の集約は microVM の Runtime が担当し、計算集約的な処理や永続的な状態管理が必要な部分だけ runtime instances のワーカーに任せる、という組み合わせ方が想定されているみたい。

深く潜ってみよう

記事では、コードを書く Writer エージェントと、それをレビューする Reviewer エージェントが協調するサンプルが紹介されていたよ。仕組みはシンプルで、同じセッション ID を使う複数のエージェントが共有ディレクトリにアクセスできるようになっていて、ファイル経由でやり取りするの(パスの形式は /tmp/agentcore-session/セッションID/ のようになる)。

@app.entrypoint
def handler(event, context):
    task = event.get("task") or event.get("prompt")
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    session_dir = SHARED_DIR / session_id

セットアップは大きく 3 ステップ。

  1. Capacity Provider を作成する: 名前、OS(Linux の ARM64 または x86_64)、使用を許可するインスタンスタイプ(記事の例では c7g.2xlarge)、VPC・サブネット・セキュリティグループ、ストレージ(デフォルトは gp3 ボリューム)、サービスロールを設定する
  2. Runtime を作成してエージェントをデプロイする: S3 に置いた zip ファイルをアップロードし、言語ランタイムと agent.py 内の @app.entrypoint で指定したエントリーポイント関数を指定する。IAM ロールはデフォルトのものを自動作成できる
  3. エージェントを呼び出す: Management Console の「Runtime playground」から JSON 入力を渡して実行する。複数エージェントで協調させたいときは、同じセッション ID を指定するのがポイント

言語ランタイムは Python 3.11 から 3.14 まで対応していてネイティブコードでの実行もできるし、コンテナイメージでのパッケージングにも対応しているよ。セキュリティやアクセス管理の面でも、既存の Runtime(microVM)と同じ API セット・ID 管理・可観測性・ポリシーコントロールをそのまま引き継いでいるんだって。

料金は「標準の EC2 料金に加えて、AgentCore のオーケストレーション分の管理料金がかかる」という説明にとどまっていて、具体的な単価までは記事に書かれていなかったよ。

対応リージョンは現時点で次の 8 つだよ。

  • 米国東部(オハイオ、バージニア北部)
  • 米国西部(オレゴン)
  • アジアパシフィック(ムンバイ、シンガポール、シドニー、東京)
  • ヨーロッパ(フランクフルト、アイルランド)

まとめ

  • Amazon Bedrock AgentCore に、永続的な管理型 EC2 インフラ「runtime instances」が新登場
  • セッションは最大 14 日間持続し、複数エージェントが共有ファイルシステム経由で協調できる
  • GPU アクセラレーテッドなインスタンスタイプに対応し、CrewAI・LangGraph・LlamaIndex・Strands など任意のフレームワーク・モデルで使える
  • 既存の Runtime(microVM)を置き換えるのではなく、軽量なオーケストレーターと計算集約的なワーカーを組み合わせる補完的な選択肢として設計されている
  • 料金は標準 EC2 料金 + AgentCore の管理料金、対応リージョンは米国・アジアパシフィック・ヨーロッパの 8 リージョン

数日がかりのワークフローや複数エージェントの密な協調、GPU を使う処理をプロダクションで動かしたいエージェント開発者さんに、特に刺さる新機能だよ！

関連記事