Zepto、DatabricksとMLflowでAIエージェントによる顧客サポートを拡大

Zepto が目指す、信頼性とリアルタイム性の高いカスタマーサポート

Zepto はインドで最も急成長しているクイックコマースプラットフォームの一つです。取り扱う商品は数千種類に及び、60 都市以上に出店し、配送は数分で完了します。このビジネスにおいて「スピード」こそが商品そのものなので、カスタマーサポートも同様に高速である必要があります。

そんな期待に応えるため、Zepto は一日に 10 万件以上の問い合わせを処理するマルチエージェント AI システムを導入しています。初期段階ではチームは素早くエージェントを構築・リリースできました。しかし、より難しい課題は、取扱件数の増加や商品カテゴリの拡大、そして変化する顧客行動の中で、いかにしてこれらのエージェントの信頼性を維持するかという点でした。Zepto は Databricks と提携し、エージェントを増やすのではなく、評価（evaluation）をエージェントの構築・テスト・運用における主要なプロセスとして確立することでこの課題に答えました。

この記事では、その取り組みの軌跡を追います。システムアーキテクチャ、Databricks と MLflow 上で構築された評価フレームワーク、そして実際に現場で成果を発揮した事例について解説します。最後に、得られた結果と教訓についても触れていきます。

「エージェントをリリースすればいい」という発想がスケールする際に破綻する理由

高速で変化するビジネス環境では、「エージェントをリリースすればいい」という考え方は、スケールするまでなら機能しても、規模が大きくなるとすぐに破綻します。一日に 10 万件を超える AI エージェントによる問い合わせがある中で、わずか 1% のエラー率でも、毎日数千件の悪い結果を生み出し、実際の収益の損失につながります。

圧力は波のように不規則に押し寄せました。天候の急変、ディワリ祭（インドの明かりの祭り）、そして夏の始まりがチケット数の急激な増加を招きました。食品から衣類、電子機器、美容用品へと事業領域が拡大するにつれ、返金・交換・返品といった新たな顧客フローも生まれました。さらに、多様な言語を話す顧客基盤の拡大によりサポート要求の種類も多様化し、数週間ごとに新たな失敗パターンが表面化するようになりました。

根本的な問題は「保証ギャップ」にあります。エージェント型システムは意図の分類、知識の検索、入力分析、意思決定のための推論、トランザクションツールの呼び出し、回答生成といったマルチステップワークフローとして動作するため、最終的な回答だけでなく、プロセスのあらゆる段階で失敗が発生する可能性があります。

この保証ギャップが具体的な課題を生みました：

• 顧客からの苦情が出るまで失敗に気づけない
• 修正対応が遅い
• 最終回答が内部エラーを隠蔽してしまう
• エージェントのコスト・パフォーマンス・品質のバランスを取るための原則的な方法がない
• エージェント設計において、重要なステークホルダーの視点がすべて反映されていない
• エージェントの急速な進化に対応し、信頼性を保証することが困難

そこで明確になった目標は、Databricks と MLflow を活用した評価フレームワークを構築し、これをエージェントが構築・運用される基盤となるコア AI インフラとして機能させることです。

評価フレームワークとその成果について

強力な評価フレームワークは、本番環境での準備度に関する5 つの軸に直接的な影響を与えます：

信頼性：各ステップでエージェントが正しく動作するよう、システムレベルの保証を提供します。単に「正しそう」に見えるだけでなく、実際に機能することが重要です。

速度：プロンプト、ポリシー、モデルの変更を自動的に回帰テストすることで、より迅速かつ安全なイテレーションが可能になります。

コスト・品質・パフォーマンスの制御：制約条件の中で最適なバランス点を見つけるため、最適なモデルやプロンプト戦略、あるいはハイブリッドルーティング戦略を選択できる能力です。これは確固たる評価データによって裏付けられています。

ガバナンス：監査可能なトレース、バージョン管理された評価ベースライン、およびデプロイとロールバックのための明確な閾値を定義します。判断基準を「このバージョンの方が良い気がする」という直感から、「合意した指標においてベースラインを上回っている」という証拠へと移行させます。

ステークホルダーとの協力：ステークホルダーの視点から成功と信頼性の基準を捉え、トレードオフを全員が明確かつ測定可能にします。

評価を最優先とするエージェントアーキテクチャと、それを支える基盤としての Databricks と MLflow を活用した Zepto は、以下の成果を達成しました。

コストと効率性

