10月23日、O'Reillyが「The Agentic Software Factory Hierarchy of Needs」と題した記事を公開した。ラップトップを閉じて離席している間もAIエージェントが自律的に開発を進め、戻ったときにはプルリクエストか具体的なブロッカーが待っている——そんな開発体制を実現するための設計思想と4層フレームワークが詳しく紹介されている。現在のClaude CodeやCodexは「会話の中で機能を実装する」段階にとどまるが、記事が提唱する「ソフトウェアファクトリー」はその構造を根本から変えようとするものだ。
「ソフトウェアファクトリー」とは何か
Stripe、Ramp、Warpといった企業がすでにエージェントベースの開発ワークフローを本番運用している。チケットやチャットの依頼をエージェントが処理し、プルリクエストを生成する仕組みだ。なお、Warpの「factories」はターミナルツール上でエージェントタスクを非同期実行する機能であり、本記事が定義するソフトウェアファクトリーの概念と直接対応している。
では「ソフトウェアファクトリー」の定義は何か。記事はこう整理する。
自律（Autonomous）かつ非同期（Asynchronous）な実行の組み合わせがファクトリーを定義する。
- 自律： エージェントが合意した目標に向けてステップを選択・実行し、結果を確認しながらアプローチを調整できる
- 非同期： その作業が人の継続的な関与なしに進行できる。離席して戻ったときに結果が出ている
スケジュールジョブは「非同期」だが自律ではない。対話型のコーディングエージェントは「自律」だが非同期ではない。ファクトリーはその両方を兼ね備えたものだ。
従来のソフトウェアファクトリーは何十年も前から構想されてきたが、エージェントの登場によってようやく実運用が可能になった、というのが記事の立場である。
なぜ今これが重要か
現在のClaude CodeやCodexなどの使い方では、「エージェントが会話の中で機能を実装する」ものの、「次に何をするか」「どこまで進んだか」の管理は依然として人間が担っている。作業はユーザーが戻るまで止まる。
ファクトリーはこの構造を変える。人間が合意した成果物とその検証基準を定義し、あとはシステムが動く。 戻ったときには結果か、具体的なブロッカーが待っている。
4層の「ニーズ階層」
記事はMonica RogatiのAIニーズ階層にならい、ソフトウェアファクトリーを4層で構造化する。
1. Harness（ハーネス）
エージェントを動かす実行環境。ファイルの読み書き、コードの実行、結果のフィードバックを提供する。Claude CodeやCodexを使っているなら、すでにこれがある。
重要な点として、ラップトップを閉じても作業が続けられるよう、クラウドマシン上で動かすことが推奨されている。チェックが失敗したとき、エージェントが原因を調査できる十分な情報をハーネスが返せるかどうかも設計上の要点だ。
2. Personalization（パーソナライゼーション）
エージェントに「あなたのやり方」を伝えるコンテキストとルール。毎回説明し直さなくて済むよう、以下を整備しておく。
- Rules： 既存の請求書レコードを保持する、支払いステータスの計算を変更する前に確認する、など
- References： テンプレート、支払い条件、サンプル請求書
- Skills： 請求書作成・支払い更新・永続化のテスト手順
AGENTS.mdのような指示ファイルにこれらへの参照をまとめておく方法が紹介されている（OpenAIのハーネスエンジニアリング事例を参照）。
記事中には実体験のエピソードも挟まれる。著者の一人がエージェントに「テストを書け」と指示したところ、READMEのテストを書いてしまったという。指示の粒度と適用範囲の明確化が不可欠だと示す事例だ。
3. Automation（自動化）
ファクトリーの核心部分。スケジュールやイベントがエージェントを起動し、あなたの指示なしに作業を開始する仕組みだ。
単一エージェントのケースでは、朝のスケジュールでタスクリストを読み込み、次の合意済みタスクを実行する。並列化が必要なら複数エージェントを協調させる。たとえば：
- エージェントAが部分払い機能を実装
- エージェントBがそのテストシナリオを準備
- エージェントCが完成した変更をレビュー
依存関係のあるタスク（部分払い計算が確定するまで督促メール機能は待機する、など）は共有タスクリストやイシュートラッカーで管理する。
検証の組み合わせとして、Anthropicの評価ガイドを引用しつつ、以下の3種類を組み合わせることが推奨されている。
- 決定論的テスト： 残高計算の正確さ、再起動後のデータ永続性など
- エージェントによる検証： 見落とした要件や変更間の不整合の検出
- 人間の判断： ワークフローが実際の業務に合っているかの確認
4. Continual Learning（継続的学習）
ファクトリーの改善サイクルを担う層だ。単なるログ保存ではなく、実行ログ・チェック結果・失敗記録をレビューエージェントが能動的に分析し、再発防止策や手順の改善案を提案する。この分析結果は上位層のPersonalizationへフィードバックされ、Rulesの追加・Skillsの更新として反映される。つまり「実行→検証→分析→改善→次の実行」という閉じたループがファクトリー全体を徐々に賢くしていく仕組みだ。
記事の例では、「再起動後に支払いが消えるバグをエージェントが見逃した」ケースを扱う。チェックをスキップしたのか、そもそもアプリ再起動のツールがなかったのかを検証し、「変更がある場合は必ず保存→再起動→残高検証」というスキルとして定型化する流れが示されている。このようにContinual Learningの真価は、個々の失敗を「次回から自動で回避できるルール」へと昇華させる点にある。
設計の通底原則：仕様化と検証
記事全体を貫くのがspecification（仕様化）とverification（検証）の2つだ。
すべての層で、「何を達成したいか」「成功の基準は何か」を明示し、その基準に対して結果を検証する。エージェントはその両方を支援できるが、「要件が自分のニーズを本当に捉えているか」「証拠が結果を受け入れる根拠として十分か」の判断は人間が担う、というのが記事の一貫した立場だ。
詳細はThe Agentic Software Factory Hierarchy of Needsを参照していただきたい。
