AIのコードは「動きそうに見える度」が異常に高い。人間の粗いコードより読み味が良いぶん、レビューの警戒心が下がるのが罠
人間のミスとAIのミスは分布が違う。AI向けのレビュー観点に切り替える必要がある
5つの技法:存在確認、境界を突く、「なぜ」を聞く、動かして確かめる、削れるか聞く

はじめに

AIが生成したコードのレビュー、していますか?

「している」と答えたあなた。では正直に聞きます。diffが500行あって、テストが通っていて、見た目がきれいだったとき、全行読みましたか?

……はい。私も読み飛ばしたことがあります。そしてそのうちの1回は本番でやらかしました。この記事は、その反省文を技術記事の形に偽装したものです(※偽装は冗談ですが反省は本物です)。

なぜAIコードのレビューは難しいのか

人間の書いた怪しいコードには「怪しい見た目」があります。変な変数名、コメントアウトの残骸、迷いの跡。レビュアーはその匂いで警戒レベルを上げます。

AIのコードには匂いがありません。命名は綺麗、コメントは丁寧、構造は整然。内容が間違っているときですら整然としています。ここが最大の罠です。

なぜそうなるのか。LLMは「正しい続き」ではなく「もっともらしい続き」を生成するように訓練されているからです。もっともらしさと正しさはかなり相関しますが、同一ではありません。そして重要なのは、間違えるときも「もっともらしさの最適化」は働き続けることです。人間は自信がないコードを書くと見た目にも自信のなさが滲みますが、AIの出力には「自信度メーター」が付いていません。正解も間違いも同じ堂々としたフォントで出てきます。

人間のミスとAIのミスは分布が違います。

観点	人間がやりがちなミス	AIがやりがちなミス
タイポ・構文	ある	ほぼない
存在しないAPIを呼ぶ	稀	ある(堂々と)
要件の誤解	質問してくる	質問せず補完する
エッジケース	面倒がって省く	それっぽく書くが的外れなことがある
過剰実装	稀(面倒だから)	頻繁(面倒じゃないから)

人間用のレビュー観点のままだと、AI特有のミスがすり抜けます。以下、AI向けに調整した5つの技法です。

技法1:存在確認〜そのAPI、実在しますか?

AIは、あったら便利そうなAPIを発明することがあります。pandas.read_excel_fast() とか、実在するライブラリの実在しないオプションとか。ハルシネーションというやつです。

厄介なのは、発明されたAPIは「いかにもありそう」な名前をしていることです。ライブラリ作者が「次のバージョンで実装しようかな」と思うレベルの自然さで生えてきます。

チェック方法:

見慣れないメソッド・オプションは公式ドキュメントかソースで実在確認
特にマイナーライブラリ、最近のバージョンで変わったAPI、言語をまたいだ移植で頻発
IDEの型チェックやビルドを必ず通す(型が守ってくれる言語では大幅にラク)

冒頭で触れた私の本番やらかしは、まさにこれでした。AIが書いたHTTPクライアントのリトライ処理、テストはモックで全部通っていたのですが、リトライ回数の設定がそのライブラリに存在しないオプション名で指定されていました。存在しないオプションは黙って無視される仕様だったため、リトライは一度も動いておらず、気づいたのは本番で外部APIが不安定になった日です。型もテストも「未知のオプションを無視する動的な設定オブジェクト」は守ってくれませんでした。ドキュメントを見に行く30秒をケチった代償です。

技法2:境界を突く〜きれいな正常系の裏を見る

AIは正常系を美しく書きます。問題は境界です。

空配列を渡したら?
0件だったら? 100万件だったら?
同時に2回呼ばれたら?
ネットワークが途中で切れたら?

AIも聞けばこれらを考慮できます。つまり、抜けているとしたら指示時点で誰も要求しなかったからです。レビューで見つけたら、コードを直すのと同時に「次からプロンプトに境界条件を書く」という学びを持ち帰りましょう。バグは直して、原因(自分の指示)も直す。二度おいしい。

技法3:「なぜ」を聞く〜説明させると分かる

AIの便利なところは、レビュー対象の作者にその場で無限に質問できることです。人間の同僚に20個質問したら嫌われますが、AIは何個聞いても文句を言いません(たぶん)。

有効な質問:

「この実装を選んだ理由は? 他に検討した選択肢は?」
「この行を消したら何が壊れる?」
「この変更で影響を受ける既存機能は?」

