Amazon AWS、StrandsとAgentCoreでエージェント評価を本番導入のゲートに

Amazon AWSとMotorwayは、誤ったエージェント結果の発生率を8件に1件から50件に1件へと引き下げる評価パイプラインを構築した。両社によれば、このシステムにより問題検知に要する時間も数時間から数分へ短縮された。

こうした改善は、基盤となるモデルを単純に置き換えた結果ではない。Motorwayは代わりに、ディーラー在庫検索エージェントのテスト、リリース、監視の方法を変えた。このパイプラインは、Strands Agents SDKとAmazon Bedrock AgentCore Evaluationsを組み合わせ、開発から本番までをカバーする。

この違いは重要だ。流暢な回答は、不適切なアクションを隠してしまうことがある。エージェントは誤ったツールを選択したり、不正確なパラメータを送信したり、以前の制約を見失ったりした後でも、もっともらしい車両リストを提示できる。従来のソフトウェアテストでは有効な回答をすべて捉えることは難しく、手動レビューでは障害の発見が遅すぎる。

Motorwayの事例は、エージェント評価を最終的な品質チェックから運用ループへと変えるものだ。Strandsはデプロイ前に制御されたシナリオをテストする。AgentCoreはデプロイ後、本番トレースのサンプルを採点する。そして失敗は次回リリースに向けた新たな回帰テストケースとなる。

この結果は、依然としてデモ、集計されたユーザー評価、あるいは少数のスクリプト化されたプロンプトでエージェントを判断しているチームに再考を迫る。またAWSにとっては、しばしば別の言語モデルに依存する評価に対して、購入者がどこまで信頼を置くべきかという、より難しい問いも投げかける。

Amazon AWS、評価をリリースパイプラインに組み込む

重要な変化は新しいスコアカードではない。評価が、エージェントを本番環境へ到達させるかどうかと、その後チームが回帰をどれだけ迅速に検知するかを左右するようになった。

Motorwayは、車両販売者とプロのディーラーをつなぐオンラインマーケットプレイスを運営している。同社のディーラー在庫検索エージェントは、車両属性、地域、走行距離、価格、その他の条件に関する自然言語のリクエストを処理する。

リクエストは成功したように見えても、運用上は誤っている場合がある。エージェントが誤った在庫ソースを検索したり、フィルターを省略したり、ツールに不正な形式の値を渡したりする可能性がある。その最終回答は、ユーザーも基本的なテキストチェックもすぐには気付かないほど、十分に整ったものになり得る。

MotorwayとAWSは、このギャップに3層の評価モデルで対応した。第1層はツール選択とパラメータを確認する。第2層は、回答に至る意思決定とツール呼び出しの連続であるエージェントの推論軌跡を検証する。第3層は、最終出力の品質とポリシー準拠を評価する。

この分離が重要なのは、許容可能な応答であっても、エージェントが安全かつ再現可能な経路をたどった証明にはならないためだ。偶然うまくいった回答は、悪い軌跡を覆い隠すことがある。反対に、エージェントが正しいツールを選んでも、最終回答が分かりにくい場合もある。

AWSによると、Motorwayのツール選択精度は87%から98%へ向上した。タスク完了率は82%から96%へ上昇し、複数ターンにわたるコンテキスト保持率も71%から94%へ改善した。

月間の本番インシデントは12件から2件へ減少した。平均検知時間は数時間から数分へ短縮された。AWSは、ディーラーが車両検索に数時間を費やす代わりに、数分で完了できるようになったとしている。

これらは独立した業界ベンチマークではなく、1つの導入事例について企業が報告した結果である。ただし、この測定値は、エージェントチームに単一の精度指標以上のものが必要な理由を示している。

このアーキテクチャでは、障害クラスごとに異なるしきい値を設定する。AWSは、その本番運用ブループリントで、ツール使用率95%以上、推論85%以上、出力品質90%以上を推奨している。

