はじめに
AgentCoreとBedrock Agentsの違いを端的に表現すると、「AgentCoreは自作したAIエージェントの実行基盤で、Bedrock AgentsはマネージドなAIエージェント」 です。この一文で理解できた方には、この記事は必要ないと思うので AI Agent on AWS Advent Calendar 2025の別の記事を読みましょう！
一方で、AIエージェントの開発経験のない方が「AIエージェントの実行基盤」と「マネージドなAIエージェント」の違いをイメージすることは難しいのではないでしょうか。（私がそうでした）
ということで、本記事ではAIエージェントの概念・実装を踏まえて、AgentCoreとBedrock Agentsの違いを整理してみます。
想定読者
- AgentCore/Bedrock Agentsの違いを正しく理解したい人
- AIエージェントの振る舞いは分かるが、AIエージェントの実装やMCPとの関係性の理解はあいまいな人
この記事を読んだから分かること
- AgentCore/Bedrock Agentsを使った場合、AIエージェントの実装方法がどのように変わるのか
※出典元を明記している画像を除いて、本記事で使用している画像は生成AIによって生成した画像です。
AIエージェントおさらい
まず「AIエージェント」とは何でしょうか。AWSの解説ページがあったので、引用させていただきます。
事前に決められた目標を達成するためのソフトウェアプログラムです。目標は人間が設定しますが、その目標を達成するために実行する必要がある最適なアクションは AI エージェントが独自に選択します。
出典：AI エージェントとは?
つまり、人間に設定された目標を達成するために、自分で考えて行動するソフトウェアのことを「AIエージェント」と呼びます。
AIとAIエージェントの違い
従来のAIとAIエージェントの違いは、「行動できるかどうか」 です。
AIだけを搭載したチャットボットであれば、質問内容に対して回答を行うだけでした。実際の処理は以下の流れになります。
- LLMに入力（ユーザーからの質問）を与える
- LLMからの出力（回答）をユーザーに返す
AIエージェントの場合は、ここに行動が伴います。例えば、「AさんとBさんが参加する会議を設定して」とお願いすれば、AさんとBさんの予定を参照したうえで、カレンダーツールやメールを使って会議案内を送信するが可能です。このとき、裏側では以下の処理が実行されます。
- LLMに目標（AさんとBさんが参加する会議を設定）と環境情報（Aさん/Bさんの予定）を入力する
- LLMが入力内容をもとにAIエージェントの行動を判断し、出力をAIエージェントに返す
- AIエージェントはLLMの判断に従って行動（会議の設定/メールの送信など）を起こす
AIエージェントの特徴
考えるだけでなく、考えた内容に従って行動を起こすことができる
AIエージェントのツールとMCP
AIエージェントが実行を起こすためのコンポーネントは「ツール」と呼ばれることが多いです。実体は事前に用意したプログラムや外部サービスのAPI、データベースへのクエリ等です。AIエージェントを実装する場合、ツールは以下のように使用されます。
- ツール（プログラム・APIなど）を用意
- 利用できるツールをAIエージェントに登録
- AIエージェントはユーザーから目標が与えられたら、LLMを使って適切なツールを選択・使用
LLM（頭）だけでなくツール（手足）を使えるようにすることで、AIエージェントはAIの能力を拡張しています。
最近AIエージェントとセットでよく登場する 「MCP(Model Context Protocol)」は、AIエージェントとツールのやりとりを標準化する規格です。 MCPの登場まではAIエージェントごとにツールの書き方がバラバラで、AIエージェント側もツール側も実装・メンテナンスに課題がありました。MCPを活用することで、あらゆるAIエージェントが共通の方法でツールを呼び出せるようになっています。
出典：https://modelcontextprotocol.io/docs/getting-started/intro
AIエージェントの実装
AIエージェントはLLMとツールで構成されますが、実際にどのような実装になるのか、ソースコードを示しながらポイントを整理します。AIエージェントを実装するためのフレームワークは複数ありますが、今回はAWSが開発している「StrandsAgents」で記述した場合のサンプルになります。
# ※ 簡略化したコードのため、このままでは動きません ※
from strands import Agent, tool
from mcp import stdio_client, StdioServerParameters
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp import MCPClient
###########################
# ローカルツールの定義
###########################
@tool(name="calculate_tax", description="入力された金額から消費税を計算します")
def calculate_tax(amount: float) -> float:
"""
（省略）金額を受け取り、消費税を計算する処理
"""
return result
# MCPクライアントを作成
external_mcp = MCPClient(
lambda: streamablehttp_client("https://mcp.global.api.aws") # MCPサーバーを指定
)
###########################
# AIエージェントの定義
###########################
agent = Agent(
name="SalesAssistant",
# 【LLMの指定】BedrockのモデルIDなどを指定
model="anthropic.claude-3-sonnet-20240229-v1:0",
# 【システムプロンプト】エージェントの役割や振る舞いを自然言語で指示
instructions="""
あなたは優秀な売上管理アシスタントです。
ユーザーからの質問に対して、丁寧な口調で回答してください。
計算が必要な場合は、必ず提供されたツールを使用してください。
""",
# 【ツール】エージェントが使用できるツールをリストで渡す
tools=[
calculate_tax, # 定義したローカルツール（Python関数）の指定も可能
external_mcp # MCPサーバーはClientインスタンスで渡す
]
)
###########################
# エージェントの実行
###########################
# agentインスタンスには、ユーザープロンプトを引数として渡す
response = agent("19800円の商品の税込価格を教えて")
print(response)
実装時のポイントは以下の通りです。
- LLMの指定：
- AIエージェントの頭脳として、どのモデルを利用するか指定します
- システムプロンプト：
- LLMに渡すプロンプトを指定します
- 「どういった役割として回答するのか」「するべきではないこと」など、LLMの思考の指針を自然言語で定義します
- ツール
- AIエージェントが行動する際に利用できるツールを指定します
StrandsAgentsの場合、ツールの仕様について以下の特徴があります
- MCPサーバーの指定方法
- 接続先のMCPサーバーを指定したMCPクライアントを作成し、ツールにはMCPクライアントインスタンスを渡す
- ローカルツールを定義できる
- Python関数をツールとして定義してAIエージェントから使用可能
- 通常通り作成したPython関数に
@toolデコレータで「ツール名」、「ツールの説明」を追加するだけでローカルツールとして使用できる
AIエージェントを実装するためのAWSサービス
AIエージェントをAWSサービスで動かしたい場合どのような方法があるかというと、代表的なAWSサービスは以下の2つだと思います。
- Amazon Bedrock AgentCore
- Amazon Bedrock Agents
AWSで生成AIアプリケーションをつくるといえばBedrockですが、AIエージェントの実装機能もBedrockの機能に含まれる位置づけで提供されています。（個人的にAgentCoreはBedrockのブランドから外した方が分かりやすいと思うのですが…）
この2つの機能の違いを見ていきましょう。
Bedrock AgentCoreを使ってできること
AgentCoreはAIエージェントをデプロイ・運用するためのプラットフォームで、実装したAIエージェントの運用を支援する複数の機能を提供しています。AgentCoreは複数のモジュールで構成されますが、代表的な「AgentCore Runtime」について取り上げたいと思います。
出典：Amazon Bedrock AgentCore、東京を含むAWSリージョンで一般提供開始：AIエージェントを現実の世界へ
これまで見てきたように、「AIエージェント」の実体は普通のプログラムなので、ユーザーに提供するためにはどこかにデプロイする必要があります。AgentCore RuntimeはAIエージェント専用のサーバーレスな実行環境を提供します。
AgentCore Runtimeの特徴
AgentCore RuntimeにAIエージェントをデプロイする方法は現在、以下の2種類が用意されています。Lambdaと同じようなサービスとイメージしておくと分かりやすいと思います。
- zip化したファイルをS3にアップロード
- DockerイメージにしてECRにプッシュ
ただしLambdaと違って、実行時間は最大8時間となっています。他にも、AIエージェントに特化したサーバーレス環境として、以下のような特徴があります。
-
任意のフレームワークを使ったAIエージェントの実装:
LangGraph, CrewAI, LlamaIndex, StrandsAgents など、AIエージェントを実装するためのフレームワークは自由に選択できます。Runtimeはあくまで実行環境のため、AIエージェントの実装方法は制限されません
-
モデルの選択も自由:
Amazon Bedrockで提供されるモデルだけでなく、OpenAI (GPT), Google (Gemini), などAWS外のモデルの利用もサポートされています。
（個人的に、AgentCoreをBedrockとは別サービスにした方がよいと考える理由がこれです）
-
MCPとA2Aをサポート:
Runtimeは実行環境のため、MCPサーバーを構築することも可能です。MCPをサポートしているため、Runtime内にAIエージェントとMCPサーバーをそれぞれデプロイして連携させることができます。
更にエージェント同士が連携するためのA2A(Agent-to-Agent)もサポートしているため、複数のエージェントをRuntimeにデプロイし、それぞれを連携させるマルチエージェント構成をRuntime内に構築/管理することができます。
AgentCoreのその他のモジュール
Runtime以外にも、エージェント開発・運用に必要な機能が独立したモジュールとして提供されています。
出典：Amazon Bedrock AgentCore、東京を含むAWSリージョンで一般提供開始：AIエージェントを現実の世界へ
例えば「AgentCore Memory」ではAIエージェントがユーザーとのやりとりを記録しておくメモリ機能を提供しています。Memoryはマネージサービスとなっているため、データベースの管理を気にせず、簡単にAIエージェントからユーザーとの会話履歴にアクセスし、パーソナライズしたやりとりを実現できます。
MCP対応していない既存のAPIやLambda関数をAIエージェントから呼び出せるようにアクセスを中継する「AgentCore Gateway」や、AIエージェントの認証認可を管理するための「AgentCore Identity」など、大規模にAIエージェントを展開するうえで必要なモジュールが用意されています。
Bedrock Agentsを使ってできること
Bedrock Agentsは、AIエージェントそのものをマネージドで提供する機能です。AgentCore Runtimeと対比させて表現すると、AIエージェントをノーコードで実装できます。
Bedrock AgentsでAIエージェントを実装する場合は、マネジメントコンソールから利用するLLMとシステムプロンプト、Bedrock Agentsが利用する「Action Group」(≒ツール)を指定するだけです。エージェントの推論処理・実行環境、メモリ管理などはサービス側が自動で行います。
Bedrock Agentsの特徴
AgentCoreと比較して、以下の点が大きく違います。
-
ノーコードでAIエージェントを構築:
AIエージェントの処理を実装する必要はなく、マネジメントコンソールからの操作だけでAIエージェントが実装できます。
AIエージェントの実装が隠蔽されているため、実装済みのAIエージェントを移植したり、フレームワークを使い分けたりするような柔軟な利用には向いていません。
-
Bedrockで提供されるモデルを利用:
Bedrock Agentsで利用できるモデルは、現在Bedrock上で提供されているモデルに限られます。この点も、Bedrock外のモデルを利用できるAgentCoreと大きな違いになります。
-
Lambda関数をActionGroup（≒ツール）として利用:
Bedrock AgentsではAIエージェントに対してActionGroup（Bedrock Agentsにおけるツール）を登録します。このActionGroupには、基本的にLambda関数を指定できます。
MCPサーバーを直接利用することはできないため、この点もAIエージェントの実装にあたって注意が必要です。
AgentCoreとBedrock Agents
AgentCoreと比較するとBedrock Agentsは簡単にAIエージェントを動かせますが、AWSによって管理される範囲が広いため、AgentCoreよりも自由度は低くなります。
2025年に登場したばかりのAgentCoreに比べて、2023年7月に登場したBedrock AgentsではAIエージェントの設計思想が異なる可能性がある点も考慮すべきでしょう。例えば、Bedrock Agentsでは標準機能としてはMCPサーバーにアクセスできませんが、これはBedrock AgentsがMCP（2024年に登場）よりも先に登場したためと考えられます。
まとめ：AgentCoreとBedrock Agentsの違い
AgentCoreとBedrock AgentsにはAIエージェントに関連するサービスというくくりは同じですが、できることには大きな違いがあります。まず簡単にAIエージェントを動かしてみたいならBedrock Agents、AIエージェントを本格的に実装したいならAgentCoreを利用する、という使い分けがいいかと思います。
| 項目 | Amazon Bedrock Agents | Amazon Bedrock AgentCore (Runtime) |
|---|---|---|
| 概要 | マネージドサービス | エージェント実行プラットフォーム |
| 開発スタイル | ノーコードでエージェントを実装可能 （マネコン操作のみで完結） |
エージェントの実装にはコーディングが必要 |
| LLM | Bedrock提供モデルのみ | 制限なし （OpenAI, Gemini等も利用可） |
| ツール | Lambda関数が主 | MCP対応ツール、他エージェントを呼び出し可能 (Gatewayを併用すればMCP非対応ツールも呼び出し可能) |