Stripe が開発した minions は、人間が書いたコードなしで毎週 1,300 件以上のプルリクエストをマージする自社製エージェントシステムです。Sierra の Pinecone は彼らの PR の 70% を開いています。これらの記事は素晴らしいです。まだ読んでいなければ、読むべきです。読んだことがあるなら、おそらく自分で構築するべきかどうか考えたことでしょう。
ほとんどのチームにとって、答えは「ノー」だと思います。Stripe や Sierra が間違っていたからではありません。彼らはこれらのアイデアに早くから取り組み、それを実現できるチームを持っています。しかし、今では彼らが構築しなければならなかった（ほぼ）すべてを購入することができます。ほとんどの組織は別の何か、つまり価値へのスピードを最適化すべきです。私は Cursor で働いているので、偏見があるかもしれませんが、以下にその理由を挙げます。
1. 差別化された部分は結局のところ移植可能
クラウドエージェントシステムの中で、あなたのものらしく感じさせるのはコンテキストレイヤーです。あなたの規約をエンコードするルール、再利用可能な指示を体系化するスキル、内部システムへのアクセスを提供する MCP、エージェントが書いた内容を検証するワークフロー。Stripe の minions が、エンジニアが Cursor や Claude Code 向けに書くのと同じルールファイルを読み、同じ内部 MCP ツールからコンテキストを取得するとき、その仕事をしているのはコンテキストです。
このレイヤーについて重要なのは、システムの中で最も差別化された部分であり、かつ最も移植性が高いということです。ルールファイル、スキル、MCP 設定はどこでも同じように機能し、ベンダーに縛られることもありません。Stripe は Cursor のルール形式を標準化することでその点を証明しました。つまり、1 セットのルールが minions、Cursor、Claude Code を同様にガイドするのです。したがって、「プラットフォームを購入すれば差別化を放棄することになる」というよくある懸念は、まったく心配する必要がありません。差別化された部分は何があっても保持できます。購入することは、その下にあるすべてをスキップすることを意味します。
2. 構築は見た目よりもはるかに大規模
VM でエージェントを動かすこと？それは週末でできます。しかし、99.99% の信頼性と 10 秒未満の環境起動を実現するには？それは複数四半期にわたるインフラプロジェクトです。私たち Cursor は 18 か月間クラウドエージェントを構築してきましたが、これは無期限の投資分野になると確信しています。
品質の問題もあります。うまく動作する内部ビルドでも、人々が実際に使いたくなるような細部へのこだわりが欠けていることがよくあります。80% の品質しかない内部ツールは、使用率が 20% にとどまります。ほとんどのチームは Slack ボットを出荷したらそこで止まってしまいます。なぜなら、同じエージェントを IDE、CLI、Web、モバイル、Jira などに統合するのは、あまりにも広範囲に及ぶからです。さらにガバナンスの問題もあります。ユーザー管理、トークン分析、予算管理、監査証跡。これらはすべて必須であり、どれも差別化にはなりません。
説明責任も、構築の見積もりには決して含まれないコストです。エージェントは何かをやらかします。やがてそのうちの 1 つが間違ったことをします。そのとき、誰もがそのシステムを構築したチームを見ます。そしてそのチームがインシデント、ポストモーテム、修復を担当することになります。購入してもインシデントが起きなくなるわけではありませんが、セキュリティチームを持つベンダーがあなたの隣で責任を負うことになります。
3. 技術の最先端は止まらない
1 ～ 2 か月ごとに、先進的なチームが SDLC を自動化するより良い方法を考案し、あなたが 3 か月前に構築したものは時代遅れに見えます。ファインチューニングされたコードモデルは、次のフロンティアリリースに追い抜かれました。誰もが構築した RAG スタックは、ロングコンテキストとエージェント検索に敗れました。カスタム統合は一夜にして MCP 設定になりました。Sierra でさえ、git worktree で並列エージェントから始め、数か月でそれを乗り越えました。
Cursor の規模では、そのような変化を受け入れることができます。私たちは喜んで再構築します。なぜなら、そのコストは何千もの顧客に分散され、それでも計算が成り立つからです。同じ規模により、交渉されたクラウド契約や、内部デプロイでは実現不可能なマルチテナントのビンパッキングが可能になります。社内の devex チームにとって、同じ変化は税金です。再発明のたびに、すでに内部顧客でいっぱいのロードマップに着地します。あなたは恒常的な R&D の treadmill に乗りたくはないはずです。あなたのためにそれを実行してくれるスケールしたパートナーが必要です。
4. 購入しても制御を放棄することにはならない
最後の反論は制御です。ほとんどの構築決定は、実際にはベンダーロックインの恐れを偽装したものです。ですから、どこで実際に選択肢が必要なのかを具体的にしましょう。明白なのはモデルです。トークン消費は実際の費用項目になりつつあり、能力とコストのパレート最前線は数週間ごとに動きます。モデルに中立なプラットフォームを使えば、今週誰がリードしているかに関係なく、常に最高のものにアクセスできます。
もう 1 つはエージェント実行レイヤーです。完全に Cursor ホストから、完全に自社ネットワーク内でのセルフホストまで、エージェントが内部エンドポイントやテストインフラにアクセスできるように、好きな方法で実行できます。セキュリティ体制はデプロイの選択肢になり、構築の理由ではなくなります。
構築が理にかなう場合
構築に傾く要素がいくつかあります。以下の特徴が多く当てはまるほど、構築の根拠は強くなります。
- あなたの製品がエージェントインフラである場合。Sierra は AI エージェントを販売して生計を立てています。エージェントシステムの構築は彼らの DNA に組み込まれており、数百人の従業員が毎日ドッグフーディングしています。彼らは確かにコーディングエージェントシステムを構築する専門知識を持っています。
- すでに難しい部分を所有している場合。Stripe は、10 年かけて完成させた devbox 上で minions を実行しました。彼らにとって、その devbox を中心にエージェントシステムを構築することは、既製の製品に合わせて devbox を曲げるよりもおそらく簡単です。あなたの開発インフラがそれほど成熟していて、それほど特注品であるなら、同じ計算があなたにも当てはまる可能性があります。
- 無期限に製品のように資金を提供する場合。ロードマップ、オンコール、再編成にも耐える予算を持つスタッフチーム。それでも、ゼロから始めるべきではありません。Cursor SDK のようなビルディングブロックは、すぐに使えるモデルに依存しないエージェントハーネスを提供するので、チームの努力はあなたに固有の部分に集中できます。
功績を称えて
Stripe、Sierra、そしてエージェントエンジニアリングの限界を押し広げている他のチームには多大な敬意を表します。彼らのエンジニアリングチームは超一流です。しかし、ほとんどの組織は彼らの足跡をたどる必要はありません。必要なのは価値へのスピードと、彼らの代わりに最先端であり続けることを仕事とするパートナーです。ほぼすべての人にとって、それは完全なカスタマイズよりも価値があります。
すぐに AI ネイティブになりましょう。その後、どの部分を社内に取り込むかを、一つずつ決めてください。
