Claude Code /simplify と /batch

問題: Claude Code で機能を実装し終えた。テストは通っている。しかし、いくつかの関数が互いに重複していること、ヘルパーが再発明されたこと、そして少なくとも1つのループが必要以上の作業をしていることも分かっている。手動でこれを全部修正しようとすると、触れたすべてのファイルを読み返し、粗削りな部分を自分で見つけ、1つずつパッチを当てることになる。そのまま出荷すると技術負債が次のスプリントに重くのしかかる。どちらの選択肢も気持ちよくない。

クイックウィン: 機能がランドした直後に /simplify と入力する。3つのレビューエージェントを同時に起動する。1つはコードの再利用を見る。1つは品質を見る。1つは効率を見る。それらは所見をまとめ、修正を適用し、クリーンな差分を返してくれる。書くべきプロンプトはなし。コマンドだけだ。

# After implementing a feature
/simplify
 
# Focus on a specific concern
/simplify focus on memory efficiency

Claude Code が初めての方は、入門ガイドで基本を確認してほしい。フレームワーク全体を別のものに移行したり、数十ファイルにまたがって変更をロールアウトするような、より大きな作業を抱えている場合は /batch が適している。どちらのコマンドも Claude Code v2.1.63 でリリースされ、以前は慎重なマルチステップのプロンプトが必要だった2つのワークフローをカバーしている。

Claude Code /simplify が行うこと

/simplify は実装後のクリーンアップコマンドだ。コードが動作したら、/simplify が差分を読み返して改善する。

最初のステップは git diff (または git diff HEAD) の呼び出しで、何が変わったかを確認する。git の変更がなければ、最近触ったファイルにフォールバックする。そこから、3つのレビューエージェントが並行して広く展開する。それぞれが完全な差分を見る:

3つが並行して実行される。完了したら、/simplify は所見をまとめ、すべての実際の問題に直接パッチを当て、誤検知らしきものは静かに除外する。修正の短い要約か、コードがすでに整っているという確認が返ってくる。

Claude Code の PM である Boris Cherny は的確に表現している。これらのバンドルコマンドは「プルリクエストを本番に導くために必要だった作業の多くを自動化する」とのことだ。/simplify は「動く」と「マージする準備ができている」の間の自動レビューパスだ。

/simplify を使うべき場面

スイートスポットは実装直後、PR を開く前だ:

• 機能を完成させた後 -- レビュー前にクリーンアップする
• バグ修正の後 -- 修正がショートカットを導入していないか確認する
• プロトタイプの後 -- 残したい実験的なコードを整える
• PR の前 -- レビュワーが指摘するだろう問題を検出する

焦点を絞りたい場合は、任意のテキストを渡せる:

/simplify focus on error handling
/simplify check for unnecessary dependencies
/simplify look at the database query patterns

コードベースを説明する完全なプロンプトを書かずに、特定のエリアが粗削りだと分かっているときに便利だ。コマンドはすでにどのファイルが動いたかを知っている。

/simplify でないもの

/simplify はリンターではない。フォーマッタでもない。アーキテクチャの判断、コード構造、アルゴリズムの選択を見る、より高いレベルで動作する。ESLint と Biome はそのままループに残る。/simplify はそれらのツールが検出できない懸念を扱う。バリデーションスタイルの強制には、hooks がすでに存在する。

包括的なリファクタリングツールでもない。注意は最近変更されたものに留まり、プロジェクト全体ではない。コードベース全体の変更には /batch が必要だ。

Claude Code /batch が行うこと

Claude Code の /batch コマンドは、プロジェクト全体にわたる大規模な変更を並行して調整する。ユーザー向けのインターフェースは意図的にシンプルだ。説明といくつかの使用例だけだ:

/batch migrate from react to vue
/batch replace all uses of lodash with native equivalents
/batch add type annotations to all untyped function parameters

何を変更すべきかを伝える。/batch はそれをより深いオーケストレーションエージェントに渡し、調査、分解、実行、PR 作成を行う。内部では、オーケストレーターが3フェーズのループを実行する。

