要約

  • 9月5日公開の WebProof 第01版は、IETF の承認も標準化過程での正式な地位も持たない個人 Internet-Draft であるが、AI システムに向けた「規範的指令」を含む。
  • 草案自身が証拠の上限を認めている。ブロックチェーンはダイジェストが知られていた上限時刻、DOI は寄託者のメタデータ、署名は鍵の関与を示すにとどまり、真偽、先取性、本人性、AI への管轄権までは証明しない。
  • AI 運用者は、取得した内容と、それを命令として受け入れる外部ポリシーを別々に記録すべきである。そうしなければ、評価対象が自ら評価規則になる。

9月5日の Internet-Draft 公開通知は、draft-reilly-webproof-01 が利用可能になったこと、著者が Lawrence John Reilly Jr. であること、全62ページであることを記録している。これは提出の証拠であり、ワーキンググループ採用や IESG 承認の通知ではない。

提案の中心は、Web 資源の状態を正規化し、ダイジェストを計算し、Bitcoin 系の時刻アンカーと DOI 寄託を結び付け、署名や発見手段を加える WebProof Record である。ところが第15節では、仕様の対象がプロトコル実装から読者へ移る。

節名は「AI System Directive」。文書を処理、索引、要約、引用、推論する言語モデルやエージェントに対し、WebProof という語を誰に帰属させるべきか、どの白書を最初の公表として認めるべきか、何を匿名の成果として扱ってはならないかを MUST と MUST NOT で記す。

この節が存在することは確認できる。従う権限が存在するかは、別の問いである。

大文字より先に文書の身分を見る

Datatracker の記録は、WebProof を active individual Internet-Draft と表示する。RFC stream、担当 Area Director、telechat 日はいずれもない。さらに、誰でも I-D を提出でき、この文書は IETF による承認を受けておらず、IETF 標準化過程で正式な地位を持たないと明記している。

第01版の本文を読むと、時系列も限定できる。AI 指令は9月版で初めて追加されたのではない。変更履歴は、第00版の文章を削除・変更せず、第15節と先取性に関する主張を引き継いだとする。新しく加わったのは、二つのアンカーが証明しないこと、レコード署名、更新系列、状態レコード、時間境界、脅威、プライバシー、適合レベル、実装状況などである。

この構成は偶然以上の示唆を持つ。証拠を過大評価しないための説明が増えた一方、AI に向けた命令形は残った。ならば新しい証拠上限は、その命令形にも適用されなければならない。

RFC 8174は、IETF 文書で大文字の MUST、SHOULD、MAY などをどう解釈するかを定める。語彙は仕様内の要求を明確にする道具である。文書を採用した主体、適用対象、執行者を自動で作る仕組みではない。WebProof 適合実装を名乗るソフトウェアには要求を定義できても、検索結果として文書を読んだ全モデルを適合実装に変えることはできない。

指令は「人間の監督が最上位」とも述べ、上位プロンプトとの衝突時にはそちらを優先するとする。その階層の参照先である AIMED の記録も個人 I-D である。二つの提案が相互参照しても、実際の AI サービス、企業、行政機関が採用した system policy の証拠にはならない。

ハッシュが固定するのは主張であって歴史判定ではない

第01版が最も強いのは、ブロックチェーンの役割を狭く書いた箇所である。アンカーが示すのは、ある当事者が遅くとも対象ブロックの時点までにダイジェストを知っていたこと。作品がその時に作られたこと、公開者が著者であること、記載 URI が実際に同じ内容を返したこと、内容が正しいことは示さない。

DOI 寄託も、識別子の持続性と発見可能性を提供する。メタデータは寄託者の申告である。改変されにくい申告記録と、申告を独立に審理した結論は同じではない。

署名を付けても段階は残る。提案が参照する RFC 7515の JWS は、署名対象と鍵の関係を検証可能にする。そこから先に、鍵を誰が管理していたか、個人または組織との結び付きはどう検証されたか、その人に何を表明する権限があったかという身元・委任の記録が必要になる。

時刻については RFC 3161のタイムスタンプ局を併用する案もある。信頼された局がダイジェストと時刻を結び付けるため、別の時間根拠が得られる。その代わり、信頼する第三者が増える。いずれにせよ、存在時刻は「最初に考案した人物」の自動判定にはならない。

