10月17日、AWSが「Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、Amazon Bedrock AgentCoreを使ってAIエージェントを本番環境で継続的に評価するための9段階フレームワークについて詳しく紹介されている。
「デモは完璧、本番で静かに崩壊する」という問題
AIエージェントはバグが出ても静かに失敗する。従来のソフトウェアはエラーで止まるが、エージェントはもっともらしい文章で、しかし誤った答えを返し続ける。
AWSのSMGS（Sales, Marketing, and Global Services）オペレーションチームが開発した社内エージェントシステムでは、リリース前評価で実際にこんな事象が発覚した：
- ある顧客の3ヶ月の売上 $410.08 を「**$410.08 Million**（約590億円）」と報告した
- 「Sales Revenue」の数字を「Sales Revenue excluding Adjustments（調整後）」として表示した
- データソースに存在しない ARR（年間経常収益）の推計値 を提示した
- エージェント自身の計算結果を、ソースから引用した事実として提示した
従来の監視（レイテンシ・エラー率・稼働率）はすべてグリーンのままだった。「応答した」ことは検知できても、「答えが正しいか」は検知できない。 これがタイトルにある「監視の限界」の本質だ。エラーログにも、アラートにも、何も引っかからない。品質の劣化は完全に不可視のまま、エージェントは誤答を返し続ける。
さらに厄介なのは、この限界がコードの問題に留まらない点だ。データパイプラインが毎週更新されることで、コードを一切変更していなくても品質が劣化しうる。また、データ変更・ツール変更・プロンプト更新を同時にリリースするつもりが、タイミングがずれて不整合状態で動いた場合、あるプレプロダクションテストではパス率が 78%から38%に急落 した。従来の監視スタックでは、こうした「静かな崩壊」をいずれも検知できない。
9段階フレームワークの全体像
このチームが構築したのは、ファーストコミットから本番稼働後の継続改善まで、エージェントのライフサイクル全体をカバーする評価フレームワークだ。
なお、Amazon Bedrock AgentCoreは2025年に発表されたサービス群で、AIエージェントの構築・実行・管理に必要なインフラ（メモリ・ツール実行・評価・ゲートウェイ等）をマネージドで提供する。従来のAmazon BedrockがFMの呼び出しと基盤機能を担うのに対し、AgentCoreはその上でエージェントを「本番運用する」ことに特化した位置づけだ。本フレームワークはAgentCore Evaluationsを軸に、Amazon Bedrock Guardrails（安全性）、CloudWatch（メトリクス・アラート）、S3・Redshift（評価データ永続化）、Lambda（カスタム評価器）を組み合わせている。
9段階は「後付けで継ぎ接ぎしたツール群」ではなく、単一の評価サーフェス上の9つの観測点として設計されている。
| ステージ | 問い |
|---|---|
| 1. Foundation | 「良い状態」をどう定義するか？ |
| 2. Experiment | どのバージョンが優れているか？ |
| 3. Merge (CI) | 何か壊していないか？ |
| 4. Gate (CD) | 本番投入して安全か？ |
| 5. Canary | 静かに壊れていないか？ |
| 6. Adversary | 意図的に壊そうとされたら？ |
| 7. Drift | 本番で品質が漂流していないか？ |
| 8. Pulse | 今この瞬間、正しく動いているか？ |
| 9. Feedback Loop | 自動的に改善し続けられるか？ |
最も重要なステージ：Stage 1（品質の定義）
9段階の中で記事が最も力を入れて解説しているのが Stage 1「品質の定義」 だ。ツール選定より先に「何をもって成功とするか」を顧客視点で定義しなければ、後続のすべてのゲートが当て推量になる、と明言している。
このシステムでは、フィールドセールス担当者と経営リーダーという2つのペルソナで成功の定義が異なる：
- セールス担当者向け：顧客商談前に、正確かつ適切な粒度の情報をタイムリーに取得できること
- 経営リーダー向け：手動でレポートを準備せずにWBR（週次ビジネスレビュー）の入力を得られること
これをメトリクスに落とすと、精度は6種類の失敗タイプ（メトリクス取り違え、期間間違い、エンティティ混同、純粋な幻覚、単位・通貨の誤り、無断の計算）で定義される。品質以外に、安全性・レイテンシ（p50/p90/p99）・クエリあたりコスト・SLAも同一ステージで定義する。
CI/CDとの統合が核心：Stage 2〜4
Stage 2（Experiment） は、プロンプトのバージョン・モデルの選択・ツール構成などの変更案を比較評価するステージだ。ゴールデンセットに対して複数のバリアントを並走させ、品質・コスト・レイテンシの3軸で定量比較する。「感覚でプロンプトを選ぶ」ではなく、評価スコアで意思決定する仕組みをこの段階で確立する。
Stage 3（CIゲート） では、プルリクエストのたびにゴールデンセット（代表的なテストケース群）全体を実行し、精度が閾値を下回ればマージをブロックする。評価結果はPRコメントとして自動投稿される。
Stage 4（CDゲート） は、本番への昇格判断を自動化する。品質・安全性・コスト・レイテンシの4次元すべてが閾値を満たさなければデプロイされない。
本番稼働後も評価は続く：Stage 5〜8
Stage 5（Canary） は、本番トラフィックの一部を新バージョンに流しながら、実際のユーザークエリに対する品質を監視するステージだ。プレプロダクション環境では再現できなかったエッジケースを、実トラフィックの中で早期に検出することを目的とする。
Stage 6（Adversary） は、敵対的プロンプト（プロンプトインジェクション・誘導質問・境界条件を突くクエリなど）を意図的に投入し、安全性と堅牢性を検証するステージだ。Amazon Bedrock Guardrailsと組み合わせ、悪意ある入力に対するエージェントの挙動を本番投入前・投入後の両フェーズで継続確認する。
Stage 7（ドリフト検知） は、本番データが毎週更新されることを想定した継続評価だ。コードを変えていなくてもデータ変化で品質が漂流することを、週次の自動評価で検知する。
Stage 8（Pulse） は、「今この瞬間」の動作状態をリアルタイムに把握するための軽量ヘルスチェックだ。ゴールデンセット全体を定期実行するドリフト検知と異なり、少数の代表クエリを高頻度で実行し、CloudWatchアラートと連携して異常を即座に検出する。障害が「気づいたら数時間続いていた」という状況を防ぐことが目的だ。
Stage 9（フィードバックループ） では、本番でのユーザーフィードバックや評価結果を自動的に次のゴールデンセット更新・プロンプト改善サイクルに組み込む。
なぜ9段階が必要か
Stage 2〜8の詳細を並べると、「段階数が多すぎる」と感じるかもしれない。しかし各ステージは異なる問いに答えている。Experimentは「どのバージョンが優れているか」、Canaryは「実トラフィックで静かに壊れていないか」、Adversaryは「意図的に壊そうとされたら耐えられるか」、Pulseは「今この瞬間正常か」——これらは一つの評価ステップでは同時に答えられない。監視の限界（応答したことしか見えない）を補うには、ライフサイクル全体に観測点を分散させるしかない、というのがこのフレームワークの根本的な主張だ。
評価は3階層で行う
このフレームワークはエージェントレベルだけでなく、ツールレベル・エージェントレベル・マルチエージェントレベルの3階層で同時に適用される。エージェント単体の品質は、それが使うツールの品質に依存し、マルチエージェント構成ではさらに別の障害面が生まれる。各階層が独自のゴールデンセットと評価器を持ち、9段階を独立して通過する設計だ。
詳細はBuilding trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCoreを参照していただきたい。
