WorkHorizon
用語・トレンド解説

Amazon Bedrock AgentCore 徹底ガイド2026|Runtime/Gateway/Memory/Identity等9サービスでエンタープライズAIエージェントを本番運用する

2026/4/23

SHARE

Bedrock AgentCore 9サービスの役割・設計・コスト・A2A連携を一次ソース基準で解説

Am
用語・トレンド解説

Amazon Bedrock AgentCore 徹底ガイド2026|Runtime/Gateway/Memory/Identity等9サービスでエンタープライズAIエージェントを本番運用する

ARTICLEWork Horizon
W

Work Horizon編集部

2026/4/23 公開

Amazon Bedrock AgentCoreは、AWSがエンタープライズ向けに提供するAIエージェント実行基盤で、AWS公式「Amazon Bedrock AgentCore is now generally available」(2025年10月)で一般提供(GA)が開始されました。AWS 公式開発者ガイド(2026年4月時点)によれば、AgentCoreは Runtime / Gateway / Memory / Identity / Browser / Code Interpreter / Observability / Evaluations / Policy などのサービス群から構成されます。本記事では、AgentCore 一式をエンタープライズ要件(VPC・IAM・監査・マルチテナント)で採用する前提で、設計のポイント、各サービスの役割、運用上の落とし穴まで整理します。Bedrock全体像(Foundation Models・Agents・Knowledge Bases・Guardrails・Pricing)のまとめはAWS Bedrock 使い方完全ガイド2026を、MCPとの接続はMCP完全ガイド2026主要MCPサーバー比較レビューを参照してください。

Amazon Bedrock AgentCoreとは|基本の整理