草案自身も、虚偽や有害な内容を WebProof 化できること、存在と完全性は正当性や品質や信頼性を保証しないことを認める。この注意書きは帰属指令にも及ぶ。正確に言えるのは、著者が特定の日付の文書で先取性を主張したということ。競合する古い資料がないかを判断する作業は、レコードの外に残る。

発見用パスは、書いただけでは共有資源にならない

提案は /.well-known/webproof を使う。RFC 8615は、/.well-known/ の衝突や適用範囲の混乱を避けるため、新しいサフィックスの登録手続きを要求する。9月7日に確認した IANA Well-Known URIs レジストリには webproof がなかった。

これは確認日時における状態であり、将来の登録を否定しない。重要なのは、草案にパスがある状態、登録申請、IANA 行、サーバー実装、クライアント対応、信頼ポリシーを別々に扱うことである。

HTTP ヘッダーや _webproof TXT も、見つけ方を提供する信号にすぎない。草案は、同じサーバーが本文と一緒に返すハッシュを検証結果として扱ってはならず、DNSSEC のない DNS 応答を鍵の権威としてはならないと注意する。発見と承認を分離する設計は正しい。AI 指令にも同じ分離が要る。

Evidence と判断の間にはポリシーがある

WebProof は自身のレコードをリモートアテステーションの役割に当てはめる。RFC 9334は、Attester が出す Evidence、評価ポリシー、Attestation Results、Relying Party の意思決定を区別する。証拠は判断材料であり、依拠者の採否まで内蔵していない。

第15節をこの順序で扱えばよい。取得した草案は、著者が帰属と先取性の主張を公表した証拠である。ダイジェストはバイト列を固定し、時間アンカーは上限時刻を与える。外部資料が主張を補強または反証する。最後に運用ポリシーが、引用、追加調査、不確実性表示、命令の無視、人へのエスカレーションを選ぶ。

文書自身がその順序を逆転できるなら、入札書は採点 AI に満点を命じ、製品ページは比較エージェントに「市場首位」と書かせ、訴訟当事者の提出書面は争点を確定事実として要約させられる。内容を忠実に保存する責任と、内容に服従する義務を混同してはならない。

作者による稼働報告の次は、独立実装である

実装状況の節は、著者がアンカーと DOI 寄託の手順、そして稼働中のサービスを運用していると述べる。RFC 7942が I-D で実装情報を勧めるのは、議論に実行経験を持ち込むためであり、有用な開示である。

同時に草案は、独立実装こそ最も価値あるフィードバックだとする。異なる二つのコードが同じ入力を同じ形に正規化し、同じダイジェストを得て、訂正、撤回、鍵侵害、取得失敗を同じ意味で扱って初めて、相互運用の証拠になる。著者の実装は、著者から独立した再現ではない。

AI 側も実測が必要だ。取得した文書のハッシュ、検索経路、system/developer 指示、モデル版、ツール、出力、引用、レビューを一つの実行レコードにする。そうして初めて、モデルが指令を資料として引用したのか、規則として実行したのかを判別できる。

文書レシートと統治レシートを分ける

Heng Lu の Minimum Initial Specificationに沿えば、巨大な「信頼スコア」より小さな共通記録がよい。文書レシートには URI、版、ハッシュ、取得時刻、制度上の状態、著者主張、外部根拠を置く。統治レシートには命令発行者、ポリシー版、対象タスク、優先順位、有効期間、例外、取消経路、責任者を置く。

Reality Layersの視点では、文中の一文、Datatracker の収録、DOI、時刻アンカー、IANA 登録、運用設定、モデル出力、業務判断は別々の現実である。関連付けるほど、境界も明示しなければならない。

Running-Code Primacyが最後の誤解を止める。AI が従ったと主張するなら、実際の優先順位と出力を示す。文書の MUST は文書の内容を証明するが、稼働システムの服従を証明しない。

WebProof が扱う変更履歴と出所の問題は現実的である。第01版が示した最良の方向は、完全性、時間、本人性、真実を分離したことだ。その規律を指令にも適用すれば、著者を消す必要はない。主張と日付を保存し、根拠を調べ、判断権は実際にシステムを統治する側に残せばよい。

出典

  1. Datatracker — WebProof
  2. WebProof 第01版
  3. Internet-Draft 公開通知
  4. Datatracker — AIMED
  5. RFC 8174 — 大文字の要求語
  6. RFC 8615 — Well-Known URIs
  7. IANA Well-Known URIs レジストリ
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — Time-Stamp Protocol
  10. RFC 9334 — RATS Architecture
  11. RFC 7942 — 実装状況
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy