ゴール分解（Goal Decomposition）
ゴール分解（Goal Decomposition）では、エージェントが行動を起こす前に、高レベルのゴールを処理可能な小さなサブタスクの順序付きセット（計画）に分解します。その後、その計画を実行および監視し、ステップが失敗した場合には再計画を行います。明示的な計画は、レビュー、ゲート制御、デバッグが可能な「検査可能なアーティファクト」になります。このパターンは、ゴールに複数の依存ステップが必要であり、その場しのぎで一歩ずつ進むリアクティブなエージェントでは方向性を見失ったり失速したりする場合に使用します。単純なワンショットのタスクではスキップしてください。
課題
広範で複数ステップにわたるゴールを1回のLLM呼び出しに委ねると、その場しのぎの対応になりがちです。一度に1つのアクションを選択するリアクティブなエージェントは、長期的な展望において文脈を見失う傾向があります。同じ作業を繰り返したり、前提条件をスキップしたり、全体の目標がすでに達成不可能になっていることに気づかずに袋小路に入り込んだりします。計画がアーティファクトとして存在しないため、実行前に予定されているステップをレビューできず、失敗の原因が戦略の誤りなのか実行の誤りなのかを判断することもできず、中断後に簡単に再開することもできません。エージェントの推論は暗黙的かつ一時的であり、監査が困難です。
適用対象
このパターンは、意味のある順序を持つ、相互に依存する複数のステップに分解できるゴール（「調査してから統合する」、「移行してから検証する」、「収集してから照合し、報告する」など）に適しています。モデルがゴールと利用可能なツールから妥当な計画を作成でき、各ステップが失敗を検知できるほど十分に観察可能であることを前提としています。ステップのコストが高く、副作用があり、または取り消しが困難な場合に最も価値を発揮し、実行前に計画をレビューするメリットが大きくなります。現在の状態から次のアクションが明白である場合や、環境の変化が非常に速く、事前に立てた計画が2番目のステップに進む前に陳腐化してしまう場合には適していません。
解決策
エージェントを計画フェーズと実行フェーズに分割します。プランナーはゴール、利用可能なツール、および現在の状態を読み取り、明示的で順序付けられた計画（依存関係と期待される出力を伴うサブタスクのリストまたはグラフ）を出力します。計画を第一級のアーティファクトとして扱うことが核心的なアイデアです。これにより、ログへの記録、人間による承認のための提示、ポリシーに照らしたスコアリング、実行間での差分（diff）比較が可能になります。モデルが考案した脆弱な線形シーケンスを強制するのではなく、依存関係を明示的にエンコードすることで、独立したサブタスクを並行して実行し、依存関係のあるサブタスクは入力が揃うまで待機できるようにします。
次に、エグゼキューターが計画をステップバイステップで実行し、各ステップの結果を次のステップに送りながら、そのステップの期待される出力と照合します。ステップが失敗したとき、使用不可能な結果を返したとき、または下流の前提条件を無効にしたときは、盲目的に実行を続けるのではなく、制御をプランナーに戻して現在の状態から再計画を行います。このクローズドループこそが、堅牢な分解とワンショットの計画を分ける要素です。計画はゴールが許す限り浅く保ちます。深いツリー構造よりも、厳選された少数のステップを優先し、エージェントが無限ループに陥らないよう予算（バジェット）で再計画を制限し、些細なゴールは計画プロセスを完全にバイパスできるようにします。
コンポーネント
メリット
- 予定されているステップがその場しのぎで一つずつ決定されるのではなく、事前に決定されるため、長期的なゴールの一貫性が維持されます。
- 明示的な計画は検査可能です。副作用が発生する前に、レビュー、承認、監査、および差分比較を行うことができます。
- 失敗箇所の特定が容易になります。不適切な計画と、不適切なステップ実行を区別できます。
- 独立したサブタスクにより並行処理が可能になり、中断が発生した場合でも最後に完了したステップから作業を再開できます。
リスク
- 初期段階の分解に欠陥があるとそれが伝播します。下流のすべてのステップが、誤った前提条件や欠落した前提条件を引き継ぐことになります。
- 過剰な計画（オーバープランニング）は、リアクティブなエージェントなら1ステップで完了できるような単純なゴールにおいて、遅延とコストを増加させます。
- 変化の速い環境では計画が陳腐化し、古い世界の状態に基づいたままステップが実行されてしまう可能性があります。
- エージェントが実際の進捗を生まないまま計画を繰り返し書き換える、制限のない再計画ループが発生するリスクがあります。
非推奨のケース
- 現在の状態から次のアクションが明白であり、単一のリアクティブなステップでゴールを解決できる場合。
- 計画の有効性が維持されるよりも早く環境が変化し、事前のシーケンスが陳腐化してしまう場合。
- ステップが低コストで、取り消し可能であり、かつ独立しているため、計画に伴うオーバーヘッドがそのメリットを上回る場合。
テクノロジー
事例
- リサーチアシスタントが「情報源の収集」、「主張の抽出」、「クロスチェック」、「統合」を計画し、依存関係のある統合ステップの前に、情報源の収集を並行して実行します。
- コード移行エージェントが「使用状況のインベントリ作成」、「ファイルの変換」、「テストの実行」を計画し、テストステップで見落とされていたエッジケースが明らかになった際に、変換ステップを再計画します。
- データ照合エージェントが「決算」というゴールを「元帳の取得」、「正規化」、「エントリーの照合」、「例外のフラグ立て」に分解し、正規化の成功を条件として照合を実行します。
KPI
- ゴール達成率
- エンドツーエンドで完全に達成されたゴールの割合。同じ複数ステップのタスクにおいて、ゴール分解がリアクティブなベースラインを上回っている状態が良好とみなされます。
- 再計画の頻度
- 実行時に再計画がトリガーされる頻度。健全な範囲とは、すべてのステップで混乱（スラッシング）することなく、ループが実際の失敗を捉えている状態を指します。
- ゴールあたりのステップ数と最小ステップ数の比較
- 妥当な最小値に対する計画の長さ。単純なゴールにおいてステップ数を膨らませてしまう過剰な計画（オーバープランニング）に注意してください。
- 計画承認の合格率
- 実行前にレビュー担当者またはポリシーチェックによって承認された計画の割合。合格率が低い場合は、システム的に分解の精度が低いことを示しています。
観察された失敗パターン
- 不適切な分解の伝播：初期段階の誤った前提条件が、下流のすべての依存ステップを損なうこと。
- 再計画ループ：エージェントが収束や進捗を得られないまま、計画を繰り返し書き換えること。
- 陳腐化した計画の実行：計画作成後に変化した世界の状態に対してステップが実行されること。
- 過剰な分解：些細なゴールが必要のないステップに分割され、遅延、コスト、および障害発生領域が増加すること。
得られた教訓
- 計画を実際のアーティファクト（ログへの記録、表示、差分比較など）にすることで、失敗の原因を不可解なものにせず、デバッグ可能にします。
- 常にループを閉じます。盲目的に継続するのではなく、ステップの失敗を検知し、現在の状態から再計画を行います。
- 浅いゴールがスパイラルに陥るのを防ぐため、計画の深さと再計画の両方に明示的な予算（バジェット）を設定して制限します。
- 些細なゴールはプランナーをスキップできるようにします。分解は、真に複数ステップに及び、依存関係のある作業に限定して使用します。
FAQ
- リアクティブなReActスタイルのエージェントとはどのように違うのですか？
- リアクティブなエージェントは、計画をアーティファクトとして持たず、現在の状態から一度に1つのアクションを決定します。ゴール分解（Goal Decomposition）では、事前に順序付けられた計画を確定させるため、予定されているステップが検査可能になり、依存関係の順序が明示的になります。実際には、これら2つは組み合わせて使用されることが多く、最初に計画を立て、各ステップ内ではリアクティブに実行し、ステップが失敗したときに再計画を行います。
- 計画の途中でステップが失敗した場合はどうなりますか？
- 盲目的に継続するのではなく、制御をプランナーに戻して現在の状態から再計画を行います。このクローズドな再計画ループこそが、分解を堅牢にする要素です。継続的に失敗するステップが進捗のないまま無限に書き換えをトリガーしないよう、予算（バジェット）を設定して制限してください。
- 計画を立てることが、メリットよりもデメリットをもたらすのはどのような場合ですか？
- 次のアクションが明白な、単純な単一ステップのゴールや、計画の有効性が維持されるよりも早く変化する環境においてです。そのようなケースでは、事前の計画立案はレイテンシーを増大させ、計画が陳腐化するリスクを生みます。些細なゴールを検出し、プランナーをバイパスさせるようにして、分解（Decomposition）は真に複数ステップで依存関係のある作業にのみ残しておきます。