要約

  • ICANNが公開するレジストリ契約とレジストラ認定契約の資料は、義務の根拠を調べる入口になる。ただし、2017年や2013年の基本資料を特定できることと、個別事業者に適用される現在の条項を確認できることは同じではない。
  • ポリシーの掲載、契約上の義務、コンプライアンス上の措置、措置に対する審査は、別々に根拠を確かめる必要がある。制度の説明から、個別の執行権限までを一足飛びに推定することはできない。
  • 本稿の調査では、再検討請求、独立審査、契約上の仲裁を開始すると措置が自動的に停止するのか、現在の暫定救済にどの条件があるのかは確認できなかった。これは救済が存在しないという結論ではなく、運用継続を評価するために残された確認事項である。

最初の問いは「どの義務を、どの文書に基づいて求めるのか」

義務の履行を求める通知を受け取った事業者にとって、発信者の組織名だけでは対応を決められない。何をしなければならないのか。誰がその義務を負うのか。いつまでに対応する必要があるのか。そして根拠を争う場合、何がその間も進むのか。これらは関連しているが、同じ問いではない。

ICANN（Internet Corporation for Assigned Names and Numbers）をめぐる権限の分析でも、この区別が出発点になる。技術的な調整を担うという説明から、参加者に対する無制限の権限を導くことはできない。一方、技術的な役割であることを理由に、契約によって生じ得る義務を無視することもできない。調整、契約、組織内部の手続き、公的な権限は、便利な一語にまとめるより、それぞれの根拠を示す方が正確である。

ICANNが公表するBylaws（付属定款）のページは、その使命や説明責任、審査の仕組みを調べるための入口になる。ただし、本稿では現行の統合版と個々の条項を直接照合できていない。したがって、付属定款の特定の条項が現在どの措置を認め、誰にどの救済を保障しているかまでは断定しない。

ここで扱うのは、個別の紛争の勝敗ではなく、公開資料からたどれる文書のつながりと、そのつながりを実効的な権限として説明するために必要な証拠である。参照できた記録は、文書の名称、掲載先、基本書式の日付を特定する一方、現行条項の全文や当事者ごとの適用関係まで裏付けるものではない。ICANN自身による制度の説明と、個別案件における権限の立証は分けて読む必要がある。

この限定は結論を弱く見せるための留保ではない。契約の適用範囲を飛ばして権限を大きく描くことも、審査制度の名前だけで参加者が十分に保護されていると評価することも避けるための、分析の前提である。

二つの契約資料は、同じ相手への一つの命令ではない

ICANNは、gTLDレジストリ契約に関する資料ページと、2017年7月31日承認の基本書式を示す契約PDFを公開している。この日付は、どの基本資料を参照しているかを明確にする。しかし、あるレジストリについて、後の改定や追加合意を含めた現在の契約内容まで確定するものではない。

別に、ICANNは2013年のレジストラ認定契約と付属仕様の資料も掲載している。参照記録には2013年9月17日という日付がある。こちらも、資料の特定には役立つが、すべてのレジストラの現在の義務を同一の条文で説明してよいという証拠にはならない。

二つの資料を区別する理由は、年代の違いだけではない。レジストリ向けの契約とレジストラ向けの認定契約を、一方から他方へそのまま読み替えることはできないからだ。契約上の権限を主張するなら、まず対象となる当事者と契約関係を示さなければならない。一般的な制度説明に登場する「事業者」という語は、その特定の代わりにはならない。

例えば、ある措置を契約違反への対応として説明する場合、必要なのは違反とされる行為の名称だけではない。適用される契約の版、該当する義務、通知や是正に関する条件、措置を決める主体をつなぐ必要がある。これは本稿がその条件を確認したという意味ではなく、条件を確認せずに措置の根拠を評価できないという意味である。

公開資料からたどれるもの その資料の特定だけでは確定しないもの
2017年のレジストリ契約の基本書式と掲載先 特定のレジストリに現在適用される改定・追加合意の全体
2013年のレジストラ認定契約と付属仕様の資料 特定のレジストラの現行義務、例外、契約上の救済条件
契約、ポリシー、コンプライアンスを調べる別々の入口 ある措置が、どの当事者に対して、どの根拠で実施できるか

