task-decomposer

タスク分解

自然言語で表現された問題を、DAG ノードに適したサブタスクに分解します。メタ DAG の最初のステップです。DAG を構築または実行する前に、まず構成要素を把握する必要があります。

---

使用する場面

✅ 次の場合に使用します：

• 曖昧な問題を具体的なサブタスクに分解する
• フェーズ、依存関係、並列化の機会を特定する
• どのサブタスクが具体的で、どれが曖昧（多能性）かを判断する
• 分解に適切なドメインメタスキルを選択する

❌ 次の場合には使用しません：

• サブタスクから DAG 構造を構築する（dag-planner を使用）
• タスクを実行する（dag-runtime を使用）
• タスクにスキルを割り当てる（dag-skills-matcher を使用）

---

分解プロセス

flowchart TD
  P[Problem description] --> M{Domain meta-skill available?}
  M -->|Yes| L[Load meta-skill phase pattern]
  M -->|No| R{Research needed?}
  R -->|Yes| RA[Research standard decomposition]
  R -->|No| Z[Zero-shot decomposition]
  
  L --> D[Apply phase pattern to problem]
  RA --> D
  Z --> D
  
  D --> C[Identify concrete sub-tasks]
  D --> V[Identify vague/pluripotent sub-tasks]
  D --> DEP[Map dependencies between sub-tasks]
  D --> PAR[Identify parallelization opportunities]
  
  C --> O[Ordered sub-task list with metadata]
  V --> O
  DEP --> O
  PAR --> O

ステップ 1：ドメインの検出

適切なメタスキルを選択できるよう、問題をドメインに分類します。

ドメインの兆候	メタスキル
「build」、「implement」、「code」、「app」、「website」	software-project-decomposition
「research」、「analyze」、「report」、「synthesize」	research-synthesis-decomposition
「design」、「UI」、「wireframe」、「prototype」	product-design-decomposition
「strategy」、「market」、「business」、「revenue」	business-strategy-decomposition
「data」、「model」、「train」、「predict」	ml-project-decomposition

該当するメタスキルがない場合は、ゼロショット分解に切り替えます。

ステップ 2：フェーズの特定

メタスキルのフェーズパターンを適用します。すべての問題にすべてのフェーズが当てはまるわけではありません。

判断：パターン内の各フェーズについて、次のように考えます。「この問題にこのフェーズは必要か？」

• 必要で、今すぐ具体的に指定できる → 具体的なサブタスク
• 必要だが、前のフェーズが完了するまで具体的に指定できない → 曖昧／多能性ノード
• 不要 → このフェーズを省略

ステップ 3：サブタスクの仕様決定

具体的なサブタスクごとに：

sub_task:
  id: unique-name
  description: "What this sub-task produces (1-2 sentences)"
  type: concrete | vague
  depends_on: [upstream-sub-task-ids]
  parallelizable_with: [sibling-sub-task-ids]
  estimated_complexity: simple | moderate | complex
  suggested_model_tier: 1 | 2 | 3
  suggested_skills: [skill-names if known]
  output_description: "What the output looks like"

曖昧／多能性のサブタスクごとに：

sub_task:
  id: unique-name
  description: "What this phase will address (1-2 sentences)"
  type: vague
  depends_on: [upstream-sub-task-ids]
  potential_paths:
    - "Path A: [exciting possibility 1]"
    - "Path B: [exciting possibility 2]"
    - "Path C: [exciting possibility 3]"
  expansion_trigger: on_upstream_complete

ステップ 4：依存関係のマッピング

サブタスクの各ペアについて、次の点を判断します。

• データ依存関係：B は A の出力を必要とするか？ → A から B へのエッジ
• 知識依存関係：B は A が明らかにした内容を知る必要があるか？ → A から B へのエッジ
• 依存関係なし：A と B は独立しているか？ → 並列化可能

ステップ 5：出力

構造化された分解を出力します。

decomposition:
  problem: "original problem description"
  domain: "detected domain"
  meta_skill_used: "meta-skill name or 'zero-shot'"
  phases:
    - phase: 1
      sub_tasks: [concrete tasks for this phase]
    - phase: 2
      sub_tasks: [mix of concrete and vague tasks]
  total_concrete: 5
  total_vague: 3
  estimated_waves: 4
  estimated_cost: "$0.08 - $0.25"

---

分解のヒューリスティクス

粒度

• 細かすぎる：「ステップ 1：ファイルを開く。ステップ 2：1 行目を読む。」→ 1 つのノードにまとめます
• 粗すぎる：「ステップ 1：アプリ全体を構築する。」→ 設計、実装、テスト、デプロイに分割します
• 適切：各サブタスクは、1 回の LLM 呼び出しで、1〜3 個のスキルを持つ 1 つのエージェントが完了できるものです

依存関係の最小化

依存関係が少ないほど、並列性が高まり、実行が速くなります。次を優先します。

• 長い逐次チェーンよりも、独立した並列トラック
• 数珠つなぎよりも、ファンアウトパターン（1 つのソースから複数のコンシューマーへ）
• 段階的な統合よりも、最後にまとめて統合すること

曖昧さは問題ありません

まだ存在しない具体性を無理に作り出してはいけません。「ソリューションを構築する（詳細は設計フェーズ後に決定）」という曖昧なノードのほうが、誤った詳細をでっち上げたノードよりも誠実で有用です。

---

アンチパターン

早すぎる具体化

誤り：未完了の調査に依存するフェーズについて、実装の詳細を正確に指定する。 正解：依存するフェーズは曖昧／多能性として示します。想定される進め方を提示します。

すべてを逐次処理する

誤り：並列化のない 10 個のタスクからなる直線的なチェーン。 正解：独立したトラックを探します。調査とコンテンツの執筆は、多くの場合並行して進められます。

メタスキルの見落とし

誤り：橋の設計プロジェクトをソフトウェアプロジェクトとして分解する。 正解：ドメインを検出し、適切なメタスキルを読み込み、そのフェーズパターンに従います。