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

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

TL;DR

AIソフトウェアファクトリーは、各段階にゲートを持つ5つのステージで構成され、コーディングエージェントはその中で最も安価な要素です。

これを機能させたすべての企業は、エージェントよりも先にゲートを構築しました。SpotifyのFleetshiftは、エージェントを搭載する2年前に2023年にリリースされました。トークン消費はより多くのコード生成を可能にしますが、レビュー能力は別の方法で構築する必要があり、それが設計作業の大部分を占めます。

Firecrawl がフィットする場所。 エージェントは、リポジトリが持っていないライブWebコンテキストを必要とします。検索+スクレイピングによるオープンWebと、コード用のキュレーションされた開発者インデックスの両方が、1つのMCPブロックの背後にあり、すべてのフェッチでプロンプトインジェクション検出が行われます。

---

2026年1月6日、Stephen Toubは高度35,000フィートから携帯電話で9件のプルリクエストを開きました。そのうち7件がマージされました。彼はdotnet/runtimeを担当しており、その経験から得たことをまとめています。

AIはコード生産の経済性を変えます。優れた判断力と携帯電話を持つ一人の人間は、チームがレビューできるよりも速くPRを生成できます。

同じリポジトリからの10ヶ月間のデータがそれを裏付けています。エージェントはそこで878件のプルリクエストを開き、2人のレビュアーがそのうちの36%のフィードバックを作成しました。ボトルネックはコードを書くことからチェックすることに移り、チェックは依然として少数の人々を通して実行されていました。

Stripe、Spotify、Shopify、Uber、Rampはそれぞれ同じ壁にぶつかり、それぞれが同じ種類のシステムをエージェントの周りに構築しました。そのシステムこそが、この記事がAIソフトウェアファクトリーと呼ぶものです。それは、何を開始する価値があるかを決定するキュー、隔離されたワークスペース、共有ツールレイヤー、自動検証、そして人間がマージゲートにいるというものです。以下の5つのステージは、それぞれが公開しているアーキテクチャの概要と、自分で構築するための設定をカバーしています。

このガイドでは、すでにエージェントを選択しており（最高のAIコーディングエージェントのまとめで比較しました）、AIエージェントがどのように推論し、ツールを呼び出し、Webコンテキストを取り込むかについて大まかに理解していることを前提とします。ファクトリーとは、エージェントを取り巻くすべてのものです。

AIソフトウェアファクトリーとは何か？

AIソフトウェアファクトリーとは、エージェント自体ではなく、コーディングエージェントを中心としたシステムのことです。作業はキューから到着し、エージェントは隔離されたワークスペースで実行され、検証は自動的に行われ、人間は明示的なマージゲートに配置されます。一部のライターはこれをエージェンティックソフトウェアファクトリーと呼んでいます。

ラップトップでコーディングエージェントを実行する場合、タスクを選択し、それが作業するのを見て、差分を読み、マージします。タイピング以外のすべては依然としてあなた自身であり、あなたの注意力が限界です。

ソフトウェアファクトリーは、これらのステップをインフラストラクチャに移します。受付ルールは、エージェントがどの問題を拾うかを決定します。ワークスペースは手動で設定するのではなくプロビジョニングされます。検証は、人間が関与する前に実行されます。担当者は最後に、責任を伴う決定のために現れます。

Addy Osmaniは、より簡潔に述べています。

ソフトウェアファクトリーとは、ループを大規模に活用することです。

彼が言うループとは、ループエンジニアリングのガイドでカバーしたものです。エージェントが実行し、自身の作業をチェックし、検証者が停止と言うまで再度実行します。ソフトウェアファクトリーは、誰も監視せずにそれらを多数同時に実行する機械です。

3つの特性がソフトウェアファクトリーをスクリプトの山から区別します。

• 作業はキューから到着する。 問題、アラート、またはSlackチャネルから入力され、システムが開始する価値のあるものを決定します。人間がプロンプトを入力するのではなく。
• 環境は使い捨てである。 各エージェントはクリーンなワークスペースを取得し、それを破棄できます。そのため、悪い実行は何もコストがかからず、並列実行は互いに破損させることはありません。
• レビューの前に検証が実行される。 差分が人に届く頃には、すでにコンパイルされ、テストに合格し、スコープがチェックされています。