回答が具体的で一貫していれば安心材料。回答がふわっとしてきたら、そこが怪しい場所です。人間の設計レビューと同じで、「えっと、それは、念のためと言いますか」ゾーンにバグは住んでいます。

技法4:動かして確かめる〜「テスト通りました」を信じすぎない

「テストが通った」には2つの罠があります。

そのテストもAIが書いた:実装に合わせたテストを書いていれば、間違った実装も通ります。答案を書いた人が採点基準も書いている状態です。自己採点、無敵。
テストが検証していない:アサーションが緩い、モックだらけで実質何も動いていない、など。

対策はシンプルで、実際に動かして目で見ること。UIなら触る、APIなら叩く、バッチなら流す。E2Eで1回本物を動かす価値は、モックテスト100本に勝ることがあります。

AIに「実際に起動して、この操作をして、結果を貼って」と頼むのも有効です。出力ログという動かぬ証拠を出させましょう。

技法5:削れるか聞く〜過剰実装を刈る

AIは頼んでいない機能を善意で付けてきます。設定オプション、抽象化レイヤー、「将来の拡張性のため」のインターフェース。人間なら面倒でやらない過剰設計を、AIは疲れないのでやります。勤勉さが仇になる稀有な例です。

レビュー時の呪文:

「この変更、要件を満たす最小限まで削るとどうなる? 削れる部分を挙げて」

すると本人がスラスラと削減案を出してきます。最初からやってくれ、と思いますが、聞かれなければ盛るのが彼らの仕様です。飲み会の幹事が聞かれる前からコース料理を大盛りにしてくるようなものだと思って、こちらから「小盛りで」と言いましょう。

5つの技法をつなぐ判定フロー

技法を個別に覚えるより、レビューの流れとして体に入れるほうが実用的です。私は毎回このフローで捌いています。

入口の「分量チェック」が最初に来るのがミソです。読み切れない分量を前に技法1〜5を頑張っても、集中力が先に尽きます。分割の目安は1回200行。人間のPRレビューで集中力が持つ限界と同じです。

この5技法でも防げないもの

正直に書いておくと、この技法群にも守備範囲があります。

ドメイン知識の誤り:「消費税の端数処理は切り捨て」のような業務ルールの間違いは、コードがどれだけ整っていても、レビュアー自身がルールを知らなければ見抜けません。ここは仕様書とドメインエキスパートの出番です
セキュリティの深い問題:認可の抜けやインジェクション耐性は、汎用レビューではなく専用の観点・ツール(SAST等)を別途通すべき領域です
全部やるとコストが高い:5技法フルコースは1レビュー15〜30分かかります。使い捨ての集計スクリプトなら「動かして確かめる」だけで十分。本番の決済コードならフルコース+人間2人目。リスクに応じて濃淡をつけるのが持続のコツです

つまりこの技法は「AI特有のミス分布に合わせた第一関門」であって、従来のレビュー観点やセキュリティレビューを置き換えるものではありません。

レビュー観点チェックリスト(コピペ用)

## AI成果物レビュー
- [ ] 見慣れないAPI・オプションの実在確認をした
- [ ] 境界条件(空・0件・大量・並行・異常系)を確認した
- [ ] 実装理由を質問し、回答の一貫性を確認した
- [ ] テストの中身(アサーションの実効性)を見た
- [ ] 実際に動かした(または動作ログを出させた)
- [ ] 過剰実装がないか「削れるか」を質問した
- [ ] diff全体を読んだ(読める分量に分割させた)

最後の項目が実は一番大事です。レビューできない分量の変更は、分割して出し直させる。人間のPRと同じルールをAIにも適用しましょう。AIは「500行は多いので分けてください」と言っても傷つきません。人間に言うより気楽です。

まとめ

AIコードは見た目の完成度が高いぶん、レビューの警戒心が下がる。綺麗さと正しさは別物
人間と違うミス分布(実在しないAPI・無断の要件補完・過剰実装)に観点を合わせる
作者に無限に質問できるのはAIレビューの特権。使い倒す

レビュー力は、AI時代に価値が下がるどころか最も価値の上がるスキルだと私は思っています。書く速度が100倍になった世界では、読む力がボトルネックです。つまり、みなさんが今まで磨いてきたレビュー筋は無駄になりません。むしろ大胸筋より鍛える価値があります(※個人の見解です。大胸筋も大事です)。

「私も過去にやらかしました」