task decomposition戦略

task decomposition戦略は、CCA-F（Claude Certified Architect Foundations）試験のDomain 1がすべての非自明なエージェントシステムに適用するアーキテクチャレベルの視点である。タスクステートメント1.6は「複雑なワークフローに対するtask decomposition戦略を設計する」ことを問い、Agentic ArchitectureとOrchestrationのドメインが試験全体の27%を占めるため、task decomposition戦略は60問・120分・720点以上合格の試験で架設が直面するほぼすべてのシナリオに直接・間接的に登場する。特にCode Generation with Claude CodeとMulti-Agent Research Systemのシナリオ群は、固定順次パイプラインか動的適応プランか、per-fileローカルパスかcross-fileインテグレーションパスか、coordinatorをplannerとして機能させるか静的に配線したチェーンか、といった正しいdecompositionの選択に大きく依存する。

この学習ノートでは、CCA-Fアーキテクトが習得すべきtask decomposition戦略の全体像を説明する。なぜdecompositionが存在するか（エージェントごとの認知負荷を下げる・並列実行を実現する・attention dilutionを緩和する）、2つの主要なアプローチ（トップダウン階層型とボトムアップ機能型）、粒度の調整（サブタスクが大きすぎると一つのエージェントを圧倒し、小さすぎると調整オーバーヘッドに埋もれる）、依存関係のマッピング（順次チェーンと独立並列トラック）、サブタスクのインターフェース設計（分解されたステップ間のクリーンなinput/outputコントラクト）、再帰的decomposition（サブタスク自体が複雑すぎる場合）、coordinator-as-plannerパターン、プラン検証、試験で最も問われるstatic対dynamicのdecompositionの分岐、fan-outによる並列化、アンチパターン（chattyなサブタスク・循環依存・コンテキストの喪失）、そして試験が参照する実践的なシナリオアンカー（CI/CDコードレビュー・レガシーテストカバレッジ拡張・マルチエージェントリサーチ合成）を網羅する。

なぜDecomposeするのか：エージェントごとの認知負荷を下げ、並列実行を実現する

Claudeに渡す非自明なワークフローには、暗黙の選択が常に伴う。問題全体を一つのプロンプトに注ぎ込むか、それとも一連の（またはグラフ状の）より小さな問題に分割するか。task decomposition戦略はこの両極端の間の空間に存在する。Anthropic自身のプロンプトエンジニアリングガイダンスでも明記されているとおり、複雑なプロンプトを連鎖させることで性能が向上する。各サブステップが、多くの関連性の薄い要求に注意を分散させる代わりに、絞り込まれた目的に完全な注意を向けられるからだ。

アーキテクトがワークフローをdecomposeする理由は3つある。

1. 注意の集中。 12のファイルを読み込み、セキュリティ問題を確認し、3つのモジュールを書き直し、移行計画を作成し、PRの説明を書くという一つの大きなプロンプトは、すべての軸で浅く正しく、どの軸でも深く正しくない回答を生成する。焦点を絞ったサブステップへのdecompositionにより、各ステップはそれぞれの作業のために完全なコンテキスト予算と推論予算を受け取る。
2. 信頼性。 小さなステップは検証が容易である。サブステップが失敗した場合、パイプライン全体を再実行するのではなく、そのサブステップだけを再試行またはリルートすればよい。エラーの影響範囲は局所化される。
3. 並列実行。 独立したサブステップは、別々のsubagentセッションで並行して実行でき、「このリポジトリ内のすべてのファイルを並列でレビューする」といったタスクの実際の経過時間を大幅に短縮する。

CCA-F試験はdecompositionがエルゴノミクスの好みではなくアーキテクチャ上の決定であることを繰り返し問う。シナリオに「単一のClaude Codeセッションが30のファイルをレビューして統合サマリーを生成するよう求められている」とあれば、試験の正解パターンはdecompositionを含む。より長いシステムプロンプトでも、より大きなコンテキストウィンドウでも、低temperatureでもない。

Decompositionのアプローチ：トップダウン階層型 vs ボトムアップ機能型

CCA-Fは2つの主要なアプローチを認識する。

トップダウン

ゴールから始め、フェーズに分割し、フェーズをより具体的なサブタスクに分割し、各リーフが1つのエージェントの作業量になるまで続ける。プランは実行前に存在する。prompt chainingとplan modeと相性がよい。成果物が明確に定義されている場合に最適。

ボトムアップ

利用可能なケーパビリティ（ツール・subagent定義・MCP サーバー）から始め、「これらのプリミティブで有用な組み合わせは何か？」と問い、上向きに作業する。動的decompositionと相性がよい。ゴールが曖昧な探索的ワークフローに最適。

選択基準

成果物が明確でパスがわかっている場合はトップダウン。発見が必要であったり、ツールの組み合わせが重要な変数であったりする場合はボトムアップ。成熟したシステムはフェーズ内で適応的なボトムアップ分岐を持つトップダウンのスケルトンを組み合わせる。

