AIエージェントを試作の段階から本番運用へ移すとき、多くのチームがぶつかる壁が品質の保証です。デモではうまく動いたのに、実際のトラフィックにさらすと想定外のツールを呼び出したり、文脈を取り違えたりする。こうした問題を「だいたい良さそう」という感覚で見過ごすと、本番インシデントとして跳ね返ってきます。英国のオンライン中古車マーケットプレイスであるMotorway社は、この課題に対してStrands Agents SDKとAmazon Bedrock AgentCoreを組み合わせ、評価を開発から運用まで一貫して組み込む設計図を築きました。本記事では、そのアプローチを日本のエンジニア視点で読み解いていきます。

Motorway社が挑んだエージェント品質という難題

Motorway社は日次オークションを運営するプラットフォームで、最大8,000ディーラーが最大2,500台の車両へ入札します。ピーク時には約1,500人が同時に利用し、89を超える車両属性で検索できる規模の大きなサービスです。この環境でAIエージェントを稼働させるということは、わずかな判断ミスが多数の取引に波及することを意味します。

同社のプリンシパルエンジニアであり、AWS Community Builderでもあるライアン・コーマック氏は、エージェントの品質を主観ではなく数値で担保する仕組みを設計しました。ここで鍵になるのが、評価をあとから付け足すのではなく、開発の最初から運用の最後まで途切れなく織り込むという発想です。感覚に頼らず、合格か不合格かを機械的に判断できる基準を先に決めておくことで、チーム全体が同じ品質の物差しを共有できるようになります。

エージェントは従来のソフトウェアと違い、同じ入力に対して常に同じ出力を返すとは限りません。だからこそ、単体テストだけでは品質を捉えきれず、確率的なふるまいを前提とした評価の枠組みが必要になります。Motorway社のように取引額の大きなサービスでは、一つの誤判断がディーラーの入札やユーザーの検索体験に直結するため、品質を定量化して継続的に見張ることが事業そのものを守る営みになります。

StrandsとAgentCoreが担う役割

この設計図は、二つの要素が互いを補い合う形で成り立っています。Strands Agents SDKはエージェントそのものを構築するためのフレームワークで、開発段階から評価を組み込める点が特徴です。エージェントのふるまいを組み立てながら、その品質を測る仕組みを同時に用意できるため、後戻りの少ない開発が実現します。

一方のAmazon Bedrock AgentCoreは、完成したAIエージェントを大規模にデプロイし運用するためのフルマネージドサービスです。エージェントを実行するランタイム、本番稼働中のふるまいを見張る本番監視、そして評価を担うAgentCore Evaluationsを提供します。開発を支えるStrandsと、運用を支えるAgentCoreが連携することで、試作から本番まで一本の線でつながった品質管理が可能になります。日本のチームがエージェント開発を検討する際にも、構築と運用を別物として扱わず、評価という共通言語でつなぐこの考え方は大いに参考になります。

品質を三つの階層で測る評価アプローチ

Motorway社の評価は三つの階層で構成され、すべての層に合格することが必須とされています。どれか一つでも不合格になれば、その時点でパイプラインはブロックされます。厳しく聞こえますが、この妥協のなさこそが品質の底上げにつながっています。

第1層のツール利用

最初の層は、エージェントが正しいツールを選び、適切なパラメータを渡せているかを評価します。しきい値は95%超という高い水準に設定されています。この層はコードベースの決定的な採点器で機械的に測定されるため、判定にぶれがありません。ツール選択のような明確な正解がある領域は、審査モデルに頼らず自動採点で高速にさばくのが合理的です。

第2層の推論

二つ目の層は、エージェントの論理的な意思決定プロセスを評価します。しきい値は85%超です。この層はLLM-as-judgeという手法で測定され、審査役のモデルにはClaude Sonnet 4.6が使われます。正解が一意に定まらない推論の妥当性は、別のモデルに審査させることで柔軟に評価できます。ツール選択のように白黒がはっきりする領域とは性質が異なるため、採点の手段もそれに合わせて切り替えている点が実践的です。

第3層の出力品質

三つ目の層は、応答の有用性、正確さ、実行可能性を評価します。しきい値は90%超で、この層もLLM-as-judgeで測定されます。決定的な採点で測れる部分は自動化し、意味の質を問う部分は審査モデルに委ねる。この使い分けが、評価の精度と効率を両立させる要になっています。

