AI駆動開発を「変更を扱う分散システム」として考える――PR単体の品質管理から、変更Control Planeへ

AI駆動開発の現場では不思議なことが起きる。個々のプルリクエストはすべてテストを通し、レビューも終わっているのに、統合してみると機能が壊れる。別のコミッターがmainに変更を入れたその直後に、以前追加したガード条件が消えている。マージコンフリクトを解消した結果、必要なテストまで失われている。つまり、PR単体の品質管理では、複数の変更が絡み合ったときの整合性を見落とす。一つの機能を完成させるには、コード変更だけでなく、DB schema、API仕様、生成コード、フィーチャーフラグ、マイグレーション、ロールアウト手順など、複数の変更が依存し合っている。それらが別々のタイミングで、別々のレビューを経てmainに入り、途中で前提が変わる。

こう考えると、AI駆動開発で管理すべきは「PRの本数」ではなく、「複数の変更がどの順番と条件で一つの機能として成立するか」という流れそのものだ。分散システムの用語を借りると、DB schema追加→バックエンド対応→API変更→クライアント生成→UI対応というのは、単なるタスク列ではなく「因果順序」である。その途中の状態も安全に通過できる必要がある。さらに、バックエンドのデプロイには成功したがフロントエンドは失敗した、というような部分失敗も起きる。AIで実装速度が上がるほど、こうした複雑性は増す。

中小企業のシステム開発でも同じ話が出始めている。「AIで機能は速く作れるようになったが、それらをどう組み合わせるか」という課題だ。個別の機能は正しくても、全体を通すプロセスの設計がないと、あちこちに齟齬が生まれる。これはもはや、コード品質の問題ではなく、組織設計の問題である。