Claude Codeを3並列で回す：worktreeと端末タブの泥臭い運用

Anthropicのcommon-workflowsに出てくる並列セッションの例は、せいぜい2つの worktree を並べる程度です。しかし少し使い込んだユーザーは、常時3〜5セッションを別タブで回しているのが実態です。

公式の説明がライトなのには理由があります。Anthropic 側は「どのタスクを分割可能か」の判断が属人的で、記事にしづらい。一方で外側の実務者は「どれを同時に回すとコスト爆発するか」の経験を身体で覚えていて、公式には書かれないこのあたりの勘所が効率差を作っています。

この記事では、3並列を標準にするための具体的な構成・失敗パターン・対策を整理します。

そもそもなぜ並列が必要か

単発セッションで困る典型シーンは次の3つです。

Claude Code が重い調査を走らせている間、自分が手持ち無沙汰になる
ブランチAで実装中に、別件の障害対応でブランチBに切り替えたい
複数の独立機能（例：認証リファクタ + テスト追加 + ドキュメント修正）を1日で進めたい

これらは全部worktreeで解ける問題です。単一セッションの「待ち時間」を他のセッションの「作業時間」に変換することで、実質的な開発速度が2〜3倍になります。

3セッション構成の典型例

私が個人開発で回している構成は次のとおりです。

┌──────────── Window 1 ────────────┐
│ main ブランチのメインセッション   │
│ コードレビュー・最終確認用        │
└──────────────────────────────────┘

┌──────────── Window 2 ────────────┐
│ claude -w feature-A              │
│ 機能Aの実装（今日の主タスク）     │
└──────────────────────────────────┘

┌──────────── Window 3 ────────────┐
│ claude -w fix-flaky-tests        │
│ flakyテストの修正（バックグラウンド）│
└──────────────────────────────────┘

claude -w <name> でgit worktreeを新規作成した上でClaude Codeが起動します。.claude/worktrees/<name>/ 配下に独立したワーキングツリーが掘られるので、親リポジトリのHEADを汚さずに作業できます。

ポイントは**「主」「従」「バックグラウンド」の3層に分ける**ことです。

主セッション: 自分が常に見ている。人間が主導する作業
従セッション: 依頼を投げて定期的に様子を見る。ユーザー確認を挟む
バックグラウンド: 自律的に進んでほしい作業。完了通知だけ受ける

端末タブの運用

Windowsなら Windows Terminal のタブ、macOS/Linuxなら tmux か iTerm の分割が一般的です。私の Windows Terminal の設定例（settings.json）は次のとおりです。

{
  "profiles": {
    "list": [
      {
        "name": "claude-main",
        "commandline": "bash.exe",
        "startingDirectory": "%USERPROFILE%/project"
      },
      {
        "name": "claude-worktree-A",
        "commandline": "bash.exe -c 'cd ~/project && claude -w feature-A'",
        "startingDirectory": "%USERPROFILE%/project"
      }
    ]
  }
}

tmux派なら次のワンライナーを .zshrc / .bashrc に仕込んでおくと即3並列起動できます。

claude3() {
  local proj=$(basename "$PWD")
  tmux new-session -d -s "$proj" "claude"
  tmux split-window -h -t "$proj" "claude -w feature-$1"
  tmux split-window -v -t "$proj" "claude -w bg-$2"
  tmux attach -t "$proj"
}

コスト爆発を防ぐHook

並列セッションを始めて最初の月、確実に遭遇するのが**「気付いたらコスト数万円」問題**です。セッションを増やす前に、必ず PostToolUse Hook で Bash 実行ログと利用量の簡易トラッキングを仕込んでおきます。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash|Edit|Write",
        "type": "command",
        "command": "echo \"[$(date +%H:%M)] ${tool_name} in ${CLAUDE_PROJECT_DIR}\" >> ~/.claude-usage.log"
      }
    ]
  }
}

さらに上限を設けたい場合は、SessionStart Hookで claude-usage.log の今日分の行数をチェックして、閾値を超えたら警告する仕組みを入れます。ツールのAPIから直接利用量を取る公式手段は安定していないので、ツール実行回数をプロキシに使うのが泥臭くて効きます。

マージ戦略

3並列で走らせた成果物を main にマージするときの流儀は1つだけで、一度に1本ずつが鉄則です。

並列で進めるのは良いが、マージは直列
ブランチごとに PR を分ける（1PRに複数機能を混ぜない）
マージ前に main で git pull --rebase して、他のworktreeにも rebase を伝播させる

これをサボると、worktree 間で微妙に整合しない変更が生まれて、後から解きほぐすのに半日溶かします。

落とし穴

セッションの状態を忘れる: どのタブで何をやっていたかを忘れる事故が頻発する。タブ名に必ずタスク名を入れる
依存関係のあるタスクを並列化する: 「Aが終わったらB」は並列にしてはいけない。直列で1セッションにまとめる
Plan Mode をかけ忘れる: 並列だとPlan Modeをスキップしがち。バックグラウンドに回すときこそ Plan を挟む
自分の注意力の限界を超える: 3セッションでも最大。5セッションを超えると人間側がボトルネックになる
MCP / Skill の多重起動: 重いMCPサーバーを3セッションで別々に起動すると、メモリがすぐ枯れる。.mcp.json でプロジェクト共有にしておく

まとめ

3並列はただの「数を増やす」以上の意味があり、「メイン」「従」「バックグラウンド」の役割分担で初めて機能します。そしてコスト管理と注意力の設計を並列化の前提として仕込むのが、並列を長く続けるコツです。

1セッションで悩んだらそのタスクは並列化できていないか疑う——これを3週間続けると、戻れなくなります。

参考:

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感