Bedrock AgentCore本番運用Vol3｜可観測性・評価・コスト・ガバナンス

1. この記事について

Amazon Bedrock AgentCoreは2025年10月13日にGA（一般提供開始）となり、東京リージョン（ap-northeast-1）を含む9リージョンで利用可能です。AgentCore Vol1ではRuntime・Memory・Gateway・Identityの基盤構築を、Vol2ではStrands SDKとマルチエージェントのデプロイを解説しました。本記事Vol3は三部作の締めとして、「構築したエージェントを本番で安定的に運用し続ける」ための運用・ガバナンス層を体系的に解説します。

Vol1・Vol2でエージェントを構築してデプロイした後、次に直面するのが「いかに本番で維持・統制するか」という問いです。
エージェントはモデル単体とは異なり、ツール呼び出し・外部API連携・マルチホップ推論・Memory永続化といった複数のコンポーネントが協調して動作します。
コンポーネントが多いほど、障害の発生箇所も多岐にわたります。
この複雑さが運用設計を難しくし、体系的な可観測性・評価・コスト統制・ガバナンスの整備が不可欠となります。
AgentCoreはこれらを統合的に扱うプラットフォームを提供しており、本記事はその運用活用を体系的に示します。

エージェントシステムの本番運用は、モデル単体のLLMOps（生成AIアプリ汎用の評価・可観測性・コスト管理）とは異なる固有の課題を抱えます。Vol1・Vol2で構築したAgentCoreエージェントを本番に置くと、次の4つの課題が顕在化します。

① トレース・意思決定ログの複雑さ

マルチホップ推論では、モデル判断→ツール選択→API呼び出し→結果評価→次のステップ判断という一連の処理が連鎖します。
従来のモデル呼び出しログ（Model Invocation Logging）だけでは、エラーや性能劣化がどのステップで発生したかの特定が困難です。
たとえばエージェントが誤ったツールを呼び出したとき、それがプロンプト設計の問題なのか・ツール定義の問題なのか・推論モデルの問題なのかを区別できません。
OpenTelemetry互換のエージェント固有トレース基盤がなければ、本番問題の根本原因分析（RCA）に長い時間がかかります。

② マルチホップ実行でのコスト可視化困難

単一セッション内でのモデル呼び出し回数・ツール実行回数・Observabilityデータ量・Gatewayトラフィックが複合的に課金されます。
AgentCore特有の消費ベース課金（前払いなし・従量）ではinvocationあたりのコストが予測しにくく、iteration caps・timeout caps・token capsによるper-invocation制御なしでは想定外の課金リスクが高まります。
特にマルチエージェント構成ではエージェント間通信のコストが積み重なりやすく、コスト可視化の仕組みを早期に整備する必要があります。

③ Identity・Gatewayのアクセス制御維持

エージェントがユーザー代理（ユーザー認証情報でのツール呼び出し）または自律モード（システム権限での動作）で処理を行う場合、OAuthトークンのリフレッシュ・IAMスコープの最小化・GatewayのMCPツール認可設定を継続的にメンテナンスする必要があります。
トークンの有効期限切れや権限の過剰付与は、エージェントの予期しない動作停止や意図しないリソースアクセスに直結します。
Identityのライフサイクル管理は本番運用における実質的な負荷が高い領域です。

④ スケーリング・障害対応

AgentCore Runtimeは最大8時間の実行ウィンドウ・セッション分離・A2A（Agent-to-Agent）プロトコルによるマルチエージェント協調をサポートします。
本番では長時間セッションのスケールアウト設計・AgentCore Memory保持期間の管理・エージェントバージョン管理によるロールバック手順の整備が求められます。
モデルやエージェントロジックの更新時に問題が発生した場合、迅速にロールバックできる仕組みがないと本番障害が長期化します。

これら4つの課題は相互に関連しており、可観測性が不十分だとコスト問題の原因特定もできず、評価基盤がなければエージェント品質の劣化に気づけません。
また、Identity/Gatewayのガバナンスが不十分なまま本番運用を続けると、エージェントが意図しないリソースを操作するリスクを抱え続けます。
スケーリング設計を後回しにすれば、ユーザー数増加時に本番障害として表面化します。
本記事では各課題に対応する5つの運用領域を体系的に解説します。本記事の内容を最初から組み込むことで、本番投入後の手戻りを最小化できます。

1-1. 本記事のゴール

本記事を読むことで、AgentCoreエージェントの本番運用設計を5つの領域で実践できる状態を目指します。

• 可観測性の設計: AgentCore ObservabilityとOpenTelemetryを使い、トレース・スパン・メトリクスをCloudWatchへ送信する設定を実施します。CloudWatchダッシュボードで意思決定ログとパフォーマンスをリアルタイムに監視できる状態を構築します。
• 評価パイプラインの構築: AgentCore Evaluations（GA 2026-03）でタスク成功率・ツール呼び出し精度を測定し、オフライン評価と本番モニタリングの2層評価パイプラインを設計・運用できる状態を目指します。
• コスト上限の管理: per-invocation制御（iteration/timeout/token caps）でエージェント実行コストの上限を設定し、AWS BudgetsとCloudWatchでコストアラートを構成できる設計を習得します。
• Identityガバナンスの実装: AgentCore Identity・Gatewayの本番運用設計（最小権限・認可スコープ管理・監査証跡・VPC/PrivateLink）を実装し、継続的に維持できる体制を構築します。
• スケーリング設計の理解: Runtimeスケールアウト設計・Memory保持期間管理・エージェントバージョン管理によるロールバック手順を設計し、本番障害に備えられる状態を目指します。

本番エージェントシステムの運用設計では、可観測性を基盤とした「監視→評価→コスト統制→ガバナンス→スケーリング」の運用ループを確立することがゴールです。各領域は独立した機能ではなく、Observabilityのトレースデータが評価パイプラインのインプットになり、コスト統制の判断材料になるという連鎖で機能します。

1-2. 読者像

本記事の対象読者は次のいずれかに該当する方です。

• AgentCore構築済みの開発者・SRE: Vol1-2でエージェントを構築済みまたは構築中で、本番運用フェーズに移行しようとしている方。エージェントの監視・評価・コスト管理の具体的な実装方法と、Runtime・Memoryのスケーリング設計を求めています。
• アーキテクト・ガバナンス担当: エージェントシステムの権限管理・セキュリティポリシー・運用責務の分界を設計する方。AgentCore Identity/Gatewayのガバナンス設計とコンプライアンス対応を探しています。
• LLMOps経験者: 生成AIアプリ汎用のLLMOps Vol1の知見を持ち、AgentCore固有の運用要件との差分を理解したいエンジニア。

前提知識はPython・AWS CLI・IAMの基礎知識です。AgentCoreの構築知識はVol1・Vol2で補完できます。CloudWatchの基本操作（ダッシュボード・アラーム作成）を知っているとより理解が深まります。

1-3. AgentCore三部作の全体像とVol3の位置づけ

AgentCore三部作はAIエージェントシステムの「基盤構築→マルチエージェントデプロイ→本番運用・ガバナンス」を段階的に扱う構成です。各Volの主要コンポーネントと対象フェーズを整理します。

LLMOps Vol1との差別化: 生成AI LLMOps本番運用 Vol1はBedrockモデル全般を対象とした汎用LLMOps設計（プロンプトレイテンシ最適化・Model Evaluation・Guardrails・汎用コスト管理）を扱います。本記事はAgentCore固有のエージェント運用に特化しており、マルチホップ推論のOTELトレース・ツール呼び出し精度評価・per-invocationコスト制御・IdentityとGatewayのガバナンスを対象とします。両者の違いを一言で言うと、LLMOps Vol1は「Bedrockモデルをどう使うか」の運用設計、本記事は「AgentCoreエージェントをどう運用・統制するか」の設計です。AgentCoreエージェントの本番システムでは双方を組み合わせて適用する設計を推奨します。

AgentCore基盤構築シリーズを読む

1-4. 本番エージェント運用ループの設計思想

AgentCore本番運用の設計思想は「可観測性を起点とした運用ループ」です。単発の機能実装ではなく、次の5要素が循環する運用体制を構築することが目標です。

1. 観測する（Observability）: OTELトレース・Runtimeメトリクス・意思決定ログによりエージェントの状態を継続的に把握します。§2で詳解します。
2. 評価する（Evaluate）: Observabilityで収集したトレースデータをもとに、タスク成功率・ツール呼び出し精度・回帰を定量評価します。§3（AgentCore Evaluations）で詳解します。
3. 制御する（Cost Control）: per-invocation制御でコスト上限を設け、Observabilityのtoken usageメトリクスで継続監視します。§4で詳解します。
4. 保護する（Governance）: IdentityとGatewayのアクセス制御を維持し、エージェントの権限をスコープに合わせて最小化します。§5で詳解します。
5. 拡張する（Scale）: 運用データをもとにRuntimeをスケールアウトし、エージェントのバージョン管理でロールバックに備えます。§6で詳解します。

この運用ループは一度設定して終わりではありません。エージェントのモデル更新・ツール追加・ユーザー数増加のたびに見直し、各領域の設定を継続的に改善していく設計が本番運用の本質です。