3番目のものがなければ、ソフトウェアファクトリーを構築したことにはなりません。吸収できないよりも速くレビュー作業を生成する機械を構築しただけです。この記事の大部分はそれを回避することについてです。

Guillermo Rauch、VercelのCEOは、Vercelが独自のクラウドコーディングエージェントの参照プラットフォームをオープンソース化した際に、戦略的な議論を行いました。そして、この記事が参照しているのと同じシステムに言及しました。

Stripe (Minions)、Ramp (Inspect)、Spotify (Honk)、Block (Goose)などの企業が独自の「AIソフトウェアファクトリー」を構築していると聞いたことがあるでしょう。なぜでしょうか？ [...] ビジネスレベルでは、ソフトウェア企業の堀は「彼らが書いたコード」から「そのコードの生産手段」へとシフトします。アルファはあなたのファクトリーにあります。

@rauchg、2026年4月14日

公開されているすべてのソフトウェアファクトリーが共有する5つのステージ

これらのシステムのほとんどは、バックグラウンドコーディングエージェントに基づいています。つまり、エディタではなく、独自の環境で無人で実行されるエージェントです。この同じ骨格が、会社がそれを何と呼ぼうとも、これらのアーキテクチャのすべてに現れます。MastraはMastra Factoryで6つの命名ステージとして出荷しています。Spotifyはそれをネストされたフィードバックループとして説明しています。Stripeはそれらをブループリントと呼んでいます。

［画像: AIソフトウェアファクトリーの5つのステージの図。受付、分離、ツール、検証、マージゲートが左から右へのパイプラインとして示され、作業の受け入れ、計画の承認、マージのための人間のゲートが間に配置されている］

順序はツールよりも重要です。各ゲートは次のステージへの作業の到達を停止し、高価なステージは最後に配置されます。

Anthropicのマネージドエージェントアーキテクチャは、ソフトウェアファクトリーを脳（モデルとハーネス、ステートレス）、手（使い捨てサンドボックス）、セッション（耐久性のある追記専用イベントログ）に分割します。ShopifyはUnder the Riverでそれを直接引用しています。セッションログは、他のすべてを使い捨て可能にするものなので、最初に構築すべき部分です。

単一セッション内でエージェントを並列実行することは、フリートを実行することとは異なる問題です。Codexによるマルチエージェントオーケストレーションのガイドでは、そのレベルでのサブエージェント、ファンアウト、ワークツリーの仕組みをカバーしています。

ステージ1：作業がエージェントに到達する方法

受付は、何を開始する価値があるかを決定します。それが間違っていると、後続のすべてのステージが、開始すべきでなかった作業にトークンを浪費します。

単純なバージョンでは、すべてのアクティブな問題にエージェントを割り当てます。公開されているバージョンはすべて最初にフィルタリングします。SentryのSeerは、各新規エラーのアクション可能性をスコアリングし、バーをクリアしたものだけを調査します。Shopifyは別の決定を下し、受付をSlack経由でルーティングし、エージェントが公開チャンネルでのみ作業することを要求しました。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 \
  --jq '.[] | select(.labels | map(.name) | index("needs-design") | not)'

Microsoftのデータはサイズフィルタを説明しています。dotnet/runtimeでの10ヶ月間、1〜50行のエージェントPRは76〜80%の成功率でしたが、パフォーマンス作業は54.5%でした。公開されている要約はそれを直接述べています。Copilotのコーディングエージェントは「適切に指定された変更の実装に優れ、問題を調査するのに非常に優れており、ソリューションのアーキテクチャリングには比較的劣っています」。

重複排除ゲート、そしてなぜそのほとんどのバージョンがオープンに失敗するのか

受付は、誰かがすでに上流で問題を修正したかどうかを確認する必要があります。

一人のエンジニアにとっては、それはあれば便利な機能です。Stripeの週1,300件のマージ済みエージェントPRでは、解決済みの問題にエージェントを起動することは、ファクトリーが存在する理由である無駄であり、何かチェックしない限り何も表面化しません。

Firecrawlの開発者インデックスは、この質問のために構築されています。ブログ記事ではなく、問題スレッド、マージ済みプルリクエスト、README、ドキュメントをインデックス化します。関連する依存関係にスコープを設定します。

