投稿者: @SantoshPraneeth と @jeffizhungry
Flux は、DoorDash のエンジニア向けクラウドベースのエージェントプラットフォームです。2026 年のある 1 か月間で、私たちは Flux を使って 13 万件のエンジニアリングタスクを自動化しました。2026 年第 1 四半期の登場以来急速に拡大している Flux は、DoorDash 全体の大量のバックグラウンドワークフローを支えています。毎週 25,000 件以上の自動化されたコードレビュー、毎週利用される 300 種類以上のプレイブックと 10,000 回以上の呼び出しなどが含まれます。これらのワークフローは、無人で、並列に、24 時間 365 日実行できます。
本稿では、ローカルのラップトップ上でのエージェントワークロードの限界、ホスト型コーディングエージェントだけに頼らずに Flux を社内で構築した理由、そしてエージェントへの委任を反復可能かつ安全にするための、エージェントサンドボックス、MCP ゲートウェイ、プレイブック、呼び出しサーフェスといったプラットフォームのプリミティブについて説明します。
Flux のバックグラウンドワークフローのユースケース
DoorDash 全体での 1 か月間の Flux 利用状況を示すスナップショット。自動化されたコードレビュー、プレイブックの実行、バックグラウンドタスクの完了にわたります。
私たちの出発点
この 1 年間で、ラップトップ上でエージェントワークロードを実行していたユーザーは、すぐに限界に直面しました。
- リソースと可用性。ラップトップには、搭載されているすべてのアプリケーションと共有される CPU コア、メモリ、バッテリーという固定リソースしかありません。エージェントワークフローは、ビルド、テスト、大規模検索などの計算集約型タスクを並列実行する必要があることが多く、ラップトップはすぐに容量不足に陥ります。さらに、ワークフローはデバイスの電源が入っていて、接続されていて、利用可能であることに依存しているため、エンジニアがラップトップを閉じたり、接続が切れたり、その場を離れたりすると、作業は一時停止します。
- 安全制御。ラップトップには通常、SSH キー、VPN セッション、認証済みツールなど、機密性の高い認証情報やシステムへの広範なアクセス権があります。自律エージェントに同じレベルのアクセス権を与えると、不必要なリスクと、潜在的に大きな影響範囲が生じます。ローカル環境では、エージェントがアクセスできるものと、その期間を厳密に制限することも難しくなります。
- 可視性と監査可能性。ワークロードが個々のラップトップ上で実行されると、実行が断片化され、監視が困難になります。何がどこで、誰の代わりに実行されているのか、どのシステムやファイルに触れたのかを把握することが難しくなります。
これらの問題に取り組むための私たちの考え方はシンプルです。
安全で自律的なコーディングエージェントにタスクを委任し、エンジニアがイノベーション、批判的思考、複雑な問題の解決により多くのエネルギーを注げるようにすることです。
なぜ Flux を社内で構築したのか
ホスト型コーディングエージェントは有用ですが、難しいトレードオフを強制します。機密性の高いコードと実行コンテキストを第三者に送信するか、第三者から社内システムに戻る経路を開くか、です。DoorDash にとって、難しい問題はエージェントにコードを書かせることだけではありませんでした。それはほぼ解決されています。難しいのは、そのエージェントに適切な環境、ツール、権限、統合、制約を与えることでした。
私たちの戦略は、オーケストレーション、サンドボックス、ワークフロー、権限、統合、そして効果的に機能するために必要な DoorDash 固有のコンテキストエージェントなど、エージェントを取り巻くプリミティブを制御することです。また、これらのプリミティブをモジュール式に設計し、各タスクに最適なサードパーティ製ツールを使用したり、より深いセキュリティ、統合、パフォーマンス、UX のオーナーシップが重要となる場合は社内で構築したりする柔軟性を持たせています。
これらのプリミティブはワークフロー作成を民主化し、将来のユースケースに合わせてシステムをより適応しやすくします。異なる方法で組み合わせることができるため、基盤となるインフラストラクチャを作り直したり、各エンジニアがワークフローをどのように構成するかを規定したりすることなく、各チームは新しいエージェントワークフローを構築できます。たとえば、私たちは評価とコードレビューの両方を Flux インフラストラクチャ上で実行しています。
ワークフローではなくプリミティブ
Flux を構成する 4 つのプラットフォームプリミティブ（サンドボックス、MCP ゲートウェイ、プレイブック、呼び出しサーフェス）と、それらがどのように連携してタスクをエージェントが安全に実行できる作業に変えるか
上記のように、Flux は 4 つのプラットフォームプリミティブ、つまりサンドボックス、モデル コンテキスト プロトコル (MCP) ゲートウェイ、プレイブック、呼び出しサーフェスを中心に構築されています。これらが連携することで、エージェントへの委任を反復可能にします。プレイブックは作業を定義します。クラウドサンドボックスは、エージェントに作業を実行する実際の場所を提供します。エージェントゲートウェイは、エージェントがアクセスできるシステムを制御します。そして呼び出しサーフェスは、エンジニアがすでに使っている場所から作業を開始したり受け取ったりすることを可能にします。
サンドボックスが実行環境を提供する
ローカルエージェントはインタラクティブな開発には適していますが、無人で実行されるワークフローには適していません。個々のエンジニアのラップトップに依存し、ローカルリソースを奪い合い、監査が難しく、並列タスク全体で効率的にスケールしません。
Flux は実行を、ハードウェアレベルの分離を提供する Firecracker マイクロ仮想マシン (microVM) 上で動作する分離されたクラウドサンドボックスに移行します。各サンドボックスには、タスクに必要なリポジトリ、開発者ツール、シークレット、ランタイム依存関係がプロビジョニングされ、エージェントに完全なエンジニアリングワークスペースを提供すると同時に、DoorDash に一貫した実行、セキュリティ、可観測性のモデルを提供します。
このレイヤーを制御することで、複数のリポジトリにまたがる変更や、単一セッションからの複数のプルリクエストなど、実際のエンジニアリングワークフローをサポートできます。Flux は、microVM の起動から必要なリポジトリのクローン、ビルドツールのインストール、サポートされているコーディングエージェントハーネスの構成までのエンドツーエンドのセットアップ全体について、95 パーセンタイルのサービスレベル目標を 5 秒未満に設定しています。
MCP ゲートウェイが管理されたアクセスを提供する
エージェントは、継続的インテグレーション (CI)、可観測性プラットフォーム、課題トラッカー、デプロイツール、コード検索、ドキュメント、サービスメタデータなど、エンジニアが毎日使うシステムへのアクセスを必要とします。しかし、広範で無制限のアクセスをデフォルトにするべきではありません。
Flux は、社内の MCP ゲートウェイである Agent Gateway を介してエージェントを社内システムに接続します。各プレイブックは必要なツールを宣言し、Flux はそのタスクに必要なスコープ付き権限のみを付与します。すべてのアクションはログに記録され、明確な監査証跡を作成します。
このゲートウェイアーキテクチャにより、認証、認可、可観測性、使用状況の追跡、ポリシー適用のための集中管理ポイントが得られます。これらすべてにより、エージェントのアクセスはより安全になり、大規模な運用も容易になります。
プレイブックが作業を定義する
プレイブックは、エージェント作業の再利用可能な単位であり、Flux プラットフォームにおけるスキルとエージェント駆動タスクのための Docker コンテナに相当します。単一の YAML ファイルで定義され、タスク、入力、コンテキスト、スキル、ツール、権限、検証、期待される出力、安全境界をパッケージ化して、一貫した作業の実行を可能にします。
プレイブックは、柔軟性と判断力を提供するエージェントステップと、予測可能性、低コスト、検証の容易さを提供する決定論的ステップを組み合わせることができます。これにより、要件が進化しても、ワークフローを再設計することなく、チームはエージェント駆動の実行と従来のコードの間でロジックを移動できます。
呼び出しサーフェスは、開発者の日常に溶け込む
同じプレイブックを、Slack、GitHub、cron、CLI、または会話型スキルから起動できます。つまり、チームはワークフローを一度定義すれば、その瞬間に最も適したサーフェスから呼び出せます。
- コラボレーションによる委任には Slack
- PR と CI の自動化には GitHub
- 定期的なメンテナンスには cron
- 開発者による直接制御には CLI、またはスキル経由での呼び出し
これが、Flux を導入しやすくしている理由です。
学んだ教訓
Flux の構築からは、インフラストラクチャと同様に製品採用についても多くのことを学びました。具体的には以下のとおりです。
- 信頼を得るには、対象を絞って始める。ソフトウェア開発ライフサイクル全体を自動化しようとするのではなく、自動化されたコードレビューから始めました。コードレビューは頻度が高く、測定可能で、エンジニアが評価しやすいものでした。これにより、品質、レイテンシ、コスト、動作を調整できる本番ワークフローが得られ、その後、CI のトリアージ、オンコールタスク、メンテナンスプレイブック、チケット駆動開発へと拡大しました。
- 作業を見えるようにする。最初の Slack 統合では、エージェントの実行ごとにプライベートチャンネルを作成しました。これにより Flux は個人にとって有用になりましたが、チームの習慣は生まれませんでした。作業をパブリックスレッドに移すことで、採用パターンが変わりました。エンジニアは、他の人が委任した内容を見て、Flux の進捗を確認し、出力をレビューし、一緒に信頼を築くことができました。
- プレイブックにはイネーブルメント（活用支援）が必要。再利用可能なワークフローは、プラットフォームが存在するだけで自然に生まれるわけではありません。ワークショップやハッカソンは、チームが繰り返し発生する運用業務をプレイブックに変換するのに役立ちました。プリミティブが自動化を可能にし、イネーブルメントが、どのワークフローをコード化する価値があるかをチームが認識するのを助けました。
今後の展開
Flux を機能させているプラットフォームのプリミティブと、新しいワークフローを構築するための開発者エクスペリエンスについてさらに深く掘り下げます。また、その上に構築したアプリケーションについても説明します。これには、社内用 Slack エージェントである Flux Responder が含まれます。
謝辞
Adam Rogal、Adam Yarger、Andy Fang、Ashwin Kachhara、Fan Xia、Ivan Rudovol、Jason Prasad、Jialu Deng、Justin Block、Justin Deocampo、Justin Fan、Keith Lyall、Praneet Singh、Sean Chen、Tyler Berrett、Volanda Zhu の各氏に、このプラットフォームとこの記事への貢献に感謝します。
