10月6日、AWSが「Evaluating multi-agent systems for explainability and helpfulness with Amazon Bedrock AgentCore」と題した記事を公開した。LLMが生成する「流暢な回答」と、エンタープライズが求める「信頼できる回答」は別物だ。エージェントが正しいツールを選んだか、ビジネス制約を守ったか、推論の根拠を示せているか——これらは従来のモデル評価指標では測れない。この記事では、Amazon Bedrock AgentCore Evaluationsを使ってその課題に正面から取り組む評価フレームワークの設計と実装が詳しく紹介されている。
マルチエージェント評価の何が難しいのか
Amazon Bedrock AgentCore Evaluationsは、開発・本番の両フェーズにわたってエージェントの品質を評価する「フルマネージドな評価基盤」として提供されている。ビルトイン評価器（helpfulness、task completion等）に加え、ドメイン固有のビジネスルールを組み込んだカスタム評価器も使える点が特徴だ。
なお、評価と並行して本番運用にはAmazon Bedrock Guardrails（コンテンツフィルタ、制限トピック検出、根拠検証などを提供）も組み合わせる構成が推奨されている。評価が「実行後の品質測定」であるのに対し、Guardrailsは「実行中の安全制約の強制」を担う。
ユースケース：リファレンス実装で使われる仮想企業AnyCompany Retail
記事では、リファレンス用途の仮想グローバル小売企業「AnyCompany Retail」を舞台にした実装例が示されている。同社は地域ごとの在庫偏在（一部地域では品切れ、別の地域では過剰在庫）という実務的な課題を抱えており、オーケストレーターエージェント＋4つの専門サブエージェントで構成されるマルチエージェントシステムを構築する。
構成は以下のとおり：
- オーケストレーターエージェント：プランナーのリクエストを受けてサブエージェントに委譲
- 最適化エージェント：MCP（Model Context Protocol）経由でAmazon API Gatewayに接続し、在庫配分の最適化判断を実行
- 流通エージェント：フルフィルメントセンター・店舗・EC間の在庫リバランスを推薦
- ルーティングエージェント：キャリア選択・配送ルートを推薦
- アナリティクスエージェント：サプライチェーンの診断的な質問に回答
実装にはStrands Agents SDKを使用し、各エージェントはAmazon Bedrock AgentCoreランタイム上で動作する。メモリ機能とオブザーバビリティも有効化されている。
3層評価フレームワーク：ここが本題
記事の核心は、3層構造の評価アプローチだ。
第1層：ビルトイン評価器（セットアップ不要）
全エージェントにHelpfulnessを共通ベースラインとして適用し、エージェントごとに主要な失敗モードをターゲットにした評価器を追加する。
| エージェント | ビルトイン評価器 |
|---|---|
| オーケストレーター | Helpfulness + Tool Selection Accuracy |
| 最適化・流通 | Helpfulness + Response Relevance |
| ルーティング | Helpfulness + Instruction Following |
| アナリティクス | Helpfulness + Faithfulness |
第2層：カスタム評価器（ビジネス妥当性の検証）
ドメイン固有のルールをコード化して検証する。たとえば：
- 制約充足評価器（最適化）：予算・在庫カバレッジ（需要量以上2倍以下）・倉庫容量制約を満たすか
- ルート実行可能性評価器（ルーティング）：配送期限・コスト・キャリアキャパシティ・地域制約を守るか
- SQLの正確性評価器（アナリティクス）：生成クエリがユーザーの意図と一致しているか
「回答が流暢かどうか」ではなく、「ビジネス的に正しい判断をしているか」を独立して測る設計になっている。
第3層：説明可能性評価器（透明性の独立測定）
ここが最もユニークな部分だ。説明可能性を単なる回答品質の添え物ではなく、独立した評価次元として扱う。6つの評価器を全エージェントにクロスカッティングで適用する：
| 評価器 | 対象 | チェック内容 |
|---|---|---|
| 意思決定根拠の品質 | 全エージェント | なぜその推薦をしたかを説明しているか |
| 証拠の帰属 | アナリティクス・流通・ルーティング | データフィールドやSQL結果を引用しているか |
| 制約の推論 | 最適化・ルーティング | どの制約が最終回答を規定したかを説明しているか |
| トレードオフの説明 | 最適化・流通・ルーティング | コスト・サービスレベル・在庫リスク間のトレードオフを説明しているか |
| ツール使用の説明可能性 | オーケストレーター | なぜそのサブエージェント/MCPツールを呼んだかを説明しているか |
| 前提条件の開示 | 全エージェント | データが不完全な場合に前提を明示しているか |
「正確だが説明できない回答」と「説明できるが間違った回答」を区別できる点が設計上の重要な意図だ。カスタム評価器を通過しつつ説明可能性評価に落ちれば、「判断ロジックではなく推論の言語化」を改善すべきというシグナルになる。
デプロイと実行
ソリューションはGitHubリポジトリからダウンロード可能で、Terraformによるワンステップデプロイに対応している：
cd terraform
cp terraform.tfvars.example terraform.tfvars
terraform init
terraform apply
テストクライアントはサブエージェントカテゴリごとに20クエリ（各5問）を実行し、セッションIDを出力する。評価は非同期で実行され、結果はS3上にMarkdownファイルとして保存される。
評価モードは2種類：オンデマンドモード（開発ベンチマーク・CIゲート向け）とオンラインモード（本番の継続的モニタリング向け）。オンラインモードでは同じカスタム評価器をサンプリングレート（例：本番トレースの1〜10%）付きで再利用でき、結果はAmazon CloudWatchのダッシュボードとアラームに流れる。
詳細はEvaluating multi-agent systems for explainability and helpfulness with Amazon Bedrock AgentCoreを参照していただきたい。