粒度の調整：大きすぎるタスク vs 小さすぎるタスク

task decomposition戦略における最も難しい判断は、サブタスクの適切な粒度を選ぶことである。

大きすぎる場合

サブタスクが大きすぎるサイン：

• 単一のプロンプトがセキュリティ・パフォーマンス・スタイルなど複数の無関係な懸念事項を処理しなければならない。
• subagentが多くのツールを渡され、どれを使えばよいか判断できない。
• 多くのゴールに注意が分散するため、出力が浅くなる。
• サブタスクの合格・不合格の基準を一文で書くことができない。

小さすぎる場合

サブタスクが小さすぎるサイン：

• 調整のオーバーヘッド（セッションのスポーン・コンテキストの受け渡し・結果の収集）が実際の作業を上回る。
• 何も局所的に決定できないため、サブタスク間で大量の状態をやり取りしなければならない。
• 1つのエージェントがインラインで実行できた1行の変換を行うノードでグラフが溢れかえる。

適切な中間サイズ

適切なサイズのサブタスクは、単一の明確な目的・焦点を絞ったツールセット（2〜5ツールが実用的な目安）・数百トークンに収まるインプットコントラクト・構造化（JSON）または短い自然言語の成果物であるアウトプットコントラクトを持つ。正確に1つのレビュー可能な成果物（per-fileレビュー・関数レベルのパッチ・リサーチブリーフのセクション）を生成するサブタスクはほぼ常に適切なサイズである。

依存関係のマッピング：順次依存 vs 独立並列トラック

サブタスクが特定されたら、次のアーキテクチャ的な問いはそれらの依存関係である。

順次依存

サブタスクBはサブタスクAが出力を生成するまで開始できない。例：per-fileの分析サマリーが揃うまで統合プランは書けない。順次依存はprompt chainingで自然に対応できる。ステップ1の出力がステップ2のインプットの一部になる。

独立並列トラック

互いの出力を消費しないサブタスクは並行して実行できる。例：コード品質問題について30のファイルを分析する場合、各ファイルのレビューは独立している。並列トラックは複数のsubagentセッションにfan-outし、coordinatorが結果を集約する。

混合（DAG）ワークフロー

現実のワークフローはほぼ常に有向非巡回グラフ（DAG）の形をとる。初期のいくつかのサブタスクが並列にfan-outし、その結果が合成ステップに収束し、その合成が次の並列ウェーブへと再びfan-outする。正確な依存関係マッピングがdecompositionを実行可能にする。

マッピングが実行形状を決定する

• 純粋な順次チェーン → ステップ間の明示的なハンドオフを伴うprompt chaining。
• 純粋な並列fan-out → coordinatorがTask toolを通じてN個のsubagentをスポーンし集約する。
• 混合DAG → coordinatorが依存エッジを尊重しながらウェーブをオーケストレーションする。

サブタスクのインターフェース設計：クリーンなinput/outputコントラクト

decompositionの信頼性は、そのステップ間のコントラクトの質によってのみ担保される。杜撰なインターフェースは連鎖的なエラーを生む。

インプットコントラクト

サブタスクが作業を完了するために何が必要で、それ以上は何も必要ないか？無関係なコンテキストをインプットに詰め込みすぎるとsubagentの注意が分散する。必要なものを提供しないとsubagentが推測やハルシネーションを起こす。良いインプットコントラクトは具体的な成果物（ファイルパス・チケットID・前のサマリー）、1文で表現された集中したゴール、期待されるアウトプットの形式を明示する。

アウトプットコントラクト

サブタスクのアウトプットは、それを消費するものへのインプットである。ダウンストリームのステップが結果をパースする必要がある場合、構造化されたアウトプット（tool useを通じたJSONまたはテキスト内の明示的なXMLセクション）が望ましい。ダウンストリームのステップが散文を解釈できる別のClaude呼び出しであれば、自然言語のアウトプットでも問題ない。

コントラクトが重要な理由

Claude CodeのsubagentはISOLATEDコンテキストで実行される。coordinatorの会話履歴を継承しない。subagentが必要とするものはすべてコントラクト境界を明示的に越えなければならない。これを忘れることはアーキテクトの最も一般的な失敗の一つであり、CCA-F試験のコミュニティ合格レポートで繰り返し指摘されているポイントである。

再帰的Decomposition：サブタスクがまだ複雑すぎる場合

ツリーが1レベルより深くなる必要がある場合もある。「このサービスをレビューする」はコントローラー・ドメイン・パーシステンスへのdecompositionになり、それぞれがさらにper-fileパスへとdecomposeされる。

再帰するタイミング vs 停止するタイミング

サブタスクが単一目的テストに失敗するか、推論すべきツールが多すぎる場合に再帰する。再帰はcoordinator-subagentのネストにマッピングされる：ルートcoordinator → フェーズcoordinator → リーフワーカー。サブタスクが明確な合格・不合格基準を持つ1つの集中したClaudeセッションになったら停止する。実際には3レベルで十分であり、それ以上深くなると集中の恩恵を上回るコンテキスト受け渡しの複雑さが生じる。