これらのゲートを下回るビルドは先へ進まない。これにより、評価は統合テストやセキュリティチェックに相当するリリース管理の一部となる。その後の本番監視では、承認された挙動が実際のユーザーとの接点に耐えられるかを検証する。

ここに本記事の中心的な緊張がある。エージェント評価は測定可能な信頼性を約束するが、最も有用な挙動が常に決定論的なアサーションで検証できるとは限らない。そのため、このパイプラインは厳密なチェックと確率的な判定器を組み合わせている。

エージェントの信頼性が本番チームに圧力をかける理由

エージェントチームは、生成テキストだけでなく意思決定とアクションにも責任を負うようになっており、従来のモデルテストだけでは不十分になっている。

チャットボットは通常、人が確認するための言語を返す。エージェントはレコードを取得し、業務システムを呼び出し、データを変更し、別のワークフローを起動できる。運用上のリスクは、不完全な一文から誤ったアクションへと移る。

この変化は、エンジニアリング責任者、プロダクトオーナー、企業の購入者に圧力をかける。彼らは、エージェントが適切なツールを選択し、有効なパラメータを指定し、以前の指示を尊重し、意図されたタスクを完了したかを知る必要がある。

単一の平均スコアでは、これらの問いには答えられない。2つのリリースは同じ出力品質評価を示していても、ツールの挙動は大きく異なる場合がある。一方は文言上の無害な失敗にとどまるかもしれないが、他方は古いレコードや無関係なレコードを取得する可能性がある。

非決定性が問題をさらに複雑にする。言語モデルは同じリクエストに対して異なる経路を生成し得る。一度テストに合格しても、エージェントが同じ結果を再現することの証明にはならない。

AWSは、この問題をpass^kという信頼性指標で取り上げている。これは、繰り返し試行してもタスクが成功するかを問うものだ。あるタスクの成功率が75%であれば、3回連続で成功する確率は約42%にすぎない。

この計算は、チームがデモをどう解釈すべきかを変える。成功したデモは、システムがタスクを完了できることを示す。しかし、本番利用に十分な一貫性で完了できることまでは示さない。

複数ターンの会話では課題がさらに大きくなる。ユーザーはまず電気自動車を求め、次に距離で結果を絞り込み、その後に最近掲載されたものだけを尋ねるかもしれない。エージェントは、ユーザーが取り下げた条件を持ち越さずに、関連するコンテキストを維持しなければならない。

Strands Evalsは、これを個別プロンプトの採点ではなくセッションの問題として扱う。その評価器は、出力、軌跡、個々のツール呼び出し、完全な会話を検査できる。同フレームワークの評価ガイドも、精度、タスク完了率、応答時間、ハルシネーション、トークン使用量、ユーザー満足度を追跡することを推奨している。

本番チームは組織面の圧力にも直面する。エージェントの失敗は、アプリケーション、モデル、データ、インフラの境界をまたぐ可能性がある。プロダクトマネージャーには誤った結果が見える一方、根本原因はプロンプト変更、ツールスキーマ、古いインデックス、タイムアウト、モデル更新にあるかもしれない。

トレースがなければ、チームは目に見える回答をめぐって議論する。構造化されたトレースがあれば、利用可能なツール、エージェントが選んだツール、送信したパラメータ、各ステップが応答にどう寄与したかを確認できる。

これが、評価とオブザーバビリティが連携しなければならない理由だ。評価は挙動が定義された基準を満たすかを判断する。オブザーバビリティは、それが合格または不合格となった理由を理解するために必要な証拠を記録する。

Motorwayの結果は、この組み合わせたアプローチが検知時間を短縮できることを示唆している。ただし、すべての組織が同じ改善を得られることを裏付けるものではない。効果は、トレースの品質、評価設計、トラフィックパターン、不合格スコアに伴う影響に左右される。

それでも、立証責任は移った。顧客向けワークフローにエージェントを導入するチームには、説得力のあるトランスクリプトの寄せ集めではなく、再現可能な証拠がますます求められている。

StrandsとAgentCoreの仕組み

Strandsはリリース前の制御された評価を担い、AgentCoreは同じ品質モデルをサンプリングされた本番トラフィックへ拡張する。

Strands Agents SDKは、エージェントの構築と計測に用いられるフレームワークを提供する。Strands Evalsは、テストをケース、実験、タスク関数、評価器に整理する。

ケースは、入力と、期待される出力またはツール軌跡を含む1つのシナリオを定義する。実験はケースをグループ化し、1つ以上の評価器を実行する。タスク関数は、それらのケースをライブエージェントまたは事前に取得した実行データに接続する。

この構造は2種類のテストパターンを支える。オンラインテストは評価実行中にエージェントを呼び出すため、開発と継続的インテグレーションに適している。オフラインテストは記録済みのトレースを評価するため、バージョン比較や過去の本番挙動の調査に役立つ。

Motorwayのパイプラインは、一般的なディーラー検索と既知のエッジケースを表す、キュレーションされたシナリオから始まる。各実行では、エージェントの応答と、その応答を生み出した経路が取得される。

ツール層では、エージェントが正しい機能を選択し、適切なパラメータを指定したかを問う。この層は、誤ったデータソースに送られた検索リクエストや、無効な形式で表現されたフィルターを検出できる。

推論層では軌跡をレビューする。各ツール呼び出しを独立して判断するのではなく、完全なシーケンスにわたる一貫した意思決定を確認する。これは、有効な結果に複数の相互依存するアクションが必要な場合に重要となる。

出力層は、ユーザーに提示される応答を採点する。関連性、完全性、安全性、根拠付けといった品質を評価できる。正しい内部実行であっても不明瞭な回答を生む可能性があるため、この最終層は依然として必要だ。

これらの開発チェックはリリースゲートとして機能する。チームは、提案されたモデル、プロンプト、ツール定義、オーケストレーション変更を、確立されたテストセットと比較できる。回帰があれば、顧客が遭遇する前に昇格を阻止する。

デプロイ後、AgentCore EvaluationsはOpenTelemetryトレースを読み取る。OpenTelemetryは、分散アプリケーションにまたがる操作を記録するためのオープンスタンダードだ。その生成AI向け規約では、プロンプト、補完、モデル設定、ツール呼び出し、関連する実行詳細を取得できる。

この共通トレース形式は、単一のエージェントフレームワークへの依存を軽減する。AWSのドキュメントによれば、AgentCoreはOpenTelemetryまたはOpenInferenceで計測されたStrandsおよびLangGraphエージェントをサポートしている。

AgentCoreはオンデマンド評価とオンライン評価を提供する。オンデマンド評価は、開発およびリリーステスト中に選択したトレースやセッションを採点する。オンライン評価はライブトラフィックをサンプリングし、結果を監視ワークフローへ送る。

このサービスは、組み込み評価器、カスタム言語モデル判定器、正解データとの比較、Lambdaベースのコード評価器を適用できる。AgentCoreのドキュメントによると、トレースは採点前に統一形式へ変換される。

言語モデル判定器は、厳密な一致に適さない品質を扱う。回答がユーザーの目的に対応しているか、利用可能なコンテキストに忠実かを評価できる。

コード評価器は決定論的な要件を扱う。関数を使えば、正確な識別子、必須フィールド、パラメータ範囲、応答スキーマを検証できる。これは、別のモデルに正確な値を確認させるよりも予測しやすい場合が多い。

パイプラインはその後、スコアをCloudWatchのダッシュボードとアラートへ送る。品質低下が発生すれば、インシデントの作成、人によるレビューの開始、ロールバックプロセスへの情報提供につながる可能性がある。

AWSは、本番監視を1%のサンプリングから始めることを推奨している。チームは評価器のコスト、レイテンシー、シグナル品質を理解した後にカバレッジを拡大できる。高リスクの操作では、言語モデル評価がサンプリングされたままであっても、より広範な決定論的チェックが必要になる場合がある。

