Bedrock エージェント VS Bedrock AgentCore：比較ガイド

Bedrock エージェント VS Bedrock AgentCore：比較ガイド

目次

• 導入
• 概要
  • Bedrock エージェントとは
  • Bedrock AgentCore とは
    • AWS 最適化フレームワーク：Strands SDK
• 詳細比較
  • アーキテクチャ比較
  • 機能比較
  • 実装の複雑さ比較
  • コスト比較
  • パフォーマンス特性比較
  • 制約事項
• ユースケース別推奨
  • 1. 迅速なプロトタイピング
  • 2. エンタープライズ向けカスタムエージェント
  • 3. マルチテナント SaaS
  • 4. 既存システムへの統合
  • 5. 高度なワークフロー制御が必要な場合
• 結論・推奨事項
  • 選択基準のフローチャート
  • 今後の展望

導入

AWS Bedrock でエージェントを構築する際、「Bedrock エージェント」と「Bedrock AgentCore」のどちらを選ぶべきか、迷っていませんか？

両者は同じ AWS Bedrock プラットフォーム上で動作しますが、アーキテクチャや実装方法が大きく異なります。適切な選択をすることで、開発効率やコスト、保守性を高めることが可能です。

「AgentCoreがもてはやされているけど、べつにAgentCore一択じゃなくてBedrockエージェントも採用の余地は十分あるよな～」と思ったのが本記事執筆の動機ですが、それを契機として、AWS Bedrock でエージェントシステムを構築しようとしている開発者やアーキテクトの方を対象に、両技術の違いを多角的に比較してみました。アーキテクチャの違い、機能比較、コスト構造、実装の複雑さ、そして具体的なユースケース別の推奨事項まで、実践的な観点から解説します。

※2026/04/24 追記：現時点ではプレビューかつ国内リージョン未対応（米国西部 (オレゴン)、米国東部 (バージニア北部)、アジア太平洋 (シドニー)、 ヨーロッパ (フランクフルト)）ですが、AgentCoreにハーネス機能が追加されました。正式に一般提供が開始された後は、後述の内容でBedrock エージェント 推奨の書き方をしている箇所でも、ハーネス機能を活用する方が推奨されるケースは増えそうです。 Get to your first working agent in minutes: Announcing new features in Amazon Bedrock AgentCore | Artificial Intelligence

概要

Bedrock エージェントとは

Bedrock エージェント（Amazon Bedrock Agents）は、AWS が提供するフルマネージド型のエージェント構築サービスです。開発者はコンソール画面や Infrastructure as Code（IaC）を通じて、コードをほとんど書かずにエージェントを構築することが可能です。AWS がインフラストラクチャ、オーケストレーション、セッション管理などを自動的に処理するため、開発者はビジネスロジックに集中できます。

主要な特徴は以下の通りです。

• マネージドサービス: AWS がエージェントの実行環境やスケーリングを自動管理
• GUI ベースの設定: プロンプトテンプレート、ナレッジベース、アクショングループを視覚的に構成
• AWS サービス統合: Amazon S3、Lambda、API Gateway などとネイティブに連携し、迅速な開発が可能
• ガードレール機能: 安全性とコンプライアンスを確保する仕組みを組み込み
• ローコードアプローチ: 複雑なコーディングなしでエージェントを構築可能

Bedrock AgentCore とは

Amazon Bedrock AgentCore は、次世代の AI エージェントを構築・運用するための「エージェント・プラットフォーム基盤」です。従来の Bedrock エージェントが「完成されたエージェント機能」を提供するのに対し、AgentCore は開発者が自由なフレームワーク（Strands、LangGraph、CrewAI、AutoGen 等）で書いたエージェントを、安全かつスケーラブルに動かすための「コア・インフラ」を提供します。

主要な特徴は以下の通りです。

• MCP（Model Context Protocol）対応: 社内外の膨大なツール群を統一された規格で即座に連携
• AgentCore Runtime: セッション管理や実行環境をサーバーレスに提供し、開発者はインフラの複雑さを意識せずエージェントロジックに専念可能
• Identity & Gateway: 認証・認可機能が組み込まれており、企業が求める厳格なガバナンスとツール利用権限の管理を実現
• フレームワーク自由度: Strands、LangGraph、CrewAI など、好みのフレームワークを選択可能
• エンタープライズ対応: セキュリティ、スケーラビリティ、ガバナンスを重視した設計

