「動いているから大丈夫」——そのレビューの基準は、本当に十分だろうか。
AI駆動開発では、コードを書く速度だけでなく、レビューで何を見るかも変わる。#1では見積もりの数字を、#2ではプロセスの向きを、#3では設計による予防を扱った。今回は、その予防をすり抜けてきたものを、レビューでどう検品するか、という話をする。
AI時代のレビューで「動くかどうか」以外に確認すべき観点と、発注者が品質保証の仕組みをどう確認すべきかがわかります。
先に断っておくと、この記事で扱うのは「すでに書かれたコードを、どう検品するか」という対症療法の話である。品質の多くは、本来レビューよりも手前の設計段階で、あらかじめ予防できていたはずのものだ（その「予防」については#3で扱った）。今回はその上で、対症療法であるレビュー自体が手薄になっていないかを見ていく。
リリース前の脆弱性診断や、外部のセキュリティ監査で指摘を受け、慌てて修正に追われた経験はないだろうか。「動作確認は済んでいたはずなのに、なぜ今頃」という感覚を持ったことは。
これは偶然ではないかもしれない。スタンフォード大学の研究（ACM CCS 2023）では、AIアシスタントを使った参加者は、使わなかった参加者より有意に安全でないコードを書いていた。さらに、AIを使った参加者ほど「自分は安全なコードを書けた」と信じる傾向が強く、過信につながっていた。特にSQLインジェクションや暗号化まわりで顕著だった。
開発時点の「動いた」というレビューを通過していても、それは安全性を確認したことにはならない。脆弱性診断という別の関門で初めて発覚し、そこから手戻りが発生する——このパターンが起きやすくなっているとしたら、それは開発チームの怠慢ではなく、レビューの基準そのものが「動くかどうか」に寄りすぎている可能性がある。
半年前に直したはずの不具合と同じようなものが、別の画面や別のモジュールでまた見つかった、という経験はないだろうか。「AIを使っているのに、なぜ横展開されていないのか」と感じたことは。
これは、AIの性能の問題ではなく、AIの動き方の性質による。AIコーディングツールは、依頼された範囲に対してその場でコードを生成する。過去に直した不具合を自動的に覚えていて、コードベース全体を探して同じパターンを直す、という動作は基本的には起きない。「このパターンを全体で確認して」と明示的に指示しない限り、同じ問題は他の場所に残ったままになる。
GitClearが2億行超のコード変更を分析した報告では、リファクタリング（共通化・一般化）に関わる変更の割合が2021年の25%から2024年には10%未満に低下し、コピペ（複製）コードの割合は逆に8.3%から12.3%に上昇していた。2024年は記録上初めて、コミット内のコピペが「移動（リファクタリング）」を上回った年になった。既存のロジックを一般化するより、その場で似たコードを新しく生成する傾向が強まっている、というデータだ。
つまり、不具合を「直したかどうか」だけを見ていると、同じ問題が他の場所に残っていることには気づけない。
AIが提案したライブラリやパッケージを、確認せずにそのまま導入したことはないだろうか。あとになって、そのパッケージが実在しない、あるいはほとんどメンテナンスされていないと分かった、という経験は。
テキサス大学サンアントニオ校などの研究では、16のLLMに57.6万件のコードを生成させたところ、多数の実在しないパッケージ名が提案された。さらに、同じプロンプトを10回繰り返すと、43%の架空名が毎回再出現した。この再現性の高さが問題を大きくする。
これは、AIが作り出した「ありそうで存在しないパッケージ名」を攻撃者が先に登録し、開発者に誤って導入させる手口だ。slopsquatting と呼ばれ、気づかずインストールしたチームにマルウェアが入り込むことになる。
つまり、コードのロジックをどれだけ丁寧にレビューしても、そこに使われている部品そのものが実在するか、信頼できるかは、また別に確認しないと分からない。
AI導入後、コードは増えているはずなのに、レビュー待ちのプルリクエストがどんどん溜まっていく、という感覚はないだろうか。レビュー担当者の人数は変わっていないのに。
AIが生成するコード量が増えることで、プルリクエストのレビュー時間が平均91%増加しているという分析がある。コードを書く速度は上がっても、それを確認する体制が同じ規模のままなら、いずれレビューが追いつかなくなる。
レビュー担当者が「動いているか」を確認するだけで手一杯になっているとしたら、1〜3章で見たセキュリティ、重複、依存パッケージの実在確認といった観点まで、手が回っているとは考えにくい。
レビューが追いつかない状態では、「動いたかどうか」を確認するだけで精一杯になり、本来レビューすべき観点から順番に抜け落ちていく。
品質を保証する仕組み自体が、AI導入前の設計のまま更新されていない可能性がある。
ここまでの4つの「あるある」に共通するのは、レビューが「動くかどうか」だけを見ていて、それ以外の観点が抜け落ちていることだ。発注する側が確認できることを整理する。
動作確認とセキュリティ確認は、同じ工程では担保できない。
「このパターンを全体で確認して」という指示を、誰かが明示的に出す仕組みになっているかを確認する。
AIが提案したパッケージ名を、そのまま信じて導入していないかを確認する。
品質保証のボトルネックになっていないかを把握し、レビュー体制の規模がコード量の増加に見合っているかを継続的に確認する。
品質とは、動くことではない。安全で、同じ問題を繰り返さず、正体のわかる部品でできていて、きちんと確認できる体制のもとで届けられていることだ。
AIはコードを書く速度を上げるかもしれない。だが、レビューが見ているものを増やさない限り、そのスピードは見えないリスクと引き換えになる。
ただし、ここまでの話はあくまで検品——すでに書かれてしまったコードへの対症療法だ。検品の観点をどれだけ増やしても、それは治療であって予防ではない。#3で見た設計による予防と、この記事で見た検品は、両輪として機能して初めて意味を持つ。どちらか一方だけでは、品質は守れない。
STVテックでは、AI導入において「見えなくなりがちな品質保証の仕組み」を可視化することを重視しています。
レビュー体制の設計段階から、不安や疑問を一緒に整理します。