
「AI を使えば、この開発はもっと安くならないんですか」——見積もりを出したあとに、こう聞かれる機会が増えました。もっともな質問です。ただ、答えは「作業を任せられるかどうか」ではなく「任せた作業を安全に走らせる場所があるかどうか」で決まります。
その差がはっきり出る事例が公開されました。DoorDash が社内で運用している Flux というエージェント基盤で、1ヶ月で 13 万件のエンジニアリングタスクをエージェントに処理させています。週あたり 25,000 件を超える自動コードレビュー、週 10,000 件を超える「プレイブック」の実行があり、プレイブックは 300 種類以上が登録されています。
数字は目を引きますが、この事例で参考になるのは規模ではありません。 同じことを 30 人の会社でやることはできませんし、やる必要もありません。参考になるのは、その規模を回す前に何を用意したかです。
ノートPCで動かしていたものを、なぜ外に出したのか
Flux の出発点は、エージェントを開発者のノートPCで動かしていたことの限界だと説明されています。挙げられているのは3点です。
1つ目はリソースの制約。 手元のマシンで動かす以上、同時に走らせられる本数にも、動かし続けられる時間にも上限があります。
2つ目は安全性。 ノートPCで動くエージェントは、その開発者が持っている権限をそのまま持ちます。本番のデータベースに繋がる資格情報が手元にあれば、エージェントもそこに届きます。
3つ目は可視性。 誰のマシンで何が動いて、どのシステムに触れたのかが、外から見えません。
この3点は、規模に関係なく発生します。むしろ小さい組織のほうが、開発者の権限が広く、監査の仕組みが薄いぶん深刻です。 「うちは3人しかいないから大丈夫」は成り立ちません。
用意されたのは、3つの構造
Flux で公表されている構成は、要素としては次の3つに整理できます。
1. 隔離された実行環境。 エージェントは Firecracker のマイクロ VM を使った隔離サンドボックスの中で動きます。エージェントが何を実行しても、その影響がサンドボックスの外に出ない前提を先に作っています。
2. スコープを絞った出入口。 社内システムへのアクセスは MCP ゲートウェイを経由します。エージェントに資格情報を直接持たせるのではなく、「どのシステムに、どの範囲で触れてよいか」をゲートウェイ側で決めて、通過したものを記録する形です。MCP が社内システム接続の標準的な入り口になりつつある流れを、そのまま統制点として使っています。
3. 再利用される手順。 300 種類以上のプレイブックが週 10,000 回以上呼ばれている、という数字が示すのは、毎回プロンプトを書いているのではなく、確立した手順を繰り返し実行しているということです。起動は Slack、GitHub、CLI など複数の入り口から行えます。

「AI で安くなる」が成立する条件
ここまでを踏まえると、冒頭の質問には次のように答えられます。
エージェントが効くのは、繰り返し発生する定型のタスクです。 公表されている用途で件数が大きいのはコードレビューとプレイブックの実行で、いずれも「毎回ゼロから考える作業」ではありません。新規の設計や、要件が固まっていない機能の実装が安くなる話ではないことは、期待値として先に共有しておく必要があります。
そのうえで、安くなるかどうかは実行環境があるかで決まります。 隔離された環境も、権限を絞る出入口も、記録も無い状態でエージェントを走らせると、レビューと事故対応の工数が増えます。削れた実装工数を、確認工数が食い潰す構図です。
これは受託の現場では契約条件にも直結します。コードを外部に出せない案件でローカル実行のエージェントを選ぶ判断は、まさに「実行環境をどう用意するか」の一形態です。クラウドの隔離環境を用意するのか、手元で完結させるのか、どちらも選べないのか。選択肢は3つあり、案件の制約で決まります。
中小規模なら、どれから置くか
3つ全部を最初から作る必要はありません。順番があります。
- 記録から始める。 誰が、どのリポジトリに対して、どのエージェントを、いつ動かしたか。まずこれを残すだけで、事故が起きたときの調査時間が変わります。専用の基盤は要りません
- 次に権限を絞る。 エージェントに渡す資格情報を、開発者本人のものから、用途を限定した別のものに分けます。本番データベースへの書き込み権限が混ざっていないか、ここで一度確認します
- 隔離環境は最後でよい。 コンテナやクリーンな VM で動かす、という程度から始めれば十分です。マイクロ VM の基盤を自前で構築する話ではありません
順番を逆にすると、たいてい途中で止まります。基盤の構築から入ると、動くまでに数ヶ月かかり、その間エージェントは今までどおりノートPCで動き続けるためです。
次にやること
まず、社内でコーディングエージェントを使っている人が、どのシステムの資格情報を持ったまま使っているかを確認してください。 本番環境に届く権限が手元にあるなら、それはエージェントにも届いています。これは AI の話ではなく、以前からある権限管理の話が顕在化しただけです。
次に、エージェントに任せている作業を書き出して、「毎回同じ手順か」で分けてください。 同じ手順のものが一定数あるなら、それが手順として固定できる候補です。固定できれば、結果が安定し、レビューの負荷が下がります。逆に、毎回違う作業しか出てこないなら、いま基盤に投資する段階ではありません。
開発フローへの AI エージェント組み込み、実行環境と権限設計、内製化と外注の切り分けについては、グリームハブの開発・AI・自動化のご相談で承っています。既存の開発体制と扱うデータの機密度によって取れる構成が変わるため、個別にご相談ください。お問い合わせからどうぞ。