AWS 最適化フレームワーク：Strands SDK

AgentCore はあくまで「実行基盤」なので、エージェントのロジック自体は開発者が実装します。ここで選択肢に上がるフレームワークが、AWS 発のオープンソース SDK「Strands」です。

Strands の特徴は以下の通りです。

• コード・ファースト: エージェントの動作を Python のクラスや関数として明示的に記述可能
• AWS ネイティブ統合: Bedrock の最新機能や AgentCore のセッション管理機能を、SDK のメソッドとしてネイティブに呼び出し可能
• パフォーマンス最適化: AWS 環境に特化した設計により、高いパフォーマンスを実現

汎用性を求めるなら LangGraph、AWS 環境への最適化を重視するなら Strands というように、プロジェクトの要件に応じて最適なフレームワークを選択できます。

詳細比較

アーキテクチャ比較

両技術のアーキテクチャには根本的な違いがあります。以下の表で主要な観点を比較します。

観点	Bedrock エージェント	Bedrock AgentCore
抽象度	高（マネージド）	中（プラットフォーム基盤）
設定方法	GUI + IaC（CloudFormation等）	コードベース（Python/SDK）
カスタマイズ性	制限あり（定義された範囲内）	高（フレームワーク選択可能）
インフラ管理	AWS管理	AgentCore が基盤提供、ロジックは開発者実装
オーケストレーション	事前定義パターン（ある程度カスタム可）	自由記述（Strands、LangGraph等）
ツール連携	Lambda、ナレッジベース等	MCP（Model Context Protocol）含め自由に連携可
セッション管理	自動管理	AgentCore Runtime が提供（microVM ベースの完全分離）
認証・認可	IAM ベース	Identity & Gateway 機能（ツールレベルの詳細制御）

機能比較

両技術が提供する主要機能を表形式で比較します。

機能	Bedrock エージェント	Bedrock AgentCore
ナレッジベース統合	Amazon S3 + Vector DB（OpenSearch Serverless等）を GUIまたはIaC で設定。RAG パターンが自動実装され、ドキュメント管理が一貫して行われる（別途Lambda経由で任意のデータソース接続は可能）	MCP を通じて任意のデータソースに接続可能。カスタム検索ロジックや複数データソースの統合を実装可能（例：社内 Wiki + Confluence + Notion の統合）
アクションツール連携	Lambda 関数や API Gateway をツールとして定義し、自動選択・実行	MCP Server として実装されたツール群を統一的に扱える。AgentCore Gateway が既存 REST API を動的に MCP 対応ツールへ変換可能（既存資産の即座な活用）、MCPに限らずコードで書ける処理は組み込み可
メモリ管理	セッション内の会話履歴を自動管理。長期記憶には追加実装が必要	AgentCore Runtime が長期・短期記憶に加え、エピソード記憶（Episodic Memory）をサポート（2025年12月〜）。過去の成功・失敗事例から自律学習し、使うほど賢くなる特性を実現。メモリ戦略を柔軟にカスタマイズ可能
セッション管理	セッション ID 指定で自動管理。マルチターン会話を簡単に実装可能（1分～90分）	AgentCore Runtime が提供。最大 8時間の長時間実行に対応し、複雑なワークフローや人間の承認待ちを含むプロセスを実現可能。セッションのライフサイクルやデータ構造を詳細に制御可能
ガードレール機能	Amazon Bedrock Guardrails を GUI で設定。有害コンテンツフィルタリング、PII 検出・マスキング、トピック制限が可能	Identity & Gateway 機能でツールレベルの認可制御が可能。ガードレール統合は開発者が実装。エピソード記憶による自律性が高まるため、行動のステアリング（制御）設計が重要
プロンプト制御	プロンプトテンプレートを GUI で編集可能。推論フローは事前定義されたパターンに従う	Strands や LangGraph でプロンプト構造と推論フローを設計可能。複雑な思考チェーンや条件分岐を実装可能
リアルタイム対話	レスポンスのストリーミングは可能	双方向ストリーミング対応（2025年12月〜）。音声エージェントでの割り込みやリアルタイムフィードバックが可能