本番反映を守る五段階のデプロイゲート

評価の基準を決めても、それを本番反映の関門に組み込まなければ意味がありません。Motorway社は五つの段階からなるデプロイゲートを設け、基準を満たさない変更はデプロイをブロックする仕組みを整えました。段階を追うごとにリスクを絞り込んでいく流れです。

第一段階はビルド時評価で、ツールの正確さが95%超であることをLLM-as-judgeの採点とあわせて確認します。第二段階はステージング検証で、合成トラフィックを用いてAgentCore評価を実施します。第三段階はシャドウモードで、実際の本番トラフィックを並行処理し、2%の乖離しきい値のもとで少なくとも4時間稼働させます。第四段階はA/Bテストで、トラフィックの5%を候補エージェントへ流して比較します。そして第五段階の本番ロールアウトでは、オンライン評価下でトラフィックを100%へと移行させます。

段階を追うごとに、変更が本物のリスクに触れる度合いを慎重に高めていく点がこの設計の巧みなところです。合成トラフィックで安全を確かめ、次に実トラフィックを影で流し、それから少量の本番トラフィックで比較し、最後に全量へ広げる。各段階に明確な基準を置くことで、どこで問題が起きても本番への影響を最小限に抑えられます。

この一連のゲートで注目したいのが、重要指標をpass^kという考え方でゲートしている点です。これは複数試行での連続成功率を測る指標です。たとえば一回あたりの成功率が75%だとしても、3回連続で合格する確率は約42%にとどまります。一発勝負では見えない不安定さが、連続成功という視点で初めて浮き彫りになるわけです。安定して繰り返し成功することを求めるこの発想は、単発の精度だけを追いがちな評価設計への鋭い問いかけになっています。

本番監視と継続的な評価の仕組み

デプロイして終わりではなく、本番稼働中も評価を続けることがこの設計図の要です。AgentCore Evaluationsは二つのモードで継続的な評価を支えます。オンデマンド評価は、CloudWatchログからスパンを選んで個別に分析する方式です。気になった挙動を掘り下げて調べたいときに役立ちます。もう一つのオンライン評価は、稼働中のトラフィックを1〜5%サンプリングして自動的に評価する方式で、本番の品質を常時見張る役割を担います。

さらに見逃せないのが、テストケースを育てていく姿勢です。Motorway社は当初50だったテストケースを、3ヶ月で150へと拡張しました。最初から完璧なテスト網を用意するのではなく、運用の中で見つかった課題を取り込みながら少しずつ厚くしていく。この継続改善の積み重ねが、エージェントの信頼性を着実に押し上げていきます。

こうした取り組みの成果は、導入の前後を比べると明確です。ツール選択の正確さは87%から98%へ向上し、誤りは8件に1件から50件に1件へと減りました。タスク完了率は82%から96%へ、複数ターンにわたるコンテキスト保持は71%から94%へと伸びています。月次の本番インシデントは12件から2件へ減少し、問題を検知するまでの平均時間も数時間から数分へと短縮されました。定量的なゲートを敷いたことが、そのまま運用の安定につながったといえます。

日本のエンジニアと企業への示唆

この事例から、日本のエンジニアや企業が持ち帰れる学びはいくつもあります。まず、精度を「だいたい良さそう」という感覚で本番に出すのではなく、合格か不合格かを判定できる定量的なゲートへ落とし込む発想です。しきい値を先に決めておけば、リリース判断が属人的な勘から外れ、チームで再現できるものになります。

次に、決定的な採点とLLM審査を使い分ける考え方も応用が利きます。明確な正解がある領域は機械的な採点で速く正確にさばき、意味の質を問う領域は審査モデルに委ねる。この切り分けは、評価コストと精度のバランスを取るうえで有効です。さらに、シャドウモードやA/Bテストで段階的にリスクを絞る運用は、いきなり全量を切り替える怖さを避けたい現場にとって現実的な選択肢になります。少数のテストケースから始めて運用の中で育てていく姿勢も、完璧主義で動けなくなりがちなチームへの良い処方箋です。評価を開発から運用まで一貫させるこの設計図は、規模や業種を問わず、AIエージェントを本番へ届けたいすべてのチームにとって確かな道しるべになるはずです。