Coordinator-as-Plannerパターン：ClaudeがDecompositionプランを自ら生成する

task decomposition戦略における強力なパターンは、Claudeにdecompositionプランをハードコーディングする代わりに自ら生成させることである。

動作の仕組み

coordinatorエージェントに全体的なゴール・利用可能なツール・任意で制約のスケッチを与える。coordinatorはextended thinking（またはplan mode）を使用してサブタスクを列挙し、依存関係に基づいて順序を決め、各ツールまたはsubagentの割り当てを選択する。coordinatorはプランを実行し、プランが指示するとおりにsubagentをスポーンするかツールを呼び出す。

使用すべきタイミング

作業の正確な形状が事前にわからない場合にcoordinator-as-plannerを使用する。例えば「このレガシーコードベースに包括的なテストを追加する」など。coordinatorはまずコードベースをマッピングし、影響度の高い領域を特定し、どのテストをどこに書くかを決定しなければならない。コードを見る前に正しい答えを予測できる静的プランは存在しない。

使用すべきでないタイミング

ワークフローが予測可能で繰り返し行われる場合（例：「mainブランチのすべてのPRを秘密情報とライセンス問題でレビューする」）、静的な事前に書かれたチェーンの方が、毎回再プランニングを行うより安価・高速・監査可能である。

プラン検証：実行前にDecompositionの完全性を確認する

coordinatorが生成した（または人間のアーキテクトが書いた）プランは、高コストの長時間実行作業が始まる前に検査すべきである。

検証すべき内容

• 完全性： 元の要求のすべてのゴールが少なくとも1つのサブタスクにマッピングされているか？
• 非重複： 2つのサブタスクが作業を重複させていないか？
• 実現可能性： 各サブタスクが必要なツール・コンテキスト・権限を持っているか？
• エッジケースのカバレッジ： 障害パスが明示されているか（サブタスクがエラーを返した場合はどうなるか）？

検証する方法

• Plan mode — Claude Codeのplan modeは任意のツールが実行される前に提案されたプランを表示し、人間（または第2のエージェント）が承認・拒否・修正する機会を与える。
• Plan-checkerエージェント — 2次エージェントがプランをレビューし、最初の実行者が開始する前にギャップを指摘する。
• 小規模でのドライラン — 3つのファイルでdecompositionを実行してから300のファイルに適用する。

動的Decomposition vs 静的Decomposition：試験で最も問われる軸

タスクステートメント1.6内で最も頻繁に問われる区別。

静的（固定パイプライン）

プランは実行前に完全に決定されている。すべてのステップ・サブタスク境界・ツールの割り当てが事前にわかっている。prompt chainingが標準的な実装。最適なケース：

• 予測可能な形状を持つ多面的レビュー（セキュリティパス・スタイルパス・パフォーマンスパス）
• 再現性が柔軟性を上回るCI/CDパイプライン
• コストとレイテンシを予測可能にする必要がある大量の繰り返し作業

動的（適応型）

プランは実行中に現れる。初期のサブタスクが後のサブタスクを再形成する情報を生成する。coordinatorがアクティブなplannerになる。最適なケース：

• オープンエンドの探索（「このレガシーコードベースに包括的なテストを追加する」）
• マルチエージェントリサーチシステム（予期しないスレッドを発見する）
• インシデントレスポンス（次のステップが現在のステップの発見内容に依存する）

アーキテクチャ上のトレードオフ

静的は予測可能で監査しやすく、動的は柔軟でコンテキストを意識する。CCA-F試験はシナリオのキューに基づいた選択を評価する。

• 「予測可能で繰り返し可能、すべてのPRが同じチェックを通る」→ 静的／prompt chaining
• 「オープンエンド、見るまで構造がわからない」→ 動的／adaptive plan

並列化のためのDecomposition：Fan-Outの機会を特定する

並列化は適切なdecompositionから得られる最大の実用的な利益の一つである。

Fan-Outパターン

サブタスクが独立している場合、coordinatorはTask tool（またはAgent SDKのsubagentスポーニングAPI）を通じて同時にサブタスクをスポーンする。各subagentは独自のISOLATEDコンテキストで実行される。coordinatorは結果を収集し、ダウンストリームのステップで合成する。

Per-fileローカル解析 + Cross-fileインテグレーションパス

このパターンはコード生成シナリオにおける主要な試験パターンであるため、特に注目に値する。多くのファイルをレビューするタスクの場合：

1. Per-fileローカルパス（並列fan-out）。 各ファイルに独自のsubagentを割り当て、コンテキストを集中させる。subagentはその1つのファイルを深く分析し、構造化されたローカルサマリーを生成する。
2. Cross-fileインテグレーションパス（順次集約）。 単一のcoordinatorがすべてのper-fileサマリーを読み込み、クロスカッティングな知見（共有ユーティリティ・APIコントラクト・一貫性のないパターン）を合成する。単一のper-fileパスでは見つけられなかった問題を発見する。

