24 人が閲覧(直近 30 日) Claude

Claude Codeの/simplifyとは?/code-reviewとの違いと/batchの使い方【2026年10月】

Claude Codeの/simplifyとは?/code-reviewとの違いと/batchの使い方【2026年10月】

Claude Codeの/simplifyは、変更したコードを「既存ヘルパーの再利用・単純化・効率・抽象化の水準」の4観点で見直し、見つけた箇所をその場で書き換えるバンドルスキルです。正しさのバグは探しません。2026年10月15日にClaude Code 2.1.299で、同じ差分へ/simplifyと/code-reviewを実行したところ、/simplifyは末尾の要素が欠けるバグに気づきながら挙動を残し、/code-reviewはそのバグを最初の指摘に挙げました。この記事では、その実行結果と公式ドキュメント・CHANGELOG・配布パッケージの記述をもとに、/simplifyの守備範囲、/code-reviewとの使い分け、名前と中身の変遷、大規模な変更を並列に流す/batchの使い方を整理します。

まとめ

  • /simplifyは変更したコードを4つのレビューエージェントで並列に見直し、修正まで適用します。観点は再利用・単純化・効率・抽象化の水準(altitude)で、正しさのバグは対象外です。
  • 同じ差分での実行では、/simplifyは重複関数の置き換えなど3件を直し、off-by-oneのバグは挙動を変えずに残して報告だけしました。一方で、設定ファイルの読み込みを移した結果、ファイルが無いときの挙動が1か所変わっています。/code-reviewはそのバグを含む6件を報告し、ファイルには触れませんでした。
  • バグが残ったまま/simplifyを先に回すと、バグが短く意図的に見える書き方へ整えられることがあります。/code-reviewでバグを直してから/simplifyで整え、最後にテストを回す順序が安全です。
  • /simplifyは2.1.63で整理専用のコマンドとして追加されました。2.1.147で/code-reviewへ改名、2.1.152で/code-review –fixの呼び出しに変わり、2.1.154で現在の整理専用レビューに戻っています。
  • /batchは作業を5〜30の独立ユニットに分解し、ユニットごとに隔離したワークツリーでサブエージェントを動かします。2.1.281以降はWorktreeCreateフックがあればgit以外の環境でも動きます。

/simplifyが見直す4つの観点と対象範囲

公式のコマンド一覧は/simplifyを「Four review agents run in parallel, covering reuse of existing helpers, simplification, efficiency, and whether the change is at the right level of abstraction. The review doesn’t look for correctness bugs.」と説明しています。4つのレビューエージェントが並列に走り、既存ヘルパーの再利用・単純化・効率・変更が適切な抽象化の水準にあるか、の4点を見ます。正しさのバグは見ません。

4つのレビューエージェントの担当

CHANGELOGの2.1.154には「reuse, simplification, efficiency, altitude」と4観点の名前が並んでいます。各観点が何を見るかと、後述の検証で実際に出た指摘を対応させると次のとおりです。

観点 見るもの 検証で出た指摘
reuse 既存ヘルパーで置き換えられる新規コード 自前の関数を既存のslugifyへ置換
simplification 回りくどい書き方・不要な中間処理 インデックスのループを内包表記へ
efficiency 繰り返しの読み込み・無駄な計算 ループ内の設定ファイル読込を外へ
altitude 変更の抽象化の水準 prefixを引数で受ける案(見送り)

altitudeは、行単位の書き方ではなく「その処理をどの層に置くべきか」を問う観点です。検証では、設定ファイルを関数の中で読む作りそのものを見直す提案が出ましたが、呼び出し側の変更が必要になるとして、今回の実行では提案だけに留まりました。

対象の指定と実行前の準備

引数を付けなければ変更したコードが対象です。公式の書式は/simplify [target]で、パスやプルリクエストの参照を渡すと対象を絞れます。

/simplify
/simplify src/export.py

/simplifyは--fixのようなフラグを待たずにファイルを書き換えます。実行前に変更をコミットして比較の基準を残し、対象のパスを指定して実行すると、git diffで整理による変更だけを確認できます。stashで退避した場合は、変更を作業ツリーへ戻してから実行してください。退避したままでは整理したいコードが対象から消えます。claude -pで非対話に回す場合は、編集を許可する権限モードが必要です。検証では--permission-mode acceptEditsで実行したため編集は通りましたが、修正後の動作確認に使うコマンドは承認待ちになり、実行されないまま終わりました。

