はじめに
「コードレビューを毎回手動でやっているけど、見落としが多い…」
「PR前にもっとコードを磨きたいけど、時間がない」
「セキュリティの観点でのレビューが甘い気がして不安」
こんな悩みを抱えたことがある方は多いのではないでしょうか。
Claude Codeには、コードレビューのプロセスをほぼ丸ごと自動化できる4つの専用コマンドが用意されています。
| コマンド | 主な役割 |
|---|---|
/code-review | バグ検出・品質改善（最も網羅的） |
/simplify | コード品質の最終磨き上げ |
/security-review | セキュリティ脆弱性の検出 |
/verify | 実際のアプリ動作で変更を確認 |
これらを組み合わせることで、人間のレビュアーが見落としがちな点を自動的に網羅し、より安全・高品質なコードをPRに出せるようになります。
この記事では各コマンドの詳細と実践的な使い方を解説します。
この記事で分かること
- 4つのレビュー系コマンドの役割と違い
/code-reviewの努力レベル（low〜ultra）の使い分け方/simplifyが並列で実行する4つのレビュー観点/security-reviewが検出できる脆弱性の種類/verifyでアプリを実際に起動して確認する方法- 4コマンドを組み合わせた実践的なワークフロー
こんな人におすすめ
- Claude Code のコードレビュー機能を使い始めたい方
- PR前のチェックを効率化したい開発者
- セキュリティチェックを自動化したい方
- 「動くけど汚いコード」を素早く磨きたい方
コードレビュー系コマンドの全体像
まず4つのコマンドの役割分担を把握しましょう。
変更コード
│
├── /code-review ← バグ検出 + 品質改善（最も網羅的）
├── /simplify ← 品質磨きのみ（バグは探さない）
├── /security-review ← セキュリティ脆弱性に特化
└── /verify ← 実際にアプリを動かして動作確認| コマンド | バグ検出 | 品質改善 | セキュリティ | 動作確認 | 自動修正 |
|---|---|---|---|---|---|
/code-review | ✅（主目的） | ✅ | △ | - | --fix で可 |
/simplify | - | ✅（主目的） | - | - | デフォルトで自動 |
/security-review | - | - | ✅（主目的） | - | - |
/verify | - | - | - | ✅（主目的） | - |
この4つは競合するものではなく、役割が異なる補完的なツールです。目的に応じて使い分けるか、後述のワークフローのように組み合わせるのが最も効果的です。
/code-review：バグ検出と品質改善の総合レビュー
/code-review は4コマンドの中で最も網羅的なレビューを行うコマンドです。現在のブランチの差分（diff）を対象に、バグ・品質・効率性・再利用性などを総合的にチェックします。
基本的な使い方
/code-review # 現ブランチの変更全体を対象
/code-review src/user.ts # 特定ファイルのみ
/code-review 123 # GitHub PR番号を指定努力レベルで深さを調整する
/code-review の最大の特徴は、努力レベルを指定してレビューの深さを調整できることです。
/code-review --effort low # 高確度な指摘のみ・少数
/code-review --effort medium # バランス型（デフォルト）
/code-review --effort high # 広範囲の指摘
/code-review --effort max # 最大範囲（時間がかかる）
/code-review --effort ultra # クラウドで深い多エージェントレビュー| 努力レベル | 速度 | 指摘の範囲 | 使いどころ |
|---|---|---|---|
low | 速い | 高確度な重大問題のみ | 軽微な変更・急ぎのチェック |
medium | 普通 | バランス型（デフォルト） | 通常のPR前チェック |
high | 遅め | 広範囲 | 複雑な変更・重要機能の修正 |
max | 遅い | 最大範囲 | 大型リリース前・品質重視 |
ultra | 数〜数十分 | クラウド多エージェント | 重要なコアロジック・最終確認 |
日常使いのおすすめ: 通常のコミット前なら
medium（省略時のデフォルト）、リリース前の重要な変更ならhighまたはmaxが適切です。ultraはクラウド上の複数エージェントが協力してレビューするため最も深い分析ができますが、$5〜$25 USD のコストがかかります。重要な場面に絞って使いましょう。
オプションで動作を拡張する
/code-review --fix # 指摘された問題を自動修正
/code-review --comment # GitHub PRにインラインコメントを投稿
/code-review --fix --comment # 修正 + コメント投稿の両方--fix オプション：指摘した問題をそのままコードへ自動適用します。すべての変更をレビューしてから採用するかどうか判断しましょう。意図しない変更が含まれる場合があります。
--comment オプション：GitHub PR に対して、指摘内容をインラインコメントとして投稿します。PR番号を指定して使います。
/code-review 123 --comment # PR #123 にインラインコメントを自動投稿チームでのコードレビューに組み込むと、レビュアーへの事前情報提供として機能します。
レビューされる内容
/code-review は主に以下の観点でレビューします：
- 正確性バグ: ロジックの誤り・エッジケースの欠落・型の不整合
- 再利用性: コードベース内の既存実装を活かせているか
- 簡潔化: 冗長な実装・より短く書ける箇所
- 効率性: パフォーマンス上の問題・不要な処理
/simplify：コード品質の最終磨き上げ
/simplify はバグを探すのではなく、「動いているコードをより良いコードに」磨き上げることに特化したコマンドです。
/code-review との違い
/simplify | /code-review | |
|---|---|---|
| バグ検出 | しない | する（主目的） |
| 品質磨き | する（主目的） | する（バグ検出のおまけ） |
| 修正の自動適用 | デフォルトで自動 | --fix オプション時のみ |
| PR コメント投稿 | なし | --comment で可能 |
| 速度 | 軽量・高速 | 網羅的な分、やや時間がかかる |
4エージェントが並列でレビュー
/simplify の内部では、4つの専門エージェントが並列で同時に実行されます。
| エージェント | チェック内容 |
|---|---|
| 再利用チェック | コードベース内の既存ヘルパー・重複コードの見落とし |
| 簡潔化 | 不要な複雑さ・より単純に書ける箇所 |
| 効率性 | パフォーマンス最適化の機会 |
| 抽象化レベル | 変更が適切なレイヤーに存在しているか |
4つの観点を同時に処理するため、単一のレビューでは見落としがちな問題も検出しやすくなっています。チェック後はそのまま修正をコードへ自動適用します。
基本的な使い方
/simplify # 現ブランチの変更全体を対象
/simplify src/foo.ts # 特定ファイルのみ
/simplify 123 # GitHub PR番号を指定適用された変更は git diff で必ず確認しましょう。意図しない変更が含まれていた場合は git checkout -- <ファイル名> で元に戻せます。
使いどころ
- テストが全て通過した後、PRを出す直前の最終磨き
- リファクタリング後の効率化チェック
- 「動いているが汚いコード」のクリーンアップ
注意: バグが潜んでいる可能性があるときは、先に
/code-reviewを実行しましょう。バグのあるコードをきれいにしても問題は解決しません。
/security-review：セキュリティ脆弱性の専門レビュー
/security-review は、現在のブランチの変更を対象にセキュリティの観点に特化したレビューを行うコマンドです。
検出できる主な脆弱性
| カテゴリ | 具体例 |
|---|---|
| インジェクション系 | SQLインジェクション・コマンドインジェクション・LDAPインジェクション |
| XSS | 入力値の不適切なエスケープ・DOMベースXSS |
| 認証・認可 | 不適切なアクセス制御・セッション管理の欠陥 |
| 機密情報漏洩 | ハードコードされたシークレット・ログへの機密出力 |
| 暗号化 | 脆弱なアルゴリズムの使用・不適切な鍵管理 |
| 依存関係 | 古いライブラリ・既知の脆弱性を持つパッケージ |
基本的な使い方
/security-review # 現ブランチの変更全体を対象
/security-review src/auth.ts # 特定ファイル（認証関連など）
/security-review 123 # GitHub PR番号を指定/code-review との役割分担
/code-review もある程度のセキュリティチェックを含みますが（表の △）、/security-review はセキュリティ観点に特化しているため、より詳細な脆弱性分析を行います。
一般的な変更 → /code-review で十分
認証・決済・個人情報処理を含む変更 → /code-review + /security-review を両方実行レポートのみで自動修正は行わない
/security-review は検出した問題を報告するだけで、コードの自動修正は行いません。セキュリティ上の修正は必ず人間が内容を理解した上で行うという設計思想によるものです。検出された問題は一つずつ内容を確認してから手動で修正しましょう。
/verify：実際のアプリ起動で動作を確認
/verify は他の3コマンドとは性質が異なります。コードを静的に分析するのではなく、実際にアプリを起動して動作を確認するコマンドです。
なぜ実際に動かすのか
テストが通過していても、実際のアプリを動かすと問題が発覚することがあります。
- 環境変数や設定ファイルの問題
- 複数コンポーネントの統合時のエラー
- UIの見た目や操作感の問題
- パフォーマンス上の問題（レイテンシ・メモリ使用量など）
静的解析では検出できないこれらの問題を、/verify は実際にアプリを起動することで発見します。
基本的な使い方
/verify # 現ブランチの変更を確認
/verify 123 # PR #123 の変更を確認使いどころ
| シーン | 内容 |
|---|---|
| PRのマージ前 | 変更が意図通りに動作するか最終確認 |
| バグ修正後の確認 | 修正が正しく適用されているか確認 |
| 新機能のテスト | 実装した機能が正常に動作するか確認 |
| リグレッションチェック | 既存機能が壊れていないか確認 |
/run との違い
似たコマンドに /run がありますが、役割が異なります。
/verify | /run | |
|---|---|---|
| 目的 | PRや変更内容の検証 | 開発中の随時動作確認 |
| 使うタイミング | PR前・バグ修正後 | 実装しながら随時 |
実践ワークフロー：4コマンドの組み合わせ
4コマンドを効果的に組み合わせるワークフローを、シーン別に紹介します。
基本ワークフロー（個人開発・日常コミット向け）
実装
↓
テスト通過
↓
/code-review ← バグ・品質を総合チェック
↓
（バグがあれば修正して再テスト）
↓
/simplify ← コードの最終磨き上げ
↓
git commit & push最小限の2コマンドセットです。時間が限られている場合や軽微な変更には、/code-review だけでも十分な場合があります。
安全重視ワークフロー（セキュリティが重要な変更向け）
実装
↓
テスト通過
↓
/code-review --effort high ← バグ・品質を深くチェック
↓
/security-review ← セキュリティ脆弱性を念入りにチェック
↓
（指摘を手動で確認・修正）
↓
/simplify ← 最終磨き上げ
↓
/verify ← 実際に動かして最終確認
↓
git commit & push認証・決済・個人情報処理などセキュリティが重要な変更に適したフローです。
チーム開発ワークフロー（PRを出す場合）
実装
↓
テスト通過
↓
/code-review ← バグ・品質チェック
↓
/simplify ← 品質磨き
↓
/verify ← 動作確認
↓
PR作成
↓
/code-review 123 --comment ← PRにインラインコメントを自動投稿
↓
チームメンバーによるレビュー・マージ--comment オプションで PR にインラインコメントを自動投稿することで、チームメンバーのレビューを補完できます。AIの指摘をレビュアーが確認する形で、レビューの質と効率を両立できます。
シチュエーション別：どのコマンドを使うか
よくある開発シナリオ別に、適切なコマンドの組み合わせを紹介します。
ケース1：小さなバグ修正
/code-review --effort low # 高確度の問題だけ素早くチェック軽微な変更に対して網羅的なレビューをかけると時間のムダです。low で十分な場合がほとんどです。
ケース2：新機能の実装が完了した
/code-review # 総合的なバグ・品質チェック
/simplify # 品質磨き
/verify # 動作確認新機能は動作確認まで含めた3コマンドセットが理想です。
ケース3：認証機能・決済処理の修正
/code-review --effort high # 深めのバグ・品質チェック
/security-review # セキュリティ脆弱性を念入りにチェック
/simplify # 最終磨きセキュリティが重要な変更には必ず /security-review を追加しましょう。
ケース4：大型リリース前の最終確認
/code-review --effort max # 最大範囲のチェック
/security-review # セキュリティチェック
/simplify # 品質磨き
/verify # 動作確認全コマンドを投入する完全なフローです。
よくある質問（FAQ）
Q. /code-review と /simplify はどちらを先に使うべき？
必ず /code-review が先です。バグが潜んでいるコードをきれいにしても問題は解決しません。バグを修正してから /simplify で磨き上げましょう。
Q. /simplify が自動適用した変更が意図しないものだった場合は？
git diff で変更内容を確認し、不要な変更は git checkout -- <ファイル名> で元に戻せます。心配な場合は /simplify の実行前に git stash でセーフポイントを作っておく方法もあります。
Q. 毎回全コマンドを使う必要がある？
不要です。変更の重要度に応じて使い分けましょう。
| 変更の種類 | 推奨コマンド |
|---|---|
| 軽微な変更・バグ修正 | /code-review --effort low のみ |
| 通常の機能追加 | /code-review → /simplify |
| セキュリティ重要な変更 | /code-review → /security-review → /simplify → /verify |
| 大型リリース前 | 全コマンド（--effort max） |
Q. これらのコマンドはスキル（Bundled Skill）として実装されているの？
はい。4コマンドすべてがClaude Code のスキル（★マーク付き）として実装されています。スキルの仕組みについては Claude Skills完全ガイド で詳しく解説しています。
Q. --effort ultra と /ultrareview は同じ？
実質的に同じ機能を指します。/ultrareview は独立したコマンドとして実装されており、クラウド上の複数エージェントが協力してレビューを行います。所要時間は約5〜10分、$5〜$25 USD のコストがかかるため、重要な場面に絞って使いましょう。
まとめ
Claude Code の4つのレビュー系コマンドを振り返りましょう。
| コマンド | 役割 | 自動修正 | 使うタイミング |
|---|---|---|---|
/code-review | バグ検出 + 品質改善（総合） | --fix で可 | テスト通過後、最初に使う |
/simplify | 品質磨き上げ（バグは探さない） | デフォルトで自動 | /code-review の後、PR前の最終磨き |
/security-review | セキュリティ脆弱性検出 | なし（報告のみ） | セキュリティ重要な変更に追加 |
/verify | 実際のアプリで動作確認 | なし（確認のみ） | 動作確認が必要な変更に追加 |
まず試すならこの2コマンド:
/code-review ← バグを探す
/simplify ← コードを磨くこれだけでも、見落としやすいバグの検出と「動くが汚いコード」の問題を大幅に減らせます。セキュリティが重要な変更には /security-review を、動作確認が必要な場合は /verify を追加していきましょう。
コードレビューの自動化は、品質向上だけでなくレビュアーの認知負荷を減らし、本当に重要な判断に集中する時間を作ることにも繋がります。ぜひ日々の開発フローに取り入れてみてください。
関連記事：
- 【2026年6月最新版】Claude Code全90コマンド以上徹底解説｜全コマンドの一覧はこちら
- Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌
- 【2026年版】Claude Code サブエージェント活用術｜並列実行で作業を最大4倍速にする方法
- 【まとめ記事】Claude Code完全攻略ロードマップ｜全記事まとめ
コメント