StripeのAIコーディングエージェント「Minions」の内部アーキテクチャ詳解

Stripeが自律型AIコーディングエージェント「Minions」の後編記事を公開した。前編がユーザー体験と概要だったのに対し、後編ではDevbox・Blueprints・Toolshed・gooseフォークという4つのコンポーネントの実装が開示されている。週1,300件超のPRをゼロ人力で生成するシステムの内側を読み解く。

Devbox: 10秒で起動する使い捨て開発環境

MinionsはAWS EC2インスタンスベースの隔離サンドボックス「Devbox」上で動作する。このDevboxは元々人間のStripeエンジニアが日常的に使っている標準開発環境そのもので、エンジニアはIDEからSSH経由でDevboxにリモート接続してコードを書いている。

設計思想は「cattle, not pets」。各Devboxは標準化された使い捨てインスタンスで、エンジニア1人が半ダースほどのDevboxを同時に走らせ、タスクごとに1つずつ割り当てる運用になっている。

Hot and Readyの実装

Stripeが「Hot and Ready」と呼ぶ10秒起動基準の裏側では、プリウォーミングプールから事前準備済みのインスタンスを払い出す仕組みが動いている。プール内の各インスタンスでは以下が完了済みとなる:

巨大なgitリポジトリのクローン
BazelキャッシュとTypeチェックキャッシュのウォームアップ
Devbox上で常時稼働するコード生成サービスの起動
masterの最新コピーへのチェックアウト

10秒後にはREPLを開く、テストを走らせる、コードを変更して型チェックする、Webサービスを起動する、といった操作が即座に可能な状態になる。

ラップトップ上でコンテナやgit worktreeを組み合わせて同等の並列性・予測可能性・隔離性を実現するのは難しい。特に「開発者のシェルと同等のパワーを持ちつつ適切に制約する」のが根本的に困難で、Devboxはこの問題をクラウドインスタンス側で解決している。

セキュリティ境界

DevboxはQA環境内で動作し、本番データ・本番サービス・任意の外部ネットワークへのアクセスが遮断されている。先日のAmazon Kiroのインシデントと比較すると、エージェントの爆発半径を1つのDevboxに閉じ込めた設計で、確認プロンプトなしの全権実行を安全に実現している。

人間のエンジニアが安全に実験できる環境を作った結果、それがそのままエージェントにとっても安全な環境になった、という順序が重要だ。エージェントのために新しい隔離基盤を作ったのではなく、既存の人間向けインフラがそのまま流用できている。

gooseフォーク: 無人運転への特化

2024年後半、Stripeはコーディングエージェントの黎明期にBlock社のOSS「goose」を社内フォークした。gooseは当時最も広く使われていたコーディングエージェントの一つだった。

フォーク後のカスタマイズ方針は明確で、人間がそばで監視する前提の機能を削ぎ落とし、無人運転に最適化することだ。具体的には以下のような差分がある:

中断可能性の除去: 人間が途中で割り込む機能は不要
人間トリガーのコマンド除去: エージェント実行の開始・操舵を人間が手動で行う機能は不要
確認プロンプトの廃止: Devboxの隔離性が保証するため、操作ごとの承認ステップを省略

CursorやClaude Codeのようなサードパーティツールは人間の伴走ツールとしてStripeエンジニアに提供されている。gooseフォークはそれらとは別の「完全自律」という路線で開発されている。

Blueprints: 決定論とエージェントのハイブリッドオーケストレーション

StripeがMinionsの中核技術として開発した「Blueprints」は、AnthropicのBuilding Effective Agentsで定義される2つのプリミティブ、ワークフローとエージェントを融合した仕組みだ。

ワークフロー: 固定グラフで各ノードが狭いスコープの処理を担当し、事前定義されたエッジで制御フローが決まる
エージェント: ツール付きループでLLMが自律的に次のアクションを判断する

Blueprintsはこの両方を1つのステートマシンとして組み合わせる。

ノード種別と実例

ノード種別	ラベル例	LLM使用	動作
エージェントノード	Implement task	あり	入力に基づきLLMが自律判断
エージェントノード	Fix CI failures	あり	テスト失敗の原因を分析して修正
決定論的ノード	Run configured linters	なし	コードを実行するだけ
決定論的ノード	Push changes	なし	gitコマンドを実行するだけ

元記事にはBlueprintのフロー図が掲載されていて、決定論的ノードは矩形、エージェントノードは雲形で描かれている。全体として「タスク実装 → リント → プッシュ → CI実行 → CI失敗ならエージェントで修正 → 再プッシュ」というステートマシンの形になる。

なぜハイブリッドなのか

リンターの実行結果は確定的に得られるのに、わざわざLLMに「リンターを実行して」と指示してトークンを消費する必要はない。予測可能な小さな判断をコードで確定的に処理することで、スケール時にトークン消費とCIコストの差が大きくなる。

