この記事の結論

Claude Codeで複数の作業を同時に進めたいけれど、ターミナルやセッションが散らかって何が動いているか分からなくなる、という悩みに向けた記事です。結論として、外部の統合ツールを新しく覚えなくても、Claude Code標準のサブエージェント・権限モード・巻き戻し・文脈整理の4つを組み合わせれば、並行作業時の混乱はかなり防げます。対象読者は、Claude Codeを使い始めて複数タスクの同時進行に課題を感じ始めた人です。
複数タスクが散らかる原因と判断基準

複数の作業をClaude Codeに任せようとすると、1つの会話の中に無関係な作業が混ざり、文脈が膨らみ、どこまで進んだか分からなくなりがちです。原因を切り分けると、だいたい次の3つに当てはまります。
- 調査・下書き・検品のような性質の違う作業を1つの会話でやろうとしている
- 大きな変更をいきなり実行させて、後から収拾がつかなくなっている
- 会話が長くなり文脈が埋まっているのに、整理せずそのまま続けている
この3つのどれに当てはまるかで、使うべき機能が変わります。作業の性質が違うならサブエージェントに分担させる、変更が大きいならPlan modeで計画から合意する、文脈が埋まっているなら/compactや/clearで整理する、という判断基準です。
再現可能な手順:作業を分担させて混乱を防ぐ

手順1 大きな作業はいきなり実行させない
指示の先頭に /plan を付けるか、会話中にShift+Tabを押してPlan modeに切り替えます。Plan modeではClaudeが調べて計画だけを書き、ファイルは編集しません。計画の対象・手順・確認方法を見て、問題なければ承認して実行に移ります。起動時からPlan modeにしたい場合は claude --permission-mode plan で起動します。
手順2 性質の違う作業はサブエージェントに分担させる
調査、下書き、検品のように役割が分かれる作業は、サブエージェントに任せると本体の会話が汚れません。サブエージェントは自分専用の文脈で作業し、要約だけを本体の会話に返すため、検索結果やログで会話が埋まるのを防げます。組み込みのExplore(読み取り専用のコード検索)、Plan(計画中の調査)、general-purpose(調査と変更の両方)のほか、自分で定義することもできます。名前を文章で書けば任せるかどうかはClaudeが判断し、@調査担当 のように@でメンションすれば確実にそのサブエージェントが動きます。
自作する場合は、プロジェクト用なら .claude/agents/、全プロジェクト用なら ~/.claude/agents/ にYAMLフロントマター付きのMarkdownファイルを置きます。
手順3 文脈が埋まってきたら整理する
/context で今の文脈使用量を確認できます。関係ない作業に移るときは /clear で空の文脈から始め、直前の会話は /resume で呼び戻せます。同じ話題を続けたまま要約だけしたい場合は /compact に残したい焦点を指示として渡します。
この図は、1つの作業依頼が来てから完了するまでの時間の流れを軸に、Plan mode→承認→実行→確認という手順の順序を示します。図の矢印の向きに沿って、今どの段階にいるかを確認し、計画の承認をまだしていないなら先に計画を見直してから実行に進んでください。
手順4 長時間動かす作業は権限モードを選ぶ
権限モードはShift+Tabで切り替えます。既定のManualは編集やコマンドの前に毎回確認し、autoは確認を別のモデルが審査します(Pro・Max・Teamの既定)。bypassPermissionsは確認と安全チェックをすべて飛ばすモードで、公式はネットにつながらない隔離環境だけで使うよう案内しています。普段の作業でbypassを使うのは避け、長時間の無人作業はauto、重要な変更はManualかPlan modeで進めるのが安全です。
具体例:指示文とスキルの書き方