フェーズ1 -- 調査と計画。 オーケストレーターはプランモードに入る。指示が触れるすべてのファイル、パターン、呼び出しサイトを追跡する Explore エージェントを生成する。そこから、コードベースと変更に合わせてサイズ調整された5〜30の自己完結型ユニットに作業を分解する。各ユニットは worktree 内で単独で実装可能で、他のユニットの完了を待たずに単独でマージ可能である必要がある。オーケストレーターは、ブラウザオートメーション、CLI テスト、既存のテストスイートなど、エンドツーエンドの検証レシピも考え出す。作業を検証する方法が分からない場合は停止して確認する。

フェーズ2 -- ワーカーのスポーン。 計画を承認したら、オーケストレーターはユニットごとに1つのバックグラウンドエージェントを起動する。すべてが1つのメッセージブロックで送出されるため、並列性は本物だ。各エージェントはクリーンな git worktree のために isolation: "worktree" で実行される。各エージェントのプロンプトは自己完結している。全体的な目標、具体的なタスク、調査中に収集されたコードベースの規約。エンドツーエンドのテストレシピとワーカー指示も含まれている。コードを書いた後、各ワーカーは自身の差分に対して /simplify を実行し、テストスイートを実行し、コミットし、プッシュし、gh pr create で PR を開く。

フェーズ3 -- 進捗追跡。 オーケストレーターはステータステーブルをレンダリングし、エージェントが完了するにつれて更新し続け、各ワーカーの出力から PR URL を引き出す。最後に「22/24ユニットが PR としてランドした」のような要約行が表示される。

Worktree の分離がこれを機能させる核心だ。すべてのエージェントが独自のブランチと独自の作業コピーを持つため、あるエージェントが別のエージェントに踏み込むことはない。マージコンフリクトは発生しない。各ユニットは独立してテスト・レビュー可能だ。

# Large-scale migration
/batch migrate src/ from Solid to React
 
# Pattern application
/batch add input validation to all API endpoints
 
# Convention enforcement
/batch rename all database columns from camelCase to snake_case
 
# Dependency update
/batch update all axios calls to use the new fetch wrapper

計画ステップ

1つのファイルが変更される前に、/batch は計画を提示する。すべての作業ユニット、触れる予定のファイル、変更の内容が分かる。承認するまで何も実行されない。

これが /batch を予測可能にするものだ。自律的なプロセスにプロジェクトを委ねて指を交差させるわけではない。分解は可視化されている。理にかなっているかを検証する。それから走らせる。

計画が外れている場合 (ファイルを見落としたかもしれない、グループ分けが悪かったかもしれない) は、実行開始前に調整を伝える。これは個別タスクのプランニングモードと同じ精神で、ただしリポジトリ全体にスケールアップされている。

要件

/batch は git リポジトリが必要だ。例外なし。すべてのエージェントユニットは独自の git worktree 内で実行され、それぞれが最後にプルリクエストを開く。git リポジトリの外では /batch は起動を拒否する。

worktree ルールは変更を安全に保つものでもある。各エージェントの作業は独自のブランチに存在する。1つのユニットが失敗したり悪いコードを出しても、他は続行する。良い PR はマージされる。悪い PR は捨てられる。

/batch を使うべき場面

/batch はきれいに並列化できる作業向けだ。つまり、何十何百ものファイルが同じ種類の編集を必要としており、1つの編集が別の編集に依存しない場合だ。

適した用途:

• フレームワーク移行 -- コンポーネントをあるフレームワークから別のものに変換する
• API コントラクトの変更 -- インターフェースが変わったときにすべての呼び出し元を更新する
• 規約の強制 -- 命名規則の適用、エラーハンドリングの追加、コードベース全体のパターンの標準化
• 依存関係の交換 -- あるライブラリを別のものに、すべての使用箇所で置き換える
• テスト生成 -- テストされていないモジュールにテストカバレッジを追加する

適さない用途:

• 密結合の変更 (ファイル A がファイル B の新しい出力に依存する場合、これらは独立したユニットではない)
• 探索的リファクタリング (最終状態がまだ分からない場合)
• 単一ファイルの変更 (分解を正当化しない場合)

