タスク分解とは？AIエージェントの分解粒度・3手法・妥当性検証を実装目線で解説

タスク分解とは、ゴールと制約を受け取って「どのサブタスクを、どの順序と依存で片づけるか」を決め、実行できる単位の列へ変換する工程です。実装で詰まるのは分解の作り方そのものではありません。どこまで細かく割るか、割った結果が正しいかをどう検査するか、そもそも割るべきかどうか。この記事では、1サブタスクの粒度を決める3基準、Least-to-Mostと依存グラフ型と役割分解の使い分け、欠落と重複と過分解を実行前に落とす検査手順、そして分解を作り込まずに済ませる場面までを実装者向けに整理します。計画をどの形式で保持し、いつ作り直すかという運用側の設計はAIエージェントのプランニングで扱っているため、本記事では分解そのものに絞ります。

まとめ｜分解単位・手法選択・妥当性検査で決まるタスク分解の成否

分解の良し悪しは、細かさではなく「割った単位が観測できるか」で決まります。完了を機械判定できない単位、失敗しても部分再実行できない単位、次段へ渡す型が定義されていない単位。この3つのどれかに当てはまる分解は、実行時にどこで止まったか分からなくなります。細かく割ったから安全になるわけではありません。

着手前に決めるのは3点です。第一に粒度の基準。完了判定・再実行単位・受け渡し型の3つを満たす最小単位を1サブタスクとし、それ以上は割りません。第二に分解手法。部分問題が前から順に積み上がるならLeast-to-Most、独立ステップが同時に立つなら依存関係付きのJSON列、専門が分かれる長工程なら役割分解、業務手順が既に文書化されているならモデルに分解させず人が固定します。第三に分解結果の検査。ゴールの制約が全サブタスクへ割り当たっているか、同じ副作用を持つステップが二重に立っていないか、階層が深くなりすぎていないかを、実行前に機械判定へ落とし込む。この3点を決めないまま分解プロンプトだけ書くと、動くデモのまま監査もテストもできない状態で本番を迎えます。

タスク分解の定義と業務のWBSがAIエージェントで通用しない理由

「タスクを分解する」という日本語は、人が計画表を作る作業と、モデルが実行時にサブゴールを生成する処理の両方を指してしまいます。実装の前に、この2つを切り分けます。

ゴールをサブタスク列へ変換する工程としてのタスク分解の定義と範囲

入力はゴールと制約、出力はサブタスクの列です。列には順序または依存関係が含まれ、各サブタスクには「何を使って何を出すか」が書かれます。ここに含まれないのは、その計画をどのデータ型で保持するか、実行途中で作り直すか、どこで打ち切るかという運用側の判断です。分解は1回の変換、プランニングはその変換結果を状態として運用する工程。責務がこう分かれます。

境界を意識しないと設計が濁ります。分解の議論をしているつもりで再計画の話に流れ、粒度の基準が決まらないまま実装に入る。よくある事故です。本記事は変換側だけを扱い、変換結果をどう持ち回るかは計画の表現形式と再計画の設計へ送ります。

人が事前に書くWBSとモデルが実行時に作る分解の3つの相違点

プロジェクト管理の作業分解構成図と混同されやすいのですが、性質は3点で異なります。

• 作成の時点と主体：WBSは着手前に人が確定させる。エージェントの分解はゴールを受け取った実行時にモデルが生成する
• 完了の定義：WBSは担当者の判断で完了とする。エージェントは出力の型やスキーマで機械判定できないと完了を検知できない
• 変更の重さ：WBSの改訂は関係者の合意が要る。分解の作り直しは数秒で終わる代わりに、何がいつ変わったかの記録を自前で残す必要がある

実務でまず効くのは2番目です。人向けの分解は「顧客情報を確認する」で通りますが、機械には通りません。確認とは何を読み、何が返ればよいのか。ここが書けない粒度は、そのままでは実行単位になりません。人が作る側の手順はWBSの作り方とガントチャートとの違いに整理してあり、両者を同じ表で管理しようとして破綻する現場は珍しくありません。

サブタスク1件の粒度を決める完了判定・再実行・受け渡しの3基準

粒度の議論は「1ステップ＝1ツール呼び出し」といった目安で語られがちです。目安としては使えますが、判断の根拠にはなりません。決め手は観測できるかどうかの3点です。

完了を機械判定できる単位まで割るときの出力型と成功条件の決め方

