Stripeが数百のエージェントを動かしてlocalhostを捨てた理由、徹夜で試してみて納得した

昨晩のハッカソンにはルールが一つあった。夜8時に開発用のスペックとハーネスだけをセットアップして、翌朝8時までキーボードから手を離すこと。12時間、エージェントだけでプロダクトを完成させる実験だ。

この実験を通じて、StripeがMinionsプラットフォームを公開し、RampがInspectという独自のバックグラウンドエージェントを構築した際に「localhostは終わった」と宣言した理由を、12時間で丸ごと体感することになった。

ラップトップでエージェントを並列起動すると衝突が始まる

複数のエージェントが同一マシン上で動くと、状態が壊れていく。シークレットが競合し、ポートが衝突し、マシンがスリープに入った瞬間に12時間分のループが全部吹き飛ぶ。

StripeとRampがエージェントアーキテクチャを公開したとき、両者に共通点があった。どちらもエージェントごとに独立したVMと開発コンテナを割り当てる構成を選んでいたのだ。

StripeのMinionsは「devbox」と呼ばれる隔離環境上で動作する。エンジニアが使うものと同じマシンタイプだが、本番リソースとインターネットから完全に切り離されている。スピンアップは10秒以内で、git worktreeのオーバーヘッドなしに並列タスクの実行が可能だ。

RampのInspectはModal Sandbox上に構築されている。各セッションがPostgres、Redis、Temporal、RabbitMQを含むフルスタックの開発環境を独立して持つ。セッション間の競合はなく、ファイルシステムのスナップショットによってほぼ即座に起動できる。

コーディングエージェントは自分のラップトップと集中力を必要とするが、バックグラウンドエージェントはどちらも必要としない。実際、徹夜で動かしている最中にマシンが一度スリープするだけでループ全体が止まる場面を目撃した。クラウドVMではそんなことは起きない。

タスクを順番に渡すと単純な機能しか生まれない

今回のハッカソンで最も痛感したのはここだ。逐次実行でエージェントを動かせば、単純なCRUDは出てくる。問題は依存関係が生まれた瞬間だ。先に完成したモジュールを後から動いたエージェントが上書きしたり壊したりすることが繰り返された。

ここで、エージェントフリート（fleet）とエージェントスウォーム（swarm）を区別する必要がある。

エージェントフリートは、同一の変更を複数のリポジトリに同時に適用するパターンだ。Stripeが週1,000件以上のPRをマージできるのもこの構造のおかげだ。同じマイグレーション、同じlintの修正を数百のサービスに一括で適用していく。

エージェントスウォームは、異なるパートをそれぞれのエージェントに担当させ、一つの成果に収束させるパターンだ。フロントエンド、バックエンド、テストをそれぞれ別のエージェントが担当し、PR単位でまとめていく構成だ。

逐次ではなく、並列実行してPR単位でマージする構造でなければ複雑なプロダクトは作れない。実際に試してみると、並列+マージレビューの組み合わせと逐次実行では、完成度の差が歴然としていた。

レート制限とエージェント間の連携はプロンプトではなくインフラで解く

12時間のループでレート制限に引っかからないのは不可能だった。さらに、エージェントが作ったコミットを別のエージェントがレビューし、スペックのあいまいな部分を自動で再判断するフローも必要だった。

「システムプロンプトに『ファイルを消すな』と書くのはお願いであって制御ではない」という言葉がある。まさにその通りだと思う。

Stripeはこの問題を実行レイヤーで解決した。Minionsは本番リソースとインターネットアクセスが根本から遮断されており、権限チェックなしで安全に実行できる。400以上のMCPツールを「Toolshed」と呼ぶ内部サーバーにホスティングし、各エージェントがアクセスできるツールセットをキュレーションしている。

RampはGitHub OAuthを通じて、PRが必ず実際のユーザーアカウントから作成されるよう設計した。アプリIDではなく個人アカウントに帰属するため、レビューなしにコードがマージされることを構造的に防いでいる。

権限の範囲を実行レイヤーで固定し、監査ログを残し、障害の影響範囲を制限すること。これがなければセキュリティチームが自律エージェントを承認するはずがない。

個人が速くなっても組織は速くならないことがある

「偽の頂上（false summit）」と呼べる現象がある。コーディングエージェントを導入するとPRは溢れ出すが、サイクルタイムは変わらない。レビューが積み上がり、CIが壊れ、マージ競合が増えていく。

ハッカソンでも、エージェントがコードを速く作ること自体は問題ではなかった。その成果物をマージして検証するボトルネックで時間がすべて消えた。

Stripeはこのボトルネックを自動化で解消している。Minionsはエージェントループと決定論的なコード操作をインターリーブするハイブリッドオーケストレーションを使う。リンティング、テスト、git操作が必ず完了することを保証しながら、エージェントの柔軟性も維持する。CIテストも最大2回の繰り返しに制限し、無限ループに陥らないよう設計されている。

RampはマージされたPR数を核心の成功指標としている。Inspectが作成したPRの50%以上が実際にマージされており、Inspect自体の80%以上がInspectによって書かれている。

バックグラウンドエージェントがPRレビューとCI失敗の分析とマージ競合の解消を人より先に処理してこそ、組織のスピードが追いついてくる。「in the loop（直接操作）」から「on the loop（結果だけ確認）」への移行が本質だ。

勝負所はつくる速さではなく、まとめる構造だ

エージェントを速く動かすことはすでに解決済みの問題だ。Stripeは週1,000件以上のPRを、Rampは全PRの半数以上をエージェントが作っている。

本当の勝負所は、エージェントが作った成果を安全にまとめるシステムを設計することだ。隔離された実行環境、並列後マージの構造、インフラレベルのガバナンス、そして検証の自動化。この四つが揃わなければ、エージェントは速いおもちゃに過ぎない。