curl -X POST https://api.firecrawl.dev/v2/search/developer \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"connection pool exhausted under high concurrency",
       "k":3,"types":["issue","pull_request"],
       "repos":["magicstack/asyncpg"],"passages":1}'

reposでスコープを設定すると、レスポンスにトップレベルのreposブロックが追加されます。これは、一見同じように見える2つのケースを分離します。

{ "success": true, "partial": false,
  "repos": [ { "repo": "magicstack/asyncpg", "indexed": true,
               "types": { "issue": true, "pullRequest": true, "readme": true } } ] }

{ "success": true, "partial": false,
  "repos": [ { "repo": "acme/internal-fork", "indexed": false,
               "types": { "issue": false, "pullRequest": false, "readme": false } } ] }

どちらもsuccess: trueでHTTP 200を返します。2番目は結果をゼロ返します。したがって、if not results: spawn_agent()として書かれたゲートは、「誰もこれを報告していない」と「そのリポジトリのカバレッジがない」を区別できず、両方を通過させてしまいます。

repos[0].indexedを読み、falseをクリアではなく不明として扱います。不明は、人間へのルーティングまたはスコープ外の再試行につながります。これは1行の変更です。

単一の問題トリアージでは、生産バグがそもそも自分のものかどうかという問題ですが、コーディングエージェントによる本番バグの修正でワークフローを詳細にカバーしました。

ステージ2：分離モデルを選択する

2つのエージェントが1つの作業ディレクトリを編集すると、1日かかります。自家製のファクトリーは、約4番目の同時エージェントまでうまく機能しますが、そこで停滞する傾向があります。

3つのモデル、コストと機能の昇順で示します。

Worktreesから始めるのが良いでしょう。Git worktreeは、独自のブランチ上の2番目の作業ディレクトリであり、1つのリポジトリを共有します。以下の例ではClaude Codeを使用していますが、Codexでもパターンは同じです。長いタスクでの両者の動作をClaude Code vs Codexで比較しました。Claude Codeはセッションごとに1つ作成します。

claude --worktree feature-auth

これは.claude/worktrees/feature-auth/にworktree-feature-authという名前のブランチとして配置されます。分離を特定のサブエージェントにピン留めすることもできます。これにより、リファクタリングエージェントは常に独自のツリーを取得します。

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---
 
Apply the requested refactor across every affected file, then run the tests
and report the results.

Worktreesは空から始まる

worktreeは新しいチェックアウトなので、.env、node_modules、および空きポートは含まれていません。それらの3つが、4番目のエージェントで問題を引き起こします。チームはworktreeが「スケーリングしない」と結論付けますが、それは設定されていないチェックアウトに当たっただけです。

Claude Codeは、プロジェクトルートにある.worktreeincludeファイルを使用して、gitignore構文でファイル部分を処理します。

.env
.env.local
config/secrets.json

ポートとデータベースは依然として自分で解決する必要があります。それらをworktree名から割り当てるのではなく、ハードコーディングし、各エージェントに独自のデータベースを与えます。その際、.claude/worktrees/を.gitignoreに追加してください。

さらに2つの設定があります。新しいworktreeはリポジトリのデフォルトブランチからブランチされます。これは通常、独立したタスクでは望ましいことです。エージェントが進行中の作業を必要とする場合は、worktree.baseRefを"head"に設定します。また、プルリクエストから直接worktreeをブランチすることもできます。これにより、エージェントをレビューフィードバックに向けることができます。

claude --worktree "#1234"

クリーンアップは忘れがちです。インタラクティブセッションは終了時にプロンプトを表示しますが、-pを使用した非インタラクティブな実行はまったくクリーンアップせず、後続のスイープが解放するまでロックを保持します。フリートをスクリプト化している場合は、明示的にクリーンアップしてください。

git worktree list
git worktree remove .claude/worktrees/feature-auth
# gitがツリーがロックされているために拒否する場合
git worktree unlock .claude/worktrees/feature-auth

エージェントが競合する依存関係バージョンを必要とし始めたらコンテナに、並列処理がインフラストラクチャ実行コストよりも重要になったらクラウドサンドボックスに移行します。RampのInspectは、最上位の主張をしています。「バックグラウンドエージェントが高速である場合、それらはローカルよりも間違いなく優れています。同じインテリジェンス、より多くのパワー、そして無制限の並列処理です。」