この表で重要なのは、右側を左側から自動的に埋めないことだ。古い日付の資料だから無効だとも、新しい掲載ページだからすべての当事者に適用されるとも言えない。公開日、承認日、効力発生日、当事者への適用日は、検証すべき別の情報である。

契約の現在性は、単なる文書管理の問題ではない。義務が変われば、それに対する異議の内容も変わり得る。適用されない条項を対象に争えば、本来確かめるべき根拠から議論が離れる。反対に、現行契約への適用が確認できないまま基本書式だけを根拠に対応を迫れば、義務の説明に空白が残る。まず契約関係を確定するという作業は、双方の主張を同じ対象に向けるために必要になる。

ポリシーが掲載されていることと、拘束力があることの間

ICANNはConsensus Policiesの一覧を公開している。これはポリシー文書やその位置付けを調べるための入口だが、一覧そのものが、あらゆる契約上の義務や救済条件を示すわけではない。

ポリシーから個別の義務までをたどるには、少なくとも三つの接続を調べる必要がある。第一に、対象のポリシーが何を定めるものなのか。第二に、どの契約が、どの条件でそのポリシーを当事者の義務に結び付けるのか。第三に、その版と適用時期が、問題となっている行為に合っているのかである。

この順番を省くと、制度への参加、ポリシー策定への関与、契約上の拘束という異なる関係が混ざる。ある文書について議論に参加できることは、その文書のどの部分が誰を拘束するかという問いへの回答ではない。また、あるポリシーに従う義務があるとしても、それだけで違反時に可能な措置の範囲まで決まるとは限らない。義務と措置には、それぞれ根拠の確認が必要になる。

具体的な資料の例が、ICANNのTransfer Policyのページである。レジストラの義務に関係するポリシー文書を調べる入口として有用だが、本稿では、この日付付きのページが現在の適用文書をすべて含むのか、後継の文書が適用されるのかを確認できていない。そのため、特定の待機期間、移管の条件、例外、期限を現在のルールとしてここに列挙することはしない。

それでも、この例は検証の仕方を明確にする。ドメインの移管に関する問題を考える場合、まず移管に関係するどの主体の義務が問題なのかを特定し、適用ポリシーと契約を対応させる。そのうえで、義務の履行を求める手続きと、その解釈や適用を争う手続きを分ける。ポリシーの題名に「移管」とあるだけでは、紛争中の継続性や別の事業者への切替えが保証されるわけではない。

ここから導けるのは、特定の移管が認められる、あるいは認められないという結論ではない。実務に影響するルールを説明するには、文書名から当事者の行動までの間を埋める必要があるということだ。制度を透明にするとは、文書へのリンクを増やすことだけでなく、その文書がどの関係に効くのかを説明できるようにすることでもある。

コンプライアンスの窓口は、権限の全体を証明しない

ICANNは、Contractual Complianceの説明資料とコンプライアンスの案内ページで、契約上の義務に関する苦情、監視、執行を扱う機能を説明している。その説明では、レジストリ契約、レジストラ認定契約、適用されるポリシーが関係する。

これはICANNによる自らの機能の説明である。本稿で参照できた資料からは、すべての契約について、具体的な是正期間、停止条件、終了条件、移行時の取扱いまでを確認できない。したがって、コンプライアンス部門の存在や案内ページだけを根拠に、特定の期限や措置を一般化することはできない。

実務では、苦情の提出、情報の確認、義務の履行を求める連絡、正式な措置を同じ段階として扱わないことが重要になる。これらを一括して「ICANNが決めた」と表現すると、何がすでに決まっていて、何がまだ確認中なのかが見えなくなる。通知の根拠と手続き上の位置付けが分からなければ、相手方が何に応答すべきかも定まらない。

