1回の注文の裏で何が起きているか

Turn 2 が肝心：カートウィジェット上のポチポチ編集はすべてカート・オブジェクトを直接更新し、AI の往復は発生しない。いちばん重い「AI 呼び出し」を大半の操作から外している。

DoorDash 公式ブログの呼び出しトレース図：1回の食料品リクエストに連なる AI 呼び出しとツール呼び出し。 · 出典：DoorDash エンジニアリングブログ

4層アーキテクチャの役割分担

「エージェントロック」という細部がある：前ターンが買い物体なら、今ターンの「カートに入れて」は食料品エージェントへ寄せたままにし、意図が明らかに変わるまで切替えない。各エージェントは Google の Agent Development Kit 上で動き、モデルは役割ごとに設定。問題があれば役割単位で差し替え、新バージョンを配らなくてよい。

DoorDash Assistant ランタイム図：クライアント、Gateway、オーケストレーター、ドメインエージェント、その下のマネージドサービスとツール層。 · 出典：DoorDash エンジニアリングブログ

4本のエンジニアリング柱：知能（記憶とパーソナライズ）、評価、プラットフォーム（ランタイムとツール）、UX。 · 出典：DoorDash エンジニアリングブログ

記憶システム：エージェントに「あなたが誰か」を覚えさせる

3層だけでは足りない。AI はまず「今ターンはどの記憶を引くか」を決める必要がある。DoorDash はこの過程を4段階に分けた：

「チキンティッカマサラを作りたい」を通すと：①意図解析でレシピ要求と判定し、ブランド/分量の嗜好を引き、近くの店は見ない。②クエリ計画で「キーワードでブランド」「意味検索で分量履歴」に分け、食料品関連ブロックだけを探す。③検索順位付けを並列実行し、最近確定した「2人分をよく買う」を上に。④「2人分・Oatlyをよく買う・肉なし」など数行の構造化事実をプロンプトへ。エージェントは数百件の履歴を全部載せない。クエリ計画は3軸でパラメータ化：意味類似/キーワード厳密/構造化フィールド、どの記憶区画か、件数・類似度しきい値・時間窓。

キーワード検索を効かせるため、会話開始時にそのユーザーの現在記憶に実在する語の目録（Memory Bank Index）をプロンプトへ入れる。目録にない語を探すとトークンを無駄にするだけ。注文履歴のような巨大ブロックでは、まず軽量の「ざっと見」で件数や可用性を取り、全文を読む価値があるか決めてから入れる。

記憶と棚の現実がぶつかったら、どちらが譲る

記憶と今の現実は別物。「いつも Oatly」でも最寄りに在庫がなければ代替を探す。「60ドル予算」でも最低72ドルなら、偽の60ドルに合わせず事実を伝える。この照合は別レイヤではなく、同一ターンで嗜好を取り出し、検索・カートツールのリアルタイム価格・在庫・営業時間と突き合わせ、衝突したら現実側に寄せる。

3層記憶はリズムが違う：長期はオフラインバッチ、セッション内はリアルタイム、対話記憶は口頭で言った嗜好。 · 出典：DoorDash エンジニアリングブログ Part 2

記憶システム構成図：生成・ツール編成・保存・アクセス方針から各エージェントへの供給まで。 · 出典：DoorDash エンジニアリングブログ

記憶はどう沈殿し、どう精密に忘れるか

一言が使える記憶になるまで

「これは友達用で今夜だけ」のような一回限りはスキップし、長期記憶に入れない。基準はシーンで変わる：レストランで「ラーメンはいい」は一時の気分とみなし、always/never などがなければ覚えると以後ずっと麺を避ける害になる。食料品では「Oatly が好き」は長期のブランド信号。価格感度はユーザーが能動的に言った時だけ（「Safeway の安いのは？」など）。AI が安い店を勧めて受け入れただけでは、その人の持続的な判断とはみなさない。

「忘れる」は「覚える」より難しい

