Software Factory とは何か - AI Engineer World's Fair 2026 に見る潮流

Author:

2026-07-08

はじめに

AI Engineer World's Fair 2026 の参加レポート、 Agent Loop と Evals の潮流に続く 3 本目の記事です。本記事では、会期中頻繁に耳にしたキーワードの 1 つであり、前記事で整理した Loop と Evals の上に成り立つ概念でもある「Software Factory」を深掘りします。

今年の World's Fair では "Software Factories" というトラックが立ち、キーノートでもこの言葉が繰り返し登場しました。一方で、後述するように「その呼び方は違うのではないか」という反論のセッションまで組まれており、言葉の定義そのものが議論の対象になっている、いままさに形成中の概念だと感じました。

本記事では、複数のセッションを横断して見えてきた Software Factory の定義と構成要素、なぜ今この概念が注目されているのか、そして私自身がこのトレンドをどう受け止めたかを共有します。

Software Factory とは何か

起源: 夜間に走り続けるループ

Software Factory の源流としてトラックの導入セッションで言及されていたのが、 Geoffrey Huntley 氏が提唱した、いわゆる Ralph loop です。これはコーディングエージェントを while ループで回し続け、人間が寝ている間も自律的にソフトウェアを作らせるという、シンプルながら挑発的なアイデアでした。

登場当初はグリーンフィールド(新規開発)にしか使えないと言われていましたが、この 1 年でモデルの検証能力、実運用データにアクセスできるツールエコシステム、コンテキストウィンドウとメモリ、推論能力、そして AI セキュリティのベストプラクティスが揃い、「Software Factory はもはや未来のビジョンではなく実用段階に入った」というのが今年のトラックの位置付けでした。
私の感覚では、参考にできる実装やテストが揃っている既存コードベースの方が、コンテキストと評価の仕組みさえ整えればむしろ効果が出やすく、このアプローチが開発を加速させ得ると感じました。

定義: コード生成ではなく、SDLC 全体を自動化する統合ループ

セッションを横断して共通していた定義は、 Software Factory とは「コード生成エージェントの集合体」ではなく「ソフトウェア開発ライフサイクル全体を自動化する統合ループ」だという点です。

工場の生産ラインに相当するのは次のような流れです。

課題の入力 (Issue、Slack、監視システムから作成)
トリアージ (エージェントが難易度・曖昧さを判断し振り分け)
スペック生成 (プロダクト仕様と実装仕様の分離)
実装 (サンドボックス内のコーディングエージェント)
レビュー (エージェントの一次レビュー → 人間のリスクベース二次レビュー)
検証・デモ (テスト実行、UI は動画・スクリーンショットで確認)
CI/CD・モニタリング (出荷後のシグナルをラインの先頭へ再投入)

ポイントは、人間の介入点が「なくなる」のではなく「明確に定義される」ことです。エージェントに委任する部分と、人間がリスクベースで判断する部分の境界設計そのものが、 Software Factory の設計だと言えます。

この整理は、先日 Findy AI Engineering Summit Tokyo 2026 で私が登壇した「チームで実践する AI-DLC: 思考の軌跡を残すチェックポイント設計」と通じるものがあります。 AI-DLC の取り組み自体の説明は前記事と登壇資料に譲りますが、開発プロセスの要所にチェックポイントというゲートを設けた意図の 1 つは、人間の確認をシフトレフトすることにありました。仕様や設計の段階で認識のズレを集中的に潰しておけば、後続のコーディングなどのタスクはより手放しでエージェントに任せられるのではないかという仮説に期待していたためです。 Software Factory の生産ラインが、人間のレビューを上流のスペックとリスクベースの判断に集中させているのはまさに同じ構造で、「どこで人間が判断するか」をプロセスとして明示的に設計するという発想が世界的な潮流と収束しつつあることを感じました。

Cursor が語る「開発の第 3 の時代」

会期中にこのキーワードが気になった私は、World's Fair のセッションに加えて、関連する過去の発表も遡って調べました。中でも具体的だったのが、今年 4 月に開催された AI Engineer Europe での Cursor の Eric Zakariasson 氏によるセッション "Building your own software factory" です。以下は、このセッションに加えて Cursor の公式ブログなどの公開情報もあわせて調べた内容の整理です。氏は AI を活用した開発を 3 つのフェーズで整理していました。