AWS公式「Amazon Bedrock AgentCore」(2026年4月時点)の位置づけは、AIエージェントを安全・スケーラブルに本番運用するためのマネージド基盤。従来のBedrock Agents(シンプルなエージェント実装)とは別レイヤーで、Runtime/Gateway/Memory/Identity等のサービスを組み合わせて、独自のエージェントを AWS上で動かすための土台として設計されています。

  • GA時期:2025年10月(AWS公式What's new
  • 対象ユーザー:独自のAIエージェントをAWSで本番運用したい企業・開発者
  • Bedrock Agentsとの違い:Bedrock Agents は簡易なエージェント実装、AgentCoreは任意のフレームワーク(LangGraph/Strands/CrewAI/AutoGen等)で作ったエージェントをホスティング&運用する基盤
  • エンタープライズ対応:GA時点でVPC/AWS PrivateLink/CloudFormation/resource taggingに対応(AWS News Blog

AgentCoreの主要サービス|9つの構成要素

AgentCoreは独立して使えるサービスの集合として設計されており、必要な要素だけを選んで組み合わせる思想です。AWS公式開発者ガイドで解説されている主要サービスは以下のとおり。

Runtime|セキュア・サーバーレスなエージェント実行環境

AgentCore Runtime 公式ドキュメント(2026年4月時点)によれば、Runtimeは各ユーザーセッションを独立したmicroVM(CPU/Memory/ファイルシステム分離)で実行する仕組み。最大8時間のロングランワークロードに対応し、リアルタイム対話もバッチ型長時間処理も同じ基盤で動かせるのが特徴です。

  • 分離レベル:microVM単位でユーザーセッションを分離(マルチテナント前提)
  • 最大実行時間:8時間(公式ドキュメント記載)
  • SDK:AgentCore SDK(Memory/Tools/Gateway連携含む)
  • A2A対応:Agent-to-Agent protocol サポート(AWS Machine Learning Blog

Gateway|ツールの統合アクセスレイヤー

AgentCore Gateway 公式ドキュメント(2026年4月時点)によれば、Gatewayはエージェントからツールを探索・呼び出す統合エンドポイント。APIやAWS Lambda関数から zero-code で MCPツールを生成でき、Inbound/Outbound の両方向で認証制御が入ります。

  • 主な機能:ツール発見、MCPツール自動生成、サーバーレス実行、認証制御
  • 対応ソース:OpenAPIスキーマ、Lambda関数、既存MCPサーバー
  • 認証:Inbound認証(エージェント→Gateway)とOutbound認証(Gateway→外部)を別設計

Memory|セッション跨ぎのコンテキスト保持

AgentCore Memoryは、短期/長期メモリを区別してエージェントに提供する管理基盤。過去の会話・決定・ユーザープロファイルを構造化して保持し、複数セッション間で参照できるようにします。開発者はメモリの保存期間や取得戦略をパラメータで制御可能です。

Identity|エージェントへの独立した認証・認可

AgentCore Identityは、AIエージェントに独立したアイデンティティを割り当て、Okta / Microsoft Entra ID / Amazon Cognito等の既存IdPと連携します。エージェントが外部APIにアクセスする際は、ユーザー委譲モード/自律モード の2方式から選択し、OAuthトークンやAPIキーの払い出しを AWSマネージドで行う設計です(AgentCore Pricing公式によれば、RuntimeまたはGateway経由の場合Identity追加課金なし)。

Browser / Code Interpreter|エージェントの拡張実行能力

Browser サービスはヘッドレスブラウザ、Code Interpreter はサンドボックス化されたコード実行環境を提供。AIエージェントにWebブラウジングやコード実行を「マネージド側」で持たせることで、ユーザー環境に侵襲的なサンドボックス構築を要求しない設計になっています。

Observability|監視とデバッグ

Observabilityは、エージェント呼び出しのトレース、ツール呼び出し履歴、メモリ取得のトレース等を可視化するサービス。CloudWatchと統合され、メトリクス/ログ/トレースを横断的に分析できます。

Evaluations|エージェント品質の継続評価

Evaluationsは、エージェントの応答品質をスコアリングするサービス。シナリオテスト、LLM-as-a-Judgeパターン、実運用データを用いた継続評価に対応し、回帰リスクを数値化します。

Policy|細粒度のアクション制御

Policyは、エージェントが実行できるアクションをきめ細かく制御するサービス。特定ツール呼び出しの許可/拒否、引数制約、監査対象アクションの定義等をポリシーとして記述でき、AWS公式アップデートで episodic memory と組み合わせた運用が案内されています。

エンタープライズ向け設計|VPC・IAM・ネットワーク分離

GA時点でAgentCoreは、AWS News Blog(2025年10月)に記載のとおり、VPC・AWS PrivateLink・CloudFormation・resource tagging に対応済みです。エンタープライズ採用の観点では以下がポイントになります。

  • VPCエンドポイント:社内ネットワークから外に出さずにAgentCore呼び出し可能
  • PrivateLink:AgentCoreサービスへのプライベート通信経路
  • CloudFormation:IaCでのデプロイ・ガバナンス強化
  • resource tagging:コスト配賦・アクセス制御の前提(Tag-based IAM)
  • IAM連携:Identity とRoleベース認可を組み合わせ、ユーザー代理実行の追跡性を確保

Bedrock Agents / Knowledge Bases / Guardrails との使い分け

Bedrock 周辺機能は似た名前で混同しやすいため、次の整理が実務上の前提になります(Amazon Bedrock Agents公式Amazon Bedrock Guardrails公式Amazon Bedrock公式 いずれも 2026年4月時点)。

  • Bedrock Agents:Bedrock内蔵の簡易エージェント。シンプルな社内ユースケースや検証向け
  • AgentCore:任意のフレームワークで作ったエージェントを AWS上でホスティング・運用する基盤
  • Knowledge Bases:マネージドRAG。AgentCoreエージェントから呼び出して社内データ検索に使う
  • Guardrails:入出力フィルタリング。AgentCoreエージェントとも、Strands等の外部フレームワークとも組み合わせ可能

実装フロー|AgentCoreを使った本番エージェント構築の流れ

典型的な導入フローは次のとおりです。各ステップで一次ドキュメントを参照し、社内セキュリティ要件との整合を取りながら進めます。

  1. エージェント設計:ユースケース、ツール一覧、メモリ要件、評価指標を定義
  2. フレームワーク選定:LangGraph / Strands Agents / CrewAI / AutoGen など、既存実装を活かせるものを選ぶ
  3. Runtimeへのデプロイ:AgentCore SDK経由でmicroVMホスティングに載せる
  4. Gateway設定:既存APIやLambdaをMCPツールに変換、Inbound/Outbound認証を設計
  5. Memory / Identity接続:長期メモリ戦略と企業IdPの接続を設計
  6. Observability / Evaluations:CloudWatchへのメトリクス出力、評価ジョブの定義
  7. Policy適用:禁止アクション/許可アクション/監査対象を記述
  8. VPC/PrivateLink:ネットワーク分離とCloudFormationテンプレ化

運用の落とし穴|コスト・レイテンシ・A2A連携

コスト設計

AgentCore Pricing公式(2026年4月時点)によれば、Runtime・Gateway・Memory等は使用量ベース課金で、Identityは Runtime/Gateway経由の場合は追加課金なし。ただし本体のBedrockモデル呼び出し料金、Knowledge Basesのベクトル検索料金、Guardrails料金が別途かかるため、エージェント1回あたりのトータル原単位を試算してから本番導入する必要があります。

レイテンシとタイムアウト

microVMは起動オーバーヘッドがあるため、最初のコールが相対的に遅い傾向があります。Runtime は最大8時間の長時間ワークロードに対応する設計なので、短時間での応答が重要なユースケース(コールセンターの音声対話等)とは別設計が望ましい場合があります。

Agent-to-Agent(A2A)連携

AWS Machine Learning Blog「Introducing agent-to-agent protocol support in Amazon Bedrock AgentCore Runtime」のとおり、AgentCore Runtime は A2A プロトコルをサポート。複数のエージェントがサービスを跨いで連携する分散エージェント設計が可能になります。ただし、A2A連携は認証・監査・依存管理が複雑化するので、最初は単一エージェントで MVP を作り、後から A2A 化する段階的導入が現実的です。

Strands Agents / LangGraph との連携

AgentCore は特定フレームワークに縛られない設計です。Amazon Bedrock Guardrails公式でも「Strands Agents等のエージェントフレームワークで実装したエージェントを AgentCore にデプロイした上で Guardrails を適用できる」と案内されています。LangGraph や CrewAI・AutoGen で作ったエージェントも同様に Runtime でホスティング可能です。これにより、既存フレームワーク資産を捨てずにAWSのエンタープライズ基盤に移行できるのが AgentCore 採用の大きな理由になります。

学習リソースとキャリアへの示唆

AgentCore の深い理解には、以下の一次ソースの通読が有効です。

エンタープライズAIエージェントを設計・運用する技術者にとって、AgentCore は「LangGraph/Strandsで作ったものをどうやって本番に載せるか」の一次ソリューションの1つです。AI時代のキャリア戦略ガイドAIエンジニア年収・キャリアパス2026 も合わせて参考にしてください。

まとめ|AgentCoreは「エージェント本番運用のマネージド土台」

Amazon Bedrock AgentCoreは、2025年10月GA以降、VPC/PrivateLink/CloudFormation/resource tagging に対応したエンタープライズ向けAIエージェント基盤として位置付けられています。Runtime/Gateway/Memory/Identity/Browser/Code Interpreter/Observability/Evaluations/Policy の9サービスを必要に応じて組み合わせ、LangGraph・Strands・CrewAI等の既存フレームワークで作ったエージェントを AWS上で本番運用する土台として機能します。コスト・レイテンシ・A2A連携の落とし穴を踏まえ、まずは単一エージェントで MVP を作り、Observability / Evaluations / Policy を段階的に強化していくのが現実的な導入パターンです。Bedrock全体像はAWS Bedrock 使い方完全ガイド2026でフォローしてください。

SHARE

よくある質問

Q.Bedrock AgentsとAgentCoreは何が違いますか?どちらを選ぶべき?
A.Bedrock AgentsはBedrock組み込みの簡易エージェント実装で、社内問い合わせボットや簡単な業務自動化など素早く立ち上げたいユースケース向けです。一方AgentCoreは、LangGraph・Strands・CrewAI・AutoGen等の任意のフレームワークで作った独自エージェントをAWS上でセキュアに本番運用するための基盤で、microVM分離・A2A対応・VPC/PrivateLink等のエンタープライズ要件を満たせます。既存のエージェント資産があるならAgentCore、ゼロから簡易なエージェントだけ作るならBedrock Agentsが妥当です。
Q.AgentCoreのコストはどう試算すればよいですか?
A.AgentCore本体(Runtime・Gateway・Memory等)は使用量ベースでそれぞれ個別課金になり、IdentityはRuntime/Gateway経由の利用であれば追加課金なしというのがAWS公式ドキュメントの記載です。実際のトータルコストには、Bedrock本体のモデル推論料金、Knowledge Basesのベクトル検索料金、Guardrails料金が加算されます。エージェント1回あたりの平均トークン数と外部API呼び出し回数を試算し、単価×月間想定回数で試算するのが実務的な進め方です。
Q.AgentCoreはVPC内で完結させて使えますか?
A.2025年10月のGA時点で、AgentCoreの主要サービスはVPC・AWS PrivateLink・CloudFormation・resource taggingに対応しており、エンタープライズのネットワーク分離要件を満たす設計が可能です。PrivateLink経由でAgentCoreエンドポイントにアクセスすれば、インターネット境界を跨がずに社内ネットワーク内で完結したエージェント運用ができ、IAMとIdentityを組み合わせて監査要件も満たせます。ただしBedrockモデル推論側のVPC設定も別途必要なので、統合構成の検証は初期段階で実施してください。
Q.Agent-to-Agent(A2A)連携はいつ使うべきですか?
A.A2A連携は、単一エージェントで責務が肥大化した場合や、異なるシステム/チーム所有のエージェントを連携させたい場合に有効です。AWS Machine Learning Blogの発表によればAgentCore RuntimeはA2Aプロトコルをサポートしますが、認証・監査・依存管理が複雑化するので、最初は単一エージェントでMVPを作りObservabilityで実測値を取った上で、境界と責務を切り出す形で段階的にA2A化するのが現実的です。いきなり複数エージェントの分散設計から入るのは避けた方が運用トラブルが少なくなります。
Q.LangGraphやStrands Agentsで作ったエージェントをAgentCoreに載せられますか?
A.はい、AgentCoreはフレームワーク非依存の設計で、LangGraph・Strands Agents・CrewAI・AutoGen等で実装したエージェントをRuntimeにホスティングできます。AWS公式のBedrock Guardrails解説でも「Strands Agents等のフレームワークで実装したエージェントをAgentCoreにデプロイしGuardrailsを適用できる」と案内されています。既存フレームワーク資産を捨てずに、AWSのエンタープライズ基盤(VPC・IAM・監査・マルチテナント分離)に移行できるのがAgentCore採用の大きな理由になります。

関連記事