「動いてはいる。テストも通っている。だけど、なぜか不安が残る」。 Claude Code をはじめとする AI 生成コードのプルリクエストを見ていて、こう感じる場面が増えていないでしょうか。
最近の現場では、こんな声をよく聞きます。
- ジュニアが AI に書かせた PR が、ぱっと見はきれいだが要件と少しずれている
- レビューで指摘しても「それは仕様に書いていなかった」と返ってきて、議論が噛み合わない
- 既存コードの修正依頼だったはずが、関係のないファイルまで書き換わっていた
- レビュアーごとに見る観点が違い、AI コードの品質基準がチーム内で揃わない
問題は「AI が悪いコードを書いた」ではありません。 人間が書いたコードを前提に作られたレビュー観点のままでは、AI生成コードの“穴”を拾えなくなっていることが本質です。
本記事では、テックリード・開発リーダー・コードレビューに責任を持つPMに向けて、AI生成コードのレビュー観点を再設計するための4つの軸を整理します。可読性や命名といった既存の観点を否定するわけではなく、その上に重ねるべき、AIコード固有の見るべきポイントをまとめました。
なぜ既存のレビュー観点だけだと足りないのか
人が書いたコードのレビューでは、暗黙のうちに前提していたことが3つあります。
- 書いた本人が要件を理解している
- 書いた本人がコードベース全体の文脈を持っている
- 修正範囲は本人の責任で必要最小限になる
人間のジュニアが書いたコードでも、この前提は完全には満たされません。だからこそレビューが要ります。 ただ、AI生成コードでは、この3つがそもそも成立していません。
AIは与えられたプロンプトと参照ファイルからしか文脈を持たず、書き終わったあとに「なぜそう書いたのか」を残してくれません。プロンプトを書いた本人ですら、出てきたコードを最後まで読み切らずにマージしてしまうことがあります。
つまり、AI生成コードのレビューは、人間レビューの最終防衛線として機能させる必要があります。 そのため、可読性や命名、スタイルといった「読めるか読めないか」のレベルの前に、もっと手前の観点を強く見る必要が出てきます。
それが、要件適合・暗黙仕様・テスト設計・依存範囲の4観点です。
観点1：要件適合（仕様書とコードの突き合わせ）
最初に最も強く見るべきは、コードがチケットや仕様の要件を本当に満たしているかです。
AI生成コードは、見た目の整合性が高いぶん、要件とのずれに気付きにくいという特徴があります。プロンプトに書かれていなかった条件、Slack で口頭合意した制約、過去の議事録に書いてあった例外処理などは、コードに反映されないまま「それっぽい実装」が出来上がってしまいます。
現場で起きがちな症状
- 顧客が言っていた「ただし金額0円のときはスキップ」が抜けている
- バリデーションは入っているが、要件にあったエラー文言ではない
- 並び順の仕様（更新日降順）が、AI の好みで作成日昇順になっている
レビューでやること
要件適合のレビューは、コードを読む前にチケットや仕様書、関連ドキュメントを開くところから始めます。
- チケットに書かれた受け入れ条件を箇条書きで取り出す
- それぞれを満たすコードがどこにあるかを、レビュアーが指差し確認する
- 仕様にない振る舞いが追加されていないかを確認する
レビュアーが「コードに書かれていることをコードから読む」と、AIが出力した整合性に引き寄せられて、要件側のチェックが甘くなります。先に要件側の観点を持ってからコードを開くだけで、AIコードの暗黙の改変に気付きやすくなります。
観点2：暗黙仕様（書かれていない前提）
AIが最も苦手なのが、ドキュメントに書かれていない前提の扱いです。
長年運用されているシステムには、コード上には現れない暗黙の仕様が積み重なっています。
- 過去の障害対応で増えた防御的な分岐
- 特定顧客のためだけの特例処理
- 排他制御や再実行の前提
- 「このテーブルは論理削除しない」「このAPIは冪等」といった運用ルール
AIはこれらを知りません。人間のジュニアであれば「これ消していいですか？」と聞きますが、AIは何も聞かずに、見た目すっきりしたコードに書き換えてしまいます。
現場で起きがちな症状
- 防御的な if 文が「冗長」と判断されてまとめられ、過去障害が再発する
- 「念のため」のリトライ処理が消える
- 例外を握りつぶしていた箇所が「正しく throw する」ように変わり、上流で想定外の挙動になる
レビューでやること
暗黙仕様の観点では、変更前のコードと変更後のコードの差分から「消えたもの」を強く見ることが要点です。
- 削除された if 文 / try-catch / コメントを必ず1つずつ確認する
- 「なぜこの条件があったのか」を git blame・関連 PR・障害票で辿る
- 説明できない削除があれば、その PR は通さない
AIは追加には強いですが、削除の妥当性を説明する責任を持てません。その責任は人間レビュアーに残り続けます。
観点3：テスト設計の妥当性（テストがあるかではなく、何を守っているか）
AI生成コードはテストを一緒に書いてくれることが多く、カバレッジ数値も高めに出やすいです。 ただし、そのテストが何を守っているのかを見ないまま「テストあり」で通してしまうのが、いま一番危ういパターンです。
現場で起きがちな症状
- 実装と同じロジックをそのままテストに書き写しただけのテスト（実装が間違っていれば、テストも同じく間違う）
- 例外系・境界値・データなしケースが抜け、正常系だけが厚い
- モックが過剰で、実際の依存先との結合が一切検証されていない
- テスト名が抽象的（
test_successなど）で、何を検証しているか読み取れない
これらは「テストがある」状態を満たすので、CI は緑のまま流れていきます。けれど、要件の重要箇所を守れていません。
レビューでやること
テスト設計のレビューでは、テストコードを「動くか」ではなく、仕様のどこを守っているかで読みます。
- 受け入れ条件のうち、テストで担保されている項目／されていない項目を一覧で並べる
- 異常系・境界値・空・nullのテストが、要件に対して必要十分か確認する
- 実装ロジックをそのまま写しただけのテストになっていないかを確認する
テストの形式ではなく、テストの守備範囲を見ること。これが AI 時代のテストレビューの中心になります。
観点4：依存範囲（変更が必要な範囲を超えていないか）
最後の観点は、変更がチケットの責任範囲を超えていないかです。
Claude Code のようなエージェント型のツールは、リファクタや関連ファイルの整理を「親切」として一緒にやってしまうことがあります。1つのチケットの PR に、本来関係のない命名整理・型修正・ユーティリティの再配置などが混入し、レビューが事実上不可能なサイズに膨らむケースが増えています。
現場で起きがちな症状
- バグ修正の PR に、無関係なリファクタが20ファイル分混じっている
- import の整理だけと思いきや、共通モジュールのシグネチャが変わっている
- diff が大きすぎてレビュアーが読み切れず、「ざっと見てLGTM」になっている
これは品質を下げるだけではなく、障害発生時の切り分けを著しく難しくします。原因コミットを特定できない PR は、運用上の負債です。
レビューでやること
依存範囲のレビューでは、技術的な良し悪し以前に、チケット範囲との一致を強く見ます。
- チケットに書かれていない変更が含まれていないかを確認する
- 含まれていれば、別 PR への分割を依頼する
- 共通モジュールに触っているなら、影響範囲（呼び出し側すべて）を一覧で添付させる
「親切なリファクタ」を許容するか、別 PR に切るかは、チームのルールとして明文化しておくと運用が安定します。AI に「このチケットの範囲だけ修正して」と書いても、その制約は強制されないと思っておいたほうが安全です。
4観点をチームで運用するときのコツ
4つの観点を頭で覚えるだけでは、レビューの粒度はすぐにバラつきます。実務では次の3つを仕組みに落としておくと安定します。
PRテンプレートに4観点を埋める
PR の説明欄に、要件適合・暗黙仕様・テスト設計・依存範囲の4ブロックを用意し、起票者が先に自分で答える運用にします。AI生成コードであっても、人間が要件との突き合わせを必ず1度は通る構造になります。
レビュー観点を「読み順」で決める
コードから読み始めるとAIの整合性に引きずられるため、「①チケット → ②差分の削除部分 → ③テスト → ④影響範囲 → ⑤実装」の順で見るというルールを決めておきます。観点の中身よりも、順番が崩れにくさを生みます。
危険な変更だけ二重レビューにする
すべての PR を厚くレビューする必要はありません。共通モジュール・認証・課金・データマイグレーションなど、AI に任せると暗黙仕様の影響が大きい領域だけ、二人レビューや変更前確認を必須にします。
よくある失敗
- AI 出力をそのまま PR にし、説明欄が空のまま投げる
- レビュアーが「動いた・テスト通った」を品質基準にしてしまう
- 「AI に書かせたものはレビューしないでマージしない」と決めるだけで、観点が共有されていない
- 4観点を導入したが、人間が書いたコードには適用しないため、運用が二重化する
4観点は AI 専用ではありません。人間のコードでも有効ですが、AI生成コードでは特に強く効く、という位置づけで導入したほうが、チーム内の納得感を作りやすいです。
まとめ：レビュー基準を「AI 前提」で再設計する
AI生成コードのレビューで見るべき4観点を、もう一度整理します。
- 要件適合：チケットの受け入れ条件を、コードの前に並べて突き合わせる
- 暗黙仕様：差分から「消えたもの」を1つずつ説明する
- テスト設計：テストの数ではなく、何を守っているかを見る
- 依存範囲：チケット範囲を超えた変更を、別 PR に切らせる
可読性や命名のレビューを捨てるのではありません。その上に、AIコードに固有のリスクを拾う層を1枚足す、というイメージです。
レビュー基準を再設計したあとは、それを開発・PM 業務にどう組み込むかが次のテーマになります。文書化や運用ルールに落とすところまで含めて体系で学びたい方には、テックエイドの2講座が直接の続きになります。
- AI 出力の品質を安定させ、ドキュメント業務に落とし込む全体像 → 【生成AI実践】仕様書・報告書・議事録を半分の時間で仕上げる技術（AIX-101）
- 進捗・課題・リスクの管理運用にAIを組み込み、PM業務の精度を保つ仕組み → 【生成AI実践】進捗・課題・リスク管理をAIで加速する運用設計（AIX-102）
レビュー観点を整えても、運用の中で揺れ戻すと崩れます。AIX-101 と AIX-102 は、本記事の4観点と整合する形で「AI 出力をどう人間レビューに乗せるか」「PM/PL が運用ルールとしてどう仕組み化するか」を扱う講座です。レビュー基準の再設計を、組織の運用にまで広げたい方の次の一歩としておすすめします。