Claude Codeを1ヶ月以上使っていて、プロジェクト全体に渡る大規模な書き換えをしたい人向け
プロジェクトの広範囲に同じ書き換えを当てたいときに叩く。例えば「料理レシピサイトの50本のmdファイルを全部英訳して別フォルダに保存」「家計簿アプリの30個のコンポーネントを古いライブラリから新しいライブラリに移す」「他人のOSSをコピーしてきて全ファイルにライセンス表示を入れる」みたいな、1個ずつなら独立してできるけど数が多い場面。直す対象が3〜4ファイルしかない時や、ファイル同士が密に絡んでいて分割できない時は使わない
「プロジェクトの50ファイルに同じ書き換えを順番に当てていく」みたいな、退屈で量だけある作業を、Claude Codeに「丸ごと一気にやってくれ」と頼むためのスラッシュコマンドが/batchです。
渡された指示をClaudeが自分で5〜30個のかたまりに割り、それぞれを別の作業場所で同時に動かして、最終的に1個ずつの「変更の取り込み申請」にして返してきます。順番にやれば1日かかる作業を、並列で30分に畳むためのコマンドという立ち位置。
噛み砕くと
会社の引っ越しを想像すると分かりやすいです。荷物が50箱あるとき、1人で1箱ずつ運んでいたら丸一日。代わりに引っ越し業者を10人呼んで「君はキッチン担当、君は寝室担当」と分担を切れば、1時間で終わります。
/batchがやっているのは、ほぼこれと同じ「分担を切る → 同時に動かす → 終わったら1人ずつ完了報告」の流れ。指示する側がやるのは「何をしてほしいか」を1行で伝えるだけです。
分担を考えるのも、各担当者を動かすのも、テストを通すのも、報告書を書くのも全部Claude側がやります。
大事な前提：gitで管理されているフォルダでないと動かない
このコマンドは、内部で「worktree」というgitの仕組みを使って作業場所を増やします。なので.gitフォルダが無い場所では起動しません。
逆に言えば、新規プロジェクトでもgit initを1回叩いて初期保存を済ませてあれば動きます。「いきなり50ファイル書き換える前に、現状をひと区切り保存しておく」のも安全策として大事です。
「料理レシピサイトの50本を英語版に翻訳」を例に、実際の手順を見る
料理レシピサイトを運営していて、recipes/フォルダの中にmarkdownのレシピが50本あるとします。これを全部英語版にしたい。1本ずつChatGPTにコピペしていたら半日コース。/batchで一気に投げます。
ステップ1：作業前に現状を保存しておく
並列実行が走る前に、現状を「ここまで」とひと区切り保存しておきます。これは保険です。途中で気が変わって戻したくなった時に、ここに戻れる起点を作っておく。
$ git add .
$ git commit -m "翻訳作業の前の状態"ステップ2：Claude Codeを起動して /batch を打つ
会話欄にこう打ち込みます。指示は普通の日本語＋具体的なファイルの場所、で十分通じます。
/batch recipes/配下のmdファイル50本を全部英訳して、recipes-en/配下に同じファイル名で保存して。frontmatter（mdファイル先頭のメタ情報）は構造を保ったまま、値だけ英訳してステップ3：Claudeが調査して計画を出してくる
このコマンドの肝はここ。打った瞬間に作業が始まるわけではなく、まずClaudeがrecipes/を眺めて、こんな計画を返してきます。
調査結果：recipes/に50本のmdファイルを確認
分解：5本ずつ10ユニットに分けて並列実行します
unit 1: recipes/01-curry.md 〜 recipes/05-pasta.md
unit 2: recipes/06-soup.md 〜 recipes/10-salad.md
...
unit 10: recipes/46-cake.md 〜 recipes/50-pudding.md
各ユニットの作業：英訳 → recipes-en/に保存 → テスト → 取り込み申請を作成
承認しますか？ (y/n)ここで初心者がやりがちな勘違いがひとつ。「コマンドを打ったらもう走り出してる」と思って待ち続けてしまう人がいます。実際は承認の入力待ちで止まっているので、yを押さない限り何も始まりません。
ステップ4：承認すると並列で10個の作業場所が立ち上がる
yを押すと、Claudeは裏で10個の作業場所（worktree）を作って、それぞれに別々の「分身Claude」を配置します。10人の作業者が同じプロジェクトの別フォルダで同時に翻訳を始めるイメージ。
本体側のフォルダはいじられません。10個のworktreeはどれも独立しているので、unit 1が書き換えているファイルとunit 2が書き換えているファイルは衝突しない。
ステップ5：それぞれが終わったら取り込み申請が10個並ぶ
各分身が翻訳を終えて、テストを通して、自分の作業を取り込み申請の形でまとめます。GitHub上で見るとこんな感じ。
#101: [batch unit 1] Translate recipes 01-05 to English
#102: [batch unit 2] Translate recipes 06-10 to English
...
#110: [batch unit 10] Translate recipes 46-50 to Englishステップ6：人間が1個ずつ中身を確かめて本体に取り込む
ここから先は普通の確認作業。10個の申請を順番に開いて、翻訳が違和感ないか確認してから本体に取り込んでいきます。全部一度に取り込むこともできるし、品質が怪しいunitだけ突き返して再実行することもできます。
つまり /batch は何をしてくれるのか
- やってくれる：1つの大きい指示を5〜30個の小さい作業に勝手に割って、同時並行で動かす。各作業のテストと取り込み申請の作成までやる
- やってくれない：いきなり本体のファイルを書き換える、勝手に本体に取り込む、1ファイルだけの修正を分割する、計画を見せずに走り始める
- 意味が薄い場面：直すのが3〜4ファイルしかない時（普通に頼んだほうが早い）、ファイル同士が密に依存していて分割できない時、テストが整備されていないプロジェクト（テストが通ったか判定できない）
使いどころ3シナリオ（具体題材で再現）
シナリオ1：料理レシピサイトのレシピを多言語化したいとき
日本語レシピ50本を持っていて、英語版・中国語版・韓国語版を増やしたい。1言語ずつ/batchを回して、3晩で150ファイル生成、というスケジュールが組めます。1本ずつコピペで翻訳していたら3週間かかる作業が、人間の作業時間は中身の確認だけになる。
シナリオ2：家計簿アプリのコードを古いライブラリから新しいライブラリに移すとき
公式の例文がまさにこれ（/batch migrate src/ from Solid to React）。ボタンやフォームを別の仕組みで書き直す作業は、コンポーネント1個ずつなら独立してできます。30個のコンポーネントを30個のサブエージェントで同時並行して書き換えて、それぞれを取り込み申請にしてもらえば、人間は1個ずつ見比べて本体に取り込める。
シナリオ3：他人のOSSをコピーしてきて、全ファイル共通の修正を入れたいとき
例えば「全ファイルの先頭にライセンス表示を入れる」「console.logを全部logger.debugに置き換える」みたいな、機械的だけど数が多い作業。grep＋sedでもできますが、ファイルごとに微妙な書き分けが必要な時は/batchに任せると、各サブエージェントが文脈を見ながら判断してくれます。
初心者が踏みやすい落とし穴
- 計画が出たあとの承認待ちを見落とす。コマンドを打ったらすぐに10並列で動き始めると思って、画面を閉じてしまう人がいます。yを押すまで何も始まりません
- gitで管理されていないフォルダで叩いてエラーになる。新規プロジェクトを作って即
/batchするとworktreeが作れず動かない。先にgit initと1回目の保存を済ませる - 「独立した作業」だと思って分けたら、実はファイルが被って衝突する。Claudeの分け方が常に正しいわけではないので、計画が出た時点で「同じファイルを2つのユニットが触る予定になっていないか」を一度目視で確認する
- 外部の有料サービスを叩く作業を50ユニットで並列実行すると、回数制限や請求が一気に跳ねる。翻訳APIやLLMを叩く作業を
/batchで並列化する時は、ユニット数を控えめに指定する（指示文に「10ユニット以下で」と書く）か、有料分の見積もりを先に取る /simplifyや/reviewと役割を混同する。/simplifyは最近書き換えたファイルの品質チェック、/reviewは変更コードを読むだけ、/batchはプロジェクト全体の大規模な書き換え。「品質チェックしたい」のに/batchを叩くと、いきなりプロジェクト全体を書き換える計画が出てきて慌てる- テストが整備されていないプロジェクトに投げて、品質を判定できないまま10件の取り込み申請が並ぶ。各サブエージェントは「テストを通す」工程を含むが、そもそもテストが存在しないと「変更しても落ちない＝OK」と扱われてしまう。先に最低限のテストを書いておくか、人力の確認に体力を多めに振る覚悟で投げる
- 取り込み申請が10〜30個並んだあとの確認作業を甘く見る。生成は10分で終わっても、1件10分かかると合計5時間。「
/batchを叩いた瞬間に終わる」わけではなく、「並列生成の後に直列確認が残る」点は忘れない
書き方
/batch <やってほしいことを1〜2文で>やってみるとこうなる
入力
/batch recipes/配下のmdファイル50本を全部英訳して、recipes-en/配下に同じファイル名で保存して。frontmatter（mdファイル先頭のメタ情報）は構造を保ったまま、値だけ英訳して出力例
調査結果：recipes/に50本のmdファイルを確認
分解：5本ずつ10ユニットに分けて並列実行します
unit 1: recipes/01-curry.md 〜 recipes/05-pasta.md
unit 2: recipes/06-soup.md 〜 recipes/10-salad.md
...
unit 10: recipes/46-cake.md 〜 recipes/50-pudding.md
各ユニットの作業：英訳 → recipes-en/に保存 → テスト → 取り込み申請を作成
承認しますか？ (y/n)
[yを入力すると、10個のworktreeが立ち上がり、それぞれの分身Claudeが並行して作業を開始。完了するとGitHub上に10件の取り込み申請が作成される]このページに出てきた言葉
- bundled skill
- Claude Codeに最初から入っている「やり方の指示書」付きのスキル。決まったロジックを動かす内蔵コマンドと違って、Claudeがプロンプトの指示を読んで自分のツールを使って動く方式
- worktree（ワークツリー）
- 同じプロジェクトを別フォルダにもう一つ展開するgitの仕組み。本体を壊さずに別の作業を並行できる作業場所
- サブエージェント
- メインのClaudeとは別に、裏で並行して動く分身のClaude。本体と会話を共有せず、与えられた仕事だけをやる
- ユニット（unit）
- <code>/batch</code>が作業を分けたときの1かたまり。「unit 1はファイル1〜5を担当」のように範囲が決まっている
- 変更の取り込み申請
- GitHubで「ここを書き換えました、本体に取り込んでいいですか？」とお伺いを立てる仕組み。GitHub上では1件1件に番号がついて並ぶ。中身を画面で見てから、人間がOK／NGを決める
- プロジェクトの保管箱
- プロジェクトのファイル一式と変更履歴をまとめて入れておく箱。<code>.git</code>フォルダがあればその場所は保管箱として扱われる
- frontmatter（フロントマター）
- mdファイルの先頭に書く設定ブロック。<code>---</code>で囲って「タイトル」「日付」「タグ」などのメタ情報を書く