「Nova のチーズ焼きが好きなのを忘れて」を類似度やキーワードだけで消すと、Nova やチーズに関する、まだ残したい記憶まで一緒に消しやすい。

削除は保存と違う。保存は非同期で遅延を足さず、削除は同期。エージェントは返信で何件消したかをすぐ言える。統一の有効期限もない：食用油は80日前でも台所にある確率が高く、牛乳は12日前なら飲み切っている確率が高い。ベジなど本人が言った嗜好には TTL がなく、本人が変えるまで残る。寿命は中身次第で、一律の減衰式は使わない。

エージェントが本当に頼れるとどう知るか

評価は層ごとに分ける：ルーティング、ガードレール、ドメイン能力を独立に測り、構造は本番ランタイムの鏡。 · 出典：DoorDash エンジニアリングブログ Part 3

評価システム構成図：rubric、トレース、AI ジャッジなどがどう1つの評価系になるか。 · 出典：DoorDash エンジニアリングブログ

評価システムが2つの本番インシデントでどう効いたか

事例①：AI がコードを読み上げているみたい

事例②：モデルを換えたら点数が落ちた

Gemini 3.5 Flash 発表時、DoorDash のエージェントは Claude Sonnet 4.6 上だった。Flash のベンチは速そうで遅延削減のため乗り換えを検討したが、基盤モデル変更は高リスクで、品質が落ちないことを先に検証してから公開する必要があった。

原因は能力不足ではなくフォーマット互換：Flash は一部ツール引数を Sonnet と違う形（文字列のところを JSON オブジェクトなど）にし、システムプロンプトの暗黙の約束を Sonnet は補完できても Flash は読めなかった。修正も対症：ツール入力に決定的な補正を入れ、不正フォーマットを捨てずに直す／プロンプトに「店舗名はデータどおり、加工しない」などを明示。再評価で点数は Sonnet と誤差が評価ノイズ内で並んだ。公開後の品質・関与指標でも遅延35%減、品質は下がらなかった。

この仕組みは何をもたらすか

業務ロジックを共有 MCP ツール層に置くと、検索・カート・在庫ツールを社内の他 AI 機能チームがそのまま使える。バックエンドを一度上げれば上層エージェント全員が恩恵を受け、チームごとに再接続しなくてよい。

記憶は独立ツール層で、特定エージェントの専有ではない。買い物対話で「この家は全員ベジ」を学んだら、予約や出前推薦の他エージェントがすぐ使え、抽出・重複排除・検索を各チームがやり直さなくてよい。

自動評価で回帰が6時間→20分になり、モデルやプロンプトの変更を数十分で検証できる。「基盤モデル載せ替え」のような高リスクも、低リスクのオフラインで通してから本番ユーザーへ出せる。

カート編集を版付きオブジェクトへ直接更新し AI 往復を省くのは、モデルが速くならなくても E2E 遅延を下げる考え方で、「AI＋リアルタイム在庫/価格」系アプリにそのまま持ち運べる。

本番データは何を語るか

以前は1週間分をアプリで1点ずつ検索して追加。いまは一言。

時間短縮の工夫もある：カート上のブランド差替え・数量・家にある物の削除はデータを直接更新し AI を通さないので速い。ただし「一言で車を満載」は簡単に見え、DoorDash は2つの難題——あなたを覚えさせること、本当に頼れるかを測ること——を解く必要がある。

まず難題①：正しい瞬間に、あなたに関する正しい数件だけを思い出させる。

小互の一言に、AI はゼロから推測しない。数百の記憶から関連数件（ベジ・Oatly・2人分）だけを抜き、不要は詰めず、棚の在庫と価格を見て1台を組む。同じ記憶は精密に忘れもする：「この嗜好を忘れて」と言えばその1件だけ消し、隣を誤削除しない。

難題②：AI は頼れるか？以前は社員の散発フィードバック（1日約1件）だけ。いまは AI が何千人もの客を演じ、別の AI ジャッジが採点し、1日2000回超「試験」する。記憶＋評価がもたらす効果は、