RE:CZ

AIスケジューリングとタスク管理の最適化に関する考察

AIスケジューリング

👤 AI開発者、プロジェクトマネージャー、技術意思決定者、AIスケジューリングとタスク最適化に関心のある人々
本稿では、AIスケジューリングプロジェクトAgent Harnessが性能のスイートスポットに達し、現在の主要課題が精度向上から反復速度の最適化へ移行したことを論じる。著者は、タスクを基本単位に分割し、依存性管理を確立してタスクグラフを構築し、AIが依存関係に基づいてタスクを並列実行できるようにすることを提案する。OpenCodeセッションメカニズムを通じて、AIはタスクのブロック状態を自律的に判断し、タスクを分割して環境を改造し、効率的なスケジューリングを実現できる。AIトークンコストが低い背景において、AIの自然な成長を促し、人的レビューを減らしてプロジェクトの進捗を加速すべきだと強調する。
  • ✨ Agent Harnessは性能のスイートスポットに達し、反復速度が主要課題となっている
  • ✨ タスク分割と依存性管理に基づく並列実行戦略を提案
  • ✨ AIはタスクの依存性を自律的に判断し、タスクを分割して実行環境を改造できる
  • ✨ 人的レビューを減らし、AIの自然な成長を促して効率を向上させることを推奨
  • ✨ AIトークンコストが低い背景において、経済コストは当面問題ではない
📅 2026-04-11 · 2,006 文字 · 約 7 分で読めます
  • AIスケジューリング
  • タスク管理
  • 反復速度
  • 並列実行
  • OpenCode
  • Agent Harness
  • 依存性管理

現在は2026年4月11日、夜です。

本日、PolyMarketアービトラージプロジェクトが正式にファンド形式でローンチされました。コードネームはPathFinder、略称はPFです。初期段階ではPMAとも命名されていました。

本日、C1と、この期間における私のAIスケジューリングに関する所感について議論しました。

私は、Agent Harnessの現在のパフォーマンスはすでにスイートスポットに到達していると考えています:少数のインタビューを行うことで、AIは100%正確ではないものの、的外れでもない、まずまずの結果を生み出すことができます。

現時点でHarnessの改善にさらに注力した場合、タスクの達成精度は向上する可能性がありますが、その代償はますます大きくなるでしょう。

現在の私のワークフローは、通常30分程度のインタビューを行い、その後1〜2時間実行するというものです。1ラウンドの作業を完了するのに約2時間かかります。

私は気づきましたが、実はspecをそれほど細かく確認する必要はないかもしれません。これにより、インタビューの時間を大幅に節約できます。多くの場合、AIが推奨する方向に無批判に「はい、はい、はい」と同意するだけで十分なのです。

実際には、私が無理に詳細をAIに教え込むのではなく、AIが自然にそれらの詳細を発展させていくのを待つこともできます。

なぜ私がレビューする必要があると考えたのでしょうか?それはやはり、AIが道を外れることを恐れていたからです。私の時間は限られており、その日の進捗が芳しくない事態は受け入れられません。

もし私が方向性を示し、数分間「はい、はい、はい」と同意した後、さらに数分で全ての作業が完了するのであれば、レビューする必要は全くありません。その場合、AIに自然に成長させることを完全に任せる方が良いでしょう。

したがって、現在、Harnessはもはや主要な問題ではないと考えます。主要な問題は、反復速度です。現在のAIトークンは依然として非常に安価であるため、経済的コストは当面問題ではありません。

私は、プロジェクトはその最初のコミット(init commit)から始まり、そのorigin/mainのref上で、PRを通じて線形的に成長していくべきだと考えています。

OpenCodeの1セッションは、任意のorigin/mainから開始できます。タスクのコンテキストに基づいて新しいworktreeを作成し、タスクを実行し、統合テストを行い、完了後にPRを提出し、コンフリクトを解決し、origin/mainにマージし、worktreeをクリーンアップします。

このタスクは、AIが比較的うまくこなせるようになっています。

このタスクを、スケジューリングの基本単位としてみましょう。

私たちは、タスクを分割し、依存関係管理を構築し、タスクグラフを作成する必要があります。各タスクは、1つのOpenCodeセッションに紐づけて実行されます。

タスクは依存関係に基づいて、ブロッキング(依存あり)とノンブロッキング(依存なし)に分類されます。もちろん、この分類は概念的なものです。あるタスクと別のタスクの依存関係を100%確実に判断することは不可能です。

実際には、すべてのタスクを並列実行することは可能ですが、一部のタスクは、他の特定のタスクが完了してから実行した方が良い場合があります。この判断もAIに委ねられます(したがって、100%正確ではありません)。

さらに、表面上はブロッキングされているタスクでも、実際にはより小さなサブタスクに分割して並列実行できる場合があります。その中にはブロッキングなものもあれば、ノンブロッキングなものもあります。これらもすべてAIが判断します。

典型的な例は、フロントエンド、バックエンド、インターフェース設計を含む総合的な機能開発タスクです。これは、フロントエンド開発、バックエンド開発、インターフェース設計という3つのサブタスクに分割できます。フロントエンド開発とバックエンド開発は並行して進めることができ、どちらもインターフェース設計の完了に依存しています。したがって、インターフェース設計はノンブロッキングタスクであり、フロントエンド開発とバックエンド開発はブロッキングタスクです。

もう一つの見方は、本来ブロッキングされるべきタスクを誤って進めてしまうことは、従来のスケジューリングでは許容されませんが、AIスケジューリングでは許容される可能性があるということです。人間と同じように、AIはそのタスク上でスタンバイ状態を維持し、すべての依存タスクが完了するのを待つことができます。

AI自身がタスクを実行する過程で、環境が実行条件を満たしているかどうかをチェックすることもできます。条件を満たしていない場合、AIは環境を改造するための事前タスクを作成し、条件が満たされるまで続け、その後で本来のタスクを実行します。

したがって、トポロジカルソートがスケジューリングの核心であるというよりは、それは単なるヒューリスティックなツールに過ぎないと言えます。もし無限のAIトークンがあれば、無数のwork-treeをforkして、さまざまなタスク上でビジーにスパンさせることができ、AIは自分自身で判断するでしょう。