結論：Claude Codeは「並列実行」で真価を発揮する
Claude Codeを1体で使っているうちは「便利なアシスタント」ですが、複数エージェントを並列で走らせた瞬間に「マネジメント問題」が発生します。
本記事では、モノレポ内の独立パッケージをClaude Codeのサブエージェントで並列開発する手法を解説します。具体的には以下がわかります。
- 親エージェント（オーケストレーター）とサブエージェント（ワーカー）のアーキテクチャ設計
- 依存関係を考慮したタスク分割のプロンプトパターン3選
- レビューエージェントによる品質管理パイプライン
- コンフリクトを起こさないためのファイルロック戦略とブランチ規約
- 3パッケージ並列開発での実測データ
環境・前提条件
| 項目 | 内容 |
|---|---|
| Claude Code | 最新版（Claude Code CLI） |
| リポジトリ構成 | pnpm workspaces によるモノレポ |
| パッケージ数 | 3（packages/api, packages/web, packages/shared） |
| OS | macOS / Linux |
| ターミナル多重化 | tmux または複数ターミナルタブ |
Claude Codeの--allowedToolsやCLAUDE.mdを活用した制御が前提です。まだClaude Codeを導入していない方は、公式ドキュメントを先にご確認ください。
なぜ並列実行が必要か
モノレポでは複数パッケージが独立したドメインを持ちます。たとえば以下のような構成です。
monorepo/
├── packages/api/ # バックエンドAPI
├── packages/web/ # フロントエンド
├── packages/shared/ # 共通型定義・ユーティリティ
├── pnpm-workspace.yaml
└── CLAUDE.md
APIのエンドポイント追加、Webの画面実装、sharedの型定義追加──これらは論理的に分離可能なタスクです。1体のClaude Codeに順番にやらせると、単純に3倍の時間がかかります。
並列実行すれば、理論上は開発時間を1/3に圧縮できます。ただし「何も考えずに3つ立ち上げる」だけでは、ファイルの競合、整合性の崩壊、レビュー漏れが発生します。これが冒頭で触れた「マネジメント問題」です。
アーキテクチャ設計：オーケストレーター × ワーカー × レビューア
並列実行の成功は役割分担の設計で決まります。
各役割の責務
| 役割 | 実体 | 責務 |
|---|---|---|
| オーケストレーター | Claude Codeインスタンス（ターミナル1） | タスク分割、依存順序の決定、最終統合 |
| ワーカー | Claude Codeインスタンス（ターミナル2〜4） | 割り当てられたパッケージのコード実装 |
| レビューア | Claude Codeインスタンス（ターミナル5） | 各ワーカーの成果物の横断的品質チェック |
実際の運用では、tmuxのペインやターミナルのタブを使って5つのClaude Codeセッションを同時に走らせます。
起動の流れ
# ターミナル1: オーケストレーター
cd monorepo
claude
# ターミナル2〜4: ワーカー（各パッケージディレクトリで起動）
cd monorepo && claude
cd monorepo && claude
cd monorepo && claude
# ターミナル5: レビューア
cd monorepo && claude
ポイントは、全員がリポジトリルートのCLAUDE.mdを読める状態にしておくことです。これにより、プロジェクト全体のルールを各エージェントが共有できます。
タスク分割のプロンプト設計：3つのパターン
タスク分割の指示が曖昧だと、エージェント同士が同じファイルを触ったり、インターフェースの不整合が起きたりします。以下の3パターンを使い分けてください。
パターン1：境界ファースト分割（推奨）
先にインターフェース（境界）を定義してから、各パッケージの実装を分配する方法です。
## オーケストレーターへの指示
以下の手順でタスクを分割してください。
### Step 1: 境界定義（あなたが実行）
- `packages/shared/src/types/user.ts` に `UserProfile` 型を定義
- `packages/api/src/routes/user.ts` のエンドポイント仕様を決定（リクエスト/レスポンス型）
- 上記を確定してから、Step 2 に進む
### Step 2: 並列実装（ワーカーに指示を出す）
以下を別ターミナルのClaude Codeに伝えてください。
**ワーカー1（API）への指示:**
「packages/api/src/routes/user.ts に GET /users/:id を実装してください。
レスポンス型は packages/shared/src/types/user.ts の UserProfile を使用。
他のパッケージのファイルは絶対に触らないでください。」
**ワーカー2（Web）への指示:**
「packages/web/src/pages/UserProfile.tsx を実装してください。
API仕様: GET /users/:id → UserProfile 型。
他のパッケージのファイルは絶対に触らないでください。」
パターン2：コントラクト駆動分割
OpenAPI仕様やGraphQLスキーマを先に書き、それを「契約」として各ワーカーに渡すパターンです。
## オーケストレーターへの指示
1. `docs/api-spec.yaml` にOpenAPI仕様を記述してください
2. その仕様をもとに各ワーカーへ以下を指示してください:
- ワーカー1: 仕様に準拠したAPIサーバー実装
- ワーカー2: 仕様に準拠したクライアント型生成＋画面実装
- ワーカー3: 仕様から共通型を抽出して shared に配置
パターン3：レイヤー分割（大規模向き）
## 分割ルール
- ワーカーA: データ層（DB スキーマ、マイグレーション、リポジトリ）
- ワーカーB: ビジネスロジック層（サービス、ユースケース）
- ワーカーC: プレゼンテーション層（API ハンドラ、UI コンポーネント）
実行順序: A → B, C（Aの完了後にB, Cを並列実行）
最も重要なのは「他のパッケージのファイルは触らないでください」という制約を明示することです。この一文があるだけでコンフリクトの大半を防げます。
品質管理：レビューエージェントによる検査パイプライン
並列開発の最大のリスクは「個別には動くが、統合すると壊れる」状態です。これを防ぐために、レビューエージェントを配置します。
レビューエージェントへのプロンプト
あなたはコードレビュー専門のエージェントです。
以下の観点で、最近変更されたファイルを検査してください。
## 検査項目
1. **型の整合性**: shared の型定義と、api/web での使用箇所が一致しているか
2. **import パスの正確性**: ワークスペースのパッケージ参照（@monorepo/shared 等）が正しいか
3. **命名規約**: CLAUDE.md に定義された命名ルールに従っているか
4. **テスト有無**: 新規関数にユニットテストが書かれているか
5. **重複実装**: 複数パッケージで同じロジックが実装されていないか
## 実行手順
1. `git diff --name-only main` で変更ファイル一覧を取得
2. 各ファイルを読み込み、上記5項目をチェック
3. 問題があれば「どのファイルの何行目に何の問題があるか」を一覧化
4. `pnpm -r run typecheck` と `pnpm -r run test` を実行して結果を報告
検査の自動化タイミング
各ワーカーが作業完了を宣言したら、オーケストレーターがレビューアに検査を依頼します。実際の手順は以下の通りです。
- ワーカーが実装完了 → 自分のブランチにコミット
- オーケストレーターがレビューアに「
feat/api-user,feat/web-user,feat/shared-userの3ブランチをチェックして」と指示 - レビューアがtypecheckとテストを横断実行
- 問題があればオーケストレーターが該当ワーカーに修正を指示
コンフリクト防止：ファイルロック戦略とブランチ命名規約
ファイルロック戦略
Claude Code自体にファイルロック機能はありません。そこで、CLAUDE.mdによるソフトロックを使います。
<!-- CLAUDE.md に追記 -->
## ファイル担当ルール（並列開発時）
- `packages/api/` 配下: ワーカー1のみ編集可
- `packages/web/` 配下: ワーカー2のみ編集可
- `packages/shared/` 配下: ワーカー3のみ編集可（ただしオーケストレーターが初期定義済みの型のみ）
- ルートの設定ファイル（tsconfig, package.json等）: オーケストレーターのみ編集可
- 上記以外のファイルを編集する必要がある場合は、作業を中断して報告すること
さらに、各パッケージディレクトリに**ローカルのCLAUDE.md**を配置して、パッケージ固有のルールを強制できます。
<!-- packages/api/CLAUDE.md -->
このディレクトリはワーカー1の担当です。
packages/web/ や packages/shared/ のファイルを直接編集してはいけません。
共通型が必要な場合は @monorepo/shared からインポートしてください。
ブランチ命名規約
命名パターンは以下のルールにします。
feat/{sprint}-{package}-{feature}
例: feat/sprint-42-api-user-profile
feat/sprint-42-web-user-profile
feat/sprint-42-shared-user-types
各ワーカーに対して「このブランチで作業してください」と明示的に指示します。
# ワーカー1への指示
git checkout -b feat/sprint-42-api-user-profile
# このブランチでのみ作業すること。mainやオーケストレーターブランチにはpushしないこと。
実運用データ：3パッケージ並列開発の実測結果
以下は、ユーザープロフィール機能（API + Web + 共通型）を開発した際の実測データです。
注意: これは筆者の環境での計測結果であり、タスクの複雑さやコンテキストの量によって結果は変動します。
計測条件
- タスク：ユーザープロフィール CRUD（API 3エンドポイント、Web 2画面、型定義5個）
- 計測対象：指示開始〜全テスト通過まで
結果
| 方式 | 所要時間 | 人間の介入回数 |
|---|---|---|
| 逐次開発（Claude Code 1体） | 約48分 | 6回 |
| 並列開発（3ワーカー + オーケストレーター + レビューア） | 約22分 | 10回 |
所要時間は約54%削減できました。一方で、人間の介入回数は増えています。これはオーケストレーターへの指示、ワーカーへのコピペ、レビュー結果の確認といったマネジメントコストです。
並列実行の効果が高いケース
- パッケージ間の依存が少ない（sharedの型定義が先に固まる構成）
- 各パッケージの実装量がある程度均等
- CLAUDE.mdでプロジェクトルールが明文化済み
効果が低い（避けるべき）ケース
- パッケージ間で密結合な変更が必要（DB スキーマ変更が全パッケージに波及する等）
- 小さな修正（1ファイルの変更で済む場合）
- プロジェクトルールが未整備でエージェントが迷う環境
現時点の限界と今後の展望
限界
-
マネジメントコストがゼロにならない
現状、ワーカー間の指示はコピペで行う必要があります。Claude Codeには組み込みのマルチエージェントオーケストレーション機能がまだありません（2025年7月時点）。 -
コンテキストウィンドウの分断
各ワーカーは独立したセッションなので、他のワーカーが何をしているかを知りません。統合時に「想定と違う実装だった」というケースはゼロにはなりません。 -
コスト（APIトークン消費）
5セッション同時実行はトークン消費も5倍です。費用対効果は事前に見積もっておくべきです。
今後の展望
-
Claude Codeの
/agentsやツール連携の進化により、プログラム的なオーケストレーションが可能になると言われています - MCPサーバー連携で、ファイルロックやタスクキューを外部ツールとして統合する構成が有望です
- GitHub Actionsとの組み合わせで、CIパイプライン上での並列エージェント実行も検討されています
まとめ
- **並列実行の鍵は「境界を先に定義し、担当範囲を厳密に分けること」**──CLAUDE.mdによるソフトロックとブランチ分離で、コンフリクトの大半は防げます
- レビューエージェントを必ず配置する──個別には正しくても統合で壊れるリスクを、横断的な型チェック・テスト実行で検出します
- 並列開発は「大きくて分離可能なタスク」に使う──小さな修正や密結合な変更には逐次開発の方が効率的です