/batchとは｜Claude Codeで大規模な変更を並列処理する

「Claude Codeの/batchは結局何をしてくれるのか、名前だけでは想像しにくい」——コードベース全体に同じような変更を何十ファイルも入れる場面で、多くの人がこの疑問にぶつかります。

結論から言うと、/batchは大きな変更を5〜30個の独立した単位に分解し、それぞれを別々のAI（サブエージェント）に並行して任せる、Claude Codeに最初から入っているバンドル済みスキルです。インストールは不要で、/batch 指示内容と打つだけで使えます。

株式会社Fyveは中小企業のAI活用を月額で伴走支援しており、Claude Codeを日常的に業務で使っています。この記事では、Anthropic公式ドキュメント（2026年9月4日時点）で確認できた/batchの仕様だけをもとに、何ができて、どういう仕事に向いているのかを整理します。

/batchとは——大規模な変更を並列処理するバンドル済みスキル

公式ドキュメントは/batchを次のように説明しています。「コードベース全体にまたがる大規模な変更を並列で調整する。コードベースを調査し、作業を5〜30の独立した単位に分解して計画を提示する。承認されると、単位ごとに1体のバックグラウンドサブエージェントを、独立したgit worktree内で立ち上げる。各サブエージェントは自分の担当を実装し、テストを実行し、プルリクエストを作成する。gitリポジトリが必須」。公式が挙げている実行例は/batch migrate src/ from JavaScript to TypeScript（srcディレクトリをJavaScriptからTypeScriptへ移行する）です。

/batchはClaude Codeにバンドル済みのスキルの1つで、/doctorや/code-reviewなどと同じ枠に属します。バンドル済みスキルは、詳細な指示をClaudeに渡し、Claudeがツールを使って自分で作業を組み立てる「プロンプトベース」の仕組みで動きます。追加のインストール作業は不要で、セッション開始時から呼び出せます。disableBundledSkillsという設定で一括してオフにもできます（/doctorだけは対象外）。

Claude Codeに標準搭載されているスキル・コマンドの全体像は、こちらの記事で一覧にしています。

Claude CodeClaude Codeのバンドル済みスキル一覧｜追加インストール不要で使えるもの

事実——4つの工程でできていること

公式ドキュメントの説明を、実際に動く順番に並べ直すと4つの工程になります。

ポイントは3番目の「承認」が独立した工程として挟まっていることです。/batchを実行しても、いきなりリポジトリ全体が書き換わるわけではありません。計画を見て、規模や分解のしかたに納得してから初めて実行段階に進みます。

4番目に出てくる「git worktree（ワークツリー）」は、同じリポジトリの中に複数の独立した作業ディレクトリを用意する仕組みです。1つのフォルダを複数のAIが同時に触ると、お互いの変更が衝突してしまいます。worktreeを使うと、サブエージェントごとに「自分専用の作業スペース」が用意されるため、5〜30体が同時に動いても、途中の作業が他のサブエージェントの手元を書き換えることはありません。最終的な成果は、サブエージェントごとに独立したプルリクエスト（変更内容をまとめてレビューできる形にしたもの）として届きます。

「新しい並列処理の仕組み」ではない

Anthropic公式ドキュメントの並列実行に関する解説では、/batchについてこう説明されています。「/batchは、1つの大きな変更を5〜30個のworktreeで隔離されたサブエージェントに分割させ、それぞれがプルリクエストを開くスキルである。これはサブエージェントとworktreeを組み合わせて使う定型パターンであり、別の調整方式ではない」。/batchという専用のエンジンが裏で動いているというより、Claude Codeがもともと持っている「サブエージェントを並行で走らせる」「worktreeで作業スペースを分ける」という2つの機能を、決まった手順にパッケージ化したものと理解するのが正確です。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

検証——なぜ「普通に頼む」のと違うのか

大規模な変更自体は、/batchを使わずに「このリポジトリ全体で〜を直してください」とそのままClaudeに頼んでも進められます。それでも/batchが別立てで用意されているのは、進め方そのものが違うからです。