調査と下書きを分けたいとき、Claude Codeに貼る指示文の例です。
@general-purpose サブエージェントで、過去30日分のログからエラー傾向を調査してください。
調査結果は要約だけを本体の会話に返してください。
調査が終わったら、本体の会話で下書きの方針をPlan modeで確認してから実行します。
毎回同じ手順で行う作業はスキルにしておくと呼び出しが楽になります。スキルはSKILL.mdに手順を書いたファイルで、プロジェクト用は .claude/skills/<名前>/SKILL.md、全プロジェクト用は ~/.claude/skills/<名前>/SKILL.md に置きます。記述例は次の通りです。
---
name: log-review
description: ログファイルからエラー傾向を調査し要約する
---
## 手順
1. 指定されたログフォルダを読み込む
2. エラーの種類ごとに件数を集計する
3. 多い順に3件、原因候補とあわせて要約する
4. 出力はMarkdownの箇条書きのみとする
選択肢の比較:どの整理方法を選ぶか

複数の選択肢があるとき、どれを選ぶかで結果が変わります。目的別に整理しました。
| 機能 | 何をするか | 選ぶ場面 |
|---|---|---|
| /compact | 会話を要約して文脈を空ける | 同じ話題を続けながら文脈を減らしたいとき |
| /clear | 空の文脈で新しい会話を始める | 関係ない別の作業に切り替えるとき |
| /rewind | コードや会話を特定の時点に戻す | 直前の変更や発言を取り消したいとき |
/rewind は入力欄が空の状態でEscを2回押すか /rewind コマンドで巻き戻しメニューが開き、「コードと会話」「会話のみ」「コードのみ」のどれを戻すか選べます。ただしBashコマンドで変更したファイルは巻き戻しの対象外です。この制限への対策は、Bashで直接ファイルを操作する前に一度コミットしておくか、重要な変更前はEditツールでの変更に留めておくことです。
失敗例と対策
失敗例1 1つの会話に全部詰め込んで文脈が埋まる
調査もコーディングもレビューも1つの会話で続けると、関係ない情報が文脈を圧迫し、Claudeの応答が的外れになっていきます。対策は、作業の性質が変わるタイミングで /clear するか、最初からサブエージェントに分担させることです。
失敗例2 bypassPermissionsのまま普段使いしてしまう
確認をすべて飛ばすbypassPermissionsは便利に見えますが、公式がネットにつながらない隔離環境専用としている通り、通常の開発環境で使うと意図しない変更が入り込むリスクがあります。対策は、長時間の無人作業でもautoモードに留め、本当に隔離環境が必要な場合だけbypassを検討することです。
失敗例3 Bashで変更したファイルを巻き戻せると思い込む
Bashコマンドで直接書き換えたファイルは/rewindの対象外のため、戻せると思って大胆な変更をすると取り返しがつきません。対策は、Bashで大きな変更をする前に一度Gitでコミットしておくことです。
初心者向け最小構成
複数タスクの管理を始めたばかりの人は、次の3つだけ覚えれば十分です。
- 大きな変更の前は
/planを先頭に付けて計画を確認してから実行する - 作業の話題が変わったら
/clearで会話をリセットする - 迷ったら
/contextで今の文脈使用量を見る
サブエージェントや複数モードの切り替えは、この3つに慣れてから取り入れれば十分です。
中上級者向け応用:サブエージェントの並行数と安全性
調査・下書き・検品のように役割を分けてサブエージェントを動かす場合、同時に動かす数が増えすぎると今度は人間側の監視が追いつかなくなります。経験上、同時に動かすサブエージェントは3〜4本までに抑えると、それぞれの進捗を見失わずに済みます。これより増やす場合は、完了したタスクを集約して確認できる仕組みを別途用意してから増やすのが安全です。
安全性の面では、フックのPreToolUseを使うと、特定のツール実行をどの権限モードでも強制的にブロックできます。PreToolUseのフックはdenyを返すとbypassPermissionsでも実行を止められるため、重要なファイルへの変更だけは権限モードに関わらず常に確認を挟みたい場合に使えます。フックの設定は~/.claude/settings.jsonや.claude/settings.jsonの
公式LINEで「Claude Code×ひとり起業 10大キット」を受け取る

コメント