AWSが複数AIエージェントの共有ファイルシステム協調を可能にする「Runtime Instances」を発表 — EC2インフラ管理なしで最大14日間の長期ワークフローに対応

8月7日、AWSが「Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore」と題した記事を公開した。Amazon Bedrock AgentCoreに新たに追加されたRuntime Instancesは、複数AIエージェントが共有ファイルシステムを介して協調し、EC2の直接管理なしに最大14日間の長期ワークフローを実行できるマネージドコンピュート環境だ。「AIエージェントをプロトタイプから本番環境に持ち込んだ瞬間に、状態管理・エージェント間連携・GPUアクセスといったインフラ課題が一気に顕在化する」という現場の痛点に直接応えるサービスとなっている。

プロトタイプから本番環境への壁

AIエージェントをプロトタイプから本番環境に移行すると、インフラの課題が一気に増える。複数ステップのワークフローを数時間・数日にわたって実行する際の状態保持、エージェント間の協調、GPUアクセスといった要件だ。

Amazon Bedrock AgentCoreにはすでに「runtime microVMs」（最大8時間のステートフルな実行環境）が存在するが、複数日にわたる連続稼働・GPU利用・同一ホスト上での複数エージェントの協調が必要なワークロードには対応しきれなかった。これまでこうした要件を満たすには、EC2インスタンスのプロビジョニング、ネットワーク設定、セッション管理、スケーリング、監視を自前で組み合わせる必要があった。

今回発表されたRuntime Instancesはそれらをマネージドサービスとして提供する。

※編集部の考察：マルチエージェントフレームワーク領域ではAzure Container Apps（Dynamic Sessions）やGoogle CloudのVertex AI Agent Engine（Reasoning Engine）も永続的なエージェント実行環境を提供しており、各社の競合構図が明確になってきている。AWSのRuntime Instancesが「共有ファイルシステムによるエージェント間協調」をファーストクラスの機能として押し出している点は、他社との差別化軸として注目に値する。

Runtime Instancesの核心：共有ファイルシステムによるエージェント協調

Runtime Instancesの最も実用的な特徴は、同一セッション内の複数エージェントが共有ファイルシステムを介して協調できる点だ。メッセージパッシングもAPIコールも不要で、あるエージェントが書いたファイルを別のエージェントがそのまま読める。

記事では「コードライター」と「コードレビュアー」の2エージェント構成のデモが示されている。

コードライター（抜粋）：

writer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",  # 元記事コードのまま引用
    system_prompt=(
        "You are a senior Python engineer. "
        "Given a task, return ONLY a single Python code block — no prose."
    ),
)

@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
    session_dir.mkdir(parents=True, exist_ok=True)

    code = str(writer(task))
    (session_dir / "code.py").write_text(code)

    return {"agent": "writer", "wrote": str(session_dir / "code.py"), "code": code}

コードレビュアー（抜粋）：

reviewer = Agent(
    model="us.anthropic.claude-sonnet-4-5-20250929-v1:0",  # 元記事コードのまま引用
    system_prompt=(
        "You are a strict Python code reviewer. "
        "Given code, return 3 bullet points: bugs, style, suggestions."
    ),
)

@app.entrypoint
def handler(event, context):
    session_id = getattr(context, "session_id", None) or event.get("session_id")
    code_path = SHARED_DIR / session_id / "code.py"
    code = code_path.read_text()
    review = str(reviewer(f"Review this code:\n\n{code}"))

    return {"agent": "reviewer", "read": str(code_path), "review": review}

モデル識別子claude-sonnet-4-5-20250929-v1:0は元記事のコードサンプルをそのまま引用したものだ。実際に利用する際はAmazon Bedrock のモデルID一覧で最新の対応モデルを確認されたい。

設計上のポイントは2つある。第一に、@app.entrypointデコレータだけで済む最小限のパッケージングだ。既存のPythonエージェントコードへの変更量が極めて少なく、LangGraphやCrewAIなど主要フレームワークで書かれたエージェントをそのままデプロイできる。第二に、同一のsession_idを2つのエージェントに渡すだけで共有セッションが成立するシンプルな設計だ。ライター→レビュアーの間にデータ転送は一切発生しない。

このパターンは2エージェントに限らない。同じセッションディレクトリを参照するテストエージェント、ドキュメント生成エージェント、セキュリティスキャンエージェントを追加していくだけで、マルチエージェントパイプラインが構成できる。開発者視点では「エージェント間のインターフェース設計をファイルシステムのパス規約に集約できる」という副次的なメリットもあり、複雑なメッセージスキーマ設計の手間が省ける点は特筆に値する。

セットアップの流れ

コンソールから行う場合、手順は3ステップで完結する。

1. Capacity Providerを作成する — EC2インフラの定義（OSはLinux ARM64/x86_64、インスタンスタイプを選択）。デモではc7g.2xlarge（8 vCPU / 16 GiB）を使用。一度作成すると説明文以外は変更不可のため、設定は事前に確認が必要。

2. Runtimeを作成してエージェントをデプロイする — Compute typeとして「Instances」を選び、Capacity Providerを紐付ける。エージェントのパッケージはzipファイルまたはコンテナイメージを指定。Python 3.11〜3.14とネイティブコードをサポート。

3. 同一セッションIDで複数エージェントを呼び出す — コンソールのテスト機能を使う場合、セッションIDをコピーして2つ目のエージェント呼び出しに貼り付けるだけでセッション共有が成立する。

AgentCore CLI、AWS CLI、IaCによる操作も可能だ。

microVMsとの使い分け

Runtime microVMsとRuntime Instancesは排他的な選択肢ではなく補完的な関係として設計されている。軽量なオーケストレーターエージェントはmicroVMsの高速スケーリングを活かしてAPIコールやタスクルーティングを担い、コンパイル・セキュリティスキャン・GUI自動化といった計算集約タスクはInstancesで実行するという構成が想定されている。

仕様まとめ

長期ワークフローへの対応として、セッションのhibernate（一時停止）とresumeもサポートされており、月曜夜に停止して水曜朝に再開しても状態がそのまま維持される。セッションをまたいだ長期記憶が必要な場合はAmazon EBSおよびAgentCore Memoryとの組み合わせが推奨されている。

詳細はRuntime instances: persistent compute for production AI agents on Amazon Bedrock AgentCoreを参照していただきたい。