AgentCore本番運用において、最もよくある失敗パターンは「構築は丁寧に行ったが、運用の仕組みを後回しにした」というものです。Observabilityなしで本番投入すると問題の特定に数時間かかり、per-invocation制御なしでは月末に予想外の請求が届き、評価パイプラインなしではエージェント品質の劣化に気づかないまま運用を続けることになります。本記事の設計を最初から組み込むことで、これらのリスクを早期に排除できます。

2. AgentCore本番運用の前提と運用層の全体設計

AgentCore Vol1・Vol2でエージェントの基盤構築とデプロイが完了したら、次のフェーズは「継続的な本番運用」です。本章では、AgentCoreエージェントを本番で安定稼働させるために整備すべき前提条件・必要AWSサービス・運用層の全体設計思想を整理します。§3以降の各専門領域（可観測性・評価・コスト統制・ガバナンス・スケーリング）へ入る前に、運用全体の設計地図をここで把握してください。

2-1. 本番運用に必要な前提条件とAWSサービス

GA状況とリージョン

AgentCore（2025年10月13日 GA）は東京リージョン（ap-northeast-1）を含む9リージョンで利用可能です。本番環境を構築する際は、対象ワークロードのデータ主権要件を確認し、適切なリージョンを選択してください。マルチリージョン構成が必要な場合は、各リージョンで独立したAgentCore Runtimeを構成し、ルーティングをアプリケーション層で制御する設計が現実的です。

必要なAWSサービス一覧

AgentCore本番運用に関与するAWSサービスを整理します。

IAMロール設計の2分類

本番AgentCoreシステムでは、最低2種類のIAMロールを分離して設計します。

• エージェント実行ロール: AgentCore Runtimeが引き受けるロールです。bedrock-agentcore:InvokeAgentRuntime・Gatewayのツール実行・CloudWatchへのメトリクス送信・Observabilityのspanインジェストに必要な権限を付与します。ツールアクセスはGateway経由に限定し、直接のデータベース接続や広権限S3アクセスは原則付与しません。

• オペレータロール: 開発者・SRE・運用担当が使用するロールです。AgentCoreの管理API（エージェント設定変更・エイリアス切り替え・評価ジョブ実行）に必要な権限を持ちますが、エージェントが操作するデータリソースへの直接アクセスは制限します。

import boto3
import json

agent_trust_policy = {
 "Version": "2012-10-17",
 "Statement": [
  {
"Effect": "Allow",
"Principal": {
 "Service": "bedrock-agentcore.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
 "StringEquals": {
  "aws:SourceAccount": "123456789012"
 }
}
  }
 ]
}

iam = boto3.client("iam", region_name="ap-northeast-1")

response = iam.create_role(
 RoleName="AgentCoreProductionExecutionRole",
 AssumeRolePolicyDocument=json.dumps(agent_trust_policy),
 Description="AgentCore本番エージェント実行ロール（最小権限）",
 Tags=[
  {"Key": "Environment", "Value": "production"},
  {"Key": "ManagedBy", "Value": "platform-team"}
 ]
)
print(f"エージェント実行ロールARN: {response['Role']['Arn']}")

Observability有効化を含む最小権限セットをロールに付与します。

aws iam put-role-policy \
  --role-name AgentCoreProductionExecutionRole \
  --policy-name AgentCoreMinimalPermissions \
  --policy-document '{
 "Version": "2012-10-17",
 "Statement": [
{
  "Effect": "Allow",
  "Action": [
 "bedrock-agentcore:InvokeAgentRuntime",
 "bedrock-agentcore:GetAgentRuntime",
 "logs:CreateLogGroup",
 "logs:CreateLogDelivery",
 "logs:PutLogEvents",
 "xray:PutTraceSegments",
 "xray:PutTelemetryRecords",
 "cloudwatch:PutMetricData"
  ],
  "Resource": "*"
}
 ]
  }'

2-2. 運用層の全体設計思想 — 5層モデル

本番AgentCore運用は「可観測性→評価→コスト統制→Identityガバナンス→スケーリング」の5層が相互に連携するモデルで設計します。これらは独立した機能ではなく、各層のデータとシグナルが隣接する層の判断材料として循環します。

5層モデルの整理

各層の連携関係を示します。§3の可観測性で収集したトレースデータは§4の評価パイプラインのインプットとなり、評価スコアは§5のコスト統制の最適化判断（不要ツール呼び出し削減）に使われます。§6のIdentityガバナンスはCloudTrailのAPIログを§3の可観測性ダッシュボードと統合して可視化します。§7のスケーリング・ロールバック判断は§3のエラー率メトリクスと§4のタスク成功率を組み合わせて行います。

設計の第一原則: 可観測性を先に整備する

可観測性なしで他の層を整備しても効果が半減します。エージェントの内部動作が見えない状態では、評価パイプラインのデバッグもコスト分析もできません。本番デプロイの前に§3のAgentCore Observabilityを有効化し、CloudWatchダッシュボードで基本メトリクスが取得できる状態を確認することを強く推奨します。

本番AgentCoreセッションの開始サンプル

運用5層が整備済みであることを前提に、本番AgentCoreセッションを開始する基本コードを示します。

import boto3

agentcore_runtime = boto3.client(
 "bedrock-agentcore-runtime",
 region_name="ap-northeast-1"
)

def invoke_production_agent(
 agent_runtime_id: str,
 session_id: str,
 user_input: str
) -> str:
 response = agentcore_runtime.invoke_agent_runtime(
  agentRuntimeId=agent_runtime_id,
  sessionId=session_id,
  payload={
"inputText": user_input,
"sessionAttributes": {
 "environment": "production",
 "observabilityEnabled": "true"
}
  }
 )
 return response.get("completion", {}).get("text", "")

result = invoke_production_agent(
 agent_runtime_id="my-production-agent",
 session_id="session-prod-001",
 user_input="月次レポートを生成してください"
)
print(f"エージェント応答: {result}")

2-3. 本番環境構築チェックリスト

本番投入前に以下の5項目を確認してください。各項目のセットアップ詳細は対応する章で解説します。

# 1. CloudWatchロググループの作成確認
aws logs describe-log-groups \
  --log-group-name-prefix "/aws/bedrock-agentcore" \
  --region ap-northeast-1 \
  --query 'logGroups[*].logGroupName'

# 2. AgentCore Observabilityの有効化確認
aws bedrock-agentcore get-agent-runtime \
  --agent-runtime-id my-production-agent \
  --region ap-northeast-1 \
  --query 'agentRuntimeConfiguration.observabilityConfiguration'

# 3. per-invocation capsの設定確認
aws bedrock-agentcore get-agent-runtime \
  --agent-runtime-id my-production-agent \
  --region ap-northeast-1 \
  --query 'agentRuntimeConfiguration.invocationConfiguration'

# 4. IAMポリシーの最小権限確認（Access Analyzerレポート）
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:access-analyzer:ap-northeast-1:123456789012:analyzer/production" \
  --filter '{"findingType": {"eq": ["ExcessivePermission"]}}' \
  --region ap-northeast-1

# 5. Memory保持ポリシーの確認
aws bedrock-agentcore get-agent-runtime \
  --agent-runtime-id my-production-agent \
  --region ap-northeast-1 \
  --query 'agentRuntimeConfiguration.memoryConfiguration'

2-4. LLMOps Vol1との責務分界

AgentCoreの本番運用設計を始める際に、生成AI LLMOps本番運用Vol1との責務分界を明確にすることが重要です。LLMOps Vol1はBedrockモデル全般（Claude・Titan等の推論コスト・応答品質・Guardrailsによるコンテンツフィルタ）を対象とした汎用LLMOps設計です。AgentCore Vol3（本記事）はエージェントが複数のツールを呼び出しながらタスクを自律的に遂行するという、モデル単体とは異なる実行モデルの運用に特化しています。

本番エージェントシステムでは両方を組み合わせる設計を推奨します。LLMOps Vol1がBedrockモデル層を守り、AgentCore Vol3がエージェント実行層を統制する二層構造です。AgentCore本番運用の前提整理と運用層設計の概要を把握したところで、§3以降で各層の具体的な実装を解説します。

3. エージェント可観測性 — AgentCore Observability

3-1. AgentCore Observabilityの概要とGA状況

AgentCore Observabilityは、AIエージェントのend-to-end実行を可視化する機能です。2025年10月13日のAgentCore GAと同時にリリースされ、東京リージョン（ap-northeast-1）を含む9リージョンで利用可能です。

AgentCore Observabilityの主な機能は次のとおりです。

• OpenTelemetry（OTEL）互換形式: エージェント実行のmetrics・spans・logsをOTEL標準形式でCloudWatchへ格納します。既存のOTEL対応監視スタックと統合できます。
• エンドツーエンドトレース: セッション開始からツール呼び出し・モデル推論・セッション終了までの全工程をトレースします。
• 意思決定ログ: エージェントが各ステップで何を判断したか（どのツールを選択したか・なぜそのパスに進んだか）を記録します。
• Runtimeメトリクス: 1分間隔のバッチ処理で実行活動・処理レイテンシ・リソース利用・エラー率を計測します。

モデル単体のModel Invocation Loggingとの違いを以下の表に整理します。

Observability有効化に必要なIAM権限

AgentCore Observabilityを利用するにはエージェントランタイムのIAMロールに以下の権限が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "logs:CreateLogGroup",
  "logs:CreateLogDelivery",
  "logs:PutLogEvents",
  "xray:PutTraceSegments",
  "xray:PutTelemetryRecords",
  "cloudwatch:PutMetricData"
],
"Resource": "*"
 }
  ]
}

