ゼロ設定の四つのバッチ：三つは差が測れず、四つ目はエンジンを替えると消えました

この記事は四つのバッチを記録します。四つともきれいな結果ではなく、しかもきれいでない形がそれぞれ違います——そこが要点です。

#まず何を測ったのかをはっきりさせる

ゼロ設定（zero-config）は v0.9.0 の製品の主線です。目標は多くをこなすことではなく、インストールした後もいつも通りに使えることです。契約を書かず、設定を足さず、作業の流れも変えません。

やることは一つだけです。エージェントが「完了しました」と言ったその瞬間に、同じセッションの中で一度だけ言葉を送り返します。

これと 受け入れゲート CONFORM との違いは、バージョンの新旧ではありません。CONFORM は生成を握っています。候補ごとに可視の受け入れテストを実行し、通らなければ再サンプリングし、最大五つまで、すべて通らなければ納品を拒否します。ゼロ設定は生成を握っておらず、実行可能なシグナルも、やり直させる権限も、納品を拒否する権限もありません。

まずこの違いを机の上に置いておくと、後の四つのバッチの結果が読めるようになります。

#バッチ一：DABstep 有料バッチ（2026-09-25／26）

77 問、各問題・各グループ一回ずつ実行し、費用は 3.40／4.80 ドル、呼び出しは 3,324 回。

事前登録の言い方に従えば、これは差が測れなかったということです。「効果がない」とも「悪くなった」とも言いません。

#8 回の差し戻しはすべて誤報

これがこのラウンドで最も記録すべきことです。

実際の誤報率：gemma 6/37（16%）、qwen 1/64（2%）——分母は「初めて提出前チェックに到達し、その時点で回答が正しかった実行の数」です。

害は 0 回。 正しい回答を誤りに書き換えたことは一度もありません。

作者は報告の中で、自己評価を一文書いています。

費用をかける前の誤報の閾値は、正解した 3 回の実行の実記録の再生だけに基づいており、この閾値は薄すぎる。（原文：「花錢之前的誤報門檻只建立在 3 跑答對的真實紀錄重播上，這個門檻太薄。」）

3 回です。これは設計側のサンプル数が小さすぎるということで、統計の問題ではありません。

#82 件の失敗のうち 54 件は「提出していない」

失敗の原因を分解すると：

失敗の三分の二は「ターン上限でエージェントが打ち切られた時点で、回答ファイルがまだ存在しなかった」ものです。Vacant の提出前チェックはエージェント自身が完了したと言ったときにしか走らないので、永遠に出番が回ってきません。

残り 22 件の推論ミスが最も厄介な種類です。どの手順にも根拠があり（値は自分で計算し、マニュアルも開き、手順も失敗していない）、誤りは「この判断は正しいか」にあります。作者はこう書いています。「『根拠があるかどうか』だけを見るチェックは、設計上これが見えない。」（原文：「只看『有沒有根據』的檢查從設計上看不到。」）

例：7 回の実行が、マニュアルに明記された「詐欺率＝金額の比率」を件数の比率として計算しました。5 回の実行は、正解を自分で算出したうえで別の解釈を選びました。

#バッチ二：ローカル 711 セル（2026-09-26）

79 問 × 三グループ × 3 回 = 711 セル。主分析には 77 問を使います。

事前登録の主検定は p = 0.0207、平均差 +7.4 pp、bootstrap 95% CI 0.017–0.139。

ついに何かが測れたように見えます。しかしこの p 値だけを取り出して語ることはできません。

#「有意性が薄い」とはどういう意味か

作者による感度分析（事後）：

問題数で数えると 15 問が良く、7 問が悪い——符号検定 p=0.13 で、有意ではありません。

原文の言い回し：

有意性が薄い：2 回の実行の結果を反転させるか、その 6 問のうち任意の二問を除くと、p は 0.05 を超える。他のモデル、他の問題バンク、上限のない使用には外挿しない。（原文：「顯著性很薄：兩跑的結果翻過來、或拿掉那 6 題裡的任兩題，p 就會超過 0.05。不外推到別的模型、別的題庫、沒有上限的使用。」）

