要約

  • 2026年9月10日から13日までのAFRINIC移転ファイルは、JSONオブジェクトのキー順を再帰的に正規化し、配列を多重集合として比較すると、いずれも同じ128件の移転オブジェクトを含む。日々進むのは生成時刻と収録期間の終点である。
  • 4ファイルの最大 transfer_date はすべて2026年6月18日だ。これだけでは、その後の移転が未掲載または遅延しているとはいえない。ファイルの鮮度とイベントの鮮度が別の主張だと分かるだけである。
  • 簡潔な「スナップショット収録証明」があれば、発行側がどのソースシステム水位まで確認したか、差分がゼロだったか、訂正・遡及収録・撤回があったかを区別できる。

ファイルに書かれた最も新しい日付が、そのファイルの中で扱われる出来事の最終日とは限らない。AFRINICの公開移転アーカイブには、この当たり前だが見落とされやすい違いがはっきり表れている。

2026年の保管ディレクトリには、9月10日、11日、12日、13日に生成された累積JSONスナップショットが並ぶ。各ファイルは生産者をAFRINIC、移転統計の版を4.0、UTCオフセットを2と記録する。production_date は毎日進み、records_interval.end_date もその日の生成時刻へ移る。始点はどれも2018年1月1日で変わらない。

しかし、外側の包みを外すと、中の業務イベント集合は止まっている。各スナップショットは128件で、101件が MERGER_ACQUISITION、27件が RESOURCE_TRANSFER と分類される。JSONオブジェクトのメンバー順を再帰的にそろえ、移転配列を多重集合として照合すれば、4日分は完全に一致する。生ファイルのハッシュは違うが、それはラッパーの時刻と直列化時のキー順が変わるためだ。バイト列の変化を業務イベントの増減と読み替えることはできない。

最大の transfer_date は 2026-06-18T15:48:49Z である。Global Internet CompanyからHormuud Telecom Somalia INCへのAFRINIC域内の合併・買収記録で、双方の国コードは SO。AS37326、IPv4範囲一つ、IPv6範囲一つを含む。ここで当事者名を挙げる理由は、公開イベント時計の終点を特定するためだけだ。この記録から、当該移転の遅れ、紛争、不備を推測する根拠は得られない。

まず採るべき解釈は定常運用

累積台帳は、最終イベント日をファイル日付に近づけるために架空の行を作るべきではない。新しく公表される移転がない期間は普通にあり得る。業務行が変わらなくても日次生成には意味がある。利用者は新しい成果物と現行スキーマのラッパーを受け取り、発行処理が動いているかを観測できる。

JCRスキーマも、この慎重な読み方を支える。production_date はファイルが作られた日時、records_interval はファイル内レコードが対象とする期間と定義される。別に定義された transfer_date は移転日だ。つまり設計自体が、複数の時計を認めている。

不明なのは、動く期間終点の裏で何が行われたかである。その時刻まで全ての認可済み入力が検査されたという保証なのか。単に生成時計を区間終点へ複写したのか。差分ゼロのファイルは、取込水位が進んだものの採用レコードがなかったことを示すのか、それとも昨日の累積集合を書き直しただけなのか。過去レコードの訂正や遅着したレコードは、新たに実行された移転とどう区別されるのか。

どの疑問も、欠落行の存在を証明しない。公表資料から分かる範囲の境界を示しているだけだ。

新しいラッパーと新しいイベントは別物

自動処理は、比較しやすい時刻欄を「鮮度」の代表にしがちである。監視システムが9月13日の区間終点を見て、データセットを最新と判定するのは、成果物としてのスナップショットについてなら妥当だろう。しかし、その評価をイベント母集団にも無言で広げ、最終イベントも9月13日前後だと扱えば誤解になる。

逆方向の断定もできない。最大イベント日が6月18日だからといって、移転が止まった、申請が滞留した、新しい移転方針が機能していない、とはいえない。ファイルは公表済みイベントを記述するだけで、非公開の申請待ち、却下や取下げ、完了待ちの内部承認、公開定義の外にある事案は映さない。AFRINICも、報告書が移転に関する全情報を提供するものではないと説明している。

128という数にも節度が要る。128件の契約、当事者組、商取引を意味するとは限らない。一つのオブジェクトにASN、IPv4集合、IPv6集合を同時に含められるからだ。オブジェクト数の年別内訳は2018年13件、2019年19件、2020年20件、2021年22件、2022年28件、2023年8件、2024年5件、2025年9件、2026年4件である。これはスキーマ上のオブジェクト分布であって、市場規模を示す系列ではない。

AFRINICの移転案内は、実行済み移転について、移転元、元の保有資源、移転先、日付、種類を公開するとしている。累積ログが運用上の証拠として有用なのは、この約束があるからだ。ネットワーク運用者、仲介者、研究者、取引当事者が、レジストリ変更が公的記録へ入ったかを確かめる材料にする以上、時間の来歴は精密に表現されるべきである。

案件資料ではなく、小さな証明を

プライバシーを守るスナップショット収録証明は、ごく短くできる。スキーマ版、生成時刻、主張する収録終点を、最大イベント時刻、オブジェクト数、移転集合の正規化ダイジェストに結び付ける。前回ダイジェストも参照し、新規追加、訂正、公開表現からの撤回、遅着取込の件数を示す。

要となるのはソースシステム水位、すなわち発行に用いる認可済み入力をどこまで確認したかである。水位が進み採用オブジェクトがなければ、完了した差分ゼロ確認と記せる。過去の移転を後から直した場合は訂正と分類し、ファイル変化だけを見た利用者が新規取引と誤認するのを防げる。申請書、契約、通信、デューデリジェンス資料を開示する必要はない。

4日分の9月ファイルは内部的に整合している。移転日の矛盾も、業務件数の変化もない。ここから得られる結論は控えめだ。現在のファイルと現在のイベントは異なる証拠物である。AFRINICはすでに両方の時計を公開している。あとは、進む時計が何を確認したのかを示す短い接続情報だけでよい。

出典