Amazon Bedrock AgentCore とは — エージェントを本番化するモジュール式の運用基盤
2025年10月にGAしたAmazon Bedrock AgentCoreを、AWSフリーランス実務の視点で解説。Runtime・Memory・Gatewayなどモジュール式サービスの役割、従量課金の料金構造、LangGraph等で作ったエージェントを本番化する流れまで整理します。
- #Amazon Bedrock
- #AgentCore
- #AIエージェント
- #AWS
- #MCP
- #本番運用
「Amazon Bedrock AgentCore」という名前は耳にしたものの、結局それが何なのかは曖昧なまま――そんな方は多いのではないでしょうか。AgentCore は、2025年10月にGA（一般提供開始）した、AIエージェントを「本番運用」するための基盤です。LangGraph などでプロトタイプ（PoC）までは作れても、いざAWS上で認証・記憶・監視・スケールまで持っていく段で詰まる。AgentCore はまさにその「本番化のギャップ」を埋めるサービス群です。
この記事では、AgentCore とは何か（Bedrock 本体との違い）、各モジュールの役割、料金の考え方、そして「自分のエージェントをどこからどう本番化するか」の判断軸まで、AWS実務の目線で整理してみましょう。
AgentCore とは何か — Bedrock 本体と何が違うか
最初に、ここだけは押さえておきたい、という最重要ポイントからいきます。それは「Bedrock 本体と AgentCore は別レイヤだ」ということです。
- Bedrock 本体 = Claude や Amazon Nova などの「基盤モデルを提供する」レイヤ。
- AgentCore = そのモデルで作ったエージェントを「安全・大規模に動かす運用基盤」レイヤ。
AgentCore の特徴は、フレームワーク非依存・モデル非依存である点です。CrewAI / LangGraph / LlamaIndex / Strands Agents など任意のOSSフレームワークで作ったエージェントを乗せられますし、モデルも Bedrock 内外を問いません（Claude / Nova / Gemini / Llama / Mistral など）。つまり「Bedrock 専用の機能」ではない、というのが比較で迷いやすい一番のポイントですね。
解決しようとしているのは、ひとことで言えば「プロトタイプ→本番のギャップ」です。エージェントのロジック（推論やツール呼び出し）は手元で動かせても、本番ではインフラ運用・IdP（社内の認証基盤、ID Provider）連携・記憶の永続化・可観測性・スケール時のセキュリティといった「地味だが必須の周辺基盤」を自前で作り込む必要があります。この差別化につながらない重労働をマネージドで肩代わりするのが AgentCore だ、というわけです。
主要モジュール — 7つのサービス（+ガバナンス2つ）
AgentCore は「ひとつの大きなサービス」ではなく、モジュール式です。重要なのは、各サービスが単独でも、組み合わせても使えること。この性質が、後半の「部分採用」の判断軸につながります。主要な7サービスを役割で整理すると、次のとおりです。
| サービス | 役割（要点） | 主な連携先 |
|---|---|---|
| Runtime | エージェント／ツール専用のサーバーレス実行環境。高速コールドスタート、セッション分離、最大8時間の実行に対応（長時間・非同期エージェント向き） | LangGraph, CrewAI, Strands, Google ADK, OpenAI Agents SDK ／ MCP・A2A 対応 |
| Memory | 短期（マルチターン会話）と長期（セッション跨ぎで永続）の記憶。記憶内容を制御でき、エージェント間で共有も可能 | LangGraph, LangChain, Strands, LlamaIndex |
| Gateway | 既存のAPI・Lambda・サービスを数行のコードで「MCP互換ツール」に変換。既存MCPサーバーにも接続 | 任意のAPI/Lambda、Salesforce, JIRA, Slack 等 |
| Identity | エージェントのID・アクセス・認証管理。既存IdPと互換でユーザー移行不要。トークンVaultを提供 | Cognito, Okta, Microsoft Entra ID, Auth0 等 |
| Code Interpreter | コード実行用の隔離サンドボックス。精度向上と複雑タスク対応 | Python, JavaScript, TypeScript |
| Browser | クラウド上のセキュアなブラウザ実行環境。Web操作・フォーム入力・情報抽出をマネージドで | Playwright, BrowserUse 等 |
| Observability | 本番でのトレース・デバッグ・監視を一元化。実行パスの可視化、ボトルネック分析 | OTEL（OpenTelemetry：監視データの標準規格）互換／CloudWatch |
用語を噛み砕いておくと、MCP（Model Context Protocol） はエージェントに外部ツールをつなぐ標準プロトコル、A2A（Agent-to-Agent） はエージェント同士が連携するプロトコルです。Gateway が「既存APIをMCPツール化する」とは、手持ちのLambdaや社内APIを、エージェントから呼べる道具として手早く公開できる、という意味ですね。
すべてを一度に覚える必要はありません。まず注目すべきは Runtime（実行環境） と Gateway（既存API/LambdaのMCPツール化） の2つ。「作ったエージェントを動かし、手持ちの資産につなぐ」入口になります。
【補足：ガバナンス／品質系（表外）】 GA後に2つのサービスが追加されています。Policy（2026年3月GA）はツール呼び出しを実行前に毎回チェックする決定論的な制御で、自然言語または Cedar（AWSのOSSポリシー言語）でルールを書け、Gatewayと統合します。Evaluations（同2026年3月GA）はエージェント／ツールの品質を自動評価し、結果は Observability に統合されます。提供状況は流動的なので、採用時は公式の最新情報を確認してください。
GA時点で押さえる事実 — 提供状況と料金
事実関係を、現時点で確認できる範囲で整理します。
- GA日: 2025年10月13日に一般提供を開始。
- リージョン: 東京を含む9リージョンで利用可能（米国東部バージニア北部／オハイオ、米国西部オレゴン、欧州フランクフルト／アイルランド、アジアパシフィックの東京／ムンバイ／シンガポール／シドニー）。
- エンタープライズ対応: GA時点で全サービスが VPC / AWS PrivateLink / CloudFormation / リソースタグ付け に対応。つまり、社内ネットワーク要件やIaC（コードによるインフラ管理）の自動化にそのまま乗せられます。
料金は 前払い・最低額なしの従量課金 です。設計の感覚として、Runtime・Browser・Code Interpreter は「秒課金」、Gateway・Identity・Memory は「呼び出し回数やレコード単位」と覚えておくと見積もりの当たりがつけやすいです。
| サービス | 課金単位（2026年6月時点・参考値） |
|---|---|
| Runtime / Browser / Code Interpreter | CPU $0.0895 / vCPU-hour、メモリ $0.00945 / GB-hour（秒課金・最低1秒、最小128MB）。I/O待機中にCPU消費がなければCPU課金は発生しない |
| Gateway | API呼び出し $0.005 / 1,000回、Search API $0.025 / 1,000回、ツールインデックス $0.02 / 100ツール・月 |
| Identity | 非AWSリソースのトークン/APIキー要求 $0.010 / 1,000回（Runtime/Gateway経由では追加課金なし） |
| Memory | 短期 $0.25 / 1,000イベント、長期（ビルトイン）$0.75 / 1,000レコード・月、長期（自己管理）$0.25 / 1,000レコード・月、取得 $0.50 / 1,000回 |
| Observability | CloudWatch の公表レート（スパン・ログ・メトリクスの取り込み／保存）に準拠 |
数値は正直にお伝えしておくと、上記はあくまで 2026年6月時点の参考値 です。AWSの料金は改定されうるので、見積もり時は必ず公式の料金ページで最新情報を確認してください。とくに Observability は CloudWatch のレート依存のため固定額を断定しません。Browser profiles の S3 保存に関する課金も、開始日・適用条件は公式で要確認です。
実務で使うときの注意点 — 本番化フローと部分採用の判断軸
ここからが、機能一覧では終わらせたくない実務の話です。
既存エージェントを本番化する流れ
LangGraph や Strands で作ったエージェントをAgentCoreで本番に乗せる場合、おおまかには次の順序で考えると整理しやすいです。
- Runtime にデプロイ — まずは実行環境に乗せる。セッション分離と最大8時間実行で、長時間タスクや非同期処理にも対応。
- Memory で記憶を外出し — 会話履歴やセッション跨ぎの記憶をエージェント本体から切り離し、永続化する。
- Gateway で既存API/LambdaをMCPツール化 — 手持ちの社内API・Lambdaを、エージェントから呼べる道具として公開する。
- Identity で認証 — Cognito / Okta / Entra ID など既存IdPと連携。ユーザー移行は不要。
- Observability で監視 — トレースと性能監視を一元化し、本番の挙動を可視化する。
「全部入り」にしない — 部分採用の判断軸
ここで効いてくるのが、各モジュールを単独で使えるという性質です。最初からフルセットを導入する必要はありません。実務では「どこから入れるか」を見極めるほうが現実的です。
- まず既存APIをエージェントから使いたい → Gateway から。手持ちのLambda・APIのMCP化が最短の価値になりやすい。
- 会話の記憶を永続化したい／セッション跨ぎで保持したい → Memory から。
- 認証・ID管理がボトルネック → Identity から。既存IdPと互換なので移行コストが低い。
このように「課題ドリブンで1モジュールずつ」入れていける設計は、導入リスクを下げる意味でも実務的です。
コストは「設計」で変わる
料金が秒課金・従量である以上、コストは断定額より「考え方」で捉えるのが妥当です。たとえば Runtime は I/O待機中にCPUを消費しなければCPU課金が発生しません。常時起動を前提にするのか、必要なときだけ動かすのかで、コスト感は大きく変わります。具体額は実際のワークロードと公式の最新料金で算出してみましょう。
まとめ
最後に、ポイントを3つに絞ります。
- AgentCore は Bedrock 本体（モデル提供）とは別レイヤの「運用基盤」。フレームワーク非依存・モデル非依存で、Bedrock 専用ではありません。
- モジュール式で単独採用が可能。全部入りにせず、まずは Runtime / Gateway あたりから課題ドリブンで入れていけます。
- 料金は前払いなしの従量課金（参考値・公式要確認）。本番化に必要な実行・記憶・認証・監視を、モジュール単位で必要なものから段階的に導入できます。
なお、AgentCore を含む最近のAWSアップデートは AWS最新サービスの解説ハブ に横断的にまとめています。あわせてご覧ください。