AWS Bedrock AgentCore本番運用｜AIエージェント基盤の設計

1. なぜ本番エージェント運用基盤か — AgentCore 全体像

AIエージェントは「作る」段階から「本番で動かす」段階へと急速に移行している。ChatGPT のような対話型 AI から一歩踏み込み、ツール呼び出し・マルチステップ推論・外部サービス連携を行うエージェントを試作したエンジニアが次に直面するのは、スケーリング・セッション管理・認証・長時間実行という本番運用の難題だ。

「LangGraph で動かしたエージェントを EC2 に乗せてみたが、同時ユーザー対応でセッションが混在した」「Lambda の15分制限でバッチ分析エージェントが途中で止まった」「各ツールの OAuth 管理がバラバラで本番リリース前に詰まった」——こうした課題を解決するためのインフラ基盤として、Amazon Bedrock AgentCore は 2025年10月13日にGAとなり、「本番運用インフラ」の課題をモジュラーな設計で解決するサービス群として東京を含む9リージョンで提供されている。

1-1. 本記事のゴール

AIエージェント開発には「エージェントを作る（フレームワーク/モデルの選択・プロンプト設計・ロジック実装）」段階と「エージェントを本番で安定して運用する（インフラ・スケーリング・セキュリティ・認証）」段階の二つがある。LangGraph や Strands で試作したエージェントをそのまま本番投入しようとしたとき、直面するのがセッション間のデータ汚染、8時間を超えるジョブの管理、フレームワーク別のスケーリング実装、ツール認証の散在といった本番特有の課題だ。

本記事のゴールは、Amazon Bedrock AgentCore の4つの中核コンポーネント（Runtime / Memory / Gateway / Identity）の設計思想と実戦的な利用方法を理解し、読者が自社エージェントの本番インフラ設計に直ちに応用できる状態を作ることにある。Vol1 では Runtime と Memory を中心に解説し、§7 で Bedrock Agents との統合パターンと移行ロードマップも整理する。

読者が本記事を読み終えたとき、「なぜ AgentCore が必要か」「どのコンポーネントをどの順で導入するか」「Bedrock Agents と AgentCore をどう使い分けるか」の三つに自信を持って答えられる状態を目指す。本記事は AWS 公式ドキュメント・re:Invent 2024・re:Invent 2025 の発表内容に基づく最新情報を反映している。サービスの仕様変更がある場合は AWS 公式ドキュメントを参照されたい。

Vol1 を読み終えたら、Vol2 ではより深い Runtime の設計パターンと Memory の長期記憶最適化を、Vol3 では Gateway の詳細設定と Observability の本番監視を取り上げる予定だ。

1-2. 読者像と前提知識

本記事が想定する読者は、生成AIアプリケーション開発の基礎（プロンプト設計・LLM API 呼び出し・Bedrock の基本操作）を習得済みで、エージェント開発に一歩踏み込んだ経験を持つエンジニアやアーキテクトだ。具体的には、Bedrock Agents でチャットボットや RAG エージェントを構築した経験、または LangGraph・Strands・CrewAI といった OSS フレームワークでツール呼び出しエージェントを試作した経験がある方を想定している。

前提知識として必要なのは、AWS IAM（ロール/ポリシーの基本）、AWS Lambda（関数定義とデプロイ）、Amazon Bedrock（モデル呼び出しと基本的な Agents 操作）の三つだ。Kubernetes や ECS といったコンテナ基盤の知識は不要——AgentCore はサーバーレスであり、インフラ管理を意識せずにエージェントを本番運用できる。

本番運用の経験がなく「試作で動いたがスケーリングや認証で詰まった」という読者にとって、このガイドは課題解決の出発点となるよう構成している。Runtime へのエージェントデプロイには Docker コンテナの基礎知識（Dockerfile の書き方と ECR へのプッシュ）が役立つが、必須ではない。AWS のコンソール操作とコマンドライン（AWS CLI）に慣れていれば、最初のデプロイまで数時間で到達できる。

AgentCore の概念を効率よく理解するには、AWS の既存サービスと対応づけると習得が早い。Runtime は「ECS/Lambda の代わりにエージェントを動かすインフラ」、Memory は「ElastiCache と DynamoDB の代わりにエージェントの記憶を管理するサービス」、Gateway は「API Gateway の代わりにエージェント向けに MCP プロトコルで API を公開するサービス」、Identity は「Secrets Manager + IAM を統合してエージェントの外部サービスアクセスを管理するサービス」として理解すると、既存の AWS 知識が直接活きる。

1-3. AgentCore の登場背景

2024年以降、AIエージェントの本番利用が急増する中で、開発チームは共通の壁に突き当たってきた。第一はセッション管理の複雑さだ。複数ユーザーが同一エージェントにアクセスするとき、セッション間でデータが混入するクロスセッション汚染リスクを自前で排除しなければならない。第二はスケーリングの難しさで、LangGraph や CrewAI はフレームワーク自体には本番グレードのオートスケール機能を持たず、ECS や Lambda でのラッパー実装が必要になる。第三は認証・認可の散在で、ツールごとに OAuth トークンや API キーを個別管理する運用コストが高い。第四は長時間実行の問題で、Lambda の15分制限や API Gateway のタイムアウトがエージェントの処理時間制約になる。

これらの課題を一つひとつ自前で解決しようとすると、エージェントのビジネスロジック開発より「本番環境の整備」に多大な工数が集中してしまう。AgentCore はこのボイラープレートを一括して請け負うことで、開発チームがエージェントのロジックとユーザー体験の向上に集中できる環境を提供する設計思想を持つ。

Amazon が 2025年7月に preview、2025年10月13日に GA（一般提供開始）として発表したのが Amazon Bedrock AgentCore だ。AgentCore は「エージェントを作る」ためのフレームワークではなく、「任意のフレームワークで作ったエージェントを本番で安定して動かすためのモジュラーなインフラ基盤」として設計されている。GA 時点で東京（ap-northeast-1）を含む9リージョンに対応し、消費ベースの従量課金で利用できる。

AgentCore の設計哲学は、既存の OSS エコシステム（LangGraph/Strands/CrewAI/MCP/ADK/Autogen/LlamaIndex/OpenAI Agents）を置き換えることなく、本番運用に必要なインフラ機能をモジュール単位で提供する点にある。開発者はフレームワークの選択を変えずに、AgentCore の各コンポーネントを必要に応じて組み込める。この「フレームワークロックインなし」の設計は、将来的なフレームワーク移行コストを最小化し、エコシステムの進化に追随しやすい構造を実現する。

GA 時点で対応している9リージョンは、米国東部（us-east-1）・米国西部（us-west-2）・欧州（eu-west-1）・アジア太平洋（ap-northeast-1・ap-southeast-1 など）にまたがる。日本リージョン（東京: ap-northeast-1）での利用が可能なため、データ所在地の要件が日本国内に限定されるシステムにも対応できる。課金は実際の計算リソース消費量（CPU 時間・メモリ量・ネットワーク転送量）に基づく従量制で、固定のインフラコストが発生しない点は大規模なスケーリングが必要なユースケースで特に有利だ。

1-4. 7コンポーネントの俯瞰

Amazon Bedrock AgentCore は7つのコンポーネントで構成される。本記事（Vol1）では Runtime/Memory/Gateway/Identity を扱い、Observability/Code Interpreter/Browser は後続巻で詳述する。

7つのコンポーネントはそれぞれ独立して利用可能だ。すべてを同時に導入する必要はなく、Runtime から始めてセッション分離を確立し、次に Memory を追加して会話継続性を持たせ、Gateway でツールを拡張するといった段階的な導入が推奨される。各コンポーネントは AWS コンソール・SDK・CDK/CloudFormation で管理できる。

Runtime は AgentCore の核心となるコンポーネントで、フレームワーク非依存のサーバーレス実行環境を提供する。Memory はセッションを超えた記憶の永続化を担い、エージェントにパーソナライゼーション能力を与える。Gateway は既存の API 資産を MCP ツールとして統合し、Identity はツールアクセスの認証・認可をセキュアに管理する。

