Stripe Minionsコーディングエージェント、週1,300件超のPR
Stripe Minionsのコーディングエージェントは、週に1,300件を超えるプルリクエストをマージしていると、Stripeは2026年2月19日のエンジニアリング記事で述べました。以前は1,000件でした。変更はすべて人がレビューしますが、人が書いたコードは含まれません。エンジニアリングチームにとっては、無人で動くエージェントが小さなアップグレードや修正の安定した流れを引き受け、エンジニアがすべてのマージの最終判断を持つ形を示す事例です。
Stripeが人の監視なしで動くエージェントを求めた理由
Stripeの課題は、ミスの代償が大きいコードベースでの規模でした。InfoQによると、エージェントが作業するコードは年間1兆ドルを超える決済額を支え、金融機関、規制の枠組み、コンプライアンス上の義務との依存関係の中で動いています。
CursorやClaude Codeのような対話型のツールは、すでにStripeのエンジニアが使えましたが、これらは、エンジニアが各ステップを見守るコンパニオンとして働きます。Stripeが求めたのは別の種類のツールでした。1つの指示を受け取り、誰も実行を監督しなくても完成したプルリクエストを返すものです。
Stripeが作ったもの: Minionsエージェント
Minionsは、Stripeが自社で作った無人のコーディングエージェントです。2024年末、StripeはBlockのコーディングエージェントgooseをフォークして自社のLLMインフラ向けにカスタマイズし、そのうえで無人実行のニーズに開発を集中させました。
「minionsの最も特徴的な点は、監督する人がいないことです。」 Stripe、Minionsコーディングエージェントについて
タスクは、Slackのスレッド、バグ報告、機能要望から始められます。minionがコード、テスト、ドキュメントを書き、実行はプルリクエストで終わり、エンジニアがマージ前にレビューします。
Minionsの日々の動き
各minionはdevboxで動きます。Stripeのエンジニアが使うのと同じクラウド開発環境で、Stripeのソースコードを載せたAWS EC2インスタンスです。Stripeはウォームアップ済みのdevboxのプールを保っており、リポジトリのクローンとキャッシュの構築が済んだ新しいdevboxを10秒以内に用意できます。各devboxは隔離されているため、ミスは1つのボックスの中にとどまり、エージェントは全権限で、確認プロンプトを飛ばして動かせます。
作業はブループリントに従います。コードで定義されたワークフローです。「タスクを実装する」や「CIの失敗を直す」のように、判断の余地があるエージェントのループになっている手順もあれば、「設定済みのlinterを実行する」や「変更をプッシュする」のように、モデルを呼ばない固定のコードの手順もあります。Stripeは、予測できる手順をコードで固定すると、規模が大きくなったときにトークンとCIのコストを節約でき、エージェントが間違える余地も減らせると述べています。
コードベースを学ぶため、minionsは特定のフォルダーやファイルパターンに限定したルールファイルを読みます。形式はCursorと同じなので、人とエージェントが1つのガイダンスを共有します。生成された変更は、人のレビューの前に、CI/CDパイプライン、自動テスト、静的解析を通ります。
Stripe Minionsの結果
測られた成果は量です。2026年2月19日付の記事で、StripeのAlistair Gray氏は、毎週マージされるStripeのプルリクエストのうち1,300件を超えるものが完全にminionsによって作られていて、シリーズの第1部では1,000件だったと書きました。すべて人がレビューし、人が書いたコードは1行も含まれません。
エンジニアリングマネージャーのCameron Bernhardt氏は、エージェントがますますエンドツーエンドで変更を作るようになっていると書きました。Stripeのエンジニアは、minionsは設定変更、依存関係のアップグレード、小規模なリファクタリングのように、定義がはっきりしたタスクで最も力を発揮すると言います。Stripeは、節約できた時間、レビューの工数、欠陥率の数字は公表していません。
自律型コーディングエージェントがエンジニアリングチームにもたらす変化
企業にとって、minionsが引き受けるのは、大きなコードベースにたまる、小さくて定義がはっきりした変更の安定した流れです。アップグレード、設定、後始末など、誰も午後を丸ごと使いたくない仕事です。それをエージェントに移せば、エンジニアは設計とレビューに時間を使え、すべてのマージに責任を持つ人もいます。
Stripeの事例は、投資がどこに向かうかも示しています。モデルは一部にすぎません。成果は、人のためにそれまで作ってきたインフラから生まれます。速く隔離された開発環境、良いテスト、共有のルールファイルです。Stripeの各チームは、単純なスクリプトによるコード変更では扱えない、コードベース全体の移行向けに、自分たちのブループリントも作っています。
よくある質問
StripeのMinionsは週にいくつのプルリクエストを作りますか?
Stripeのエンジニアリングブログによると、週に1,300件を超えるマージ済みのプルリクエストが完全にminionsによって作られていて、以前は1,000件でした。
StripeのAI生成コードは人がレビューしていますか?
はい。minionのプルリクエストはすべて、マージ前に人のエンジニアがレビューします。ただしコード自体に人が書いた行は含まれません。
Stripeのコーディングエージェントはどんなタスクが得意ですか?
Stripeのエンジニアによると、設定変更、依存関係のアップグレード、小規模なリファクタリングのような、定義がはっきりしたタスクです。
MOZGIIの視点
私たちならこう作ります
Stripeの事例は、無人のコーディングエージェントが、大部分はインフラのプロジェクトだと示しています。コードを書くのはモデルですが、そのコードをマージして安全かどうかは、隔離された開発マシン、テストスイート、共有のルールファイルが決めます。これらがない会社では、プルリクエストが増えると同時にリスクも増えます。
これを作るなら、まず依存関係のアップグレードのような、狭くて退屈なタスクを1つ選び、正しい変更とは何かを書き出します。エージェントの実行はそのたびに使い捨ての環境で行い、本番や個人の認証情報にはアクセスさせません。linterやプッシュのような固定の手順は普通のコードにし、モデルには判断が要る部分だけを任せます。すべてのプルリクエストに、レビューしたエンジニアの名前を付けます。
壊れるのはレビューです。エージェントが週に数百件の変更を作ると、レビューする人は流し読みを始め、決済コードの小さな間違いが、直前のものに似ているという理由で通るかもしれません。ルールファイルも、コードベースが動くにつれて古くなります。見る指標は1つで、人の変更と比べた、後で取り消されたり修正されたりしたエージェントのプルリクエストの割合です。
次に作るのは、エージェントの変更をリスク別に仕分けるレビューキューです。小さな設定変更は素早く確認し、お金の動きに近い変更は2人目のレビュアーが見るようにします。
出典
この記事の事実の出典です。