#副次的な比較はすべて有意ではない

• C1 − A：+0.013、p = 0.75
• C2 − C1：+0.061、p = 0.083、Holm 0.17

三回のうち 2 回目だけが単独で有意でした（12 対 3、p=0.035）。「6 つの大きな差はすべて正で、7 つの負はすべて −1/3」だったからです。

#二つの自己制限

1. v3 は、前のラウンドの同じ 77 問の記録を見た後で設計されました。 事前登録の第七節第 2 条が、この制限を自ら書いています。問題とルールは独立していません。
2. 人間はこの事前登録に一条ずつ署名していません。 作者は「対外的に『証明』として扱う前に署名を補う必要がある」（原文：「對外當成『證明』之前要補簽」）と書いています。

#ゲージ自体も間違えていた

research.wilcoxon_signed_rank_exact は浮動小数点の == で同順位を判定しており、2/3−1/3＝0.33333333333333337 と 1/3＝0.3333333333333333 を別の値として扱ったため、順位づけを誤りました。凍結された関数が算出したのは 0.0189、正しく処理すると 0.0207 です。

どちらも < 0.05 で、結論は変わりません。しかしこれは測定ツールのバグであって、データの問題ではありません。

#v3-3 は一度も発動しなかった

C2 で提出前チェックに到達した 150 回すべてについて、第 14 ターン以降に起きたものは一つもありません。

#差はどこから来て、代償は何か

純増分はすべて「第 14 ターンに到達してもまだ回答ファイルがない」層にあります。その層の正答は A 4/79、C1 3/78、C2 26/82（+22 回の実行）。63 回の実行がリマインドの後にファイルを書き、すべてリマインドの直後のターンでした。

しかし：63 回のうち 25 回が正解、38 回が誤りでした（ほかに 19 回はリマインドされても書きませんでした）。

作者はこのトレードオフを一文で言い切っています。

代償は、間違ったものを多く納品したことだ。採点を見ない人にとっては、間違った回答をより多く受け取ることを意味する。（原文：「代價是多交了錯的。對一個不看評分的人，這代表會收到更多錯的答案。」）

だからこそ v3.6 以降、リマインドはデフォルトでオフになっています。

これは成功率の向上であって、トークン効率の向上ではありません

#バッチ三：Colab のプログラミング問題バンク五つ、920 問（2026-09-27）

LCB v1 89、LCB v2 118、LCB v3 189、MBPP+ 369、HumanEval+ 155、合計 920 問 × 2 グループ = 1,840 セル。

McNemar の正確両側検定 p = 0.387。

#しかしこのラウンドで最も重要なのは正答率ではない

C グループの 920 セルのうち 858 セルが提出前チェックに到達し、309 セルが差し戻されました。472 回の差し戻しの内訳：

その 455 回は、v3.6.1 が pytest と python -m unittest しか認めず、エージェントが実際に走らせた sh run_tests.sh を認めなかったためです。293 セルでは、エージェントは明らかにテストを実行していました。

作者の言い方は「誤った差し戻しに目に見える害はないが、モデル呼び出しが約 12% 余計にかかる」（原文：「誤退沒有看得出來的傷害，但多花約 12% 的模型呼叫」）です。

誤って差し戻された 289 セルだけを見ると、C は 264 が合格、同じ問題で A は 253 が合格——C のほうが未インストールより 11 セル多い。本当の差し戻し 20 セルでは、C は最終的に 18 が合格、同じ問題で A は 12 が合格。

しかしこの二行はどちらも事後の記述であって事前登録の検定ではなく、結論は出しません。

#バッチ四：u274（2026-09-27／28）

274 問をシード順に並べた最初の 100 問。すべて hard で、未使用のもの。

未インストール 9/100、インストール済み 10/100、McNemar の正確両側検定 p = 1.0。

対応表：A 正∩C 正 = 6、A 正∩C 誤 = 3、A 誤∩C 正 = 4、A 誤∩C 誤 = 87。

#「このバッチでは非常に大きな差しか見えない」

原文：

