AIソフトウェアファクトリーの構築方法：プルリクエストを開き、レビューし、マージするエージェント

AIソフトウェアファクトリーの構築方法：プルリクエストを開き、レビューし、マージするエージェント Hiba Fathima 2026年9月11日 要約：AIソフトウェアファクトリーは、各段階にゲートを持つ5つの段階から構成されます。エージェントは安価な部分です。 段階 決定内容 公開されている例 受付 開始する価値のある作業はどれか SentryのSeerは、アクション可能性について、受信したすべての問題をスコアリングします。 分離 エージェントが衝突することなく実行される場所 Stripeは、約10秒で事前ウォームアップされた開発ボックスを起動します。 ツール エージェントが到達できるもの StripeのToolshedは、MCP経由で約500の内部ツールを公開しています。 検証 変更が正しいかどうか SpotifyのLLMジャッジは、エージェントセッションの約25%を拒否します。 マージゲート 誰が責任を負うか Faireは、エージェント作成のPRに対して2回の人間によるレビューを要求します。 短く言うと、これを機能させたすべての企業は、フリート（エージェント群）の前にゲートを構築しました。SpotifyのFleetshiftは、エージェントを搭載する2年前にあたる2023年に出荷されました。生成はコスト（spend）に比例してスケールしますが、レビューはそうではありません。この非対称性が、設計上の問題のすべてです。 Firecrawlがフィットする場所。 エージェントには、リポジトリが持っていないライブウェブコンテキストが必要です。オープンウェブを検索・スクレイピングし、コード用のキュレーションされた開発者インデックスを使用します。これらはすべて1つのMCPブロックの後ろにあり、各フェッチでプロンプトインジェクション検出が行われます。 2026年1月6日、Stephen Toubは高度35,000フィートから携帯電話で9件のプルリクエストを開きました。そのうち7件がマージされました。彼はdotnet/runtimeで作業しており、その経験から得たことをまとめています：AIはコード生産の経済性を変えます。優れた判断力と電話を持つ一人の人間が、チームがレビューできるよりも速くPRを生成できます。その文が、主題のすべてです。コーディングエージェントを持つ一人のエンジニアが、飛行機座席からチームのレビュー能力を飽和させることができます。興味深い問題は、エージェントにコードを書かせる方法から、その出力を吸収する方法へと移行しました。AIソフトウェアファクトリーは、企業が収束してきた答えであり、自律型コーディングエージェントをデモからチームが吸収できるスループットへと転換するものです。このガイドでは、それを5つの段階に分解し、各段階には公開されているアーキテクチャと構築するための設定が含まれています。AIエージェントがどのように推論し、ツールを呼び出し、ウェブコンテキストを取り込むかについてのより広い視野を得るには、まずその入門書を参照し、次にコーディングエージェントフリートが実際にどのように出荷されるかについてここに戻ってきてください。すでにエージェントを選択したと仮定します。これは、最高のAIコーディングエージェントのまとめでカバーしました。ソフトウェアファクトリーは、それを取り巻くすべてです。 AIソフトウェアファクトリーとは何か？ AIソフトウェアファクトリーとは、エージェント自体ではなく、コーディングエージェントを取り巻くシステムです。作業はキューから到着し、エージェントは隔離されたワークスペースで実行され、検証は自動的に行われ、人間は明示的なマージゲートに座ります。エージェント型ソフトウェアファクトリーとも呼ばれます。 有用な区別は、エージェントとソフトウェアファクトリーの間です。ラップトップでコーディングエージェントを実行するのはエージェントです：タスクを選択し、それが動作するのを見て、差分を読み、マージします。タイピング以外のすべてはまだあなたであり、あなたの注意が限界です。 ソフトウェアファクトリーは、これらのステップをインフラストラクチャに移行させます。受付ルールによって、どの問題にエージェントが取り組むかを誰も決定しません。分離がプロビジョニングされるため、ワークスペースを誰もセットアップしません。検証が人間が関与する前に実行されるため、変更がコンパイルされるかどうかを誰もチェックしません。その人は、説明責任を伴う決定の最後に現れます。 Addy Osmaniは、これをより簡潔に述べています：ソフトウェアファクトリーとは、規模でのループを活用することです。彼が意味するループは、ループエンジニアリングのガイドでカバーしたものです：実行し、自身の作業をチェックし、検証者が停止と言うまで再度実行するエージェントです。ソフトウェアファクトリーは、誰も監視せずにそれらを一度に多数実行する機械です。 真のソフトウェアファクトリーとスクリプトの山を分ける3つの特性があります： 1. キュー駆動であり、プロンプト駆動ではない。作業は、問題、アラート、またはSlackチャネルから入力され、システムが開始する価値のあるものを決定します。誰もプロンプトを入力していません。 2. 環境は使い捨て可能である。各エージェントは、破壊できるクリーンなワークスペースを取得するため、悪い実行はコストがかからず、並列実行は互いに破損できません。 3. 検証はレビューの前に実行される。差分が人に届く頃には、すでにコンパイルされ、テストに合格し、スコープがチェックされています。 3番目を逃すと、ソフトウェアファクトリーを構築したことになりません。レビュー作業を吸収できるよりも速く生成する機械を構築したことになります。これは、この記事の残りが回避するために構成されている失敗モードです。 VercelのCEOであるGuillermo Rauchは、Vercelがクラウドコーディングエージェントの参照プラットフォームをオープンソース化した際に戦略的なケースを提示し、この記事が参照しているのと同じシステムを挙げました： 「Stripe（Minions）、Ramp（Inspect）、Spotify（Honk）、Block（Goose）などの企業が独自の「AIソフトウェアファクトリー」を構築していると聞きました。なぜでしょうか？ [...] ビジネスレベルでは、ソフトウェア企業の堀は「彼らが書いたコード」から、そのコードの「生産手段」へとシフトします。アルファはあなたのファクトリーにあります。」 @rauchg、2026年4月14日 公開されているすべてのソフトウェアファクトリーが共有する5つの段階 これらのシステムのほとんどは、バックグラウンドコーディングエージェントに基づいています。つまり、エディタではなく、独自の環境で無人で実行されるエージェントです。これらのアーキテクチャを十分に読めば、企業が何と呼んでいても、同じ骨格が現れます。MastraはMastra Factoryとして6つの名前付き段階で出荷しています。Spotifyはそれをネストされたフィードバックループとして説明しています。Stripeは、その部分をブループリントと呼んでいます。形状は同じです。 段階 Stripe (Minions) Spotify (Honk) Shopify (River) Ramp (Inspect) 受付 Slackメッセージ、絵文字リアクション Fleetshiftがリポジトリ全体でターゲットを選択 @riverが公開チャンネルで 割り当てられたタスク 分離 事前ウォームアップされたEC2開発ボックス Kubernetesポッド、アクセス制限付き 耐久性のあるセッションの使い捨てハーネス ファイルシステムスナップショットからのModalサンドボックス ツール Toolshed、約500の内部MCPツール MCP経由の内部システム 認証情報プロキシとゲートウェイ テスト、テレメトリ、機能フラグ、スクリーンショット 検証 5秒未満でのLintとテスト、その後キャップ 決定論的チェック、LLMジャッジ、CI 自動PRレビューモード 視覚的およびテレメトリ検証 マージゲート 2回のCI実行後の人間によるレビュー 人間によるレビュー 人間によるレビュー 人間によるレビュー 段階の順序は、ツールよりも重要です。各ゲートは、作業が次の段階に到達するのを止め、高価な段階は最後に配置されます。 詳細に入る前に、構造的な注意点があります。Anthropicのマネージドエージェントアーキテクチャは、ソフトウェアファクトリーをブレイン（モデルとハーネス、ステートレス）、ハンド（使い捨て可能なサンドボックス）、セッション（耐久性のある追記専用イベントログ）に分割します。ShopifyはそれをUnder the Riverで直接引用しています。この記事から何も構築しないのであれば、セッションログを構築してください。なぜなら、それが他のすべてを使い捨て可能にするものだからです。 単一セッション内でエージェントを並列実行することは、フリートを実行することとは異なる問題です。Codexを使用したマルチエージェントオーケストレーションのガイドでは、サブエージェント、ファンアウト、ワークツリーのメカニクスをそのレベルでカバーしています。 段階1：作業がエージェントに到達する方法 受付は、開始する価値のあるものを決定します。これを間違えると、すべての下流段階が、開始すべきでなかった作業にトークンを浪費します。単純なバージョンは、すべてのアクティブな問題にエージェントを割り当てます。公開されているバージョンはすべて、まずフィルタリングします。 SentryのSeerは、受信した各エラーのアクション可能性をスコアリングし、バーをクリアしたものだけを調査します。 Shopifyは異なる判断を下し、受付をSlack経由でルーティングしました。ルールは1つです：エージェントは公開チャンネルで作業し、DMでは決して作業しません。ShopifyのCEOであるTobi Lütkeは、この制約を意図的なものとして説明しました： 「Riverはダイレクトメッセージに応答しません。彼女は丁寧に断り、あなたと彼女が作業を開始するための公開チャンネルを作成することを提案します。[...] そのため、すべての会話は検索可能です。Shopifyの誰でも参加できます。」 @tobi、2026年5月9日 議論は技術的なものではなく、組織的なものです。プライベートなエージェントセッションは一人の人間を教育し、ウィンドウと共に消滅します。 最小限の受付フィルターは、ラベルとクエリです。これは、人間が明示的にエージェント適格とマークした問題を、小さくプルします：gh issue list --label "agent-ready" --state open --limit 20 --json number,title,labels,body -