の隠れた強力機能が Sub- です。メインセッションを詰まらせずに、独立タスクを並列で走らせられます。今回は、私たちが日々使っている並列パターンを共有します。
Sub-Agent が活きる3パターン
- 1独立調査タスク：本流の作業中に、別の調査を裏で進める
- 2重い処理の隔離：大量ファイル処理など、メインを詰まらせる作業を分離
- 3「もしも」シナリオの並行検証：アプローチA/B/Cを同時に試して、結果で選ぶ
パターン1：独立調査の並走
メインセッションで モデル設計をしながら、Sub-Agent で「過去6ヶ月の似たPRをリストアップ」「現行ジョブのコスト分析」「既存ドキュメントの古さチェック」を並列実行。すべて終わったら結果を集約。
実例：「Aシナリオで進める前に B/C も試す」
prompt：3アプローチを並列検証
この dbt モデルのパフォーマンス改善で、3つのアプローチを並列で検証してください。
## アプローチ
- **A**: パーティショニングを week → day に変更
- **B**: incremental マテリアライズに切り替え
- **C**: WHERE句を sub-query から CTE に変更
## 各アプローチの検証手順
1. 該当モデルを別名でコピー（例: fct_orders__a, __b, __c）
2. それぞれ変更を適用
3. dbt run --full-refresh で実行時間とBigQueryコスト測定
4. クエリプラン比較
## 出力
- 各アプローチの数値結果（実行時間・スキャン量・$コスト）
- 推奨案と理由（3行以内）
- 副作用や懸念点 想定される実行結果（例示）
## 並列検証結果
### A: day パーティショニング
- 実行時間: 4.2分 → 1.8分（57%短縮）
- スキャン量: 280GB → 95GB
- 月コスト推定: $410 → $140
- 副作用: 互換性維持に partition_filter_required を要設定
### B: incremental
- 実行時間: 4.2分 → 0.6分（86%短縮、増分のみ）
- スキャン量: 280GB → 12GB（増分のみ）
- 月コスト推定: $410 → $18
- 副作用: 過去データ修正時 --full-refresh 必要、merge key 設計要
### C: CTE 化
- 実行時間: 4.2分 → 3.9分（7%短縮）
- スキャン量: 変化なし
- コスト: 変化なし
- 副作用: ほぼ無し、可読性向上
### 推奨
**B（incremental）が最適**。短縮率86%でコスト削減 96%。merge key は `order_id` で設計済み。
注意点: 過去データ修正時の --full-refresh が必要なので、Runbook に追記必須。Sub-Agent の限界と注意点
並列タスクの落とし穴
(1) 同じファイルを並列で編集すると競合が起きる、(2) 外部APIへの並列呼び出しでレート制限に当たる、(3) 結果集約時に矛盾が出ることがある（Aの前提とBの前提が違う等）。並列にするタスクは「独立性」が必須。
次回予告
EP.06 は、半年使い込んだ受託開発の生産性数字をまとめます。「3倍速くなった」と言える根拠を実プロジェクトの計測から共有します。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。