要約

  • 優先番号が後ろだからといって、その申請文字列が比較対象から外れるわけではない。2026年ラウンドでは、評価バッチを設定する前に、すべての申請文字列について類似性評価を完了しなければならない。
  • 視覚的に似た二つのトップレベルドメイン文字列が申請された場面を考えてみよう。一方には早い優先番号が、もう一方にはかなり遅い番号が割り当てられたとする。最初のグループだけを切り離して評価すれば、両者の関係が判明する時点では、すでに最初のバッチが確定しているかもしれない。

視覚的に似た二つのトップレベルドメイン文字列が申請された場面を考えてみよう。一方には早い優先番号が、もう一方にはかなり遅い番号が割り当てられたとする。最初のグループだけを切り離して評価すれば、両者の関係が判明する時点では、すでに最初のバッチが確定しているかもしれない。

2026年ラウンドのApplicant Guidebookは、この順序上の欠陥を防いでいる。セクション7.10.2.2によれば、バッチ処理が必要な場合、評価優先バッチを設定する前に、全申請文字列のString Similarity Evaluationを完了する。さらに、複数の申請が同じ競合セットに含まれる場合、そのセット内で最も優先度の高い文字列に従い、すべてを同じバッチに入れる。

これは単なる日程管理の規則ではない。優先順位は作業を並べるためのものであり、パネルが見るべき比較範囲を区切るものではない、という統治上の役割を担っている。

全体を比較してから、処理順を決める

現在の正式な英語版GuidebookはV2-2026.04.24である。Module 1は、文字列類似性評価を、申請文字列とその割当可能なバリアント文字列を対象とするString Evaluationの一部に位置付ける。また、String Evaluationの五つの要素は並行して評価され、申請および申請者の評価とは異なり、優先順位には従わないと明記している。

Module 7は比較対象を具体化する。各申請のプライマリ文字列と該当するバリアント文字列は、既存の委任済みgTLD、過去ラウンドから処理中の文字列、規定対象となるccTLDやIDN ccTLD申請、現ラウンドの他の申請文字列、一部のBlocked Names、その他の2文字ASCII文字列などと比較される。割当可能なバリアントとブロック対象のバリアントも、Guidebookの詳細な条件に従って評価範囲に入る。

バッチ設定前に全申請文字列を評価する必要があるのは、この比較対象に「同じラウンドの他の申請」が含まれるからだ。ある文字列の評価は、優先番号が大きく離れた別の申請に左右され得る。先に全体比較を終えることで、運用上のキューが、パネルに必要な比較範囲を途中で分断することを防げる。

ここでいう「比較範囲の完全性」は、規則の設計を説明するための編集上の解釈であり、ICANNがそのまま示した公式の理由ではない。ICANNが明示する目的は、視覚的に類似した文字列の委任によって生じ得る利用者の混乱とDNSへの信頼低下を防ぐことである。