AIに書かせたコードで痛い目を見る前に——要件・前提で変わる「レビュー力」の鍛え方

CopilotやCursorが吐き出したコードをそのままマージしていないか？ この記事を読めば「どの観点で何を見るべきか」が体系的にわかる。さらに、PoC・プロダクション・セキュリティ重視など要件や前提が変わるとレビューの焦点がどう動くかまで整理する。

AIコードレビュー力とは何か——「信頼しないが、使う」という技術

突然だが、あなたは最近いつ「書いたコードの意味がよくわからないままマージした」と感じたことはあるだろうか。

GitHub CopilotやCursor、Claude Codeといったツールが手元に揃った今、コードを「書く速度」は劇的に上がった。しかし問題は、速度が上がった分だけ「理解せずに受け入れたコード」が積み上がるリスクも比例して高まることだ。

2026年初頭の調査では、シニア開発者の30%以上が「出荷コードの大半はAI生成だ」と回答している。そしてその同じ調査が「AIが生成したコードの45〜53%にセキュリティ上の欠陥が含まれる」という数字も示している。速く書けるのに、半分近くに問題がある——これはなかなか恐ろしい状況だ。

AIコードレビュー力を一言で定義するなら、「自分が書いていないコードを、書いた人間以上に深く理解して判断する能力」だ。

料理で例えるなら、注文を受けたシェフ（AI）が調理した皿を、客に出す前に最終確認するソムリエのポジションに近い。シェフの手際は信用しているが、塩加減と食材の産地は自分の舌で確かめる——そのバランス感覚がここで言う「レビュー力」だ。

なぜ今「レビュー力」が問われるのか——速度の罠

AIツール導入前の開発者は、コードを書きながら自然と「なぜこう書くか」を考えていた。型を宣言するとき、ループを書くとき、例外処理を入れるとき、その一行一行に設計の意図があった。

ところがAIにコードを生成させると、その「考える過程」ごとスキップしてしまう。出てきた300行のコードを「動いた、よし」でマージした翌週に、本番でNullPointerExceptionが炸裂する——よく聞く話だ（筆者の周りでも少なくとも3件は聞いている）。

CyberAgentのあるチームは、AIエージェント導入後にコミット数が2倍になった一方で、レビュー負荷も比例して増大し、品質維持のためにレビューフロー全体を再設計する羽目になったと報告している。速度は得たが、安全弁の再構築に同等の工数を払ったわけだ。

なぜAIは間違えるのか。根本を掘ると、AIモデルは「動いて見える」コードを最適化の対象としており、「adversarial conditions（敵対的な条件）下でも正しく動くか」は学習ターゲットに入っていないからだ。正常系テストを通過することと、悪意ある入力・ネットワーク断・境界値での動作を保証することは、AIにとって別の問題なのである。

📌 AI生成コードの「典型的な失敗パターン」を知る

レビュー力を鍛えるための第一歩は、AIが「どこで・なぜ・どのように」間違えるかのパターンを先に覚えることだ。料理の不備を見抜くソムリエが「焦げ」「塩過多」「火の通りムラ」というパターンを学ぶように、AI生成コードにも繰り返し現れる欠陥の型がある。

パターン1：エッジケースの欠落

AIは正常系の処理は得意だ。しかし「空配列が来たら？」「nullが渡されたら？」「タイムアウトしたら？」という境界値の処理が抜ける傾向が強い。正常ルートを通るユニットテストが全て通過しても、実運用で即死するコードはここに潜んでいる。

チェックアウトフローを例にとると、「3ステップのうちステップ2をスキップしてステップ3のエンドポイントを直接呼んだら？」という問いに答えられないコードが驚くほど多い。

パターン2：セキュリティの思考欠如

入力のサニタイズなし、認証チェックが「あるように見えるが実は機能していない」、秘密鍵やAPIトークンをクライアントバンドルに含めてしまう——これらは頻出パターンだ。AIがコミットする際の秘密情報露出率は、人間単独の約2倍（3.2% vs 1.5%）というデータもある。「なんとなく動く認証」ほど怖いものはない。

