TL;DR

AIが生み出すコード量は人間がレビューしきれる規模を超えつつある
「本番リリースしてよい」と判断する基準を、組織ごとに再設計する必要がある
筆者は、レビュー範囲別に4つの案(A:全自動 / B:テスト中心 / C:設計中心 / D:全コード)を整理し、現時点では B案(テスト中心レビュー) が最も現実的だと考えている

はじめに

AIの進化は目覚ましい。日々新機能が追加され、既存のSaaSにも急速に侵食している。

業務でAIを利用するなかで筆者が一番悩んだのは、「AIが書いたコードの信頼性を、どうやって担保するか」だった。本記事は、その問いに対して現時点で出した暫定的な答えをまとめたものである。

なお、本記事は筆者個人の意見であり、所属企業の見解を代表するものではない。

これまでのソフトウェア開発における品質担保は、おおむね次の二段構えだった。

それでも本番でバグが発生した場合は、PMが最終責任を負い、レビュアーとQAにヒアリングして再発防止を図る、というのが従来の運用である。

ところが、AI駆動開発の普及によって 1のレビュー工程が成り立たなくなりつつある。AIが生成するコード量は、人間が目視で追えるスケールを完全に超えている。レビューがボトルネックになるか、形骸化するかの二択になりつつあるのが実情だ。

そこで今後は、「本番リリースしてよい」と判断するための新しい指標が必要になる。筆者はそれを、人間がどこまでレビューに関与するか という軸で4段階に整理してみた。

AIにレビューとテスト実行を任せ、すべてのテストがパスしたら本番リリースする。
→ 現実的に成立するのは、個人開発プロジェクトに限られる。

AIにテスト計画・テスト設計を作成させ、テスト内容とテスト結果を人間がレビュー する。コードレベルのレビューはAIに委譲する。
→ 「何を確認したか」を人間が握る形。

B案に加え、設計方針やプロジェクト構成といった粒度でコードもレビュー する。詳細実装まで踏み込まない。
→ アーキテクチャの逸脱だけは人間が止める形。

C案に加え、AIが生成した全コードを人間がレビュー する。
→ 従来のレビュー文化をそのまま維持する形。

観点	A: 全自動	B: テスト中心	C: 設計+テスト	D: 全コード
安全性	×	△	◯	◎
スピード	◎	◯	△	×
個人開発	◎	◯	△	△
スタートアップ	△	◎	◯	△
高信頼性が求められる業界	×	△	◯	◎

補足:

ここまでの整理と、現状のAIの実力感を踏まえて、筆者は B案(テスト中心レビュー) が最も現実的だと考えている。理由は次の通り。

A案は時期尚早: AIだけで完結できる水準に達するには、もう少し時間がかかると見ている。少なくとも現時点では、人間によるテスト観点の妥当性確認なしに本番投入する勇気は出ない。
C・D案は過剰になりつつある: 現在のAIは、適切なプロンプトとガードレールがあればコードレベルでは十分な品質を出せる。詳細レビューに人間の時間を使うのはコストパフォーマンスが悪い。
テスト観点こそ人間が握るべき: 「何が正しい挙動か」を定義する作業は、ビジネス文脈を理解している人間にしかできない。ここを人間の主戦場にする方が筋が良い。

信頼性の担保ラインは、企業や業種によって大きく異なる。重要なのは、自社にとって過小でも過剰でもない地点を意識的に選ぶこと だと考えている。

そして、AIの進化スピードを踏まえれば、この最適解は数年単位で動く。「A案でも回る」状態になったタイミングで、フットワーク軽く移行できる組織が強くなるはずだ。