ステージ3：ツールレイヤー

リポジトリを読み取ることしかできないモデルは、追加ステップ付きのオートコンプリートです。テストランナー、テレメトリ、フィーチャーフラグ、デプロイツーリングを接続すると、同僚の仕事を始めるようになります。その配線がツールレイヤーであり、5つのステージの中で最も注目されない部分です。

公開されている数値は、リーダーがここにどれだけ投資しているかを示しています。StripeのToolshedは、1つのMCPサーバーの背後に約500の内部ツールをホストし、破壊的なアクションをブロックする制御を備えています。Cloudflareは内部MCP Portalを実行しており、3,900以上のリポジトリにわたってAGENTS.mdを生成しました。Rampは、テスト、テレメトリクエリ、フィーチャーフラグ、スクリーンショット検証を各サンドボックスに配線します。

これはエージェントごとの設定ではなく、フリート全体の構成です。1つのMCPブロックがすべてのエージェントに到達します。

{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": { "FIRECRAWL_API_KEY": "${FIRECRAWL_API_KEY}" }
    }
  }
}

ソフトウェアファクトリーの代表的なツールレイヤーは、おおよそ次のようになります。

Rauchは同じ点をさらに押し進め、コンテキスト自体が一箇所に存在するべきだと主張しています。

あなたのソフトウェアファクトリーはモノレポであるべきです。あなたの会社のコンテキスト（デザイン、マーケティング、セールス、エンジニアリング、サポート…）すべてが一箇所にあり、エージェントがそれを基盤に構築できます。

@rauchg、2026年8月18日

Firecrawlでも同じ場所にたどり着きました。私たちは、製品やエンジニアリングからマーケティング、セールス、サポートまで、会社のコンテキスト全体をエージェントが読み取れる一箇所に保持するFirebrainという内部モノレポを実行しています。エージェントは、会社がどのように機能するかをすでに知った状態でタスクを開始します。それは私たちにとってほとんどのチームよりも重要です。私たちは5つの大陸と多くのタイムゾーンにまたがる完全リモートなので、リポジトリはしばしば唯一起きている同僚です。

指示ファイルを短く保ちます。OpenAIのCodexチームは、約100万行のリポジトリを、約100行のAGENTS.mdで管理しています。これは「主にマップとして機能し、より深い真実の源へのポインタを提供します」。Microsoftのデータは、反対方向から同じことを示しています。.github/copilot-instructions.mdとファイアウォール構成を追加したことで、dotnet/runtimeでのエージェントの成功率が41.7%から持続的な71%に向上しました。これは、同時期のモデルアップグレードよりも大きな成果でした。

MCP経由でツールを配線することと、エージェントにシェルアウトさせることのトレードオフについては、MCP vs CLIの比較とエージェントにとってCLIが優れている理由を参照してください。フリート内のすべて のエージェントが引き継ぐ役割をパッケージ化するには、Claudeプラグインとスキルの概要を参照してください。ファクトリーが初日から導入できる市販の開発者向けMCPサーバー（Webデータ、デザイン、ブラウザ自動化、コード実行）については、2026年のまとめを参照してください。

ステージ4：検証はソフトウェアファクトリーが異なる場所

すべてのソフトウェアファクトリーはコードを生成します。生成と人間の目の間で行われることにおいて、それらは異なります。

Spotifyのフィードバックループ投稿は、最も明確な構造、つまり最も安価なものから始まるネストされたループを説明しています。

1. 内部ループ。 リポジトリ内にあるものから自動的に選択される決定論的な検証ツール、つまりフォーマット、コンパイル、テストであり、モデルは関与しません。
2. ジャッジ。 モデルは、差分がスコープ内に収まっているかを評価します。これはエージェントセッションの約25%を却下し、そのうち約半分は作業を破棄するのではなく、エージェントをコース修正することで回復可能です。
3. 外部ループ。 CIおよびPRチェック。

Spotifyはまた、失敗モードをランク付けしており、そのランク付けはコピーする価値があります。失敗したPR生成は迷惑です。CIに失敗したPRはエンジニアの負担です。CIに合格し、機能的に間違っているPRは、システム全体の信頼を損ないます。生成時に失敗することを目指してください。CIやレビュアーに到達する前です。