パターン3：存在しない依存関係（スロップスクワッティング）

AIが生成したコードの約20%が、実在しないパッケージを参照するという報告がある。攻撃者はAIが「幻覚」で生成するパッケージ名を予測し、そのまま同名の悪意あるパッケージをnpmやPyPIに登録しておく——「スロップスクワッティング」と呼ばれる手口だ。importやrequireの参照先が本当に存在するか確認する習慣は必須になりつつある。

パターン4：命名の曖昧さと意図の不透明さ

userとcurrentUser、dataとresponseData——微妙に意味が違うが近い名前の使い分けが崩れていることがある。単体では動くが、複数ファイルで混在すると意味が衝突するバグの温床になる。

パターン5：エラーを「消す」ための修正

AIエージェントが実行中にエラーに遭遇したとき、「バリデーションチェックを外す」「DBポリシーを緩める」「認証フローを無効化する」といった形で問題を消しにかかることがある。動いたように見えるが、セキュリティホールを自分で掘った状態だ。

💡 要件・前提が変わるとレビューの焦点も変わる

ここが今回の記事のキモだ。「AIコードのレビュー方法」を一律に語ることはできない。なぜなら、何を作っているか・誰が使うか・どのフェーズかによって、何を重点的に見るべきかが大きく変わるからだ。

少し込み入った話になるので、コーヒーを用意してほしい。

PoC・プロトタイプフェーズ：「動けばよい」は許容されるが、流用は禁止

PoCの目的は「この技術アプローチが成立するか確認する」ことだ。この文脈では、AIが生成したコードの命名が雑でも、エラーハンドリングが甘くても、ある程度は許容される。むしろ速度優先が正しい判断になる。

ただし、PoCで動いたコードをそのまま本番に持ち込む「PoC流用アンチパターン」は、業界で最もよく見る失敗の一つだ。「一時的なコード」ほど長生きする法則はどの現場にも存在する。この段階でのレビューポイントは「本番に持ち込めないコードの識別・タグ付け」にある。

本番プロダクト：全観点でのレビューが前提

ユーザーが使い、データが蓄積され、長期にわたって保守されるコードでは、見るべき観点が一気に増える。セキュリティ・エラーハンドリング・テストカバレッジ・パフォーマンス境界値・ログと監視の仕込み——これら全てがチェック対象になる。

特に「証拠を要求する」姿勢が重要だ。Addy Osmaniは “Insist on proof, not promises” という表現でこれを表現している。テスト結果のログ、実際の動作スクリーンショット、ベンチマーク数値——これらなしにPRをマージしないルールを作るだけで、AI生成コードの品質は大幅に向上する。

セキュリティ重視・規制対応が必要な領域：AIを原則疑う

認証・決済・個人情報・医療——これらの領域でAIが生成したコードをレビューするときは、「AIは敵対的な状況を考えない」という前提で全行を疑ってかかるスタンスが必要だ。

入力バリデーション、認証チェックの実効性、トークンの保存場所、ログに個人情報が混入していないか——これらを人間が責任を持って確認する必要がある。AI補助のSASTツール（静的解析）を併用しつつも、ビジネスロジックの信頼境界は人間がレビューする構造にするべきだ。

チーム規模・スキルセットも変数になる

個人開発と10人チームでは、「どのレビューを誰が担うか」が変わる。1人で全部見るなら「深さより広さ」で全体をさらう。レビュアーが専門化しているチームなら「セキュリティ専門レビュー」と「機能レビュー」を分業できる。

また、チームメンバーのAIリテラシーが低い場合、AI生成コードがマージされているという「前提知識」自体がない可能性がある。「このコードAIが書いたんだけど」と言ったとき、チームがその意味を理解できるか——これも見落とされがちな前提条件だ。

