要約

  • 9月1日から、ICANNのOpen Data PlatformとAPIは利用できなくなり、旧URLは新しいページへ転送される。現在案内されているCSVは、ログインせずに取得できる。
  • 引き継ぎの成否は、現在の取得可否だけでは測れない。旧データセットと現行の置き場を結ぶ対応表、さらに各版の定義・バイト列・訂正関係を示す受領記録が必要になる。

今回の変更を「APIの廃止」とだけ呼ぶと、重要な改善を見落とす。「アクセスの簡素化」とだけ呼ぶと、失われる機能とデータの履歴管理を見落とす。

ICANNは6月15日、新しい公開データページを発表した。旧プラットフォームは8月末まで併存させ、利用者が新しいページを確認し、処理を更新できる期間を設けた。8月27日の通知は期限を改めて明示した。8月31日後に旧プラットフォームは利用不能となり、9月1日からAPIも停止し、旧URLはOpen Data Initiativeページへ転送される。

理由として挙げられたのは、公開アクセスの簡素化と、保守・データ保存・バックアップ負担の削減である。通知も移行期間も存在するため、根拠なく「隠された閉鎖」と表現すべきではない。

ただし、通知は移行台帳ではない。いつ、どこへ移るかは分かる。旧カタログの各名称、APIへの依存、通知や検索などの機能が、現在どの状態になったかを一行ずつ確認できる資料は、今回確認した移行ページにはない。

アカウントの壁はなくなる

現行のOpen Dataページに表示されるのは、Domain Name Marketplace Indicators（DNMI）とSecurity Response Waiver Requests（SRW）の二系統である。リンクされたファイルは、アカウントを作らずに取得できる。

DNMI Version 1.1は、Robust Competition、Marketplace Stability、Consumer Trustの三分類に16の現役指標を置く。各ページは年次更新の指標と旧版から残すアーカイブ指標を分けている。SRWは、受領件数、対象、申請時期、処理結果など五つの測定項目を一つの年次CSVにまとめる。

単純なファイル配布には強みがある。一般的な道具で開け、全体を保存でき、APIキーやクォータを管理する必要がない。公共のファイルを一度確認したいだけの読者にアカウントを要求しないことは、実質的な改善だ。

本稿で抽出確認した二つのCSVは、検証時点で正常に取得できた。HTTP応答にはLast-ModifiedやETagといった配信情報もあった。これらはキャッシュや変化の検知に役立つ。ただし、確認したページは、それをICANNが認定する版の同一性や訂正理由の記録として定義していない。

「今、取れるか」と「後から同じものを特定できるか」は別問題である。後者には対象期間、測定定義、発行時点、期待されるダイジェスト、行数、訂正・後継版へのリンクが必要になる。

旧プラットフォームは機能と関係を持っていた

2018年の調達発表で、ICANNはOpen Data Platformを、オープンライセンスとオープンAPIを備え、信頼できる機械可読データをダウンロード・処理するための「source system」と位置づけた。

旧Aboutページはさらに、アクセス可能性、利用可能性、適時性、包括性、比較可能性、相互運用性を掲げ、ガバナンスとコミュニティ参加への活用を期待した。登録利用者向けには、分析の保存、更新通知、APIキー、クォータ確認もあった。

この製品を永久保存する義務が生じるわけではない。外部ホストのプラットフォームには費用がかかる。全量スナップショットを残す用途では、単純なCSVの方が、サーバー依存の問い合わせより再利用しやすい場合もある。

それでも、インターフェースを変えれば、利用者が自分で保持すべき情報が増える。旧APIのデータセットID、フィルター、フィールド、ページング、通知に依存した処理は、新しい対応先か、対応しないという明示的な状態を必要とする。同じURLでCSVが更新されるなら、新版、訂正版、単なる再配信を区別する仕組みが要る。

ベンダーを終了することと、制度の記憶を終了することは同じではない。

「四つから二つ」は消失の証拠ではない

