結論3行で書く。

Claude Code Max $200プランは「シングルセッションで使ってる限り元が取れない」設計になっている。並列で回して初めて損益分岐を超える。
でも「とりあえず10並列」はファイル衝突・メモリ汚染で破綻する。先に「並列にできるタスクの判別基準」を決めるのが正解。
判別フローと、30分で2-3並列を始める手順、Anthropic作者の運用から拾える知見を実例ベースで書く。

この記事でわかること

自分のタスクが「並列に回していいやつ」か「ダメなやつ」かを判別する基準
並列度1→3→5→10へ段階的に上げていく具体手順（コピペ可）
並列度を上げたときに踏むハマりどころと、踏む前の回避策
Anthropic 作者 Boris Cherny の通知駆動介入の真似方

対象読者

Claude Code Max ($200) を契約したけど元取れてる感覚がない人
並列運用を試したいけど、何から始めればいいか分からない人
「とりあえず複数タブで並列」を試して破綻した経験がある人

なぜシングル運用だと$200の元が取れないか

Max $200 プランは Pro $20 の10倍の料金。10倍働かせる前提で値付けされている。

実際、Anthropic 公式の How Anthropic teams use Claude Code には、エンジニアの仕事は 「並列エージェントのオーケストレーション」 と書かれている。1人で複数のClaudeを同時に走らせる前提のプラン。

シングルセッションで1日3-4時間Claudeに話しかけても、実は Pro $20 で十分回る。Max を活かすには「同じ時間で2-3倍のタスクを片付ける」運用が必要。

そのための具体手順を以下に書く。

1. 並列にできるタスク / できないタスクの判別基準

「とりあえず複数タブで並列」を試して破綻するパターンの大半は、並列にしちゃダメなタスクを並列にしたケース。先にこのフレームで判別する。

並列OK / NG 判別表

タスクの性質	並列可否	理由
別々のリポジトリの作業	✅ OK	ファイル衝突なし
同一リポジトリの異なるファイルを編集	✅ OK（worktree必須）	git worktree で物理分離すれば衝突しない
独立した調査（Web検索・ドキュメント読み）	✅ OK	書き込み先が分かれていれば安全
同一ファイルを複数Claudeで編集	❌ NG	後勝ちで上書きされる
連続したリファクタリング（A→B→Cと依存）	❌ NG	並列にしても待ち時間が発生する
メモリ書き込みを伴うタスク	⚠️ 注意	1セッションに集約する

判別フローチャート

タスクを並列に回す前に、3つの質問を自問する：

このタスクは他のタスクの結果を待つ必要があるか? → Yes なら直列
書き込み先のファイル/メモリが他タスクと被るか? → Yes なら NG（または worktree で分離）
タスク間で同じ文脈（CLAUDE.md・メモリ）を参照するか? → Yes なら片方だけが書き込む

3問ともクリアできるタスクだけ並列に回す。これだけで破綻の8割は防げる。

並列向きタスクの具体例

複数の独立した記事の調査（記事A・B・C を別々のClaudeで）
別々のバグ修正（issue #1 と issue #2 を別worktreeで）
フロントエンドとバックエンドの並行実装
テストコード生成（実装が固まってから複数ファイルに対して並列実行）

並列にしちゃダメな具体例

「設計→実装→テスト」の一連フロー（直列依存）
同じ関数のリファクタ（複数Claudeが同じファイルを触る）
メモリ・CLAUDE.md の更新（並列書き込みで整合性が崩れる）

2. 30分で2-3並列を始める手順

「いきなり10並列」じゃなく、まず2-3並列で慣れるのが安全。コピペで動く手順を書く。

ステップ1: git worktree でディレクトリを分ける（5分）

複数のClaudeが同じリポジトリを触るなら、必ず worktree で分離する。

# プロジェクトのルートで実行
cd ~/your-project

# 並列タスク用のworktreeを2つ作る
git worktree add ../your-project-task1 -b task1
git worktree add ../your-project-task2 -b task2

# 確認
git worktree list

これで ../your-project-task1 と ../your-project-task2 に別々のディレクトリが作られる。それぞれが独立した作業ツリーになる。

ステップ2: iTerm2 で2タブ起動 + 通知設定（10分）

iTerm2 の通知を有効化して、Claude が入力待ちになったときだけ気づける状態にする。

iTerm2 > Preferences > Profiles > Terminal
- Silence bell: OFF
- Send "•" notification on bell: ON

その上で各タブで Claude を起動：

# タブ1
cd ~/your-project-task1
claude

