TL;DR

自作の AWS 運用エージェント (Converse API の tool use ループ + read-only ツール4種) を、同じコードのままローカル実行と Amazon Bedrock AgentCore Runtime の2通りで動かして比較しました。

移行作業は「Lambda の zip デプロイ」とほぼ同型でした。60行弱のラッパ + arm64 向け zip + Terraform で、Docker も ECR も不要 (直接コードデプロイ)。
同じコード・同じ質問なのに、ツールの選び方が変わりました。絞り込みのフォローアップに対し、ローカルではツールを呼ばず前回結果から回答 (steps=0)、Runtime では無料のログ検索ツールを自発的に追加。方式の差ではなく LLM の非決定性で、エージェントの出力は固定値の一致を前提にできない — 回帰テストは観点評価で設計する必要があることが、2回の実行で体感できます。
今回の構成では、Runtime のセッション内でプロセスメモリ (会話履歴) が生き残りました。アプリの会話履歴 (ただの Python リスト) が microVM のメモリに残り、コードを変えずにマルチターンが成立。アイドルタイムアウトが「会話の寿命」になります。
レイテンシは今回も生成が支配。Runtime 化のオーバーヘッドは生成時間の揺れに沈み、アイドル後1回の観測ではコールドスタートも体感できませんでした。
背景: Bedrock Agents (Classic) は 2026-07-30 で新規顧客の受付を終了します。これからエージェントを作るなら AgentCore です (東京対応済み)。
検証環境一式 (Terraform + クライアント) は GitHub で公開: bedrock-lab (phase3 タグ)

この記事で扱うこと・扱わないこと

扱わないこと — tool use ループの作り方そのものは、@502_ さんのエージェントループ記事や @ren8k さんの詳細解説が既に丁寧です。AgentCore の直接コードデプロイ機能の紹介も AWS 公式ブログと DevelopersIO の記事があります (末尾の参考にまとめています)。

扱うこと — 本記事は「手元で動いているエージェントを、そのまま Runtime に持ち込む移行」の記録です。移行に何が必要で、移行の前後で何が同じで何が変わるのかを、同一の質問セットで実測します。この構図の比較は探した範囲で見つからなかったので、一次データとして残します。

背景: Bedrock Agents Classic が新規終了する

従来の Amazon Bedrock Agents (2023年11月〜) は「Bedrock Agents Classic」となり、公式ドキュメントに 2026年7月30日から新規顧客に開放されない旨が明記されました。既存利用者はそのまま使えますが、モデルカタログは凍結され、以後の新モデルは後継の AgentCore 側に提供されます。

AgentCore はコードファーストのエージェント実行基盤で、東京リージョンにほぼ全機能が対応済みです (公式リージョン表)。Classic が「エージェントの定義を AWS に登録する」方式だったのに対し、AgentCore は自分のコードを持ち込む方式 — つまり「エージェント」というリソースは登録せず、実体はただのコードです。だからこそ「ローカルで動くものをそのまま持ち込んで比較する」という本記事の実験が成立します。

作ったもの: AWS 運用エージェント

比較の題材は、自分の AWS アカウントを調べる運用エージェントです。

図1: 同じエージェントコード (橙) を2つの実行基盤で動かす。ツールの鍵束 (IAM ポリシー) も同一で、持ち主だけが違う

項目	内容
エージェント本体	Converse API の tool use ループ (toolConfig / toolUse / toolResult を自前で回す。最大8ステップ)
ツール (すべて read-only)	コスト照会 (Cost Explorer) / ログ調査 (CloudWatch Logs) / リソース棚卸し (Tagging API) / ナレッジ検索 (Knowledge Base)
モデル	`jp.anthropic.claude-sonnet-4-6` (東京/大阪ルーティング)
実行基盤	② ローカル (Mac で python 実行) / ① AgentCore Runtime (東京、直接コードデプロイ)
時期	2026年7月

安全設計として、ツールは照会系のみです。「FSx を削除して」と頼むと、照会専用である旨を説明して手順だけ案内します (実測済み)。エージェントに書き込み権限を持たせない線引きは、企業導入でも最初に問われるポイントだと思います。

移行作業: 実体は「Lambda の zip デプロイ」だった

ローカルで動いていたエージェント (agent_cli.py) を Runtime に持ち込むのにやったことは3つだけです。

1. エントリポイントのラッパを書く (60行弱)

from bedrock_agentcore.runtime import BedrockAgentCoreApp
from agent_cli import AgentSession, build_clients, resolve_kb_id  # ← 既存コードをそのまま import

app = BedrockAgentCoreApp()
_agent = None  # microVM (セッション単位) のプロセスメモリに履歴が残る

