ICANNの政策進捗報告に「決定までの時計」が必要な理由

要約

ICANN理事会は8月21日付の回答で、案件ごとの複雑さを無視した固定の最終期限はBylawsに基づく審査を妨げかねないとした。その代わり、各ICANN Public Meeting前の進捗報告と、会議前ワークショップでの常設レビューを行う意向を示した。
定期報告は現在地を伝えるが、そこへ至る履歴までは残さない。受領、必要資料、照会事項、担当、見通しの改定、勧告ごとの最終処置をつなぐ「勧告から決定までの時計」が必要であり、リエゾンやcaucus、スタッフ分析を決定権と混同してはならない。

期限を求めた側に対し、ICANN理事会が提示したのは報告の周期だった。

5月25日、GNSOを構成する六つのStakeholder GroupとConstituencyの代表が、Tripti Sinha理事会議長に連名で書簡を送った。現行ルールに時間の記述がない、と主張したわけではない。Annex Aは、理事会がGNSO Councilの勧告を「可能な限り速やかに」、望ましくはRecommendations Report受領後二回目の会合までに議論すると定めている。

書簡が問題にしたのは、その先である。議論を始める時期についての期待はあっても、いつ審査を終えて採否を返すかは標準化されていない。そこで、理事会会合の回数と月数の上限を組み合わせた標準期間を提案し、六か月を一例として挙げた。さらに、継続的な進捗報告、Consolidated Policy Scorecardの恒久的な掲載場所、審査中に理事会がGNSO CouncilやWorking Groupのリーダーへ質問できる経路を求めた。

8月21日の回答は、迅速さの必要性を認める一方、固定の最終期限を退けた。勧告は性質も複雑さも異なり、一律の期限がBylaws上必要な審査を阻害するおそれがあるという。理事会は代案として、予想時期と状態を報告し、各ICANN Public Meetingの前に更新を出すこと、会議前の理事会ワークショップで政策案件の状態を常設項目として扱うことを表明した。

これは「六か月か、無期限か」という二択ではない。期限は経過時間を制御する。定期報告は、機関が自らの状態を説明する時点を制御する。後者が前者を律するには、新しい報告が古い状態を消すのではなく、履歴を積み上げなければならない。

5月に未決だった二案件は6月に動いた

連名書簡は、当時理事会審査が完了していなかった二つの例を挙げていた。IDN EPDP Phase 2の勧告は2024年12月、Transfer Policy Reviewは2025年4月に理事会へ送られていた。

両案件は、回答書が出る前に状態を変えた。2026年6月7日、理事会はTransfer Policy Reviewの47勧告すべてと、IDN EPDP Phase 2の14政策勧告すべてを採択した。いずれについても、優先順位付け、および実施過程で判明する運用、技術、法務、セキュリティ、資源上の事情を踏まえて実施するよう、President and CEOまたはその指名者に指示した。

決議理由は、審査の時間と手続に対するコミュニティの懸念を明記している。また、Final Report、Public Comment、実現可能性の評価、GACへの通知、案件固有の資料を検討したと説明した。時間への疑問が無意味になったのではない。未決だった二案件が、審査を振り返るための完了例へ変わったのである。

現在のICANN政策実施ページでは、両案件はimplementation queueに置かれている。「理事会判断待ち」より後の状態だが、「実施開始」と同じではない。キューに入っただけでは、担当者、初回作業日、Implementation Review Team、実施案、発効日を証明できない。

5月の書簡だけを読めば、二案件は今も理事会にあるように見える。最新の実施ページだけを読めば、問題は理事会審査ではなく実施待ちにあったように見える。二つの状態と6月7日の遷移を一続きにして初めて、権限がいつ移ったかが分かる。

「議論する」と「決着させる」を分ける

Annex Aの時期に関する文言は限定的である。勧告を受領した後、速やかに会合を開いて議論するよう求めるが、その会合で採択または拒否まで終えるとは書いていない。本稿で確認した公開資料からは、すべての関連議論の日時や、この条項の「会合」をICANNがどのように数えたかも確定できない。

したがって、カレンダー上の長さだけからBylaws違反を断定することはできない。確認できるのは、入り口付近に議論開始の期待があり、出口には固定上限がないという構造である。

柔軟性には理由がある。GNSO supermajorityが支持した勧告には強い制度的重みがあり、理事会は原則として採択しなければならない。採択がICANN communityまたはICANNの最善の利益に反すると、投票資格のある理事の三分の二を超える多数が判断した場合に限り、退けることができる。