Observability・Code Interpreter・Browser の3つは「組込ツール」として位置づけられ、エージェントの可観測性とコード/Web 操作能力を拡張する。Observability は CloudWatch と OTEL 互換フォーマットで推論プロセス・ツール呼び出し・性能指標・エラーを収集し、エンドツーエンドの可視化を実現する。Code Interpreter はサンドボックス内でコードを生成・実行し、データ分析や計算処理をエージェントが安全に担える。Browser はクラウド上のブラウザランタイムで Web 操作を実行し、Web 情報の収集や入力作業を自動化できる。

コンポーネントの選択に迷う場合は、以下のユースケース早見表を参考にしてほしい。

上表の「必須コンポーネント」だけで最初のデプロイを行い、本番稼働後に運用データを見ながら「推奨追加」のコンポーネントを段階的に導入するアプローチが、リスクとコストを最小化しながら AgentCore の価値を享受する現実的なパスだ。

1-5. Bedrock Agents との違い（概観）

Amazon Bedrock Agents と Amazon Bedrock AgentCore は、どちらも「AIエージェント」という言葉を冠しているが、解決する問題のレイヤーが根本的に異なる。混同すると設計判断を誤るため、ここで明確に整理しておく。

Bedrock Agents（フルマネージド・設定ファースト）: ReAct ループの実行エンジン、プロンプト管理、Knowledge Base 統合、Action Group による Lambda 呼び出しを AWS がすべて処理する。開発者は YAML/コンソール設定とビジネスロジック（Lambda）の実装に集中できる。カスタマイズの自由度は限定されるが、インフラ管理は最小化される。ReAct ループ・リトライ・エラーハンドリングを AWS に委ねたい場合の最速の選択肢だ。

AgentCore（モジュラーインフラ・フレームワーク非依存）: エージェントのロジック（ReAct ループ・思考・判断）は開発者が LangGraph や Strands で実装する。AgentCore はそのエージェントを「本番で動かすインフラ」を提供する。セッション分離・スケーリング・認証・ツール統合・記憶の永続化を担うが、エージェントの動作ロジックには関与しない。複雑なオーケストレーション・細粒度のセッション制御・特定フレームワーク必須の要件で本領を発揮する。

「どちらを選ぶべきか」という問いに対する現実的な答えは「用途に応じて両方を使い分ける・組み合わせる」だ。新機能のプロトタイピングは Bedrock Agents で2〜3日で動くものを作り、ユーザーの反応を確認してから、本番化要件（カスタムオーケストレーション・詳細なセッション管理・複雑な認証）が明確になったタイミングで AgentCore へ移行する。この段階的アプローチにより、初期投資を抑えながら本番品質を段階的に高めることができる。

両者の関係は「置換」ではなく「共存・補完」だ。Bedrock Agents でプロトタイプを素早く作り、要件の複雑化（カスタムループ・詳細なセッション管理・高度な認証）が生じたタイミングで AgentCore へロジックを移行するという段階的アプローチが、多くのチームにとって現実的な移行パスになる。なお、Bedrock Agents の Knowledge Base に相当する長期記憶機能は AgentCore Memory が補完し、Action Group に相当するツール統合は AgentCore Gateway が担う。§7 で統合パターンと移行ロードマップを詳述する。

関連記事: Amazon Bedrock 本番運用ガイド（Flows/Nova/Evaluations）→

2. AgentCore Runtime — サーバーレス実行とセッション分離

AgentCore Runtime はエージェントのサーバーレス実行環境として、最も基盤となるコンポーネントだ。従来のエージェント本番化では、ECS や Lambda でエージェントをラップし、セッション管理ロジックを自前で実装する必要があった。Runtime はこの課題をサーバーレスの microVM アーキテクチャで解決する。

2-1. microVM によるセッション分離

各ユーザーセッションは専用の microVM（独立した CPU・メモリ・ファイルシステムを持つ軽量仮想マシン）上で実行される。microVM はコンテナよりも厳密な分離を提供し、ハードウェアレベルでの隔離を実現する。セッション終了後、microVM は即座に終了し、メモリはサニタイズされる。

この設計により、セッションをまたいだデータ汚染（クロスセッション汚染）を構造的に排除する。複数ユーザーが同一エージェントに同時アクセスしても、各セッションは完全に隔離された環境で動作するため、セッション A のユーザーデータがセッション B に漏洩するリスクがない。

従来アプローチとの比較:

microVM の起動は低レイテンシで設計されており、セッション開始からエージェントが応答可能になるまでのコールドスタート時間は通常のコンテナと同等程度に抑えられている。高頻度のセッション生成が必要なユースケースでも、スケーリングは AgentCore が自動で処理するため、開発者はセッションプールの管理を意識する必要がない。

2-2. 最大8時間の実行ウィンドウ

Lambda の15分制限や API Gateway の29秒タイムアウトとは異なり、Runtime は最大8時間の継続実行をサポートする。これにより、リアルタイム応答型のエージェント（チャット・問い合わせ対応）だけでなく、長時間の非同期ワークロードも同一インフラで扱える。

8時間実行が有効なユースケース:

• 大規模データ分析: 数万行の CSV を解析してレポートを生成するエージェント
• 複数ステップのリサーチ: Web 情報収集→要約→比較→レポート生成を一連のセッションで完結させる
• コードリポジトリ全体の解析: クローンから解析まで時間のかかる処理
• バッチ処理の調整: 複数サブタスクのオーケストレーションを一つのセッションで管理
• 対話的な長時間セッション: ユーザーが長期間にわたってエージェントと対話するシナリオ

実行ウィンドウには「リアルタイムモード」と「非同期モード」の2種類がある。リアルタイムモードはチャットのようにユーザーが待機している状況向けで、レスポンスをストリームで返す。非同期モードは処理完了後に結果を返す設計で、バックグラウンド処理や長時間タスクに適する。

長時間実行タスクを設計する際の重要な考慮点は「チェックポイント設計」だ。エージェントが途中で失敗した場合に最初からやり直すのではなく、完了したステップを外部ストア（S3・DynamoDB）に記録し、再開時にスキップできる仕組みを最初から組み込む。これにより、8時間のセッションが7時間50分で失敗しても、チェックポイントから短時間で復旧できる。

import boto3
import json

client = boto3.client("bedrock-agentcore-runtime")

# 非同期セッション開始例
response = client.invoke_agent_runtime(
 agentRuntimeArn="arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:agent-runtime/my-agent",
 sessionId="session-user123-20251013",
 endpointName="my-endpoint",
 payload=json.dumps({
  "task": "analyze the Q3 sales report and generate a summary",
  "data_location": "s3://my-bucket/q3-sales.csv"
 }).encode(),
 contentType="application/json",
)
print("Session started:", response["sessionId"])

2-3. フレームワーク非依存の実行環境

Runtime は特定のエージェントフレームワークに依存しない。これは AgentCore Runtime の最も重要な設計思想の一つだ。開発チームがすでに LangGraph で書いたエージェントを、フレームワークを変えずにそのまま本番運用できる。

公式サポートが確認されているフレームワーク（2025年10月時点）:

実装方法は統一されている。エージェントのコードをコンテナイメージにパッケージし、Amazon ECR にプッシュしてから AgentCore Runtime に登録するだけだ。フレームワーク固有のインターフェースを AgentCore 向けにラップする必要はなく、既存のエージェントコードをそのまま使える。

デプロイの基本フロー:

1. エージェントコードをコンテナイメージに収める（Dockerfile 作成）
2. ECR にイメージをプッシュ（docker build & push）
3. AgentCore Runtime にエージェントを登録（AWS SDK / コンソール）
4. エンドポイントを作成して呼び出し開始

# AgentCore Runtime へのエージェント登録例（Python SDK）
import boto3

control_client = boto3.client("bedrock-agentcore-control")

# エージェント（コンテナ）の登録
agent_runtime = control_client.create_agent_runtime(
 agentRuntimeName="my-langgraph-agent",
 agentRuntimeArtifact={
  "containerConfiguration": {
"containerUri": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-agent:latest",
  }
 },
 description="LangGraph ベースのカスタマーサポートエージェント",
 networkConfiguration={
  "networkMode": "PUBLIC"
 },
 roleArn="arn:aws:iam::123456789012:role/AgentCoreRuntimeRole",
)
agent_runtime_arn = agent_runtime["agentRuntimeArn"]

