blog
AIブログ
Claude Codeのレビュー系コマンド完全ガイド|/code-review /review /security-review【2026年10月更新】
文:クリスタルメソッド編集部 監修:河合 継(代表取締役)
Claude Codeには、コードの品質や安全性をチェックするレビュー系コマンドが複数あります。似ているようで役割が違い、使い分けが分かりにくいものです。本記事で「何を・いつ・実例」を整理します。
各コマンドの使い方
/code-review
何を:現在のgit diffを対象に、バグや論理的誤りといった正確性の問題と、コードの再利用・簡略化・効率化の観点からレビューを実行するコマンドです。`–fix`フラグで指摘をワーキングツリーへ自動適用、`–comment`フラグでGitHub PRにインラインコメントとして投稿、`ultra`サフィックスでクラウドサンドボックスを使ったディープレビューに切り替えられます。
いつ:PRを出す直前にローカルで素早くバグチェックを走らせたいとき、またはレビュアーへ渡す前に機械的な指摘を自動修正まで完結させたい場面で使います。
実例:`/code-review –fix` を実行すると、diffに含まれるバグや非効率なロジックが検出され、修正内容がそのままワーキングツリーのファイルへ書き込まれます。`/code-review ultra` を実行すると、クラウドサンドボックス上で複数エージェントが並列動作し、より深い静的解析とリファクタリング提案がセッションに返ってきます。
コツ:比較的新しいバージョンはバグ検出と簡略化整理が `/code-review` と `/simplify` に役割分離されたため、バグ修正だけ当てたい場合は `/code-review –fix`、コード整理だけ当てたい場合は `/simplify` と使い分けると意図しない変更の混入を防げます。
下は、小さなサンプルアプリに「削除ボタン」を追加した未コミットの変更に対して /code-review を実行した実際の画面です(2026年10月5日、Claude Code v2.1.289で撮影)。レビューはバックグラウンドのエージェントとして動き、16秒ほどで終わりました。問題点が行番号つきで2つ挙げられ、修正案と「この内容で修正しましょうか?」という確認まで日本語で返ってきます。


/review
何を:/code-review の別名で、中身は同じです。同じeffort(low〜max・ultra)と引数(--fix・--comment・PR番号など)を受け付けます。v2.1.223より前は、GitHubのPRを1回だけ読み取り専用でレビューする別のコマンドだった(出典:Commands、2026年10月23日確認)。
いつ:/code-review と同じ。軽い・重いの使い分けはありません。
実例:/review 1234 でPR 1234を、/review だけで今のブランチの変更をレビューします。
下は、検索機能を追加したサンプルのブランチ(SQLを文字列の連結で組み立て、データベースの接続を閉じ忘れた変更)で /review を実行した実際の画面です(2026年10月23日、Claude Code v2.1.309で撮影)。入力した /review は別名のため /code-review としてバックグラウンドで動き、16秒ほどで6件の問題(バグ3件・整理3件)が行番号つきで示され、最後に修正してよいかを確認されました。スマホでも読めるよう、画面を上下2枚に分けています。


/security-review
何を:現在ブランチの未コミット・未マージの変更を対象に、セキュリティ脆弱性に特化した静的解析を行うコマンドです。SQLインジェクション・認証バイパス・機密データ露出・クロスサイトスクリプティングなど、OWASPカテゴリに沿ったリスクを検出してリスクレベルとともに報告します。
いつ:セキュリティ要件が厳しいAPIエンドポイントや認証ロジックを変更したあと、本番マージ前の最終ゲートチェックとして実行するのに最適です。
実例:`/security-review` を実行すると、git diffに含まれるユーザー入力のサニタイズ漏れやハードコードされたシークレットが列挙され、各問題にCRITICAL/HIGH/MEDIUMのリスクレベルが付与されます。たとえばSQLクエリへの文字列連結を検出した場合は、プリペアドステートメントへの書き換え例も合わせて提示されます。
コツ:このコマンドはdiff範囲のみを解析するため、既存コードに潜む脆弱性は対象外になる点を理解した上で、CI/CDの差分チェックステップとして組み込むと効果的です。
同じブランチで /security-review を実行した画面です(2026年10月23日、v2.1.309で撮影)。脆弱性を探すエージェントのあとに誤検知を除くエージェントが動き、SQLインジェクション1件が「Severity: High」「Confidence: 8/10」として、攻撃の入力例と修正案つきで報告されました。