機能別GA状況（2025-10時点）

3-2. OpenTelemetryトレースとスパン分析

AgentCore ObservabilityはOpenTelemetry SDK経由でエージェントの実行トレースを収集します。トレースデータはaws/spansロググループに格納され、CloudWatchのTrace Viewタブで視覚的に分析できます。

トレースインデックスの仕組み

AgentCoreは取得したトレースの1%を無コストで自動インデックスします。インデックス率はObservability設定で調整可能です（インデックス率を上げるとCloudWatch X-Rayのコストが増加するためバランスに注意してください）。

Pythonによるカスタムスパンの追加

AgentCoreが自動生成するトレースに加え、アプリケーション固有のスパンを追加して詳細なトレースを構築できます。

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

tracer_provider = TracerProvider()
otlp_exporter = OTLPSpanExporter(
 endpoint="https://xray.ap-northeast-1.amazonaws.com/v1/traces"
)
tracer_provider.add_span_processor(BatchSpanProcessor(otlp_exporter))
trace.set_tracer_provider(tracer_provider)

tracer = trace.get_tracer("agentcore-production-agent")

def invoke_agent_with_tracing(session_id: str, user_input: str) -> str:
 with tracer.start_as_current_span("agent-session") as span:
  span.set_attribute("agent.session_id", session_id)
  span.set_attribute("agent.input_length", len(user_input))

  with tracer.start_as_current_span("agent-tool-selection") as tool_span:
tool_span.set_attribute("agent.step", "tool_selection")
selected_tool = select_tool(user_input)
tool_span.set_attribute("agent.selected_tool", selected_tool)

  with tracer.start_as_current_span("agent-execution") as exec_span:
exec_span.set_attribute("agent.tool", selected_tool)
result = execute_tool(selected_tool, user_input)
exec_span.set_attribute("agent.success", True)

  return result

CLIでスパンを確認する

aws/spansロググループに格納されたスパンをCLIで照会する方法を示します。

# 直近1時間のエージェントスパンを取得
aws logs filter-log-events \
  --log-group-name "aws/spans" \
  --filter-pattern '{ $.resource.attributes."service.name" = "agentcore-runtime" }' \
  --start-time $(python3 -c "import time; print(int((time.time()-3600)*1000))") \
  --region ap-northeast-1 \
  --query 'events[*].message' \
  --output text | python3 -m json.tool | head -100

# X-Ray APIでトレースサマリーを取得
aws xray get-trace-summaries \
  --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -d "1 hour ago" +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --filter-expression 'service("agentcore-runtime")' \
  --region ap-northeast-1

3-3. Runtimeメトリクスと意思決定ログ

Runtimeメトリクスの種類

AgentCore ObservabilityはRuntimeの実行状態を1分間隔のバッチ処理でCloudWatchメトリクスとして収集します。

CloudWatchダッシュボードの構築

以下のCLIコマンドでAgentCore専用のCloudWatchダッシュボードを作成できます。

aws cloudwatch put-dashboard \
  --dashboard-name "AgentCore-Production-Overview" \
  --dashboard-body '{
 "widgets": [
{
  "type": "metric",
  "x": 0, "y": 0, "width": 12, "height": 6,
  "properties": {
 "title": "セッション数とエラー率",
 "metrics": [
["AWS/BedrockAgentCore/Runtime", "SessionCount",
 "AgentRuntimeName", "production-agent"],
["AWS/BedrockAgentCore/Runtime", "InvocationErrors",
 "AgentRuntimeName", "production-agent"]
 ],
 "period": 60,
 "stat": "Sum",
 "view": "timeSeries"
  }
},
{
  "type": "metric",
  "x": 12, "y": 0, "width": 12, "height": 6,
  "properties": {
 "title": "レイテンシとトークン使用量",
 "metrics": [
["AWS/BedrockAgentCore/Runtime", "InvocationLatency",
 "AgentRuntimeName", "production-agent"],
["AWS/BedrockAgentCore/Runtime", "TokenUsage",
 "AgentRuntimeName", "production-agent"]
 ],
 "period": 60,
 "stat": "Average",
 "view": "timeSeries"
  }
}
 ]
  }' \
  --region ap-northeast-1

意思決定ログの活用

AgentCore Observabilityの意思決定ログは、エージェントがマルチホップ実行の各ステップで「なぜそのツールを選んだか」「どのような推論パスを辿ったか」を記録します。CloudWatchのTrace Viewでビジュアル化することで、次のユースケースに対応できます。

• デバッグ: エージェントが想定外のツールを呼び出した原因をステップ単位で追跡します。
• 品質評価の補助: 意思決定ログをAgentCore Evaluations（GA 2026-03）のオフライン評価データとして活用します。
• コスト分析: マルチホップ実行の各ステップでのトークン消費量を確認し、不要なツール呼び出しを特定します。

Pythonでのメトリクス取得例

import boto3
from datetime import datetime, timedelta, timezone

cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-1')

def get_agent_metrics(agent_runtime_name: str, hours: int = 1) -> dict:
 end_time = datetime.now(timezone.utc)
 start_time = end_time - timedelta(hours=hours)

 metrics = {}
 for metric_name in ['SessionCount', 'InvocationLatency',
 'TokenUsage', 'InvocationErrors']:
  response = cloudwatch.get_metric_statistics(
Namespace='AWS/BedrockAgentCore/Runtime',
MetricName=metric_name,
Dimensions=[{
 'Name': 'AgentRuntimeName',
 'Value': agent_runtime_name
}],
StartTime=start_time,
EndTime=end_time,
Period=300,
Statistics=['Sum', 'Average', 'Maximum']
  )
  metrics[metric_name] = response['Datapoints']
 return metrics

metrics = get_agent_metrics('production-agent', hours=1)
for name, datapoints in metrics.items():
 if datapoints:
  latest = max(datapoints, key=lambda x: x['Timestamp'])
  print(f"{name}: Sum={latest.get('Sum', 0):.2f}, "
  f"Avg={latest.get('Average', 0):.2f}")

AgentCore Observabilityの詳細な構築手順（Runtime・Memoryのセットアップ・IAM設定）はAgentCore Vol1を参照してください。本記事はObservabilityの運用設計に特化します。

4. エージェント評価・品質保証

AgentCore Evaluations（2026年3月 GA）は、AIエージェント固有の品質評価フレームワークです。LLMの応答品質を測るモデル評価（LLMOps Vol1）とは評価軸が根本的に異なり、「エージェントがタスクを完遂したか」という実行品質に焦点を当てています。

4-1. モデル評価とエージェント評価の使い分け

モデル評価とエージェント評価は補完関係にあります。モデル評価はLLMの応答品質を単一ターン単位で測定し、モデル選択やプロンプト最適化に活用します。AgentCore Evaluationsはエージェントのタスク遂行品質をマルチステップ実行シーケンス単位で評価し、本番品質ゲートと回帰検知に活用します。

4-2. AgentCore固有の3つの評価指標

タスク成功率（Task Success Rate）

タスク成功率は、エージェントが与えられた目標タスクを最終的に完遂したかを測定します。「成功」の定義はユーザーが明示的に設定し、最終出力の内容・状態変化・外部APIの呼び出し結果などを基準に判定します。単純なLLM出力品質ではなく、エンドツーエンドのタスク完遂を評価する点がモデル評価との根本的な違いです。

複数ターンの会話や非同期ツール実行を含むタスクでは、最終状態だけでなく中間ステップの成否も集計します。タスク成功率が閾値（例：90%）を下回ると、自動的にアラートが発火し、問題のあったセッションのトレースが記録されます。

ツール呼び出し精度（Tool Call Accuracy）

ツール呼び出し精度は、エージェントが正しいツールを適切なパラメータ・タイミングで呼び出したかを評価します。AgentCore ToolsはGateway経由でMCPサーバーや外部APIと統合しており、ツール選択ミスはシステム全体の品質へ影響します。

評価では以下を測定します。

• ツール選択正解率：タスクに対して適切なツールを選択した割合
• パラメータ正解率：選択したツールに正しい引数を渡した割合
• 不要ツール呼び出し率：不必要なツール呼び出しが発生した割合（コスト・レイテンシに直結）

ツール呼び出し精度の低下は、プロンプト変更・モデルアップグレード・ツール仕様変更のいずれかが原因であることが多く、回帰検知の主要シグナルとなります。

マルチステップ推論の正確性（Multi-step Reasoning Accuracy）

マルチホップ実行では、各ステップの推論が後続のステップに連鎖します。マルチステップ推論の正確性は、実行シーケンス全体を通じて各ステップが適切な中間出力を生成したかを評価します。

たとえば「検索→フィルタリング→集計→レポート生成」の4ステップタスクでは、検索ステップの誤りが最終レポートを無効化します。ステップ単位の評価スコアを記録することで、どのステップで品質が劣化したかを特定できます。

4-3. 2層評価アーキテクチャ

AgentCore Evaluationsはオフライン評価と本番モニタリングの2層構造で品質を保証します。

オフライン評価（開発・テスト環境）

