はじめに
前回、Claude Codeのスラッシュコマンドを開発フローの場面ごとに整理しました。その中で「これを知らなかったのが一番もったいなかった」と書いたのが、並行して作業を進めるためのコマンド群です。
場面の分類だけだと、実際にどう変わるのかが伝わりにくいので、今回は/batch /fork /background /tasksを、実際の業務開発でありそうな場面に当てはめてBefore/Afterで見ていきます。コードの中身そのものより、「作業の進め方がどう変わるか」に焦点を当てています。
/batch｜横並びの修正を一括分解する
場面：APIのエラーレスポンスの形式を統一する対応で、対象は20個のエンドポイント。それぞれ似たような修正だが、ファイルは別々。
Before：1つのチャットでエンドポイントを1つずつ指定して直してもらう。19回目あたりで「さっきの形式、忘れてないか」と確認しながら進めることになる。
After：対象ファイルの一覧と修正方針を渡して/batchで実行する。1つの大きな作業を5〜30個くらいの単位に分解して並行で実装させる仕組みなので、20個のエンドポイントをまとめて渡せば、各ファイルへの適用を並行で進めてくれる。
1個ずつ直すと「直したつもり」が積み重なって最後の数個で抜け漏れが出る。最初に全部投げて並行で終わらせた方が、最終確認も1回で済む。
向いているのは、修正方針が決まっていて、対象ファイルが多いだけの作業。逆に方針自体が固まっていない段階で投げると、間違った方針が全ファイルに広がるので、1ファイルで試してから全体に展開する順番は守った方がいい。
/fork｜本流と横道の調査を分ける
場面：新しい機能を実装している最中に、別のところで発生しているエラーログの原因が気になりだした。今の実装を止めて調査に入ると、会話の文脈が混ざる。
Before：同じ会話の中で「ちょっとこのログも見て」と聞いてしまい、実装の話と調査の話が交互に出てくる会話になる。後で見返すと、どこまでが実装の話だったか分かりにくい。
After：今の会話を引き継いだサブエージェントを/forkでバックグラウンドに起動し、ログ調査だけそちらに任せる。本流の会話はそのまま実装を続けられる。
横道に逸れたくなった瞬間に「これは別腹」と切り出せるのが大きい。本流の会話が調査ログで汚れないので、後から実装の経緯だけ追いたいときに読みやすい。
/background + /tasks｜重い処理を裏で走らせる
場面：DBのマイグレーションスクリプトを流す必要があるが、終わるまで数分かかる。その間ターミナルを占有されると、他の作業に進めない。
Before：実行が終わるまで待つ。終わったら次の作業に移る。待ち時間がそのまま手待ちになる。
After：マイグレーションの実行を/backgroundでバックグラウンドに切り離し、ターミナルを解放する。その間に別の修正作業を進め、/tasksで裏の処理がどこまで進んでいるかを確認する。
「裏で何が動いているか分からなくなる」のが一番怖いところだったが、/tasksで一覧を見られるので、放置していい処理かどうかをいつでも判断できる。
E2Eテストの実行や、ビルドの待ち時間など、終わるまで結果が分からないが手元の作業を止める必要はない処理全般に同じ考え方が使える。
逆引き早見表
| 場面 | コマンド |
|---|---|
| 方針が決まった修正を多数のファイルへ広げたい | /batch |
| 本流の作業を止めずに横道の調査を任せたい | /fork |
| 終わるまで待つだけの重い処理を裏で走らせたい | /background /tasks |
まとめ
並行作業系のコマンドは、どれも「1つずつ順番に」が当たり前になっている作業フローに気づかせてくれるものでした。修正方針が決まっている横並びの作業、本流から切り離していい横道の調査、結果を待つだけの重い処理。この3パターンに当てはまる場面を見つけたら、それぞれ/batch /fork /backgroundを試してみる価値があります。
次は、会話そのものの整理や計画に使うコマンドを、業務開発の具体例でまとめます。
最後まで読んでいただきありがとうございました。