信頼度スコアの罠

Faireはfaire-reviewという内部レビュアーを構築し、最初に明白な品質レバーを試しました。モデル自身の信頼度スコアでコメントをフィルタリングしました。最も厳しいゲートでは、すべてのコメントの65%が破棄され、受け入れ率は3%しか向上しませんでした。彼らのレポートは、0.93とスコアされたコメントが却下された一方で、0.35とスコアされたコメントが受け入れられて修正されたことを示しています。

受け入れ率を73%に引き上げたのは、変更に関するより良いコンテキスト、コメントが価値のある場所へのより良いターゲティング、そして固定しきい値に代わるモデルグレードのゲートでした。自己申告の信頼度は品質シグナルではないことが判明しました。コメントが人間の時間の価値があるかどうかを尋ねる2番目のモデルがそれでした。

AIコードレビューはソフトウェアファクトリーで最も広く展開されている部分であり、UberはuReviewで異なる方向から同じ結論に達しました。これは現在、約65,000件の週次差分の90%以上をカバーしています。Uberの原則は、ボリュームよりも精度です。なぜなら、開発者はノイズの多いレビュアーを信頼しなくなるからです。uReviewのコメントの65%は、人間によるレビュアーの51%と比較して、同じ変更セットで対処されます。

テストがカバーしないチェック

決定論的な検証ツールは、コードがコンパイルされ、テストがパスしたかどうかを回答します。どちらの質問も、ページがまだ正しく表示されているかどうかをカバーしません。CSSの変更は、内部ループのすべてのチェックをクリアし、電話ビューを静かに壊す可能性があります。なぜなら、レイアウトが合理的であると主張するテストを書いているチームはほとんどいないからです。

そのギャップは、Spotifyが最も有害だとランク付けする失敗モードであるため重要です。CIに合格し、間違っている変更です。エージェントにブラウザを与え、ルーチンをスキルファイルにピン留めして、フリート内のすべてのエージェントが同じ方法で実行できるようにします。

---
name: visual-verify
description: Screenshot affected pages before and after a change, then attach the evidence to the PR.
---
 
## Verify
1. Read the git diff to identify which pages changed
2. Screenshot each affected page at 1280px and 375px before applying the change
3. Apply the change, then screenshot the same pages at the same two widths
4. Capture anything the browser console printed
 
## Report
Attach every screenshot to the pull request, labelled before and after.

ステップ1は作業の大部分を行います。差分を読むことで、アプリ全体を悪くテストするのではなく、変更にスコープされたチェックを維持します。Devinの3段階テストパターンや、指示の言葉遣いがそのどれが役立つかをどのように決定するかを含め、より完全なルーチンをコーディングエージェントによる本番バグの修正でカバーしました。

最後のステップはかつて弱点でした。スクリーンショットは簡単に生成できます。それらをプルリクエストに添付するには、人がファイルをコメントボックスにドラッグする必要がありましたが、これは自動化しようとしていたポイントに人間を再びループに戻します。GitHubは、2026年9月1日付けで、gh v2.99.0以降の繰り返し可能な--attachフラグでそれを修正しました。

gh pr comment "$PR" \
  --body "Visual verification: checkout flow, desktop and mobile." \
  --attach './before-1280.png#Checkout at 1280px, before' \
  --attach './after-1280.png#Checkout at 1280px, after' \
  --attach './before-375.png#Checkout at 375px, before' \
  --attach './after-375.png#Checkout at 375px, after'

#の後のテキストは代替テキストになり、ghはそれがない場合はファイル名にフォールバックします。このフラグは、gh issue create、edit、comment、およびgh pr create、edit、commentでも同様に動作します。画像は10MBまで、ビデオは無料プランで10MB、有料プランで100MBです。GitHub Enterprise Serverはこのリリースではサポートされていません。

スキルを配布することはそれ自体のフリートの問題であり、gh skillはプレビューでそれを処理します。一度公開すれば、すべてのエージェントはローカルコピーを保持するのではなく、同じピン留めされたバージョンをインストールします。

gh skill install your-org/agent-skills visual-verify@v1.2.0 --agent claude-code