• 人間の監督下で AI エージェントが完全に処理するチケットが 80% 以上
• サポートコストまたはサポートチケット数が 65% 削減
• 投資回収期間が 1 ヶ月未満

品質と評判

• カスタマー満足度 (CSAT) が 20% 向上
• 精度が 8% 向上

パフォーマンスと運用

• 開発サイクルが 3 倍 高速化
• 解決までの時間が 4 倍 短縮

信頼性と制御のための二重ループを構築する

このアプローチの中核にあるのは、開発用と運用用の二つのループです。これらは品質ゲートによって接続されており、両者がどのように連携するかを以下に説明します。

• 開発ループ: エージェントのバージョンを設計・反復・評価し、本番環境へのリリース前に確信を持って構築するためのプロセス
• 運用ループ: 本番環境での動作を監視し、障害を検知してエージェントを確実に稼働させるためのプロセス
• フィードバックループ: 運用中の障害を開発側へフィードバックし、次の反復のためのデータを充実させるプロセス
• 品質ゲート: ループ間の移動を制御し、本番環境への導入を許可するバージョンと、より良い反復のために開発側に戻すバージョンを判断する仕組み

これら二つのループにより、エージェントは確実な管理のもとで構築・運用されます。発生した障害は自動的に捕捉され、フィードバックされて修正されるため、エージェントは信頼性を持って構築され、制御された状態で稼働し、時間とともに本番環境での障害への対応能力を継続的に高めていきます。この二重ループこそが、当社のフレームワークの中核です。

フェーズ 0: トレーシングの活用による透明性の確保：設計段階からの透明なエージェント

すべてのエージェント呼び出しは、豊富な実行トレースを生成します。これにはプロンプト、生成結果、取得したドキュメント、ツール呼び出し、レイテンシ、意思決定経路などが含まれます。その結果、入力と最終出力のみならず、細粒度レベルで全体のワークフローを可視化することが可能になります。

MLflow を活用したハイブリッドアプローチにより、この仕組みを実現しました。単一の行 mlflow.<library>.autolog() を記述するだけで 自動トレーシング が有効になり、@mlflow.trace デコレーターを使用することで、より詳細な情報が必要な箇所に カスタムスパン を追加できます。トレーシングデータは一意の ID を持つ OpenTelemetry スパンとしてリアルタイムに出力されるため、柔軟に組み合わせが可能で、MLflow と Unity Catalog の連携によりログが Delta テーブルに一元化されます。

フェーズ 1: 評価基準の定義——柱とゲート

トレーシングを有効にした次は、各ステークホルダーの視点から「このエージェントにとって成功とは何か？」という問いを明確にすることです。これを評価の柱（ピラー）として形式化し、それぞれに具体的なゲートを設けます。

これにより、複数の関係者間での議論が、共通で測定可能な契約へと変わります。各ステークホルダーにとって実際に重要な次元に沿ってエージェントが評価されます。典型的な柱には、顧客体験、運用効率、リスクとコンプライアンス、財務への影響などが含まれ、それぞれの柱にはデプロイ前に満たすべき明確な数値基準が設定されています。

フェーズ 2: ゴールデンデータセット——信頼性の基盤

ゴールデンデータセット は、開発ループにおけるエージェントの振る舞いを評価するための唯一の真実源です。これは以下の要件を満たす必要があります：

エージェントが対応すべき通常ケース、エッジケース、そして失敗ケースをすべて網羅する

異なるステークホルダーからの期待事例を含める

シナリオタイプ、事業部門、リスクレベルなどのメタデータで詳細に注釈をつける

すべてのステークホルダーは、例えばセキュリティチームがプロンプトインジェクションやアイデンティティ攻撃、データ漏洩試行といった敵対的パターンに関する事例を提供するなどして、データセットの構築に参加します。これにより、信頼性は通常の利用だけでなく、現実世界のあらゆるシナリオに対して測定されます。

データセットは生きている資産であり、その品質は時間とともに複利効果で向上します。開発環境と本番環境での精度の差自体が、データセットの質を示す指標となります。Zepto は 6 ヶ月間にわたり MLflow の評価用データセットへの投資を継続し、事例数が 500 から 2,000、そして 5,247 に増加する一方で、開発と本番の精度差は 8 ポイントから 2 ポイント、さらに 0.4 ポイントへと縮小しました。データセットの品質向上に費やす 1 時間は、約 10 時間の生産環境でのデバッグ時間を節約することになります。つまり、黄金のデータセットは 10 倍の乗数効果を持つのです。本番環境で発生した不具合はすべて、その失敗痕跡を黄金のデータセットに追加し、将来のすべてのバージョンにおいてシステムをより堅牢なものにします。

