9月12日、AWSが「Monitoring production agent lifecycle with AWS DevOps Agent and AgentCore Evaluations」と題した記事を公開した。この記事では、本番環境で稼働するマルチエージェントシステムを「品質」と「インフラ」の二層で継続的に監視する手法について詳しく紹介されている。
なぜ従来の監視ではエージェントを監視できないのか
マルチエージェントシステムの本番運用が広がる中、従来のインフラ監視が追いつかないケースが増えている。AWSがこの記事で指摘している問題は具体的だ。
- エージェントがFM（基盤モデル）を呼び出せず空のレスポンスを返しているが、500エラーは出ない。原因はIAMパーミッションの欠落だった
- スーパーバイザーエージェントのプロンプトの設計ミスにより、リクエストの20%が意図しない専門エージェントにルーティングされているが、インフラメトリクスはグリーンのまま
- ツール呼び出しは全て成功しているのに、3ステップ先のチェーンで例外が握りつぶされており、予約が完了しない
Amazon CloudWatchのメトリクスは「システムが正しく実行されたか」を教えてくれるが、「エージェントがユーザーの目標達成を助けられたか」は教えてくれない。この二つは全く別の問題だ。
二層監視アーキテクチャ：品質 × インフラ
AWSはこの問題に対して二つのツールを組み合わせた監視アーキテクチャを提示している。
Layer 1：AgentCore Evaluations（品質監視）
Amazon Bedrock AgentCore Evaluationsは、本番のエージェント対話を継続的にスコアリングするフレームワークだ。「LLM-as-a-Judge」手法を採用しており、13種類のLLMベース評価器と3種類の決定論的トラジェクトリマッチャー、合計16の評価器を内蔵している。
以下の表は元記事で取り上げられている評価項目の一部（全16項目から抜粋）だ：
| 評価項目 | 内容 | 評価レベル |
|---|---|---|
| Goal Success Rate | セッション全体でユーザー目標が達成されたか | セッション |
| Correctness | 回答の事実的正確性 | トレース |
| Coherence | 論理的一貫性（矛盾・論理飛躍の検出） | トレース |
| Faithfulness | 会話履歴との整合性 | トレース |
| Conciseness | 情報の伝達効率 | トレース |
残り11項目（LLMベース評価器8種＋決定論的マッチャー3種）については、公式ドキュメントで全容を確認できる。
スコアには「なぜその点数になったか」の説明が付与されるため、チームは判定の妥当性を検証できる。低スコアセッションが蓄積されるとパターン分析が走り、特定リクエスト種別でのツール選択ミスや、正確だが使いにくい形式での回答といった傾向を自動検出する。検出結果はプロンプト変更案やツール選択ロジックの改善提案という形で出力される。
Layer 2：AWS DevOps Agent（インフラ調査）
AWS DevOps Agentはインフラ障害の自律調査ツールだ。インシデント発生時に署名付きWebhook経由でエージェントへ通報すると、エージェントが自動でCloudWatchログを取得し、IAMポリシー・Bedrock呼び出しログ・オーケストレーショントレースを横断的に相関分析する。
「空のエージェントレスポンス」をIAMパーミッション欠落に紐付けたり、「タイムアウトスパイク」を特定リージョンでのBedrockスロットリングに結びつけたりと、手動のウォールームなしで根本原因分析と修復手順を提示する。
実証システム：4エージェントの航空予約システム
このアーキテクチャを実証するため、AWSはSwarmパターンで構成された航空予約システムを構築した。Swarmパターンとは、スーパーバイザーエージェントがタスクを動的に専門エージェントへルーティングする構成で、固定の実行グラフを持たない。固定のパイプライン型（Sequential）やDAG型とは異なり、次にどのエージェントが動くかをランタイムの判断で決定する点が特徴だ。これはAWSやOpenAIのエージェントフレームワークが採用する業界横断的な設計概念であり、AgentCore固有の用語ではない。
4つの専門エージェントの役割は以下のとおりだ：
- Supervisor Agent：リクエスト受付、サブタスク計画、適切なエージェントへのルーティング
- Flight Agent：フライト検索、乗り継ぎルート処理
- User Agent：ロイヤルティステータス、証明書、プロフィールデータの取得
- Reservation Agent：予約作成・変更・キャンセル、コミット前のバリデーション
次のようなリクエストを1回の会話ターンで処理することを想定している：
"Book me from Seattle to Boston on March 15th, then Boston to Miami on March 18th. Use my companion certificate for the second leg and make sure both flights comply with my company's travel policy. I'm Gold status so apply any eligible upgrades."
2区間の同時検索、ロイヤルティ証明書の適用可否判断、コーポレートポリシーチェック、アップグレード適用をシーケンシャルかつ並列に処理する必要がある。Swarmでは各エージェントが次に誰が動くべきかをランタイムの判断で決定するため、実行パスが毎回変わる。これが監視を難しくする根本原因だ。
監視データの流れ
システム構成はシンプルに集約されている。AWS Amplify上にホストされたReactフロントエンドが、AgentCore Identityを経由してAgentCoreランタイムへ接続する。監視データの起点はAgentCoreランタイム1か所であり、OpenTelemetry形式でトレースとメトリクスをCloudWatchへ送信する。AgentCore Evaluationsも同じランタイムトレースを参照してスコアリングし、評価結果もCloudWatchに集約される。これにより運用メトリクス・分散トレース・品質スコアが一元管理される。
ソースコードはCDKインフラ、評価ダッシュボード、AWS DevOps Agent連携を含む形でGitHubリポジトリに公開されている。
詳細はMonitoring production agent lifecycle with AWS DevOps Agent and AgentCore Evaluationsを参照していただきたい。