def _get_agent():
    global _agent
    if _agent is None:
        session = boto3.Session()  # Runtime 実行ロールの一時クレデンシャル
        _agent = AgentSession(clients=build_clients(session), ...)
    return _agent

@app.entrypoint
def handler(payload: dict):
    answer = _get_agent().ask(payload.get("prompt", ""))
    return {"result": answer}

Lambda ハンドラを書く感覚そのものです。エージェント本体には一切手を入れていません。

2. arm64 向けの zip を作る

Runtime は ARM64 で動きます (Python はバージョン選択式、今回は 3.13 を指定)。依存は実行先アーキテクチャ向けに取得する必要がありますが、手元が Mac でも uv のクロスプラットフォーム指定で解決できます。

uv pip install \
  --python-platform aarch64-manylinux2014 \
  --python-version 3.13 \
  --target=build/pkg \
  --only-binary=:all: \
  bedrock-agentcore boto3
# → 依存 + agent_cli.py + ラッパを zip (今回 19MB)

3. Terraform でデプロイ

直接コードデプロイは Terraform がネイティブ対応しています (aws_bedrockagentcore_agent_runtime の code_configuration)。Docker も ECR も出てきません。

resource "aws_bedrockagentcore_agent_runtime" "ops_agent" {
  agent_runtime_name = "bedrock_lab_ops_agent"
  role_arn           = aws_iam_role.agent_runtime.arn  # ツール権限はこのロールへ

  agent_runtime_artifact {
    code_configuration {
      entry_point = ["agent_runtime.py"]
      runtime     = "PYTHON_3_13"
      code {
        s3 {
          bucket = aws_s3_bucket.agent_code.id
          prefix = aws_s3_object.agent_package.key  # ← zip
        }
      }
    }
  }
  network_configuration { network_mode = "PUBLIC" }
  lifecycle_configuration {
    idle_runtime_session_timeout = 300   # ← 後述の「会話の寿命」
    max_lifetime                 = 1800
  }
}

IAM は、ローカル実行で利用者ロールに付けていた同じポリシー2枚 (モデル呼び出し+KB / read-only ツール) を Runtime 実行ロールにアタッチしただけ。「運用端末の作業者権限を、バッチサーバのサービスアカウントに移す」あの定番作業と同型です。

実測比較

同一の質問セット (単一ツール / ナレッジ検索 / マルチステップ / 絞り込みフォローアップ) を両方式で実行しました。生成条件も両方式で同一です (inferenceConfig は maxTokens のみ指定、temperature は未指定 = API デフォルト)。

	② ローカル	① AgentCore Runtime
実行場所	手元の Mac	東京の microVM (セッション単位で分離)
認証・ツールの鍵	利用者ロール	Runtime 実行ロール (同一ポリシーを付け替え)
会話文脈	CLI プロセスのメモリ	セッション microVM のメモリ (idle 5分で消滅)
ツール実行の観測	`--verbose` で手元に表示	クライアントからは見えない。stdout が CloudWatch へ自動転送
同一質問のレイテンシ (棚卸し)	18.2s	14.1s (差は生成の揺れの範囲)
コールドスタート	なし	体感差なし (アイドル後の初回も 14.0s)
絞り込みフォローアップ	✅ steps=0 (ツールを呼ばず前回回答から再構成)	✅ ただしログ検索を自発追加してよりリッチに回答
追加コスト	なし	実行秒課金 (vCPU $0.0895/h + メモリ $0.00945/GB-h。I/O 待機中の CPU は無課金、メモリはピーク分課金が継続)

発見

1. 同じコード・同じ質問でも、ツールの選び方が変わった

タイトルの件です。「今月のコストは?」→「そのうち Bedrock 分だけ詳しく」という絞り込みのフォローアップに対して:

ローカル: ツールを一切呼ばず (steps=0)、前回の回答に含まれる内訳から再構成。「追加のコスト照会は行っていません (前回取得データを再利用)。$0.01 の節約です」と自己申告までした
Runtime: コスト照会 ($0.01) の再実行は同じく節約しつつ、無料のログ検索ツールを自発的に追加し、ログ考察付きのよりリッチな回答を返した (Runtime 側の CloudWatch ログでツール呼び出しを確認)

どちらも合理的ですが、同じではありません。方式の差というより LLM の非決定性で、「今回の2回の実行では、たまたま同じにならなかった」が正確なところです (temperature 未指定のデフォルト設定)。逆にいえば、エージェントの出力は固定値の一致を前提にできない。回帰テストは「出力の一致」では書けず、観点評価 (禁止操作をしていないか・ツール呼び出し回数が上限内か・回答に根拠があるか) で設計する必要があります。テスト計画を書く立場として、これが2回の実行であっさり観測できたのは収穫でした。