# エンドポイントの作成
endpoint = control_client.create_agent_runtime_endpoint(
 agentRuntimeId=agent_runtime["agentRuntimeId"],
 name="production-endpoint",
)
print("エンドポイント ARN:", endpoint["agentRuntimeEndpointArn"])

Strands Agents SDK を使う場合は、AgentCore Runtime との統合がさらに簡素化される。SDK が提供する AgentCoreRuntime クラスを使うことで、コンテナのビルドからデプロイまでを SDK が処理してくれるオプションもある。

2-4. A2A（Agent-to-Agent）プロトコル対応

AgentCore Runtime は A2A（Agent-to-Agent）プロトコルに対応しており、エージェント間の直接通信を標準的な方法で実現する。複数の専門エージェントが協調して複雑なタスクを分担するマルチエージェント構成で、A2A は通信の標準化基盤として機能する。

A2A プロトコルが解決する課題:

マルチエージェントシステムを自前で構築しようとすると、「オーケストレーターがサブエージェントを呼び出す方法」「呼び出し結果の受け取り方」「セッションのライフサイクル管理」などを独自実装する必要があった。A2A プロトコルはこれらを標準化し、AgentCore Runtime が管理する。

A2A プロトコルの主な特徴:

• タスクの委譲: オーケストレーターエージェントがサブエージェントにタスクを委譲し、完了を待つか非同期で処理を続けるかを選択できる
• セッション境界の保持: 各エージェントは独立した microVM で動作し、セッション分離が保たれたまま通信できる
• 大容量ペイロード: 画像・音声・ドキュメントなどのマルチモーダルデータを含む大容量の通信をサポート
• 双方向通信: 一方向の呼び出しだけでなく、コールバックや進捗報告などの双方向通信も可能

典型的なマルチエージェント構成パターン:

オーケストレーター（Runtime A）
├── リサーチエージェント（Runtime B）← Web 情報収集担当
├── 分析エージェント（Runtime C）← データ解析担当
└── レポートエージェント（Runtime D）← 文書生成担当

各サブエージェントは独立した Runtime 上で動作し、障害の影響範囲が限定される。リサーチエージェントが失敗しても、分析エージェントとレポートエージェントのセッションには影響しない。

A2A プロトコルは Google が主導し、複数のクラウドベンダーが採用を表明している。AgentCore の A2A 対応により、他社の A2A 対応エージェントと AgentCore Runtime 上のエージェントが相互通信できる可能性もある。

2-5. Runtime のセッションライフサイクル管理

セッションには明確なライフサイクルがあり、これを理解した上で設計することがコスト最適化とデバッグの両面で重要だ。

セッションの状態遷移:

PENDING → STARTING → ACTIVE → COMPLETING → TERMINATED

• PENDING: セッション作成リクエストが受理され、microVM の起動を待っている状態
• STARTING: microVM が起動中でエージェントの初期化処理が走っている状態
• ACTIVE: エージェントがリクエストを受け付け可能な状態
• COMPLETING: セッション終了処理（Memory への書き込み・リソース解放）中
• TERMINATED: microVM が終了し、リソースが完全に解放された状態

セッション ID は呼び出し元が指定できる。user_id + date + channel のような構造化した ID にしておくと、CloudWatch でのフィルタリング・Memory へのデータ紐付け・障害調査の効率が大幅に上がる。ランダム UUID を使うと後からデバッグが困難になるため、ID の命名規則は設計初期に決めておくこと。

セッション終了の設計:

タスクが完了したら明示的にセッションを終了させる処理を組み込む。タイムアウトによる自動終了に任せるだけでは、処理完了後も不要なセッションが残りコストが発生する。

# セッション終了の明示的な呼び出し例
def complete_task(session_id):
 # タスク結果を永続化
 save_results_to_s3(session_id, results)

 # Memory に重要な学習内容を記録
 memory_client.store(session_id=session_id, content=insights)

 # セッションを明示的に終了
 runtime_client.delete_session(sessionId=session_id)

2-6. フレームワーク別の統合パターン

各フレームワークを AgentCore Runtime で動かす際の統合パターンを整理する。

Strands Agents SDK の場合:

Strands Agents SDK は AgentCore Runtime との統合が最も密接で、SDK の AgentCore クラスを使うことでコンテナビルド不要でデプロイできるオプションがある。

from strands import Agent
from strands.runtimes import AgentCoreRuntime

# AgentCore Runtime をバックエンドとして指定
runtime = AgentCoreRuntime(
 agent_runtime_arn="arn:aws:bedrock-agentcore:...:agent-runtime/my-agent",
 endpoint_name="production-endpoint",
)

agent = Agent(
 system_prompt="あなたはカスタマーサポートエージェントです。",
 runtime=runtime,
)

# セッション指定での実行
response = agent(
 "注文状況を確認したい",
 session_id="session-user123-20251013",
)

LangGraph の場合:

LangGraph エージェントは通常の Python アプリケーションとしてコンテナ化し、AgentCore Runtime に登録する。エントリーポイントで AgentCore が期待する JSON 形式の入出力を処理するラッパーを追加するだけで、LangGraph のグラフ定義自体は変更不要だ。

# entrypoint.py（コンテナのエントリーポイント）
import json
import os
from my_langgraph_agent import graph  # 既存の LangGraph グラフをそのまま import

def handler(event, context):
 payload = json.loads(event["body"])
 session_id = event.get("sessionId")

 # LangGraph グラフを実行（コード変更なし）
 result = graph.invoke(
  {"messages": payload["messages"]},
  config={"configurable": {"thread_id": session_id}},
 )
 return {
  "statusCode": 200,
  "body": json.dumps({"response": result["messages"][-1].content}),
 }

2-7. Runtime を使うべき判断基準

AgentCore Runtime が適しているケースと、Lambda や ECS でシンプルに実装する方が良いケースを整理する。

AgentCore Runtime を選ぶべき状況:

• セッションごとの厳密な分離が本番要件として存在する（金融・医療・法律など高セキュリティ領域）
• 処理時間が数分〜数時間になる長時間タスクを扱う
• 同時に多くのユーザーセッションを処理するスケーリングが必要
• フレームワークを変えずに本番運用したい（既存 LangGraph/Strands 等の資産を活かす）
• マルチエージェント構成で A2A プロトコルの恩恵を受けたい

Lambda で十分な状況:

• 単発の stateless なリクエスト処理（15分以内）
• セッション状態の管理が不要なシンプルな応答
• リクエストごとに完全にリセットされる処理
• 最小限のインフラコストで済むユースケース

Runtime と Lambda を混在させる設計も有効だ。「ユーザーとの対話」は Runtime で長時間セッションを保持し、「単発の外部 API 呼び出し」は Gateway 経由の Lambda で処理する。AgentCore のコンポーネントは組み合わせ自由なため、ユースケースに応じた最適な構成を選べる。

3. AgentCore Memory — 短期・長期記憶

AgentCore Memory は、AIエージェントがセッションをまたいで文脈を保持するためのフルマネージドな記憶基盤です。会話の「今ここ」を扱う短期記憶と、セッション横断で知識を蓄積する長期記憶の2層構造を持ち、パーソナライゼーションや継続的な学習を実現します。

3-1. 短期記憶 — セッション内イベントの保持

短期記憶（Short-Term Memory、以下 STM）は、現在進行中のセッション内で発生した生の会話イベントを時系列で保持します。ユーザーの発言・エージェントの応答・ツール呼び出し結果などがイベントとして記録され、エージェントはセッション内の文脈を一貫して参照できます。

短期記憶の主な特性は次の通りです。

STM はそれ自体で会話の一貫性を保つ機能を提供しつつ、長期記憶の抽出処理へのデータ源としても機能します。長期記憶への抽出は非同期で実行されるため、セッション中のレイテンシに影響しません。

3-2. 長期記憶 — セマンティック抽出と永続化

長期記憶（Long-Term Memory、以下 LTM）は、STM から有益な情報をセマンティックに抽出し、セッション横断で永続化する仕組みです。抽出には小型言語モデルが使われ、会話の中から事実・ユーザー嗜好・セッションサマリーを自動で識別・記録します。取得時はキーワードマッチではなくセマンティック検索が用いられるため、次のセッションで表現が変わっても意味的に関連する記憶を自然に引き出せます。

