Uber Eatsが検索パイプラインを刷新、レイテンシ50%削減の裏側にある泥臭い最適化

• Uber Eatsが検索パイプラインを刷新し、エンドツーエンドのレイテンシを50%削減することに成功した。
• バックエンドのAPI応答時間ではなく、ユーザー体験に直結する「Above-the-Fold（ファーストビュー）の描画完了時間」を指標に据えた。
• 不要なデータ取得の排除、Go言語のGC最適化、広告配信のインメモリ化など、地道な積み重ねが劇的な改善を生んだ。

多くのエンジニアが陥る罠がある。それは、バックエンドのAPI応答時間（Latency）を最適化すれば、ユーザー体験が向上するという幻想だ。しかし、Uber Eatsの今回の事例は、その前提を根底から覆した。彼らが最初に行ったのは、計測指標の変更である。従来の「サーバーサイドの処理時間」という指標を捨て、ユーザーが実際に画面を目にするまでの「Above-the-Fold（ファーストビュー）の描画完了時間」を最優先のKPIに据えたのだ。これは、我々が普段の業務で「APIは速いのに、なぜかUIの表示が遅い」という現象に直面した際、フロントエンドとバックエンドの境界で発生している「見えない待ち時間」を可視化したことに他ならない。

具体的には、ページネーションにサーバーサイドキャッシュを導入し、初期レスポンスを高速化。さらに、非同期レンダリングを駆使して結果アイテムを並列処理することで、Above-the-Foldのレイテンシを200ミリ秒以上短縮した。これは単なるチューニングではない。ユーザーが「検索ボタンを押してから、最初の料理画像が表示されるまで」の体験を、アーキテクチャの設計思想の中心に据えたというパラダイムシフトである。我々エンジニアは、往々にして「処理の速さ」という自己満足的な指標に逃げがちだが、Uber Eatsの事例は、真のパフォーマンスとは「ユーザーが待たされていると感じる時間をいかに削るか」という一点に集約されることを証明している。

さらに、彼らは「Measure, Identify, Fix, Validate」というループを徹底した。このプロセスは、単なるバグ修正のサイクルではなく、継続的なパフォーマンス最適化のモデルとして機能している。特に注目すべきは、彼らが「何か一つの魔法のような技術」に頼ったわけではないという点だ。Anubhooti Nagar氏が指摘するように、これは「速く動かすこと」ではなく「無駄な仕事を減らし、不要な待ち時間を回避すること」に注力した結果である。我々の現場でも、複雑なクエリを投げる前に、そもそもそのデータが必要なのか、あるいはキャッシュで代替できないのかを問い直すだけで、劇的な改善が見込めるケースは少なくないはずだ。

今回の刷新で最も興味深いのは、その改善手法の「泥臭さ」だ。Uber Eatsは、検索パイプラインにおいて「数万件もの候補をランキング前にハイドレーション（データ補完）し、その多くを結局破棄していた」という非効率な処理を特定した。これは、まさにスパゲッティコードの温床であり、メモリとCPUを無駄に食いつぶす典型的なアンチパターンだ。彼らはこの不要な検索戦略を排除することで120ミリ秒を削り、さらに製品レベルの埋め込み（Embeddings）を活用してデータルックアップを100倍以上効率化し、50ミリ秒を捻出した。こうした「地味だが確実な」改善の積み重ねこそが、50%という驚異的なレイテンシ削減の正体である。

技術的な詳細に目を向けると、広告配信パスの刷新も特筆すべき点だ。カラム指向の入札データ構造を採用し、インメモリでのアクセスを強化、さらにシリアライズのオーバーヘッドを最小化したことで、130ミリ秒の短縮を実現している。また、Go言語のデータ構造を見直してガベージコレクション（GC）の負荷を軽減するなど、言語レベルの特性を深く理解した最適化も行われている。これは、高レイヤーのフレームワークに依存しがちな現代のエンジニアにとって、改めて「言語のメモリ管理やデータ構造の選択が、大規模システムにおいてどれほど重要か」を突きつける教訓と言えるだろう。

さらに、彼らは「ランキングのハイドレーション」と「プレゼンテーションデータ」を分離した。これにより、ランキング計算に必要なデータと、UI表示に必要なデータを切り分け、依存関係を排除した。この「疎結合化」こそが、並列処理を可能にし、リクエストヘッジング（複数のバックエンドにリクエストを投げ、最も速い応答を採用する手法）を効果的に機能させた。Pratik Dhanave氏が述べる通り、これは「一つの大きなアイデア」ではなく、「フルスタックにわたる慎重な意思決定のリスト」の結果である。我々が明日から取るべき対策は、最新のAIツールを導入することではなく、自らのシステムの依存関係を可視化し、不要な同期処理を一つずつ剥がしていくことではないだろうか。

Uber Eatsの挑戦はここで終わらない。彼らは現在、エンドツーエンドのマイクロバッチング、Zero Pass Ranking、そしてHTTPマルチパートストリーミングといった、より高度な最適化を模索している。特にマイクロバッチングは、処理ステージ間の同期を減らすための手法であり、AIシステムで用いられるパイプライン処理の概念を検索エンジンに応用したものだ。これは、処理ステージが前のステージの完了を待つのではなく、オーバーラップして実行されることを意味する。このアプローチにより、p99レイテンシで50%以上の削減を達成しているという事実は、今後の大規模分散システムにおける標準的な設計思想になる可能性が高い。

しかし、ここで我々エンジニアが自問すべきは、「なぜこれほどまでにレイテンシを削る必要があるのか」という点だ。単なる数字の遊びではない。Uber Eatsのようなプラットフォームにおいて、検索の遅延は即座にコンバージョン率の低下、ひいてはビジネスの損失に直結する。AIエージェントがユーザーの代わりに買い物をする「Cart Assistant」のような機能が普及する未来において、検索パイプラインは単なる「検索結果を返す場所」から「AIが意思決定を行うためのリアルタイムなデータ供給源」へと変貌を遂げている。この文脈において、レイテンシは単なるパフォーマンス指標ではなく、AIの推論精度やエージェントの応答速度を左右する「生命線」となる。

読者諸君に問いたい。あなたのシステムは、AIエージェントが秒単位でリクエストを投げてきたとき、耐えうる設計になっているだろうか？「今のままで十分速い」という慢心は、技術的負債を蓄積させるだけだ。Uber Eatsの事例から学ぶべきは、最新技術の導入よりも先に、既存のパイプラインにおける「無駄な待ち時間」を徹底的に排除する姿勢である。明日から、自らのコードをプロファイリングし、不要な依存関係を一つずつ断ち切ることから始めてほしい。システムが複雑化するほど、シンプルさこそが最強のパフォーマンスチューニングになるという真理を、我々は決して忘れてはならない。