AWSは営業向けマルチエージェントの運用を基に、開発から本番監視までを結ぶ9段階の評価手法を公開しました。応答の速さだけでは検知できない、数値や指標の誤りを扱います。 社内AIの品質管理では、データ、ツール、指示の更新をまとめて検証する体制が必要になります。正解が確定する項目と、判断を要する品質を分けた評価が焦点です。 応答が正常でも業務上の答えは誤り得る AWSは2026年10月16日、Amazon Bedrock AgentCoreを用いた継続的な品質評価の手法を紹介しました。基になったのは、社内営業向けの複数エージェントを運用する取り組みです。原文では、金額の単位を取り違えたり、資料にない数値を回答したりする問題を挙げています。遅延や稼働状況の監視は正常でも、内容の誤りは残っていました。そこで、品質の定義から実験、公開判断、本番監視、改善までを九つの段階で結んでいます。新しい汎用モデルの発表ではなく、既存のサービスを業務品質の管理へ組み込む設計例です。回答が生成されたかという監視と、業務に使えるかという検証の差を扱っています。 ツールと担当エージェントを別々に評価する 紹介された構成は、AgentCore Evaluationsを中心に、GuardrailsやCloudWatchなどを組み合わせます。対象は個々のツール、専門エージェント、複数エージェントの連携です。顧客名の同定や金額の一致など、正解が定まる項目には決定的な検査を用います。回答の有用性などには、モデルによる判定も使います。影響を受けるのは、営業支援、社内検索、自然言語でのデータ照会を提供する開発・運用部門です。最終回答だけを採点すると、途中の検索や引き継ぎで生じた不具合を見落とす可能性があります。業務の利用範囲に沿って評価用の事例を持ち、変更前後を比較する設計が示されています。データの更新だけでも品質が変わるため、コード公開時の検査だけでは十分でないという説明です。 評価の費用と公開を止める基準を決める 実務では、評価項目を増やす前に、重大な誤りの定義と公開を止める条件を決めることが論点になります。指標名、集計期間、対象顧客、通貨単位が一致しているかを、業務側と合意する必要があると見られます。モデルを使う採点は幅広い内容を扱えますが、その採点結果自体の妥当性も確認が必要です。費用には、評価用の推論、ログの保存、人手での正解確認が含まれます。本番の低評価事例を次の検証へ戻す際には、顧客情報の扱いとアクセス権限も論点になります。原文の九段階をそのまま導入するより、利用中の業務で起きる誤りを起点に優先順位を決める考え方が参考になります。データ、指示、ツールの更新担当が異なる組織では、公開時点の組み合わせを記録する運用も重要です。評価に使う正解資料の版と実行時のデータを対応付ければ、モデルの誤りと元データの変化を切り分ける材料になります。