実装の複雑さ比較

開発効率と学習コストの観点から、両技術の実装の複雑さを比較します。

観点	Bedrock エージェント	Bedrock AgentCore
初期セットアップ時間（※）	30分〜、GUIで設定するだけで動作	数時間〜1日（デモレベルであればBedrock AgentCore Starter ToolkitでBedrock エージェント同等かそれ以上の高速セットアップは可能。フレームワーク選択、エージェントロジック実装、MCP Server 設定を詰めていくと時間はかかる）
学習曲線	緩やか（AWS コンソール操作、または基本的な IaC 知識で開始可能。プログラミング経験が少なくても扱える）	中〜急勾配（Python プログラミング、フレームワーク（Strands/LangGraph等）、MCP プロトコル、エージェント設計パターンの理解が必要。ただし Strands SDK もよりシンプルな記述で済むよう改善が進んでおり、敷居は低くなってきている
保守性	運用面では高い（AWS 管理）が、カスタマイズや詳細なデバッグが必要な場合は制限あり。Lambdaのランタイムアップデート等も考慮は必要	コードベースのため変更管理は容易だが、フレームワークのアップデート対応やカスタムロジックの保守が必要。エピソード記憶による自律学習で、行動の予見可能性を保つステアリング設計が新たな課題
デバッグの容易さ	中程度（CloudWatch Logs でトレース確認可能だが、内部の推論プロセスは限定的）	高い（コードレベルでデバッグ可能。推論フローの各ステップを詳細に追跡でき、ローカル環境でのテストも容易）
チーム体制	1〜2名で構築・運用可能（私自身プロトタイピング用途では優先的に利用しています）	1名でも可能だが、プログラミング（Python/TypeScript等）、インフラ、エージェント設計の幅広いスキルが必要。複数名での分担で効率化しやすい
プロトタイピング速度	非常に速い（アイデアから動作するプロトタイプまで数時間で実現可能）	中程度（設計と実装に時間がかかるが、Strands SDK の進化により開発速度は向上。初期から本番品質のアーキテクチャを構築可能）

※開発者のスキルセットや、整備済み開発環境の有無等により大きく前後します

コスト比較

コスト項目	Bedrock エージェント	Bedrock AgentCore
基本料金構造	従量課金制（エージェント呼び出し回数、入出力トークン数、ナレッジベース検索回数に応じて課金）	従量課金制（AgentCore Runtime の実行時間、入出力トークン数、MCP Server の実行コストに応じて課金。重要: LLM 回答待ちや外部 API 待機中のアイドル時間は課金対象外）
モデル利用料	Bedrock モデルの標準料金（入力・出力トークンごと）。Claude 4.5 Sonnet の場合、入力 $3/1M トークン、出力 $15/1M トークン。Amazon Nova 2 Pro は入力 $0.8/1M トークン、出力 $3.2/1M トークンとコスト効率に優れる（2026年2月時点）	同じく Bedrock モデルの標準料金（料金体系は Bedrock エージェントと同一）
インフラコスト	ナレッジベース用の Vector DB（OpenSearch Serverless 等）、Lambda 実行コストが追加	AgentCore Runtime の実行コスト、カスタム MCP Server のホスティングコスト（Lambda、ECS、Fargate 等）が追加
スケーリングコスト	自動スケーリングで追加コストなし（トラフィック増加に応じて従量課金が増えるのみ）	AgentCore Runtime は自動スケーリング（カスタム MCP Server のスケーリング設計とコストは開発者が管理）
運用コスト	低い（マネージドサービス）	中程度（カスタムロジックやMCP Server の監視、メンテナンス、アップデート対応が必要）
隠れたコスト	ナレッジベースのデータ転送料、CloudWatch Logs のストレージコスト等	カスタム実装の開発・保守コスト、フレームワークの学習コスト、MCP Server の運用コスト等
アイドルコスト効率	リクエスト単位課金のため、待ち時間が長いワークフローでも全体に課金	アイドル時間は課金対象外。複雑で待ち時間の長いワークフロー（人間承認待ち、外部システム処理待ち等）では、Bedrock エージェントより コスト効率が大幅に良いケースあり
コスト最適化の余地	限定的（プロンプト最適化やキャッシング戦略で削減可能だが、アーキテクチャレベルの最適化は困難）	高い（推論フローの最適化、効率的なツール呼び出し、プロンプトキャッシュ（Prompt Caching）による大幅なコスト削減、カスタムキャッシング戦略、アイドル時間の最適化等、多様な最適化手法を適用可能）

