受け入れゲート CONFORM

#ルール

ルールは一字一句凍結されており、調整できるパラメータはありません。

1. 候補を順に生成する。
2. どの候補にもサンドボックス内で可視の受け入れ検査を実行する。
3. 最初に合格した候補をすぐに通し、生成を止める。
4. 最大五つ。すべて不合格なら納品を拒否する。
5. 納品拒否は失敗に数え、分母はすべての問題とする。

#評価委員会をどう置き換えたか

2026 年 8 月の利得実験では、委員会式の設計（評判ルーティング、三人の評価者、サンプリング監査、一回の修正）が、同じ呼び出し予算のもとで、同じ問題を五回生成して多数決を取る方式に負けました。

仕組みの分析で原因が見つかりました。

評価者が追っているのは問題の難しさであって、答えの正誤ではない

9 月 3 日の R440P は審判そのものを置き換えました：評価委員会を削除し、顧客の受け入れテストを実行する方式に改めました。 プロジェクト文書の言い方では——

意見の代わりに実行を、投票の代わりにレシートを。}}

#実測結果

三つの問題バンクで、五回の再現と四つの互いに重ならない問題セットにまたがっています。

ゲートは一回だけ引くより多く納品する——問題バンクをまたいでも、再現をまたいでも成り立つ

問題が難しいほど、早期停止の価値は高い

#同予算での比較：ゲートが投票に勝つ

これは最もきれいな比較です：同じ 5 つの候補、同じ 5 回の呼び出しで、一方は最初に合格した候補を納品し、もう一方は五つの候補で投票して多数を取ります。

#なぜゲートは効き、評価者は効かないのか

保存済みの五候補データ二バッチでは、候補プールの上限はそれぞれ 82.68%（31 問で五つすべて不正解）と 85.03%（22 問ですべて不正解）でした。

この記事はゲートの系列全体の数字と反証の記録をまとめたものです

#このゲートは今も成り立つが、唯一の道ではない

2026 年 9 月末以降、製品にはゼロ設定（ゼロ設定の Vacant）というもう一つの主線が加わりました。これがすることは一つだけです：エージェントが「完了しました」と言ったその瞬間に、一度だけ言葉を送り返します。

四つのバッチのうち三つで差が測れませんでした。 四つ目では測れましたが、推論エンジンを替えると再現しませんでした。

これは本ページの数字を反証するものではありません。 理由は、二つに欠けているものが同じではないからです。

原文の言い方では、ゼロ設定の C 群は三つの部品を一つも持っていません。

#サンドボックスと受け入れスイート

候補プログラムは独立したプロセスで実行されます：10 秒、128 MiB、作業ディレクトリは一時ディレクトリ、環境変数は継承しません。テストプログラムと候補プログラムは別々のプロセスにあり、ランダムなトークンを付けたリテラル値のみを許すリモート呼び出しで通信するため、候補プログラムは構造的にテストコードを見ることができません。

#受け入れスイートはデータであって、プログラムではない

2026 年 9 月 6 日の攻撃実験（R451）で分かったこと：受け入れスイートが「信頼されたコード」の一片である限り、攻撃者は状態を持つ変種を書いてゲージを無効化できます——ゲージは両方向とも満点なのに、納品率は −75.20 pp 落ち、それでもゲージは ok を返していました。

修正は SuiteSpec です：スイートには方言、エントリポイント名、「入力—期待値」のリテラル値リストだけが含まれます。実行器は自分自身の決定論的なレンダラーでこのデータからテストコードを生成するだけで、レンダリング結果のハッシュはマシンをまたいで照合できます。

効果：exec の密輸は 368/371 → 0/371 になりました。

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

#前提条件

私たちはこの文を、効果の数字を述べるすべての文書に一字一句書き込んでいます。そのブロックを削除することは、それらの数字が成り立つ条件を削除することに等しいのです。

関連する構造的な発見：私たちが使った問題バンクでは、非公開テストはいずれも可視テストの上位集合（V ⊆ GT）でした。そのため「非公開では通るが可視では通らない」は構造上起こりえません。これにより「可視テストによる選別は無損失である」という文は中身を失います。v-gt-is-not-lossless

#偽の納品：ゲートは確かに止めているが、半減ではない

R532 の比較的大きなモデルでの実験（836 問、43 ブロック、0 無効）：

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

#次に読むもの

• 修正ループを加えるとどうなるか：実行可能な受け入れ層
• 五回の再現のあとの判定：見出しの主張は自分たちの安定性ルールに負けた
• token の収支：これは成功率の向上であって、token 効率の向上ではない