Autocomplete の時代: タブ補完によるローカルコーディングの高速化
Pair Programmer の時代: 対話形式でプロンプトを送り、提案をその場でレビューする現在の主流
Software Factory の時代: 人間は意図・制約・フィードバックループ・検証を定義し、エージェントはクラウド上の隔離環境で自律的にタスクをこなす

実際に Cursor の開発元では、マージされる PR の 35%(今年 2 月時点の 30% から上昇中)がクラウド VM 上で自律稼働するエージェントによって作成されていると紹介されていました。

そのうえで、ファクトリーを成立させる要素として挙げられていたのが次の 3 つです。

1 つ目はエージェントが理解しやすいコードベースです。

Agents are completion machines.

この表現が印象的でした。エージェントは既存のコード・命名・ディレクトリ構造・実装パターンに強く引っ張られるため、モジュール境界が明確で、標準的な起動・テストコマンドがあり、真似すべき良い実装例が揃っていることが前提になります。裏を返せば、汚いコードベースに AI を投入すると、汚いパターンが高速に増幅されるだけです。

2 つ目は検証(ガードレール)です。エージェントに任せられる仕事は runnable / accessible / verifiable、つまりエージェントが自分で環境を立ち上げ、必要な情報にアクセスし、結果を検証できる必要があります。 UI の変更であれば、スクリーンショットや操作動画を成果物として出させ、人間はそれをレビューします。

3 つ目は隔離環境です。複数のエージェントをローカルで同時に走らせると、DB・キャッシュ・ポート・依存関係が衝突します。 Git worktree だけでは不十分で、エージェントごとに独立した VM を与えることが本格的な並列化の条件になります。

もう 1 つ実務的だったのは、ルールの育て方です。最初から巨大なルールファイルを書くのではなく、エージェントが同じミスを繰り返したときに、その失敗をルール・テスト・レビューボットへ変換して「生やしていく」というものです。この失敗からの学習ループこそがファクトリーの改善ループだと整理されていました。

Harness Engineering との関係

今年は "Harness Engineering" という新設トラックもあり、Software Factory と近い文脈で語られていました。ハーネスとは、モデルの周囲にあるツール実行・コンテキスト管理・検証・権限制御といった運用基盤の総称です。

前記事の「規律あるループ」でも触れた、実行記録の監視から修正 PR の提案までを自動で行う長期稼働エージェントのセッションでは、次のように語られていました。

If the harness is the product, you want to improve this loop.

ハーネスがプロダクトなら、改善すべきはこのループだ、という主張です。

私の理解では、ハーネスが「1 つのエージェントを信頼できる形で走らせる基盤」であるのに対し、 Software Factory は「複数のハーネスを組織のプロセスとして束ね、SDLC 全体を回す仕組み」です。個のエンジニアリングからチーム・組織のエンジニアリングへのスケールアップと言えます。

なぜ今 Software Factory なのか

コード生成のコストが下がり、ボトルネックが移動した

Google DeepMind の Benoit Schillings 氏によるキーノート "Research to Reality with Google DeepMind" では、ソフトウェア開発の歴史を 3 つの時代で整理していました。先に紹介した Cursor の 3 フェーズが AI 活用の進み方の整理だとすれば、こちらはコンピューティングの歴史全体を俯瞰する整理です。機械が高価でコードを機械のために最適化した第一の時代、人間の認知能力がボトルネックとなりモジュール化や再利用が発達した第二の時代、そして LLM によりコード生成コストが劇的に低下した第三の時代です。

第三の時代のボトルネックは「コードを書く速度」ではなく、「生成されたものが本当に望むものかを保証すること」、つまり検証と統治に移っています。 Software Factory は、この新しいボトルネックに正面から向き合うための組織的な回答だと捉えられます。この「検証」と、それを回し続ける仕組みについては、前記事で深掘りした通りです。 Software Factory は、その Loop と Evals を組織のプロセスとして束ねた到達点だと位置付けられます。

データが示す普及度と、楽観できない現実

