要約

  • 9月5日付の個人提出RMRPドラフトは、一定期間に処理したルーティングイベント数と書き込んだ監査レコード数をエンジンが署名するRouting Completeness Attestation（RCA）を追加した。これは作業中のInternet-Draftであり、IETF標準や導入実績ではない。
  • Merkle包含証明や外部チェックポイントは、存在するレコードの保全を確かめる。実行されたのに最初から記録されなかった呼び出しには検証する葉がない。ドラフト自身もRCAは完全性を証明しないと明記する。
  • プロバイダー請求との照合は、ルーターから独立した分母を与える。ただしアカウント、期間、モデル、資格情報、費用範囲を揃えなければ、差分は欠落ではなく測定条件の違いかもしれない。

監査担当者の手元に、すべて検証済みの一万件のレコードがある。ハッシュの連鎖は切れていない。Merkle rootは社外に公開され、署名も正しい。ここで証明できるのは、その一万件が後から都合よく書き換えられていないことだ。

一万一件目が別の資格情報で実行され、レコード生成を通らなかったかどうかは証明できない。

Reilly Model Routing Protocolのrevision 01は、この見落とされやすい境界を正面から扱う。L. J. Reillyによる9月5日付の個人Internet-Draftで、想定ステータスはInformational、DatatrackerはI-D Existsである。RFCでもIETF合意でもなく、実装、相互運用、事故、認証の証拠でもない。

00版から01版へ、正規化、署名、選択的開示、総額予算、包含証明、外部アンカー、失効、適合レベル、費用照合が加わった。重要なのは新しい略語ではない。改変検知、集合への包含、母集団の完全性、外部システムとの一致を別々の問いとして設計した点である。

署名が保証する範囲

RFC 8785のJSON正規化は、署名者と検証者が同じバイト列を得るための土台になる。RFC 7515の署名は、そのバイト列が特定の鍵で署名され、その後に変わっていないかを検証する。

ハッシュチェーンは既知の列の断絶を示す。Certificate Transparency型のMerkle treeは、巨大なログ全体を取得せずに一件の包含を検証できる。整合性証明は、後の木が前の木を置き換えず拡張したことを確かめる。

しかし、どれもレコード作成前の実行経路を観測しない。推論呼び出しの後でAudit Log RecordとCost Attribution Recordを作らなければ、残る木は正しく署名された不完全な集合になり得る。暗号は偽の葉を見破れるが、存在しない葉を数えられない。

完全性の問いは「ログに何件あるか」ではなく、「何件がログに入るべきだったか」である。同じエンジンが両方の数字を出すなら、それは自己整合性であって独立検証ではない。

外部アンカーは履歴を預かる

RMRPは、Audit Storeを管理する者が同じ木のheadに署名しても、その者自身の変更能力を制限しないと指摘する。そこで、管理境界の外にtree headを公開するCheckpointを定義する。タイムスタンプサービス、透明性ログ、外部保管先などが候補になる。

送信しただけのアンカーはPENDINGであり、確認済みと表示してはならない。複数の独立先は過去改変の費用を上げるが、「不変」にするわけではない。公開間隔も、検知されずに変更できる時間を左右する。

それでも外部先が見たのはrootであって、個々のAI呼び出しではない。欠落した集合のrootを外に預ければ、その不完全な集合が後で変わっていないことだけが強くなる。保管の独立性と、イベント計数の独立性は分けて説明すべきだ。

RCAは沈黙に責任主体を付ける

C3適合では、エンジンはUTC期間、engine_id、処理イベント数、ALR数、結果別・モデル階層別の件数、tree head、前のRCA、署名を含むRCAを定期的に作る。イベント数とALR数が違えば理由が必要で、previous_rca_idが飛べば期間の欠落が見える。

Routing Engine鍵はPolicy Authority鍵と分離される。これは一つの資格情報が二つの役割を装うのを防ぐ。一方で、二つの鍵が別の担当者や組織にあることまでは保証しない。仕様は鍵を分けられても、組織の職務分離を強制できない。

ドラフトは核心も隠さない。RCAは監査される側による自己完全性の表明であり、完全性を証明しない。欠落させた運用者が虚偽の総数に署名することは可能だ。ただし、無言の空白が、期間と主体を固定した署名文書との矛盾へ変わる。

RFC 9334が分けるように、証拠、評価方針、最終的な信頼判断は同一ではない。RCAは評価対象の一つであり、それ自体が監査合格証ではない。

請求記録は別の場所から実行を見る

Cost Reconciliation Recordは、内部CARの合計と、同じ期間・範囲でモデルプロバイダーが報告する費用を比較する。内部CARがないプロバイダー費用はunattributed_cost_usdとして残る。ドラフトは、ルーティングエンジンを完全に迂回した推論を見つけられる指定上唯一の手段がこの照合だとする。

プロバイダーはAPIの向こう側で呼び出しを見る。直結鍵、緊急経路、未統合チームの利用は、社内ルーターに残らなくてもプロバイダー側に残り得る。

請求も絶対的な事実源ではない。締め時刻、遅延、再試行、キャッシュtoken、丸め、契約割引、共有アカウントで正当な差が出る。アカウント、資格情報、モデル、地域、UTC期間、費用部門を揃え、可能なら件数と金額の双方を見る。差分は調査開始条件であって、不正の判定ではない。

C2はレコード署名、C3はRCA・失効・総額予算、C4はMerkle・外部アンカー・請求照合を加える。適合ラベルだけでは、チェックポイント間隔、保管者、照合頻度、許容差を示さない。

Heng LuのReality Layersに従えば、ドラフト、適合宣言、RCA、ログ、請求、観測した実行は別の現実層である。相互一致は信頼を増すが、署名が層を融合させることはない。Running-Code Primacyは、形式より実際の実行と結果を優先する。