結論3行で書く。
- Claude Code Max $200プランは「シングルセッションで使ってる限り元が取れない」設計になっている。並列で回して初めて損益分岐を超える。
- でも「とりあえず10並列」はファイル衝突・メモリ汚染で破綻する。先に「並列にできるタスクの判別基準」を決めるのが正解。
- 判別フローと、30分で2-3並列を始める手順、Anthropic作者の運用から拾える知見を実例ベースで書く。
この記事でわかること
- 自分のタスクが「並列に回していいやつ」か「ダメなやつ」かを判別する基準
- 並列度1→3→5→10へ段階的に上げていく具体手順（コピペ可）
- 並列度を上げたときに踏むハマりどころと、踏む前の回避策
- Anthropic 作者 Boris Cherny の通知駆動介入の真似方
対象読者
- Claude Code Max ($200) を契約したけど元取れてる感覚がない人
- 並列運用を試したいけど、何から始めればいいか分からない人
- 「とりあえず複数タブで並列」を試して破綻した経験がある人
目次
- なぜシングル運用だと$200の元が取れないか
- 1. 並列にできるタスク / できないタスクの判別基準
- 2. 30分で2-3並列を始める手順
- 3. 並列度を5→10に上げるときの設計
- 4. Anthropic 作者 Boris Cherny の運用から学べること
- 5. ハマりポイントと回避策
- まとめ
なぜシングル運用だと$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週間続けて、ハマりどころを実体験するのが最短ルート。
参考ソース: