Amazon Bedrock AgentCore全体像 — AIエージェントの「インフラ」を丸ごと引き受ける新サービス

AWSAmazon BedrockAgentCoreAIエージェントMCPGatewayRuntime
Amazon Bedrock AgentCore adds new features to help developers build agents faster - AWS Discover more about what aws.amazon.com
Amazon Bedrock AgentCore adds quality evaluations and policy controls for deploying trusted AI agents | Amazon Web Services Deploy AI agents with confidence using new quality evaluations and policy controls—enabling precise ... aws.amazon.com
Overview - Amazon Bedrock AgentCore Amazon Bedrock AgentCore is an agentic platform for building, deploying, and operating highly effect... docs.aws.amazon.com
Amazon Bedrock AgentCore - AWS aws.amazon.com

Amazon Bedrock AgentCoreが急速に進化しています。2025年12月のre:Inventでプレビュー発表されてから約5ヶ月、SDKは200万回以上ダウンロードされ（2026年4月時点 AWS News Blog）、コンポーネントが次々とGAになっています。2026年4月22日にはManaged Harness（プレビュー）とAgent Registryが追加され、「数分でエージェントを動かせる」時代に入りました（2026年4月22日 AWS What’s New）。

これは面白いですね。AIエージェントを本番運用するために必要なインフラ要素を、AWSがまるごとマネージドサービスとして提供し始めた形です。自分もいくつか触ってみたので、全体像を整理しつつ深掘りしていきます。

AgentCoreとは何か

一言で言えば、AIエージェントの「インフラ」を丸ごと引き受けるプラットフォームです。

AIエージェントを本番に載せるには、推論を呼ぶだけでは済みません。実行環境、ツール連携、認証、メモリ管理、品質モニタリング、ガバナンス。これらのインフラを自前で組むと、エージェントのロジックそのものよりも周辺の「配管工事」に時間を取られます。AgentCoreはこの配管工事をAWSが引き受ける、というサービスです。

公式ドキュメントには以下のように記載されています（2026年4月 AWS Documentation）。

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 and foundation model」の部分です。AgentCoreは特定のフレームワークやモデルに縛られません。

  • フレームワーク: CrewAI、LangGraph、LlamaIndex、Strands Agents、Google ADK、OpenAI Agents SDK
  • モデル: Anthropic Claude、Amazon Nova、OpenAI、Google Gemini、Meta Llama、Mistral

どのフレームワーク・モデルの組み合わせでも、AgentCoreのインフラ層を使えます。

10個のコンポーネント

AgentCoreは単一のサービスではなく、10個のコンポーネントの集合体です。それぞれ独立して使うことも、組み合わせて使うこともできます。

実行系

コンポーネント役割ステータス
Runtimeエージェントのサーバーレス実行環境。高速コールドスタート、セッション分離、マルチモーダル対応GA
Harnessマネージドなエージェントループ。モデル・プロンプト・ツールを指定するだけで動くPreview
Browserクラウドブラウザ環境。Webフォーム操作、情報抽出、OS レベルの操作もサポートGA
Code Interpreterサンドボックスでのコード実行。Python、JavaScript、TypeScript対応GA

ツール連携・認証

コンポーネント役割ステータス
GatewayAPI/Lambda/MCPサーバーをMCP互換ツールに変換。認可・ツール検索も管理GA
IdentityエージェントのOAuth認証管理。Cognito、Okta、Azure Entra ID等と統合GA

メモリ・データ

コンポーネント役割ステータス
Memory短期記憶（マルチターン会話）と長期記憶（セッション間永続化）。エピソード記憶による経験学習もGA

ガバナンス・品質

コンポーネント役割ステータス
PolicyCedarポリシー言語によるツール呼び出しの制御。自然言語でのポリシー記述も可能GA
Evaluationsエージェントの品質評価。正確性、有用性、安全性などのビルトイン評価 + カスタム評価GA
ObservabilityOpenTelemetry互換のトレース・デバッグ・モニタリングGA

管理

コンポーネント役割ステータス
Registryエージェント、ツール、MCPサーバー、スキルのカタログ。セマンティック検索対応Preview

Gateway — エージェントのツール接続を一元管理

ユーザーが「地味に大切」と言っていたGatewayですが、自分もそう思います。エージェントがツールを使うためのインフラとして、Gatewayはかなり重要な位置にあります。

なぜGatewayが必要なのか

エージェントがツール（API、データベース、外部サービス）を呼ぶとき、開発者が自前で解決しなければならない課題が山ほどあります。

  • 各APIごとの認証・認可（OAuth、APIキー、IAM）
  • エージェントがどのツールを使えるかの制御
  • MCPプロトコルへの変換
  • ツールのスキーマ管理と検索

Gatewayはこれらを一箇所に集約します。公式ブログでは以下のように説明されています（2026年4月頃 AWS Machine Learning Blog）。

AgentCore Gateway serves as a centralized tool server, providing a unified interface where agents can discover, access, and invoke tools.

Gatewayの仕組み

Gatewayの基本的な構成は以下の3層です。

  1. Gateway本体: MCPプロトコルのエンドポイント。認証・認可を管理
  2. Gateway Target: 実際のバックエンドサービスへの接続。OpenAPI仕様、Lambda関数、既存MCPサーバーなどを接続
  3. Policy Engine（オプション）: Cedarポリシーによるツール呼び出しの事前検証

エージェントがGateway経由でツールを呼ぶと、以下のフローが走ります。

エージェント → Gateway（MCP） → 認証チェック → Policy検証 → Gateway Target → バックエンドAPI

API→MCPの自動変換

特に面白いのは、既存のREST APIをOpenAPI仕様からMCPツールに自動変換できる点です。Lambda関数をMCPツールとして公開することも可能です。つまり、既存のAPIやマイクロサービスを、エージェント向けのツールとして再利用できます。コードの書き換えは不要です。

双方向のセキュリティ

Gatewayは「双方向セキュリティアーキテクチャ」を実装しています。

  • インバウンド: MCPの認可仕様に準拠したOAuth認証で、エージェントからのツール呼び出しを検証
  • アウトバウンド: バックエンドサービスへの接続はOAuth、APIキー、IAM資格情報を管理

企業環境で本番運用するなら、この「誰がどのツールをどの条件で使えるか」の制御は必須です。ここをGateway + Policyで宣言的に管理できるのは大きなメリットだと思います。

Harness — 数分でエージェントを動かす

2026年4月に追加された最新機能がManaged Harnessです。これは「エージェントの推論ループ」自体をAWSが管理する仕組みです（2026年4月22日 AWS What’s New）。

従来のRuntimeでは、エージェントのオーケストレーションコード（推論→ツール選択→実行→応答のループ）を開発者が書く必要がありました。Harnessでは、モデル・システムプロンプト・ツールを指定するだけで、推論ループ全体をAWSが管理します。

公式の説明によると、従来は数日かかっていたセットアップが数分に短縮されるとのことです。

Harnessの特徴は以下のとおりです。

  • モデル非依存: セッション中にモデルを切り替えることも可能
  • ファイルシステム永続化: セッション状態を外部化し、中断→再開が可能（プレビュー）
  • フルマネージド: コンピュートリソース、認証、ストレージ、コード実行サンドボックスを全て内包

現在、US West (Oregon)、US East (N. Virginia)、Asia Pacific (Sydney)、Europe (Frankfurt) の4リージョンでプレビュー提供中です。東京リージョンはまだですが、今後の展開に期待が持てます。

Policy — Cedarによるツール呼び出しのガバナンス

Policyは2026年3月3日にGAになったコンポーネントです（2026年3月3日 AWS What’s New）。エージェントの推論ループの外側でツール呼び出しを検証する仕組みで、Gateway経由のツール呼び出しをインターセプトします。

