AIによるソフトウェア開発の自動化は、かつてないスピードで進化しています。アトラシアンが発表したJiraの最新機能では、AIが自動的に要件定義を作成し、タスクを切り出し、それをClaude CodeやGitHub Copilotといった外部のAIエージェントへ自動でアサインする環境が整いつつあります。これはいわば、人間が介在しない「消灯ソフトウェアファクトリー（Lights-off Software Factory）」の実現に向けた大きな一歩に見えます。

しかし、本当に人間はコードを読まず、レビューもせず、AIにすべてを任せてしまって良いのでしょうか？

本記事では、HumanLayer社のDex氏による考察「Why Software Factories Fail（ソフトウェアファクトリーが失敗する理由）」をベースに、AI駆動開発の光と影、そしてコードベースを崩壊させずにAIの恩恵を最大化するための現実的なアプローチを探ります。

AI駆動開発がもたらした「バグとインシデントの急増」

「AIモデルは十分に賢くなった。コードは無料だ。人間はボトルネックだから、開発プロセスから排除してしまおう」

このようなナラティブのもと、多くの企業がAIエージェントによる開発ループ（Loop Engineering）の自動化を試みてきました。

しかし、現実はそれほど甘くありません。Faros AIが発表したレポートによると、開発者がAIコーディングツールを本格的に導入し始めて以降、以下のような深刻な兆候が見られています。

• プルリクエスト（PR）のレビュー品質の低下（レビューなしでマージされるPRの増加）
• インシデントの急増
• 開発者あたりのバグ発生数の増加

完全に自動化された「消灯ソフトウェアファクトリー」を試験的に導入したチームも、数ヶ月後には「AIではどうしても解決できない複雑なバグ」に直面し、最終的には人間が数ヶ月間放置されたスパゲッティコード（いわゆるAI Slop）を解きほぐすために、多大な時間を費やす羽目になっています。

なぜAIはコードベースの「保守性」を破壊するのか？

モデルの性能は日々向上しており、ベンチマークテストのスコアも上がっています。それにもかかわらず、なぜAIが書くコードは時間が経つにつれてメンテナンスしづらくなるのでしょうか？

その理由は、AIモデルの強化学習（RL）の評価構造にあります。

AI codingのベンチマーク（SWE-benchなど）や強化学習における報酬（スコア）は、主に**「テストが通過したか（Pass/Fail）」**という一次元的な基準で測定されます。

• FAIL_TO_PASS: 課された課題（バグ）を修正できたか？
• PASS_TO_PASS: 既存のテストを壊していないか？

モデルがどうやってその結果を達成したか（コードの設計が美しいか、将来的に拡張しやすいか）は評価されません。その結果、モデルは「テストを通すためだけ」に、以下のような安易な修正を行うよう学習してしまいます。

• すべての処理を無差別にtry-catchで囲む
• 型システムを無効化するような適当なキャスト（anyなど）を多用する
• コードのコピペによる重複を増やす（いわゆる「散弾銃の手術/Shotgun Surgery」の原因を作る）

テストの実行結果は数秒でフィードバックされますが、悪い設計のコスト（技術負債）は数週間、数ヶ月、あるいは数年後にしか顕在化しません。 保守性（Maintainability）には高速なフィードバックループ（オラクル）が存在しないため、今日のAIモデルに「綺麗なコード設計」を自律的に維持させることは極めて困難なのです。

対策：「灯りを再び灯す」ための4つの協調ステップ

では、AIを使った高速開発を諦めるべきなのでしょうか？ 答えは「No」です。100倍の速度で爆走して自滅するのではなく、人間が適切に関与することで「安全に2〜3倍の速度」を維持することが可能です。

そのためには、開発のプロセスに人間が介在するプランニングと設計のフェーズを組み込みます。

1. プロダクトレビュー (Product Requirements)

まずは「何を、なぜ作るのか」を言語化し、すり合わせます。ユーザーのペインや成功の定義を明確にし、必要に応じてラフなHTMLモックアップを作成します。技術的な詳細に踏み込む前に、人間同士（またはAIと人間）で意図をアラインさせます。

2. システムアーキテクチャ (System Architecture)

サービス、エンドポイントの形状、データベースのスキーマがどのように相互作用するかを定義します。Mermaidなどのシーケンス図を活用し、高レベルな構造で合意します。

3. プログラム設計 (Program Design)

AIが最も脱線しやすいのがこのフェーズです。実装に入る前に、具体的な「コードの形状」を決めます。

• コールスタックツリーやファイルツリーの差分を疑似コードで表現する
• 主要な関数の型定義とメソッドシグネチャを事前に記述する

これにより、コードレビューという「最も修正コストが高い段階」で設計の誤りに気づくのを防ぎます。

4. 垂直スライス (Vertical Slices)

AIはデータベースからフロントエンドまでを一気に作る「水平方向の計画」を好みますが、これはテストや軌道修正を困難にします。APIモックの作成、フロントエンドの統合、データベースの接続といった形で、動作確認可能な「垂直スライス（Tracer Bullets）」ごとに段階的に開発とレビューを進めます。

まとめ：制約を受け入れ、賢くAIと共存する

Jiraなどのツールがタスクの切り出しやアサインを自動化してくれる未来は非常に魅力的です。しかし、その背後にある**「AIはコードベースの品質を維持できない」という根本的な制約**を忘れてはなりません。

現代のエンジニアに求められるのは、AIに丸投げすることではなく、設計段階で適切なコンテキストを提供し、生成されたコードの品質に責任を持つことです。

「コードを読む」という基本に立ち返りつつ、AIを強力なパートナーとして手綱を握り続けましょう。