料理画像は、ユーザーが料理や店舗に抱く第一印象を左右する。画像の出来栄えは、ユーザーが画面をスクロールし続けるか、料理を選んでカートに追加するかという行動にも関係する。しかし、個人経営を含む小規模な加盟店では、料理画像の撮影に必要な時間やノウハウ、予算を確保しにくい。プロによる撮影には費用がかかり、メニューを頻繁に更新する店舗では継続的な対応も難しい。その結果、鮮明さや構図、色合いに課題を抱える画像が掲載される場合がある。

　そこでUber Eatsは、AIを使って画像を補正する仕組みの構築に取り組んだ。ただし、単に見栄えのよい画像を生成すればよいわけではない。完全なAI生成画像に不信感を持つユーザーもいるため、実際の商品に忠実であること、店舗ごとの特徴を残すこと、全ての画像が同じような見た目にならないことが重要になる。

　同チームは、この条件を「本物らしさの維持」と「必要な品質改善」の両立と捉えた。高品質な画像まで一律に加工すれば、計算コストが無駄になるだけでなく、元画像より品質を下げる恐れもある。そのため、品質の低い画像だけを選択的に補正し、基準を満たさない結果は公開しない仕組みを設けた。

　システムは、複数のAIエージェントが連携する構成を採る。最初に動作するのが、画像理解・ルーティングエージェントである。画像そのものに加えて、商品名などのテキスト情報やメタデータを読み取り、画像の内容を説明する構造化データを生成する。

　その結果を基に、画像を補正する「Enhance」と、元画像を維持する「Skip」のどちらに振り分けるかを判断する。既に品質の高い画像を補正対象から外すことで、無駄な処理コストと画像の改悪リスクを抑える。

　ルーティングの評価には、一般的な分類器と同様に混同行列を使い、適合率や再現率を測定する。同チームが特に重視するのは再現率である。補正が必要な画像を見逃し、不適切な状態のまま後続工程に流すことを防ぐためだ。

　一方で、誤って高品質な画像を補正対象にすると、品質向上が見込めない処理に計算資源を使うことになる。両氏によると、既に高品質なハンバーガー画像を低品質と判定し、補正に送ってしまう例もあったという。

　商品情報との不一致も重要な評価対象だ。例えば、商品名に「8ピース」とあるにもかかわらず、画像に6個しか写っていない場合、その画像を編集エージェントに渡すと、AIが不足する2個を生成して帳尻を合わせる可能性がある。見栄えが改善しても、実物との忠実性を損なえば公開できない。

　補正対象となった画像は、画像編集エージェントに送られる。編集エージェントは、画像の説明やルーティング工程で得た指示を基に、その画像固有の修正プロンプトを作成し、補正を実行する。

　補正後の画像は、QAエージェントが評価する。評価項目には、盛り付け、色合い、自然さ、現実性、元画像への忠実性、内容の完全性などが含まれる。基準を満たさなければ、不合格の理由を編集エージェントへ戻し、再編集させる。

　この処理を、一定回数まで繰り返す。評価指標には「Pass@K」を用いる。これは、K回目の編集までに品質基準を通過した割合を示す指標だ。再編集のたびにQA結果をフィードバックし、エージェント自身に修正させることで、自己修復型の処理ループを構成する。

　処理ループの例として両氏は、サツマイモのフライを写した画像を示した。1度目の編集結果は、量や盛り付けが不自然だったためQAエージェントが却下した。評価結果を基に再編集したところ、2回目で基準を通過したという。

　ただし、編集とQAのループだけで全ての問題を防げるわけではない。実際の失敗例として、元画像に存在しないエビを追加する、寿司に添えられたたれを削除する、器がたれを覆うといった問題が確認された。

　QAの評価を通過することだけを優先し、意味のある改善を伴わない変更を加える「報酬ハッキング」も発生したという。最初の編集が大胆過ぎると指摘された結果、次の編集では逆に過度に保守的になり、一般的な器へ置き換えるだけの変更にとどまる例もあった。

　こうした問題に対応するため、編集工程の後には、公開可能かどうかを判断する最終QAを設ける仕様だ。ここでは、ポリシー違反の有無に加え、上流工程で見逃した品質上の問題や予期しない破綻を確認する。

