--- title: "AIが書いたコードのレビュー：差分を読む人のための15項目チェックリスト" url: https://www.thinnd.site/ja/gijutsu/ai-ga-kaita-code-no-review/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "エンジニアリング" tags: ["コードレビュー", "AI", "検証", "セキュリティ", "チェックリスト"] summary: "AIがコードを書くとボトルネックはレビューに移るので、レビュアーには感覚で読むのではなく決まったチェックリストが要ります。15項目は4つのグループで、作業の理解、正確で安全、価値あるテスト、保守しやすさです。特に見落とされやすいのは、ライブラリが実在するか、入力を信じすぎていないか、コードが間違いのときにテストが失敗するかです。" license: "Cite with the author name and the canonical URL above." --- # AIが書いたコードのレビュー：差分を読む人のための15項目チェックリスト > コードをレビューする人向けで、初心者も含みます。専門用語には短い説明を添えています。 > > 数字は末尾に挙げた公開レポートや研究によるものです。多くはテクノロジー企業が発表したものなので、注意して読んでください。「例」と書いたものは、イメージしやすいように組み立てたもので、特定の出来事ではありません。 --- ## 要点 - AIがコードを速く書くと、**ボトルネックはレビューに移ります**。AIをよく使うチームは多くの変更を統合しますが、1件あたりのレビューに時間がかかります。 - AIが書いたコードは**整って見えて動く**ため、レビュアーが油断しやすくなります。感覚で読まず、決まったチェックリストを使いましょう。 - このリストは**4つのグループに分けた15項目**です。作業の理解（3）、正確で安全（5）、価値あるテスト（3）、保守しやすさ（4）。 - 最も見落とされやすい3つ：**ライブラリは実在するか**、**入力を信じすぎていないか**、**コードが間違いのときテストは失敗するか**。 - AIは最初の一巡に使えますが、**責任は人が負います**。AIには「正しい？」ではなく「誤りを探して」と頼みます。 - よいPRの説明は、**AIが書いたこと、人が確認したこと、その方法**を明記します。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **差分（diff）** | コードの2つの版の比較。緑の行は追加、赤の行は削除。レビュアーは差分を読む。 | | **PR（プルリクエスト）** | 変更をプロジェクトに入れる提案。他の人が受け入れる前に見られる。 | | **XSS、インジェクション** | 入力欄に悪意のあるコードを紛れ込ませる攻撃。よいコードはどんな入力も信用しない。 | | **依存（dependency）** | コードが呼び出す外部のライブラリ。 | | **常に緑のテスト** | コードが間違っていても合格を報告するテスト。自分自身しか確認していない。 | | **ミューテーションテスト** | わざとコードを壊して、テストが失敗するかを見ること。 | --- ## 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を鵜呑みにしてはいけない理由](https://www.thinnd.site/ja/gijutsu/ai-wo-unomi-ni-shinai-riyu/)と[AI時代のITチームの働き方](https://www.thinnd.site/ja/keiken/ai-jidai-no-chimu-no-hataraki-kata/)につながります。結果は完成して見えるので欠陥に気づきにくく、ボトルネックは読む工程にあります。 Googleの公開コードレビューガイド（eng-practices）には、覚えておきたい3つの基本の問いがあります。設計はシステムに合っているか、振る舞いは意図に合い利用者に役立つか、コードはもっと単純にできないか。以下のリストは、この3つをAIが書いたコード向けに具体化したものです。 --- ## 2. 15項目チェックリスト 重大度：**高**は事故やデータ消失につながりうるもの、**中**は技術的負債や小さな不具合の原因になるものです。 ### グループA．作業の理解 | # | 問い | AIのコードによくある兆候 | 確認方法 | 重大度 | |---|---|---|---|---| | 1 | 頼まれたことを、過不足なく行っているか？ | 頼まれていないことを足す、または解釈の違いで依頼の半分を落とす | 先に作業の説明を読み、期待を自分の言葉で言ってから、差分を読む | 高 | | 2 | 変更の範囲は絞られているか？ | 差分が無関係のファイルに触れ、「ついでに」名前変更や整形をしている | 変更ファイルを並べ、1つずつ「なぜここにあるか」を問う | 中 | | 3 | 前提は明示されているか？ | あいまいな依頼の1つの読み方を黙って選んで進める | 「何を前提にしましたか」と聞き、作業の説明と照らす | 高 | ### グループB．正確で安全 | # | 問い | AIのコードによくある兆候 | 確認方法 | 重大度 | |---|---|---|---|---| | 4 | ライブラリ、関数、引数は実在し、版は正しいか？ | 存在しない、または廃止された関数を呼ぶ。もっともらしいが作られた名前のパッケージを入れる | パッケージの公式ページ、メンテナー、作成日、ダウンロード数を確認。実行してインポートエラーを見る | 高 | | 5 | 外部からの入力はすべて検査されているか？ | XSS、インジェクション、不審なファイルパスへの対策を忘れる | 入力が届く場所から使われる場所まで追う。悪い文字列で試す | 高 | | 6 | 秘密情報や機密データが漏れていないか？ | 鍵やトークンをコードに直書き、個人データをログに出す | 鍵のような文字列を検索し、ログ出力の行を読む | 高 | | 7 | 境界の場合とエラーは扱われているか？ | 順調な道だけを想定：空、null、タイムゾーン、大きな数、同時の2リクエスト | 境界の場合を3つ自分で挙げ、それぞれの処理を探す | 高 | | 8 | 破壊的な操作に歯止めがあるか？ | 確認なしの削除や上書き、条件のない文 | 削除、上書き、一括更新を探す。「間違えたらどう元に戻すか」を聞く | 高 | ### グループC．価値あるテスト | # | 問い | AIのコードによくある兆候 | 確認方法 | 重大度 | |---|---|---|---|---| | 9 | テストは本当の振る舞いを確認しているか？ | テストが確認する値をそのまま返すモックを使い、常に緑 | コードの前にテストを読む。「このテストは自分自身以外の何を確認していますか」と聞く | 高 | | 10 | コードが間違いのとき、テストは失敗するか？ | わざとコードを壊しても、テストが通る | 重要な1行を壊してテストを走らせる（手動のミューテーションテスト） | 高 | | 11 | まっさらなマシンで動くか？ | プロジェクトに記録されていないものが作者のマシンにあるため動く | 新しいコピーを取得し、手順どおりに実行するかCIに走らせる | 中 | ### グループD．保守しやすさ | # | 問い | AIのコードによくある兆候 | 確認方法 | 重大度 | |---|---|---|---|---| | 12 | 重複していないか、プロジェクトにすでにあるものを無視していないか？ | すでにある関数を書き直す、ほぼ同じブロックを貼る | 受け入れる前に、似た関数名やブロックをプロジェクトで検索する | 中 | | 13 | コードは単純で読みやすいか？ | 不要な抽象化の層、単純な仕事のための深い入れ子 | コードを1分で人に説明してみる | 中 | | 14 | プロジェクトの決まりに従っているか？ | 命名、フォルダ構造、エラー処理が他と違う | [AI向けの手引き](https://www.thinnd.site/ja/gijutsu/agents-md-no-kakikata/)や近くのファイルと比べる | 中 | | 15 | PRは小さく、目的が1つで、説明は明確か？ | 複数の仕事を混ぜたPR、あいまいな説明 | 分割を求める。4章の説明テンプレートを使う | 中 | 根拠について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説明テンプレート よい説明は、レビュアーにどこを見るべきかを教えます。 ```text 作業：注文ページに注文キャンセルのボタンを追加 完成とは：テストがあり、返金が処理され、画面の写真がある AIが書いたもの：ボタンのUI、キャンセルAPIの呼び出し、通常ケースのテスト 人が確認したこと：差分をすべて読み、テストを走らせ、配達済みの注文のキャンセルを試した 人が直したこと：不要なライブラリを削除、APIエラー時の処理を追加 再確認の方法：npm testを実行し、注文ページを開き、テスト注文をキャンセルする 自信がない点：分割払いの注文の返金。業務を知る人の確認が必要 ``` レビュアーが「自信がない点」の行を見れば、どこに力を注ぐべきかが分かります。この説明は、作者に送る前に差分を読み直させる効果もあります。 --- ## 5. AIにレビューさせるのは？ AIは**最初の一巡**で役立ちます。小さな誤りを探す、忘れた点を思い出させる、長い部分をざっと読む。ただし最終のレビュアーとして扱わないでください。理由は3つです。 - **同調する傾向。** Anthropicの迎合に関する研究（Sharmaら、2024年）では、多くのAIアシスタントが、問い詰められると存在しない誤りを認めやすく、質問者に同調する傾向がありました。「このコードは正しい？」と聞かれたAIは「はい」と答えがちです。 - **同じ誤りの源。** レビューするAIが、書いたAIと同じ種類の間違いをするかもしれません。 - **責任を負えない。** 署名する人が責任を負います。 リスクの低い使い方は、具体的な依頼です。 ```text この差分を、厳しいレビュアーとして読んでください。 間違っているかもしれない箇所を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ページで 印刷用の要約です。 | グループ | 項目 | |---|---| | A．作業の理解 | 1 依頼どおり。2 範囲が絞られている。3 前提が明示されている | | B．正確で安全 | 4 ライブラリと関数が実在。5 入力が検査されている。6 秘密情報が漏れていない。7 境界の場合とエラー。8 破壊的操作に歯止め | | C．テスト | 9 本当の振る舞いを確認。10 間違いのとき失敗する。11 まっさらなマシンで動く | | D．保守 | 12 重複なし。13 単純で読みやすい。14 決まりに従う。15 小さなPR、明確な説明 | --- ## 9. 結論 AIがコードを書く費用を下げると、レビューが品質を決める工程になります。決まったチェックリストはレビュアーを感覚への依存から救い、正直なPRの説明はどこを見るべきかを教えます。AIは最初に読めますが、責任を負うのは署名する人です。 小さく始めましょう。最も見落とされやすい3項目（4、5、10）を次のPRに当てはめ、見つけたことを記録します。1週間後、チームが実際に出会う不具合に応じて残りを足します。 --- ## 参考資料 数字は2026年10月時点の公開情報によります。多くの出典はベンダーのレポートや要約記事で、数字の伝わり方が少し違うものもあるため、引用する前に原典を開いて確認してください。 - Faros AI、AI Productivity Paradox（2025年7月）：[Farosの要約](https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings)、[Software Seniの要約](https://softwareseni.com/the-ai-productivity-paradox-in-software-development-and-what-the-research-actually-shows)（原典は未読） - Veracode、GenAI Code Security Report 2025：[Veracodeのプレスリリース](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)、[Help Net Security](https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks/) - Pearceら、[Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions](https://arxiv.org/pdf/2108.09293)（2021年） - Perryら、[Do Users Write More Insecure Code with AI Assistants?](https://arxiv.org/pdf/2211.03622)（スタンフォード、2022年） - スロップスクワッティングの研究：[Dark Reading](https://darkreading.com/application-security/ai-code-tools-widely-hallucinate-packages)、[Infosecurity Magazine](https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/) - GitClear、AI Copilot Code Quality 2025：[LeadDevの分析](https://leaddev.com/software-quality/how-ai-generated-code-accelerates-technical-debt)（要約記事、原典は未読） - Sharmaら、[Towards Understanding Sycophancy in Language Models](https://arxiv.org/pdf/2310.13548)（ICLR 2024） - Google、[Engineering Practices: The Code Reviewer's Guide](https://google.github.io/eng-practices/review/)