FAQ
呼び名の比較、自分のプロジェクトに使えるか、LangSmith／OpenTelemetry／ブロックチェーンとの違い、そして何度も尋ねられたのに私たちが「分からない」としか答えられない質問。
#これは何か
#説明責任を問える（accountable）と信頼できる（trustworthy）は何が違うのか？
信頼できるはシステムの性質についての判断です。説明責任を問えるは記録の性質についての判断です。
私たちの厳密な定義は、特定の鍵が署名したイベントの追跡可能性と検証可能性であり、心理的な意味での信頼は含みません。
なぜ「信頼」を使わないのか：信頼の古典的な定義には「監視しなくてよい」が含まれますが、監視こそが Vacant のしていることです。「信頼を高める」と言えば「確認を少し減らしてよい」と読まれてしまいます。それは逆の方向です。
2026 年 7 月の独立したレビューがこの点を言い切りました。結論は一文です。
このアーキテクチャが現在高めているのはアカウンタビリティであって、信頼ではない。
アカウンタビリティ層に完全な説明があります。
#なぜ Vacant という名前なのか？
英語で「空いている、誰も占めていない」という意味です。エージェントのエコシステムの中でまだ埋められていない空白を指すのに使っています。エージェントの行動が記録され、検査され、結果を伴うようにする責任の層です。
#これは別の AI フレームワークなのか？
違います。エージェントがどう推論し、どうツールを呼ぶかを代わりに決めることはしません。 外側を包む層です。あなたが書いた受け入れテストを一度実行し、合格したときだけあなたの手元に届けます。
#ほかのものと何が違うのか
#vs OpenTelemetry／構造化ログ
| OpenTelemetry | Vacant | |
|---|---|---|
| 記録 | テレメトリとトレース | 署名付きイベントチェーン |
| 完全性の保証 | 伝送層のベストエフォート | 一つのセルを書き換えるとそのセルで切れ、誰でもオフラインで再計算できる |
| 審判 | なし | あなたの実行可能な受け入れテスト |
| 誰が書けるか | 権限を持つ任意のプロセス | 鍵が必要 |
一緒に使えます。Vacant が生成したレシートは、OpenTelemetry の span の属性として扱えます。ただし trace を置き換えるものではありません。
#vs LangSmith／promptfoo のような評価ツール
それらは評価です。問題と答えをひとまとまり渡すと、点数を教えてくれます。
Vacant の違いは、審判が人の書いたルールではなくデータであること、そして判定結果が、後から再検証できるチェーンに署名して残されることです。受け入れゲートのページに、committee 方式の評価との同一予算での比較があります——委員会は多数決に負けました。これは私たちが自分で測ったものです。
#vs ブロックチェーン／notary
違いは三つです。
- ブロックチェーンには合意とインセンティブが必要です。 Vacant にはありません——Vacant は分岐を許すので、公開鍵を持つ人は誰でもそれぞれ自分のチェーンを走らせられます。
- ブロックチェーンはリプレイ攻撃を防御します。 Vacant はリプレイを防御しませんが、リプレイと順序の乱れを検知します。
- ブロックチェーンのコストは改ざん不可能性のためのものです。 Vacant のコストは署名そのものだけです。
言い換えれば、Vacant はブロックチェーンではなく、署名付きの append-only log に実行可能な審判を一つ加えたものです。身元と署名記録
#vs in-toto／SLSA／Sigstore
方向が逆です。 それらはソフトウェアサプライチェーンのやり方で、ビルドする側が証明（attestation）を生成し、利用する側が検証します。
Vacant は受け取り口です。検証可能なレシートのない納品は受け入れられません。publish モジュールの資格情報の構造は、SLSA の検証サマリー証明から取っています。
違いは誰が判定するかです。サプライチェーンは「この成果物はこのパイプラインで作られた」ことを証明し、Vacant は「この成果物はあなたの受け入れテストに合格した」と判定します。
#自分のプロジェクトに使えるか
#使えます。ただしテストを書く必要があります
これは絶対条件です。
もしあなたの要求が実行可能なテストに書けないなら——「四半期報告書を書いて」——ゲートには審判がおらず、そのとき「モデルに聞く」に退化します。そしてそれこそが、私たちの測定で最も効果の悪かったものです。
#三つの接続方法、強制の度合いはそれぞれ違う
| 形態 | 強制性 |
|---|---|
| ライブラリ／MCP ツール | 任意——エージェントが呼ばなければ、Vacant は介入しようがない |
| コントローラ | 自分で起動した子プロセスにだけ |
| ループを持つ実行フレームワーク | 完全に強制 |
インストールのページに完全な説明があります。
#遅くならないか？
遅くなります。正直に言います。
- ゲートは平均 1.51 – 1.71 回の呼び出し/問（単発は 1.00）。
- 比較基準の OFF5 は 5.00 回の呼び出し/問。
- H-MIX は OFF に対して 2.23 – 2.78× の token/問。
token の完全な帳簿（reasoning の占める割合を含む）
これは成功率の向上であって、token 効率の向上ではありません。 効率の向上と言えば、それは私たち自身が反証した言い方になります。
#結果についての質問
#いちばん誇りに思っている数字はどれか？
「一回だけ試すより 14–19 ポイント多い」ではありません——あれは私たち自身の安定性ルールで格下げされました。
最も硬いのはこれです：三つのループアームを単発（1 回だけ引く）と比べると、15 ブロックすべてがそれぞれの Holm 補正を通過し、差は +17.5 ~ +29.2 ポイント、5 回の再現と、互いに重ならない四つの問題セットにまたがっています。
#自分たちで何を反証したのか？
最も痛かった三つ：
- 「AI の評価者委員会は多数決より優れている」 — 反証。評価者の票はほぼ定数でした（正確度 0.7552 vs 知能ゼロのベースライン 0.7522）。
- 「修正ループは再サンプリングより優れている」 — 同符号・未解決に格下げ。5 回の再現で Holm を通過したのは 0/5。
- 「出口で止める」 — 反証。監査で、納品拒否が単なるフラグにすぎないことが分かりました。
#なぜまず自分のものを反証するのか？
それが自分自身に対して説明責任を果たせる唯一の方法だからです。説明責任を問えると主張するシステムが、自分の主張について説明責任を問えないなら、その主張には中身がありません。
実務上も必要でした。2026-09-19 の監査で「出口で止める」が成り立たないことが分かりました。もし私たちがその時この語彙を使っていなかったら、この誤りはサイトに残ったままだったでしょう。
#私たちが分からないこと
#人はこれによって、より思い切って AI に頼るようになるのか？
分かりません。 利用者を募集しておらず、信頼を測っていません。
「根拠のある依存」は私たちの用法では技術用語であり（独立に確かめられる受け入れ結果と記録の上に成り立つ）、心理測定の結果ではありません。
#受け入れテストの出来の良し悪しで、ゲートの効果はどれだけ変わるのか？
測っていません。 これは私たちが自分で挙げた次の一歩の第一位です。ゲージ検査が与えるのは片側の保証だけです。既知の誤りを防げても、本当の要求をカバーしていることにはなりません。
#あなたの攻撃者モデルは現実に合っているのか？
完全には合っていません。 メカニズムのシミュレーションは安全性を立証できず、攻撃コスト上界の下界を与えるだけです。攻撃者の戦略空間は固定で書き込まれた三〜四種類です。盲点の真の値には外生的な錨がありません。
#これは本番環境で使えるのか？
私たちはそのような主張をしていません。 現行の製品経路では、秘密鍵は同じ OS ユーザーが読める平文のファイルで、ハードウェアによる保護はありません。これが「アカウンタビリティは信頼と同じではない」の第一の理由です。