本番環境での失敗は、開発スイートへと還流される。まれな販売店特有の表現、タイムアウトのパターン、想定外の追加問い合わせが、新たなケースになる。こうしてテストセットは、固定化された合成プロンプトの集まりではなく、実際の挙動から成長していく。

このフィードバックループこそ、報告された改善を支える仕組みだ。単一の評価器だけで信頼性は生まれない。観測された失敗を、測定可能なリリース基準へ繰り返し変換することで、信頼性は生まれる。

本当の競争相手は、エビデンスか直感か

Motorwayのパイプラインは、感覚に頼ってプロンプトを変更し、都合のよい少数の例で検証するという、エージェント開発でよく見られる習慣に異を唱えている。

プロンプトの反復改善は速いため、非公式なレビューを促しやすい。開発者は弱い回答を見つけ、指示を調整し、いくつかのプロンプトを試し、改善したように見える状態でリリースする。

この手順は、目に見えるケースを修正する一方で、別の挙動を損なう可能性がある。より厳格な指示はツール選択を改善しても、タスク完了率を下げるかもしれない。より長いプロンプトは文脈を維持する一方、レイテンシを高めたり、不要な呼び出しを促したりする可能性がある。

したがって、Amazon AWSのブループリントにおける主な対抗相手は、別のクラウドプロバイダーではない。安定したベースラインがなく、顧客からの苦情を通じて回帰を発見する、直感主導のエージェント開発である。

Strandsの実験は、制御された比較を提供する。チームは同じケースを2つのバージョンに対して実行し、評価レイヤーごとの変化を確認できる。これにより、トレードオフをリリース前に可視化できる。

AgentCoreは、その比較を本番環境へ拡張する。実際のユーザーは、キュレーションされたデータセットではほとんど扱われない用語、不完全な依頼、相反する制約、タイミング条件を持ち込む。シャドー評価では、ユーザー向けシステムを直ちに変更せずに、こうしたやり取りを採点できる。

このモデルは、重要な一点で成熟したソフトウェアデリバリーに似ている。品質基準が実行可能かつ反復可能になることだ。ただし、有効な出力が多数存在するため、エージェント評価はユニットテストの慣行をそのままコピーできない。

従来のアサーションなら、関数が特定の値を返したことを検証できる。エージェント評価器では、回答が十分に役立つものか、根拠に基づくものか、完全なものかを判断する必要がある場合が多い。これらの基準には解釈が伴う。

このパイプラインは、主張に応じて評価器を選ぶことで、その対立を解決する。正確なデータや形式のルールはコードに任せる。意味的な品質は言語モデルの判定に委ねる。ツール経路には、期待される軌跡、文脈に基づく判断、またはその両方を使える。

この違いは、購買判断にも影響すべきだ。単一の統合品質スコアを報告するプラットフォームでは、どの失敗カテゴリが変化したのかが隠れてしまう可能性がある。エンタープライズの購入担当者は、ツール、トレース、セッションの各レベルでスコアを確認できるかを問うべきだ。

また、評価が環境をまたいでアプリケーションを追跡できるかも確認すべきである。デプロイ後に消えてしまう開発ベンチマークでは、本番データやユーザーパターンによる挙動変化を検出できない。

AWSは、その継続性を担うマネージドレイヤーとしてAgentCoreを位置付けている。同社の評価概要によれば、このサービスは評価モデル、推論インフラ、データ処理、スケーリングを管理する。

この構成はインフラ作業を減らす一方で、評価、テレメトリー、ダッシュボード、デプロイ制御におけるAWSサービスへの依存を深める。すでにAWS上で運用しているチームにとっては、この統合が利点となる可能性がある。

マルチクラウド要件を持つ組織は、移植性を検討する必要がある。OpenTelemetryは移植可能なトレース形式を提供するが、ダッシュボード、評価器の設定、IAMポリシー、自動応答はプラットフォーム固有のまま残る可能性がある。