　そこでチョプラ氏とグプタ氏のチームは、この確認方法として「スイスチーズモデル」を紹介する。それぞれの評価工程には見逃しが生じ得るが、複数の安全網を重ねることで、問題のある画像が本番環境へ到達する確率を下げる考え方だ。

　さらに、全てのエージェントの処理内容を一元的に記録するようにしている。各エージェントの入力、出力、評価結果を、共通のフラットなJSON構造でログに残す設計だ。

　これにより、エンジニアだけでなく、製品やデザインなどの非技術部門も個別事例を確認しやすくなる。特定の失敗を追跡するだけでなく、複数の事例を集約して傾向を分析することもできる。

　チョプラ氏とグプタ氏のチームは、AIエージェントを本番運用する際には、最初にログの記録機能を整備することが重要だと強調した。ログがなければ、どこを改善すべきか判断できず、継続学習の仕組みも構築できないためだ。

　Uberの仕組みで最大の特徴となるのが、人手を介さずにAIエージェントを継続的に最適化する「閉ループ評価」だ。本番環境では、地域や料理の種類、画像品質の変化によって、導入時の評価データと実際のデータ分布が徐々にずれるデータドリフトが発生する。

　チョプラ氏とグプタ氏のチームは、本番データを定期的に抽出し、人間の評価者に送る。評価者は、事前に定めた客観的なガイドラインに従ってラベルを付ける。地域、料理の種類、画像品質などに偏りが出ないよう、代表性を持つデータセットを使う。

　AIエージェントの出力と人間の評価結果に不一致がある場合、診断エージェントが問題の発生箇所を特定する。システム全体のどのエージェントを調整すべきか判断し、自動チューニングの処理へ振り分ける。

　プロンプト最適化は、「Reflect Agent」と「Synthesize Agent」という2つのサブエージェントが担う。Reflect Agentは、人間とAIの判断が一致しなかった事例を分析し、ノイズを除きながら系統的な失敗原因を特定する。

　Synthesize Agentは、その分析結果と現在の設定を受け取り、対象エージェントのプロンプトや設定ファイルを更新する。更新後のエージェントは、あらかじめ用意した正解データセットで再評価する。

　品質、安全性などの基準を満たした場合、新しい設定をエージェントストアへ登録し、次回の本番処理から新バージョンを利用する。基準に達しなければ、設定の修正と評価を繰り返す。監視と迅速な切り戻しの仕組みも備え、問題が生じた際に旧バージョンへ戻せるようにした。

　この自動チューニングは設定ファイルを中心に動作し、人間が都度プロンプトを書き換える必要はない。診断エージェントが設定を生成し、自動調整の処理を起動する。静的なモデルを一度導入して終わるのではなく、本番データの変化に合わせてシステム全体を継続的に更新する。

　閉ループ評価に取り込むのは、人間による正解ラベルだけではない。Uber社内で正式公開前のサービスをテストする「ドッグフーディング」の結果や、加盟店、デザインチーム、他の製品チームから寄せられる評価も使う。

　高評価、低評価のボタンに加え、自由記述のコメントも診断工程へ送れるようになっている。よい事例と問題のある事例を再実行し、更新前後の指標を比較した上で、新しい設定を本番環境へ反映する。

　最終的には、画像単体の品質だけでなく、事業への効果も測定する。カートへの追加率や注文完了率などのコンバージョン指標を監視し、地域、端末、料理の種類といった単位で細分化して分析する。

　全体では改善していても、特定地域や料理カテゴリで効果が低い可能性がある。そこで、セグメントごとの結果を確認し、必要に応じて特定の領域に合わせてエージェントを調整する。

　Uberの事例は、AIエージェントの開発が、モデルやプロンプトを作るだけでは完結しないことを示している。画像の本物らしさを定義し、複数段階の評価を設け、全処理を記録し、本番データと利用者の反応を基に継続的に設定を更新する。

　複数のAIエージェントに役割を分担させ、失敗を前提とした安全網を設けるとともに、評価結果を自動的に改善へつなげる。こうした閉ループ型の設計が、大規模サービスでAIエージェントを安全かつ効率的に運用するための中核となっている。

本稿は、AI Engineerが2026年7月25日に公開した動画「Building Closed-Loop Evals for a Multimodal Agent at Scale－Soumya Gupta＆Jai Chopra, Uber」を基に作成しました。