サブタスクを定義したら、先に「成功とは何が返ることか」を書きます。文字列が返ればよいのか、指定したキーを持つJSONが返ればよいのか、件数が1件以上あればよいのか。ここを型として書けない単位は、実行しても成功も失敗も判定できず、後続へ進んでよいかが決まりません。

実務では、期待する出力の型をサブタスクの属性として持たせ、実行直後に検証します。型が合わなければ、そのサブタスクの失敗として扱う。呼び出し側の引数検証や関数定義の設計はAIツール使用の実装と地続きで、分解の段では「何が返るはずか」だけを決めておけば足ります。

失敗したステップだけを再実行できる冪等性と副作用の切り分け方

分解の第二基準は、失敗時にそのステップだけをやり直せるかどうかです。5件の処理を1ステップにまとめると、3件目で落ちたときに1件目から作り直すか、途中状態を自前で管理するかの二択になります。

副作用を持つ処理は単独のサブタスクへ隔離します。メール送信、DB更新、外部システムへの登録。これらを検索や要約と同じステップに混ぜると、リトライのたびに二重送信が起きる。読み取り系は何度実行しても結果が変わらないため、まとめても実害が出にくい。この非対称を前提に、書き込みだけを切り出すのが実装上の定石です。

20ステップ超の過分解で追跡が破綻する深さ2〜3階層の上限設計

細かく割るほど安全という直感は外れるものです。1ステップが「変数に値を入れる」水準まで落ちた分解は、失敗箇所の特定より分解結果の読解に時間がかかります。目安として、階層は2〜3層まで、末端のサブタスクは20件程度を上限に置きます。

階層を許すのは、ゴールが明確に別領域へ分かれる場合だけです。古典プランニングの階層タスクネットワーク（HTN）はゴールを下位タスクへ再帰展開しますが、あれは操作と状態が形式化された領域の話。自然言語のゴールで再帰展開を許すと、下位ほど抽象語が並び、末端で何をすればよいのか誰にも分からなくなります。上限を超えたら、割るのではなく1つ上の階層でまとめ直す。

LLMに分解させる3手法と人が手順を固定する方式との使い分け基準

分解の作り方は、出力の形で3系統に分かれます。どれを選ぶかはタスクの依存構造で決まり、好みでは決まりません。

初手は依存グラフ型です。並列度が1のままでも、id と依存を持たせておけば検証層をそのまま流用できます。

部分問題を順に解かせるLeast-to-Most方式が効く条件と限界

Least-to-Most（arXiv:2205.10625・2022年5月提出、ICLR 2023）は、複雑な問題をより易しい部分問題へ分け、前の答えを次の入力に渡しながら順に解かせる手法です。論文はcode-davinci-002と14例示でSCANの全splitを99%以上、同条件のchain-of-thoughtは16%と報告しました。段階的に難度を上げる分解が、単に途中式を書かせるより効いた例です。

効くのは、部分問題が前から順に積み上がる構造に限られます。逆に、途中の観測結果で後続の分岐が変わるタスクでは、最初に生成した部分問題の列が2手目で無効になる。もう1つの限界は誤りの伝播で、部分問題の生成そのものが外れると、以降の解答はすべてずれたまま進みます。分解の妥当性を実行前に見る層が要る理由がここにあります。

依存関係を持つJSON列で受け取るHuggingGPT型の分解記法

HuggingGPT（arXiv:2303.17580・2023年3月提出、NeurIPS 2023）は、分解結果を task・id・dep・args の4フィールドを持つJSON列で受け取ります。id は参照用の一意な識別子、dep は先行タスクIDの配列で、論文は「全ての先行タスクが完了して初めて起動する」と定義しています。先行タスクの生成物は resource-task_id の形で引数に書き、実行時に実体へ置き換える構成です。

自社実装へ落とすときは、task を自社ツール名の列挙へ差し替え、args に渡す引数のスキーマを固定します。この形にしておくと、存在しないツールを指す分解、循環依存を含む分解、許可外の操作を含む分解を実行前に落とせる。並列実行やスケジューリングの設計は分解の下流にあたるため、そちらは計画の実行アーキテクチャを参照してください。

役割ごとに分けて委譲する分解と人が手順を固定する方式の境界線

3つ目は、工程ではなく担務で割る方式です。調査役・執筆役・検査役のように専門で分け、各担当へサブタスクを委譲します。分割後の受け渡しと統合には別の設計が要り、その全体像はマルチエージェントオーケストレーションの主要パターンにまとめています。

