中心概念 · 概念 / 手順まで追う / 2026-09-24 ·
アカウンタブル・トレース
汎用の受け取り口は「この納品物は合格か」には答えますが、どこが不合格か、どの手順で誤ったか、誰が誤ったかは言えません。トレースは手順まで切り込みます：どの結論も二層に分かれ、再実行で反転を示せる層だけが評判上の帰結につながります。
このページが引用する判定 5 件：成立 5クリックするとその主張カードへ移動します
論文の一文による位置づけは「誰が何をしたかが分かり、誤りが起きたときにたどり戻せる」です。レシートと汎用の受け取り口がしていたのは後半の「誤りが起きたとき」だけで、しかも三つのものが欠けていました。
それはどこが不合格か（ClaimResult に位置がない）、どの手順で誤ったか（手順の記録がない）、誰が誤ったか（行為者がいない）を言えず、フィードバックは汎用の文章だった。
2026-09-24、人間が受け取り口を全面的に使ってみた後の生の言葉：
今のこの版は、ローカルで検証に使える検証器を複数持たせるものであって、責任を問い誤りの箇所を突き止めるものではない。（原文：「你現在的這個版本是讓本機多個可以去驗證的驗證器，並非是咎責且抓出錯誤點的東西。」）
トレースはこの三つを補うものです。同じラウンドで四つのことが確認されました：責任を問う対象は手順と行為者の両方であること。誤りの箇所とは誤りを生んだ手順までたどることであること。帰結は評判＋ルーティングであること。利用場面は人が一つのエージェントを直接使うことであること。
#「誤り」の出所は三つだけで、止められるのは最初の二つだけ
| 出所 | 止められるか | 説明 |
|---|
| 契約 | 止められる | 既存の検証器。ここは変えない |
人によるマーク vacant flag <path>[:<行>-<行>] "<どこが誤りか>" | 止められる | 署名し、納品物の sha256 と位置に結びつける |
| 能動的な決定論的検査 | 止められない | 注意を促すだけで、止めない |
能動的な検査は二つだけです：unsourced_number（出所のない数字）、unhandled_failed_command。
#二層の帰属
これがこの系列全体の中心となる仕組みです。
provable の定義は、三つの条件が同時に成り立つことです。
- 再構築した状態の上で再実行する
- ちょうどこの手順で合格から不合格に変わる
- 誤った値が固定されたどの入力にも、観察されたどの読み取りにも含まれていない
五つのレベルにはそれぞれ異なる帰結があります。
| レベル | 帰結 |
|---|
provable | その行為者に record_review(0, weight=1.0)。slash はしない |
lineage_exact | 行為者は動かさず、出所に一件カウントを記録する |
lineage_internal | それを生んだ手順までさかのぼってから改めてレベル分けする |
heuristic | 動かさず、報告するだけ |
gap | 誰も動かさず、「統合カバレッジ」に記録する |
評判のキーは四つ組です：(プラットフォーム, エージェント定義, モデル, タスク族)。各セルの n は長期的に一桁なので、常に回数と区間を表示し、裸の得点は表示しません。n < 5 では何の行動も取りません。人は評判表に入りません——利用者が一人しかいないときに、その人を採点するのは敵対的だからです。
#エンドツーエンドの証拠
三つの表はすべて L-fake です：モデルは台本どおりに答える偽の上流で、本物のモデルも API 鍵もありません。四つの本物のエージェントの binary と本物のフックは本物です。
| バッチ | セル数 | 帰属が正しい | 位置付きのフィードバックがモデルへのリクエストに入った | フィードバックに行為者の識別が含まれる |
|---|
| ネイティブフック × 八つの誤り埋め込みシナリオ | 33 | 33/33 | — | 0/33 |
vacant do | 25 | 25/25 | 25/25（OpenCode も同様） | 0/25 |
| 本物の対話 TUI（tmux 疑似端末） | 16 | 16/16 | 16/16 | 0/16 |
フック一回あたりの追加時間の p95 は 6.3–13.3 ms（小さな作業領域）。複数ターンのセルでは、前のターンがラウンド数 4/4 を本当に使い切っていました。
#フィードバックに行為者の識別が含まれたことは一度もない
これは設計上の線引きであって、欠陥ではありません。
責任を問う対象は手順と行為者ですが、フィードバックは人にだけ見せます。理由は、読み取りのカバレッジが下限にすぎないからです。
フックが見られるのはツールの出力（Read のファイル内容、コマンドの stdout、WebFetch の結果、子エージェントの返信）で、モデルのコンテキストにもともとあるもの、シェルコマンドの実行中に読まれたファイル、Codex がホストする web_search の結果は見えません。
だから「出所が見つからない」ことから「エージェントの誤り」を単独で導いてはなりません。どの報告も三値の read_coverage を持ちます。
#いつ介入するか
| 設計パートナーの提案 | 実際の採用 | 理由 |
|---|
| 検知 | 書き込みのたびに安価な検証を実行する | Stop のときに、再構築した各手順の状態の上で再実行する | コストをツール呼び出しごと（30 秒の予算）から Stop（600 秒）へ移す |
| フィードバック | — | 一件、≤12 行、安定した finding id | |
作業領域のスキャンでは「契約に列挙された納品物だけをハッシュする」という提案を採用しませんでした。理由は測定です：Claude の Bash と Codex の shell によるファイル書き込みは、どのプラットフォームの通信路でもコマンド文字列しか残りません。代わりに作業領域全体を増分で扱うようにしました（サイズと mtime が変わっていなければハッシュを再利用）。
#七つの誠実な限界
言うことを明確に禁じられている三つの文：
❌「Vacant はすべての誤りを捕まえる」 ❌「トレースは必ず正しい」 ❌「エージェントは迂回できない」
言ってよいのは：「記録のある手順の中で、この検査は第 k 手順で合格から不合格に変わり、第 k 手順は X が行った。証拠は再実行できる。」
#今日証明できないこと
証明できないこと：本物のモデルのもとで、成果物が要求により近づくこと。
事前登録する予定の実験はまだ実行していません：三つのアーム——RS（三回の再サンプリング、フィードバックなし）、RF（汎用フィードバック）、RL（位置特定されたフィードバック）。一般タスクとプログラミングタスクは別々に報告し、主要な結果は accepted ∧ hidden pass です。
#次に読むもの
