DoorDashが、2段階のマルチエージェントLLMシステムで古い機能フラグの削除を自動化した。テスト50件のうち45件でエンジニアの承認を得たプルリクエストが生成され、フラグ1件あたり平均4.79ドル、13.8分で完了している。社内で手作業した場合は1〜2時間かかる作業だ。成果はDoorDashのエンジニア、Atharv Chandratre氏とJai Datar氏によるICSME 2026インダストリートラック論文で公開された。
要点
- システムは古いフラグ50件のうち45件を実用に足るプルリクエストへ変換した。全体で90%、最も複雑なケースでも85%の成功率を記録している。
- Claude SonnetのオーケストレーターがMCP経由で削除計画を立て、実際のコード修正はClaude Opusのエージェントが担う。エージェントは各自のgit worktreeで最大4件まで並列に動く。
- ビルド、テスト、パッチカバレッジ95%、静的解析をローカルですべて通過するまでプルリクエストは作られない。
623リポジトリに積もった死んだフラグが保守の負担になった理由
機能フラグはランタイム設定である。段階的なロールアウトを制御し、実験群を分け、手動のキルスイッチとしても働く。機能が完全にリリースされれば、フラグの役目は終わる。それでも分岐ロジックは死んだ重しとしてコードベースに残り、誰もテストしない休眠状態の経路が誤って再び有効化されかねない。
手作業を不可能にしているのは規模だ。論文は623のリポジトリに5万6000を超える機能フラグが存在し、2025年5月時点でそのうち1659件が放置状態だったと集計している。DoorDash自身のエンジニアリングブログによれば、現在プラットフォーム上の動的な値は6万を超え、毎月およそ2300件が新たに作られている。著者らは、ルールベースの削除ツールではDoorDashのコードベースに歯が立たなかったと記す。フラグを正しく取り除くには、シンボルのパターンマッチではなく、周囲の条件分岐がどの値に収束するかを推論する必要があるからだ。
2段階エージェントシステムの仕組み
第1段階は計画である。Claude Sonnetで動くオーケストレーターエージェントがJiraのチケットを取得し、MCPで実験基盤からロールアウトの実データを照会し、リポジトリ全体を意味単位で走査したうえで、フラグをどの値に置き換えるかを明示した構造化された計画を出力する。コードに触れる前にエンジニアがその置換値を確認する。このループで人間が関わる唯一の地点だ。
第2段階は外科手術にあたる。確定した値ごとに削除エージェントを1つ割り当て、Claude Opusで動かす。1リポジトリあたり同時に最大4件で、各エージェントは別々のgit worktreeで作業するため並列の修正が衝突しない。Gradleは--no-daemonで実行してビルド状態がworktree間に漏れないようにし、エージェントごとに1時間のハードタイムアウトを設ける。
興味深いのはゲートの部分だ。エージェントがプルリクエストを作るには、ビルド、テストスイート、JaCoCoによるパッチカバレッジ95%の下限、Detektの静的解析を通���しなければならない。1つでも落ちればPRは生成されない。モデルの使い分けは明確に経済的な判断である。安いモデルがメタデータ収集と計画を担い、高価なモデルはコールチェーンの推論と実際の修正にだけ投入される。
フラグ50件の評価が実際に示したもの
評価対象は簡単な事例だけを選んだものではない。ブーリアン値41件、文字列6件、整数型3件で構成し、ファイル1〜2個に触れる単純なケース6件、3〜5ファイルにまたがる中程度のケース18件、入れ子の条件分岐とファイル間依存が絡む複雑なケース26件に分けている。
初回成功率は複雑さにほぼ正確に連動した。単純が100%、中程度が94%、複雑が85%である。コストも同様だった。単純な削除は平均7.5分・2.69ドル、中程度は10.4分・3.46ドル、複雑は17.7分・6.20ドル。承認された45件のプルリクエストのうち14件は軽微な修正が1度必要で、5件はエンジニアの介入を要した。
失敗の型は具体的で参考になる。やり直し6件はパッチカバレッジ不足から、8件は削除漏れから生じた。変数が1つ残っていたり、コールチェーンの深部に参照が生き残っていたりするケースだ。人間が介入した5件はいずれもコールチェーンの深さと、インターフェースをまたぐパラメータの受け渡しに関係していた。ファイル単位の視野で作業するコーディングエージェントが最も苦手とする推論が、まさにここにある。
定着するエージェント導入の共通点
アーキテクチャを読むと見慣れたパターンが浮かぶ。作業単位ごとの隔離、狭く限定した人間の承認点、そしてエージェントが言い抜けできない機械的なゲートだ。Cloudflareがコンテキストを共有しない4つのエージェントでAstroのオープンissueを85%削減したときと同じ形である。モデルの選択は費用項目にすぎず、プロダクトの本体はゲートの側にある。
採算は最悪のティアでも成立する。複雑なケースで6.20ドル・18分未満、人手なら1〜2時間の作業だ。留保すべきはサンプル数である。50件はパイロットであって、1659件のバックログではない。しかもコストと失敗は、そのバックログの大半を占める複雑ティアに集中している。85%が全件の待ち行列に触れても維持されるか、そこが見るべき数字だ。
よくある質問
DoorDashの削除システムはどのモデルを使っているのか
役割を分けて2つを使う。Claude SonnetのオーケストレーターがJiraの取得、ロールアウト実データへのMCP照会、計画立案を担当する。コードの修正はClaude Opusのエージェントが行う。コールチェーンの推論こそ、高性能モデルがコストに見合う領域だからだ。
エージェントがビルドを壊さないのはなぜか
各エージェントは隔離されたgit worktreeで作業し、プルリクエスト作成前にビルド、テストスイート、JaCoCoのパッチカバレッジ95%基準、Detektの静的解析をすべて通過する必要がある。停滞したエージェントは1時間のハードタイムアウトで打ち切られる。
この削除作業は完全自律なのか
いいえ。計画段階の最後にエンジニアが置換値を確認してから初めてコード変更が始まり、生成されたプルリクエストも通常どおりレビューを受ける。評価でも50件中5件はエンジニアの直接の介入が必要だった。