フェーズ 3: プロンプトエンジニアリングの自動化：自動生成と最適化

手動でプロンプトを作成するのではなく、プロンプトエンジニアリングをデータ駆動型の自動化プロセスへと転換しました。プロンプト設計はエンジニアが最も時間を費やす重要なフェーズであり、プロンプトの質はエージェント出力の品質やパフォーマンスに不均衡なほど大きな影響を与えます。

MLflow のプロンプト最適化を活用し、初期のプロンプトを登録した上で、デプロイのゲートとなるスコアラーと同じ基準でバリエーションを生成・最適化します。その後、A/B 評価を自動実行して最良の結果を採用します。このオプティマイザーは、候補の評価に安価なモデルを使用しつつ、強いモデルと本番環境でのスコアリング結果を反映させることで、検索プロセス自体がコストを意識した状態を保ちます。これにより、手動によるプロンプトの実験が減り、精度が向上しました。また、本番環境へ展開される前に必ず「ゴールデンデータセット」に対して改善効果を測定できる仕組みも確立されています。

フェーズ 4: スコアラーの定義と AI ジャーシーの構築

生産ループにトレースが流れ込むようになった今、エージェントの品質に関わる重要な次元（評価指標）に沿ってスコアリングを行う必要があります。これは「AI の陪審員」のようなもので、各スコアラーが得意分野を発揮する仕組みです。MLflow では スコアラー を作成するための 3 つのオプションを提供しています。

• 組み込みジャッジ - すぐに使えるスコアリング機能
• カスタムジャッジ - 独自の要件に合わせて作成した専用ジャッジ
• コードベースのスコアラー](https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/custom-scorers) - ツール応答時間やツール呼び出し回数など、確定的な指標の評価に使用

人間のような判断が不可欠な場面では LLM ベースのスコアラーを採用し、論理的な処理で十分と判断される箇所には単純なルールベースのスコアリングを適用します。ジャッジは人間のラベルと比較して較正を行い、80〜90% の一致率を達成した上で、重要な意思決定においては複数のジャッジを活用しています。

フェーズ 5：モデルの選択肢を設定する

モデルの選択肢（Modal optionality）は、Databricks の設定でモデル名を変更するだけで、多くの独自開発モデルやオープンソースモデルを切り替えられるようにするフレームワークの中核要素です。これにより、開発ループの中でコスト、パフォーマンス、品質の最適なバランスを見つけるために、より良い組み合わせを継続的に探索することが可能になります。

フェーズ 6：自動回帰評価の構築

反復的で構成可能かつスケーラブルな開発ループを実現するため、回帰評価を自動化します。変更が発生すると自動的に回帰評価が実行され、信頼性が保証された場合は自動デプロイへと移行します。

これら要素を組み合わせた場合、通常の変更フローは以下の通りになります：

エージェントのロジック、プロンプト、またはモデルに変更を加えた場合、評価ワークフローは自動的にトリガーされます。この際、3 つの入力が用いられます。

• 新しいバージョンのエージェント
• ゴールデンデータセット
• 現在の生産環境ベースライン

システムは全スコアラーと各ピラーにわたって評価を実行し、指標を生成します。その後、品質ゲートがチェックされます。

• 新しいバージョンはすべての基準（コスト、品質、パフォーマンスなど）を満たしているか？
• 既存の生産環境ベースラインと比較して、同等以上、あるいはそれ以上の性能を発揮しているか？

もし両方の条件を満たせば、新しいバージョンが生産環境へプロモートされます。逆に条件を満たさない場合は拒否され、既存のエージェントが引き続きトラフィックを処理し続けます。

フェーズ 7：生産ループの構築 - リアルタイムセーフティネットの設置

全トラフィック（100%）を評価するのはコストがかかりますが、単純に 10% を均等にサンプリングするだけでは、ほとんどのエッジケースを見逃してしまいます。そこで私たちは層別サンプリングを採用しました。

評価対象のサンプリング率は、以下の条件に応じて動的に調整されます。

• 高価値顧客
• 新機能の利用
• 直近で変更されたフロー
• ネガティブな感情やエスカレーションリスクの高いケース
• 画像ベースのやり取りや不正行為が懸念されるインタラクション

