計画と実行をつなぐ作業を、三回に分けてやった

01

計画はあるのに、実行とつながっていなかった

Agent Taskには最初から二つの記録がありました。モデルが立てた計画と、実際に何をしたかが残る実行ログです。問題は、その二つが互いを指していないことでした。計画の二番目の段階がツールを何回使ったのか、計画と実行がどれだけずれたのかを尋ねる方法がありませんでした。

ロードマップは次の段階としてExecution Graphを挙げます。ノードごとに依存関係、必要な権限、コスト上限、再試行方針、完了条件を自分で持つDAGです。しかしそうしたノードを設計するには、まずノードに何を付けるべきかを知る必要があり、それは実測なしには分かりません。そこでグラフを建てる前に、付ける場所のほうを先に作ることにしました。

02

まず、そのターンが何をしようとしたかを残した

1.21.0で、各ターンがどのツールを呼ぼうとしたかをステップとして永続化しました。同じリリースで、一時的なLLMエラーに対する指数バックオフの再試行と、承認要求が繰り返し無応答のときに承認必須ツールを外す降格も、それぞれステップとして残すようにしました。

狙いは単純です。再試行と降格が実際にどれだけ発動するのかを、ログを掘らずデータベースから直接数えることです。あとでノードごとの再試行方針を決めるときの根拠になる数字を、先に積んでおく形です。

03

分からないなら空のままにする

1.22.0のマイグレーション088が、実行ステップのテーブルに計画段階のインデックスをnullableな列として追加しました。ステップを記録する時点で進行中の計画段階のインデックスを決定的に刻みます。ここにモデルの判断は一度も入りません。

最も重要な選択は、何をしないかでした。進行中の段階が無ければ、最初の未完了段階で当てにいかず、そのまま空にします。この列の目的は計画と実行がどれだけ一致するかを測ることなので、分からない値を作ってしまえば計測そのものが無意味になるからです。

• 紐づける対象: アシスタントの応答、計画ステップ、ツール結果、再試行
• 意図的に空にする対象: 仕上げのターン、承認降格、ユーザーの介入、コード差分など、特定の段階に属するとは言いにくい管理イベント
• 既存の行には影響がなく、同じマイグレーションを何度実行しても結果は変わりません

04

最初の実測は45%、原因はコードではなかった

溜まったデータを遡って測ると、厳しい基準での紐づけ率は45%前後でした。半分弱のステップだけが、どの段階から出たかを言えるということです。

原因を分けるとコード側の問題ではありませんでした。40%は、モデルが計画を更新する際に進行中の印をまったく残さなかったケースです。明示的にそうするよう指示しても、二段階目で印が落ちることをライブで再現しました。

ここで分岐が生まれます。プロンプトでマーキングをより強く促すのか、コードで補正するのか。プロンプトに手を入れると他の動作まで揺れる恐れがあるため、その判断は前向きのデータが溜まるまで先送りしました。

副産物もありました。ノード一つがツールを何回呼ぶかの分布が出て、中央値は4回、最大は26回でした。この分布が、のちにノードごとのコスト上限を決める根拠になります。

05

モデルを説得する代わりに、決定的に補正した

増分3はプロンプトをそのままにして、コードで空白を埋めます。計画を作った直後と、ある段階が完了または停止した後に、進行中の段階が一つも無ければ最初の未着手段階を進行中へ繰り上げます。線形の実行を前提にした決定的な規則で、ここにもモデルの判断はありません。

ただしモデルが言ったことは尊重します。すでに進行中の段階があれば何もせず、モデルが明示的に未着手へ戻した段階は再び繰り上げません。この自動補正は環境変数で切ることができ、既定では有効で、六件のテストがこの規則を守っています。

06

画面に出ない計測は検証されない

最後に、作業詳細のタイムラインで各ステップがどの段階に属するかをバッジで表示しました。バックエンドには手を入れていません。ステップの応答にはすでに列が入っていたため画面で読むだけでよく、4ロケールにキーを一つ追加しました。

計測を画面に出したのは見栄えのためではありません。目で見えて初めて、間違っていることに気づけるからです。そして実際、その直後に気づきました。

07

計測そのものに死角があった

同じ流れで、ツール結果がどれだけ切り詰められるかを測る計測を入れました。直す前にまず測る、という原則です。ところがチャットからPDF作業へ自動委任される経路をブラウザーで点検していて、サンドボックス作業ではこの計測が一件も記録していないことが判明しました。

原因は経路でした。サンドボックスのツールはターン実行器を通らず別の実行経路を辿るのに、計測をそのツールが通らない場所へ付けていたのです。実測ではツール結果のステップが2件残っているのに、記録の試行は0件でした。

1.22.1で、結果が実際に切られる地点へ計測を移し、そこに埋まっていたマジックナンバーを既存の環境変数へ統一しました。まず測って後で直すという原則は、計測が正しい場所にあるときだけ成り立ちます。

08

次にやること

いまあるのは、ステップを計画ノードへ紐づける計測と、進捗の印が欠けたときの決定的な補正、そしてその結果を見せる画面です。まだ無いのは、ノードが自分の依存関係、必要な権限、コスト上限、再試行方針、完了条件を自ら持つ永続的なDAGです。

次の判断の根拠は数字です。自動補正を入れたあと45%が前向きのデータでどこまで上がるのか、そしてノードあたりのツール呼び出し分布の裾がどこで切れるのか。それが、ノードに付けるコスト上限と完了条件の最初の候補になります。