ポリシーの記述にはAWSのオープンソースポリシー言語Cedarを使います。たとえば「refund-agent ロールを持つユーザーのみが返金ツールにアクセスでき、かつ金額は$200未満」というルールは以下のように書けます（2025年12月2日 AWS News Blog）。

permit(
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"RefundTool__process_refund",
  resource == AgentCore::Gateway::"<GATEWAY_ARN>"
)
when {
  principal.hasTag("role") &&
  principal.getTag("role") == "refund-agent" &&
  context.input.amount < 200
};

エージェントが自律的に判断する以上、「このツールは呼んでいいのか」を推論ループの外側で決定論的に検証できるのは重要です。自然言語でポリシーを記述してCedarに変換する機能もあり、セキュリティチームがコードを書かずにルールを設定できる点も実用的だと感じます。

Memory — エージェントに「記憶」を持たせる

AgentCore Memoryは短期記憶と長期記憶の2層構造です。

  • 短期記憶: マルチターン会話のコンテキスト保持。セッション内で有効
  • 長期記憶: セッションをまたいでの情報永続化。ユーザーの好みや過去のインタラクション履歴
  • エピソード記憶: 2025年12月に追加。エージェントが過去の経験（成功パターン・失敗パターン）から学習し、類似タスクでのパフォーマンスを向上させる

エピソード記憶は特に面白い機能です。ブログの例では、出張予約エージェントが「クライアント会議がある出張では、ユーザーが後からフライトを変更することが多い」というパターンを学習し、次回から変更可能なチケットを提案する、というシナリオが紹介されています。

CLIで試してみる

ここからは実際にAWS CLIでAgentCoreを操作してみた結果です。

  • AWS CLI: 2.34.27
  • リージョン: ap-northeast-1

CLIの構成

AgentCoreのCLIは2つのサービス名に分かれています。

  • aws bedrock-agentcore — データプレーン（30以上のコマンド）
  • aws bedrock-agentcore-control — コントロールプレーン（50以上のコマンド）

コントロールプレーンでリソースを作成・管理し、データプレーンでエージェントの実行やメモリの読み書きを行う設計です。

コントロールプレーンのコマンド構成

$ aws bedrock-agentcore-control help

AVAILABLE COMMANDS
  create-agent-runtime          # Runtimeの作成
  create-agent-runtime-endpoint # Runtimeエンドポイントの作成
  create-browser                # Browserの作成
  create-code-interpreter       # Code Interpreterの作成
  create-evaluator              # 評価器の作成
  create-gateway                # Gatewayの作成
  create-gateway-target         # Gatewayターゲットの作成
  create-memory                 # Memoryの作成
  create-oauth2-credential-provider  # OAuth2資格プロバイダの作成
  create-online-evaluation-config    # オンライン評価設定の作成
  create-policy                 # ポリシーの作成
  create-policy-engine          # ポリシーエンジンの作成
  ...（50以上のコマンド）

コンポーネントごとに create-*、get-*、list-*、update-*、delete-* が一通り揃っています。EFSやS3 Filesのような比較的シンプルなサービスと比べると、コマンド数の多さがAgentCoreの守備範囲の広さを物語っています。

Memoryの作成

試しにMemoryリソースを作成してみます。

$ aws bedrock-agentcore-control create-memory \
    --name testMemoryBlog \
    --event-expiry-duration 7 \
    --region ap-northeast-1 \
    --profile your-profile

{
    "memory": {
        "arn": "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:memory/testMemoryBlog-xxxxxxxxxx",
        "id": "testMemoryBlog-xxxxxxxxxx",
        "name": "testMemoryBlog",
        "eventExpiryDuration": 7,
        "status": "CREATING",
        "createdAt": "2026-04-23T09:56:42.998000+09:00",
        "updatedAt": "2026-04-23T09:56:42.998000+09:00",
        "strategies": []
    }
}

--event-expiry-duration はイベント（会話記録）の有効日数です。最初に 86400（秒のつもり）を指定したところ、以下のバリデーションエラーが出ました。