旧トップページは、DNMI、Identifier Technology Health Indicators（ITHI）、Registry Activity Reports、Registrar Transaction Reportsの四テーマを表示していた。現行のOpen DataトップはDNMIとSRWの二行を示し、利用可能になったデータを今後追加するとしている。

この数だけを比較して「二系統が消えた」と結論づけるのは誤りだ。Monthly Registry Reportsは現在もICANN本体の別ページでTLD別に取得できる。ITHIの専用ダッシュボードも、現在値と履歴を公開している。

確実に言えるのは、旧テーマごとの行き先を示す対応表が、移行告知と新トップページからは見えないということだ。

Registry Reportsの経緯は、この空白を具体化する。ICANNは2021年、Registry Functions Activity ReportsとPer-Registrar Transactions ReportsをOpen Data Platformへ移し、自動ダウンロードを行うスクリプトはOpen Data APIを使うよう変更せよと通知した。当時の案内に従った利用者は、再び処理を変える必要がある。

実際の障害が起きたとは確認されていない。しかし、API依存がICANN自身の公開案内によって生じたことは確認できる。

対応表には複数の正当な状態を書ける。新CSVへ移行、専用ダッシュボードで継続、本体サイトの報告書ページで継続、統合、アーカイブ、代替機能なし。問題は特定の状態ではなく、利用者がそれを推測しなければならないことだ。

転送先と正式な版は別物

リダイレクトは旧入口を訪れた人を案内する。旧クエリの意味や、ある時点で公表された正確なバイト列までは表現できない。

例えばRC 2.1を引用するなら、現在のURLだけでなく、対象期間、定義の版、発行時刻、期待ダイジェスト、行数、後の訂正が必要になる。利用者が自分でハッシュを計算すれば、手元に保存したものは証明できる。しかし、そのバイト列を当該期間の公式版と結びつける制度上の判断は、利用者がICANNに代わって作ることはできない。

必要な仕組みは大規模でなくてよい。移行対応表と版の受領台帳で足りる。

公開項目 明らかにすること
旧ファミリー、ID、API経路 何を移すのか
現在の正規URLと責任主体 どこにあり、誰が管理するか
処置と機能差 移行、別置、統合、アーカイブ、終了のどれか
対象期間、頻度、定義版 数値が何を意味するか
発行時刻、期待ダイジェスト、行数 どの公開物がその版なのか
訂正・後継関係 過去を消さずに何が変わったか
ライセンス、集約制約、連絡先 再利用条件と異議申立て先

URLは場所を示す。受領記録は版を示す。訂正リンクは履歴を示す。この三つは一つの転送命令には置き換えられない。

インターフェースから独立した記憶を

今回の移行を、API対CSVという好みの問題にすべきではない。ログイン不要は前進であり、運用費の削減も正当な判断になり得る。確認した資料から、現行ファイルの誤りやデータ消失を断定することもできない。

問うべきは、製品が変わっても公開データの同一性が残るかである。

軽量でベンダーに依存しない台帳があれば、ICANNは将来もホスト、保存方式、APIの有無を変えられる。利用者は明示された処置に沿ってソフトウェアを直し、研究者はその時点の版を引用し、訂正は元の公開物を残したまま説明できる。

ICANNは日付、入口、一般的な理由を示した。最後に必要なのは、引き継ぎそのものを検証可能にする受領記録である。

出典

  1. ICANN Public Data Webpage Update、2026年8月27日
  2. 新しい公開データページの発表、2026年6月15日
  3. ICANN Open Data Initiative
  4. Domain Name Marketplace Indicators
  5. DNMI：Robust Competition
  6. DNMI：Marketplace Stability
  7. DNMI：Consumer Trust
  8. Security Response Waiver Requests
  9. 旧Open Data Platformトップページ
  10. 旧Open Data PlatformのAboutページ
  11. 2018年のOpen Data Platform調達発表
  12. 2021年のRegistry Reports移行発表
  13. 現行Monthly Registry Reports
  14. 現行ITHIダッシュボード
  15. DNMI RC 2.1のサンプルCSV
  16. SRW M1-M5のサンプルCSV