同じ差分で/simplifyと/code-reviewを比べた検証

2026年10月15日、Claude Code 2.1.299で小さなPythonリポジトリを2つ複製し、片方でclaude -p "/simplify" --permission-mode acceptEdits、もう片方でclaude -p "/code-review"を実行しました。モデルは既定の設定のまま、/code-reviewはレベルを指定せず、どちらも1回ずつの実行です。整理の余地とバグの両方を含む同じ差分を渡し、2つのコマンドがそれぞれ何を拾い、何を書き換えるかを比べています。

検証に使った差分

リポジトリには、文字列をURL用のスラッグに変えるslugifyを持つtextutil.pyと、それを使うreport.pyをコミット済みです。そこへ次のexport.pyを未コミットの変更として追加しました。既存のslugifyと同じ処理の再実装、ループのたびに設定ファイルを開く処理、そしてrange(len(titles) - 1)で最後のタイトルが落ちるoff-by-oneのバグを入れています。

import re
import json


def make_slug(title):
    s = title.lower()
    s = re.sub(r"[^a-z0-9]+", "-", s)
    s = s.strip("-")
    return s


def export_titles(titles, path):
    rows = []
    for i in range(len(titles) - 1):
        with open("config.json") as f:
            cfg = json.load(f)
        prefix = cfg["prefix"]
        rows.append(prefix + make_slug(titles[i]))
    with open(path, "w") as f:
        f.write("\n".join(rows))
    return len(rows)

/simplifyが直したもの・残したもの

/simplifyは4つのエージェントをReuse・Simplification・Efficiency・Altitudeの名前で起動し、重なった指摘をまとめたうえでexport.pyを次のように書き換えました。

import json

from textutil import slugify


def export_titles(titles, path):
    with open("config.json") as f:
        prefix = json.load(f)["prefix"]
    # TODO: 元の実装に合わせて末尾要素を除外しているが、意図した仕様か要確認
    rows = [prefix + slugify(title) for title in titles[:-1]]
    with open(path, "w") as f:
        f.write("\n".join(rows))
    return len(rows)

直ったのは3点です。make_slugを消して既存のslugifyを使うようにし、設定ファイルの読み込みをループの前の1回にまとめ、ループをリスト内包表記に置き換えました。正規表現の事前コンパイルと逐次書き出しは「効果が小さい」として見送っています。

off-by-oneのバグは、レビューの途中で見つかっていました。それでも/simplifyは「直すと出力が変わる」としてtitles[:-1]という形で挙動をそのまま残し、TODOコメントを付けたうえで、報告の末尾に「別途確認してほしい点(正しさの問題)」として挙げています。修正前と修正後のexport.pyに3件のタイトルを渡すと、どちらも2行しか出力しませんでした。この入力では末尾要素の欠落が維持されています。ただし、設定ファイルがなくタイトルが0件または1件の場合、修正前は空ファイルを書いて終了するのに対し、修正後はFileNotFoundErrorになります。設定読み込みの移動で境界条件の挙動は変わっており、完全な動作互換性は確認できません。

/code-reviewが報告した6件

/code-reviewは同じ差分から6件を報告しました。冒頭には「high effort」で実行したと表示されています。--fixを付けていないので、ファイルは1文字も変わっていません。

順 指摘 種別
1 off-by-oneで最後のタイトルが出ない バグ
2 config.jsonをカレントディレクトリ基準で開く バグ
3 日本語タイトルのスラッグが空になる バグ
4 ループのたびにconfig.jsonを読む 整理
5 make_slugが既存のslugifyと重複 整理
6 open時にencodingを指定していない バグ

各指摘には、どの入力で何が起きるかが添えられていました。1件目は「3件渡すと2件しか書かれず、1件だけなら空ファイルになる」という具体例付きです。/simplifyが拾った整理系の指摘(4と5)も含まれていますが、並びはバグが先でした。

検証から決める実行順序

