ひとことで言うと
エージェントを「作る」ためのフレームワークではなく、他人が書いたエージェントを「本番で走らせて監視する」ための基盤です。CrewAI・LangGraph・LlamaIndex・Strands Agents・Google ADK・OpenAI Agents SDK などのどれで書いても、Bedrock の内外どのモデルを使っても載ります。モジュール（Runtime / Memory / Gateway / Identity / Observability ほか）は組み合わせても単独でも使えます。
要するに、エージェント専用の貸しビルです。入居者が何語で商売していようが建物側は中身を問いません。部屋は入居者ごとに完全に隔離され（セッションごとの microVM）、退去時には内装ごと解体されます。ビルが提供するのは受付と外線交換（Gateway）、入館証（Identity）、書庫（Memory）、監視カメラ（Observability）です。
だから試験でも「どのフレームワークで書くか」ではなく「誰が電気と鍵と監視カメラを面倒みるか」の問いとして出ます。
なぜ生まれたか
| 時期 | 何が起きたか |
|---|---|
| 2025-07-16 | AWS が AgentCore をプレビュー発表。「エージェントの中核機能ではなく、セッション管理・ID制御・メモリ・可観測性という土台の構築に数か月を費やしている」という問題設定 |
| 2025-10-13 | 一般提供（GA）開始。 Runtime / Memory / Gateway / Identity / Observability の各サービスが VPC・PrivateLink・CloudFormation・リソースタグに対応。9リージョンで提供 |
PoC のエージェントは1日で書けます。詰まるのはその先で、AWS 自身が挙げているのは 「システムとの接続」「ツール呼び出しの保護」「予期しない挙動のデバッグ」「作り直さずにスケールさせること」 です。
構造的に言うと、エージェントは従来のサーバーレスの前提を壊します。Lambda の実行時間ではマルチステップの推論が終わらず、ステートレス前提なのに会話状態を持ち、ユーザーの代理で外部SaaSの認証を通す必要がある。AgentCore はこの3点（実行時間・状態・IDと資格情報）を、フレームワークに依存しない形で外出しした基盤です。
何に使うか
| モジュール | 何をするか | 関連する試験ドメイン |
|---|---|---|
| Harness | 1回のAPI呼び出しでエージェントを定義・実行するマネージドなエージェントループ。モデル・システムプロンプト・ツールをインラインで指定すると、オーケストレーション／ツール実行／メモリ管理／応答生成を引き受ける。セッションごとに隔離 microVM（ファイルシステムとシェル付き） | D2 |
| Runtime | エージェント／ツールのサーバーレス実行環境。セッションごとに専用 microVM、MCP・A2A 対応 | D2 |
| Memory | 短期記憶（1セッション内のターン）と長期記憶（セッションをまたぐ嗜好・事実・要約）。メモリストアは複数エージェントで共有できる | D2 |
| Gateway | 既存 API・Lambda・サービスを MCP互換ツールに変換する単一エンドポイント。入力形式は OpenAPI / Smithy / Lambda | D2 |
| Identity | ワークロードIDとしてのエージェントID。受信認証（JWT）と送信認証（OAuth・APIキー）の両方 | D2・D3 |
| Observability | OTEL 互換のテレメトリを CloudWatch に出す。セッション数・レイテンシ・所要時間・トークン使用量・エラー率 | D4 |
| Code Interpreter | 隔離サンドボックスでのコード実行（Python / JavaScript / TypeScript） | D2 |
| Browser | クラウド上のブラウザ実行環境。Playwright・BrowserUse などから操作 | D2 |
| Evaluations | セッション・トレース・スパンを対象にしたエージェント評価 | D5 |
| Policy | ツール呼び出しを実行前に Gateway で捕まえ、自然言語または Cedar のルールで許可・拒否する | D3 |
| Payments | エージェントが有料API・MCPサーバ・コンテンツを使うためのマイクロトランザクション決済（x402プロトコル）。ウォレット連携と支出上限を持つ | D2 |
| Optimization | トレースを入力に、システムプロンプトやツール説明の改善案をAIが生成し、A/Bテストで検証する継続改善サービス。Evaluations の上に載る | D4 |
| Registry | 組織横断でエージェント・MCPサーバ・ツール・スキルを公開・審査・承認する中央カタログ。セマンティック検索とキーワード検索の併用 | D3 |
試験でどう問われるか
D2（実装と統合・26%）が主戦場です。「エージェントをどこで動かすか」「ツールをどう繋ぐか」の分岐として出ます。用語の定義は問われません。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| エージェントの実行先を選ぶ | 既存のOSSフレームワークのコードをそのまま／数時間かかる推論／セッション間のデータ混入を防ぎたい → AgentCore Runtime | Lambda に載せ替える案（実行時間と状態が持たない）／「フレームワークを Strands に書き直す」 |
| 既存のREST API・Lambda をエージェントに使わせる | MCP サーバを自前で書きたくない／OpenAPI 仕様がある → AgentCore Gateway | 「Lambda を MCP サーバとして実装し直す」／API Gateway を前に置くだけの案 |
| ツールが数百〜数千に増えた | プロンプトが膨らみレイテンシが悪化 → Gateway のセマンティックツール選択 | 全ツール定義を毎回プロンプトに詰める／ツールを減らす |
| セッションをまたいだ個人化 | 「前回の好みを覚えていてほしい」 → Memory の長期記憶 | 会話履歴を全部プロンプトに入れる案（短期記憶の役割と混同させる） |
| ユーザー代理で外部SaaSを叩く | Slack / GitHub 等へ OAuth で → AgentCore Identity の送信認証 | Secrets Manager にトークンを置いて共有する案 |
| 本番でエージェントの挙動が追えない | 推論の各ステップ・ツール呼び出しを見たい → AgentCore Observability（CloudWatch・OTEL） | CloudWatch Logs にアプリログを出すだけの案 |
| 長時間・GPU・複数エージェント常駐 | マルチデイのセッションが要る → Runtime の Instances | microVM のまま時間を延ばそうとする（上限は8時間） |
実行時間の上限は計算タイプで変わります。microVM は最長8時間、Instances（自アカウントの AWS 管理 EC2 上）は最長14日。「数日走り続ける調査エージェント」というシナリオが出たら microVM の選択肢は落ちます。逆に「即時に立ち上がり使った分だけ払う」なら microVM です。
ペイロードは 100MB まで扱え、HTTP に加えて WebSocket による双方向ストリーミングに対応します。「音声・動画を投げたい」がヒントになります。
実務でどう使うか
- セッション隔離は設計の前提であって、おまけではありません。 Runtime は各ユーザーセッションを専用 microVM（CPU・メモリ・ファイルシステムが分離）で動かし、セッション終了時に microVM ごと破棄してメモリをサニタイズします。マルチテナントのエージェントで「他人の会話が混ざる」事故を、アプリ側のコードではなく基盤側で潰せます
- Gateway の受信認証と送信認証を混同しない。 受信＝「そのエージェントが誰か」を検証する、送信＝「ツール側の資格情報を注入する」。ツールごとに認証方式が違う現実（OAuth・APIキー）を吸収するのが後者です
- Code Interpreter の実行時間は既定15分で、最長8時間まで延ばせます。 インラインでのファイルアップロードは100MBまで、ターミナル経由の S3 アップロードは 5GB まで。「巨大CSVを渡したい」場合は S3 を経由する設計になります
- Observability は CloudWatch に着地します。 メトリクス・スパン・ログはすべて CloudWatch に保存され、エージェントの Runtime データについてはトレース可視化のダッシュボードが用意されます。OTEL 互換で出るので、既存の監視スタックにも流せます
- モジュールは独立して使えます。 「Runtime は使わないが Gateway だけ欲しい」「Memory だけ他所のエージェントから叩く」が成立する設計です。全部入りを前提に見積もらないこと
ハマりどころ: AgentCore は Bedrock 本体と提供リージョンが別勘定です。GA 時点の提供は9リージョン（東京を含む）。「Bedrock が使えるからAgentCore も使えるはず」は成り立ちません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Strands Agents / Agent Squad | あちらはエージェントを書くためのフレームワーク。AgentCore はそれを載せる基盤。競合ではなく上下関係（Runtime は Strands をそのまま動かす） |
| Bedrock Agents Classic（旧 Amazon Bedrock Agents） | **これが AgentCore の前身です。**公式に「Amazon Bedrock Agents（now Amazon Bedrock Agents Classic）is no longer open to new customers」と明記され、同等の機能として AgentCore が案内されています（既存顧客は継続利用可）。試験ガイドの In-Scope 一覧にも Bedrock Agents は単独では載っておらず、載っているのは Bedrock AgentCore です。ドキュメントを検索すると Classic 側の記事が大量に出てくるので、読んでいるページがどちらの世代かを必ず確認してください |
| AWS Lambda | Lambda はステートレスな関数実行。AgentCore Runtime はセッション状態を持ったまま長時間動く。判断材料は「実行時間」と「セッション隔離」 |
| Amazon API Gateway | API Gateway は HTTP のフロント。AgentCore Gateway はプロトコル変換器で、REST/Lambda を MCP ツールとして見せる。前者は認証を通すだけ、後者は資格情報を注入する |
| DynamoDB に会話履歴を持つ | 自前実装なら DynamoDB でもできます。AgentCore Memory の差は長期記憶の抽出（会話から嗜好・事実・要約を自動で取り出す）。試験で「セッションをまたいで学習」と書かれたら Memory |
| Amazon Cognito | Cognito は人間のID。AgentCore Identity はエージェントのワークロードIDで、既存 IdP（Cognito・Okta・Entra ID）と繋いで使う。置き換えではありません |
| Bedrock Knowledge Bases | あちらは検索（RAG）。AgentCore は実行基盤。マネージド Knowledge Base は AgentCore Gateway と統合され、MCP ツールとして エージェントから呼べます（Knowledge Bases のノート） |
想起チェック
Q1. 「LangGraph で書いた既存エージェントを、コードを書き換えずに本番へ」というシナリオで真っ先に外れる選択肢は？
「Strands Agents に書き直す」「Bedrock 標準のエージェント形式に移す」といった書き換えを伴う案です。AgentCore Runtime はフレームワーク非依存を明示しているので、書き換えを要求する選択肢は設問の条件（コード変更なし）と矛盾します。
Q2. microVM と Instances を分ける基準は？
セッションの長さと、常駐が要るかです。microVM は即時起動・従量課金で最長8時間。Instances は自アカウントの AWS 管理 EC2 上で動き、最長14日の永続セッション・GPU・複数エージェントの同居に対応します。
Q3. ツールが増えすぎてレイテンシが悪化した。AgentCore のどれを使う？
Gateway のセマンティックツール選択です。文脈に合うツールだけを検索して渡すことで、数千のツールを扱いながらプロンプトサイズとレイテンシを抑えられます。「全ツール定義を毎回渡す」は正解になりません。
Q4. AgentCore Memory の短期記憶と長期記憶を1文ずつで。
短期記憶は単一セッション内のターンごとの文脈（「明日は？」が何を指すか）。長期記憶は複数セッションをまたいで自動抽出される嗜好・事実・要約で、メモリストアは複数エージェントで共有できます。
Q5. 「本番でエージェントがなぜその答えを出したか追えない」への定石は？
AgentCore Observability です。推論ステップ・ツール呼び出し・モデル呼び出しをスパンとして CloudWatch に出し、Runtime についてはトレース可視化ダッシュボードが使えます。出力は OTEL 互換なので既存の監視基盤にも流せます。