ArtifactArena：生成物を評価し、主張の境界を定める

出力が生成物になると、問うべきことが変わる

文字列の答えなら、正解表で採点できる。身体性を伴う設計の評価では、作られたものを採点する。対象は形状、制御コード、そして両者を機能させる戦略である。これは実機の結果を意味しない。証拠の単位を「モデルが何を言ったか」から「宣言された評価環境で、実行可能な生成物が何をしたか」へ移すのである。

2026年10月5日の arXiv v1 論文 ArtifactArena は、MuJoCo の対戦で、生成されたロボットの形状・制御コード・戦略を評価する。著者の測定が示すのは、そのシミュレーター内の設計と制御であり、実機能力ではない。本章では結果を独立して再現していない。

1. 1課題の規則と固定したシミュレーター
2. 2モデルが形状・制御コード・戦略を生成

1. 1検証器
2. 2実行可能な生成物
3. 3固定した対戦相手と乱数 seed
4. 4結果

1. 1結果の記録
2. 2設計の質と評価環境、探索予算を分離

1. 1実機についての主張
2. 2別の安全審査、権限、実機からの証拠

これは独自の教材図である。論文が示すのは競技場の前提であり、以下の比較手順と主張の境界は再利用できる評価設計である。

系譜：建造の評価と対戦の評価は同じでない

2024年の MMLU-Pro は、選択式の回答を評価した。続く BuildArena は生成された物理的な建造物を、ArtifactArena は対戦する生成物を評価する。出力も評価器も異なるため、三者の点数を横に並べて比較することはできない。

2025年10月の BuildArena は、言語で指示した建造を物理に基づく検査で評価した。ArtifactArena は問いを変え、生成物を同じ競技場で競わせる。荷重を支える橋と相手に勝つロボットには別の比較条件が必要であり、どちらも製造可能性、信頼性、現場での安全性を証明しない。

シミュレーター自体も比較条件であり、世界の中立な写真ではない。MuJoCo は、関節をもつ構造と接触を扱う汎用の物理エンジンである。入力、数値設定、接触の扱い、観測の接続が、測定するものを決める。モデル比較の途中でこれらを変えれば、設計の比較がシミュレーターの比較に変わる。

近くの VLA パッチ防御の教材は、介入後も通常の方策が保たれるかを問う。本章では、生成器が出した形状、制御コード、戦略が、一つの固定した評価器の下で結果を得たかを問う。

比較条件を固定する

ArtifactArena の評価用資料は、「シミュレーターで試した」だけでは弱い理由を見せる。提出物には MJCF のロボット構造と制御コードが入り、競技場側が物理の共通設定を持ち、提出物を検証する。この入出力も、比較条件の一部である。

生成器 A と B を比べる前に、次の表を固定する。明示した理由なしに一行でも違うなら、集計値だけで勝者を決めない。

比較項目	記録するもの	結論が反転し得る理由
評価環境	シミュレーターの版、規則、時間刻み、接触設定、検証器の改版	評価器が変われば課題が変わる
生成物の入出力	許す形状要素、制御用 API、観測の形式	一方だけが易しい設計空間を受ける場合がある
探索予算	モデルと版、指示文、API 呼び出しまたはトークン上限、時間上限	多く探したことは、より良い設計と同じではない
対戦集合	対戦相手の版、組合せ、順番、開始側、乱数 seed	特定の既知の相手だけに適応できる
候補の選択	通過条件、候補を選ぶ手順、再試行	多数の失敗後に選べば探索量を隠す
結果	勝ち・負け・引分、検証失敗、異常終了、時間切れ、NaN/Inf、失格	失敗を除いた勝率は脆さを隠す

候補ごとに同じ乱数 seed の一覧を使うが、それだけでは足りない。未使用の seed 一覧と未使用の対戦相手の版を残す。前者は既知の開始状態だけで動く設計を、後者は既知の相手向けの戦略を見つける。競技場の改版が対戦相手の集団を変えたら、古い集計に勝ち数を足さず、新しい評価として扱う。

公正な比較のためのオフライン用記録

この演習では、モデル、シミュレーター、GPU、API、ロボットを実行しない。架空の生成物 A と B を二つ作り、生成物ごとに二行を持つ確認用の記録を作る。

run_id,artifact_id,arena_rev,opponent_rev,seed,budget_calls,result,failure_code
r01,A,arena-01,opponents-01,11,40,win,none
r02,A,arena-01,opponents-01,29,40,loss,none
r03,B,arena-01,opponents-01,11,40,invalid,xml_validation
r04,B,arena-01,opponents-01,29,40,timeout,timeout

形状のハッシュ、制御コードのハッシュ、指示文の版、モデルと版の識別子、候補を選ぶ規則、記録のハッシュを追加する。loss は対戦上の負けだけを表す。timeout は独立した結果、invalid は独立した検証失敗として残す。その上で比率を計算する前に、四つを問う。

1. 二つの生成物は同じ競技場、対戦相手、乱数 seed、探索予算を受けたか。
2. invalid と timeout を対戦上の loss と分けて数え、捨てていないか。
3. 確認する人は、探索の記録からどの生成物を選んだかを再現できるか。
4. 既知の集合を未使用の seed と対戦相手に入れ替えても結論は残るか。

未使用の条件で消える改善は、失敗の診断であって恥ではない。opponent_overfit、seed_sensitivity、budget_asymmetry、validator_failure、unknown のいずれかを付け、追跡できる記録を残す。都合のよい seed だけを再実行して記録を直してはいけない。

三つの生成方法は、三つの実行許可ではない

公開された評価用リポジトリの三つの方法は、比較条件として扱う。単発生成は反復した評価結果なしに候補を作る。検証結果を使う改良は、判定内容に応じて候補を直す。Design Lab は道具を使った探索を広げる。フィードバックが増えれば提出物は改善し得るが、使える権限、再試行、候補選択も変わる。結果には必ず model + checkpoint + harness + budget + arena revision を記す。そうしなければ、モデルの性質に探索の仕組みが混ざる。

費用、権限、実機との境界

資料は、読者ごとの価格や再現可能な計算費用を示さない。実行には、モデル提供元またはローカルの重み、シミュレーターの依存関係、生成物と記録の保管、繰り返す対戦の計算資源が必要になり得る。定義した作業を実行するまで、論文の順位表から運用費を見積もらない。

論文は ArtifactArena の組織ページへリンクしている。公開されている harness-public と design-lab-harness は MIT ライセンスを掲げる。現在の README は Python 3.10 と MuJoCo 3.10 を指定し、モデル実行には提供元の鍵、Hugging Face のデータセット用トークン、Design Lab では Linux の隔離機能が必要になり得るとする。これは必要条件であって費用見積りではない。読者に API、データセット、モデルの重み、実機を使う権限を与えるものでもない。論文本文の版は CC BY-NC-SA 4.0 であり、生成物の権利は未確認である。

シミュレーター内のロボットが勝ったからといって、実機に移してはいけない。実機試験には、別に承認されたハードウェア、審査済みの安全計画、非常停止の責任者、速度と力の上限、隔離区域、監視、復帰手順、実機そのものからの証拠が必要である。ここでは何も依頼・実行していない。

心に置くべき見方は単純である。生成物の点数は、宣言した競技場の中で特定の生成器が示した証拠である。競技場、探索予算、乱数 seed、対戦相手、失敗を調べられるときにだけ、有用な結果になる。