この2段階の形状は「すべてを1つのプロンプトでレビューする」（注意が分散）と「各ファイルを完全に独立してレビューして統合しない」（cross-fileのバグが見落とされる）の両方を上回る。

並列化の限界

Fan-outは無料ではない。各subagentはAPIクォータを消費し、各スポーンされたセッションはセットアップレイテンシを生じ、集約コストは結果数とともに増加する。実用的な上限の目安は「Nが大きく経過時間が重要な場合に並列化するが、集約自体が負荷問題にならない程度に抑える」ことである。

Attention Dilution：シングルパスレビューにおける根本的なリスク

attention dilutionはtask decomposition戦略の多くを動機づける障害モードであり、CCA-Fのコア技術的内容で明示的に言及されている。

Attention Dilutionの現れ方

• 20のファイルのシングルパスレビューが、真の検査ではなくジェネリックなチェックリストのような各ファイルについての1段落を生成する。
• coordinatorが深く掘り下げることができないため、異なる言葉で同じ高レベルの観察を多くのファイルで繰り返す。
• セッションがすべてのファイルを同時に作業中の注意に保持できないため、cross-fileのバグが見落とされる。

Decompositionによる修正方法

1つのファイルに集中したコンテキスト予算でper-fileのサブタスクに分割する。次に、per-fileの出力を見てクロスカッティングなパターンを見つけることだけを担うInDEDICATEDインテグレーションパスを追加する。2つの狭いパスが1つの広いパスを上回る。

Attentionのためにdecomposeすべきでない場合

小さな作業（2〜3ファイル）はdecompositionを必要としない。調整のオーバーヘッドが注意の恩恵を上回る。decompositionが明確な優位性を持つのは概ね5ファイル以上であり、ファイルが大きかったりチェックリストが豊富だったりする場合はより早い段階から優位性が現れる。

Prompt Chaining：静的Decompositionの標準的なツール

Prompt chainingは静的decompositionの最もシンプルで最も試験に出る実装である。

Prompt Chainingが適切なケース

• タスクに予測可能なシーケンスがある（分析 → 要約 → 翻訳 → フォーマット）。
• 各ステップに明確なインプットとアウトプットがある。
• 柔軟性より信頼性と監査可能性が重要。

Prompt Chainingが不適切なケース

• 次のステップが現在のステップで発見したことに本質的に依存する（代わりに動的decompositionを使用する）。
• チェーンが1つのプロンプトで処理できる単純な変換である。
• サブステップが独立して並列実行できる（シリアルチェーニングの代わりにfan-outを使用する）。

動的（適応型）Decomposition：実行中にプランが現れる

適応ループ

動的decompositionエージェントはループを実行する：

1. 現在の状態に基づいて次の1〜3つのサブタスクを計画する。
2. 次のサブタスクを実行する（直接またはスポーンされたsubagentを通じて）。
3. 結果を観察し、残りの作業のメンタルモデルを更新する。
4. 学習した内容に照らして残りの作業を再計画する。
5. 全体的なゴール基準が満たされたら終了する。

実践例：レガシーコードベースへの包括的なテストカバレッジ

CCA-F試験の標準的な動的decompositionシナリオ。coordinatorはまずディレクトリ構造をマッピングし、既存カバレッジが最も低く本番リスクが最も高いモジュールを特定し、優先順位付きのプランを作成してからsubagentにper-moduleのテスト作成を委任する。静的プランはコードを見る前に正しい優先順位を選べない。

動的DecompositionとPlan Mode

Plan modeは動的decompositionの軽量な形態である。Claude Codeはツールに触れる前に実行予定のことを計画し、人間のレビューのためにプランを表示してから実行する。Plan modeは1人の人間レビュアーがプランを確認・承認する場合に有用。完全に自律的な動的decompositionはループが人間の介在なしに実行されなければならない場合に有用。

Task ToolとSubagentスポーニングをDecompositionプリミティブとして使う

Claude CodeとAgent SDKはいずれも、decompositionの機械的な実装であるTask tool（および関連するsubagentスポーニングAPI）を公開している。

Task Tool

Task toolはcoordinatorエージェントが明確にスコープ設定されたサブタスクを処理するsubagentをスポーンすることを可能にする。coordinatorはsubagentが行うべきことの説明と、任意でsubagentが使用を許可されるツールセットを提供する。subagentはISOLATEDコンテキストで実行される。coordinatorの会話履歴を参照できず、coordinatorが明示的に渡したものだけを参照する。

DecompositionユニットとしてのSubagent

各subagent呼び出しはdecompositionツリーの1つのサブタスクに対応する。適切なアーキテクチャはdecompositionとsubagent境界を整合させる。subagent呼び出しごとに1つのリーフサブタスクと、クリーンなinput/outputコントラクト。

コンテキストの分離はバグではなく機能である

