DoorDashがLLMで6万個のフラグを自動削除！負債解消の劇的コスト削減術

• DoorDashがマルチエージェントLLMを活用し、6万個のフィーチャーフラグを自動削除するシステムを構築した。
• Claude SonnetとOpusを組み合わせ、MCP経由で実験データと連携し、1件あたり平均13.8分でPRを作成する。
• 複雑な依存関係も自動処理し、50件の評価で成功率90%を達成。手動作業の1/5以下の時間とコストを実現した。

深夜の障害対応中、原因が「3年前に放置されたフィーチャーフラグ」だったと判明した時の絶望感を知っているだろうか。コードのあちこちに散らばる条件分岐は、まさにスパゲッティコードの温床であり、我々エンジニアにとっての「時限爆弾」だ。DoorDashが直面していたのは、まさにこの極限状態だった。623のリポジトリにまたがる6万個ものフィーチャーフラグ。毎月2,300個が新規生成される一方で、放置された「ステイル（死んだ）フラグ」が1,000個以上もコードベースを汚染していた。

従来の静的解析ツールやUberのPiranhaのようなルールベースのアプローチでは、DoorDashの複雑な依存関係注入（DI）パターンを突破できなかった。フラグの定義、クライアント呼び出し、ビジネスロジックが複数のファイルに分散し、一つのフラグを消すために5〜20ファイルの修正が必要になる。これはもはや人間が手作業で追跡できる複雑さではない。DoorDashが今回採用したのは、単なるLLMのチャットボットではない。GoogleのAgent Development Kitを基盤とし、Claude SonnetとOpusを適材適所で使い分ける「マルチエージェント・オーケストレーション」だ。

このシステムが画期的なのは、単にコードを書き換えるだけでなく、実験プラットフォームのメタデータ（ロールアウト率やターゲット値）をModel Context Protocol（MCP）経由でリアルタイムに取得し、意思決定の根拠としている点にある。エンジニアは「AIが提案した削除案」をレビューするだけでいい。この「人間による承認」というゲートキーパーを挟むことで、AIのハルシネーションによる破壊的な変更を未然に防いでいる。我々が学ぶべきは、AIを「コードを書かせる道具」としてではなく、「複雑な依存関係を解き明かすコンテキスト・エンジン」として活用するこのアーキテクチャの設計思想である。

「AIによる自動化はコストが見合わない」という懐疑論を、DoorDashは冷徹な数値で粉砕した。今回の検証対象となった50個のステイルフラグにおいて、システムは45個の有効なプルリクエスト（PR）を生成した。特筆すべきは、その処理コストとスピードだ。1件あたりの平均処理時間はわずか13.8分、コストは4.79ドル。人間が手作業で行えば1〜2時間を要するタスクを、圧倒的な効率で完遂している。この数値は、単なる生産性向上を超えた「開発体験（DevEx）の再定義」を意味している。

特筆すべきは、複雑度に応じた成功率の高さだ。以下の表は、DoorDashが公開した検証結果の要約である。

この結果が示唆するのは、AIが「単純作業の自動化」というフェーズを完全に卒業し、「複雑なロジックの理解とリファクタリング」という領域に踏み込んでいるという事実だ。もちろん、5件の介入が必要だったケースでは、深いコールチェーンやインターフェースを跨ぐパラメータの受け渡しといった、人間でも追跡が困難な箇所で苦戦している。しかし、バグやリグレッションがゼロであったという事実は、隔離されたGitワークツリーでの実行、JaCoCoによるカバレッジ計測、Detektによる静的解析という「多重の防壁」が機能している証左である。我々が自社のCI/CDパイプラインにAIを組み込む際、この「検証の多層化」こそが、AIを信頼するための唯一の解となるだろう。

DoorDashの事例は、単なる「フラグ削除の自動化」というニュースではない。これは、ソフトウェア開発の現場において「人間がコードの細部を管理する時代」が終わりを告げつつあることを示している。我々エンジニアは、これまで「コードを書くこと」に多くの時間を費やしてきたが、今後は「AIが生成した変更の妥当性を評価し、システム全体の整合性を担保するアーキテクト」へと役割をシフトせざるを得ない。しかし、ここで一つの痛烈な問いが浮かび上がる。AIが自動的にコードを消し去り、リファクタリングを行う世界で、我々は「なぜそのコードが存在したのか」という歴史的文脈をどこまで保持し続けられるのか。

フラグを消すことは、過去の実験の痕跡を消すことと同義だ。もしAIが誤った判断で重要なロジックを削除してしまった場合、その責任は誰が負うのか。DoorDashは「エンジニアの承認」をプロセスに組み込むことでこのリスクを回避しているが、これはあくまで過渡的な対策に過ぎない。真の課題は、AIが生成したコードの品質を、人間が「直感」ではなく「客観的なデータ」で評価できる仕組みを構築できるかにある。明日から我々が取るべき対策は明確だ。まずは自社のコードベースに潜む「死んだコード」を可視化すること。そして、AIを単なるコード生成ツールとしてではなく、MCPのような標準化されたプロトコルを用いて、外部ツールと連携する「自律的なエージェント」としてCI/CDパイプラインに統合する準備を始めることだ。

技術的負債を放置することは、将来の自分たちに対する背信行為である。AIという強力な武器を手にした今、我々は「負債を返済する」という泥臭い作業を、AIに委ねることで解放されるべきだ。しかし、その解放の代償として、我々は「AIの判断を監視し、制御する」という、より高度な知的能力を求められている。あなたは、AIが書き換えたコードを、自信を持って本番環境へデプロイできるだろうか？その問いに対する答えこそが、これからのエンジニアとしての生存戦略を左右するはずだ。