要約

  • 個人提出のInformational Internet-DraftであるAER-1改訂04は、各ステップのreceipt_idから葉を作るよう要求する。現在の公開ページはseq:receipt_hashを葉にしている。
  • 5件の公開ステップはすべてHTTP 200で応答し、個別検証に成功し、出力ハッシュもマニフェストと一致した。ページの方式は掲載根を再現するが、改訂04の方式では別の根になる。
  • 固定コミットのPython、Rust、TypeScript補助関数は改訂04に沿う。一方、43件の適合性コーパスは-03表記のままで、ワークフロー根を試すベクトルがない。

満点が試していなかったもの

公開リポジトリは、Rust、Go、TypeScript、Python、Java、C#、Swiftの各ランナーが43件中43件、すなわち43/43に合格したと報告している。この数字自体を疑う理由はない。問題は、43件が何を問うたかだ。

付属文書が列挙する対象は、必須フィールド、UUID、日時、厳格なBase64とUTF-8、出力コミットメント、来歴区分、プロデューサー用プロファイル、任意のアンカー、エミッターの往復である。ワークフローは挙がっていない。ベクトル一覧も仕様改訂を-03としており、workflow、Merkle、step sequence、odd nodeといった試験は見当たらない。

つまり、7言語が満点を取ったまま、改訂04で追加された木を一度も作っていないことは十分にあり得る。適合性の点数は、出題範囲を越えて権威を持たない。

この空白は公開ワークフローで現実になった。5件のステップはどれも壊れていない。各検証URLは成功を返し、verified: trueを示し、出力ハッシュはページ上の値と一致した。それでも、木の作り方を変えると根が変わる。

同じ5件から生まれた二つの値

公開ページが掲げる根はa4b2fcb4684cec481e4ece889ed15c7d9e47e58d9ba4fb02ea354c0cb2ca44c4である。ページ内のJavaScriptは、各ステップの検証結果から出力ハッシュを取得し、連番、コロン、小文字のハッシュをつないだseq:receipt_hashをUTF-8でハッシュする。子ノードは32バイトのまま連結し、奇数なら最後を複製する。この手順で掲載値がそのまま再現できた。

順序もSHA-256も親ノードの計算も奇数処理も維持し、葉だけを各receipt_idのUTF-8ハッシュにすると、根は7c4817ca249edfeae259b98abf63ed38a31d9dbeebf5ee23139410a7a7f63b37になる。

後者は、2026年9月29日に投稿された AER-1: A Portable Execution Receipt for AI Agent Tool Calls 改訂04の指定である。これはRFCではなく、IETFワーキンググループ採択文書でもない。その留保は必要だが、公開中の二つの構成が別の値を出すという観測は変わらない。

ここで失敗したのはSHA-256ではない。二つの計算は、それぞれ選んだ入力に対して正しい。共通していないのは「何を葉と呼ぶか」である。

葉の定義は実装詳細ではない

改訂04は、receipt_id文字列のUTF-8バイトをSHA-256にかけ、隣接する生のダイジェストを組み合わせ、奇数の末尾を複製する。代替構成を認めた旧版の余地を削除した理由も明記している。同じワークフローに異なる根ができれば、実装間検証が破綻するからだ。節の冒頭には推奨という語があるが、その直後にMUSTで採用を義務付ける。

公開ページは、順番と出力コミットメントを葉に直接含める。これは理解可能な設計である。改訂04は、安定したレシートIDを単位にし、各レシートの解決と個別検証に意味を持たせる。こちらも理解可能だ。

しかし、理解可能であることと互換であることは違う。根の16進文字列だけを受け取った監査人は、どちらの構成かを復元できない。根は自分の葉を説明しない。

したがって、葉の定義は単なる実装詳細ではない。承認、支払い、証跡保存などに根を使うなら、その根が指す対象そのものを決める契約である。

リポジトリと稼働ページの距離

公開リポジトリをコミットf3aacbb5cf7d00977fd107afc34fc24b08c4f569で固定すると、Pythonの関数はレシートIDを受け取り、RustはIDのバイトを、TypeScriptはIDのUTF-8をハッシュしている。3実装とも改訂04側にいる。

稼働ページのブラウザコードは出力ハッシュを取り出し、seq:hashを葉にする。ページの説明とコードは互いに整合しており、だからこそページの根を再現できる。問題は内部不整合ではなく、外部との互換性である。

Lu HengのRunning-Code Primacyをここで「動いている方が常に正しい」と読むのは浅い。重要なのは、実際に走っている互換集合を可視化することだ。新しい文章が公開されても、過去の公開レシートは自動的に移行しない。逆に、既存ページが動くからといって、移植可能な共通規則を単独で決められるわけでもない。

最小仕様は薄くてよい。ただし、独立検証に不可欠な決定まで省いてはならない。葉のバイト列はその中心にある。後から運営者の説明を聞かなければ検証できないなら、ハッシュは権威依存を消したのではなく、見えにくくしただけだ。

「検証済み」を分解する

この事例では、少なくとも六つの事実を分ける必要がある。

第一は各ステップのバイト整合性。第二は、取得した出力ハッシュとワークフローマニフェストの一致。第三は、名前の付いた構成どおりの葉を選んだこと。第四は、別実装が同じ構成で同じ根を得ること。第五は、外部の証人がその根を時刻と鍵に結び付けたこと。第六は、ツールの外部効果が本当に起きたことだ。

公開ページは第一と第二を強く示し、自分の構成について第三と第四も満たす。ページはpartial状態のNostrアンカーも示す。ただし、アンカーは渡された値を記録する。どちらの葉が正しいかを裁定しない。

来歴も木によって格上げされない。外部エージェントが報告した実行は報告のままであり、ゲートウェイが観測した事実はその観測範囲を越えない。価格取得が売買成立になることもない。

画面に「検証済み」と出すなら、対象を続けて表示すべきだ。バイト、ステップ、構成、根、アンカー、外部効果は別々の状態である。

根に必要な持ち物

組織をまたいで根を使うには、レシートとワークフローのスキーマ版、葉構成ID、符号化、ハッシュ方式、親ノード規則、奇数処理、出力形式、順序付きステップIDとコミットメント、各ステップの来歴、最終出力バイトの定義、アンカーの範囲、試験ベクトル版が必要である。

さらに、受け入れ側の方針版と決定主体を残す。これは書類を増やすためではない。「誰が、どの木を、どの規則で受け入れたか」を後で答えるためだ。

seq:receipt_hashからreceipt_idへ移行するなら、古い根を黙って再計算してはいけない。旧根を保存し、後継の版付きコミットメントを出し、移行中は二つを明示して並べる。採用は文章上の宣言ではなく、実装と利用者の移動として観測されるべきである。

情報源と限界

観測は上海時間2026年9月30日に固定した。改訂04、固定した公開コミット、当時の公開ページの間に再現可能な差があることを示す。悪意、SHA-256の脆弱性、侵害、外部効果の失敗、広範な採用、IETFの支持は示さない。コードの記述は実際に確認したPython、Rust、TypeScriptのワークフロー補助関数に限る。草案とサービスは今後変わり得る。