WEXP Coverageが問う記録の外の一件と管理権限

要約

Mikhail Sergeev が2026年10月23日に提出した個人草案 WEXP Coverage は、署名済みの受領記録が本物であることと、対象範囲のすべての行為に受領記録があることを別の問いとして扱う。PostgreSQL の例では、行為を閉じた期間の台帳への確定書き込みに絞る。
問われるのは収集の前提を誰が承認するかだ。台帳を支配する者が記録を迂回できるなら、その者の「漏れはない」という説明を受け入れる権限と理由を、結果の利用者が確かめなければならない。

受領記録の外にある一件

監査画面の緑色の印は、表示された受領記録が検証に通ったことを示す。画面に一度も載らなかった行為については、何も語らない。Mikhail Sergeev の WEXP Coverage 草案が突きつけるのは、この見えない一件である。署名と照合の精度を上げても、収集経路を通らなかった行為は後から画面に現れない。

10月23日付の文書は、万能な監視装置を提案しているわけではない。対象、締め切り、行為と受領記録の同一性、収集経路、受け入れた仮定を指定し、どこまでの主張を支えられるかを評価する。IETF Datatracker上の位置づけは、RFC の流れに入っていない個人 Internet-Draft だ。標準として採択されたという話でも、実在の運用現場で欠落が起きたという報告でもない。提案の面白さは、監査の「完全」の中に隠れがちな権限関係を露出させた点にある。

数える前に分ける

草案は実際の行為を A、作成された最終受領記録を C、指定された受取人が期限までに利用できる記録を R と呼ぶ。評価器に渡されたビューは Cv と Rv、行為の証拠となる元データのビューは S だ。S の内容が改ざんされていないことと、S が A の全件を含むことは別の命題になる。

この区分には実務上の意味がある。要求が失敗して再送されても、行為が二回起きたとは限らない。データベースへの確定書き込み後に応答だけが失われたなら、応答がなくても行為は成立しうる。受領記録が作成されても相手に届かなければ配達の問題であり、行為が成立したのに記録が作られていなければ作成の問題だ。都合のよい列を合計して「件数が合った」と言う前に、何を一件とするか決めなければならない。

提案された十個の主張識別子も、そのためにある。creation-complete は各行為に最終受領記録があるかを問う。creation-sound は各記録に対応する行為があるかを問う。creation-exact は一対一の対応を要求する。配達、元データ、渡されたビュー同士の対応、「行為がゼロ」という主張にはそれぞれ別の名前がつく。「完全」という一語に、違う検査を詰め込む余地が減る。

元データのファイルと受領記録のファイルが一行ずつ一致しても、それだけで全行為が捕捉されたとは言えない。元データを作る前に一件が迂回されれば、二つのファイルは同じ欠落を共有する。草案は、取得に失敗した元データを空の配列に置き換えることを禁じる。読み終えたうえで空だった状態と、そもそも読めなかった状態を混同させない。空の配列に署名しても、失敗した取得処理は成功しない。

誰の仮定かを残す

前提は検査済み、政策によって受け入れた仮定、不明、反証済みに分けられる。仮定を採用するなら、その権限を持つ主体、理由、適用範囲を明記する必要がある。「すべて収集された」をそのまま収集の完全性の根拠にしてはならない。書き込み経路、関係者の権限、失敗時の分岐、迂回可能な入口が審査の対象になる。

管理者が元データを書き換えられる場合、復元によって履歴が入れ替わる場合、分岐した履歴の一方だけを示す場合、あるいは台帳を通さず受領記録を発行できる場合を考えよう。二つの一致する封印も、二つの組織も、二本の鍵も、それだけでは全行為の捕捉を証明しない。統制の独立性は鍵の数ではなく、誰が何を変えられるかで決まる。

草案の仮想例では、収集に関する承認済み仮定から肯定的な推論が出る一方、別の証拠が記録から漏れた行為を示す。評価器は双方を保持し、当該主張を衝突付きの not-established として返す。反例を隠すために政策を書き換えることは許されない。仮定を認める権限と、不利な証拠を消す権限は同じではない。

三つの締め切りが守る範囲

pg-ledger/0.2.0 という具体例では、行為を単一プライマリの PostgreSQL 18 に置かれた指定台帳への確定追記と定義する。金銭の移動や外部の作業完了まで意味を広げない。そうした効果を主張するには、台帳の書き込みと外部効果を結ぶ別の仕組みを定義し、検証する必要がある。

追記と封印は同じ期間の行をロックする。確定した三つの境界が、行為の受け入れ、最終受領記録の作成、受取人による受け入れをこの順に閉じる。第一の封印後に記録の確定処理が始まり、第二の封印後に公開と受け入れが始まる。三つがそろった後の完全なスナップショットを使って、元データ、確定記録、受信箱のビューを作る。時刻や連番だけで確定順序を証明したことにはならない。重複試行や矛盾する版は残し、認証済みで内容も同じ再送だけを明示的な規則でまとめる。

この手順は「すべて」の対象を狭くして、その範囲での検査を可能にする。同時に、ホストと PostgreSQL の正しい動作、保存領域の完全性、職務分離、事前の外部発行や迂回の禁止、認証された完全な輸出、安定した鍵と政策を前提とする。特権管理者、復元、履歴の分岐、台帳外の発行は、その土台を崩しうる。封印は閉じた本の内容を守れても、製本前にページを抜く手までは止められない。

WEXP Core の別草案は、特定された行為についての内容上の主張を評価する。Coverage は行為の集合を扱う。Coverage 草案の思考実験では、閉じた百件の行為のうち九十九件に有効な個別評価があり、一件について最終記録の欠落が別途立証される。九十九件の評価はそのまま残るが、全体の作成完全性は成立しない。単に九十九と数えたことだけでは欠落の立証にならず、百件目が対象に属する証拠と、対応記録がないことを示す十分な探索が要る。これは実運用の発生率ではなく、推論規則の検査例だ。