AgentCore Memory は3つの組み込み長期記憶戦略をサポートします。

summaryMemoryStrategy（会話要約）

セッション終了時に会話全体の要約を生成して保存します。次のセッション開始時に要約を読み込むことで、エージェントは「前回何を話したか」を高速に把握できます。会話量が多いシナリオや、概要レベルの継続性を重視する用途に適しています。

userPreferenceMemoryStrategy（ユーザー嗜好の学習）

会話の中でユーザーが示した好み・設定・行動パターンを抽出して保存します。「フォーマルな文体を好む」「日本語で回答してほしい」「コードは Python で」といった嗜好が自動で学習され、次のセッションから反映されます。パーソナライゼーションを必要とするアシスタント系エージェントで特に有効です。

semanticMemoryStrategy（事実のセマンティック抽出）

会話から事実情報（名前・日付・関係性・タスク状態など）を抽出し、構造化されたメモリレコードとして保存します。抽出フェーズでは小型モデルが会話を解析して有益な洞察を特定し、統合フェーズでは既存レコードへの追記か新規レコード作成かを判断します。2026年5月のアップデートで長期記憶レコードへのメタデータ付与が可能になり、構造化属性によるフィルタリングとセマンティック検索の組み合わせで、より高精度な記憶取得が実現しています。

3-3. Strands Agents SDK との連携

Strands Agents SDK は AgentCoreMemorySessionManager クラスを通じて AgentCore Memory とネイティブに統合されます。低レベルの Memory API を直接操作せずに STM と LTM を自動で同期できる点が特徴です。バッチ処理・メッセージ順序管理・名前空間の選択・メタデータ書式化を内部で自動処理するため、セッションマネージャーを構成するだけで記憶機能を利用できます。

from strands import Agent
from strands.session.agentcore_memory import AgentCoreMemorySessionManager

session_manager = AgentCoreMemorySessionManager(
 memory_id="your-memory-id",
 session_id="session-001",
 actor_id="user-123",
 batch_size=5,
)

agent = Agent(
 system_prompt="あなたはユーザーの好みを学習するアシスタントです。",
 session_manager=session_manager,
)

with session_manager:
 response = agent("好きな色は青です")
 response = agent("次は赤に変えました")
# with ブロック終了時にバッファをフラッシュして LTM 抽出をトリガー

batch_size を指定すると複数のメッセージをバッファリングしてまとめて送信し、API 呼び出し回数を削減できます。batch_size > 1 の場合は with ブロックまたは明示的な close() を必ず使用してください。省略するとバッファ内の未送信メッセージが失われます。

3-4. 短期/長期記憶の使い分け指針

LTM の抽出にはコストが発生します。全セッションで LTM 抽出を有効にするのではなく、パーソナライゼーションや知識蓄積が必要なエージェントにのみ適用し、不要なセッションは STM のみで運用するのがコスト最適化の基本方針です。

4. AgentCore Gateway — API/Lambda の MCP ツール化

AgentCore Gateway は、既存の API・Lambda 関数・各種サービスを MCP（Model Context Protocol）互換のツールへ変換し、エージェントから安全かつ統一的なインターフェースで利用可能にするマネージドサービスです。サーバーのホスティングやスケーリングを管理することなく、数行のコードで MCP エンドポイントを構築できます。

4-1. MCP と AgentCore Gateway の位置づけ

MCP（Model Context Protocol）は、AIエージェントが外部ツール・データソース・サービスと標準化されたプロトコルで通信するための仕様です。エージェントは MCP を通じてツールの一覧を「発見」し、呼び出しインターフェースを動的に把握することができます。

従来の課題は、既存の REST API や Lambda を MCP に対応させるには、MCP サーバーの実装・ホスティング・スケーリング・セキュリティ設定が別途必要で、本番レベルで運用できるまでに相当な開発工数が掛かる点でした。

AgentCore Gateway はこの課題をフルマネージドで解決します。既存の定義ファイル（OpenAPI 仕様など）や Lambda ARN を指定するだけで、インフラ管理なしに MCP エンドポイントが生成されます。AWS 公式には「ingress 認証と egress 認証の両方をフルマネージドで提供する唯一のソリューション」と位置付けられています。

4-2. サポートするターゲット種別

Gateway は以下の4種類のターゲットを MCP ツール化できます。

Lambda を対象とする場合、コードの変更は不要です。既存の Lambda 関数を Gateway のターゲットとして登録するだけで MCP ツールとして公開されます。MCP サーバーをターゲットとする場合は、バラバラに管理されていた複数の MCP サーバーを Gateway で集約し、単一エンドポイントに統合することができます。

4-3. 2方向アクセス制御 — 受信検証と送信接続

Gateway の特徴の一つが、受信側の検証（inbound）とバックエンドへの接続（outbound）を独立して設定できる2方向のアクセス制御モデルです。エンドツーエンドのセキュリティをインフラ管理なしで実現します。

受信側の検証（Inbound Authorization）

Gateway エンドポイントへのアクセスを要求するクライアント（エージェントや他のサービス）を検証・認可します。

送信側の接続（Outbound Authorization）

Gateway が受信済みのリクエストをバックエンドのターゲットへ転送する際に使用します。ターゲットの種類に応じて適切な接続方式を選択します。

4-4. Lambda を MCP ツール化する最小構成例

Gateway の構築は Bedrock AgentCore スターターツールキット、AWS マネジメントコンソール、または AWS SDK から行えます。以下は Python SDK を使って Lambda 関数を MCP ツールとして公開する最小構成の例です。

import boto3

client = boto3.client("bedrock-agentcore-control")

# Gateway の作成（初回のみ）
gateway = client.create_gateway(
 name="my-api-gateway",
 protocolType="MCP",
 authorizerType="IAM",
)
gateway_id = gateway["gatewayId"]

# Lambda 関数をターゲットとして登録
target = client.create_gateway_target(
 gatewayId=gateway_id,
 name="my-lambda-tool",
 targetConfiguration={
  "lambda": {
"lambdaArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:my-function",
  }
 },
 credentialProviderConfigurations=[{
  "credentialProviderType": "GATEWAY_IAM_ROLE",
 }],
)
print("Gateway endpoint:", gateway["gatewayUrl"])

エージェント側では生成された Gateway エンドポイント URL を MCP サーバーとして指定するだけで、Lambda 関数がツールとして利用できます。OpenAPI 仕様を対象にする場合は targetConfiguration の openApi キーに仕様ファイルの S3 URI を指定する形に変わりますが、それ以外の手順は共通です。

4-5. ツール検索性と一元的 MCP インターフェース

Gateway はツールの検索性（discoverability）を高める設計になっています。複数のターゲット（OpenAPI/Lambda/MCP サーバー）を単一の Gateway エンドポイントに集約することで、エージェントは1つのエンドポイントを参照するだけで利用可能なツール一覧を動的に取得できます。

大規模なエンタープライズ環境では、部門ごとに分散した API や Lambda を Gateway に集約することで、エージェントのツール管理が一元化され、ガバナンスと可視性が向上します。サーバーレスインフラで動作するため、同時リクエスト数に応じた自動スケーリングが行われ、MCP サーバーのキャパシティ管理が不要になります。

5. AgentCore Identity — 認証・認可とトークン管理

5-1. アイデンティティ対応認可 — エージェントが「誰として」動くか

AgentCore Identity は、エージェントが外部サービスへアクセスする際に必要となる「このエージェントが何者であるか」の証明を一元管理する仕組みだ。従来のシンプルな権限付与とは考え方が根本的に異なる。エージェントはエンドユーザーから委任を受けた代理人として振る舞い、ユーザーのコンテキストを保持したまま外部サービスへ代理でアクセスする。これがアイデンティティ対応認可（identity-aware authorization）の本質だ。

委任の連鎖はシンプルに設計されている。エンドユーザーが AgentCore に処理を依頼すると、エージェントはそのユーザーから明示的な同意を得た上で代理アクセス（delegation）を行う。エージェントがユーザーになりすます「impersonation」とは明確に区別されており、外部サービス側でも「誰の代理でどのエージェントがアクセスしているか」を正確に追跡できる構造になっている。