普及の実態については前記事の Evals の節で触れた通り、 AI がエンドツーエンドで生成する PR はすでに全体の 4 分の 1 を超え、品質指標でも人間の PR と同水準に達しています。

一方で楽観論ばかりではありません。前記事でも触れたカーネギーメロン大学の分析が示す通り、導入初月の生産性向上は 2 ヶ月ほどで消えます。同分析ではさらに、静的解析の警告が 30%、コードの複雑性が 41% 増加したまま残り、この蓄積した技術的負債がその後の開発速度を押し下げる自己強化的なサイクルを生む、と推定されています。検証を後工程に置いたまま生成量だけを増やすと、レビューと修復がボトルネック化し、速度・品質・信用が同時に劣化する下降スパイラルに入るということです。

つまり「エージェントをたくさん走らせれば速くなる」は誤りで、検証をエージェントの内ループ・CI・レビューの各所に組み込んだ設計、すなわちファクトリーとしての設計があって初めて速度向上が持続する、というのが今年の合意形成でした。

単一のエージェントをどう設計するかという議論から、複数のエージェントを非同期・並列・隔離環境で走らせて組織のプロセスに組み込む議論へと、抽象度が一段上がったのがこの 1 年だと感じます。

トレンドに対する思い

ここからは私自身の受け止めです。

私の感覚として、「ファクトリー」という言葉には違和感を覚えるエンジニアも一定数いるのではないでしょうか。ソフトウェアエンジニアは元来、職人的なマインドセットを持っています。その目線に立つと、工場という比喩からは無機質な印象を受けますし、ただコードを大量生産することが望ましい姿だとは思いません。

この違和感を正面から扱ったのが、Conductor 創業者の Charlie Holtz 氏による "Orchestras, Not Factories" というセッションでした。かつて「feature factory」という言葉が批判的な意味で使われたように、機能を量産するライン管理者になることが未来の姿ではありません。人間は指揮者として全体を見渡し、要所では個々のパートに耳を傾けるように細部へ踏み込みながら、エージェントとの合奏を導きます。 DB マイグレーションや設計ドキュメントのような領域は、AI の自動編集を禁止する「slop-free zone」として人間が守ります。この整理には強く共感しました。

同時に、経営の視点では生産の自動化がもたらす迅速な価値創出は間違いなく望ましいものです。この 2 つは矛盾しません。一般化されやすい機能や、やり方が明らかな部分はどんどん自動化していきます。その分、人間は定型ではない「価値を生み出す」部分に集中し、高速にフィードバックサイクルを回します。オーケストラの比喩を借りれば、譜面通りに演奏できる部分はエージェントに任せ、人間は指揮と、ジャズのような即興を担います。目の前のビジネス課題を、AI を活用しながら即興で解決していく部分にこそ、エンジニアの価値が現れると考えています。

だからこそ、エンジニアとしては評価(Evals)やループといったワークフローの自動化を設計できる人材の価値が、今後ますます高まるはずです。参加レポートで触れた「Building is easier, generating value is still hard」という言葉の通り、作ること自体はエージェントに任せられるようになった今、何を作るかを決め、作られたものが価値を生むことを検証する側の設計力が問われています。

まとめ

本記事では AI Engineer World's Fair 2026 で頻出した Software Factory という概念を整理しました。

Software Factory はコード生成の自動化ではなく、SDLC 全体(トリアージ〜実装〜検証〜モニタリング)を自動化する統合ループ
成立条件は、エージェントが読めるコードベース、検証可能なタスク定義、隔離された実行環境、失敗をルールに変換する改善ループ
検証を後工程に置いたままでは速度向上は 2 ヶ月ほどで消える。検証をループに組み込む設計が持続性の分水嶺
一方で「工場」ではなく「オーケストラ」として、人間が指揮者であり続ける設計思想にも共感する

3 本の記事を通して、今年の AI Engineer World's Fair を振り返りました。生成の容易さに満足せず、Loop と Evals を設計し、その上に自分たちの生産ラインと、人間が指揮するオーケストラをどう組み立てるか。私達もこの問いに向き合っていきます。

AI 駆動開発のオーケストラを率いたい方、即興のセッションのように能動的かつ迅速な課題解決を楽しみたい方は、ぜひ Belong のエンジニアリングチームで指揮を執ってみませんか。