アカウンタビリティ層
「説明責任を問える」は「信頼」と同じではありません。これが Vacant の中心的な定義で、研究期間中に五回書き換えられ、そのたびに主張は小さくなりました。この表が現在唯一有効な版です。
#現在の定義
受け取り口：検証可能なレシートのない納品は受け入れられない。
強制点は受け入れ時にあり、実行時にはありません。下流は受け取る際にレシート上のハッシュを再計算し、署名を検証します。しかも一枚のレシートは一度しか消費できません。
本研究の正確な用語で言えば、これは「後から再検証でき、改ざんが察知できる記録」です。
#なぜ「信頼」と言わないのか
信頼の古典的な定義には「監視しなくてよい」が含まれます。しかし監視こそが Vacant のしていることです——Vacant はその監視層そのものです。「信頼を高める」と言えば「少し確認を減らしてよい」と読まれますが、それは逆の方向です。
2026 年 7 月のある独立審査が、この点を決定づけました。審査の結論は一文です。
このアーキテクチャが現在高めているのはアカウンタビリティであって、信頼ではない。
さらに審査は、「信頼と言える」ために同時に成り立たなければならない三つの条件を挙げ、そのうち二つは端的に成り立っていません。
| 信頼と呼ぶために成り立つべきこと | 現状 |
|---|---|
| ① シグナルを安価に偽造できない | 成り立たない — 誰でも他人の stream_id を名乗ってその評判を引き継げる（PoC 実測 0.50 → 0.7417） |
| ② 罰が実際に効く | 成り立たない — slash は証拠の比率を保つため、低得点者にとってはむしろ報酬になる：破壊者 0.0161 → 0.0312 → 0.0588 → 0.1053 |
| ③ 監査の錨が信頼できる | 部分的に成り立つ — 決定論的リプレイは本物の錨だが、サンプリングのシードが固定で公開されており予測できる |
そこで私たちは「説明責任を問える」と言い換えました。アカウンタビリティ（accountability）は本研究では技術用語です：特定の鍵が署名した事象の追跡可能性と照合可能性であり、心理的な意味での信頼は含みません。
#定義の五つの版
これは本研究全体で最も重要な自己修正の記録です。どの版も言い回しの調整ではなく、一つ前の版の主張を狭めたものです。
| 時期 | 定義 | なぜ変えたか |
|---|---|---|
| 2026 年 4–5 月 | 一種の「住人の形式」：エージェントが自発的に採用する責任の構造で、鍵・記録・公開の評判を持つ。ネットワーク自身が判定し、中央の審判はいない | 出発点。理論文書 V3–V5 は二回の敵対的レビューを経て、38 の攻撃ベクトルを一つずつ防止／検知／コストを上げるに分類した |
| 2026 年 6 月 | 「永続し、進化し、説明責任を問える subagent」、やがてエージェントが必要に応じて取り出せる能力層へと収束し、検証—修正を中心に据えた | 合意会議での 63 のエージェントによる批判が、架空の引用と未実装の仕組みを見つけた。「エージェントごとに一つのインスタンス」は計算コストが高すぎた |
| 2026 年 7 月 | 住人＝身体（凍結されたモデル）＋記憶（イベントストリーム）。責任は審査された記憶に宿る | KS-1 が単一エージェントの責任仮説を反証した。独立審査はアカウンタビリティが信頼と同じではないと判定した |
| 2026 年 8 月 | 「誰が何をして、誰が確認したか」を後から再検証できる記録にし、悪いことをした者が仕事を受け取りにくくする | 8 月 17 日の二つの修正：責任を問う主体、防御は利得と同じではない |
| 2026 年 9 月 | 受け取り口：検証可能なレシートのない納品は受け入れない。実行可能な受け入れゲートを主力とし、プロセスの終了を納品点とする | 委員会式の設計は同予算では多数決に勝てなかった。受け入れゲートが利得の主体になった |
#三つの帰結を分けて述べる
誠実な防御の言葉遣いは本研究の厳格なルールです。どの仕組みも、それが防止するのか、検知するのか、コストを上げるのかを明示しなければなりません。
| 脅威 | 防御 | 強度 |
|---|---|---|
| 記録の事後改ざん | ハッシュチェーン＋署名 | 検知する（鍵の保管が成り立つ場合は偽造を防止できる） |
| なりすまし | Ed25519＋公開鍵の公示 | 防止する（鍵の保管が成り立つ場合） |
| リプレイと順序の入れ替え | 通し番号、直前のハッシュ、重複排除 | 検知する |
| 評価を別の納品に付け替える | 評価者をチェーン先頭に結びつける。基盤とタスク族は納品側が宣言する | 防止する |
| 票の水増しとシビル攻撃 | 重みの内生化、未証明の評価者は 0.1/k、同一出所の重みを下げる | コストを上げる |
| 身元を替えての洗浄 | 見習い期間の上限、強制監査、信用はイベントストリームに付いて回る | コストを上げる |
| 評価者の集団的な虚偽 | 決定論的なサンプリング監査 | 検知する（確率はサンプリング率） |
| 悪い仕事をしても仕事を受け取り続ける | UCB ルーティング、罰、減衰 | コストを上げる |
#六つの設計原則
現行アーキテクチャのすべての部品は、この六つから導かれています。
- 中央の審判はいない。 「誰に確認する資格があるか」を決められる役割は、どれもシステム全体が信頼しなければならない対象になります。だからピアレビューにはホワイトリストがなく、監査のサンプリングはハッシュ値で決まり、登録所は公示の集約層にすぎません。
- 誠実な防御の言葉遣い。 上の表を参照してください。
- 意見の代わりに実行を、投票の代わりにレシートを。 決定論的な実行で判定できることはモデルの判断に委ねず、署名付きの記録で証明できることを多数決で代用しません。
- 評判は記憶に付いて回り、身体には付かない。 評判の会計単位はイベントストリームであり、鍵やモデルではありません。モデルを替えたり記憶を消したりすれば、信用は引き継がれません。
- 測っていないことは、ゼロと測ったことではない。 すべての網羅性の項目は三値（真／偽／未測定）を取ります。納品拒否は失敗に数え、インフラの失敗はモデルの失敗に数えません。
- 説明責任を問えると主張するシステムは、まず自分自身に対して説明責任を果たせなければならない。 反証された主張は削除せず、判定とともに主張索引に保存します。
#本研究が主張しないこと
- Vacant が人間の AI に対する信頼を高めたこと（利用者を募集しておらず、信頼を測定していません）。
- パルス攻撃、共通の盲点、あるいはいずれかの単一要素が新しい発見であること。
- 修正ループが同予算の再サンプリングより優れていること。
- システムがシビル攻撃に耐えられること、あるいは正しさを保証すること。
3 番目は、かつて私たち自身が主張していたもので、2026 年 9 月 13 日に私たち自身の五回の再現によって反証されました。五回の再現のあと：見出しの主張は自分たちの安定性ルールに負けた
#検証の希少性
同じ理論文書は、信頼を機能的に「許容できる残余リスクのもとで、委任する側が合理的に省略できる検証の量」と定義しています。これが仕組みの境界を与えます。
- 検証が希少な場面では、アカウンタビリティ層の総便益が総コストを上回る可能性があります。
- 検証が無償な場面では、それは純粋なオーバーヘッドです。
- 要求を形式化できない場面では、使える審判がいません。
私たちの利得実験が測っているのは、まさにこの代替物の一つの側面です：受け入れテストが与えられた条件のもとで、納品の成功率がどれだけ上がり、その代価が何 token か。
