/batch migrate src/ from Solid to React と入力したら、Claudeがコードベースを調査して20の作業単位に分割し、20個のエージェントが並列で実行、それぞれが独立したブランチにPRを作成して返してきた。それがClaude Code v2.1.63で追加された /batch の実際の動作だ。
v2.1.63で何が変わったか
Claude Codeの開発責任者であるBoris Chernyが2026年2月27日に発表し、翌28日にv2.1.63がリリースされた。このバージョンで /batch と /simplify という2つのコマンドが「bundled slash commands」として追加された。
Boris Chernyの発言を引用する。
Combined, these skills automate much of the work it used to take to (1) shepherd a pull request to production and (2) perform straightforward, parallelizable code migrations.
「PRを本番に送り届けるまでの作業」と「素直に並列化できるコードマイグレーション」の大部分を自動化する、という位置付けだ。
公式ドキュメントによる /batch の定義はこうだ。
/batch <instruction>: orchestrates large-scale changes across a codebase in parallel. Provide a description of the change and/batchresearches the codebase, decomposes the work into 5 to 30 independent units, and presents a plan for your approval. Once approved, it spawns one background agent per unit, each in an isolated git worktree. Each agent implements its unit, runs tests, and opens a pull request. Requires a git repository.
5〜30の独立した作業単位に分解し、各ユニットに1エージェントを割り当て、テスト実行とPR作成まで自動で行う。前提条件はgitリポジトリが存在すること、そしてPR作成に gh CLIが必要だ。
3フェーズで完結する仕組み
/batch は内部で3つのフェーズに分かれて動作する（claudefa.st による詳細解説）。
フェーズ1: リサーチと計画
まずExploreエージェントがコードベース全体をスキャンし、依頼された変更をどの単位で分割するか分析する。「このファイルとあのファイルをまとめて1ユニット」「このディレクトリを10ユニットに分割」といった計画を立て、ユーザーに提示する。
ここでユーザーが確認・修正できる。「このユニットは除外したい」「この2つは一緒にやってほしい」といった調整を加えてから承認する流れだ。
フェーズ2: 並列実行
承認後、各ユニットに1つずつバックグラウンドエージェントが生成される。各エージェントは isolation: "worktree" フラグで独立したgit worktreeを持ち、.claude/worktrees/ 以下で作業する。
引越し業者のチームと同じ構造だ。全荷物を1人で順番に運ぶより、各担当者が部屋別に同時進行する。1人が転んでも、他の人は止まらない。
各エージェントの作業フローはこうなっている。
フェーズ3: 進捗管理
実行中はステータステーブルがリアルタイムで更新される。各ユニットの状態（実行中・完了・失敗）と、完了したPRのURLが並ぶ。全エージェントが終了した時点でサマリーが表示される。
worktreeによる隔離が重要な理由
/batch がgit worktreeを使うのは、並列化のためだけではない。失敗した作業が他に影響しない保証をするためだ。
通常の開発では、1つのブランチで作業中にコンフリクトが起きると全体が止まる。/batch では各エージェントが完全に独立したworktreeを持つため、あるユニットで失敗が起きても他のエージェントはそのまま動き続ける。失敗したユニットだけを個別に再実行すればいい。
v2.1.63では同時に、「同一リポジトリのworktrees間でプロジェクト設定とauto memoryが共有される」機能も追加された（CHANGELOG.md）。各エージェントがCLAUDE.mdや.claude/の設定を共有しながらも、作業ツリーは独立して保つという設計だ。
worktreeのファイルは .claude/worktrees/ に作られる。不要になったら削除してよいため、.gitignore に追加しておくのが推奨だ。
/simplify との組み合わせ
/simplify は /batch と同日に追加されたコマンドで、単体でも使える。各 /batch ワーカーはPRを作成する前に自動で /simplify を実行する。
/simplify は3つの並列レビューエージェントを起動して動作する。
- コード再利用エージェント：重複コードや抽象化できる部分を検出
- 品質エージェント：可読性・保守性の問題を検出
- 効率エージェント：パフォーマンスや不要な処理を検出
3エージェントが git diff を起点に変更ファイルだけをレビューし、結果をまとめて提案する。工場の品質管理に例えると、3人の専門検査員が同時にチェックして結果をまとめる体制だ。
単体でも、PRを出す前の仕上げとして使うのが推奨ワークフローだ。
# 機能実装後、PRを出す前に実行
/simplify
# フォーカスを絞る場合
/simplify focus on memory efficiency
/simplify check for unnecessary dependencies
コマンド構文と具体的な使い方
/batch の基本構文はシンプルだ。変更の内容を自然言語で記述するだけでいい。
# フレームワーク移行
/batch migrate src/ from Solid to React
# ライブラリ置き換え
/batch replace all uses of lodash with native equivalents
# 型アノテーション追加
/batch add type annotations to all untyped function parameters
# テストフレームワーク変更
/batch migrate all test files from Jest to Bun Test
# APIレスポンス形式の統一
/batch standardize all API error responses to use { error: string, code: number } format
従来の「1ファイルずつ順番に修正」アプローチとの違いはこうだ。
# ❌ 従来のアプローチ
# 1. 対象ファイルのリストを手動で洗い出す
# 2. Claudeに1ファイルずつ渡して修正を依頼
# 3. マージコンフリクトを手動で解消
# 4. 各ファイルのテストを手動で確認
# 5. PRを手動で作成
# ✅ /batch のアプローチ
/batch migrate src/components/ from class components to hooks
# → Claudeが計画を提示（例: 20ユニットに分割）
# → ユーザーが計画を確認・修正して承認
# → 20エージェントが並列で実行
# → 各エージェントがテスト実行後、独立したブランチでPRを作成
# → 人間の仕事はPRをレビューするだけになる
向いているユースケースと向いていないユースケース
/batch が力を発揮するのは、「各ユニットが独立して実行できる変更」だ。あるファイルの修正が他のファイルの修正に依存しない状況が前提となる（claudefa.st）。
向いているユースケースはこうだ。
- フレームワーク移行（React to Vue、SolidJS to React）
- APIコントラクト変更に伴う全呼び出し元の修正
- 命名規則の一括変換
- 依存ライブラリの置き換え
- 未テストモジュールへのテスト追加
向いていないユースケースもある。
- 密結合な変更（Aを変えるとBの変更に影響する）
- 探索的なリファクタリング（何を変えるかが未定）
- 単一ファイルの修正
密結合な変更を /batch に渡すと、エージェント間の整合性が取れなくなって失敗するユニットが増える。「並列化できる変更かどうか」を先に判断することが重要だ。
使い始め方
/batch を使うには Claude Code を v2.1.63 以降に更新するだけでいい。
claude update
前提条件は2つ。
- アクティブなgitリポジトリであること
ghCLI がインストールされていること（PR作成に使用）
gh CLIがない場合、PRの作成ステップで失敗する。事前に gh auth login まで済ませておくこと。
人間がPRをレビューするだけになる
/batch が変えるのは、大規模なコード修正における人間の役割だ。
これまで「100ファイルをAIに修正させる」には、ファイルリストの作成、1ファイルずつの依頼、コンフリクト解消、PR作成と、大量の手作業が間に挟まっていた。/batch はその間をほぼ自動化する。
人間がやることは、フェーズ1の計画を確認して承認し、完成したPRをレビューする2ステップに絞られる。コードの変更量が大きいほど、この差は顕著になる。
/simplify がセットになっているのも理にかなっている。大量のPRを受け取っても、各PRがすでに品質チェックを通過しているなら、レビューの負荷が下がる。
ただし、各エージェントはテストを実行してPRを作成するが、コードが正しいかどうかの判断は最終的に人間が行う。PRを承認してマージするのはあなたの仕事だ。エージェントの数が増えても、レビューの責任はなくならない。