CCA-F試験は候補者がsubagentのコンテキスト分離が意図的であることを理解しているかどうかを繰り返し問う。分離はcoordinatorの蓄積された会話がsubagentの集中を薄めることを防ぐ。subagentが必要とするものはすべて明示的に渡されなければならない。コンテキストを境界をまたいで「漏らす」必要がある場合、おそらくdecompositionが間違っている。

Cross-fileインテグレーション：Per-fileの結果をまとめるパス

Per-fileローカル解析がfan-outして完了した後、専用のcross-fileインテグレーションパスが、単一のper-fileパスでは生成できなかった知見を合成する。

Cross-fileインテグレーションが行うこと

• ファイルをまたいだパターンを検出する：消費者間で一貫性なく使用されているAPIコントラクト・複数の場所で再実装されているユーティリティ・一部のモジュールには適用されていて他には忘れられているセキュリティパターン。
• 矛盾を解消する：あるper-fileレビューがインポートを未使用と指摘し、別のper-fileレビューがクリティカルと指摘した場合、インテグレーションパスがどちらが正しいかを解決する。
• 最終的な集約成果物（PRコメント・アーキテクチャメモ・優先順位付きアクションリスト）を生成する。

なぜ別個のパスでなければならないか

すべてのファイルを読んでから同じプロンプトでcross-fileの合成も生成するよう単一エージェントに頼むと、両方の作業に注意が分散する。それぞれが1つの作業のために完全な注意予算を持つ2つの狭いパスは、1つの広いパスを上回る。

インテグレーションパスのインプット

インテグレーションパスは生のファイルではなく、per-fileパスの構造化されたアウトプットを消費する。これにより、コードベースが大きい場合でもインテグレーションパスのコンテキスト予算が管理可能に保たれる。

DecompositionアンチパターンChattyなサブタスク・循環依存・コンテキストの喪失

成熟したdecompositionは、回避する障害モードによって部分的に定義される。

Chattyなサブタスク

粒度が細かすぎることを補うためにサブタスクが大量のコンテキストをやり取りする。修正： より多くの作業が1つのサブタスク内で局所的に決定できるように粗くする。

循環依存

AはBが必要、BはAが必要。境界が間違った場所にある。修正： AとBをマージするか、依存が一方向に流れるように切り直す。

境界でのコンテキスト喪失

Coordinatorがsubagentのインプットに重要な事実を渡し忘れる。Subagentが折り返し（往復）を尋ねるかすでに代替を作成する。修正： すべてのサブタスクタイプのインプットコントラクトを明示的にドキュメント化する。

決して再集合しないDecomposition

パイプラインがper-fileの出力を生成して停止し、人間が統合することを期待する。人間が常にいる場合は問題ないが、パイプラインが自律的であれば問題。修正： 常に明示的な集約ステップを含める。

一律適応型

作業が予測可能か探索的かに関わらず同じ固定パターンを使用する。修正： 先に説明したキューに基づいてシナリオごとにstaticかdynamicかを選択する。

やさしい解説: Task Decomposition Strategies

抽象的なdecompositionパターンは、実世界の具体的な系に基づいた直感的なものになる。task decomposition戦略の全体像をカバーする3つの比喩を紹介する。

Analogy 1: 駅弁工場の製造ライン — 静的なPrompt Chaining

新幹線の発車に間に合わせるために大量の駅弁を生産する工場の製造ラインは、物理的な形をとった静的・順次的なdecompositionである。食材を洗って切り分ける下ごしらえ担当、ごはんを詰める担当、おかずを並べる担当、包装担当、品質検査担当。各担当者は1つの仕事・自分のツール・次の担当者への予測可能な引き渡しを持つ。メニューがチェーンを事前に定義し、あるおかずセットはすべて同じ担当者を同じ順序で通過する。どの担当者も他の担当者の仕事をしようとしない。それはatention dilutionのお弁当箱版だ。

これがprompt chainingである：各Claude サブステップは狭い目的・集中したツールセット・クリーンな引き渡し成果物を持つ製造ラインの工程である。多面的なPRレビューも同様に機能する。セキュリティ担当・スタイル担当・パフォーマンス担当・そして統合レビューを生成する最終の盛り付け担当。

Analogy 2: 初めて入る古民家のリノベーション — 動的適応型Decomposition

レガシーコードベースに包括的なテストを追加することは、一度も入ったことのない古い家をリノベーションするようなものだ。初日から完全な工事スケジュールは書けない。どの壁が構造壁か、どの配線が古くて腐食しているか、どの部屋が構造的に健全かがわからないからだ。代わりに、総監督は最初の週を建物の調査・最もリスクの高い問題の特定・優先順位付けに費やし、その後でようやく特定の部屋に専門業者を割り当て始める。電気工が予想外の古い配線を発見すると、プランは再び組み替えられる。

これが動的decompositionである。プランは層ごとに現れ（まず調査、優先順位の特定、具体的なタスクの委任）、サブタスクが状況を変える情報を返すたびに自らを再形成する。一度も入ったことのない家の静的に計画されたリノベーションは高価な失敗に終わる。

