Claude Code /simplifyコマンド — /code-reviewとの役割分担

/simplifyは、変更したコードを「正しく動くか」ではなく「もっと簡潔に書けないか」という観点だけでレビューし、見つかった指摘をその場で作業ツリーに適用するコマンドです。バグ探しは/code-reviewの仕事で、/simplifyは一切やりません。

名前が似ているうえに、この2つは過去に改名・統合・再分離を繰り返しました。古い手順書やブログの記述がそのまま通用しない場面があります。v2.1.287のClaude Codeで確認できる範囲と、公式ドキュメント・changelogの記述を突き合わせて、どちらをいつ使うかを判断できるようにします。

今のターンで直したいのはバグか、見通しの悪さか

迷ったら、直したい対象で選びます。

/simplifyの書式に載っているのは対象指定の[target]だけで、effort levelや--fix、ultraに相当する引数は出てきません。「無い」と断定できる根拠は見当たらないので、ここでは「書式に出てこない」とだけ書きます。/simplify --fixのように書く必要はなく、適用はコマンド自体の既定動作です。

/reviewが/code-reviewの別名なのは、v2.1.223でそうなったからです。それ以前の/reviewは、PRを1パスで読む独立したコマンドでした。ただしv2.1.186から201の間は、/code-review mediumと同じマルチエージェント方式でした。/simplifyには別名がありません。/code-reviewには、ローカル・GitHub Actions・管理機能・ultrareviewという実行経路があります。違いはClaude Codeコードレビューで扱っています。

4つのエージェントは何を見るか

/simplifyは4つのレビューエージェントを並列に走らせます。説明にある観点は、既存ヘルパーの再利用、簡素化、効率、変更が適切な抽象度に収まっているか、の4つです。各エージェントの内部の判定基準(どんなパターンを拾うか)は書かれていません。

この4つのうち、前の3つは過去の/code-review --fixの説明にも出てきた語です。v2.1.152のchangelogには、/code-review --fixが「reuse, simplification, and efficiency」の提案を出すと書かれています。抽象度(altitude)が加わったのは、v2.1.154で/simplifyがクリーンアップ専用レビューになってからです。

古い手順書の「/simplify」はいつの挙動か

v2.1.63から現在までの間に、/simplifyは3回意味が変わりました。手順書やスクリプトに書かれた/simplifyが、どの時期の挙動を前提にしているかを見分けるのが先です。

v2.1.152〜153の手順書に「/simplifyでバグを洗い出す」と書かれていたなら、当時は正しかったはずです。v2.1.147から151までは、改名で/simplify自体がありませんでした。v2.1.154以降は同じ操作でバグは出ません。バグ検知のつもりで/simplifyをスクリプトに組み込んでいた場合は、/code-review --fixへの切り替えが案内されています。v2.1.152時点の変更点はClaude Code v2.1.152にもあります。

手元のバージョンはclaude --versionで分かります。v2.1.287の環境で確認したところ、出力は次のとおりでした。

claude --version

2.1.287 (Claude Code)

同じ環境でclaude --helpを見ても、スラッシュコマンドの/simplifyや/code-reviewは一覧に出ません。これらはセッションの中で入力するコマンドで、CLIの引数ではないからです。シェルのスクリプトから呼びたい場合は、-pを使う非対話実行になります。

自動適用が既定なのはなぜ「クリーンアップ側」だけか

/code-reviewが指摘を作業ツリーに書き込むには--fixが要ります。/simplifyは何も付けなくても書き込みます。この非対称の理由は書かれていませんが、指摘の性質を考えると筋は通ります。バグの指摘は、検出が外れていたときに確認なしで書き換えると誤った修正を持ち込みます。クリーンアップの指摘は、挙動を変えない整理が中心です。ここまでは推測です。

確かな事実として言えるのは、v2.1.152〜153の同居期がv2.1.154で解消されたことと、その後の/simplifyの説明が「適用はするがバグは探さない」という形に固まっていることです。

適用結果を戻したいときは、git以外の手が効かない場合があります。checkpointingのページによると、サブエージェントの編集は多くの場合セッションのチェックポイントに記録されず、/rewindで戻せません。バックグラウンドの/code-review --fixの編集もこの扱いです。フォアグラウンドで走ったレビューの編集は、通常どおり/rewindで戻せます。/simplify自体について、同じ扱いになると明記した記述は見つかりませんでした。4つのエージェントが書き換える以上、同じ前提で、実行前にコミットか退避を済ませておく方が安全です。

コミットの直前に必ず通したいとき

v2.1.286以降、verifyまたはsimplifyという名前のスキルを自分で用意しておくと、Claude Codeのコミット手順がそのスキルを「コミットの直前に実行する」よう指示してくれます。skillsのページにある仕様です(v2.1.286のchangelogはverifyにしか触れていません。詳しくは後述します)。ここで見落としやすいのは、同梱の/simplifyにはこの働きがない点です。

ただし、2つの資料で書きぶりが食い違っています。skillsのページは「verifyまたはsimplifyという名前のスキル」と書いています。一方、v2.1.286のchangelogは「verifyという名前のスキルがあれば、コミットの直前に実行するよう伝える」としか書いておらず、simplifyには触れていません。simplifyでも働くかどうかは、skillsのページの記述に頼るしかありません。実際に効かせるつもりなら、新しいセッションでコミットを依頼し、Claudeがスキルを実行するかどうかを自分で見て確かめるのが確実です。

