要約

  • GACは5月11日、法人登録データの収集と公開を実現する作業に進展がないとして、Phase 2Aの実装日程を求めた。
  • ICANNの8月24日付回答はFY2027に着手できるとの見通しを示したが、現行方針は法人・自然人の区分を許容するだけで義務付けず、ベストプラクティスにも契約上の拘束力がないと確認した。

同じ「実装」という言葉でも、何を完成させるのかが一致しているとは限らない。

Governmental Advisory CommitteeのNicolas Caballero議長は2026年5月11日、ICANN理事会のTripti Sinha議長に書簡を送った。GACは、2022年3月にEPDP Phase 2A勧告が採択されて以来、法人の登録データを収集し公開できるようにする作業が進んでいないと評価した。契約当事者は法人データを収集し公に利用可能にすべきだという従来の立場を繰り返し、日程の確認とImplementation Review Teamへの参加意思を示した。

8月24日付の回答は、既存プロジェクトが専用の実装資源を使い終えることを条件として、ICANN orgがFY2027に作業を開始できると見込んでいるとした。公開日は8月25日である。これは着手の予測であって、完成期限ではない。

回答の核心は、その直前にある。Phase 2Aチームは、法人と自然人の登録データを区分する既存のConsensus Policy要件を変更しなかった。Registration Data Policyは、レジストリやレジストラがRDDSの墨消し要件を適用する際、データが法人に関するものか、個人データを含むかを考慮することを認めている。しかし必須とはしていない。今後作成されるベストプラクティスも、契約当事者に義務を発生させない。

つまり、公開記録に見えるのは単純な遅延だけではない。GACが求める政策上の到達点と、実装待ちの採択済みパッケージには範囲の差がある。

「作る」と「使う」を分けた2022年決定

ICANN理事会は2022年3月10日、四つの勧告を採択した。第1勧告は、法人と自然人の登録データ、または個人データと非個人データの区分を容易にするフィールドを一つ以上作るよう求める。区分を行う契約当事者は、そのフィールドを利用できる。

第2勧告は、主体の種類によって区分することを選んだ当事者に報告書のガイダンスを参照するよう促す。第3勧告は、ICANN内でGDPR Code of Conductが策定される場合の扱いである。第4勧告は、登録者ベースまたは登録ベースのメールアドレスを公開RDDSに掲載することを選ぶ当事者に、EPDPチームが得た法的助言を検討するよう求める。

ICANN orgに対する実装指示は明確に存在する。理事会はPresident and CEOまたはその指定者に、GNSO Councilのガイダンスと整合する実装計画の策定・実行を命じた。フィールドの利用が任意だからといって、ICANNが技術的成果物を作る責任まで任意になるわけではない。

一方、契約上の限界も決定文に残っている。理事会の理由説明は、これらの勧告が契約当事者に新たな義務を生じさせないと述べた。Registry Agreement、Registrar Accreditation Agreement、Consensus Policiesの外にあるガイダンスやベストプラクティスについては、ICANN Contractual Complianceが執行する契約上の権限を持たないとも説明している。

今回の回答は、勧告1、2、4をベストプラクティス文書の作業、勧告1、3をICANN org向けの作業として整理した。勧告1が両方に現れるのは、指針と技術調整の二面を持つためだ。分類上の重なりは、任意の助言を強制規則へ変えない。

現行方針では公開までに複数の判断がある

Registration Data Policyは、収集、レジストリへの移転、エスクロー、公開、墨消し、同意、適法な開示を別の行為として扱う。法人か自然人かという一つの分類で、すべてが自動的に決まる設計ではない。

第9.2.1項は、適用法を守るため個人データの墨消しが必要な場合に、その要件を適用するよう求める。ほかの一定の事情でも適用できる。判断に際して、レジストリとレジストラは法人に関する登録データか、個人データを含むか、登録者などの地理的位置を考慮できるが、必須ではない。