Analogy 3: 全科目の持ち込み可能な大学の期末試験 — Attention Dilution

10の異なる章をカバーする持ち込み可能な試験を、90分間で全章に対応する1つのエッセイを書くとして想像してほしい。10の章すべてに連続して対応しようとする学生は、各トピックに浅く触れるだけで深いつながりを見落とした浅いエッセイを生成する。賢い戦略は時間を分割することだ。各章に20分間集中してノートを取り、最後に10分間の合成パスでその章のノートを1つの一貫したエッセイにまとめる。

これがまさにper-fileローカル解析とcross-fileインテグレーションである。各「章パス」は1つのファイルに完全な注意を向ける。合成パスはインテグレーションに完全な注意を向ける。注意は分割すると損失が生じる有限のリソースであるため、2つの狭いパスが1つの広いパスを上回る。

試験当日にどの比喩を使うか

• 「予測可能なパイプライン、すべての実行が同じ形状」→ 駅弁工場の比喩 → prompt chaining ／静的decomposition
• 「オープンエンド、計画の前に見る必要がある」→ 古民家リノベーションの比喩 → 動的／適応型decomposition
• 「多くのファイルをレビューしているが、出力が浅いかcross-fileの問題を見落としている」→ 期末試験の比喩 → per-fileのdecompositionとインテグレーションパス

シナリオウォークスルー：Code Generation with Claude Code

Code Generation with Claude Codeシナリオクラスターは6つのCCA-Fシナリオの1つであり、タスク1.6問題の頻繁な舞台である。

シナリオの形状

Claude Codeセッションが12のファイルにわたるプルリクエストをレビューして、セキュリティ・スタイル・保守性をカバーする単一の統合レビューコメントを生成するよう求められる。

間違ったDecomposition

単一のプロンプト：「すべてのファイルをセキュリティ・スタイル・保守性でレビューして統合コメントを書く」。注意が12のファイルと3つの懸念事項に分散し、浅い観察を生成してcross-fileの問題を見落とす。

正しいDecomposition

• Per-fileのfan-out： 1ファイルあたり1つのsubagent、それぞれがそのファイルのみの3つの懸念事項をカバーする構造化されたローカルレビューを生成する。
• Cross-fileインテグレーションパス： 単一のcoordinatorが12の構造化されたレビューを読み込み、クロスカッティングなテーマを特定し、矛盾を解消し、統合PRコメントを書く。

この形状はper-fileローカル＋cross-fileインテグレーションパターンを直接反映しており、ClaudeのドキュメントでもPreferredアーキテクチャとされている。

シナリオウォークスルー：Multi-Agent Research System

Multi-Agent Research Systemシナリオは動的decomposition問題の標準的な舞台である。

シナリオの形状

Coordinatorがオープンエンドなトピックのリサーチブリーフを作成するよう求められる。coordinatorはウェブ検索・内部ドキュメント検索・リサーチsubagentをスポーンする能力を持つ。

間違ったDecomposition

静的チェーン：検索 → 要約 → 執筆。coordinatorは初期の検索結果を読む前にどのスレッドを追う価値があるかを事前に知ることができない。静的チェーンは有望なスレッドを発見するのが遅すぎるため浅いブリーフを強制する。

正しいDecomposition

• 初期スキャン： coordinatorが幅広い検索を実行してトップレベルの結果を読み込み、領域をマッピングする。
• スレッドの特定： coordinatorが最も有望な3〜5のスレッドを特定する。
• 並列の深掘り： coordinatorがスレッドごとにリサーチsubagentをスポーンし、それぞれが独自のISOLATEDコンテキストと集中したツールセットを持つ。
• 合成： coordinatorがスレッドサマリーを最終ブリーフに集約する。

プランは初期スキャンの後に生成され、前ではない。これが動的decompositionである。

シナリオウォークスルー：Claude Code for Continuous Integration

CI/CDシナリオクラスターは、アーキテクトが静的で再現可能なdecompositionが正しい選択である場合を認識できるかどうかを問う。

シナリオの形状

チームがCI上のすべてのプルリクエストでClaude Codeを実行し、組織全体で一貫したレビュー標準を適用したい。

正しいDecomposition

ここではほぼ常に静的prompt chainが正しい。ステップはすべてのPRで同じ。再現性と監査可能性が優先される。PRごとの動的再プランニングはCIの結果を非決定的にしパイプラインをレビュー不可能にする。

なぜ動的ではないか

CIにおける動的decompositionは、すべての実行が異なる動作をする可能性があることを意味し、「同じ入力、同じ出力」というCI上のコアコントラクトを破壊する。-p（非インタラクティブ）フラグ・静的チェーン・明示的なステップ定義はCIの再現性要件と合致する。

よくある試験のトラップ：CCA-Fが悪用するDecompositionの誤解

トラップ1：DecompositionはコンテキストリミットをAutomaticallyに解消しない

