AIエージェントの誤処理をどう見つける？MLflowでつなぐ評価と本番監視｜2026年9月10日版
AIが丁寧に回答していても、その裏で参照した注文や呼び出した処理が正しいとは限りません。業務を実行するAIエージェントでは、最終回答に加え、検索やツール実行の途中経過を記録し、失敗を次のテストに戻す仕組みが必要です。
9月に公開されたインドの即配サービスZeptoの顧客対応事例は、この仕組みを大規模な運用につなげたものです。開発時の評価と本番監視を別々にせず、共通の基準で改善を回す設計が焦点になります。
本稿は日本時間2026年9月10日時点の情報を基に、MLflowの公式資料とともに、その技術的な意味を整理します。
- 記録する対象：回答だけでなく、検索結果、ツールの入出力、処理時間。
- 更新前の判断：決めたテストケースと採点基準で、新旧の動作を比較する。
- 運用後の改善：本番で見つかった失敗を評価データに追加する。
Zeptoの事例が示す、開発と運用をつなぐ設計
中心にあるのは、開発と本番運用を往復する「二つのループ」です。
Databricksが公開したZeptoの事例では、開発側でエージェントを設計・評価し、本番側で実際の動作を監視します。その間に、公開してよい品質に達したかを判定する品質ゲートを設け、本番の失敗を次の開発へ返します。事例の規模は、1日10万件を超える問い合わせ処理とされています。Databricksの事例原文
ここで重要なのは、自動対応件数の多さだけではありません。問い合わせの種類が増えたり、業務ルールが変わったりした際にも、以前できていた処理が壊れていないかを確認できる点です。
例えば、返品に関する指示を変更した場合、返品の回答だけを数件見るテストでは、注文照会など別の処理への影響を見落とします。変更前後を同じケースで評価すれば、改善と悪化を分けて確認できます。これは事例を自社の開発に置き換える際の基本的な考え方です。
トレースで「どこから間違ったか」を追う
原因を調べるには、AIに渡した質問と最終回答だけでは情報が足りません。
MLflow Tracingは、リクエストの途中にある各処理について、入力・出力・メタデータを記録します。OpenTelemetryに対応し、処理ごとの時間やトークン使用量も確認できます。MLflow Tracing公式ドキュメント
顧客対応エージェントを例にすると、調べる対象は次のように分かれます。
- 検索：必要な規約や商品情報を取得できたか。
- ツール呼び出し：意図した処理を、適切な引数で呼び出したか。
- 外部処理の結果：成功したのか、エラーや空の結果が返ったのか。
- 回答生成：取得した情報や処理結果と矛盾する説明をしていないか。
この切り分けができれば、修正対象も絞れます。検索に必要な文書がない場合と、正しい文書を渡しても回答を誤る場合では、直す場所が違うからです。
ただし、トレースはモデル内部の思考を完全に読む機能ではありません。確認できるのは、アプリケーション側で記録した呼び出しとデータです。見える範囲を増やすには、重要な処理に計測を入れる必要があります。
同じ採点基準を、更新前と本番で使う
記録を集めただけでは、品質の良し悪しは決まりません。次に必要なのが評価です。
MLflowの評価は、基本的に「入力と期待結果を持つデータセット」「アプリケーションの実行処理」「採点するスコアラー」を組み合わせます。LLMを採点役として使う方法に加え、独自の判定処理や人のフィードバックも扱えます。MLflowの評価機能
判定できる条件と、読んで判断する条件を分ける
例えば、注文番号の一致や必須項目の有無は、プログラムで確認しやすい条件です。一方、説明が質問に答えているか、案内が分かりやすいかは、文章の意味を踏まえた評価が必要になります。
両者をまとめて一つの点数にすると、丁寧な文章が処理上の誤りを覆い隠しかねません。実装では、少なくとも次の項目を別々に見ると問題を把握しやすくなります。
- 業務処理の正しさ。
- 回答の根拠と内容の整合性。
- 応答時間と処理コスト。
- 人の担当者へ引き継ぐ判断。
本番でも同じ物差しを使う
Databricksの公式資料では、開発時に使った判定器やスコアラーを本番監視でも再利用できると説明しています。これにより、公開前だけ厳しく採点し、公開後は速度しか見ない、といった分断を減らせます。Databricksの評価・監視ドキュメント
ただし、同じ判定器を使うことと、その判定が正しいことは別です。LLMによる採点は、人の担当者が確認した結果と照合する必要があります。人が不適切と判断した回答を採点役のAIが合格にしていれば、エージェントだけでなく評価方法も見直す対象です。
日本の開発現場では、失敗例を残すところから始める
社内ヘルプデスクやECの問い合わせ対応に応用するなら、まず一つの業務フローを追跡できる状態にするのが現実的です。
具体的には、問い合わせの受信から、情報検索、外部処理、最終回答までを一つの記録として確認します。そのうえで、現場担当者が誤りと判断したケースに、期待する動作を付けて評価用に保存します。
MLflowは、本番トレースを評価データの作成に利用する仕組みを備えています。失敗したケースを次の更新でも試せるようにすれば、同じ不具合の再発を検知する材料になります。
ここでの実装上の確認点は三つです。
- 日本語の実データで評価する：省略された主語や社内用語など、自社で起きる問い合わせを含める。
- 引き継ぎも成功条件にする：AIが処理できない場面で、適切に人へ渡せるかを試す。
- 記録する情報を決める：注文情報などを扱う場合、トレースのマスキング、閲覧権限、保存期間を設計する。
これらはZeptoでの実施内容を断定するものではなく、同種の仕組みを日本の業務に導入する際の確認事項です。
継続ウォッチ：評価が実際の失敗を拾えているか
次に見るべきなのは、評価基盤を入れたかどうかより、運用中の誤りをどれだけ検出できているかです。
- 本番で発生した失敗が、次の評価データに追加されているか。
- 採点役のAIと現場担当者の判断が食い違うケースを追えているか。
- モデルやプロンプトを更新した際、正確さと応答時間の両方を比較できるか。
AIエージェントを更新する前に、直近の誤処理を一件選び、新しい版で再現しないかを確かめる。その確認を繰り返せる形で残すことが、本番の失敗を次の改善につなげる第一歩になります。