ここは言い切ります。業務手順が既にマニュアルとして文書化されている領域では、モデルに分解させません。人が確定した順序と分岐条件を手順として持たせ、モデルには各ステップ内の判断だけを任せる。分解を生成させると、現場の例外処理や承認順序といった文書に書かれた制約が毎回落ちるためです。標準作業手順で制御する型は対極のアプローチとして関連記事に置きました。

分解結果を実行前に検査する欠落・重複・過分解の3つの検出手順

分解は生成した時点では正しさが分かりません。実行して初めて破綻が見えるのでは遅く、検査を挟みます。

ゴールの制約が全サブタスクへ割り当たっているかの欠落検査手順

最初に、ゴール文から制約を抜き出して並べます。対象範囲、期限、出力形式、禁止事項、承認の要否。次に、各制約がどのサブタスクで満たされるかの対応表を作り、割り当て先が無い制約を欠落として検出します。「社外へ送る前に責任者の確認を通す」という制約が、どのステップにも紐づいていない。この型の欠落が本番事故の入口です。

対応表は人が目視するものではなく、分解結果のフィールドとして持たせます。Anthropicの「Building effective agents」（2024年12月公開）がprompt chainingを「タスクを固定のステップ列へ分解し、途中にプログラム的なゲート検査を挟む型」として定義しているのと同じ発想で、ゲートの判定材料を分解の段で用意しておく形になります。

同じ副作用を持つ2ステップを洗い出す重複と競合の具体的な検出方法

重複は、同じ処理が2箇所に書かれる素朴な型より、同じ対象へ書き込むステップが別名で2つ立つ型が厄介です。「通知を送る」と「担当者へ連絡する」が別サブタスクとして並び、実行すると二重に届く。

検出は、各サブタスクに「書き込み対象」を属性として持たせ、対象集合の交差を機械判定します。宛先、テーブル名、ファイルパス、外部APIのエンドポイント。交差があり、かつ依存関係で順序が定まっていないステップ対を競合として警告します。読み取り専用のステップは交差しても問題にならないため、副作用の有無で判定を分ける。この一手間で、実行してから気づく二重処理の大半が事前に消えます。

分解の妥当性を軌跡評価へ渡して継続的に測る2つの指標の置き方

事前検査で落とせるのは形式的な破綻までで、分解が業務として妥当だったかは実行後にしか分かりません。継続して見る指標は2つで足ります。サブタスク単位の成功率と、1ゴールあたりの再分解の発生回数。前者が特定のサブタスクだけ低ければ、その単位が粗すぎるか、成功条件の定義が曖昧です。後者が増えていれば、最初の分解が現実と噛み合っていない兆候になります。

どちらもゴール単位の成否だけを見ていると検出できません。実行の軌跡を記録して、どのサブタスクで何が起きたかを追える形にしておく必要があります。測り方の設計はAIエージェント評価の指標に整理しました。

分解を作り込む採用条件と単発プロンプトで済ませる場面の判断基準

ここも言い切ります。分解の設計に工数をかけるべき案件は限られ、条件を外れた案件では純粋な負債になります。

分解を作り込んでよい3条件と1つ以下なら入れないと決める理由

作り込む価値があるのは、次の3条件のうち2つ以上を満たす場合です。第一に、同じ型の依頼が繰り返し来ること。分解テンプレートを資産として使い回せます。第二に、途中の成果物に人の承認が要ること。承認の節目がそのままサブタスクの境界を規定するため、分解しないと承認点を置けません。第三に、巻き戻しコストの高い副作用を含むこと。部分再実行のために単位を切る必要が出ます。

満たすものが1つ以下なら、分解の構造を持たずに単発のプロンプトとゲート検査1枚で組んだほうが速く、壊れにくい。分解を持つと、分解の生成・検証・記録という保守対象が3つ増えます。なお、費用や呼び出し回数の観点から明示的な計画層を持つかどうかという判断は、分解の粒度とは別の軸で、プランニングの採用条件側で整理しています。

業務知識がモデル側に無い案件で分解が破綻する典型的な2つの失敗例

本番で見る失敗は2型に集中します。ひとつは、社内固有の順序が分解に反映されない型です。与信の確認を見積提示より先に置く、稟議を通してから発注する。こうした順序は一般的な文書に書かれておらず、モデルが生成する分解では毎回抜けます。対処は分解の生成をやめることではなく、順序の制約を分解時の入力として明示し、検査で違反を落とすことです。