よくある選択肢はワークフローをdecomposeすることが常にコンテキストウィンドウの問題を解決すると主張する。Decompositionは各サブタスクに集中したコンテキストを与えることで役立つが、コンテキストを魔法のように無限にするわけではない。各subagentにはまだコンテキストウィンドウがある。1つのsubagentのインプットに50メガバイトのコードを渡すと、モノリシックなエージェントと同様に失敗する。

トラップ2：Plan ModeはDecompositionと同じではない

Plan modeは実行前に提案されたプランをレビューするためのClaude Code機能である。Task decompositionはワークフローをサブタスクにどう切り分けるかについてのアーキテクチャ的な設計決定である。Plan modeはdecomposeされたプランまたはモノリシックなプランのいずれにも使用できる。

トラップ3：動的Decompositionが常により良いわけではない

「adaptive」をすべてのシナリオで選択する本能はコミュニティの合格レポートで繰り返し指摘されている。CI/CD・大量の構造化extraction・予測可能性が柔軟性を上回るシナリオではadaptiveは間違いである。

トラップ4：SubagentのコンテキストはInheritされない

Coordinatorの履歴がすべてのsubagentに流れると仮定する候補者は壊れたシステムを設計する。Task toolとAgent SDKのsubagent APIはいずれもデフォルトでコンテキストを分離する。これは集中を向上させる機能であり、回避すべきバグではない。

トラップ5：Fan-OutはFreeではない

並列化は表面上「無料」に見えるが、各subagentはAPIクォータを消費し、各スポーンにはセットアップレイテンシがあり、集約の複雑さはブランチ数とともに増加する。

トラップ6：Cross-fileインテグレーションはPer-file Fan-Outのオプションではない

Per-fileのsubagentにfan-outして停止し、ユーザーが12の別々のレポートを読むことを期待するdecompositionは作業を終えていない。アーキテクトは常にインテグレーションパスを設計しなければならない。

実践アンカー：タスク1.6シナリオ問題テンプレート

task decomposition戦略に関するCCA-F実践問題は5つの形状にまとまっている。

テンプレートA：Static vs Dynamic選択（Code Generation）

チームがClaude CodeにすべてのPRを一貫したチェックリスト（秘密情報検出・ライセンスコンプライアンス・テストカバレッジ閾値）でレビューさせたい。チェックは全PRで同じ。正解：静的prompt chaining — 予測可能な作業面、再現性と監査可能性が優先。

テンプレートB：Static vs Dynamic選択（レガシーテスト拡張）

エンジニアリングチームがClaude Codeに自分たちが書いていないレガシーPythonコードベースに包括的なテストを追加させたい。対象モジュール・優先順位・テストスコープは事前に不明。正解：動的adaptive decomposition — coordinatorはコードベースをマッピングし影響度の高い領域を特定してから計画する必要がある。

テンプレートC：Attention Dilution診断（マルチファイルレビュー）

単一のClaude Codeセッションが20のファイルをセキュリティ・スタイル・保守性について1つのプロンプトでレビューするよう求められる。出力は表面的でcross-fileの問題を見落とす。最もありそうなアーキテクチャ的な修正は何か？正解：per-fileのdecompositionとcross-fileインテグレーションパス。

テンプレートD：Subagentのコンテキスト分離

Coordinatorが特定のモジュールを分析するsubagentをスポーンし、subagentがcoordinatorのプロジェクト規約についての以前の議論を見られると仮定する。Subagentが規約を無視する。根本原因は？正解：subagentのコンテキストはISOLATEDである；coordinatorがTask toolのインプットを通じて明示的に規約を渡さなかった。

テンプレートE：CI/CDのDecomposition形状

Claude Codeを使用したCIパイプラインがすべてのPRに対して確定的な動作で同じレビューステップを実行しなければならない。アーキテクトが推奨すべきdecompositionパターンは何か？正解：-p非インタラクティブモードでの静的prompt chain — 再現性が優先される。

CCA-Fの深さ：タスク1.6が問うことと問わないこと

CCA-Fはtask decompositionについてのアーキテクチャレベルの認識深度の資格である。シナリオに対して正しいdecompositionパターンを特定し・static対dynamicの軸を認識し・attention dilutionを発見し・明示的なコントラクトでクリーンなサブタスク境界を設計することが期待される。

タスク1.6が期待すること

• いつdecomposeするかと1つのプロンプトで十分な場合を認識する。
• シナリオのキューに基づいてstatic（prompt chaining）かdynamic（adaptive）かを選択する。
• Per-fileローカル＋cross-fileインテグレーションパターンを設計する。
• Attention dilutionの症状を発見し修正としてdecompositionを適用する。
• Subagentのコンテキスト分離が意図的で設計されたものであることを認識する。
• Decompositionアンチパターン（chatty・circular・lost-context・never-reassembled）を特定する。

タスク1.6が期待しないこと