2. 今回の構成では、セッション内でプロセスメモリが生き残った

Runtime はセッション ID (runtimeSessionId) ごとに分離された microVM を立て、プロセスが数分生き残ります。ラッパでグローバル変数に置いたエージェント (会話履歴 = ただの Python リスト) がそのまま残るため、アプリコードを一切変えずにセッション内マルチターンが成立しました。別セッション ID にすると文脈は消えます (実測)。

ただしこの履歴の寿命は idle_runtime_session_timeout (今回 300 秒) まで。インフラの設定値が「会話の寿命」を決める運用パラメータになるのが面白いところです。恒久的な記憶が要件なら、プロセスメモリ頼みではなく AgentCore Memory 等の外部化が筋になります。

3. 観測性が逆転する

ローカルの --verbose (手元にツール実行が見える) は、Runtime ではクライアントに届きません。代わりに stdout が CloudWatch (/aws/bedrock-agentcore/runtimes/...) へ自動転送されます。発見1で「Runtime が実際に何のツールを呼んだか」を確認できたのも CloudWatch のログでした。

デバッグ出力がそのまま運用ログになるということです。エージェントの行動を後から説明できるか (監査・インシデント調査) はログ設計次第 — 運用化するなら、ツール呼び出しの構造化ログを最初から仕込んでおくべきでした。

4. レイテンシは生成が支配 — Runtime 化のオーバーヘッドは誤差

同一質問でローカル 18.2s vs Runtime 14.1s — Runtime 化のオーバーヘッドは生成時間の揺れに沈みます。ツール実行は 0.1〜1.1 秒 (最も遅いのは Cost Explorer)。アイドルタイムアウト後の初回呼び出しも 14.0s (1回の観測) で、直接コードデプロイのセッション生成は速いという仕様どおりでした。

実行基盤の選択はレイテンシではなく、権限・観測性・共用性の要件で決めるのがよさそうです。個人の使い分けとしては「開発・実験はローカル、共用・常設は Runtime」で、移行コストが小さい (ラッパ数十行) ので両対応にしておくのが現実解でした。

おまけ: Gateway でツールを MCP 化 — IAM 認証なら Cognito 不要

仕上げに、エージェント専用だったツール4種を AgentCore Gateway で MCP ツールとして公開しました (構成は「API Gateway + Lambda」と同型)。詳細な手順は DevelopersIO の記事群に譲りますが、1点だけ:

Gateway のインバウンド認証は IAM (SigV4) が選べます (authorizer_type = "AWS_IAM")。個人・社内用途なら Cognito や外部 IdP を立てずに、利用者ロールへ bedrock-agentcore:InvokeGateway を付与するだけで MCP サーバをマネージド公開できました。ツール名が <ターゲット名>___<ツール名> 形式になるので、Lambda 側でプレフィックスを剥がす小細工だけ必要です。

これで同じ read-only ツールの「鍵束」の持ち主が3人になりました: 利用者ロール (ローカル) / Runtime 実行ロール / Lambda 実行ロール (Gateway)。実行基盤が増えても鍵束は同じ、持ち主が変わるだけ — エージェント運用の権限設計は、結局いつもの IAM 設計でした。

まとめ

学び	内容
移行の実体	Lambda の zip デプロイと同型 (ラッパ60行弱 + arm64 zip + Terraform)。Docker/ECR 不要
ツール選択	同一コード・同一質問でも出力の固定一致は前提にできない。回帰テストは観点評価で設計
セッション	今回の構成ではプロセスメモリに履歴が残存。idle timeout が会話の寿命
観測性	verbose → CloudWatch へ逆転。ログ設計 = エージェントの説明責任
レイテンシ	生成が支配。Runtime 化のオーバーヘッドとコールドスタートは誤差
権限	同じポリシーの持ち主が変わるだけ。read-only の線引きが企業導入の第一関門

Terraform 一式・エージェント実装・比較の生データは GitHub で公開しています。

シリーズ前作: モデルアクセス編 (Phase 1) / RAG 3方式比較編 (Phase 2)

参考

AWS 公式

Amazon Bedrock Agents Classic maintenance mode — 2026-07-30 新規終了の一次情報
Direct code deployment for Python (AgentCore) — zip デプロイの公式手順 (arm64 要件含む)
Iterate faster with Amazon Bedrock AgentCore Runtime direct code deployment (AWS Blog)
Supported AWS Regions (AgentCore) — 東京対応状況
Amazon Bedrock AgentCore Pricing — 消費ベース課金の詳細

先行記事 (tool use ループの作り方・機能紹介はこちらが詳しいです)