Toolify

シニアコードレビューア プロンプト — バグ・性能・エッジケースを発見

AIコードレビューは普通、スタイル指摘の山に本物のバグが埋もれて使い物にならない。このプロンプトは深刻度でトリアージを強制し、テックリードの厳しいレビューを生き残るものだけ報告させ、根拠の行番号も引用させるので各指摘を秒で検証できる。

カテゴリ: coding推奨モデル: claude / chatgpt / cursor
prompt
あなたはシニアスタッフエンジニアとして以下の差分をレビューします。目的は、テックリードの厳しいレビューを実際に生き残る指摘を捕捉することです — Lintのノイズではなく。

レビュー方針:
1. すべての指摘を BLOCKER / MAJOR / MINOR / NIT のいずれかにトリアージしてください。
2. デフォルトでは BLOCKER と MAJOR のみ出力。MINOR と NIT は明示要求がない限り抑制。
3. 各指摘は、ファイルパス + 行番号範囲を引用したうえで、(a) 何が間違っているか、(b) 本番での障害モード、(c) 推奨修正、を順に説明してください。
4. 指摘の確信度が80%未満の場合は [low-confidence] を付け、検証に必要な追加情報を述べてください。
5. 最後に総評を一段落: ship-it / ship-with-followups / do-not-ship。

以下については指摘しない:
- 命名の好み(誤読を誘う場合を除く)。
- フォーマッタが入っている場合の整形・空白。
- 計測されたホットパスに紐づかない仮想的な最適化。
- 既にコードベース他所で使われているパターン(これは整合性であってバグではない)。

レビュー対象差分:

[ここにunified diffまたはファイル本体を貼る]

使うべきタイミング

  • 非自明なPRをマージする前 — 差分を本プロンプトに通して、もう一組の目で見たい点を洗い出す。
  • 自分で書いたコードのセルフレビュー — 人間レビューを依頼する前に通すと、恥ずかしい単純ミスを潰せる。
  • 馴染みの薄いコードベースのオンボーディング — 関数とプロンプトを貼って、変更前にリスクを把握する。

モデル別ヒント

claude
Claude (Sonnet 4.6 か Opus 4.7) が最も慎重なトリアージを返す。差分はコードブロックで貼るとPR全体でも読み切れる。
chatgpt
GPT-5 / GPT-4o はスタイル指摘に積極的になりがち。上記の「MINOR と NIT を抑制」ルールで軌道修正される。
cursor
Cursor では .cursorrules に保存するか、composer に貼り付ける。@file 参照と組み合わせると効果的。

出力例

BLOCKER: src/auth/session.ts:42-58
  - what: セッショントークンの比較が === で、定数時間比較になっていない。
  - failure mode: リモートログインでタイミング攻撃に晒される可能性。
  - fix: crypto.timingSafeEqual() でバッファ同士を比較する形に変更。

MAJOR: src/auth/session.ts:73 [low-confidence]
  - what: リフレッシュトークンが localStorage に書かれている。
  - failure mode: 未サニタイズのユーザーコンテンツが画面に届けば XSS 経由で抜き取られる。
  - fix: フロントが直接読まないなら httpOnly Cookie に移す。(low-confidence: フロント側でこのトークンをどう使うか見えていない)

Summary: ship-with-followups。定数時間比較はマージ前に必須、保存先の件はこのPRに関わらずfollow-up issueの価値あり。

使い方の解説

なぜ多くのAIコードレビューは役に立たないのか

デフォルトのLLMはコードレビュータスクで「親切な後輩」のペルソナに陥りがちで、命名にコメントしすぎ、問題ないコードに「クリーンコード化」を提案し、本物のバグ1つを大量の提案の山に埋めてしまう。S/N比が悪く、多くのチームは1週間で使うのをやめる。

上記プロンプトは3点をひっくり返す: 深刻度トリアージで自明な問題を明示的に抑制、行番号を要求して各指摘を秒で検証可能にし、信頼度フラグでファイル全体を読まずに信頼すべき指摘を判別できるようにする。

CIとの組み合わせ方

PRワークフローの「セカンドオピニオン」ステップとして使う — ゲーティングチェックではなく。モデルは依然としてハルシネーションを起こす、特にファイル横断の不変条件や、貼っていないフレームワーク慣習に依存するコードで。出力は「機械的に修正する課題リスト」ではなく「検証する課題リスト」として扱うこと。

CIに入れたい場合は、JSON出力に変えて(プロンプトを変更:「severity, path, lineStart, lineEnd, what, fix, confidence の各フィールドを持つJSON配列を返す」)、BLOCKER/MAJORだけをまとめて1つのコメントとしてPRに投稿し、明確に「AIアシスト — 行動前に検証」ヘッダを付ける。

チームに合わせた調整

差分の上に「Codebase context」セクションを追加し、スタック、テスト慣習、非自明な不変条件(例:「DB書き込みはすべて src/db/withTx 経由、生のクライアントは禁止」)を5-10行で記述する。これがないと、モデルはコードベース固有の慣習を見逃す。

チーム特有の弱点(あるジョブランナーでのレースコンディション、特定のサービスのN+1クエリ等)があれば「Watch especially for: …」行を追加。それらのバグクラスをモデルが重視するようになり、検出率が上がる。

よくある質問

›クローズドソースのコードに使えますか?

使えますが、雇用主のポリシーを先に確認してください。プロンプト自体は無害で、論点は「使うモデルにコードを貼り付けてよいか」です。Claude と ChatGPT のエンタープライズプランは通常入力で学習しません、コンシューマプランは要確認。

›なぜ MINOR と NIT を抑制するのですか?

実用上、レビュー疲労を生むからです。「この部分は関数化を検討」を3件読むと続きを読まなくなります。抑制することで BLOCKER/MAJOR シグナルがシャープに保たれます。深掘りしたい時だけ「show all findings including MINOR and NIT」で戻せばよい。

›差分はどれくらい長くて大丈夫?

Claude Sonnet/Opus と GPT-5 は 50K+ トークン差分を余裕で扱えます。とても大きなPRはディレクトリ単位(src/auth → src/billing)で分割すると、各サブシステムを独立して考えられて精度が上がる。

›セキュリティ専用レビューは?

本プロンプトは明らかな暗号・保存先・SSRF系の問題は捕捉しますが、認証・決済系コードのセキュリティレビューの代替にはなりません。これらは本プロンプトに加えて専用のセキュリティレビュープロンプト(別途公開予定)を併用してください。

›複数ファイル横断のレビューは?

可能です — 全ファイルを含む差分を貼ってください。1回の貼り付け内で横断不変条件は妥当に扱えます。複数PRをまたぐ問題(例:「他所のフィーチャーフラグゲートと一致しているか」)は、それらのファイルから代表的な抜粋を含めると効果的。

›[low-confidence] 指摘は信用してよい?

「行動前に調査」として扱ってください。低信頼度の指摘の半分は本物でモデルが検証しきれていないだけ、もう半分は読み違いです。フラグは正直なシグナルで、無視する理由ではありません。

›障害モードを書かせる理由は?

「これは間違い」だけでは「unicode入力でクラッシュする」が分からないからです。障害モード行が優先度を教えます — 100万に1回のエッジケースを防ぐ修正と、毎日の本番障害を防ぐ修正は別物です。

›Cursor で具体的にどう使う?

リポジトリルートの .cursorrules に保存するか、composer に貼り付けて @file 参照と組み合わせます。Cursor はそのプロジェクトでルールを継続適用します。

関連する計算ツール

関連プロンプト

最終更新: