2026-08-13·無料·論文·10分で読めます

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

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

要点

LongHorizon-Harness は、モデルを変えず外側の枠組み(ハーネス)だけで長時間タスクの崩れを防ぐ手法である。
進行役・作業者・読み取り専用の検収係に分け、検収係が環境で確認した事実だけを台帳に残す。
Manage-Execute-Audit(MEA)ループで、作業者は毎ラウンドまっさらなコンテキストで起動される。
WeaveBench の合格率は 51.8% から 80.7% に、OSWorld 2.0 の完全達成率は 2.8% から 8.3% に伸びた。
監査がトークンの19〜38%を占め、視覚精度や数学など単発のモデル能力が壁のタスクでは効果が薄い。

#agents #llm #long-horizon #harness #computer-use #paper

対象textタスクagents

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

一次資料 — この記事の根拠

論文の発表 2026-08-03→この解説の公開 2026-08-13同月

LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World TasksZiyu Ma, Hailang Huang, Shun Zou ほか · 2026-08-03 · v1arXiv:2608.01964論文ページ·PDF

原文の要旨（Abstract）を読む

Large language model (LLM) agents increasingly undertake long-horizon tasks that require sustained reasoning, tool use, and revision across many interdependent steps. However, existing agent harnesses maintain task execution, task state, and completion assessment within a growing context, making the state difficult to track and allowing incorrect self-assessments to propagate into later decisions. We reformulate long-horizon execution as a task-state management problem and propose LongHorizon-Harness, which maintains the task state explicitly outside execution and updates it only with facts independently verified from the environment. Its Manage-Execute-Audit(MEA) loop uses a manager to maintain the task state and determine the next subtask, a fresh-context executor to perform it, and a read-only auditor to verify the resulting environment state before the next round. A lightweight AgentAdapter supports interchangeable model and harness backends without modifying their native agent loops. LongHorizon-Harness improves Qwen~3.7-Plus from 51.8% to 80.7% on WeaveBench, from 69.7% to 77.2% on Terminal-Bench~2.1, and from 2.8% to 8.3% on OSWorld~2.0. It also raises Claude Opus~4.7 from 20.0% to 34.3% on an OSWorld2.0 subset, demonstrating consistent gains across models, harnesses, and interaction domains.

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

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

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

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

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

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

FIG 1横軸をタスクのステップ数と読み替えてみてください。影響が線形にしか積もらない仕事と、複利で膨らむ仕事の差は、ステップ数が増えるほど「桁」になります。長時間タスクの怖さはこの立ち上がりにあります

そのうえで論文は、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）。

(S_{i+1},\; q_{i+1},\; c_{i+1}) = \Phi_{\mathrm{mgr}}\left(\mathcal{T},\, S_i,\, V_i\right)

(1)

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

台帳には要件・成果物・事実の3種のレコードが入り、それぞれ completed / pending / blocked / untrusted のステータスを持ちます。completed にできるのは、クリーンな監査証拠が支持するときだけ（§2.2）。

作業者（エグゼキュータ）は環境を変更できる唯一の役です（§2.3）。毎ラウンドまっさらなコンテキストで起動され、渡されるのは元タスク・現在の台帳・作業指示書（ゴール、受け入れ基準、境界条件、参照すべき監査報告）だけ。GUI係とCLI係に分かれ、割り当てられた道具しか使えません。中身は Claude Code や Codex CLI そのもので、AgentAdapter という薄い層が、内部ループを改造せずに「文脈・道具・権限・予算」だけを外から与えます。

検収係（オーディタ）は読み取り専用です（§2.4）。作業者の報告はヒントに使えますが、完了判定は環境を自分で調べた証拠で行います。報告は完了状態（complete / incomplete / blocked）と整合性状態（clean / suspect / violation）を持ち、監査中に保護対象への変更が検知されると整合性違反となり、その監査は completed の根拠にできません。「現物を書き換えた検収書は無効」というルールまで機構化されています。

FIG 2動的計画法の表も、生の計算過程は持ち回らず「検証済みの部分結果」だけを表に残して次の部分問題を解きます。実行履歴を捨てて監査済みタスク状態だけを引き継ぐMEAループと同じ発想です

ループ全体を擬似コードにすると、これだけです。

state = init_state(task)              # 要件を pending で台帳に登録
for round in range(25):               # 最大25ラウンド (§3.1)
    decision, contract = manager(task, state, audits)
    if decision != "execute": break   # done / blocked / ask で終了
    report = executor(contract)       # 毎回まっさらな文脈・1800秒まで
    audit  = auditor(contract, report, env)  # 読み取り専用・300秒まで
    audits.append(audit)
    state = update(state, audit)      # 検証済みの事実だけを反映

実験: 3つのベンチマークで一貫して伸びる

