一人で作るエンジニアチーム:Claude Code 並列ワークフロー完全ガイド
2026年初頭、Boris Cherny——Claude Codeの作者——がThreadsでシェアしたワークフローが開発者コミュニティで広まりました。彼は10〜15のClaude Codeセッションを同時に走らせ、それぞれが異なるタスクを独立して進めているというものです。
多くの開発者はClaude Codeを「シングルスレッド」で使っています。タスクが終わるのを待ってから次へ。それは優秀なエンジニアを雇っておきながら、一度に一つの仕事しかさせていないようなものです。このガイドでは、判断フレームワークから実際のセットアップまで、並列ワークフロー全体を解説します。
TL;DR
- 3〜5個のworktreeを並列実行するのがBoris本人の推奨。ブラウザセッションを加えると10〜15個に到達
- 判断原則:タスク間が完全に独立していて、共有ファイルがない場合のみ並列化
claude --worktree [name]一行で完全に隔離された作業環境を構築- CLAUDE.md三層アーキテクチャ(グローバル / プロジェクト / タスク)が並列セッションの一貫性を保つ
- macOSフックでClaude完了・待機時に自動通知。タブを監視し続ける必要がない
なぜClaude Codeの作者は15セッションを同時に走らせているのか?
Boris ChernyのThreads投稿によると:ターミナルに5つのClaude Codeウィンドウを開き、claude.ai/codeのブラウザ版で5〜10セッションを追加し、スマートフォンのセッションも合わせると、合計10〜15の並列ワークフローになります。この投稿は開発者コミュニティで広く共有されました。
彼はこの手法を「最大の単一生産性解放(single biggest productivity unlock)」と呼び、Claude Code開発チーム全体が投票で選んだ第1位のテクニックだと言います。個人的な好みではなく、チームのコンセンサスです。
核心的な哲学は一文に集約されます:「介入を減らす + ツールをうまく使う = 全体的に速い結果」。
従来の開発思考はシーケンシャルです——Aが終わってからB、Bが終わってからC。しかしClaude Codeは疲れません。複数の独立した問題を同時に全力で進められ、あなたは重要なポイントだけで介入できます。Borisのもう一つの重要な実践はPlan Modeとの組み合わせ:各タスクの戦略と境界をPlan Modeで明確にしてから、複数セッションを並列実行します。
私もShareuhackの自律コンテンツシステムで同じパターンを検証しています:scout、research、writer、socialの4ワーカーを同時実行し、全体のスループットが3〜4倍向上しました。
どのタスクを並列化すべきか?判断フレームワーク
並列作業は「多ければ多いほど良い」ではなく、「適切なタスクだけを並列化する」ことです。
3つの判断基準:
- このタスクの完了は、別の進行中のタスクに依存しているか?(依存あり → 非対応)
- 複数のタスクが同じコアファイルを編集する必要があるか?(共有状態 → 非対応)
- 各タスクの境界が一文で説明できるほど明確か?(曖昧 → まず分解)
3つすべてクリアしたら並列化開始。
並列化に向いているタスク:
- 複数の独立した機能開発(Feature AとFeature Bが異なるファイルを使用)
- ユニットテストの記述(ほぼ独立)
- ドキュメント生成(完全に独立)
- 異なるモジュールに散らばったバグ修正
- 大規模なコード移行(ディレクトリ単位でバッチ処理)
並列化に向いていないタスク:
- タスクBがタスクAの出力を必要とする場合(例:APIのリファクタリング → フロントエンド更新)
- 複数のエージェントが同時に
config.tsや共有コアutilityを編集する場合 - アーキテクチャレベルの設計決定(人間が全体像を把握している必要がある)
incident.ioのエンジニアチームの事例が参考になります:UIの改善、ビルドツールの最適化、テスト仕様の記述、バックエンドの機能開発——それぞれが独自のファイル領域で作業し、重複なしに4〜5エージェントを同時実行しました。
一コマンドで隔離環境構築:git worktree + --worktree フラグ実践
なぜworktreeが必要か?
同じ作業ディレクトリで複数のClaude Codeセッションを走らせると、セッション同士が上書きし合うリスクがあります。git worktreeは各タスクに独自のディレクトリとブランチを与え、完全に隔離します。
公式 --worktree フラグ(推奨)
Claude Code CLIにはworktreeサポートが組み込まれています:
# feature-authという隔離されたworktreeを作成してClaudeを起動
claude --worktree feature-auth
# 別のセッションを並列で開く
claude --worktree bugfix-payment
# 名前なし — Claudeが自動生成(例: bright-running-fox)
claude --worktree
このコマンドは:
<repo>/.claude/worktrees/<name>/に新しい作業ディレクトリを作成- デフォルトのリモートブランチから
worktree-<name>ブランチを作成 - 隔離ディレクトリでClaude Codeセッションを開始
セッション終了時:変更がなければ自動クリーンアップ、コミットがあればClaudeが保持するか確認します。
.gitignore に追加することを推奨:
.claude/worktrees/
メインリポジトリに大量のuntracked filesが表示されるのを防ぎます。
手動 git worktree(より細かな制御が必要な場合)
# 新しいブランチ + worktreeを作成
git worktree add ../project-feature-a -b feature-a
# worktreeでClaudeを起動
cd ../project-feature-a && claude
# 完了後にクリーンアップ
git worktree remove ../project-feature-a
Plan Modeとの組み合わせ
複数のworktreeセッションを起動する前に、Plan Mode(Shift+Tab切替、または claude --permission-mode plan)で各タスクの方向性を確認します。Plan ModeではClaudeはファイル変更を行わず計画のみ——スコープが明確になったら実行モードに切り替え、未承認の変更を心配せずにセッションをバックグラウンドで走らせられます。
CLAUDE.md 三層アーキテクチャ:すべての並列セッションにルールを
複数のworktreeが同時に走るとき、各セッションは「このプロジェクトのルールは何か」を理解している必要があります。CLAUDE.mdの三層アーキテクチャがその解決策です。
第一層:グローバル(~/.claude/CLAUDE.md)
個人設定。すべてのセッションで読み込まれ、gitにはコミットしません:
- 個人のコードスタイル設定
- 個人のツールショートカット
- 個人のワークフロー習慣
できる限りシンプルに保つこと。すべてのセッションがこのファイルを完全に読み込むため、長くなるとコンテキストを消費します。私は50行以内を目標にしています。
第二層:プロジェクト(./CLAUDE.md または ./.claude/CLAUDE.md)
チーム共有の規範。gitにコミットし、すべての協力者とworktreeで共有:
- アーキテクチャの決定と設計原則
- ビルドコマンド、テストコマンド
- 命名規則、ディレクトリ構造
- 共通ワークフローの説明
ShareuhackのプロジェクトレベルのCLAUDE.mdにはコンテンツパイプラインのルール全体が含まれています——各Agentの役割、禁止事項、frontmatter仕様——並列で走る各エージェントが境界を理解できるように。
第三層:タスク(.claude/rules/ ディレクトリ)
最も細粒度の設定。ルールを特定のファイルパスにバインドできます:
---
description: APIルートレイヤーのルール
paths:
- "src/api/**/*.ts"
---
# APIルートのルール
- すべてのエンドポイントにZodバリデーションが必要
- エラーレスポンス形式は { error: string, code: string } で統一
このルールはClaudeが src/api/**/*.ts に一致するファイルを開いたときのみ読み込まれ、他のタスクのコンテキストを汚染しません。
worktree間のメモリ共有:すべてのworktreeが同一のauto memoryディレクトリ(~/.claude/projects/<git-repo>/memory/)を共有するため、あるworktreeでClaudeが学んだことは他のworktreeでも活用されます。
実用的なアドバイス:公式の推奨は各CLAUDE.mdを200行以内に保つこと——それを超えると遵守率が下がります。詳細な説明は agent_docs/ サブディレクトリの独立した .md ファイルに分割し、メインCLAUDE.mdから @agent_docs/api-rules.md 構文で必要に応じて参照する形がベストです。
10個のタブで迷子にならないために:セッション管理と通知機能
複数のセッションを同時管理する場合、最大の課題は技術的な設定ではなく「どのタスクが完了して、どれが自分の介入待ちで止まっているかを知ること」です。
macOS通知(hooks)
Claude Codeのhooks機能が最善のソリューションです。~/.claude/settings.jsonに設定:
{
"hooks": {
"Stop": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "osascript -e \"display notification 'Claudeがタスクを完了しました' with title 'Claude Code'\" && afplay /System/Library/Sounds/Glass.aiff",
"async": true
}
]
}
],
"PermissionRequest": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "osascript -e \"display notification '確認が必要です' with title 'Claude Code 待機中'\" && afplay /System/Library/Sounds/Ping.aiff",
"async": true
}
]
}
]
}
}
Stopフック:Claudeが応答を完了したときに発動——タスク完了の通知PermissionRequestフック:Claudeが人間の確認を必要とするときに発動——どのセッションが止まっているかを通知
"async": true でhookがセッション実行をブロックしないようにします。
命名と状態追跡
worktreeの名前 = タスクの説明:feature-auth、bugfix-paymentのように意味のある名前を使います(worktree-1、worktree-2ではなく)。ターミナルのタブを一目見れば、各セッションが何をしているかわかります。
カスタム /worktree-status コマンド:CLAUDE.mdにslash commandを定義して、すべてのworktreeのgit状態を一括表示:
git worktree list && for wt in $(git worktree list --porcelain | grep worktree | awk '{print $2}'); do echo "=== $wt ==="; git -C $wt status --short; done
BorisのiTerm2アプローチ:番号付きタブで複数セッションを管理し、iTerm2を「入力が必要なときに通知音」設定にします。--nameフラグでセッションにラベルを付けることもできます:
claude --worktree feature-auth --name "auth-worker"
いつ介入するか
私のルール:セッション起動後5分でチェックポイント——Claudeの方向性が正しいか確認してから継続させます。その後は15〜20分ごとにスキャンし、完了と待機の通知はhooksに任せます。実行中に頻繁に割り込むと、全体的な品質が低下します。
今日、2つ目のセッションを始めよう
並列作業はパワーユーザーのテクニックではなく、Claude Codeを正しく活用するための方法です。すでにClaude Codeを使っているなら、必要なツールはすでにすべて揃っています。
最速の始め方:手元のプロジェクトから3つの独立したタスクに分割できるものを見つけ、上記の判断フレームワークで独立性を確認してから:
claude --worktree task-a # 1つ目のターミナルタブ
claude --worktree task-b # 2つ目のターミナルタブ
claude --worktree task-c # 3つ目のターミナルタブ
各セッションに明確なタスク説明を渡し、起動して、コーヒーを取りに行く。通知音が鳴ったら戻ってくる。
それがBorisの働き方です。あなたの働き方にもなれます。
FAQ
Claude Code MaxプランはParallel Workflowに向いていますか?
Maxプランはより高いトークン上限とレート制限を持ち、複数セッションの同時実行に最適です。月額固定費で高使用量をカバーできるため、並列作業による時間あたりの成果物が大幅に増えます。1日2時間以上Claude Codeを使うなら、MaxプランのROIはほぼ確実です。
並列worktree開発でgitマージコンフリクトは起きやすいですか?
各worktreeが完全に独立したファイルや機能を担当していれば、コンフリクトの可能性は低いです。タスク分割の段階でファイルの境界を明確にし、同一のコアモジュールを複数セッションが同時編集しないよう設計することが重要です。公式の--worktreeフラグは自動的に専用ブランチを作成し、マージリスクを隔離します。
Parallel session + worktreeとAgent toolのsubagentはどう使い分けますか?
worktreeは長時間のコード変更タスク(数十分〜数時間)に向いています。subagentは単一セッション内での短時間の調査・検索・分析タスク(数分で完了)に向いています。両者を組み合わせることもでき、各worktreeのセッションからAgent toolでさらにsubagentを起動することも可能です。