2025年10月13日のGA以降、新規エージェントにはサービスリンクロール AWSServiceRoleForBedrockAgentCoreRuntimeIdentity が自動的に割り当てられる。手動でのポリシー定義は不要になり、エージェントのアイデンティティ管理が大幅に簡素化された。

5-2. ワークロードアイデンティティ — エージェントプロセス固有の識別子

AgentCore のワークロードアイデンティティ（workload identity）は、人間のユーザーIDとは独立してエージェントプロセス自体に付与される識別子だ。自動化されたワークロードを個別に識別するための仕組みとして機能する。

ワークロードアイデンティティを持つエージェントは、外部の連携先に対してJWT形式のベアラートークンを提示する。AgentCore は GetResourceOauth2Token APIを介してこのトークン取得フローを管理しており、エージェント側の実装量を最小限に抑える。サービスリンクロールがバックグラウンドで必要な権限を保持するため、開発者は複雑な権限設定から解放される。ワークロードが誰であるかをAWSが保証し、外部サービスへの接続はその保証を活用する形になる。

5-3. 認証情報の安全な保管（Token Vault）

長期利用を前提とした外部サービス連携では、有効期間が異なる複数の情報を安全に管理する仕組みが不可欠だ。AgentCore の Token Vault はこの役割を担う保管庫として機能する。

Token Vault の主な特徴:

• 保管対象: 外部サービスへのアクセスに必要な情報全般（短命なアクセスキーと、長期間有効なリフレッシュ情報の両方）
• 暗号化: AWS KMSによる保存時・転送時のデータ保護（カスタマーマネージドキーにも対応）
• 自動更新: アクセス情報の期限切れをAgentCoreが検知し、保管済みのリフレッシュ情報で自動的に新しいアクセス情報を取得
• 保管期間: リフレッシュ情報は通常30日程度の有効期間（アクセス情報の1〜2時間と比べて大幅に長期）

この自動更新の仕組みにより、エージェントが長時間のタスクを実行する場合でも、ユーザーが手動で再認可を行う必要がなくなる。GitリポジトリやCI環境変数への直接書き込みと比べて、アクセス制御と監査ログが付随する点が運用上の大きな違いだ。GitHub（User-to-server token expiration有効時）、Slack（token rotation設定時）、Google（access_type=offline 指定時）など、プロバイダーごとにリフレッシュ情報の取得方法が異なる点は設定時の注意ポイントになる。

5-4. OAuth 2.0 連携と委譲アクセスのパターン

AgentCore Identity が事前設定済みで対応するサービスとして、2025年時点で確認されているのは以下の通りだ。

事前設定済みプロバイダー: GitHub、Slack、Salesforce、Google、Microsoft、Atlassian、LinkedIn

カスタム設定の範囲:
– ディスカバリーURLとクライアント情報を指定することで任意のOAuth 2.0互換サービスに対応
– APIキー方式のみをサポートするサービス向けの API key credential provider
– Coinbase CDPやStripe Privyなどの決済系サービスへの対応

連携フローには2種類ある。マシン同士が直接連携する2-legged OAuth（サービス間連携）と、エンドユーザーの承認を介した3-legged OAuth（ユーザー委任）だ。AgentCore は両パターンをサポートしており、ユーザー委任が必要な場面ではエージェントが認可URLをユーザーに提示してコンセントを取得するフローが走る。

RFC 8707に基づくリソースインジケーターにより、発行されるトークンのスコープを特定のリソースサーバーに限定できる。MCPサーバーを介したツール連携では、この精密なスコープ制御が重要な役割を果たす。Cognito ResourceServerの identifier 値と対応付けることで、MCP実装における最小権限の原則を実現できる。

以下に AgentCore Identity の委譲アクセスフロー全体を示す。

graph TD
  User[エンドユーザー] -->|処理依頼| Agent[エージェント\nAgentCore Runtime上]
  Agent -->|ワークロードIDで識別| WID[ワークロード\nアイデンティティ]
  WID -->|GetResourceOauth2Token| TV[Token Vault\n暗号化保管庫]
  TV -->|アクセス情報を返却| Agent
  Agent -->|代理アクセス JWT Bearer| Ext[外部サービス\nGitHub / Slack / Google等]

  User -->|3LO: 同意フロー| Auth[ユーザー承認\n認可画面]
  Auth -->|長期保存情報を格納| TV

  SLR[サービスリンクロール\nAWSServiceRoleFor\nIdentity] -.->|自動プロビジョン| WID

6. AgentCore Observability と組込ツール

6-1. エージェント実行のエンドツーエンド可視化

AgentCore Observability はエージェントが「何をしているか」をリアルタイムで把握する仕組みだ。推論プロセス、ツール呼び出し、性能指標、エラーを一元的に収集し、開発者とオペレーターに完全な実行コンテキストを提供する。

収集される情報を階層で見ると:

• セッション（Session）: ユーザーとの会話全体のコンテキスト、状態管理、リソース割り当て
• トレース（Trace）: 個々のリクエスト〜レスポンスサイクル、処理ステップの全記録
• スパン（Span）: 個別の計測単位（推論1回、ツール呼び出し1回など）、親子関係で入れ子構造

この3層構造により、「どのセッションのどのリクエストで、どの処理に何ミリ秒かかったか」を特定できる。問題発生時のデバッグが大幅に効率化される。

6-2. CloudWatch 連携と OTEL 互換

AgentCore のテレメトリデータは OpenTelemetry (OTEL) 互換フォーマットで出力される。これにより、Amazon CloudWatch への直接送信と、Datadog や Elastic 等のサードパーティツールへのエクスポートが標準的な方法で実現できる。

デフォルトで収集されるCloudWatchメトリクス（追加実装不要）:

リソース使用量メトリクス（1分解像度）:
– CPUUsed（vCPU時間）
– MemoryUsed（GB時間）
– セッションレベルのvended logs（1秒粒度）

CloudWatch には AgentCore 専用の組み込みダッシュボードが用意されており、エージェント一覧・セッション・トレースを画面から確認できる。スパンデータは aws/spans ロググループに格納され、CloudWatch Transaction Searchを有効化すると詳細なスパン分析が可能になる（反映まで最大10分）。

ログには trace_id と span_id が付与されるため、分散トレーシングに対応したツールとの連携も容易だ。カスタムメトリクスやスパンを追加したい場合は AWS Distro for OpenTelemetry (ADOT) SDKを利用する。エージェントのビジネスロジックに固有の指標を既存のCloudWatchメトリクスと並べて可視化できる。

6-3. Code Interpreter — 安全なコード実行環境

Code Interpreter はサンドボックスコンテナ内でコードを生成・実行する仕組みだ。エージェントが計算やデータ分析を必要とする局面で、コードを外部に送出することなくAgentCoreの管理下で安全に処理できる。

対応環境と制限:
– サポート言語: Python、JavaScript、TypeScript
– よく使われるライブラリはプリインストール済み
– ファイルサイズ: インライン100MBまで、S3経由で最大5GB
– インターネットアクセス: 有効（要件に応じて制御可能）
– 実行タイムアウト: デフォルト15分、最大8時間まで設定可

代表的な用途:

各実行はコンテナで独立しており、セッション間でのデータ混入を防ぐ。CloudTrailによる監査ログも自動で記録されるため、エンタープライズ環境のコンプライアンス要件にも対応できる。

6-4. Browser Tool — クラウドブラウザランタイム

Browser Tool はクラウド上のセキュアなブラウザ環境でWeb操作を実行する仕組みだ。エージェントがWebサイトの情報収集、フォームへの入力、ボタンのクリックといったブラウザ操作を自律的に行える。

ローカルにブラウザをインストールする必要はなく、AgentCoreが完全に管理するコンテナ上のブラウザインスタンスを使う。Playwright互換のAPIを通じてWebSocket経由でブラウザを操作する設計だ。

主な機能:
– URLナビゲーション・フォーム入力・クリック操作
– 動的コンテンツの取得と解析
– スクリーンショット取得（エージェントの視覚的理解に利用）
– セッションの独立性（使用後は自動リセット）

エンタープライズ向け監査機能:

設定は aws.browser.v1 マネージドオプションで素早く開始でき、ネットワーク設定や高度な録画が必要な場合はカスタムオプションを利用する。デフォルトのタイムアウトは15分で、最大8時間まで拡張可能だ。