この結果から、/code-reviewでバグを直してから/simplifyで整える順序を勧めます。/simplifyは挙動の維持を意図した整理ですが、既存のバグを残す場合も、整理によって別の挙動差を生む場合もあります。検証ではrange(len(titles) - 1)がtitles[:-1]という短く意図的に見える形に変わりました。TODOコメントを消してしまえば、次にコードを読む人はこれを仕様と受け取りかねません。

設定ファイルが無いときの挙動差は、/simplify自身の報告には出てきませんでした。修正後の動作確認に使うコマンドが承認待ちで実行されなかったためです。/simplifyを先に回した場合は、正しさの問題やTODOが報告されていれば確認し、別途/code-reviewとテストで変更後の挙動を確認してからコミットしてください。指摘の件数や文面は、モデル・effort・コードベースによって変わります。

/simplifyと/code-reviewの機能比較

2つのコマンドの差は「正しさのバグを探すか」と「修正を既定で当てるか」の2点に集約されます。公式のコードレビュー解説によれば、/code-reviewは正しさのバグを報告し、モデルとeffortによっては再利用・単純化・効率の整理も扱います。

項目 /simplify /code-review
正しさのバグ 探さない 報告する
整理の指摘 4観点 モデルとeffort次第
修正の適用 既定で適用 --fixを付けたとき
主な引数 パスかPR参照 effort・PR番号・ブランチ・パス
主なフラグ なし --fix・--comment・--max-findings
別名 なし /review

/code-reviewのeffortは、lowが最も確信度の高い指摘だけに絞り、mediumからmaxにかけて対象を広げます。レベルを打たずに実行すると、以前のセッションも含めて最後に自分で打ったlow〜maxのレベルが再利用されます。--max-findingsは通常の上限の代わりに報告件数を指定するフラグで、2.1.288以降で使えます。ultraを付けるとクラウドのultrareviewに切り替わり、ProとMaxにはアカウントごとに一度限りの無料枠が3回あります。使い切ると追加の利用クレジットで課金されます。料金や自動レビューの設定はClaude Code「Code Review」完全ガイドで扱っています。

/simplifyの名前と中身の変遷

「/simplifyはバグを見つけて直すコマンド」という説明と「バグは探さない」という公式の説明が併存しているのは、同じ名前のコマンドが、追加から3か月の間に3回作り替えられたためです。npmの公開記録・CHANGELOG・各版の配布バイナリで追うと、次の4段階になります。

2.1.63から2.1.154までの4段階

版 npm公開日 /simplifyの中身
2.1.63 2026-02-28 整理して修正(3エージェント)
2.1.147 2026-05-21 /code-reviewの別名(バグを報告)
2.1.152 2026-05-26 /code-review –fixを呼ぶ
2.1.154 2026-05-28 整理専用のレビュー(4観点)

2.1.63のnpm配布パッケージに含まれるcli.jsでは、/simplifyの説明文は「Review changed code for reuse, quality, and efficiency, then fix any issues found.」です。プロンプト本文はCode Reuse・Code Quality・Efficiencyの3つのレビューエージェントを並列に起動し、指摘を集約して直す手順でした。追加当初から整理のためのコマンドで、正しさのバグを探す設計ではありません。2.1.146の配布バイナリでも同じ説明文のまま、code-reviewという名前にsimplifyが別名として登録されていました。

2.1.147のCHANGELOGは「Renamed /simplify to /code-review. It now reports correctness bugs」と書き、従来の整理と修正の動作は削除されたと明記しています。2.1.147と2.1.150の配布バイナリでは、/simplifyは正しさのバグを報告する/code-reviewの別名のままです。2.1.152では/simplifyが/code-review --fixと同等の独立したコマンドになり、2.1.154で現在の整理専用レビューに置き換わりました。/simplifyがバグを探していたのは、2026年5月21日公開の2.1.147から5月28日公開の2.1.154の手前までの約1週間です。

古い解説・スクリプトを読み替える要点

公式ドキュメントは「If you scripted /simplify for bug-finding, switch to /code-review --fix.」と移行先を示しています。CIや手順書で/simplifyをバグ検出目的に使っているなら、/code-review --fixへ置き換えてください。2026年3〜5月の解説にある「3つのエージェントが並列で見る」という説明は2.1.63〜2.1.146の仕様で、現在は4観点です。手元の版はclaude --versionで確認できます。

code-simplifierプラグインとの違い

