ソフトウェアファクトリーとは何か。
エージェントのループで組む工場と、その外にある暗黙知。
上のスライドは、2026年10月23日に社内勉強会で使った資料である。ブログ、各社のエンジニアリング記事、OSSのリポジトリ、HNやXのスレッドなど、約130のソースを10月に集めて作った。スライドは英語で75枚あるので、この記事では日本語で、流れに沿って何を言っているのかを説明する。前半の5部は他人の調査、最後の第6部だけが自分の意見である。
ソフトウェアファクトリーは、意図を検証済みのソフトウェアに変える、エージェントのループの生産ラインである。
01 — DEFINE
ソフトウェアファクトリーとは、エージェントの周りにある仕組みである
「ソフトウェアファクトリー」という言葉は、HNやXでかなり雑に使われている。10月には「個人のソフトウェアファクトリーは時間の無駄だ」というスレッドが立ったが、議論の大半は定義のすれ違いだった。だから最初に定義を一つに固定する。
人間が意図を決める。それが仕様（計画、シナリオ、受け入れテスト）になり、キューでタスクに分けられ、サンドボックスの中で複数のエージェントが並列にループを回す。出てきた変更はテストやCIや判定器で検証され、リスクに応じたゲートを通ってから出荷される。本番のインシデントや失敗した実行は仕様に戻ってくる。最後に、人間が結果を受け入れてリスクを負う。Addy Osmaniの短い言い方を借りると、「ループでできた組織図」である。
大事なのは、エージェントは部品の一つにすぎないということだ。キュー、サンドボックス、検証、ゲート、フィードバックが揃って初めて工場になる。逆に言えば、次のものはソフトウェアファクトリーではない。
- 賢いエージェント一体、大きなプロンプト、長いチャット
while trueのループ単体- チャットボットを足しただけのCI/CD
- 「人間がいない」こと。ダークはあくまで設定値の一つ
- 品質の証明。テストが緑でも、読めないコードは隠れている
ある仕組みが工場かどうかを見分ける問いは一つでいい。誰が「この変更は完了した」と決めるのか。そしてその判定が間違っていたら何が起きるのか。
Claude Codeは、ラインの一つの持ち場である
Claude CodeやCodexは、工場の中の「ハーネス」という一つの持ち場にあたる。Thorsten Ballの言葉では、コーディングエージェントは「LLMとループと十分なトークン」で、400行足らずで書ける。Spotifyはわかりやすい例で、既存のFleet Management（対象リポジトリの選定、PR、レビュー、マージ）はそのまま残し、変換ステップだけをエージェント、のちにClaude Codeに差し替えた。
Geoffrey Huntleyの「Ralphループ」は、同じプロンプトを毎回新しいコンテキストで流し続けるBashループである。状態はspecs、計画ファイル、gitというディスク上に置く。これは一つの持ち場を繰り返す部品であって、工場は複数のループを仕様とゲートにつなぐ。比べると次のようになる。
- Claude Codeのセッション：人間が毎ターン見ている。上限は一人の注意力
- Ralphループ：人間は実行の合間にプロンプトを調整する。上限は1リポジトリ1プロセス
- CI/CD：コードを書くのは人間。上限は人間のコーディング時間
- ソフトウェアファクトリー：多数のエージェントが並列に書く。上限は変更をどれだけ速く検証できるか
つまり新しい製品は「チェック」そのものである。仕様、シナリオ、検証器が、無人の出力を信じていいかを決める。
工場は二度生まれた
言葉自体は新しくない。1968年にBemerが「software factory」と言い、翌1969年に日立がソフトウェア専用の工場を作った。1991年にはCusumanoが『Japan's Software Factories』で再利用・品質保証・標準化を論じ、2004年にはMicrosoftがモデルとDSLから生成する「Software Factories」を出した。2017〜22年の米国防総省Kessel Runも同じ系譜にある。これらが解こうとしたのは人間の仕事のばらつきと再利用で、働き手は人間だった。
二度目の誕生は2026年である。1月にDan Shapiroが「ダークファクトリー」を語り、2月にStrongDMがマニフェストを出し、7月にはAI Engineer World's Fairのメインテーマになった。今回の問題は、人が見ていない出力をどう信じるかである。
02 — LEVELS
ほとんどの会社はレベル3にいる。人間がまだ差分を読んでいる
Shapiroは自動運転のレベル分けを借りて、AIと開発者の関係を6段階にした。L0は全部手書き、L1はAIインターン（補完と小さなタスク）、L2はジュニアの相棒（ペアプロ、開発者の約9割がここ）。L3はマネージャーで、AIが書いた差分を人間がレビューする。L4はプロダクトマネージャーで、人間は仕様を書き、結果を確認する。L5がダークファクトリーで、仕様を入れるとコードが出てきて、誰もコードを読まない。
各社の記事を読んで配置すると、Stripe、Ramp、Uber、CloudflareはL3、Spotify、OpenAI、AWS Kiro CrewはL4、StrongDM、Steve YeggeのGas Town、AnthropicのC compilerはL5になる（配置は自分の読みである）。ほぼ全員がL3で頭打ちになっている。
もう一つの軸が「明るさ」だ。ライトは人間がコードを読む。トワイライトはエージェントが必要なときに人間を呼ぶ。ダークは誰もコードを読まない。ここで大事なのは、明るさは会社ごとではなくループごとに決めるということだ。Osmaniのルールは明快で、そのループのチェックが安く、ごまかしにくく、安定しているときだけダークにしていい。認証、課金、公開APIには人間を残す。
03 — WHY NOW
2025年に、長く走るエージェントと安いサンドボックスが揃った
条件は三つある。一つ目はモデルが長いタスクを持てるようになったこと。METRの計測では、モデルがこなせるタスクの長さは約7か月ごとに倍になっており、OpenAIはCodexの1回の実行が6時間を超える例を報告している。二つ目はサンドボックスが安く速くなったこと。Stripeは開発環境を約10秒で立ち上げ、RampはModal上でエージェントごとにフルスタックを用意する。三つ目はハーネスがヘッドレスで動くようになったこと。Claude Code SDKやCodex execで、パイプラインがエージェントをビルドステップのように呼べる。
結果として数字が出ている。Stripeではエージェント（Minion）が作ったPRが週1,300件以上マージされ、UberではPRの70%以上がエージェントに帰属し、Rampではマージ済みPRの約半分が社内エージェントInspectから始まっている。OpenAIは5か月で約100万行を、一行も手で書かずに作った。いずれも各社の自己申告である。
04 — BLUEPRINT
工場は9つの持ち場の直列と、フィードバックと統制でできている
調査から組み立てた設計図は、11のステーションに分かれる。これはどこか一社が公開している標準ではなく、約130のソースから自分たちがまとめたものである。
- Intake（受付）
Slackでのメンション、Linearのチケット、本番アラート、フリート全体の変更依頼。何が実行を始めるかを決める。
- Spec（仕様）
何を作るか、どう作るか、どの手順で作るかをファイルにする。GitHub Spec KitやAWS Kiroなど。薄すぎるとエージェントが推測し、厚すぎると遅いコーディングと変わらない。
- Context（文脈）
文脈は予算である。約100行のAGENTS.mdという地図を常に渡し、それ以外は必要なときに読ませる。OpenAIの言葉では「1,000ページのマニュアルではなく地図を」。
- Orchestrate（編成）
作業をタスクグラフに分け、多数のエージェントを走らせる。ただしOsmaniの「オーケストレーション税」のとおり、エージェントは増やせても人間の注意は並列化できない。
- Sandbox（隔離環境）
エージェントごとに使い捨ての開発環境を与え、本番・秘密情報・インターネットから切り離す。Stripeが言う「監督する人間がいない」状態を安全にするのは、この隔離である。
- Harness（作業者）
モデルがツールを使って読み、編集し、実行し、テストするループ。Princetonの SWE-agent は、モデルを変えずにコマンド設計だけで成績を上げた。道具が腕を決める。
- Verify（検証）
エージェントは検証器が見ているものを解く。だからlint、テスト、LLM判定、隠しシナリオと、ごまかしにくいチェックを積み上げる。Carliniいわく「検証器はほぼ完璧でなければ、Claudeは間違った問題を解く」。
- Review（レビュー）
新しいボトルネック。人間が承認する会社、AIレビューと人間を組み合わせる会社、シナリオで置き換えて人間が見ない会社に分かれる。
- Ship（出荷）
フィーチャーフラグ、カナリア、テレメトリーで影響範囲を小さくし、異常があればラインを止める。DORA 2025では、AI利用はスループット向上と同時に安定性低下と結びついていた。
- Feedback（還流）
エラーを下書きPRにして受付に戻し、AGENTS.mdやスキルやテストを直して工場そのものを直す。
- Govern（統制）
すべての持ち場の下にある。エージェントごとのIDと責任者となる人間、権限、トークン予算、PR数以外の指標。METRのRCTでは、熟練開発者16人がAIを使うと19%遅くなり、本人たちは20%速くなったと感じていた。
第2部の一行要約はこうなる。生成が安くなると、渋滞は上流の仕様と下流のレビューに移る。上流では「これは正しいものか」が、下流では「これは正しく作られているか」が詰まる。HumanLayerは、10〜100倍ではなく安全な2〜3倍を狙い、ラインの一番遅いところに投資しろと言っている。
05 — CASES
大企業はL3〜L4、L5を名乗るのは小さなチームである
スライドでは、人間・エージェント・機械のレーンに分けて各社の工場を描いている。数字はすべて各社の自己申告である。
- StrongDM（L5）：「コードは人間が書いてはならない」。人間はレビューもしない。代わりに、Okta、Jira、Slackなど6サービスのデジタルツインの上で、エージェントから隠したシナリオを走らせ、LLMが満足度を採点する。トークンはエンジニア1人1日1,000ドルが下限。
- Stripe Minions（L3）：Slackでボットを呼ぶと、温めておいた開発環境が約10秒で立ち上がり、goose（の社内フォーク）が実装し、CIは最大2回まで回してPRになる。人間が全PRをレビューする。
- Spotify Honk（L4）：フリート管理のパイプラインはそのまま、スクリプトだけをClaude Codeに置き換えた。LLM判定がセッションの約4分の1を差し戻し、移行作業の時間を60〜90%削減した。
- OpenAI（L4）：Codexが読むために作られたリポジトリと、LinearのチケットをCodexの実行に変えるSymphony。「人間が舵を取り、エージェントが実行する」。
- Anthropic C compiler（L5）：16体のClaudeがDocker内で、gitのロックファイルでタスクを取り合いながら、テストだけを頼りに10万行のCコンパイラを作った。Linux 6.9が起動する。API費用は2万ドル未満。
- Ralph、Gas Town（個人）：Huntleyのループと、Yeggeの「町」。Gas Townでは人間はMayorとだけ話し、20〜30体のエージェントの作業状態はgit上の台帳に残る。
- HumanLayer（L3）：2025年7月に完全にライトを消し、11月頃の3度目の障害の後に手で書き直した。今は人間が仕様を見て、コードを読む。合言葉は「Read the dang code」。
共通しているのは、タスクごとのサンドボックスと、人間より先に機械のチェックを通すこと、そして状態をエージェントの記憶ではなくファイルに置くことである。違うのは最後のゲートだけで、スコアだけの会社、人間がPRを読む会社、安全なら自動マージする会社、人間が証拠を見て承認する会社に分かれる。
06 — DEBATES
作る人は「もっと進め」、測る人と保守する人は「落ち着け」と言う
六つの論点のどれでも、作っている側は前に進めたがり、計測している側と保守している側はブレーキを踏む、という構図になっている。
ダークか、ライトか
ダーク派は「コードではなく振る舞いを検証しろ」と言う。エージェントはコードに合わせてテストを書き換えられるので、StrongDMはシナリオをリポジトリの外に置く。反対派は「テストが通っている間に設計が腐る」と言う。HumanLayerの原因分析は「保守性を壊しても罰がない」だった。両者とも限界は検証だと認めていて、分かれるのは設計の質に人間の読解が要るかどうかである。落としどころはトワイライトで、チェックが信頼できるループだけを自動化し、意図・設計・リスクには人を残す。
レビューはどうするか
使われている方法は六つある。人間が全差分を読む（Stripe）、設計を先に見てからコードを小分けで見る（HumanLayer）、AIが全変更をレビューし人間が署名する（Cloudflare、Uber）、リスクで深さを変える、CIやビデオなどの作業証拠を人間が見る（Symphony、Ramp）、シナリオだけで誰も読まない（StrongDM）。違いは人間がどれだけコードを読むかに尽きる。
生産性は本物か
会社の数字はAIの出力量を数えている。一方、統制された研究の結果は小さく、まちまちで、ときにマイナスである。METRの2025年のRCTでは作業時間が19%増え、Farosの2.2万人のデータではAI採用度が高いとPRあたりのインシデントが242.7%増えた。そもそも「触った」「書いた」「生成した」「マージした」が混ざっているので、会社間の数字は比べられない。
仕様駆動はMDDの再来か、歴史は繰り返すか、トークン代は見合うか
仕様を「ソースそのもの」に近づけるほど、モデル駆動開発（MDD）と同じ問題を抱える、とBöckelerは指摘する。歴史を見ても、日立もSDCもMicrosoftもKessel Runも、品質は上げたが広がらずに止まった。そこから借りるべきはトヨタの自働化とアンドン、つまり異常があれば機械が自分で止まり、すぐに人を呼ぶというルールである。お金の面では、StrongDMの1日1,000ドルを250営業日で掛けると年25万ドルで、給料並みになる。今のところ「見合う」証拠は、支出額と企業価値が中心である。
最後のスライドの結論はこうだ。暗くすることは決断ではなく能力である。一段暗くするたびに人間のチェックが一つ消えるので、その分を何かで置き換えられなければならない。
07 — STACK
重要度が上がるのは、エージェントとmainブランチの間の層である
工場はモデル、ハーネス、文脈とツール、編成、サンドボックス、検証とCI、レビューとマージ、デプロイと観測の8層でできていて、IDと権限とコストがそれらを横断する。スライドではそれぞれの層の実際の製品を並べた。
いくつか印象に残った点を挙げる。サンドボックスのベンダーは隔離だけでなく、スナップショット、フォーク、再開といった状態の扱いで競っている。CIはエージェントがループの中で呼ぶ道具になるので、速く、キャッシュされ、回数に上限がなければならない（Stripeは2回まで、Dropboxはflaky testの修正を5回まで）。数時間かかるエージェントの作業をクラッシュで失わないために、TemporalやCloudflare Workflowsのような永続実行が下に入る。統制では、エージェントごとに人間のスポンサー、短命なトークン、セッションあたりのコストモデルを持たせる。Uberのコスト式は「ユーザー数 × セッション × ターン × リクエスト × トークン × 単価」で、因数ごとに削る手段がある。
今後重要になると自分たちが読んでいるのは、モデルのルーティング、ヘッドレスなハーネス、MCPゲートウェイ、チケット駆動の永続ワークフロー、タスクごとのマイクロVM、エージェントの道具としてのCI、隠しシナリオとデジタルツインである。どれもエージェントとmainブランチの間にある。
08 — OUR VIEW: TACIT KNOWLEDGE
ここから私見。顧客が知っていることの8割は、水面の下にある
ここまでは調査の報告だった。ここからは自分の意見である。結論から言うと、工場が儲かるかどうかは暗黙知で決まると思っている。
工場に「打刻ボタンを作って」「CRMを作って」と頼めば作ってくれる。しかし顧客一社一社は、膨大な暗黙知を抱えている。マニュアル、仕様書、既存のデータとして書かれているのは、感覚的にはせいぜい2割である。残りの8割は現場にしかない。誰が実際に使うのか。毎日何に困っているのか。使いながらどう考えているのか。どの作業が一番多いのか。その人たちが自分の顧客と何を話しているのか。（80/20は自分の大まかな見積もりで、計測した値ではない。）
工場が受け取れるのは、細いパイプを通ってくる依頼文と、存在する文書だけである。その左側にある、顧客が知っているが書いていないことは、入り口ですべて失われる。だから工場は、技術的には動くがその現場には合わない汎用的な答えを作る。HumanLayerの処方箋も、コードを書く前の製品レビューから始まっている。
09 — OUR VIEW: PRACTICE
レーンで育て、定期的に直し、一枚の図面を共有する
需要に合わせてレーンを足す
工場は使うほど扱うタスクの種類が増える。何でもやる一本のレーンではなく、デザインとエンジニアのエージェントを持つフロントエンドのレーン、自分のエージェントを持つバックエンドのレーン、というように専門のレーンに分け、需要が見えたときに初めて新しいレーンを足す。各レーンには人間のオーナーを一人置き、工場が大きくなっても一人あたりの認知負荷を平らに保つ。
1%のずれは複利で効く
暗黙知の小さなずれ、たとえば1%は、自動化が走るほど大きくなる。人間のチェックなしに200ステップ走ると 1.01200 ≈ 7.3倍、25ステップごとにチェックすれば 1.0125 ≈ 1.28倍で済む。これはデータではなく算数の例えだが、無人で長く走るほど戻るのが難しくなり、AI特有の雑な成果物（AIスロップ）が溜まっていく感覚には合っている。
だから答えは、思い出したときではなく決まったリズムで、レビューし、開発し、現場からフィードバックをもらうことだ。そして、おかしいと思ったらラインを止める。ここでもトヨタの自働化とアンドンが参考になる。自分たちにとってのアンドンは、エージェントがいつ人間を呼ぶべきかのルールである。
3つの文書を共通言語にする
今の自分たちのやり方では、UXフロー（誰が何をどの順でやるか）、設計書（システムがどう動くか）、実装計画（エージェントが従う手順）の三つを、それぞれレビューしてから次を書く。レビューする人は一度に短い一層だけを読めばいいので、認知負荷が下がる。HumanLayerも、製品レビュー、システム設計、プログラム設計、縦切りの実装と、同じ形を取っている。意図、構造、コードレベルの計画の順に合意してから、エージェントに作らせる。
なぜ何千人もの人が一つのロケットを作れるのか。工場、マンション、超高層ビル、潜水艦でもいい。全員が、きちんとレビューされた一枚の図面から作るからである。試作や3Dプリントの実験も図面の中にあり、チェック用の文書は図面から派生し、レビュー会議が重ねられる。図面がずれないから、誰が作っても結果がぶれない。ソフトウェアファクトリーでは、三つの文書が図面で、エージェントが100人の作り手である。
2種類の暗黙知をつなぐ
ただし、レビューを増やして厳しくするだけでは足りない。暗黙知は二種類ある。人間の暗黙知は、顧客が本当に意図したこと、現場が実際にどう回っているか、なぜその選択をしたか。AIの暗黙知は、モデルが置いた前提、黙って選んだデフォルト、まだ誰も読んでいないコード。レビューはこの二つが出会う場所であり、共有された文書の上で、両側が自分の前提を表に出すときに一番うまく働く。
10 — OUR VIEW: DOES IT PAY?
コーディングが簡単になると、ボトルネックは売る・入れる・広げるに移る
一つのプロダクトに対しては、工場は確実にコストを下げ、機能を増やす。疑わしいのは、機能が増えると使いやすさや顧客の成果が良くなるのか、という点である。そこは利用者を理解しているかどうか、つまり氷山の水面下で決まる。YCのGarry Tanも、Railsで約50万行を生成した後に、量を追う「Foxconn工場」を作るなと警告している。
エンタープライズでは話が変わる。10社のために工場を作るということは、10社それぞれの暗黙知を吸収するということなので、共有の工場一つではなく、専用の工場が10個になると予想している。それぞれが現場で使われ、データと文脈が溜まり、次の出力が良くなる。使うほど良くなる複利がここにある。（まだ予想であって、測ったわけではない。）
結局、ソフトウェアファクトリーとはボトルネックの移動である。コーディングが簡単になると、制約は営業、カスタマーサクセス、企画、コンサルティングに移る。エンタープライズなら営業、稟議、組織への定着、現場への展開。SMBなら営業、マーケティング、価格競争、差別化。日本では特に、オンボーディング、カスタマーサクセス、エバンジェリスト型のマーケティング、ブランディングが効いてくると思う。
まだ答えが出ていない問いもある。誰にとってもコードが安くなったとき、ブランドに全振りするのか、それとも希少性とボトルネックが移る先を追い続けるのか。自分はまだ決めていない。
長い目で見た問いは、作るほど文脈が溜まる工場を作れば、いずれAIがすべての部署に正しいアプリを正確に作れるようになるか、である。そのためには四つの礎石が要る。文脈を集めて保ち再利用すること。ソフトウェアファクトリーを設計する力。顧客が本当に言いたいことをつかむ力（これはまた氷山の問題である）。それをテンプレートにして展開する力。
11 — SUMMARY
まとめと、勉強会で投げた問い
- 定義
ソフトウェアファクトリーとは、仕様・チェック・レビューゲートのパイプラインの中で、エージェントが作る仕組みである。
- 現場
人間がレビューするライトから、誰もコードを読まないダークまで幅がある。そしてHumanLayerはライトを点け直した。
- 暗黙知（私見）
顧客が知っていることの大半は書かれていない。工場は与えられたものからしか作れない。
- 実践（私見）
需要に合わせてレーンを足し、決まったリズムで直し、UXフロー・設計書・実装計画というレビュー済みの文書を共有する。
- お金（私見）
安いコードはボトルネックを営業、導入、展開に移す。価値もそこに行く。
勉強会の最後には、自分たちの工場を作る前に話し合いたい問いを五つ置いた。読んでいる人の会社でも、そのまま使えると思う。
- 水面の下：いまの顧客について、現場にいたからこそ知っていることは何か。それをどう書き下すか。
- 最初のレーン：どのレーンを最初に作り、誰がオーナーになるか。
- ケイデンス：どのくらいの頻度でレビューするか。何が起きたらエージェントは止まって人を呼ぶべきか。
- 自分たちの図面：UXフロー、設計書、実装計画で足りているか。何が欠けているか。
- ブランドか希少性か：誰にとってもコードが安いなら、ブランドに賭けるか、次のボトルネックへ移り続けるか。
工場はコードを安くする。しかし、何を作るべきかは、いまも現場にしか書かれていない。
参考文献の12本はスライドの最後（75枚目）にまとめてある。特にHumanLayerの「Why Software Factories Fail」、StrongDMの「Software Factories and the Agentic Moment」、Shapiroの「The Five Levels」、Osmaniの「Software Factories, Light and Dark」の四本は、最初に読むといい。