最近のAIによるコーディングは性能がかなりあがっており、はっきりいって人間よりも高品質なコードを高速に書き上げることができる。ここ1年の伸びは特に大きく、テストに合格するためだけのテストを書くようなことも最近はほとんどない。人間が埋め込みがちな基本的な問題、たとえばN+1問題（データベースへの問い合わせが無駄に何度も繰り返されて遅くなる問題）やSQLインジェクション（入力欄から不正な命令を入れてデータベースを操作される脆弱性）、その他の脆弱性をソースコードに埋め込むこともほとんどない。もし混じっていても、AI自身にコードを監査させれば、見つかった問題を自動で直してくれる。
そう、コーディングにおいては人間は不要になったといっていい。
とはいえ、人間の仕事がなくなったわけではない。本記事では、AIにコードを書かせる新しい開発手法「ソフトウェアファクトリー」について、海外と国内の事例から「人間の判断はどこに残るのか」を整理する。後半では、筆者が公開している開発基盤orchestrator-skillsに、その整理をどう取り入れたかも紹介する。
ソフトウェアファクトリーとは
人が1回ずつ指示を出すのではなく、チケットやPRを起点にエージェントが自動で動き、マージ可能なコードを出す仕組みを指す。用語自体は古い。開発者向けの発信で知られるエンジニアのAddy Osmaniは、その起源を、GE（ゼネラル・エレクトリック）でソフトウェア開発を率いていたBob Bemerの1968年の論文までさかのぼっている（Software Factories, Light and Dark）。
当時の意味は、標準化した道具と計算機上の開発環境で、プログラマーごとの生産性のばらつきを減らそうという構想である（Cusumanoの解説）。これを現在のAIエージェントに当てはめてOsmaniが整理し直すと、次の3層になる。
| 層 | 中身 |
|---|---|
| ループ | 1体のエージェントが「情報を集める→作業する→結果を確かめる」を条件を満たすまで繰り返す単位 |
| ハーネス | ループを囲む環境。隔離された作業場所（サンドボックス）、使えるツール、作業の記憶、「完了」かどうかを判定する関門（ゲート） |
| ファクトリー | ハーネス付きのループを並列に多数回し、全体の運用と責任を人間が持つもの |
さらにファクトリーは、人間がどこまで中身を見るかによって「明るい（light）」と「暗い（dark）」に分けて語られる。
- ライトファクトリー: 出荷前に人間が成果物を確かめる。判断はコードを書く前の設計やアーキテクチャの段階にも置かれる
- ダークファクトリー: 誰も読んでいないコードが、機械の検証だけを通って出荷される。無人工場で照明を消してもロボットは困らない、という製造業の比喩から来ている12
ライトかダークかは「人間がコードを読むかどうか」の違いに見える。ただし、人間がコードを書かなくなっても、「何を作るか」「何をもって正しいとするか」「出してよいか」を決める判断は残る3。
人間の判断を置く5つの場所
先に結論を示しておく。海外と国内の事例を並べると、人間の判断を置く場所は次の5つに整理できる。どの事例も、このうちどこを厚くし、どこを薄くするかを選んでいるにすぎない。
| # | 置き場所 | 人間が決めること |
|---|---|---|
| 1 | 意図・仕様（上流） | 何を作るか、なぜ作るか |
| 2 | 検証の設計 | 何をもって正しいとするか（シナリオ、証拠） |
| 3 | 振り分け | どの変更を人間に回すか（可逆性、影響範囲） |
| 4 | 承認（マージ前） | この変更を出してよいか |
| 5 | 事後の観測 | 仕組み全体が壊れていないか |
以下の事例では、それぞれがこの5つのどこに人間の判断を置いたのかを示しながら見ていく。
海外の事例
海外の主な事例は、人間の判断をどう扱ったかで、次の4つのタイプに分けられる。
| タイプ | 代表事例 | 厚くした置き場所 |
|---|---|---|
| ① レビューをなくし、検証の設計に移す | StrongDM（2026年2月公開） | 1 意図・仕様、2 検証の設計、5 事後の観測 |
| ② レビューをマージの後ろへ移す | OpenAI（Frontierチーム） | 5 事後の観測（リリース前の承認も一部残す） |
| ③ 書くのはAI、承認は人間 | Stripe（Minions） | 4 承認 |
| ④ リスクで自動化の範囲を分ける | Meta（RADAR、2026年5月の論文） | 3 振り分け |
このほかに、AnthropicとCloudflareが、事例というより方針として同じ問題を整理している。
こう見ると、当たり前だが「ソフトウェアファクトリー」だからといって何か決まった手法があるわけではなく、それぞれの組織が自分たちに合った方法を模索していることがわかる。自分たちに合った判断の置き方を見つけた組織ほど、速さと品質を両立しやすくなる。つまり、その模索の結果がそのまま競合への優位性につながるということだ。
以下、それぞれが人間の判断をどこへ移したのかを順に見ていく。
① レビューをなくし、検証の設計に移す（StrongDM）
アクセス管理というセキュリティ製品を扱うStrongDMは、「人間がコードを書かない」「人間がコードをレビューしない」をチームの憲章に掲げている。その代わりに使っているのが、ホールドアウト・シナリオだ。
ホールドアウト・シナリオとは
利用者が実際にどう操作するかを手順として書いたシナリオを、コードベースの外に置いて、コードを書くAIからは見えないようにしたものである。採点のときにだけ使う。名前は機械学習から来ている。機械学習では、データの一部を学習に使わずに取っておき、最後の評価にだけ使う。これを「ホールドアウトセット」と呼ぶ。学習で見たデータで評価すると、答えを丸暗記しただけでも高得点になってしまうからだ。
これが必要になったのは、公開当時（2026年2月）のエージェントがテストを通すことに最適化しがちだったからだ。実際に return true でテストを通したことがあったという（Stanford CodeX）。採点に使う問題をAIが見られなければ、テストを通すためだけのコードでは点が取れない。
手法
- Okta、Jira、Slack、Google Docsなどの振る舞いを真似たクローン（Digital Twin Universe）を作り、本物のサービスの回数制限や利用料金を気にせずに、1時間に数千のシナリオを回す
- 合否は「全テスト通過」ではなく、シナリオを繰り返し実行し、その動きのうち利用者が満足しそうなものの割合（satisfaction、満足度）で測る。製品にAIの部品を含むため、同じ操作でも毎回同じ結果になるとは限らないからである
人間の判断が残った場所
シナリオを書くこと（何をもって正しいとするか）と、満足度を見て仕組みを直すことである。コードの1行は見ないが、合否の基準は人間が握っている。
ただし、この方法には弱点も指摘されている。StrongDMは、満足度の判定にもAIを使っている。スタンフォード大学の法と技術の研究センターであるCodeXは、これを「書く側と確かめる側が同じ系統の技術」という循環だと指摘している。人間がテストを書けば、コードを書いた人とは違う前提や見落としが持ち込まれる。同じ系統のAIが両方を書くと、その違いが小さくなる。
② レビューをマージの後ろへ移す（OpenAI）
OpenAIは、人間のレビューをなくしたのではなく、マージの前から後ろへ移した。
出発点は、OpenAIのFrontierチーム（新しい製品のあり方を探る社内チーム）が行った実験である。約5か月にわたり、「人間はコードを1行も書かない」という制約を自分たちに課して、社内向けのデスクトップアプリ（Electron製）を作った。
コードを書くのがすべてエージェントになると、今度は人間のレビューが追いつかなくなる。そこでチームは、マージ前に人間がすべての変更を確かめるのをやめた。代わりに、マージされた変更から一部を抜き出して読み、「エージェントがどこでつまずいているか」を見つける使い方に切り替えた。
エージェントが間違えたときも、人間がその変更を直接直すのではない。エージェントに読ませる作業手順書（スキル）を更新して、同じ間違いが次から起きにくいようにする。人間の判断は、1件ずつの修正ではなく、手順書という「仕組み」の側に向けられている。
この運用はその後、Symphony（2026年4月）として外部にも公開された。Linearなどのタスク管理ボードに課題を書くと、エージェントがそれを拾って作業を始める仕組みである。ただし、できあがった結果は人間がレビューする前提になっている。
③ 書くのはAI、承認は人間（Stripe）
Minionsは、Stripeが社内で使っているコーディングエージェントである。エンジニアがSlackなどで作業を頼むと、あとは誰も見ていない状態で作業を進め、自動テストを通したPRまで作ってくる。こうして作られたPRは週1,300件を超えるが、全件を人間がレビューしてからマージしている。「誰が書くか」と「誰が承認するか」は別の問題であることがよくわかる例だ。
この仕組みを分析した技術ニューズレターのByteByteGo（How Stripe’s Minions Ship 1,300 PRs a Week）は、うまくいっている理由をAIモデルの性能には求めていない。Stripeは、LLMが登場する何年も前から、人間のエンジニアのために、隔離された開発環境や自動テストの仕組みを整えていた。エージェントはその環境をそのまま使えたからこそ、無人でも安定して動いている、というのがその見立てである。
④ リスクで自動化の範囲を分ける（Meta）
Meta（FacebookやInstagramの運営会社）は、Stripeとは逆に、承認の一部まで自動化した。2026年5月の論文で報告されたRADARという仕組みでは、自動マージの対象にしてよい変更かの確認、ルールに基づく機械的なチェック、機械学習によるリスクの点数付け、LLMによるレビュー、毎回同じ結果になる検証（テストなど）をすべて通った変更（diff）だけを、人間のレビューなしでマージする。どこかで落ちれば人間に回る。論文では53万5,000件超を審査し、33万1,000件超をマージした。人間がレビューした変更と比べて、取り消し（revert）になった割合は3分の1、本番障害につながった割合は50分の1と報告されている。ただし、もともと低リスクな変更だけが自動マージされるので、この差がそのまま自動化の効果を示すわけではない（選択バイアス）。自動マージを任せる条件には「60日間障害ゼロ」などの実績も使っている。
方針としての整理（AnthropicとCloudflare）
Anthropic（Claudeの開発元）が2026年8月に公開した「AI-native SDLC playbook」（AIを前提にした開発プロセスの手引き）は、判断を要する決定はすべて人間が責任を持ち、人間の注意はレビューすべき成果物に合わせて移る、という立場を取る。コードベースをリスク別に分けて自動化の範囲を限ることや、新しいAIレビュアーは信頼がたまるまでコメントだけに留めることも挙げられている（BestHub.devの解説記事）。
Cloudflareも、2026年8月のブログで、AIエージェントを開発の全工程に組み込む「エージェント開発ライフサイクル」を提案している（エージェント開発ライフサイクル）。ただし現時点では、本番環境に出すPRの承認とマージを、まだエージェントに任せていないとしている。
懐疑的な意見
ここまでの事例に対しては、慎重な意見も少なくない。代表的なものを4つ挙げる。
- 実験の失敗例: AIエージェント向けの開発ツールを手がけるHumanLayerのDex Horthyは、誰もコードを読まない運用を数か月続けた結果、障害と誰も把握していないコードベースが残ったと述べている。対策として、エージェントに書かせる前に設計のすり合わせに時間を使うことを勧めている（Swapnil Talekarによるまとめ）
- 掛け算の問題: PythonのWebフレームワークFlaskの作者であるArmin Ronacherは、出力が10倍でエラー率が半分になっても、出荷されるエラーは5倍になると指摘している（Ronacherの発言をまとめた個人のwiki）
- 理解負債: Osmaniは、存在するコード量と人間が理解している量の差を「理解負債」と呼ぶ。テストがすべて成功（緑）のままたまっていき、そのツケは気づかないうちに、遅れて表に出る
- バックプレッシャー: もともとは、処理しきれない量の入力を受けたときに流れを抑える仕組みを指す言葉である。同じくOsmaniは、AIに任せる範囲を「安く確実に検証できる範囲」を超えさせないよう勧めている。認証、課金、公開APIの契約のような影響範囲が広い判断は人間に残す、という立場である
国内の事例
国内では、人間が誰も見ないままマージする「無人マージ」よりも、人間レビューとAIレビューの線引きを試している事例が多い。
前提となる国内調査
ファインディが2026年4月に国内エンジニア157人に行った調査では、AI活用で改善を実感した割合はコーディング87%、実装後の品質検証44%、リリース運用41%だった（Findy）。書く工程だけが速くなり、確かめる工程が追いついていない。海外事例と同じ構図である。
Acsimのセルフマージ制度
Acsimの開発チームは、2026年4月に「セルフマージ制度」を導入した（人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話）。セルフマージとは、PRを作った本人が、ほかの人のレビューを待たずに自分でマージすることを指す。きっかけは、AIを使った開発でPRの数が増え、人間のレビューを必須にしたままでは、レビュー待ちでPRが滞るようになったことだった。
どのPRを本人の判断でマージしてよいかは、「その変更は簡単にやり直せるか」で決める。元になっているのは、引き返せない決定（One-Way Door）と引き返せる決定（Two-Way Door）を分けて扱う、という意思決定の考え方である。やり直しのきかない変更、たとえばデータベースの構造（スキーマ）の変更、認証・認可、デプロイの仕組みなどは、必ず人間がレビューする。
また、Design Doc、ADR、コーディング規約のようにチームで合意して作る文書は、やり直しがきく変更であっても人間のレビューを必須にしている。これらはあとから意思決定の記録として参照されるので、合意のないまま書き換えられるのを避けるためである。
この振り分けの判定もAIに任せている。PRを作ると、Claude Code Action（GitHub上でClaudeを動かす仕組み）がガイドラインと変更内容を読み、「セルフマージ可」か「人間レビュー必須」かを、根拠を添えてコメントする。ただし、AIの判定はあくまで判断材料で、最後に決めるのはPRの作成者である。迷ったときは人間のレビューを選ぶ。
導入後2週間でマージされた159件のうち、約8割がセルフマージ可と判定され、PR作成からマージまでの時間も短くなった。ただし期間が短いので、記事では参考値として扱っている。
一方で、課題も残っている。AIレビューの指摘が多すぎたり的外れだったりすると、開発者が疲れてレビューを読み飛ばすようになるおそれがあり、チームはその対策を検討している途中だという。
コードレビュー廃止の半年
henteko氏のZenn記事を要約した Qiita記事（2026年11月5日）によると、henteko氏のチームは人間のコードレビューをやめ、実装前に「何のために何を作るか」を書いた「コンセプト」を確認する形に変えて半年運用した。
結果だけを見ると、うまくいっている。人の承認（approve）が付くPRは97%から1割未満に減り、それでもhotfixやrevertは増えていない。
ところが、代わりに置いた判断点のほうは機能していなかった。コンセプト確認の84%は実質「LGTM（問題なし）」の一言だけで、差し戻しは0件だった。コンセプトから実装に着手するまでの時間も中央値で2分しかなく、誰も立ち止まって考えていなかった。記事はその原因を、本人しか持っていない情報を、流れの中で一度も求めなかったことにあると分析している。そのうえで次の一手として、AIがコンセプトを下書きし、AIが決めきれなかった点だけを人間に尋ね、その回答を本人の判断として記録する形を挙げている。
判断点を上流に移すだけでは足りず、そこで何を問うかまで設計しないと、判断点は形だけになる。公開事例の中でも、この点を数字で示したものは少ない。
freeeのSelective Dark Factory
会計や給与など間違えられない業務を扱うfreeeは、2026年10月の講演で自社の「大規模ソフトウェアファクトリー」を紹介した（講演資料、公式noteのレポート）。目指しているのは、人間を完全に外すダークファクトリーでも、人間がすべてを見るライトファクトリーでもない「Selective Dark Factory」である。
freeeの仕組みの特徴は、次の6点にまとめられる。
- 構成: ナレッジ、ハーネス、人のレビューの3つ。要件定義から設計・実装・テストまではAIエージェントが進め、人は必要な箇所だけ成果物を確認する
- 役割分担: 機械的に確かめられることは機械、判断が要る部分はLLM、残った判断だけを人間が見る
- 人に聞くのは4つだけ: 業務上の判断、ユーザーの振る舞い、他チームとの契約・制約、取り返しのつかないリスク
- 間違えられない領域: 会計や給与では、ドメイン知識と最終責任をAIが持ちきれないとしている。給与は適用月や遡及変更などのレビューを厚くし、既存ルールに沿った定型のデータ登録・参照・更新・削除（CRUD）やAPIはAIに任せる
- 人が読む量を減らす: 設計書はAI向けの網羅版と、人向けに「全体像・事実・理由・問い」に絞った表示に分ける。AIが仮に決めたことは、人の承認とは別に「未確認事項」として記録する
- 直すのは工場: 問題を見つけても成果物を直接直さず、上流から作り直させる。現行仕様・用語・法令・意思決定の記録・障害履歴をまとめたナレッジ基盤を、全工程が参照する
こうした仕組みによって、2026年9月時点でPR数は前年同月比1.90倍になり、AIが書いたコードの割合は89.6%に達した。企画・開発のリードタイムも60～90%短くなっている。一方で、AIレビューツールのCodeRabbitを入れても、人間のレビューは大きなボトルネックのまま残っている。リリースしてよいと自信を持てる水準にも、まだ届いていないという。
お金や法令に関わる領域ほど、人間の判断を「人に聞く問い」の形まで絞り込み、AIの仮決めと人の承認を分けて記録している。前述のhenteko氏の事例で課題になった「判断点で何を問うか」に、正面から取り組んでいる例である。
LegalscapeとKDDIアジャイル開発センター
この2つは、人間が何を見るかを絞り込んだ例である。
Legalscape（法律情報の検索サービスを提供する会社）は、約7,300行を追加するリファクタリングのPRをきっかけに、2026年4月のテックブログでレビューの分担を提案している。書式や型のチェックは自動ツールに、バグやセキュリティはAIレビューと自動テストに任せ、人間はアーキテクチャに合っているかと、要件やビジネス上の判断に集中する、という分け方である。
KDDIアジャイル開発センター所属の筆者による Qiita記事（2026年11月）では、自作のファクトリーで人間の判断を2回に絞っている。プレビューを見てデザインPRをマージするときと、「公開する」を押して実装PRをマージするときである。人間が見るのはコードではなくプレビューだ。
事例から分かること
冒頭の5つの置き場所に照らして事例を振り返ると、言えることは3つある。
- 「人間がコードを読まない」は「人間が判断しない」と同じではない。 ダークファクトリーを名乗る事例でも、4（マージ前の承認）をなくした分、1（意図・仕様）・2（検証の設計）・5（事後の観測）を厚くしている。削ったのは判断ではなく、コードを1行ずつ目で確かめる作業である
- 振り分けの軸は「可逆性」に収束しつつある。 AcsimのOne-Way Door、Osmaniの「影響範囲が広く長く残る判断」、RADARが低リスクの変更だけを自動化していること。表現は違うが、引き返せないものを人間に残すという点で一致している
- 判断点は、置いただけでは機能しない。 henteko氏の事例では、上流に移した判断点で84%がLGTMになった。AcsimもAIレビューの読み飛ばしを懸念している。判断点が効くのは、そこで人間しか持っていない情報（業務上の意図、優先度、リスクを受け入れるか）を求められたときだけである。freeeが人に聞く項目を4つに絞り、AIの仮決めを「未確認事項」として人の承認と分けているのも、この考え方に沿った運用である
つまり、ずっと続いてきた議論は「人間を残すかどうか」ではなく、次の3つの問いに分けて答えるものだと考える。
- 場所: 5つのうちどこに置くか（項目ごとに選ぶ。Osmaniも「全部を同じモードにしない」よう勧めている）
- 質: その判断点で、人間にしか答えられない問いを出しているか
- 量: AIに任せる範囲が、安く確実に検証できる範囲を超えていないか
一人開発での実践：orchestrator-skillsへの反映
大企業の事例はそのままでは使えない。StrongDMは「エンジニア1人あたり1日1,000ドル以上のトークン」を目安に掛け、Stripeは何年もかけて整えた開発環境を前提にしている。一方で、一人で受託や自社プロダクトを回す場合、事故が起きたときの説明責任は自分一人に来る。コードを全部読む余裕もないが、誰も読まない運用も選びにくい。海外や国内の企業がそうしているように、自分の規模とリスクに合った判断の置き方を自分で選ぶしかない。
筆者が公開している orchestrator-skills は、Claude Codeで「要件→設計→実装→テスト→レビュー」を機能単位で回す仕組みである。
ただし、これはソフトウェアファクトリーそのものではない。冒頭で紹介した3層に当てはめると、ループとハーネスはほぼそろっているが、ファクトリーの条件は満たしていない。動かし始めるのは人間で、チケットやスケジュールを起点に自動で動き出すわけではない。機能は1件ずつ順番に処理し、多数のループを並列には回さない。動く場所も、人がいない間に動き続けるクラウドではなく手元の端末である。いわば、ファクトリーの手前にある「ハーネス付きの生産ライン1本」にあたる。それでも、人間の判断をどこに置くかという問題は、ライン1本でもファクトリーでも同じように生じる。
冒頭の5つの置き場所に照らすと、もともと次の対応があった。
| 置き場所 | 既存の対応 |
|---|---|
| 意図・仕様 | 要件定義書は人間が承認するまで先に進まない。特にリスクの高い機能（お金・個人情報・認証など）は、設計も人間が承認する |
| 検証の設計 | テスト仕様書は実装コードを見ずに設計書から作り、設計書・コード・テストが食い違っていないかを照合する工程（Gate 2）で突き合わせる |
| 振り分け | 機能をリスクの大きさで段階分けし、リスクの高い機能だけマージ前に止まる |
| 承認 | リスクに応じて、変更点の問題を探すことに特化したレビュー（Gate 3、敵対的差分レビュー）を提案する |
| 事後の観測 | 機能3～5件ごとに、バグを見つけることを目的にした監査（敵対的監査）を行う。人間のレビュー待ちの機能が3件たまったら、AIはそれ以上先に進まない |
足りなかったのは、振り分けの軸と、判断点の「質」である。そこで5つの仕組みを加えた。中でも、ここまでの事例を一人開発向けに作り変えたのが次の3つである。
One-Way Doorを、通常のリスク判定より優先する
これまで可逆性は、機能のリスクを判定するための6つの評価軸（金銭的損失、個人情報、法的責任、可逆性、影響を受ける利用者の数、複雑さ）の1つにすぎなかった。そこで、DBスキーマ、認証・認可、公開しているAPIの仕様を利用側が動かなくなる形で変えること、デプロイの仕組み、基盤ライブラリ、課金や通知のように外部に出たら取り消せない処理を「One-Way Door」として定義した。これに当たる変更は、通常のリスク判定に関わらず、マージ前に必ず止まる。迷ったときは、当たるものとして扱う。
ここでいう可逆性は、コードを元に戻せるかどうかだけではない。その変更によって起きた業務上の結果まで取り消せるかどうかを含む。たとえば、一度送ったメールや通知、外部に漏れた個人情報、済んだ決済、権限の設定ミスがあった間に起きた不正アクセスは、コードをロールバックしても元に戻らない。課金はあとから返金できても、顧客や決済事業者への影響は残る。One-Way Doorに「外部に出たら取り消せない処理」を含めているのは、このためである。
AIが自分の判断基準を書き換えて通すのを防ぐ
要件定義書、設計判断、CLAUDE.md（Claude Codeに読ませるプロジェクトの指示書）やスキル、リスク判定の基準そのもの、AIとの作業の進め方の取り決め（作業合意）は、やり直しがきく変更であっても必ず人間が承認する。AIが自分の判断基準を書き換え、その基準で自分の変更を通してしまうことを防ぐためである。Acsimがチームの合意文書を人間レビュー必須にしているのと同じ考え方である。
人間への問いを最大5つに絞り、回答を記録する
機能ごとにAIが作るテスト手順書の冒頭に「判断してほしいこと」を置き、人間にしか答えられない問いを最大5つ、選択肢とAIの推奨案付きで示す。「問題がないか確認してください」のように、何を判断すればよいか分からない依頼は書かない。回答は docs/decision_log.md に残し、次の判断の材料にする。henteko氏の事例で判断点が形だけになった反省と、freeeが人に聞く項目を4つに絞り、AIの仮決めを人の承認と分けて記録している運用を、一人開発向けに取り入れたものである。
そのほかの追加
- 証拠を先に出す: AIが実際に実行したテストと動作確認の結果を手順書に載せ、人間は疑わしい箇所だけコードを読む。実行していない確認は「未実施」と書く
- 形骸化を数える: 問いなし・コメントなしで通った判断点の数と、人間レビュー未実施のままマージされた機能数（理解負債の目安）を品質レポートに載せる
なお、orchestrator-skillsはもともと人間の承認をかなり省いている。コマンドの実行など細かな操作の許可は、既定でClaude Codeのauto mode（操作ごとにAIが安全かどうかを判断して自動で許可する仕組み）に任せている。リスクの低い機能は、人間のレビューを待たずに次の機能へ進む。ただし、マージだけは既定で人間が判断する（AIが行うのはPRの作成まで）。今回の変更も、承認を減らすためではなく、残した承認を効かせるためのものである。設計の背景はリポジトリ内の docs/JUDGMENT_PLACEMENT.md にまとめた。
まだ入れていないものが2つある。
- 受入シナリオのホールドアウト化: 要件承認時にシナリオを作り、実装工程からは読めない場所に置く（StrongDMの考え方）
- 実績に基づく段階的な緩和: 一定期間revertや不具合がない領域だけを、リスク判定を下げる候補として提示する（RADARの実績条件、Anthropicの「まずコメントだけ」の考え方）。採否は人間が決める
まとめ
- 公開事例で人間の判断をなくしたものはほぼない。読まなくなったのはコードの行であり、判断は仕様・検証の設計・振り分け・事後の観測へ移っている
- 振り分けの軸は、海外も国内も「引き返せるか」に寄ってきている
- 判断点は置いただけでは機能せず、人間にしか答えられない問いを出したときだけ効く
- 「人間のレビューは要るか」という問いは、場所・質・量の3つに分けると答えやすくなる
ソフトウェアファクトリーに決まった型はない。大企業のやり方をそのまま真似るのではなく、自分の規模と扱うリスクに合わせて判断の置き場所を設計することが、そのまま競合との差になる。
参考文献
- Addy Osmani, Software Factories, Light and Dark（2026-07）
- Simon Willison, How StrongDM's AI team build serious software without even looking at the code（2026-02）
- Stanford CodeX, Built by Agents, Tested by Agents, Trusted by Whom?（2026-02）
- ZenML LLMOps Database, Extreme Harness Engineering（OpenAI Frontierの事例まとめ）
- OpenAI, An open-source spec for Codex orchestration: Symphony（2026-04）
- ByteByteGo, How Stripe's Minions Ship 1,300 PRs a Week
- Meta, Automating Low-Risk Code Review at Meta: RADAR（2026-05）
- Anthropic, The AI-native SDLC playbook（2026-08）
- Cloudflare, エージェント開発ライフサイクル（2026-08）
- Swapnil Talekar, The Role of Humans in "Software Factories"
- Envisioning, Dark Factory（Matt Pocockの用語集を出典とする解説）
- ファインディ, ハーネスエンジニアリングとは？
- Acsim, 人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話（2026-04）
- @pitaspot, レビュー廃止の半年（2026-11、henteko氏のZenn記事の要約）
- Legalscape, エンジニアは何をレビューすれば良いのか（2026-04）
- @Syoitu, AI駆動開発の次の段階: ソフトウェアファクトリー（2026-11）
- freee, freeeにおける大規模ソフトウェアファクトリーの実践（2026-10、AI×開発組織Summit 2026）、公式noteのレポート
-
Matt Pocockの用語集では、無人で走るだけなら「ファクトリー」、できたコードを誰も読まないときだけ「ダークファクトリー」と区別している（Envisioningの解説）。無人で動いてもPRを人間が見るならダークではない、という線引きである。 ↩
-
「ダークファクトリー」をソフトウェア開発に持ち込んだのはGlowforge CEOのDan Shapiroで、AI開発の自律度を自動運転のレベルになぞらえた5段階の最上位に置いた。なお、中間のレベル3は「人間がマネージャーとしてループに入る」段階とされる（書籍『Something Big Already Happened』第9章）。 ↩
-
OpenHandsも、AI支援の開発とダークファクトリーの違いは、開発の流れのどこに人間の判断を置くかだと整理している（What Is An AI Dark Factory?）。 ↩