生成AI時代のソフトウェアファクトリー：加速の裏に潜む「光と影」
出典：Addy Osmani「Software Factories, Light and Dark」
1. 半世紀以上前の夢が現実になるとき
1968年、計算機科学者のBob Bemerは論文「The economics of program production」で、ソフトウェアファクトリーという構想を提示しました。開発を個人の職人芸から、自動車部品をプレスするように反復可能で、工程を計測できる生産プロセスへと変えるものです。それから半世紀以上、アイデアを「型」に流し込むことの難しさもあり、この構想は一部の例外を除いて十分な成果を上げられませんでした。
しかし今、AIエージェントの台頭により、この古い夢が現実味を帯びています。「コードを書くこと」から「コードを書く工場を動かすこと」へと、開発の仕事の単位が変わりつつあるのです。
2. ループ、ハーネス、ファクトリーの3階層
Osmaniは、HumanLayerの共同創業者であるDex HorthyがAI Engineer World’s Fairで行った講演を紹介しながら、ソフトウェア工場を「ループ」「ハーネス」「ファクトリー」という3つの階層で整理しています。
- ループ：エージェントが「文脈収集、アクション、結果確認」を、所定の条件を満たすまで繰り返す最小の作業単位です。
-
ハーネス：ループを囲む環境と制約です。
サンドボックス、利用可能なツール、実行をまたいで維持されるメモリ、そして「完了」を判定するゲートを含みます。 - ファクトリー：ハーネスに包まれた複数のループがワークキューから課題を取り出し、変更をレビューゲート経由で本番環境へと送り出す仕組みです。
Osmaniは、この構造を「ループで構成された組織図」にたとえています。エンジニアの仕事の重心は、個別のコード修正から、ループやハーネス、それらの間の流れの設計へと移ります。エージェントに一回ずつ指示を与える作業を、指示と検証を繰り返すシステムの構築に置き換えるのです。
3. ダークファクトリーと理解負債
製造業には、照明を必要としないロボットが生産を担う無人工場があります。こうした工場はダークファクトリーと呼ばれます。原文では、日本のファナックが2001年から稼働させている工場や、中国のXiaomiが2024年に開設した工場が例として挙げられています。
ソフトウェアにおける「ダークファクトリー」とは、人間が生成されたコードを読まず、機械による検証だけでデプロイする仕組みを指します。人間のレビューを省けば、短期的には開発が大幅に速くなったように感じられるでしょう。しかし、コードが増える一方で、人間の理解が追いつかなくなります。この隔たりが広がることを理解負債（comprehension debt）と呼びます。
週末の趣味のプロジェクトであれば、コードの詳細を読まずに生成AIとやり取りするバイブコーディングで、目的を達成できるかもしれません。しかし、10年以上続くエンタープライズシステムを業務で維持する現場では、コードを理解せずに変更し続けると、問題の原因や影響範囲を追うことが難しくなります。テストが通っていても、中身を誰も理解していないシステムには、こうした保守上のリスクが残ります。
4. なぜ生成速度を上げても開発は速くならないのか
AIによってコードを生成しやすくなっても、開発プロセス全体が同じだけ速くなるとは限りません。人間の判断を伴うレビューゲートは、生成と同じようには処理能力を増やせないからです。
ここで問題になるのが、生成と検証の処理能力の差です。
- 生成：AIによって、大量の変更を短時間で作成できます。
- 検証：人間がレビューに使える時間や注意には限りがあります。
生成をいくら速めても、検証が追いつかなければ、未処理のプルリクエスト（PR）が積み上がります。Osmaniは、後段の検証能力に合わせて前段の生成を制御する考え方を、バックプレッシャー（背圧）として説明しています。ループに与える自律性も、低コストで信頼性高く検証できる範囲に収める必要があります。信頼できる検証の仕組みがないまま生成量を増やすと、不具合の流入も防ぎにくくなります。
5. グラフによるエージェントの制御
AIエージェントに自由に手順を選ばせるループは、複雑な既存のコードベース（ブラウンフィールド）で、処理が長引くほど方針を見失いやすくなります。Horthyは、エージェントが扱う範囲を3〜10ステップ程度、多くても20ステップ程度に絞ることを目安として示しています。蓄積する文脈を抑えて信頼性を保つための指針であり、特定のステップ数を超えれば必ず失敗するという限界を示したものではありません。
この対策の一つが、ループをあらかじめ定めたワークフローに組み込む方法です。各ステップをノード、ステップ間の遷移条件をエッジとして表すグラフで、処理の流れを明示的に定義します。
エージェントは各ノードの中で判断しますが、次に進む条件や必須の検証は、外側のプログラムが制御します。ソフトウェアをフローチャートで表してきたように、エージェントにも処理の流れを定める考え方です。
このアプローチでは、決定論的なコードを骨格とし、要所にLLMの処理を組み込みます。型やテスト、明確なコンポーネント境界といった従来の設計手法も、モデルの誤りを検出し、影響を抑える手段になります。
6. アウターループを担うエンジニア
ファクトリーが稼働し始めても、エンジニアの役割が消えるわけではありません。自動化する仕組みを設計し、その成果を確かめる役割が増していきます。
- インナーループ：エージェントが担う、バグの調査、調査結果の報告、修正の実装、テストの実行などの作業です。
- アウターループ：人間が担う、解決方針や実装の妥当性の判断、アーキテクチャの決定、変更の承認、結果に対する責任の引き受けです。
人間は、実装前の設計に加え、エージェントが提示する根拠（コードの差分、テスト結果、ログ）を基に判断します。たとえば、リント違反や、必須であるべきプロパティを省略可能にしている定義の修正は、検証方法が確立していれば、修正から小さなPRの作成までを自動化できます。ただし、PRの作成と、本番への反映までを全自動にすることは別の判断です。認証システム、課金処理、公開APIの契約など、誤りの影響が大きい領域では、人間が設計段階から判断に加わり、変更内容を確認する必要があります。
ライトスイッチをどこに置くか
生成AI時代のソフトウェア開発では、どこまでを全自動にし、どこに人間の判断を残すかが設計上の課題になります。人間の判断が必要な箇所に明かりを残すのが、ライトファクトリーという考え方です。
すべてを自動化してコードを読まなくなれば理解負債が増え、すべてを人間が細かく確認すればレビューが滞ります。エンジニアには、誤りの影響と検証のしやすさを見極め、ループごとに自動化の範囲を決める仕事が求められます。