オープンフレームワークは別の道筋を提供する。LangSmith、Arize Phoenix、Braintrustなどのエージェント可観測性システムも、トレース、データセット、実験、評価器を組み合わせている。意味のある比較基準は、利用可能な判定器の数ではない。

より重要な問いは、システムが本番での失敗を再現可能なテストやリリース判断に結び付けられるかどうかだ。Motorwayの導入が改善したと主張しているのは、この閉じたループである。

チームには、規律ある運用知識も必要になる。評価結果、インシデントの説明、ドメインルールは、エンジニアがトレースやテストケースと並べて検索できるとき、より有用になる。検索可能なエンジニアリングナレッジベースは、リリースをまたいでその文脈を保持できる。

報告された精度向上が証明しないこと

報告された改善は有意義だが、判定器のばらつき、サンプリングの不足、ベンチマークの偏り、プラットフォーム依存を解消するものではない。

最初の制約は、寄与の特定である。Motorwayは評価パイプラインを導入し、その後に性能向上を報告した。公開された結果だけでは、新しいテスト、プロンプト変更、ツール修正、運用上の注力、あるいはAgentCoreそのもののどれが、どの程度の改善に寄与したのかを切り分けられない。

2つ目の制約は、ベンチマークの構築にある。評価スイートは、チームが含めることを選んだシナリオを反映する。ケースが曖昧な言語、まれな在庫状態、通常と異なる会話経路を十分に代表していなければ、高い合格率と不十分なカバレッジは両立しうる。

本番からのフィードバックはこのリスクを軽減するが、解消はしない。ユーザーは問題を報告せず、失敗したやり取りを途中で離脱する可能性がある。その場合、組織は検索条件の再調整やタスク放棄といったビジネスシグナルによって、見えない失敗を検出する必要がある。

3つ目の制約はサンプリングだ。1%のモニタリング率は評価コストを抑えるが、まれな失敗は観測から漏れる可能性がある。サンプリング方針は、単一の普遍的な開始比率だけでなく、トラフィック量と影響度を反映すべきだ。

4つ目の制約は、判定器の信頼性である。LLM-as-a-judgeは、ルーブリックに照らして別のモデルの挙動を評価するために言語モデルを使う。これは、位置バイアス、一貫しない採点、回答スタイルに関する選好を持ち込む可能性がある。

詳細な説明が、正しい判定を保証するわけではない。チームはモデル判定器を人間がレビューした事例に照らして較正し、定期的に一致度を測定すべきだ。反復評価により、単一のスコアでは見えないばらつきを明らかにできる。

ルーブリックにもバージョン管理が必要だ。評価器への指示を変更すると、エージェントに変更がなくてもスコアが変動する可能性がある。ダッシュボードでは、製品の回帰と測定方法の変更を区別すべきである。

AWSは、AgentOpsのガイダンスにおいて、このより広範な運用負荷を認識している。推奨モデルでは、リリース前にオンデマンドチェックを置き、デプロイ後にオンラインモニタリングを行う。同社のAgentOpsフレームワークも、フレームワーク、サービス、インフラ、ビジネスのテレメトリーを分けている。

5つ目の制約は、指標の解釈である。ツール選択精度を98%まで高めても、失敗は残る。許容できる残余エラー率は、そのツールが何を行うかに依存する。

車両フィルターの見落としは、検索体験を悪化させる。支払い、医療記録、アクセス方針に関する誤った操作は、それとは異なるリスクを伴う。チームはMotorwayの目標値をそのままコピーするのではなく、影響に応じて閾値を設定すべきだ。

コンテキスト保持についても、慎重な定義が必要である。AWSは71%から94%への向上を報告しているが、公開要約には、そのスコアを他社のベンチマークと比較するための十分な詳細がない。

6つ目の制約は、評価器間の相関である。複数の判定器が同じ表面的な品質を評価し、共通する盲点を見逃す可能性がある。AWSは、それぞれの評価器が別々の品質次元をカバーするよう、異なる基準を推奨している。