この手法により、管理可能なコストで効果的な評価サンプル率 18〜20%（1 日あたり約 14,400 トレース）を達成しつつ、エッジケースの 45〜60% を検出し、問題発生から 4〜6 分以内に対応できる体制を整えています。

この財務的なロジックは非常に説得力があります。均等サンプリング方式と比較して、層別アプローチでは特定された課題あたりのレビューコストを 86% 削減し、エッジケース検出能力を 9 倍向上させました。これにより、品質保証プロセスは大幅に効率化され、スケーラビリティも確保されています。

評価結果は Delta テーブルに記録され、Databricks 上のダッシュボードやアラートルールを通じて可視化されます。5 分ごとにチェックされる重要アラートでは、意図の精度低下、根拠のない回答（グラウンデッドネス違反）、エスカレーションリスクの高まり、P95 レイテンシーの超過などを監視します。また、高・中優先度のアラートでは、共感性の低下、コスト急増、ツール故障率、CSAT の推移、不正検知率、マルチモーダル処理の遅延などを追跡します。これにより、AI エージェントに対する SRE（サイト信頼性エンジニアリング）のような運用が可能になり、迅速な検出、トリアージ、対策が実現されます。

構成可能なアーキテクチャを持つエージェントスタック

優れた評価フレームワークは、エージェントのアーキテクチャ自体が観測可能で分解しやすいように設計されて初めて真価を発揮します。Zepto のサポートスタックはこの考え方を基盤に構築されています。

チャットまたは画像形式での顧客問い合わせは、まずアジェンシーオーケストレーターとルーターを経由します。ルーターはいつでも人間担当者に引き渡すことができます。その下層では、システムは 2 つの種類のエージェントに分離されます。

垂直型エージェントは専門家で、それぞれが単一の明確な意図ファミリーを専有しています：

• WIMO: 注文追跡と到着予定時間（ETA）に関する質問に対応
• Missing: 未配送または部分的な配送の問題を担当
• Expiry: 賞味期限切れの包装食品に関する問い合わせを処理
• Returns: 返金ステータスと処理状況を確認
• Quality: 鮮度の低下や腐敗した農産物に関する対応
• Unable to Pay: ウォレット、プロモーションコード、決済失敗の問題を担当
• General: その他の汎用的な問い合わせ（フォールバック用）

水平型エージェントは、利用ケースを横断する監視レイヤーとして機能します：

画像の重複検出：主張間で再利用された画像を捕捉します。

アイテムマッチングと画像改ざん検出：アップロードされた画像がカタログ項目と一致しているか、また編集されていないかを検証します。

この分離は二重の効果をもたらします。各垂直領域のエージェントごとに指標を計算できます（例：WIMO 意図の F1 スコアや有効期限 OCR の精度）。一方、横断的なエージェントは不正検出の精度、画像の再利用、改ざん検出といった共通課題に対して評価されます。各機能は個別に、また組み合わせても測定可能です。

フレームワークの実践

AI エージェントを本番環境に初めて投入する際、それはまるで優秀だが予測不能な新人社員を会社の代表として送り出すようなものです。指示を与えて最善の結果を祈るしかありませんが、プレッシャーがかかるまで、実態は目隠しをして飛行しているような状態です。

当初、私たちは従来のソフトウェア監視が AI には全く役に立たないことに気づきました。サーバーの稼働率が完璧でエラーもゼロであっても、AI エージェントが怒った顧客に対して同じ間違った回答を繰り返す可能性があります。エンジニアにとってはダッシュボードは緑色（正常）ですが、顧客にとっては大惨事です。

私たちは「期待」に頼って AI をスケールさせることはできないと悟りました。単に AI が話しているかどうかを追跡するだけでなく、何を理解し、どこで失敗しているかを把握できる評価フレームワークが必要でした。以下の事例は、そのフレームワークが真価を発揮した瞬間です。優れた評価システムこそが、全く新しい製品機能の unlocks を可能にするのです。

話1：動かないETA

ある生産環境の問題で、ライダーが渋滞に巻き込まれたまま動けず、エージェントはキャッシュされたデータを読み込んで「あと10分で到着します」というメッセージをループして返していました。顧客が注文の行方を確認すると、同じ文言が返され、再度確認してもまた同じ答えでした。

トークンカウンター（利用状況の監視）と警告スコアラーが、この繰り返しが5分以内に検出され、エスカレーションリスクが高いことを察知しました。これにより、動かないライダーでETAが変わらないケースの痕跡が浮き彫りになりました。その結果、ルール変更が行われました。 rider が10分以上動かない場合、エージェントは正直な更新情報を提供し、古くなった約束を繰り返すのではなく、自発的に全額返金付きのキャンセルを提案するようになりました。