同じ理由で、苦情を受け付ける仕組みがあることと、苦情を申し立てた人が望む措置を得られることは別である。ある義務の履行を求める申立てと、その義務の根拠や措置の適法性を争う申立ては、向いている方向が異なる。前者の窓口を見つけたことが、後者の救済経路を確保したことにはならない。

この区別は、ICANNの説明を一律に否定するものでもない。公開された案内は、制度を理解し、関連する文書を探すうえで役に立つ。ただし、その説明を個別の権限に結び付ける段階では、適用文書と当事者の関係を確認する必要がある。制度側の説明を出発点として使うことと、その説明だけで結論を出すことは違う。

権限を検証する側にも同じ規律が必要だ。契約上の措置があり得るという理由だけで、その措置が恣意的に使われたと推定することはできない。問題とすべきなのは、特定の措置について必要な根拠と手続きが示されているかであって、強い措置の名前が資料に登場すること自体ではない。

審査の名前ではなく、対象と効果から分ける

義務の根拠を争う際に、再検討請求、独立審査手続き（IRP）、契約上の仲裁を同じ「不服申立て」として束ねると、最も重要な違いを見落とすおそれがある。何を対象に、誰が、どの文書に基づいて、何を求められるのかは、経路ごとに確かめる必要がある。

ICANNの付属定款の公開ページは組織の説明責任や審査の仕組みを調べる入口であり、レジストリ契約の資料やレジストラ認定契約の資料は契約関係を調べる別の入口になる。ただし、本稿はこれらの現行条項から、特定の当事者の申立資格や利用できる手続きを確定したものではない。

そこで、審査経路の一覧を作る前に、争っている対象を記述する必要がある。問題は組織の意思決定手続きなのか。契約の解釈なのか。義務に違反したとする判断なのか。それとも、ある措置が実施されるまでの時間なのか。これらは一つの案件で重なる可能性があるが、重なることと同じ救済で処理できることは同じではない。

検討する経路 利用可能性を判断する前に確かめること
再検討請求を検討する場合 対象となる行為、申立資格、期限、判断主体、得られる結果
独立審査を検討する場合 審査対象、適用される付属定款・手続規則、暫定的な保護の条件と効果
契約上の仲裁を検討する場合 当該契約における対象紛争、当事者、申立方法、措置の実施との関係

この表は、三つの経路がどの案件でも利用できると示すものではない。利用できるかどうかを確かめる際に、制度名だけでは足りないことを示している。個別案件で申立資格や期限を判断するには、適用文書と専門的な法的検討が必要になる。

また、暫定的な保護を認める判断と、本案についての最終判断は区別しなければならない。仮に一定の措置が一時的に止められても、それだけで申立人の主張が最終的に認められたことにはならない。反対に、暫定的な保護を得られなかったことだけをもって、本案で主張に理由がないと結論付けることもできない。本稿は特定の暫定判断や本案判断を報告していないが、救済の効果を読む際にはこの区別が欠かせない。

未確認なのは「争っている間」に何が起きるか

ここで本稿の調査が答えを出せなかった問いがある。再検討請求、IRP、契約上の仲裁を始めることによって、争われている措置の実施は自動的に停止するのか。別の申請や判断が必要なのか。必要だとすれば、誰がどの基準で判断し、いつから何に対して効力が生じるのか。

参照できた公開資料の記録からは、これらを確定できない。特に、現在の付属定款やIRPの規則における暫定救済の正確な条件、個別契約に適用される停止や継続の条件は直接確認できていない。この限界から「自動的には止まらない」と断定することも、「申立てさえすれば止まる」と説明することも不適切である。

分析上は、少なくとも次の三つを分けて考えられる。ある条件を満たす申立てに停止効果が結び付く仕組み、別の申請に対して判断者が暫定的な保護を決める仕組み、その経路では求める保護を得られず別の根拠を検討する必要がある仕組みである。これは考え得る制度設計の整理であり、ICANNの現在の各手続きがどれに当たるかを認定するものではない。