以下に AgentCore Observability と組込ツールの連携フローを示す。

graph LR
  Agent[エージェント] -->|テレメトリ出力\nOTEL形式| Obs[AgentCore\nObservability]

  Obs --> Sess[セッション層]
  Obs --> Trace[トレース層]
  Obs --> Span[スパン層]

  Sess --> CW[Amazon CloudWatch]
  Trace --> CW
  Span --> CW

  CW --> Dash[内蔵ダッシュボード\nAgent/Session/Trace View]
  CW --> Logs[aws/spansロググループ]

  Agent -->|コード実行要求| CI[Code Interpreter\nサンドボックス]
  Agent -->|ブラウザ操作要求| BT[Browser Tool\nクラウドブラウザ]

  CI -->|監査ログ| CT[CloudTrail]
  BT -->|操作記録| SR[Session Recording\n+ Live View]

7. 実戦統合パターンと Bedrock Agents からの移行

ここまで Runtime・Memory・Gateway・Identity をそれぞれ単体で解説してきた。本番システムではこれらを組み合わせて初めて価値を発揮する。§7 では「どのユースケースにどのコンポーネントを組み合わせるか」という選択基準と、既存の Amazon Bedrock Agents からの移行戦略を整理する。

7-1. ユースケース別の組合せ選択基準

AgentCore の 4 コンポーネントは独立して利用できるが、ユースケースごとに最適な組み合わせパターンが存在する。以下の 3 パターンは本番での採用頻度が高い代表例だ。

パターン A: カスタマーサポート Bot

構成: Runtime + Memory（長期記憶）+ Gateway（CRM API 接続）

カスタマーサポート Bot の本番要件は「顧客ごとの文脈保持」と「社内 CRM/チケットシステムとのリアルタイム連携」に集約される。

Runtime がセッションごとの microVM 分離を提供することで、同時接続する複数顧客のセッションが互いに影響しない。各会話が終了しても、Memory の長期記憶抽出によって顧客の過去問い合わせ履歴・好み・未解決課題が次セッションで自動的に復元される。

Gateway は社内 CRM や注文管理システムの REST API を MCP ツールとして公開する役割を担う。エージェントからは「顧客情報を取得する」「チケットを更新する」という自然言語に近い操作として扱えるため、プロンプトのツール記述が簡潔になる。Gateway の dual auth により、エージェントが CRM にアクセスする際の委譲接続もセキュアに管理できる。

# カスタマーサポート Bot の構成イメージ（Strands Agents SDK 使用例）
from strands import Agent
from strands.tools import MCPClient

# Gateway 経由で CRM ツールを取得
crm_tools = MCPClient(gateway_endpoint=GATEWAY_URL).get_tools()

agent = Agent(
 tools=crm_tools,
 memory_id=MEMORY_ID,# 長期記憶: 顧客ごとのメモリストア
 session_id=SESSION_ID, # Runtime: 専用 microVM セッション
)

Memory の長期記憶を活かすためのポイントは、メモリストアの粒度設計だ。顧客 ID をキーにしたメモリストアを顧客ごとに作成することで、異なる顧客の記憶が混在するリスクを避けられる。長期記憶の抽出モデルには小型 LLM が使われるため、高精度を期待するよりも「重要事実をシンプルな文で記録する」プロンプト設計が効果的だ。

パターン B: コード生成エージェント

構成: Runtime + Code Interpreter + Browser

コード生成エージェントの課題は「生成したコードを実行・検証するサンドボックス」と「外部ドキュメントやリポジトリへのアクセス」だ。

Runtime の最大 8 時間実行ウィンドウにより、大規模リポジトリの解析・複数ファイルにまたがるリファクタリング・テスト実行サイクルなど時間のかかるタスクが完結できる。Code Interpreter はサンドボックス内でコードを安全に実行し、依存ライブラリのインストール・コンパイル・単体テスト実行まで一気通貫で扱える。

Browser ツールはドキュメントサイトや公開リポジトリへのアクセスに使い、最新の API 仕様やライブラリの使い方を取得してコード生成の精度を高める。Memory はセッション間でのプロジェクト文脈保持（コードの設計方針・過去の修正履歴）に活用する。

このパターンで特に重要なのは Runtime の microVM によるサンドボックス保護だ。Code Interpreter で実行するコードは原則的に untrusted な生成物のため、microVM の分離が本番安全性の前提となる。

パターン C: マルチエージェント協調システム

構成: Runtime（A2A プロトコル）+ Identity（委譲）+ Gateway（ツール共有）

複数の専門エージェントが協調して複雑なタスクを分担する構成では、A2A（Agent-to-Agent）プロトコル・権限委譲・ツール共有の 3 要素が鍵になる。

Runtime の A2A プロトコルにより、オーケストレーターエージェントがサブエージェントを非同期で呼び出し、結果を集約できる。各エージェントは独立した microVM で動作するため、障害の影響範囲が限定される。

Identity の権限委譲機能により、オーケストレーターがサブエージェントに対して「自分が持つスコープの一部を委譲」できる。たとえばデータ読み取り権限のみを持つ分析エージェントと、書き込み権限も持つ更新エージェントに役割を分離し、最小権限の原則を保ちながら協調させる。

Gateway はツールを共有インフラとして一元化する役割を持つ。各エージェントが同じ MCP インターフェースを通じて同一のツール群にアクセスできるため、ツール定義の重複を排除し一貫した挙動を保証できる。

7-2. コンポーネント選択の判断フロー

以下の基準でコンポーネントを選択すると、設計の迷いが減る。

7-3. Amazon Bedrock Agents との関係 — 共存・補完・移行

AgentCore と従来の Amazon Bedrock Agents は競合ではなく、解くべき課題が異なるサービスだ。この区別を理解せずに「AgentCore に移行すべきか」と悩むケースが多いため、関係を整理する。

Amazon Bedrock Agents の位置づけ

Bedrock Agents はフルマネージドな設定ファーストのサービスだ。ReAct ループ（Reason+Act サイクル）を AWS が処理し、Action Group（Lambda 呼び出し）と Knowledge Base を設定画面から繋ぐだけでエージェントが動く。ロジックを自分で書くより「設定して組み立てる」アプローチのため、プロトタイプ・PoC・定型業務の自動化では圧倒的に速く動かせる。

AgentCore の位置づけ

AgentCore は任意フレームワーク（LangGraph・Strands・CrewAI 等）で書いたエージェントコードを本番運用するためのモジュラーインフラだ。フレームワークやモデルの選択に制約がなく、複雑なオーケストレーションロジックをコードで表現できる。ただし「ReAct ループ」などのエージェントロジック自体は自分で書く必要があり、設計・実装コストは Bedrock Agents より高い。

段階的移行パターン

最も現実的な移行パスは「Bedrock Agents でプロトタイプ → 要件進化で AgentCore へ」だ。

• フェーズ 1（プロトタイプ）: Bedrock Agents で動く最小版を作る。設定ベースで速く検証でき、フィードバックを得やすい。
• フェーズ 2（機能拡張）: カスタム ReAct ロジック・複雑なマルチエージェント協調・特定フレームワーク必須など「Bedrock Agents の制約に当たった」タイミングで AgentCore を検討する。
• フェーズ 3（AgentCore 本番）: Runtime でセッション分離・Memory で記憶管理・Gateway でツール統一・Identity で権限管理に切り替える。Bedrock Agents の Knowledge Base は AgentCore Memory の長期記憶ストアに相当する機能で補完できる。

移行を急ぐ必要はなく、既存の Bedrock Agents が機能している部分はそのまま維持して共存させる設計が現実的だ。AgentCore は「Bedrock Agents では実現できない deeper customization が必要なコンポーネント」だけに部分的に採用してもよい。

7-4. スケーリング設計とコスト最適化

AgentCore の課金は消費ベース（actual compute 利用量・秒単位）のため、使わないリソースへの支払いが発生しない。スケーリングは AgentCore が自動管理するため、Lambda に近い感覚で設計できる。

コスト最適化で押さえるべき点は以下の 4 つだ。

セッション設計の見直し

Runtime の課金はセッションが存在する時間に比例する。不要なセッションを長生きさせると無駄なコストになる。タスクが完了したら明示的にセッションを終了する設計にする。8 時間の上限は最大値であり、必要以上に長いタイムアウトを設定しないこと。

