タスクの優先順位付け
エージェントの候補タスクを先入れ先出し（FIFO）で処理するのではなく、価値、緊急度、依存関係、およびコストに基づいて順序付けします。スコアリング関数と優先度付きキューが次に実行するタスクを決定するため、限られた計算リソース、予算、時間を最も重要な作業に割り当てることができます。状態の変化に応じて再スコアリングを行い、キューに上限を設けて無制限に肥大化するのを防ぎます。
課題
ゴールを分解するエージェントは、実行すべき検索、読み込むべきファイル、呼び出すべきツール、追求すべきサブゴールなど、一度に多くの候補タスクを抱えがちです。これらを到着順に処理すると、些細なクリーンアップステップが、期限付きのブロッキングタスクと同等に扱われてしまいます。重要な作業が低価値のノイズの後回しになり、依存関係が侵害され、状況が変わった後ではもはや重要ではないタスクに予算が費やされてしまいます。
適用対象
エージェントまたはオーケストレーターが、独立した、あるいは疎結合のタスクのバックログを保持しており、計算リソース、レート制限、コスト、または実時間の制約により、それらすべてを即座に実行できない場合に使用します。これは、1つのコンポーネントが次に実行するものを選択するプランナーやスーパーバイザーのアーキテクチャに適しています。各タスクにシグナル（影響度、期限、依存関係、コスト）を付与でき、新しい観測結果が得られるにつれて優先度がシフトする可能性があることを前提としています。
解決策
すべてのタスクに明示的なシグナルを付与します。これには、ゴールに対する期待される影響度、緊急度または期限、依存関係（最初に完了すべきもの）、およびトークン、費用、またはレイテンシにおける推定コストが含まれます。これらを、不透明なモデルの判断ではなく、透明で監査可能な関数を使用して単一のスコアに結合します。スコアリングされたタスクを優先度付きキューに投入し、最も価値の高い「準備完了（ready）」状態のタスクが次に実行されるようにします。常に依存関係を最優先してください。前提条件が満たされていないタスクは、スコアに関係なく「準備完了」とはみなされません。これにより、順序付けが正しく保たれ、無駄な再試行を防ぐことができます。
優先順位付けを動的に行います。各ステップの後、影響を受けるタスクを再スコアリングします。新しい結果によって影響度が変化し、期限が近づき、一部のタスクは不要になって破棄できるためです。エイジング（長時間待機しているタスクの優先度を徐々に上げる）や、下位層向けのキャパシティ確保によって、スターベーション（飢餓状態）を防ぎます。明示的な上限と受付ポリシーによってバックログを制限します。キューが満杯のときは、無制限に肥大化させるのではなく、最も優先度の低いタスクを拒否、マージ、または破棄（エビクト）します。スコアリングの重みを設定可能に保ち、各タスクが選択された理由をログに記録することで、動作の説明可能性を維持します。
コンポーネント
メリット
- 限られた計算リソース、予算、時間が、最初に到着したものにではなく、価値が高く時間的制約のある作業に費やされます。
- 前提条件を尊重することで、インプットが存在する前にタスクを実行することによる無駄な再試行や手戻りを回避できます。
- 再スコアリングにより、状況の進展に応じて、エージェントは関連性のなくなったタスクを破棄し、新たに緊急性の高まったタスクを昇格させることができます。
- コストを意識したスコアリングと上限付きキューにより、トークンとレイテンシのバジェットを、際限なく膨らむことなく管理下に置くことができます。
リスク
- 重み付けの誤りや不適切なコスト見積もりは、重要な作業をシステム的にスターベーション（飢餓状態）に陥らせたり、低価値のタスクを追いかけさせたりする可能性があります。数式の見直しとキャリブレーションが必要です。
- エイジングや予約されたキャパシティがないと、優先度の低いタスクが実行されず、必要なクリーンアップやバックグラウンド作業が永久に未完了のまま放置される可能性があります。
- 頻繁すぎる再スコアリングは、エージェントに絶え間ないフォーカスの切り替えを発生させ、コンテキストスイッチのコストを支払うだけで、何も完了できなくなる可能性があります。
- タスクの分解によって追加されるタスクのペースが完了ペースを上回る場合、上限のないバックログはメモリ、コスト、およびプランニングのレイテンシを膨張させます。
非推奨のケース
- 同様のタスクが数個しかない場合は、FIFOや単純な並列処理の方がシンプルであり、スコアリングのオーバーヘッドに見合う価値はありません。
- ドメインによって規定された固定の順序でタスクを実行する必要がある場合は、動的な優先度付きキューよりも、静的なワークフローやDAG（有向非巡回グラフ）の方が明確です。
- 予算と制限の範囲内ですべてを即座に実行できる場合、優先順位を付ける必要はなく、順序付けは不要な複雑さを招くだけです。
テクノロジー
事例
- 証拠を収集するエージェントは、未解決の疑問を解決する可能性が最も高い検索を優先し、主張が確認された後は冗長なクエリをスキップします。
- 運用エージェントは、影響範囲（ブラスト半径）と期限に基づいて修復ステップを順序付けし、影響の少ない警告よりも先に、顧客に影響する障害に対応します。
- パイプラインエージェントは、価値の高いドキュメントや期限の近いドキュメントを優先してスケジュールし、低コストの一括処理（バルク）アイテムを後回しにします。その際、エイジングによってバルクキューが永久に失速するのを防ぎます。
本番環境での実績
- コンテキスト
- 57日間にわたり観測された、シングルオペレーター、ローカルファーストのOpenClawデプロイメント（161セッション / 2,776ターン）。エージェント自身のトラジェクトリトレースから集計。
- シナリオ
- 自律エージェントがスケジュール（ハートビート + cron）に基づいて起動されます。毎正時のスタッガー（時間差起動）とハートビートのクールダウンがバックプレッシャーを提供し、ジョブが集中するのを防ぎます。
- テクノロジー
- CronServiceスケジューラー、heartbeat-runner、5分間の毎正時スタッガー、heartbeat-cooldown遅延ロジック、およびハートビート結果のlow/normal/high優先度フィールド。
- 負荷
- 57日間にわたる2,801回のハートビートターン + 57回のcronターン + 106回のユーザーターン（トリガーの約94%がハートビート）。
- 結果
- スケジューラーは1日あたり約50回の自律的な起動を維持し、スタッガーとクールダウンによって集中を防止しました。スケジュール起因の障害モードは発生しませんでした。シングルオペレーター、ローカルファーストのデプロイメント。
KPI
- 単位コストあたりに完了した重み付けタスク価値
- 取り組みが影響度の高い作業に向けられているかを捉えます。良好な状態とは、FIFOの基準値と比較して、トークンまたはドルあたりに提供されるゴール関連の価値がより多くなることです。
- 時間的制約のあるタスクにおける期限/SLA遵守率
- 緊急度シグナルが機能していることを示します。良好な状態とは、緊急タスクの大部分が期限前に完了することです。
- スターベーション指標（低優先度タスクの最大およびテール待ち時間）
- エイジングが効果的であるかを示します。良好な状態とは、最悪の場合の待ち時間が制限され、タスクが永久にスタックしないことです。
- キューの深さ対上限、および受付/破棄（エビクション）率
- バックログが制限内に収まっていることを確認します。良好な状態とは、キューの深さが上限未満に維持され、破棄が真に低価値のタスクのみに限定されていることです。
観察された失敗パターン
- 高優先度のタスクが、スケジュールされない低優先度の前提タスクを待機してしまう。リゾルバーはブロッキングタスクに緊急度を伝播させる必要があります。
- 一度計算されたきり更新されない優先度に基づいて、古い影響度や期限の情報で意思決定が行われてしまう。関連する状態の変化に応じて再スコアリングをトリガーする必要があります。
- タスクのコストを過小評価すると、そのタスクが予算を独占してしまいます。見積もりには、実際に測定された消費量からのフィードバックが必要です。
- 積極的な受付ポリシーによって、後から必要であることが判明するタスクを破棄してしまい、高コストな再検出を余儀なくされる。破棄（エビクション）は、真に冗長なアイテムを優先すべきです。
得られた教訓
- 次に何をすべきかに関する不透明なモデルの判断よりも、監査可能で設定可能な数式の方が、デバッグや調整が容易です。
- 前提条件の完了を個別の準備完了チェックとして扱うことで、高いスコアによってタスクがインプットよりも先に実行されるのを防ぎます。
- 最初からエイジングまたは予約されたキャパシティを追加してください。実行されない低優先度のバックグラウンド作業は、静かな正確性の欠如につながります。
- 明確な受け入れポリシーを伴う厳格な上限（ハードキャップ）を設定することは、タスク分解の暴走によるコストやレイテンシの膨張を防ぐ最もシンプルな防御策です。
FAQ
- これはゴールの分解とどう違うのですか？
- 分解はタスクを生成し、優先順位付けは生成されたタスクを実行する順序を決定します。これらは相互補完的です。分解がバックログを満たし、優先順位付けがそれを合理的に消化します。
- LLM自体が優先度をスコアリングすべきですか？
- 推定される影響度などのシグナルをLLMに提案させることは可能ですが、それらは透明で監査可能な関数と組み合わせるべきです。名前付きシグナルに基づく決定論的な数式は、単一の不透明なランキング呼び出しよりも、調整、ログ記録、そして信頼が容易になります。
- 低優先度のタスクがいつまでも実行されないのを防ぐにはどうすればよいですか？
- エイジング（経年処理）を使用して長時間待機しているタスクの優先度を徐々に上げるか、キャパシティの一部を低優先度層のために確保し、テールの待ち時間を監視してスターベーションが発生していないことを確認します。