第1回*1のおさらいとして：MinionsはStripeが自社開発した完全無人のエージェント型コーディングフローです。毎週Stripeでマージされるプルリクエストのうち1,300件以上（第1回時点の1,000件から増加）がMinionsによる完全自動生成であり、人間によるレビューは行われますが、コード自体は一切人間が書いていません。
第1回をまだお読みでない方は、Minionsの開発者体験を理解するためにそちらを先にお読みください。本記事では、Minionsの構築方法についてさらに詳しく掘り下げ、Minionsフローの中でもStripe固有の部分に焦点を当てます。
Devbox：いつでも即起動
スケールする無人エージェントコーディングを最大限に機能させるには、並列化・予測可能性・隔離性を備えたクラウド開発環境が必要です。人間が多くのエージェントに論理的に独立した作業を割り当てられること、エージェントがクリーンな環境と作業ディレクトリを持てること（エージェント同士の変更が干渉すると、解決に無駄なトークンを消費することになります）、そして完全な自律性を確保するためにエージェントが特権マシンや機密マシンに対して破壊的な操作を行わないよう体系的に隔離されていること——特に人間の個人的な認証情報を使う場面では重要です——が求められます。
開発者のラップトップ上でこれらの特性をすべて備えたエージェントを動かすのは容易ではありません。コンテナ化やgit worktreeも助けになりますが、組み合わせることが難しく、開発者のシェルの全機能を持ちながら適切に制約されたローカルエージェントを構築することは本質的に困難です。
しかしStripeのMinionsは、Stripeのエンジニアが使う標準開発環境「devbox」上で動作するため、これらの特性をデフォルトで得ることができます。
Stripe devboxはソースコードを格納し、開発中のサービスを実行するAWS EC2インスタンスです。人間が書くStripeのコードの大部分はすでに、SSH経由でdevboxにリモート接続したIDEで書かれています。DevOpsの言葉を借りれば、devboxは「ペットではなく家畜（cattle, not pets）」：カスタマイズされた長期稼働型ではなく、標準化されていつでも交換可能です。
多くのエンジニアはタスクごとに1つのdevboxを使います——Stripeのエンジニアが同時に半ダースのdevboxを稼働させていることもあります。
新しいdevboxを立ち上げることを「手間なくできる」と感じてもらうため、10秒以内に準備完了することを目標にしています。この「いつでも即起動」の水準を達成するため、開発者が必要とするタイミングに備えてdevboxのプールを事前にプロビジョニングしてウォームアップしておきます。これには、巨大なgitリポジトリのクローン、BazelおよびType Checkingキャッシュのウォームアップ、devbox上で継続的に実行されるコード生成サービスの起動などが含まれます。10秒後には、devboxのオーナーはStripeのすべてのメインリポジトリにまたがる最新のmasterブランチがチェックアウトされた状態になり、REPLを開く・テストを実行する・コードを変更して型チェックする・Webサービスを起動するといった作業をすぐに始められます。
Devboxはもともと、LLMコーディングエージェントが存在するずっと前から、人間のエンジニアのニーズのために構築されました。そして結果として、並列性・予測可能性・隔離性はStripeのエンジニアが最も効果的に作業するためにも非常に望ましい特性でした。「人間に良いものはエージェントにも良い」——このインフラの基盤の上に構築したことが、LLMエージェントの自然な住処として配当をもたらしました。
エージェント
人間の開発をすでに支えていたdevboxとは対照的に、エージェントハーネスはMinionsのユースケースのために独自に構築しました。
2024年後半、コーディングエージェントが業界全体に広がる中、私たちは社内でBlockのGoose——最初期に広く使われたコーディングエージェントの一つ——をフォークし、StripeのLLMインフラで動作するようカスタマイズしました。時間が経つにつれ、Gooseの機能開発を人間が監督するツールのニーズではなくMinionsのニーズに集中させていきました。人間が監督するツールのユースケースは、すでにエンジニアが利用できるCursorやClaude Codeといったサードパーティ製ツールが十分に満たしているからです。
実際、Minionsの最もユニークな点は、監督する人間が存在しないことです。市販のローカルコーディングエージェントは通常、エンジニアの「肩越しに見ている」ような形で、エンジニアと並走しながらコード変更を進めるコンパニオンとして最適化されています。一方Minionsは完全無人であるため、エージェントハーネスは割り込み可能性や人間が起動するコマンドといった人間向けの機能を使ってエージェントの実行を開始・誘導することができません。
その反面、隔離されたdevbox環境によって、エージェントは確認プロンプトを必要としません。エージェントが犯す可能性のある間違いは1つのdevboxの限られた範囲に閉じ込められるため、フルの権限でエージェントを安全に実行し、確認プロンプトをスキップできます。
またStripeの開発フローに精密に合わせた最適化も施すことができます。Stripeのシステムの特性に基づいて多くの細かい最適化を行ってきました。より大きな最適化として——そしてMinionsの実装においてより根本的であることが判明したもの——が「ブループリント」という概念です。
ブループリント
LLMフローのオーケストレーションに使う最も一般的なプリミティブはワークフローとエージェントです。ワークフローは固定されたステップのグラフで動作するLLMシステムで、グラフの各ノードが全体の目標の狭い範囲を担当し、事前定義されたエッジがこれらの離散ノード間の実行フローを制御します。
一方エージェントは通常「ツールを持つループ」というシンプルなオーケストレーションパターンで、LLMが自分の判断で手持ちのツールを繰り返し呼び出し、ツール呼び出しの結果に基づいて次に何をするかを決定します。
Minionsは「ブループリント」と呼ぶプリミティブでオーケストレーションされています。ブループリントはMinionsの実行を指示するコードで定義されたワークフローです。ブループリントはワークフローの決定論性と、未知のものを扱うエージェントの柔軟性を組み合わせます：各ノードは決定論的なコードかタスクに集中したエージェントループのどちらかを実行できます。本質的に、ブループリントとはエージェントのスキルを集め、特定のサブタスクを最も適切に処理できるよう決定論的なコードと絡み合わせたものです。
Minionsを動かすブループリントには、例えば「タスクを実装する」「CIの失敗を修正する」といったラベルを持つエージェント的なノードがあります。これらのエージェントノードは入力に基づいて自らの判断を下す広い裁量を与えられています。一方ブループリントには「設定済みリンターを実行する」「変更をプッシュする」といったラベルを持つ完全に決定論的なノードもあります：これらの特定ノードはLLMを一切呼び出さず、ただコードを実行するだけです。
このようにブループリントは、エージェントの実行内において特定のサブタスクが決定論的に完了することを保証する手段です。Minionsのブループリントは、決定論的なコードノードと自由に流れるエージェントノードを混在させたステートマシンのようなものになります。
私たちの経験では、「実行の最後に必ず変更をリントする」など予測できる小さな決定を決定論的にコードで処理することで、スケール時のトークン（とCIコスト）を節約でき、エージェントが間違いを犯す機会も少し減ります。総じて「LLMを限定されたボックスに入れる」ことがシステム全体の信頼性向上として積み重なることがわかっています。ブループリントの仕組みは、ツールの制限・システムプロンプトの変更・サブタスクに必要な会話コンテキストの簡素化など、サブエージェントのコンテキストエンジニアリングを容易にします。
個々のチームも自分たちの特殊なニーズに最適化したブループリントを設定できます。例えば、完全に決定論的なコードmodでは実現できないLLM支援によるコードベース全体のトリッキーなマイグレーションを実行するカスタムブループリントを構築したチームもあります。
コンテキスト収集：ルールファイル
Stripeのような大規模なコードベースでは、何の案内もなしに放たれたエージェントは、優れたリンターがあっても、ベストプラクティスを守ったり適切なライブラリを使ったりするのに苦労するかもしれません。この問題を解消するため、CLAUDE.mdやAGENTS.mdのような各種エージェントルール形式によって、エージェントがディレクトリ構造を走査する中でコードベースについて自動的に「学習」できるようになっています。
リポジトリの規模のため、無条件のグローバルルールの使用は非常に慎重にしています。そうしなければエージェントが実際に動き始める前にルールだけでコンテキストウィンドウが埋まってしまうからです。代わりに、エージェントがファイルシステムを走査する際に自動的に付加される、特定のサブディレクトリやファイルパターンにスコープされたファイルからのコンテキストをほぼ専ら使用しています。
私たちの考えでは、人間が操作するエージェントが使うのと同じコンテキストをエージェントに読ませるために、ルールファイルの重複を避けることが最善です。そのため、これらの機能をサポートする人気のルール形式——Cursorのもの——を標準として採用し、Minionsがそれまでの自社製フォーマットに加えてそのルールを読めるようにハーネスを修正しました。
また現在は、CursorのルールをClaude Codeが読めるフォーマットにも同期しているため、最も人気の高い3つのコーディングエージェント（Minions・Cursor・Claude Code）がすべて、Stripeのエンジニアがコードベースに整備しているルールファイルの案内から恩恵を受けられます。
コンテキスト収集：MCP
ファイルシステムからの読み取りは静的なコンテキスト収集には有効ですが、エージェントはネットワーク越しのツール呼び出しを使って情報を動的に取得する必要が頻繁にあります。特にMinionsはユーザーリクエストを完全に処理するために、社内ドキュメント・チケット詳細・ビルドステータス・コードインテリジェンスなどの情報を取得する必要があります。リリース当初から、Model Context Protocol（MCP）はネットワーク越しのツール呼び出しの業界標準として急速に普及し、私たちはMinionsをMCPと統合しました。
Stripeは様々なフレームワーク上で動く多くのエージェントを構築・統合しています：ノーコードの社内エージェントビルダー・専用サービスで動くカスタムエージェント・サードパーティ製の既製エージェント・コマンドラインエージェントツールやその他のコーディングエージェント・エージェント型Slackボット。MinionsだけでなくこれらすべてのエージェントがMCPの機能を必要とし、多くの場合共通ツールの重複したセットを含んでいました。
これらすべてをサポートするため、「Toolshed」と呼ぶ中央集権型の社内MCPサーバーを構築しました。Toolshedはエンジニアが簡単に新しいツールを作成してエージェントシステムに自動的に公開できるようにしています。すべてのエージェントシステムはToolshedを共有の機能レイヤーとして利用でき、Toolshedにツールを追加するだけで数百の異なるエージェント全体に機能が即座に付与されます。
Toolshedは現在、Stripeで使う社内システムとSaaSプラットフォーム向けの約500のMCPツールを収容しています。エージェントはタスクに関連するツールを厳選した「小さなボックス」を与えられたときに最も良いパフォーマンスを発揮するため、異なるエージェントがそれぞれのタスクに関連するToolshedツールのサブセットのみをリクエストするよう設定しています。Minionsも例外ではなく、デフォルトでは意図的に少数のツールのみが提供されますが、ユーザーごとのカスタマイズによりエンジニアが自分のMinions用にテーマ別のツールセットを追加設定できます。
Minionsは完全にMCPツールを自由に呼び出しながら自律的に動作するため、破壊的なアクションを実行するためにツールを使用できないことを保証する社内セキュリティ制御フレームワークも設けています。ただし、最初の防衛線として、devboxはすでにQA環境で動作しており、その結果Minionsは実際のユーザーデータ・Stripeの本番サービス・任意のネットワーク出力へのアクセス権を持ちません。これは偶然ではありません：人間が安全に実験できる環境を持てるよう、意図的に隔離されたdevboxを構築しました。しかし他の多くのことと同様、人間にとって安全な開発環境はMinionsにとっても同様に有用であることが証明されました。
…そして反復
Minionsはタスクをワンショットでこなすことを目標に構築していますが、エージェントが進捗するために反復できる自動フィードバックを与えることが鍵です。Stripeの膨大な既存テストスイート——300万件以上——がこのフィードバックを提供できます。しかし、プッシュされたブランチはCIで関連するすべてのテストを実行しますが、すべてのコードフィードバックをCIだけに頼りたくはありません。
開発者生産性を考える際に「フィードバックをシフトレフト（早期化）する」という原則のもとで運用しています。この言葉が意味するのは、自動チェックがCIで失敗することがわかっているなら、それをIDEで検出してエンジニアに即座に提示するのが最善であるということです。それがユーザーへのフィードバックを最も速く提供する方法です。
たとえばpre-pushフックで最も一般的なリントの問題を修正します。バックグラウンドのデーモンが変更に適用されるリントルールのヒューリスティクスを事前計算してキャッシュするため、開発者は通常プッシュから1秒以内にリント修正を得られます。
Minionsもこのフレームワークと自然に統合されているため、オートフォーマッターなどに対して反復することでトークンやCI時間を無駄にする必要がありません。エージェントのdevloopブループリント内で決定論的ノードとしてリンターのサブセットを実行し、エージェントのブランチをプッシュする前にそのリントノードをローカルでループさせます。これにより、ブランチが最初のCIパスを通過できる公算が高まります。
すべてのテストをローカルで実行することは現実的でないため、標準のMinionsブループリントに完全なCIスイートへの1回のイテレーションも含めています。Minionsが変更をプッシュした後、CIを実行して失敗したテストの自動修正を適用します。自動修正のない失敗があれば、ブループリントのエージェントノードに失敗を返送してMinionsにローカルで修正するもう1回のチャンスを与えます。2回目のプッシュとCIの実行後、ブランチを人間のオペレーターに返送して手動で精査してもらいます。
なぜCIは1〜2ラウンドだけなのか？スピードと完全性のバランスがあります。CIの実行にはトークン・計算資源・時間がかかり、LLMが無限にCIループを回しても限界収益は逓減すると考えています。私たちのポリシーは競合する考慮事項の間で良いバランスを取っていると考えています。
おわりに
MinionsはStripeがエンジニアを加速するためにAIを活用する多くの方法のうちの一つにすぎませんが、エージェントハーネスやMCPといった業界標準の概念と、エンジニアが長年かけて開発者生産性を最大化するために磨き続けてきた社内ツールやインフラの独自の組み合わせを融合できることの優れた例だと思っています。
ドキュメントの改善・開発環境・反復ループのいずれを通じてであっても、人間の開発者生産性への投資が時を超えてエージェントの世界での配当をもたらすということを、私たちは何度も経験してきました。
MinionsはすでにStripeのソフトウェアエンジニアリングの景色を変えました。業界全体の最新の成果をStripeのスケールで機能するよう適応させながら、エージェント体験を構築し続けています。人間の開発者体験のための苦難の戦いで学んだ知見と専門性を組み合わせて、Minionsを最高のものにしていきます。
MinionsとともにあるいはMinionsの開発に携わることに興味がありますか？Stripeは採用中です。
著者について
Alistair Gray
AlistairはLeverageチームのソフトウェアエンジニアです。LeverageチームはStripeのエンジニアが生産性を最大化するための、驚くほど使い心地の良い社内プロダクトを構築しています。
