実行可能な受け入れ層

#L3　可視と非公開の分離

各問題の要求は三つの部分からなります。問題文、公開された入力の契約、受け入れテストです。

受け入れテストは二組に分けます。

プログラムが可視テストには合格したが、非公開テストには合格しなかったとき、それが一回の偽の納品です。これは「出力は要求のように見えるが、要求ではない」という問題を操作可能にした形です。

#動的監査：非公開テストが漏れ込んでいないか

#サンドボックス

候補プログラムは独立したプロセスで実行されます。

テストプログラムと候補プログラムは別々の二つのプロセスに置かれ、ランダムな標識を付けた、リテラル値だけを許すリモート呼び出しで通信します。これにより候補プログラムは構造的にテストコードを見られません。

実測（2026-07-09、24 回の呼び出し、思考モード有効）の遅延：中央値 9.1 秒、p95 40.0 秒、最大 41.7 秒、合計 5.4 分。Hermes のエンドツーエンドは約 78 秒でした。

#L4　受け入れスイートはデータである

#問題：ゲージは役に立たないものに食わされうる

2026-09-06 の攻撃実験（R451）が示したのは、受け入れスイートが「信頼されたコード」の一片である限り、攻撃者は状態を持つ変種を書いてゲージを無力化できるということです。ゲージは両方向で満点なのに、納品率は −75.20 pp 下がり、それでもゲージは ok を報告しました。

371 問のバッチでは、スイートを commit に結びつけた後、平凡なスイートは 371/371 ですべて拒否されました（正常）。しかし状態を持つ変種は納品率を 75 ポイント下げ、ゲージは ok を報告しました。

#直し方：SuiteSpec

スイートに含めるのは三つだけです。

1. 方言（dialect）
2. エントリーポイントの名前
3. 「入力—期待値」のリテラル値の一覧

実行器は自分の決定的なレンダラーだけを使ってこのデータからテストコードを生成し、レンダリング結果のハッシュはマシン間で照合できます。

受け入れスイートをプログラムからデータに変えてから

#ゲージの検査：片側の保証

スイートは使う前にゲージの検査も通らなければなりません。参照解は合格しなければならず、既知の誤りのサンプルはどれも止められなければなりません。

#CONFORM と H-MIX

二つの規則は同じゲートの意味を共有しており、違いは失敗した後に何をするかです。

#CONFORM（再サンプリング）

候補を順に生成 → それぞれに可視の受け入れ検査を実行 → 最初に合格したものを通す → 最大五つ → すべて不合格なら納品を拒否。納品拒否は失敗として数え、分母はすべての問題です。

#H-MIX（修正）

1. 第一ラウンドのプロンプトには、問題の原文、インポートを許可する標準ライブラリの一覧、そして「まず問題文の例で自分の関数を手で確認する」という一行を含めます。
2. コードを取り出したら、まずサンドボックスを使わない静的な事前検査（構文、禁止されたインポートと属性、エントリーポイントの有無）を行い、通らなければ読み込めない理由を返します。
3. サンドボックスで可視の受け入れ検査を実行し、合格すれば通します。
4. 失敗したときは失敗シグネチャ（失敗の種類、例外の型、メッセージのハッシュ）を計算します。前のラウンドと同じなら、一回目は「別のやり方を試す」というヒントを付け、二回目はそのまま納品を拒否します。
5. 一問あたりの上限：5 回の呼び出し、32,000 token、900 秒。
6. フィードバックのメッセージは AssertionError: args=… got=… want=… という固定の形式で示し、長すぎるものは切り詰めます。
7. 文脈には、最初のユーザーメッセージ、直前のモデルの応答、そして今回のフィードバックだけを残します。

五回の再現の判定を見る

#偽の納品率

R532 の大きめのモデルの実験（836 問、43 ブロック、無効 0）：

ゲートは偽の納品をおおよそ四割削りました。半分ではありません。論文はもともと「halved」と書いていましたが、ファクトチェックで ERROR E6 と判定されました——二つの率が異なる分母を使っていたからです。

#次に

• ゲートの規則と判定：受け入れゲート CONFORM
• この層があなたのアシスタントにどう接続されるか：製品接続層