Memory の長期記憶抽出頻度

長期記憶の抽出は会話データからの LLM 推論コストを発生させる。全会話を長期記憶対象にするのではなく、「定期的なサマリーセッション」や「ユーザーが明示的に記憶指示した情報」のみ抽出対象にする設計がコスト効率が良い。

Gateway の MCP キャッシュ活用

同じツール定義を繰り返し取得するオーバーヘッドを避けるため、Gateway の MCP ツール一覧はセッション開始時に一度取得してキャッシュする。頻繁なツール一覧取得は不要な API コールを発生させる。

Observability の粒度設定

トレースとログは CloudWatch に流れ、量に応じてコストが発生する。開発環境は詳細トレース・本番環境は要点のみ（エラー・タイムアウト・パフォーマンス異常）のように粒度を環境別に分ける。全ての推論ステップをトレースするとコストが想定以上に膨らむことがある。

8. 詰まりポイント・アンチパターンとまとめ

AgentCore を本番に持ち込んだチームが直面しやすい詰まりポイントとアンチパターンを、実戦経験に基づいて整理する。設計段階でこれらを知っておくことで、後戻りコストを大幅に削減できる。

8-1. 詰まりポイント

詰まり 1: microVM セッション分離での状態管理の誤解

Runtime の microVM はセッション終了時にメモリサニタイズされる。「セッション内で作ったファイルや変数は次のセッションで使えるはず」という前提で設計すると、本番でデータが消える事故になる。

セッションをまたぐ状態は必ず外部ストアに書き出す。Memory サービスへの記録・S3 へのファイル保存・DynamoDB へのデータ永続化など、microVM の外に出す設計が必須だ。「セッション内でのみ使う一時データ」と「セッション間で引き継ぐ永続データ」を設計時に明確に分類しておくこと。

# セッション終了前に必要なデータを外部ストアへ
def on_session_end(session_context):
 # microVM 内のローカル変数は消えるので Memory に書き出す
 agent.memory.store(
  session_id=SESSION_ID,
  content=session_context.important_findings,
  memory_type="long_term"
 )
 # 生成ファイルは S3 に保存
 s3.upload_file(local_path, BUCKET, key)

詰まり 2: Memory の長期記憶抽出精度の限界

長期記憶の抽出は小型 LLM が会話から事実を抽出する。このモデルは軽量なため、曖昧な表現・複雑な文脈・専門用語が多い会話では抽出精度が落ちる。「確かに話したはずの情報が記憶されていない」という現象が起きる。

対策は 2 つある。一つは記憶してほしい情報をエージェントが明示的にまとめ文として生成し、それを抽出対象にする「サマリー先出し方式」だ。もう一つは長期記憶への書き込みを LLM 任せにせず、アプリケーションコードから memory.store() を直接呼び出す「プログラマティック書き込み」だ。重要な事実は後者で確実に記録し、自然な会話文からの自動抽出は補完的な役割に留めるのが安全だ。

詰まり 3: Gateway の dual auth 設定の複雑さ

Gateway の dual auth は「inbound auth（エージェントがゲートウェイへのアクセスを認証される側）」と「outbound auth（ゲートウェイが背後のサービスへ接続する側）」の 2 層からなる。この 2 層の概念を混同して設定すると、意図しない権限付与やエラーが発生する。

inbound は「誰がこのツールを呼べるか」、outbound は「このツールが何に接続できるか」と分けて考える。IAM ポリシー設計時も、エージェントの IAM ロール（inbound 側）とゲートウェイが使うサービスアカウント（outbound 側）を別リソースとして管理する。設定変更後は必ず両方向の疎通テストを実施する。

詰まり 4: Identity の権限スコープ管理とリフレッシュのタイミング

token vault に保管した資格情報はリフレッシュが必要なものがある（特に OAuth2 のアクセストークン）。リフレッシュのタイミングを誤ると、長時間実行タスクの途中で「認証エラーが突然発生する」事故になる。

AgentCore の token vault はリフレッシュを自動管理するが、スコープの設計が不適切だと機能しない。必要最小限のスコープを明示的に設定し、エージェントのユースケースに合わせたスコープ範囲を見直す。本番移行前に「8 時間の連続実行中にトークンが切れないか」のシナリオテストを実施すること。

詰まり 5: 実装コストが Bedrock Agents より高い

AgentCore は「フレームワーク非依存」を謳うが、エージェントロジック（ReAct ループ・エラーハンドリング・リトライ・タイムアウト制御）は自前で実装が必要だ。Bedrock Agents では AWS が担っていた部分を自分で書くことになる。

PoC から直接 AgentCore に移行しようとすると、「Bedrock Agents の 3 倍の実装工数がかかった」というケースがある。AgentCore の採用判断は「Bedrock Agents では実現できない要件が具体的に存在するか」を先に確認してから行うこと。プロトタイプは Bedrock Agents・本番カスタマイズ要件が出たタイミングで AgentCore へ移行する段階的アプローチが現実的だ。

詰まり 6: A2A プロトコルでのデッドロック

マルチエージェント構成で A2A プロトコルを使う場合、エージェント間の循環呼び出しがデッドロックを引き起こすことがある。エージェント A がエージェント B を呼び、B が A を呼び返す設計はデッドロックの典型パターンだ。

設計段階でエージェント間の呼び出しグラフを有向非巡回グラフ（DAG）として管理し、循環がないことを確認する。加えて、各サブエージェント呼び出しには必ずタイムアウトを設定し、応答がなければエスカレーションまたは失敗として処理する設計にする。デッドロックは Observability のトレースで「呼び出し待ちで止まっているエージェント」として検出できる。

詰まり 7: Observability のトレースコスト

Observability はエージェントの推論プロセス・ツール呼び出し・エラーを全て CloudWatch に記録する。「とりあえず全部トレースを有効にして本番に投入した」結果、CloudWatch コストが予想の 10 倍になるケースがある。

トレースデータは詳細なほど有用だが、量が多い。本番ではエラー・パフォーマンス異常・特定のツール呼び出しなど「問題検出に必要なイベント」に絞る設計を最初から行う。サンプリング設定（例: 10 リクエストに 1 件のフルトレース・エラーは 100% 記録）で量をコントロールする。開発環境でのフルトレースは問題ないが、本番では段階的に粒度を上げる運用が安全だ。

詰まり 8（補足）: セッション ID 設計の見落とし

Runtime のセッション ID は、同じユーザーの複数のセッションを区別する鍵になる。セッション ID をランダム生成するだけでなく、「ユーザー ID + チャンネル + 日付」など意味のある構造にしておくと、Memory の参照・Observability でのフィルタリング・デバッグが格段に楽になる。設計初期に決めておかないと後から変えにくい部分なので、ID 設計は早めに固める。

詰まり 9（補足）: Gateway のツール数とコンテキスト長

Gateway で多数のツールを MCP として公開すると、エージェントへのツール定義の受け渡しがコンテキスト長を圧迫する。LLM が 100 個のツール定義を同時に受け取ると、関連するツールの選択精度が下がる。Gateway のツール検索（discoverability）機能を活用して、タスクに必要なツールのみをセッション開始時にフィルタリングして渡す設計にする。

8-2. アンチパターン → 正解パターン

アンチパターン 1: AgentCore を Bedrock Agents の置換として急いで移行する

NG: 現在動いている Bedrock Agents のワークロードを一括で AgentCore に移行しようとする。移行工数の見積もりを誤り、ロジックの再実装・テスト・本番検証で数ヶ月かかることがある。

OK: プロトタイプや定型業務の自動化は Bedrock Agents のままにする。「Bedrock Agents では表現できない複雑なオーケストレーション」「特定のフレームワーク必須」「細粒度のセッション制御が必要」という具体的な要件が出たタイミングで AgentCore を部分的に採用する。置換ではなく「共存・補完」が基本方針だ。

アンチパターン 2: Runtime 内にセッション状態をローカルファイルで保持する

NG: open('/tmp/session_state.json', 'w') のように Runtime の microVM 内にファイルを書いてセッション状態を保持しようとする。セッション終了時に microVM がサニタイズされ、データが消える。

