ゼロ設定の Vacant

ゼロ設定は v0.9.0 の製品の主線です。設計目標は多くをこなすことではなく、インストールした後もいつもどおり使えることです——契約を結ばず、設定を足さず、ワークフローを変えません。

#何をするか

中心は納品前チェックです：エージェントが「終わりました」と言ったその瞬間に、書き出すよう求められたファイルがあるか、テストを実行したか、失敗した手順が飛ばされていないか、出所の分からない数字がないかを確認します。

設計原則は 「ほぼ確実に本当の問題であるものだけを差し戻し、それ以外はすべて納品説明に書くだけにする」 です。

それ以外は「納品説明」に書いて人に見せ、差し戻しはしません。

ターン予算のリマインダーは v3.6 から既定でオフになっています。 理由は測定できるトレードオフです。

リマインダーは正答率を 51.9% から 59.3% に上げましたが、提出された答えのうち正しいものの割合は約 82% から 65% に下がりました。作者の理由は「採点を見ない人にとって、根拠のない答えが一つ増えることは改善ではない」です。

#四つのバッチの結果

#① DABstep 有料バッチ：二つのモデルとも差は測れず

77 問、各問各群一回の実行：

事前登録の言い方に従えば、これは差が測れなかったのであって、「効果がない」ではありません。

そのラウンドの 8 回の差し戻しはすべて誤報でした。

なぜこうなるのか。82 の失敗した実行のうち 54 は「15 ターンを使い切っても答えのファイルがまだ存在しない」もので——ゲートの検査にはそもそも順番が回ってきません。残りの誤答はどの手順にも根拠があり、誤りは「この判断が正しいかどうか」にあります。これは根拠の有無だけを見る検査には、設計上見えないものです。

#② ローカル 711 セルのバッチ：p=0.021、ただし 6 問に集中

79 問 × 三群 × 3 回、主分析には 77 問を使用：

事前登録の主検定は p=0.0207、平均差 +7.4 pp。ただし、この p 値だけを取り出して語ることはできません。

作者の感度分析：6 問のうち任意の二問を除くと p は 0.05 を超え、6 問をすべて除くと平均差 0.009、p=0.80 になります。差はすべて「第 14 ターンまで進んでも答えのファイルがない」層から来ており、v3-3 の仕組みは一度も発動していません。

しかも v3 は前のラウンドの同じ 77 問の記録を見た後で設計されたもので、問題とルールは独立していません。その事前登録に人間が一項目ずつ署名したわけでもありません。

#③ Colab 五群のプログラミング問題バンク 920 問：差は測れず

p = 0.387。

このラウンドの最も重要な発見は正答率ではなく、差し戻しの仕組みそのものにありました。

472 回の差し戻しのうち 455 回は、pytest と python -m unittest しか認めず、エージェントが実際に実行した sh run_tests.sh を認めなかったことが原因でした。その 293 セルのエージェントは確かにテストを実行していました。

#④ u274 事前登録バッチ：9 対 10

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

なし 9/100、あり 10/100、McNemar 正確両側 p = 1.0。

原文書の記述：「仮に 7 組すべてが C だけの正解だったとしても、p は 0.016 にしかならない。6 対 1 なら 0.125。このバッチでは非常に大きな差しか見えない。」（原文：「就算 7 對全是 C 單獨對，p 也只有 0.016；6 比 1 是 0.125。這一批只看得到非常大的差。」）

しかも、このバッチではファイル欠落の差し戻しはまったく役に立ちませんでした。

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

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

1. test_claim が任意のテストスクリプトを認める — pytest だけでなく、コマンドの位置で実行され、ファイル名が test で始まるか終わるものなら認めます。細則もあります：「テストスクリプトが赤になり、その後に緑のテスト実行がもう一度あれば＝直った、として失敗した手順の飛ばしには数えない。ずっと緑にならないものは従来どおり差し戻す。」
2. 納品物は、人がエージェントに従わせる説明ファイルからも認定する — エージェントへの命令だけを対象とし、否定、任意、例示のものは数えません。
3. モデルのエラーで終わったターンは一律に差し戻さない — 人に向けて書くだけにします。

効果：

ただし作者自身、v3.7 が正答率に与えうる上限は小さいと明記しています：「Colab で新たに増えた 10 回の実行のファイル欠落の差し戻しをすべて救えたとしても、920 問中 +10 問である。」

#v3.7 のその後の実測：測れたが、エンジンを替えると消えた

2026-10-02、v3.7 は Colab で初めて差を測りました。

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

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

C37 − A −0.4 pp、p = 0.84。

作者の対照群についての結論は「一方のエンジンでは出て、もう一方では出ない」で、仕組みの説明も添えています：GGUF では差し戻しにターンを使うため、15 ターンで打ち切られたものが 59 から 74 に増え、取り戻した分と打ち切られた分がちょうど相殺されました。

タスク指向の三つの問題バンク 94 問（ターン上限なし）でも、同じく差は測れませんでした。

バッチをまたいだ仕組みのまとめ：DABstep の 15 ターンでは、なしのエージェントの 18% が「言ったのに書いていない」状態だったので差が測れた。タスク指向の三つのバンクでは 4% しかなく、測れなかった。

#なぜこれが CONFORM を反証しないのか

これがこのページで最も重要な段落です。

ゼロ設定の C 群には三つの部品が欠けており、その三つこそ、過去に利得が測れた仕組みが備えていたものです。

だから正しい言い方はこうです：「同じセッション内で一度言う」という道は、四つのバッチのうち三つで差が測れなかった。過去に利得があったのは、どれも Vacant が生成を握る仕組みである。 これは矛盾ではなく、二つの異なる仕組みがそれぞれ別に測られたということです。

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

#誠実な限界

1. v3-2／v3-3 はエージェントがターン上限を知らされている場合にしか働きません。 一般的な対話での利用（pi は既定で上限なし）ではほとんど発動しません。
2. リマインダーはファイルの有無だけを見て、答えが正しいかどうかは言いません。
3. 有料バッチのシミュレーションの数字はモデルが指示どおりに動くと仮定しています。しかもそれは gemma-26b の思考ありの場合で、ローカルの gemma-4-12b の思考なしは別のモデルです。
4. 模擬ユーザー群の証拠は L-fake です：差し戻しを見た後にモデルがどう動くかは台本が決めています。それが証明するのは「差し戻しは届き、直せば見え、問題がないときはまったく動かない」ことであり、本物のモデルが指示どおりに動くことは証明しません。
5. R530 は 2026-09-28 に完了しました（差し戻し 32 セル、全問正解なのに差し戻されたもの 4 セル）。もう未完了の項目ではありません。

ゼロ設定の四つのバッチの完全な記録。各バッチについて言えないことも含む

#次に読むもの

• 生成を握る道：受け入れゲート CONFORM
• シグナルはどこから来るか：実行可能な受け入れ層
• プラットフォームが協力しないとどうなるか：ネイティブプラットフォームと静かな無効化