通常の1つの会話でまとめて頼んだ場合、Claudeは同じ作業ディレクトリの中でファイルを1つずつ順番に処理していきます。対象が数十ファイルに及ぶと、どこまで終わったかを自分で追跡し続ける必要があり、最終的な変更は基本的に1つの大きな差分としてまとまります。/batchはここを構造的に変えます。単位ごとに専用のworktree（独立した作業ディレクトリ）を割り当てるため、複数のサブエージェントが同時に動いても互いのファイルを踏みにいく心配がなく、成果も単位ごとに独立したプルリクエストとして分かれて届きます。1つの巨大な差分をあとから読み解くのではなく、最初から「レビューしやすい大きさ」に割った状態で受け取れる、というのが構造上の違いです。

判断——向いている仕事・向いていない仕事

公式ドキュメントが「5〜30の独立した単位に分解する」と説明していることから、向き不向きが見えてきます。裏を返せば、分解した各部分が本当に独立していない仕事や、そもそも5個未満にしか分けられないほど小さな仕事には向きません。

実務——使う前に確認しておきたいこと

実際に使う前に押さえておくとよい前提が3つあります。

• gitリポジトリが必須：公式ドキュメントに明記されている唯一の必須条件です。git管理していないフォルダでは使えません
• 計画の承認は飛ばせない：分解・計画提示のあとに承認ステップがあるため、内容を見ずに一括実行される心配はありません。規模が大きすぎる、分解の仕方がおかしいと感じたら、その場で止められます
• 同時に動く分だけ、消費と後片付けが増える：単位ごとに1体のサブエージェントが並行して動くため、1体に順番に頼むより多くのやり取りが同時進行します。仕上がりも単位の数だけプルリクエストとして届くので、最終的なレビュー・マージ作業は人間側に残ります
• 複数のプルリクエストが同じファイルに触れていないか、マージ前に確認する：単位は「独立している」という前提で分解されますが、思わぬところで同じファイルに変更が重なっていないかは、最終的に人間側でも一度目を通しておくと安心です

指示の書き方のコツ

公式の実行例は/batch migrate src/ from JavaScript to TypeScript（srcディレクトリをJavaScriptからTypeScriptへ移行する）というシンプルな一文です。この形からわかるとおり、/batchへの指示は「どの範囲を」「どう変えるか」を短く明示するのが基本になります。対象ディレクトリやファイル群の範囲があいまいなまま指示すると、分解の計画自体がずれやすくなるため、範囲を先に絞ってから頼むほうが、提示される計画を確認しやすくなります。

実務のイメージ——具体例で考える

たとえば、20店舗ぶんの店舗紹介ページを個別のファイルとして持つWebサイトで、すべてのページに埋め込んでいる古いお問い合わせフォームのコードを、新しいフォームサービスのコードに差し替えたい、という場面を考えてみます。

/batchにこの指示を出すと、Claudeはまずリポジトリを調査し、対象の埋め込みコードがどのファイルに何箇所あるかを洗い出します。そのうえで「20店舗ページ＋共通レイアウト1件＝21個の独立した単位」のように分解した計画を提示します。ここで、店舗ページ同士は互いに依存していない（1店舗ぶんの修正が他の店舗ページに影響しない）ため、独立した単位として扱える、という判断です。計画を確認し、分解のしかたに問題がなければ承認します。

承認後は、21体のサブエージェントがそれぞれ独立したworktreeで動き、担当のページを書き換え、用意されていればテストを実行し、変更ごとにプルリクエストを作成します。人間側は、届いた21件のプルリクエストを順に確認しながらマージしていく、という流れになります。1店舗ぶんの修正だけ差し戻したい場合も、そのプルリクエストだけを保留にできるという点は、1つの巨大な差分で受け取るより扱いやすいところです。

よくある誤解を防ぐ

誤解1：承認なしでいきなりコードが書き換わると思ってしまう

/batchは「調査→分解・計画提示→承認→並列実行」という順番で進みます。計画を確認して承認するまでは、実際のコード変更は始まりません。

