要約

  • GNSO Councilは2016年10月13日、ccNSO Councilは同年11月7日に統一枠組みを採択した。ICANN orgは2026年9月、他のSO/ACの採択または支持を確認できなかったと報告した。
  • Boardは枠組みの検討・採択を求められておらず、文書に書かれたBoardの役割が一般的に合意されたとは証明できない。
  • 現在のReviews CCGは2025年の別個の憲章、SO/ACからの指名、Board承認に基づく。未確定なのは将来のStructural Reviewグループの設計である。

二つの決定と、その先の空欄

GNSOの記録には、最終枠組みを採択した日と、その後に求めた行動が分けて記されている。2016年10月13日の決議は枠組みを承認し、ccNSOの採択後にすべてのSO/ACへ「二つの評議会が採択した」と知らせ、将来のCCWGを検討する際に原則を参照するよう勧めるものだった。

ccNSOは11月7日の決議123-07で、最終報告と枠組みを採択した。同時に、ICANNの各諮問委員会とAddress Supporting Organizationにも採択を呼びかけた。ここで確認できるのは、二つの採択と、他組織への招待である。招待を受けた事実は、招待先の意思決定を代行しない。

Reviews CCGから状況を問われたICANN orgは、2026年9月18日に記録調査の結果を回答した。他のSO/ACが枠組みを採択または支持したとは考えていない、したがって現時点では、実証済みで利用可能な招集メカニズムではなく、せいぜい参照点として扱うべきだという内容だった。

これは「非公式の利用が一度もなかった」という断定ではない。記録上の正式行為が見つからないという証拠境界である。過去の実務への影響と、組織を拘束する採択は別々に記述しなければならない。

Boardについても同じ区別が要る。GNSOの活動ページは、Board審議前のパブリックコメントとBoard決議をいずれもN/Aとしている。ICANN orgは、Boardが枠組みの検討と採択を求められたことはなく、そこに定義された役割への合意もなかったと説明した。

枠組みは「憲章を作るための枠組み」だった

Version 1は、あらゆる場合に固定的に適用する拘束規則ではなく、一般的な指針とベストプラクティスを集めた文書だと自ら位置づけている。CCWGを成立させるには、少なくとも二つのSO/ACが、それぞれの通常手続で同一の憲章を採択しなければならない。その組織がChartering Organizationsとなる。

具体的な権限は憲章に書かれる。どの組織がいつ、どの決議で承認したか。任命されたメンバー、一般参加者、オブザーバーの違いは何か。Boardやスタッフのリエゾンが参加するのか。合意形成の方法と閾値、少数意見、エスカレーション、変更、終了をどう扱うのか。Boardに最終勧告への対応を求めるなら、その点も憲章に明記する。

開放性と決定権を分ける規定もある。一般の参加者は会合や作業に参加できる。しかし、正式なコンセンサス確認が必要な場合、既定ではChartering Organizationsが任命したメンバーだけがその対象になる。広い知識の入口を保ちながら、参加を代表権に読み替えない構造である。

成果物は全Chartering Organizationsへ同時に送られる。憲章に別の定めがない限り、すべてが少なくとも反対しないことが、正式なCCWG成果物となる条件だ。実施やBoardへの提出は、その後の定められた手続に従う。つまり、この枠組みは完成済みの権限ではなく、権限を記録する方法を提示していた。

現行Reviews CCGの根拠は別にある

現在活動するReviews CCGの正当性を、2016年文書の採択範囲だけで評価するのは誤りだ。2025年の同グループの憲章には独立した仕組みがある。

SO/AC、Board、ICANN orgがNominating Groupsとされ、メンバーを指名した組織は憲章を支持したとみなされる。メンバーは指名組織の代表ではなく個人の資格で活動する一方、最終提案を支持するかどうかはSO/ACが決める。内部ではコンセンサスを求め、外部では全SO/ACに審議を求める。二つ以上のSO/ACが支持しなければ手続は終了する。

Boardは2025年9月5日にこの憲章を承認し、James GalvinとLeón Sánchezを参加者に任命した。Board Chairの書簡もその二点を確認している。現行グループには、憲章、指名、外部支持、Boardとの関係を追跡できる独自の記録がある。

Structural Reviewで未確定のもの

2026年6月のReview of Reviews草案は、Structural Reviewの後半段階を、既存慣行を使うCross-Community Working Groupが担う案を示した。9月1日の会合では、ICANNの新しい構成要素、既存部門間の関係、Boardの構造、組織の適合性まで扱う可能性があるため、誰でも参加できる開放的な場を維持する考えが議論された。

同時に、会合はCCWG方式の現在の地位を確認するよう求めた。後日の回答が示したのは、名称だけでは足りないということだ。どのSO/AC、または何組織が憲章を承認するのか。参加の均衡をどう定義するのか。Boardへ提出する前にいくつの支持が必要か。Boardが採択しない場合に誰とどのような対話を行うのか。これらを新しい設計で明文化する必要がある。

憲章ごとの認証票を公開する

将来グループの開始前に、正確な憲章版とハッシュを公開し、SO/ACごとの行を持つ認証票を作れる。各行には、検討、採択、支持、反対、未行動の別、日付、決議、効力を記す。その行為によりChartering Organization、指名組織、オブザーバーのどれになるのか、あるいは役割を持たないのかも明示する。

同じ記録には、任命権、メンバーと参加者の差、内部閾値、少数意見と異議申立て、成果物に対する各機関の扱いを入れる。Boardの行では、リエゾン、審議、拒否時の対話、承認、実施を分ける。実質的な憲章改定は、新しい版と新しい組織決定を必要とする。

Structural Reviewには広い参加が有益だろう。だが、広い参加は、各組織がどの文書を採択したかという記録の代わりにはならない。2016年枠組みはチェックリストとして使い、新しい権限は新しい証拠で示すことができる。

情報源