法人名義の登録にも、従業員、代表者、外部弁護士、運用担当者といった識別可能な人の氏名や連絡先が入る場合がある。登録主体が法人だという情報だけでは、各値が個人データかどうかを確定できない。

Registrant Organizationフィールドには現行の判断構造が表れている。レジストラはRegistered Name Holderに入力の機会を与え、提供された場合は収集しなければならない。また、同意した場合にその値が公開され、当該組織がRegistered Name Holderとして扱われることを通知する。同意があれば公開し、なければ方針に従って墨消しできる。

したがって、実際の公開判断には、対象フィールド、由来、個人データの有無、適用条項、同意の役割、責任主体が必要になる。法人という値は判断材料であり、公開命令ではない。

技術フィールドが担えるのは意味の運搬

ICANNは、Extensible Provisioning Protocolに区分フィールドを加え、更新版gTLD RDAP Profileにつなげるため、技術コミュニティと調整するとしている。

共通仕様には意義がある。事業者ごとに自由記述、定義不明の真偽値、修正不能な推定を使えば、後続システムは同じ語を別の意味で読む。共通の値、未確認・未区分の状態、更新責任、訂正方法を定義すれば、システム間で意味を保ちやすくなる。

ただし、フィールドの構文に独自の権限はない。誰が入力しなければならないか、分類を裏付ける証拠は何か、EPPで送られた値をRDAPで見せてよいかは、別の問いである。RDAP Profileは表現を定められるが、Registration Data Policyや適用法、責任ある処理者の判断に代わることはできない。

技術標準は、権限のある区分を相互運用可能にする。採択されていない義務まで運ぶことはできない。

実装計画に必要な「範囲対応表」

公開される計画には、少なくとも五つの層を並べるべきだ。

GACの書簡・コミュニケを政策上の助言として示す行。2022年の勧告と理事会決議を、ICANN orgへの指示として示す行。現行Registration Data Policyと契約を、収集・墨消し・同意・公開・開示の規則として示す行。EPP/RDAP作業を、データ表現の仕様として示す行。そして、個別登録について方針と法を適用する責任主体を示す行である。

各行には文書の版、責任者、効力、作業状況、変更できる正式手続を付ける。義務的な区分を求めるなら、どの政策プロセスがそれを作れるかが分かる。RDAP Profileが完成しても、全契約当事者による採用や、GACの公開目標の達成を意味しないことも分かる。

この対応表は、公開とプライバシーのどちらが正しいかを決めない。何が、どの権限で、いま作られているかを明らかにする。その明確さがなければ、進捗報告が未採択の約束に見えてしまう。

FY2027の後に確認すべきこと

8月24日付回答は、FY2027に「開始できると見込む」と述べ、FY2028の計画過程へのGAC参加も促した。最終設計、ベストプラクティス本文、完成日、契約当事者の採用率はいずれも示していない。

問うべき進捗は具体的にできる。誰が担当するのか。どの既存プロジェクトが完了したのか。どの成果物がどの勧告に対応するのか。順序変更の理由は何か。技術提案と指針はいつ公開されるのか。

同時に、役割の混同を避けなければならない。GACの参加は契約改定ではない。理事会によるICANN orgへの実装指示は、全レジストラへの命令ではない。フィールドは開示許可ではない。工程表は政策ではない。

今回の書簡は、その境界を公にした。Phase 2Aの次の評価点は、文書とコードと運用期待が接近したときにも、その境界が読める状態にあるかどうかだ。

出典

  1. ICANN書簡一覧
  2. Tripti SinhaからNicolas Caballeroへの書簡、2026年8月24日
  3. Nicolas CaballeroからTripti Sinhaへの書簡、2026年5月11日
  4. ICANN理事会のPhase 2A決定、2022年3月10日
  5. EPDP Phase 2A最終報告書
  6. 理事会審議に付されたPhase 2A勧告
  7. ICANN Registration Data Policy
  8. ICANNのRDAP資料