AI生成コードのレビュー・検証チェックリスト｜使う前に見る所
「とりあえず動いた」AIのコードを、そのまま通していいものか。いまはエージェントがファイル編集からテスト実行、コミットやPR作成まで自走し、人はPRや差分ビュー上で承認する形も増えました。それでも、手は止まらないのに、頭の片隅で「本当にこれで大丈夫か」という声が消えない——そんな夜、ありますよね。
レビューしようにも、どこから見ればいいのか。 全部を疑えばキリがないし、かといって読まずに通すのは怖い。納期は迫る。上からは「AIで速くなったよね」と言われる。 その板挟みのなかで、せめて「ここだけは外さない」順番があれば、少し楽になります。
この記事は、AIが書いたコードを使う前に見ておきたい観点を、現場で潰せるチェックリストにまとめたものです。一度に全部やる必要はありません。まず効く所から、一緒に見ていきましょう。
結論：AI生成コードは「動くかどうか」より先に、①依頼した仕様と合っているか → ②壊れやすい所（境界・異常系）→ ③セキュリティと機密 → ④依存とライセンス → ⑤読みやすさ・保守性の順で見ると、少ない労力で大きな事故を防げます。AIは「もっともらしく間違える」ので、テストが緑でも、リスクの高い変更（外部入力・認証・お金・データ書き換え）に限っては人の目を一段挟む前提で扱います。それ以外の変更は軽めの確認で十分——全部を等しく重く見ないことが、続けるコツです。最後のチェックリストを、コピーして手元に置いてください。
AIの出力は、検証して初めて自分のコードになります。 ここで挙げる観点は特定のツールに依存しません。GitHub Copilot でも Cursor でも Claude Code でも、出力をコピペした後でも、エージェントが差分・テストまで自走した後でも——生成の前提が変わってもそのまま使える「見る順番」として読んでください。PRや差分ビュー上で承認する前の、最後に一段見る確認としても使えます。
なぜ「動いた」だけでは安心できないのか
AIが書くコードの特徴は、「文法的には正しく、それらしく動くのに、依頼の意図とは微妙にずれている」ことがある点です。 コンパイルは通る。サンプル入力では動く。テストも緑。それでも、要件の解釈が一段ずれていたり、想定外の入力で静かに壊れたりする。
これは「AIが劣っているから」ではありません。 AIは、与えられた文脈のなかで一番ありそうな続きを作るのが得意で、あなたの頭のなかにある「言わなかった前提」までは読めない、というだけのことです。だから人が見るべきなのは、文法ではなく前提と境界になります。
レビューを上から5つの関門で考えると整理しやすくなります。仕様 → 境界 → 安全 → 依存 → 可読性。上の関門で引っかかったら、その下を細かく見る前に、まずそこを直す。順番があるだけで、闇雲に全部を疑う消耗が減ります。
関門1：依頼した仕様と合っているか
最初に見るのは、コードの中身ではなく「これは私が頼んだことをやっているか」です。
- 入力と出力の型・単位・並び順は、想定どおりか
- 「やってほしいこと」だけでなく、「やってほしくないこと」（例：既存データを書き換えない、副作用を出さない）を守れているか
- 仕様の解釈が分かれる所で、AIが勝手に一方に決めていないか
ここでよくあるのは、こちらが省略した前提をAIが「常識的な方」に補完しているケースです。 たとえば「金額を計算して」と頼んだら、税込なのか税抜なのか、丸めは切り捨てか四捨五入か——AIはどれかに決めて書きます。その決め方が自分の意図と同じかを、まず突き合わせます。
関門2：壊れやすい所（境界・異常系）を見る
仕様が合っていたら、次は「サンプル以外の入力で壊れないか」です。AIのコードがいちばん漏らしやすいのが、ここです。
- 空・null・0・負の数・極端に大きい値を渡したらどうなるか
- 配列やリストが空のとき／要素が1つのときの振る舞い
- エラーを握りつぶしていないか（例外を
catchして何もしない、になっていないか） - 同じ処理を二重に呼んだとき（リトライ・連打）に壊れないか
AIは「正常系のきれいな例」を中心に学んでいるので、異常系の処理があっさりしがちです。 ここは、生成されたコードに対して自分で1〜2個、意地悪な入力のテストを足してみるのがいちばん速い確認になります。緑だったテストが赤くなれば、それが見つけたかった穴です。
関門3：セキュリティと機密の扱い
動作とは別軸で、「これを本番に出して危なくないか」を見ます。範囲を絞れば、確認は数分です。
- 外部入力をそのままSQL・シェル・HTMLに渡していないか（インジェクションの基本）
- 認証・認可のチェックを飛ばしていないか
- APIキー・パスワード・トークンがコードやログに直書きされていないか
- AIに渡したプロンプトや文脈に、社内の機密・個人情報が混ざっていなかったか（入力側のリスク）
ここを毎回フルで見る必要はありません。外部入力・認証まわりに触れたPRのときだけ、上の項目を確認すれば十分です。それ以外の変更では、この関門はいったん飛ばして構いません。 代表的な脆弱性のパターンをまとめた OWASP Top 10（owasp.org）は、時間が取れるときの参考・任意として頭の隅に置いておく程度でかまいません。通読を前提にすると現場では回らないので、勘所をつかみたくなったら見る、くらいで十分です。 ただし外部入力を扱うコードと、認証まわりだけは、AI生成かどうかに関わらず人が見る前提にしておくと安心です。
関門4：依存とライセンス
この関門は、新しい依存（ライブラリ・パッケージ）を足したときだけ見れば十分です。依存を増やしていない変更では、まるごと飛ばして構いません。
- 見覚えのないライブラリ・パッケージを
importしていないか。実在し、メンテされているものか - 既存プロジェクトに同等の関数・ユーティリティがあるのに、AIが新しく作り直していないか
- そのライブラリのライセンスは、自社のプロダクトに入れて問題ないか
ライセンスの可否は、個人や小規模だと判断材料が乏しくて迷いがちです。そんなときは無理に追加せず、既存の仕組みで代替できないかを先に試す。それでも必要なら、判断できる人に一言相談してから入れる——この順番にしておくと、迷ったまま入れてしまう事故が減ります。 AIは「動かすために便利なライブラリ」を気軽に足します。それが本当に必要か、既存の仕組みで足りないか——ここは、コードベースを知っている人にしか判断できない所です。重複を増やさない視点だけ、持っておきましょう。
関門5：読みやすさ・保守性
最後に、「半年後の自分（と同僚）が読めるか」を見ます。今日は動いても、読めないコードは後でコストになります。
- 命名・コメントが、プロジェクトの流儀に合っているか
- 1つの関数に詰め込みすぎていないか。分けた方が読めないか
- 「なぜそうしているか」が分かるか（処理の意図がコメントや構造から追えるか）
- 過剰に賢い書き方で、かえって読みにくくなっていないか
ここは事故には直結しませんが、「動くけど読めない」コードが積み重なると、次にAIへ文脈を渡すときにも効いてきます。気になった所だけ、自分の言葉に直しておくと、コードベース全体が穏やかになります。
明日からやること（小さく始める3つ）
全部を一度に仕組み化しようとすると続きません。まずこの3つから。
- 「動いた」の後に、意地悪な入力を1つ試す：空・0・想定外の値を1個渡してみる。これだけで関門2の多くが拾えます。
- 机に5つの関門メモを貼る：仕様 → 境界 → 安全 → 依存 → 可読性。順番を目に入れるだけで、レビューの抜けが減ります。
- AIへの入力に機密を入れない癖をつける：貼り付ける前に「これは社外に出ても困らないか」を一拍考える。関門3の入力側の事故が防げます。
AI生成コード レビュー・検証チェックリスト
コピーして、プルリクや自分のコミット前に1項目ずつ「○／要確認」を付けながら使ってください。全部の○を埋める前提ではありません。 16項目すべてを毎回やろうとすると重いので、最低ラインと優先順位を先に決めておきます。
まずこの3つだけは毎回（最低ライン）
- 意地悪な入力を1つ試した（空・0・想定外の値など）
- 鍵・パスワード・トークンの直書きが無い
- 外部入力をそのままSQL・シェル・HTMLに渡していない
この3つを押さえたら、あとは今日の変更が触っている領域に関係する所だけでかまいません。下の各関門は、その変更が触っていない領域なら免除（飛ばしてよい）です。特に依存・ライセンス・可読性は、該当するときだけ見れば十分です。
関門1：仕様
- 入力・出力の型・単位・並び順が依頼どおりか
- 「やってほしくないこと」（副作用・既存データの変更など）を守れているか
- 解釈が分かれる所（丸め・税・初期値）を、自分の意図と突き合わせたか
関門2：境界・異常系
- 空・null・0・負・極大の入力で壊れないか
- 空配列・要素1つのときの振る舞いを確認したか
- 例外を握りつぶしていないか
- 意地悪な入力のテストを1つ以上自分で足したか
関門3：セキュリティ・機密（外部入力・認証まわりに触れたPRのときに見る）
- 外部入力をそのままSQL・シェル・HTMLに渡していないか
- 認証・認可のチェックを飛ばしていないか
- 鍵・パスワード・トークンが直書き／ログ出力になっていないか
- AIへの入力に機密・個人情報を混ぜていなかったか
関門4：依存・ライセンス（新しい依存を足したときだけ／足していなければ免除）
- 見覚えのない依存が実在し、メンテされているか
- 既存の関数・ユーティリティの作り直しになっていないか
- ライセンスに迷うなら、追加せず既存で代替するか相談したか
関門5：可読性・保守性（気になったときに／余裕がなければ後回し可）
- 命名・コメントがプロジェクトの流儀に合っているか
- 関数が大きすぎないか、意図が追えるか
- 過剰に複雑な書き方になっていないか
最後に
AIに任せたコードを疑うのは、AIを信用していないからではありません。 最後に責任を持つのが自分だから、見る所を決めておくだけのことです。それは、速さを手放すことでもありません。見る順番がある分、むしろ迷いが減って速くなります。
5つのうち、今日見られたのが1つでも、それはもう「そのまま使わなかった」という確かな一歩です。 気になった関門から、ひとつずつ潰していきましょう。