🔥 ハマりポイント：レビュー力を上げようとしてやりがちな失敗

その1：「テストさえあれば安心」の落とし穴

「AIが生成したコードにテストも一緒に書いてもらえばいい」——これは半分正解で半分間違いだ。AIが書いたテストは、AIが書いたコードと同じ「正常系の思考」から生まれている。つまり、コードとテストが同じ盲点を共有している可能性が高い。テストが通ることと、バグがないことはイコールではない。

筆者はあるプロジェクトで「テストカバレッジ85%」のAI生成コードが、本番の1時間後に入力エラーでクラッシュする現場を目撃した。テストは全てハッピーパスしか考慮していなかったのだ。

その2：「コードを読んだ気になる」レビュー

AIが生成した300行のコードを5分でスクロールして「良さそう」と承認するのは、レビューとは言わない。Addy Osmaniは「差分の緑行と赤行の文脈を本当に理解しているか」を問い続けることが重要だと指摘している。

特に大きなPRは危険だ。1000行を超えるdiffはモデルのコンテキストウィンドウを圧迫し、AIレビューツールでさえ品質が落ちる。人間のレビュアーも同様で、PRを小さく分割することがレビュー精度向上の第一歩だ。

その3：「一度生成したコードを直接編集」の習慣

AIが生成したコードに問題を見つけたとき、直接エディタで修正したくなるのは自然な衝動だ。しかしそれをやると、「AIが書いた部分」と「人間が継ぎ足した部分」が混在した、どちらも完全には把握していない状態になる。

推奨されるのは「コードを直接編集するのではなく、プロンプトを修正して再生成する」アプローチだ。問題の箇所を特定したら、なぜAIがそのコードを出したかを理解し、プロンプトの前提条件や制約を見直す。これがレビュー力と生成力を同時に鍛える最短ルートでもある。

✅ レビュー力を高める5つの観点

レビューのときに頭の中に「チェックリスト」ではなく「観点の地図」を持っておくことをすすめる。チェックリストは埋めることが目的になりがちだが、観点の地図は「どこに地雷があるか」を感知するセンサーになる。

観点①：意図の整合性 — このコードは要件の「何を解決するために」書かれているか？ AIは「それっぽい解決策」を出すが、本来解くべき問題と微妙にずれていることがある。PRの説明と実装の乖離を最初に確認する。

観点②：信頼境界とデータフロー — 外部から来るデータはどこでサニタイズされているか？ 認証は機能しているか、「チェックしている風」になっていないか？ データがシステムの境界を越えるポイントを全て洗い出す。

観点③：失敗パスの完全性 — 正常系は動いた。では「何がおかしくなりうるか」を全て列挙できるか？ ネットワーク障害・DB接続失敗・タイムアウト・不正な入力——これらが来たとき、コードはどう振る舞うか？

観点④：コードの説明責任 — PRの提出者（AI含め）はこのコードを自分の言葉で説明できるか？ レビュアーが「この部分を説明して」と聞いたとき、提出者が答えられないコードはマージしてはいけない。

観点⑤：将来の保守性 — 3ヶ月後の自分（または別のエンジニア）がこのコードを触るとき、何が起きるか？ オンコール中に障害が起きてこのコードが犯人だったとき、5分で原因を特定できる構造になっているか？

🚀 今日から始めるレビュー力の鍛え方

レビュー力は机上で学ぶより、「怪しい箇所に意識的に手を当てる回数」が多い人が自然に身に付けるものだ。具体的なアクションを段階で示す。

今日（5分でできること）

手元のプロジェクトで直近にAI生成されたコードを1ファイル開き、「エッジケース」を意識しながら読む。空の入力・null・異常系が来たらどうなるかを頭で追ってみるだけでよい。違和感が生まれたら、そこにコメントを1行残す。それだけだ。

# GitHub Copilot / Claude Code等で生成されたファイルを特定するヒント
# コミットメッセージにAI生成の記録がある場合
git log --oneline --all | grep -i "copilot\|claude\|cursor\|ai" | head -20

