■ 1. 速度と成果の溝
- 個人の生産性と組織の成果の乖離:
- AIがコードを書き画面も作れるようになり、個人の生産性は確かに上がった
- 一方で組織の成果はそれほど伸びていない
- 速度向上が生む副作用:
- 作る速度が上がった分だけレビューが詰まる
- 品質のばらつきが広がる
- 誰も全体を理解していないコードが増えていく
- 速く作れることと良いものを出し続けられることのあいだには、まだ深い溝がある
- この溝への答えとして、2026年に入りAI開発の文脈で「ソフトウェアファクトリー」が再び前面に出てきた
■ 2. ソフトウェアファクトリーの定義
- ソフトウェアファクトリー:
- AIエージェントを工場の作業者とみなす開発体制
- 人間が工程を設計し、ソフトウェアを継続的に量産する
- 具体的なフロー:
- 標準化された形式で仕様が投入される
- 複数のエージェントが実装とテストを進める
- 人間とエージェントの成果物が、同じ検査工程を通る
- 良品条件を満たしたものだけが出荷される
- 良品条件の範囲:
- 機能要件だけではない
- テスト、セキュリティ、性能、アクセシビリティ、デザインの一貫性など、出荷を認める条件全体を指す
- この流れが何本も並行で毎日回り続け、主語は個人の技術から組織の工程に移った
- 工場という比喩への抵抗:
- ソフトウェア開発は創造的な仕事でありベルトコンベアとは違うという反発が、この言葉の歴史の中で繰り返されてきた
- それでも再浮上しているのは、実装という工程に限れば継続的に量産する条件が揃い始めたため
■ 3. いま語られ始めた背景
- AI Engineer World's Fair 2026:
- 2026年6月末にサンフランシスコで開催された、6,000人以上が集まる世界最大級のAIエンジニアリングカンファレンス
- 本会議初日の6月30日には、メインステージのトラック名として「Software Factories」が掲げられた
- Microsoft、OpenAI、Factory、HumanLayerなどがこのテーマで講演した
- CursorのFDE部門を率いるPauline Brunet氏:
- 顧客の現場に入り開発体制を一緒に構築するForward Deployed Engineering部門を統括する
- 会場でのインタビューで、顧客組織とAIソフトウェアファクトリーを構築していると語った
- Stripeの実績:
- Minionsと呼ばれるコーディングエージェントが、人間の書いたコードを含まないプルリクエストを毎週1,000件以上本番へ送り出している
- ただし出荷前のレビューと承認は人間が担当する
- OpenAIの実績:
- 3人のエンジニアがCodexを動かし、手書きコードなしで内部向けベータ版を5か月で構築した
- リポジトリはアプリケーション、インフラ、ツール、ドキュメントを含めて約100万行に達した
- マージされたプルリクエストは約1,500件に到達した
- 論点の移動:
- 個人がAIで速く書く段階はすでに終わった
- エージェントの群れに開発を任せる体制をどう組むかへ論点が移った
- 企業側の動き:
- FactoryのようなAIネイティブの開発基盤が、IDEからCIまでをつないでいる
- コンサルティング会社も、エージェントを前提とした開発体制を扱い始めた
- 個人側の動き:
- Geoffrey Huntley氏が広めたRalph Loopがある
- 毎回まっさらなコンテキストでエージェントを起動し、一つのタスクを処理させ、結果をファイルやGitに残して次のループへ進む
- 巨大なエージェントに長い仕事を任せるのではなく、短い実行を繰り返す
- 上から工程全体を設計する動きと、下から小さなループを積み上げる実践が、同じ開発体制へ近づいている
■ 4. 日本由来の語源
- ソフトウェアファクトリーは新語ではなく、構想の起点は米国だが最初に組織として形にしたのは日本である
- 1968年: Bob Bemer氏が、標準化された道具と管理環境を備えたソフトウェア工場を提唱
- 1969年: 日立が、世界で初めて「ソフトウェア工場」を名乗る開発組織を設立
- 1975年: 米国のSystem Development Corporationがソフトウェア工場を実験
- 1976年から1977年: 東芝、NEC、富士通が工場型の開発体制を展開
- 1991年: MITのMichael Cusumano氏が『Japan's Software Factories』を出版
- 2004年: Microsoftが、パターン、モデル、フレームワークを組み合わせる方法論として再定義
- 2017年: 米空軍がKessel Runを立ち上げ、国防分野でもソフトウェアファクトリーという呼び名が使われる
- 当時と現在の違い:
- 当時の中心にあったのは標準化、再利用、品質管理
- 2026年の再解釈では、実装を担う主体としてAIエージェントが加わる
- 人間の仕事は、意図を定義すること、工程を設計すること、出てきた成果を検証することへ寄っていく
■ 5. 工房の品質と工場の品質
- 品質の根拠の違い:
- 一点物を作る工房では、作り手の腕が品質を大きく左右する
- 工場では、作り手の技術に加えて、どの工程を通ったかが品質の根拠になる
- 入力の標準化:
- スコープや受け入れ条件が、同じ形で入ってくる
- 共通の検査:
- 人間が書いた変更も、エージェントが書いた変更も、同じ検査を通る
- 出力の測定:
- サイクルタイムや欠陥率などを測定できる
- 再現性:
- 出荷した変更を、入力・プロンプト・モデルのバージョンから再現できる
- 生成AIは同じ入力から毎回まったく同じ結果を出すとは限らない
- 必要なのは完全な再現性より、何をもとに、どの環境で、どのように作られたかを後から追えること
- 個人の腕前の位置づけ:
- 個人の腕前が不要になるわけではない
- その腕を、組織で再利用できる基準と工程に移せるかが問われる
- 品質の根拠が「誰が作ったか」だけでなく、「どの条件を満たし、どの検査を通ったか」に移る
■ 6. 工場を成立させるハーネス
- Addy Osmani氏による定義:
- 元Googleのソフトウェアエンジニアが構造を整理した
- ソフトウェアファクトリーを「ハーネスを付けたループを、大きな規模で動かすこと」と説明する
- ハーネスの構成要素:
- ループを囲む仕組みであり、実行環境と使える道具を含む
- 実行をまたいで残る記憶、権限、そして何をもって完了とするかを決めるゲートを含む
- 工場という全体像:
- ハーネス付きのループが何本も同時に回り、仕事のキューから供給を受ける
- 検査とレビューを通って本番に流れ込み、障害やユーザーの声は再びキューに戻る
- 人間は全体の設計と責任を担う
- 巨大なエージェントを一体育てる方向とは異なり、小さなループが役割を分担し受け渡しと検査でつながる、ループでできた組織図である
- WorkOSのRyan Cooke氏の指摘:
- 同カンファレンスで「No, That's Not a Software Factory」という講演を行った
- サンドボックスを用意しエージェントを何体か並べただけでは工場にならない
- 成果を安定させる要素:
- 成果を安定させるのはモデルだけではない
- その周囲にある規約、実行環境、検証ゲート、完成の定義である
- エージェントに任せる範囲が広がるほど、任せ方を定義する構造の側が重要になる
■ 7. デザインハーネスとの重なり
- デザインハーネス:
- 2026年5月から提唱している考え方
- 制約、コンテキスト、検証、フィードバックループの4層で、デザインの判断をAIが読める仕様に落とす
- ソフトウェアファクトリーの条件と比べると、必要な部品が大きく重なる
- 標準化された入力には、制約とコンテキストが必要になる
- 共通の検査には、検証可能な品質基準が必要になる
- 出力の測定には、結果を次の実行へ戻すフィードバックループが必要になる
- 追跡可能性には、判断の根拠や変更履歴を残す仕組みが必要になる
- 部品が重なる理由:
- 別々の議論が似た部品を必要とするのは、エージェントへ仕事を任せる際の問題が共通しているため
- エージェントは組織の暗黙知や品質基準をそのままでは読めない
- 制約として渡し、結果を検証し、失敗から基準を更新する必要がある
- エージェントに案件を任せるなかで作り込んできたのも制約や検証の仕組みであり、工場でいえば検査工程にあたる
- ソフトウェアファクトリーという名前があることで、個別のプロンプトやツールの話ではなく組織の開発工程として議論できる
■ 8. デザインとの親和性
- 工場が送り出すもの:
- 工場が送り出すのはコードだけではなく、利用者が触れるソフトウェアである
- 良し悪しを決めるのは、画面の一貫性、文言のトーン、操作したときの反応、エラー時の振る舞いといったデザインの判断である
- 良品条件のかなりの部分は、デザインの言葉で書かれる
- 良品条件の具体例:
- 指定外の色や余白が使われていないか
- キーボードだけで操作できるか
- ローディング、空、エラーの状態が揃っているか
- 文言がトーンの規約に沿っているか、画面差分が許容範囲に収まっているか
- こうした条件を機械と人が確認できる形にすれば、デザインは実装前の制作物ではなく出荷判定の一部になる
- 現場で起きている変化:
- AIがある程度デザインできるとわかった時点から、品質をどう担保するかという相談が増えた
- 工場化の相談は、多くの場合、品質基準の相談として持ち込まれる
- 工場化の適用範囲:
- すべての開発が工場になるとは考えていない
- 何を作るべきかがまだ決まっていない探索段階では、人間の観察と判断が必要になる
- 工場が扱いやすいのは、意図と良品条件をある程度定義できる仕事である
- 探索が消えるのではなく、探索と量産の境界を設計する必要がある
■ 9. 「暗い工場」の失敗
- 明るい工場と暗い工場:
- Osmani氏は製造業の無人工場になぞらえ、人が判断に関わる工程を「明るい工場」と呼ぶ
- 機械の検証だけで出荷する工程を「暗い工場」と呼ぶ
- 暗い工場とは、人がいない工場では照明をつける必要がないという意味である
- 明るい工程:
- 間違えたときの影響が大きい場所に、人の設計やレビューを残す
- 暗い工程:
- 完了を機械的に判定できる仕事を、人が読まずに出荷する
- 工程ごとのスイッチ:
- 組織全体を二つに分類する話ではない
- どのループを暗くできるか、工程ごとにスイッチを決める話である
- 小さく、失敗を自動で判定でき、影響範囲も限られている変更は暗くできる
- 認証、課金、公開API、長期的な設計判断のように影響が大きい工程には人を残す
- HumanLayer社の実験:
- AIコーディングIDEとチーム向け開発基盤を提供する同社が、約4か月、人が生成コードを読まない全自動の開発を試した
- 創業者のDex Horthy氏によれば、障害が起きたとき、すでに人間の理解から離れていたコードを読み直し手作業で原因を突き止めることになった
- テストは通っているのに、中身を理解している人がいないコードが増えていた
- 理解負債:
- Osmani氏はコードの量と人間が理解している範囲の差をこう呼ぶ
- 暗い工場はレビュー待ちをなくせるが、同時に理解負債を速いペースで積み上げる
- 同一エージェントによる自己検証の問題:
- コードとテストを同じエージェントが同じ前提から作ることが問題となる
- 仕様を誤解したまま実装し、その誤解に沿ったテストを書けばテストは通る
- 緑色のチェックだけでは、意図に合っているかを証明できない
- 検証こそが制約:
- 生成量は計算資源を増やせば拡大できるが、検証に使える人間の注意には限りがある
- ソフトウェアファクトリーの制約は、どれだけコードを作れるかではなく、どれだけ安く速く確実に検証できるかである
- 工場化の明暗を分けるのは検品の設計である
- 検品設計で問うべきこと:
- どの工程は自動検査で足りるのか、どこに人の目を残すのか
- 誰が良品条件を定義し、失敗したときに責任を持つのか
- 自動化できる工程を増やすには、まず検証できる工程を増やす必要がある
■ 10. 基準の言語化
- 人間の持ち場の移動:
- 人間は工場から消えたのではなく、持ち場が移った
- ラインの中で変更を一つずつ作る側から、ラインを設計し重要な判断に参加し出口のゲートを守る側へ移る
- これからのデザインに求められるもの:
- 作れることに加えて、何を良いとするかを言語化できることの比重が大きくなる
- 良い画面を一度作れるだけでは、毎日動く工場の品質は保てない
- 判断を制約、規約、テスト、レビュー項目として残し、人間とエージェントの両方が使える形にする必要がある
- 経営側の打ち手:
- 個人にAIツールを配るだけでは、生成量が増えた先でレビューが詰まる
- 良品条件、検査工程、判断の責任に投資した組織ほど、量産の速度と品質を両立しやすくなる
- ソフトウェアファクトリーを成立させるのは、エージェントの数ではなく、組織が自分たちの基準をどこまで工程にできるかである