要約

  • ICANNの制度的権限は、規約上の使命と権限、IANA命名機能に関する契約、ルートゾーン管理の手続、レジストリおよびレジストラとの契約によって段階的に具体化される。
  • その権限は一般的な政府規制権ではなく、契約上の履行確保と調整手続に依存する。争われた理事会の作為・不作為には再考、独立審査、オンブズマン手続、コミュニティ権限などが関係するが、すべての運用判断に対する一般的な上訴ではない。

規約は出発点だが、運用権限そのものではない

ICANNの使命、権限、組織構造、説明責任手続は、組織の規約に定められている。規約は、理事会の一定の行為を審査する手続も含むが、規約の存在だけで、ICANNがインターネット全体に対して政府と同じ意味での公権力を持つことにはならない。制度の根拠を読む際には、組織規約が与える内部的な権限と、他の主体が契約または運用手続を通じて受け入れる義務を分ける必要がある。https://www.icann.org/resources/pages/governance/bylaws-en

この区別は、ICANNの正統性を評価するうえで重要である。ICANN自身の説明は制度の設計を示すが、それだけで、特定の決定が適法または適切だったことを独立に証明するわけではない。実際の権限は、規約上の任務が契約、政策、技術手続にどのように変換されるかによって測られる。

IANA契約とルートゾーン管理が示す運用面

IANA命名機能に関する契約は、命名機能の運用責任、性能、報告、説明責任に関する要件を定める。これにより、ICANNの制度的役割は、抽象的な調整理念から、履行すべき業務と報告可能な成果へと変換される。契約上の義務は、誰が何を実施し、どの基準で説明するのかを確認するための検証可能な接点になる。https://www.icann.org/resources/pages/iana-naming-function-agreement-2016-08-01-en

ルートゾーン管理は、さらに複数主体の連携として記述されている。ICANN、IANA機能運用者、ルートゾーン変更を承認する責任を持つ主体が、それぞれ異なる役割を担う。したがって、ルートゾーンの変更や委任をICANN単独の命令として説明することは、公開資料が示す責任分担を過度に単純化する。資料は、ICANNに一方的な政府権限があることを示していない。https://www.icann.org/resources/pages/root-zone-management-2016-06-16-en

ここでの実務上の焦点は「誰が最終的に支配するか」という単純な問いではない。変更要求の受付、技術的検証、承認、実装、記録、異議申立ての各段階で、別々の主体が関与する。その連鎖のどこに契約上の義務があり、どこが独立した運用判断なのかを特定しなければ、障害や紛争の責任を正確に説明できない。

契約がICANNの実効的なレバーになる

汎用トップレベルドメインのレジストリ契約は、技術運用、コンプライアンス、データエスクロー、コンセンサスポリシー、紛争関連義務、報告、契約違反への対応を定める。契約ごとに条項や改訂は異なるため、単一の契約をすべてのレジストリに一般化することはできない。それでも、レジストリ運用に対するICANNの実効的な影響力が、抽象的な主権ではなく、契約上の義務と違反対応に結びついていることは確認できる。https://www.icann.org/resources/pages/registries/registry-agreement-en

レジストラについても、認定契約が運用、コンプライアンス、ポリシー遵守、執行または終了に関する要件を設定する。これにより、ICANNの実務的なレバーは、政府機関として市場全体を直接規制することではなく、認定関係を維持し、契約違反に対して定められた手段を使うことに置かれる。2013年の認定契約がすべてのレジストラに現在も適用されるとは限らないため、個別案件では当該事業者の現行契約を確認する必要がある。https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en

この構造は、権限と責任の境界を明確にする。ICANNは契約相手に対して一定の履行を求められるが、各レジストリやレジストラのすべての技術的行動を直接実行するわけではない。ルートサーバー運用者、IANA機能運用者、政府、政策策定主体も、それぞれ異なる責任を持つ。ICANNの文書に名前があることだけでは、個別の障害、決定、復旧をICANNに帰属させる根拠にならない。

救済は「一般的な上訴」ではなく、手続ごとの限定的な検証である

ICANNの説明責任枠組みには、再考請求、独立審査プロセス、オンブズマン手続、コミュニティに付与された権限などが含まれる。各制度には、対象、資格、期限、手続要件、利用できる救済または勧告の範囲がある。したがって、救済の有無を判断するには、問題となる行為が理事会の作為・不作為なのか、契約執行なのか、政策形成なのか、独立運用者の実装なのかを先に分類しなければならない。https://www.icann.org/resources/pages/accountability-2016-06-25-en

独立審査プロセスは、資格を持つ申立人が、ICANN理事会の一定の行為または不作為が定款や規約に反すると主張するための説明責任メカニズムである。審査の中心は、あらゆる政策判断を最初からやり直すことではなく、争われた行為が定款・規約と整合しているかを検討することにある。運用上の不満や政策上の敗北が、そのまま独立審査の対象になるわけではない。https://www.icann.org/resources/pages/accountability/irp-en

このため、ICANNの救済構造は二重の限界を持つ。第一に、申立人は適格性、対象行為、期限などの入口条件を満たさなければならない。第二に、審査が認められても、それは必ずしも裁判所と同じ意味での全面的な損害賠償や政策の置換を意味しない。制度が提供するのは、規約・定款との整合性を検証し、定められた範囲で是正または勧告につなげるための手続である。

どこまでが確認でき、何がまだ確認できないのか

公開資料から確認できるのは、権限の制度的な連鎖である。規約が使命と権限を示し、IANA契約が運用上の責任と報告要件を具体化し、ルートゾーン管理が複数主体の役割分担を示し、レジストリ・レジストラ契約が相手方への履行確保の手段を定める。そして、再考、独立審査、オンブズマン、コミュニティ権限が、一定の争いに対する説明責任の入口を用意する。

一方、制度が実際にどれほど強靱かを判断するには、個別案件の記録が必要である。どの契約条項が適用されたのか、違反通知と是正期間がどう運用されたのか、独立審査や再考の結論がどのように実装されたのか、異なる主体間で責任がどのように移転したのかを確認しなければならない。文書上の救済手続が存在することと、争われた決定を現実に修正できることは同じではない。

結論として、ICANNの権限は、単一の法源から一括して与えられるものではない。規約、契約、政策、委任された運用、そして説明責任手続が、異なる種類の権限と責任を接続している。正統性を検証するには、ICANNが何を主張しているかだけでなく、どの文書が権限を付与し、誰が実装し、誰が異議を申し立て、どの範囲の救済が実際に利用可能だったかを追跡する必要がある。