AIが書いたコードのレビュー：差分を読む人のための15項目チェックリスト

コードをレビューする人向けで、初心者も含みます。専門用語には短い説明を添えています。

数字は末尾に挙げた公開レポートや研究によるものです。多くはテクノロジー企業が発表したものなので、注意して読んでください。「例」と書いたものは、イメージしやすいように組み立てたもので、特定の出来事ではありません。

---

要点#

• AIがコードを速く書くと、ボトルネックはレビューに移ります。AIをよく使うチームは多くの変更を統合しますが、1件あたりのレビューに時間がかかります。
• AIが書いたコードは整って見えて動くため、レビュアーが油断しやすくなります。感覚で読まず、決まったチェックリストを使いましょう。
• このリストは4つのグループに分けた15項目です。作業の理解（3）、正確で安全（5）、価値あるテスト（3）、保守しやすさ（4）。
• 最も見落とされやすい3つ：ライブラリは実在するか、入力を信じすぎていないか、コードが間違いのときテストは失敗するか。
• AIは最初の一巡に使えますが、責任は人が負います。AIには「正しい？」ではなく「誤りを探して」と頼みます。
• よいPRの説明は、AIが書いたこと、人が確認したこと、その方法を明記します。

---

むずかしい言葉をやさしく#

---

1. なぜより丁寧にレビューするのか#

3種類の根拠があり、どれも注意して読む必要があります。

• ボトルネックが移った。 Faros AIの「AI Productivity Paradox」レポート（2025年7月、1,255チームの1万人超の開発者）では、AIをよく使うチームは約98%多くの変更を統合しましたが、変更1件あたりのレビュー時間は約91%、変更の大きさは約154%増えました。測定ツールを売るベンダーのデータで、相関であって因果とは限らず、私は要約を読んだだけです。
• セキュリティ上の欠陥。 Veracodeの2025年GenAI Code Securityレポート（80の作業、100以上のモデル）では、AIが生成したコードは約45%の作業に脆弱性がありました。クロスサイトスクリプティングと安全でないログ出力では、モデルが対策できなかったのはそれぞれ約86%と88%です。それ以前に、Pearceら（2021年）は、Copilotが書いた1,689本のプログラムの約40%に脆弱性があると示しました。これらは試験用の作業で測った数字で、本番で動くコードではありません。
• 自信過剰。 Perryら（スタンフォード、2022年）は、AIアシスタントを使った人が5つのうち4つの課題でより安全でないコードを書きながら、安全だとより強く信じていたと示しました。小さなグループと古いモデルなので、兆候として読んでください。

これはAIを鵜呑みにしてはいけない理由とAI時代のITチームの働き方につながります。結果は完成して見えるので欠陥に気づきにくく、ボトルネックは読む工程にあります。

Googleの公開コードレビューガイド（eng-practices）には、覚えておきたい3つの基本の問いがあります。設計はシステムに合っているか、振る舞いは意図に合い利用者に役立つか、コードはもっと単純にできないか。以下のリストは、この3つをAIが書いたコード向けに具体化したものです。

---

2. 15項目チェックリスト#

重大度：高は事故やデータ消失につながりうるもの、中は技術的負債や小さな不具合の原因になるものです。

グループA．作業の理解#

グループB．正確で安全#

グループC．価値あるテスト#

グループD．保守しやすさ#

根拠について2点補足します。

• 項目4は、作られたパッケージ名の研究（バージニア工科大学ほか、2025年）につながります。パッケージ提案のおよそ5件に1件が存在せず、作られた名前の約43%が毎回の実行で繰り返し現れるため、攻撃者が先に登録できます（スロップスクワッティング）。
• 項目12は、GitClearの分析（2025年、2億1,100万行超の変更）につながります。要約記事は、2024年に重複したコードブロックが急増し、リファクタリングされた行の割合が下がったと伝えています。分析ツールを売るベンダーのデータで、相関であり、私は要約を読んだだけです。

---

3. 15分でPRを読む順序#

1. 説明と元の作業を読む（2分）。 説明が不明確なら、止めて聞きます。項目1、2、3。
2. コードの前にテストを読む（3分）。 テストは作者が仕事をどう理解したかを示します。項目9、10。
3. 差分の高リスクの箇所を走査する（6分）。 入力、秘密情報、削除と上書き、新しいライブラリ。項目4、5、6、7、8。
4. 動かす（3分）。 テストを走らせ、機能を動かし、悪いケースを1つ試します。項目10、11。
5. 残りを保守の観点で読む（1分以上）。 重複、複雑さ、決まり。項目12から15。

3で問題が見つかったら、「不具合を全部集める」ために読み続けないでください。早めに差し戻して作者に直してもらいます。回転のたびに時間がかかるからです。

---

4. AIが関わったコードのPR説明テンプレート#

よい説明は、レビュアーにどこを見るべきかを教えます。

作業：注文ページに注文キャンセルのボタンを追加
完成とは：テストがあり、返金が処理され、画面の写真がある

