論文解説: LoopArena — コーディングエージェントを「操縦する側」を測る

コーディングエージェントに指示を出し続ける『外側のループ』の良し悪しを、エージェント本体を固定したまま測るベンチマーク LoopArena を、前提知識ゼロから解説する。最良でも完全タスク成功率24.69%という結果の読み方まで。

LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering

「ループを回す側」は、測られていなかった

コーディングエージェントに長い仕事を任せると、人間の役割は「コードを書く人」から「様子を見て次に何をさせるか決める人」へ移ります。テストを走らせるのか、実装を続けさせるのか、もう提出していいのか。この判断を毎回手で書く代わりに、監視・割り当て・検査・継続判断を自動で回す設計にする——この実践が Loop Engineering と呼ばれ始めています。

困るのは評価です。1回の実行が成功したとき、それは指示を出した側が賢かったからなのか、コードを書いた側が優秀だったからなのか、最終結果だけからは切り分けられません。

本記事が扱う論文の原題は LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering（arXiv:2608.28281、2026年8月28日公開、DreamX Team／Alibaba Group ほか）です。

アブストラクトを要約すると、こうなります。ループは古い進捗メモを信じたり、必要な検証を飛ばしたり、予算を誤った方向に使ったり、まだ安全でないのに停止したりしうる。しかし1回のエンドツーエンド実行の最終結果からは、成否がループの誘導によるものかエージェントの遂行能力によるものかを判別できない。そこで著者らは LoopArena を提案する。評価対象のモデルは Controller で、各コーディングラウンドの後に実行の構造化サマリを受け取り、固定された別のコーディングエージェント Worker に次に何をするか／何を検証するかを指示するか、停止を決める。実行スコープとコストの異なる3設定で評価し、完全タスクでの最良の Strict Success Rate は 24.69% にとどまった。Controller 間の推定推論コストの対応削減率は平均 64.4%、Type II は主要な Core 基準のもとで Type III と近い順位を与えた（Spearman の $\rho = 0.9747$）。ベンチマークデータと評価コードは公開されている。

比喩: 道具を持たない現場監督

工事現場を想像してください。職人（Worker）は道具を持ち、実際に壁を塗り、配管を通します。現場監督（Controller）は道具を一切持ちません。監督にできるのは「次はここをやってくれ」「その配管、水を通して漏れがないか確かめてくれ」「もう引き渡していい」と言葉で指示することだけです。

しかも監督は現場を直接見ていません。見ているのは第三者の報告係（Reporter）が書いた報告書だけです。報告書に書かれるのは「何を頼まれていたか」「何をやって今どうなっているか」「どんな検査をして何が分かったか」「まだ分からないこと・残っている問題」の4つで、次に何をすべきかは書かれません。次の一手を決めるのは監督の仕事だからです。

LoopArena が測るのは、この監督だけです。職人も道具も工期も評価基準も全部固定して、監督のモデルだけを差し替えたときに完成率がどう変わるかを見ます(§1)。だから「エージェントが賢いのか、指示が賢いのか」を切り分けられます。

3つの役: Worker / Reporter / Controller

Worker は唯一コーディングツールを使える存在です。割り当てられた区間の中で自分の ReAct ループに従い、リポジトリを調べ、書き換え、チェックを走らせます。会話履歴は実行を通じて永続します(§2.2)。

Reporter は各ラウンドの区切りで、Worker の会話履歴のコピーから一時的に生成されます。Worker と同じモデル構成で、読み取り専用ツールでしかワークスペースを見られません。書くのは4フィールド、task_context_and_constraints / work_history_and_current_state / verification_and_evidence / open_issues_and_uncertainty です。重要な主張には Worker の該当ターンを [E12] のように引用します。Reporter は現状を述べるだけで、次に何をすべきかは決めません(Appendix 11.1)。

Controller が評価対象です。ハーネスが Reporter の報告と引用ターンを決定論的に整形した Evidence Packet を読み、次の指示書にあたる Loop Contract を返します。リポジトリにもツールにも触れず、送る指示だけを通じてしかタスクに影響できません。

この構造がなぜ効くかは、実行の長さを見ると分かります。論文の測定では、1回の完全タスク実行で Worker の ReAct ターンは平均 139.81〜288.90 回、制御サイクルは 8.60〜13.46 回に達します(Table 1)。判断を間違える機会がそれだけ積み上がる、ということです。

制御サイクルを式とコードで

タスク $i$ の制御サイクル $k$ で Controller が返す Loop Contract は、こう書けます(§2.2)。

$\pi$ が Controller モデル、$x_{i,k}$ がその時点の Evidence Packet、$h_{i,k}$ がその判断より前の会話履歴（過去の Packet と Contract）、$c_{i,k}$ が出力される Contract です。要するに「いまの報告書とこれまでの経緯を読んで、次の指示書を1枚書く」だけの関数です。

Contract は action が advance（前進）／verify（検証）／stop（停止）と rationale（理由）。前進・検証ならさらに worker_instruction（goal / context / required_outcomes / prohibited_actions / completion_condition）、protected_invariants、verification_acceptance_condition を返します(Appendix 11.1)。ハーネスは Contract を検証し、継続なら追加のモデル呼び出しなしで次の Worker ターンとして描画し、停止なら現在のワークスペースを評価器に提出します。

while True:
    worker.run_segment()                    # 職人が働く（唯一ツールを持つ）
    report = Reporter(copy(worker.history)) # 報告係が4項目の報告を書く
    packet = format_packet(report, cited_turns, budget)
    contract = controller(packet, history)  # 評価対象はここだけ
    if contract.action == "stop":
        return evaluator(workspace)
    worker.push(render(contract))           # 契約を次の指示に変換