OK: セッションをまたぐデータは AgentCore Memory か外部ストア（S3・DynamoDB）に書き出す。Runtime 内のローカルファイル書き込みは「そのセッション内でのみ使う一時データ」（処理中の中間ファイル等）に限定する。永続化が必要なものは必ず外部に出す設計を徹底する。

アンチパターン 3: Gateway を使わず既存 API をエージェントから直接呼び出す

NG: エージェントのコード内に requests.get(INTERNAL_API_URL, headers={"Authorization": "..."}) のように直接 API 呼び出しを埋め込む。認証情報がコードやプロンプトに露出し、ツールの管理も分散する。

OK: 既存 API は Gateway で MCP ツール化し、エージェントはツール名で呼び出す。ツールの定義・変更は Gateway 側で集中管理でき、エージェントのコードを変えずにバックエンドの変更が可能になる。dual auth で認証情報もコードから分離できる。

アンチパターン 4: 認証情報を環境変数やハードコードで管理する

NG: os.environ.get("THIRD_PARTY_SECRET") でサードパーティサービスの秘密情報を環境変数から取得し、エージェントコードで直接使う。ローテーションが手動・リークリスクが高い。

OK: Identity の token vault で秘密情報をセキュアに保管し、エージェントは vault 経由で取得する。リフレッシュが必要な資格情報（OAuth2 アクセストークン等）は token vault が自動更新する。コードには認証情報が残らず、ローテーションも vault で一元管理できる。

アンチパターン 5: Observability をオフにして本番運用する

NG: 「トレースのコストを節約したい」「どうせログを見ないから」という理由で Observability を無効にして本番運用する。障害発生時に「何が起きたかわからない」状態になり、デバッグに何日もかかることがある。

OK: 本番では必ず Observability を有効にする。コストを抑えたい場合はトレースのサンプリング率・ログレベル・保持期間を調整する。「エラーは 100% 記録・通常リクエストは 10% サンプリング」のような設定で、コストと可観測性のバランスを取る。推論プロセスの可視化は問題の早期発見に直結する。

アンチパターン 6（補足）: A2A での全エージェント待機

NG: マルチエージェント構成で全サブエージェントの完了を同期的に待ってから次のステップに進む設計。並列実行できるはずのタスクが直列になり、エンドツーエンドのレイテンシが増大する。

OK: 独立したサブタスクは A2A の非同期呼び出しで並列実行し、結果が揃った時点で集約する。依存関係のある処理だけ同期待ちにして、それ以外は非同期で並列化する。レイテンシ要件が厳しいユースケースでは、タスク分解時に並列化できる部分を意識的に設計する。

8-3. まとめ — AgentCore を選ぶべき状況と選ばない状況

Vol1 では Runtime・Memory・Gateway・Identity の 4 コンポーネントと、Observability・Code Interpreter・Browser の組込ツールを実戦設計の観点から解説した。

AgentCore を選ぶべき状況

• フレームワーク（LangGraph/Strands/CrewAI 等）を自分で選びたい
• 複雑なマルチエージェントオーケストレーションをコードで表現する必要がある
• セッションごとの厳密な分離・長時間実行（最大 8 時間）が本番要件として存在する
• 既存 API・Lambda を MCP ツールとして統一的に管理したい
• サードパーティサービスへの委譲アクセスを安全に管理する仕組みが必要

Bedrock Agents のままでよい状況

• PoC・プロトタイプ・定型業務の自動化で速さを優先する
• ReAct ループを自分で実装するリソースがない
• Knowledge Base + Action Group の組み合わせで要件を満たせる

選択の実際的な基準

「Bedrock Agents の制約（フレームワーク固定・フルマネージドの ReAct・設定ファースト）に当たったか」が判断の起点になる。制約に当たっていないなら AgentCore への移行は費用対効果が低い。制約に当たったタイミングで、AgentCore の該当コンポーネントだけを部分採用する段階的アプローチが現実的だ。

移行ロードマップの推奨ステップ

1. Bedrock Agents でプロトタイプを作り、要件を固める
2. 「Bedrock Agents では実現できない」具体的な要件を特定する
3. Runtime から段階的に導入（セッション分離・長時間実行が最初の動機になりやすい）
4. 必要に応じて Memory・Gateway・Identity を追加
5. Observability を本番最初から有効にして問題検出の仕組みを作る

AgentCore は「エージェントを作るツール」ではなく「エージェントを本番で動かすインフラ」だ。この区別を設計段階から意識することが、安定した本番運用の土台になる。

次のステップ

Vol2 では Runtime の詳細設計（セッションライフサイクル管理・A2A プロトコルの実装パターン・フレームワーク別の統合方法）をより実装に近い粒度で掘り下げる予定だ。また、Memory の長期記憶設計（ストア設計・抽出プロンプト最適化・コスト管理）と Gateway の詳細設定（OpenAPI 仕様からのツール生成・dual auth のトラブルシューティング）についても実戦事例を交えて解説する。

8-4. 本番投入前チェックリスト

AgentCore を初めて本番投入するチームに向けた、見落としやすいポイントのチェックリストだ。設計レビューで活用してほしい。

Runtime 設計チェック

• [ ] セッションをまたぐデータを外部ストア（Memory/S3/DynamoDB）に書き出す設計になっているか
• [ ] タスク完了後に明示的にセッションを終了する処理があるか
• [ ] 最大 8 時間を超えるタスクを非同期分割する設計になっているか
• [ ] セッション ID に意味のある構造（ユーザー ID ＋日付など）が含まれているか
• [ ] マルチエージェント構成の場合、エージェント間の呼び出しグラフが DAG になっているか（循環なし確認）

Memory 設計チェック

• [ ] 顧客/ユーザーごとにメモリストアを分けているか（混在リスク回避）
• [ ] 長期記憶に書き込む情報の判断基準が明確か（全会話 vs 重要事実のみ）
• [ ] 重要事実はプログラマティック書き込み（memory.store() 直接呼び出し）で確実に記録しているか

Gateway 設計チェック

• [ ] inbound auth と outbound auth の設定対象リソースを別管理しているか
• [ ] ツール数が多い場合、セッション開始時にタスク関連ツールだけをフィルタリングしているか
• [ ] ゲートウェイ設定変更後に両方向の疎通テストを実施しているか

Identity 設計チェック

• [ ] 環境変数やコードに秘密情報を直接書いていないか
• [ ] token vault のスコープが最小権限になっているか
• [ ] 8 時間連続実行中に認証が切れないことをシナリオテストで確認したか

Observability チェック

• [ ] 本番環境で Observability を有効にしているか
• [ ] エラーは 100% 記録・通常リクエストはサンプリング設定になっているか
• [ ] CloudWatch コストの月次予算を見積もり、アラートを設定しているか
• [ ] A2A 呼び出しのタイムアウト値が全エージェントに設定されているか

8-5. エラーハンドリングの基本パターン

AgentCore はマネージドサービスだが、エラーハンドリングはアプリケーション層で設計する必要がある。本番でよく遭遇するエラーパターンと対処方針を整理する。

セッションタイムアウト（8 時間上限）

長時間タスクが 8 時間を超えそうな場合、タスクをチェックポイント単位で分割し、各チェックポイントの完了状態を外部ストアに書き出す設計にする。再実行時は完了済みチェックポイントをスキップして再開できるようにする。

ツール呼び出しの一時エラー

Gateway 経由のツール呼び出しは外部サービスへの依存を持つため、一時的なエラーが発生する。指数バックオフ付きのリトライロジックをエージェントのツール呼び出し層に組み込む。リトライ上限に達した場合は、人間によるエスカレーションフローに接続する。

メモリ読み取りの空レスポンス

新規ユーザーや新しいメモリストアでは長期記憶が空になる。長期記憶が空の場合にデフォルト値や初期設定で動くフォールバック処理を必ず実装する。「記憶がない場合」を例外ではなく通常ケースとして設計することが重要だ。

A2A 呼び出しのタイムアウト

サブエージェントが応答しない場合（デッドロック・長時間処理）は、タイムアウト後にオーケストレーター側でキャンセル・代替処理・エラー返却のいずれかを選択できる設計にする。タイムアウト値はユースケースごとに適切な値を設定し、デフォルト値に依存しないこと。