はじめに
この度 Amazon Bedrock と AgentCore をよく使う機会があり、企業AI基盤構築の全体像を整理したくなったのがこの記事のきっかけです。
全体像のイメージをつかむことを優先した内容なので、同じように企業へのAI導入を検討されている方の参考になれば幸いです。
この記事で分かること
- Amazon Bedrock Agents と AgentCore って何が違うの？
- 企業でAIを導入するとき、どんな順番で進めるの？
- 外部システムと安全につなぐには何を考えればいい？
1. 全体像 — Amazon Bedrock の機能
Amazon Bedrockは、AWS日本語公式サイト で 5つの機能 として整理されています。階層構造ではなく、目的別の横並びです。
【図1：全体図】
出典：aws.amazon.com/jp/bedrock（2026年3月確認）
| 機能名 | 内容 | 主なサービス・ツール | 企業での使い道の例 |
|---|---|---|---|
| モデルの選択 | 数百のモデルにアクセス。評価ツールで最適なモデルを選択 | Claude / Llama / Nova / OpenAI / Mistral ほか | 用途・コスト・精度のバランスで使い分け。例：高精度な分析にはClaude、大量バッチ処理にはコストの低いモデル |
| データを利用してカスタマイズ | 自社データを使ってモデルを業務特化させる | Knowledge Bases（RAG）/ Fine-tuning / Prompt engineering / Bedrock Data Automation | 社内規程・製品マニュアルをRAGで参照。Fine-tuningで業界特有の用語・表記に対応 |
| 安全とガードレール | 有害な出力や情報漏洩をブロックし、コンプライアンスに対応 | Guardrails（有害コンテンツ・PII・ハルシネーション対策） | 顧客向けチャットボットで個人情報の漏洩を防止。金融・医療など規制業種のコンプライアンス要件を満たす |
| コストの最適化 | 精度を落とさずにAIの利用コストを削減 | Prompt caching / Model Distillation（最大75%削減）/ Intelligent Prompt Routing（最大30%削減） | 同じ前提条件を何度も送るシステムはキャッシュで削減。用途によって軽量モデルへ自動振り分け |
| オーケストレーション | エージェントの構築・実験から本番運用までをカバー | Bedrock Agents（GUI設定）/ Bedrock Flows（ビジュアルビルダー）/ AgentCore（本番基盤） | 問い合わせ対応・承認フロー・データ収集など複数ステップの業務を自動化。PoCはAgentsで素早く、本番はAgentCoreへ移行 |
📌 Guardrailsについて
全体に自動でかかる「共通の層」ではなく、必要な箇所に個別で組み合わせて使うオプション機能です。
📌 AgentCoreについて
日本語版公式では「オーケストレーション」とは独立したセクションで紹介されています。Bedrockのモデルだけでなく OpenAI・Gemini など外部モデルや、LangGraph・CrewAI など任意のフレームワークにも対応しており、Bedrockに閉じたサービスではありません。
2. Bedrock Agents と AgentCore — 何が違うの？
5つの機能のうち オーケストレーション に、エージェントを構築・運用する選択肢が2つあります。さらにAgentCoreが本番稼働ための基盤として独立して提供されています。
Bedrock Agents ＝「素早く試す」ためのサービス
GUIのコンソール画面で設定するだけで、AIエージェントが作れます。
コードをほぼ書かなくていいので、エンジニア以外でも扱いやすいのが特徴です。
できること：
- 社内マニュアルや規程をAIに読ませてQ&A対応（RAG）
- 問い合わせを受けたら自動的に社内システムへ登録
- 複数ステップのタスクを自動でこなす
向いている場面：数週間でPoC（試作品）を作って上司に見せたい、まずAIで何ができるか試したい、という場合。
AgentCore ＝「本番で使い続ける」ための基盤
2025年7月に発表され、同年10月に正式公開された新サービスです。
PoC で作ったエージェントを、数百人・数千人が使う本番環境に持っていくための仕組みを丸ごと提供します。
【図2：AgentCoreのコンポーネント図】
出典：Amazon BedrockCore Overview（2026年3月確認）
AgentCoreは以下のサービスと機能で構成されています：
| コンポーネント | 一言で言うと | 機能・特徴 | 具体例 |
|---|---|---|---|
| Runtime | 実行エンジン | サーバーレスで自動スケール。セッション完全分離。最大8時間の長時間実行をサポート。双方向ストリーミングで音声エージェントにも対応 | アクセスが急増しても自動でスケールアウト。複数テナントのセッションが互いに干渉しない |
| Gateway | 外部連携の窓口 | 既存REST API・LambdaをMCP互換ツールに自動変換。統一されたMCPインターフェイスでツール発見・呼び出しを一元管理。IAM・OAuth 2.1・APIキーの複数認証方式に対応 | APIドキュメント（OpenAPI仕様）を登録するだけでエージェント用ツールが自動生成される |
| Memory | 記憶管理 | 短期（会話の文脈）と長期（ユーザーの好み・知識）の2層構成。長期記憶にはエピソード戦略（過去の経験から学習・適応）が追加。セマンティック検索で関連記憶を取得 | 「先月も同じ問題でしたね。前回の解決策を試してみましょう」と自動的に応答できる |
| Identity | 認証・認可の管理 | インバウンド認証（呼び出し元の検証：IAM SigV4・OAuth 2.0）とアウトバウンド認証（外部サービスへの代理アクセス）の両方を管理。OAuthトークンを安全なボールトに保管。Cognito・Okta・Microsoft Entra IDと統合可能 | エージェントがSlackに投稿する際「誰の代理で・どの権限で」アクセスするかを制御。APIキーをコードに書かずに安全に保管 |
| Observability | 監視・デバッグ | トークン使用量・レイテンシ・エラー率などのメトリクスはCloudWatchにデフォルトで自動出力。スパン・トレースの詳細取得には別途コードの計装が必要。OpenTelemetry（ADOT SDK）対応。ログの出力先はCloudWatch Logs・S3・Firehoseから選択可能 | 本番稼働中の異常をCloudWatchアラームで検知。詳細なデバッグには実行ステップのトレースを遡る |
| Policy | 行動ルールの強制執行 | Gatewayと統合し、ツール呼び出しをAIの推論外でリアルタイムに検査・制御。自然言語でポリシーを書くとAWS製OSSのCedar言語に自動変換。2026年3月3日GA。※現時点でIAM認証・認証なしのGatewayでは未対応（対応予定） | 「払い戻し処理は金額2万円未満のみ許可」などのルールをコードなしで定義。AIがどう推論してもGatewayで強制的にブロック |
| Evaluations | 品質評価 （プレビュー） | 13種類の組み込みエバリュエーター（正確性・有用性・ツール選択精度・安全性・目標達成率など）で本番トラフィックを継続的にサンプリング評価。カスタム評価ツールも作成可能。結果はCloudWatch（AgentCore Observability）で確認 | 本番トラフィックの一部を自動採点し、品質劣化を早期検知。リリース前の動作検証にも活用できる |
| Code Interpreter | コード実行 | 隔離されたサンドボックス環境でコードを安全に実行。複数言語に対応。データ分析・グラフ生成・計算処理に利用可能 | 「売上データをグラフにして」という指示をそのまま実行できる |
| Browser Tool | ブラウザ操作 | Firecracker microVMで完全隔離されたマネージドブラウザ環境。ローカルへのブラウザインストール不要。Webサイトのナビゲーション・マルチステップフォーム入力・複雑なWebタスクに対応 | APIを持たないWebシステムへのフォーム入力・情報収集を自動化。各セッションは独立したVM上で動作するため安全 |
どっちを使えばいい？ 判断の目安
結論：最初はBedrock Agents、育ってきたらAgentCoreへ移行する流れが王道です。
AgentCoreのCLIには import-agent コマンドがあり、既存のBedrock AgentsをAgentCoreに移行する機能も用意されています。
3. 企業でのAI導入 — 4つのフェーズ
【図3：導入フェーズ図】
Phase 1：探索（2〜4週間）
まず「自社でAIは何に使えるか」を探ります。
Bedrockのコンソール画面でいろんなモデルを試し、社内の課題に合うユースケースを探す段階です。
この段階でよくあるテーマ：
- 問い合わせ対応の自動化
- 社内文書の検索・要約
- 会議の議事録生成
Phase 2：PoC構築（1〜2ヶ月）
特定のユースケースに絞って、動くものを作って見せるフェーズです。
Bedrock Agentsを使ってGUIで素早く構築し、ステークホルダーに「こんなことができます」とデモします。
よくある構成：
- 社内FAQ → Knowledge Bases（RAGで文書検索）
- チケット登録 → Action Group（社内APIを呼び出す）
Phase 3：パイロット展開（2〜3ヶ月）
PoCで動作確認が取れたら、このタイミングでAgentCoreへ移行します。
限定的なユーザーに実際に使ってもらいながら、実際の業務の中でフィードバックを集めます。
AgentCoreに切り替えるメリットがここで出てきます：
- 外部システム（Salesforce・Slack等）との連携をGatewayで一元管理
- Identity でアクセス制御を整備し、セキュリティ要件に対応
- Observability でエラーや利用状況を監視しながら改善を続ける
Phase 4：本番展開・拡張（継続的に）
社内全体・社外のユーザーへ展開する段階です。
パイロットで整備した基盤をそのまま拡張していきます。
- 利用者が増えても自動でスケール（Runtime）
- エージェントの動きをCloudWatchで監視（Observability）※スパン・トレースの詳細は別途計装が必要
- Policy で業務ルールをコードなしに定義・強制執行
- Evaluations で本番品質を継続的にスコアリング
4. 企業AI基盤構築の考慮点
AgentCoreを使って企業AI基盤を構築する際、AWS Well-Architected Frameworkの6つの柱を軸に考慮すべき点を整理します。
① セキュリティ（Security）
AIエージェント固有の脅威を前提に設計する
| 観点 | AgentCoreでの対応 |
|---|---|
| エージェントIDの管理 | Identity でインバウンド・アウトバウンド認証を一元管理。OAuthトークンをコードに書かずSecrets Managerやトークンボールトで保管 |
| 最小権限の原則 | Lambda実行ロールは bedrock-agentcore:InvokeAgentRuntime など必要最小限に限定。IAMポリシーを細粒度で設計 |
| ポリシーの強制執行 | Policy エンジンでGatewayのツール呼び出しをAIの推論外でリアルタイム制御。AIがどう推論してもGatewayでブロック |
| 通信の暗号化 | 全通信はHTTPS（TLS 1.2以上）。本番環境はVPC + PrivateLinkで閉域網構成 |
| CORS・アクセス制限 | ワイルドカード（*）禁止。信頼できるドメインのみ許可 |
② 信頼性（Reliability）
エージェントが止まらない・壊れない設計
| 観点 | 対応 |
|---|---|
| 自動スケーリング | Runtime はサーバーレスで自動スケール。最大8時間の長時間実行に対応 |
| セッション分離 | マルチテナント環境でのセッション完全分離により、テナント間のデータ混在を防止 |
| 障害時の回復 | エラーレートをCloudWatchで監視。アラームを設定して異常を早期検知 |
| 長期記憶の耐久性 | Memory の長期記憶はAWSマネージドで永続化。セッション跨ぎのコンテキスト保持 |
③ パフォーマンス効率（Performance Efficiency）
ユーザー体験とコストのバランスを保つ
| 観点 | 対応 |
|---|---|
| モデル選択の最適化 | 高精度が必要な判断にはClaude、定型処理には軽量モデルと使い分け（Intelligent Prompt Routing活用） |
| プロンプトキャッシュ | 繰り返し送る前提条件はPrompt cachingで削減。最大75%のコスト削減 |
| ツール過負荷対策 | Gateway のセマンティック検索で動的にツールを絞り込み。不要なツール呼び出しによるレイテンシを削減 |
| 非同期処理 | 長時間タスクは Runtime の非同期実行で対応。ユーザーをブロックしない設計 |
④ コスト最適化（Cost Optimization）
使った分だけ払う設計で無駄を排除
| 観点 | 対応 |
|---|---|
| 消費ベース課金 | AgentCoreは前払い不要の従量課金。RuntimeはvCPU時間・メモリGB時間に応じた課金。I/O待機時間（LLM応答待ち等）はCPU課金対象外 |
| トークン使用量の監視 | Observability でトークン使用量をCloudWatchに自動出力。コスト異常をアラームで検知 |
| Policy課金の設計 | Policyはツール呼び出しごとに承認リクエストが発生。設計段階でツール粒度を適切に設定 |
| モデル蒸留 | Model Distillationで最大75%コスト削減・500%高速化。精度への影響は最小限 |
⑤ オペレーショナルエクセレンス（Operational Excellence）
継続的に改善できる運用体制を整える
| 観点 | 対応 |
|---|---|
| 可観測性の確保 | Observability でSessions・Traces・Spans・Errors・Latencyを収集。※スパン・トレースは別途コード計装が必要 |
| 品質の継続評価 | Evaluations（プレビュー）で本番トラフィックを自動採点。正確性・有用性・安全性など13種の指標 |
| 監査証跡 | CloudTrail で管理操作の履歴を記録。Identity のアクセスログと組み合わせてエージェントの行動を監査 |
| IaC管理 | CloudFormation対応（2025年10月GA）。インフラをコードで管理・再現可能に |
⑥ 持続可能性（Sustainability）
環境負荷を意識したAI基盤を設計する
| 観点 | 対応 |
|---|---|
| サーバーレス活用 | Runtimeはサーバーレス。アイドル時にリソースを占有しない設計 |
| 不要処理の削減 | Prompt cachingで同一プロンプトの再計算を削減。Gatewayのツール検索で不要な呼び出しを抑制 |
| 適切なモデル選択 | タスクに過剰なモデルを使わない。軽量モデルで解ける処理は軽量モデルへ（エネルギー消費を最小化） |
考慮点のまとめ
Well-Architected Frameworkの6柱をAgentCoreの機能と照らし合わせると、多くの考慮点がAgentCoreのマネージドサービスによってカバーされていることがわかります。ただし以下の点は開発者側で明示的に設計・実装が必要です。
- Policyエンジンへのポリシー定義（Cedar言語 or 自然言語）
- Observabilityのスパン・トレースを取得するためのコード計装（ADOT SDK）
- IAMロールの最小権限設計
- 認証情報のSecrets Manager管理
- CloudWatchアラームの設定とEvaluationsの評価基準定義
5. 外部システム連携の考慮点
企業AIを実用的にするには「社内外のさまざまなシステムとつなぐ」ことが必要です。
ただし、つなぐ際にはセキュリティ・スケーラビリティ・運用性の3つを同時に考える必要があります。
4層のアーキテクチャで考える
【図4：外部システム連携アーキテクチャ図】
①アクセス層 — 誰がどこからアクセスするか
スマホ・Web・社内ツール・外部パートナーなど、様々な入り口があります。
すべての通信はHTTPS（暗号化）で行い、平文通信はしません。
②認証・制御層 — 正しい相手だけ通す
Amazon API Gateway・Cognito・IAM・WAFが役割分担しています。
| AWSサービス | 役割 |
|---|---|
| Amazon API Gateway | 受付係。HTTPエンドポイントの管理・スロットリング・APIキー管理。クライアントからの入口を一元管理 |
| Amazon Cognito | 認証基盤。ユーザーアカウント管理・JWT発行・Okta / Microsoft Entra IDなど外部IdPとの統合 |
| AWS IAM | アクセス権限管理。Lambda実行ロール等に必要最小限の権限のみ付与（最小権限の原則） |
| AWS WAF | 警備員（オプション）。SQLインジェクション・XSS・DDoSなどの攻撃パターンを自動検出・ブロック |
📌 2つの「Gateway」の違いに注意
- Amazon API Gateway：クライアント→AgentCoreへの入口。HTTPエンドポイントの公開・認証・スロットリングを担う
- AgentCore Gateway：AgentCore→外部ツールへの出口。REST APIやLambdaをMCPツールに変換してエージェントが使えるようにする
名前が似ていますが、役割・位置ともに全く異なります。
③AIコア層 — AgentCoreが仕事をする
セキュリティを通過したリクエストがAgentCoreに届きます。
GatewayがAPIやLambdaをMCPツールに変換して外部ツールへの接続を仲介し、MemoryやIdentityが記憶・認証を管理します。
Gatewayの特徴的な機能：既存のREST APIをOpenAPI仕様を登録するだけでエージェント用ツールに自動変換します。
開発者が「MCPサーバーを作る」「APIをエージェント用に書き直す」といった手間をかけずに済みます。
ツール過負荷問題への対応：ツールが100個・1000個と増えると、AIが「どのツールを使えばいいか」迷って誤動作します（ツール過負荷）。
Gateway のセマンティック検索機能（x_amz_bedrock_agentcore_search）で動的にツールを検索・選択でき、これを防ぎます。
④外部システム層 — 実際につなぐ先
よく連携されるシステム：
| カテゴリ | 代表例 | 接続方式 |
|---|---|---|
| 社内システム | 社内REST API / ERP / MES | OpenAPI仕様を登録してGatewayでMCPツール化。既存APIをそのまま活用できる |
| AWSサービス | AWS Lambda / Amazon S3 / Knowledge Bases | LambdaはGatewayのターゲットとして登録。S3・Knowledge BasesはエージェントコードからAPI直接呼び出し |
| SaaS | Salesforce / Jira / Asana / Zendesk / Slack | Gateway Integration Target（事前設定済みコネクター）で統合。Slackは別途API Gateway + Lambda構成が必要なケースあり |
セキュリティで特に気をつけるポイント
認証情報は絶対にコードに書かない
SalesforceのパスワードやAPIキーをソースコードに直書きするのは厳禁です。
AWS Secrets Manager に暗号化して保管し、実行時に取得する設計にします。
エージェントのIDを管理する（AgentCore Identity）
従来のIAMは「人間」や「システム」向けに設計されていましたが、AIエージェントは「ユーザーの代わりに動くAI」という特殊な存在です。
AgentCore Identityはこの「非人間のID」を専門的に管理する仕組みです。
- Salesforceにアクセスするとき「誰の代理か」を明示できる
- OAuthトークンを暗号化して安全に保管
- どのエージェントがいつ何にアクセスしたか監査証跡が残る
ポリシーはAIの「外側」で確定的に実行する
Policyエンジンは自然言語またはCedar言語でポリシーを定義し、Gatewayのすべてのツール呼び出しをインターセプトして評価します。
たとえば「払い戻し処理ができるのは、専用ロールを持つ担当者が承認した場合のみ、かつ金額は2万円未満に限定」といったルールを定義できます。
ポイントは「AIの推論の外側で確定的に実行される」こと。
AIがどんなに巧みな推論でルールを迂回しようとしても、Gatewayが物理的にブロックします。
これにより「AIが暴走する」リスクを根本から防ぎます。
まとめ
Amazon BedrockとAgentCoreが企業AI基盤において果たす役割をまとめます。
「AIを試す」から「AIで事業を動かす」へ
オーケストレーション機能 AgentCore（独立サービス）
───────────────────────────── ────────────────────────────
Bedrock Agents ・フレームワーク自由選択
・GUI設定で素早く構築 ・パイロット〜本番・大規模向き
・PoC・プロトタイプ向き ・Runtime / Gateway / Memory
・Identity / Observability
Bedrock Flows ・Policy / Evaluations
・ビジュアルビルダーで
ワークフロー構築
│
└──→ PoCが通ったらPhase 3（パイロット）から AgentCore へ移行
企業でのAI導入は「一気に全部やる」必要はありません。
まずBedrockのオーケストレーション機能でPoC → 手応えを掴んだらAgentCoreで本番展開、という段階的なアプローチが現実的でおすすめです。
参考リンク
AWS Well-Architected Framework
AWS公式
- Amazon Bedrock 製品ページ（日本語）（5つの機能名の出典）
- Amazon Bedrock 開発者ガイド
- Amazon Bedrock AgentCore 公式ページ
- AgentCore GA発表ブログ（日本語）
- AgentCore Gateway 紹介ブログ
- AgentCore Identity 紹介ブログ
参考記事
最後まで読んでいただきありがとうございました！
「いいね」や「ストック」をいただけると励みになります 🙌