誤解2：/batchは独立した並列実行エンジンだと思ってしまう

公式の説明どおり、/batchはサブエージェントとgit worktreeという既存の仕組みを組み合わせた「パッケージ化された使い方」です。まったく新しい実行基盤が動いているわけではありません。

誤解3：どんな変更でも/batchに投げれば速くなると思ってしまう

5〜30の独立した単位に分解できることが前提になっています。手順が前後に依存する仕事や、そもそも小さくまとまる仕事では、分解の恩恵が出にくく、1つの会話でそのまま進めたほうが速いこともあります。

誤解4：「裏で動き続ける機能」はすべて/batchの仲間だと思ってしまう

Claude Codeには、指示を出したあとも裏で動き続ける機能が/batch以外にもあります（セッションごと裏側に回して手元の作業を続けられるようにする機能など）。ただし公式ドキュメントは、こうした機能は/batchとは別の課題を解決するためのものだと整理しています。/batchが解決しているのは「1つの大きな作業を独立した単位に割って並列で進める」という課題であり、「セッションを裏に回して自分は別の作業をする」という課題とは別物です。名前や見た目が似ていても、解決している問題が違う、という点は区別しておくと混同しにくくなります。

/batchのよくある質問

/batchを使うのにインストールは必要ですか

不要です。/batchはClaude Codeに最初から入っているバンドル済みスキルで、追加設定なしに/batch 指示内容と入力するだけで呼び出せます。

gitを使っていないプロジェクトでも使えますか

使えません。公式ドキュメントは「gitリポジトリが必須」と明記しています。各サブエージェントの作業をworktreeという仕組みで分離する都合上、gitリポジトリであることが前提になります。

実行すると、すぐにコードが書き換わりますか

いいえ。コードベースの調査と作業の分解が終わると、まず実行計画が提示されます。承認するまでは実際のコード変更は始まりません。

何体のAIが同時に動きますか

作業は5〜30個の独立した単位に分解され、1つの単位につき1体のバックグラウンドサブエージェントが割り当てられます。分解された単位の数だけ、サブエージェントが並行して動くことになります。

作業の結果はどうやって受け取りますか

単位ごとに独立したプルリクエストとして届きます。1つの巨大な差分としてではなく、レビューしやすい単位に分かれた状態で受け取れます。

/batchはどんな作業にも使ったほうがいいですか

いいえ。分解のメリットが出るのは、対象が5〜30個程度の独立した単位に分けられる規模の作業です。1〜2ファイルで完結する小さな修正や、手順に前後の依存関係がある作業は、通常の会話でそのまま進めるほうがシンプルです。

まとめ｜/batchを使う前のチェックリスト

最後に、/batchを使う前に確認しておきたい点をチェックリストにまとめます。

• gitリポジトリであること。これが唯一の必須条件
• 変更が5〜30個の独立した単位に分解できる仕事かどうか。依存関係の強い作業や、1〜2ファイルで済む小さな作業には向かない
• 実行前に計画が提示され、承認するまでコードは変わらない
• 実行はサブエージェント単位で並行して進み、成果は独立したプルリクエストとして届く
• 最終的なレビュー・マージは人間の仕事として残る
• インストール不要。disableBundledSkills設定で無効化されていなければ、そのまま/batch 指示内容で呼び出せる

大きな変更を「1つずつ頼むと日が暮れる」と感じたときに、まず候補に挙げる価値があるスキルです。ただし向いているかどうかは、変更が本当に独立した単位へ分解できるかどうかで決まります。実行前の計画画面で、その分解のしかたに納得できるかを確認してから承認する、という使い方が安全です。

非エンジニアの立場で使う場合も、確認すべきことは変わりません。提示された計画が「対象範囲」「分解された単位の数」「それぞれの単位が独立しているように見えるか」の3点で無理がないかを見れば、承認していいかどうかは判断できます。中身のコードそのものを読めなくても、この3点の確認だけで、意図しない範囲まで手を広げられてしまうリスクは大きく減らせます。