作業にエージェント間の調整が必要な場合、たとえばエージェント A が共有ユーティリティを作成し、エージェント B がそれをインポートする必要がある場合、/batch は間違ったツールだ。そのようなクロストークは、通常の Claude Code セッションやエージェントチームが扱う。

/simplify vs /batch: 各コマンドをいつ使うか

2つのコマンドは異なるスケールで異なる問題を解決する。判断フレームワーク:

Claude Code での分かりやすいイメージ: /simplify はコードレビュワーで、/batch は移行チームだ。

設計上、2つはペアになっている。すべての /batch ワーカーはコミット前に自身の変更に対して /simplify を実行する。つまり、/batch から出てくるすべての PR はすでに3エージェントのパスを経ている。手動でチェーンする必要はない。統合はすでに組み込まれている。

実用的なワークフロー例

例1: 機能開発サイクル

4ファイルにわたる新しい認証フローを実装し終えたところだ:

# 1. Implement the feature (normal Claude Code session)
"Add JWT authentication with refresh tokens to the API"
 
# 2. Clean up with /simplify
/simplify
 
# 3. Focus on specific concerns if needed
/simplify focus on security patterns in the auth flow

3つのレビューエージェントが認証コードを調べ、重複したトークン検証ロジック、一貫しないエラーレスポンスのような品質問題、不要なトークンデコードのような効率の問題を探す。

例2: フレームワーク移行

フロントエンドに、Hooks を使った関数コンポーネントに変換する必要のある React クラスコンポーネントが45個ある:

# 1. Describe the migration
/batch convert all React class components in src/components/ to functional components with hooks
 
# 2. Review the plan (batch shows 15 units of ~3 components each)
# 3. Approve
# 4. Each agent creates a PR with its batch of conversions
# 5. Review and merge PRs individually

すべての PR がレビューとマージのために独立している。1つの変換が複雑になって人手が必要になっても、その PR は脇に置かれ、残りは続行する。

例3: API の標準化

API エンドポイントが一貫しないエラーレスポンスフォーマットを使用している:

/batch standardize all API error responses to use { error: string, code: number, details?: object } format

/batch はすべてのエンドポイントを見つけ、(通常はルートファイルまたはドメインごとに) 独立したユニットにバンドルし、各エージェントを割り当てられたルートに向ける。各ユニットは編集後に既存のテストスイートを実行するため、何かが壊れたかどうかすぐに分かる。

バンドルコマンド vs カスタムスラッシュコマンド

/simplify と /batch はバンドルされた Claude Code コマンドだ。すべてのインストールに同梱され、すぐに動く。カスタムスラッシュコマンドはもう一方の種類で、CLAUDE.md 設定または .claude/commands/ の下に自分で書くプロジェクト固有のプロンプトだ。バンドルコマンドは Anthropic によって管理され、各 Claude Code リリースとともに更新が届く。

この違いは、バンドルコマンドがカスタムコマンドではアクセスできない内部機能に到達できるため重要だ。/batch は分離された worktree でエージェントを生成し、自動的に PR を開ける。/simplify はオーケストレーションのコードを1行も書かずに3エージェントのレビューパイプラインを起動できる。

とはいえ、2つの側面は補完し合っている。カスタムコマンドはプロジェクト固有のもの (デプロイプロセス、テスト規約、コード生成パターン) を所有する。バンドルコマンドはどのプロジェクトにも当てはまる普遍的なもの (コードレビュー、コードベース全体の編集) を所有する。

マルチエージェントのレビューパスを手作りする独自のサブエージェントワークフローを構築している? /simplify がそれをそっくり置き換えるかもしれない。ファイル全体に繰り返し編集を適用するスクリプトを書いていた? /batch はそのスクリプトの Claude ネイティブ版だ。

/simplify と /batch を効果的に使うためのヒント

すべての PR の前に /simplify を実行する。 習慣にしよう。3エージェントのパスは、何時間も集中して実装作業をした後に見逃すものを検出する。実際のところ、/simplify はコードレビュー中に表面化するだろう問題をフィーチャーブランチごとに3〜5件確実に見つけ出す。効率エージェントは特に無駄なイテレーションと見逃された並行性の機会の検出に強い。