Stripeの経験則として「LLMを小さな箱に入れる」アプローチが、システム全体の信頼性向上に複利的に効く、と述べられている。Blueprint機構はサブエージェントのコンテキストエンジニアリングを容易にする。具体的には:

サブタスクごとにツールセットを制約する
システムプロンプトを変更する
会話コンテキストを簡素化する

チーム独自のBlueprint

チームごとにカスタムBlueprintを定義できる。元記事の例では、完全に決定論的なcodemodでは処理しきれないLLM支援のマイグレーションを、カスタムBlueprintでエンコードしたケースが挙げられている。

Toolshed: 約500のMCPツールを集中管理するサーバ

StripeはMinions専用ではなく、社内の全エージェントシステムが共有する集中型内部MCPサーバ「Toolshed」を構築した。

設計思想

MCPが業界標準として登場した際、Stripeには既に複数のエージェントシステムが存在していた:

ノーコード内部エージェントビルダー
専用サービス上のカスタムエージェント
サードパーティのオフザシェルフエージェント
CLIベースのエージェントツール
Slackボット

これらが重複するMCPツールを個別に持つのは非効率なので、Toolshedに約500のMCPツールを集約し、全エージェントフリート（数百のエージェント）が共有する構造にした。Toolshedにツールを1つ追加すれば、即座に全エージェントがそのツールを使える。

ツールの払い出し戦略

エージェントは少ないツールセットの方がパフォーマンスが出る。そのため、Toolshedは全500ツールをそのまま渡すのではなく、タスクに応じた厳選サブセットのみを払い出す。Minionsにはデフォルトで意図的に小さなサブセットが設定されている。

加えて、個々のエンジニアがテーマ別のツールグループを自分のMinionsに追加設定できるカスタマイズ機能も備えている。

セキュリティ制御

Minionsは自律的にMCPツールを呼び出すため、内部セキュリティ制御フレームワークによって破壊的操作が防止されている。ただし第一の防衛線はDevbox自体のQA環境隔離であり、そもそも本番データ・本番サービス・外部ネットワークにアクセスできない。

コンテキスト管理: ルールファイルとMCPの二層構造

大規模コードベースでエージェントを動かすと、ベストプラクティスに従わない、適切なライブラリを使わないといった問題が起きる。リンターだけでは防げない領域だ。

ルールファイル

Stripeはリポジトリが巨大なため、無条件のグローバルルールを極力使わない。グローバルルールを詰め込むと、エージェントが動き始める前にコンテキストウィンドウがルールで埋まってしまう。

代わりに、ディレクトリやファイルパターンにスコープされたルールファイルを使い、エージェントがファイルシステムを辿る過程で自動的にアタッチされる仕組みにしている。

ルールのフォーマットはCursor互換を採用した。理由は、ディレクトリ・ファイルパターン単位のスコープ機能をサポートしていたことと、Stripeで人気のある3つのコーディングエージェント（Minions、Cursor、Claude Code）が同じルールファイルを共有できるようにするためだ。CursorフォーマットのルールはClaude Code向けにも自動syncされている。

MCPによる動的コンテキスト

ファイルシステムからの静的コンテキスト収集に加え、ToolshedのMCPツール呼び出しで動的にコンテキストを取得する。内部ドキュメント、チケット詳細、ビルドステータス、コードインテリジェンスなどがこの経路で供給される。

CI反復: 2サイクル上限とShift Leftの原則

Stripeには300万以上のテストがあり、これがエージェントのフィードバックループとして機能する。ただし全テストをCIに依存するのではなく、「shift feedback left」の原則を採用している。CI で失敗するとわかっているチェックは、できるだけ早い段階でフィードバックする。

ローカルでのリント処理

pre-pushフックがlintの修正を自動実行する。バックグラウンドデーモンが変更に適用されるlintルールのヒューリスティクスを事前計算してキャッシュするため、プッシュ時のlint修正は通常1秒以内に完了する。

Minionsでもこのフレームワークをそのまま使う。lint実行はBlueprintの決定論的ノードとしてローカルで回し、ブランチをプッシュする前にlintを通すことで、初回CIでパスする確率を上げている。

CIの反復サイクル

Minionsがコードを変更してブランチをプッシュ
CIが実行され、autofixがあれば自動適用
autofixのない失敗はBlueprintのエージェントノードに渡され、Minionsがローカルで修正を試みる
2回目のプッシュとCI実行
それでも失敗したら人間のオペレーターに差し戻し

CI反復が最大2サイクルに制限されているのは、トークン・コンピュート・時間のバランスを取った判断だ。無制限にCIループを回しても限界収穫逓減が生じるというのがStripeの見解である。エージェントが自力で解決できない問題に延々とリソースを投じるより、人間に渡す方が合理的だ。

元記事: Minions: Stripe’s one-shot, end-to-end coding agents — Part 2