- はじめに — 静的ベンチマークが終わるところで
- 何が新しいのか — ライブコンテナとステップ単位のチェックポイント
- 閉ループ — 実行者、隠れた監督者、ユーザーエージェント
- モデルとスキャフォールドを切り分ける — 5 つの能力
- おわりに
- 参考資料
はじめに — 静的ベンチマークが終わるところで
以前の コーディング評価で信号とノイズを見分ける記事 では、最も広く使われるコーディングベンチマークが汚染と採点上の欠陥で揺らいでいることを扱いました。あらかじめ記録された正解と照合する静的な方式は、暗記とハーネスの差に弱いのです。すると問いは裏返ります — 道具を自ら操作する エージェント のためのベンチマークは、いったいどう作られるべきなのでしょうか。
HKU MMLab が 2026 年 7 月 9 日に arXiv へ投稿した UniClawBench は、その問いに対する具体的な一つの答えです。副題は「実世界タスクにおけるプロアクティブエージェントのための汎用ベンチマーク」です。ここでプロアクティブエージェントとは、日常的な道具を直接操作しながら実環境でユーザーを助けるエージェントを指します。
著者が挙げる既存ベンチマークの限界は 3 つです。第一に、多くは サンドボックス環境 に依存します。第二に、 単一ターン 評価であり、対話的な補助作業の実際の流れを捉えられません。第三に、シナリオ基準のタスク分類が 複数の能力を一つのカテゴリに混ぜて しまい、エージェントが失敗したときにその原因を特定しづらいのです。UniClawBench は自らを「動的な実環境でプロアクティブエージェントを評価する最初の能力駆動ベンチマーク」と称しています。
何が新しいのか — ライブコンテナとステップ単位のチェックポイント
最も目を引く設計は採点方式です。あらかじめ記録した静的な正解と文字列を照合するのではなく、UniClawBench はエージェントを ライブの Docker コンテナ 内で動かし、 きめ細かなステップ単位の完了チェックポイント で採点します。
この差がなぜ重要かは、実際のタスクを思い浮かべると明確になります。「レストランを予約し、その予定をカレンダーに入れて」というような要求には中間状態があります。最終的な答えだけを照合する方式は、その文字列一つしか見ません。一方チェックポイントは、「予約が実際に取れたか」「カレンダーに項目ができたか」を環境の中でステップごとに確認します。人間のアシスタントを評価するやり方にずっと近く、成果物だけでなく過程が実際に起きたかを見ます。
もちろんタダではありません。ライブコンテナは静的な JSON の正解ファイルより実行コストが高く、決定的(deterministic)に保つのも難しいのです。ただしそのコストは、エージェントが実際に何かを やり遂げたか を見るために払う対価であり、静的ベンチマークが取りこぼすのはまさにそこです。
閉ループ — 実行者、隠れた監督者、ユーザーエージェント
二つ目の核心は、評価ループそのものを 3 つのエージェントで組んだ 閉ループ(closed-loop) 設計です。
- 実行者(executor)エージェント — 実際にタスクを遂行します。採点の対象です。
- 隠れた監督者(supervisor)エージェント — ステップ単位のチェックポイントで進捗を採点しますが、 採点基準を明かしません。
- ユーザー(user)エージェント — 人間のユーザーの代わりに、多ターンのフィードバックを与えます。
User-Agent -> 要求・追質問・フィードバックをターンをまたいで送る
Executor -> コンテナ内で道具を操作しタスクを遂行する
Supervisor -> ステップ単位のチェックポイントで採点(基準は隠したまま)
「隠れた」が肝です。採点基準が会話に漏れれば、実行者はタスクを やり遂げる 代わりに、基準に合う言葉を言うよう最適化されかねません。監督者のルーブリックを隠しておけばその近道は塞がれます — これは前の記事で扱った汚染とゲーミングの問題を正面から狙った設計です。多ターン構成も同じ論理です。実際の補助作業は一回のプロンプトではなく会話であり、ユーザーエージェントがその追加要求や明確化を供給します。
モデルとスキャフォールドを切り分ける — 5 つの能力
UniClawBench は 400 の二言語タスクを 5 つの 基礎モデル能力 に分けます — スキル使用(skill usage)、探索(exploration)、長文脈推論(long-context reasoning)、マルチモーダル理解(multimodal understanding)、クロスプラットフォーム協調(cross-platform coordination)です。各タスクが狙う能力が決まっているため、失敗は霧ではなく原因を指し示します — 「探索で崩れた」と「長文脈を見失った」を区別できます。(なお、どの二つの言語かは要旨に明記されていません。)
開発者の視点で最も歓迎すべきは最後の点です。著者は ベースモデルの能力とフレームワーク水準の設計上の選択を切り分ける ため、最新モデルを複数のエージェントフレームワークの上で評価します。これは前の記事で確認した事実 — スキャフォールド(ハーネス)を替えるだけでスコアが数ポイント動く — への正攻法です。スキャフォールドを固定するか意図的に変えて試さない限り、モデル A がモデル B に勝ったのか、A のハーネスが良かっただけなのかは分かりません。
一点だけ明確にしておきます。要旨はモデルとフレームワークが「性能を共に形づくる」と結論しますが、 具体的な順位やスコアを要旨には載せていません。 本文にどんな表があろうと、それは著者報告値であり、まだ独立に再現・監査されていません。ベンチマークとコードは公開するとされているので、検証はコミュニティに委ねられます。
おわりに
この一本から、2026 年のエージェントベンチマーク設計の方向はかなり明瞭に読めます — 静的より ライブ環境、最終解より ステップ単位のチェックポイント、漏れるルーブリックより 隠れた監督者、そして モデルとスキャフォールドの分離 です。この 4 つは次第に基本になりつつあります。
もちろん留保すべき点も多いです。出て数日の論文であり、数値は著者報告値で、二言語の正体も要旨にはありません。ライブコンテナ方式は高コストで再現が難しく、どんなベンチマークもいずれ飽和しゲーミングされます — 前の記事が残した教訓のとおりです。それでも設計の方向だけは正しいと言えます。
ですから有用な問いは「誰が UniClawBench の首位か」ではありません。「環境がライブで、ターンが何度もあり、採点者が基準を教えてくれないとき、自分のエージェントは持ちこたえるか」です。リーダーボードの数字一つではなく、その条件こそが本当の信号です。
参考資料
현재 단락 (1/22)
以前の [コーディング評価で信号とノイズを見分ける記事](/blog/2026-07-11-signal-noise-coding-evals) では、最も広く使われるコーディングベンチマークが汚染と...