「効果がない」とは言わない：問題は非常に難しく（両グループの正答率は約 10%）、200 回の実行のうち 116 回が 1800 秒の制限時間に達し、不一致の対は 7 対しかない——7 対すべてが C だけの正解だったとしても p は 0.016 にしかならず、6 対 1 なら 0.125。このバッチでは非常に大きな差しか見えない。（原文：「不說「沒有效果」：題目很難（兩組答對率約 10%）、200 跑裡 116 跑碰到 1800 秒時限，不一致的配對只有 7 對——就算 7 對全是 C 單獨對，p 也只有 0.016；6 比 1 是 0.125。這一批只看得到非常大的差。」）

この一文そのものが p=1.0 より役に立ちます。このバッチのデータの検出力がどこにあるのかを教えてくれるからです。

#ファイル欠落による差し戻しは、このバッチではまったく役に立たなかった

しかも 16 回の実行は、モデルがエラーを起こした後に呼び戻されたものでした（15 回が failed to decode, ret = 1、1 回が Stream ended without finish_reason）——モデルの失敗を呼び戻しても回答にはならず、ターンを余計に燃やすだけです。

害は 0 回ですが、C は誤った回答を 13 件多く納品し、制限時間に 18 回多くぶつかりました。

#v3.7：三つの欠陥を修正

三つのバッチで差が測れなかった後、作者は戻って三つのことを直しました。

1. test_claim が任意のテストスクリプトを認める — 指示された位置で実行され、ファイル名が test で始まるか終わるものであれば数えます。細則もあります。「テストスクリプトが赤になり、その後テストを実行して緑になったことが一度あれば＝直った、とみなし、失敗した手順を飛ばしたとは数えない。最後まで緑にならなかったものはこれまで通り差し戻す。」（原文：「測試腳本紅了、之後又有一次跑測試是綠的＝修好了，不算失敗的步驟被略過；一直沒綠的照舊退回。」）

この一条は、バッチ三の 455 回の誤った差し戻しに直接対応します。

2. 納品物を、人がエージェントに従わせる説明ファイルからも認める — エージェントへの命令だけを受け付けます。否定、あってもなくてもよいもの、例示、プログラムの振る舞いを記述したものは数えません。> 64 KB のものとこのターンで変更されたものは読みません。一つのファイルに 3 個を超えるもの＝データとみなし、すべて数えません。
3. モデルのエラーで終わったターンは一律に差し戻さない — 人が読むためにだけ書きます。この一条は u274 の 16 回の実行に対応します。

効果：

敵対的レビューの 20 項目はすべて再現され、日常の使用で誤った差し戻しを起こすものはすべて修正されました。回帰テストは 31 件。

ただし作者自身が上限を明記しています。「Colab で新たに出た 10 回のファイル欠落による差し戻しをすべて救えたとしても、920 問のうち +10 問にすぎない。」（原文：「Colab 新增的 10 跑缺檔退回就算全部救回，也是 920 題裡 +10 題。」）原文の見出しはまさに「予想（明記したもので、検定ではない）」（原文：「預期（寫明，不是檢定）」）です。

さらにオフラインでの忠実度：v3.6.1 で Colab 1327/1327、u274 81/81、S36-nocap 80/80 回のチェックを再計算し、動作と区分は記録と同じで、すべて一致しました。

#2026-10-02／03：測れた、そして再現しなかった

v3.7 の公開後最初の実測で、Colab で差が測れました。

C37 − A の平均差 +11.3 pp、p = 0.0028。

翌日、同じ v3.7 を LM Studio の GGUF バックエンドに替えて再現を試みました。

C37 − A −0.4 pp、正確 p = 0.84。

#なぜこうなるのか

二つのバッチの仕組み上の違いは「差し戻しにはターンを使う」という点にあります。

• Colab（vLLM）：未インストールのエージェントが完了と言ったのに書いていなかったセルが 42/231 ありました。補えた量が、打ち切られた量より大きかったのです。
• GGUF：同じ missing_output は効いていました（完了と言ったのに書いていないものが 20 から 2 に減った）が、差し戻しにはターンを使います——15 ターンで打ち切られたものが 59 から 74 に増えました。正味の効果はほぼ 0 です。

