AILEXは、IETF（Internet Engineering Task Force）に提出しているInternet-Draft「Verifiable AI Provenance (VAP) Framework and Legal AI Profile (LAP)」の改訂版 -02 を公開しました。
https://datatracker.ietf.org/doc/draft-ailex-vap-legal-ai-provenance
本稿では、-01 から -02 への改訂で「何が問題だったのか」「どう直したのか」「なぜそれが重要なのか」を、技術的な詳細も含めて解説します。33ページだった仕様書は54ページになりました。ページが増えたのは冗長になったからではなく、「実装者が迷う余地」を潰した結果です。
なお、IETF Internet-Draftは標準化の草案（Work in Progress）であり、IETFによる承認・推奨を意味するものではありません。
そもそもVAP/LAPとは何か
VAP（Verifiable AI Provenance）は、AIシステムが下した判断の「来歴」を暗号技術で検証可能にするフレームワークです。AIが何を入力として受け取り、どんな文脈で、どういう判断を出力し、人間がそれをどう承認・修正したか。この一連の流れを、ハッシュチェーンとデジタル署名で改ざん不能に記録します。
LAP（Legal AI Profile）は、VAPを法務AI領域に特化させたプロファイルです。弁護士によるAI出力の精査（Human Override）、守秘義務を守りながらの第三者監査、裁判所への証拠開示と個人情報保護の両立など、法律業界固有の要件を仕様に落とし込んでいます。
核心にある思想は「Verify, Don’t Trust.（信頼するな、検証せよ）」です。AIプロバイダーの「安全です」という主張を信じるのではなく、暗号学的に証明できる仕組みを作る。それがVAPの設計哲学です。
なぜ -02 が必要だったのか
-01は仕様として「何を実現したいか」は明確でしたが、「どう実装するか」にまだ曖昧さが残っていました。法務関係者とIETF・セキュリティ分野の技術者に-01をレビューしてもらったところ、「実装者によって解釈が割れうる」箇所が複数見つかりました。
IETFの仕様は、世界中の異なるチームが独立して実装しても相互運用できることが前提です。同じ仕様書を読んで、あるチームはハッシュ値Aを算出し、別のチームはハッシュ値Bを算出するようでは、仕様として機能しません。-02 の改訂は、この「解釈の余地」を徹底的に排除することに注力しました。
改訂の全体像：39項目の修正
-02 では、レビューフィードバックに基づき39項目の修正を実施しました。最優先（P0）として暗号基盤の根本問題11件、高優先（P1）として検証インフラとセキュリティの改善13件、中優先（P2）としてプライバシー・規制対応・実装支援の改善15件です。以下、特に重要な改善を詳しく解説します。
暗号基盤の根本修正
EventHashの循環参照を解消した
-01 では、イベントのハッシュ値計算について「Signature フィールドを除外してハッシュする」としか書かれていませんでした。しかし実際には、security.event_hash フィールド自体も除外しなければ循環参照になります。自分自身のハッシュ値を含んだ状態でハッシュを計算することは、論理的に不可能だからです。
-02 では、Hash Input の定義を厳密にしました。イベントから security.event_hash と security.signature の2フィールドを除外し、残りのフィールド（security.hash_algo、security.sign_algo、security.signer_id を含む）を RFC 8785（JSON Canonicalization Scheme）で正規化した上でハッシュを計算します。除外すべきフィールドが列挙されているので、実装者が「この情報は残すのか、消すのか」で迷うことがなくなりました。
計算式も以下のように明確化しています。
HashInput[n] = Event[n] から {security.event_hash, security.signature} を除去
EventHash[n] = HashAlgo(JCS-Canonicalize(HashInput[n]))ここで HashAlgo は security.hash_algo フィールドで指定されたアルゴリズムです。-01 では式に「SHA-256」がハードコードされていましたが、-02 ではアルゴリズムをパラメータ化し、暗号アジリティ（後述）との矛盾も解消しました。
アルゴリズム識別子の表記を統一した
これは一見些細に見えて、実装上は深刻な問題でした。-01 では、同じアルゴリズムが文脈によって異なる名前で呼ばれていました。hash_algo フィールドには "SHA-256"（大文字・ハイフンあり）、ワイヤフォーマットのプレフィクスには "sha256:"（小文字・ハイフンなし）。さらに署名アルゴリズムも "Ed25519" と "ed25519" が混在していました。
文字列比較で検証するシステムにとって、"SHA-256" と "sha256" は別物です。ある実装が "SHA-256" で記録し、別の実装が "sha256" で検証すると、正当なイベントが検証失敗になります。
-02 では Canonical Algorithm Identifiers（正規化アルゴリズム識別子テーブル）を新設し、すべてのアルゴリズム識別子を小文字ハイフン区切りのASCII文字列に統一しました。例えば SHA-256 は "sha-256" が正規形であり、フィールド値もワイヤプレフィクスも同じ文字列を使います（プレフィクスはコロンを追加するだけ）。
具体的には、SHA-256 → "sha-256"、SHA-384 → "sha-384"、Ed25519 → "ed25519"、ECDSA P-256 → "ecdsa-p256"、ML-DSA-65 → "ml-dsa-65" という対応です。
実装の相互運用を考慮し、検証時はcase-insensitive比較をMUST（必須）、出力時はlowercase出力をMUSTとしています。これにより、既存実装が大文字で出力していても受容しつつ、新規実装は統一形式で出力する移行パスが確保されます。
なお、プロファイル識別子（"LAP", "VCP" など）は意図的に大文字のままとしています。これはIANA（後述）のレジストリで大文字として登録するためであり、アルゴリズム識別子（小文字）との区別は仕様上明文化されています。
暗号アジリティの矛盾を解消した
-01 では、アルゴリズム一覧の表にはSHA-384、SHA-512、ECDSA-P256、ML-DSA-65 などの代替アルゴリズムを列挙しておきながら、実際の計算式では SHA-256 と Ed25519 がハードコードされていました。「代替アルゴリズムを使えるはずなのに、式は固定されている」という矛盾です。
-02 では、すべての計算式をパラメータ化しました。EventHash[n] = HashAlgo(...) の HashAlgo は各イベントの security.hash_algo フィールドで指定されるアルゴリズム、Signature = SignAlgo.Sign(PrivateKey, EventHash_bytes) の SignAlgo は security.sign_algo フィールドで指定されるアルゴリズムです。
さらに、Section 4.4 として Algorithm Migration（アルゴリズム移行）の手順を新設しました。アルゴリズムを変更する際は、6か月間のデュアルサイニング期間（新旧両方のアルゴリズムで署名）を推奨し、非推奨化の通知は12か月前に行うことを推奨しています。
Section 4.4.1 ではポスト量子暗号への対応準備にも踏み込みました。NIST FIPS 204 で標準化された ML-DSA-65（格子暗号ベースの署名アルゴリズム）を将来の必須実装候補として位置づけ、古典暗号とポスト量子暗号のハイブリッド署名（RFC 9794）による段階的移行を明記しています。
ML-DSA-65 をパラメータとして選定した理由も記載しています。ML-DSA-65 はAES-192相当のセキュリティレベルを持ち、署名サイズは3,309バイト。より高いセキュリティレベルのML-DSA-87（AES-256相当）は署名サイズが4,627バイトと大幅に増加するため、監査ログの長期保存コストとセキュリティ強度のバランスを考慮してML-DSA-65を選定しました。
NISTによるRSA/ECCの非推奨タイムライン（2030年非推奨、2035年禁止）も参照しており、法律文書の10年以上の長期保存要件に対して、いつまでに移行すべきかの指針を提供しています。
エンコーディング仕様を厳密化した
-01 では「Base64エンコード」「ISO 8601タイムスタンプ」としか書かれていない箇所が複数ありました。しかし、Base64にはstandard（RFC 4648 Section 4）とURL-safe（RFC 4648 Section 5）の2種類があり、パディングの有無でも4パターンに分かれます。ISO 8601もタイムゾーンの記法が複数あります。
-02 では以下のように固定しました。署名やアンカー証明のバイナリデータは RFC 4648 Section 5（URL-safe alphabet、パディングなし）。タイムスタンプは RFC 3339（ISO 8601のプロファイル）で、タイムゾーンオフセットまたは "Z"（UTC）の付与を必須としています。JSONの構文は RFC 8259 を正式参照として追加し、テキストフィールドのエンコーディングは RFC 3629（UTF-8）を必須としました。
ハッシュ値の表現も、小文字16進数でアルゴリズム識別子をプレフィクスとして付与する形式に統一しました。例えば "sha-256:a1b2c3d4..." のように、アルゴリズムが何であるかが値自体に埋め込まれます。16進文字列の長さもアルゴリズムごとに固定（SHA-256なら64文字、SHA-384なら96文字、SHA-512なら128文字）であり、不正な長さの値は検証段階で弾けます。
検証インフラの実質化
Merkleツリーの構成をRFC 9162に統一した
-01 では、Merkleツリー（複数のイベントハッシュを1つのルートハッシュに集約する木構造）の構成について、廃止されたRFC 6962と現行のRFC 9162の両方を参照していました。RFC 6962 はCertificate Transparency v1の仕様で、RFC 9162（Certificate Transparency v2）で改訂されています。
-02 ではRFC 9162に統一し、以下の3点を明示しました。
第一に、domain separation（ドメイン分離）です。葉ノード（個々のイベントハッシュ）のハッシュ計算には 0x00 のプレフィクスを付与し、内部ノード（2つの子ノードを結合する中間ノード）には 0x01 のプレフィクスを付与します。これにより、葉ノードのハッシュ値を偽装して内部ノードとして注入する「第二プリイメージ攻撃」を防ぎます。
第二に、葉ノードの複製禁止です。RFC 6962 では、葉の数が2のべき乗でない場合に最後の葉を複製して帳尻を合わせる実装がありました。RFC 9162 ではこれを禁止し、最大の2のべき乗で左右に分割する再帰的構築を定義しています。これによりツリーの構造が一意に決まります。
第三に、空ツリーの扱いです。入力が0件の場合は空のハッシュ SHA-256() を返し、1件の場合は SHA-256(0x00 || d(0)) を返すことを明記しました。
これらの3点を仕様に書き込んだことで、異なる実装が同じイベント集合から必ず同じMerkleルートを計算でき、包含証明（ある特定のイベントがツリーに含まれていることの暗号学的証明）の生成・検証も一致することが保証されます。
アンカー証明を「型付き」に再設計した
-01 では、外部アンカリング（ハッシュチェーンの特定時点のMerkleルートを外部サービスに記録し、タイムスタンプの独立した証拠を得る仕組み）のアンカー証明（anchor_proof）が単一の文字列型でした。「Base64エンコードされた証明データ」とだけ書かれており、何が入っているのか、どう検証するのかが不明確でした。
-02 では、anchor_type ごとにフィールド構造を分けました。
RFC 3161タイムスタンプの場合、anchor_proofには tst_token（Base64urlエンコードされたTimeStampToken）、hash_algo（TSAリクエストで使用したハッシュアルゴリズム）、tsa_cert_hash（TSA証明書のSHA-256ハッシュ）を含みます。RFC 5816（ESSCertIDv2）のサポートも必須化し、TSA証明書の識別にSHA-1ではなくSHA-256を使用することを要求しています。
透明性ログ（IETF SCITTなど）の場合は、inclusion_proof（Merkle audit pathのBase64url配列）、tree_size、leaf_index、log_id を含みます。検証手順はRFC 9162 Section 2.1.3のMerkle audit pathアルゴリズムに従います。
ブロックチェーンの場合は tx_id、block_height、chain（bitcoin/ethereum）、confirmations を含みますが、これは参考仕様（non-normative）としています。
このように構造を型で分けたことで、検証ツールは anchor_type フィールドを読むだけで、どのフィールドをどの手順で検証すべきかが機械的に決定できます。
第三者検証APIの最低要件を定義した
-01 では Silver レベルの準拠要件として「第三者検証エンドポイントが必須（REQUIRED）」と書かれていましたが、具体的なAPIの定義がありませんでした。何をリクエストして何が返ってくるのかが分からなければ、REQUIREDという言葉は空文化します。
-02 では Section 12.1 として Minimum Verification API を定義し、5つのHTTPエンドポイントを規定しました。
GET /vap/v1/anchors は、指定期間のアンカー記録を返します。GET /vap/v1/chain/verify は、指定期間のチェーン整合性を検証し、結果を返します。GET /vap/v1/completeness は、完全性不変条件（すべてのAI操作が記録されていること）の検証結果を返します。GET /vap/v1/events/{event_id}/proof は、特定のイベントのMerkle包含証明を返します。GET /vap/v1/events/stream は、リアルタイムのイベントストリーム（WebSocket/SSE）を提供しますが、これはGoldレベルでのみ必須です。
認証方式としてBearerトークンまたは相互TLS（mutual TLS）を規定し、エラーレスポンスは標準的なHTTPステータスコードとJSON形式の {error, detail} 構造としています。
セキュリティの大幅強化
12の脅威を具体的に分析した
-01 のSecurity Considerationsは概要レベルの記述にとどまっていましたが、IETFではRFC 3552（セキュリティ考慮事項の記述ガイドライン）に準拠した具体的な脅威分析が求められます。
-02 では Section 20 を全面改訂し、12の具体的な脅威と対策を文書化しました。
ハッシュチェーン改ざんに対しては、Merkle consistency proofによるログのフォーキング（分岐）検出が対策となります。外部アンカリングと組み合わせることで、ある時点以降のチェーン書き換えが検出可能になります。
タイムスタンプ操作に対しては、外部アンカリングが独立した時間参照を提供します。ローカルのタイムスタンプと外部アンカーのタイムスタンプの差が300秒を超える場合は異常として検知する閾値も推奨しています。
内部脅威（管理者や運用者による不正）に対しては、管理イベントへの多者署名（multi-party signatures）と職務分離（署名者とアンカー提出者を分離する）で対策します。
鍵の漏洩に対しては、レベルごとの鍵ローテーションスケジュール（Bronzeは年1回、Silverは半年に1回、Goldは四半期に1回でHSM必須）を規定しました。漏洩時の対応手順として、即時失効、新鍵生成、KEY_ROTATIONイベントの記録、新鍵でのre-anchoring、依存者への通知という5ステップも定義しています。
プライバシー漏洩に対しては、テナントごとのソルトの分離を必須とし、メタデータ漏洩（「いつ」「何回」AIを使用したかという情報）が暗号化されたフィールドからも推測可能であることを固有の限界として認めています。
可用性攻撃（DoS）に対しては、Goldレベルで地理的冗長性を必須とし、障害時のローカルバッファリングを規定しています。
プロベナンス否認（「その記録は知らない」という主張）に対しては、外部アンカリングが否認防止の証拠を提供します。
選択的開示攻撃（都合の悪いイベントだけ隠す）に対しては、完全性不変条件（後述）が欠落を検出します。
リプレイ攻撃に対しては、chain_id がチェーンを特定し、prev_hash が順序依存性を作り、UUIDv7がグローバル一意性を保証するという三重の防御があります。
迅速承認ゲーミング（形式的に承認ボタンを押すだけの「ゴム印承認」）に対しては、承認レイテンシの統計分析で異常パターンを検知する手法を記述しています。
ソルト管理を厳密化した
プライバシー保護フィールド（弁護士登録番号、事件番号、当事者名など）のハッシュ化に使用するソルトについて、-02 では Section 10.1 として独立した管理要件を定義しました。
最も重要な変更は、低エントロピーフィールドへのHMAC-SHA-256の必須化です。弁護士登録番号は5桁程度、事件番号も定型的なフォーマットで、可能な値の総数が限られています。このような低エントロピーの値に対して単純な SHA-256(salt || value) を使用すると、ソルトが漏洩した場合に辞書攻撃（可能な値をすべて試す攻撃）で元の値が復元されるリスクがあります。
HMAC-SHA-256はソルトを鍵として使用するため、たとえソルトが漏洩しても計算コストが高く、辞書攻撃への耐性が格段に向上します。具体的には BarNumberHash = "sha-256:" || hex(HMAC-SHA-256(tenant_salt, bar_number)) という形式です。
ソルト自体の要件として、最小256ビット（32バイト）の暗号学的に安全な乱数生成、テナント間での共有禁止、署名鍵と同等のアクセス制御、年1回のローテーション推奨を規定しました。ソルト漏洩時の対応手順として、即時の新ソルト生成、SALT_ROTATIONイベントの記録、暴露期間の評価、違反通知の4ステップも定義しています。
GDPRとの関係を整理した
-01 では、GDPR（EU一般データ保護規則）との相互作用が未記載でした。「監査ログに個人データのハッシュが含まれている場合、GDPR第17条の削除権（いわゆる忘れられる権利）にどう対応するのか」という問いに答えられない状態でした。
-02 では Section 11.1 として Privacy Regulation Interaction を新設し、以下を明記しました。
まず、監査エントリはハッシュベースの参照を使用し、直接的な個人データを保存しない設計であることを確認しています。次に、監査証跡の処理は独立した処理目的として独立した法的根拠（GDPR第6条(1)(c)の法的義務、または第6条(1)(f)の正当な利益）を持つことを示しています。
GDPR第17条(3)の例外規定（法的請求の行使・防御、法的義務の履行）が監査証跡に適用される可能性があることにも言及しました。ただし、「これらの例外の適用可能性は法域固有の法的判断である」という注記を付しており、技術仕様が法的解釈を断定しないよう配慮しています。
実装面では、暗号学的消去（crypto-shredding）の手法を記述しました。ユーザーごとに暗号鍵を発行し、削除要求時に鍵を破壊することで、ハッシュチェーン自体は維持しながらデータを実質的に復元不能にする方法です。
完全性保証の精緻化
完全性不変条件にグレースピリオドを導入した
完全性不変条件（Completeness Invariant）は、VAPの最も重要な概念の一つです。「すべてのAI操作は、開始（ATTEMPT）と終了（成功/拒否/エラー）の両方が必ず記録される」という不変条件であり、都合の悪い結果だけを削除する「選択的ログ」を構造的に不可能にします。
しかし -01 には、ATTEMPT が記録されてから対応する結果イベントが記録されるまでの許容時間が定義されていませんでした。AI処理中にシステムがクラッシュした場合、ATTEMPTだけが永久に宙に浮いた状態になり、不変条件が永久に違反し続けることになります。
-02 では、グレースピリオド（猶予期間）として最大300秒、推奨デフォルト60秒を導入しました。グレースピリオドを超過した場合は、TIMEOUT_ERRORという合成的な結果イベントを自動生成し、不変条件を回復させるメカニズムを規定しています。
Override Coverageの計算式を修正した
Override Coverage（弁護士精査率）は、AIが出力した結果のうち弁護士が精査した割合を示す指標です。-01 の計算式には2つの問題がありました。
第一に、同一のAI出力に対して複数回のHUMAN_OVERRIDEイベントが記録された場合（例：承認した後に取り消して再承認した場合）、分子が分母を超え、カバレッジが100%を超えるという数学的な不整合がありました。-02 では分子を「少なくとも1つのHUMAN_OVERRIDEを持つdistinct target_event_idの数」に変更し、この問題を解消しました。
第二に、DENYイベント（AIが入力を拒否した場合）が分母に含まれていましたが、AIが拒否した場合にはAI出力が存在しないため、弁護士が精査する対象がありません。-02 ではDENYを分母から除外し、その根拠を文書化しました。法域によってDENY事例の精査が必要な場合は、別指標として「Denial Review Coverage」を追跡することを推奨しています。
因果リンクを標準化した
-01 では、あるイベントが別のイベントに対する「応答」であることを示す方法が統一されていませんでした。-02 では header.causal_link フィールドを Common Event Structure に追加し、すべてのプロファイルで利用可能な因果関係の表現を標準化しました。
causal_link には target_event_id（参照先イベントのUUIDv7）と link_type（関係の種類）が含まれます。link_type には OUTCOME_OF（AI操作の結果）、OVERRIDE_OF（弁護士による精査対象）、HOLD_ON（法的保全の対象）、RECOVERY_OF（データ復旧の対象）、TIER_CHANGE_OF（保持レベル変更の対象）が定義されています。
これにより、Override Coverageの計算も「OUTCOME_OFリンクを持つイベントのうち、OVERRIDE_OFリンクで参照されたものの割合」として、構造的に定義できるようになりました。
IETF標準化への対応
IANAレジストリを正式定義した
IETFの仕様が他の仕様やシステムと相互運用するためには、IANA（Internet Assigned Numbers Authority）への登録が重要です。-01 のIANA Considerationsは最小限でしたが、-02 では RFC 8126（IANA Considerations のベストプラクティス）に準拠した正式な登録テンプレートを作成しました。
メディアタイプとして2種を登録します。application/vap-evidence-pack+zip はEvidence Pack（監査証拠パッケージ）のZIPアーカイブ、application/vap-manifest+json はEvidence Pack内のマニフェストファイル（UTF-8 JSON）です。RFC 6838 Section 5.6 に準拠した登録テンプレートを完備しています。
VAP Domain Profile Identifiers レジストリでは、プロファイルIDの登録ポリシーを「Specification Required」（仕様書の添付が必要）と定め、初期登録としてVCP（Finance）、CAP（Content）、LAP（Legal）の3プロファイルと、DVP、MAP、PAPの3つの予約済みIDを登録します。
VAP Event Types レジストリでは、LAPで定義された全イベントタイプ（LEGAL_QUERY_ATTEMPT、LEGAL_QUERY_RESULT、DOC_GEN_ATTEMPT など）の初期登録を行います。
これらのレジストリが設立されることで、将来的に第三者が新しいドメインプロファイル（例：医療AI向け、教育AI向け）やイベントタイプを追加する際の枠組みが整います。
関連仕様との関係を明確化した
-02 では Section 22 として Relationship to Other Work を新設し、IETFおよびISO/IECの関連仕様とVAP/LAPの関係を整理しました。
IETF SCITT（Supply Chain Integrity, Transparency and Trust）との関係では、VAP Evidence PacksをSCITT Signed Statementsとして登録可能な設計であることを示しました。SCITTが透明性インフラを提供し、VAPがペイロード（ドメイン固有のプロベナンス）を定義するという役割分担です。
IETF RATS/EAT（Remote Attestation Procedures / Entity Attestation Token、RFC 9711）との関係では、EATが「AIシステムが何であるか」をアテストし、VAPが「AIシステムが何をしたか」を記録するという相補的な関係を示しました。
IETF AIPREF（AI Preferences）との関係では、AIPREFが入力側のユーザー選好を表現し、VAPが出力側の説明責任を記録するという対比を示しました。VAPのプロベナンスチェーンにより、AIPREFで表現されたユーザー選好がAIシステムによって実際に遵守されたことを証明できます。
ISO/IEC 42001（AI管理システム）、42005（AIガバナンス）、24970（AIの出所管理）との関係では、VAPの準拠レベル（Bronze/Silver/Gold）がこれらの規格のアーキテクチャ非依存な要件にマッピング可能であることを示しました。
エスクローと法的保全
エスクロー管理者の要件を定義した
コンテンツ保持のTier 2（裁判所命令による開示に備えた暗号化保管）に必要なエスクロー管理者について、-01 では「designated custodian」という抽象的な記述にとどまっていました。-02 では Section 11.3 でエスクロー管理者の具体的な要件を定義しています。
VAP運用者からの組織的独立性を必須とし、鍵エスクロー操作（預入、取出、破棄）のすべてに監査ログイベントの生成を要求しています。エスクロー鍵は管理者自身のKMS（鍵管理システム）で暗号化して保管し、鍵の粒度は案件単位またはテナント単位を推奨しています（漏洩時の影響範囲を限定するため）。
復旧実行にはデュアル認可（要求者とエスクロー管理者の2者）を必須とし、CONTENT_RECOVERY_EXECUTED イベントには hold_id、recovered_event_range、recovered_by、custodian_id、court_order_reference_hash を記録します。裁判所命令の参照がハッシュ値として記録されることで、命令の存在を証明しつつ命令内容のプライバシーを保護する設計です。
実装支援
Bronze最低検証要件を定義した
-01 では「Bronzeレベルの準拠」が何を意味するのか、具体的な検証項目が定義されていませんでした。-02 では Appendix B として Bronze Level Minimum Validation Requirements を新設し、最低限の検証項目を列挙しています。
すべてのREQUIREDトップレベルフィールド（vap_version、profile、header、provenance、accountability、security）の存在確認、header.event_idの有効なUUIDv7検証、header.timestampのRFC 3339準拠確認、header.prev_hashのnull（ジェネシスイベント）または {algo_id}:{hex_string} パターン検証、security.event_hashの再計算一致検証、security.signatureの署名検証、header.causal_link.target_event_idのnullまたは有効なUUIDv7検証です。
正式なJSON Schema（RFC 8610のCDDL形式）は文書サイズの制約から別文書として予告しています。
実装状況を報告した
RFC 7942（Implementation Status）に準拠し、Appendix C として AILEX SaaS Platformの実装状況を記載しました。
実装のMaturity（成熟度）は「Bronze-level conformance with select Silver-level features implemented on an experimental basis」と明確にしています。Bronze要件（ハッシュチェーン整合性、デジタル署名、イベントログ、UUIDv7識別子）は本番実装済み、Silver要件の一部（三パイプライン完全性不変条件、プライバシー保護フィールド、テナント別ソルト、Override Coverageトラッキング）は試験的に実装済みです。External anchoring と Evidence Pack 生成（Silver 必須要件）は未実装であることも明記しました。
-03 以降の検討事項
-02 で対応しなかった項目のうち、将来的に検討すべきものとして以下を特定しています。
CDDL（Concise Data Definition Language、RFC 8610）による正式スキーマは、文書が既に54ページに達しているため、別文書化が望ましいと判断しました。テストベクター（具体的な暗号データを使った検証用テストケース）は、実装と並行して作成するのが効率的です。VAP（上位フレームワーク）とLAP（法務プロファイル）の文書分離は、-03 で判断します。COSE（CBOR Object Signing and Encryption）エンベロープへの移行は、JSON からCBOR への大規模変更となるため、別フェーズとして計画しています。
IETFのどのワーキンググループ（SCITT、RATS、SECDISPATCH など）をターゲットにするかは、技術的な内容とは別の戦略的判断として検討を続けます。
おわりに
-02 の改訂は、「何をしたいか」を書く段階から「どうやるかを誰が読んでも同じ意味に取れるように書く」段階への移行です。ハッシュの循環参照、アルゴリズム識別子のゆれ、検証手順の未定義といった「実装を書いてみて初めて気づく曖昧さ」は、レビューを経なければ発見できませんでした。
VAPの設計哲学「Verify, Don’t Trust」は、仕様書自体にも適用されるべきものです。仕様を読んだ人が「たぶんこういう意味だろう」と推測する余地がなくなるまで、曖昧さを潰し続ける。それが -02 で目指したことであり、-03 以降も継続する作業です。
AIが法律業界に浸透するほど、「そのAIの判断は本当に正しかったのか」「弁護士はちゃんと確認したのか」を事後的に検証する仕組みの重要性は増していきます。VAPとLAPは、その検証を「信頼」ではなく「暗号」に基づいて行うための基盤です。
本Internet-Draftに基づく技術仕様はAI判断の監査・検証を目的とするものであり、弁護士法第72条に定める法律事務の取扱いを行うものではありません。最終的な法的判断および責任は弁護士に帰属します。
IETF Internet-Draftは標準化の草案（Work in Progress）であり、IETFによる承認・推奨を意味するものではありません。
AILEX合同会社
〒150-0043 東京都渋谷区道玄坂1-10-8 渋谷道玄坂東急ビル
代表社員：山川 慎太郎
顧問弁護士事務所：弁護士法人えそら
TEL：03-6821-7462
E-mail：info@ailex.co.jp
サービスURL：https://users.ailex.co.jp
公式サイト：https://ailex.co.jp
IETF Internet-Draft：https://datatracker.ietf.org/doc/draft-ailex-vap-legal-ai-provenance/
公式LINE：https://lin.ee/P9JAWZp
