Stripe「Minions」と社内 MCP「Toolshed」— 週1,300 PR を出す無人コーディングエージェントの足回り¶

作成日: 2026-09-27 出典: Stripe Dot Dev Blog「Minions: Stripe's one-shot, end-to-end coding agents」Part 1 / Part 2 関連: 社内saasデータ統合基盤_ai活用_事例比較_整理 / stripe_harbor_aiプロトタイピング_整理 / shopify_river_aquifer_社内エージェント基盤_整理 / 社内mcp共通基盤_認証認可ログ_整理 / メルカリ_arca_ai時代の高速プロトタイピング基盤_整理

0. 要点（3行）¶

一言で: 「エージェントに全権を渡しても大丈夫な箱（devbox）」と「全社共通の道具箱（Toolshed）」を先に作り、そこへ小さく切った道具だけ持たせて走らせる。Minions は人がコードを1行も書かない PR を週1,300本以上マージさせている。
Toolshed は社内システムと社内で使う SaaS 向けの約500の MCP ツールを持つ中央 MCP サーバー。1つ足せば数百の社内エージェント全部が使えるが、各エージェントにはタスクに関係するサブセットだけを渡す。破壊的操作は社内の統制フレームワークで禁止。
安全の本体は devbox: QA 環境で動く EC2 で、本番データ・本番サービス・任意の外部通信に触れない。だから権限確認なしに全権で動かせる。10秒で立ち上がるようにプールしてある。

1. 全体像¶

flowchart LR
    subgraph Entry[起動口]
        Slack[Slack スレッドでタグ付け]
        CLI[CLI / Web]
        Ops[社内ツールのボタン<br>ドキュメント・機能フラグ・チケット]
    end
    subgraph Devbox[devbox - QA 環境の EC2]
        Agent[Minion<br>goose フォーク]
        Rules[ルールファイル<br>ディレクトリ単位で適用]
    end
    subgraph Tools[Toolshed - 中央 MCP]
        T1[社内ドキュメント]
        T2[チケット]
        T3[ビルド状況]
        T4[Sourcegraph コード検索]
        T5[社内で使う SaaS]
    end
    Entry --> Agent
    Rules --> Agent
    Agent -->|タスク向けのサブセットだけ| Tools
    Agent --> Lint[ローカル lint<br>5秒未満]
    Lint --> CI[CI<br>最大2ラウンド]
    CI --> PR[PR 作成<br>テンプレート準拠]
    PR --> Human[人間がレビュー]

2. 起動とフロー¶

最も使われる起動口は Slack。スレッドでタグ付けすると、スレッドの内容とリンク全体を文脈として取り込む
CLI・Web のほか、社内プラットフォーム（ドキュメント、機能フラグ、チケット UI）からも起動できる。例: CI が検出したフレーキーテストを自動でチケット化し、チケットに「Minion に直させる」ボタンを置く
流れ: Slack メッセージ → devbox 起動 → エージェント実行 → ローカル lint → CI → ブランチ push → PR テンプレートに沿った PR 作成 → 人間がレビューするかを判断

3. devbox — 全権を渡せる箱¶

項目	内容
実体	ソースコードを持ち、開発中のサービスを動かす AWS EC2 インスタンス。「cattle, not pets」
起動	目標10秒以内。ギガバイト級の git クローン、Bazel と型チェックのキャッシュ温め、コード生成サービスの起動を事前に済ませたプールから払い出す
隔離	QA 環境で動作。実ユーザーのデータ、本番サービス、任意の外部通信にアクセスできない
並列	git worktree のようなオーバーヘッドなしに並列で動かせる
権限	上記の隔離があるので、人間の許可なしに全権で動かせる

メルカリ Arca（gVisor Pod ＋出口プロキシ）と比べると、Stripe は「そもそも本番とつながっていない環境」で安全を取っている。PoC 用途の Arca は社内ツールや GCP に実際につなぐ必要があるので、出口制御で守る方向になる。

4. Toolshed — 中央集約の MCP サーバー¶

