EP.05 で の Sub- を扱いましたが、今回は本気で使い込みたい人向けの応用編。3 並列で複雑タスクを進める実装パターンを、ふくふくの実プロジェクトで使った設計とともに公開します。
Claude Code が子エージェントを起動して並列に作業させる機能。親エージェントは指示を出し、結果を待ち、統合する。1 つのタスクを 3 並列にすれば理論上 1/3 の時間で済むが、設計しないと結果がバラバラになる。
並列タスクの 3 パターン
| パターン | 用途 | 並列度 | 結果集約 |
|---|---|---|---|
| Map | 同じ処理を多数のデータに適用 | N（データ数） | 全結果を結合 |
| Race | 複数アプローチを競争 | 2〜4 | 最良 / 最速の 1 つ採用 |
| Pipeline | 段階処理を各段で並列化 | 段ごと N | 段間で受け渡し |
1. Map パターン：同じ処理を多数に
最も使うのがこれ。「100 ファイルに同じリファクタを適用」「全テーブルに同じマイグレーションを生成」のような、同型タスクの並列化。
次の 12 個のテーブルそれぞれに対して、同じ作業を並列で行ってください。3 並列の Sub-Agent を起動してタスクを割り振り、結果を集約してください。
## タスク（テーブルごと）1. `migrations/` 以下に新規マイグレーションファイル生成2. {{dbt|*}} の sources.yml に追加3. dbt model を `models/staging/` に作成
## 対象テーブル@docs/new-tables-list.md
## 集約方法全 Sub-Agent の結果を 1 つの PR にまとめる。各テーブルのファイルを並列で作成し、最後に main に rebase。ファイル名衝突に注意。複数 Sub-Agent が同じディレクトリに書き込むと、タイムスタンプが微妙にズレるだけのファイル名で衝突する。親エージェントが ID 範囲を割り振る（A→#1〜4、B→#5〜8、C→#9〜12）のが鉄則。
2. Race パターン：複数アプローチを競争
正解が1つに絞れない設計タスクで使う。「A: 、B: 、C: で同じ要件を実装し、出来栄え・コスト・運用負荷を比較」のような選定タスクに最適。
次の要件を満たす設計を、3 つのアプローチで並列実装してください。
## 要件@docs/data-pipeline-spec.md
## アプローチ- Sub-Agent A: BigQuery + dbt + Cloud Composer 構成- Sub-Agent B: Snowflake + dbt + Airflow 構成- Sub-Agent C: Databricks + dbt + Workflows 構成
## 各 Agent の output1. `design/proposal-{a,b,c}.md` 設計書2. `design/cost-{a,b,c}.md` 月額試算（前提：{{dau|*}} 5K、データ量 1TB）3. `design/ops-{a,b,c}.md` 運用負荷の見積もり
## 親エージェントの最終 output3 案の比較表を `design/comparison.md` に。意思決定は人間が行うので、**選ばずに比較材料を出す**。「最良案を選んで」と頼んではいけない。 は迎合的に「○○ がベスト」と決めてしまうが、選定はビジネス文脈次第。比較材料だけ出させ、選択は人間が行うのがルール（ EP.16 の Hypothesis 思想と同じ）。
3. Pipeline パターン：段階処理の並列化
段階間に依存があるが、段内では並列化可能な大型タスク。「仕様策定 → 実装 → テスト → デプロイ」のような構造で、各段階の中で複数タスクが走る。
新機能 X を以下のパイプラインで実装してください。
## Stage 1（並列 3）：仕様策定- A: API 仕様- B: DB スキーマ設計- C: フロントエンド画面設計→ Stage 2 への入力にする
## Stage 2（Stage 1 の結果を受けて、並列 3）：実装- A: バックエンド実装（Stage 1-A をもとに）- B: マイグレーション実装（Stage 1-B をもとに）- C: フロント実装（Stage 1-C をもとに）
## Stage 3（並列 2）：検証- A: 単体テスト追加- B: E2E テスト追加
## Stage 4（直列 1）：PR 作成親エージェントが全成果物を統合した PR を作成。競合回避の鉄則
- ファイル分離：各 Sub-Agent が触るファイル / ディレクトリを物理的に分ける（同じファイルへの並列書き込みは厳禁）
- ブランチ分離：各 Sub-Agent が独立ブランチで作業（main へのマージは親が直列で実行）
- ID 範囲割り当て：マイグレーション番号、PR 番号などはオフセットで衝突回避
- 結果フォーマット統一： / / Markdown の決まった構造で返してもらう（集約時のパースが楽）
実プロジェクト事例
事例 1： 28 テーブル × 3 サービスの一括対応 → Map で 7 並列 → 通常 3 日 → 半日で完了
事例 2： 移行先選定（BigQuery / Snowflake / Databricks）→ Race で並列設計 → 比較表作成 → 意思決定までの時間を 3 週間 → 1 週間に短縮
事例 3：新機能リリース（仕様 → 実装 → テスト → デプロイ）→ Pipeline 構成 → 2 スプリント → 1 スプリントで本番投入
ふくふくの進め方
「Claude Code を導入したが Sub-Agent をうまく使えない」というご相談には、実プロジェクトの 1 タスクを題材に Map/Race/Pipeline の使い分けを伴走形式で 1〜2 週間。「並列で何ができるか」のレパートリーがチームに溜まると、生産性は単純な Claude Code 導入の倍以上に跳ねます。
次回予告
EP.09 は レビュー文化を組織に根付かせる方法。技術以外の話題、組織変革の実例を共有します。「AI が書いたコードをマージしていいか」の判断基準を組織で揃える 3 ヶ月の進め方。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。