最近、弊社ではCursorを導入するプロジェクトが増えてきました。Cursorといえば「コードを書いてもらう」ツールという印象が強いですが、**「コードレビュー」**に活用することで、開発の質とスピードを劇的に上げることができます。
しかし、何も考えずに「レビューして」と投げると、手痛いしっぺ返しを食らうこともあります。今回は、私が実践しているAIレビューの活用法と、実際に踏み抜いた「罠」について共有します。
AIコードレビューで実際に活用している内容
-
本命：PR（Pull Request）レビュー 一番のメインです。プロンプトをしっかり作り込み、今回のPRの影響範囲に絞って確認してもらいます。
-
メモリ効率・パフォーマンスチェック 「もっとメモリ効率が良い書き方はないか？」という視点は、AIが得意とする分野です。
-
リファクタリング案の提示 「別の書き方はないか」「もっと簡潔に（省略して）書けないか」など、セカンドオピニオンとして使います。
絶対に守るべき鉄則：「レビュー」と「修正」を分ける
なぜ一気にやらせると危険なのか？
仕様の消失（Context Lost）: 型エラーを消すためにAIが勝手にロジックを変えてしまい、いつの間にか仕様が変わってしまうことがあります。
「何を変えたか」がブラックボックス化する: レビューと修正を同時に行うと、AIが「何を問題視して、どう直したのか」の思考プロセスが見えなくなるときがあります。
影響範囲の無視: 目の前のコードを直すために、別画面で共通利用しているコンポーネントの型を壊してしまうなど、広い視野での判断を誤ることがあります。
結論： まず「指摘」だけを出してもらい、人間がその妥当性を判断する。修正が必要な箇所だけを、改めて個別に指示する。この**「思考の分離」**が、AIと共存するコツです。
実際に使っているレビュー用プロンプト
事前に gh pr diff > diff.txt などのコマンドで差分ファイルを用意し、Cursorに投げています。モデルはGemini3 flashかChat GPT-5.2
# 指示
あなたはシニアエンジニアとして、PR内容をレビューしてください。
# 制約事項
- レビューの「指摘」のみを行い、ファイルを書き換えないでください。
- 今回のPRによる変更箇所（diff）に集中してください。既存バグの修正は不要です。
# 出力形式
1. 指摘の概要
2. 修正すべき理由（リスク）
3. 修正案（コード例）
まとめ
AIは「プロジェクトの背景」や「プロジェクト全体の複雑な仕様」を完璧には理解してくれません。
あくまで仕様が適切か、設計が崩れてないか、別の仕様になっていないかなど、人間がきちんと確認しないといけないことが多いです。
AIにレビューを依頼するときは、「まず口だけ出してもらい、手は出させない」。そして、提示された指摘が正しいかを人間が吟味する。このステップを挟むだけで、AIコードレビューの安全性と品質は向上します。
おまけ 自分だけ？
演算子の混同 ||（論理和）と ??（Null合体）の混同
JavaScriptでソース作成時にCursorがこの ?? ではなく、 || を使い出すことがなんか多いです。
- || (OR): 0 や ""（空文字）も「偽」と判定してデフォルト値に上書きする。
- ?? (Null合体): null か undefined のときだけ上書きする。
const count = 0; // ユーザーが意図的に「0」を入力
const result = count || 10; // 結果: 10 （バグ：0が消える）
const result = count ?? 10; // 結果: 0 （正解）
AIが良かれと思って|| を入れて、「数値の0が保存できない」というサイレントなバグが埋め込まれます。
AIに書いてもらったコードでバリデーションエラーにずっとなってるから何だろうと思ってみたらこのパターンがなんか多い。
何でだろ・・・。
Discussion