DoorDash、マルチエージェントLLMで6万件のFeature Flagを整理

はじめに

Feature Flagは段階的なリリースや実験に欠かせない一方、役目を終えたFlagを残すとコードの負債になる。DoorDashはこの問題に対し、実験基盤のメタデータ、コード検索、人による確認、隔離実行、自動検証を連結したマルチエージェントLLMの仕組みを導入した。

要点

• 対象となる基盤は約623のリポジトリにまたがり、6万件を超えるFeature Flagを管理している。
• 毎月約2,300件が追加される一方、1,000件以上が期限切れと判定されている。
• 90日間変更されず、コードから参照され続け、アーカイブや廃止の対象になっていないFlagが過期扱いになる。
• 50件の評価では45件の利用可能なPull Requestを作成し、平均処理時間は13.8分、コストは4.79ドルだった。

なぜ削除が難しいのか

DoorDashでは依存性注入型のWrapperを通じてFlagを利用している。そのため、定義、クライアント呼び出し、業務ロジック、テストが複数のファイルに分散する。単純なBoolean Flagでも、5〜20ファイルの変更が必要になる場合がある。

この構造は、構文だけに依存する自動化の限界を示している。UberのオープンソースツールPiranhaは、抽象構文木とルールベースの変換によって過期Flagを検出・削除する。しかしDoorDashでは、依存性注入による関係が構文上ではなく意味的なレベルにあるため、この方式だけでは十分に対応できなかった。

LLMを使う方式は、コード検索の結果、利用文脈、削除方針を横断して扱える点に特徴がある。ただし、決定的な検証を不要にするものではなく、より広いコード構造に対応するための推論層として機能する。

2段階のエージェント構成

第1段階では、Claude Sonnetを使ったオーケストレーションAgentがJiraからタスクを取得し、関連リポジトリを検索する。さらにModel Context Protocolを通じて実験基盤を照会し、公開比率や目標値などのメタデータを取得する。レポートはエンジニアが確認し、目標値を承認してからコード変更に進む。

第2段階では、Claude Opusを使ったクリーンアップAgentが実作業を行う。各タスクは隔離されたGit Worktreeで実行され、1つのリポジトリでは最大4体を同時に動かせる。Agentはすべての参照を探し、削除方針を決め、ソースコードとテストを修正する。その後、ビルド、テスト、JaCoCoのパッチカバレッジ、Detektの静的解析を実行する。全検証を通過した場合だけPull Requestを作成し、タイムアウトは1時間に設定される。Worktree間の状態共有を避けるため、Gradle Daemonも無効化されている。

成果と限界

50件の評価では、31件が初回提出のままマージされ、14件は修正が必要で、5件はエンジニアの介入を要した。単純なFlagの一回での成功率は100%、中程度は94%、複雑なものは85%だった。介入した5件はいずれも、深い呼び出しチェーンやインターフェースをまたぐパラメータ伝達に関係していた。DoorDashによれば、50件の変更でバグや回帰は確認されなかった。

この事例が示すのは、Agentにコードを書かせることだけではなく、承認、隔離、検証を含む運用設計の重要性だ。DoorDashは今後、低リスク作業に信頼度スコアを導入し、削除後に誤解を招く変数名などを確認する品質チェックも追加する予定である。

出典：InfoQ 中文