自分のsimplifyスキルを置くと、同梱の/simplifyは置き換わります。同名解決の表に、エンタープライズ・個人・プロジェクトのスキルは同名の同梱コマンドを置き換えるとあるためです。つまりコミット前の自動実行を選ぶと、同梱の4エージェント構成は手元では使えなくなります。置き換える内容は自分で書くことになります。

スキルの中身は、たとえば次のような最小形から始められます。以下は筆者が書いた例で、v2.1.287で実際に動かして確かめたものではなく、書式はskillsページの例(nameとdescriptionのfrontmatter)に合わせています。

---
name: simplify
description: コミット前に、変更したコードの重複・冗長な処理・過剰な抽象化を見直して直す
---
 
変更したファイルだけを対象に、次の点を確認して必要な修正を行う。
 
- 既存のヘルパーで置き換えられる重複がないか
- 不要な中間変数や深いネストがないか
- 変更の範囲を超えた抽象化をしていないか
 
バグの有無は判断しない。挙動を変える修正はしない。

コミットの指示から外れる変更は「ドキュメントまたはテストだけの変更」です。それ以外の変更では、コミットのたびにスキルが走ることになります。小さなコミットを何度も刻む作業スタイルだと、そのたびにレビューの時間とトークンがかかります。

無人実行の前に確かめておくこと

/simplifyは既定で書き換えます。人が見ているセッションなら差分をその場で確かめられますが、スケジュールタスクやCIの無人実行ではそうはいきません。/code-reviewは--fixを付けなければ指摘の提示で終わるので、無人運用の初期設定としては保守的です。

スケジュールタスクの/code-reviewには、ultraを付けないよう案内されています。スケジュールされたタスクはクラウドレビューを起動しないためです。/simplifyをスケジュールタスクで走らせる手順や挙動は、scheduled-tasksのページに載っていません。無人で回す場合は、別ブランチやPRに結果を出して人が読む経路を自分で用意する形になります。

2つを続けて流すときに/code-review側で起きること

/simplifyのあとに/code-reviewを続ける運用では、/code-review側の癖を知っておくと戸惑いません。

effort levelを書かずに/code-reviewを実行すると、直近に自分で入力したlowからmaxのレベルが再利用されます。前のセッションで入力したものでも同じです。再利用されるときは、Reusing high effort, the level you typed last timeのような通知が出ます。この挙動はv2.1.223からで、それより前はセッションの現在のeffortが使われました。レベルを一度も入力していないときも、セッションの現在のeffortです。-pの非対話実行で渡したレベルは、この記憶を更新しません。ultraはこの記憶を更新も参照もしません。

対象の指定にも注意が要ります。ultraを付けない場合、レベルとフラグの後ろの文字列はすべてレビュー対象として読まれます。/code-review /fix-issue 123と打っても、/fix-issueが別のスキルとして読み込まれるわけではなく、対象を示す文字列として扱われます。v2.1.218より前は、後ろに書いたコマンドが別のスキルとして展開されていました。

また、レビューは既定でバックグラウンドのサブエージェントとして走り、CLAUDE.mdには従いますがREVIEW.mdは読みません。-pによる非対話実行や、CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1を設定した環境では、フォアグラウンドで走ります。/simplifyが同じ条件で動くかどうかは、確認できる記述が見つかりませんでした。

実装直後とPR直前で使い分ける

書いたその場では/simplifyが向いています。重複したヘルパーや不要な抽象化が先に消えるので、あとで/code-reviewを通したときの指摘がバグに寄ります。PRを出す前やマージを判断する前は/code-reviewで、必要ならultraまでかけます。順番に流す場合は次のとおりです。

/simplify
/code-review

どちらの指摘も、まず作業ツリーの差分を自分の目で読むのが前提です。Claude Codeの標準的な使い方の流れは、別のガイドでまとめています。

まとめ

/simplifyは挙動を変えずにコードを整える自動適用のコマンドで、バグは/code-reviewに任せる前提です。手順書に書かれた/simplifyは版によって意味が違うので、まず自分の環境のバージョンを確かめてください。コミット前に必ず通したいなら、同梱ではなく自分のsimplifyスキルを置く必要があります。

よくある質問

同名のスキルを置いたら、元の/simplifyはどうなりますか

同名解決の表では、エンタープライズ・個人・プロジェクトのいずれかの場所に置いたスキルが同梱スキルを置き換えます。置き換えるのは同梱コマンド本体で、別名は対象外です。/simplifyには別名が載っていないので、同名のスキルを置けば/simplifyは自分のスキルを指します。元の4エージェント構成に戻したければ、スキルを外します。

古い手順書に「/simplifyでバグを検知する」とあります。今も使えますか

v2.1.152〜153の情報なら、当時は通用した可能性があります。今のバージョンで同じ結果を得たいなら、案内のとおり/code-review --fixに置き換えます。

/simplifyの結果をPRへのコメントとして残せますか

/simplifyの書式に、PRへ投稿する引数は出てきません。コメントとして残したい場合は/code-review --commentの領分です。