要約

  • ICANNは9月3日、Universal Acceptance Expert Working Groupの共同議長が8月28日付で送った書簡を公開した。書簡によると、意見募集後に更新した最終文書はグループ内の合意を得て、ICANNのCEOに検討用として提出された。
  • 変更例として、UAの普及にAI技術を活用することが挙げられた。実施の優先順位と、認知、政策支援、実装、能力開発を追う測定枠組みも含むという。
  • 公開意見では、AIは不具合の発見や修正を助ける道具である一方、コード支援、メールセキュリティ、アドレス解析、音声サービスなど、それ自体を試験すべきシステムでもある。
  • 各主張を役割、版、試験対象、権限者、分母、結果段階に結び付ければ、生成量を利用者の成功と取り違えずに済む。

合格を出す側と、合格を求められる側

AIにテストケースを作らせ、古いASCII限定の検証処理を発見させる。これは有用な作業だ。だが、そのAIが作った修正案は、保守担当者のレビューも、本番への投入も、国際化された識別子を使う一連の操作の成功も証明しない。

逆向きの場面もある。AIを使う迷惑メール判定がEAIの確認メールを止める。音声アシスタントが非ラテン文字のドメインを別の文字列として扱う。コード生成支援が古い正規表現を再び持ち込む。この場合、AIは検査者ではなく検査対象の一部である。

この二面性は、ICANNの書簡一覧に加わった新しい記録から現実の運用課題になった。Edmon ChungとSarmad Hussainは8月28日付の書簡で、2026年2月から4月の公開意見を検討し、指針を更新し、メンバーの合意を得た最終文書をICANNのKurt Erik Lindqvist CEOに提出したと報告した。

共同議長が変更例として明示したのは、UA普及にAI技術を活用することだ。最終文書には、実施の優先順位と、認知、政策支援、実装、能力開発の進捗を測る枠組みもあるという。だからこそ、AIという一語を一つの進捗欄に押し込めると、測定の向きが消えてしまう。

公開されたのは提出の事実である

書簡は、ICANNが指針を採択したとは述べていない。専門家グループが自らの成果物について合意し、ICANNの検討に付したという段階だ。実現可能性の評価、優先順位、予算、担当、実行は別の判断である。さらに各事業者は、自社のアプリケーション、メール基盤、DNS関連システムを動かす権限を保持する。

確認できる公開文書にも限界がある。終了済みの意見募集ページは2月版を「意見を求める提案」として掲載し、ICANNが今後グループと最終化して公開すると記している。書簡一覧から開けるのは一ページの送付状で、UA関連のお知らせ一覧にも確認時点で最終文書へのリンクはなかった。

これは文書が存在しないという証明ではない。内部作業がないとも言えない。ただし、最終的な条文や番号を送付状から推測してはならない。AI活用が更新例であることは共同議長に帰属させ、AIの具体的な二役は公開意見の記録に帰属させるのが正確だ。

UAは途中の成功を最終結果にしない

2月の草案は、UA対応を六つの動作で説明する。適用される標準に従い、すべての有効なドメイン名とメールアドレスを受け入れ、検証し、保存し、処理し、表示し、相互運用できることだ。IDNとEAIも含まれる。

入力欄の通過は、データベースの保存を保証しない。保存できても認証やアカウント回復が失敗し得る。送信サーバーが受けてもフィルターが止めることがある。表示は書字方向や混在文字列で別の試験を要する。個別部品の結果が語れるのは、その版、その試験、その範囲までである。

草案が認知、政策支援、実装、能力開発を分けた理由も同じだ。イベントや広報は認知への投入であり、調達要件は制度的需要を作る。研修は能力を増やし、利用者が登録からメール受信まで完了することは運用上の結果である。それぞれに価値はあるが、同じ単位ではない。

もし一枚のダッシュボードが、研修人数、AIが走査したリポジトリ数、生成した修正数、導入数、利用者の成功数を足し合わせれば、安く大量に作れる活動が最後の障害を覆い隠す。

37件の意見に表れた二方向

公開意見の要約報告は37件の提出を整理している。AI支援開発、コード支援企業との連携、自動検出、大規模試験、開発工程へのチェック導入などが提案された。ここでAIは、発見や修正の費用を下げる手段だ。

同じ報告には、AIシステムを独立した関係者の区分として扱う提案もある。大規模言語モデル、AI型メールセキュリティ、コード生成、ドメイン名やメールの解析、迷惑メール対策、音声アシスタント、学習データの工程、診断ツールが例示された。こちらでは、AIの判断が利用者の識別子の成否を左右するため、試験の対象になる。

ISPCPの提出意見は、AI固有の指標、段階的な実施、期限付きの目標、統治の仕組みを求めた。これは意見であって、採択済みのICANN方針や契約上の義務ではない。それでも、一つのAI指標では因果関係を追えないことをよく示している。

二面の役割表を作る

Daniel Kadeが提案する最小の記録は、AI/UAの役割と証拠を二面に分けた表だ。最初に、AIが診断手段、提案生成、意思決定支援、被験部品、自動運用者のどれであったかを書く。複数なら、関係を示した別々の行にする。

次に権限者を記録する。道具と試験集合を選んだのは誰か。出力を確認し、コードを統合し、導入し、停止し、元に戻せるのは誰か。モデル提供者とシステム運用者の権限を混ぜてはならない。

対象の状態も必要だ。分かる範囲のモデルまたはサービス版、試験仕様、生成物や診断、リポジトリのリビジョン、ビルド、依存関係、実行時刻を結ぶ。モデルや検証ライブラリが変われば、再試験するか、以前の結果を比較できる理由を示す。

UAの機能欄には、入力、検証、保存、処理、表示、認証、回復、メール配送、相互運用のどれを調べたかを書く。コーパス欄には、文字体系、言語、有効・無効の例、長さ、右書きと双方向、ドメインの組合せ、経路、抽出方法、除外を載せる。

結果は、警告、修正案、人が確認したコード、許可された導入、部品の観測結果、利用者の一連の成功に分類する。分子と分母、失敗、誤検出、見逃し、訂正先、再試験日を伴わない「合格」は置かない。

企業秘密や個人データを公開する必要はない。生成物は導入権限ではなく、導入は全体適合ではなく、部品適合は利用者結果ではない。この三つを読めるだけで、AIの有用性を誇張せずに評価できる。

情報源

  1. ICANNの書簡一覧
  2. UA専門家グループ共同議長の書簡、2026年8月28日
  3. UA指針案の公開意見募集
  4. Universal Acceptance普及指針案
  5. 公開意見の要約報告
  6. ISPCPの提出意見
  7. UA専門家グループ憲章
  8. ICANNのUA関連告知一覧