014つの軸
出力が客観的に検証可能なコードである領域でモデルを測ります(文章ではなく)。ゲーム制作とモンスター対戦は遊べるHTML5キャンバスアプリ、イラストはSVGを手書き、コーディング・推論は伏せた課題に解答します。
02ルーブリックと配点
各軸にバージョン管理された機械的ルーブリック。機能チェックは「できて当然」の土台で、強いモデルを分けるのは難しめの信号です。モンスター対戦(battle-v2)= 40点の土台(読込・起動・JS仕様・描画・技発動・双方行動・決着)+ 差がつく60点: 勝利可 12(良い手で実際に勝てる)・技数 8・技パラメータ 6・威力多様 8・戦略技 10(回復/防御)・視覚密度 16。各行の内訳でどのティアを通過したか分かり、ホバーのtitleに生のキーが入っています。
03不正対策: 放置 vs 操作
放置で勝てるゲームは素朴な採点を欺けます。そこで各ゲームを2回プレイ —— 放置(入力なし)と操作(汎用ボット)。スキル点はボットが放置を上回ることが条件で、ゲームは敗北可能でなければなりません。固まる/自動勝利のビルドはこれらのティアで落ちます。
04型厳格な契約
ゲームは固定のwindow.__game APIを公開します。採点側は型を厳格に検査 —— typeof score === 'number' であって関数ではない —— ので、関数を返すgetterでライブ値を偽装できません。ボットはこの契約経由でのみ操作します。
05K回サンプリングと分散
ゲームの乱数で単発プレイはぶれるため、各成果物を複数回採点し、中央値とσ(試行間のばらつき)を報告します。σが大きいほど品質が不安定で、各行に表示されます。
06オフライン隔離
信頼できないモデルのコードはネットワークを切ったヘッドレスChromiumで実行 —— 外部通信も持ち出しもできません。公開サイトでもゲームは厳格なdefault-src 'none'サンドボックスに埋め込まれます。
07来歴のティア
フロンティア · 有料 = 従量制クラウドAPI、バージョン固定(最も厳密)。ローカル · 無料 = 24GBのApple機で動かすオープンモデル。Web · 手動 = チャットUIからの貼付: 単一・信頼ベースのサンプルで、厳密性が低いため明確に区別表示します。
08具体例
Claude Opus 4.8 の game/v2、3試行で {75, 100, 100} → 中央値 100、σ 11.79。grok-4.3 のモンスター対戦は勝利可能な決闘を作れたものの、state() が各技について {name} しか公開せず威力を出さないため、メタデータ系ティア(技パラメータ・威力多様)が採点できず → 72: 機能するかつ仕様を報告する対戦をルーブリックは評価します。