マルチCLIワークフロー
並列ターミナルセッションを活用して生産性を最大化する方法。
学ぶこと
タスクが単一の Claude Code セッションで効率的に処理できる範囲を超えた場合、最も強力なパターンは複数のターミナルセッションを同時に実行することです。各ターミナルにはそれぞれ独自のフルコンテキストウィンドウ、独自の役割、独自の担当領域があります。
このセッションを終えると、以下を理解できるようになります：
- 大規模タスクにおいて複数ターミナルが単一セッションより優れている理由
- 各ターミナルに役割を割り当てる方法
- ターミナル間でファイルシステムを通じて通信する方法
- 作業を調整するオーケストレーターパターン
- マルチCLI vs. サブエージェント付き単一CLIの使い分け
課題
単一の Claude Code セッションにはコンテキストウィンドウが1つしかありません。コンパクション機能があっても、1つのセッションが同時に維持できる認識量には上限があります。データベーススキーマ、APIレイヤー、フロントエンドコンポーネント、テストスイートに跨る機能を実装する場合、単一セッションは常に情報のページイン・ページアウトを繰り返す必要があります。
さらに悪いことに、特定のタスクは互いにブロックし合います。あるセッションが長いテストスイートを実行している間、あなたは待機するしかありません。あるセッションが複雑なリファクタリングに没頭している間、次のステップを同時に計画させることはできません。
根本的な制約：1セッション、1フォーカス、1コンテキスト。
仕組み
マルチターミナルパターン
┌──────────────────────────────────────────────────────────┐
│ Your Screen │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Terminal 1 │ │ Terminal 2 │ │
│ │ ORCHESTRATOR │ │ IMPLEMENTER │ │
│ │ │ │ │ │
│ │ Plans the work │ │ Writes the code │ │
│ │ Breaks into tasks │ │ Follows the plan │ │
│ │ Reviews results │ │ Creates files │ │
│ │ Decides next step │ │ Modifies existing │ │
│ │ │ │ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Terminal 3 │ │ Terminal 4 │ │
│ │ VALIDATOR │ │ FIXER │ │
│ │ │ │ │ │
│ │ Runs tests │ │ Reads error logs │ │
│ │ Checks types │ │ Diagnoses failures │ │
│ │ Lints code │ │ Applies fixes │ │
│ │ Reports issues │ │ Verifies resolution │ │
│ │ │ │ │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘各ターミナルは独自の Claude Code インスタンスを実行します。それぞれが独自のフルコンテキストウィンドウを持ちます。各ターミナルは専門的な役割にコンテキストを完全に活用できます。
ロールベースターミナル
力の源泉は専門化にあります。すべてを行おうとする1つのジェネラリストセッションではなく、スペシャリストを作成します：
ORCHESTRATOR (Terminal 1)
├── Read requirements
├── Create task breakdown
├── Write task files to disk
├── Monitor progress
└── Make architectural decisions
IMPLEMENTER (Terminal 2)
├── Read task files
├── Write production code
├── Create new files
├── Modify existing code
└── Mark tasks complete
VALIDATOR (Terminal 3)
├── Watch for changes
├── Run test suite
├── Run linter / type checker
├── Write error reports
└── Flag failing tests
FIXER (Terminal 4)
├── Read error reports
├── Diagnose root causes
├── Apply targeted fixes
├── Rerun failing tests
└── Confirm resolutionファイルシステムを通じた通信
ターミナル間は直接通信しません。すべてのターミナルがアクセスできる唯一のもの、ファイルシステムを通じて情報を共有します。
project/
├── .tasks/
│ ├── plan.md ← Orchestrator writes
│ ├── task-01-schema.md ← Orchestrator writes, Implementer reads
│ ├── task-02-api.md ← Orchestrator writes, Implementer reads
│ ├── task-03-frontend.md ← Orchestrator writes, Implementer reads
│ ├── progress.md ← Implementer writes, Orchestrator reads
│ └── errors.md ← Validator writes, Fixer reads
├── src/ ← Implementer + Fixer write
└── tests/ ← Validator runs, Fixer fixes通信プロトコルはシンプルです：
- Orchestrator が何をすべきかを記述したタスクファイルを作成
- Implementer がタスクファイルを読み、コードを書き、進捗を更新
- Validator がコードの変更を監視し、チェックを実行し、エラーレポートを作成
- Fixer がエラーレポートを読み、修正を適用し、ステータスを更新
オーケストレーターパターン
オーケストレーターターミナルは頭脳です。他のターミナルが実行に集中する間、プロジェクトの全体像を保持します。
┌─────────────────────────────────────────────────┐
│ Orchestrator Flow │
│ │
│ 1. Read requirements │
│ 2. Analyze codebase structure │
│ 3. Break work into sequential tasks │
│ 4. Write task files to .tasks/ │
│ │ │
│ ▼ │
│ 5. Tell Implementer: "Start task-01" │
│ 6. Monitor progress.md for completion │
│ │ │
│ ▼ │
│ 7. When task-01 done, tell: "Start task-02" │
│ 8. Check errors.md for issues │
│ │ │
│ ▼ │
│ 9. When all tasks done, do final review │
│ 10. Write summary and commit │
│ │
└─────────────────────────────────────────────────┘コンテキスト分離のメリット
これが決定的な優位性です。コンテキスト使用量を比較してみましょう：
Single CLI (1 session, all tasks):
┌──────────────────────────────────────────────┐
│ Requirements + Schema + API + Frontend + │
│ Tests + Errors + Fixes + History │
│ ████████████████████████████████████ 95% │
│ └── everything crammed into one window ──┘ │
└──────────────────────────────────────────────┘
Multi-CLI (4 sessions, specialized):
┌──────────────────────┐ ┌──────────────────────┐
│ Orchestrator │ │ Implementer │
│ Plan + Progress │ │ Current task + Code │
│ ████████░░░░░ 40% │ │ ██████████░░░ 55% │
└──────────────────────┘ └──────────────────────┘
┌──────────────────────┐ ┌──────────────────────┐
│ Validator │ │ Fixer │
│ Test output + Lint │ │ Errors + Fixes │
│ ██████░░░░░░░ 35% │ │ ████████░░░░░ 40% │
└──────────────────────┘ └──────────────────────┘各セッションに余裕があります。コンテキストの限界で苦しんでいるセッションはありません。
重要なポイント
マルチCLIワークフローが大規模タスクに最も強力なパターンである理由は、各ターミナルが限られたコンテキストしか持たないサブエージェントではなく、フルコンテキストウィンドウを持つスペシャリストだからです。
サブエージェントは親の指示の圧縮版を継承し、要約を返します。これは限定的なサブタスクには適しています。しかし、各役割がその領域について深い認識を必要とする持続的なマルチフェーズの作業では、フルターミナルセッションの方が根本的に優れています。
次のように考えてみてください：
- サブエージェント = 同僚に何かを調べてもらう簡単なメッセージを送ること
- マルチCLIターミナル = プロジェクトの担当部分に完全に没頭し、自分のデスクとメモを持つ専任チームメンバーが隣に座っていること
オーケストレーターパターンが機能するのは、ファイルシステムが共有メモリだからです。すべてのターミナルが他のターミナルが書いたものを読むことができます。タスクディレクトリがプロジェクトの調整バスになります。
ハンズオン
4ターミナル機能開発ワークフローのセットアップ
ステップ1：タスク構造を作成する
プロジェクトルートに .tasks/ ディレクトリを作成します。オーケストレーターがこれを使います。
ステップ2：オーケストレーターを起動する（ターミナル1）
ターミナル1を開き、計画用プロンプトで Claude Code を起動します：
You are the ORCHESTRATOR for this feature. Your job:
1. Read the requirements I give you
2. Break them into numbered task files in .tasks/
3. Each task file should contain:
- What to implement
- Which files to modify
- Acceptance criteria
4. Monitor .tasks/progress.md for updates
5. Do NOT write code yourself — only plan and review
Feature: Add user profile page with avatar uploadオーケストレーターがコードベースを分析し、タスクファイルを作成します：
<!-- .tasks/task-01-schema.md -->
# Task 01: Database Schema
## What
Add user_profiles table with avatar_url column.
## Files
- prisma/schema.prisma (modify)
- prisma/migrations/ (new migration)
## Acceptance Criteria
- [ ] user_profiles table exists
- [ ] Foreign key to users table
- [ ] avatar_url is nullable string
- [ ] Migration runs without errorsステップ3：実装者を起動する（ターミナル2）
ターミナル2を開き、Claude Code を起動します：
You are the IMPLEMENTER. Your job:
1. Read task files from .tasks/ in order
2. Implement each task according to its spec
3. Update .tasks/progress.md when each task is done
4. Do NOT run tests — the validator handles that
5. Start with .tasks/task-01-schema.mdステップ4：検証者を起動する（ターミナル3）
ターミナル3を開き、Claude Code を起動します：
You are the VALIDATOR. Your job:
1. When notified, run: pnpm test && pnpm lint && pnpm typecheck
2. Write results to .tasks/errors.md
3. Include the exact error message and file location
4. Do NOT fix errors — just report them clearlyステップ5：修正者を起動する（ターミナル4）
ターミナル4を開き、Claude Code を起動します：
You are the FIXER. Your job:
1. Watch .tasks/errors.md for new entries
2. Read the error, find the root cause
3. Apply the minimal fix
4. Mark the error as resolved in errors.md
5. Do NOT change the overall approach — fix within the existing architectureマルチCLI vs. 単一CLIの使い分け
Use SINGLE CLI when:
├── Task is contained (< 30 min)
├── Touches 1-3 files
├── Linear workflow (do A, then B, then C)
└── Research + implement in same domain
Use MULTI-CLI when:
├── Task is large (> 1 hour)
├── Touches many files across layers
├── Parallel work is possible
├── Different skills needed (planning vs coding vs testing)
└── Context would overflow in a single session代替パターン
4ターミナルパターンだけが選択肢ではありません。ニーズに合わせて調整しましょう：
2-Terminal Pattern (Plan + Execute):
T1: Plan and review
T2: Implement and test
3-Terminal Pattern (Frontend + Backend + QA):
T1: Frontend components
T2: Backend API
T3: Integration tests
5-Terminal Pattern (Microservices):
T1: Orchestrator
T2: Service A
T3: Service B
T4: API Gateway
T5: Integration tests変更点まとめ
| 単一CLI | マルチCLIワークフロー |
|---|---|
| すべてに1つのコンテキストウィンドウ | 役割ごとにフルコンテキスト |
| 順次実行のみ | 並列実行 |
| 大規模タスクでコンテキストが溢れる | 各ターミナルが軽量に保たれる |
| 1つのジェネラリストセッション | 複数のスペシャリストセッション |
| サブエージェントは限られたコンテキスト | フルセッションはフルコンテキスト |
| すべての知識が1つの頭に | 知識が役割ごとに分散 |
次のセッション
セッション20ではエラーリカバリーを扱います。リトライロジックの構築、エラーの分類、フォールバック戦略の設計により、エージェントが途中で停止するのではなく、障害を適切に処理する方法を学びます。