オンライン評価によって捉えられた一つの洞察が、一連の新機能へと発展しました。「遅延時のキャンセル」です。これは、ライダー不足時に顧客に自発的にキャンセルを提案する機能で、一定時間内にライダーが割り当てられない場合は自動キャンセルが行われ、高価値の顧客には理由を問わないキャンセルも可能になりました。

話2：顧客が発覚する前に検出されたキャンセル処理の回帰

Zepto が WIMO エージェントにキャンセル処理機能を追加した際、モデルは「注文はどこですか」「キャンセルしたい」「注文はキャンセルされましたか」という3 つの全く異なる意図を混同し始めました。

開発段階で MLflow による評価を実施したところ、すぐに問題が発見されました。全体の意図認識精度は約 92.1% から 87.4% に低下し、特に新しい WIMO_CANCEL や WIMO_CANCEL_STATUS の F1 スコアが低かったのです。しかし、この回帰現象はゴールドデータセットに対して検出されたため、顧客に届くことはありませんでした。プロンプトの最適化とデータセットの更新により、全体の精度は約 94.2% に回復し、元のベースラインを上回る結果となりました。また、キャンセル API におけるツール呼び出しの F1 スコアもほぼ完璧なレベルまで向上しました。この機能はロールバックゼロで本番環境にリリースされました。

ストーリー 3：人間の評価基準に基づくマルチモーダルエージェントの調整

品質評価は非常に難しく、人間の判断者同士ですら意見が一致しないことがあります。例えば、同じキノコの画像でも、ある評価者は 5 段階中 2 点と付け、別の評価者は 3 点を付けるケースがあります。私たちはこの不一致を Cohen's Kappa で測定し、モデルが学習する人間よりも一貫性が高まることはあり得ないため、これを信頼性の上限として扱いました。

また、AI が安全策に走っていることも判明しました。放任しておくと、難しい判断を避けるために 3 点付近のスコアが偏って積み上がる一方、人間の評価は 4 点や 5 点でピークを迎える傾向がありました。そのため、単に平均値に対する誤差を最小化するだけでなく、人間が付けるスコアの分布形状そのものを再現するように調整を行いました。

オンライン評価では、システムが想定していなかったケースも明らかになりました。例えば、パッケージ品として棚に並んでいるのに、生鮮食品のように判断すべき腐った牛乳や、写真では表現できない味や匂いに関する苦情などです。これらは別の処理パスへ振り分けられました。

この調整済みのベースラインにより、製品タイプごとにどのモデルを採用するかを決定し、人間の判断に対してプロンプトをどのように反復改善するか、また顧客セグメント別に実務者のパフォーマンスに基づいて返金ポリシーをどう調整するかを明確にできます。

ストーリー 4：悪用の抜け道を塞ぐ

返金不正の試みでは、カタログ画像や加工された写真、複数の請求で流用される画像が利用されていました。マルチモーダル評価パイプラインは、これらの画像に対してぼかし・明るさ・解像度に関する前処理チェックを実行し、OCR で検証した上で、3 つのビジョンモデルによる審議と合意ルールに基づき、自動承認か人間による審査かの判断を下します。その上層には、ぼかし検出、スクリーンショット検出、重複画像検出、画像と SKU の照合、画像と申告理由の整合性チェック、配送完了証明の検証といった複数の防御レイヤーが積み重ねられています。

大規模運用から得た教訓

このフレームワークを大規模に運用した経験から、クイックコマースに限らず汎用する数々の原則が浮き彫りになりました。

単一の指標の最適化は避ける

以前、意図認識精度だけを孤立して追求したことがありました。その結果、顧客満足度（CSAT）が低下する事態を招きました。意図認識のみを最適化すると、精度は 5 ポイント向上しましたが、レイテンシは 133% も増加し、CSAT は 0.4 ポイント低下しました。一方、複数の目的を組み合わせた複合スコアを採用したところ、意図認識精度は 3 ポイント向上しつつ、レイテンシの増加はわずか 17% に抑えられ、CSAT は 0.2 ポイント改善されました。LLM（大規模言語モデル）による判定、ルールベースのチェック、人間のラベル付け、そして本番環境のメトリクスなど、多角的な視点と複数の評価手段を組み合わせることで、真実が浮かび上がります。この冗長性は無駄ではなく、リスクヘッジのための保険なのです。

ゴールデンデータセットは基盤である

初期段階で投資を行い、数千件に及ぶ多様で高品質なサンプルを集めることが重要です。開発環境と本番環境での精度の差を常に追跡し、両者が収束するまで調整を続けましょう。開発と本番の精度の乖離は謎ではなく、データセットの質を示す明確なシグナルです。

LLM による判定にはキャリブレーションが必要

判定を行う LLM もまた一つのモデルであり、それ自体の評価が必要です。人間との合意度を測定し、重大なケースではアンサンブル手法を活用しましょう。さらに、基盤となるモデルが更新されるたびに再調整（キャリブレーション）を怠らないようにしてください。

サンプリング戦略はサンプリングレートよりも重要

単純な均一サンプリングは安価ですが、盲点があります。一方、高リスクのフローに焦点を当てた層別サンプリングでは、コストあたりの問題検出率が桁違いに向上します。

フィードバックループは初日から自動化せよ

検知、ラベル付け、再学習、デプロイ、監視という一連のプロセスはすべて自動化すべきです。発生したすべての失敗事例が、次の学習ラウンドを自動的に強化する仕組みを作りましょう。私たちの場合、これにより月間約 155 時間の工数を節約でき、その分を機能開発に専念できるフルタイムエンジニア 2 名分のリソースを生み出すことができました。

評価を製品の一部として扱う

ダッシュボードや指標は、サポート、プロダクト、不正検知、運用チームなど多様な組織内で利用されます。そのため、単に技術的に正確であるだけでなく、誰が見ても理解でき、具体的なアクションにつながるものである必要があります。

エージェント構築者への推奨事項

Databricks上でエージェントシステムを構築する組織にとって、Zeptoの経験から以下のロードマップが示唆されます。

• モデルだけでなくトレースから始める：共有されるトレーススキーマを定義し、すべてのデータをDeltaにログとして記録する
• MLflowによる評価をCI/CDの必須ゲートとする：合意された指標でベースラインを上回る結果が出なければデプロイしない
• ゴールデンデータセットを資産として構築する：所有権を持つKPI（サイズ、開発環境と本番環境の乖離、エッジケースのカバー率など）を設定する
• 人間が評価している項目（品質、共感力、根拠のある回答）についてはLLM-as-judgeを活用するが、適切なセグメントに限定し、キャリブレーションを行う
• 層別サンプリングとリアルタイムアラートの導入をできるだけ早期に行う。運用上の可視化機能を後から追加するのはコストがかかる
• エージェントアーキテクチャは、垂直方向（特化型）と水平方向（監督・管理型）の両方を組み合わせることで、個別の評価と統合時の評価の両方が可能にする

結論

実験的なデモからミッションクリティカルな基盤へと移行する過程で、最大の制約要因はモデルの純粋な能力から「システムの保証」へとシフトしました。Zepto の取り組みが示すのは、評価（evaluation）を開発の基本要素として確立することで、組織は多様な入力に対応する数万件もの複雑な日常業務をエージェントに任せることを信頼性高くスケールできるということです。これには、品質、コスト、リスク低減に関する厳格な保証が伴います。

Databricks と MLflow は、この進化を支える不可欠な基盤です。Unity Catalog や Delta 上でトレーサビリティ（追跡可能性）に焦点を当てたデータインフラを提供し、スケーラブルな評価機能、自動的なプロンプト最適化、そしてシームレスな CI/CD 統合を実現しています。このように組み立て可能なスタックとモデルの選択肢を組み合わせることで、チームは各タスクごとにパフォーマンスとコストの最適なバランスを微調整することが可能になります。

究極的に競争優位性を握るのは、「評価」を最終的なチェック項目ではなく、コアとなる AI インフラとして捉えるという戦略的判断です。本番環境で動作する大規模エージェントを運用するための設計図はもはや謎ではありません。Zepto と Databricks がその答えを示しました。今求められているのは、その導入スピードです。急速に進化する AI の風景において、真のリーダーは完璧な確実性を待つ人々ではなく、最初の日から信頼性の構築に着手する人々になります。

生産環境で信頼を獲得するエージェントを開発するビルダーにとって、これらの基盤となる要素は Databricks と MLflow 3 で既に利用可能です。次のフロンティアを定義するのは、今日から評価ファーストの取り組みを開始する組織です。

Databricks でエージェントを構築

MLflow の評価とモニタリングの入門