学習目標:
- 3つのタスク分解戦略をマスターする
- タスク間の依存関係を特定する
- 分解を実行可能なワークフローに変換する
あなたの机にタスクが届きます。「モノリシックなRailsアプリをマイクロサービスアーキテクチャに分割する」というものです。これは複雑なタスクです。どこから始めればいいのか、何ステップ必要なのか、各ステップが何をするのかわかりません。
タスク分解とは、曖昧で大きすぎるタスクを小さく明確なステップに分割する方法です。1
優れた分解は3つの基準を満たします:
分解が適切であれば、ワークフローの記述はレゴブロックを組み立てるような感覚になります。分解が不適切だと、実行中にステップの欠落、順序の誤り、データの流れの問題を発見することになります。2
いつ使うか: タスクに明確な前後の順序があり、各ステップが前のステップの結果に依存する場合。
方法: 終わりから逆算します。「このステップにはどんな入力が必要か? その入力はどこから来るか?」と問います。
タスク: APIのユーザー向けドキュメントを生成する。
逆算による分解:
ワークフローに変換:
依存関係チェーン:
ステップ2はステップ1と並列実行できますか? いいえ — ステップ2はステップ1の endpoints が必要です。
ステップ3はステップ2と並列実行できますか? いいえ — ステップ3はステップ2の examples が必要です。
シーケンシャル分解の特徴: 長い依存関係チェーン、並列化の機会は少ないが、ロジックは明確です。3
いつ使うか: タスクが相互に依存しない複数の独立したサブタスクに分割できる場合。
方法: 「すべてのXについてYを実行」というパターンを見つけます — 各Xは並列処理できます。
タスク: 100個のファイルをセキュリティ問題について監査する。
パラレル分解:
形状:
ファンアウト・リデュースパターン: これはパラレル分解の最も一般的な形状です。4
パラレル分解の威力: 100ファイル、各監査に2分。シーケンシャル実行は200分かかりますが、パラレル実行は2分で完了します(リソース制限がない場合)。
いつ使うか: ほとんどの実際のタスク。一部は並列実行でき、一部は順序を守る必要がある場合。
方法: まず高レベルのフェーズ(順番に実行する必要があるもの)を見つけ、次に各フェーズ内の並列化の機会を見つけます。
タスク: 50個のコンポーネントをVue 2からVue 3にアップグレードする。
ハイブリッド分解:
ワークフローに変換:
ハイブリッドの依存関係グラフ:
ハイブリッド分解の核心: 本当に必要な順序を保ちながら、並列化のあらゆる機会を絞り出します。3
分解をLLMに任せることもできます。3つの方法がすべて機能します: ゼロショットプロンプト、思考連鎖プロンプト、そしてフューショット(例ベース)プロンプトです。1
LLM分解の利点: 最初の計画を素早く作成し、見落としていたステップを見つけます。
LLM分解の欠点: 抽象的すぎる可能性があります(「各ファイルの循環的複雑度を計算する」ではなく「データを分析する」と言うなど)。したがって、人間が明確化する必要があります。1
ヒント1: 「このステップは最初のステップの前に実行できるか?」と問う
答えが「はい」なら、並列実行できます。「いいえ、最初のステップの結果が必要」なら、依存関係があります。
ヒント2: 依存関係グラフを描く
ステップ2とステップ3は並列実行できますか? はい — どちらもステップ1にのみ依存します。
ステップ3とステップ4は並列実行できますか? いいえ — ステップ4はステップ2に依存します。
矢印が依存関係を意味し、決して開始地点にループバックしないグラフには正式な名前があります: DAG(有向非巡回グラフ)。ステップ1は何にも依存しないため、グラフが最初に実行できるリーフです。矢印の方向に違反しないようにすべてのステップを順序付けすることは、トポロジカルソートと呼ばれます。
ヒント3: データフローをチェックする
各ステップの入力と出力をリストアップします:
ステップXの入力がステップYの出力から来る場合、XはYに依存します。
間違い1: ステップが大きすぎる
「データを準備する」は何を含みますか? ファイルを読む? 設定をパースする? データベースに接続する? 曖昧すぎます。
間違い2: エラーハンドリングステップがない
ステップ2が失敗したらどうなりますか? サービスAはすでにデプロイされていますがBはされておらず、システムは不整合な状態です。
間違い3: 並列化の機会を無視する
これは各サービスを一度に1つずつ処理します。遅いです。
次: レッスン4: 状態管理とコンテキスト渡し — ワークフローのステップ間でデータを正しく渡し管理する方法を学びます。
ApX Machine Learning: Task Decomposition Strategies for LLM Agents — https://apxml.com/courses/agentic-llm-memory-architectures/chapter-4-complex-planning-tool-integration/task-decomposition-strategies ↩ ↩2 ↩3
ACONIC paper: Systematic LLM Task Decomposition — https://arxiv.org/html/2510.07772v1 ↩
OneUpTime: How to Create a Task Decomposition — https://oneuptime.com/blog/post/2026-01-30-task-decomposition/view ↩ ↩2
MindStudio: Five Claude Code Agentic Workflow Patterns — https://www.mindstudio.ai/blog/claude-code-agentic-workflow-patterns ↩
タスクA: Webアプリのパフォーマンスレポートを生成する(ロード時間、リソースサイズ、Core Web Vitals)
タスクB: Gitリポジトリをクリーンアップする(未使用の依存関係を削除、デッドコードを削除、古いコメントを更新)
要件:
要件:
最終出力: Markdownドキュメント ↑ 何が必要?ステップ4: Markdownをレンダリング (必要: 構造化されたドキュメントコンテンツ) ↑ どこから来る?ステップ3: コンテンツを整理 (必要: エンドポイントリスト + サンプルコード + 説明) ↑ どこから来る?ステップ2: エンドポイントごとにサンプルを生成 (必要: エンドポイントリスト) ↑ どこから来る?ステップ1: コードからエンドポイントリストを抽出 (必要: ソースコード) ↑開始: ソースディレクトリasync function generateAPIDocsWorkflow(sourceDir) {
// ステップ1: エンドポイントを抽出
const endpoints = await extractEndpoints(sourceDir);
// ステップ2: サンプルを生成 (ステップ1に依存)
const examples = await Promise.all(
endpoints.map(ep => generateExample(ep))
);
// ステップ3: コンテンツを整理 (ステップ1と2に依存)
const content = await agent({
task: 'Organize the doc structure',
prompt: 'Organize the endpoints and examples into a user-friendly doc structure',
context: { endpoints, examples }
});
// ステップ4: Markdownをレンダリング (ステップ3に依存)
const markdown = await renderMarkdown(content);
return markdown;
}
ステップ1 → ステップ2 ↓ ↓ └─→ ステップ3 → ステップ4async function securityAuditWorkflow(files) {
// フェーズ1: 各ファイルを並列監査 (依存関係なし)
const audits = await Promise.all(
files.map(file => auditFile(file))
);
// フェーズ2: 結果を集約 (フェーズ1に依存)
const summary = await agent({
task: 'Summarize the security audit',
prompt: `Analyze the audit results across ${audits.length} files,
rank issues by severity, and produce an executive summary`,
context: audits
});
return summary;
}
async function auditFile(file) {
return await agent({
task: `Audit ${file.path}`,
prompt: `Check for SQL injection, XSS, hardcoded secrets, and weak crypto.
Return JSON: { file, issues: [{ type, line, severity }] }`
});
}
┌─→ auditFile(1) ─┐ ├─→ auditFile(2) ─┤files ───→├─→ auditFile(3) ─┼─→ summary ├─→ ... ─┤ └─→ auditFile(100)─┘graph TD A[フェーズ1: 依存関係を分析] --> B{並列?} B -->|はい| C1[コンポーネント1-25を分析] B -->|はい| C2[コンポーネント26-50を分析] C1 --> D[フェーズ2: 移行計画を構築] C2 --> D D --> E{並列?} E -->|はい| F1[コンポーネント1-25を移行] E -->|はい| F2[コンポーネント26-50を移行] F1 --> G[フェーズ3: 統合テスト] F2 --> G G --> H{テスト成功?} H -->|はい| I[完了] H -->|いいえ| J[フェーズ4: 失敗コンポーネントを修正] J --> Gasync function vue2to3MigrationWorkflow(components) {
// フェーズ1: すべてのコンポーネントを並列分析
const analyses = await Promise.all(
components.map(c => analyzeComponent(c))
);
// フェーズ2: 移行計画を順番に構築 (フェーズ1に依存)
const plan = await agent({
task: 'Build the migration plan',
prompt: 'Based on the analysis, decide the migration order and flag potential conflicts',
context: analyses
});
// フェーズ3: 計画に従ってコンポーネントを並列移行
const migrated = await Promise.all(
plan.batches.map(batch =>
Promise.all(batch.map(c => migrateComponent(c)))
)
);
// フェーズ4: 統合テストを順番に実行
let testResult = await runIntegrationTests();
// フェーズ5: テストが失敗したら修正して再テスト (ループ)
let attempts = 0;
while (!testResult.passed && attempts < 3) {
const failures = testResult.failures;
await Promise.all(
failures.map(f => fixComponent(f))
);
testResult = await runIntegrationTests();
attempts++;
}
if (!testResult.passed) {
throw new Error('Migration failed: 3 fix attempts all failed the tests');
}
return { plan, migrated, testResult };
}
フェーズ1 (パラレル) フェーズ2 (シーケンシャル)analyze(1..50) ────→ generatePlan ↓フェーズ3 (パラレル) ↓migrate(1..50) ←────────────┘ ↓フェーズ4 (シーケンシャル)runTests ←─────┐ ↓ │ ├─成功→ 完了 │ └─失敗→ フェーズ5 (パラレル + ループ) fix(failures) ─┘タスク: REST APIのドキュメントを100個のエンドポイントについて、Swagger 2.0からOpenAPI 3.0にアップグレードする
このタスクを5-8個の明確なステップに分割してください。各ステップについて次を述べてください:1. 何をするか2. どんな入力が必要か3. 何を出力するか4. 並列実行できるかタスク: 5000行のPythonクラスを複数の小さなクラスに分割してリファクタリングする
このタスクの分解について段階的に考えましょう:
最初のステップは何をすべきで、なぜですか?最初のステップの出力に対して、2番目のステップは何に依存しますか?どのステップを並列実行できますか?各ステップが正しく完了したことをどう検証しますか?
詳細な分解を提供してください。複雑なタスクを提供します。例に従ってワークフローステップに分解してください。
例のタスク: 50枚の画像をバッチ処理(リサイズ、ウォーターマーク追加)例の分解:1. 画像リストを読み込む (入力: ディレクトリパス、出力: ファイルリスト)2. 各画像を並列処理: 2a. リサイズ (入力: 元画像、出力: リサイズされた画像) 2b. ウォーターマークを追加 (入力: リサイズされた画像、出力: 最終画像)3. 結果を保存 (入力: 処理済み画像リスト、出力: 保存パスリスト)
では、このタスクを分解してください: 20個のGitリポジトリのコントリビューター統計レポートを生成する矢印は依存関係を意味する: A → B は「BはAの出力に依存する」
ステップ1 → ステップ2 → ステップ4 ↓ ステップ3 ↗❌ 悪い例:1. データを準備する2. 移行を実行する3. 結果を検証する✓ 良い例:1. 設定ファイルを読み込む2. データベースに接続する3. ソースデータテーブルを読み込む4. データ形式を変換する5. ターゲットデータテーブルに書き込む6. 検証クエリを実行する❌ 悪い例:1. サービスAをデプロイ2. サービスBをデプロイ3. ロードバランサーを更新✓ 良い例:1. 現在の設定をバックアップ2. サービスAをデプロイ3. サービスAのヘルスチェック4. ステップ3が失敗 → サービスAをロールバック5. サービスBをデプロイ6. サービスBのヘルスチェック7. ステップ6が失敗 → サービスAとBをロールバック8. ロードバランサーを更新❌ 悪い例 (シーケンシャル):for (const service of services) { await buildService(service); await testService(service); await deployService(service);}✓ 良い例 (ハイブリッドパラレル):// すべてのサービスを並列ビルドawait Promise.all(services.map(s => buildService(s)));
// すべてのサービスを並列テストawait Promise.all(services.map(s => testService(s)));
// すべてのサービスを並列デプロイawait Promise.all(services.map(s => deployService(s)));元の分解:1. すべてのAPIエンドポイント設定を読み込む2. 新しいエンドポイント定義を生成する3. 本番環境にデプロイする