AWSの営業・マーケティング・グローバルサービス運用チームは、世界各地のAWS営業担当者が使う本番マルチエージェントシステム向けに、Amazon Bedrock AgentCore Evaluationsを用いた継続的な評価基盤を構築しました。営業担当者はAmazon Quickに平易な英語で業務上の質問をし、管理職は同じシステムで週次業務レビュー（WBR）を行います。専門エージェントは担当区域ごとの売上・業績分析、顧客情報、分析データへのテキストからSQLへの変換によるアクセスを提供し、回答には各ユーザーの役職に応じたアクセス制御が適用されます。

公開前の評価では、システム監視が正常を示していたにもかかわらず、Customer Insights Agentの誤りが4件見つかりました。顧客の3か月間のサービス売上410.08ドルを「410.08百万ドル」と表記し、Sales Revenueを調整項目を除外した売上と誤って説明し、データにない年間経常収益を推定し、独自の計算結果を出典のある事実として提示しました。公開前テストでは、調整済みデータ、ツール、プロンプトの変更間に不整合があり、合格率が78％から38％に低下しました。チームによると、毎週のデータ更新やエージェント、プロンプト、コード、モデルの変更も品質リスクを生むため、リリース前と本番稼働中の両方で回答を確認する必要があります。

評価基盤はAgentCore Evaluationsに加え、安全性のためのAmazon Bedrock Guardrails、指標・アラーム・トレース用のAmazon CloudWatch、評価結果の保存に使うAmazon S3とAmazon Redshift、ダッシュボード用のAmazon Quick、独自評価器を動かすAWS Lambdaで構成されます。評価するのは安全性、品質、性能、コスト、運用管理の5領域です。チームは安全性をエージェントの立ち上げと継続運用の必須条件とし、投稿で最も詳しく説明している品質を、適切に確保するのが最も難しい領域としています。

9段階は、最初のコミットで品質を定義する段階から稼働中システムの改善までをつなぎます。段階名はFoundation、Experiment、Merge（CI）、Gate（CD）、Canary、Adversary、Drift、Pulse、Feedback Loopです。それぞれ、成功条件の定義、バージョン比較、性能後退の検出、本番運用の準備状況の評価、気づきにくい障害の発見、攻撃テスト、品質変化の監視、稼働状況の確認、改善の自動化を担います。評価対象は個別ツール、エンドツーエンドのサブエージェント、マルチエージェントの連携という3階層で、各階層に固有の正解データセット、評価器、次段階への昇格基準を設けます。

Foundation段階では、営業担当者と管理職にとっての業務成果を出発点に、しきい値とアラーム条件を備えた測定可能な評価指標を定めます。営業担当者向けの例は実体解決の精度とグラウンディング率、管理職向けの例は精度の合格率と回答範囲です。チームは安全方針、ツールとエージェントごとのp50・p90・p99レイテンシ目標、問い合わせ1件当たりのコスト予算、アラームと手順書に結び付けたサービス品質保証契約（SLA）も定義します。本番で起きた誤りを基に、指標の取り違え、期間の誤り、対象の誤り、完全な幻覚、通貨・単位記号の誤り、許可されていない計算という6種類の精度エラーを分類しました。全体の精度合格率を主要指標とし、関連性、忠実性、有用性、指示への準拠、ツール選択の精度も監視します。提供された記事本文は、組み込み評価器とカスタム評価器を紹介したところで終わっています。

AWSの営業・マーケティング・グローバルサービス運用チームは、世界各地のAWS営業担当者が使う本番マルチエージェントシステム向けに、Amazon Bedrock AgentCore Evaluationsを用いた継続的な評価基盤を構築しました。営業担当者はAmazon Quickに平易な英語で業務上の質問をし、管理職は同じシステムで週次業務レビュー（WBR）を行います。専門エージェントは担当区域ごとの売上・業績分析、顧客情報、分析データへのテキストからSQLへの変換によるアクセスを提供し、回答には各ユーザーの役職に応じたアクセス制御が適用されます。

公開前の評価では、システム監視が正常を示していたにもかかわらず、Customer Insights Agentの誤りが4件見つかりました。顧客の3か月間のサービス売上410.08ドルを「410.08百万ドル」と表記し、Sales Revenueを調整項目を除外した売上と誤って説明し、データにない年間経常収益を推定し、独自の計算結果を出典のある事実として提示しました。公開前テストでは、調整済みデータ、ツール、プロンプトの変更間に不整合があり、合格率が78％から38％に低下しました。チームによると、毎週のデータ更新やエージェント、プロンプト、コード、モデルの変更も品質リスクを生むため、リリース前と本番稼働中の両方で回答を確認する必要があります。

評価基盤はAgentCore Evaluationsに加え、安全性のためのAmazon Bedrock Guardrails、指標・アラーム・トレース用のAmazon CloudWatch、評価結果の保存に使うAmazon S3とAmazon Redshift、ダッシュボード用のAmazon Quick、独自評価器を動かすAWS Lambdaで構成されます。評価するのは安全性、品質、性能、コスト、運用管理の5領域です。チームは安全性をエージェントの立ち上げと継続運用の必須条件とし、投稿で最も詳しく説明している品質を、適切に確保するのが最も難しい領域としています。

9段階は、最初のコミットで品質を定義する段階から稼働中システムの改善までをつなぎます。段階名はFoundation、Experiment、Merge（CI）、Gate（CD）、Canary、Adversary、Drift、Pulse、Feedback Loopです。それぞれ、成功条件の定義、バージョン比較、性能後退の検出、本番運用の準備状況の評価、気づきにくい障害の発見、攻撃テスト、品質変化の監視、稼働状況の確認、改善の自動化を担います。評価対象は個別ツール、エンドツーエンドのサブエージェント、マルチエージェントの連携という3階層で、各階層に固有の正解データセット、評価器、次段階への昇格基準を設けます。

Foundation段階では、営業担当者と管理職にとっての業務成果を出発点に、しきい値とアラーム条件を備えた測定可能な評価指標を定めます。営業担当者向けの例は実体解決の精度とグラウンディング率、管理職向けの例は精度の合格率と回答範囲です。チームは安全方針、ツールとエージェントごとのp50・p90・p99レイテンシ目標、問い合わせ1件当たりのコスト予算、アラームと手順書に結び付けたサービス品質保証契約（SLA）も定義します。本番で起きた誤りを基に、指標の取り違え、期間の誤り、対象の誤り、完全な幻覚、通貨・単位記号の誤り、許可されていない計算という6種類の精度エラーを分類しました。全体の精度合格率を主要指標とし、関連性、忠実性、有用性、指示への準拠、ツール選択の精度も監視します。提供された記事本文は、組み込み評価器とカスタム評価器を紹介したところで終わっています。