/simplify
何を:変更されたコードを対象にリファクタリング機会を検出し、修正を自動適用するコマンドで、既存ヘルパーの再利用・ロジックの簡略化・処理効率の改善・抽象レベルの適切さの4観点を4エージェントが並列に担当します。比較的新しいバージョンはバグ検出を行わない整理専用レビューとなっており、バグ修正は `/code-review` に委ねる設計になっています。
いつ:機能実装が完了したあとのコードクリーンアップフェーズや、レガシーコードを段階的にリファクタリングしたいときに使います。
実例:`/simplify src/utils/formatter.ts` のようにパスを渡すと、そのファイルの変更箇所だけを対象に4エージェントが並列レビューし、冗長なforループをArray.reduce()に書き換えるといった整理が自動適用されます。`/simplify #42` のようにPR番号を渡せば、リモートPRの差分を取得してローカルに整理を適用することもできます。
コツ:比較的新しいバージョン前のバージョンでは `/simplify` は `/code-review –fix` と等価だったため、バージョンをチーム全員が揃えないとCIでの動作が変わる点に注意してください。
同じブランチで /simplify を実行した画面です(2026年10月23日、v2.1.309で撮影)。4つのレビューの指摘が、件数の数え方・不要なループ・検索クエリのプレースホルダー化・接続の閉じ忘れの4つの修正にまとめられて作業ツリーへ直接反映され、使い捨てのデータベースで動作を確かめた結果と、見送った提案の理由も表示されました。コミットはされません。