# タブ2
cd ~/your-project-task2
claude

ステップ3: タスクを Plan Mode で投入（10分）

各タブでタスクを依頼する前に Plan Mode に入る（Shift+Tab で切り替え）。実装まで一気に進めず、計画を作らせて確認する。

理由：並列だとレビュー負荷が爆発する。Plan Mode で先にレビューを終わらせて、auto-accept で実装するフローが現実的。

ステップ4: 通知が来たら拾う（5分）

両方のClaudeが動き始めたら、自分は別の作業をする（記事を読む・コーヒーを淹れる・別のタスクを考える）。

通知が鳴ったら該当タブに行って指示を返す。これが通知駆動の介入。

この時点でできるようになること

2タスクが同時に進行する（実時間で半分）
ファイル衝突は worktree で物理的に防がれている
レビューは Plan Mode で先に終わってるので auto-accept で流せる

慣れたら3並列に増やす。worktree を1つ追加するだけ。

3. 並列度を5→10に上げるときの設計

3並列まで来たら、次は5、その次に10。ここからは設計の話になる。

5並列の壁: 人間の認知容量

5並列を「常時監視」するのは無理。Boris Cherny も画面を見てない（Pragmatic Engineer）。通知駆動を徹底する必要がある。

実装：

iTerm2 通知 ON（必須）
macOS の通知センターで「重要な通知だけ」フィルタする
詰まってないClaudeは放置していい

10並列の壁: 同時APIリクエスト数

子プロセスで claude -p "..." を10並列で叩くと、Max プランでも APIレート制限を踏み始める。検証してみると：

並列度	結果
5	安定
20	安定（実用上限）
50	全 timeout（レート制限）

10並列は安全圏。20が個人の天井と思っていい。それ以上は API レート制限で全 timeout する。

並列タスクの粒度設計

並列度を上げるなら、1タスクの粒度を小さくするのがコツ。粒度の指針：

✅ 1タスク = 1論理変更（1 PR分）
✅ 完了まで5-15分で終わる
❌ 30分以上かかる重いタスクは分割する

Boris が「1日10-30 PR」と言うのも、PR粒度を小さくしてるから（howborisusesclaudecode.com）。1 PR = 1論理変更を徹底すると、並列で流すユニットがちょうどよくなる。

4. Anthropic 作者 Boris Cherny の運用を再現する設定手順

参考までに、Claude Code 作者がどう使ってるか。ここは「描写」じゃなく、真似するための設定コマンドだけ書く。一次ソースは Pragmatic Engineer の取材と howborisusesclaudecode.com。

Boris の構成（再掲）

配置	セッション数
iTerm2 タブ（各々別 git checkout）	5
claude.ai ブラウザ	5-10
合計	10-15

設定1: iTerm2 の通知駆動を有効化する

Boris が画面を見なくて済むのは、iTerm2 の通知設定のおかげ。手順：

iTerm2 > Settings > Profiles > Terminal
- Silence bell: OFF
- Send "•" notification on bell: ON
- Filter alerts: 全部 ON にしておく

さらに macOS 側でも：

System Settings > Notifications > iTerm2
- Allow Notifications: ON
- Banner Style: Alert（自動消滅させない方が見落としにくい）

これで Claude が入力待ちになるたびに通知が飛ぶ。

設定2: git worktree のテンプレ運用

Boris が「各タブで別 checkout」と言うのは、git worktree のこと。よく使うパターン：

# プロジェクトルートで実行
PROJECT_ROOT=$(pwd)

# 並列タスク用worktree作成（5並列の例）
for i in 1 2 3 4 5; do
  git worktree add "${PROJECT_ROOT}-task${i}" -b "task${i}"
done

# 確認
git worktree list

# 終わったらクリーンアップ
git worktree remove ../your-project-task1
git branch -D task1

エイリアスにしておくと毎回やらなくて済む：

# ~/.zshrc または ~/.bashrc
alias wta='git worktree add'
alias wtl='git worktree list'
alias wtrm='git worktree remove'

設定3: Plan Mode を全タスクで強制する

Anthropic 公式の Best Practices で推奨されているフロー。Claude Code 起動後に Shift+Tab で Plan Mode に切り替える。

毎回手動で切り替えるのが面倒なら、~/.claude/CLAUDE.md に書いておく：

# ~/.claude/CLAUDE.md

## デフォルトの作業フロー

実装タスクは必ず以下の順で進める：
1. まず Plan Mode で計画を提示する
2. 人間がレビュー・編集してから auto-accept に切り替える
3. 計画通りに実装する