この高い壁は、ボトムアップの政策形成を尊重しつつ、理事会自身が法適合性、実現可能性、安全性、費用、公共利益を審査する責任を残す。一律期限の満了と同時に自動採択するのも、理由を示さず「審査中」を続けるのも、制度設計を損なう。時間が必要なら、その理由が記録されるべきだ。

早い対話は有益だが、決定権を移してはならない

理事会回答は、Board liaison、GNSO Councilとの早期対話、Board Caucus Groupを迅速化の手段として挙げた。2025年のBoard Readiness Small Team報告は、その背景をより具体的に描いている。従来、理事会が本格的に勧告を検討する時点では、PDPチームがFinal Reportを提出して解散してから数か月が経過していた。妥協の意図や不採用案の経緯を知るボランティアは日常業務へ戻り、質問を投げる相手が失われていた。

早期の照会はこの断絶を小さくできる。リエゾンは、Bylaws、費用、実施可能性に関する懸念をWorking Groupがまだ説明できる時期に伝えられる。caucusは理事の分析を整理できる。スタッフはPublic Commentや実現可能性資料を集められる。Working Groupのリーダーは、曖昧な文言が意図した均衡なのか、単なる欠落なのかを説明できる。

ただし、いずれも非公開の修正権を持たない。リエゾンは連絡役であってGNSO consensusを決めない。スタッフ報告は資料であって勧告の代わりではない。対話で実質が変わるなら、誰がその変更を承認できるのか、政策主体へ戻す必要があるのかを明示しなければならない。

8月の回答もこの線を認めている。対話は記録を明確にし、疑問を早く表面化させるためのものだが、理事会とGNSO CouncilのBylaws上の役割を変えてはならない。役割の混同で得る速度は、改善ではない。

Scorecardは現在地を示す。時計は経路を示す

ICANN orgは、Consolidated Policy Scorecardを定期的に公開し、コミュニティ由来の政策や成果を一か所で追跡できるようにしている。利用者が書簡、理事会資料、GNSOページ、実施ページを毎回つなぎ直す必要を減らす点で有用である。

しかし最新状態だけでは、遷移の説明にならない。「理事会審査中」から「実施キュー」へ変わったとき、新版は後者を表示できる。旧状態と遷移イベントが残らなければ、完全な資料がいつ揃ったか、何が日程を止めたか、見通しがなぜ変わったか、一部勧告だけがpendedになったかを答えられない。

同じ「pending」も中身は異なる。Public Commentの終了待ち、GAC回答期限待ち、実現可能性評価待ち、法的な質問への回答待ち、ワークショップ日程確定済み、次の担当が未設定——それぞれ責任も次の行為も違う。

法的助言やセキュリティ上の機微を公開する必要はない。法務審査、技術的実現可能性、資源分析、公共政策上の意見、clarification待ち、agenda capacityといった限定的な理由区分で、何の種類の依存関係かは示せる。非公開の必要がなくなった時点で、追加開示を再検討すればよい。

勧告から決定までを一つの時計にする

Daniel Kadeが提案する時計は、理事会が正式なRecommendations Reportを受領した時点から始まる。文書の識別子とhash、GNSOの投票、適用されるBylawsの経路と投票基準を保存する。Public Comment、GACへの通知、feasibility analysisなど、必要な資料について、開始、終了、理事会記録への投入日を分ける。

調整と権限も分離する。情報を動かすliaison、caucus、スタッフownerは記録できるが、decision-makerはBoardと表示する。最初の議論とその後の重要な審議を残し、出席しただけで結論が出たとは扱わない。

状態語は限定する。受領、資料待ち、審議可能、clarification依頼、決定予定、採択、拒否、pended、撤回、supersededである。各状態に証拠日、次の行為、担当、見通しを付ける。見通しを変更したら以前の値と理由を残し、最新日で上書きしない。

決定時には報告書全体だけでなく、勧告ごとの処置、投票、理由、実施条件を記録する。採択後にimplementation queueへ渡る場合は、別のhandoffでキューと開始を区別する。

これは自動採択の仕組みではない。複雑な案件が六か月を超えることには正当な理由があり得る。時計が求めるのは、その理由と責任が同時代の記録として残り、後から丁寧な近況報告を推測する必要がないことである。

ICANNは政策審査の最終期限を置かない。進捗報告には履歴の時計が要る

なぜ重要か