「完了」と言われただけでは完了ではない：長期タスク Agent のマイルストーン設計

これは長期タスク Agent 設計ノートの第二回である。きっかけは BEACON（浙江大学、arXiv:2605.06078）の精読だった。

第一回の結論は、ループ検知では停滞を捕まえられない、というものだった。繰り返しは入力側の信号であり、進捗は出力側で見るしかないからだ。ただしその結論が成り立つには、進捗を測る「基準となる何か」が必要になる。今回はその何かの話である。

まず問いを正しく立てる

問うべきは「Agent はどうやって自分がステップを終えたと知るのか」ではない。「システムはどうやって、本当に終わったのか、それとも終わったと申告しただけなのかを知るのか」である。

違いは一層だけだが、信頼性はまったく別物になる。

二つの半分はすでにあり、つながっていなかった

自社の実装を読み返して意外だったのがここだ。

一つ目の半分。マイルストーン自体はすでにプロダクトにある。永続的なタスク計画を保持するツールがあり、長いタスクがどう分解され、各ステップが未着手・進行中・完了・ブロック中のどれなのかを記録している。設計意図は、長いタスクに安定した進捗のアンカーを与えることだ。ではステップはどうやって「完了」になるのか。モデルが自分でそう宣言する。

二つ目の半分。ツール呼び出しのたびに、ホスト側は決定的な事実を記録している。ファイルの内容ハッシュが実際に変わったか、コマンドの終了コードは何か、タイムアウトしたか。これらはホスト側に記録され、モデルのコンテキストには入らない。だからこそ捏造できない。

断絶はここにある。一方には「終わりました」があり、他方には「あるファイルのハッシュが A から B に変わった」がある。この二つが並べられたことは一度もなかった。

足りないのはデータ構造でも観測データでもない。両者を架ける橋である。

論文で一番役に立つのは、あの数式ではない

BEACON は二重スケールの advantage で知られているが、本当に持ち帰る価値があるのは、検出器 Φ をどこに置いているかだ。

Φ には学習済みモデルも人手のアノテーションも要らない。環境フィードバックから観測できる状態変化だけを読む。ALFWorld では物体の状態遷移（掴めた、加熱が完了した）、WebShop ではページ遷移、ScienceWorld では環境がもともと出しているサブゴール信号をそのまま使う。

追加モデルはゼロ、追加サンプリングコストもゼロ。他の二つと比べてほしい。プロセス報酬モデルは高価なアノテーションを要し、スコアを操作される余地もある。モンテカルロ価値推定は決定点ごとに追加の rollout を回す必要がある。Φ が回避しているのはこのコストだ。

そして Agent プロダクトを作る側には、論文の環境にはない有利さがある。ツール呼び出しはそもそも構造化されていて、成功と失敗が明示的に返る。論文は環境から信号を掘り出す必要があったが、こちらの信号は最初からそこにある。

実装するなら三層に分ける

第一層：決定的な証拠を一本のストリームにまとめる。意味的な判断は一切しない。不可逆で検証可能な変化を機械的に記録するだけだ。ファイルの内容ハッシュが変わった。コマンドの終了コードがゼロだった。外部 API 呼び出しが成功を返した。データが書き込まれた。これらは今も存在するが、あちこちに散らばっていて、「これまでに確定した事実」という一本にまとめられたことがない。

第二層：二つの半分をつなぐ。最も費用対効果が高いステップだ。モデルがステップの完了を宣言したとき、それを無条件に信じるのをやめ、その区間に第一層の証拠があるかを確認する。証拠があれば検証済み完了、なければ宣言のみの完了と印をつける。モデルの宣言を止めるわけではない。裏付けのあるものとないものを分けるだけだ。

第三層：能力タイプごとに Φ を定義する。著者自身が、Φ はドメイン知識を要し汎化しにくいと認めている。万能の検出器を期待してはいけない。コーディング系はテストの終了コードを見る。データ分析系は出力ファイルが生成されたかを見る。メッセージ送信系は API のレスポンスを見る。この層は能力を一つずつ、ゆっくり広げていくしかない。

自分たちで足した判定基準：重要度ではなく不可逆性を見る

これは論文にはない。

BEACON のマイルストーンが効くのは、それが後戻りできない状態遷移を刻んでいるからだ。鍵を手に入れたら世界は変わる。だから基準はその行動が不可逆な外部副作用を生んだかであるべきで、そのステップが重要だったかではない。

不可逆：ファイル書き込み、コードのコミット、メッセージ送信、有料 API の呼び出し、データベースへの確定。可逆：ファイル読み込み、検索、ページ取得、思考。

これには二つの利点がある。機械的に判定できること。行動の種類だけで決まるので意味理解は要らず、「モデルがこのステップを重要だと思った」という主観が紛れ込まない。もう一つは、復旧ポイントと最初から一致していること。不可逆な境界から再開することだけに意味があり、可逆な行動はやり直せば済む。

論文の二つの数字。一つは背中を押し、一つは釘を刺す

背中を押すのは劣化実験だ。マイルストーンを半分ランダムに落としても 82.8 を保ち、ベースライン 72.8 を 10 ポイント上回る。劣化は滑らかで、崖ではない。実装する側にとってここが肝心で、Φ を完璧に設計し終えるまで導入を待つ必要はない。半分カバーできれば、その時点で得がある。

釘を刺すのは分割の比較だ。

第一回でもこの数字を引いたが、ここでの含意はもっと直接的だ。マイルストーンを勘で置いたなら、それはほぼランダム分割であり、労力は無駄になる。マイルストーンに価値があるのは、それがタスクの実際の構造と一致しているときだけだ。

割り引くべきところ

論文自身が付録で「マイルストーンの自動発見」を未解決問題として挙げている。三つのベンチマークのマイルストーンはすべてルールで得られたものだ。環境応答のパターンマッチ、ページ遷移、あるいは環境が直接渡してくる信号。ブラウザ操作、コードベースの改修、ディープリサーチのような本当にオープンな場面には、そんな出来合いの検証可能な遷移は存在しない。

つまりあれは構造化環境の中で検証されたパラダイムであって、そのまま持ち出せる解ではない。Agent プロダクトで成立させられるのは、ツール呼び出しという構造化された境界のおかげであり、論文が答えを用意してくれたからではない。

もう一つの罠は粒度だ。粗すぎれば何もしていないのと同じ、細かすぎればセグメント信号がノイズになる。プロダクトで言えばタスク分解の粒度にあたるが、ここには論文の環境にはない便利さがある。計画の各ステップはもともとユーザーに見せるものなので、粒度を「人がこのステップを理解できるか」で決められる。純粋にアルゴリズムで調整する必要がない。

一つだけやるなら

第二層をやる。

安い。第一層のデータはすでにあり、第二層はそれをモデルの宣言と突き合わせるだけだからだ。独立に検証できる。「検証済み」と「宣言のみ」の比率そのものが見る価値のある指標になるからだ。そして後続すべての前提でもある。検証済みマイルストーンという概念がなければ、第一回の停滞検知も、次回の圧縮境界も、立つ足場がない。

もう一つ気持ちのいい性質がある。導入しても挙動は何も変わらない。モデルはこれまで通り宣言し、印が一つ増えるだけだ。データが溜まってから、証拠のない宣言に介入するかどうかを決めればいい。

次回はコンテキスト圧縮を扱う。token 閾値で切ることが「何を忘れてよいか」とほとんど関係がない理由、そして今回の内容を最も自然に延長したときに出てくる思い込み、つまり「マイルストーンが検証されたなら、その手前は丸ごと畳んでよい」への訂正である。