- ソフトウェアファクトリーは、コンテキスト収集・行動・検証を繰り返すループをハーネスで包み、大規模に運用するもので、人間が判断する明るいファクトリーと、コードレビューまで機械に任せるダークファクトリーに分かれる
- コード生成・テスト・スキャンはほぼコストなしにスケールするが、人間のレビューと判断はスケールしにくいため、生成量よりも結果を安価かつ信頼性高く検証する速度がボトルネックになる
- 人がコードを読まなければ、コードの規模と人間の理解の間に**理解負債（comprehension debt）**が蓄積し、テストが通り続けていても、長期間運用された複雑なシステムでは保守問題が遅れて表面化し得る
- 完全自動化は、即時でドリフトせず操作されにくい判定基準を備えた短いループにのみ許可し、認証・決済・公開 API のように誤った判断のコストと影響範囲が大きい作業では人間のレビューを維持すべき
- エンジニアの役割は、個別の変更を直接書くことから外側のループを設計して守ることへ移り、エージェントが行った診断・実装・テストの証拠を検証し、承認と結果に責任を負う必要がある
ループからソフトウェアファクトリーへ
- ソフトウェアを反復可能で計測可能な生産工程にしようという発想は、Bob Bemer が 1968 年に発表した「The economics of program production」までさかのぼる
- アイデアを自動車部品のように量産するのは難しかったため、この半世紀の間、こうした試みは概ね期待に届かなかった
- ここ 2 年の変化は、古いソフトウェアファクトリー構想を再検討するに足る大きなものだったが、過去の落とし穴が新しい機会のように包装される可能性もある
- 全体の体系はループ・ハーネス・ファクトリーという 3 つの層で構成される
- ループは、1 つのエージェントがコンテキストを集めて行動し、その結果を確認し、終了条件を満たすまで繰り返す最小の作業単位である
- ループエンジニアリングは、人が毎回プロンプトを入力する代わりに、エージェントにプロンプトを提供する小さなシステムを設計する方法である
- ハーネスには、ループが実行されるサンドボックス、使用可能なツール、実行間で維持されるメモリ、完了可否を判断するゲートが含まれる
- ハーネスのないモデルは際限なく繰り返せるため、ハーネスがループを有用かつ安全にする
- ソフトウェアファクトリーは、作業キューから項目を受け取り、複数のハーネスベースのループを同時に実行し、レビューゲートを経てプロダクションへ送り出す構造である
- より大きな単一エージェントではなく、ループで構成された組織図に近い
- エンジニアの作業単位も、個別のコード変更から、ループ、ハーネス、ループ間の流れへ移る
ファクトリーの作業フローとボトルネック
- エンジニアリングリーダーシップのビジョン、エンジニアの意図、障害やユーザー要望から出たシグナルが、1 つの作業キューに入る
- ハーネスが項目を選んで変更を作り、CI・テスト・静的解析・各種スキャンが変更を同時に検査する
- レビューゲートが承認すると変更をデプロイし、プロダクションの監視データは再び作業を引き起こすシグナルとして戻る
- 生成・テスト・スキャンは無視できるほどのコストでスケールできるが、レビューゲートにおける人間の判断はスケールしにくい
- 開発速度とデプロイ頻度を高められるかは、この判断のボトルネックをどう扱うかにかかっている
ダークファクトリーと理解負債
- 製造業におけるダークファクトリーは、機械が照明を必要としないため、明かりを消したまま運用される施設である
- FANUC は 2001 年からこのような工場を運用しており、Xiaomi も 2024 年に高度に自動化されたダークファクトリーを開設した
- ダークソフトウェアファクトリーでは、人がコードを読まず、コードを作った機械が行った検証だけで変更をデプロイする
- ここでの闇はネガティブな雰囲気ではなく、人が diff を作成・レビュー・デプロイする過程からいなくなったという意味である
- 人間のレビューを取り除くと、妨げが消え、チームの垂直方向のスループットが急激に高まったように感じられる
- しかし隠れたコストのため、このような作業フローを長期間維持するのは見た目より難しい
- オーケストレーション、サンドボックスベースのプロトタイピング、ツール呼び出しは今後も強力になっていくだろうが、ハーネスだけで長期的なコードベース品質を維持するには不十分である
- 理解負債とは、存在するコードの量と、人間が実際に理解しているコードの量とのギャップである
- ダークファクトリーは、テストが通っている間にも理解負債を急速に積み上げる
- 小さなコード領域への即時変更や週末プロジェクトとは異なり、10 年以上開発されてきた複雑な既存システムは、専門的な速度で継続的に保守しなければならない
- 自動化プロジェクトを 3〜6 か月運用すると、読んでいないコードに圧倒される可能性がある
- Dex Horthy が約 4 か月間、人間が生成コードを見ない完全自動化ファクトリーを運用したとき、問題の原因を突き止めるには骨の折れる手動デバッグが必要だった
- トークン使用量を最大化するほど、人がシステムを理解している度合いは静かに低下する
- 失敗は、テストが通っていたシステム全体が突然崩壊するのではなく、遅く静かに訪れることがある
生成より検証が制約になる理由
- **バックプレッシャー（back pressure）**とは、安価かつ信頼性高く検証できる範囲に限ってループに自律性を与える原則である
- ほぼ無制限の生成能力と、有限な人間の注意力とのギャップが核心的な問題である
- 検証区間が広がらなければ変更が積み上がり、信頼できるゲートなしに量だけを増やすと、低品質な PR と作り込まれた欠陥が生まれる
- モデル性能の向上が、生成と検証の間隔を自動的に縮めるわけではない
- 良いアーキテクチャの価値は、数秒や数分ではなく、数か月から数年にわたって現れる
- アーキテクチャの優秀さに対するきれいなコスト関数や即時の評価シグナルを計算するのは難しく、複雑な設計判断を良い事例として訓練することも難しい
再び明かりをつける方法
- 明るいファクトリーでも、エージェントが実装の大半を担当するが、誤った判断のコストが大きい地点では明かりをつけ、人が成果物を読んだうえでデプロイする
- 人間の判断は最後のコードレビューだけに付けるのではなく、エージェントがループを開始する前のプロダクト・設計・アーキテクチャ段階へ移すべきである
- 事前に 1 時間かけて 200 行の計画をレビューすれば、実装後に 2,000 行の生成コードを掘り返して設計判断を探す長いレビューを減らせる
- コストが大きく長く残る判断ほど、実装前に人が関与すべきであり、事前レビューをしていても必要なら diff を直接確認する
- セーフティネットは新しい手法ではなく、なじみのあるアーキテクチャの慣行で構成される
- 良い型とメソッドシグネチャにより、エラーをプロダクションではなくコンパイラで捕捉する
- テストの接合点（seam）を設け、振る舞いを固定し、変更を観察できるようにする
- 人とモデルのどちらも、必要なコードを簡単に見つけられるように配置する
- コールスタックを短く読みやすく保つ
- コンポーネント境界を明確にし、変更の影響範囲を制限する
- 依存性注入により構成要素を交換可能にする
- こうしたアーキテクチャは、自動コーディングエージェントのミスを安価でだましにくい方法で防ぐという第二の役割を果たす
- Claude Code や Codex のようなエージェントは、自身のハーネスやツール使用については強化学習されているが、長期的な保守性までは提供しない
- セーフティネットはモデルの外側に存在する必要があり、アーキテクチャへの投資は、より多くの自律性を安全に確保する手段になる
- 安全なインフラと組み合わせれば、一部の短く低リスクなループは無人で実行できる
- たとえば毎晩 GitHub Actions cron が、アンチパターン、lint 違反、不必要に optional になっている prop のうち正確に 1 つを直してコミットし、小さな PR を 1 つ開ける
- 認証システム、決済エンジン、公開 API 契約のように失敗コストが大きい対象は、人がシステム知識と判断でレビューすべきである
自動化の資格を得るループ
- ループが完全自動化されるには、検査が安価で頻繁に実行され、簡単にだませない基準に依存している必要がある
- 真偽を明確に返す判定器、型ゲート、プロパティベーステスト、実際の評価ルーブリックと組み合わせたレビューエージェントが該当する
- 判定は即時に出る必要があり、時間が経ってもドリフトしてはならない
- 完了状態を人間ではなく機械も証明できるとき、自動化できる
- 短いループは長いループより検証しやすい
- Dex の経験則によれば、エージェントは3〜10 ステップではうまく機能するが、20 ステップを超えると流れを失い始める
- コンテキストが蓄積するほど、エージェントが経路を外れる可能性は高まり、長いループは隅にエラーを隠す
- 誤った答えのコストが大きく、人間だけがそれを発見できるなら、明かりをつけるべきである
- テストでは捕捉できない微妙なプロダクションバグ、広い影響範囲、1 年以上の作業を左右する判断が該当する
- この場合、人間の注意力が実際のプロダクトであり、高価だが不可欠な資源である
- すべてのループを同じモードに設定すると、どちらも失敗する
- すべてを暗く運用すれば、数か月後にシステムを解体しなければならなくなるかもしれない
- すべてを明るく運用すれば、レビューが巨大なボトルネックになる
- 各ループでどの地点に明かりをつけるかを決めることが、核心的な技術である
ループを包むグラフとステートマシン
- エージェント作業は、有限ステートマシンや条件付きサービス呼び出しと呼ぶとしても、結局は有向グラフで構成される可能性が高い
- 各ノードは明示的なステップであり、ノード間のエッジは明示的な条件である
- すべてのコードは制御フローグラフとして表せるため、構造そのものは新しくない
- エージェントの自律性は、グラフ全体ではなく各ノードの内部に限定される
- 新しい試みは、フローチャートをなくし、モデルがツール呼び出しごとに経路を選び、自ら完了を宣言するようにしたことだった
- 古いコードベースとぶつかった後で制御フローを再び所有しようとする動きは、ループの周囲に従来のグラフを復元することに等しい
- バグ修正作業は、純粋なループとグラフでは異なる進み方をする
- 純粋なループでは、問題調査、コード変更、テストの選択と実行順序、再試行と完了判断を、進行中にすべて決める
- グラフでは、バグ再現または追加情報の要求、原因特定、修正、テスト、レビューをあらかじめ経路として定義する
- テスト失敗は修正ステップへ戻り、成功はレビューへ移動し、承認された場合にのみ完了する
- エージェントは各ノードの中で知的に振る舞うが、許可されていない経路へ逸脱することはできない
- グラフはバックプレッシャーを可視化した形である
- エージェントの自由の一部を手放す代わりに、必須の検査と、読める失敗地点を得る
- 実行が失敗したとき、どのノードが停止させたのかを特定できる
- 12-factor agents のアプローチのように、多くのエージェントシステムは「適切な地点に LLM ステップを混ぜた、ほとんど決定論的なコード」に近い
- LangGraph と LlamaIndex Workflows、Jerry Liu のエージェント上のハイブリッド作業フローグラフ、David Khourshid が結び付けたステートマシンとアクターモデルにも、同じパターンが現れている
- ここでのグラフは知識グラフではなく、作業フローと条件付きエッジをあらかじめ定義した有向グラフを意味する
人間は外側のループを所有する
- 人間はファクトリーから消えるのではなく、実行ラインから外側のループへ移る
- エージェントは、バグ調査、診断作成、修正実装、テスト実行、結果報告という内側のループを実行する
- エンジニアは、問題を正しい方法で解決しているかを判断し、診断と実装を検証し、変更を承認し、誤った結果に責任を負う
- 内側のループと外側のループの境界には、diff、テスト、ログ、それらをつなぐ短い解説のような証拠が置かれる
- 型、テストの接合点、評価ルーブリックを備えれば、変更ごとに多くの手作業をしなくてもエージェントの実行を監督できる
- エンジニアの位置は、生産ラインで変更を直接書く場所から、ラインを設計してゲートを守る場所へ移る
- モデルとハーネスは改善できるが、長期的に高くつく問題を識別する人間の判断まで自動化するのは難しい
- すべての作業空間を暗くして、人が何が進んでいるのか確認できず、照明スイッチすら見つけられない状態が最も危険である
まだコメントはありません。