Claude Codeの/simplifyで差分を4つのエージェントが並列にクリーンアップする — /code-reviewはその後に実行する

はじめに

Claude Codeに同梱されているスキル/simplifyを、私は何週間も使っていましたが、それが何をしているのかは知りませんでした。知っていたのは、/code-reviewという双子のようなスキルがあり、2つを組み合わせて使うよう勧める人が多いということだけです。2つのスキルはよく似て見えましたが、どう役割を分けているのかは説明できませんでした。

/simplifyはクリーンアップ専用のレビューです。4つのエージェントが差分を並列に読み、それぞれが1つの観点を担当します。観点は再利用、簡素化、効率、そして抽象度（変更が適切な層にあるか）です。修正はそのままワーキングツリーに書き込まれ、適用する修正を事前に一覧から選ぶ機会はありません。

/simplifyは正しさに関するバグを一切探さないので、/code-reviewはその後に、/simplifyが残したコードに対して実行します。このブログの実際のコミットで両方を実行し、それぞれが何を見つけるかを確かめました。

/simplifyが実行する内容

/simplifyはバンドルスキルです。Claude Codeに組み込まれたプロンプトで、モデルが自分のツールを使ってレビューと修正をどう進めるかを指示します。コマンドリファレンスでは、次のように説明されています（拙訳）。

変更されたコードをクリーンアップの観点でレビューし、修正を適用します。4つのレビューエージェントが並列に動き、既存ヘルパーの再利用、簡素化、効率、変更が適切な抽象度にあるかを確認します。正しさに関するバグは探しません。バグを見つけるには/code-reviewを使ってください。

読み込まれるプロンプトは3つのフェーズで進みます。

1. 差分を集める。upstreamブランチに対するgit diffに、コミット前の変更を加えたものです。引数でパスやプルリクエストを渡した場合はそれが対象になります。
2. レビューする。4つのエージェントが同時に起動し、それぞれがステップ1で集めた差分と、担当する観点を受け取ります。
3. 適用する。同じ行を指す指摘は1つにまとめられ、そのうえで1件ずつワーキングツリー上で修正されます。

各エージェントは、プロンプトからそれぞれ1つの担当を与えられます。

適用フェーズを担うのは4つのレビュー担当ではなくメインのエージェントで、指摘を見送ってよい条件が書かれています。プロンプトから引用します（拙訳）。

修正が意図した動作を変える指摘、レビュー対象の差分から大きく外れた変更が必要な指摘、誤検知と判断した指摘は見送ってください。反論はせず、見送ったことを記録してください。

バグを探すのは、同じくバンドルスキルである/code-reviewの役割です。

その3月の記事は、Rubyの静的解析・フォーマットツールであるRuboCopの作者、Bozhidar Batsov氏によるものです。同氏は/simplifyを「最もよく使うスキル」と呼び、「大きめのリファクタリングの直後や、AIが生成したコードをまとめて受け入れた直後」に実行しています（引用は拙訳）。

実際の差分で/simplifyを実行する

私が選んだのは、すでに本番公開済みの差分です。rehype-link-icons.tsは、リンクの横にブランドマークを描くこのブログのrehypeプラグイン（HTMLの構文木を加工するプラグイン）で、選んだ差分はそこに4つの新しいマークを追加したものでした。Qiita、Zenn、DevelopersIOの3つと、このブログへのリンクに付けるこのブログ自身の印（判子）です。

過去のコミットを別のワークツリーにコミット前の変更として再適用し、/simplifyが本来のコードや作業中の変更に触れずに自由に編集できるようにしました。

git worktree add --detach ../simplify-trial <commit>^
git -C ../simplify-trial cherry-pick -n <commit>

そのワークツリーの中で、Claude Code 2.1.310を使って次を実行しました。

/simplify src/lib/rehype-link-icons.ts

4つのエージェントが返した指摘は9件で、/simplifyはそのうち3件を適用しました。

再利用と効率が0なのは、この2つのエージェントが報告したのが前の表の例のような所見だけで、今回の差分で直すべき点はなかったからです。

適用された3つの修正