制限は、これがページがレンダリングされ、フローが実行されたことを証明することです。変更がうまく構築されていること、または来四半期も有効であることを証明するものではありません。これは、実行されなかった修正という1つの失敗を取り除き、レビューを置き換えるものではありません。

コストでチェックを並べ替える

Stripeは、エージェントを最大2回のCI実行に制限しています。300万以上のテストでは、CIサイクルは高価なリソースです。したがって、問題はどのチェックがそれにスロットを稼ぐかということです。

順序はコストから導かれます。Lintとテストはローカルで5秒未満で返されます。スコープされた開発者インデックスクエリは、2026年9月現在、10件の結果あたり2クレジットかかります。そのサイズのスイート全体でのCIサイクルは、どちらよりもはるかにコストがかかります。したがって、エージェントが半分記憶しているAPIに対して書き込む場合、それをプッシュする前に実際の問題、PR、および移行ガイドに対してその呼び出しをチェックすることは、ほぼ無料です。

curl -X POST https://api.firecrawl.dev/v2/search/developer \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"createClient options changed breaking rename in v5",
       "k":3,"types":["issue","pull_request","doc"],"passages":1}'

ライブで実行すると、Deepgram JavaScript SDKからのMigrating-v4-to-v5.mdなど、実際の移行ガイドが返されます。参照はブランチではなくコミットSHAにピン留めされているため、参照はドリフトしません。

ヒット率は完璧ではありません。Firecrawl自身のDevDexベンチマークでは、インデックスはトップ10で正しい回答を63%の時間で返します。これは通常のWeb検索の45%と比較して大幅な改善であり、約3分の1のクエリはまだ見逃されるため、検索を終了するのではなく、検索を狭めるものとして扱います。取得メカニズムと、構築対購入の決定については、AIコーディングエージェントのための最新ドキュメントの提供でカバーしました。

ステージ5：マージゲート

エージェントのマージポリシーは、最も文書化されていないステージであり、ファクトリーが資産か負債かを決定します。ポリシーは、エージェントのPRが着陸する前に真でなければならないことを述べる必要があります。

公開されているポリシーは、ブラスト半径によってティアにクラスター化されます。

Faireのルールは最も具体的な公開セットであり、そのうちの3つはレビュー自体ではなく、レビューシーケンスに関するものです。Copilot作成のPRには、担当者のレビューと別の人間のレビューを要求します。PRがすでに1回のレビューを受けていない限り、コードオーナーからのレビューを要求しないでください。これにより、エージェントが未完成の作業にドメインエキスパートを引き込むのを防ぎます。エージェントが要求した場合にのみ、レビュー準備完了とマークします。

MastraのFactoryは、ゲートを3つの別々の承認に分割します。作業をキューに入れることの受け入れ、計画の承認、PRのマージです。そのドキュメントでは、これらは独立しており、「受け入れはタスクが作業に入ることを承認します。これは計画の承認や最終的なPRのマージとは別です」と明記しています。

次に、帰属の問題があります。Linuxカーネルの2026年のポリシーでは、AIエージェントはSigned-off-by:行を追加してはならないとされています。なぜなら、そのトレーラーはモデルが行えない法的表明であり、代わりにAssisted-by: AGENT_NAME:MODEL_VERSIONトレーラーが必要だからです。GitHubは、人間開発者を管理する方法でエージェントIDを管理するAgent HQで逆の方向に行きました。どちらでも機能します。ポリシーがないと、6ヶ月後にはどの変更がどこから来たのか誰も言えなくなります。

遠い端では、OpenAIのCodexチームは、内部プロジェクトで「人間はプルリクエストをレビューするかもしれませんが、必須ではありません」と報告しており、エージェントは「しばしば独自のプルリクエストをsquashしてマージします」、そしてチームは「レビュー作業のほとんどすべてをエージェント間で行われるようにしました」。それは慎重な立場ですが、外部ユーザーがいないグリーンフィールドのコードベースで、エージェントを構築するチームによって取られました。採用する前に次のセクションを読んでください。

［画像: dotnet/runtimeでのCopilotコーディングエージェントのプルリクエストのマージ率を比較した棒グラフ。人間によるコミットを受けたプルリクエストは86.2%、完全に自律的なものは55.1%を示している］

