スイスチーズモデルから考えるAIによるコードレビューがもたらす品質リスク

はじめに

AIネイティブ開発が主流になり、PRレビューの多くをAIに任せることが当たり前になってきました。コード規約違反の指摘、既知の脆弱性パターンの検出、既存コードとの一貫性チェック——こうした作業は、もはや人間が手作業で行うものではなくなりつつあります。

これは間違いなく生産性の向上です。しかし同時に、「レビューとは本来何をする行為だったのか」という本質的な理解が、現場から少しずつ薄れてきているようにも見えます。AIに任せられる部分だけが可視化され、それ以外の部分の輪郭がかえって曖昧になっているのではないでしょうか。本稿ではその構造を整理し、AIと人間がレビューにおいてどこを分担すべきかを考えます。

レビューは一つの機能ではなかった

「レビュー」という一つの言葉には、実は性質の異なる複数の機能が無自覚に同居していました。

• 正しさの検証：バグ、規約違反、設計原則からの逸脱を見つける
• 知識の伝播：コードを書いた本人以外がロジックを理解する過程そのもの
• 所有権の移転：個人の成果物からチームの成果物へ——「自分が書いた」から「我々が承認した」への転換
• 説明責任の所在の確定：何か問題が起きたときに「誰が見て通したか」という人間側のアカウンタビリティ
• 意思決定の記録：なぜその実装を選んだのかという文脈をコメントとして残す

これまでは、これら全てが「レビュー」という一つの作業の中に溶け込んでいました。だからこそ、レビューが形骸化しないよう運用されている限り、特に意識しなくても機能していたのです。

AIが代替したのは、ごく一部でしかない

AIが得意とし、実際に大きく代替しつつあるのは、上記のうちほぼ「正しさの検証」の部分だけです。構文エラー、既知のアンチパターン、規約違反、既存コードとの一貫性——これらは判定基準がある程度定まっている問いであり、AIとの相性が良い領域です。

一方で、残りの四つはそもそも「正しいかどうか」とは別の軸の問題です。特に「なぜその設計・実装を選んだのか」というトレードオフの妥当性は、複数ありえた選択肢の中からの文脈依存の判断であり、唯一の正解が存在しません。AIはコードそのものは読めても、その背後にあるビジネス要件や組織的な制約、過去の意思決定の経緯といった「文脈」までは持ち得ないため、原理的にこの領域には踏み込めないのです。

つまり、AIレビューが機械的にカバーしているのは、レビューが本来担っていた役割のほんの一面に過ぎません。にもかかわらず、AIの指摘に対応してマージするというフローだけを回していると、「なぜこの設計にしたのか」という方針や判断の共有が置き去りになりやすくなります。これは仕組みとして構造的に片手落ちになりがちだと言えるでしょう。

カバレッジの穴が重なってしまう危うさ

さらに厄介なのは、エンジニア側の意識の問題です。AIがレビューしている範囲と、人間が本来レビューすべき範囲——このカバレッジをお互いが意識していないと、抜け穴だらけのレビューになってしまいます。

安全工学には「スイスチーズモデル」という考え方があります。

複数の防御層があり、それぞれの穴の位置が異なるからこそ、重ねることで防御が成立する

しかし今起きているのは、その逆の現象ではないでしょうか。「AIが見てくれているはず」という思い込みと、「人間のレビュアーも大枠は見ているはず」という思い込みが、同じ穴の位置で重なってしまう。結果として、穴が相殺されずにそのまま貫通してしまうのです。

特に危険なのは、AIのapprove的な出力が一種の心理的な満足感を与えてしまうことです。「AIが通した」という事実が、本来人間が引き受けるべき「なぜこの実装なのか」の検証を省略してよい免罪符のように機能してしまうケースがあります。品質を上げるためのツールが、かえって品質低下のリスクを生む——このねじれこそが、本稿のタイトルに込めた「品質リスク」の正体です。

これからのレビューに求められること

AIが「正しさの検証」を担うようになった今、レビューの重心は「品質のダブルチェック」から、「AIが生成・指摘した内容に対して、人間が理解し、責任を引き受け、チームの合意として確定させる行為」へと移っていくべきだと考えられます。AIレビューの指摘を人間がどう判断するか、その判断プロセス自体が新しいレビューの実体になっていくのです。

実務的には、AIと人間の担当領域を暗黙のままにせず、明示的に切り分けることが現実的な一歩になります。

• AIレビューが担う領域：構文チェック、既知の脆弱性パターン、規約準拠、既存コードとの一貫性
• 人間レビューが必須の領域：設計判断の妥当性、代替案との比較検討、ビジネス要件との整合性、そして「承認した」という説明責任そのものの引き受け

具体的な仕組み化としては、以下のようなアプローチが考えられます。

1. PRテンプレートに「なぜこの実装にしたか」を書く欄を設け、人間の必須項目とする
2. AIによるコメントと人間によるコメントをUI上で明確に分離し、どちらの指摘かを常に意識できるようにする
3. チーム内で「AIが見る範囲・人間が見る範囲」の合意を明文化し、定期的に見直す

おわりに

AIによるコードレビューは、開発速度と一定の品質担保を大きく前進させました。しかしそれは「レビューが不要になった」ことを意味しません。むしろ、これまで無自覚に一括りにされていた複数の機能のうち、AIが代替できない部分——設計判断の妥当性検証と、それに対する人間の説明責任——が、これまで以上にくっきりと問われる時代になったということです。

AIと人間、それぞれのカバレッジを正しく認識し、意図的に運用する。それができて初めて、AIレビューは品質向上の武器になります。逆に言えば、そこを曖昧にしたまま「AIがレビューしているから大丈夫」と思い込むことこそが、最大の品質リスクなのかもしれません。

本稿についてのご質問・ご感想があれば、ぜひお気軽にお寄せください。

連絡先： contact@katatan.com