はじめに

この度 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つの柱を軸に考慮すべき点を整理します。

出典：AWS Well-Architected Framework

① セキュリティ（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公式

参考記事

Bedrock Agents vs AgentCore 比較（Qiita）

最後まで読んでいただきありがとうございました！
「いいね」や「ストック」をいただけると励みになります 🙌