/ultrareview
何を:クラウドサンドボックス上で複数エージェントを並列起動し、ローカルレビューでは捉えにくい深い構造的問題やパフォーマンスリグレッションまで掘り下げるディープコードレビューコマンドです。現在は `/code-review ultra` が推奨呼び出し形式となっており、`/ultrareview` はそのエイリアスとして残っています。
いつ:大規模なアーキテクチャ変更や、複数ファイルにまたがる複雑なリファクタリングを本番ブランチにマージする前の最終品質保証として使います。
実例:`/ultrareview` を実行すると、クラウドサンドボックスでコードがビルド・解析され、型安全性の崩れや循環依存の導入、パフォーマンスのボトルネックが詳細なレポートとして返ってきます。Pro・Maxプランは無料で3回使えます。3回はアカウントごとの1回限りで毎月は戻らず、以後は1回おおむね5〜25ドルの使用量クレジットがかかる(出典:ultrareview、2026年10月23日確認)。
コツ:無料枠3回はブランチ単位ではなく呼び出し回数で消費されるため、軽微な修正では `/review` や `/code-review` で済ませ、重要リリース直前の仕上げに温存しておくのが賢明です。
Claude Code・AIエージェントの業務導入をご検討の方は、自社での開発実例を公開しているクリスタルメソッドの無料相談をご利用ください。
レビューの前に変更内容を確かめるときは、差分・変更確認の使い方で解説しています。
よくある質問
/code-reviewと/reviewはどう使い分ければいい?
使い分けは不要です。/reviewは/code-reviewの別名で、同じeffortと引数を受け付け、結果も同じです。v2.1.223より前の/reviewは、GitHubのPRを1回だけ読み取り専用でレビューする別のコマンドでした。
REVIEW.mdとCLAUDE.mdは何が違う?
CLAUDE.mdはコーディングやドキュメント作成などタスク全般に共通する指示を書くファイル、REVIEW.mdはレビュー専用のガイダンス(重視したい観点やチームの規約など)を書くファイルです。リポジトリに置くことでレビューの精度をチーム基準に合わせてカスタマイズできます。
GitHub連携のコードレビュー機能はいくらかかる?
GitHub連携のCode Review(Team・Enterprise向け、2026年10月15日に一般提供)に1回あたりの定額はなく、レビューの深さ(Quick・Standard・Deep)や変更の大きさで変わります。プランの利用枠とは別に、使用量クレジットから組織に請求されます。/code-reviewなどのコマンドは普段の使用量として数えられます。
/security-reviewは他のレビューコマンドと同時に使ってよい?
セキュリティレビューは独立したステップとして単独で実行することを推奨します。一般的なコード品質のレビューとセキュリティ観点のレビューを混ぜずに分けて回すことで、指摘の見落としや優先度の混同を防げます。
次に読む:Claude Codeの検証ループとは?
コマンド構文リファレンス(実運用メモ)
本記事は2026年10月23日時点の内容に更新しています。以下は本文で紹介した各コマンドの実行例です。
/code-review
/code-review --fix
/code-review ultra
/review
/security-review
/simplify src/utils/formatter.ts
/simplify #42
/ultrareview
いずれも監修者・河合継が実運用の中で使用している構文で、詳細な使いどころは本文「各コマンドの使い方」セクションを参照してください。
REVIEW.md・CLAUDE.mdによるレビューのカスタマイズと料金(GitHub連携版Code Review)
ここまで紹介した5つは、ターミナルの/code-reviewのようにローカルでdiffをレビューするコマンド群です。これとは別に、GitHubのプルリクエストへ自動でインラインコメントを投稿する「Code Review」(Team/Enterpriseプラン向け、2026年10月15日に一般提供)があり、公式ドキュメントによるとリポジトリにCLAUDE.mdまたはREVIEW.mdを置くことでレビュー内容をカスタマイズできます。
- CLAUDE.md:レビュー専用ではなく、Claude Codeの全タスクで使われる共有プロジェクト指示。ここに書かれたルールに新しく違反した変更は、Nit(軽微な指摘)としてフラグが立ちます。
- REVIEW.md:レビュー専用のガイダンスファイル。リポジトリルートに置くと、レビューを担当する全エージェントのシステムプロンプトへ最優先の指示として直接注入され、デフォルトの重大度基準や報告方法(Nitの件数上限、特定パスのスキップ、リポジトリ固有のチェック項目など)を上書きできます。
結果には3段階の重大度が付けられます。
| マーカー | 重大度 | 意味 |
|---|---|---|
| 🔴 | Important | マージ前に修正すべきバグ |
| 🟡 | Nit | 軽微な問題。修正する価値はあるがブロッキングではない |
| 🟣 | Pre-existing | コードベースに既に存在し、このPRで導入されたわけではないバグ |
PR上で@claude review(または@claude review once)とコメントすると1回だけレビューされ、以降のプッシュもレビューさせるには@claude review always、やめるには@claude review stopと書く(2026年7月の更新より前は@claude reviewだけで購読された)。料金はトークン使用量に応じた従量制で、1回あたりの定額はなく、レビューの深さ(Quick・Standard・Deep)や変更の大きさで変わり、プランに含まれる使用量とは別枠のUsage Creditsから請求される(出典:Code Review costs・pull requests、2026年10月23日確認)。組織の月次支出上限は管理者がadmin-settings/usageから設定できます。
どれをいつ使う?使い分けのポイント
レビュー系コマンドは目的で選び分けます。/code-review(/reviewは同じコマンドの別名)は差分の正確性のバグを見つけるコマンドで、作業の途中やプルリク前のチェックに使います。/security-reviewはSQLインジェクションや認証漏れなどセキュリティ脆弱性の発見に絞った専門コマンドで、本番リリース前や外部公開APIの確認時に選びます。/simplifyはレビューではなくリファクタリング寄りで、「コードが複雑すぎる・読みにくい」と感じたときに冗長な処理を整理する用途に使います。/ultrareviewは品質・セキュリティ・パフォーマンス・設計を横断した総合レビューで、重要機能の実装完了時や大規模PR時に使いますが、処理が重いです。迷ったら/code-review → /security-reviewの順に使い、大きな変更のマージ前だけ/ultrareviewを足す。
実運用でのレビューコマンドの使い方(一次情報)
当メディアの監修者・河合継はClaude Codeを3.5の時代から1年以上、実務で日次運用してきました。レビュー系コマンドについて、使い分け以上に効いた運用上のポイントを補足します。
- 軽いレビューを日常に、重いレビューは仕上げに。
/code-reviewのような軽量レビューはコミット前の習慣として日常的に回し、/ultrareviewのような重く課金もかさむ総合レビューは重要リリース直前に温存する、というメリハリが結局いちばんコスト効率が良かったです。 - AIのレビュー結果は「採否を人が決める」前提で使います。レビューコマンドは見落としを拾ってくれる一方で、無害な箇所を問題として挙げたり、逆に文脈依存の不具合を見逃すこともあります。指摘をそのまま適用せず、一件ずつ採否を判断する運用にしてから、手戻りが減りました。
- セキュリティレビューは公開前の独立ステップにします。品質レビューに混ぜず、外部公開・本番リリースの前に
/security-reviewだけを単独で走らせると、見るべき観点が絞られて精度が上がりました。
全96コマンドの一覧はClaude Codeスラッシュコマンド完全ガイドにまとめています。
まとめ
用途に合わせて使い分けることで、Claude Codeでの開発がさらに快適になります。まずは気になったコマンドを一つ試してみてください。
Claude Codeの全体像・仕組み・始め方は、Claude Codeとはでまとめて解説しています。
参考文献
Claude Code・AIエージェントの業務活用をご検討の方へ
クリスタルメソッドは、Claude Codeを日々の業務で使いながら、AIエージェント・社員AIの導入と開発効率化を支援しています。自社サイトの表示速度をAI社員(Claude Code)で12.89秒→2.03秒に短縮した実例も事例記事として公開しています。「自社の開発・業務にAIをどう組み込むか」といったご相談を承っています。
- 無料相談・お問い合わせ:ご相談はこちら
Read next
あわせて読みたい
-
Claude Code diff・差分・変更確認の使い方|実装者向け完全ガイド
Claude Code の /diff は、Claudeが各ターンで加えた変更をインタラクティブに確認できるビューアだ。上下キーで変更ファイルを選んでEnter...
-
Claude Code 検証ループとは?「できました」を信じない仕組みの作り方
Claude Codeの検証ループとは何か 公式ブログ「Building verification loops in Claude Code with skil...
-
Claude Code コマンド完全ガイド|スラッシュコマンド116個+CLIオプション+ショートカット一覧【2026年版】
Claude Code には 100個を超えるスラッシュコマンドがあり、長く使っていても「どの場面でどれを使うのか」は意外と掴みにくいものです。本ページでは全コ...