An error occurred (ValidationException) when calling the CreateMemory operation:
2 validation errors detected:
Value at 'name' failed to satisfy constraint: Member must satisfy regular expression pattern: [a-zA-Z][a-zA-Z0-9_]{0,47};
Value at 'eventExpiryDuration' failed to satisfy constraint: Member must have value less than or equal to 365

単位は日数（最大365日）で、名前は英数字とアンダースコアのみ（ハイフン不可）です。ドキュメントを確認せずに感覚で入れるとハマるポイントですね。

リソース一覧の確認

東京リージョンでのリソース一覧取得も問題なく動作しました。

$ aws bedrock-agentcore-control list-gateways --region ap-northeast-1 --profile your-profile
{
    "items": []
}

$ aws bedrock-agentcore-control list-memories --region ap-northeast-1 --profile your-profile
{
    "memories": []
}

$ aws bedrock-agentcore-control list-agent-runtimes --region ap-northeast-1 --profile your-profile
{
    "agentRuntimes": []
}

Gateway、Memory、Agent Runtimeの全てが東京リージョンで利用可能であることが確認できました。

料金

AgentCoreは従量課金制で、コンポーネントごとに料金体系が異なります（2026年4月時点 AgentCore Pricing）。

コンポーネント課金単位
Runtime / Browser / Code Interpreter秒単位のCPU消費 + ピークメモリ/秒。最小1秒、最小メモリ128MB。I/O待ちやアイドル時間は無料
GatewayMCP操作、検索クエリ、インデックス化ツール数に基づくAPI呼び出し課金
Policy認可リクエスト数 + 自然言語ポリシー記述の入力トークン数
IdentityRuntime/Gateway経由なら追加料金なし。それ以外はOAuthトークンまたはAPIキーリクエスト数
Memory短期: 作成イベント数。長期: 保存レコード数（日次平均、月次集計）+ 取得呼び出し数
Registryプレビュー期間中は無料

新規AWSユーザーには$200の無料利用枠もあります。Runtimeの「I/O待ちは無料」というのは、エージェントが外部APIのレスポンスを待っている間の課金がない、という意味で、実質的なコストを大きく下げてくれます。

Terraform対応

Terraform AWS Providerではv6.17.0（2025年10月）からAgentCoreリソースが追加されています。主なリソースは以下のとおりです。

プレビュー段階からTerraformリソースが充実しているのは珍しいと思います。v6.34.0〜v6.38.0にかけてもGateway TargetやRuntimeの機能拡張が継続的に入っており、活発に開発が進んでいることが分かります。

まとめ

AgentCoreは「AIエージェントのインフラ層」を包括的にカバーするサービスです。10個のコンポーネントが、実行環境・ツール連携・認証・メモリ・ガバナンス・品質評価・可観測性・カタログ管理という、エージェント本番運用に必要な要素を全てカバーしています。

自分が特に注目しているのは以下の3点です。

GatewayとPolicyの組み合わせ。既存のAPIをMCPツールに変換し、Cedarポリシーでアクセス制御する。エージェントに「どのツールを使っていいか」を宣言的に管理できるのは、企業環境でのAIエージェント導入において必須の機能だと思います。

Harnessによる参入障壁の低下。エージェントの推論ループ自体をマネージドにすることで、「まず動くものを作ってみる」までの時間が大幅に短縮されます。東京リージョンへの展開を期待しています。

フレームワーク・モデル非依存。LangGraphで作ったエージェントも、Strands Agentsで作ったエージェントも、同じAgentCoreのインフラ上で動かせます。特定のフレームワークにロックインされないのは、技術選定の自由度を保つ上で重要です。

一方で、10個のコンポーネントがある分、学習コストは低くありません。全部を一度に使う必要はないので、まずはGatewayでツール連携を試してみる、MemoryでセッションCONTEXTを永続化してみる、といった形で段階的に導入するのが良いと思います。