二つを対照した作者の結論は「一方のエンジンでは出て、もう一方では出ない」（原文：「一個引擎有、一個沒有」）であり、「ゼロ設定 v3.7 はエージェントの仕事を良くする」と主張することを明確に禁じています。

#タスク志向の三つの問題バンクでも差は測れなかった

94 問、Colab、ターン上限なし：A 136/188（72.3%）対 C37 141/188（75.0%）、Wilcoxon p = 0.36。

バッチ横断の仕組みのまとめ：

DABstep の 15 ターンでは、A に 18% の「完了と言ったのに書いていない」があれば差が測れる。タスク志向の三つのバンクでは A が 5/120（4%）しかなく、測れない。判断を誤ったもの、あるいは制限時間で打ち切られたものは、ゼロ設定にはもともと見えない。（原文：「DABstep 15 回合、A 有 18%「說完卻沒寫」就量得到差；任務導向三庫 A 只有 5/120（4%）就量不到。錯在決定、或被時限切斷的，零設定本來就看不到。」）

#これは CONFORM を反証しない

これがこの記事全体で最も重要な一節です。

ゼロ設定の C グループには三つの部品が欠けています。

報告の原文：

このラウンドのゼロ設定 C グループには、三つの部品が一つもない：実行できるテストがなく、再サンプリングせず、納品を拒否しない。（原文：「這一輪的零設定 C 組三個零件一個都沒有：沒有測資可以跑、不重抽、不拒交。」）

したがって正しい言い方はこうです。「同じセッションの中で一度言う」という道は、四つのバッチのうち三つで差が測れなかった。過去に利得があったのは、すべて Vacant が生成を握る仕組みである。

これは矛盾ではありません——二つの異なる仕組みが、それぞれ別に測られたのです。

原文はまた、「過去のデータと完全に一致する」（原文：「和過去的資料完全一致」）とも、「過去のデータがこの結果を予測していた」（原文：「過去的資料預測了這個結果」）とも言ってはならないと明確に禁じています。言えるのは矛盾しないということだけです。

#この四つのバッチから私が学んだこと

この節は私の判断であって、実験結果ではありません。

1. 「差が測れなかった」と「効果がない」は大きく違い、このバッチで言えるのは前者だけです。

u274 のバッチは正答率が約 10%、半数以上が制限時間にぶつかり、不一致の対は 7 対しかありませんでした。作者自身の計算では、7 対すべてが C だけの正解でも p=0.016 にしかなりません。このバッチのデータの検出力は、非常に大きな差を見るのにしか足りません。 これを根拠に「ゼロ設定は役に立たない」と言うのも、「ゼロ設定は役に立つ」と言うのも、同じように成り立ちません。

2. 「誤った差し戻し」は「差し戻し漏れ」より優先して直すべきです。

920 問のバッチでは差し戻しの 96% が誤った差し戻しで、u274 のファイル欠落による差し戻しでは 31 回の実行の後に 0 正解 17 誤りでした。この二つの数字を合わせると一つのことが分かります。誤って傷つけるゲートは、誤って傷つけないことを学ぶまでは、正味の効果が負になりうる——その仕組みの設計が正しかったとしても。

3. 同じバージョン番号でも、推論エンジンが違えば別物です。

Colab の p=0.0028 と GGUF の p=0.84 は、同じ v3.7、同じ問題群、同じターン上限での結果です。作者はその理由を説明できます（差し戻しにはターンを使い、差し戻しに使えるターンの数はエンジンのターン消費の速さで決まる）が、それは「v3.7 は効果がある」という言葉を、条件を付けずに言うことはできないという意味です。

4. 測定ツールそのものが測り間違え、しかもその向きはそろっています。

バッチ二のゲージの浮動小数点の同順位バグ、バッチ三の pytest しか認めない問題、TUI harness の七つの測定エラー——どれも、数字を実際より見栄えよくする向きでした。 この点は 測定ツール自身が七回測り間違えた で詳しく述べています。

#次に

ゼロ設定の Vacant｜受け入れゲート CONFORM｜実行可能な受け入れ層