全面リファクタリングに何日も？ /batchで大きな変更を数十片に分けて同時処理

ライブラリを丸ごと変えたり、すべてのAPIに検証コードを入れたりするような「全面工事」。いざ始めると何日もかかり、量が山積みで手をつける気にすらなれませんね。一つずつ手で直していると、どこまでやったか分からなくなったりもします。/batchはこうした大規模な作業のためのコマンドです。大きな変更を数十個の片に分けて同時に処理し、何日もかかる仕事を数時間に縮めてくれます。上級機能なので、入門段階なら「こういうのがあるんだな」程度に知っておけばいいです。

定義

/batchは大きな変更を5〜30個単位に分けて並列で処理するコマンドです。

核心となる概念を二つ押さえます。

• 並列処理: 作業を細かく分けて複数を同時に進める方式です。一人が順番にやる代わりに、複数の働き手がそれぞれ一片ずつ受け持って同時に働くわけです。
• worktree（ワークツリー）: 各片が作業する隔離された作業空間です。片ごとに別々に分離された部屋で作業するので、一片の変更が別の片を壊しません。

そして各片は作業を終えるとPR（Pull Request、変更内容を合わせてくれと出す要求）まで作ってくれます。つまり「分割 → 同時作業 → それぞれPR提出」が自動で流れていくのです。

使い方（難易度別）

基礎 — 大規模な変更を任せる

チャット欄に変更範囲と内容を書いて入力します。

/batch src/ フォルダをSolidからReactに転換して

入力するとClaudeがこの大きな作業を複数の片に分けたあと、各片を隔離された空間で同時に進めます。画面には片別の進行状況が表示され、終わるとそれぞれの変更がPRの形で整理されます。

応用 — 範囲を指定して分担させる

/batch すべてのAPIエンドポイントに入力値の検証ロジックを追加して

「コード全般にわたる繰り返し作業」も分担させられます。数十個のAPIに同じ検証を入れる仕事を片に分けて同時に処理するので、一つずつ手をつけるよりずっと速いです。

よくある落とし穴 — 結果を一度に合わせず、まず検討

/batchの強みは速度ですが、その分注意点があります。複数の片が作ったPRを検討なしに一度に合わせると危険です。

• 各片は隔離された空間で別々に作業するので、互いに衝突したり一貫性が合わない変更が生じることがあります。
• だからbatchが終わったあとは、各PRの変更内容を（例: /diffで）検討して一つずつ合わせるのが安全です。

速く作ってくれる分、合わせる前の検討は人の役目だという点を覚えてください。入門段階で大きなコードベースにすぐ使うより、小さな範囲で一度試してみることをおすすめします。

実例

古いライブラリを新しいバージョンに丸ごと移すマイグレーション作業がありました。手でやると何日もかかるものでした。/batchで作業を30個単位に分けて同時に進めました。

/batch プロジェクト全体の旧バージョンのライブラリを新バージョンにマイグレーションして

各片が隔離された空間で同時に回りながらPRを作り出し、私はPRを一つずつ検討しながら合わせました。順番にやれば何日もかかっていた大工事が、ずっと短い時間で終わりました。

もっとこう使えます

• 5〜30片に分解: 大きな変更を独立した単位に分けて同時処理します。
• 隔離実行 + PR: 各片が別々に作業したあとPRで結果を提出。
• 大規模マイグレーション: ライブラリの置き換え、フレームワークの転換のような大工事に適合。
• 進行管理: 複数の片が回る分、進行状況を見守りながら管理するといいです。

ヒント: /batchは強力な分、危険も大きいです。最初は小さなフォルダ一つで試してみて、結果のPRを必ず検討する習慣をつけてから大きな範囲に広げましょう。

まとめ

肝心なのは一文です。一人で何日もかかる大工事は/batchで分けて同時に処理しろ。大きな変更を自動で分担させられるので、全面リファクタリングやマイグレーションも速く終えられます。ただし、速い分、合わせる前の検討は必ず人が行わなければなりません。

基準: Claude Code v2.1.154 (2026.05)