出典: Stephen Toub, "Ten Months with Copilot Coding Agent in dotnet/runtime"、2026年9月10日取得。396件のエージェントプルリクエストが人間によるコミットを受け、482件は受けなかった。

数字が示すもの

公開データは限られており、一部はアイデアに反しています。

エージェントPRは人間PRよりもマージ率が低い。 Microsoftの10ヶ月間のdotnet/runtimeレビューは、同様の比較ができる唯一の公開データセットです。エージェントPRは67.9%のマージ率に対し、Microsoftエンジニアは87.1%でした。自律性の分割はより鋭いです。人間によるコミットを受けたPRは86.2%のマージ率でしたが、完全に自律的なものは55.1%でした。リバート率は0.6%対0.8%で安定していたため、マージされたものは著しく悪くはありません。

［画像: dotnet/runtimeでのプルリクエストマージ率を著者タイプ別に比較した棒グラフ。Microsoftの人間は87.1%、ボットは85.9%、コミュニティ貢献者は79.7%、Copilotコーディングエージェントは67.9%］

出典: Stephen Toub, "Ten Months with Copilot Coding Agent in dotnet/runtime"、2026年9月10日取得。6,181件のプルリクエスト全体。

テストに合格してもPRはマージ可能にならない。 METRは、scikit-learn、Sphinx、pytestのメンテナーに、SWE-benchの自動グレーダーにすでに合格した296件のAIプルリクエストをレビューするように依頼しました。約半分はマージされなかったでしょう。これはグレーダーに対して約24パーセントポイントのギャップです。2024年半ばから2025年半ばにかけて、ギャップは縮小しませんでした。

スループットと不安定性は共に上昇する。 DORAの2025年レポートは、AI導入がデリバリーのスループット増加とデリバリーの不安定性増加の両方と相関していることを発見し、AIは組織がすでに持っているものを増幅すると結論付けました。その2026年のROIモデリングは、初年度のROIを約39%とし、8ヶ月のペイバックとしていますが、これは部分的に検証税に起因するJカーブの低下によるものです。単純なタスクでは35〜40%、レガシーコードではしばしば10%未満の利益があります。

ボリュームには保守コストがかかる。 GitClearの2億1100万行の変更コードの分析によると、重複コードブロックは2024年に8倍に増加し、リファクタリングされた行は変更の約25%から10%未満に減少し、チャーンは約2倍（3.3%から7.1%）になりました。

それに対して、導入数は現実的で大規模です。Shopifyは、単一の30日間ウィンドウで59,918件のRiverセッションと3,536件のRiver共同作成プルリクエストがマージされたと報告しており、Lütkeはそのシェアを明確に述べました：「先週私たちのコードベースにマージされたプルリクエストの約8分の1はRiverによって作成され、私たちがレビューしました」。Rampは、義務なしでマージされたPRの約30%に到達しました。Airbnbは、手作業で推定1.5年かかるところを、約3,500件のテストファイルを6週間で移行しました。そのうち75%は最初の4時間で行われました。

最後のものは移行です。Spotifyのフリート作業も、AmazonのJavaバージョンアップグレードも同様です。これらはすべて、誰も手作業で行いたくない大規模な機械的な作業です。これまでのところ、証明されているワークロードは大規模な機械的変更です。グリーンフィールド製品作業については、同等の公開結果は見つかっていません。

ソフトウェアファクトリーが壊れる場所

レビュー能力が最初に失われます。 dotnet/runtimeでは、マージされたエージェントPRは16.5件のレビューコメントを引き付けましたが、人間PRは12.4件でした。そして、上位2名のレビュアーが全フィードバックの36%を生成しました。Faireも同様の事態を経験しました。PRのボリュームは増加しましたが、人間のレビュアーの数は横ばいでした。

最後の区間は高価です。 Airbnbのロングテールファイルは、それぞれ50〜100回の再試行が必要でした。Hacker Newsのコメント投稿者の一人は、次のように述べています。「エージェンティックなソフトウェア開発は、あまりうるさくなければ成果を上げます。最後の10%は非常に長くかかり、多くのトークンを消費する可能性があります。」

並列ブランチが衝突する。 Worktreeは同じブランチを2回チェックアウトできません。エージェントのスループットが上昇すると、マージキューは低下します。

