要約

  • draft-mih-agent-settlement-records-00 は、支払者と受取者がそれぞれ自分側の観測だけを封印し、検証者が二つの支払い脚の一致を導出する方式を提案する。片方の記録が結合結果を宣言することはできない。
  • 支払いの一致と配送は独立している。支払いが agreed でも配送が none である状態を仕様は明記しており、署名も一致も商品、コンテンツ、サービスの到着を証明しない。

自律エージェントの商取引で最も危うい表示は、赤い警告ではなく、意味を詰め込みすぎた緑色の「完了」かもしれない。会計は入金を確認し、発注システムは案件を閉じ、紛争処理は成功済みとみなす。しかし、各システムが確かめた事実は同じではない。2026年10月2日に提出された Two-Party Settlement Records for Agent Payments の第00版は、この違いを記録形式そのものに残そうとしている。

出発点は単純だ。支払者のウォレットや銀行は価値が出ていくのを見る。受取者のシステムは価値が入ってくるのを見る。既存のプロトコルは片側だけを保存することが多く、引き換えに何が渡されたかについてはさらに弱い。そこで草案は、terms、payer-observed、payee-observed、delivered という最大四種類の脚を用意する。

各当事者が封印できるのは、自分のシステムで観測した内容だけである。支払者が受取者の証拠を入手しても、それを支払者観測として作り直してはならない。逆方向も同じだ。他方の脚を参照することは、その記録を保持し関連付けた事実を示すだけで、主張の発生主体を移し替えない。

結合状態を決める権限は検証者に残る。どの settlement member も agreed や mismatch を自称しない。検証者は Agent Action Capsule、producer envelope、構造、wrapped object、role、ローカルな鍵ポリシーを検査する。その上で terms reference と型付き payment reference を使って受理可能な脚を束ね、そのバイト列から結果を導出する。証拠の提出者が、そのまま判定者にもなる設計ではない。

片側しかなければ、それは陳述にとどまる。payer_stated は支払側システムが出金を報告したこと、payee_stated は受取側システムが入金を報告したことしか意味しない。相手側が欠けていること自体は不一致の証拠ではない。まだ作られていない、開示されていない、あるいは今後も作られない可能性がある。関連する evidence-request 案も、回答、署名付き拒否、記録された不在を別々の結果として扱う。

agreed には狭い条件がある。二つの観測が結合可能で、異なる受理済み鍵を使い、正規化された支払い参照が同じで、金額規則を満たし、同じ status を報告しなければならない。金額比較は近似ではない。同一資産と共通の小数スケールで、支払者金額は受取者の受領額と receive fee の合計に正確に等しくなる必要がある。許容差はない。受領額だけと比較すれば、正当に開示された手数料を誤って不一致にしてしまう。

それでも一致が語るのは、二つの支払い系が資金移動を同じように記録したという範囲までだ。観測金額が terms と同じかどうかは別に報告される。両者が互いに一致しながら、双方とも当初条件から外れることもある。手数料が商取引上許容されるかは条件の問題であり、暗号学的な一致から自動的に生まれる答えではない。

配送は独自の状態機械を持つ。delivered leg がなければ none、矛盾のない片側だけなら stated、送信側と受信側の content digest が同じなら matched、異なれば mismatch である。独立性は逆方向にも働く。支払いが agreed でも配送は none にでき、配送が matched でも支払いは payee_stated のままでよい。

digest は争点を狭めるが、紛争を終わらせはしない。同じ digest は二つの記録が同じバイトを指すことを示せる。しかし、物理商品の品質、サービスの期限、ソフトウェアの性能、受領者の検収権限、契約上の救済期間まで証明するには、別の方針と証拠が要る。「同じバイト」を「義務の履行」に変えるのは、記録形式ではなく制度判断である。

status の語もローカルな観測だ。settled は封印者の側で最終になったこと、つまり支払側なら引落済み、受取側なら入金または受領済みを表す。モデルには reversed もあり、新しい観測は古い観測を supersede する。従って settled を、どの決済レールでも取消不能という普遍的保証として扱うことはできない。

署名は署名者を任命しない。草案は trust policy を明示的に適用範囲外とする。検証者は、どの鍵が主張された支払者や受取者を代表できるかを別途決めなければならない。異なる二鍵という条件は一鍵による両側偽造を防ぐが、二鍵が存在するだけで、権限を持つ二当事者が存在するとは証明できない。

既存の signed receipt を包むときにも境界がある。元のオブジェクトは digest で参照され、再署名されるべきではない。wrapper が証明するのは、封印者が特定バイトを含めたことまでで、元の発行者になったことではない。SCITT receipt も、ある脚が指定ログに登録された事実を示せるが、内容の真実性や双方向合意を作り出さない。

ここで読んでいるのは提案の意味論であって、普及の事実ではない。Datatracker 上では個人 Internet-Draft であり、stream も standards level もない。x402、AP2、Payment HTTP、Open Payments、Lightning、ISO 20022 との対応は著者による crosswalk で、それぞれのコミュニティが形式を採用した証拠ではない。ISO の公開ページは今回の取得でアクセス拒否となったため、保存した草案記述以上の支持は主張しない。

Lu Heng の Minimum Initial Specification は、この種の共通記録に合う統治姿勢を示す。独立観測が出会うための最小形を共有し、結果を伴う判断はローカルに保つ。Running-Code Primacy は、実際に動いた rail object、鍵方針、正規化規則、supersession head を問う。Reality Layers は、署名済み観測、二者の支払い一致、配送証拠、契約履行を一つの completed badge に潰すことを拒む。

必要なのは、派手な完了表示ではなく再現可能な decision receipt だ。受理・拒否された脚、鍵と当事者を結ぶ方針、導出した payment state、terms との比較、delivery state、wrapped object の検査、rail status、supersession、そしてローカルな業務判断を残す。そうして初めて、後日の紛争で「どこまでが合意した事実で、どこからが組織の判断か」を説明できる。

出典