要約

  • 2026年9月1日付のGNSO運用手続v3.8には、5月21日にGNSO評議会が承認した理事会の採択撤回手続きが組み込まれた。実施完了前の限定的かつ例外的な事情だけが対象であり、現に手続きが動いていることを示す資料はない。
  • 理事会はGNSO評議会に十分な対話時間を与えるべきで、「例えば60日」は目安にすぎない。最初に公開が必須となるBoard Statementは理事会の行動後に出され、行動前の公開証拠記録や実施レビュー・チームとの協議は義務ではない。

ある政策勧告が採択済みだが、まだ全面運用には至っていないとする。契約文言が検討され、システムが設計され、実施レビュー・チーム（IRT）には未解決の問いがあり、企業は採択を前提に投資計画を立て始めている。そこで新しい情報が現れ、ICANN理事会は勧告がICANNまたはコミュニティの利益に沿わなくなったとして、以前の採択を撤回しようとする。

制度が判断を変えられるかどうかが問題なのではない。懸念を行動へ変える証拠を、影響を受ける側がいつ確認し、争えるかが問題である。新手続きは、理事会にGNSO評議会との事前対話を求め、撤回時には理由を公開させる。だが、その間にある最初の理事会行動について、先に証拠記録を開く要件はない。

これがGNSO運用手続v3.8に残った統治上の境界である。手続きの空白を埋めたこと自体は前進だ。しかし、行動後の説明と、行動前に検証できる証拠は別の統治装置である。

三つの日付を一つにしない

GNSOの手続きページは9月2日に更新され、9月1日付のv3.8を掲げている。版管理欄によれば、統合文書には2026年5月21日承認の附属書2（PDPマニュアル）と附属書5（GGPマニュアル）、さらに2025年に承認された附属書7が組み込まれた。独立版の二つのマニュアルは5月11日付である。更新附属書以外のv3.8の変更は、行政上・編集上のものと説明されている。

したがって、5月21日の評議会決議が承認の出来事であり、9月は統合版の公表である。いずれも撤回手続きの発動ではない。調べた資料には、新手続きの対象となっている現行勧告は示されていない。

2025年戦略計画会合報告は設計の背景を説明する。新gTLD後続手続きの勧告20.6を含め、採択後に問題が浮上した事例に理事会が直面し、専用の撤回経路がなかった。この経緯は規則の必要性を示すが、勧告20.6をv3.8の現行案件にするものではない。本稿もその是非を再審しない。

明文化された順序

更新された附属書2・PDPマニュアル第16節と附属書5・GGPマニュアル第10節は、ほぼ同じ順序を採用する。撤回は限定的で例外的な事情に限られる。理事会が勧告を採択済みで、実施がまだ完了していない場合に使える。すでに実施され効力を持つ勧告には使えない。

理事会は行動前にGNSO評議会と対話すべきである。少なくとも、撤回の意図、問題の内容、理由と影響、撤回が唯一または最善の選択である理由を伝える。GNSO評議会には検討と追加質問のため十分な時間が必要とされる。「例えば60日」という記述は有用な目安だが、固定期限ではない。

実体的な要件は二段である。新しい情報または事情の変化がなければならない。さらに、その結果として勧告がICANNまたはICANNコミュニティの利益に沿わなくなったと理事会が判断しなければならない。単なる変化だけでも、証拠の変化を示さない抽象的な公益主張だけでも、書かれた構造を満たさない。

票決要件はGNSOでの当初の支持に連動する。GNSO超多数を得た勧告なら、撤回には理事会の3分の2が必要である。超多数未満で採択された勧告なら、理事会の過半数で足りる。

理事会が撤回を実行する際は、判断理由をBoard StatementとしてGNSO評議会へ送り、添付文書とともに公開しなければならない。その後、GNSO評議会が声明を検討して理事会と協議し、勧告を維持するか修正するかを決める。Supplemental Recommendationは再び理事会に渡り、GNSOの支持水準に応じた要件で扱われる。