実務に必要なのは、どれか一つをもっともらしく選ぶことではなく、適用文書によって該当する条件を確定することだ。申立てを受け付けたという確認、暫定的な保護を求めたという事実、保護を認める判断が出たという事実、判断に基づいて措置が止まったという事実は、それぞれ別の証拠を要する。

時間の比較も、最終判断が出るまでの日数だけでは足りない。運用に変化が生じる時点と、必要な保護が効き始める時点を比較する必要がある。後に主張が認められたとしても、その前に生じた変化を元に戻せるのか。元に戻すことと、その間の損失や第三者への影響を埋めることは同じなのか。こうした問いに答えなければ、手続きへのアクセスを運用上の保護と同一視することになる。

逆に、継続性を確保する条件が確認できれば、争うための選択肢は変わり得る。措置の停止、対象の限定、実施時期の調整など、何が認められるかは文書と判断によるが、いずれにしても「審査がある」という説明より具体的な情報が必要だ。制度の名称ではなく、保護の対象、開始時点、期間、条件、終了後の扱いを明らかにすることが重要になる。

運用上の依存は、立証する対象であって前提ではない

共通の記録や手続きに依存する関係では、形式上は異議を唱えられても、運用を維持するために決定を受け入れる方が容易になる可能性がある。ただし、それは検証すべき仕組み上の可能性であり、本稿がICANNによる不当な圧力や、特定事業者の選択肢の喪失を確認したという意味ではない。

依存を評価するには、何が続かなければ事業が成り立たないのかを具体化する必要がある。どの記録、手続き、契約関係が問題となるのか。それに変更が生じた場合、代替手段はあるのか。代替できるとして、同じ機能を必要な時間内に維持できるのか。単に別の事業者が存在するという事実だけでは、同じ条件での継続性は証明されない。

他方、ある契約関係を離れるのが難しいという主張も、根拠なしには採用できない。実際の制約が技術的なものなのか、契約上のものなのか、費用や準備時間に由来するのかを分ける必要がある。異議を唱える費用が高いことと、法的に争えないことも異なる。制約を一括して「出口がない」と描くと、可能な改善策まで見えなくなる。

救済の評価では、措置を受ける事業者だけでなく、その運用に依存する利用者や相手方への影響も問うべきだ。ただし、本稿には、そうした影響を数量化できる個別案件の記録はない。顧客数、損失額、審理期間、救済の成功率を示すことはできず、一般的な文書の所在からそれらを推計することもしない。

同じく、措置を遅らせることが常に望ましいとも限らない。仮に義務違反の継続が別の当事者に不利益を与えるなら、継続性の確保と是正の必要性を同時に検討する必要がある。重要なのは、どちらかの組織への信頼だけで答えを決めるのではなく、措置の根拠、保護する利益、期間、範囲を検証できるようにすることである。

確認できる文書の経路と、まだ測れない救済の効果

ICANNの公開資料には、付属定款、契約、コンセンサスポリシー、コンプライアンスを調べる別々の入口がある。これらを一つの包括的な命令権として扱うより、各文書がどの当事者のどの義務に関係するかをたどる方が、権限の範囲を正確に問える。

一方、本稿の調査では、個別の現行契約、適用される改定、審査の停止効果、暫定救済の条件までは確定できなかった。したがって、説明責任が十分に機能しているとも、救済が実質的に存在しないとも評価できない。文書の所在を示すことと、救済の実効性を実証することの間には、なお確認すべき事実がある。

それでも、検証の焦点は明確になる。義務を求める側には、その根拠と適用関係を説明できることが必要だ。争う側には、利用できる経路だけでなく、必要な保護がいつ、どの範囲で効くのかを確かめる作業が必要になる。異議を申し立てる機会があることは重要だが、それだけで争っている間の運用が守られると評価してはならない。停止効果が未確認であることも、保護が存在しない証拠にはならない。

ICANNの権限と説明責任を検証するうえでの核心は、この二つの早合点を避けることにある。文書から義務へ、義務から措置へ、措置から審査へ。その各接続を立証し、最後に時間の中でどの保護が働くかを確かめてこそ、形式的な審査と実務上の選択肢の関係を評価できる。