AI が書いたコードをレビューする：「正しそうで壊れる」を先に探す
収録 2026-11-05
AI コードの誤りは文法ではなく、もっともらしい前提にある。
このコードは AI が生成しました：[コード／説明]。「正しそうで正しくない」観点でレビューしてください：1）検証されていない前提（入力範囲、呼び出し順、外部状態）を挙げる；2）エラーにならず結果だけが狂う箇所を探す；3）エラー処理をしているように見えて、実は正常系だけ扱っている分岐を指摘する；4）フレームワークの作法に沿う部分と、存在しない API を補っただけの部分を分け、後者は公式資料で確認するよう示す；5）必ず足すテストケースと、それぞれが捕まえる誤りを書く。コード全体の書き直しは不要。
当サイトオリジナル
中国語の原文
置き換えるプレースホルダー 1
括弧の中をご自身の情報に置き換えてから送ってください。
[コード／説明]
使い方
AI コードで怖いのは、明らかに間違っていることではなく、もっともらしく間違っていること。
こう変えてみる
- コードを書く前に要件と制約を復唱させる。
- 全体書き換えではなく、最小の変更とロールバック方法を出させる。
得られる成果物
- そのまま使える最小変更（コピー可能なコード）
- 影響範囲：変更ファイルと追従が必要な呼び出し元
よくある失敗
- 一度に十ファイル変更させ、何が原因か分からなくなる。
- エラーだけ貼ってコードとバージョンを省くと、使えない修正が返る。
出力のチェック
- 変更は動いて戻せて、無関係なコードに手を入れていない。
- 境界条件（空・巨大・同時実行）が説明かテストで押さえられている。
使いどころと注意
- 向いている用途：要件と制約を復唱させてから、最小限の動く変更を出させる。
- 注意：エラーにはバージョンと最小再現を添える。無いと一見もっともらしいが合わない修正が返る。
向いている場面
- コードは動きテストも通るが、何かが引っかかる。とくに AI が一度に書いた実装のとき。
- 同僚や AI の変更をレビューする立場で、相手は自信がある。こちらは「もっともらしい」と「本当に安全」を分ける必要がある。
向いていない場面
- コードが動かない：まず動かしてからレビューする。
- 命名やインデントを揃えたいだけ：lint や formatter のほうが、人に一行ずつ見させるより確実。
例
入力
AI が生成した一覧 API：`page = int(request.args.get("page", 1))`、続いて `offset = page * size`、`size` を SQL の LIMIT にそのまま文字列連結。得られるもの
「正しそうで正しくない」点を二つ指摘する：1）page の基準が未定義で、0 起点だと最初のページを飛ばす——規約を明記し境界を検証する；2）size に許可リストも上限もなく、巨大値・負値・注入片を渡せる——LIMIT は文字列連結にしてはいけない。加えて空結果と範囲外ページの挙動が未定義であることも補う。各項目に発火する入力と最小の修正を書き、命名や整形には触れない。
よくある誤用
- 「AI のコードに問題がないか見て」とだけ送る：意図も実行環境もなく、汎用チェックリストしか返らない。
- そのまま書き直させる：検証できるレビュー意見ではなく、別のコードが出てくる。
こう変えると効く
- 「データ誤り・セキュリティ・静かな失敗につながるものだけ報告し、それ以外は黙る」と添えると、水増しが大きく減る。
- 「重大度順」を「各項目、まず発火する入力を示し、次に最小修正」に変えると、再現できる根拠が得られる。