もうひとつは再現性の欠如です。同じ依頼から毎回違うサブタスク列が出ると、テストも監査も成立しません。分解の出力形式を固定し、例示を数件与え、生成の温度を下げる。それでも揺れる部分は、代表的なゴールに対する分解を保存して差分を見る運用へ寄せます。

受託開発でPoCから本番へ上げるとき分解へ課す3つの受入要件

PoCで動く分解を業務システムへ載せる段では、デモでは省かれる項目が要件になります。第一に、代表ゴール10件程度の分解を正解として保存し、モデル更新やプロンプト変更のたびに差分を検知する回帰テスト。第二に、分解を生成したプロンプト版とモデル版を出力へ紐づけて残す記録。第三に、人が確認する節目とサブタスクの境界を一致させることです。承認点が単位の途中に来ると、止める場所がありません。

どの業務をエージェントに任せるかという上流の判断はAIエージェントの導入判断にまとめています。分解の設計から検査層・監査ログまでを含めて外部に任せる場合は、AIエージェント開発で相談を受け付けています。

よくある質問

タスク分解の実装で実際に問われることの多い5点に答えます。

タスク分解とプランニングは何が違いますか？

タスク分解はゴールをサブタスクの列へ変換する1回の処理で、プランニングはその変換結果を状態として保持し、必要に応じて作り直しながら実行を進める工程です。分解は「何をどの順で」を決めるところまで、プランニングは計画をどのデータ型で持つか、いつ再計画するか、どこで打ち切るかまでを含みます。実装上は分解が上流、計画の保持と再計画が下流にあたります。両方を同じ層に押し込むと、分解の粒度基準が決まらないまま再計画の話に流れがちです。

サブタスクは何個くらいに分けるのが適切ですか？

個数から決めず、粒度の基準から決めます。完了を機械判定できること、失敗時にそのステップだけ再実行できること、次段へ渡す出力の型が定義できること。この3つを満たす最小単位が1サブタスクです。結果として末端が20件を超えるようなら分解しすぎで、失敗箇所の特定より分解結果の読解に時間がかかるようになります。階層を持たせる場合も2〜3層までにとどめ、それ以上は1つ上でまとめ直してください。

タスク分解はプロンプトだけで実装できますか？

生成はプロンプトだけでできますが、本番運用には検証層が要ります。出力を自然言語の箇条書きにすると、存在しないツールを指す分解や循環依存を含む分解を機械判定できません。HuggingGPTの記法のように id と dep を持つJSON列で受け取り、スキーマ検証を1枚挟む構成が扱いやすくなります。プロトタイプは箇条書きで始め、本番化の要件定義で構造化へ寄せる進め方が現実的です。

分解した結果が毎回変わるのはどう抑えますか？

出力形式の固定、例示の付与、生成温度の引き下げが基本の3手です。それでも揺れは残るため、代表的なゴール10件程度について正解となる分解を保存し、プロンプトやモデルを更新したときに差分を検知する回帰テストを併用します。加えて、順序や承認の制約は生成に任せず、分解時の入力として明示し、検査層で違反を落とす。再現性が要らない探索的な用途と、監査が要る業務用途で要求水準が変わります。

WBSのように人が分解したほうが速い場面はありますか？

業務手順が既にマニュアルとして文書化されている領域では、人が固定したほうが速く確実です。文書化された順序・分岐条件・承認フローをモデルに生成させると、例外処理や社内固有の順序が毎回落ちます。この場合はサブタスク列を人が定義し、モデルには各ステップ内の判断や文章生成だけを任せる構成にしてください。逆に、依頼内容が毎回異なり手順を事前に書き切れない業務では、実行時の分解に寄せる価値があります。

関連記事

• AIエージェントのプランニングとは：分解した計画をどの形式で保持し、いつ作り直し、どこで打ち切るかの設計を扱います。
• ReActパターンとは：分解を先に確定させず、1手ずつ考えて進める方式の仕組みと採用判断を解説しています。
• Agent SOPとは：モデルに分解させず、人が定めた標準作業手順で制御する対極のアプローチです。
• エージェントメモリとは：分解結果と完了済みサブタスクの出力をどこに保持するかの記憶設計をまとめています。
• AIエージェントとは：どの業務にエージェントを載せるかという導入判断の基準を発注者視点で解説しています。