flowchart TB
    Eng[エンジニアがツールを追加] --> TS[Toolshed<br>約500 MCP ツール]
    TS --> A1[Minions<br>既定は小さなサブセット]
    TS --> A2[他の社内エージェント<br>数百種類]
    TS --> A3[個人がテーマ別ツール群を追加した Minion]
    Guard[社内セキュリティ統制<br>破壊的操作を禁止] -.->|適用| TS

論点	Stripe のやり方
ツール数	Part 1 では「400以上」、Part 2 では「約500」
つながる先	社内システムと、Stripe が使う SaaS プラットフォーム（個別の SaaS 名は記事に記載なし）
配り方	ツールを1つ足すと数百のエージェント全部が使える「共有の能力層」
絞り方	「小さな箱」の方がエージェントの性能が良いので、タスクに関係するサブセットだけを要求させる。Minions は意図的に小さい既定セット。個人がテーマ別のツール群を追加できる
統制	社内のセキュリティ統制フレームワークで、ツールによる破壊的操作をできなくしている（仕組みの詳細は記載なし）
資格情報	記事に記載なし

5. blueprint — 決定的な処理とエージェントを混ぜる¶

stateDiagram-v2
    [*] --> Implement
    Implement: Implement task（エージェント）
    Implement --> Lint
    Lint: Run configured linters（決定的）
    Lint --> Push
    Push: Push changes（決定的）
    Push --> CIRun
    CIRun: CI 実行（決定的）
    CIRun --> Done: 成功
    CIRun --> AutoFix: 失敗・自動修正あり
    AutoFix: 自動修正を適用（決定的）
    AutoFix --> Done
    CIRun --> FixCI: 失敗・自動修正なし
    FixCI: Fix CI failures（エージェント・もう1回だけ）
    FixCI --> Done
    Done --> [*]

「Implement task」「Fix CI failures」のようなエージェントノードは、入力に応じて広い裁量で判断する
「Run configured linters」「Push changes」のような決定的ノードは LLM を呼ばずにコードを実行するだけ
CI は最大2ラウンド。自動修正があるテストはそれを適用し、無い場合だけエージェントにもう1回の機会を与え、その後は人間に渡す
ローカルでは5秒未満でヒューリスティックに選んだ lint を回し、CI では300万のテストから選んで実行する

図は記事の説明から起こしたもので、ノード名は記事の例示。実際の blueprint の全ノードではない。

6. ルールファイル¶

人間が Cursor や Claude Code で使うのと同じルールファイルを読む
ほとんどのルールはサブディレクトリやファイルパターン単位で条件付き適用（Cursor 形式）。全部を常に読ませて文脈を浪費しないため

7. データ・SaaS アクセスの観点で読む¶

観点	Stripe の答え
本番データ	そもそも触らせない（devbox は QA 環境）
社内知識・SaaS	Toolshed 経由の MCP ツールで取得（ドキュメント・チケット・ビルド状況・コード検索など）
ツールの暴走	破壊的操作は統制で禁止、渡すツールは最小限
知識の配り方	ルールファイルをディレクトリ単位で

持ち帰れる原則: 社内 MCP は「集約は1か所、配布は小さく」。全ツールを全エージェントに渡すと、精度も安全性も下がる。

8. まとめ¶

一言で: 「安全な箱」「共通の道具箱」「決定的な手順との混ぜ方」の3点セット。

状況	Stripe から借りるアイデア
エージェントに権限確認なしで作業させたい	本番から切り離した環境（QA / sandbox）で全権を渡す
社内ツール連携が乱立しそう	中央の MCP サーバー1つに集約し、全エージェントで共有
ツールが多すぎて精度が落ちる	タスク別のサブセットだけを渡す
エージェントが CI を延々と回す	回数上限（2回）を決めて人間に渡す
lint・push などを LLM にやらせて不安定	決定的ノードとして固定し、LLM は判断が要る箇所だけ

参考リンク¶

Stripe「Minions: Stripe's one-shot, end-to-end coding agents」Part 1: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents
Part 2: https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2
Block goose: https://github.com/block/goose

作成: 2026-09-27 ／最終更新: 2026-09-27