「/simplifyはcode-simplifierエージェントを呼び出す」と説明する英語の解説がありますが、2つは別物です。code-simplifierは公式マーケットプレイスclaude-plugins-officialで配布されているプラグインで、中身はmodel: opusを指定した1体のサブエージェントです。2.1.63のcli.jsに「code-simplifier」という文字列は1か所も出てきません。

code-simplifierは、直近に変更したコードを機能を保ったまま読みやすく整えるエージェントです。CLAUDE.mdのコーディング規約に合わせることや、ネストした三項演算子をswitchやif/elseへ置き換えることが指示に書かれています。/simplifyが再利用・効率・抽象化の水準まで見るのに対し、こちらは書き方の統一に寄っています。導入はClaude Codeのプロンプトで次を実行します。

/plugin install code-simplifier@claude-plugins-official

差分の重複や無駄な処理を減らしたいなら/simplify、チームの規約に沿って書き方を揃えたいならcode-simplifier、と目的で選びます。プラグインの配布方法はpr-review-toolkitとは|Claude Codeプラグインの導入とreview-prの使い方でも扱っています。

simplifyスキルの自作・自動実行・無効化

公式のスキル解説は、/simplifyを含むバンドルスキルを「prompt-based」と説明しています。中身がプロンプトなので、同じ名前のスキルを置けば差し替えられ、設定で隠したり止めたりもできます。

同名スキルによるバンドル版/simplifyの置換

プロジェクトの.claude/skills/simplify/SKILL.mdに自作のスキルを置くと、バンドルの/simplifyより優先されます。ただし置き換わるのはコマンド名だけで、別名は置き換わりません。公式の例では、自作のcode-reviewスキルを置いても、/reviewと打てばバンドル側が動きます。

---
name: simplify
description: コミット前に変更差分の重複と無駄な処理を整理する。挙動は変えない
---
変更したファイルだけを対象に、既存ヘルパーで置き換えられる処理と
ループ内の重複した読み込みを整理してください。
正しさの問題を見つけた場合は直さずに一覧で報告してください。

SKILL.mdの書き方はClaude Skillsとは?SKILL.mdの書き方、.claude/commands/との関係はClaude Codeカスタムコマンドの作り方で整理しています。

コミット直前に自作のsimplifyを走らせる条件

2.1.286以降、verifyまたはsimplifyという名前のスキルがセッション開始時に存在すると、Claude Codeのコミット手順に「コミット直前にそのスキルを実行する」指示が加わります。ドキュメントとテストだけの変更は除外されます。この指示が入るのは次の3条件を満たすときです。

  • スキルがenterprise・personal・project・追加ディレクトリのいずれかにあるか、.claude/commands/に同名のファイルがある。バンドルの/simplify、プラグインのスキル、claude.aiアカウントのスキルは数えない
  • Claudeがそのスキルを呼び出せる。disable-model-invocation: trueで止めていると指示は入らない
  • 設定のincludeGitInstructionsを切っていない

バンドルの/simplifyを置いただけでは自動実行されない点に注意してください。コミットのたびに整理を挟みたいチームは、上のような自作スキルをリポジトリにコミットしておく必要があります。前章の検証のとおり整理はバグを残すので、自動実行にするなら、正しさの問題を報告させる一文を自作スキルに入れておくのが無難です。

skillOverridesとdisableBundledSkillsによるスキルの無効化

設定ファイルのskillOverridesは、スキルごとに4つの状態を切り替えます。

値 Claudeへの提示 /メニュー
“on” 名前と説明 表示
“name-only” 名前のみ 表示
“user-invocable-only” 非表示 表示
“off” 非表示 非表示

Claudeの判断で/simplifyが走るのを止め、自分で打ったときだけ動かすには、プロジェクトの.claude/settings.jsonへ次の設定を追加します。既存の設定がある場合は、ファイル全体を置き換えずにキーを追加してください。

{
  "skillOverrides": {
    "simplify": "user-invocable-only"
  }
}

バンドルスキルをまとめて止めるならdisableBundledSkillsをtrueにします。この設定でも/doctorだけは打てば動き、隠すにはDISABLE_DOCTOR_COMMAND環境変数か"doctor": "off"を使います。

/batchで大規模な変更を並列に流す手順

