記録と多者実行
レシートチェーン 194 本、9,841 件はすべて検証を通りました。嘘をつく鍵は 273/273 で名指しされ、誠実な参加者が誤って告発されたのは 0/1,840 でした。しかしチェーン検証は切り詰め・分岐・記録漏れを捕まえられず、相互実行は「受け入れスイート自体の腐敗」に対してまったく防御がありません。
#レシートチェーンの検証
| バッチ | チェーン数 | 件数 | 結果 |
|---|---|---|---|
| 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 タスク × 5 候補 = 1,840 候補、macOS + Linux | 可視受け入れラベルが 1,840 / 1,840 一致；両方のチェーンとも検証を通過 |
| R454 名指し | k=3、嘘をつく鍵 1 本 | 嘘のセルの名指し 273 / 273；誠実な参加者の誤告発 0 / 1,840；矛盾する署名のセルの判定が正しかったもの 58 / 58；証言 5,519 件で署名失敗 0 回 |
#数学的な上界
| 許容上界 | ⌊(k − 1)/2⌋ |
| 過半数を超えた後の誤告発率 | 0.175（r446 371 問 × 5）／0.374（r443 91 問 × 5） |
過半数が共謀すると結果は反転し、かえって誠実な参加者が名指しされます。しかも仕組み自身は、自分が閾値のどちら側にいるのかを知りません。
#固定点：受け入れスイート自体の腐敗
スイートが「読み込んだだけで合格」に差し替えられたら、すべての票は誠実で、すべてのチェーンは検証を通り、それでもシステムはゴミを納品し続けます。
| 段階 | 納品率の変化 |
|---|---|
| スイートを commit に紐づけ、平凡なスイート | 371 / 371 すべて拒否（正常） |
| 状態を持つ変種 | −75.20 pp、しかもゲージは ok を返す |
| 修正：SuiteSpec（exec の密輸） | 368 / 371 → 0 / 371 |
| 残余：generic_gauged | +2.72 pp |
| 事後の上界：weak_oracle | +4.35 pp |
#オフラインビューアの構造的な限界
R455：単一ファイルのオフラインビューア（exhibit/receipts/receipt_viewer.html、0.3 MB；多者版は 4.5 MB）はレシートをファイル内に埋め込んでおり、外部リソースゼロ、ネットワークリクエストゼロです。
攻撃：攻撃者が自分の鍵でチェーン全体を鋳造し直し、埋め込まれたレシートもそれに合わせて書き換えれば、ビューアはそれでも検証を通します。
緩和策は、三つの vacant_id を物理的なラベルに印刷し、チェーンの外に、一緒に鋳造し直すことのできない錨を置くことです。
#既存のエージェントプラットフォームへの接続の実測
#五種類のエージェント
| エージェント | バージョン |
|---|---|
| pi | 0.85.1 |
| OpenCode | 1.18.31 |
| Claude Code | 2.1.278 |
| Codex | 0.147.0 |
| Hermes | 0.19.0 |
20 セル（2 セル × 2 回の実行 × 5 エージェント）はすべて事前に書いた判定基準どおりで、レシートチェーン 20 本 / 40 件です。
#公開問題バンクのゲート
LCB v2 × 10 問。
| バッチ | 結果 |
|---|---|
| pbgate（20 セル） | 納品:差し止め = 15:5 |
| pbgate2（30 セル、1003、reasoning オン） | pi 5:5、Claude Code 7:3、OpenCode 7:3；非公開チェック 19/19；stub 陰性対照 10/10 |
| pbgate3（30 セル、1004） | 24:6；非公開チェック 24/24 |
| 三つのアシスタントの一致度 | 一致したのは 4 / 10 問のみ |
pbgate2 と比べると、三つのエージェントはそれぞれ 5 / 2 / 2 セルで結果が反転しました。
#Hermes と MCP のエンドツーエンド
| 段階 | 結果 |
|---|---|
| 2026-06-19 の観測 | ローカルで 2 回の呼び出し；VM 上で 16 回連続の verify_fix、すべて verified:true + 署名 |
| 2026-07-05 のエンドツーエンド実録 | Hermes が自律的に delegate を選択；1 ラウンドあたり 2.6 秒、モデル呼び出し 1 回、エンドツーエンドで約 20 秒；179 テストすべてグリーン；credit 0.5 → 0.535 |
| 2026-07-09 の実現可能性検証 | VM リセット後 pytest 189/189；24/24 delegate、イベント 96 件；on アームの壊れた納品 4 件はすべて捕捉、off アームの壊れた納品 3 件は黙って通過し、説明責任を問える痕跡はゼロ；リプレイ 29/29 |
#pi-tty
40 セル、5 アーム：受理 PRT 6/10、PTP 5/10、INT 6/10、INT2 3/5、INTQ 0/5。-p と TUI の最初のリクエストのバイト列は 5/5 で同一です。
#R535 再試行チャネル
gemma-4-12b + pi 0.85.1；自作の 90 タスク（S1 50、S2 40）× 4 アーム = 360 セル。
| S1（H1 が M1 で反証された後の再テスト） | +0.860 [+0.760, +0.940]、b=43 c=0、p = 2.27e-13 |
| S2 | +0.400 [+0.225, +0.550]、b=17 c=1、p = 1.45e-4 → CONFIRMED_POSITIVE |
#ネガティブ監査
#ABPI 監査（391 セル、2026-09-20）
| チェック | 結果 |
|---|---|
| サーバー側の対話に欠落はあるか | なし、2,755 ラウンドすべて一致 |
| レシートチェーン | 195 / 195 が検証を通過 |
| レシートのレベル | すべて C レベル（サンドボックスなし、フックなし） |
| 「出口で止める」は成り立つか | 成り立たない |
納品拒否はフラグと終了コードにすぎず、外側のスクリプトは終了コードを読みません。納品拒否の 59 セルのうち 7 セルで、ファイルが外にコピーされ採点されていました。 本物の上流 URL はエージェントの環境変数に残ったままでした（コマンド一つで迂回できます。そのバッチでは起きなかっただけです）。requests_seen は下限です。フックは一度もインストールされていませんでした。
#デジタルツインの展示品（54 セル、実際のモデル呼び出し 630 回）
| 条件 | 受理 |
|---|---|
| インターフェースが必要な情報を提供しない | 0 / 27 |
| インターフェースが必要な情報を提供する | 24 / 27 |
| やり直しループで救済 | 0 / 30 |
ほかに、エージェントが成功を宣言したのに可視チェックが失敗したものが 82 回、タイムアウトで強制終了されたものが 8 回ありました。
#2026-07-26 の展示品（TWIN）
54 セル：30 件を差し止め、やり直しで救えたのは 0 件（うち 27 件は、問題文で関数名を意図的に隠していました）。デフォルト設定では、納品拒否はマークであって壁ではありません。ファイルを止めるには、サンドボックスの中で実行する必要があります。
#フレームワークのフックと隔離壁（2026-09-20）
陰性対照 7/7；bwrap はゲート以外のすべてを遮断；五種類のエージェントのフックはどれもシェルコマンドを止められます——しかしエージェントは自分のフック設定を削除できます。
実際のエージェントによる最初の A レベルのレシート：pi が 1003 で実行し、説明のつかない呼び出しは 0 件でした。
#BARE アーム（手ぶらの成功宣言）
b1003：25 セル；b1004：0 セル。
#接続層の計測ツール
agentlane（2026-09-22、コミット 36609614）：一つのセルが合格するには、三つの独立した情報源が一致する必要があります——requests_seen ≥ 1、プロキシサーバーのインデックス行数 == requests_seen、エージェントの終了コードに値があること。毎ラウンド陰性対照を実行します（上流を閉じたポートに向ける）。納品が受理されるかどうかは、意図的に判定基準に入れていません。
最初のスモークテストで見つかったこと：OpenCode は指定した作業ディレクトリを無視し、納品物を別の場所に書き込んだため、仲介はすべて合格したのに全セルが納品拒否になりました。さらに OPENCODE_CONFIG_CONTENT はユーザーの MCP 設定を消してしまいます。
#この先
- 一件ずつの判定：証拠台帳
- 本研究が主張しないこと：限界と保証しない事項
