エージェントのプロトタイプは Claude Code でサクッと動いた。次の壁は、それをどう本番に出すかだ。セキュリティ、セッション分離、最大8時間動き続ける長時間実行、コスト可視化——どれも Lambda では解決しきれない。そこに AWS が 2025年10月、正面から答えを出してきた。それが Amazon Bedrock AgentCore で、BGL Corporate Solutions はすでに Claude Agent SDK と組み合わせてビジネスインテリジェンスエージェントを本番稼働させている。
本ブログのテーマは EM × Claude Code 文脈で、これまで Claude Code 側を中心に書いてきた。本稿はその外側——書いたエージェントをどこにデプロイするか——を AWS の公式情報に基づいて整理する。
AgentCore とは何で、何ではないか
公式の AgentCore ドキュメントは次のように定義している。
> Amazon Bedrock AgentCore is an agentic platform for building, deploying, and operating highly effective agents securely at scale using any framework and foundation model.
要するに「any framework × any model × fully managed」のサーバーレス運用基盤だ。AgentCore は LLM ではない。Strands Agents・LangGraph・CrewAI・LlamaIndex・OpenAI Agents SDK・Claude Agent SDK のいずれで書いたエージェントでも、Anthropic Claude・OpenAI・Google Gemini・Amazon Nova・Meta Llama・Mistral のいずれを呼んでも動く、サーバーレスの運用基盤だ。
2025年10月13日に GA したのは Runtime / Memory / Gateway / Identity / Observability の5サービス。その後、2026年3月に Evaluations と Policy が GA、4月に Harness と Registry が Public Preview、5月に Payments が Preview として追加された。2026年6月時点で AgentCore は12のコンポーネントを束ねる一つのプラットフォームだ。
リージョンは GA 時の9リージョンから半年で15リージョン超に拡大した。東京は GA 時から対応していて、2026年5月には AWS GovCloud (US-West) でも GA。HIPAA eligible、ISO と CSA STAR 認証取得、FedRAMP は申請中という状態で、エンタープライズの調達フローに乗せられるラインに来ている。
Lambda が15分の壁、AgentCore は8時間動き続ける
エージェント特化基盤の価値を一番感じるのは Runtime だ。公式 Runtime ドキュメントから実務に効く差分を拾う。
まず実行時間。Lambda は最大15分、AgentCore Runtime は8時間。「人間が放置している間にエージェントが調べ物をして、コードを書いて、テストを回して、レポートを返す」非同期ワークロードを正面から想定している。
セッション分離も大きい。AgentCore は Firecracker MicroVM ベースで、各セッションが専用 microVM で動く。公式は次のように説明している。
> In AgentCore Runtime, each user session runs in a dedicated microVM with isolated CPU, memory, and filesystem resources.
セッション終了時に microVM が破棄されメモリも消毒される。「非決定的な AI プロセスを扱うのに決定的なセキュリティを提供する」という設計だ。エージェントに Bash や Code Interpreter を持たせるなら、ここがあるとないとで安心感が違う。
コスト構造も変わる。公式ページによると、バックグラウンドプロセスが動いていない限り I/O wait と idle 時間は CPU 課金対象外になる。LLM の応答を待っている間、Lambda なら CPU 時間が課金され続けるが、AgentCore Runtime は止まる。Runtime / Browser / Code Interpreter の価格は 2026年6月時点で $0.0895/vCPU-hour、メモリは $0.00945/GB-hour。1日8時間 × 1 vCPU × 2GB で動かしたとして1日約 $0.87、月約 $26 程度（LLM 推論コスト別）。bursty な単発処理なら Lambda の方が安いが、エージェントワークロードでは AgentCore の方が現実的なコストになる。
12 のコンポーネントを役割で読む
Runtime 以外も、エージェント運用に必要なものを一通り揃えている。GA / Preview 区分付きで並べると以下になる。
| コンポーネント | 状態 | 役割 |
|---|---|---|
| Runtime | GA (2025-10) | サーバーレス実行基盤、microVM 分離、最大8時間 |
| Memory | GA (2025-10) | 短期＋長期メモリ、structured metadata filtering 対応 |
| Gateway | GA (2025-10) | API / Lambda を MCP 互換ツール化、既存 MCP server プロキシ |
| Identity | GA (2025-10) | 非人間 ID、OAuth 2.0 / SigV4 / API key |
| Observability | GA (2025-10) | OpenTelemetry 互換、CloudWatch / X-Ray 統合 |
| Code Interpreter | GA (2025-10) | Python / JavaScript / TypeScript サンドボックス |
| Browser | GA (2025-10) | Playwright / BrowserUse 対応のクラウドブラウザ |
| Evaluations | GA (2026-03) | 13種の組み込み evaluator、Ground Truth、custom evaluator |
| Policy | GA (2026-03) | Cedar または自然言語でツールアクセス制御 |
| Harness | Preview (2026-04) | 1 API でモデル＋プロンプト＋ツール定義 |
| Registry | Preview (2026-04) | エージェント・MCP server・ツールの中央カタログ |
| Payments | Preview (2026-05) | x402 プロトコル、Coinbase CDP / Stripe Privy |
設計判断として一番面白いのは Gateway だ。手元の Lambda 関数や OpenAPI 仕様をいくつか紐付けるだけで MCP 互換ツールになり、AgentCore Runtime 上の任意のフレームワークから呼べる。Salesforce / Zoom / JIRA / Slack といったメジャー SaaS との統合は公式に提供されている。
Observability が OpenTelemetry 標準準拠なのも実務的な意味が大きい。本ブログの5/26 OTel 記事では Claude Code 側の OTel 出力を扱ったが、AgentCore はその受信側のエージェント本体テレメトリを同じ OTel で取り回せる。Datadog や Honeycomb の既存ダッシュボードに接続できる。
Policy は AWS のオープンソース言語 Cedar、または自然言語でツール呼び出しの可否を宣言的に書ける。すべてのツール呼び出し前に判定が走るので、「このエージェントは prod の DB に書き込めるか」のような細粒度ガバナンスを後付けで効かせやすい。
Claude Code から動かす3つの入り口
ここが本ブログの読者にとって一番気になる接続点だろう。AWS が公式に示している利用パスは3通りある。
入り口1: Claude Code から AgentCore リソースを操作する
awslabs/mcp リポジトリに公式の AgentCore MCP server が含まれている。Claude Code の .mcp.json に1行追加するだけで「AgentCore Runtime を立てて」「Memory リソースを作って」「Code Interpreter サンドボックスでこのコードを試して」とセッション内から指示できる。boto3 を書く必要がない。
入り口2: Claude Agent SDK で書いたエージェントを AgentCore Runtime にデプロイする
AWS Builder ライブラリの「Deploying Claude Agent SDK on Amazon Bedrock AgentCore Runtime」というガイドが公式パスだ。冒頭で触れた BGL Corporate Solutions の事例は、まさにこの組み合わせで BI エージェントを本番投入した例だ。AWS ブログでは、金融サービスのセキュリティ・コンプライアンス要件（セッション分離と identity-based access controls を含む）を満たした形でエージェントを展開したと紹介されている。
入り口3: Claude Code 自身を AgentCore 上でホストする
aws-samples/sample-claude-code-web-agent-on-bedrock-agentcore という公式サンプルがある。Claude Code を Web からアクセスできるエージェントとして AgentCore Runtime にデプロイするパターン。社内で「Claude Code 環境を Web 化して配布したい」場合の参考実装だ。
整理すると、入り口1はローカル開発の効率化、入り口2は自社プロダクトの本番化、入り口3は組織内ツールとしての配布、という棲み分けになる。Claude Code の用途と AgentCore の用途が排他関係ではなく、開発と運用の役割分担として接続できているのが現状の設計だ。
何と比べて選ぶか——Lambda・旧 Bedrock Agents・自前 ECS
AgentCore を選ぶ判断軸は、何と比べているかで変わる。
Lambda は最大15分の制限、I/O wait の課金、stateless 前提、エージェント特化トレースの自前構築といった点でエージェントワークロードに不向きだ。bursty な単発関数なら Lambda、長時間 LLM 待ちを伴うエージェントなら AgentCore Runtime、という分け方が自然になる。
旧 Bedrock Agents API は AWS 提供のクローズドなエージェント仕様で、フレームワーク選択の自由がなかった。AgentCore は「任意フレームワーク × 任意モデル」に開かれている。Anthropic の Claude にロックインされたくない場合や、社内で複数フレームワークを並走させたい場合に効く。
自前 ECS / EKS と比べると、VPC・PrivateLink・CloudFormation はどちらでも使える。ただし microVM 分離・組み込み Identity・MCP/A2A プロトコル対応・OTel ストックを自前で組むと相当の工数になる。AWS インフラを深くコントロールしたい場合は ECS/EKS、エージェント特有のセキュリティと課金モデルを最短で得たい場合は AgentCore という棲み分けだ。
5/25 の Bedrock vs サブスク記事では「Claude Code を Bedrock モデル経由で使うときの機能差」を扱った。本記事はその先の話で、「Bedrock 上で動かしたエージェントをどこにデプロイするか」というレイヤー。AWS のサブスクとの組み合わせを検討している読者は両方を参照すると、Anthropic 直接契約と Bedrock ルートの選択肢が立体的に見える。
何から始めるか
AgentCore の全コンポーネントを一気に評価しようとすると、判断材料が多すぎて止まる。私なら Runtime・Memory・Observability を先に立てて、Gateway で既存 API を1本だけ MCP 化するところから入る。Policy と Identity はトラフィックが流れ始めてから細粒度に詰めれば十分だ。
5/30 の Dynamic Workflows 記事で扱った Claude Code 内の workflow と subagent 連携は、開発時のオーケストレーションの話だった。AgentCore はその後段——本番運用フェーズでのオーケストレーション基盤だ。Claude Code のローカル開発で得た「workflow + subagent + skill」の設計知識は、AgentCore Runtime にデプロイしても活きる。Strands Agents や LangGraph のフレームワーク選択は自由だが、フレームワーク内のエージェント構成パターンは Claude Code で培ったものをそのまま持ち込める。
awslabs/mcp を .mcp.json に追加して、Claude Code から AgentCore MCP server を呼んでみるのが一番早い。5分あれば動く。
コメント