評価は、GUIとCLIの併用が要る WeaveBench（114タスク）、人間でも中央値約1.6時間かかる OSWorld 2.0（108タスク）、コマンドライン難タスク集 Terminal-Bench 2.1 の3つ（§3.1）。

同じ Qwen 3.7-Plus・同じ Claude Code 実行系で条件を揃えた比較では、WeaveBench の合格率が 51.8% → 80.7%、8ドメインすべてが改善（§3.2, Table 1）。OSWorld 2.0 は完全達成率 2.8% → 8.3%（3倍）、Terminal-Bench 2.1 は 69.7% → 77.2%。Claude Opus 4.7 でも34タスク部分集合で 20.6% → 35.3% と伸びており（Table 3）、「弱いモデルの穴埋め」ではなく強いモデルにも上乗せされる効果だと論文は主張します。

何が効いて、どこにコストがかかるのか

トークン消費の内訳が示唆的です（§3.3, Fig. 5）。マネージャの消費は全体の2〜8%にすぎず、状態管理はほぼタダ。追加投資の本体は監査で19〜38%を占めます。総コストは固定倍率にならず、WeaveBench で2.3倍、OSWorld で出力3.6倍になる一方、Terminal-Bench 2.1 では24%減で成績が上がりました。

最も印象的なのは WeaveBench の Games 17タスクです（Table 4）。LongHorizon-Harness を着けた Qwen 3.7-Plus の平均スコア 0.733 は、素の Claude Code を使う Claude Opus 4.7 の 0.680 を上回りました。トークンは Opus では 16.5M → 11.1M と減り、Qwen では 10.7M → 34.3M と増える。ここから論文は「エージェント能力はモデル単体ではなく、モデル×ハーネスというシステムの性質だ」と結論づけます。

効き方はタスク依存です（§3.3）。伸びるのは進捗を「検証可能な環境状態」で表せるタスクで、Terminal-Bench のシステム管理は 0.593 → 0.889。逆に視覚精度や数学など単発のモデル能力がボトルネックだと効果は薄く、data-science（0.792 → 0.667）のように退行するカテゴリもあります。監査は誤りを検知して回復を促せても、モデルにない能力は足せません。

ケーススタディも雄弁です（§3.4）。素の Claude Code は、Wireshark の反応しないダイアログに同じ操作を400ステップ以上繰り返して 0.59 で終了。LongHorizon-Harness は失敗と未収集の証拠を台帳に外部化し、次の作業者が未解決分に直行して 0.92。文書タスクでは、XML直編集で「見た目だけ正しい」結果を作った素の実行が 0.00、監査がXMLレベルで15見出しの様式を確認した本手法が 0.89 でした。

限界と、数字の読み方の注意

論文自身が明記する注意点があります。WeaveBench の自前実行はVM内で root 権限を使い、一般ユーザー権限の公式結果とは条件が揃っていないため、公式スコアとの比較は参考値です（Table 1注記）。OSWorld 2.0 でも本手法は GUI+CLI のハイブリッド道具立てで動き、GUI操作のみの公式ベースラインとは条件が異なります（§A.2）。Terminal-Bench の自前実行は予算の都合で3構成のみです（§3.2）。

原理的な限界も付録にあります（§B.2.3）。正解条件が隠れ閾値や評価慣習に依存するタスクでは、契約を読み違えたまま監査が通る——論文の言葉で「自信を持って検証された誤答」が起きえます。また弱いモデルでは消費が跳ねる構成があり（OSWorld で出力トークン 28.9K → 104K）、無条件に安くなる仕組みではありません。

現場ではこう使う

エージェント製品の開発者や、Claude Code / Codex CLI で長時間ジョブを回す人が、今日から輸入できる設計原則です。

実行役と検証役のサブエージェントを分ける。検証役には Read / Grep など読み取り専用ツールだけを許可し（ツールのallowlist設定）、書き込み権限を渡さない。
進捗は「自己申告」でなく「環境の事実」で記録する。TODOや計画ファイルを更新してよいのは、テスト結果・ファイル実体・ログを確認した後だけ、という運用規則にする。
予算を役ごとに切る。論文の設定は実行1800秒・管理/監査300秒・最大25ラウンド（§3.1）。上限があると、失敗ループの暴走が「上限で止まって台帳が残る」失敗に変わります。

事故になる落とし穴は3つ。①実行エージェントの「完了しました」をそのまま進捗として記録する（0.00になった文書タスクがまさにこれ）。②検証役に書き込み権限を渡す（検証中に環境を壊しても気づけない）。③監査コストを見込まず短いタスクにまで導入する（監査だけでトークンの19〜38%。効果は長時間・多依存のタスクに集中します）。

LLMエージェント入門 — ツール使用とループの基本形から
KVキャッシュを理解する — 「コンテキストが伸びると何が高くつくか」の仕組み側
論文解説: SWE-Bench ProMax — エージェント評価ベンチマークの設計を深掘り