要約

  • 取材時点のICANN Public Comment一覧では、IRP-IOT手続は提出9件、報告期限2026年9月1日の「報告待ち」とされ、個別ページのOutcome欄は空だった。
  • ICANN BylawsはIRPの主要作業言語を英語としつつ、必要な申立人への翻訳サービスを求めている。
  • 2018年の暫定Rule 5Bは、英語で翻訳支援を申請すること自体が過重な場合、その申請だけは別言語で提出できる。
  • 提案文は、紛争申立書と翻訳サービス申請の双方を英語で出すよう定める。
  • ただし提案には、緊急判断、ICANN負担、期限調整、必要な場合の非国連公用語といった明確な改善もある。
  • 多言語の予備受付票を設ければ、英語という作業言語やPanelの判断権を変えずに、最初のアクセスだけを守れる。

報告予定日は採択日ではない

Independent Review Processは、ICANNの対象行為がArticles of IncorporationやBylawsに反したという紛争を、外部の立場から審査する仕組みである。Bylawsはそれを意味があり、費用面で利用可能で、アクセスできる専門審査と位置づける。同時に、手続は英語を主要作業言語として運営される。

IRP Implementation Oversight Teamは2024年、Panel選任、申立期限、翻訳、第三者参加などの改定案を意見募集に付した。公開提出は9件ある。本稿の基準時点では総合一覧に9月1日の報告期限が表示されていたが、個別手続の結論は掲載されていなかった。

したがって、案文を現行ルールとして扱うことも、期限から報告内容を先読みすることもできない。いま比較できるのは、2018年の暫定文と提案文が最初の言語障壁をどう扱うかである。

現行文は「支援を求める一文」だけを例外にする

暫定Rule 5Bは、IRP全体を申立人の希望言語にする制度ではない。翻訳の必要性、対象文書や審理、使用言語はPanelが決める。必要性が認められなければ資料は英語で提出する。対象言語も原則として、英語と、アラビア語、中国語、フランス語、ロシア語、スペイン語に限られる。

それでも、支援を求める申請については明示的な例外がある。英語でその申請を出すことが過重な負担だと申立人が証明すれば、申請自体は英語でなくてよい。

この例外は翻訳を認める決定ではない。紛争の受理、当事者適格、期限停止、費用負担も自動的には生じない。言語障壁の存在を、言語障壁を先に解消しなくても判断者へ届けられるだけだ。

小さな但し書きだが、制度への入口としては大きい。

提案は認定後のサービスを大きく改善する

提案中のRule 5Bは、何を翻訳できるかを具体化する。申立書、重要文書、速記録、Panel判断、口頭手続の通訳が含まれる。最初の申立書を英語にする費用の償還や、ICANNの答弁を希望言語にすることも申請できる。申立書と同時に出した翻訳申請は、本体のページ数に数えない。

Panelがまだ構成されていない緊急時には、Emergency Panelistが先に判断できる。命じられたサービスはICANNの言語事業者を通じて調整され、後の別命令がない限り行政費用としてICANNが負担する。翻訳で合理的な遅れが出れば、提出や上訴の期限も調整できる。

対象言語も広がる。公平に参加できる国連公用語があれば可能な限りそれを使う一方、それ以外の言語でなければ公平な参加ができない場合は排除しない。この点は、グローバル機関の紛争手続として重要な前進である。

しかし支援の前に、英語を二度用意する

案文は、書面のStatement of Disputeを英語で提出するよう要求する。さらに翻訳サービスの申請も英語とし、希望言語、必要な理由、本人や代理人の言語能力を説明し、5ページの範囲に収めるよう求める。

英語で提出できたことを理由に「翻訳は不要」と推定してはならない、という保護も置かれている。自費で弁護士や翻訳者を確保した申立人にとっては重要である。

ただし、最初の橋を買えない人には届かない。英語で支援を申請できる状態になって初めて、英語支援の必要性を評価してもらえるからだ。公的な支援が始まる前の費用と能力が、実質的な選別条件になる。

Non-Commercial Stakeholder Groupは別の角度から同じ入口を問題にした。Rule 5Bを支持しつつ、申請しなければ動かない仕組みでは、権利を知らない非英語話者に負担がかかるとして、開始時の積極的な案内と提供を求めた。

これはICANNの認定でも、コミュニティ全体の合意でもない。案文によって具体的な申立人が排除されたという公開証拠も確認されていない。むしろ問題は、正式申請の前に諦めた人は却下決定にも統計にも現れないことだ。

予備受付と正式な紛争申立てを分ける

すべての資料を自動翻訳する必要はない。費用は大きく、Bylawsの「必要性」に基づく設計からも離れる。また、どの言語でも短い連絡を送れば正式申立てが完成し、全期限が止まるという扱いも危険である。

必要なのは薄い受付層だ。ICANNまたはICDRが識別できる言語で、短い支援要請を受け取る。受付時刻と中立的な番号を付し、可能なら同じ言語で返答する。返答には、受領したもの、まだ申立てになっていないもの、進行中の期限、暫定保護の有無、必要性を判断する者を明記する。

原文は、認証済みまたは事業者作成の英語版と並べて保存する。翻訳に異議が出たら、訂正を履歴として追加し、元の表現を消さない。緊急経路、ICANNの合意、Panelの命令も別々の状態として記録する。

公開するのは集計で足りる。申請言語、合意・承認・拒否、応答時間、英語版完成までの時間、期限変更、費用を個人情報なしで示せる。ある言語の申請がゼロなら、需要がゼロと断定せず、案内と入口を検証するきっかけにする。

Heng Luが区別する参加と権限の観点でも、この受付は限定的である。要請を受け取ることは、送信者の主張を認めることでも、ICANNを拘束することでもない。言語の窓口ではなく、正規の判断者に判断を委ねるための経路である。

後段の拡張と入口の後退を交換しない

新旧のどちらが一律に優れているか、という比較ではない。提案文は費用、緊急性、期限、言語範囲を改善する。暫定文は「支援を求める最初の行為」について、より合理的な順序を残している。

予備受付票を残しても、英語の主要作業言語は変わらない。翻訳の必要性、範囲、言語をPanelが決める構造も変わらない。申立人の適格や主張の正しさも推定しない。

変えるのは順番だけだ。障壁を記録し、支援を判断し、その後に英語の正式記録を整える。障壁を説明する前に障壁を自力で越えさせる仕組みは、アクセス制度として自己矛盾を抱える。現行Rule 5Bにある小さな例外を、次の版では見える入口として育てるべきだ。

出典

  1. ICANN Public Comment一覧
  2. IRP-IOT補充手続改定の意見募集
  3. 提案規則のクリーン版
  4. 理由付き対照版
  5. 2018年暫定補充手続
  6. NCSGの提出意見
  7. ICANN Bylaws Article 4.3
  8. Heng Lu, The Multi-Stakeholder Mirage