DoorDashが社内5000人規模で実証したLLMゲートウェイ設計術

• DoorDashが社内5,000人超へ展開するLLM Gateway基盤の設計と運用知見を公開
• OpenAIからAzure、ClaudeからBedrockへの自動フォールバックと厳密な部門別コスト追跡を実装
• Notebook前提のML文化を脱却し、単一SDKによるAPI抽象化で全社的な生成AI活用を加速

2023年春、OpenAIとの巨額契約書にサインする手の震えから、DoorDashの生成AIプラットフォームの歴史は始まった。当時の機械学習インフラチームが直面した最大の誤算は、モデルの性能でもGPUの枯渇でもない。「プラットフォームの顧客が誰なのか」という前提そのものの崩壊だった。MLエンジニアを前提に『Jupyter Notebookを使って検証してくれ』と案内した瞬間、プロダクト開発者から『Notebookとは何か？』と聞き返されたときの衝撃は、我々エンジニアの記憶に深く刻まれている。

この失敗を機に、DoorDashのチームは根本的なパラダイムシフトを決断した。機械学習の専門家だけが触る閉じたインフラを捨て去り、全社向けの「APIファースト」「SDKファースト」のアーキテクチャへと舵を切ったのだ。開発者が求めていたのは、GPUインスタンスの割り当てやPython環境のデバッグといった泥臭い配管作業ではない。既存のWebサービスやマイクロサービスから、REST APIや型定義されたSDKを介して即座に呼び出せるシンプルなインターフェースだった。

さらに特筆すべきは、社内チャットボットやコード生成エージェントといった流行りの機能開発に逃げず、「ビジネスインパクトへの直接的な貢献」にスコープを絞り込んだ点である。業務自動化によるボトムライン（運用コスト）の削減と、パーソナライゼーションや推薦エンジン強化によるトップライン（売上）の拡大という2軸に集中し、プラットフォームの価値を「精度（Accuracy）」「レイテンシ（Latency）」「コスト（Cost）」の三者最適化と明確に定義した。その結果、現在では5,000人を超える社内ユーザーを抱え、毎日45人が新規オンボーディングする巨大基盤へと成長した。驚くべきことに、その利用者の40%は法務や営業、オペレーションといった非エンジニア組織が占めている。Notebookを捨て、使い慣れたAPIとSDKへ抽象化レイヤーを引き上げたことこそが、全社展開を可能にした最初の勝因であると私は考える。

生成AIを本格的にプロダクション環境へ組み込もうとした瞬間、エンジニアの前に立ちはだかるのは「プロバイダのクォータ制限」と「突然のダウンタイム」という冷徹な現実だ。OpenAIのAPI制限で深夜にアラートが鳴り響き、ユーザーリクエストが5xxエラーで次々とドロップしていく光景は、もはや我々にとって悪夢以外の何物でもない。各開発チームが個別にAPIキーを発行し、プロバイダごとの仕様差異を吸収するグルーコードを量産していては、開発速度の低下と障害の連鎖は避けられない。

DoorDashがこの課題に対して導き出した解が、すべてのモデルアクセスを集約する単一のプロキシレイヤー「LLM Gateway」の構築だった。開発者は単一のSDKとエンドポイントに向かってリクエストを投げるだけでよく、背後にあるモデルがOpenAIのGPTシリーズなのか、AnthropicのClaudeなのか、GoogleのGeminiなのか、あるいは自社ホストのオープンソースモデルなのかを意識する必要がない。モデルの世代交代が数ヶ月単位で巻き起こる現在において、SDK側のパラメータを1行書き換えるだけで最新モデルのA/Bテストや性能検証が完了する俊敏性を実現した。

そして技術的ハイライトと言えるのが、クラウドを跨いだ「自動フォールバック機能」の徹底である。DoorDashのゲートウェイは、OpenAIの公式エンドポイントに障害やレートリミットが発生した際、自動的にMicrosoft Azure上のAzure OpenAI Serviceへとトラフィックをリルートする。同様に、AnthropicのAPIに遅延やエラーが生じれば、即座にAWS Bedrock上のClaudeエンドポイントへと切り替わる仕組みをプラットフォーム側で担保した。プロダクト開発者にリトライやフォールバック処理のコードを書かせるのではなく、インフラの配管（plumbing）として透過的に高可用性を提供する。この徹底した職人芸的な抽象化こそが、ミッションクリティカルなデリバリー事業を支える基盤の真髄だ。

社内での生成AI利用が急速に拡大したとき、エンジニアリング組織が次に直面するのは「財務部門（Finance）からの査問」である。全社共通のAPIキーを配り、自由にプロンプトを叩かせた結果、月末に届いた請求書を見て経営陣が青ざめるという事態は、多くのテック企業で繰り返されてきた悲劇だ。「誰が、どのプロダクトの、どの機能のために、いくら消費したのか」がブラックボックスのままでは、プラットフォームとしての説明責任を果たすことはできない。

DoorDashのLLM Gatewayは、初期設計の段階から「コスト帰属（Cost Attribution）」を中核機能として組み込んだ。ワークスペース単位で利用チームを厳密に分離し、APIリクエストごとに消費された入力トークン数、出力トークン数、モデル種別をメタデータとともにリアルタイムで追跡する。これにより、発生したインフラ費用を各事業部門の予算へダイレクトに按分（チャージバック）できる体制を確立した。コスト意識が希薄になりがちな開発現場に対し、明確なアカウンタビリティを突きつける仕掛けをインフラレベルで埋め込んだのだ。

現在、Courseraなどの先進企業が全社的な生成AI戦略を展開する動きを見せる一方で、多くの現場ではモデル呼び出しコストとインフラ運用費の肥大化が深刻な課題となっている。DoorDashのように、ゲートウェイ層でルーティング制御とコスト監視を一元管理するアーキテクチャは、もはや単なる便利ツールではなく、企業が生成AI投資でROIを成立させるための「生命維持装置」であると私は確信している。

DoorDashのプラットフォーム進化の軌跡は、我々に極めて重い問いを投げかけている。あなたのチームが今書いているLLM呼び出しコードは、半年後にプロバイダがAPI仕様を変更したとき、あるいはより安価で高性能なオープンモデルが登場したときに、破綻せずに生き残れるだろうか。各リポジトリに散乱した生のリクエストコード、チームごとにバラバラに管理されたAPIキー、そして誰も把握していないトークン消費量。これらは数年後、過去のモノリスレガシーを凌駕する巨大な「AI技術負債」となって我々の首を絞めることになる。

明日から現場のエンジニアが着手すべき具体的な処方箋は明確だ。まずは直接プロバイダのSDKをアプリケーション層から叩くのを即刻やめ、オープンソースのLitellmや自作の軽量リバースプロキシでも構わないため、トラフィックを束ねる「単一のGateway抽象化レイヤー」を挟むことだ。そして、リクエストヘッダーに必ずサービス名や機能IDを付与させ、トークン消費のトレーサビリティを確保せよ。

AIエージェントや推論モデルが台頭し、モデルへの問い合わせ回数が幾何級数的に増加していく未来において、インフラの信頼性と経済性を担保するプラットフォームエンジニアリングの規律を持たない組織は、早晩そのコストと障害の重圧に耐えかねて自壊するだろう。我々はモデルの華やかな進化に目を奪われる前に、泥臭い配管の堅牢性をどこまで高められているだろうか。