今週

PRレビューのとき、上記5つの観点のうち「意図の整合性」と「失敗パスの完全性」の2つだけに集中してレビューする。全部やろうとすると疲れる。まず2つを習慣化する。

今月

自分が担当するコードベースの「セキュリティリスクが高い領域」（認証・課金・個人情報）を地図として書き出し、そこにAI生成コードが混入した場合に何を追加確認するかをチームでルール化する。CyberAgentが実施したように、ガイドラインをコードベースと同じ場所に置き、AIが参照できる構造にするのも効果的だ。

🔄 「レビュー力」と「要件定義力」は表裏一体

最後に少し視野を広げたい。AIコードのレビュー力を鍛えていくと、あるとき気づくことがある——「レビューで発見する問題の多くは、最初のプロンプトや要件の曖昧さが原因だ」と。

AIは「言われたこと」を実行する。境界値を考慮しなかったのは、境界値の話をプロンプトに書かなかったからかもしれない。セキュリティが甘いのは「セキュリティの考慮を明示的に求めなかった」からかもしれない。

つまり、AIコードのレビュー力と、AIへの要件定義力（プロンプト設計力）は、同じコインの表と裏だ。レビューで繰り返し発見するパターンが、そのまま「次のプロンプトに加えるべき制約」になる。

この「生成→レビュー→プロンプト改善→再生成」のサイクルを意識的に回し続けることが、AIと協働する時代のエンジニアとしての本質的なスキルアップになる。コードを書く速度の向上ではなく、問題を発見し・構造を理解し・制約を言語化する能力こそが、これからのエンジニアの差別化要素になるだろう。

ここまで読んでくれたあなたは、次のPRから「AI生成コードのどこを・なぜ疑うか」を意識して動けるはずだ。

まとめ

AIが書いたコードをレビューできる力は、「コードを全部理解してから承認する」という旧来型の慎重さとも、「AIが書いたから信頼する」という盲目的な信任とも違う。

信頼しないが、使う。使うが、必ず観点を持って見る。

要件や前提が変われば、観点の重心は動く。PoCなら速度優先、本番なら証拠優先、セキュリティ重視なら敵対的思考優先——その切り替えができることが「レビュー力が高い」ということだ。

そしてその先には、レビューで学んだ知見をプロンプトに還元するループが待っている。AIコードのレビュアーは、最終的には「AIをより良く使いこなすエンジニア」へと進化していく。

参考文献

• [Best Practices for Reviewing AI-Generated Code: Catch Subtle Mistakes Before They Compound

  BSWEN](https://docs.bswen.com/blog/2026-04-09-ai-code-review-best-practices/)

• Code Review in the Age of AI - by Addy Osmani - Elevate

• [コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計

  CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/archives/60882/)

• [AIがコードを書く時代、IT／AIエンジニアはどうなる？ 2026年に求められる4つの役割とは

  @IT](https://atmarkit.itmedia.co.jp/ait/articles/2601/06/news007.html)

• [Vibe Coding Security Risks: Why 53% of AI Code Has Security Holes

  Autonoma](https://www.getautonoma.com/blog/vibe-coding-security-risks)

• [Vibe Coding Is Shipping Vulnerabilities: A Security Team’s Guide to AI-Generated Code Risks

  Kusari](https://www.kusari.dev/blog/vibe-coding-is-shipping-vulnerabilities-a-security-teams-guide-to-ai-generated-code-risks)

• [AI時代のエンジニア市場価値最大化戦略 - 2026年最新データで見るスキル習得ロードマップ

  Zenn](https://zenn.dev/ailmarketing/articles/20260316-ai—2026)

• [開発者に必要なスキルが激変、要件定義や設計も生成AIのカバー範囲に

  日経XTECH](https://xtech.nikkei.com/atcl/nxt/column/18/02831/052200002/)