最も大きな修正は、上の表の簡素化の例にあたるMarkSymbol型の削除でした。この型の役割は、idフィールドをresolveMarkから唯一の呼び出し側に渡すことだけでした。その呼び出し側であるスプライト（すべてのマークをまとめた非表示の<svg>）を組み立てるコードは、戻り値を受け取った瞬間に分解していました。

function resolveMark(key: MarkKey): MarkSymbol {
  if (isLocal(key)) return { id: symbolId(key), ...LOCAL_MARKS[key]() };
  return { id: symbolId(key), viewBox: "0 0 24 24", children: [markPath(key)] };
}
// …
children: [...used].map((key) => {
  const { id, viewBox, children } = resolveMark(key);
  return element("symbol", { id, viewBox }, children);
}),

/simplifyはresolveMarkを、<symbol>ノードそのものを返すsymbol()に置き換え、MarkSymbol型はなくなりました。

function symbol(key: MarkKey): HastNode {
  const { viewBox, children } = isLocal(key)
    ? LOCAL_MARKS[key]()
    : { viewBox: "0 0 24 24", children: [markPath(key)] };
  return element("symbol", { id: symbolId(key), viewBox }, children);
}
// …
children: [...used].map(symbol),

残りの2つは小さな修正です。

• faviconの読み取り方：プラグインは印の形状をfaviconから読み取っています。これまで<svg>タグだけ別の行で読み、<circle>・<g>・<path>は1つの.mapで読んでいました。今は4つとも同じ.mapで読み取り、結果は変わりません。
• 旧ホスト名：ブログの旧アドレスoharu-tech-blog.vercel.appがマークの表に直書きされていましたが、サイトのアドレスはsite.tsに置くべきものです。上の表の抽象度の例がこれです。今はsite.tsのLEGACY_HOSTSに移り、アドレスが変わってもsite.tsだけを直せば済みます。

見送られた6つの指摘

/simplifyが見送った6件の指摘と、その理由です。

/simplifyは、自分が編集したコードを実行しません。そこでClaude Codeが、3つの修正でページ上の表示が何も変わっていないことを別途確認しました。6種類のリンク（GitHub、ルート相対、旧ホスト、DevelopersIO、Zenn、脚注）を修正前と修正後のプラグインにそれぞれ通したところ、出力は完全に一致しました。

/simplifyが残したコードに/code-reviewを実行する

/simplifyが編集したrehype-link-icons.tsとsite.tsの2ファイルに/code-reviewを実行すると、指摘は10件でした。

そのうち9件は、本番公開されたときのコミットにすでにあったものです。この9件のうち3件はそのまま再現できます。

抽象度のエージェントもmarkForにあるルート相対判定の正規表現を読んでいましたが、指摘したのは判定を置く層が不適切だという点だけでした。この正規表現が不正なhrefを通してしまうかどうかは正しさの問題で、このエージェントの担当外です。そのため、バックスラッシュのケースは/code-reviewまで見つかりませんでした。

/simplifyと/code-reviewはいつ実行するか

/simplifyを先に、/code-reviewを最後に実行します。/simplifyはワーキングツリーのコードを直接書き換え、レビューが見るのは実行した時点のコードだけです。順番を逆にすると、/simplifyによる変更はレビューされないままコミットされます。

Batsov氏の3月の記事で紹介されているワークフローは逆の順番で、「変更を加え、/reviewで問題を見つけ、指摘をすべて直してから/simplifyで整える」（拙訳）という流れです。

まとめ

/simplifyは差分を4つのエージェントに並列に渡し、再利用、簡素化、効率、抽象度の観点で修正を適用します。動作を変える修正や差分の外側に及ぶ修正は見送ります。バグは一切探さず、編集したコードを実行することもありません。

/code-reviewはその後に、/simplifyが残したコードに対して実行します。すでに本番公開したコミットでこの2つを試すなら、git cherry-pick -nでそのコミットを別のワークツリーに再現し、そこで実行してください。

参考リンク

• Claude Codeのコマンドリファレンス（/simplifyと/code-reviewの項目）
• Review locally with /code-review（/simplifyとの関係を含む）
• Claude Codeのチェンジログ（/simplifyの経緯は2.1.63〜2.1.154）
• Bozhidar Batsov: Essential Claude Code skills and commands