人間からの指示が「すぐ実装して」と明示されない限り、必ず Plan Mode から始める。

これでグローバル CLAUDE.md がClaudeに「Plan Mode から始めろ」と指示する。

設定4: チーム CLAUDE.md を git 共有する

Anthropic 内部では、CLAUDE.md は「チームの失敗ログ」（公式）。プロジェクト直下の CLAUDE.md は git に乗せる：

# プロジェクトルートで
touch CLAUDE.md
git add CLAUDE.md
git commit -m "feat: Add CLAUDE.md as team knowledge base"

CLAUDE.md のテンプレ例：

# プロジェクト名

## コーディング規約
- 関数は50行以下
- ネスト3階層以上は早期リターンでフラット化

## このプロジェクトでやらかしたこと（Claude が同じミスをしないため）
- 2026-04-15: マイグレーション中にテーブルロック取らずに本番でエラー → 必ず BEGIN; LOCK TABLE; を先に
- 2026-04-22: 環境変数を直接コードに埋め込んだ → secrets manager 経由のみ

## PR の出し方
- 1 PR = 1論理変更
- タイトルは feat: / fix: / refactor: のいずれか

ここに「失敗の知見」を積み上げると、並列で走るどのClaudeも同じ知識を共有できる。これが Boris 方式の核心。

設定5: 通知の優先度を分ける（5並列以上で必須）

5並列以上にすると通知が鳴り続ける。Bell音をプロファイル別に分けると、重要なClaudeだけ気づける：

iTerm2 > Settings > Profiles
- "重要タスク" プロファイルを作る → Bell音を Glass.aiff
- "軽量タスク" プロファイルを作る → Bell音を Tink.aiff
- 起動時に -p フラグでプロファイル指定

実装側Claudeは Glass.aiff（高音で目立つ）、調査側は Tink.aiff（控えめ）にすると、人間が瞬時に判別できる。

Boris の運用で真似しなくていいこと

「常時10-15並列」を最初から目指す → 破綻する。3並列で1ヶ月慣らす
ブラウザで5-10セッション → 個人には過剰。Boris は社内ツール検証も兼ねている
1日30 PR → PR粒度がBoris基準で小さい。日本企業のレビュー文化だと現実的じゃない

5. ハマりポイントと回避策

並列度を上げると確実に踏むやつ。先に知っておけば回避できる。

ハマり1: ファイル衝突

複数Claudeが同じファイルを書きに来ると後勝ち。

回避策：

git worktree で物理ディレクトリ分離（必須）
共有ファイル（CLAUDE.md・package.json）は1セッションだけ触るルール

ハマり2: メモリ汚染

~/.claude/projects/.../memory/ に並列で書き込むと整合性崩壊。

回避策：

メモリ書き込みは1セッションに集約
並列セッションは「メモリを読むだけ」に限定

ハマり3: コンテキストの分断

並列セッション同士でコンテキストを共有する標準的な仕組みは、まだない。CLAUDE.md は静的すぎ、メモリは並列書き込みに弱い。

回避策：

並列タスクの前に「親セッション」で計画書を書き、各worktreeに配布する
タスク完了後に親セッションが結果を統合する（map-reduce 構造）

ハマり4: 通知の見落とし

10並列で通知が鳴り続けると、人間がパンクする。

回避策：

通知音をタスクの重要度で分ける（iTerm2 のプロファイル機能）
軽いタスクは auto-accept で通知を減らす
重いタスクは Plan Mode で人間レビューを必須にする

自分の実消費（参考データ）

参考までに、自分が並列運用してる4月の実消費を貼っておく。ccusage で計算した値：

2026年4月の API換算消費: $1,376.44
Max プラン料金: $200/月
モデル別: Opus 4.7=$675 / Opus 4.6=$654 / Sonnet 4.6=$32 / Haiku 4.5=$14

npx ccusage@latest monthly で誰でも自分の消費を測れる（ccusage）。Max契約してて $200を上回ってない人は、並列運用を始めれば素直に元が取れる。

まとめ

今日からやること

今日（30分）: git worktree で2ディレクトリ作る → iTerm2 通知ON → 2並列で1タスクずつ流す
今週: Plan Mode → auto-accept のフローを全タスクで習慣化。3並列まで上げる
今月: 並列OK/NG判別表を見ながらタスクを振り分け。5並列を安定させる

この記事の使い方

並列運用は「設計→運用→修正」の繰り返し。一発で10並列を成功させる必要はない。まず2並列を1週間続けて、ハマりどころを実体験するのが最短ルート。

参考ソース: