要約

  • ICANNの権限は、定款・付属定款による組織上の根拠、コミュニティの説明責任、参加者との契約という複数の層から成り立つ。契約があるからといって、ICANNが一般的な政府権力を持つことになるわけではない。
  • レジストリ契約やレジストラ認定契約は、政策や技術要件を報告、監査、コンプライアンス、紛争処理、制裁や終了の可能性を伴う運用上の義務に変換する。異議申立て、独立審査、コミュニティ権限などは、同じ「不服申立て」でも対象、審査基準、決定者、救済の性質が異なる。

1. 権限の出発点は、まず組織の文書にある

ICANNの権限を理解するには、まず何が組織を設立し、何がその行動範囲を定めているかを分けて見る必要がある。ICANNの【Articles of Incorporation】(https://www.icann.org/resources/pages/governance/articles-en)は、同組織をカリフォルニア州の非営利公益法人として位置づけ、グローバルなインターネット識別子システムの調整などの目的を記載している。これは、レジストリ事業者やレジストラに個別の命令を出す契約条項そのものではない。組織の法的形態と目的を示す、より上流の文書である。

次の層にあるのが【ICANN Bylaws】(https://www.icann.org/resources/pages/governance/bylaws-en)だ。付属定款は、使命、基本的価値、理事会の構造、政策策定、説明責任の仕組み、権限の限界を定める。したがって、付属定款は単に組織内部の手続を列挙する文書ではない。ICANNが何を目的に行動し、どの意思決定経路を通り、どのような審査の対象になり得るかを示す統治上の基準でもある。

ただし、公開されている各文書のページだけから、あらゆる時点の紛争に適用される条文を確定することはできない。ICANNの資料自体も、付属定款や手続が更新され得ることを前提としている。日付のある紛争を検討する場合には、当時の改訂版、補足手続、個別契約の締結日を特定しなければならない。この不確実性を無視して「ICANNのルールは常に同じだった」と扱うのは危険である。

2. IANA移行は、権限の単純な移転ではなく説明責任の再設計だった

2016年の【IANA Stewardship Transition】(https://www.icann.org/resources/pages/iana-transition-2016-06-03-en)に関する資料は、IANA機能をめぐる従来の米国政府との契約的な枠組みから、コミュニティが策定した説明責任の仕組みへ移行した経緯を説明している。資料は、ICANN、Public Technical Identifiers、グローバルなインターネット・コミュニティの役割を区別している。

ここで重要なのは、「政府の監督がなくなり、ICANNが無制限の公権力を得た」という理解ではない。移行の意味は、誰がどの機能を運用し、どの機関やコミュニティがそれを監視し、どの基本文書に基づいて異議を申し立てられるかという関係を再構成した点にある。移行資料は説明的な証拠であり、それ自体がすべての現在の契約や付属定款に取って代わる法的文書ではない。

【ICANN Agreements and Policies】(https://www.icann.org/resources/pages/agreements-2012-02-25-en)が示すように、ICANNの統治は制度文書だけで完結しない。レジストリ、レジストラ、技術運用者など、識別子エコシステムの参加者との契約が、実際の運用関係を定義する。ここに、組織の目的から参加者の行動へ至る因果の中間層がある。

3. 契約は政策を運用上の統制へ変換する

【Registry Agreements】(https://www.icann.org/resources/pages/registry-agreements-en)に掲載されるレジストリ契約は、トップレベルドメインの運営者に対して、委任された責任、技術要件、報告、コンプライアンス、紛争関連の義務などを定める。契約が実務上重要なのは、抽象的な政策を、運営者が履行すべき具体的な条件へ落とし込むからである。

より具体的な標準枠組みとして、2017年6月30日付の【Base Registry Agreement】(https://www.icann.org/resources/pages/registry-agreement-2017-06-30-en)は、レジストリ運営、技術および政策上のコンプライアンス、データエスクロー、報告、監査と検査、料金、紛争解決、契約上の救済を扱う。資料には複数の版や改訂があるため、特定の事業者や時期について結論を出す場合は、該当する実行日と版を確認する必要がある。

レジストラ側では、2013年9月17日付の【Registrar Accreditation Agreement】(https://www.icann.org/resources/pages/registrars/registrar-accreditation-agreement-2013-09-17-en)が、ICANN認定レジストラとなるための契約条件を示す。そこにはレジストラの義務、コンプライアンスと監査、データおよび消費者保護、紛争関連の条件、停止または契約終了に至り得る救済が含まれる。ただし、後続の契約や改訂が後の期間を支配する可能性がある。

この構造が意味するのは、ICANNがインターネット上のすべての主体に直接命令できるということではない。契約関係に入る事業者に対して、契約上の義務と違反時の手段を持つということである。つまり、実務上の統制面は広いが、その法的性質は契約、組織統治、技術調整の組み合わせとして理解すべきであり、一般的な国家行政権と同一視できない。

4. 「救済がある」だけでは、どの問題を解決できるか分からない

ICANNの説明責任のページは、再考、独立審査、オンブズマン、文書情報請求、コミュニティ権限など複数の仕組みを挙げている【Accountability Mechanisms】(https://www.icann.org/resources/pages/accountability/mechanisms-2018-06-15-en)。しかし、これらを一つの上訴制度として扱うと、誰が申立てられるのか、何が審査されるのか、誰が判断するのか、どの救済が得られるのかという違いを失う。

第一の区別は、契約上の問題と組織手続上の問題である。レジストリやレジストラの契約違反に関する争いでは、契約条項、通知、監査、履行、制裁、終了、紛争解決条項が中心になる。他方、ICANNの職員または理事会の行為が付属定款や文書化された手続に適合していたかという問題では、別の説明責任手続が問題になる。

【Reconsideration】(https://www.icann.org/resources/pages/accountability/reconsideration-2012-02-25-en)は、適格性と申立期限などの要件を満たす影響を受けた当事者が、ICANN職員または理事会の一定の作為・不作為について、理事会ガバナンス委員会に再考を求める仕組みとして説明されている。その中心は、政策、付属定款、または文書化された手続との整合性であり、一般的な意味での全面的なメリット上訴とは異なる。現行の期限、適格性、対象範囲は、最新の付属定款と手続で確認しなければならない。

【Independent Review Process】(https://www.icann.org/resources/pages/accountability/irp-2012-02-25-en)は、ICANNの理事会または職員がArticles of IncorporationやBylawsと整合しない行動を取ったという一定の主張について、外部的な審査を提供する。資料は、この手続が裁定的な性格を持ち、適用される付属定款やIRPルールに定められた宣言その他の結果を生じ得ると説明する。ただし、後続の付属定款改訂や補足手続が適用される可能性があるため、古い概要ページだけで現在の救済範囲を断定することはできない。

5. 情報開示は、救済手続そのものではなく、証拠を得る経路になり得る

【Documentary Information Disclosure and Transparency】(https://www.icann.org/resources/pages/governance/transparency-2012-02-25-en)は、ICANNの運営に関する記録を請求する経路を説明している。請求には例外や秘密保持上の制限があり、開示が自動的に認められるわけではない。

この仕組みの位置づけは、他の救済手続との違いを明確にする。文書請求は、必ずしも特定の決定を取り消す審査ではない。むしろ、意思決定の経緯を評価したり、別の手続で主張を組み立てたりするための資料を得る経路になり得る。何が開示されるかは、例外、特権、プライバシー、セキュリティなどの制約によって変わる。

したがって、「文書を請求できる」ことと「決定を再審査してもらえる」ことは同じではない。前者は情報へのアクセス、後者は決定の適法性または手続的整合性を問う制度である。この区別は、ICANNに対する異議を考える際に、手続の順序と目的を見誤らないために重要になる。

6. コミュニティ権限は、個別の契約救済とは別の統治レバーである

【Community Powers】(https://www.icann.org/resources/pages/community-powers-2016-03-16-en)は、ポスト移行の説明責任枠組みにおいて、Empowered Communityが理事会の一定の行為や基本的なBylaws変更に対して指定された権限を持つことを説明する。例として、予算や戦略計画の拒否、個別理事の解任、理事会全体のリコール、指定された基本的行為の承認または拒否などが挙げられているが、いずれも手続的要件に従う。

この権限は、レジストラが契約上の義務を履行しなかった場合に用いる個別の契約救済とは異なる。前者は組織の基本的な方向、理事会、予算、規則変更に対する集団的な統治手段であり、後者は契約当事者間の履行と違反に関する手段である。両者を同じ「制裁」や「上訴」と呼ぶと、誰が動けるのか、何を変えられるのかが不明確になる。

また、コミュニティ権限の実際の要件は、現行のBylawsとEmpowered Communityのチャーター文書で確認すべきである。概要ページは制度の説明に有用だが、個別案件の手続的結論を置き換えるものではない。

7. 権限の連鎖を追うと、ICANNの正当性に対する問いが変わる

ICANNの権限をめぐる議論は、「誰がインターネットを支配しているのか」という抽象的な問いだけでは整理できない。より正確には、次の連鎖を追う必要がある。

第一に、Articles of IncorporationとBylawsが組織の目的、権限、手続、限界を設定する。第二に、IANA移行後の説明責任構造とコミュニティ権限が、理事会や基本文書に対する集団的な統制を加える。第三に、レジストリ契約とレジストラ認定契約が、政策と技術上の要件を参加者の報告、監査、データ管理、コンプライアンス、紛争処理の義務へ変換する。第四に、違反や意思決定への不服が生じたとき、契約、再考、IRP、文書請求、コミュニティ権限のうち、問題に適合する手続が選ばれる。

この連鎖から導ける限定的な結論は、ICANNの実務上の力が、単一の命令権ではなく、文書、契約、技術的調整、参加資格、説明責任手続を組み合わせた制度的な制御面から生じているということである。契約があることで運用上の義務を履行させる力は生まれるが、それはICANNのあらゆる行為を公権力として正当化するものではない。

反対に、ICANNを単なる民間団体とだけ見るのも不十分である。識別子の調整に関わる組織として、ICANNの決定はレジストリ、レジストラ、技術運用者、利用者、公共機関に影響を及ぼし得る。そのため、定款上の目的、契約上の義務、コミュニティによる監視、外部審査の範囲を一緒に検討しなければ、制度の正当性もその限界も評価できない。

結論――争点は「権限があるか」ではなく、どの文書が何を許すか

ICANNの権限を評価する際に最も有用なのは、権限の有無を一度に判断することではない。まず、問題となる行為がどの文書や契約に基づくのかを特定する。次に、その行為が契約上の履行、組織上の手続、Articles of IncorporationやBylawsとの整合性のいずれに関係するかを分ける。最後に、申立人の地位、審査基準、決定者、得られる救済を確認する。

公開資料からは、ICANNが定款・付属定款、コミュニティの説明責任、参加者との契約を組み合わせて運用上の統制を形成していることが分かる。一方、特定の紛争に適用される現在の条文、契約版、期限、救済範囲は、案件ごとに再確認しなければならない。したがって、結論は「ICANNは政府である」でも「ICANNは単なる民間企業である」でもない。より慎重な結論は、ICANNの実効性が契約と制度設計の接点にあり、その正当性と限界は、どの手続がどの文書に照らして何を審査できるかによって決まる、というものになる。