/batch の説明を具体的に。 「コードベースを更新して」は曖昧すぎる。「moment.js のインポートをすべて dayjs に置き換え、API コールを dayjs の構文に合わせて更新する」はプランナーが作業を適切に分解できる十分なコンテキストを与える。

/batch の計画を注意深く確認する。 分解ステップがほとんどの問題が出る場所だ。ユニットがファイルをカバーしすぎているか、独立した変更を混ぜている場合は、承認前に別の分割を依頼する。

/simplify のオプションのフォーカステキストを使う。 特定のエリアが粗削りだと分かっているとき (プロトタイピング中にショートカットを取ったなど)、/simplify をそこに直接向ける。ターゲットを絞ったレビューは汎用的なスイープより良い結果を出す。

/batch をテストスイートと組み合わせる。 すべての /batch エージェントは編集後にテストを実行する。それらのテストが実際に回帰を検出することを確認する。弱いテストは /batch エージェントが壊れたコードを「合格」させてしまうことを意味する。

FAQ

Does /simplify modify files automatically? (/simplify はファイルを自動的に変更するか?)

Yes。/simplify は修正を直接作業コピーに書き込む。コミット前に git diff でレビューする。修正が間違っていれば、git checkout でファイルを元に戻す。

What happens if a /batch worker fails? (/batch ワーカーが失敗した場合はどうなるか?)

失敗したワーカーが他のワーカーを道連れにすることはない。それぞれが独自の git worktree 内、独自のブランチで実行される。失敗はステータステーブルに表示され、そのユニットを再試行するか手動で対応する。すでにランドした PR は変更されない。

Which version of Claude Code ships these commands? (どのバージョンの Claude Code でこれらのコマンドが使えるか?)

/simplify と /batch は Claude Code v2.1.63 でリリースされた。claude --version で確認する。古いビルドなら claude update で取り込める。

Can /batch handle monorepos? (/batch はモノレポを扱えるか?)

Yes。/batch はどの git リポジトリでも動作する。モノレポ内では、プランナーが作業を正しく分解できるよう、説明でターゲットにするパッケージやディレクトリを具体的に指定する。

How is /simplify different from a linter? (/simplify はリンターとどう違うか?)

リンターは構文とスタイルの問題を検出する。/simplify はアーキテクチャの問題を検出する。重複したロジック、見逃した抽象化、パフォーマンスの非効率性、人間のレビュワーが指摘するパターンだ。それらは異なるレイヤーをカバーする。

次のステップ

• /batch が使う分離モデルを理解するために Claude Code の git worktrees について読む
• セッションコントロール、キーボードショートカット、/btw の補足質問を含む完全なインタラクティブモードスラッシュコマンドシステムの中で /simplify と /batch がどう機能するかを見る
• /batch が扱えない調整されたマルチエージェントタスクのためのエージェントチームの仕組みを学ぶ
• これらのバンドルコマンドと並んでプロジェクト固有のワークフローを構築するためのカスタムスラッシュコマンドを探索する
• 独自のマルチエージェントパターンを設計するためのサブエージェントのベストプラクティスを確認する
• 開発プロセスにレビューサイクルを組み込むためのフィードバックループガイドを読む
• これらのコマンドと共にリリースされた他のすべてについて v2.1.63 の完全な変更ログを確認する
• Claude Code のインストールまたは更新が必要な場合は、インストールガイドですべてのプラットフォームのセットアップ (1行インストールコマンドを含む) をカバーしている

/simplify と /batch は Claude Code の向かう先を示している。一般的なエンジニアリングパターンをすぐに使えるマルチエージェントワークフローとして扱うバンドルされたコマンドだ。すべての差分をまだレビューする。すべての計画をまだ承認する。しかし、オーケストレーション作業、並行エージェントのスポーン、worktree 管理、結果の集約は、もはや自分で組み立てるものではない。プラットフォームが成熟するにつれて、このような方向のバンドルコマンドが増えることを期待してほしい。

事前構築されたエージェントオーケストレーション、カスタムスラッシュコマンド、これらのバンドルコマンドと並ぶマルチエージェントパターンを持つ開発フレームワークが欲しいか? ClaudeFast Code Kit は18の特化エージェントと、まさにこの種のワークフロー向けに設計されたパイプラインを同梱している。