はじめに
この記事では、AWS の AI エージェント構築における2つのサービス、Amazon Bedrock Agents と Amazon Bedrock AgentCore を比較します。それぞれの特徴、使い分けのポイントを記載します。
Amazon Bedrock / Agents / AgentCore の関係性
まず、3つのサービスの関係性を整理しておきます。
Amazon Bedrock は基盤モデルアクセス、ナレッジベース、ガードレール等を含む生成 AI プラットフォーム全体を指します。その中にエージェント関連のサービスとして Bedrock Agents と AgentCore が存在します。
Bedrock Agents は設定ベースのマネージドなエージェント構築サービス、AgentCore はコードファーストで任意のフレームワーク・モデルを使い、より細かい制御を可能にするエージェント運用プラットフォームです。
リリース時系列
| サービス | プレビュー | GA(正式リリース) |
|---|---|---|
| Amazon Bedrock | 2023年4月 | 2023年9月 |
| Bedrock Agents | 2023年7月 | 2023年11月(re:Invent 2023) |
| AgentCore | 2025年7月 | 2025年10月 |
Amazon Bedrock Agents と AgentCore の概要
Amazon Bedrock Agents
Amazon Bedrock Agents は、AWS が提供するフルマネージドな AI エージェント構築サービスです。インフラストラクチャの管理やオーケストレーションコードの記述なしに、GUI ベースまたは設定ベースのアプローチでエージェントを構築できます。
以下のような特徴があります。
- GUI / API による設定ベースのエージェント構築
- インフラストラクチャ管理不要のフルマネージド
- Action Groups によるツール統合
- Knowledge Bases によるナレッジ連携
- マルチエージェントコラボレーション対応
- セッション横断のメモリ保持(SESSION_SUMMARY、最大365日)
- コードインタープリテーション対応
- Amazon Bedrock 上のモデルを使用(Anthropic、Meta、Mistral、OpenAI OSS、DeepSeek 等100以上のモデル)
Amazon Bedrock AgentCore
Amazon Bedrock AgentCore は、あらゆるフレームワーク・あらゆるモデルを使用して AI エージェントを安全かつ大規模にデプロイ・運用するためのエージェンティックプラットフォームです。
以下のような特徴があります。
- フレームワーク非依存(Strands Agents、LangGraph、CrewAI、LlamaIndex 等)
- モデル非依存(Bedrock、OpenAI、Gemini 等)
- モジュラーなサービス構成(Runtime、Gateway、Memory、Identity、Observability)
- 完全なセッション分離による高セキュリティ
- 最大8時間の長時間実行ワークロード対応
- コードファーストのアプローチ
主な機能差分
両サービスの機能の違いを整理します。
| 観点 | Bedrock Agents | AgentCore |
|---|---|---|
| 使用可能なモデル | Amazon Bedrock 上のモデル | 任意のモデルプロバイダー(Bedrock 外も利用可能) |
| フレームワーク | Bedrock のマネージドサービスとして提供 | 任意のフレームワーク(Strands Agents、LangGraph、CrewAI、LlamaIndex 等) |
| ツール統合 | Action Groups(Lambda / Return Control) | AgentCore Gateway(MCP プロトコル) |
| メモリ | セッション内コンテキスト + SESSION_SUMMARY による複数セッション保持(最大365日) | 短期メモリ(イベント単位の会話履歴)+ 長期メモリ(ユーザー嗜好・事実の自動抽出、セマンティック検索) |
| オブザーバビリティ | CloudWatch Logs + Trace 機能 | CloudWatch + OpenTelemetry 互換のテレメトリ |
| セッション分離 | マネージドサービスとして提供 | 専用 microVM による完全なセッション分離 |
| 実行時間 | マネージドサービスの制限内 | 最大8時間の非同期ワークロード |
| 認証・認可 | IAM + Bedrock Guardrails | AgentCore Identity(Cognito / Entra ID / Okta)+ AgentCore Policy |
モデル選択の違いについて
Bedrock Agents は Amazon Bedrock 上で利用可能なモデルを使用します。Bedrock 自体は Anthropic、Meta、Mistral、OpenAI OSS、DeepSeek、Cohere 等100以上のモデルを提供しており、カスタムモデルのインポートにも対応しています。
一方、AgentCore はモデルプロバイダーに依存しない設計で、Bedrock 上のモデルに加え、Bedrock 外のモデルプロバイダー(OpenAI API、Google Gemini API 等)を直接利用することも可能です。
メモリの違いについて
Bedrock Agents のメモリは SESSION_SUMMARY タイプで、セッション終了時に会話サマリーを生成・保存し、次のセッションで参照できます(最大365日保持)。
AgentCore Memory は、短期メモリ(イベント単位の生の会話履歴)と長期メモリ(会話から自動抽出されたユーザー嗜好・事実・サマリー)の2層構成です。長期メモリではセマンティック検索による関連記憶の取得が可能で、メモリ戦略(サマリー、ユーザー嗜好抽出等)をカスタマイズできます。
基本的な実装の比較
同じ「ユーザーの質問に回答するエージェント」を両方のサービスで実装して比較してみます。
Bedrock Agents での実装
Bedrock Agents では、boto3 SDK を使って設定ベースでエージェントを構築します。
import boto3
bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1")
# エージェントの作成
agent = bedrock_agent.create_agent(
agentName="my-support-agent",
foundationModel="anthropic.claude-sonnet-4-20250514",
instruction="""あなたはカスタマーサポートのエージェントです。
ユーザーの質問に丁寧に回答してください。""",
agentResourceRoleArn="arn:aws:iam::123456789012:role/BedrockAgentRole",
)
agent_id = agent["agent"]["agentId"]
# エージェントの準備(デプロイ可能状態にする)
bedrock_agent.prepare_agent(agentId=agent_id)
import boto3
runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
response = runtime.invoke_agent(
agentId="AGENT_ID",
agentAliasId="ALIAS_ID",
sessionId="session-001",
inputText="返品ポリシーについて教えてください",
)
for event in response["completion"]:
if "chunk" in event:
print(event["chunk"]["bytes"].decode())
AgentCore での実装
AgentCore では、好みのフレームワーク(ここでは Strands Agents)を使ってコードファーストで構築します。
from strands import Agent
from bedrock_agentcore.runtime import BedrockAgentCoreApp
# Strands Agent の作成(任意のフレームワークで代替可能)
agent = Agent(
system_prompt="""あなたはカスタマーサポートのエージェントです。
ユーザーの質問に丁寧に回答してください。""",
)
# AgentCore Runtime にデプロイするためのラッパー
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload):
"""ユーザー入力を処理してレスポンスを返す"""
user_message = payload.get("prompt", "Hello")
result = agent(user_message)
return {"result": result.message}
if __name__ == "__main__":
app.run()
# AgentCore CLI でデプロイ
agentcore configure --entrypoint my_agent.py -er <IAM_ROLE_ARN>
agentcore launch
# エージェントの呼び出し
agentcore invoke '{"prompt": "返品ポリシーについて教えてください"}'
実装の違い
| 観点 | Bedrock Agents | AgentCore |
|---|---|---|
| 構築アプローチ | 設定ベース(GUI / API) | コードファースト |
| 使用モデル | Amazon Bedrock 上のモデル | 任意のモデルプロバイダー(Bedrock 外も可) |
| フレームワーク | マネージドサービスとして提供 | 任意(Strands、LangGraph 等) |
| デプロイ方法 | prepare_agent API | CLI / CDK / Terraform |
| 記述量 | 少ない(設定で完結) | やや多い(自由度が高い) |
ツール統合の比較
エージェントが外部 API やデータベースと連携する仕組みを比較します。
Bedrock Agents のツール統合
Bedrock Agents では、Action Groups と Lambda 関数 を使ってツールを統合します。
# Lambda 関数としてツールを定義
def lambda_handler(event, context):
action = event["actionGroup"]
api_path = event["apiPath"]
if api_path == "/getOrderStatus":
order_id = next(
p["value"] for p in event["parameters"]
if p["name"] == "orderId"
)
# 注文状況を取得するロジック
return {
"statusCode": 200,
"body": {
"orderId": order_id,
"status": "配送中",
"estimatedDelivery": "2026-02-12",
},
}
# Action Group の作成
bedrock_agent.create_agent_action_group(
agentId=agent_id,
agentVersion="DRAFT",
actionGroupName="OrderActions",
actionGroupExecutor={"lambda": lambda_arn},
apiSchema={
"payload": open("openapi_schema.json").read(),
},
)
AgentCore のツール統合
AgentCore では、AgentCore Gateway を使い、既存の API や Lambda を MCP 互換のツールに変換します。
from strands import Agent
from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters
# AgentCore Gateway 経由で MCP ツールを利用
mcp_client = MCPClient(
lambda: stdio_client(
StdioServerParameters(
command="npx",
args=["-y", "@anthropic/my-mcp-server"],
)
)
)
with mcp_client:
agent = Agent(
system_prompt="注文管理をサポートするエージェントです。",
tools=mcp_client.list_tools(),
)
response = agent("注文 #12345 の状況を教えてください")
AgentCore Gateway を使えば、既存の API Gateway や Lambda 関数を最小限のコードでエージェント対応ツールに変換できます。
ツール統合の違い
| 観点 | Bedrock Agents | AgentCore |
|---|---|---|
| 統合方式 | Action Groups(Lambda / Return Control) | AgentCore Gateway + MCP |
| ツール定義 | OpenAPI スキーマ | MCP プロトコル |
| プロトコル | OpenAPI ベース | MCP(オープンスタンダード) |
メモリ管理の比較
エージェントがコンテキストを保持する仕組みを比較します。
Bedrock Agents のメモリ
Bedrock Agents では、セッション内のコンテキスト保持に加え、SESSION_SUMMARY によるセッション横断のメモリ保持が可能です。メモリを有効にすると、セッション終了時に会話サマリーが生成・保存され、後続のセッションで参照できます(最大365日保持)。
# 同一セッションでの会話
response1 = runtime.invoke_agent(
agentId="AGENT_ID",
agentAliasId="ALIAS_ID",
sessionId="session-001",
inputText="私は森田です。東京に住んでいます。",
)
# 同じ session_id を使うことでコンテキストを維持
response2 = runtime.invoke_agent(
agentId="AGENT_ID",
agentAliasId="ALIAS_ID",
sessionId="session-001",
inputText="私の名前と住んでいる場所を覚えていますか?",
)
# → 「森田さんですね。東京にお住まいです。」
AgentCore のメモリ
AgentCore Memory は、短期メモリと長期メモリの両方をサポートし、セッションを超えたコンテキスト維持が可能です。
from datetime import datetime
from strands import Agent
from bedrock_agentcore.memory import MemoryClient
from bedrock_agentcore.memory.integrations.strands.config import (
AgentCoreMemoryConfig,
RetrievalConfig,
)
from bedrock_agentcore.memory.integrations.strands.session_manager import (
AgentCoreMemorySessionManager,
)
# メモリクライアントの作成
client = MemoryClient(region_name="us-east-1")
# 短期+長期メモリを持つメモリストアを作成
memory = client.create_memory_and_wait(
name="SupportAgentMemory",
description="カスタマーサポート用メモリ",
strategies=[
{
"summaryMemoryStrategy": {
"name": "SessionSummarizer",
"namespaces": ["/summaries/"],
}
},
{
"userPreferenceMemoryStrategy": {
"name": "UserPreferences",
"namespaces": ["/preferences/"],
}
},
],
)
# メモリ設定
config = AgentCoreMemoryConfig(
memory_id=memory["id"],
session_id="session-001",
actor_id="user-morita",
)
session_manager = AgentCoreMemorySessionManager(
memory_client=client,
config=config,
)
# メモリ付きエージェント
agent = Agent(
system_prompt="ユーザーの好みや過去の会話を踏まえて回答してください。",
session_manager=session_manager,
)
agent("寿司が好きです、特にマグロが好きです")
# → エージェントがユーザーの好みを記憶
agent("今日のランチは何がいいですか?")
# → マグロの寿司を含むおすすめを提案
メモリ管理の違い
| 観点 | Bedrock Agents | AgentCore |
|---|---|---|
| セッション内 | 会話コンテキスト保持 | イベント単位の会話履歴(短期メモリ) |
| セッション横断 | SESSION_SUMMARY(サマリーベース、最大365日) | 長期メモリ(嗜好・事実の自動抽出) |
| メモリ戦略 | SESSION_SUMMARY のみ | カスタマイズ可能(サマリー、ユーザー嗜好抽出等) |
| 検索 | — | セマンティック検索による関連記憶の取得 |
オブザーバビリティの比較
Bedrock Agents のモニタリング
Bedrock Agents では、CloudWatch Logs と Trace 機能で動作を監視します。
response = runtime.invoke_agent(
agentId="AGENT_ID",
agentAliasId="ALIAS_ID",
sessionId="session-001",
inputText="注文状況を教えてください",
enableTrace=True,
)
for event in response["completion"]:
if "trace" in event:
trace = event["trace"]["trace"]
for key, value in trace.items():
print(f"{key}: {value}")
AgentCore のオブザーバビリティ
AgentCore Observability は、OpenTelemetry 対応の包括的な監視機能を提供します。
AgentCore Observability では以下を追跡できます。
- トークン使用量・コスト
- レイテンシー・セッション継続時間
- エラー率・成功率
- エージェントのワークフロー全体の可視化
- 各ステップの判断過程の監査
| 観点 | Bedrock Agents | AgentCore |
|---|---|---|
| 監視方法 | CloudWatch Logs + Trace | CloudWatch + OpenTelemetry 互換テレメトリ |
| 外部システム統合 | CloudWatch 経由 | OpenTelemetry 対応システムへの出力が可能 |
セキュリティの比較
Bedrock Agents のセキュリティ
- IAM ロールベースのアクセス制御
- Bedrock Guardrails による入出力フィルタリング
- 転送中・保存中のデータ暗号化
AgentCore のセキュリティ
- 完全なセッション分離:各セッションが専用の microVM で実行
- AgentCore Identity:Cognito、Entra ID、Okta 等のIDプロバイダーとネイティブ統合
- AgentCore Policy:自然言語でエージェントの行動境界を定義
- VPC 接続、AWS PrivateLink サポート
使い分けのポイント
Bedrock Agents が適している場合
- 素早いプロトタイピング: GUI で数クリックでエージェントを構築したい場合
- ノーコード / ローコード: 開発者以外のメンバーもエージェントを設定する場合
- Bedrock エコシステム内で完結: Bedrock のモデルとナレッジベースで十分な場合
- インフラ管理を避けたい: プロンプト工学、メモリ、API 呼び出し、暗号化を自動で任せたい場合
AgentCore が適している場合
- フレームワークの自由度: LangGraph、CrewAI など既存のフレームワークを活用したい場合
- Bedrock 外のモデルを利用したい: OpenAI API や Google Gemini API を直接呼び出したい場合
- 高度なメモリ管理: ユーザー嗜好の自動抽出やセマンティック検索など、SESSION_SUMMARY 以上のメモリ機能が必要な場合
- 長時間実行タスク: 最大8時間の非同期ワークロードが必要な場合
- セッション分離: microVM による完全なセッション分離が必要な場合
- OpenTelemetry 互換の監視: 既存の OpenTelemetry 対応システムと統合したい場合
Bedrock Agents から AgentCore への移行
Bedrock Agents でプロトタイピングし、要件が複雑化したら AgentCore に移行するというアプローチが可能です。
AgentCore の CLI には import-agent コマンドがあり、既存の Bedrock Agents を AgentCore に移行する機能も提供されています。
まとめ
この記事では、Amazon Bedrockにおけるエージェント構築サービスの「Agents」と「AgentCore」の比較について記載しました。設定ベースで手軽に構築できるマネージドなAgentsに対し、AgentCoreはコードファーストで外部モデルや任意のフレームワークを自由に組み合わせられる柔軟性が特徴です。手軽な試作にはAgents、高度なカスタマイズや厳格なセキュリティを求める本番運用にはAgentCoreといった使い分けが考えられます。