Amazon Bedrock AgentCore のレイヤ構造と Lambda・ECS 自作からの委譲判断
Amazon Bedrock AgentCore が提供する 5 レイヤ (Runtime / Memory / Identity / Gateway / Observability) の責務分割と、東京リージョン対応・料金モデル・Lambda/ECS からの移行判断ポイントをまとめました。
目次
本記事では、Amazon Bedrock AgentCore のコンポーネント構成と、Lambda / ECS 自作エージェントからの責務移行の判断材料を整理します。
5 レイヤの役割・東京リージョンの対応状況・料金モデル・移行判断の評価軸を順に整理します。
各レイヤと自前実装の対応関係を把握して、移行範囲を判断しましょう。
AgentCore の位置付け ── Bedrock Agents との並存と「実行基盤」としての役割
Amazon Bedrock AgentCore は、2025 年 7 月の Preview を経て、2025 年 10 月 13 日に GA となったエージェント実行プラットフォームです。フレームワーク・モデル・プロトコルを問わず動作することが設計上の前提です。
AgentCore eliminates the undifferentiated heavy lifting of building specialized agent infrastructure.
出典: Amazon Bedrock AgentCore developer guide
この文言が示すように、AgentCore が扱う対象はモデルの推論そのものではなく、エージェントを実運用するための周辺インフラです。
具体的には、実行環境の分離・セッション状態の管理・認証フロー・ツール公開・観測性という、Lambda や ECS でエージェントを自作した場合に自前実装を強いられていた領域が対象になります。
既存の Bedrock Agents は廃止されません。公式は「現在 Amazon Bedrock Agents を使用している場合は、引き続き使用できます」と明言しています。
AgentCore はフレームワーク非依存・エンタープライズ要件 (MCP / VPC / A2A) の強化版として並列で提供される位置付けです。
AgentCore が解く問いは「どのモデルを使うか」ではなく「エージェントの実行基盤をどう構成するか」であり、この点で Bedrock Agents とは役割が異なります。
5 つのマネージドレイヤ ── Runtime から Observability まで何が変わるか
AgentCore は機能ごとに独立したレイヤとして設計されています。Runtime / Memory / Identity / Gateway / Observability の 5 レイヤを中心に説明します。Browser Tool / Code Interpreter も GA ですが Runtime と同じ課金体系で動くため、Runtime の派生として扱います。Policy / Evaluations / Registry は preview 段階です。
Runtime ── セッション分離とタイムアウト制約
Runtime は microVM ベースの実行環境です。1 セッション = 専用 CPU / Memory / ファイルシステムで動作し、セッション間の干渉を物理的に分離します。
スペック上限は 1 セッションあたり最大 2 vCPU / 8 GB です。タイムアウトは実行モードによって異なります。
| 実行モード | タイムアウト |
|---|---|
| 非同期 | 8 時間 |
| 同期 | 15 分 |
| ストリーム | 60 分 |
Lambda の同期実行は最大 15 分で Runtime の同期モードと同じ上限を持ちますが、非同期 8 時間という制約が Lambda とは根本的に異なります。長時間の推論ループや多ステップのタスク実行が必要なエージェントでは、この差が設計の分岐点になります。
コンテナイメージ (最大 2 GB) または直接コード (圧縮後 250 MB) の 2 つのデプロイ方式に対応します。
Browser Tool (Playwright / BrowserUse 互換のクラウドブラウザ) と Code Interpreter (Python / JS / TS のサンドボックス実行) は Runtime と同じ課金体系で動作します。
Memory ── セッション横断の状態管理
Memory は短期・長期・エピソードの 3 層構成です。短期は同一セッション内のターン履歴、長期はセッションをまたぐユーザーの嗜好やコンテキスト、エピソードは過去の対話経験から学習した知識を保持します。複数のエージェント間で共有できます。
自前実装では DynamoDB などで賄う必要があったセッション横断の状態管理が、AgentCore の場合は Memory として独立したマネージドレイヤに集約されます。
メモリの管理戦略は 3 種類から選択します。
- built-in: AgentCore がスコープを自動管理
- override: 保存・取得のロジックをカスタマイズ
- self-managed: 外部ストアへの格納を自前で制御
長時間の会話履歴や複数セッションにまたがるコンテキスト保持が必要な場合、DynamoDB の TTL / インデックス設計を自前で管理する代わりに built-in か override を選択する判断になります。
Gateway ── 既存 API・Lambda を MCP ツール化する
Gateway は既存の REST API / Lambda 関数 / OpenAPI 定義 / Smithy スキーマをエージェントが呼び出せる MCP ツールに変換します。
Salesforce / Slack / Jira / Asana / Zendesk への 1-click 連携も用意されています。認証は IAM と OAuth を組み合わせて処理します。
自作エージェントで「外部 API へのアクセスをどうラップするか」を都度実装していた部分を、Gateway の変換レイヤに委譲できます。既存 Lambda を MCP ツールとして公開する場合、Gateway を経由することで認証と呼び出しフローを統一できます。
Identity ── IdP 統合と OAuth フロー
Identity は代表的な IdP として Cognito / Microsoft Entra ID / Okta が利用でき、ほかにも Auth0 / GitHub / Google / Slack / Salesforce など多数の OAuth プロバイダに対応します。OAuth 2LO (2-legged) および 3LO (3-legged) の両フローを提供します。
重要なのは料金構造です。Runtime または Gateway 経由でアクセスした場合、Identity の追加料金は発生しません。スタンドアロンで Identity のエンドポイントを直接呼び出す場合のみ $0.010 / 1,000 token または API key の課金が発生します。
既存の IdP を流用しつつ OAuth フローを AgentCore に委譲するケースでは、Gateway 経由でアクセスする設計にしておくことで Identity の追加コストを回避できます。
Observability ── OTEL ベースの統合と外部ツール連携
Observability は CloudWatch に加えて OpenTelemetry (OTEL) の標準メトリクス・トレースをサポートします。外部の観測プラットフォームとして Datadog / Dynatrace / Arize / LangSmith / Langfuse との連携が公式にサポートされています。
CloudWatch の利用は通常料金のみで、AgentCore としての追加単価は設定されていません。ステップ単位のトレースが必要な場合、OTEL 形式のスパンを CloudWatch Logs または外部プラットフォームに転送する構成が基本になります。
東京リージョン (ap-northeast-1) の対応状況 ── GA 済みレイヤと preview 段階の制約
ap-northeast-1 で利用可能なコンポーネントと、現時点で対応していないものを整理します。
| コンポーネント | ap-northeast-1 | 備考 |
|---|---|---|
| Runtime | 利用可能 | — |
| Memory | 利用可能 | — |
| Gateway | 利用可能 | — |
| Identity | 利用可能 | — |
| Browser Tool | 利用可能 | — |
| Code Interpreter | 利用可能 | — |
| Observability | 利用可能 | — |
| Policy (preview) | 利用可能 | — |
| Evaluations (preview) | 利用可能 | us-east-1 / us-east-2 / us-west-2 / eu-central-1 / eu-west-1 / ap-south-1 / ap-southeast-1 / ap-northeast-1 / ap-southeast-2 |
| Managed Harness (preview) | 未対応 | us-east-1 / us-west-2 / eu-central-1 / ap-southeast-2 の 4 リージョンのみ |
| AgentCore CLI | 利用可能 | 14 リージョン対応 (東京を含む) |
GA 済みの主要レイヤはすべて東京リージョンで利用できます。Evaluations は ap-northeast-1 でも preview 提供されており、エージェントの継続評価が可能です。一方、Managed Harness (実行テスト自動化基盤) は現時点で ap-northeast-1 未対応のため、Harness を使った評価パイプラインを東京で構築したい場合は GA タイミングを待つ必要があります。AgentCore CLI は東京を含む 14 リージョンで利用できます。
エンドポイントは以下の通りです。コントロールプレーンとデータプレーンで URL が分かれています。
bedrock-agentcore-control.ap-northeast-1.amazonaws.com
bedrock-agentcore.ap-northeast-1.amazonaws.com
{gatewayId}.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com同時セッション上限は ap-northeast-1 で 500 / アカウントです。us-east-1 / us-west-2 の 1,000 に対して半数の設定です。本番で大量の並列セッションが想定される場合は、事前に上限緩和申請を行っておく必要があります。
料金の積み上がり方 ── レイヤごとの課金単位と試算の読み方
AgentCore の料金はレイヤごとに独立した課金単位を持ちます。利用するコンポーネントの組み合わせによって合計金額の構成が変わる点が特徴です。
Runtime の課金単位は I/O 待機中に課金されない点が重要です。ここでの active time は、モデル呼び出しやネットワーク待機などの I/O を除く CPU / メモリ実行時間を指します。
| 対象 | 単価 |
|---|---|
| vCPU (active time) | $0.0895 / vCPU-hour |
| メモリ (active time) | $0.00945 / GB-hour |
1 秒単位の課金です。Browser Tool と Code Interpreter も同単価で動作します。
Gateway・Identity・Memory の単価は以下の通りです。
| コンポーネント | 課金対象 | 単価 |
|---|---|---|
| Gateway | 呼び出し (List/Invoke/Ping) | $0.005 / 1K |
| Gateway | 検索 | $0.025 / 1K |
| Gateway | ツールインデックス | $0.02 / 100 ツール / 月 |
| Identity | スタンドアロン呼び出し | $0.010 / 1K token または API key |
| Memory | 短期 (イベント) | $0.25 / 1K events |
| Memory | 長期 built-in (レコード) | $0.75 / 1K records |
| Memory | 取得 | $0.50 / 1K |
| Egress | データ転送 | $0.006 / GB |
公式の計算例として、月 1,000 万セッション (60 秒 / I/O 70% / 1 vCPU / 2.5 GB) で約 $7,235 / 月という試算が示されています。1 USD = 155 円換算 (2026-05-06 時点) で約 112 万円 / 月に相当します。
事前割当型 (peak provisioning) と比べた場合、CPU コストは最大 3.3 分の 1、メモリコストは最大 1.4 分の 1 に抑えられると公式は試算しています。
ただしこの試算は I/O 待機中の無課金を前提にしており、モデル呼び出し待ち (I/O) の比率が高いエージェントワークロードほど有利に働く構造です。CPU バウンドに近いワークロードでは試算とずれが生じます。
Lambda / ECS からの移行判断 ── 委譲が有力な条件と維持が合理的な条件
Lambda / ECS でエージェントを自作しているときに発生する自前実装の負荷と、AgentCore の各レイヤの対応関係を整理します。
移行が有力な条件は以下の組み合わせで判断できます。
- Lambda の 15 分タイムアウトを超えるセッションがある → Runtime の非同期モード (最大 8 時間) が解決策になります
- DynamoDB 等でセッション横断の状態を自前管理している → Memory の built-in または override 戦略で置き換えられます
- 既存 IdP (Cognito / Entra ID / Okta) を OAuth フローで扱いたい → Identity に委譲することで、自前の JWT 検証 / トークン更新ロジックを削減できます
- 既存 Lambda 関数や REST API を MCP ツールとしてエージェントに公開したい → Gateway が変換を担います
- ステップ単位のトレースを CloudWatch や LangSmith で確認したい → Observability の OTEL 統合を利用します
自前実装を維持する条件は以下の通りです。
- セッションあたりの実行時間が 15 分以内に収まり、Lambda のタイムアウト制約が問題になっていないケース
- 状態管理が単純で、DynamoDB のスキーマ設計の自由度を維持したいケース
- コンテナランタイムの CPU / メモリを Runtime の上限 (2 vCPU / 8 GB) より細かく制御したいケース
- Managed Harness を使った評価パイプラインを東京リージョンで構築したい (現時点では ap-northeast-1 未対応)
核心は「Lambda / ECS + DynamoDB + 自前 OAuth + CloudWatch の組み合わせで賄ってきた各レイヤを、AgentCore のどのコンポーネントに委譲するか」という責務境界の判断です。全レイヤを一度に移行する必要はなく、たとえば Runtime だけ AgentCore に切り出し、Memory と認証は既存のまま維持する部分移行も設計上成立します。
Policy (自然言語から Cedar ポリシーへの自動変換) と Evaluations (エージェント動作の評価基盤) はまだ Preview 段階のため、本番投入の判断は GA 後に改めて行う形が現実的です。
まとめ ── 委譲するレイヤの選択が設計の本質
AgentCore の 5 レイヤ (Runtime / Memory / Identity / Gateway / Observability) は、それぞれが独立した課金単位と責務境界を持ちます。Lambda / ECS 自作エージェントで自前実装を強いられていた領域が、個別に委譲可能なマネージドサービスとして提供されています。
設計上の問いは「AgentCore を使うか使わないか」ではなく「どのレイヤを AgentCore に委譲し、どのレイヤを自前で持ち続けるか」という責務境界の判断です。タイムアウト制約・セッション状態の複雑さ・IdP 統合のコスト・MCP ツール化の必要性、これら 4 点が委譲判断の主な評価軸になります。
東京リージョン (ap-northeast-1) では GA 済みの主要レイヤをすべて利用できます。Evaluations は東京でも preview 提供されており、エージェントの継続評価が可能です。Managed Harness のみが現時点で ap-northeast-1 未対応のため、Harness を使った評価パイプラインの設計は GA タイミングを確認してから進めましょう。
参考文献
- Amazon Bedrock AgentCore developer guide — What is AgentCore?
- Amazon Bedrock AgentCore FAQ
- Amazon Bedrock AgentCore pricing
- Amazon Bedrock AgentCore service quotas
- Amazon Bedrock AgentCore endpoints
- GA announcement — Amazon Bedrock AgentCore available (2025-10-13)
- Policy/Evaluations preview announcement (2025-12)
- Managed Harness / CLI announcement (2026-04)
大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。