オフライン評価はリリース前の品質ゲートです。事前定義したテストケースセット（入力タスク・期待する中間ステップ・期待する最終出力）に対してエージェントを実行し、評価スコアを記録します。CI/CDパイプラインに組み込むことで、コード変更・プロンプト変更・モデルアップグレードのたびに自動評価を実施します。

オフライン評価では以下を実施します。

• ゴールデンテストセット：代表的なタスクパターン（ハッピーパス・エッジケース・失敗ケース）を網羅
• 品質閾値ゲート：タスク成功率≥90%・ツール呼び出し精度≥95%などの閾値でリリース可否を判定
• 評価スコアの時系列記録：バージョン間の品質変化を追跡

本番モニタリング（回帰検知）

本番モニタリングはライブトラフィックでの品質継続監視です。AgentCore Observabilityと連携し、本番エージェントの実行トレースからリアルタイムにメトリクスを収集します。統計的品質管理手法で異常を検知し、回帰の発生を早期に通知します。

回帰検知の主要シナリオを以下に示します。

• タスク成功率の急落：モデルアップデートの副作用
• ツール選択ミスの急増：ツール仕様変更との不整合
• 特定タスクパターンでの精度劣化：データ分布シフト

4-4. 評価パイプライン

評価パイプラインは5ステップで構成されます。テストケース定義→評価実行→スコア記録→閾値アラート→回帰通知の順に処理します。

1. テストケース定義：入力タスク・期待中間ステップ・期待最終出力を定義したJSONLファイルを作成します。
2. 評価実行：定義したテストケースに対してエージェントを実行し、実際の実行トレースを収集します。
3. スコア記録：タスク成功率・ツール呼び出し精度・推論精度を計算してCloudWatchメトリクスに記録します。
4. 閾値アラート：設定した品質閾値を下回った場合にCloudWatch Alarmが発火します。
5. 回帰通知：アラート発火時にSNS経由でSlack・メール等に通知し、問題のあったセッションのトレースリンクを共有します。

4-5. コード例：AgentCore評価ジョブの設定・実行

テストケース定義（JSONL形式）

import json

test_cases = [
 {
  "task_id": "task_001",
  "input": "Q3売上データを集計して上位3製品をレポートせよ",
  "expected_tools": ["query_database", "aggregate_data", "generate_report"],
  "expected_steps": 3,
  "success_criteria": {
"final_output_contains": ["上位3製品", "売上合計"],
"tool_sequence_match": True
  }
 },
 {
  "task_id": "task_002",
  "input": "在庫が10個以下の商品を特定してアラートメールを送れ",
  "expected_tools": ["query_inventory", "filter_items", "send_email"],
  "expected_steps": 3,
  "success_criteria": {
"email_sent": True,
"tool_sequence_match": True
  }
 }
]

with open("test_cases.jsonl", "w") as f:
 for case in test_cases:
  f.write(json.dumps(case, ensure_ascii=False) + "\n")

評価ジョブの作成と実行（Python SDK）

import boto3
import time

bedrock_agent = boto3.client("bedrock-agent", region_name="ap-northeast-1")

response = bedrock_agent.create_agent_evaluation_job(
 jobName="agent-quality-gate-v1",
 description="リリース前品質ゲート評価",
 agentAliasArn="arn:aws:bedrock:ap-northeast-1:123456789012:agent-alias/ABCDEFGHIJ/KLMNOPQRST",
 evaluationConfig={
  "automated": {
"datasetMetricConfigs": [
 {
  "taskType": "General",
  "dataset": {
"name": "agent-test-dataset",
"datasetLocation": {
 "s3": {"uri": "s3://my-bucket/test_cases.jsonl"}
}
  },
  "metricNames": [
"TaskSuccessRate",
"ToolCallAccuracy",
"ReasoningAccuracy"
  ]
 }
]
  }
 },
 outputDataConfig={"s3Uri": "s3://my-bucket/evaluation-results/"},
 roleArn="arn:aws:iam::123456789012:role/BedrockEvaluationRole"
)

job_id = response["jobIdentifier"]

while True:
 result = bedrock_agent.get_agent_evaluation_job(jobIdentifier=job_id)
 status = result["status"]
 if status == "Completed":
  break
 elif status == "Failed":
  raise RuntimeError(f"評価ジョブ失敗: {result.get('failureMessages')}")
 time.sleep(30)

summary = result["evaluationSummary"]
print(f"タスク成功率: {summary['taskSuccessRate']:.1%}")
print(f"ツール呼び出し精度: {summary['toolCallAccuracy']:.1%}")

評価スコアのCloudWatch記録

import boto3

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

cloudwatch.put_metric_data(
 Namespace="AgentCore/Quality",
 MetricData=[
  {
"MetricName": "TaskSuccessRate",
"Value": summary["taskSuccessRate"] * 100,
"Unit": "Percent"
  },
  {
"MetricName": "ToolCallAccuracy",
"Value": summary["toolCallAccuracy"] * 100,
"Unit": "Percent"
  }
 ]
)

AgentCore Evaluationsの詳細なセットアップとIAM設定は AgentCore Vol1 を、汎用LLMのモデル評価手法は LLMOps Vol1 を参照してください。

5. コスト統制

AgentCoreは消費ベース課金モデルを採用しており、前払いや固定費なしで利用量に応じて課金されます。マルチステップのエージェント実行では1回の処理が複数のLLM呼び出し・ツール呼び出し・データ処理を連鎖するため、適切な上限管理なしにコスト膨張のリスクが生じます。

なお、以下に示す料金例は例示値です。実際の料金は必ずAWS公式の料金ページで確認してください。

5-1. AgentCore課金体系

AgentCoreの課金は主要3コンポーネントで構成されます。

Observabilityコスト

エージェント実行の可観測性データの取込・保存・クエリ・PII（個人情報）マスキングに対して課金されます。

Observabilityコストはトレースインデックス率（デフォルト1%）とデータ保持期間の設定で大きく変動します。高頻度エージェントでは、インデックス率を上げすぎるとストレージ・クエリコストが急増するため、業務要件に応じた調整が必要です。

Identityコスト

AgentCore RuntimeおよびGateway経由でIdentity機能を使用する場合、追加コストは発生しません。Runtime・Gateway以外でIdentity機能を直接利用する場合は、OAuth tokenリクエスト数およびAPI keyリクエスト数に応じて課金されます。

Gatewayコスト

AgentCore GatewayはMCPサーバーや外部APIへのセキュアなエントリポイントです。以下のAPI呼び出しに応じて課金されます。

• ListTools：ツール一覧取得呼び出し
• InvokeTool：ツール実行呼び出し（最もコストに影響する項目）
• Search：ナレッジベース検索呼び出し
• ツールインデックス：登録ツール数に応じたインデックス保持コスト

5-2. per-invocation制御によるコスト上限管理

per-invocation制御はAgentCore固有のコスト爆発防止機構です。エージェントの1回の実行（invocation）に対して3種類のキャップを設定することで、異常なコストの膨張を防ぎます。

iterationキャップ

エージェントが1回の実行で実施できるLLM呼び出し・ツール呼び出しのイテレーション数の上限です。マルチステップタスクが無限ループ的に実行され続けるケースを防止します。業務タスクの標準的なステップ数を分析し、通常の2〜3倍を上限として設定することを推奨します。

timeoutキャップ

1回のエージェント実行の最大実行時間（秒）です。外部API呼び出しのタイムアウトや処理ループで発生する長時間実行を防ぎます。AgentCoreは最大8時間の実行ウィンドウをサポートしますが、業務タスクの想定処理時間に応じた適切な上限設定が重要です。

tokenキャップ

1回の実行全体で消費できるトークン数の上限です。LLM呼び出しのたびにinputトークン・outputトークンが消費されるため、マルチステップの長い会話履歴を伴うタスクでは特に重要です。

5-3. エージェント実行コストの可視化

CloudWatchメトリクスによる監視

AgentCore ObservabilityはRuntimeメトリクスをCloudWatchに1分間隔で送信します。コスト関連の主要メトリクスを以下に示します。

• TokensUsed：実行あたりのトークン消費量（モデル呼び出しコストに直結）
• ToolInvocationCount：ツール呼び出し回数（Gatewayコストに直結）
• SessionDuration：セッション継続時間
• ErrorRate：エラー率（エラーによる再試行コストを把握）

Cost Explorerタグ付け戦略

AgentCoreリソースに統一タグを付与することで、Cost ExplorerでエージェントごとのAWSコストを分離して把握できます。

推奨タグ構成を以下に示します。

• AgentName：エージェント識別子（例：customer-support-agent）
• Environment：環境区分（prod / staging / dev）
• BusinessUnit：コスト帰属部門
• CostCenter：コストセンターコード

5-4. コスト最適化とLLMOps Vol1との対比

エージェント実行コストの最適化は以下の観点で実施します。不要ツール呼び出しの削減は4章の評価パイプライン（ツール呼び出し精度指標）と連動させ、Observabilityデータ量はトレースインデックス率とデータ保持期間を業務要件に合わせて調整します。

汎用のBedrockコスト管理は LLMOps Vol1 を参照してください。

5-5. コード例：per-invocation制御とコストアラートの設定

per-invocation capsの設定（Python SDK）

import boto3

bedrock_agent = boto3.client("bedrock-agent", region_name="ap-northeast-1")