実際のコストはユースケースにより大きく変動します。トークン数、ツール呼び出し頻度、ナレッジベース検索回数などを考慮した詳細な見積もりが必要です。

パフォーマンス特性比較

両技術のパフォーマンス特性を理解することは、システム設計において重要です。

特性	Bedrock エージェント	Bedrock AgentCore
レイテンシ	中程度（初回 2〜5秒。ナレッジベース検索やツール呼び出しで増加）	低〜中程度（実装方法により変動。最適化で高速化可能だが、非効率な実装では遅延。双方向ストリーミングにより音声エージェント等でのリアルタイム応答が可能）
スループット	高い（自動スケーリングで大量の同時リクエストに対応。リージョンごとのクォータ制限内で動作）	高い（AgentCore Runtime が自動スケーリング。カスタム MCP Server がボトルネックになる可能性あり）
スケーラビリティ	非常に高い（AWS インフラを活用し、トラフィック急増に自動対応。開発者の介入不要）	高い（AgentCore Runtime はスケーラブル。カスタムコンポーネントのスケーリング設計が必要）
コールドスタート	あり（2〜5秒）	実装方法に依存（Lambda ベースでは発生、ECS/Fargate では発生しない）
セッション時間	短時間（数分〜数十分程度）	最大 8時間の長時間実行に対応。複雑なワークフロー、人間の承認待ち、外部システム処理待ちを含むプロセスを実現可能
制限事項	リージョンごとのクォータ制限（大規模利用時はクォータ引き上げ申請が必要）	AgentCore Runtime の制限に加え、カスタムコンポーネントの制限を考慮する必要あり
最適化の余地	限定的（プロンプト最適化、キャッシング、ツール呼び出し削減で改善可能）	高い（推論フロー最適化、並列処理、カスタムキャッシング、バッチ処理、アイドル時間最適化等、多様な手法を適用可能）

制約事項

両技術には、それぞれ固有の制約事項があります。プロジェクト計画時に考慮すべき重要なポイントです。

Bedrock エージェントの制約

• カスタマイズ性の制限: エージェントの推論フローは事前定義されたパターンに従う。複雑な条件分岐や独自の思考チェーンの実装は困難（ただし 2026年はマルチエージェントコラボレーション対応により一部緩和傾向）
• ツール連携の制約: Lambda 関数と API Gateway に限定。MCPにはネイティブには対応していないため、MCP連携するには工夫が必要
• プロンプト制御の制限: プロンプトテンプレートは編集できるが、推論プロセスの根本的な変更は不可
• セッション時間の制限: 長時間実行（数時間単位）のワークフローには不向き
• リアルタイム対話の制限: 双方向ストリーミング非対応のため、音声エージェント等のリアルタイム対話には制約あり
• ベンダーロックイン: AWS 固有のサービスに依存するため、他のクラウドプロバイダーへの移行が困難
• デバッグの制限: 内部の推論プロセスは限定的にしか可視化されず、詳細なデバッグが難しい場合あり

Bedrock AgentCore の制約

• 学習コストの高さ: Python プログラミング、エージェントフレームワーク、MCP プロトコル、設計パターン等、幅広い知識が必要（ただし Strands SDK の DX 向上により 2026年は緩和傾向）　※心理的ハードルを感じる方も多いかもしれません（私自身そうでした。。）
• 開発・保守コスト: カスタムロジックの実装と保守に継続的なリソースが必要。フレームワークのアップデート対応も求められる
• インフラ管理の責任: AgentCore Runtime は提供されるが、カスタム MCP Server やデータベース等は開発者が管理（サードパーティのリモートMCP中心の場合は開発者管理範囲は少なくなる）
• 初期開発時間: プロトタイプから本番環境まで、Bedrock エージェントより長い開発期間が必要（ただし agentcore launch 等のツール進化で短縮傾向）
• チーム体制の要件: 効果的に活用するには、エージェント設計者、バックエンド開発者、インフラエンジニアの協力（または総合的なスキルを持つ開発者による開発）が望ましい
• 行動の予見可能性: エピソード記憶による自律学習機能が高度化するほど、エージェントの行動が予測困難になる可能性あり。ステアリング（制御）設計が新たな課題
• 成熟度: 2025年末の大型アップデートで機能は大幅に進化したが、ベストプラクティスやコミュニティリソースは発展途上

