はじめに — いろんな記事を読んで思ったこと
AI時代の品質保証について、最近いろんな記事を読んでいます。
「AIが実装し、AIがテストし、最後は人間がレビューする」
「リスクの高い箇所は人間が重点的に確認する」
どちらも一見もっともらしいアプローチです。
ただ、AI中心の開発サイクルを実際に動かしていると、どうしても拭えない疑問があります。
人間がレビューすることで、追加で何が保証されるのか。
そして、その人間は見るべき箇所をどう特定し、どこまで確認できれば完了と言えるのか。
人間レビューの価値そのものを疑っているわけではありません。必要な場面があるなら、そこに人を配置すればよい。
問いたいのは、その「必要性」を役職や慣習ではなく、検証できる根拠で説明できているかどうかです。
前回：レビューは実際に終わらなかった
前回の記事『レビューの終わりとは何か — AIレビューの停止と品質の完了条件』では、家計簿アプリにHuman-on-Exceptionを適用した検証結果を紹介しました。
AIが実装し、別コンテキストのAIが独立してレビューを行う。
すると、確定レシートの親子合計不整合、カード明細の不適切な変更、カテゴリ削除の競合、修正後のロック順不一致など、実際の不具合につながる指摘が挙がりました。
しかし、指摘を修正すればコミット（head）が変わります。再レビューを走らせれば、また別の観点から指摘が出る。
結果としてレビューのサイクルは収束せず、統合headに対する必須検証も完了しませんでした。
最終的には時間とコストの制約からレビューを打ち切り、品質ゲートがpendingのままmainへマージしています。
ここは重要なので、前回の記事でも「マージしたこと」と「品質ゲートを通過したこと」は区別して記録しました。
その後、レビュー証拠の再利用や影響範囲判定の進め方を見直しましたが、「レビューの終了条件をどう定義するか」という根本問題は依然として残っています。
この経験を経て、さらなる疑問が浮かびました。
AIレビューが収束しないとき、最後に人間を挟めば本当に問題は解決するのでしょうか。
1日に100本のPRが来たら
仮に、AIによって1日に100本のPull Request（PR）が生成される開発現場を想像してみてください。
専任のレビュー担当者が1人いて、1日8時間の稼働すべてをレビューに注ぎ込めたとしても、1本にかけられる時間はわずか4.8分です。
現実には、変更意図の把握、影響範囲の調査、指摘後の再確認、各種ミーティングなどの周辺コストも発生します。
「100本すべてを精読する必要はない。リスクの高い領域に絞って人間が見ればいい」という意見もあるでしょう。
しかし、その「リスクの高い領域」は、一体誰がどうやって見分けるのでしょうか。
レビュー対象を選ぶこと自体がレビューになる
例えば、金額計算ロジックの変更を考えます。
リスクが潜んでいるのは、計算関数そのものだけとは限りません。
DBのカラム型定義、API境界での単位変換、共通の端数処理、割引と消費税の適用順序、さらには別経路からの呼び出しなど、影響は多岐にわたります。
人間がコードベース全体を調査して対象を選別するなら、その選定作業自体が実質的なレビュー工数となります。
かといって選定をAIに委ねるなら、AIが見落とした対象外領域の品質リスクをどう扱うかという問題が残ります。
さらに、リスク判定には二種類の誤りがあります。
- 本当は高リスクなのに、低リスクと判定する：重大な変更が人間レビューの対象から漏れる。
- 本当は低リスクなのに、高リスクと判定する：人間レビューの対象が増え、処理能力を圧迫する。
この二つは、同じ問題ではありません。
見落としを避けようとして高リスク判定を広げれば、人間のレビュー待ちが増えます。
逆に、レビュー工数を減らすために対象を絞れば、重要な変更を見逃す可能性を考慮しなければなりません。
もちろん、実際にどの程度の誤判定が起きるかは測定が必要です。
ただ、「リスクの高い箇所だけ人間が見る」という方式には、対象選定の精度と処理能力を両立させる設計が必要だということは分かります。
人間にレビューを集中させる前に、その振り分けをどう検証するのか。
ここを決めないままでは、単にボトルネックを別の場所へ移しているだけかもしれません。
閑話休題：人間がレビューしていた頃、品質は本当に担保されていたのか
ここで、少し昔の開発体制を振り返ってみます。
「AIのテストは信用できない」
「AI同士でレビューさせても同じ盲点にはまる」
「だから最後は人間が確認するべきだ」
そうした慎重論の背景は理解できます。
しかし、人間が実装し、人間がテストし、人間がレビューしていた時代、バグは本当に防げていたのでしょうか。
もちろん、人間がレビューしたコードでも、本番障害や不具合は発生していました。
人間のレビューにも見落としはあります。
それなのに、AIのレビューには検証能力の根拠を厳しく問い、人間のレビューについては「人間が確認した」という事実で完了を認めていないでしょうか。
あのExcelの単体テスト仕様書
かつてよく見かけた、何百行ものテスト項目が並び、実施率100%と記録され、レビュー印と日付が添えられたExcelの単体テスト仕様書。
あの「100%」は、突き詰めれば何の100%だったのでしょうか。
「事前に定義したチェックリストをすべて消化した」という意味での100%なら、重要な作業ログです。
しかしそれは、「想定すべき観点を100%網羅した」ことの証明ではありません。
期待値が要求仕様と合致しているか。記載から漏れた境界条件はないか。
承認者自身、どこまで踏み込んで確認できていたのでしょうか。
実施率100%。レビュー済み。承認済み。
その三つが揃っていても、テスト観点の抜け漏れはあり得ます。
それでも、私たちは一定の条件を満たした成果物を「テスト完了」として扱ってきました。
では、AIが同じ証拠を提出した場合、同じように完了と判断できるでしょうか。
過去のプロセスを無意味だったと言いたいのではありません。
人間が作成した成果物とAIが作成した成果物を、同じ基準で評価できているか。
気になっているのは、そこです。
もしかして、人間に期待しているのは別のレビューなのか
「人間がレビューする」という言葉の解釈にズレがあるのかもしれません。
関係者それぞれが、異なる種類の確認作業を想定している可能性があります。
レビューの役割を分解してみると、少なくとも以下の5つに分けられます。
- 製品の意味・要件判断：この振る舞いでユースケースを満たすか、受入基準を見直すべきかという仕様決定。
- アーキテクチャ：責務の分離、依存関係、将来の拡張性、インフラや運用制約との整合性の確認。
- 実装スタイル・保守性：命名規則、可読性、コードの重複排除、コーディング規約の遵守。
- 正しさ・安全性：不変条件の維持、認可制御、データ整合性、回帰の防止、テストケースの妥当性。
- 残余リスクの受容：未検証領域や既知の制約を把握したうえで、リリースを進める責任と権限の行使。
例えば、アーキテクチャレビューを考えてみます。
AIが実装したコードに対して、人間が「この責務はControllerではなくServiceに置くべきだ」と指摘したとします。
その指摘が既存の設計原則に基づくものなら、そもそも実装前にその原則をAIへ渡せなかったのでしょうか。
そして、実装時に守れなかったとしても、独立したAIレビューで検出できないのでしょうか。
一方、レビューの場で初めて「今後はServiceに責務を寄せる」という方針が決まったのなら、それは既存ルールへの違反を発見したというより、未決定だった設計方針を決めたことになります。
この二つは、同じレビューではありません。
もちろん、設計には明文化しきれないトレードオフがあります。将来の事業計画や運用上の制約など、コードだけを読んでも判断できない情報もあるでしょう。
そうした場合は、人間への相談や設計判断が必要になります。
ただし、その判断をすべてのPRの最終レビューという形で行う必要があるのかは、別の話です。
さらに、レビューで繰り返し指摘される内容があるなら、それは毎回人間が発見するしかないのでしょうか。
一度決まった設計方針をルールや受入条件として残し、次のAI実装と独立レビューに反映することも考えられます。
「人間にしかできない」と結論づける前に、少なくとも次の違いを整理したいところです。
- 仕様や設計方針が、まだ決まっていない
- 判断には、事業上の権限や責任が必要である
- 判断基準は決まっているが、AIの検証能力が不足している
最初の二つは、人間に判断を求める理由になり得ます。
三つ目なら、AIの検証精度をどう測り、どう改善するかという技術的な課題です。
人間がコードを書いていた時代には、これらの判断を同じ人がまとめて担うことも自然でした。
しかし、AI中心の開発でも、それらを全部「人間の最終レビュー」に詰め込む必要があるのでしょうか。
レビューが収束しないことと、品質が足りないことは同義か
ここで、前回の検証から持ち越している問題に戻ります。
レビューを打ち切る理由には、時間切れ、予算上限、規定回数への到達、担当者の承認などがあります。
しかし、これらは必ずしも品質水準を満たした証拠ではありません。
同様に、レビューで新たな指摘が挙がり続けている状態も、直ちにリリースを止めるべき重大な欠陥が存在することを意味しません。
実際の不具合なのか、設計上の改善提案なのか、仕様が未決定なのか、レビュー側の誤検出なのか。
指摘の内容を区別する必要があります。
人間が承認ボタンを押せば、ワークフローとしては完了します。
しかし、その承認が具体的に何を確認した結果なのかは、別に説明しなければなりません。
AIであれ人間であれ、未知のバグがゼロであることを事前に証明することはできません。
それでも開発をどこかで終わらせる以上、必要なのは「誰が承認したか」だけではなく、確認済みの範囲、必須テストの結果、未解決指摘の重大度、未確認事項、そして残余リスクの扱いです。
前回の実験では、その条件を十分に定義できませんでした。
だからこそ、レビューを止めた事実と、品質ゲートを通過した事実を分けて記録しています。
この区別を曖昧にしたまま、人間の承認だけを最後に追加しても、問題の本質は変わらないと思っています。
今のところの結論
AIがコードを書くようになっても、レビューという工程は残ります。
ただし、その工程に人間を配置する理由まで、以前のままでよいとは限りません。
バグを探すのか。設計を評価するのか。仕様を決めるのか。リスクを引き受けるのか。
それぞれ必要な証拠も、判断する主体も違います。
「最後は人間が見る」という一文で、それらをまとめてしまっていないでしょうか。
Human-on-Exceptionでも、影響範囲判定の信頼性とレビュー終了条件は未解決です。
次に検証したいのは、人間をレビューから外せるかどうかではありません。
人間が判断すべき例外を、どう定義し、どう検出するか。
その設計ができて初めて、レビューの処理能力と品質を同時に考えられるのだと思います。
人間がレビューしたから信用するのでも、AIがレビューしたから疑うのでもない。何を確かめ、何が残ったかで判断する。
※本稿は問題提起と設計上の仮説を整理したものです。1日100本のPRは説明用の仮定であり、実測値ではありません。記事の構成整理・推敲にはChatGPTを使用しました。実験の記述は前回記事で報告した範囲に基づきます。