AIが書いたもの：ボタンのUI、キャンセルAPIの呼び出し、通常ケースのテスト
人が確認したこと：差分をすべて読み、テストを走らせ、配達済みの注文のキャンセルを試した
人が直したこと：不要なライブラリを削除、APIエラー時の処理を追加

再確認の方法：npm testを実行し、注文ページを開き、テスト注文をキャンセルする
自信がない点：分割払いの注文の返金。業務を知る人の確認が必要

レビュアーが「自信がない点」の行を見れば、どこに力を注ぐべきかが分かります。この説明は、作者に送る前に差分を読み直させる効果もあります。

---

5. AIにレビューさせるのは？#

AIは最初の一巡で役立ちます。小さな誤りを探す、忘れた点を思い出させる、長い部分をざっと読む。ただし最終のレビュアーとして扱わないでください。理由は3つです。

• 同調する傾向。 Anthropicの迎合に関する研究（Sharmaら、2024年）では、多くのAIアシスタントが、問い詰められると存在しない誤りを認めやすく、質問者に同調する傾向がありました。「このコードは正しい？」と聞かれたAIは「はい」と答えがちです。
• 同じ誤りの源。 レビューするAIが、書いたAIと同じ種類の間違いをするかもしれません。
• 責任を負えない。 署名する人が責任を負います。

リスクの低い使い方は、具体的な依頼です。

この差分を、厳しいレビュアーとして読んでください。
間違っているかもしれない箇所を3つ挙げ、理由を述べてください。
新しいライブラリ、関数、引数をすべて挙げ、どれくらい確かか述べてください。
検査されていない入力を指摘してください。
誤りが見つからなければ、何を見たかを述べてください。

そのうえで、人がAIの指摘した箇所を読み直し、AIが触れなかった箇所も読みます。

---

6. 3つの例#

よくある間違いから組み立てたもので、特定の出来事ではありません。

「いかにも本物らしい」ライブラリ。 AIがファイル形式を読むためにpip install fastparse-utilsを足します。すべてもっともらしく見えますが、レビュアーがパッケージのページを確認します（項目4）。パッケージは先週登録されたばかりで、メンテナーは1人。人気の代替品はすでにプロジェクトにありました。

常に緑のテスト。 AIが手数料の関数のテストを書きますが、テストはテストが期待する数字をそのまま返すモックを使っています（項目9）。レビュアーが式を1行壊しても（項目10）、テストは通ります。実際のデータでテストを書き直すよう求めます。

大きすぎる差分。 1つのPRに名前変更、リファクタリング、新機能が混ざり、1,000行超。レビュアーは差し戻して3つに分けるよう求めます（項目15）。3つの小さなPRは、列に並んだ1つの大きなPRより早くレビューが終わります。

---

7. バランスの取れた見方#

このリストは、AIが書いたコードが人が書いたコードより劣るという意味ではありません。人も入力の検査を忘れ、弱いテストを書きます。違いは速さと見た目です。AIはより多くのコードをより速く作り、整って見えるコードは欠陥を隠します。だから、このリストは人のコードにも役立ちます。

セキュリティの数字は、セキュリティ企業の試験用の作業で測ったもので、新しいモデルでは違うかもしれません。FarosとGitClearの数字は相関です。より確かなのは構造です。下書きを書く費用は下がっているが、確認する費用はそれに伴って下がっていない。レビュアーを増やすより、レビューの手順、自動テスト、共通の手引きに投資するほうが効くことが多いです。

---

8. 15項目を1ページで#

印刷用の要約です。

---

9. 結論#

AIがコードを書く費用を下げると、レビューが品質を決める工程になります。決まったチェックリストはレビュアーを感覚への依存から救い、正直なPRの説明はどこを見るべきかを教えます。AIは最初に読めますが、責任を負うのは署名する人です。

小さく始めましょう。最も見落とされやすい3項目（4、5、10）を次のPRに当てはめ、見つけたことを記録します。1週間後、チームが実際に出会う不具合に応じて残りを足します。

---

参考資料#

数字は2026年10月時点の公開情報によります。多くの出典はベンダーのレポートや要約記事で、数字の伝わり方が少し違うものもあるため、引用する前に原典を開いて確認してください。

• Faros AI、AI Productivity Paradox（2025年7月）：Farosの要約、Software Seniの要約（原典は未読）
• Veracode、GenAI Code Security Report 2025：Veracodeのプレスリリース、Help Net Security
• Pearceら、Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions（2021年）
• Perryら、Do Users Write More Insecure Code with AI Assistants?（スタンフォード、2022年）
• スロップスクワッティングの研究：Dark Reading、Infosecurity Magazine
• GitClear、AI Copilot Code Quality 2025：LeadDevの分析（要約記事、原典は未読）
• Sharmaら、Towards Understanding Sycophancy in Language Models（ICLR 2024）
• Google、Engineering Practices: The Code Reviewer's Guide