• Pythonでカスタムcoordinator-plannerループをゼロから実装する。
• Task toolまたはAgent SDKスポーニングAPIの特定パラメーターをコードレベルで調整する。
• 特定のモデルウェイトやファインチューニングされたバリアントを選択する。
• ストリーミングAPIの詳細・ビジョン入力・クラウドプロバイダー固有のデプロイ（Bedrock / Vertex / Azure）。
• Decompositionされたサブタスクのトークン予算やレートリミットクォータを計算する。

研究がそれらの項目に流れ込んだ場合、スコープ外の領域に入っている。アーキテクチャレベルの判断に戻り次に進む。

Task Decomposition Strategies よくある質問（FAQ）

CCA-F試験におけるprompt chainingと動的decompositionの違いは何か？

Prompt chainingは静的である。サブプロンプトの完全なシーケンスが実行前に定義され、すべての実行が同じステップを辿る。動的（adaptive）decompositionは実行中に再形成する。coordinatorは次の1〜2つのサブタスクを計画し・実行し・結果を観察し・学習した内容に基づいて残りの作業を再計画する。Prompt chainingは固定チェックリストでのPRコードレビューなど予測可能なパイプラインに適している。動的decompositionはcoordinatorがコードを調査するまで正しいプランがわからないレガシーコードベースへのテストカバレッジ拡張などオープンエンドの作業に適している。

いつper-fileのdecompositionとcross-fileインテグレーションパスを選択すべきか？

作業が複数のファイルにわたり、ファイル内の深さ（セキュリティ・スタイル・保守性）とcross-fileの合成（APIコントラクトの一貫性・共有ユーティリティの重複）の両方が必要な場合にこのパターンを選択する。多くのファイルのシングルパスレビューはattention dilutionを引き起こし、出力が浅くcross-fileのバグが見落とされる。Per-fileのfan-outはファイルごとの集中した注意を回復し、専用のインテグレーションパスはcross-cuttingの合成を回復する。

Attention dilutionとは何か、decompositionはどのようにそれに対処するか？

Attention dilutionは、単一のClaude セッションが一度に多くのファイル・ゴール・懸念事項に注意を向けることを求められたときに出力品質が低下する現象である。推論予算がすべてのフォーカスターゲットに分散され、各ターゲットはClaudeの実際の能力のほんの一部しか受け取らない。Decompositionは過負荷になったプロンプトを集中したサブタスクに分割し（各サブタスクが単一の目的のための完全な注意予算を持つ）、合成が必要な場合は明示的なインテグレーションパスを追加することで、直接対処する。

Task toolを通じてスポーンされたsubagentはcoordinatorの会話履歴を継承するか？

しない。Task toolまたはAgent SDKのsubagentスポーニングAPIを通じてスポーンされたsubagentはISOLATEDコンテキストで動作する。coordinatorがサブタスクの説明を通じて明示的に渡したものだけを参照する。これは意図的である。分離によりcoordinatorの会話がsubagentの集中を薄めることを防ぎ、サブタスクのコンテキスト予算をクリーンに保つ。継承を仮定したアーキテクトは静かに失敗するシステムを設計する。

Plan modeはtask decompositionとどう関係し、同じものか？

Plan modeとtask decompositionは関連しているが異なる。Plan modeはClaudeがツールに触れる前にプランを提案することを可能にするClaude Code機能で、人間のレビュアーに承認・拒否・修正の機会を与える。Task decompositionは複雑なワークフローをサブタスクにどう切り分けるかについてのアーキテクチャ的な設計決定である。CCA-F試験では2つを互いのdistractor として頻繁に使用する。代替品ではない。

動的decompositionは常に静的prompt chainingを上回るか？

いいえ。動的decompositionはプランが事前にわからないオープンエンドで発見が多いタスクで優れている。CI/CDパイプライン・大量の構造化extraction・予測可能性・再現性・監査証跡が柔軟性より重要なワークロードでは積極的に間違いである。「adaptive」をすべてのシナリオで選択することはCCA-F合格レポートで指摘されている最も一般的な誤答パターンの1つである。

Task decompositionで回避すべき主なアンチパターンは何か？

CCA-Fシナリオで繰り返し現れる5つのアンチパターンがある。第1に、粒度が細かすぎるために大量のコンテキストをやり取りするchattyなサブタスク。第2に、AがBを必要としBがAを必要とする循環依存。第3に、coordinatorが重要な何かを渡し忘れる境界でのコンテキスト喪失。第4に、fan-outするが決して再集合しないdecomposition。第5に、作業が予測可能か探索的かに関わらず同じ固定パターンを使用すること。

参考資料

• Claude Certified Architect Foundations Exam Guide (v0.1): https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Building effective agents (agentic loop patterns): https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Create custom subagents (Claude Code): https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Plan mode and iterative refinement: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude Code CI/CD integration: https://docs.anthropic.com/en/docs/claude-code/ci-cd

関連するExamLabのトピック：Multi-Agent Orchestration with Coordinator-Subagent Pattern、Multi-Step Workflows with Enforcement and Handoff、Agentic Loops for Autonomous Task Execution、Plan Mode vs Direct Execution。