Claude Code /simplifyコマンド — /code-reviewとの役割分担
Claude Codeの/simplifyは、コードの再利用性・簡素化・効率・抽象度だけをレビューして直すコマンドです。バグ検知を担う/code-reviewとの役割分担と、両者が分離・統合を繰り返してきた経緯を確認します。
/simplifyは、変更したコードを「正しく動くか」ではなく「もっと簡潔に書けないか」という観点だけでレビューし、見つかった指摘をその場で作業ツリーに適用するコマンドです。バグ検知は/code-reviewが担当します。この2つは名前が似ていて、しかも過去に統合・分離を繰り返してきたため、いつどちらを使うべきかが分かりにくくなっています。
/simplifyは何を見るコマンドか
/simplifyを実行すると、4つのレビューエージェントが並列で動きます。
- 再利用: 既存のヘルパー関数・ユーティリティで代替できる重複コードが無いか。同じロジックを複数箇所に書くと、片方だけ直して片方を直し忘れるバグの温床になります
- 簡素化: 過剰に複雑な実装をより単純な形に書き直せないか。深いネスト・不要な中間変数・冗長な条件分岐が主な対象です
- 効率: 無駄な計算・冗長な処理が無いか。同じ値を何度も再計算していないか、不要なデータのコピーが発生していないかを見ます
- 抽象度(altitude): 変更が適切な抽象化の水準に置かれているか。今後誰も使わないような過剰な汎用化になっていないか、逆に決め打ちが強すぎて次の変更で書き直しが必要にならないかを判定します
見つかった指摘は、レビュー後に自動で作業ツリーへ適用されます。/code-reviewのように--fixフラグを別途渡す必要はありません。「見つけて直す」までが1コマンドで完結する設計です。
/simplify引数を渡さない場合は、直近の変更(ブランチのアップストリームより先のコミットと未コミットの変更)が対象になります。特定のファイルパスやPR番号を渡せば、対象を絞り込めます。
/simplifyと/code-reviewの役割分担
同じ「レビュー系コマンド」でも、見ているものと既定の挙動が違います。
| 観点 | /code-review | /simplify |
|---|---|---|
| 検出対象 | /code-review正しさのバグ・ロジック誤り・回帰 | /simplify再利用漏れ・簡素化余地・効率・抽象度のズレ |
| 修正の適用 | /code-review既定では適用しない(--fixを付けたときのみ) | /simplify既定で適用する |
| レビューの深さ調整 | /code-reviewlow〜maxのeffort levelを指定可能 | /simplify効果レベルの指定は無く、常に4エージェント並列 |
| クラウドでの深掘り | /code-reviewultraでultrareviewへエスカレート可能 | /simplifyultraへのエスカレートは無い |
| 対象指定 | /code-reviewパス・PR番号・ブランチ名・main...my-featureのようなref range | /simplifyパスまたはPR参照 |
| PRへのコメント投稿 | /code-review--commentフラグで対応 | /simplify案内なし(作業ツリーへの適用のみ) |
/reviewは/code-reviewだけのエイリアスで、/simplifyのエイリアスではありません。似た名前のコマンドが並んでいますが、別名を持つのはバグ検知側のコマンドだけという点も覚えておくと混同を防げます。/review自体もv2.1.223より前は別物で、GitHubのプルリクエストを1パスで読み取り専用にレビューする独立したコマンドでした。v2.1.223で/code-reviewのエイリアスに統合されており、/simplifyの改名・分離とは別の経路をたどってきています。3つのコマンド名が絡む変遷なので、バージョンをまたいだ手順書やスクリプトを見るときは、対象バージョンでの実際の挙動を確認する価値があります。
バグを探したいときは/code-review、動いているコードをもっと整理したいときは/simplifyという使い分けです。/code-reviewの実行経路(ローカル・GitHub Actions・管理Code Review機能・ultrareview)の詳しい比較はClaude Codeコードレビューにまとめています。
なぜ自動修正はクリーンアップ専用に切り出されたのか
/code-reviewが指摘を作業ツリーに適用するには--fixという明示的なフラグが要ります。一方/simplifyは既定で適用します。この非対称は、2つのコマンドが見ている対象の性質差を反映したものです。バグの指摘は誤検知のリスクを常に抱えるため、確認なしの自動適用は事故につながりかねません。再利用漏れ・簡素化・効率・抽象度の指摘は、コードの挙動そのものを変えないリファクタリングが中心のため、自動適用してもロジックが壊れるリスクは相対的に小さくなります。
v2.1.152からv2.1.153までは、バグ検知と自動適用が/code-review --fixという1つのコマンドに同居していました。この同居を解いたのがv2.1.154で、バグは確認してから直す、クリーンアップは確認せず直す、という線引きになりました。誤検知の許容度が違う2種類のレビューを1つのコマンドに詰め込むより、それぞれに適した既定動作を持つ別コマンドへ分けたほうが、実運用での事故は減らせます。
/simplifyと/code-reviewは分離・統合を繰り返してきた
2つのコマンドの関係は、リリースを追うと3回変わっています。単純にどちらか一方が新しいわけではありません。
| バージョン | /simplifyの状態 |
|---|---|
| v2.1.63 | /simplifyの状態/simplifyと/batchが公式の同梱コマンドとして追加(それまで各自が.claude/commands/で自作していた系統が公式装備に) |
| v2.1.147 | /simplifyの状態/simplifyが/code-reviewに改名。効果レベル指定でバグを報告する機能になり、旧来の「クリーンアップして直す」挙動は削除された |
| v2.1.152 | /simplifyの状態/simplifyが復活し、内部で/code-review --fixを呼び出すだけのエイリアスとして動作 |
| v2.1.154 | /simplifyの状態/simplifyが独立したコマンドに再分離。バグ検知を含まない、4エージェント並列のクリーンアップ専用レビューになった(現行の挙動) |
v2.1.147で一度/simplifyという名前自体が消え、/code-reviewに一本化されています。その後v2.1.152で名前が復活したものの中身は/code-review --fixと完全に同じで、実質的にはエイリアスでした。今のように「バグは探さず、再利用・簡素化・効率・抽象度だけを見る」という独立した役割を持つようになったのはv2.1.154からです。バグ検知機能を/simplify向けにスクリプト化していた場合は、/code-review --fixに切り替える必要があります。この移行の経緯はClaude Code v2.1.152でも確認できます。
v2.1.152の公式changelogを見ると、当時の/code-review --fixが拾う指摘として「reuse, simplification, and efficiency(再利用・簡素化・効率)」という3つの観点が明記されています。この3つは、v2.1.154で独立した/simplifyが引き継いだ軸とほぼ重なります。つまり現在の4観点のうち3つは、コマンドが分離される前から/code-review --fixの一部として既に存在していたことになります。新しく加わったのは「抽象度(altitude)」の観点で、これはバグ検知から完全に切り離された/simplifyだからこそ独立した基準として持てるようになったと言えます。
どちらを先に使うべきか
コードを書いたその場では、まず/simplifyを通すと手戻りが少なくなります。重複したヘルパーや過剰な抽象化はこの段階で削れる分、後から/code-reviewでバグを探すときのノイズが減ります。逆に、PRを出す直前やマージ判断のタイミングでは/code-review(必要ならultra)を通し、ロジックの誤りや回帰が無いかを確認します。両方を1回のセッションで順番に流す運用も難しくありません。
/simplify
/code-reviewなお/code-reviewをバックグラウンドの--fixで走らせた場合、編集はセッションのチェックポイントの外側で適用されるため/rewindでは戻せず、取り消すにはgitを使う必要があります。適用された修正を戻したくなったときは、まずgitで差分を確認する習慣にしておくと安全です。
CIやスケジュールタスクから無人実行する場合の注意
/simplifyは既定で修正を適用するコマンドです。人が確認する前提のインタラクティブなセッションで使う分には問題になりませんが、スケジュールタスクやCIパイプラインから無人で呼び出すと、レビュー担当者の目を通さないままコードが書き換わります。/code-reviewは--fixを明示的に付けない限り指摘を提示するだけで終わるため、無人実行での安全側の既定値という意味では/code-reviewの方が保守的です。/simplifyをCIに組み込みたい場合は、適用結果をそのまま既存ブランチへコミットするのではなく、いったん別ブランチやPRとして出力してから人がレビューする経路を挟む運用が無難です。
まとめ
/simplifyは再利用・簡素化・効率・抽象度の4観点だけを見て、見つけた指摘をその場で適用するクリーンアップ専用コマンドです。バグ検知は/code-reviewの役割で、この線引きはv2.1.154で確定しました。それ以前は/simplifyという名前がバグ検知コマンドを指していた時期(v2.1.147以前)や、/code-review --fixの単なるエイリアスだった時期(v2.1.152〜153)もあり、同じコマンド名でも版によって挙動が違う点には注意が必要です。日常の実装直後には/simplify、PR直前やマージ判断には/code-reviewという使い分けが実務での落としどころです。CIやスケジュールタスクから無人実行する場合は、/simplifyが既定で修正を適用する点を踏まえて、コミット前に人の目を挟む経路を用意しておくと安全です。
よくある質問
/simplifyは修正を自動で適用しますか
はい。/code-reviewと違い--fixフラグは不要で、見つかった指摘は既定で作業ツリーに適用されます。適用前に指摘内容だけを確認したい場合でも、それを止めるオプションは案内されていません。
/simplifyでバグも一緒に検知できますか
v2.1.154以降はできません。バグ検知は/code-reviewが専任で担当します。v2.1.152〜153では/simplifyが内部で/code-review --fixを呼んでいたためバグも検知していましたが、現行版ではその挙動は削除されています。両方を確認したいときは、/simplifyの後に/code-reviewを続けて実行してください。
/simplifyの適用結果を取り消せますか
公式ドキュメントは/simplify自体の取り消し手順を明記していませんが、/code-reviewのバックグラウンド--fixが適用した編集はチェックポイントの対象外で/rewindでは戻せず、gitでの取り消しが必要と案内されています。同様に振る舞う可能性があるため、適用後の差分はまずgitで確認してください。
/simplifyに対象を絞って実行できますか
できます。引数無しなら直近の変更(ブランチのアップストリームより先のコミットと未コミットの変更)が対象ですが、ファイルパスやPR番号を渡せば対象を絞り込めます。
古いバージョンの手順書やブログ記事で/simplify=バグ検知と書かれていました。今も正しいですか
v2.1.154より前の情報であれば、その時点では正しかった可能性があります。現在使っているClaude Codeのバージョンがv2.1.154以降なら、その情報は古いままなので参考になりません。claude --versionでバージョンを確認すると、手元の挙動がどちらに該当するか判断できます。
effort levelを指定して/simplifyのレビュー精度を上げられますか
公式ドキュメントには/simplifyのeffort level指定は記載されていません。low〜maxのeffort levelで深さを調整できるのは/code-review側の機能です。/simplifyは常に同じ4エージェント構成でレビューする設計です。