ユースケース別推奨

実際のプロジェクトでどちらの技術を選ぶべきか、5つの代表的なユースケースで推奨を示します。

1. 迅速なプロトタイピング

シナリオ: スタートアップや新規事業で、アイデアを素早く検証したい。限られた時間とリソースで MVP（Minimum Viable Product）を構築する必要がある。

推奨技術: Bedrock エージェント

推奨理由 - 数時間で動作するプロトタイプを構築可能 - GUI ベースの設定で、コーディング量を最小限に抑制 - AWS がインフラを管理するため、運用負荷がほぼゼロ - 小規模チーム（1〜2名）でも十分に対応可能

考慮事項 - プロトタイプが成功し、本番化する際にカスタマイズ性の制限に直面する可能性あり - 初期段階から複雑な要件がある場合は、AgentCore の検討も推奨

2. エンタープライズ向けカスタムエージェント

シナリオ: 大企業で、独自のビジネスロジックや複雑なワークフローを持つエージェントシステムを構築。厳格なガバナンス、セキュリティ、監査要件がある。

推奨技術: Bedrock AgentCore

推奨理由 - Identity & Gateway 機能により、ツールレベルでの認可制御が可能。例えば、Amazon Cognito や既存の IdP と連携し、特定のユーザーグループにのみ「本番 DB への書き込みツール」の実行権限を付与するといった、きめ細かな認可制御を実現可能 - カスタムロジックで、複雑なビジネスルールや承認フローを実装可能 - MCP を通じて、既存の社内システム（ERP、CRM、データベース等）と統合可能 - 推論フローを完全に制御でき、監査ログを詳細に記録可能

考慮事項 - 開発チーム（エージェント設計者、バックエンド開発者、インフラエンジニア）の確保が必要（小規模であれば1名でも可能だが、フルスタック対応できるスキルセットが必要） - 初期開発に数週間〜数ヶ月かかる可能性あり

3. マルチテナント SaaS

シナリオ: 複数の顧客（テナント）にエージェント機能を提供する SaaS プロダクトを構築。各テナントごとに異なる設定やツールアクセス権限が必要。

推奨技術: 規模と要件により選択

標準的な要件の SaaS（Bedrock エージェント推奨） - すべてのテナントが同じツールセットとワークフローを使用する場合に適する - テナント数が数十件程度で、各テナントの差異が設定レベル（プロンプト、ナレッジベース内容）に留まる - IaC でテナントごとに個別エージェントを自動プロビジョニングし、IAM ポリシーで分離可能 - 迅速な市場投入が可能で、運用負荷が低く抑えられる（AWS がインフラを管理）

多様な要件の SaaS（Bedrock AgentCore 推奨） - テナントごとに必要なツールやワークフローが大きく異なる場合に適する（例：製造業向けには SAP 連携、不動産業向けには物件管理システム連携） - MCP を通じて、テナントごとに異なるツールセットを柔軟に提供可能 - 設定駆動でテナント固有のワークフローを動的に構築でき、コードの再利用性が高い - Identity & Gateway 機能で、テナントごとの認証・認可を細かく制御可能 - テナント数が増えても、単一のコードベースで管理できるため、運用負荷が一定に保たれる

考慮事項 - 標準的な要件で小規模から始める場合は Bedrock エージェントが適しているが、テナントごとのカスタマイズ要求が増えると限界に達する - 多様な要件や将来的な拡張を見込む場合は、初期から AgentCore で構築する方が長期的にコスト効率が良い - テナント間のデータ分離とセキュリティは、どちらの技術でも細心の注意が必要

4. 既存システムへの統合

シナリオ: 既に稼働している社内システムやアプリケーションに、エージェント機能を追加。既存の認証基盤、データベース、API との統合が必要。

推奨技術: Bedrock AgentCore

