「PRレビュー、誰か見てくれないかな…」を解決するコマンド
PR出したけどレビュアーが忙しくて2日放置。自分でもう一度見直したいけど、自分のコードのバグは自分では見つけにくい。かといってペアプロに付き合ってもらうほどでもない ― そんな時に使えるのが、Claude Codeの/code-reviewコマンドです。
2026年5月のv2.1.147で大幅に刷新され、バグ検出に特化したレビューコマンドとして生まれ変わりました。GitHub PRのインラインコメントとして指摘を投稿する機能も追加され、SNSでも「めっちゃ良い」と話題になっています。
本記事では、/code-reviewの基本的な使い方から、実際にどんな指摘が出るのか、そして全部鵜呑みにしないための取捨選択のコツまでを紹介します。
/code-reviewって何ができるの?
/code-reviewは、Claude Code上で実行するコードレビュー専用コマンドです。現在の差分(ステージング済みの変更やPRの差分)を解析し、バグの可能性がある箇所を検出・レポートしてくれます。
以前は/simplifyという名前で「コードの簡素化」が目的でしたが、v2.1.147でバグ検出・レポート専用に再設計されました。スタイルの改善提案ではなく、実際に修正すべきバグを見つけることにフォーカスしています。
主な機能は以下の通りです。
- バグ検出:型の不一致、未処理のエラーケース、ロジックの抜け漏れを指摘
- effortレベル:
low(高確信度のバグのみ)〜high(網羅的にチェック)で指摘の粒度を調整 --commentフラグ:GitHub PRのインラインコメントとして指摘を直接投稿--fixフラグ(v2.1.152〜):指摘箇所を自動修正して作業ツリーに反映
使い方
基本:ローカルでレビュー
# 現在の差分をレビュー(デフォルトeffort: medium)
/code-review
# 高確信度のバグだけに絞る
/code-review --effort low
# 網羅的にチェック(指摘が増える)
/code-review --effort high日常のセルフレビューにはlow〜mediumが適切です。highにするとスタイル寄りの指摘も増えるため、マージ前の最終チェックに使うのがおすすめ。
GitHub PRにインラインコメントを投稿
# PRの差分をレビューし、GitHubにインラインコメントとして投稿
/code-review --commentこれを実行すると、GitHub上のPRにClaude Codeが直接コメントを付けてくれます。人間のレビュアーがコメントするのと同じ形式なので、指摘箇所がコードの該当行にひも付いて表示されます。
指摘を自動修正する
# レビュー結果をもとに自動修正
/code-review --fixv2.1.152で追加された--fixフラグ。指摘箇所を自動で修正し、作業ツリーに反映してくれます。ただし、修正内容は必ずgit diffで確認してからコミットしましょう。
実際にどんな指摘が出るのか
実際に使ってみると、以下のような指摘が出てきます。
- 異常系の未処理:「この
fetchのエラーハンドリングがない。ネットワークエラー時に例外が伝播する」 - 型の不一致:「この関数は
string | undefinedを返すが、呼び出し側でundefinedチェックがない」 - ロジックの抜け漏れ:「この
switch文にdefaultケースがない。未知の値が来た時にサイレントに通過する」 - セキュリティリスク:「ユーザー入力がサニタイズされずにSQLクエリに渡されている」
- 命名の改善(effort highの場合):「変数名
dよりdataの方が可読性が高い」
特に異常系の考慮漏れは、自分のコードでは見落としやすい典型的なバグ。「正常系は動くけどエッジケースで壊れる」パターンをAIが拾ってくれるのは、実用上かなり助かります。
全部鵜呑みにしない ― 取捨選択のコツ
SNSでも「指摘を全部受け入れるとコードが冗長になった」という声があります。AIレビューは万能ではなく、取捨選択は人間の仕事です。
受け入れるべき指摘
- 未処理のエラーケース(try-catchの欠落、nullチェック漏れ)
- セキュリティリスク(SQLインジェクション、XSS、認証バイパス)
- 明らかなロジックバグ(off-by-one、条件分岐の誤り)
スルーしてもいい指摘
- 好みレベルの命名変更(チームの規約に沿っているなら不要)
- 過剰な防御的プログラミングの提案(型システムで保証されている箇所のnullチェック追加など)
- プロジェクトの文脈を無視した「教科書的」な改善提案
判断基準はシンプルで、「この指摘を無視した場合、本番で問題が起きる可能性があるか?」。YESなら対応、NOなら見送りでOKです。
チームのレビュー観点をカスタマイズする
プロジェクトルートにREVIEW.mdを置くと、Claude Codeがレビュー時にその内容を参照してくれます。チーム固有のルールを反映させたい場合に便利です。
# REVIEW.md(例)
## 必須チェック
- 認証・認可の漏れ
- N+1クエリ
- 環境変数のハードコード
## スキップ
- テストコードのスタイル指摘
- ドキュメントのみの変更Claude Codeの活用を深める関連記事
- Claude Codeとは?AI搭載のコーディングアシスタントを徹底解説 – /code-reviewの前提知識としてClaude Codeの基本から知りたい方に
- GitHub IssuesにClaude Codeを導入する方法|AIでバグ修正・コードレビューができる仕組みとは? – Claude Codeをチーム開発に組み込む応用例
- 「それ、上げちゃダメ!」GitHub管理で絶対守るべきセキュリティルールと対処法 – PRレビュー文化の基盤となるGitHubセキュリティ
- GitHub Copilot日本語サイトが正式オープン!Free/Pro/Pro+全プラン徹底比較【2025年】 – Claude Code以外のAIレビューツールとの比較に
まとめ:AIレビューは「人間のレビューの前座」として最強
/code-reviewはClaude Codeのバグ検出特化レビューコマンド(v2.1.147で刷新)- effortレベルで指摘の粒度を調整。日常は
low〜medium、マージ前はhigh --commentでGitHub PRにインラインコメントを直接投稿できる--fixで指摘箇所を自動修正。ただしgit diffで確認してからコミット- 指摘の取捨選択は人間の仕事。「本番で問題が起きるか?」を基準に判断する
/code-reviewは人間のレビュアーを置き換えるものではなく、「人間がレビューする前にAIが下見しておく」ためのツールです。明らかなバグやエラーハンドリング漏れをAIが先に拾っておけば、人間のレビュアーはロジックや設計の議論に集中できる。PRを出す前に/code-reviewを1回走らせる ― その習慣だけで、レビューの質と速度が変わります。
