要約

  • ICANN理事会は9月6日、2026年新gTLDラウンドに必要なシステム開発と支援の契約を承認した。9日に公表された決議は、機能開発、迅速なインシデント対応、安定性、重要業務を挙げる一方、ベンダー、金額、理由の相当部分を伏せている。
  • 5月3日の先行決議は、申請受付開始から当時10月30日と見込まれたString Confirmationまでを6か月の強化オンコール期間とし、その後は通常業務時間へ縮小する見通しを示していた。
  • 二つの決議が同じ契約、範囲、供給者を指すとは確認できない。ただし、5月に示した時間的な境界の結果を検証する必要は確認できる。
  • 公開する終了テストは、機能ごとの通常体制、ICANN内部の受入責任者、移管の証拠、残る例外、判断日、次回レビューを記せばよい。機密の交渉条件や運用手順は要らない。

「支援が必要」から「いつ平時に戻すか」へ

9月6日の承認決議は、President and CEOまたはその指名者に、2026年ラウンド向けシステム開発・支援契約の締結と支出を認めた。公開部分には、十分なシステム機能、適時のインシデント対応、安定運用、重要な業務プロセスという目的が並ぶ。財政上の影響はFY27予算と将来予算に織り込み済みだという。

しかし、対象サービス、支援時間、重大度の区分、期間、金額、供給者は分からない。背景説明の一部も交渉上の機密として削除された。理事会はこの行為を、公開コメントを要しない組織上の管理機能と位置付けた。

非公開部分があることは、失敗の証拠ではない。契約交渉やセキュリティに関わる情報を守るのは当然であり、申請受付後にも専門的な支援が必要になり得る。9月の意味は、5月3日に公表された決議との比較から生まれる。

5月の理事会は、強化オンコールモデルの契約延長を承認した。公開理由は、4月30日の申請受付開始から、当時10月30日を見込んでいたString Confirmationまでの6か月を、需要と複雑性が高い期間と定義した。通常時間外の支援によってインシデントへ速やかに対応し、期間終了後は支援チームを縮小して通常業務時間に戻すとの見通しも書いた。

これは厳密なサービス保証ではない。それでも、特別体制の理由、期間、想定される終了状態を示した公開基準である。9月の決議を受けて問うべきなのは、契約が存在するかではなく、どの証拠に基づき各機能を平時へ戻すか、例外を誰が承認するかである。

二つの契約を同一視してはいけない。5月の説明では、当時の事業者は2023年10月のRFPで選定され、RSPとASPのシステムを提供し、TAMS開発も進めたとされる。9月の文書は、同一事業者、同一契約、同一範囲だとは述べていない。終了テストはベンダー名ではなく、ICANNが引き受ける機能単位で設計すべきである。

受付終了後に、処理の本番が続く

申請受付は8月12日に終了した。ICANNは1,600件を超える主申請を受け取り、そのうち1,100件超に代替文字列の申請が付いていたと発表した。この数はアクセス件数でも、チケット数でも、インシデント数でもない。オンコール要員の必要量を直接算定できる数字ではない。

一方、申請の後に大きな処理が残ることは分かる。Applicant Journeyには、管理審査、Reveal Day、コミュニティ意見、異議・上訴、文字列評価、申請者・申請内容の評価、競合解決、契約、オンボーディング、委任までが続く。窓口が閉まると、システムの仕事は終わるのではなく性質を変える。

ICANN85前の進捗報告も段階差を示す。2月時点でTAMS build 5とユーザー受入試験が終わり、エンドツーエンド統合試験が始まっていた。一方、build 6、7、8は、その後の評価や契約に必要な機能を完成させる計画だった。組織面でも、プログラム統治、インフラ開発、業務化、職員・ベンダーの準備、財務・調達・法務支援は別の作業として整理されている。

したがって、単一の日付で全機能を一斉に通常化するのが正しいとは限らない。申請受付は安定しても、評価機能は開発中かもしれない。ある業務は内部へ移管できても、別の業務は期間限定の夜間対応を必要とするかもしれない。安全な縮小には機能別の判定がいる。

終了テストは一枚でつくれる

決議番号と評価日を付した短い表でよい。ICANNが正確な区分を選び、申請処理、支払い・管理確認、評価ワークフロー、公開、契約などの大分類ごとに、次の六項目を記録する。

  1. 特別に追加した支援は何で、通常時の基準は何か。
  2. サービスを受け入れ、縮小・継続・再設計を決めるICANN内部の役割は誰か。
  3. 復旧試験、未解決不具合、作業量予測、手順移管、定義済みの当番データなど、どの証拠区分を見たか。
  4. 平常運用へ移った機能と、その発効日はいつか。
  5. 残る例外の理由、責任者、再検討日は何か。
  6. 次に公表する判断点はいつか。

終了テストは契約終了命令ではない。「通常時間で十分」「特定機能だけ一定期間延長」「内部移管は完了したが特定リリース時に専門支援を待機」「平時の基準そのものを変更」といった結論があり得る。大事なのは、継続が慣性ではなく判断になることだ。

数字にも仕様が要る。年間平均の可用性は、期限直前の重要時間帯を隠すことがある。チケット件数は、問い合わせ、不具合、インシデント、予定変更を混ぜれば意味を失う。測定単位と期間を先に示さなければ、精密に見える数値も移行判断の証拠にならない。

公開できる状態と、守るべき詳細

ICANNのDocumentary Information Disclosure Policyは、保有文書を原則公開としつつ、商業上の利益を害する情報などに非開示理由を認めている。Board資料のPublication Practicesも、決議、速報、議事録をBylawsに基づいて公開しながら、一定の事項を除外できる仕組みを説明する。

この境界なら、価格、供給者の機密、認証情報、脆弱性、個人の勤務表、リアルタイムの対応経路を伏せたまま、移行結果を示せる。「評価機能は日付付きレビューまで強化体制を継続する」という状態情報は、攻撃手順でも交渉資料でもない。

Contracting and Disbursement Policyでは、75万ドルを超える義務に理事会承認が必要で、CFOは重要な支出を定期報告する。9月の金額が非公開である以上、その閾値から額を推測してはならない。そして財務承認が適切でも、臨時支援を平時へ移せるかは別に確認する必要がある。

分かっていないこと

公開資料は、障害、対応目標の未達、侵害、品質不良、予算超過、ベンダーロックイン、移管失敗を報告していない。申請件数はシステム負荷を示さない。9月契約がTAMS、RSP、ASPだけを対象とするとも書かれていない。

9月の契約は予定された開発、別の段階、別の範囲、あるいは適切に管理された移行の一部かもしれない。5月の縮小見通しを撤回した証拠ではない。だからこそ、伏せ字を推測するのではなく、境界を越えた時の結果を公開する価値がある。

出典

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — 2026年9月6日理事会承認決議
  5. ICANN — 2026年5月3日理事会承認決議
  6. ICANN — ICANN85向け2026年ラウンド進捗報告
  7. ICANN — 2026年ラウンド、1,600件超の申請で受付終了
  8. New gTLD Program — 2026 Round Applicant Journey
  9. ICANN — Documentary Information Disclosure Policy
  10. ICANN — Publication Practices
  11. ICANN — Contracting and Disbursement Policy