response = bedrock_agent.update_agent_alias(
 agentId="ABCDEFGHIJ",
 agentAliasId="KLMNOPQRST",
 agentAliasName="prod-v1",
 routingConfiguration=[{"agentVersion": "1"}],
 agentAliasInvocationConfiguration={
  "invocationConfiguration": {
"maxIterations": 15, # iterationキャップ: 最大15イテレーション
"timeoutInSeconds": 300,# timeoutキャップ: 5分
"maxTokens": 100000  # tokenキャップ: 10万トークン
  }
 }
)
print("per-invocation制御を設定しました")

CloudWatchコストアラームの作成（Python SDK）

import boto3

cloudwatch = boto3.client("cloudwatch", region_name="ap-northeast-1")

cloudwatch.put_metric_alarm(
 AlarmName="AgentCore-HighTokenUsage",
 AlarmDescription="エージェント実行のトークン消費量が閾値超過",
 MetricName="TokensUsed",
 Namespace="AWS/Bedrock",
 Statistic="Sum",
 Period=3600,
 EvaluationPeriods=1,
 Threshold=5000000,
 ComparisonOperator="GreaterThanThreshold",
 Dimensions=[{"Name": "AgentId", "Value": "ABCDEFGHIJ"}],
 AlarmActions=["arn:aws:sns:ap-northeast-1:123456789012:cost-alert-topic"],
 TreatMissingData="notBreaching"
)

cloudwatch.put_metric_alarm(
 AlarmName="AgentCore-HighToolInvocationCount",
 AlarmDescription="ツール呼び出し回数が異常に高い（不要呼び出しの可能性）",
 MetricName="ToolInvocationCount",
 Namespace="AWS/BedrockAgentCore",
 Statistic="Sum",
 Period=3600,
 EvaluationPeriods=1,
 Threshold=10000,
 ComparisonOperator="GreaterThanThreshold",
 AlarmActions=["arn:aws:sns:ap-northeast-1:123456789012:cost-alert-topic"]
)
print("コストアラームを設定しました")

AWS Budgets連携（CLI）

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
 "BudgetName": "AgentCore-Monthly",
 "BudgetType": "COST",
 "TimeUnit": "MONTHLY",
 "BudgetLimit": {"Amount": "1000", "Unit": "USD"},
 "CostFilters": {"Service": ["Amazon Bedrock"]},
 "CostTypes": {
"IncludeTax": true,
"IncludeSubscription": true,
"UseBlended": false
 }
  }' \
  --notifications-with-subscribers '[
 {
"Notification": {
  "NotificationType": "ACTUAL",
  "ComparisonOperator": "GREATER_THAN",
  "Threshold": 80,
  "ThresholdType": "PERCENTAGE"
},
"Subscribers": [
  {"SubscriptionType": "EMAIL", "Address": "ops-team@example.com"}
]
 }
  ]'

6. セキュリティ・Identityガバナンス

AgentCoreエージェントは、外部サービスへの委任アクセスや自律的なツール呼び出しを伴うため、従来のサービス間通信とは異なるセキュリティ・ガバナンス設計が必要です。エージェントがユーザー代理（ユーザー認証情報での動作）または自律モード（システム権限での動作）で処理を行う場合、OAuthトークンのライフサイクル管理・IAMスコープの最小化・GatewayのMCPツール認可設定を継続的にメンテナンスする必要があります。本章ではAgentCore Identity（認証・委任アクセス管理、GA 2025-10）とAgentCore Gateway（ツール統合ハブ、GA 2025-10）を組み合わせた本番運用ガバナンス設計を解説します。

6-1. AgentCore Identity本番運用

AgentCore Identityは、エージェントがユーザーの代理としてOAuthで保護された外部サービスへ安全にアクセスするための基盤です。refresh token vault storageにより、エージェントはOAuthトークンを安全に保管・自動更新し、ユーザーが毎回認証しなくても継続的に外部サービスを利用できます。

identity-aware authorizationの主要機能

• refresh token vault storage: OAuthトークンをAgentCore Identityが暗号化保管し自動更新します。トークンの有効期限切れによる実行中断を防止できます。
• OAuth統合: Google DriveやSlack等の外部サービスへのアクセスをエージェントが委任受領し、ユーザーの再認証なしに継続アクセスを実現します。
• identity-aware authorization: エージェントIDに基づく認可制御です。どのエージェントがどのユーザーの代理でアクセスしているかを細粒度で管理します。

AgentCore Identity基盤の構築（OAuth2 Credential Providerのセットアップ・IAMロール設計）はAgentCore Vol1を参照してください。本章は本番運用・ガバナンス設計に特化します。

OAuth2 Credential Providerの作成と設定確認

import boto3

agentcore_client = boto3.client("bedrock-agentcore", region_name="ap-northeast-1")

# OAuth2 Credential Providerの作成
response = agentcore_client.create_oauth2_credential_provider(
 name="google-drive-provider",
 oAuth2ProviderConfigInput={
  "googleConfig": {
"clientId": "your-google-client-id",
"clientSecretArn": (
 "arn:aws:secretsmanager:ap-northeast-1"
 ":123456789012:secret:google-oauth-secret"
)
  }
 }
)
credential_provider_arn = response["credentialProviderArn"]
print(f"Credential Provider ARN: {credential_provider_arn}")

Identity設定を含むエージェント定義を更新し、設定を確認します。

# エージェントのIdentity設定を有効化
agentcore_client.update_agent_runtime(
 agentRuntimeId="my-production-agent",
 agentRuntimeConfiguration={
  "identityConfiguration": {
"enabled": True,
"credentialProviderArns": [credential_provider_arn]
  }
 }
)

# 設定確認
runtime_info = agentcore_client.get_agent_runtime(
 agentRuntimeId="my-production-agent"
)
identity_config = (
 runtime_info
 .get("agentRuntimeConfiguration", {})
 .get("identityConfiguration", {})
)
print(f"Identity有効: {identity_config.get('enabled', False)}")
print(f"Credential providers: {identity_config.get('credentialProviderArns', [])}")

6-2. AgentCore Gatewayによる統合アクセス制御

AgentCore Gateway（GA 2025-10）は、MCPサーバー・REST API・Lambda関数を単一のセキュアなエンドポイントに統合するツールハブです。エージェントはGatewayを介して外部ツールを呼び出すことで、各ツールへの個別認証管理が不要になります。

GatewayのAPIオペレーション

• ListTools: 利用可能なツール一覧を取得します。エージェントが実行計画を立てる際に参照するAPIです。
• InvokeTool: 指定したツールを実行します。Lambda関数・REST API・MCPツールが統一インターフェースで呼び出せます。
• Search: ツールをセマンティック検索します。多数のツールが登録された環境で適切なツールを自動選択できます。

Lambda関数のGatewayツール登録（CLI）

# Lambda関数をGatewayツールとして登録
aws bedrock-agentcore create-gateway-target \
  --gateway-id "my-production-gateway" \
  --name "get-customer-data" \
  --description "顧客データベースから情報を取得するツール" \
  --target '{
 "lambda": {
"functionArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:GetCustomerData",
"authorizationType": "IAM"
 }
  }' \
  --authorization '{
 "type": "IAM_AND_OAUTH",
 "oauthScopes": ["customer:read"]
  }'

IAM認証とOAuth認可を組み合わせることで、ネットワーク層（IAM）とアプリケーション層（OAuthスコープ）の二段階でツール呼び出しを制御できます。単一のGatewayエンドポイントがすべてのツール認証を集約するため、エージェントごとに認証設定を個別管理する複雑さが解消されます。

Gatewayに登録されたツール一覧を確認（Python）

import boto3

agentcore_client = boto3.client("bedrock-agentcore", region_name="ap-northeast-1")

# Gatewayに登録されたツール一覧を取得
response = agentcore_client.list_gateway_targets(
 gatewayId="my-production-gateway"
)

for target in response.get("targets", []):
 auth_type = target.get("authorization", {}).get("type", "未設定")
 print(f"ツール: {target['name']} / 認可タイプ: {auth_type}")

6-3. 最小権限IAMポリシー設計

エージェントへのIAMポリシーは、タスクに必要な最小限のアクションとリソースのみを許可する最小権限原則が基本です。開発時に利用した広権限ポリシーを本番環境で継続使用することは重大なリスクです。

import json

