論文解説: LongHorizon-Harness — 長時間タスクは「実行」ではなく「状態管理」で解く

モデルを一切変えずに、タスク状態を実行の外に置き「管理→実行→監査」のループで回すだけで、長時間タスクの成績が大きく伸びる——Alibaba DreamXチームのハーネス設計論文を、比喩と擬似コードで1から解説する。

LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks

徹夜で全部やる新人と、台帳を持つチーム

数時間かかる仕事をAIエージェントに任せると、序盤は順調なのに終盤で崩れる。本稿で扱う論文 LongHorizon-Harness（Alibaba DreamXチーム、arXiv:2608.01964）の主張はシンプルです。崩れる原因はモデルの賢さ不足だけではなく、仕事の「回し方」にある。モデルには一切手を加えず、外側の枠組み（ハーネス）を変えるだけで、コンピュータ操作ベンチマーク WeaveBench の合格率が 51.8% から 80.7% まで伸びたと報告しています（§3.2）。

まず比喩から。従来のエージェントは「徹夜で全部やる新人」です。1つの会話（コンテキスト）の中で、計画も、作業も、メモも、「終わったかどうか」の判断も全部やる。疲れた頭で「たぶん終わった」と自己申告して次に進み、一度の思い込みが以後の全判断の前提に混ざり込みます。

LongHorizon-Harness はこれをチーム制に変えます。ホワイトボード（タスク台帳）を管理する進行役、毎回まっさらな頭で1つの作業だけをする作業者、成果物を現物で確かめる読み取り専用の検収係。作業者の「終わりました」は台帳に直接書かれません。検収係が環境そのものを見て確認した事実だけが、台帳に残る。この一点が論文の核心です。

長いタスクはなぜ崩れるのか

論文は長時間実行の難しさを3つに整理します（§1）。第一に誤りの複利とゴールずれ。初期の小さな誤りが後続の判断を歪め、軌道が元の目的から少しずつ逸れていく。第二にコンテキスト腐敗（context rot）。履歴が伸びるほど必要な情報を取り出しにくくなり、コンテキスト使用率がある閾値を超えると性能が急落する。第三にタスク状態の喪失。「何が要件で、何が済んでいて、何が判明したか」という現在地を、エージェントは保ち続けられない。

そのうえで論文は、Claude Code や Codex CLI のような既存ハーネスに残る構造的な限界を2つ指摘します（§1）。(i) タスクの実行と状態管理が、同じ「伸び続けるコンテキスト」に同居している。(ii) 実行と完了判定が結合していて、誤った自己評価がそのまま状態として記録され、後続の判断の前提になる。計画機能もサブエージェントも既にあるのに長時間で崩れるのは、この2つが温存されているから——というのが問題設定です。

発想の転換: 状態管理問題として定式化し直す

論文の再定式化はこうです（§2.1）。長時間実行とは1本の長い会話ではなく、独立に監査された状態遷移の列である。タスク状態は実行の外に明示的なレコードとして持ち、環境から独立に検証された事実だけで更新する。ラウンドをまたいで残るのはタスク状態と監査報告だけで、作業者の生の対話履歴は毎ラウンド捨てます。

MEAループ: 管理→実行→監査

この原則の実装が Manage-Execute-Audit（MEA）ループです。ラウンド $i$ 開始時のタスク状態を $S_i$、これまでの監査報告の列を $V_i$ とすると、進行役（マネージャ）の仕事は1本の式で書けます（§2.2）。

言い換えると——元のタスク $\mathcal{T}$ と、現在の台帳 $S_i$ と、検収済み報告の束 $V_i$ だけを見て、更新後の台帳 $S_{i+1}$、次の一手 $q_{i+1}$（実行execute／完了done／手詰まりblocked／ユーザーへ質問ask の4択）、次の作業指示書 $c_{i+1}$ を決める関数です。マネージャは環境に一切触れられません。画面も見られず、コマンドも打てない。台帳と証拠だけで判断する役です。