高影響の失敗や争いのあるスコアでは、人間によるレビューが依然として重要だ。ルーブリックが実際のビジネス要件を表しているかどうかは、人が見極められることであり、自動判定器が独立して決められることではない。

最後の制約は、インセンティブに関するものだ。指標がデプロイのゲートになると、チームはテストスイートに最適化する可能性がある。本番ケース、入れ替え式のチャレンジセット、非公開の評価は、システムが見慣れたプロンプトだけで改善することを防ぐのに役立つ。

これらの問題は、Motorwayの結果を無効にするものではない。結果を責任を持って解釈するために必要な条件を定義するものである。評価は測定システムであり、測定システム自体にもテストが必要だ。

Amazon AWSのブループリントの次に注目すべきこと

次の試金石は、このパイプラインが新しいエージェントバージョン、実トラフィックの増加、評価コストの中でも改善を維持できるかどうかだ。

最初のシグナルは、Motorwayのインシデント傾向である。月間インシデント数が12件から2件に減少したという報告は、ベースラインを示している。持続的な成果が見られれば、継続的評価が一時的な整理にとどまらず、回帰を検出しているという主張を支持することになる。

これらのインシデントは、件数と同じくらい内容が重要だ。残る失敗が未知の表現やマルチターンの文脈に集中するなら、Motorwayはケースと判定器を拡張できる。ツールやパラメーターのエラーが繰り返されるなら、リリースゲートへの信頼は弱まる。

2つ目のシグナルは、新しいモデルやプロンプトにおけるpass^kの性能である。Motorwayがモデルバージョン、ツールスキーマ、オーケストレーションロジックを変更する際にも、反復実行時の信頼性が安定しているかをチームは監視すべきだ。

リリースは平均精度を向上させながら、一貫性を低下させる可能性がある。反復試行の成功率を報告すれば、単一の合格率よりもその違いを明確に示せる。

3つ目のシグナルは、本番サンプリングの拡大だ。AWSは1%から始め、徐々に拡大することを推奨している。判定器コストを制御不能にせずカバレッジを広げられれば、マネージドサービスとしての価値は強まる。

組織が、サンプリングした意味的な判定と、より広範なコードベースのチェックを組み合わせるかに注目したい。このハイブリッド設計では、曖昧な品質上の問いには言語モデルを使いながら、重要なすべての操作には決定論的な検証を適用できる。

Strands以外でのAgentCoreの採用も、そのトレースベースのアーキテクチャの価値を試すことになる。標準OpenTelemetryデータのサポートは、チームがエージェントを移行し、有用な評価履歴を保持できる場合にのみ意味を持つ。

より大きな教訓はすでに明確だ。本番エージェントには、リリース前に始まり、ユーザーの利用開始後も続く品質ループが必要である。テスト、トレース、アラート、インシデント分析、新たな回帰ケースは、ひとつながりのプロセスを構成すべきだ。

開発者にとって実務上の行動は、評価器を選ぶ前に、価値の高いワークフローを1つ選び、その失敗モードを定義することだ。ツール選択、パラメーター、タスク完了、コンテキスト、レイテンシ、最終出力をそれぞれ分けて追跡する。そして同じケースを複数回の試行で繰り返す。

エンタープライズの購入担当者は、エージェントレビューの際にこのエビデンスを求めるべきだ。どの挙動がデプロイを阻止するのか、本番トラフィックをどのようにサンプリングするのか、誰が判定器の精度を検証するのか、そして失敗が将来のテストにどう変わるのかを尋ねたい。

ナレッジワーカーも気にかけるべきである。なぜなら、こうした統制が、エージェントを重要な業務で信頼できるかどうかを左右するからだ。Amazon AWSのエージェント導入を評価する際は、流暢な回答だけに目を向けてはならない。その背後にあるトレース、反復実行の結果、本番フィードバックループを求めるべきだ。