推奨理由 - MCP を通じて、既存システムのツールやデータソースを統一的に扱える - カスタムロジックで、既存の認証基盤（SAML、OAuth 等）と統合できる - 既存のワークフローやビジネスロジックをエージェントに組み込める - 段階的な移行が可能で、既存システムへの影響を最小限に抑えられる

考慮事項 - 既存システムの API や認証方式を理解する必要あり - MCP Server の開発が必要な場合あり - Bedrock エージェントでも Lambda 経由で統合可能だが、柔軟性が制限される

5. 高度なワークフロー制御が必要な場合

シナリオ: 複雑な条件分岐、並列処理、人間の承認フロー、エラーハンドリングなど、高度なワークフロー制御が必要なエージェントを構築。

推奨技術: Bedrock AgentCore（Strands または LangGraph）

推奨理由 - Strands や LangGraph で、複雑な推論フローをコードとして明示的に記述できる - 条件分岐、ループ、並列処理、サブグラフなど、高度な制御構造を実装できる - 人間の承認待ちや外部イベント待ちなど、非同期処理を組み込める - デバッグが容易で、各ステップの状態を詳細に追跡できる

考慮事項 - エージェント設計パターンとフレームワークの深い理解が必要 - 複雑なワークフローは、テストとデバッグに時間がかかる - Bedrock エージェントでは、このレベルの制御は実現困難

結論・推奨事項

選択基準のフローチャート

以下のフローチャートを参考に、プロジェクトに最適な技術を選択してください。 絶対的指針ではありませんが、以下を原則としつつ、他要因を踏まえてご判断頂ければと思います。

graph TD
    Start[エージェント構築を検討] --> Q1{迅速なプロトタイピング<br/>またはMVP検証？}
    
    Q1 -->|はい| BedrockAgent1[Bedrock エージェント]
    Q1 -->|いいえ| Q2{テナントごとに<br/>要件が大きく異なる？}
    
    Q2 -->|はい| AgentCore1[Bedrock AgentCore]
    Q2 -->|いいえ| Q3{複雑なワークフローや<br/>条件分岐が必要？}
    
    Q3 -->|はい| AgentCore2[Bedrock AgentCore]
    Q3 -->|いいえ| Q4{開発リソースは<br/>限定的？<br/>1-2名}
    
    Q4 -->|はい| BedrockAgent2[Bedrock エージェント]
    Q4 -->|いいえ| Q5{将来的に<br/>数百テナント以上に<br/>拡大予定？}
    
    Q5 -->|はい| AgentCore3[Bedrock AgentCore]
    Q5 -->|いいえ| Q6{標準的なツールセット<br/>で十分？}
    
    Q6 -->|はい| BedrockAgent3[Bedrock エージェント]
    Q6 -->|いいえ| AgentCore4[Bedrock AgentCore]
    
    style BedrockAgent1 fill:#ff9900
    style BedrockAgent2 fill:#ff9900
    style BedrockAgent3 fill:#ff9900
    style AgentCore1 fill:#0073bb
    style AgentCore2 fill:#0073bb
    style AgentCore3 fill:#0073bb
    style AgentCore4 fill:#0073bb

迷った場合は、まず Bedrock エージェントで PoC（概念実証）を実施し、市場や技術的な検証を行うことをお勧めします。 私自身、Bedrock エージェントで機能的に問題無い内容であれば、まずはサクッとBedrock エージェントで試すことがほとんどです。 要件の複雑化やスケールの必要性が明確になった段階で、Strands + AgentCore への移行を検討することで、リスクを最小限に抑えながら最適なアーキテクチャに到達可能です。（両技術は排他的ではなく、状況に応じて移行や併用が可能です）

今後の展望

AWS Bedrock のエージェント技術（というか、AI関連技術）は急速に進化しています。

技術選択においては、短期的（1年以内）には現在の特性に基づいて選択し、中長期的（1〜3年）には両技術の進化を見据えた柔軟な設計を心がけると良いと思います。最新情報を定期的にチェックしながら、プロジェクトの要件に最適な技術を選択していきましょう。

ご参考になれば幸いです！

注: 本記事の内容は 2026年2月時点の情報に基づいています。AWS のサービスは継続的にアップデートされるため、最新情報は公式ドキュメントをご確認ください。

Yushi.Sakuraba(記事一覧)

アプリ出身クラウドエンジニア（絶賛奮闘中）