GNSOには正式な応答権が残るため、一方的な最終決定ではない。より限定された問題は公開の時点である。最初に公開が明文で必須となる文書は、最初の理事会行動の後に現れる。

意見募集で求められた事前関与

公開意見募集は2025年11月20日から2026年1月22日まで行われ、10件の提出があった。概要報告は、厳しい歯止めを伴う稀な手続きへの広い支持を記録する。

最終文言に入った提案もある。理事会が手続きに従うことを「may」ではなく「should」とする要望は採用された。根拠も「新しい情報」だけでなく「事情の変化」まで広げられた。

一方、必須にならなかった提案もある。複数の提出者は、撤回手続きの結論前に限定的な公開意見募集またはコミュニティ協議を設けるよう求めた。レジストラおよびレジストリの各ステークホルダー・グループとTucowsは、該当IRTとの協議を必須にする考えを支持した。レジストリ側は可能なら元の作業部会への照会も提案した。採択文はこれらを要件にしていない。

だから将来の案件が非公開になるとは限らない。評議員は各構成員に意見を求められ、理事会は資料を早く公開でき、双方はIRTを招ける。確認できる事実は、そうした開放が選択可能であって、最初の行動の条件ではないという点に限られる。

実施状態を誰が証明するのか

入口の線は一見明快だ。「実施が完了していない」勧告は対象になり、「実施され効力を持つ」勧告は対象外となる。しかし実際の制度実装は一斉に状態を変えない。契約文が完成してもシステムが未完成かもしれない。発効日後も移行が続き、IRTの問いが残り、執行が延期されることもある。一つの勧告が相互依存するパッケージの一部である場合もある。

マニュアルは、その境界を認証する担当者、必須の証明書、最低限の証拠集合を指定していない。これは文書上の欠落であり、ICANN内部に作業がないという断定ではない。それでも重要なのは、状態の分類が例外的な権限を使えるかどうかを決めるからだ。

「効力あり」と早すぎる認定をすれば、新証拠が重大でも経路を閉じる。「未完了」を長く維持すれば、レジストリ、レジストラ、申請者、利用者が採択済み規則を合理的に信頼した後も撤回が可能になる。後日のBoard Statementは選ばれた分類を記録できるが、最初の票決前に誤りを直す機会は保証しない。

最初の票決前に撤回記録を開く

必要なのは、最初の理事会行動前に開く、範囲と版が明確な公開撤回記録である。無期限の意見募集にする必要はなく、法的特権やセキュリティ上の秘密を開示する必要もない。権限と判断時点の証拠を結びつければよい。

記録には、開始通知と時刻、対象勧告、対象外の依存勧告、当初採択と票決要件、実施段階、段階を認証する担当主体を含めるべきだ。認証は単なる状態ラベルではなく、日付のある証拠スナップショットを参照する必要がある。

さらに、新情報または事情変化の出所、想定影響、検討した代替策を保存する。理事会の質問とGNSOの回答には安定した版を付ける。IRT、元の作業部会、コミュニティが関連証拠を提出できる期限付き窓口を設ける。保護資料についても、存在、保管者、非公開理由、判断への影響は公開層で示せる。

行動後は、同じ記録に票決、Board Statement、GNSOとの協議、Supplemental Recommendation、最終処理を加える。訂正は過去の証拠を無言で上書きせず、置換関係を付けて追記する。

これはv3.8に書かれた制度ではなく、私の編集提案である。The Policy Mirrorが問う権限の所在、Running-Code Primacyの観測可能な実行、Reality, Not Advocacyの事実と制度的自己説明を分ける姿勢に基づく。

v3.8は、採択後に新しい事実が現れ得ることを正しく認めた。次に必要なのは、行動後の透明性を行動前の異議申立可能性と取り違えないことである。証拠の窓は、最初の判断がまだ変えられる時に開くべきだ。

出典