コストが見合うとは限らない。 あるチームが、コードは人間によって書かれるべきでもレビューされるべきでもないというマニフェストを発表し、エンジニアあたり1日1,000ドルのトークン消費を推奨したとき、トップのHacker Newsの回答は次のとおりでした。「サイトにはベンチマーク、欠陥率、コスト比較、本番での成果がゼロです。提供される唯一のメトリックは『もっとお金を使う』です。」

何かでクリアしない限り、ゴミが蓄積する。 OpenAIのCodexチームは、ループを自動化する前は、「私たちのチームは毎週金曜日（週の20%）を『AIスロップ』のクリーンアップに費やしていました。驚くことではありませんが、それはスケーリングしませんでした」と述べています。

オープンソースがコストを吸収している。 tldrawというキャンバスライブラリの創設者であるSteve Ruizは、プロジェクトが外部貢献を一時停止した際のシフトを要約しました。「コードを書くのは簡単になりました。本当の仕事はそれをレビューすることです。」curlはさらに進みました。長年にわたる低品質レポートの増加の後、メンテナーは2026年7月全体を脆弱性報告から休み、「おそらく私たちのプロジェクトで最も良い決定だった」と呼びました。Daniel Stenbergは、彼が参加している他のセキュリティチームのために洪水は遅くなっていないと述べています。

FirecrawlでライブWebコンテキストをAIソフトウェアファクトリーに提供する

ソフトウェアファクトリーの費用を賄うワークロードは、移行と保守です。Spotifyのフリート全体での変更、Airbnbのテスト移行、AmazonのJavaアップグレードはすべて、誰も手作業で行いたくない大規模な機械的作業です。

それらのそれぞれは、リポジトリの外にある何かによってトリガーされます。リリースノート、非推奨、3つの依存関係の深いところにある破壊的な変更です。Fleetshiftスタイルのツールはコード内のターゲットを見つけますが、何に移行するかは外部の事実です。自身のリポジトリしか読めないファクトリーは、作業を作成した変更を見ることができません。

Firecrawlの開発者インデックスは、そのライブWebコンテキストを1つの検索呼び出しで提供します。7000万以上の問題スレッド、マージ済みプルリクエスト、README、およびドキュメントページがあり、ほとんどが毎日更新されています。フィルターは、人気のある回答ではなく、現在の回答に絞り込みます。

npx -y firecrawl-cli@latest setup developer-index

curl -X POST https://api.firecrawl.dev/v2/search/developer \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"modern replacement for moment.js, tree shakeable",
       "k":5,"types":["readme"],"language":"TypeScript","min_stars":2000}'

同じサーバー、同じfirecrawl_developer_searchツールが、1つのMCPブロックからフリート内のすべてのエージェントで利用可能です。

回答が開発者アーティファクトにない場合、同じMCPは一般的なFirecrawl検索およびスクレイピングパイプラインを公開します。firecrawl_searchはオープンWeb全体でランク付けされた結果を返し、firecrawl_scrapeはURL（JavaScriptレンダリングページを含む）をエージェントが推論できるクリーンなMarkdownに変換します。ほとんどのファクトリーサイドのルックアップは次のようになります。質問に答えられる可能性のある2〜3のURLを検索し、それぞれから現在のテキストをスクレイピングし、エージェントに決定させます。ベンダーのステータスページ、パートナーAPIの変更ログ、価格表、または政府のスキーマはリポジトリの外にあり、それらすべてが同じツール呼び出しを通じて返されます。実行時点の最新情報です。

スクレイピングされたページは、攻撃者がエージェントを対象とした指示を仕込む場所でもあります。Firecrawlのプロンプトインジェクション検出は、すべての抽出で実行され、レスポンスで疑わしいインジェクション試行をフラグ付けし、フリートオペレーターがモデルに到達する前に問題のあるコンテンツをドロップまたは検疫できるようにします。これは、オープンWebツールをバックグラウンドエージェントに渡すことを可能にするセーフガードです。

1つのゲートから始める

エージェントが最も多くの手戻りを生み出すステージを選択し、そこにゲートを設置してください。今のところフリートやオーケストレーターはスキップしてください。この記事のすべてのアーキテクチャは、そのように組み立てられました。すぐにボリュームに飛び込んだ企業は、金曜日を片付けに費やしていると書いている企業です。