Amazon Bedrock AgentCoreは、今年10月にGAされた最新のサービスです。
にも関わらず、12/16より開始されるAWS認定の新試験 AWS Certified Generative AI Developer – Professional では、AgentCoreが出題対象のサービスとして数えられています。
そこで、Amazon Bedrock AgentCore を 技術的に深く、かつ 凡人エンジニアでも理解できるよう噛み砕いた 学習ノートを作成して勉強しました。
このノートはChatGPTが作成し、人間がチェックしました
0. このノートの読み方（試験対策向け）
- 太字：試験でキーワードとして問われやすい用語
- 📘補足：概念理解のための噛み砕き説明
- 🧠試験観点：選択肢問題で狙われやすいポイント
- 🏗設計観点：アーキテクチャ設計問題での使い所
1. Amazon Bedrock AgentCore 全体像
1.1 AgentCore とは何か（ひとことで）
Amazon Bedrock AgentCore は、
「AIエージェントを 安全に・大規模に・実運用 するためのマネージド実行基盤」
です。
何が嬉しいのか？
従来のエージェント開発では：
- エージェントの実行環境（コンテナ、スケーリング）
- ユーザーごとの会話状態管理
- 外部API接続時の認証・権限制御
- ツール呼び出しのガバナンス
- ログ・監視・評価
を 自分で全部作る必要 がありました。
AgentCore はこれらを AWSがマネージドで提供 します。
📘補足：
「Lambdaが関数実行の土台を提供した」のと同じ立ち位置で、 AgentCoreは「AIエージェント実行の土台」を提供します。
🧠試験観点：
- AgentCore = モデルそのものではない
- AgentCore = エージェントの実行・運用基盤
1.2 Bedrock 内での位置づけ
Amazon Bedrock の構成要素を整理すると：
| レイヤ | サービス | 役割 |
|---|---|---|
| モデル | Claude / Nova / etc | 文章生成・推論 |
| ガード | Bedrock Guardrails | 安全制御 |
| RAG | Knowledge Bases | 検索拡張生成 |
| エージェント基盤 | AgentCore | 実行・連携・運用 |
🏗設計観点：
- AgentCoreは「モデルをどう使うか」を司る層
- モデル変更しても AgentCore 設計は流用できる
2. AgentCore Runtime（実行基盤）
2.1 Runtime の役割（Why）
AgentCore Runtime は「エージェントを“生き物”として動かすための心臓部」です。
エージェントは以下を同時に満たす必要があります。
- 会話の文脈（状態）を保持する
- ツールを呼び出す
- モデル推論を複数回行う
- ユーザーごとに安全に分離される
- 負荷に応じて自動的にスケールする
従来の Lambda / ECS では、これらを自前実装する必要がありました。 AgentCore Runtime はこれを エージェント前提で抽象化 しています。
📘補足（凡人向け）
Lambda は「1回で終わる仕事向け」 エージェントは「考えながら何度も行動する仕事向け」
2.2 セッション分離（Isolation）
なぜ重要か
エージェントは以下を扱います。
- ユーザー入力（個人情報を含む）
- 社内データ
- 外部API操作権限
これが混ざると 即インシデント です。
AgentCore の仕組み
- 各セッション = 独立したサンドボックス
- メモリ / ツール状態 / 実行コンテキストを分離
🧠試験観点
- 「マルチテナント環境での安全な実行」→ Runtime + Isolation
2.3 実行モデル（Execution Model）
Runtime 上での典型的な流れ：
- ユーザー入力を受信
- モデル推論（思考）
- ツール選択
- Gateway 経由でツール実行
- 結果を Memory に反映
- 再度モデル推論
- 応答生成
📘補足
「推論 → 行動 → 振り返り」を繰り返す
これは ReAct / Plan-Act-Reflect パターンそのものです。
2.4 スケーリング特性
- サーバレス
- 同時数千〜数万セッション
- 長時間実行（数分〜時間）対応
🧠試験観点
- ECS を自分でスケール？ → 不正解
- AgentCore Runtime → 正解
3. AgentCore Memory（記憶）
3.1 なぜ Agent に「記憶」が必要なのか（Why）
LLM 単体は ステートレス です。
- 1回の推論 = その瞬間だけ賢い
- 次の呼び出しでは「完全に忘れる」
しかし エージェント は違います。
エージェントは：
- 会話を継続する
- 過去の判断を踏まえて行動する
- ユーザーごとに振る舞いを変える
👉 つまり 状態（State）を持つ存在 です。
AgentCore Memory は、この「状態管理」を モデルから切り離して 提供します。
📘凡人向け補足
LLM = 記憶喪失の天才 Agent = 記憶を持たせた実務担当者
3.2 Memory の設計思想（重要）
AgentCore Memory の本質は、
「何をモデルに渡し、何を外に保持するか」を分離すること
です。
なぜ分離するのか？
-
プロンプトに全部詰めると
- トークン爆増
- コスト増
- ノイズ増
-
モデルに覚えさせると
- 制御不能
- 削除・更新不可
👉 Memory は“外部状態ストア”
🧠試験観点
- Memory = プロンプト工夫ではない
- Memory = アーキテクチャ要素
3.3 短期メモリ（Short-term Memory）
役割
- 直近の会話履歴
- ユーザーの直前意図
- 途中までの思考結果
技術的特徴
- セッション単位
- 揮発的
- 自動的にモデルへ注入
📘例
ユーザー：「その注文をキャンセルして」 → 「その」が何かを短期メモリが保持
🧠試験観点
- マルチターン会話 = 短期メモリ
3.4 長期メモリ（Long-term Memory）
役割
- ユーザー固有の事実
- 繰り返し参照される情報
- パーソナライズ要素
技術的特徴
- セッションをまたいで保持
- 構造化 / 半構造化
- セマンティック検索可能
📘例
・このユーザーは管理者 ・日本語回答を好む
🧠試験観点
- パーソナライズ = 長期メモリ
3.5 Memory と Knowledge Base の違い（超重要）
| 観点 | Memory | Knowledge Base |
|---|---|---|
| スコープ | ユーザー依存 | 全体共通 |
| 更新頻度 | 動的 | 比較的静的 |
| 目的 | 状態保持 | 事実検索 |
📘凡人向け理解
Memory = 人の記憶 KB = 社内Wiki
🧠試験観点
- RAG が必要 → Knowledge Base
- 会話文脈 → Memory
3.6 Memory があることで可能になる設計
- 会話継続型エージェント
- ユーザー別権限制御
- 過去行動を踏まえた判断
🏗設計観点
- Memory 無し = チャットボット止まり
- Memory 有り = エージェント
4. AgentCore Gateway（ツール連携）
4.1 Gateway の正体（結論から）
AgentCore Gateway は「ツール実行の制御プレーン」 です。
単なる API プロキシではありません。
Gateway が解決する本質的な問題は：
- エージェントに 何をさせてよいか
- どの手段で 実行させるか
- どの権限で 実行させるか
- どう監査・制御するか
を モデルの外側で強制する ことです。
📘凡人向け補足
モデルは「やる気がある新人」 Gateway は「業務ルールと決裁フロー」
4.2 なぜ LLM に直接 API を呼ばせてはいけないのか
ダメな設計（アンチパターン）
- プロンプトに API の URL / パラメータを書く
- Lambda を直接呼ばせる
何が起きるか
- 意図しない API 呼び出し
- 権限逸脱
- 再現不能な挙動
- 監査不可
🧠試験観点
- 「モデルに API を直接書かせる」選択肢 → 不正解
4.3 Gateway が提供する抽象化
Gateway は以下を 分離 します。
| 関心事 | 分離先 |
|---|---|
| 何ができるか | Tool 定義 |
| 認証 | Identity |
| 実行可否 | Policy |
| 実体 | API / Lambda |
👉 モデルは「何をしたいか」だけを考える。
4.4 MCP（Model Context Protocol）とは何か
一言で
MCP = モデルとツールの共通インターフェース
なぜ必要か
- ツールごとに I/F が違う
- モデルごとに tool calling 仕様が違う
→ 組み合わせ爆発
MCP はこれを断ち切ります。
📘凡人向け補足
USB 規格のようなもの
4.5 Gateway と MCP の関係
-
Gateway は
- API / Lambda / SaaS を
- MCP 準拠ツールに変換
-
エージェントは
- MCP とだけ会話
🧠試験観点
- MCP = 標準化
- Gateway = 実装
4.6 Tool 選択の仕組み（重要）
エージェントは：
- ユーザー要求を理解
- 利用可能なツール一覧を参照
- 意味的に最適なツールを選択
👉 Gateway は
- ツールの 意味情報（Schema） を提供
📘補足
モデルは「名前」ではなく「意味」で選ぶ
4.7 セキュリティ・ガバナンス
Gateway 単体では完結しません。
| 機能 | 担当 |
|---|---|
| 認証 | Identity |
| 実行可否 | Policy |
| 実行 | Gateway |
🏗設計観点
- Gateway は必ず Policy とセット
4.8 API Gateway / Lambda との違い
| 観点 | API Gateway | AgentCore Gateway |
|---|---|---|
| 想定利用者 | 人 / アプリ | AI エージェント |
| 権限制御 | 静的 | 動的・文脈依存 |
| 監査 | API単位 | 意図単位 |
🧠試験観点
- エージェント用途 → AgentCore Gateway
4.9 Gateway があることで可能になる設計
- ツールの差し替え
- 安全な自律行動
- 監査可能な AI
🏗設計観点
- Gateway 無し = 危険な自律AI
- Gateway 有り = 企業AI
5. AgentCore Identity（認証）
5.1 Identity の役割（結論）
AgentCore Identity は「エージェントは誰として行動するのか」を定義する仕組み です。
重要なのは：
- 人間ユーザーの認証ではない
- API の認証でもない
👉 非人間主体（Non-Human Identity） を扱うこと
5.2 なぜエージェントに Identity が必要か
問題設定
- エージェントが S3 を読む
- エージェントが DB を更新する
👉 誰の権限？
- 開発者？
- 管理者？
- エンドユーザー？
📘凡人向け補足
人が操作しないのに「誰として？」が必要
5.3 IAM だけでは足りない理由
IAM は：
- 静的
- 事前定義
- 人 or サービス前提
エージェントは：
- 動的
- 文脈依存
- ユーザー代理
👉 設計前提がズレている
🧠試験観点
- 「IAM ロールを直接付与」→ 多くの場合 NG
5.4 Non-Human Identity とは何か
定義
人間ではないが、行為主体として扱う ID
例：
- エージェント
- バッチ
- ワークフロー
AgentCore では：
- エージェントごとに Identity を定義
5.5 ユーザー代理実行（On-behalf-of）
一言で
ユーザーの権限を一時的に借りる
なぜ必要か
- ユーザー A のデータを
- ユーザー B の権限で触らせない
👉 SaaS 必須要件
📘凡人向け補足
代理印鑑
5.6 Identity と Gateway / Policy の関係
[ Agent ]
|
[ Identity ] ← 誰として
|
[ Policy ] ← 何ができるか
|
[ Gateway ] ← 実行
🏗設計観点
- Identity 単体では意味がない
5.7 セキュリティ設計のベストプラクティス
- エージェント専用 Identity
- 最小権限
- ユーザー代理は一時的
🧠試験観点
- 永続的な広権限 → 不正解
5.8 よくある誤解（試験対策）
| 誤解 | 正解 |
|---|---|
| エージェント = IAM ロール | ❌ |
| ユーザー権限を常時付与 | ❌ |
| Gateway が認証もする | ❌ |
5.9 Identity を理解した状態
あなたは今：
- なぜ AgentCore が必要か
- なぜ Bedrock Agent では足りないか
を セキュリティ視点で説明可能
6. AgentCore Policy（制御）
6.1 Policy の本質（結論）
AgentCore Policy は「エージェントの意図を評価し、実行可否を決める仕組み」 です。
重要なのは：
- API の可否判定ではない
- IAM ポリシーの代替ではない
👉 意図（Intent）レベルの制御
6.2 なぜプロンプト制御は破綻するのか
よくある失敗
- 「○○してはいけません」と書く
- ルールを長文化する
なぜダメか
- LLM は確率モデル
- 解釈が揺らぐ
📘凡人向け補足
マニュアルを守る新人ではない
🧠試験観点
- プロンプト制御のみ → 不正解
6.3 Policy が評価するもの
Policy は以下を入力に取ります。
| 要素 | 内容 |
|---|---|
| Identity | 誰として |
| Intent | 何をしたいか |
| Context | 文脈 |
| Resource | 対象 |
👉 API 前ではなく 実行前
6.4 Intent（意図）とは何か
例
- 「顧客情報を閲覧」
- 「請求データを更新」
👉 API 名ではない
📘補足
人間が説明できる単位
6.5 文脈依存ポリシー
静的制御
- 常に禁止 / 許可
動的制御
- 時間
- ユーザー
- 状態
👉 エージェント必須
6.6 Policy と IAM の役割分担
| レイヤ | 役割 |
|---|---|
| Policy | 意図 |
| IAM | 実行 |
🧠試験観点
- IAM だけで完結 → ❌
6.7 Policy と Gateway の連携
Intent
↓
Policy 判定
↓
Gateway 実行
🏗設計観点
- Policy は必ず Gateway 前
6.8 監査・説明可能性
- なぜ拒否されたか
- なぜ許可されたか
👉 説明できる AI
6.9 よくある試験トラップ
| 選択肢 | 判定 |
|---|---|
| プロンプト制御 | ❌ |
| IAM 強化 | ❌ |
| Policy 導入 | ✅ |
6.10 Policy を理解した状態
あなたは今：
- AI の暴走を止める方法
- 企業が AI を許可する条件
を 構造で説明可能
7. AgentCore 全体アーキテクチャまとめ
7.1 AgentCore の全体像（俯瞰）
AgentCore は 単一サービスではなく、制御された AI エージェントを作るための基盤群 です。
[ User / App ]
↓
[ Agent Runtime ] ← 推論・意思決定
↓
[ Memory ] ← 文脈の保持
↓
[ Policy ] ← 意図の評価
↓
[ Identity ] ← 行為主体
↓
[ Gateway ] ← 実行制御
↓
[ AWS Services / SaaS ]
👉 LLM を信頼せず、周辺で囲う設計
7.2 各コンポーネントの役割（試験即答用）
| コンポーネント | 一言で | 試験でのキーワード |
|---|---|---|
| Runtime | 考える | 推論 / オーケストレーション |
| Memory | 覚える | 会話状態 / 状態管理 |
| Gateway | 行動させる | ツール制御 / MCP |
| Identity | 誰として | Non-human identity |
| Policy | 裁く | Intent-based control |
7.3 Bedrock Agent との違い
| 観点 | Bedrock Agent | AgentCore |
|---|---|---|
| 制御 | 限定的 | 厳密 |
| 対象 | PoC / 軽量 | 本番 / 企業 |
| セキュリティ | 基本 | 高度 |
🧠試験観点
- エンタープライズ要件 → AgentCore
7.4 Step Functions / Lambda との使い分け
-
Step Functions
- 手順が固定
- 判断ロジックが明示
-
AgentCore
- 判断が動的
- 文脈依存
👉 「考える必要があるか？」が分岐点
7.5 典型ユースケース（試験頻出）
SaaS 管理エージェント
- ユーザー代理実行
- マルチテナント
- 厳密な権限制御
→ AgentCore
FAQ / 検索
- 自律行動なし
→ Knowledge Base + Model
7.6 AgentCore を使うべき判断軸
| 要件 | 判定 |
|---|---|
| 自律行動 | 必須 |
| 監査 | 必須 |
| 権限制御 | 必須 |
1つでも Yes → AgentCore
7.7 試験での思考プロセス
- AI は考える？
- 行動する？
- 制御が必要？
→ 全部 Yes = AgentCore
7.8 このノートを読み切ったあなた
あなたは今：
- AgentCore を「説明できる」
- 設計として「選択できる」
- 試験で「迷わない」
7.9 最後に（合格のために）
試験では暗記ではなく：
なぜこの構成が必要か
が問われます。
このノートは、その理由を 構造で理解するためのもの です。