{"generated":"2026-10-15","lang":"ja","entries":[{"t":"Vacant とは","u":"/ja/docs/overview.html","g":"はじめに","s":"Vacant は AI アシスタントの外側を包むアカウンタビリティ層です。AI を置き換えるのではなく、あなたが書いた受け入れテストを一度実行し、合格したときだけ納品し、すべての手順に自分で再計算できる署名付きレシートを残します。","b":"ひとことで AI が「できました」と言う。 完了したと言うだけでは数えません。実行して初めて数えます。 Vacant は AI アシスタントの外側を包む層です。要求と受け入れテストを渡すと、Vacant はあなたの AI に作業させ、終わったら あなたのテストを一度実行します 。合格すればあなたの手元に届き、不合格ならゲートで止めます。過程のすべてのセルに署名が付き、一つのセルを書き換えるとチェーンはそのセルで切れます。 やること、やらないこと --- --- やること あなたが書いた受け入れテストで納品を判定し、その判定を自分で再計算できるレシートチェーンに署名して残し、悪い仕事をした参加者が次の仕事を受け取りにくくします。 やらないこと AI を賢くはしません。この AI が信頼できると保証もしません——レベルは一回の実行に属し、一つの AI には属しません。テストに書けない仕事の採点もしません。 なぜ「信頼」ではなく「説明責任」なのか 本研究の定義は五回変わり、そのたびに主張は小さくなりました。最後に定まったのはこれです。 検証可能なレシートのない納品は受け取らない。 これは受け取り口であって、遮断装置ではありません。違いは第四章で詳しく説明します。「拒否」と判定されることは、「公開できない」ことと同じではありません。 では、私たちが外に向けてどの段階まで言えるのかを説明しています。 二つの形 生成を握る形 （本研究の主線であり、 でもあります）： — あなたの可視テストを実行し、最初に合格した候補を納品します。五つとも不合格なら納品を拒否します。 — 不合格のとき別の試行に替えず、失敗の原文を貼り戻して同じ試行に直させます。 — すべてのセルに署名し、一つ前のセルを固定します。公開鍵があれば誰でもオフラインで再検証できます。 生成を握らない形 （v0.9.0 の製品の主線）： — インストールすればそのまま働き、設定は要りません。エージェントが「完了しました」と言ったその瞬間に、一度だけ言葉を送り返します。実行可能なシグナルも、やり直させる権限も、納品を拒否する"},{"t":"インストール","u":"/ja/docs/install.html","g":"はじめに","s":"Vacant は Python パッケージ vacant-network です。インストール後、vacant on でメニューからあなたのコンピュータにすでにある AI アシスタントを選び、仲介のもとで起動します。常駐の設定は変更しません。","b":"要件 --- --- Python 3.11 以上 OS macOS、Linux（Windows ではサンドボックスを構築できません） モデルの通信路 OpenAI 互換の任意のエンドポイント：LM Studio、Ollama、vLLM、またはクラウド API AI アシスタント コマンドラインのエージェント（Codex、OpenCode、Claude Code、pi…）、またはあなた自身が接続した OpenAI 互換のエージェント 三つの接続方法、強制の度合いが違う これがインストール前に最も知っておくべきことです。「すべての呼び出しが自分を経由する」ことについての Vacant の保証は、 どう接続するかによって範囲が決まります 。 形態 強制性 説明 --- --- --- ライブラリ／MCP ツール 任意 エージェントが自分の設定に Vacant の MCP サーバーを登録し、 delegate などのツールを呼び出せます。エージェントが呼び出さなければ、Vacant は介入しようがありません。 コントローラ 自ら起動した子プロセスに対してのみ まず委任し、受け入れ検査をしてから、下流のエージェントを起動します。保証はこのコントローラを通して起動したプロセスにしか及びません。同じ OS ユーザーなら、これを迂回してエージェントを直接実行できます。 ループを所有する実行フレームワーク 完全に強制 生成、受け入れ検査、出荷をすべてこれが制御します。利得実験の runner はこの種類に属します。 2026 年 7 月のある実測が反面教師を残しています：Hermes エージェントは環境変数を一つ設定し忘れただけで、黙って外部サービスに直接接続していました。 requests_seen がゼロであることを除けば、そのセルは どのフィールドも正当な納品拒否のように見えました 。だからレシートの requests_seen フィールドは、仲介が本当に起きたことを証明できる唯一の証拠です——「環境変数を設定した」は証拠ではありません。 インストール 二つの起動方法、証拠のレベ"},{"t":"クイックスタート","u":"/ja/docs/quickstart.html","g":"はじめに","s":"標準解のある一問で、道筋を最後までたどります：要求と受け入れテストを書き、AI アシスタントに作業させ、ゲートがどう判定するかを見て、レシートの各欄に何が含まれるかを読み解き、チェーン検証が捕まえられない三つのことを知ります。","b":"用意するものは二つ ゲートはあなたのテストを 実行する のであって、モデルに「これは正しく見えるか」と聞くのではありません。だから： 1. 要求の記述 — 何が欲しいかをはっきり書きます。 2. 実行できる受け入れテスト — 入力は何か、期待される出力は何か。 一問はどんな形をしているか 受け入れテストは二つに分けます。 誰が見られるか 用途 --- --- --- 可視 V エージェントが読める システムはこれで通すか納品を拒否するかを決める。修正の流れが受け取れるのもこれの失敗メッセージだけ 非公開 GT 事後の採点だけが見られる 生成、選択、修正プロンプト、停止条件のいずれにも入れてはならない あるプログラムが 可視テストに合格し、非公開テストに合格しない なら、それは一回の偽の納品です。これは「成果物が要求のように見えるが、要求ではない」という問題を操作可能にした形です。 ここには私たち自身がはまった落とし穴があり、先に知っておく価値があります：私たちが使った二つの問題バンクでは、 非公開テストはいずれも可視テストの上位集合 でした。そのため「非公開では通るが可視では通らない」は構造上起こりえません。この発見は、私たち自身の事前登録にあった前提の一つを反証しました。 一通りやってみる この過程で、二つの層のものが手に入ります。 アクションチケット（一問につき一枚） — 要求、AI が何と言ったか、どの受け入れ検査を実行したか、判定は何か。 レシート（試行ごとに一件 + 一問につき判定一件） — 下を参照してください。 レシートを読む レシートのすべてのセルに署名が付き、一つ前のセルのハッシュを固定します。だから： - 一文字を書き換える → チェーンはそのセルで切れます 。 - 公開鍵を持つ人なら誰でもオフラインで再計算でき、私たちを信じる必要はありません。 検証の方法： 私たちが保存している単一ファイルのオフラインビューア（ exhibit/receipts/receipt_viewer.html 、0.3 MB。多者版は 4.5 MB）はレシートをファイル内"},{"t":"アカウンタビリティ層","u":"/ja/docs/accountability-layer.html","g":"中心概念","s":"「説明責任を問える」は「信頼」と同じではありません。これが Vacant の中心的な定義で、研究期間中に五回書き換えられ、そのたびに主張は小さくなりました。この表が現在唯一有効な版です。","b":"現在の定義 受け取り口：検証可能なレシートのない納品は受け入れられない。 強制点は 受け入れ時 にあり、実行時にはありません。下流は受け取る際にレシート上のハッシュを再計算し、署名を検証します。しかも 一枚のレシートは一度しか消費できません 。 本研究の正確な用語で言えば、これは「 後から再検証でき、改ざんが察知できる記録 」です。 なぜ「信頼」と言わないのか 信頼の古典的な定義には「監視しなくてよい」が含まれます。しかし監視こそが Vacant のしていることです——Vacant はその監視層そのものです。「信頼を高める」と言えば「少し確認を減らしてよい」と読まれますが、それは逆の方向です。 2026 年 7 月のある独立審査が、この点を決定づけました。審査の結論は一文です。 このアーキテクチャが現在高めているのはアカウンタビリティであって、信頼ではない。 さらに審査は、「信頼と言える」ために同時に成り立たなければならない三つの条件を挙げ、そのうち 二つは端的に成り立っていません 。 信頼と呼ぶために成り立つべきこと 現状 --- --- ① シグナルを安価に偽造できない 成り立たない — 誰でも他人の stream_id を名乗ってその評判を引き継げる（PoC 実測 0.50 → 0.7417） ② 罰が実際に効く 成り立たない — slash は証拠の比率を保つため、低得点者にとってはむしろ 報酬 になる：破壊者 0.0161 → 0.0312 → 0.0588 → 0.1053 ③ 監査の錨が信頼できる 部分的に成り立つ — 決定論的リプレイは本物の錨だが、サンプリングのシードが固定で公開されており予測できる そこで私たちは「説明責任を問える」と言い換えました。アカウンタビリティ（accountability）は本研究では技術用語です： 特定の鍵が署名した事象の追跡可能性と照合可能性 であり、心理的な意味での信頼は含みません。 定義の五つの版 これは本研究全体で最も重要な自己修正の記録です。どの版も言い回しの調整ではなく、一つ前の版の主張を狭めたものです。 時期"},{"t":"レシート","u":"/ja/docs/receipt.html","g":"中心概念","s":"レシートは「改ざんが察知できる」署名付きの記録ですが、五つの段階に分かれており、どのレシートもどの段階まで達したかを自分で宣言しなければなりません。2026-09-20 の監査で「納品拒否」が単なるフラグだと分かり、それ以来「出口で止める」とは言わなくなりました。","b":"五段階の語彙 2026 年 9 月 20 日、ある内部監査で、ある実験バッチの「納品拒否」が一つのフラグと終了コードにすぎなかったことが分かりました——外側のスクリプトは終了コードを読まず、拒否されたファイルをそのままコピーして外に出していました。 監査した 391 セルのうち、納品拒否の 59 セル中 7 セルでファイルが外にコピーされ、採点されていました。 その監査の後、プロジェクトは五段階の語彙でシステムが「何を証明したか」を記述するように改め、各段階がそれぞれ対象範囲を宣言することを求めました。 段階 システムが何を証明したか 2026 年 9 月の状態 --- --- --- Observed 観察した ある振る舞い、通信、成果物を見た 成立済み ：仲介が見た対話に欠落はない（2,755 ラウンドすべて一致、195/195 本のチェーンが検証を通過） Decided 判定した この納品が合格か不合格かを独立に判断した 成立済み ：エージェントが完了を自称しても、システムは納品拒否と判定して署名できる Withheld 差し止めた 不合格の成果物が外に送られなかった 既定では成り立たない 。release／publish の能力分離で補う Mediated 仲介した エージェントがシステムを迂回する代替経路を見つけられない 既定では成り立たない 。bwrap の隔離壁で実験的に成立 Attested 認証した 上記の事実が成果物・ポリシー・身元に改ざん不能な形で結びつけられた 部分的に成立 ：レシートレベル A／B／B′／C で表す この語彙の利点は、「ゲートがあるかないか」という二値の言い方を分解できることです。 私たちにゲートがないのではありません。ゲートが止められると仮定できないのです。 イベントチェーンの形式 各住人（参加者）は追記のみ可能なイベントチェーンを一本維持します。各イベントは ちょうど八つのフィールド を持ちます。 検証するのは三つです： 通し番号が連続していること 、 直前のハッシュが一致すること 、 Ed25519 署名が有効であること "},{"t":"受け入れゲート CONFORM","u":"/ja/docs/conformance-gate.html","g":"中心概念","s":"一字一句凍結されたルールです。候補を順に生成し、どの候補にも可視の受け入れ検査を実行し、最初に合格した候補を通します。最大五つで、すべて不合格なら納品を拒否します。納品拒否は失敗に数え、分母はすべての問題です——これがこのルールの最も重要な半分です。","b":"ルール ルールは一字一句凍結されており、調整できるパラメータはありません。 1. 候補を順に生成する。 2. どの候補にもサンドボックス内で 可視の 受け入れ検査を実行する。 3. 最初に合格した候補をすぐに通し、生成を止める。 4. 最大五つ。すべて不合格なら 納品を拒否する 。 5. 納品拒否は失敗に数え、分母はすべての問題とする。 評価委員会をどう置き換えたか 2026 年 8 月の利得実験では、委員会式の設計（評判ルーティング、三人の評価者、サンプリング監査、一回の修正）が、 同じ呼び出し予算のもとで 、同じ問題を五回生成して多数決を取る方式に 負けました 。 仕組みの分析で原因が見つかりました。 指標 数値 --- --- 評価者の票の正解率 0.7552 「すべて合格と判定する」という 知能ゼロのベースライン 0.7522 差 +0.29 ポイント 一回の修正で「直す機会がなかった」割合 93 / 113 修正後の版を盲目的に採用した場合の非公開評価の合格率 82.3% → 78.8%（ −3.5 pp ） 修正がもたらした本当の改善 1 / 113 9 月 3 日の R440P は審判そのものを置き換えました： 評価委員会を削除し、顧客の受け入れテストを実行する方式に改めました。 プロジェクト文書の言い方では—— 意見の代わりに実行を、投票の代わりにレシートを。 }} 実測結果 三つの問題バンクで、五回の再現と四つの互いに重ならない問題セットにまたがっています。 問題バンク n 差 統計量 1 問あたりの呼び出し --- --- --- --- --- MBPP+（統合 371） 371 +4.58 pp 95% CI +0.57, +8.04 1.51 LCB v2（難問） 120 +19.17 pp b=31 c=8、 p=0.0003 1.71 LCB v3 189 +7.94 pp b=25 c=10、 p=0.0167 1.55 同予算での比較：ゲートが投票に勝つ これは最もきれいな比較です： 同じ 5 つの候補、同じ 5 回の呼び出し で、一方"},{"t":"帰属","u":"/ja/docs/attribution.html","g":"中心概念","s":"「誰が何をしたか」が成り立つには、鍵の保管、決定論的なサンプリング、記憶がイベントストリームに付いて回ることの三つが同時に真でなければなりません。どれか一つでも欠ければ、帰属は「ある参加者がこれをした」ではなく「ある鍵がこの記録に署名した」で止まります。","b":"帰属の三つの条件 条件 現状 証拠 --- --- --- 鍵の保管 成り立たない 現行の製品経路の秘密鍵は同じ OS ユーザーが読める平文ファイルで、ハードウェアによる保護はない 決定論的なサンプリング 部分的に成り立つ 決定論的リプレイは本物の錨だが、サンプリングのシードが固定で公開されており予測できる 記憶がイベントストリームに付いて回る 成り立つ 評判の会計単位はイベントストリーム。モデルを替えたり記憶を消したりすれば、信用は引き継がれない この文は でもう一度登場し、そこではその具体的な帰結が述べられます。 分身の身元 vacant_id は公開鍵から 導出される もので、照会して得るものではありません。 そのため誰でも公開鍵から識別子を再計算でき、 中央の名簿を照会する必要はありません 。これは「中央の審判はいない」という原則の具体的な実装です。 結びつけの三つの切れ目 独立審査（2026-07-26、対象コミット f9a381a ）は、 vacant_id の結びつけの連鎖に三つの切れ目を見つけました。三つ目は今も修正されておらず、修正ブランチが意図的に残した未解決項目です。 ① vacant_id → stream_id はまったく検証されていない registry.py:78-82 は公開鍵 ↔ vacant_id を再計算していますが、 vacant_id ↔ stream_id については 一つの検査もありません 。 CapabilityCard には stream_id フィールドまでありますが、登録所はそれを一度も読みません。 ② なりすましで評判を引き継げる 誰でも他人の stream_id を名乗り、その相手の評判を引き継げます。攻撃 PoC の実測： 0.50 → 0.7417 。これは「シグナルを安価に偽造できない」という必要条件の直接の失敗です。 ③ slash は低得点者にとって報酬になる slash は証拠の比率を保ちます——数学的には「記録をちょうど半減期の半分だけ古くする」ことと同じです。高得点の破壊者では、UBB はむしろ "},{"t":"ゼロ設定の Vacant","u":"/ja/docs/zero-config.html","g":"中心概念","s":"インストールすればそのまま働き、設定は一切要りません。することは一つだけ：同じセッション内で一度だけ言葉を送り返します。その代わり三つの部品——実行可能なシグナル、やり直させる権限、納品を拒否する権限——が欠けています。四つのバッチのうち三つで差が測れませんでした。","b":"ゼロ設定は v0.9.0 の製品の主線 です。設計目標は多くをこなすことではなく、 インストールした後もいつもどおり使えること です——契約を結ばず、設定を足さず、ワークフローを変えません。 {{note:warn このページが何について述べ、何について述べていないかを先に明確にします このページのタイトルは「ゼロ設定」なので、 を置き換えたものだと思われがちです。 置き換えていません。 二つの違いは版の新旧ではなく、 仕組みそのもの です。CONFORM は生成を握ります：どの候補にも可視の受け入れ検査を実行し、通らなければ再サンプリングし、最大五つ、すべて通らなければ納品を拒否します。ゼロ設定は生成を握らず、エージェントが「完了しました」と言ったその瞬間に、同じセッション内で一度だけ言葉を送り返すだけです。 このページに載せているのはゼロ設定自身の実験結果です。四つのバッチのうち、三つで差が測れませんでした。四つ目では測れましたが、推論エンジンを替えると再現しませんでした。}} 何をするか 中心は 納品前チェック です：エージェントが「終わりました」と言ったその瞬間に、書き出すよう求められたファイルがあるか、テストを実行したか、失敗した手順が飛ばされていないか、出所の分からない数字がないかを確認します。 設計原則は 「ほぼ確実に本当の問題であるものだけを差し戻し、それ以外はすべて納品説明に書くだけにする」 です。 差し戻しの種類 ターン上限 理由 --- --- --- 出所のない具体的な値 2 七つの条件がすべて成り立つ必要がある タスクが名指ししたファイルを開いていない 1 テスト済みと言うが記録と合わない 2 失敗した手順が飛ばされた 2 書き出すよう求められたファイルが存在しない 2 DABstep の答えには可視テストがないため、この種類が主なトリガーになる それ以外は「納品説明」に書いて人に見せ、差し戻しはしません。 ターン予算のリマインダーは v3.6 から既定でオフになっています。 理由は測定できるトレードオフです。 リマインダーは正答率を 51.9"},{"t":"アカウンタブル・トレース","u":"/ja/docs/accountable-trace.html","g":"中心概念","s":"汎用の受け取り口は「この納品物は合格か」には答えますが、どこが不合格か、どの手順で誤ったか、誰が誤ったかは言えません。トレースは手順まで切り込みます：どの結論も二層に分かれ、再実行で反転を示せる層だけが評判上の帰結につながります。","b":"論文の一文による位置づけは「 誰が何をしたかが分かり 、誤りが起きたときにたどり戻せる」です。 と汎用の受け取り口がしていたのは後半の「誤りが起きたとき」だけで、しかも三つのものが欠けていました。 それは どこ が不合格か（ ClaimResult に位置がない）、 どの手順 で誤ったか（手順の記録がない）、 誰 が誤ったか（行為者がいない）を言えず、フィードバックは汎用の文章だった。 2026-09-24、人間が受け取り口を全面的に使ってみた後の生の言葉： 今のこの版は、ローカルで検証に使える検証器を複数持たせるものであって、 責任を問い誤りの箇所を突き止める ものではない。（原文：「你現在的這個版本是讓本機多個可以去驗證的驗證器， 並非是咎責且抓出錯誤點 的東西。」） トレースはこの三つを補うものです。同じラウンドで四つのことが確認されました：責任を問う対象は 手順と行為者の両方 であること。誤りの箇所とは 誤りを生んだ手順までたどる ことであること。帰結は 評判＋ルーティング であること。利用場面は 人が一つのエージェントを直接使う ことであること。 「誤り」の出所は三つだけで、止められるのは最初の二つだけ 出所 止められるか 説明 --- --- --- 契約 止められる 既存の検証器。ここは変えない 人によるマーク vacant flag <path :<行 -<行 \"<どこが誤りか \" 止められる 署名し、納品物の sha256 と位置に結びつける 能動的な決定論的検査 止められない 注意を促すだけで、止めない 能動的な検査は二つだけです： unsourced_number （出所のない数字）、 unhandled_failed_command 。 二層の帰属 これがこの系列全体の中心となる仕組みです。 provable の定義は、三つの条件が 同時に 成り立つことです。 1. 再構築した状態の上で再実行する 2. ちょうどこの手順で 合格から不合格に変わる 3. 誤った値が 固定されたどの入力にも、観察されたどの読み取りにも含まれていない 五つのレベルには"},{"t":"システム構成","u":"/ja/docs/architecture.html","g":"システム構成","s":"Vacant は七つの層からなります。L0 身元、L1 署名付き記録、L2 アカウンタビリティ層、L3–L4 実行可能な受け入れ、L5 観測、L6 製品への接続です。四つの仕組みが四種類のごまかしに対応し、どれにも実測された失効条件があります。","b":"位置づけ プロジェクトの中核文書は、Vacant の役割を一文で書いています。 AI を信頼できるものにするのではなく、「誰が何をして、誰が確認し、どれだけ丁寧に確認したか」を 後から書き換えられない記録 に変え、さらに悪い仕事をした参加者が仕事を受け取りにくくする。 2026 年 9 月以降、この位置づけはさらに具体化されて 受け取り口 になりました。検証可能なレシートのない納品は受け入れられません。 この位置づけは、よくある二つの誤読を意図的に避けています。 - Vacant は別のエージェントフレームワーク ではありません 。エージェントがどう推論し、どうツールを呼ぶかを代わりに決めることはしません。 - Vacant はエージェントの外側にかぶせて、すべてを確実に遮断する強制層 ではありません 。Saltzer と Schroeder（1975）の完全仲介の原則はすべてのアクセスが検査を通ることを求めますが、既定の構成での受け取り口はこれを 満たしていません 。 七つの層 層 名称 誰のものか 構築された時期 --- --- --- --- L0 暗号学的な身元 ゲートウェイ 2026-06 L1 署名付き記録（イベントチェーン） ゲートウェイ 2026-06 L2 アカウンタビリティ層 ゲートウェイ 2026-06～08 L3 問題バンクとサンドボックス 実行フレームワーク 2026-08 下旬から L4 実行可能な受け入れゲート 実行フレームワーク 2026-09-03 L5 観測と展示 ゲートウェイ 2026-07～09 L6 製品への接続（ vacant run / on / agentlane ） 利用者 2026-09-18 から L0–L2 がアカウンタビリティ層の本体です。L3、L4 は、利得の実験で「意見の代わりに実行する」ための実行対象を用意するために作られました。L6 は 9 月以降に加わった製品層です。 四つの仕組み、四種類のごまかし 仕組み 対象とする行為 強さ --- --- --- 署名付きハッシュチェーン 記録を後から書き換える "},{"t":"身元と署名付き記録","u":"/ja/docs/identity-logbook.html","g":"システム構成","s":"住人はそれぞれ Ed25519 の鍵ペアを持ち、vacant_id は公開鍵から導出されるので名簿を引く必要はありません。イベントチェーンの各レコードは八つのフィールドを持ち、追記のみで、すべての署名は正規化 JSON のバイト列を対象とします。","b":"L0 暗号学的な身元 参加者（プロジェクトでは「住人」と呼びます）はそれぞれ Ed25519 の鍵ペアを持ちます。 vacant_id は導出されるもの 誰でも公開鍵から識別子を再計算でき、 中央の名簿を照会する必要はありません 。これは「中央の審判を置かない」という設計原則を具体化したものです——どの表も権威を持ちません。 ディスク上の配置：信頼ストアと能力ストアを分ける ストア 内容 所有者 --- --- --- 信頼ストア 秘密鍵、公開鍵、イベントチェーン、評判のスナップショット、能力カード ゲートウェイ 能力ストア エージェントの設定と記憶 エージェント 設計原則は「 身元を頭脳に晒さない 」です——エージェントの推論過程は署名鍵に触れられません。 能力カード（halo） 住人はそれぞれ能力カードを一枚持ち、公示として使います。登録所（Registry）はこれらの公示の 集約照会インターフェースと評判の索引 にすぎず、中央のルーターでも、信頼されなければならない存在でもありません。相手が見つかれば、双方はピアツーピアで直接つながります。 登録所は「stream 所有権表」を管理しており、 先着順 です——創世イベントを添えた者が暗号学的な証明を持ちます。登録所はさらに、納品のたびに観察したチェーン先頭を記録し、 チェーン先頭は前進するだけで、巻き戻すことはできません 。 L1 イベントチェーン 住人はそれぞれ 追記のみ のイベントチェーンを管理します。各イベントはちょうど八つのフィールドを持ちます。 フィールド 説明 --- --- stream_id イベントストリームの識別子 branch_id ブランチ seq 通し番号 prev_hash 一つ前のレコードのハッシュ ts_ms ミリ秒単位のタイムスタンプ type イベントの種類 payload 内容 sig Ed25519 署名 一つのイベントの上限は 64 KiB です。 検証する三つのこと 1. 通し番号が連続している 2. 一つ前のハッシュが一致する 3. Ed25519 署名が有効である 署"},{"t":"登録と評判","u":"/ja/docs/registry-reputation.html","g":"システム構成","s":"評判は（イベントストリーム, ブランチ, モデル基質, タスク族）の四つ組に記録され、五次元の Beta 分布と UCB ルーティングを使います。新規参加者には見習い期間の上限があります。罰則の副作用は永久排除です——368 個のシードのうち戻ってきたのは 0 個でした。","b":"評判の会計単位 評判は「一つのエージェント」に記録されるのではなく、 四つ組 に記録されます。 要素 なぜキーに含まれるのか --- --- stream イベントストリーム 信用は 記憶 についていき、 身体 にはついていきません。同じ鍵でも記憶を消して創世イベントを作り直せば、新しい stream になり、信用は自然にゼロに戻ります。 branch ブランチ 同じイベントの並行するブランチは別々に数えます substrate モデル基質 「モデル A で積み上げた信用を、モデル B の納品の隠れ蓑に使う」ことを防ぎます family タスク族 「この参加者が全体として信頼できる」ことと「この参加者がこの種類の問題を得意とする」ことを区別します タスク族は 2026 年 8 月 7 日に加わりました。交換記憶システムの研究にある「誰が何を知っているか」の区別に対応します。 五次元の Beta 評判の各セルは、五つの次元それぞれに Beta α, β 分布を持ち、事前分布は Beta 1, 1 です。 次元 測るもの --- --- 事実 記述が検証可能な事実と合っているか 論理 推論が成り立っているか 的確さ 問われた問題に答えているか 誠実さ 隠したり誤導したりしていないか 採用 他者が実際にその出力を採用しているか 点数が s ∈ 0,1 、重みが w の評価一件によって、次のように更新します。 評判スコアは五つの次元の 事後平均の平均 です。 減衰 評判は 半減期 200 イベント で事前分布へ回帰します。 ルーティング：信頼上限 N は観測の総数、 n はその候補の有効観測数です。 観測記録のない新しい候補は非常に大きな探索ボーナスを得るため、 必ず一度は試されます 。アカウンタビリティ層を無効にすると、ルーティングはタスクのハッシュで決まる決定的なランダム選択に切り替わります——二つのモードの違いはブール値のスイッチ一つだけで、インターフェースは同じです。 見習い期間 新規参加者は最初の m = 2 回の納品のあいだ見習い状態にあります。 - 見習いでない候"},{"t":"ピアレビューと監査","u":"/ja/docs/peer-review-audit.html","g":"システム構成","s":"納品はどれも三人のピアが評価し、ホワイトリストはなく、重みは評判から内生的に決まります。監査はモデルにもう一度聞くことではなく、サンドボックスでの決定的な再実行です——盲点はゼロではなく、人数を増やしても独立した情報は増えないからです。","b":"ピアレビュー（K = 3） 評価者は タスクのハッシュと住人の名前のハッシュによる並べ替え で選ばれ、 自分自身は評価しません 。結果を登録所に書き込む前に四つの検査を通らなければなりません（ を参照）。 ホワイトリストはない 公示さえすれば誰でも評価できます。重みは評価者自身の評判から 内生的に 決まります。 score_r と obs_r は、評価者の 同じモデル基質 での評判と観測数です。新参者の票はとても軽いですが、 票は持っています 。 ホワイトリストがないことの代償：票の水増し 三段階の重み引き下げで対応します。 段階 条件 上限 --- --- --- ① 同一制御者の自己申告 同じ制御者の評価者のうち、同じ対象に対する k 人目 0.1 / k ② 行動から推定した同一出自 二人の評価者が「識別力のある問題」で一致率 ≥ 0.9、かつその種の問題を共同で評価した数が ≥ 5 問 0.1 / k ③ 未証明の評価者 自身の観測 < 5 で、同じ対象に対する k 人目 0.1 / k 第 ③ 段階のねらいは、N 個の匿名の身元の集団としての寄与をおよそ 0.1 × 調和數 H_N にし、 線形ではなく対数的に増えるようにする ことです。修正前は、200 個の匿名の身元がそれぞれ一票を投じると 10.0 の重みを積み上げられました。 詳しくは を参照してください。 評価は自分の向きを捕まえられない 攻撃実験は「行動から推定した同一出自」について段階ごとのアブレーションを行いました。 どの段階を切ったか 中傷スコア --- --- すべて有効（基準） 4.2 重みの内生化を切る 3.8 自己申告 の同一出自を切る 4.2（すべて有効の場合とビット単位で同一＝純粋な飾り） 行動推定 の同一出自を切る 11.4（2.7 倍） 、共謀者の評価の重みは 0.015 → 0.322（21 倍） すべて切る 10.7 決定的なサンプリング監査 監査は 言語モデルにもう一度聞くことではなく 、サンドボックスの中で客観的な検査を再実行し、環境の真値で判定するものです。 ある納品"},{"t":"実行可能な受け入れ層","u":"/ja/docs/executable-acceptance.html","g":"システム構成","s":"可視テスト V は通すために使い、非公開テスト GT は事後の採点にだけ使います。サンドボックスによって、候補プログラムは構造的にテストコードを見られません。受け入れスイートはプログラムではなくデータです。そうでなければ、攻撃者はゲージを両方向で満点にしながらごみを納品できます。","b":"L3 可視と非公開の分離 各問題の要求は三つの部分からなります。 問題文 、 公開された入力の契約 、 受け入れテスト です。 受け入れテストは二組に分けます。 誰が見られるか 用途 --- --- --- 可視 V エージェントが読める システムはこれで通すか納品を拒否するかを決めます。修正の流れが受け取れるのもこれの失敗メッセージだけです 非公開 GT 事後の採点だけ 生成、選択、修正のプロンプト、停止条件のどれにも入れてはなりません プログラムが 可視テストには合格したが、非公開テストには合格しなかった とき、それが一回の 偽の納品 です。これは「出力は要求のように見えるが、要求ではない」という問題を操作可能にした形です。 動的監査：非公開テストが漏れ込んでいないか 版 やり方 結果 --- --- --- v1 キーワードの照合 偽陽性 90 件 v2 「この文章を誰が書いたか」を判定基準にする R460R と R529 の全 67 ブロックで違反ゼロ 。独立したプロセスが 2,497 件の提出テキスト、164,963 個の照合項目を走査し、ヒットはゼロ（陽性対照つき） 全アームの遡及的な追加走査（2026-09-18） 179 件の記録、約 349 万の照合項目 165 件が違反なし、10 件が検証不能、4 件が違反と判定 （4 件はいずれも完了していない R530 のもの） サンドボックス 候補プログラムは 独立したプロセス で実行されます。 制限 値 --- --- 時間 10 秒 メモリ 128 MiB 作業ディレクトリ 一時ディレクトリ 環境変数 継承しない テストプログラムと候補プログラムは 別々の二つのプロセス に置かれ、ランダムな標識を付けた、リテラル値だけを許すリモート呼び出しで通信します。これにより候補プログラムは 構造的にテストコードを見られません 。 実測（2026-07-09、24 回の呼び出し、思考モード有効）の遅延：中央値 9.1 秒 、p95 40.0 秒 、最大 41.7 秒 、合計 5.4 分。Hermes のエンドツーエンド"},{"t":"多者実行","u":"/ja/docs/peer-execution.html","g":"システム構成","s":"分散させるのは実行と証言であって、判断ではありません。意見の食い違いは情報を持たないが、実行の食い違いは情報を持つからです。この道が耐えられる上限は ⌊(k−1)/2⌋ 個の腐敗した実行器で、過半数を超えると結果が反転します。","b":"なぜ「相互に実行し、相互に評価しない」と呼ぶのか 初期に放棄された設計は「分散型の相互評価」でした。多者実行はそれを、相互に実行し、相互に評価しない形に書き換えました。 分散させるのは実行と証言であって、判断ではありません。 理由は一文です。 意見の食い違いは情報を持たないが、実行の食い違いは情報を持つ。 受け入れ検査は決定的なプログラムなので、誠実な実行器は必ず同じ結果を得ます。食い違いが出たなら、誰かが実際には実行しなかったか、自分の実行結果と異なる内容に署名したかのどちらかしかありません—— どちらも帰属可能な過失です 。 三つのこと 1. 実行と署名 ：各実行者は自分のレンダラーとサンドボックスで受け入れ検査を実行し、タスク、候補、スイート、レンダリング結果のハッシュと、可視の受け入れ結果を、自分のイベントチェーンに署名して書き込みます。 2. 票の集約 ：まずスイートがゲージを通るかを検査し、次に 証言を一件ずつ検証します 。同じ実行者が同じイベントについて内容の異なる二つの証言に署名した場合、 証明レベルの過失 とみなして無効にします。 3. 表決と名指し ：残りは多数決で決めます。票数が定足数に満たないか同数の場合は 未決 とし、出荷規則は未決を 不合格 として扱います。少数側は、そのイベントハッシュと署名を添えて 名前を挙げて列記されます 。 耐えられる上限 過半数が共謀すると結果は 反転し 、誠実な側がかえって名指しされます。しかも 仕組み自体は、自分が閾値のどちら側にいるかを知りません 。 スキャンのバッチ 過半数を超えた後の誣告率 --- --- r446（371 問 × 5 候補） 0.175 r443（91 問 × 5 候補） 0.374 シミュレーションのスキャン：人を増やすより規則を替える 200 セルのスキャン（r446 371 問 × 5、r443 91 問 × 5、k ∈ {1, 3, 5, 7}、腐敗比率 0–70%、五種類の攻撃）： 発見 数値 --- --- 腐敗比率を固定すると、k を 1 から 7 にしても納品率は一字も変わ"},{"t":"製品接続層","u":"/ja/docs/product-integration.html","g":"システム構成","s":"三種類の接続形態は強制の度合いが違います。`vacant run` は「プロセスの終了」を納品の時点とし、隔離壁は bwrap で独立した名前空間を作り、出口は release/publish の能力分離で扱います。エージェントは自分のフックを削除できます——だからフックは補強にすぎず、信頼の根ではありません。","b":"三種類の接続形態 形態 強制の度合い 説明 --- --- --- ライブラリ／MCP ツール 任意 エージェントが自分の設定に Vacant の MCP サーバーを登録し、 delegate などのツールを呼び出せます。エージェントが呼び出さなければ、Vacant には介入する手段がありません。 コントローラー 自分で起動した子プロセスに対してだけ まず委任し、受け入れ検査をしてから、下流のエージェントを起動します。保証がカバーするのはこのコントローラーを通して起動したプロセスだけで、同じ OS ユーザーはこれを迂回してエージェントを直接実行できます。 ループを持つ実行フレームワーク 完全に強制 生成、受け入れ検査、出荷をすべて制御します。利得実験の runner はこの種類に属します。 コントローラーのソースコードのコメントには、この境界がはっきり書かれています。 保証がカバーするのは、このコントローラーを通して起動した子プロセスだけである。 vacant run ：プロセスの終了を納品の時点とする 2026-09-18 に加わりました。 一つの観察 の上に成り立っています。 納品を差し止めたいだけなら、トリガーはネットワークプロトコルの上にあるのではなく、 エージェントのプロセスが終了するその瞬間 にある。 このシグナルは完全に信頼でき、プロトコルの知識を一切必要とせず、token を消費せず、しかも すべてのフレームワークで成り立ちます 。 流れ 1. ローカルのプロキシサーバーを起動し、一覧に従ってエージェントの base URL 環境変数を設定します。 本物の上流アドレスと鍵はエージェントの環境から取り除き 、プロキシサーバーのプロセスにだけ残します。 2. ワークスペースの ツリーハッシュ を記録します。 3. エージェントを起動して終了を待ちます。終了したら プロセスグループ全体を終了させ 、孫プロセスが凍結後に書き込むのを防ぎます。 4. 凍結したワークスペースのスナップショット上で可視の受け入れ検査を実行し、ツリーハッシュをもう一度測ります。一致しな"},{"t":"ネイティブプラットフォームと静かな無効","u":"/ja/docs/native-platform.html","g":"システム構成","s":"判定点を agent のプロセスの中に置くと、プラットフォームが協力しないとき「効果が小さい」のではなく、静かに無効になります——カルテは完全で、署名チェーンは検証を通り、判定はゼロです。三つの欠落と、ループを親プロセスに移すという一つの決定について記します。","b":"2026-09-29 時点でのこの線の状態は 設計上の決定であり、効果は未測定 です。このページは、そこで測られた三つの欠落を記録します。 三つの欠落 W1 — 経路の仲介が認識する鍵の変数は二種類だけ envmap.py の SECRET_VARS からは OPENROUTER_API_KEY が削除されており、 discover_keys は openai と anthropic の二つしか読みません。 測られた結果：opencode の openrouter provider は ローカルで 1.2 秒以内に rc=1、 requests_seen = 0 となり、wire は一度も送られませんでした 。固定ポートの openai-compatible provider に替えると requests_seen は 2 になりました——経路の仲介は opencode に対して通じていますが、 opencode は依然として非ゼロのコードで終了します。この道は最後まで通っていません。 W2 — opencode には stop に相当するイベントがない vacant install が生成する opencode plugin が登録するのは chat.message 、 tool.execute.before 、 tool.execute.after だけです。pi の同名のテンプレートには ask \"stop\", … がありますが、opencode のテンプレートにはありません。Python 側の EVENT_MAP には \"opencode\": {… \"stop\": \"stop\" …} が あります 。したがって欠けているのは plugin の側です。 一つのセルを実測したときの署名チェーンのイベント集計： 作者自身の言葉： 37 個の step の完全な署名付きカルテ、判定はゼロ。これはやらないより危険だ。receipt が正しく見えてしまうからだ。 （原文：「37 個 step 的完整簽章病歷、零個裁決。這比不做更危險，因為 receipt 會看起來是對的。」"},{"t":"実験方法と判定値","u":"/ja/docs/experiments.html","g":"実験","s":"四つの実験手法ファミリー、判定値の六つの状態、事前に宣言した四つのルール、そして再検証を受けてから書かれた四つの分析の規律。このページは、すべての数字を読むための前提です。","b":"二つの軸 2026-08-17 から、本研究はすべての実験を正式に二つの軸に分けました。これは研究全体で最も重要な構造の調整でした——それまでに積み上げた実験はすべて「悪いものが止められたか」を問うもので、 「この層を加えたら、納品されるものが要求により合うようになるか」を問うものは一つもありませんでした 。 軸 問い 方法 --- --- --- 防御軸 意図的に誤ったものを納品する参加者がいるとき、このルールがどれだけ防げるか メカニズムのシミュレーションが中心 利得軸 要求が実行可能な受け入れテストにコンパイルできるとき、納品成功率がどれだけ上がり、代償にどれだけの token がかかるか 実モデルでの対応のある実験 四つの手法ファミリー 1. メカニズムのシミュレーション（E1–E9, E12–E24, A1–B5, M1–M5, S1–S3） 答えること ：このルールのもとで、ある攻撃戦略や仕組みのパラメータにどれだけの価値があるか。 本物であるもの：ルーティング（本物の Registry.route 、UCB + 見習い期間の上限 0.55 + 10 ラウンドごとの見習い枠）、監査（本物の Auditor 、 sha256 seed:task_id による決定的サンプリング）、評判（本物の Reputation 、五次元 Beta、乗法的 slash、per-stream 半減期 200 イベント）、署名（本物の Ed25519 と hash-chain）。 シミュレーションしているもの ：「この納品が良いか悪いか」だけです——それはもともと実験処理であって、仕組みではありません。 制御していないもの ： - 攻撃者の戦略空間はハードコードされた三〜四種類です。現実の攻撃者はもっと強いかもしれません。 - 単一の攻撃者 + 5 人の誠実な住人という固定の生態系規模。 - 盲点の真の値は不明です（外部のアンカーがない）。 2. 実モデル実験 答えること ：パイプライン全体が実モデルで動くか。信頼層のオン・オフで測定可能な差があるか。 手順：EvalPlus M"},{"t":"防御軸","u":"/ja/docs/defense.html","g":"実験","s":"攻撃者がどれだけの仕事を手にできるか。本研究の索引にあるこの軸の 12 件の主張のうち、3 件は自分で反証し、3 件は言い過ぎでした。それでも悪い参加者を抑える仕組みは確かに効いており、効いているのは「捕まえられる」ことではなく「飢えさせられる」ことです。","b":"この軸が答える問い 意図的に誤った納品をする参加者がいるエージェント集団において、署名付きの記録、評判ルーティング、ピアチェック、抜き取り監査、ペナルティが、誤った納品が受け入れられる機会をどこまで減らせるか。 最も効いたもの：捕まることではなく、見られること これは防御軸で最も強い肯定的な結果であり、しかもそれは「捕まえられる」ことではありません。 群 9,600 ラウンドで得た仕事 --- --- 一度も捕まらなかった 215 のシード 7 – 24 件 一度も違反しない対照群 1,290 件 言い換えると、 捕まらなかった悪意ある参加者が得た仕事は、誠実な参加者の 0.57% – 1.84% にすぎません。 結論を一文で書くとこうです。 攻撃者を止めたのは「見られること」であって、「捕まること」ではありません。 評判ルーティングだけで彼らを飢えさせるのに十分で、一度捕まえる必要すらありません。 （出典： runs/s5_v1_FINDINGS.md ） 参入コスト：どちらの道も選ぶべきではない 2026-07-26、14 本のメカニズムのシミュレーション（セルごとに 20 シード、E9 は 40、E15 は 30。400 ラウンド。誠実な参加者 5 + 攻撃者 1。監査率 0.2、E2/E3 以降は 0.05。評価者の正確度 0.7 は著者が選んだ値で、測定していません ）。 本当の制約は評価者の正確度 評価者の正確度 攻撃者へのルーティング 攻撃成功 ROI --- --- --- --- 1.0 18.0 1.90 ± 0.30 0.119 0.7 — 2.35 — 0.5 — 2.70 — 0.3 — 4.30 0.269 0.0 33.6 16.65 ± 12.89 1.041 acc = 0 は、表全体で唯一「不正が割に合い始める」セルです。 ほかのすべてのパラメータ——参入料、推薦者の連帯責任、見習い期間の長さ——は、評価者の正確度という制約には及びません。 参入料を低くしすぎると、かえって攻撃者を助ける 外生的な保証金 攻撃成功 ROI 完全阻止率 "},{"t":"利得軸","u":"/ja/docs/gain.html","g":"実験","s":"最も力を注ぎ、最も多く自分を反証した軸です。見出しは「AI 評価者は多数決に負けた」、結論は「実行可能な受け入れゲート＋再サンプリングは有効、修正ループの追加の利得は同符号・未解決」です。","b":"この軸が答えること 要求が実行可能な受け入れテストにコンパイルできるという条件のもとで、受け入れゲート、再サンプリング、失敗フィードバックによる修正が、 それぞれ 納品成功率にどれだけの利得をもたらし、その代償にどれだけの token がかかるか。 始まり：委員会型の設計は負けた 初期の G シリーズ（探索的） 等予算での比較（同一問題、同一呼び出し数）： 比較 n 結果 p --- --- --- --- ON vs OFF5（371 タスク） 347 82.42% vs 83.57% 0.5572 OFF5 vs OFF（ 等予算ではない ） 349 83.09% vs 78.51% 0.0090 重要な発見 ：OFF5 アームはコードに accepted = True が書き込まれていました—— 拒否という経路を持っていなかった のです。したがって上の比較は、実際には「無償のゲートを持つアーム」対「拒否を禁じられたアーム」でした。 R437 決定的な三アーム run 事前に定めた三つの判定基準（2026-08-24/28 凍結）： 判定基準 判定 --- --- ① OFF の失敗率が 20–60% に入る ✓ 26.44% （Wilson 20.4, 33.4 ）—— ゲージにシグナルがある ② 三アームに識別可能な差がある 測れなかった （それ自体が答え） ③ ON が等予算で OFF5 に勝つ ✓ 答えは「勝たない」 R438 メカニズム分析（成立） 指標 数値 --- --- 評価者の票の正解率 0.7552 「すべて合格と判定する」ゼロ知能ベースライン 0.7522 差 +0.29 pp 単一ラウンドの修正で「修正の機会がなかった」 93 / 113 修正版を盲目的に採用した後の非公開評価合格率 82.3% → 78.8%（−3.5 pp） 修正による本当の改善 1 / 113 二つの仮説はどちらも排除された 人間が 2026-09-01 に二つの説明を出しましたが、どちらも自分たちの実験で排除されました。 H-A 天井：worker が強すぎる 単一の"},{"t":"記録と多者実行","u":"/ja/docs/records.html","g":"実験","s":"レシートチェーン 194 本、9,841 件はすべて検証を通りました。嘘をつく鍵は 273/273 で名指しされ、誠実な参加者が誤って告発されたのは 0/1,840 でした。しかしチェーン検証は切り詰め・分岐・記録漏れを捕まえられず、相互実行は「受け入れスイート自体の腐敗」に対してまったく防御がありません。","b":"レシートチェーンの検証 バッチ チェーン数 件数 結果 --- --- --- --- R460R（5 回の再現） — 6,674 すべて合格 R529（問題バンク横断の 4 セット） — 3,167 すべて合格 合計 194 9,841 すべて独立した署名検証に合格 R532（より大きなモデル） 86 3,895 すべて合格 ABPI 監査 195 — すべて合格 R454（多者実行） — 証言 5,519 件 署名検証の失敗 0 回 E10（チャネル分離の改版後） — 評価者封筒 180/180 通 引き続き検証可能 検証しているのは三つです。連番が途切れていないこと、一つ前の記録のハッシュが一致すること、Ed25519 署名が有効であること。対象範囲は CONFORM と三つの H アームだけです—— OFF と OFF5 アームにはレシートがありません 。 V/GT 漏えい監査 バージョン 範囲 結果 --- --- --- v1 — 偽陽性 90 件 v2 R460R 30 ブロック + R529 37 ブロック 違反ゼロ v2 独立プロセス 提出テキスト 2,497 件、照合項目 164,963 個 ヒットゼロ （陽性対照付き） 全アームの遡及再走査（2026-09-18） 記録 179 件、照合項目約 349 万 違反なし 165、検証不能 10、違反と判定 4 その 4 件の違反は すべて完了していない R530 のものです 。R460R の最初の 3 回の内訳：照合項目 95,090 個のうち、57,248 を検査、37,842 をスキップ（39.8%）。 多者実行：互いに実行し、互いに審査はしない シミュレーションによる掃引（200 セル） 発見 数字 --- --- 腐敗の比率を固定すると、k を 1 から 7 まで変えても納品率は一字も変わらない 共謀 67.39%、破壊 0% k=3／定足数=2 で一票欠ける 1-1 の同数 → 未決、名指しなし 実際の実行 実験 規模 結果 --- --- --- R453 マシン間の一貫性 368 タスク "},{"t":"証拠台帳","u":"/ja/docs/evidence-ledger.html","g":"証拠と再現","s":"外に向けた主張 58 件のそれぞれに、判定値、根拠となる数値、再計算の方法があります。反証されたもの、言い過ぎだったもの、差が測れなかったものも、すべて表に残しています。説明責任を問えると称するシステムは、まず自分自身に対して説明責任を問えなければなりません。","b":"この表の成り立ち 各主張には四つの要素があります。 1. 原文 — 当時、外に向けて何と言ったか。 2. 根拠となる数値 — それを支える数字。分母付き。 3. 判定値 — 六つの状態のいずれか。 4. 訂正後 — 判定が「反証」または「言い過ぎ」の場合、正しい言い方は何か。 統計 台帳の全体 どの行もクリックすると展開され、根拠となる数値、元の記録のパス、再計算の方法が見られます。 判定はどこに集中しているか この節では 本研究の正式な索引にある 34 件 だけを整理します（以下の括弧内の件数は、すべてこの 34 件を分母としています）。repo 判定の 24 件は上の台帳の全体にあり、フィルター行で「軸」または「判定」を切り替えれば見られます。 反証（34 件中 6 件）——すべて防御軸と「同一予算」 ID 主張 反証された理由 --- --- --- pulse.crossover 盲点が 0.5–0.75 を超えると、パルスは持続的な悪事に劣る 対応のある差 −0.57、95% CI が 0 をまたぐ。実測では盲点 1.0 での pulse の成功数は 81/84/87 で、 すべて patient の 79 を上回る pulse.audit_cannot_close_blindspot 監査を増やしても、盲点のある状況は救えない 盲点 0.5 のとき、監査を 0.1→1.0 にすると総成功数が 82% 減少 、Wilcoxon p=5.5e-6 pulse.crude_wins_under_blindspot 同一予算では crude がパルスに勝つ E19 はそもそも同一予算の比較ではなかった。実際の悪事の回数は 11.97 vs 4.87 。正しく budget=2 に揃えると 1.67 vs 0.97、 p=0.0015 gain.equal_budget_on_beats_off5 同一予算では Vacant が五回の多数決に勝つ 対応ありの全体で p=0.4531、難問のサブセットで p=1.0 gain.ceiling_hypothesis 弱いモ"},{"t":"再実行の方法","u":"/ja/docs/reproduce.html","g":"証拠と再現","s":"手順を一つずつここに並べます。メカニズムのシミュレーション、実モデルのスイート、API を使わないオフライン再生、レシートチェーンの検証。統計的な結論の大部分は、API を使わない再計算スクリプトで再実行でき、モデルは一切使いません。","b":"なぜ大部分の結果をコストゼロで再実行できるのか 利得実験の元の記録はすべて rows.jsonl に一問ずつ書き出されており、 arm / task_id / delivered / hidden_pass / calls_used の五つのフィールドを含みます。つまり 統計的な結論のためにモデルを呼び直す必要はありません 。 メカニズムのシミュレーション 完全に決定的です。 rng のシード = f'{seed}:{config_digest}' なので、 同じパラメータなら必ず同じ結果になります 。 実モデルのスイート --- --- 問題バンク EvalPlus MBPP+ v0.2.0（378 問、 sha256 で固定 ） 品質判定 アームの外 での compile_check t.check answer 対応キー task_id = sha256 prompt + tests 、アーム間で安定 統計 McNemar の正確検定 + 固定シードの bootstrap 95% CI + 検出力 再開 arm, i をキーにしており、中断しても最初からやり直す必要なし レシートチェーンとオフラインビューア オフラインの単一ファイルビューアもこのサイトに置いています。そのままダウンロードして使えます。 ファイル サイズ 内容 --- --- --- receipt_viewer.html /exhibit/receipts/receipt_viewer.html 0.3 MB 単独実行 receipt_viewer_multiparty.html /exhibit/receipts/receipt_viewer_multiparty.html 4.5 MB 多者実行 どちらも Vacant リポジトリの examples/ からそのままコピーしたものです。 - レシートはファイルに埋め込まれています - 外部リソースゼロ、ネットワークリクエストゼロ - 保存して file:// で直接開いても、チェーン全体の検証を最後まで実行できます {{note:limit こ"},{"t":"研究の経緯","u":"/ja/docs/journey.html","g":"証拠と再現","s":"「エージェントが自発的に採用する責任構造」から「検証可能なレシートのない納品は受け取らない」へ。九か月のあいだに定義を五回変え、自分の主張を六つ反証し、三つの攻撃名を手放しました——この表はその道筋です。","b":"なぜ経緯をドキュメントに入れるのか なぜなら、 説明責任を問えると主張するシステムは、まず自分自身に対して説明責任を問えなければならない からです。これは設計原則の六番目であり、本研究が自分自身に対して証明できる唯一のものです。 ここに最終版の結論だけを置けば、外部の人には、私たちの言い分が「考え抜かれた」ものなのか「たまたま問われなかった」だけなのか判断できません。だから反証された道筋はすべて残しています。 ノード 日付（2026） 出来事 --- --- 4 月 研究提案「責任構造に基づくエージェント間協調プロトコル」。中心となる比喩：今のエージェントは「 免許も、記録も、結果責任もない医者 」のようなもので、どれほど腕が良くても誰も手術を任せようとしない。 04-28 一回目の指導ミーティング。テーマは Harness Engineering（「鞍馬機制」）。「なぜ誰もエージェントを使わないのか？」→ 痛点は信頼性。指導教員は AI が書いたように見えない 提案書を出すよう求めた。 04-30 0430 コンセプト技術概要。四つの生産上の優先事項：責任呼び出し／タスクをまたぐ持続運用／分散型の責任アーキテクチャ／多次元の評価シグナル。責任は 人やシステムに対して払うのではなく、自分の未来に対して払う ；ネットワークが裁定する。 ~4 月末 現時点の認識の総まとめ v0.4。登録所を中央コンポーネントとしていた時代で、9 つの誤解を明確に訂正し、「中央の LLM はない」を確立。 05-01/02 理論文書 V3 → V4 → V5。V3：攻撃ベクトル 20 本。V4：T1–T7 の研究ライン、Ricoeur の idem/ipse/character、H1–H5 の定量化。V5：鍵保管の前提、 P/D/C の誠実な防御言語 。二ラウンドの敵対的レビュー。 05-07 から 05-12 Claude Code プラグイン、PyPI パッケージ、Vacant 企画書。 06-11 から 06-13 合意会議：63 体のエージェントによる批判。 架空の引用と未実装の仕組"},{"t":"限界と保証しない事項","u":"/ja/docs/limits.html","g":"限界","s":"このページでは、システムが保証しないこと、私たちが測れないこと、そして意図的に残している四つの既知の欠落を挙げます。Saltzer と Schroeder の完全仲介の原則はすべてのアクセスが検査を経ることを求めますが、デフォルト構成の受け取り口はこれを満たしていません。","b":"五段階の語彙：外に向けてどの段階まで言えるか のページに完全な表があります。ここでは結論だけを述べます。 2026 年 9 月時点の現状では、外に向けて言えるのは Decided（判定した）までです。 段階 現状 --- --- Observed 観察した 成立済み Decided 判定した 成立済み Withheld 差し止めた デフォルトでは成り立たない Mediated 仲介した デフォルトでは成り立たない （bwrap の隔離壁の下では実験的に成立） Attested 認証した 部分的に成立 （A／B／B′／C の四段階） 完全仲介は成り立たない Saltzer と Schroeder（1975）の完全仲介の原則は、 すべてのアクセスが検査を経ること を求めます。Vacant の受け取り口は、デフォルト構成では これを満たしません 。エージェントが別の経路で成果物を送り出せば、受け取り口からは見えません。 やらない四つのこと --- --- この AI が信頼できると 保証はしません レベルは一回の実行に属し、一つの AI には属しません。 AI を 賢くはしません 展示品 54 セル：30 件を差し止め、 やり直しで救えたのは 0 件 。 テストに書けない仕事の 採点はしません 自動で実行できる受け入れがなければ、審判はいません。 迂回 されない保証はありません 隔離壁に閉じ込めたその一回の実行だけが、すべての通信がゲートを通ります。 システムが捕まえられない四つのこと 1. チェーン検証が捕まえられない三つのこと 切り詰め （信頼できるチェーン先頭がない）、 分岐 （同じイベントについて内容の異なる二本のチェーンに署名する）、 記録漏れ （一度も書き込まれなかったイベント）。 2026-09-19 の実測で三つ目が確認されました。 モデルへのリクエストを一度も送っていない実行が、それでも検証を通るレシートチェーンを生成しました。 2. 相互実行は「スイート自体の腐敗」に対してまったく防御がない 受け入れスイートが「読み込んだだけで合格」に差し替えられたら、 "},{"t":"FAQ","u":"/ja/docs/faq.html","g":"限界","s":"呼び名の比較、自分のプロジェクトに使えるか、LangSmith／OpenTelemetry／ブロックチェーンとの違い、そして何度も尋ねられたのに私たちが「分からない」としか答えられない質問。","b":"これは何か 説明責任を問える（accountable）と信頼できる（trustworthy）は何が違うのか？ 信頼できる はシステムの性質についての判断です。 説明責任を問える は記録の性質についての判断です。 私たちの厳密な定義は、 特定の鍵が署名したイベントの追跡可能性と検証可能性 であり、心理的な意味での信頼は含みません。 なぜ「信頼」を使わないのか：信頼の古典的な定義には「監視しなくてよい」が含まれますが、 監視こそが Vacant のしていることです 。「信頼を高める」と言えば「確認を少し減らしてよい」と読まれてしまいます。それは逆の方向です。 2026 年 7 月の独立したレビューがこの点を言い切りました。結論は一文です。 このアーキテクチャが現在高めているのはアカウンタビリティであって、信頼ではない。 に完全な説明があります。 なぜ Vacant という名前なのか？ 英語で「空いている、誰も占めていない」という意味です。エージェントのエコシステムの中でまだ埋められていない空白を指すのに使っています。エージェントの行動が記録され、検査され、結果を伴うようにする責任の層です。 これは別の AI フレームワークなのか？ 違います。 エージェントがどう推論し、どうツールを呼ぶかを代わりに決めることはしません。 外側を包む層です。あなたが書いた受け入れテストを一度実行し、合格したときだけあなたの手元に届けます。 ほかのものと何が違うのか vs OpenTelemetry／構造化ログ OpenTelemetry Vacant --- --- --- 記録 テレメトリとトレース 署名付きイベントチェーン 完全性の保証 伝送層のベストエフォート 一つのセルを書き換えるとそのセルで切れ、誰でもオフラインで再計算できる 審判 なし あなたの実行可能な受け入れテスト 誰が書けるか 権限を持つ任意のプロセス 鍵が必要 一緒に使えます。Vacant が生成したレシートは、OpenTelemetry の span の属性として扱えます。ただし trace を置き換えるものではありませ"},{"t":"訂正記録","u":"/ja/docs/changelog.html","g":"限界","s":"格下げまたは反証されたすべての主張、訂正されたすべての数字、削除を求められたすべての文を、時系列で一か所に並べています。「出口で止める」から KS-1 まで、研究全体の中で最も読まれるべき部分です。","b":"なぜこのページがあるのか なぜなら、 説明責任を問えると主張するシステムは、まず自分自身に対して説明責任を問えなければならない からです。 このページは、本研究におけるその実践の形です。格下げされたすべての主張、訂正した数字、削除した言い回しを時系列で並べています。完全な対照は にあります。 2026-10-07 サイトのデータ照合 サイト上の数字を一つずつ出典（本研究の _index/claims.json 、論文、Vacant リポジトリの決定文書と結論文書）に照らし直し、次の箇所を直しました。 - zero.reminder_default_off の分母が別のバッチのものでした ：「答えファイルが正しい割合は約 82% → 65%」の横に書いていた分母（A 119、C37 161、C37R 211）は 10-02 の Colab v3.7 バッチのもので、09-26 のローカルバッチのものではありません。現在は二つのバッチを分けて書いています。ローカルバッチは決定文書の原文どおりで、分母は付いていません。Colab バッチは A 97／119＝81.5%、C37 123／161＝76.4%、C37R 139／211＝65.9% です。 - ノートのトップページの統計が「55 件で差が測れない」となっていました ：これはプログラムが 5 と 5 を文字列として連結したもので、正しくは 10 です。しかも「識別可能な差なし」と「同符号・未解決」を足し合わせること自体が、判定値の定義に反します。この欄は取り除き、二つの値を分けて示す判定分布バーに置き換えました。 - no_effect のページ上のラベルを「識別可能な差なし」に統一しました （論文の用語）。以前はサイト上に「識別可能な効果なし」も混在していました。 - 「34 件」が古くなっていました ：トップページ、アーカイブ、ドキュメントのトップ、ノートのトップ、FAQ、実験方法、このページ、そして 4 本のノートがまだ 34 件と書いていました。現在は 58 件です（正式索引の 34 件＋repo 判定の 24"},{"t":"六つの判定値：「差がない」と言わずに「測れなかった」と言う方法","u":"/ja/blog/verdict-values.html","g":"方法","s":"成立、反証、言い過ぎ、識別可能な差なし、同符号・未解決、未再検証——この六つの言葉にはそれぞれ厳密な定義があります。分けておくのは、「測れなかった」が「測ったが、なかった」と読まれないようにするためです。","b":"これはこのサイト全体で最も重要な言葉の組です。 外に向けたすべての主張は、そのうちのどれか一つの枠に入らなければならず 、七つ目の枠はありません。 なぜここまで細かく分けるのか 「測れなかった」と「測ったら、なかった」は別のことなのに、報告書ではしばしば同じ一文として書かれてしまうからです。 - 測ったら、なかった → 「これはこの条件のもとでは効果がない」と言えます。これは情報のある結論です。 - 測れなかった → 「この規模では区別する力がなかった」としか言えません。これは結論ではなく、データの限界です。 私たちの R529 には、ちょうどこの二つが同時にあり、違いがよく見えます。 数字 判定 --- --- --- H-MIX − OFF +7.96 pp 、Holm p = 2.02 × 10⁻⁸ 成立 H-MIX − CONFORM +1.12 pp 、Holm p = .3409 同符号・未解決 同じ実験、同じデータで、一つは成立、一つは未解決。 違いは、差の大きさが閾値を超えたかどうかだけです。 六つの定義 なぜ「同符号・未解決」に独立した枠が必要なのか 私たちのデータファイル claims.json には、自らこの注記が書かれています。 verdict = 未複驗 は、まだ誰も反証を試みていないという意味であり、 合格したという意味ではない 。（原文：「verdict = 未複驗 代表還沒有人試過推翻它，不代表它通過了。」） その claims.json にある 6 件の 未複驗 の多くは、「おそらく間違っていると分かっているが、まだ誰も調べていない」ものです。誠実な扱いは未再検証と表示することであって、成立と表示することではありません。 「識別可能な差なし」はどういう形をしているか 一件だけですが、この研究で最も説得力のある一件です。 その証拠は、 同じデータ、二つの集計方法、逆の向き です。 集計方法 ON OFF5 差 p --- --- --- --- --- 元のまま 75.25% 77.23% −1.98 pp 0.7905 typing ホ"},{"t":"事前登録：なぜ実験を走らせる前に判定基準を書き留めるのか","u":"/ja/blog/preregistration.html","g":"方法","s":"判定基準、統計手法、四つの状態ルールは、すべて実行開始前に凍結し、タイムスタンプを付けています。この記事では、私たちがどのように事前登録を行うか、そしてなぜ「後から判定基準を一つ足す」ことがこの研究では数に入らないのかを説明します。","b":"なぜこれが必要なのか 後から判定基準を選ぶことは、 統計で最もよくある不正の形 の一つであり、しかも誰も嘘をつく必要がないからです。結果を見た後で「もともと通るはずだった」閾値を選び、報告書に書くだけです——その過程で誰一人として悪いことはしていないのに、結論は偽物になります。 私たちは一度それに出くわしました。R440P の §七には「可視フィルタリングは無損失である」（原文：「可見篩選是無損的」）という前提が一つ書かれていました。それは 判定基準 であり、決定文書に書かれていて、問題はないように見えました。 九日後、R440Q がそれを覆しました。 LCB v1 の 91/91 の非公開テストは、すべて可視テストの上位集合 （ V ⊆ GT ）である。（原文：「LCB v1 的 91/91 隱藏測資都是可見測資的超集（ V ⊆ GT ）。」） したがって「非公開テストなら通るが可視テストでは通らない」ことは、構造上 起こりえません 。これは「反例がないことを測った」のではなく、「この命題はこの問題バンクでは恒真である」ということです。恒真の判定基準の検出力はゼロです。 四つの状態ルール R460 の決定文書は 2026-09-07 に四つの状態を固定しました。 状態 発動条件 --- --- EFFECTIVE 区間の下限 0、かつ Holm 補正を通過 INCONCLUSIVE 向きは正しいが、どの閾値も通過しない RULED_OUT 区間の上限 < 閾値（= 効果が閾値より小さいことを確認） 未発動 事前に固定した反証条件が成立（たとえば c ≥ b） 納品拒否は失敗として数える これは二つ目の厳格なルールであり、最も見落とされやすいものでもあります。 納品拒否は失敗として数え、分母はすべての問題とする。 （原文：「拒交計為失敗，分母是全部題目。」） 理由は単純です。分母に「納品があった問題」だけを数えるなら、「 すべて拒否 」で成功率 100% になります。何もせず、何も納品しないシステムが、このルールのもとで満点を取れてしまいます。 私たちのコードには、実際"},{"t":"私たちは AI に自分たちの結論を覆させに行き、そして AI は成功した","u":"/ja/blog/adversarial-recheck.html","g":"方法","s":"2026-08 の初め、私たちはパルス攻撃の六つの見出しの結論を独立エージェントに渡し、指示は「それが誤りだと証明せよ」だけでした。結果は三つが反証、二つが格下げで、持ちこたえたのは二つだけでした。","b":"結果 元の結論 判定 --- --- 時間構造は総攻撃成功にほとんど影響しない（15 セルで差は 1.81 倍） 言い過ぎ 盲点の影響は攻撃者のパラメータ選択よりはるかに大きい 言い過ぎ 盲点が 0.5–0.75 を超えるとパルスは持続的な不正に劣る 反証 監査を強めても盲点のある状況は救えない 反証 一度捕まる = 永久除名 言い過ぎ 等予算のもとでは crude 戦略がパルスに勝つ 反証 六つのうち三つが反証、二つが格下げです。 残った二つの肯定的な結論は、どちらも私たちの分析規律の中で規則として書かれました。 なぜこれほど誤りやすいのか 報告を書くとき、私たちは 無意識のうちに、関連する二つの因子を直交する次元として扱っていた からです。三組の例： 私たちが思っていたこと 実際 --- --- 時間構造 vs 総攻撃成功 総攻撃成功 = 露出 × 効率 で、両者は逆向きに打ち消し合う 盲点 vs サンプリング率 三つの因子は 同じ一つの積 の中の項 タイミング vs 不正回数 私たちの「等予算」は 予算を縛っていなかった 最も確かめにくかったもの：退化した端点に支えられた結論 「盲点の影響はパラメータ選択よりはるかに大きい」という結論について、再検証エージェントの発見はこうでした。 盲点と時間構造には 強い交互作用 がある（二因子分解で η² = 0.264 、時間構造の主効果の 4 倍 ）。したがって「本当の変数は X だ」という文型そのものが成り立たない。 しかも元の数字は、ほぼ全面的に一つの 退化した端点 に支えられていました。 blind = 1.0 を除外したあと --- --- pulse の盲点効果 8.9 倍 → 3.28 倍 patient の盲点効果 54 倍 → 5.68 倍 ゲージが端点で退化すると、測れる数字は最もきれいで、最も情報がありません。 これは後に分析規律の第二として書かれました。 統計ツールのバグが捕まった 再検証の過程で、予期していなかった問題も一つ捕まりました。 wilcoxon_signed_rank_exact の正規"},{"t":"私たちが測り間違えた六つのこと","u":"/ja/blog/measurement-traps.html","g":"方法","s":"フィールドの読み間違い、ネットワーク切断が評価結果として数えられたこと、極限に退化した rng シード、`defected <= BUDGET` を同一予算とみなしたこと、端点のきれいな数字、そしてデフォルトでオフになっていたルール——六つの実際の測定の落とし穴とその教訓です。","b":"この記事では、本研究で 測り間違えた ことをすべてまとめます。どれも実際に起きたことで、どれも危うく偽の肯定的または否定的な結論になるところでした。 一、フィールドを読み間違えて偽の結果を作った E10 実モデル実験 の最初の分析： audit.passed を読む アームの外の判定を使う --- --- --- off アーム 0 / 11 7 / 12 on アーム 5 / 10 5 / 10 差 有意（on の圧勝） 消える 正しいやり方 ：品質判定はアームと無関係でなければなりません—— アームの外の compile_check t.check answer で独立に判定します。 この件は典型的な落とし穴として examples/realmodel_suite.py のコメントに残してあります。}} 二、ネットワーク切断が「評価合格」として数えられた 2026-06-30、集団ルーティングの再検証。最初のラウンドで a2hard は ✓ を出力しました が、呼び出しごとの I/O 監査が次のことを捕まえました。 - 第 20–23 回の呼び出し（ちょうど good_1 に対する 4 つのピアレビュー）が Connection refused / reset by peer にぶつかっていた。 - 応答は空文字列で、照合ルールは \\bYES\\b の否定形のマッチだった—— 空文字列は「YES ではない」、つまり「不合格」として数えられた 。 - 結果：good_1 のピア評判は誤って 0.50 まで押し下げられ、ピアの真値に対する的中率は 88% から 75% に、捕捉率は 71% に下がった。 見かけの効果は −4% でした。 三、一つのオプションのパラメータが、すべての数字を黙って動かした SimConfig.digest は同時に二つのものでした。 1. RNG のシード。 2. すべてのフィールド のハッシュ。 そのため開発者が「オプションのパラメータを一つ足す」と、 E1 から E16 のすべての数字が変わり 、しかもエラーメッセージは一つも出ませんでし"},{"t":"誹謗するだけで一度も違反しない攻撃者が、仕事の 95.4% を手にした","u":"/ja/blog/collusion-scores-zero.html","g":"防御軸","s":"票の水増しへの防御を三層とも備えたのに、悪いものを一度も納品せず他者を評価するだけの共謀集団が、ルーティングのほぼすべてを持っていきました——しかもそのスコアは 0 です。被害は過小評価されたのではなく、ゼロと測定されたのです。","b":"2026-08-07、私たちは「新たな攻撃面」の実験群（A1–A3、B1–B5）を行いました。そのうち一つの実験の結果は、本研究全体で 最も慎重に引用すべき ものです。 設計 --- --- 規模 評価者 6 人、bug 6 種類（専門家の正確度 0.90 対 非専門家 0.35） ルーティング agent, family のセル上で UCB を実行 family の宣言 納品側が note_head で宣言 し、評価者は転記しかできない A シリーズ 12 シード。B シリーズは 10 シード 統計 平均のみで、CI も対応のある検定もない 票の水増しへの三層の防御 私たちは評価者のホワイトリストを持っていません（ホワイトリストが必要なら、それを発行する人が必要になり、その人が信頼されなければならない対象になってしまうからです）。その代償が票の水増しなので、重みを引き下げる層を三つ設けました。 層 発動条件 重みの上限 --- --- --- ① 自己申告による同源 同一の管理者を自己申告し、同じ対象に対する k 人目 0.1 / k ② 行動推定による同源 二人の評価者が「識別力のある問題」で一致率 ≥ 0.9、かつその種の問題を ≥ 5 問共同で評価している 0.1 / k ③ 未実証の評価者 自身の観測 < 5、同じ対象に対する k 人目 0.1 / k 第 ③ 層の狙いは、N 個の匿名の身元の集団としての寄与をおよそ 0.1 × 調和数 H_N にし、 線形ではなく対数的に増える ようにすることです。修正前は、200 個の匿名の身元がそれぞれ一票を投じると 10.0 の重みを積み上げられました。 層ごとのアブレーション：どの層が本当に働いているか 攻撃者が安いほど、被害は大きい 攻撃者の種類 スコア --- --- 同一の管理者を自己申告 3.8 匿名 5.1 新規登録 10.9 / 7.5 1.5 – 2.9 倍の差です。 報告の結論ははっきり書いています。 荷重を支える唯一の層は、最も安い攻撃者を止められない。 B5：スコア 0 の攻撃者 ここが要点です。"},{"t":"なぜ「永久除名」は実は二つの妥当な修正の積なのか","u":"/ja/blog/slash-halves-both.html","g":"防御軸","s":"実測では、ペナルティを受けた 368 シードのうちルーティングに戻ったのは 0 でした。私たちは「一度捕まる = 永久除名」と言いました——しかし本当の仕組みは時計ではなく、slash が平均を半分にすると同時に観測数を倍にし、その観測数が回帰時間の指数係数になっていることです。","b":"実験結果はこうでした。実際にペナルティを受けた 368 個のシミュレーションのシードを走らせると、 ルーティングに戻ったのは 0 でした 。 私たちの結論はこう書かれていました。 一度捕まる = 永久除名。 この文が述べる現象は正しいのですが、仕組みの説明は誤りです。 そして誤った仕組みの説明は誤った直し方につながるので、最後まで追う価値があります。 まず、どれほど極端かを見る パラメータ ルーティングに戻った割合 --- --- 現行（f = 0.5, λ = 1） 0 / 368 平均だけ動かし、観測数は動かさない（λ = 0） 214 / 368 （58.2%） f = 0.7, λ = 0 308 / 368 f = 0.7, λ = 1 0 / 368 f = 0.9, λ = 0 309 / 368 f = 0.9, λ = 1 308 / 368 解析式：「長く待つ」のではなく「到達できない」 ペナルティの解析可能な形はこうです。 m = 0.9、target = 0.95、c = 0.3 として、各設定で必要な総観測数（log₁₀）を計算しました。 ペナルティ前の n f = 0.5, λ = 0 f = 0.5, λ = 1（現行） f = 0.9, λ = 0 f = 0.9, λ = 1 --- --- --- --- --- 1 1.21 4.83 0.09 0.13 3 3.62 9.65 0.28 0.34 10 12.06 26.54 0.95 1.07 48 57.91 118.22 4.54 5.07 本当の仕組み：三つのことが同時に成り立つ 主な原因は slash の実装の形です。 この形には二つの効果があります。 効果 結果 --- --- 事後平均を半分にする target − mean が大きくなる 実効観測数 n を倍にする そして n は回帰時間の 指数係数 である 実測による確認 一点での実測（シード p1、800 ラウンド、f = 0.5）： ペナルティが起きたラウンド ペナルティ後のスコア 観測数 その後ルーティングに"},{"t":"「時間構造は重要でない」はどう間違えたか：集計量を分解する","u":"/ja/blog/aggregate-decomposition.html","g":"防御軸","s":"15 セルの攻撃戦略で総攻撃成功の差が 1.81 倍しかないと測り、私たちは「時間構造は結果にほとんど影響しない」と書きました。分解すると、露出は 6.06 倍、効率は 8.45 倍の幅があり、攻撃能力の差は 8.45 倍でした。","b":"私たちが最初に測ったもの 攻撃戦略は「パルス攻撃」です。B 件の連続した不正を放電し、R 件のクリーンな納品を蓄積し、繰り返します。私たちは 15 通りの burst, recover の組み合わせを、盲点 0.5 のもとで走査しました。 値 セル --- --- --- 最少の攻撃成功 2.8333 1, 20 最多の攻撃成功 5.1333 8, 20 幅 1.81 倍 この数字に基づいて、私たちは報告にこう書きました。 攻撃の時間構造は、総攻撃成功数にほとんど影響しない。 この文は誤りです。 より正確に言えば、それは 推論の誤り であって、計算の誤りではありません。 再検証エージェントの発見 エージェントは「総攻撃成功」を二つの量に分解しました。 幅 --- --- 露出 （ルーティング回数） 6.06 倍 効率 （一回あたりの成功率） 8.45 倍 両者の積 1.81 倍 正しい言い方 盲点 0.5 というこの一点では、時間構造が総攻撃成功に与える効果を測れませんでしたが、それは absence of evidence です。攻撃成功を「ルーティング回数 × 一回あたりの成功率」に分解すると、前者の幅は 6.06 倍、後者は 8.45 倍です——総数が平らなのは、露出と効率が逆向きに打ち消し合っているからです。 攻撃能力の差は 8.45 倍です。 この件の深刻さ 再検証はさらに三つのことを確かめました。 --- --- ANOVA F = 1.27 η² 0.039 （主効果はほぼゼロ） 並べ替え検定 p = 0.115 検出力 わずか 25% なぜこの誤りはこれほど起こりやすいのか この規則の三つの適用範囲 私たちは後にこれを一般則として書き、ほかの二か所でも使いました。 場所 元の文型 分解したあと --- --- --- パルスの時間構造 「重要でない」 露出 6.06×、効率 8.45× 盲点 vs 時間構造 「本当の変数は盲点だ」 交互作用 η² = 0.264 で、主効果の 4 倍 等予算の比較 「crude 戦略のほうが安上がり」 実際の不正 11."},{"t":"検知確率は一つの積であって、三つの次元ではない","u":"/ja/blog/blindspot-is-a-product.html","g":"防御軸","s":"私たちは当初「監査率を上げても盲点のある状況は救えない」と主張していました。実測では、盲点 0.5 のとき監査率を 0.1 から 1.0 に引き上げると攻撃者の総攻撃成功は 82% 低下し、p = 5.5e-6 でした。三つの因子は同じ一つの積の中の項です。","b":"私たちの元の主張 私たちの直感はこうでした。 監査と評価者に共通の盲点があるなら、監査率を どれだけ 上げても、盲点による損失は取り戻せない——見落とされたものは永遠に見落とされるからだ。 根拠にした数字は次のとおりです。 攻撃成功 完全阻止率 --- --- --- 盲点 0、監査率 1.0 0.0 100% 盲点 0.5、監査率 1.0 0.9667 56.67% そこで私たちはこう書きました。 「監査率を上げれば盲点ゼロは救えるが、盲点のある状況は救えない。」 再検証エージェントの発見 エージェントはグリッド全体を走査し、こう書きました。 検知確率は単一の積 1−盲点 ×サンプリング率×正確度 であり、三つは同じ軸の上にある。サンプリング率と盲点は互いに置き換えられる。 盲点が変えるのは防御の天井（残量 β/ 1−β ）であって、サンプリング率が役に立つかどうかではない。 実測の数字 条件 結果 --- --- 盲点 0.5、監査率 0.1 → 1.0 総攻撃成功は 82% 低下 （Wilcoxon p = 5.5e-6 ） 同上、盲点カテゴリ内部の攻撃成功 70% 低下 監査率 0.5 → 1.0（50% の盲点を相殺するため） 対応のある差 0.03 、 p = 0.78 「天井」とは何か 盲点の外部の錨 私たちは 2026-08-06 に、外部の文献にある盲点の数字を登録しました。 これらは私たちの β ではなく 、他の人が別の設定で測った相関です。 研究 数字 --- --- Kim ら（2025） 、350+ モデル 二つのモデルがともに誤答したとき、HELM 0.600 （ランダム 1/3 = 0.333）、HuggingFace 0.423 （ランダム 0.127）。しかも より正確なモデルほど誤り方が似ている 。 Begin（2026） 選好整合の相関 ρ = 0.70 。10 エージェントの実効的な独立数は 1.38 。40 に増やしてもほとんど動かない Bugaud ら（2026） 、17 の VLM／8 つのファミリー 相関した多数派の誤りは"},{"t":"「等予算」は罠だった：私たちの順位は丸ごと逆転した","u":"/ja/blog/equal-budget-must-bind.html","g":"防御軸","s":"判定基準を defected <= BUDGET と書くと常に成り立つ上界になるので、「このアームはそもそも縛られていない」ことを捕まえられません。その結果、whitewash は 2.5 倍多く不正をしていたのに、私たちは「戦略が安上がり」と読みました。== に変えて検証すると、順位は逆転しました。","b":"私たちがしたかったこと E19 はとても直観的な問いに答えようとしました。 攻撃者が同じ不正の予算を手にしたとき、 どの時間配分が最も手間がかからないか ？ そこで上限を設けました。総不正回数は 12 を超えてはならない。そのうえで五つの攻撃戦略の「効率」を比べました。 測れたもの アーム 判定基準のもとでの効率 縛られたか --- --- --- whitewash （ずっと不正をし、捕まったら身元を替える） 8.1667 29 / 30 sybil 6.1333 30 / 30 pulse 5,20 4.30 1 / 30 pulse 3,10 4.2333 1 / 30 patient（ゆっくり不正をする） 3.7333 1 / 30 私たちの結論： 等予算（各 12 件）＋盲点 0.5 のもとでは、 whitewash 8.17 がかえってパルス 4.23 に勝つ 。 「だから乱暴な連続攻撃のほうが、リズムを工夫するパルスより安上がりだ。」この文は読んでみるとなかなか洞察があるように見えます。 どこが誤っていたか では、その予算 12 は結局誰を縛っていたのでしょうか？ アーム 予算 12 に達したシードの割合 --- --- whitewash 29 / 30 sybil 30 / 30 patient 1 / 30 pulse 3,10 1 / 30 pulse 5,20 0 / 30 しかも defected <= BUDGET は常に成り立つ上界です ——不正回数が 12 を超えなければ通ります。だからこの判定基準は、設計上「縛られている」と「縛られていない」を区別することが できません 。 修正後 defected == BUDGET に替え、さらに 事前に各アームが本当に縛られていることを検証しました 。 budget ∈ {1, 2, 3, 4, 6} を走査しました。 予算 whitewash patient sybil pulse 3,10 pulse 5,20 --- --- --- --- --- --- 1 1.00 / 0.533 1."},{"t":"パルス攻撃：新しくはなく、私たちの見出しの数字すら古かった","u":"/ja/blog/pulse-attack.html","g":"防御軸","s":"B 件を放電し、R 件を蓄積し、繰り返す。このモデルは 2005 年にすでに先例がありました（Srivatsa らの strategic oscillation）。2026-08-06、私たちは「新しい攻撃」という主張を取り下げました。","b":"モデル 攻撃戦略は「パルス」です。 B, R でパラメータ化します。既存の三つの戦略はその特殊ケースです。 既存の戦略 B, R --- --- patient（持続的にゆっくり） 1, ∞ whitewash（ずっと不正） ∞, 0 連続攻撃 ∞, 0 または 1, 1 先行研究 Srivatsa ら（2005、TrustGuard）§2 model I には、一字一句こう書かれています。 \"Or it could oscillate between building and milking reputation.\" 彼らの model I は 固定周期の矩形波 で、まさに私たちの B, R パラメータ化です。model II–IV（指数間隔／ランダムな良さ／正弦的な漸変）は私たちは走査していません。 Hoffman ら（2009、ACM Computing Surveys）§5.4 は、これを oscillation attack という名前の付いた攻撃類型として挙げ、Srivatsa 2005 に帰しています。彼らの版には 複数の身元による交代 が含まれており、私たちの単一の攻撃者より強いものです。 私たちの見出しすら先を越されていた 取り下げた主張 私たちは 2026-08-06 に、二種類の主張を正式に取り下げました。 主張 取り下げの理由 --- --- パルス攻撃は 新しい発見 である Srivatsa 2005 model I が一字一句記述しており、Hoffman 2009 が名前の付いた類型として挙げている 七つのメカニズム要素は 新しいメカニズム である 六つにはすでに同等の先行研究がある {{note:good 新しい可能性があるものとして残した部分 私たちはすべてを古いと言ったわけではありません。控えめに、まだ新しい可能性がある三点を挙げました。 1. 四つの防御が同時に動いている構成 のもとで測ったこと。 2. 盲点を第二の軸とし 、時間構造との交互作用を測ったこと（η² = 0.264）。 盲点の文献はルーティングも減点もせず、評判の攻防の"},{"t":"実モデルでの信頼スイッチ実験：+8.3%、しかし統計的には何も起きていません","u":"/ja/blog/e10-paired-null.html","g":"防御軸","s":"60 の対応のあるタスクで、信頼層のオン・オフによって合格率は 51.67% から 60.00% に上がりました——しかし 95% 区間は 0 をまたぎ、McNemar p=0.332、検出力は 0.163 しかありません。同じデータには、もっと意味のある結果がもう一つあります。","b":"これは本研究で 初めて実モデルで行った対応のある防御実験 であり、私たちが初めて手にした「実モデルでの null 結果」でもあります。 設計 --- --- モデル qwen3.6-35b-a3b @ 100.119.113.56:8765 問題バンク EvalPlus MBPP+ v0.2.0（378 問、sha256 で固定） タスク 60 の対応のあるタスク 名簿 デモ用の名簿に、 破壊者を人為的に 2 人植え込む 対応キー task_id = sha256 prompt + tests 、アーム間で安定 品質判定 アームの外 での compile_check t.check answer 結果 アーム 合格 有効 合格率 所要時間 ledger イベント 合格あたりの呼び出し --- --- --- --- --- --- --- off 31 60 0.5167 6,837.5 s ROUTE 60、ATTEMPT 60、DELIVERED 60 1.94 on 36 60 0.6000 6,168.0 s +REVIEW 180 、AUDIT 60 1.67 最初の測り間違い：読むフィールドを間違えた 二つ目の結果変数：こちらのほうが面白い 私たちは 破壊者に割り振られた仕事量 も測りました。これは「悪い仕事をしても仕事をもらい続ける」ことの直接の指標です。 破壊者に割り振られた割合 --- --- off 20 / 60（33.3%） on 11 / 60（18.3%） 検定の方法 p --- --- 60 問すべて 0.0931 （.05 に届かず） ウォームアップの 10 タスクを除く 0.021 – 0.041 20 個を除く 0.021 – 0.041 30 個を除く 0.021 – 0.041 35 個を除く 0.0703 40 個を除く 0.2188 {{note:good ただし向きは「防御がよく効く」という結果と一致しています 面白いことに、信頼層は「品質」には識別可能な差を生みませんでしたが、「誰が仕事を受け取るか」には向きの一貫した影響"},{"t":"保証金を低くしすぎると、攻撃者がかえって 235% のリターンを得る","u":"/ja/blog/entry-cost-backfires.html","g":"防御軸","s":"14 本のメカニズムのシミュレーションの中で最も直観に反する結果です。無料の参入は完全に封鎖できたのに、保証金 2 では攻撃者の単位コストあたりのリターン率が 2.354 に達しました。私たちは二つの防御設計（外生的な参入料、推薦者の連帯責任）を丸ごと削除しました。","b":"2026-07-26、私たちは 14 本のメカニズムのシミュレーション（E1–E9、E12–E16）を走らせ、ごく普通の問いを立てました。 攻撃者にとって割に合わないようにするには、参入料をいくら取るべきか？ 答えは、 取らないこと でした。 設計 --- --- 誠実な住人 5 人。それぞれが本物の Ed25519 の身元 + 本物のイベントチェーン + 本物の能力カードを持つ 攻撃者 1 人 ウォームアップ 8 ラウンド。エコシステムに推薦できる記録を作るため 総ラウンド数 400 シード セルごとに 20（E9 は 40、E15 は 30） 監査率 0.2（E2／E3 以降は 0.05） 評価者の正確度 0.7（著者が選んだ値で、測定していない） 結果：保証金が少ないほど安全 外生的な保証金 攻撃成功 リターン率 完全阻止率 --- --- --- --- stake = 0 0.00 — 100% stake = 2 5.00 2.354 0% stake = 5 3.05 0.560 — stake = 10 1.95 0.177 — stake = 20 1.90 0.092 — なぜこうなるのか 見習い期間：価値はすべて最初の一歩にある 見習い期間の長さ m 攻撃成功 完全阻止率 --- --- --- m = 0 6.85 ± 1.80 0% m = 1 0.00 100% m = 2 0.00 100% m = 3 0.00 100% m = 5 0.00 100% m = 8 0.00 100% 一言でいえば、 防御の価値はすべて m = 0 → 1 の一歩にあります。 見習い期間を長くしても何の利得もありません。 推薦者の連帯責任：純損失 連帯責任係数 λ 攻撃者の利得 誠実な参加者の損失 --- --- --- λ = 1.0 0 0.000 λ = 0.9 0 0.691 λ = 0.7 0 0.702 λ = 0.5 0 0.702 λ = 0.3 0 0.702 三つの設計の直接対決（E6）： 設計 攻撃成功 完全阻止率 誠実な参加者の損失"},{"t":"防御システム全体で唯一本当にきつい制約：評価者の正確度","u":"/ja/blog/reviewer-accuracy-binds.html","g":"防御軸","s":"保証金、見習い期間、エコシステムの規模、攻撃者の比率、審査者の誤差の相関を走査しましたが、どれも緩い制約でした。攻撃が割に合い始める唯一のセルは、評価者の正確度が 0 に落ちたときです。","b":"で、私たちは「外生的な参入料」と「推薦者の連帯責任」を削除しました。理由は、それらの効果が弱めだったからではなく、一方は能動的に有害で、もう一方は純損失だったからです。 しかしその二つの道を削除したあと、 このシステムは何で攻撃者を止めているのでしょうか？ 五つのパラメータを走査し、四つは緩かった 保証金 緩い。stake=0 で完全に封鎖、stake=2 でリターン率 2.354。 見習い期間の長さ とてもきついが、向きが逆です。m=0 → 6.85、完全阻止 0%。m≥1 → 0.00、完全阻止 100%。 一歩で決まり、そのあとは何の区別も生みません。 エコシステムの規模（E8） 完全に緩い。 誠実な参加者 2／3／5／10／20 人で、 すべて 0.00、100% 完全阻止 。 攻撃者の比率（E14） 攻撃者／総数 攻撃成功 一人あたりのリターン率 完全阻止率 --- --- --- --- 1 / 6 2.30 0.144 5% 2 / 7 4.00 0.125 — 3 / 8 3.80 0.079 — 5 / 10 5.40 0.068 — 8 / 13 7.45 ± 1.07 0.058 0% 評価者の誤差の相関（E16） 相関係数 ρ 攻撃成功 標準偏差 --- --- --- 0.0（独立） 2.40 0.58 0.3 2.30 0.95 0.6 2.50 0.67 0.9 2.45 1.07 1.0（完全に一致） 2.85 1.98 唯一きつい制約：評価者の正確度（E12） 評価者の正確度 攻撃者へのルーティング 攻撃成功 リターン率 --- --- --- --- 1.0（完璧な評価者） 18.0 1.90 ± 0.30 0.119 0.7（私たちの設定） — 2.35 — 0.5 — 2.70 — 0.3 — 4.30 0.269 0.0（評価者なし） 33.6 16.65 ± 12.89 1.041 acc = 0 は、表全体で唯一「攻撃が割に合い始める」セルです。 リターン率 1.041 は、攻撃者が儲けられることを意味します。 しかもその標"},{"t":"ゼロ設定の四つのバッチ：三つは差が測れず、四つ目はエンジンを替えると消えました","u":"/ja/blog/zero-config-measured.html","g":"利得軸","s":"ゼロ設定を DABstep、ローカル 711 セル、Colab 920 問、u274 の四つのバッチで測りました。有料バッチは二つのモデルとも差が測れず、ローカルバッチは p=0.021 でしたが 6 問に集中し、920 問と u274 は差が測れず、v3.7 は後に p=0.0028 を測ったものの GGUF に替えると再現しませんでした。","b":"この記事は四つのバッチを記録します。四つともきれいな結果ではなく、しかもきれいでない形がそれぞれ違います——そこが要点です。 まず何を測ったのかをはっきりさせる ゼロ設定（zero-config）は v0.9.0 の製品の主線です。目標は多くをこなすことではなく、 インストールした後もいつも通りに使えること です。契約を書かず、設定を足さず、作業の流れも変えません。 やることは一つだけです。 エージェントが「完了しました」と言ったその瞬間に、同じセッションの中で一度だけ言葉を送り返します。 これと との違いは、バージョンの新旧ではありません。CONFORM は生成を握っています。候補ごとに可視の受け入れテストを実行し、通らなければ再サンプリングし、最大五つまで、すべて通らなければ納品を拒否します。ゼロ設定は生成を握っておらず、実行可能なシグナルも、やり直させる権限も、納品を拒否する権限もありません。 まずこの違いを机の上に置いておくと、後の四つのバッチの結果が読めるようになります。 --- バッチ一：DABstep 有料バッチ（2026-09-25／26） 77 問、各問題・各グループ一回ずつ実行し、費用は 3.40／4.80 ドル、呼び出しは 3,324 回。 モデル 未インストール インストール済み p --- --- --- --- gemma-4-26b（主） 50/77 （64.9%） 44/77（57.1%） 0.21 qwen3.8-27b（副） 68/77 （88.3%） 64/77（83.1%） 0.29 事前登録の言い方に従えば、これは 差が測れなかった ということです。「効果がない」とも「悪くなった」とも言いません。 8 回の差し戻しはすべて誤報 これがこのラウンドで最も記録すべきことです。 実際の誤報率：gemma 6/37（16%）、qwen 1/64（2%）——分母は「初めて提出前チェックに到達し、その時点で回答が正しかった実行の数」です。 害は 0 回。 正しい回答を誤りに書き換えたことは一度もありません。 作者は報告の中で、自己評価を一文"},{"t":"ゲートは偽の納品を半分ではなく約四割削減した","u":"/ja/blog/gate-cuts-forty-percent.html","g":"利得軸","s":"836 問、43 ブロック、無効 0 の実験です。論文の「halved」は誤りでした——二つの率が異なる分母を使っていたからです。この訂正で、ゲートの効果は「半減」から「約四割」になりました。","b":"偽の納品とは何か 用語 定義 --- --- 納品成功 システムが実際に通し、 かつ 保存された候補が非公開評価に合格した 偽の納品 システムは通したが、候補が非公開評価に 合格しなかった したがって「偽の納品率」には三通りの集計の取り方があり得て、どれも正しいのですが、違う数字が出ます。 R532 のデータ --- --- モデル qwen/qwen3.8-27b Q4_K_M、 非 reasoning タスク 836 ブロック 43 完了率 43 / 43 データ行 2,508 無効 0 V/GT 指紋 199,019 項目 CLEAN レシートチェーン 86 本 / 3,895 件すべて検証を通過 これは本研究で データ品質が最もクリーンな実験 でした——無効 0、V/GT 違反 0、86 本のチェーンすべてが検証を通過。 三通りの集計 アーム 受け入れ数 偽の納品数 偽の納品 / 全 836 偽の納品 / 受け入れ数 --- --- --- --- --- CONFORM 811 120 14.4% 14.8% OFF 625 211 25.2% 33.8% 訂正後の主張 この数字がなぜ重要か 他の数字との関係 数字 値 出典 --- --- --- 偽の納品率（CONFORM） 14.4% （受け入れ数に対して 14.8%） R532 偽の納品率（OFF） 25.2% R532 カバー率（CONFORM が通せた割合） 811 / 836 = 97.0% R532 候補プールの上限（r441） 82.68% R440P 残存する実現可能な攻撃（generic_gauged） +2.72 pp R452 ゲージの上限（weak_oracle） +4.35 pp R452 この実験の二つの修正案 AMEND1 （H-MIX のラベルについて）： 問題セット H-MIX − CONFORM --- --- 1 −5.83 2 −5.19 3 −16.67 4 −1.28 5 −0.54 統合 −3.23 pp 、区間 −5.52, −0.75 、Holm p = 0"},{"t":"これは成功率の向上であり、token 効率の向上ではない","u":"/ja/blog/token-cost-ledger.html","g":"利得軸","s":"一通ずつ再計算した 197 セルで差はゼロでした。H-MIX は一回だけの抽出の 2.23–2.78 倍の token を使い、五回の再現のうち四回で、正しい納品一件あたりのコストがゲートより高くつきました。「同じ上限」は「同じ実際のコスト」ではありません。","b":"混同しやすい二つの定義 --- --- reasoning completion の部分集合 であり、別に一回加算されるものではない 失敗したリクエスト 中核実験の 116 件の失敗したリクエストには usage がなく 、 不明 として計上（0 で埋めない） R460 のコスト アーム 納品率 token / 問 token / 正しい納品 --- --- --- --- OFF 58.33% 2,913 4,994 CONFORM 70.83% 5,805 8,195 OFF5 65.00% 15,004 23,084 H-PI 75.83% 9,448 12,459 H-OC 80.00% 7,432 9,290 H-MIX 84.17% 5,677 6,745 三つの比 比較 問題あたり 正しい納品あたり --- --- --- H-MIX vs OFF 2.23 – 2.78× 1.65 – 2.11× H-MIX vs CONFORM 0.92 – 1.56×（R460R）／1.07 – 1.69×（R529） — OFF5 vs CONFORM 2.16 – 2.85× 、しかも 毎回納品率がより低い — 「token を多く使わない」は成り立たない 私たちの元の看板の主張は「修正ループは再サンプリングより 多く納品し、しかも token を多く使わない 」でした。 r1 r2 r3 r4 r5 --- --- --- --- --- --- H-MIX vs CONFORM 問題あたり 0.92× — — — 1.56× 正しい納品あたり — — — — 四回は CONFORM より高い なぜ「同じ上限」は「同じコスト」ではないのか R529 のホスト別の発見 R529 は互いに重ならない四つの問題セットを使い、 二台の LM Studio ホスト にまたがっていました： ホスト HumanEval+ の結果 H-MIX token/問 CONFORM token/問 差 --- --- --- --- --- reasoning 有効（0.4.24） "},{"t":"五回の再現の後：看板の主張は自らの安定性ルールに負けた","u":"/ja/blog/five-replications.html","g":"利得軸","s":"R460 では修正ループが再サンプリングより 13.33 ポイント多いと測定され、Holm p = .0112 でした。同一問題での再現を五回行うと五回とも有意でなく、補正を通過したのは 0/5、状態は「同符号・未解決」に下がりました。","b":"出来事の順序 2026-09-07 ：R460 の事前登録が四つの状態ルールを固定。 2026-09-11 ：R460 の実行完了（LCB v2 120 問、6 ブロック × 20）。 アーム 成功 率 --- --- --- OFF 70 / 120 58.33% CONFORM 85 / 120 70.83% OFF5 78 / 120 65.00% H-PI 91 / 120 75.83% H-OC 96 / 120 80.00% H-MIX 101 / 120 84.17% H-MIX − CONFORM：b=22、c=6、 +13.33 pp 、条件付き区間 4.22, 19.46 、 Holm p = .0112 → EFFECTIVE 。 2026-09-11 ：R460R の事前登録が「同一問題での五回の再現」の主張ルールを固定。 2026-09-12 ：五回の実行完了。 事前登録された主張のルール --- --- 一回ずつ判定 五回とも通過する必要がある 禁止 n の統合、平均、一回だけ選んで報告 判定の閾値 条件付き区間の下限 0 かつ Holm 補正を通過 五回の再現の結果 納品率（%）： アーム r1 r2 r3 r4 r5 --- --- --- --- --- --- OFF 57.50 54.17 57.50 51.67 51.26 OFF5 60.83 61.67 59.17 66.67 68.64 CONFORM 71.67 72.50 75.00 70.83 70.94 H-PI 76.67 79.17 75.83 80.83 70.83 H-OC 76.67 73.33 75.00 78.33 75.00 H-MIX 77.50 76.67 75.83 73.33 74.79 H-MIX − CONFORM： r1 r2 r3 r4 r5 --- --- --- --- --- --- Δ +5.83 +4.17 +0.83 +2.50 +4.31 Holm p .6301 .9165 1.0000 .6776 .9224 95% "},{"t":"五回の再現で唯一安定して成立したもの：ループは一回だけの抽出より 17 から 29 ポイント多い","u":"/ja/blog/loop-vs-single-shot.html","g":"利得軸","s":"15 ブロックすべてがそれぞれの Holm 補正を通過し、差の範囲は +17.5 から +29.2 ポイント。同一問題での五回の再現と、互いに重ならない四つの問題セットにまたがります。これは本研究で最も堅い結果です。","b":"比較対象の違いこそが要点 比較 結果 判定 --- --- --- ループ vs 一回だけの抽出 （OFF） +17.5 ~ +29.2 pp 、 15/15 が Holm を通過 成立 ゲート vs 一回だけの抽出 （OFF） +14.17 ~ +19.97 pp 成立 ループ vs 再サンプリング （CONFORM） +0.83 ~ +5.83 pp、 0/5 が通過 同符号・未解決 ループ vs 投票 （OFF5、探索的な量） −1.74 ~ −15.83 pp 同符号・未解決 15 ブロックの詳細 結果 --- --- ブロック数 5 回の再現 × 3 つの H アーム = 15 それぞれの Holm 補正を通過したブロック 15 / 15 Δ の範囲 +17.5 ~ +29.2 pp ゲート vs 一回だけの抽出 CONFORM − OFF、五回： r1 r2 r3 r4 r5 --- --- --- --- --- --- CONFORM 86 87 88 87 85 OFF 69 65 66 60 58 Δ +14.17 +18.33 +17.50 +19.17 +18.97 補正前 p 0.0015 — — — — 帰属：利得の本体はゲート＋再サンプリング 五回のデータを重ねて見ると： 差 --- --- 三つの H アーム vs OFF +17.5 ~ +29.2 pp CONFORM vs OFF +14.17 ~ +19.97 pp H-MIX vs CONFORM +0.83 ~ +5.83 pp（0/5 が通過） 利得の内訳：R460P のオフライン再生に戻る API ゼロの再計算 で候補プールを分解して見ると： g_r441 g_r356 --- --- --- 候補プールの上限（少なくとも一つが正解） 82.68% 85.03% 早期停止ゲートの到達率 78.21% 82.99% 早期停止 vs 一回だけの抽出 +7.82 pp 、b=14 c=0 +6.80 pp、b=10 c=0 早期停止 vs 五つの投票 +4.47 pp、p=0.0"},{"t":"利得はループから来ており、第一ラウンドのプロンプトからではない","u":"/ja/blog/loop-not-prompt.html","g":"利得軸","s":"第一ラウンドの完全な応答を取り出し、オフラインで採点し直しました。ループの寄与は +19.17 / +17.50 ポイント、第一ラウンドのプロンプトの寄与は +6.67 / +8.33 にとどまります。21 問がループによって救われました。","b":"三種類のアームの第一ラウンド H-MIX、H-PI、H-OC の第一ラウンドのプロンプトはほぼ同じです。問題の原文、import してよい標準ライブラリのリスト、そして「まず問題中の例で関数を手で確かめてください」という一行。 違いは その後 に何が起きるかです： アーム 失敗の後 --- --- H-MIX 失敗シグネチャを計算し、失敗の原文を同じワーカーに貼り戻す H-PI 元の pi 式フィードバックループ H-OC 計画 → 診断 → 自己テスト 結果：二つの効果に分ける アーム ループ効果 （最終 − 第一ラウンド） プロンプト効果 （第一ラウンド − OFF） ループに救われた問題数 第一ラウンドの可視テスト合格率 --- --- --- --- --- H-MIX +19.17 / +17.50 pp +6.67 / +8.33 pp 21 74.2% H-PI +18.33 / +15.83 pp −0.83 / +1.67 pp — 71.7% H-OC +19.17 / +18.33 pp — — — なぜこの設計でそれができたのか {{note:method 帰属を可能にした三つの設計 ① 第一ラウンドの完全な応答をすべてディスクに書き出している （ calls.jsonl ）ので、オフラインでコードを取り出し直せます。 ② プロンプトのテンプレートが一字一句同じ （KS-1 不変条件）なので、「プロンプト効果」が測っているのはまさに「ループのあるアーム vs ループのないアーム」の第一ラウンドの差です。 ③ モデル呼び出しゼロ ——なので、この帰属はモデルのバージョン、バックエンドの負荷、ランダム性の影響を受けません。 この三つはいずれも、2026-06-28 の KS-1 の結論に迫られて生まれた設計です。 }} 書いておかなければならない留保 この結果と看板の主張の関係 この設計の実際的な意味}} 次に - ループ vs 再サンプリングの完全な判定： - ループ vs 一回だけの抽出の 15/15 セル： - KS-1 とは何か、なぜこの設計"},{"t":"MDE は 4.31 ポイント、しかし問題バンクは 378 問しかない","u":"/ja/blog/mde-and-power.html","g":"利得軸","s":"ゲート対多数決という比較では、検出力 80% に 491 対が必要だと計算できますが、問題バンクは実際には 378 問しかありません。この「同符号・未解決」は未完了なのではなく、物理的に測れないのです。","b":"先に計算し、それから実行する R529（問題バンク横断）の前に、私たちはまず一つのことを計算しました： 真の効果が存在するとき、80% の確率でそれを検出するには、何問必要か？ --- --- MDE @ n = 371 4.31 ポイント 検出力 80% に必要な数 約 491 対 問題バンクの実際の大きさ 378 問 実測の結果 問題バンク n Δ 統計 --- --- --- --- LCB v2 120 +6.67 pp p = 0.15 LCB v3 189 +1.59 pp 95% CI −3.17, +6.35 、 p = 0.6636 MBPP+ クリーン再現（新しい 192 問） 192 +4.69 pp 95% CI −1.11, 9.42 三つの区間の幅 問題バンク 95% CI 半幅 --- --- --- LCB v3（n=189） −3.17, +6.35 4.76 pp MBPP+ 再現（n=192） −1.11, +9.42 5.27 pp MBPP+ 統合（n=371） — 半幅は MDE 4.31 pp に対応 同じ概念が別の実験ではどう現れるか 実験 n 検出力 80% に必要な数 --- --- --- --- E10 信頼のオン・オフ 60 0.163 337 R460 で +10 pp に対して 120 0.43 – 0.63 — R529 統合 716 （効果量が小さすぎる） — ゲート vs 多数決 371 — 491 最後の行は「113 問足りない」唯一のケースです ——他のいくつかは何倍も足りません。}} この判断の四つの特徴 {{note:method なぜこれは「未完了」ではなく正当な「同符号・未解決」なのか ① 規模を先に計算した。 実行する前から、491 問が必要だと分かっていました。 ② 差は構造的なもの。 378 は問題バンクの上限であり、時間や資源の制約ではありません。 ③ 代わりの証拠源がある。 同じ仕組みは、 候補をそろえた 比較（EQ5）では成立しています： 。 ④ 区間をすべて報告した。 p 値だ"},{"t":"問題が難しいほど、受け入れゲートの価値は高くなる","u":"/ja/blog/harder-tasks-more-worth.html","g":"利得軸","s":"早期停止ゲートは MBPP+ で 7.8 ポイント、LiveCodeBench の難問で 20.9 ポイント多く納品しました。しかも「漏れ率」は 44 から 11 に下がりました——納品拒否は難問でこそ最も価値があります。","b":"三つの次元の対照 MBPP+ LCB v1（難問） --- --- --- 問題数 179 91 OFF（一回だけの抽出）の失敗率 31.8% 48.4% ゲート vs 一回だけの抽出 +7.82 pp +20.88 pp b / c（早期停止で救済 / 一回の抽出で正解） 14 / 0 19 / 0 候補プールの上限 82.68% 75.82% 一回だけの抽出の成功率 78.2% 45.05% 漏れ率：納品拒否は難問でこそ最も価値がある アーム MBPP+ の漏れ LCB 難問の漏れ --- --- --- OFF（一回だけの抽出） — 44 / 91 OFF5（五回の投票） — 35 CONFORM（ゲート） — 11 MBPP+ LCB 難問 --- --- --- ゲート vs 五回の投票 +4.47 pp +4.40 pp p 0.0963 0.424 ゲート vs 一回だけの抽出 +7.82 pp +20.88 pp p 0.0001 < 0.0001 これは、難問ではモデルが 自信満々に壊れたものを出しやすい からです。ゲートの仕組みは「あなたのテストを実行し、合格したら納品する」です——難問でも「これは不合格」と判断できますが、投票の仕組みは五つすべてが誤っているときには誤るしかありません。 納品拒否された 41 問 ゲートが納品拒否した問題を一つ残らず事後監査し、五つの草稿が本当にすべて不正解かを確かめました： バッチ 納品拒否 五つすべて不正解 --- --- --- r447 7 7 / 7 r449b 8 8 / 8 r449c 10 10 / 10 r461 15 15 / 15 三つの問題バンクでの収束 R445 は三つの問題セットで収束を確かめました（ゲート vs 一回だけの抽出）： 問題バンク n Δ 統計 呼び出し/問 --- --- --- --- --- MBPP+（統合 371） 371 +4.58 pp 95% CI +0.57, +8.04 1.51 LCB v2（難問） 120 +19.17 pp b=31 c=8、 p ="},{"t":"評価ゲートの誕生：意見の代わりに実行を、投票の代わりにレシートを","u":"/ja/blog/conformance-gate.html","g":"利得軸","s":"AI の評価委員会を削除し、「顧客の受け入れテストを実行し、最初に合格した候補を納品し、すべて不合格なら納品を拒否する」方式に改めました。三つの問題バンクで納品が 4.58 から 19.17 ポイント増え、1 問あたりの呼び出しは 1.5 回だけでした。","b":"ルール（一字一句凍結） 1. 候補を順に生成する。 2. どの候補にもサンドボックス内で 可視の 受け入れ検査を実行する。 3. 最初に合格した候補をすぐに通し、生成を止める。 4. 最大五つ。すべて不合格なら 納品を拒否する 。 5. 納品拒否は失敗に数え、分母はすべての問題とする。 なぜ「最初に合格したら止める」が効くのか 選択ルールの上限は、候補プールの中に少なくとも一つ正しい候補がある割合 だからです。多数決もこの上限からは抜け出せません。 保存済みの五候補データ二バッチ： 問題セット 候補プールの上限 五つすべて不正解の問題数 --- --- --- g_r441 82.68% 31 / 179 g_r356 85.03% 22 / 147 {{note:method これは非常に硬い天井です 各候補が独立に生成されると仮定すれば、「少なくとも一つが正しい」確率が上限になります。 呼び出しをいくら増やしても、どんな選択ルールでも、これは突破できません。 それでもゲートに価値があるのは、 上限の内側で 手を止めるからです——5 回ではなく、1.34 回しか使いません。 一方、 修正 は候補そのものを変えるので、原理的にはこの上限を越えられます。実験で越えられるかどうかは別の問題です。 }} 三つの問題バンクでの収束 問題バンク n 差（一回だけ引く場合との比較） 統計量 1 問あたりの呼び出し --- --- --- --- --- MBPP+（統合 371） 371 +4.58 pp 95% CI +0.57, +8.04 1.51 LCB v2（難問） 120 +19.17 pp b=31 c=8、 p = 0.0003 1.71 LCB v3 189 +7.94 pp b=25 c=10、 p = 0.0167 1.55 納品拒否された問題は運ではない ゲートが納品を拒否したすべての問題を事後に監査し、五つの草稿が本当にすべて誤りだったかを確かめました。 バッチ 納品拒否された問題数 五つすべて不正解 --- --- --- r447 7 7 / 7 r4"},{"t":"二つの説明が自分たちの実験で排除されてから、ようやく仕組みに直す余地が生まれました","u":"/ja/blog/hypotheses-excluded.html","g":"利得軸","s":"「モデルが強すぎる」と「問題が簡単すぎる」は、人間が出した二つの説明です。二回の実験でその両方が排除され、評価の仕組みは設計の変更を迫られました。変えた方向は審判を替えることで、評価モデルを替えることではありません。","b":"状況 ON vs OFF5：75.25% vs 77.23%、差 −1.98 pp 、p = 0.7905。 H-A：天井仮説（2026-09-01 に人間が提案） qwen3.6-35b が強すぎる。 だからどのモデルも正解してしまい、仕組みが力を発揮する機会がない。 もう少し弱いモデルに替えれば利得が見える。 実験（R440N / E1） --- --- 設計 単一モデル gemma-4-12b、179 問 監査 独立した監査で一行ずつ再計算し、 R516 と完全に一致 監査の証憑 rows.jsonl 525 行、sha 440d973c ；calls 1,986、sha 3d24b73d アーム n 合格 失敗率 --- --- --- --- OFF 179 122 31.8% （Wilson 25.5, 39.0 ） ON 167（+12 void = 6.7%） 122 26.9% OFF5 179 132 26.3% 比較 差 統計 --- --- --- ON vs OFF5 （同一予算） −0.60 pp b=11 c=12、 p = 1.0000 ON vs OFF +5.99 pp b=17 c=7、p = 0.0639 OFF5 vs OFF +5.59 pp b=12 c=2、p = 0.0129 評価者の grounded lift +4.19 pp 95% 0.00, +8.58 H-A は排除。 H-B：難易度仮説（2026-09-01 に人間が提案） MBPP+ は現代のモデルには簡単すぎる。 日付スタンプ付きのコンテストの難問（LiveCodeBench）に替えれば利得が見える。 実験（R440T / E3） --- --- 設計 LCB v1 の medium + hard 91 問、gemma-only、シード g-r442-lcb アーム n 合格 失敗率 納品 漏れ 一問あたりの呼び出し --- --- --- --- --- --- --- OFF 91 47 48.4% 38.4, 58.5 91 44 1.00 ON "},{"t":"評価者が追っているのは問題の難しさであって、答えの正誤ではありません","u":"/ja/blog/reviewer-tracks-difficulty.html","g":"利得軸","s":"同じ評価者の層が、MBPP+ ではほぼ一律に合格と判定し（誤り率 0.305）、LiveCodeBench の難問ではほぼ一律に不合格と判定しました（誤り率 0.46）。それは全体的な性質に従っており、この回答そのものには従っていません。","b":"二つの問題バンク、同じ評価者 MBPP+ LCB v1（medium + hard） --- --- --- 問題数 179 91 OFF アームの失敗率 31.8% 48.4% 初稿の実際の誤り率 0.305 0.460 評価者の元の FAIL 主張 少数（ ほぼ一律に PASS ） 234 / 261 = 89.7% （ほぼ一律に FAIL） 評価者の層 − ゼロ知能ベースライン −2.99 pp +0.77 pp 監査の過程で見つかった想定外のこと FAIL 主張を調べているとき、「FAIL 主張が破棄されている」例が大量に見つかりました。 --- --- round346 の元の FAIL 主張率 1.2% – 25.8% そのうち outside_input_contract と判定されて破棄されたもの 73.6% – 100% もう一つの観察：集団の盲点 三回の run を合わせ、本当に失敗する 49 タスクについて見ると： --- --- 総タスク数 275 真陰性（TN = 0 の部分） 0 3 つの評価エージェントが投じた票 147 そのうち「pass」 145（98.6%） 一度でも不合格に投票されたタスク 2 / 49 （しかも二回とも多数に押し切られた） {{note:warn 評価者の層は、間違える問題でも一致して間違えます 275 タスクの中に 真陰性は一つもありません 。本当に失敗する 49 タスクで、三つの評価エージェントは 147 票を投じ、 145 票が「合格」でした 。 これは と同じことを指しています。 同じ系統のモデルの評価者どうしは強く相関しており、その相関はみんなが失敗する問題に集中しています。 }} 三回の run で一致した結果 R438 の分析と、その後の二つの run： run 評価者の正確さ ゼロ知能ベースライン 差 --- --- --- --- R438（179 問） 0.7552 0.7522 +0.29 pp R440N（179 問、gemma-only） +4.19 pp（grounded） — 95% "},{"t":"「非公開テストは無損失だ」という文は、構造上空っぽである","u":"/ja/blog/v-gt-is-not-lossless.html","g":"利得軸","s":"R440P の事前の判定基準の一つが九日後に反証されました。LCB の 91/91 の非公開テストはすべて可視テストの上位集合なので、「非公開では合格するが可視では不合格」は構造上起こりえません。この判定基準の検出力はゼロでした。","b":"元の判定基準 私たちのゲートは、可視テストだけで通すかどうかを決めます。したがって、一つのことを検証する必要がありました： 「非公開テストには合格するのに、可視の受け入れテストには不合格」という候補は現れない。 もし現れるなら、可視テストがある要求を取りこぼしており、ゲートは壊れたものを通してしまうことになります。 六つのデータセットの結果 データセット 候補数 非公開は合格・可視は不合格 --- --- --- g_r441 （MBPP+） 895 0 g_r356 （MBPP+ プール） 735 0 g_r443 （LCB v1 再生） 455 0 g_r447 （LCB v2 実走行） 120 0 g_r461 （LCB v3 実走行） 189 0 合計 2,394 0 しかし R440Q は、なぜ 0 なのかを見つけた したがって「可視テストによる選別は無損失である」というこの判定基準は、この二つの問題バンクでは検出力がゼロです。 0/2394 は「無損失であることを私たちが検証した」ではなく、「この問題バンクの定義がそれを成り立たせている」ということです。 より厳格な三つの見方 R440Q はこれを主要な結論に格上げしました： 要求が実行可能なテストにコンパイルできないなら、この仕組みには無償の審判がいません。「モデルに聞く」に退化します——そしてそれこそが、測定で効果が最も悪かったものです。 {{note:good これは本研究で最も引用する価値のある一文 これは「意見を実行で置き換える」という設計判断の 適用範囲の境界 をはっきり書いています： - 要求をテストにコンパイルできる → 実行は無償で完全な審判になります。ゲートは有効です。 - 要求をテストにコンパイルできない → 審判がいません 。このとき残る唯一の選択肢はモデルに聞くことで、私たちはその道を測りました： したがって仕組み全体の価値の上限は、「要求をどこまで形式化できるか」で決まります。 }} これは文献で何と呼ばれているか これは Barr ら（2015）がレビューした テストオラクル問題"},{"t":"私たちの AI 評価委員会は「五回生成して多数決」に負けました","u":"/ja/blog/committee-loses-to-majority.html","g":"利得軸","s":"同じ 5 回の呼び出し、同じ問題で、三人の AI 評価者と一回の修正からなる委員会が「五回生成して多数決」に負けました。差の点推定は −1.98 ポイントで、無関係なバグを一つ直すと +2.97 になりました。","b":"2026-08-30、私たちは本研究全体で最も重要な実験を行いました。結果は、 私たちが設計した中核の仕組みが負けた というものでした。 背景：委員会型の設計 私たちのアーキテクチャは、もともと次のようなものでした。 問題は、この仕組み全体の 審判が AI だということです。そして対照群は最も単純なもの、つまり 同じ問題を五回生成し、五つの回答で投票して多数を取る というものでした。 同じ呼び出し予算 のもとで（どちらも 5 回）、どちらの納品率が高いのでしょうか。 設計 --- --- 問題バンク MBPP+（EvalPlus v0.2.0） タスク数 179 問、6 ブロック 三つのアーム OFF （一回だけ抽出）／ ON （仕組み全体）／ OFF5 （五回取って多数決） 判定基準の凍結 2026-08-24 と 2026-08-28 統計 対応のある McNemar 結果 判定基準 判定 --- --- ① ゲージにシグナルがある ✓ 26.44% （Wilson 20.4, 33.4 ） ② 三つのアームに識別可能な差がある 測れない ③ ON が OFF5 に勝つ ✓ 答えは「勝たない」 対応のある結果（n = 101、三つのアームすべてが void でないもの）： 集計方法 ON OFF5 差 b c p --- --- --- --- --- --- --- 元のまま 75.25% 77.23% −1.98 pp 6 8 0.7905 typing ホワイトリストのバグを修正 84.16% 81.19% +2.97 pp 5 2 0.4531 なぜ負けたのか：仕組みの分析 指標 数値 --- --- 評価者の票の正確さ 0.7552 「すべて合格と判定」するゼロ知能ベースライン 0.7522 差 +0.29 ポイント 一ラウンドの修正に「直す機会がなかった」 93 / 113 修正版を盲目的に採用した後の非公開評価の合格率 82.3% → 78.8%（−3.5 pp） 修正がもたらした本当の改善 1 / 113 「委員会に審査を回す」設計はどう削除されたか"},{"t":"計測ツール自身が七回測り間違え、そのどれもが自分に不利な方向だった","u":"/ja/blog/measuring-measurement-errors.html","g":"記録と多者実行","s":"対話型 TUI の A/B harness には七つの計測誤りがあり、さらにコードのコメントにだけ書かれた二つがありました。どれも本物の pi の上で見つかり、どれも数字を実際より良く見せる方向でした——捏造された結果が 8 件、一度も送られなかったプロンプトが 5 セル。","b":"この記事は、計測ツール自身の誤りの記録です。 commit b0eb0680 の一文目は、はっきりこう書いています。 これは体裁の手直しではない。どれも本物の pi 0.87.1 の TUI の上で見つけたもので、どれも harness を自分に不利に、または agent に有利にする方向だった。つまり これらの数字は本来、実際より良く見えるはずだった 。（原文：「這不是排版修飾。每一條都在真 pi 0.87.1 的 TUI 上抓到，而且每一條的方向都是讓 harness 對自己不利或對 agent 有利，也就是說 這些數字原本會長得比實際好看 。」） 「方向がそろっている」ことが鍵です。七つの誤りの方向がランダムなら、それはノイズです。すべて同じ方向なら、それは系統的なものです——この harness に構造的な問題があることを示しています。 --- なぜ対話型 TUI は特に測りにくいのか 対話型インターフェースには、叩く API がありません。測りたいもの（ゲートのバナーがどこに出るか、モデルが何ターン目まで進んだか、settle したかどうか）は、すべて画面からかき出す必要があります。 測り方は tmux の疑似端末です。pane を一つ開いて agent を走らせ、止まるのを待ち、 capture-pane で画面を取り込み、正規表現でその中から判定を探します。 これが七つの誤りの出どころです—— どれも「画面からどう真実を読み取るか」という層にあります 。 --- 誤り 1：arm A が別のモデルで走っていた 「Vacant を入れていない agent の成績」を測るには、まったく入れていない arm が一つ必要です。問題は、モデルの接続先が起動引数ではなく設定から来ることです。 やり方は、 models.json をテスト環境に一部コピーすることでした。 しかしそれで pi がその provider を選ぶわけではありません。 起動時の固定指定がないと、pi は自分のデフォルトを使います。 実測では openrouter/moonshotai/kimi-"},{"t":"攻撃者が自分の鍵でチェーン全体を鋳造し直しても、レシートビューアは合格と判定する","u":"/ja/blog/offline-viewer-limit.html","g":"記録と多者実行","s":"レシートチェーン 194 本、9,841 件はすべて検証を通りました。しかしオフラインの単一ファイルのビューアには構造的な限界があります。チェーン全体を一度鋳造し直されても、それでも合格するのです。これは脆弱性ではなく、署名の定義上の境界です。","b":"チェーン検証が捕まえられない三つのこと 捕まえられないもの なぜか --- --- 切り詰め チェーンには信頼できるチェーン先頭がありません。末尾を切り落としても同じように合格します。 分岐 同じ人が同じイベントについて内容の異なる二本のチェーンに署名すると、二本とも検証を通ります。 記録漏れ 一度も書き込まれなかったイベントについて、レシートは自分がその一件だと主張できません。 R455：オフラインビューアの限界 私たちは 外部リソースゼロ、ネットワークリクエストゼロ の単一ファイルのオフラインビューアを作りました。レシートをファイルに埋め込み、 file:// で直接開くだけでチェーン全体の検証を最後まで実行できます。 ファイル サイズ --- --- exhibit/receipts/receipt_viewer.html 0.3 MB exhibit/receipts/receipt_viewer_multiparty.html 4.5 MB そして、それを攻撃しました。 なぜこれは直せる脆弱性ではないのか この一文には、多者実行のところでもっと鋭い版があります。 署名が指し示すのは鍵であって、主体ではない。鍵の多数は独立した主体の多数ではない。 緩和策 なぜ私たちは直すのではなく、はっきり述べることを選んだのか このことが「説明責任を問える」という定義にとって持つ意味 私たちの定義は、 特定の鍵が署名したイベントの追跡可能性と照合可能性 です。}} {{note:good 「特定の鍵」という言葉に注意してください 「特定の鍵」を削って「イベントの」にすると、R455 の攻撃は致命的になります。 そして私たちの定義は 最初から「特定の鍵」と書いていました 。だから R455 は私たちの定義を反証したのではありません——定義の精確さを 裏づけた のです。 のページが「署名が証明できるのは、その秘密鍵を持つ誰かがこの記録に署名したことだけである」の説明にあれほど紙幅を割いているのは、このためです。 それは免責事項ではなく、定義の一部なのです。 }} 誠実な限界 次に"},{"t":"嘘をつく鍵は 273 回すべて名指しされ、誠実な側の誣告は 0 回","u":"/ja/blog/named-dissent.html","g":"記録と多者実行","s":"k=3、制御下にある嘘をつく鍵が 1 本、証言 5,519 件。嘘のセルの名指しは 273/273、誠実な鍵の誣告は 0/1,840、矛盾した署名のセルの判定は 58/58 で正解でした。この数字がどれほど厳しいかは、⌊(k−1)/2⌋ という数学的な上限を知っているかどうかで決まります。","b":"三つのこと 1. 実行と署名 ：各実行者は自分のレンダラーとサンドボックスで受け入れ検査を実行し、タスク、候補、スイート、レンダリング結果のハッシュと、可視の受け入れ結果を、自分のイベントチェーンに署名して書き込みます。 2. 票の集約 ：まずスイートがゲージを通るかを検査し、次に 証言を一件ずつ検証します 。同じ実行者が同じイベントについて内容の異なる二つの証言に署名した → 証明レベルの過失 として無効にします。 3. 表決と名指し ：多数決で決めます。票数が定足数に満たないか同数 → 未決 で、出荷規則は未決を不合格として扱います。少数側は、イベントハッシュと署名を添えて 名前を挙げて列記されます 。 R454 の結果 k = 3、制御下にある嘘をつく鍵が 1 本（K3）： 検査 結果 --- --- 嘘のセルが K3 を名指し 273 / 273 誠実な鍵が誣告される 0 / 1,840 矛盾した署名のセルで判定が正しい 58 / 58 証言の総数 5,519 件 署名検証の失敗 0 マシン間の一致（R453） --- --- 規模 368 タスク × 5 候補 = 1,840 個の候補 環境 macOS + Linux（k = 2） 可視の受け入れラベルの一致 1,840 / 1,840 レシートチェーン 二本とも検証を通る Windows 除外 （サンドボックスを構築できない） シミュレーションのスキャン：直感に反する二つの結果 200 セル（r446 371 問 × 5 候補、r443 91 問 × 5、k ∈ {1,3,5,7}、腐敗比率 0–70%、五種類の攻撃）： ① マシンを増やしても何も買えない 条件 納品率 --- --- 腐敗比率を固定して、k を 1 から 7 に 一字も変わらない 共謀 67.39% 破壊 0% ② k = 3 で一票欠けると名指ししない --- --- k = 3、定足数 = 2、一票が欠席または提出拒否 1-1 の同数 → 未決、名指ししない これは意図的な設計上の選択です。その意味はこうです。 名指しが前提とするのは"},{"t":"受け入れスイートをプログラムからデータに変えたら、納品率の低下は 75% から 2.7% になった","u":"/ja/blog/suite-as-data.html","g":"記録と多者実行","s":"攻撃者が状態を持つゲージの変種を書き、ゲージは両方向で満点なのに、納品率は 75 ポイント下がりました。直し方は、スイートに残すものを三つだけにすることです。方言、エントリーポイントの名前、入力—期待値のリテラル値の一覧です。","b":"問題：ゲージは役に立たないものに食わされうる 2026-09-06、R451。 段階 結果 --- --- スイートを commit に結びつける、 平凡なスイート （読み込めれば合格扱い） 371 / 371 すべて拒否 —— 正常 状態を持つゲージの変種 納品率が 75.20 pp 低下 ゲージの報告 ok （両方向とも満点） 攻撃の仕組み もとのスイートは 信頼されたコードの一片 でした。それは次のことができました。 1. 外部の状態を読む。 2. 呼び出されたときに自分自身や環境を変える。 3. 「既知の誤りのサンプル」に対してだけ正しく振る舞う。 多者実行はこれを防いでいませんでした—— どの票も誠実で、どのチェーンも検証を通る からです。 直し方：SuiteSpec スイートを 三つのもの に制限します。 --- --- 1. 方言 Python / 特定のバージョン 2. エントリーポイントの名前 solve 3. 「入力—期待値」のリテラル値の一覧 純粋なデータ 実行器は 自分の決定的なレンダラーだけを使って 、このデータからテストコードを生成します。レンダリング結果のハッシュは マシン間で照合できます 。 効果 攻撃 修正前 修正後 --- --- --- exec の密輸 （候補プログラムが実行時にテストコードをすり替える） 368 / 371 0 / 371 generic_gauged（残余） — +2.72 pp weak_oracle（事後の上限） — +4.35 pp 意味のある範囲 — MBPP+ の上だけ なぜ残余の +2.72 ポイントは消せないのか {{note:limit これはゲージの定義上の境界です ゲージの検査が検証できるのは、 参照解が合格する こと、 既知の誤りのサンプルが止められる ことです。 検証できないのは、 このテストが要求をカバーしている ことです。「弱いゲージ」（weak oracle）は、既知の検査をすべて通りながら、本当の要求の大部分を見逃すことがありえます。 したがって： ゲージの種類 実現可能な残余の"},{"t":"定義は五回変わった：「責任の構造」から「レシートのない納品は受け取らない」へ","u":"/ja/blog/definition-five-versions.html","g":"研究の経緯","s":"九か月の間に「Vacant とは何か」は五回書き直され、そのたびに主張は小さくなりました：「エージェントが自発的に採用する責任の構造」から「検証可能なレシートのない納品は受け取らない」へ。この縮小の過程そのものが本研究の貢献です。","b":"五つの版 時期 定義 なぜ変えたか --- --- --- 2026 年 4–5 月 一種の「 住人の形式 」：エージェントが自発的に採用する責任の構造で、鍵・記録・公開の評判を持つ。ネットワーク自身が判定し、中央の審判はいない 出発点。理論文書 V3–V5 は二回の敵対的レビューを経て、38 の攻撃ベクトルを一つずつ防止／検知／コストを上げるに分類した 2026 年 6 月 「 永続し、進化し、説明責任を問える subagent 」、やがてエージェントが必要に応じて取り出せる能力層へと収束し、検証—修正を中心に据えた 合意会議での 63 のエージェントによる批判 が、架空の引用と未実装の仕組みを見つけた。「エージェントごとに一つのインスタンス」は計算コストが高すぎた 2026 年 7 月 住人＝ 身体 （凍結されたモデル）＋ 記憶 （イベントストリーム）。責任は審査された記憶に宿る KS-1 が単一エージェントの責任仮説を反証した。独立審査は「アカウンタビリティは信頼と同じではない」と判定した 2026 年 8 月 「誰が何をして、誰が確認したか」を 後から再検証できる記録 にし、悪いことをした者が仕事を受け取りにくくする 8 月 17 日の二つの修正： 責任を問う主体 、 防御は利得と同じではない 2026 年 9 月 受け取り口 ：検証可能なレシートのない納品は受け入れない。実行可能な受け入れゲートを主力とし、プロセスの終了を納品点とする 委員会式の設計は同予算では多数決に勝てなかった。受け入れゲートが利得の主体になった 各版が退けられた理由 第一版 → 第二版：63 のエージェント 2026-06-11 から 06-13 までの合意会議。63 のエージェントによる批判が見つけたもの： - 架空の引用。 たとえば I-CALM の「幻覚 −50%、正解率 +2–8%」は 原文にありません 。 - 未実装の仕組み。 五月の理論にあったいくつかの概念は、コードの中に対応する実装が見つかりません。 - 計算コスト。 「エージェントごとに一つのインスタンス」という設計はも"},{"t":"KS-1：凍結されたモデルの上では、「結果を本物らしく書く」ことと「結果を本物にする」ことは同じことである","u":"/ja/blog/ks-one.html","g":"研究の経緯","s":"2026-06-28、二つの主な検証設計が、17 体と 10 体のエージェントによる敵対的ワークフローで潰されました。それらを潰した事実は、後に本研究全体の方法論の核になりました。","b":"潰された二つの設計 2026-06-27/28 の主な検証の目的は、「責任構造はエージェントの行動を変えられるか」を測ることでした。 --- --- 版その一 「主検証の再設計：減衰タスクにおける責任構造」 版その二 「主検証の確定版 v2（post-adversarial）」 敵対的ワークフロー 17 体のエージェント / 10 体のエージェント 結果 二つとも潰された voids は設計史として保存 ——削除したのではなく、「これは設計の歴史であって、有効な仕組みではない」と標示しています。 それらを潰した一文 なぜこれが致命的なのか KS-1 が成り立つ論理は単純です。 1. モデルは 凍結されている （ファインチューニングも学習もない）。 2. それに影響を与えられる唯一の入力チャネルは プロンプト である。 3. したがって、どんな「仕組み」も行動に影響を与えるには、プロンプトを 通らなければならない 。 4. ゆえにこの設定では、「仕組み」と「より良いプロンプト」は 区別できない 。 これがどうやって設計上の制約になったか KS-1 は後に、プログラムの中の 二つの実行可能なガード になりました。 なぜ Agrawal ら（2025）によってそれが必要になったのか それが後のすべての実験にどう影響したか {{note:good 三つの具体的な結果 ① 利得軸のすべての比較で、一字一句同じプロンプトテンプレートを強制しています。 R437 の三つのアーム（OFF／ON／OFF5）の prompt テンプレートは一字一句同じで、ON と OFF5 の差は仕組みからしか生じえません。 ② 記憶の三アーム（E11）の設計 ：M0（注入なし）、M1（直近 k 件の原文を注入）、M2（教訓に蒸留）。三つのアームの 違いは記憶の出どころであって、記憶の言い回しではありません 。 結果は M0 8/12、M1 8/12、M2 8/12—— 三つのアームはまったく同じ で、元の文書には「いかなる効果の主張を支えるにも足りない」（原文：「不足以支撐任何效果宣稱」）と書かれていま"}]}