/batchは、1つの指示を多数の独立した作業に分けて同時に進めるバンドルスキルです。公式の説明は「Orchestrate large-scale changes across a codebase in parallel」で始まり、例として次のコマンドが挙げられています。

/batch migrate src/ from JavaScript to TypeScript

分解から変更の公開までの流れ

まずコードベースを調べ、作業を5〜30の独立ユニットに分解して計画を示します。承認すると、ユニットごとに1体のバックグラウンドサブエージェントが隔離されたワークツリーで起動し、担当分を実装してテストを実行し、変更を公開します。gitリポジトリならユニットごとのプルリクエストになるため、一部だけ取り込んで残りを差し戻せます。

2.1.63のプロンプトでは、各ユニットに「他のユニットと状態を共有しない」「他のユニットのPRを待たずにマージできる」「おおむね同じ大きさ」の3条件を課していました。対象のファイルが少なければ5に近く、数百あれば30に近づけるよう指示されています。並列に走るエージェントの隔離の仕組みはClaude Codeのgit worktreeで並列エージェント開発を行う方法で解説しています。

git以外のバージョン管理における/batchの実行条件

/batchの前提は、gitリポジトリか、ワークツリーを作るWorktreeCreateフックです。gitリポジトリの外で/batchを動かすには2.1.281以降が必要です。公式のワークツリー解説によると、フックを使う場合、各サブエージェントはプロジェクトのバージョン管理コマンドで変更を公開し、プルリクエストを開けないときは公開した内容を報告します。

SVNやPerforce、Mercurialの環境では、作業コピーを作って作成先のディレクトリパスを出力するWorktreeCreateと、後始末のWorktreeRemoveを組で用意します。フックを使うと.worktreeincludeは処理されないので、.envのような管理外のファイルはフックのスクリプトの中でコピーしてください。フックの書き方はClaude Code Hooksの設定方法にまとめています。

/batchが向かない変更

変更同士に順序の依存がある作業は、独立ユニットに分けられないので向きません。たとえば共通の型定義を先に変えないと各モジュールが通らない移行がこれにあたります。対象が数ファイルなら、分解と計画の手間のほうが大きくなります。サブエージェントを1体だけ隔離したい場合は、/batchを使わず、カスタムサブエージェントのフロントマターにisolation: worktreeを書く方法があります。

よくある質問

/simplifyと/code-reviewはどちらを先に実行すべきですか?

/code-reviewを先に実行し、バグを直してから/simplifyで整える順序を勧めます。/simplifyは挙動を維持する意図で整理しますが、既存バグの修正や動作互換性を保証しません。整理後にも差分とテスト結果を確認してください。

/simplifyはバグを直しますか?

直しません。2.1.154以降の/simplifyは再利用・単純化・効率・抽象化の水準の4観点だけを扱う整理専用のレビューです。バグを直すには/code-review --fixを使います。

simplifyスキルは自作できますか?

できます。.claude/skills/simplify/SKILL.mdに同名のスキルを置くとバンドルの/simplifyより優先され、2.1.286以降はコミット直前に実行する指示も入ります。

/simplifyとcode-simplifierは同じものですか?

別物です。/simplifyはClaude Code本体に同梱されたスキル、code-simplifierはclaude-plugins-officialで配布されているプラグインのサブエージェントです。

/batchはgitリポジトリ以外でも使えますか?

2.1.281以降なら、WorktreeCreateフックでワークツリーを作らせることで使えます。それより前の版ではgitリポジトリが必須です。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.23 テックブログ Renta!不正アクセスでサービス停止:再開未定の現状と運営側の停止判断・証拠保全・段階的再開
  2. 2025.01.09 コラム アドレサブルCM(Addressable CM)とは?フジテレビで出る表示の意味・仕組みと視聴データの扱い
  3. 2026.10.21 テックブログ ふるさとチョイス不正アクセスで445万件流出:対象確認・パスワード変更と再開時期
  4. 2026.07.09 テックブログ Muse Imageとは?Metaの画像生成AIの使い方・API料金(1枚0.01ドル)と日本での提供状況【2026年10月】
  5. 2026.10.14 テックブログ ローソンID不正アクセス:215万件漏えいの対象確認と本物メールの見分け方

RELATED POSTS 関連記事

目次