# エージェント用最小権限IAMポリシーのサンプル
least_privilege_policy = {
 "Version": "2012-10-17",
 "Statement": [
  {
"Effect": "Allow",
"Action": [
 "bedrock-agentcore:InvokeAgentRuntime",
 "bedrock-agentcore:GetAgentRuntime"
],
"Resource": (
 "arn:aws:bedrock-agentcore:ap-northeast-1"
 ":123456789012:runtime/my-production-agent"
)
  },
  {
"Effect": "Allow",
"Action": ["lambda:InvokeFunction"],
"Resource": [
 "arn:aws:lambda:ap-northeast-1:123456789012:function:GetCustomerData",
 "arn:aws:lambda:ap-northeast-1:123456789012:function:UpdateOrderStatus"
]
  },
  {
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::my-agent-data-bucket/inputs/*"
  }
 ]
}

print(json.dumps(least_privilege_policy, indent=2, ensure_ascii=False))

IAMポリシーはツール別・エージェントロール別に分離し、各ポリシーの影響範囲を限定してください。IAM Access Analyzerを定期実行して未使用の権限を特定し、削除するプロセスを運用ルーティンに組み込むことを推奨します。四半期ごとの権限棚卸しを運用プロセスとして確立してください。

# IAM Access Analyzerで未使用の権限を検出
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:access-analyzer:ap-northeast-1:123456789012:analyzer/AgentCore-Analyzer" \
  --filter '{"findingType": {"eq": ["UnusedIAMRole", "UnusedPermission"]}}' \
  --query 'findings[*].[id,status,resource]' \
  --output table

6-4. CloudTrailによる監査証跡

AgentCore Identity・Gatewayのアクセスログは自動的にAWS CloudTrailに記録されます。どのエージェントが・いつ・どのユーザーの代理として・どのツールを呼び出したかを追跡できます。

# CloudTrailでAgentCore Gatewayの呼び出し履歴を確認
aws cloudtrail lookup-events \
  --lookup-attributes \
 AttributeKey=EventSource,AttributeValue=bedrock-agentcore.amazonaws.com \
  --start-time "2025-10-01T00:00:00Z" \
  --end-time "2025-10-01T23:59:59Z" \
  --query 'Events[?EventName==`InvokeTool`].[EventTime,Username,Resources]' \
  --output table

CloudTrail Insightsを有効化すると、通常と異なるAPIコールパターン（例：短時間での大量InvokeTool実行）を自動検知し、異常アクセスのアラームを受け取れます。

import boto3

cloudtrail = boto3.client("cloudtrail", region_name="ap-northeast-1")

# エージェントのツール呼び出し履歴を取得
response = cloudtrail.lookup_events(
 LookupAttributes=[
  {
"AttributeKey": "EventSource",
"AttributeValue": "bedrock-agentcore.amazonaws.com"
  }
 ],
 MaxResults=50
)

for event in response.get("Events", []):
 event_name = event.get("EventName", "unknown")
 event_time = event.get("EventTime", "unknown")
 username = event.get("Username", "unknown")
 print(f"{event_time} - {event_name} by {username}")

CloudTrailのログはS3へアーカイブし、Athenaでクエリ分析することで、エージェントの行動ログ・ツール使用履歴・認可リクエストを長期的に監査できます。コンプライアンス要件がある場合は、監査ログの保持期間をデータライフサイクルポリシーで明示的に管理してください。

6-5. VPC/PrivateLinkによるネットワーク分離

金融・医療など規制業界では、AgentCore APIとの通信をインターネット経由ではなくVPC内に閉じる必要があります。AgentCore（GA 2025-10）はVPC/PrivateLink対応を提供しており、明示的な設定でプライベート通信を実現できます。

# AgentCore用VPCエンドポイントの作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.ap-northeast-1.bedrock-agentcore \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-11111111 subnet-22222222 \
  --security-group-ids sg-33333333 \
  --private-dns-enabled

VPCエンドポイントを設定した後、エージェントが動作するEC2・ECS・Lambda等のリソースからのみAgentCore APIへのアクセスを許可するセキュリティグループを構成します。Ingressルールで承認されたVPC内リソース以外からのアクセスを遮断することで、多層防御設計を実現できます。

# VPCエンドポイント用セキュリティグループのIngressルール設定
aws ec2 authorize-security-group-ingress \
  --group-id sg-33333333 \
  --protocol tcp \
  --port 443 \
  --source-group sg-agent-resources

本番環境ではVPC/PrivateLink設定をCloudFormationまたはTerraformで管理し、構成ドリフトをAWS Configで定期的に検知する体制を整えることを推奨します。VPCエンドポイントポリシーで特定のエージェントランタイムARNのみを許可するスコープ制限を加えることで、さらに細粒度のネットワークアクセス制御を実現できます。

7. スケーリング・運用設計と実戦統合

本章では、AgentCore上で構築したエージェントを本番環境でスケールさせる際の実装指針と、§2〜§6で解説した各機能を一気通貫で統合するシステム設計を整理します。構築フェーズ（AgentCore Vol1-2）で実装したエージェントを継続的に運用・改善するための運用ループを確立することが本章の目的です。

7-1. AgentCore Runtimeスケーリング

AgentCore Runtimeはサーバーレスアーキテクチャを採用しており、追加のインフラ管理なしにスケールします。本番運用における主要な設計ポイントを以下に整理します。

8時間実行ウィンドウとセッション分離

AgentCore Runtimeは1セッションあたり最大8時間の実行ウィンドウを提供します。長時間タスクは単一セッション内で完結させるか、チェックポイントを設けてセッションを分割する設計が必要です。per-invocationコスト上限（§4で設定）と組み合わせることで、暴走コストを防ぎながら安定稼働を実現できます。

import boto3

agentcore_client = boto3.client("bedrock-agentcore-runtime", region_name="ap-northeast-1")

# セッションタイムアウトとper-invocation制御を組み合わせた実行設定
response = agentcore_client.invoke_agent_runtime(
 agentRuntimeId="my-production-agent",
 sessionId="session-prod-001",
 payload={
  "inputText": "月次レポートを生成してください",
  "sessionAttributes": {
"maxIterations": "20",
"timeoutSeconds": "3600",
  }
 }
)

A2A（Agent-to-Agent）プロトコルによる役割分担

本番環境では、オーケストレーターエージェントとサブエージェントを分離することで、役割ごとの独立したスケーリングが可能になります。各エージェントは独立したRuntimeインスタンスとして動作し、AgentCore GatewayのA2Aプロトコルで相互通信します。マルチエージェント実装の詳細はAgentCore本番運用Vol2を参照してください。

resource tagging による運用管理

本番環境ではコスト配賦・アクセス制御・可観測性フィルタリングの粒度を細かくするために、リソースタグを設定します。

# AgentCore RuntimeにタグをCLIで設定（GA時追加機能）
aws bedrock-agentcore tag-resource \
  --resource-arn "arn:aws:bedrock-agentcore:ap-northeast-1:123456789012:runtime/my-production-agent" \
  --tags "Team=platform,Env=production,CostCenter=aiops"

7-2. AgentCore Memory運用

AgentCore Memoryのself-managed strategyを採用した場合、抽出・統合パイプラインの運用設計が重要になります。

self-managed strategy の保持期間とプライバシ設定

# Memory保持期間・プライバシ設定のサンプル
memory_config = {
 "memoryStrategy": "SELF_MANAGED",
 "retentionDays": 90,
 "privacyMode": "PII_REDACT",
 "extractionConfig": {
  "enableFactExtraction": True,
  "enablePreferenceExtraction": True
 }
}

agentcore_client.update_agent_memory_configuration(
 agentRuntimeId="my-production-agent",
 memoryConfiguration=memory_config
)

self-managed strategyでは、抽出ジョブが非同期で実行されます。本番運用では抽出失敗をCloudWatchアラームで検知し、パイプラインの異常を早期に把握する設計を推奨します。Memoryストレージはコストに直結するため（§4で設定したダッシュボードと合わせて）、不要なセッションメモリを定期的にパージするバッチジョブも組み込んでください。

7-3. 障害対応・ロールバック

エージェントバージョン管理と切り戻し

AgentCore Runtimeはエージェントのバージョニングをサポートしており、本番環境ではLATESTエイリアスと明示的バージョン番号の切り替えでロールバックを実現します。

# 安定バージョンへのエイリアス切り替え（CLIでのロールバック）
aws bedrock-agentcore update-agent-runtime-alias \
  --agent-runtime-id my-production-agent \
  --alias-name production \
  --routing-config '[{"agentRuntimeVersion":"3","routingWeight":1.0}]'

問題発生時の切り戻しフロー

本番でエージェントの品質劣化（§3の評価メトリクス悪化・§2のエラーレート上昇）を検知した場合は、次の手順で対処します。

1. AgentCore Observabilityでエラートレースを確認し、影響範囲を特定する
2. update-agent-runtime-aliasで安定バージョンに切り替える
3. §5（Identityガバナンス）のGatewayアクセスログで異常アクセスがないか確認する
4. CloudWatchアラームが正常範囲に戻ったことを確認後、問題バージョンの調査を開始する

7-4. 本番エージェントシステム全体運用設計 — Vol1-2との責務分担

AgentCore三部作の責務を明確化することで、本番運用の設計がシンプルになります。

「構築して終わり」ではなく、デプロイ後に次の継続的運用ループを確立することが重要です。

開発・実装（Vol1-2）
  → オフライン評価（AgentCore Evaluations §3）
  → デプロイ（AgentCore Vol2参照）
  → 本番モニタリング（Observability §2 / コスト §4 / ガバナンス §5）
  → 品質劣化・異常検知 → ロールバックまたは再開発
  → 改善して再デプロイ（ループ継続）

7-5. AgentCore Vol3 × LLMOps Vol1 — 責務分界表

AgentCoreエージェントの運用と汎用LLMOps（生成AI LLMOps本番運用Vol1）は重なる領域があります。どちらで対応すべきかを次の峻別表で整理します。

AgentCore Identity / Gateway / Runtime / Memory 固有の運用は本記事で完結します。Bedrockモデル全般の評価・運用はLLMOps Vol1に委ね、両者を組み合わせてエージェントシステムの完全な運用ループを実現してください。

7-6. Bedrock機能群との連携

AgentCoreエージェントはBedrock機能群と組み合わせることで、完全な本番システムを構成します。

特にBedrock本番運用Vol3のGuardrailsはAgentCoreエージェントが呼び出すモデルにも適用可能です。AgentCore Identity / Gatewayとの組み合わせにより、エージェントの出力とツール呼び出しの両面から統制を効かせる多層防御設計が実現できます。

7-7. マルチレイヤー統合設計と設定確認サンプル

本番エージェントシステムは複数のレイヤーが協調して動作します。

本番環境ではこれら5レイヤーを同時に稼働させ、CloudWatchダッシュボードで一元的に監視することを推奨します。以下は、可観測性・コスト上限・Identity設定の一括確認を行うサンプルスクリプトです。

import boto3

def verify_production_agent_config(agent_runtime_id: str, region: str = "ap-northeast-1"):
 """本番エージェントの可観測性・コスト・Identity設定を一括確認する"""
 client = boto3.client("bedrock-agentcore", region_name=region)

 runtime_info = client.get_agent_runtime(agentRuntimeId=agent_runtime_id)
 config = runtime_info.get("agentRuntimeConfiguration", {})

 observability = config.get("observabilityConfiguration", {})
 cost_control = config.get("invocationConfiguration", {})
 identity = config.get("identityConfiguration", {})

 print(f"=== {agent_runtime_id} 本番設定確認 ===")
 print(f"Observability有効: {observability.get('enabled', False)}")
 print(f"maxIterations: {cost_control.get('maxIterations', '未設定')}")
 print(f"timeoutSeconds: {cost_control.get('timeoutSeconds', '未設定')}")
 print(f"Identity有効: {identity.get('enabled', False)}")

 return config


if __name__ == "__main__":
 verify_production_agent_config("my-production-agent")

このスクリプトを定期実行することで、設定ドリフト（意図しない設定変更）を早期に検知できます。変更履歴はCloudTrailにも記録されるため、§5で設定した監査証跡と組み合わせることで変更追跡が可能です。設定確認の自動化はRunbookに組み込み、デプロイパイプラインのゲートとして活用することを推奨します。

8. つまずきポイント・アンチパターン・まとめ

8-1. つまずきポイント（7つ以上）

AgentCore本番運用では、構築フェーズでは表れなかった問題が運用を始めてから顕在化することが多いです。ここでは実際に詰まりやすいポイントを「症状 → 原因 → 対処」の形式でまとめます。

① Observabilityのトレースが1%しかインデックスされない

症状: AgentCore Observabilityを有効化してCloudWatchを確認したが、スパン・トレースデータがほとんど表示されません。大量のエージェントを実行しているにもかかわらず、ダッシュボードに反映されるトレースが極端に少ない状態です。

原因: AgentCore Observabilityのデフォルト設定では、トレースのインデックス率が1%に設定されています。これは「コスト0でまず試す」ための初期値であり、本番監視には不十分なケースがあります。

対処: traceSamplingRateパラメータを運用要件に合わせて調整してください。ただし、100%インデックスに設定するとspan ingestionコスト（$0.35/GB程度）が急増します。エラー率・レイテンシ異常のアラームを組み合わせた段階的な調整が推奨です。まず10%程度から始め、監視精度とコストのバランスを確認しながら引き上げていくアプローチが現実的です。

② per-invocation capsを設定していないエージェントが無限ループでコスト急増

症状: 本番デプロイ後、エージェントがツール呼び出しと推論を繰り返し続け、想定外のコストが発生しています。CloudWatchのtoken usageメトリクスが異常値を示し、1回の実行で数百回のステップが記録されています。

原因: maxIterations（最大反復回数）、maxExecutionTime（最大実行時間）、maxTokens（最大トークン数）のper-invocation capsが設定されていないため、エージェントが終了条件を見失って思考ループに陥っています。

対処: エージェント定義時にper-invocation制御を必ず設定してください。一般的な設定例として、maxIterations: 20、maxExecutionTime: 300（秒）、maxTokens: 50000程度から始め、タスク特性に合わせて調整します。AWS Budgetsでアラームを設定し、コスト異常を早期検知できる体制も併せて整えてください。

③ GatewayのListToolsでツール一覧が返らない

症状: MCPクライアントからAgentCore GatewayのListToolsエンドポイントを呼び出すと、空リストまたは認可エラーが返ります。Gatewayの管理コンソールではツールが登録されているように見えるが、エージェントから利用できません。

原因: 主に以下の2つが原因として多いです。(1) IAM権限不足：bedrock:InvokeAgent、bedrock:GetAgentAlias等の必要な権限が不足している。(2) Gatewayのツール設定ミス：ツールのLambda関数ARNや認可スコープの設定誤りです。

対処: IAMポリシーを精査し、AgentCore Gatewayの操作に必要な最小権限セットを付与してください。Gatewayのツール定義（スキーマ・Lambda ARN・認可設定）を再確認し、CloudTrailのAPIログから発生時点をトレースすることで、原因を特定しやすくなります。

④ AgentCore Evaluationsのタスク成功率が低くデバッグできない

症状: AgentCore Evaluations（2026年3月GA）でエージェントを評価すると、タスク成功率が低いスコアを示します。しかし、どのステップで失敗しているかが分からず改善できません。

原因: Trace Viewを活用していないことが多いです。AgentCore Observabilityが提供するTrace Viewでは、各ホップ（エージェントの各思考・ツール呼び出しステップ）の意思決定ログを詳細に確認できます。このビューを使わないと失敗箇所の特定が困難です。

対処: AgentCore ObservabilityのTrace Viewを有効化し、失敗した評価タスクの実行ログを確認してください。どのツール呼び出しが失敗したか、どのホップで誤った判断が行われたかをステップ単位で追跡できます。特定のツール呼び出しパターンでエラーが集中している場合は、プロンプトの改善またはツール定義の見直しが必要です。

⑤ Memory保持期間を設定せずPIIがメモリに残留する

症状: エージェントのMemoryに過去のユーザー会話が蓄積され続け、個人情報（PII）が長期間保存された状態になっています。GDPRやその他プライバシー規制の観点でコンプライアンスリスクが生じました。

原因: AgentCore Memoryの保持ポリシーが未設定の場合、会話履歴が無期限に保持されます。PII除去フィルタが設定されていないと、氏名・メールアドレス・決済情報などがメモリに残留します。

対処: Memory設定で保持期間ポリシー（例：30日）を設定し、PII除去フィルタを有効化してください。self-managed strategyを利用することで、抽出・統合パイプラインを自前で制御し、保持する情報の粒度をコントロールできます。コンプライアンス要件がある場合は、Memoryに保存する情報カテゴリを明示的に定義し、定期的な監査ログを取得する運用を推奨します。

⑥ Runtime 8時間制限でセッションが強制終了する

症状: 長時間かかるデータ処理タスクやワークフロー自動化エージェントが、8時間経過後にRuntimeで強制終了されます。処理途中のデータが失われ、最初からやり直しになっています。

原因: AgentCore Runtimeの実行ウィンドウは最大8時間です。これはAWSが設計した制約であり、設定変更はできません。長時間タスクをこの制約を考慮せずに設計すると、セッション切れによる処理中断が発生します。

対処: 長時間タスクはセッション分割設計が必須です。タスクを8時間以内で完結するチャンクへ分割し、各チャンクの完了状態をMemoryまたは外部ストレージ（S3・DynamoDB）へチェックポイントとして保存してください。中断後は保存済みのチェックポイントから再開する設計により、処理の冗長性を確保できます。A2A（Agent-to-Agent）プロトコルを活用した分散処理設計も有効な対策です。

⑦ AgentCore EvaluationsをモデルのLLMOps評価と混同する

症状: 既存のLLMOps評価パイプライン（BedrockモデルのRAG精度・回答品質評価）をAgentCore評価に流用しようとしたが、ツール呼び出し精度やマルチステップ推論の正確性が適切に測定できませんでした。

原因: モデル単体評価（プロンプト入力→回答出力の品質）と、エージェント評価（タスク達成率・ツール選択精度・マルチステップ推論の正確性）は根本的に異なる評価対象です。LLMOps Vol1のBedrockモデル評価機能はモデル出力の品質を測るものであり、エージェントのタスク遂行能力を評価する枠組みではありません。

対処: モデル評価にはBedrockモデル評価機能（LLMOps Vol1）を、エージェント評価にはAgentCore Evaluationsを使い分けてください。AgentCore Evaluationsはタスク成功率・ツール呼び出し精度・マルチホップ推論の正確性という、エージェント固有の指標で評価します。本番稼働後もこの評価を定期ジョブとして組み込み、エージェントの挙動変化を継続的にモニタリングすることが重要です。

⑧ VPC/PrivateLink未設定でパブリックエンドポイント経由の通信になる

症状: エージェントとAgentCore APIの通信経路を確認したところ、インターネット経由（パブリックエンドポイント）を経由していることが発覚しました。金融・医療など規制業界の要件でプライベート通信が必須だが、構成設定を見落としていました。

原因: AgentCore（GA時）はVPC/PrivateLink対応を提供していますが、明示的に設定しなければデフォルトはパブリックエンドポイントを使用します。

対処: VPCエンドポイント（PrivateLink）を設定し、AgentCore APIとの通信をVPC内に閉じてください。CloudFormationまたはTerraformでVPCエンドポイントリソースを定義し、エージェントが動作するサブネットからのみ疎通可能な構成を組んでください。セキュリティグループでIngressを制限することで、最小権限ネットワーク設計を実現できます。

8-2. アンチパターン → 正解（5つ以上）

AgentCore本番運用でよく見られるアンチパターンと、それに対応する正解パターンをまとめます。設計・実装フェーズのレビューに役立ててください。

アンチパターン1: 全スパンをインデックスしてObservabilityコストを増大させる

❌ アンチパターン: AgentCore Observabilityを有効化した直後に、トレースインデックス率を100%に設定する。「全部見えないと不安」という心理から全スパンをインデックスするが、span ingestionとデータ保存コストが大幅に増加します。

✅ 正解パターン: デフォルトの1%インデックス率でまず本番運用を開始してください。CloudWatchメトリクスのアラーム（エラー率・レイテンシ異常）を優先的に設定し、アラーム発生時にサンプリング率を一時的に引き上げる運用でコストを最適化できます。通常時は1〜10%で運用し、インシデント時のみ高サンプリングに切り替える段階的アプローチが推奨です。

アンチパターン2: per-invocation制御なしでエージェントを本番デプロイする

❌ アンチパターン: プロトタイプ段階で無制限設定のまま本番デプロイする。開発環境では意図したとおりに動いていたため、制限値の設定を「後回し」にしたまま本番稼働させます。

✅ 正解パターン: エージェント定義時にmaxIterations（反復上限）・maxExecutionTime（実行時間上限・秒）・maxTokens（トークン上限）を必ず設定してください。タスク特性に合わせた初期値を決め、本番モニタリングの結果を見ながら段階的に調整します。per-invocation capsの設定はコスト暴走防止の第一関門であり、省略は許容できないリスクです。

アンチパターン3: AgentCore Identity/Gatewayに広権限IAMポリシーを付与する

❌ アンチパターン: 開発スピードを優先して広権限IAMをエージェントに付与する。「後で絞る」と言いながら本番デプロイして放置します。

✅ 正解パターン: 最小権限原則に従い、エージェントが実際に必要とするツール・サービスへのアクセス権のみを付与してください。Gatewayのツール定義で認可スコープを細粒度に設定し、IAMポリシーをツール別・エージェントロール別に分けて管理します。定期的なIAM Access Analyzerによる権限見直しを運用プロセスに組み込むことで、権限の肥大化を防止できます。

アンチパターン4: エージェント評価をデプロイ前だけ実施する

❌ アンチパターン: リリース前にAgentCore Evaluationsを一度実行して合格したため、その後の継続評価を行わない。本番稼働中にモデルバージョンアップやツール仕様変更が発生しても気づかず、エージェントの品質劣化が進行します。

✅ 正解パターン: デプロイ前評価を通過したエージェントも、本番稼働後に定期評価ジョブを継続実行してください。モデルアップデート・ツール変更・プロンプト修正のたびに評価パイプラインを走らせ、タスク成功率・ツール呼び出し精度の回帰がないことを確認します。CI/CDパイプラインにAgentCore Evaluations実行ステップを組み込むことで、継続的品質保証を自動化できます。

アンチパターン5: Memory全履歴を無期限・無制限で保持する

❌ アンチパターン: ユーザー利便性のため「なるべく多くの記憶を残す」方針でMemory保持ポリシーを設定せず、会話履歴を全て無期限に保持する。PIIが含まれることを軽視し、保持期間・除去ポリシーを定義しません。

✅ 正解パターン: 保持期間ポリシー（例：30日・90日・1年）を明示的に設定し、PII除去フィルタを有効化してください。self-managed strategyによって抽出・統合パイプラインを自前で制御し、保持する情報の粒度と形式を管理します。コンプライアンス要件（GDPR・個人情報保護法等）に沿った保持方針を文書化し、定期的に監査する運用体制を整備してください。

アンチパターン6: エージェント実行コストをタグ管理なしで把握しようとする

❌ アンチパターン: 複数エージェントを本番稼働させているが、AWS Budgetsのコストアラームを1つ設定するのみで、どのエージェントがどのくらいのコストを発生させているか追跡できない。コスト超過が発生しても原因エージェントの特定に時間がかかります。

✅ 正解パターン: エージェントをデプロイする際にタグ（agent-name・environment・cost-center等）を設定し、AWS Cost Explorerでエージェント別のコスト追跡を可能にしてください。AWS Budgetsでエージェント別・タグ別のアラームを設定することで、コスト異常を早期検知できます。CloudWatchのtoken usageメトリクスとタグ情報を組み合わせた可視化ダッシュボードを構築すると、継続的なコスト最適化判断が容易になります。

8-3. まとめ

本記事ではBedrock AgentCore本番運用の5つの柱（可観測性・評価・コスト統制・Identityガバナンス・スケーリング）について解説しました。AgentCore三部作の最終章として、構築から運用への移行で直面する課題に対する具体的な設計指針を提示しました。

AgentCore三部作の全体像

本シリーズは以下の三部構成でエージェント開発・運用の全体像を網羅しています。

Vol1「基盤構築」では、AgentCore Runtime（エージェント実行エンジン）・Memory（会話記憶管理）・Gateway（ツール統合ハブ）・Identity（認証・認可）という4つのコアコンポーネントのセットアップと基本的な利用方法を解説しました。エージェントを動かすための土台となる知識が対象です。

Vol2「Strands SDK・マルチエージェント」では、Strands Agents SDK（Pythonファースト・OSS）を使ったエージェント実装、MCP（Model Context Protocol）によるツール統合、複数エージェントが協調するマルチエージェントアーキテクチャの構築・デプロイを扱いました。実際に動くエージェントを作るための実装ガイドです。

Vol3「本番運用・ガバナンス」（本記事）では、構築済みエージェントを本番で「安全に・安定して・コスト効率よく」運用し続けるための運用層の設計を解説しました。

本記事で確立した運用設計の柱

第1の柱: エージェント可観測性（AgentCore Observability）では、end-to-endのエージェント実行をCloudWatchとOpenTelemetry互換形式で可視化する方法を解説しました。トレース・スパン・意思決定ログの活用により、エージェントの内部動作を透明化できます。サンプリングレートとコストのバランスを保ちながら、本番監視に必要な視認性を確保することが重要です。

第2の柱: エージェント評価・品質保証（AgentCore Evaluations）では、エージェント固有の評価指標（タスク成功率・ツール呼び出し精度・マルチステップ推論の正確性）による継続的品質保証を解説しました。デプロイ前評価だけでなく、本番後の定期評価ジョブで回帰検知する二層評価設計が品質維持の鍵です。

第3の柱: コスト統制では、AgentCoreの消費ベース課金（Runtime・Gateway・Observability）の内訳を明確化し、per-invocation capsによるコスト上限管理、タグ戦略によるエージェント別コスト可視化、AWS Budgetsアラームによる異常検知の組み合わせを解説しました。コスト設計はエージェント設計と同時に行うことが不可欠です。

第4の柱: セキュリティ・Identityガバナンスでは、AgentCore IdentityによるOAuth統合・identity-aware authorization、Gatewayによるツール呼び出しの認可・スコープ制限、VPC/PrivateLinkによるネットワーク分離、監査証跡の取得を解説しました。エージェントがユーザー代理または自律で動作する際の権限設計は、従来のサービス間通信とは異なるガバナンス要件があります。最小権限原則を徹底し、IAM Access Analyzerによる定期見直しを運用に組み込むことが重要です。

第5の柱: スケーリング・運用設計では、Runtimeの8時間実行ウィンドウを踏まえたセッション分割設計、A2A（Agent-to-Agent）プロトコルを使った分散処理、Memoryの保持期間・プライバシーポリシー設計、障害時のロールバック手順を解説しました。

LLMOps Vol1との棲み分け

本シリーズと生成AI LLMOps本番運用Vol1は対象が異なります。LLMOps Vol1はBedrockモデル全般（Claude・Titan等）の本番運用に特化しており、モデル評価（ベンチマーク・人間評価・LLMジャッジ）・Observability（モデル呼び出しログ）・コスト最適化（プロビジョンドスループット・キャッシュ）・ガードレールを扱います。

一方、本記事（AgentCore Vol3）はエージェント固有の運用課題、すなわちエージェントがツールを使いながら複数ステップで自律的にタスクを遂行する際の運用・ガバナンスを扱います。両者は補完関係にあり、AgentCoreエージェントの本番運用では両方の知識が必要です。

次のステップ

AgentCore三部作を完読した方は、以下のステップでエージェントシステムの本番運用品質を高めることができます。まずAgentCore Observabilityを有効化し、CloudWatchダッシュボードで基本的な可視化を整備してください。次にper-invocation capsとAWS Budgetsアラームを設定し、コスト暴走防止の安全網を構築します。その後、AgentCore Evaluationsを使ったエージェント評価パイプラインをCI/CDに組み込み、継続的品質保証を自動化してください。最後に、IAM権限の定期レビューとMemory保持ポリシーを確立し、長期運用に耐えるガバナンス体制を整備します。

生成AIエージェントは、構築して動かすだけでなく、「安全に・安定して・コスト効率よく」長期運用できる体制を整えて初めて本番価値を発揮します。AgentCore三部作が、その基盤構築の一助となれば幸いです。

8-4. 関連記事（クロスリンク）

生成AI LLMOps本番運用Vol1を読む