1

ドメイン名の競争環境整備に関する動向

97

98

1 ドメイン名の競争環境整備に関する動向
1-1 スポンサ付きトップレベルドメイン(sTLD)の導入の状況
スポンサ付き gTLD(sTLD)の導入は 2002 年 12 月の ICANN アムステルダム会議で承認され、導入プロセスが開始された。その後、選定のための基準策定、申請に関する詳細事項の作成、提案依頼書の作成等の作業を経て、2003 年 12 月に募集が開始された。
この募集に対して 10 組織が応募を行い、順次 ICANN による評価選定作業が進められている。2007 年 3 月現在、ICANN との交渉が継続しているのは.post に関するもののみであり、
他 TLD については選定・評価が済んでいる。以下に申請された sTLD との選定・評価状況を示す。

選定・評価状況

申請 TLD
.asia
.cat

申請組織

用途

DotAsia Organization

アジア太平洋地域の企業、個Limited

人、団体専用Associacio puntCAT

カタロニア地域の言語、文化
コミュニティ用

最終承認済み.jobs

Employ Media LLC

人事管理業務関係者用.mobi

Nokia/Vodafone/Microsoft

モバイル機器、サービス用等.tel

TELNIC

個人または企業の連絡先表
示、ナビゲーション用.travelTralliance Corporation

旅行関連業界用

業務・技術面での .post

Universal Postal Union

郵便事業関係者用

交渉段階

(UPU)

却下

.tel

NetNumber, Inc,

IP ベースの電話番号用.mail

The Anti-spam Community

スパムフリー電子メールの送

Registry

受信者用

ICM Registry, LLC (ICM)

アダルトサイト用.xxx

次々に新しいスポンサ付き gTLD の導入が決定された 2005 年とは異なり、2006 年はそれほど大きな動きはなかった。しかしながら、2007 年に入り、3 月のリスボン会議で 3 年にわたって交渉が続けられ、またアダルトコンテンツを対象とする点で注目を集めていた.xxxの申請が却下されたことは、コミュニティにインパクトを与えた。以下では、申請 TLD 毎に 2008 年 2 月までの動きを概観する。

99

.asia2005 年 12 月の ICANN バンクーバー会議において、業務面・技術面の交渉段階へ入ることが ICANN 理事会によって承認された後、契約書内容の交渉を経て、2006 年 10月 18 日の ICANN 理事会において本申請が最終承認された。その後 ICANN サンパウ
ロ会議期間中の 2006 年 12 月 6 日に正式契約が締結され、2007 年 5 月に本 sTLD がルートゾーンに追加され、運用が開始された。
登録スケジュールについては、2007 年 10 月 9 日からの段階的な優先登録期間（政府向け、登録済み商標権者向け、企業名や事業名の権利保持者向け）を設けただけではなく、ドメイン名の活用案募集に対する優れた提案者には、対象ドメイン名を優先的に登録できる権利を付与する.Asia Pioneer Domains Program27や、登録意欲の一番高い者に登録してもらうためのオークションの実施など、新たな取り組みにも挑戦している。先願制での登録は、2008 年 3 月以降となる。
.cat
本申請は 2005 年 9 月に ICANN 理事会によって最終承認された。その後 2005 年 10月に ICANN と申請者との間で正式契約を締結し、2005 年 12 月に本 sTLD がルートゾーンに追加され、運用が開始された。2006 年 4 月 23 日からは一般登録が開始され、現在に至っている。
.jobs
本申請は 2005 年 4 月の ICANN マルデルプラタ会議での ICANN 理事会で最終承認された。2005 年 5 月には ICANN と申請者との間で正式契約を締結し、2005 年 9 月には本 sTLD がルートゾーンに追加され、運用が開始された。2005 年 9 月 9 日から一般登録が開始され、現在に至っている。
.mobi
本申請は 2005 年 6 月の ICANN 理事会によって最終承認を受けた。2005 年 7 月にはICANN と申請者との間で正式契約を締結し、2005 年 10 月には本 sTLD がルートゾー
ンに追加され、運用が開始された。2006 年 9 月 26 日から一般登録が開始され、現在に至っている。
.travel
本申請は 2005 年 4 月の ICANN マルデルプラタ会議での ICANN 理事会において最終承認を受けた。その後 2005 年 7 月には正式契約が締結され、同月に本 sTLD がルート
27 http://pioneer.domains.asia/100

ゾーンに追加され、運用が開始された。2006 年 1 月 2 日からは一般登録が開始され、現在に至っている。
.tel (TELNIC)
2005 年 6 月の ICANN 理事会において業務面・技術面の交渉段階へ入ることが承認された後、契約書内容の交渉を経て、2006 年 5 月 10 日の ICANN 理事会において本申請が最終承認された。その後 2006 年 5 月 30 日に正式契約を締結し、2007 年 3 月に本sTLD がルートゾーンに追加され、運用が開始された。
.post
本申請は 2004 年 7 月に業務面・技術面の交渉段階へ入ることが承認されており、2007
年 1 月 4 日には、2007 年 6 月 30 日までに交渉を完了することを目標に作業を進めているとICANNよりアナウンス28されたが、現在まで交渉はまとまっていない。2007 年
9 月 6 日には、UPUからの書簡が掲示29され、そこにはUPUのビジネスモデルや希望する契約上の取り決め等が記されており、10 月 6 日まで意見募集も行われた。2008 年
1 月 23 日の理事会議事録において、ICANNとUPUとの交渉は継続しており、ニューデリー会議にて理事会に対し更なる情報を寄せると記されている。現在も交渉が継続しているものと推測される。
.xxx
本申請は、ICM から 2004 年 3 月に提出されたが、アダルトコンテンツを対象とした
sTLD 申請のため、各方面から承認に慎重論が出て作業が遅れ、2005 年 6 月の ICANN
理事会でようやく業務面・技術面の交渉段階へ入ることが承認された。
2005 年 8 月 9 日に最初の契約書案が公開されると、すぐさま 8 月 12 日には ICANN
政府諮問委員会(GAC)のチェアより、GAC を代表して.xxx に対する懸念が寄せられた。
また、懸念を示す多くのパブリックコメントも寄せられ、2005 年 9 月 15 日の理事会
では、法令順守に関する問題点などを理由に不承認とした。
その後の契約書内容の交渉を経て、修正契約書案が 2006 年 4 月 18 日に公開され、2006
年 5 月 10 日のICANN理事会に提出された。しかし同理事会は、本契約案を再び不承認としている。この不承認に対して、ICMは 5 月 19 日に再考を求める文書30を提出しているが、10 月 29 日にはその要求を取り下げている。

28 http://www.icann.org/announcements/announcement-04jan07.htm
29 http://www.icann.org/announcements/announcement-2-06sep07.htm

30 http://www.icann.org/committees/reconsideration/icm-06-4/petition-20may06.pdf

101

ICANN と申請者との間で再交渉に入り、修正契約案は 2007 年 1 月 5 日に再度パブリックコメントへ付され、3 度目の審議に持ち込まれた。3 月 9 日まで行われたパブリッ
クコメント期間では、かなりの数のコメントが寄せられた。ICANN のウェブサイトによれば、これまでに.xxx について寄せられたコメントや文書類は 9 万件を超え、アーカイブを提供できないほどの数となっている。コメントは賛否両論を含んでいたが、アダルトコンテンツは各国の法律により捉え方が異なるため.xxx の導入に懸念を示すとする GAC の公式声明に代表されるように、.xxx に寄せられたコメントは実質的には否定的な内容が多数であったと言える。このような状況下、3 月 30 日の理事会で修正契約案が審議された。審議の結果、申請内容が GAC の懸念を払拭できるものとはなっておらず、また ICANN が.xxx を承認するということは、.xxx への掲載に適するか否かといったコンテンツに関する判断を伴うことにもなり、ICANN が負っている技術的な役割を超えることを理由に、ICANN 理事会は修正契約案のみならず、ICM による申請そのものも却下することを決議した。
.tel (NetNumber, Inc.)
本申請は、2004 年 11 月に評価基準に達しないとの判断がされ、却下となっている。
.mail
本申請は、2005 年 7 月に評価基準に達しないとの判断がされ、却下となっている。
2003 年 12 月に始まった sTLD 募集のプロセスは、.post の申請 1 つを残すのみとなった。
2007 年 6 月 30 日という期限設定がされたことによって、交渉が促されることが見込まれたが、現時点でも終了しておらず、今後の見通しも不明瞭である。
今回の sTLD 募集のプロセスは、開始から既に 4 年以上が経過しており、承認プロセスでは常に「進みが遅い」との批判がつきまとってきた。目下進行中の新 gTLD 募集のプロセ
スでは、sTLD 承認プロセスでの教訓を活かすことが期待されている。

1-2 新 gTLD の導入に関する議論の動向
ICANN では 2003 年 12 月以降、順次スポンサ付き新 gTLD(sTLD)の導入が進んでいる。
新しい gTLD を順次導入してその数を増やすことは、ICANN が設立された当初から
ICANN に課せられた責務であり、そのプロセスの第一弾としてまず 2000 年 11 月に 7 つの新 gTLD(.info / .biz / .name / .pro / .aero / .coop / .museum)を導入することが決定された。

102

当初はこれらの gTLD の導入状況を評価、検証して、その後に続く gTLD をどのように導入していくかを検討していく予定であった。しかし、折しも ICANN 改革についての議論が沸騰していたこともあり、これら新 gTLD の評価が遅々として進まない状況となった。そこで 2002 年 11 月に、まずは規模が比較的程度小さいと思われるスポンサ付き新 gTLD の導入を先に進めようという提案が当時の ICANN 事務総長であった Stuart Lynn 氏からなされ、2002 年 12 月の理事会でその進め方が承認されたものである。
このように、当初は新gTLDの導入を目指して始まった議論は、sTLDの導入に関する議論と、今後新たなgTLDをどのようなポリシーに基づいて選定、導入していくのかという議論とに分化した。前者に関しては既に進捗を報告したのでそちらを参照されたい。後者の議論に関しては、2004 年 9 月 30 日に「戦略：新たな分野別トップレベルドメインの導入」という報告書が発表31され、ポリシー策定のための手順が提示された。それ以降、新gTLDの導入の手続き等に関する議論が深まってきており、2005 年には新gTLDに関する課題報
告書の公開32、評価依頼事項の公開33と矢継ぎ早に新gTLD導入に関する議論が進み、2006
年 2 月にはICANNのGNSOから新gTLDの導入に関してそれまでの検討をまとめた初回レ
ポート34が提出された。その後は、2006 年 2 月に初回レポートドラフト、2006 年 7 月に初回レポート、2006 年 9 月に勧告のドラフト、2007 年 2 月に勧告のドラフトを元にした最終レポートドラフトが提出されるにつれ、評価委任事項に沿った検討が深化し、新gTLD導入に関する条件が明確になっていった。続いて、評議会メンバーの議論等を反映させた最終レポートドラフトが 2007 年 3 月、2007 年 6 月と再度提出され、GNSO評議会におけるこれまでの議論の集大成として、2007 年 8 月に最終報告書が提出されるまでに至った。ここでは、各段階における議論の内容を評価委任事項の検討内容を中心に振り返りつつ、2008
年 2 月までの動きについて報告する。
新 gTLD 導入に関する GNSO の初回レポートドラフトを公開（2006 年 2 月）
2006 年 2 月 19 日に、GNSO は新 gTLD 導入に関する初回レポートのドラフトを公開した。
本ドラフトの結論は概ね以下の通りである。
新 gTLD の導入は、その頻度や条件に関しては実に幅広い意見があったにも関わらず、導入自体に反対する意見は無かった。ほとんどの意見は、gTLD の創設はICANN の義務だとするものであった。
一方、新 gTLD をいくつ、どのような頻度で創設するか、スポンサ付きとするの
31 http://www.icann.org/tlds/new-gtld-strategy.pdf

32 http://gnso.icann.org/issues/new-gtlds/gnso-issues-rpt-gtlds-05dec05.pdf
33 http://www.icann.org/announcements/announcement-06dec05.htm#TOR
34 http://icann.org/topics/gnso-initial-rpt-new-gtlds-19feb06.pdf

103

かしないのか、またどのような文字列が割り振られるべきかについては合意が無かった。
レジストリ運用にあたり、標準化された契約条件を契約前に公開すべきという点については概ね合意が得られた。
2 つのシナリオについて検討する必要がある。1 つは、新 gTLD の導入を 1 つに制限すべきとするもので、もう 1 つは、より幅広い申請を認めていこうというものである。
新 gTLD の導入に伴い、総額でどれくらいのコストが発生するのか（法務担当や理事会のコストも含む）運用上のインパクトをさらに分析することが必要である。
新 gTLD の導入の要望度に関して、エンドユーザからの観点からの事実に基づいた市場分析が有用である。
gTLD を「公認」「非公認」に分類するということも試してみる価値があるかもしれない。
ICANN ウェリントン会議での議論（2006 年 3 月）
2006 年 3 月のICANNウェリントン会議では、上記ドラフトレポートを元に議論が行われた。会期中、この議論の進捗をGNSO評議会チェアで当時の新gTLD検討委員会のチェアでもあるBruce Tonkin氏が報告35している。その内容は以下の通りである。
新 gTLD の導入の是非については、導入すべきという意見でほぼコンセンサスに至った。しかし、妥当な選定基準があるのならという条件付きである。
既に選定基準を提案してきている部会もある。強い支持を受けたのは、技術的要件に適合すること（IDN 標準や、業務に関連する IETF の RFC）、申請費用を支払うこと、財政的に安定していることを示すこと、新 gTLD 設立の目的において、他の gTLD と明確に区別可能なことという諸条件である。
この他にも、ICANN 認定レジストラを利用すること、当該 gTLD のチャーター、
目的に沿うことを保証する仕組みがあること、ICANN のポリシーに従うことという諸条件も強い支持を得ている。
選定基準で強い支持とまではいかないが概ね支持を受けた事項としては、申請者がきちんと定義されたコミュニティを代表する組織であり、かつ登録者はそのコミュニティに属する者であるべきというもの、登録資格の正確な検証を行うことというものなどが挙げられる。
gTLD 名の割り当てについては、早い者勝ちにするのか、比較評価を行うかのどちらかであるがまだ結論は出ていない。
35 http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-28mar06.pdf

104

新 gTLD の契約条件についてはまだ議論中で結論が出ていない。
ICANN 理事会の決議（2006 年 3 月）
上記報告を受け、ICANN 理事会は「ICANN は 2007 年 1 月までに新 gTLD 募集のプロセスを開始する意図がある」ということ、及び「GNSO は次回の ICANN マラケシュ会議（2006
年 6 月）までに本件に関する正式な初回レポートを提出するよう、努力すること」という決議を行った。
ICANN 理事会側から GNSO に対してプロセスを早めるよう要求する決議が出るというのはこれまでの ICANN からすると異例のことであり、ICANN 理事会が新 gTLD プロセスを早く進めたがっていることの現れと解釈することもできる。当時の ICANN 理事の一人である伊藤穰一氏からは、これが実現すると、VeriSign の半独占とも言える状況を将来的には変えていくことができるのではないかという期待を持った発言もなされている。
GNSO 初回レポートの提出（2006 年 7 月）
2006 年 6 月のマラケシュ会議での議論を受け、GNSO は 2006 年 7 月にそれまでの議論の結果をまとめた初回レポートの最終版を提出した。以下、2005 年 12 月に出されている評
価委任事項に沿ってその内容を見ていく。
新しい gTLD は導入されるべきか。
新しい gTLD は導入されるべきであり、後述する勧告を考慮に入れた上で、導入を実現させるための作業が進められるべきである。
導入されるべきとした場合、その選択の基準はどのようなものか。
プロセスに関する基準として、申請費用の支払い、申請にあたっての信義則、申請終了までの明確な締め切りが設けられるべきである。
技術的な基準としては、IETF の RFC その他の技術標準に準拠すること、IDNを提供する場合、関連する IETF 標準及び ICANN の IDN ガイドラインの内容を遵守することが必要である。申請者が gTLD に ASCII に基づいた文字列を提案するか、その他の文字列を提案するかに関わらず一貫した取り扱いをするべきかについては更なる議論を要する。
申請者は ICANN のコンセンサスポリシーに従わなければならない。
申請する gTLD は、その目的において明確に既存のものと区別できるものでなければならない。IDN トップレベルドメインに関してこの要求がどのよう105

な影響を持つかは議論尽くされたわけではなく、更なるインプットが必要である。
申請者は、当該 TLD に関してその目的等を遵守するための仕組み、及び違反の登録に対処する仕組みを持たなければならない。
申請者は、レジストリ業務を行うに必要な財政面、運用面でのリソースを持っていることを示さなければならない。
どのような割り振りの手法が適切か
原則早い者勝ちとして申請を進めるべきであるが、同じ文字列の申請が来た際もしくは審査するスタッフのリソースが足りない等の事情がある場合において議論がある。この場合、オークションまたはくじによって優先度を決めるか、もしくは申請内容の相互比較によって優先度を決めるかの 2 つの選択肢が提示されているが、この 2 つはそれぞれほぼ同じ程度の支持を得ており、決着はついていない。
契約条件を詰める指針となるべきポリシーはどのようなものか
法令遵守の手法の確立についてさらに検討が必要であり、現時点では結論は出ていない。
この報告書において、gTLD の選択基準はその大枠が定まってきたように見える。しかし細部においてまだ詰めるべき点があることも報告書内で認めているという状況である。
GNSO による勧告ドラフトの公開（2006 年 9 月）
GNSOでは上記初回レポート提出の後さらに検討を重ね、2006 年 9 月にGNSOとしての勧告ドラフトをまとめ、公開36した。その内容を再度評価委任事項に沿って見ていく。
新しい gTLD は導入されるべきか。
新しい gTLD は導入されるべきであり、後述する勧告を考慮に入れた上で、導入を実現させるための作業が進められるべきである。（初回レポートに同じ）導入されるべきとした場合、その選択の基準はどのようなものか。
（初回レポートの内容から、gTLD の文字列についての要件が追加された。）
ICANN は、gTLD の申請が文字列の要件に従っているか予備的に判断する期
36 http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm

106間を設ける。その期間内には、専門家の助言を受けることができる。
新しい文字列の要件については、ICANN はパブリックコメント期間を設ける
ものとする。
申請された gTLD の文字列が要件を満たさない可能性があると ICANN が判断した際は、ICANN は専門家からなるパネルに当該申請を付託することができる。
gTLD の文字列は、既存の TLD の文字列と混同を引き起こすほど類似していてはならない。
gTLD の文字列は、他のいかなる第三者の法的権利を侵害するものであってはならない。
gTLD の文字列は、技術的な問題を引き起こすものであってはならない。
（.localhost や、.exe などは gTLD の文字列としては認められない。）
gTLD の文字列は、国内及び国際法に抵触するものであってはならない。
ICANN は、当該文字列が既存の gTLD 文字列と混同を引き起こすほど類似しているかどうかの争い（既存のレジストリからの申立）を、独立した紛争解決機関を使って解決するためのプロセスを提供しなければならない。紛争解
決機関によって混同を引き起こすほど類似していると判断された文字列は、
その後いかなる組織も申請できない。
ICANN は、当該文字列が既存の商標と混同を引き起こすほど類似しているかどうかの争い（既存の商標権者からの申立）を、独立した紛争解決機関を使って解決するためのプロセスを提供しなければならない。この紛争解決のプ
ロセスは、既存の UDRP のプロセスを用いて行われる。
どのような割り振りの手法が適切か早い者勝ち(First Come, First Served)の原則を採用するが、複数回のラウンドに分けて募集する。
新 gTLD 募集の初回ラウンドは、募集をかけることを決議した理事会の日から少なくとも 4 ヶ月後以降に開始することとし、ICANN は募集開始日を広く周知する。
申請は受け付けたものから日付順に整理される。
初回ラウンドの締め切り日は、開始日から少なくとも 30 日後以降の日とする。
申請された文字列は、締め切り日まで公開されないものとする。
同じ文字列の申請があった場合、もしくは混同を引き起こすほど類似している文字列の申請があった場合、まずそれらの申請が文字列要件を満たしているかの審査を行う。
次に申請者同士で協議を行う（異なる文字列を選択する、一緒に申請するな

107ど）時間を設定する。
申請者間で協議が成立しなかった場合、ICANN はそれぞれの申請者がコミュニティからどれほどのサポートを得ているかを評価する。申請者は追加資料を提出するための 90 日の猶予が与えられる。この評価で却下された申請者は、次回の申請ラウンドまで新しい申請を行うことはできない。
ICANN スタッフがどちらの申請が良いか判断出来ない場合、ICANN 理事会
が ICANN の使命と主たる価値に基づいて判断を行う。この評価で却下された
申請者は、次回の申請ラウンドまで新しい申請を行うことはできない。
申請を承認された申請者は、その文字列を使ったサービスを適切な期間内に開始しなければならない。
契約条件を詰める指針となるべきポリシーはどのようなものか
ある程度の一貫性を保つため、レジストラ契約のように大枠となる契約があ
るべきである。その契約の枠内であれば、ICANN スタッフが承認の権限を与えられるべきで、枠内に止まらない契約になれば、パブリックコメントに付した上で ICANN 理事会が判断するべきである。
契約内容は、市場プレイヤーと ICANN との間で変化する市場や技術、ポリシー上の条件を十分カバーできるようなものであるべきである。
新 gTLD の初期契約期間は商慣習的に合理的な長さであるべきである。
（例えば 10 年。ただし、ケース毎に判断する場合がある）
契約は重大な違反が無い限りは自動延長されるべきである。
契約違反の場合に契約を打ち切ることが出来る条項を明確に設けておくべきである。
ICANN でコンセンサスとなったポリシーに準拠させる条項を設けるべきである。
レジストリが IDN を提供する場合は、契約上でその旨明記しておくべきである。
最初の契約時は、競争を管轄する政府当局等に対し、契約中に法令違反が無いかどうか確認するものとする。
ICANN はレジストリ料金について、地域や経済、ビジネスモデルの違いを考慮に入れた上で、一貫したアプローチを取るべきである。
個人情報の取り扱いについては、それが第三者から入手可能になるのはどのような場合かについて、レジストリは定義しておかなければならない。
上記を見れば分かるとおり、初回レポートの内容からはかなり要件が詳細にわたり詰まってきている。

108

GNSO による最終レポートドラフト提出（2007 年 2 月）
GNSOの作業部会ではさらに議論を進め、上記勧告ドラフトの内容を元に最終レポートのドラフトを 2007 年 2 月に公開37した。ここに至りgTLDの各種選定条件がほぼ整ってきている。以下に最終レポートドラフト内で示されている選定条件を列挙する。
文字列の条件既存の gTLD と混乱を引き起こすほど類似していてはならない。
第三者の権利を害するものであってはならない。
技術的不安定をもたらすものであってはならない。
予約語（ICANN との関係において。ASO や IANA など）であってはならない。
公共政策に反するものであってはならない。（GAC の助言による）申請者の条件
申請者は自らの技術的能力を示さなければならない。
申請者は自らの財政、運営能力を示さなければならない。
プロセスの条件
明確で前もって公開された、客観的で計測可能な基準が示されなければならない。
プロセスの始めに、基本契約書が申請者には示されなければならない。
申請に関して予備的決定を行うために、専門家からなるパネルの使用とともにスタッフがその任にあたり、決断を行う。
プロセスに先立ち、紛争解決や異議申し立てのプロセスを確立しておく必要がある。
割り振りの条件
申請は複数のラウンドにわけて行われる。
申請された文字列は申請締め切り後に公開される。
複数の申請が同じ文字列に対してなされた場合、まず申請者間である特定の時間内に調整ができるかを試み、調整出来なかった場合はこれを解決するためのプロセスを進める。
最終判断は、スタッフ及び専門家からなるパネルの助言に基づき、ICANN 理事会が行う。
37 http://gnso.icann.org/drafts/GNSO-PDP-Dec05-FR13-FEB07.htm

109

契約条件
基本契約書が RFP の一部として提供されるべきである。
初期契約期間は、商慣習に照らして合理的な長さであるべきである。
自動更新の仕組みを取り入れるべきである。
法令遵守や制裁のプロセスを明確に基本契約書に盛り込み、契約破棄ができるようにすべきである。
レジストリは既存のコンセンサスポリシーに従い、今後成立するコンセンサ
スポリシーも採用することをコミットするべきである。
レジストリが IDN を提供する場合、ICANN の IDN ガイドラインに従わなければならない。
レジストリは ICANN 認定レジストラを利用しなければならない。
実施にあたってのガイドライン
コスト回収のための申請費用はあるべきである。申請費用は申請者毎に異なっても良い。
早い者勝ちを原則としてプロセスの順番を決定する。
申請は受け付けた日付と時間を記録する。
申請提出の日付は、RFP を出してから少なくとも 4 ヶ月後とする。
ICANN は申請受け付けを広く周知するものとする。
申請期間は少なくとも開始してから 30 日とする。
申請者は申請が承認された場合、当該 gTLD を合理的な時間内に利用開始しなければならない。
基本契約書は ICANN が変化する市場や技術、ポリシー上の条件を十分カバーできるようなものであるべきである。
ICANN はレジストリ料金に関して一貫したアプローチを取るべきである。
個人情報の使用は、それを収集する目的の範囲内にのみ制限される。
2006 年 9 月の勧告ドラフトの内容とそれほど変化はないものの、条件の記述がより簡潔に、かつ具体的な方向に変わってきたことがわかる。
この後、続いて、評議会メンバーの議論等を反映させた最終レポートドラフトが 2007 年 3月、2007 年 6 月と再度提出され、GNSO 評議会におけるこれまでの議論の集大成として、2007 年 8 月に最終報告書が提出された。

110

GNSO による最終レポート提出（2007 年 8 月）
2007 年 3 月以降のレポートは、冒頭の要約部分にてGNSO評議会メンバーが新gTLDを導入する上で優先事項と考えている事柄からなる原則(Principles)、勧告、ICANNスタッフが2007 年 3 月のリスボン会議でGACより提示された原則38も考慮しつつGNSOメンバーとも協調して作成した、実施にあたってのガイドライン(Implementation Guidelines)が整然とまとめられた内容となっている。また、これら 3 要素の中の各項はそれぞれ、ICANNの付
属定款に記されるICANNのミッションと基本的価値観に対応付けされている。
以下に、最終報告書における勧告とガイドライン（略称 IG）を列挙する。
勧告 1：

全ての GNSO 部会は、新 gTLD 導入を支持する。

勧告 2：

既存の TLD 文字列と混乱を引き起こすほど類似していてはならない。

勧告 3：

文字列が、一般的に受容され国際的に認知されている法の原則の下で法的効力を持つ第三者の権利を害するものであってはならない。

勧告 4：

技術的不安定をもたらすものであってはならない。

勧告 5：

予約語であってはならない。

勧告 6：

文字列は、国際的な法の原則の下で考えられる公序良俗に関連して一般的に受容されている法的規範に反するものであってはならない。
（GAC の助言による）

勧告 7：

申請者は自らの技術的能力を示さなければならない。

勧告 8：

申請者は自らの財政、運営能力を示さなければならない。

勧告 9：

明確で前もって公開された、客観的で計測可能な基準が示されなければならない。

勧告 10：

プロセスの始めに、基本契約書が申請者には示されなければならない。

勧告 11：（欠番）

勧告 12：

プロセスに先立ち、紛争解決や異議申し立てのプロセスを確立しておく必要がある。

勧告 13：

申請の希望数が明確になるまでは、初めのうちは申請は複数のラウンドに分けて行われなければならない。

勧告 14：

初期契約期間は、商慣習に照らして合理的な長さであるべきである。

勧告 15：

自動更新の仕組みを取り入れなければならない。

勧告 16：

レジストリは既存のコンセンサスポリシーに従い、今後成立するコンセ
ンサスポリシーも採用しなければならない。

勧告 17：

法令遵守や制裁のプロセスを明確に基本契約書に盛り込み、契約破棄が38 http://gac.icann.org/web/home/gTLD_principles.pdf

111

できるようにしなければならない。
勧告 18：

レジストリが IDN を提供する場合、ICANN の IDN ガイドラインに従わなければならない。

勧告 19：

レジストリは ICANN 認定レジストラを利用しなければならず、不公平な取り扱いを受けるレジストラがあってはならない。

勧告 20：

応募のあった文字列に対して、当該文字列を登録するのに相応しいと思われるコミュニティからの反対が投じられたと専門家パネルが判断すれば、その応募は却下される。

IGA：

申請プロセスにおいて、新 gTLD の申請提出を促進できるよう申請者向けのロードマップを事前に明示する。

IG

B：

コスト回収のための申請費用はあるべきである。申請費用は申請者毎に異なっても良い。

IG

C：

ICANN は、申請者やコミュニティとのコミュニケーションの場を、コメントフォーラムも含めて頻繁に用意する。

IG

D：

申請期間中および必要あらば進行中のプロセスの間も、先願制を原則とする。申請は受け付けた日付と時間を記録する。

IG

E：

申請提出の日付は、RFP を出してから少なくとも 4 ヶ月後とし、ICANN
は申請期間の開始を促す。

IG

F：

複数の申請が同じ文字列に対してなされた場合、
i)まず申請者間である特定の時間内に調整ができるかを試み、
ii)調整出来なかった場合は、あるコミュニティをサポートすると主張する組織が申請への優先権を認められると考える。そのような主張や相互調整が無い場合は、これを解決するためのプロセスを進める。
iii)最終判断は、スタッフ及び専門家からなるパネルの助言に基づき、
ICANN 理事会が行う。

IG

H39：

sTLDや特定のコミュニティのためのTLDのように、申請するTLDがある特定のコミュニティをサポートするものであると申請者が主張する場合、信用することとするが、次は例外とする：(i)別の申請にも影響を与える文字列に関する主張や、コミュニティをサポートするという主張が申請において優先権を獲得するための場合(ii)正式な異議申し立てのプロセスが開始した場合
これらの例外が出た場合、スタッフである評価者は主張を調査するための基準や手順を策定する。
例外(ii)については、専門家パネルが「IG39「G」の間違いと思われるが、最終報告書内の表記のままとする。

112

P」に記載の手順、ガイドラ

イン、定義を適用する。
IG

H：

外部の紛争処理機関が異議申し立てへの裁定を下す。

IGI：

申請者は申請が承認された場合、当該 gTLD を申請期間中に指定される
予め決められた時間内に利用開始しなければならない。

IG

J：

基本契約書は ICANN が変化する市場や技術、ポリシー上の条件を十分カバーできるようなものであるべきである。

IG

K：

ICANN はレジストリ料金に関して一貫したアプローチを取るべきであ
る。

IG

L：

個人情報の使用は、それを収集する目的の範囲内にのみ制限しなければ
ならない。

IG

M：

ICANN は、参加者が英語を読み書きできなくても、重要かつ技術的なイ
ンターネットガバナンス機能に関するコミュニケーションを効果的に行えるようにするための能力開発やサポート体制を構築することもある。

IG

N：

ICANN は、国連が後発発展途上国と分類する経済圏にある gTLD 申請者に対しては、料金値下げの仕組みを導入することもある。

IG

O：

ICANN は、gTLD プロセスに関する情報を提供できるようなシステムを、
6 つの国連公用語等のような英語以外の主要言語で導入することもある。

IG

P：

次の手順、定義、ガイドラインは、勧告 20 について触れる
手順
異議申し立ては、反対意見をもっておこなわれること。
裁定は、紛争解決のために組成された紛争解決パネルにより下される。
申立てをする者は、自組織がコミュニティにおいて確立された組織である
ことを立証できる証拠を提出しなければならない。
ガイドライン
パネルのタスクは、反対意見に対する判断を下すことである。（判断項目の解釈の仕方については割愛）

IG

Q：

ICANN スタッフは、異議申し立ての手順についてパブリックコメントを投じる人すべてに自動応答する。

IG

R：

正式な異議申し立てや紛争が審理のために受理されると、パネルの審理前に当事者間で紛争や異議申し立てを解決できるクーリングオフ期間が設けられる。

2007 年 2 月の最終レポートドラフトと比較すると、勧告の部分の内容は大筋で同様である
が、要求の度合いが高まって語調が厳しくなっている点と、一部がガイドラインの項目となった点が異なっている。ガイドラインは、より明確になり、項目も追加された。

113

GNSOによる最終レポートは、2007 年 8 月 10 日〜30 日のパブリックコメント期間を経て、
9 月 6 日のGNSO評議会にて特別多数にて採択し、理事会に提出することが決議された。理事会レポート40は、GNSO評議会のウェブサイトを見ると、次項に記すロサンゼルス会議の最終日である 11 月 2 日に掲示されているが、本文を見ると 9 月 11 日の日付が記されており、GNSO評議会会議の後 5 営業日で提出することとなっている付属定款に則り作成されたものと思われる。
ICANN ロサンゼルス会議での議論（2007 年 10〜11 月）
ロサンゼルス会議では、GNSO 評議会が採択した最終報告書に関して、6 時間にわたるワ
ークショップが開催され、内容についての網羅的な説明や、コミュニティとのディスカッ
ションが行われた。参加者からは多くのコメントが上がり、新 gTLD 導入に多くの関心が寄せられていることが窺えた。しかしながら、好意的な反応よりも、勧告 6 と勧告 20 に対する否定的なコメントが目立ったことが特徴的であったと言える。この 2 つの勧告は、各国で捉え方が異なる公序良俗に関する判断や文字列の選別を ICANN が行うといった内容を含んでおり、これらは ICANN が負っている技術的な役割を超えた、恣意的、政治的な判断を伴うため適当ではない、というのが反対意見が投じられた主な理由である。
理事会は、新 gTLD 導入について特段の決議は行わず、ICANN スタッフに対して、勧告の実装に関する分析を進めると共に、2008 年 1 月の理事会までに理事会とコミュニティにフィードバックするよう要請し、会議を終えた。
ICANN ニューデリー会議での議論（2008 年 2 月）
ニューデリー会議では新 gTLD 導入に関する目立った進捗はなく、ロサンゼルス会議以降
理事会の決議待ちの状況から大きな進展は生じていない。前述のごとく、GNSO が提出した勧告が倫理的、政治的な判断を要する内容等を含んでいたため、理事会での判断に時間を要しているものと想像される。
しかしながら、会期中のICANN Public Forumにて、ICANNスタッフよりNew gTLD
Program Status41を用いた説明があり、それによれば、ICANNが想定する新gTLD実装のタイムラインは以下の通りである。
2008 年 4 月〜6 月： 理事会が勧告を承認

40 http://gnso.icann.org/issues/new-gtlds/council-report-to-board-pdp-new-gtlds-11sep07.pdf
41 http://delhi.icann.org/files/NewgTLDPresentationPublicForum.pdf

114

2008 年 6 月中旬：

ドラフト RFP の提示

2008 年 9 月中旬：

パブリックコメント期間や修正期間を経て、理事会が最終 RFP と実装計画を承認

2008 年 10 月：

RFP 公示開始(90 日間公開)

また、ニューデリー会議前にも、2007 年 12 月には紛争解決サービス機関からの関心表明の募集、RFP策定を依頼する業者の選定（Deloitte Audit & Enterprise Risk Services(Belgium) とInterisle Consulting Group(米国)の 2 社を選定）、2008 年 1 月にはオークシ
ョン設計の専門家からの関心表明の募集、2 月には新gTLD導入がDNSの安定性に与える影響についての意見募集42、過去の新gTLD導入ラウンドで採用されなかった申請に関する情報の公開などを行っており、ICANNスタッフレベルでの準備は着々と進められているものと思われる。
本会議においても、理事会は ICANN スタッフに対して、勧告の実装に関する分析を引き続き進めるよう要請して終わっているが、計画通りに進めば 2008 年中に新 gTLD の申請受付が開始することとなる。

1-3 ccTLD に関する国際的な議論
ccTLD に関連した国際的な議論は、ICANN（Internet Corporation for Assigned Names
and Numbers）において行われることが多い。ここでは、ccTLD に関して主に 2007 年にICANN で議論された話題として、ICANN と ccTLD との関係正式化、IANA のサービスレ
ベルの改善、ICANN における地域の定義をあげる。なお、2007 年は IDN についても大きく取り上げられ議論されたが、その内容は別章にて示すこととする。
● ICANN と ccTLD との関係正式化
ccTLD は、ISO3166-1 リストにしたがって国や地域に付与されているものであり、そのレ
ジストリは、インターネットの発展の中で、相互信頼をベースに割り当てられてきた。このため、ICANN と ccTLD には契約などの正式な関係が存在しなかった。ICANN は、インターネット全体の安定した運用体制を確固としたものとするため、1998 年の設立当初より、
ccTLD Sponsorship Agreement（ccTLD スポンサ契約。以下「スポンサ契約」）という契約書を各 ccTLD と締結することによって ccTLD との関係正式化を実現しようとしてきた。
しかし、スポンサ契約には厳格な罰則規定、賠償責任などの条件が含まれていることから、
42 http://www.icann.org/announcements/announcement-06feb08.htm

115

ヨーロッパを中心とする多くの ccTLD が締結を拒否し、関係正式化は進まなかった。2001
年にスポンサ契約書の雛形を公開して以来、2008 年 2 月までにスポンサ契約を締結したのは 8 ccTLD、スポンサ契約に準じた形式の覚書を締結したのは 7 ccTLD のみにとどまっている。
その後、ICANN において、ccTLD 登録管理組織で構成する ccNSO（Country Code Names
Supporting Organisation）が中心となり、スポンサ契約よりも条件の緩い、相互信頼をベースとした「Accountability Framework」という新たな関係正式化の枠組みが作られた。
「Accountability Framework」には、契約書を締結する形式と、相互に書簡を交換する形
式 の 2 種 類 が あ り 、 ccTLD は い ず れ か を 選 択 す る こ と が で き る 。「 Accountability
Framework」の導入を受け、スポンサ契約の締結を拒否していた ccTLD でも、この枠組みに基づく契約締結または書簡交換には応じるものが出てきた。2006 年 1 月に書式の雛形が確定して以来関係正式化は順調に進み、2008 年 2 月 26 日時点で、16 の ccTLD が「Accountability Framework」での契約書を締結し、21 の ccTLD が書簡の交換を完了している。
上述のように、ICANN と ccTLD 間の契約締結は、インターネットの運用体制を安定化させることを目的としている。一方、ICANN と ccTLD との関係正式化には、インターネッ
トのポリシー策定に ccTLD として正式に参画するという趣旨もあり、それは各 ccTLD の
ccNSO への加入という形で実現される。CcNSO は ICANN の付属定款（Bylaws）に基づいて設置された組織である。したがって、ccNSO への加入は、ICANN の付属定款における ccNSO 関連条項に定められた条件を遵守することを意味する。
ccNSO は、2003 年の ICANN 組織改革にともなって設置された。設置後、日本の.jp を含
む世界の主要 ccTLD が ccNSO に加入したが、ヨーロッパを中心とした一部の ccTLD は、
ICANN 付属定款中の ccNSO に関する規定内容について不満を抱いていた。その不満とは、
ICANN の付属定款において ccNSO 会員に対する拘束事項が明確でないことであった。こ
の拘束事項をより明確にする努力が ccNSO と ICANN スタッフとの間で進められたが、この議論が収束するまでの間、ヨーロッパから ccNSO に加入する ccTLD はなかった。2006
年 3 月時点の ccNSO 会員数は 48 で、そのうちヨーロッパの ccTLD は ccNSO 創設時の検討に積極的に参加していた.nl（オランダ）のみであった。しかし、2006 年 6 月に付属定款
中の ccNSO 関連条項の明確化が承認されたことから、それ以降はヨーロッパの ccTLD に
よる ccNSO への加入が進んだ。その他の地域の ccTLD による加入もあって、2008 年 2 月
26 日時点で 72（うちアジア太平洋 20、ヨーロッパ 10、北米 4、南米・カリブ 20、アフリカ 18）へと、ccNSO 会員数は増加した。

116

● IANA のサービスレベルの改善
ccTLD にとって、IANA の業務の迅速化はかねてからの大きな課題であった。たとえば、ある ccTLD がルートゾーンファイルに登録されたその TLD のネームサーバ情報の書き換
えを IANA に申請したとき、その書き換えが実際にルートゾーンに反映されるまでには、「申請者の本人性の確認」「申請者の正統性の確認」「申請者の意図の確認」｢ネームサーバに関する技術的な確認｣「米国政府（商務省）の承認」などの多くのステップがあり、早い場合でも申請から 1 週間、遅い場合は数ヶ月かかっていた。各 ccTLD が自らの管理する TLDのネームサーバの追加や変更を行う際に大きな時間を要することになり、結果として
ccTLD の安定運用に支障をきたす原因のひとつになることがあった。
この申請処理は電子メールを用いたやり取りを通じて行われる業務であり、IANA 内で多くの人手がかかるものであるが、効率化の検討など多くの努力により、サービスの改善が図られた。2008 年 2 月現在、IANA 業務は、以前と比べると 4 分の 1 の待ち時間で申請がルートゾーンに反映されるようになるなど飛躍的にスピードアップし、サービスレベルの改善が大きな成果をあげてきている。
また、.pl（ポーランド）のレジストリである NASK などは、IANA の申請処理が電子メー
ルによる申請であること自体を見直し、Web インターフェースから受け付ける形式で自動化する仕組みを作成して IANA に提案した。その後、IANA および NASK は共同でシステムの開発を進め、2007 年末には一部の ccTLD を対象とした Web インターフェースのテストを開始するにいたった。テストには JPRS を始めとする少数の ccTLD がボランティアで参加している。このシステムが導入されることにより、申請処理の更なる効率化、プロセスの明確化、利便性の向上が期待されている。この一連の動きは、ccTLD コミュニティと
ICANN が協力してインターネット全体をより良くしていく努力の一例ととらえられている。
今後さらに IANA のサービスを改善していく必要があるとの声もあるが、そもそも現在のIANA における TLD 向け機能にはサービスレベルが規定されておらず、自動化によりサービスが改善されたとしても、達成度や目標などが不明確であるという根本的な課題が残る。
このような背景から、定義すべきサービスレベルとしてどのような項目が必要か、そしてそれぞれの項目のサービスレベルはどの程度であると定めるか、さらに IANA がそれを満たせなかった場合にはどうするかなどについて検討されている。今後何らかの形で TLD からのサービスレベル要求がまとめられ、提案されることも考えられる。

117

● ICANN における地域の定義
現在 ICANN は、国際連合が作成しているリストに基づき、世界をアフリカ、アジア太平洋、
ヨーロッパ、ラテンアメリカとカリブ海諸島、北米の 5 地域に分け、この「地域」を基準として理事などの選挙を行っている。
ICANN の活動のコンセプトは「広く意見聴取を行ってから意思決定をすること」であり、意思決定の際に多くの当事者の意見が反映されるようにすることに重点が置かれている。
このような背景を考えた場合、各 ccTLD の意見が「その地域の意見」としてまとまった形で反映されるかどうかは、ICANN の根幹に関わる重要な問題であるといえる。特に、各地域が選挙区と一致している ccNSO にとっては、ccTLD がどの地域に属するかが大きな問題となる。
例えば、.nc（ニューカレドニア）はフランスの海外領土であり、地理的にはアジア太平洋地域に存在しながらも、ICANN での定義ではヨーロッパ地域に属することになる。したがって、.nc は、ccNSO の評議委員選挙に立候補した場合に、地理的に遠く交流の少ないヨー
ロッパの ccTLD の票を獲得しなければならない。
ccNSO では 2006 年からこの問題を検討してきたが、2007 年末現在で、次のような提案をまとめる方向でコンセンサスが得られつつある。
・独立国の単位と一致しない ccTLD は、ccNSO での活動に際し、自ら所属する「地域」を選択できる
・必要に応じ「地域」をさらにサブグループ化する・課題をベースにしたグルーピングを適宜実施する
ここでとりあげた「国と地域」の問題は、ネットワークの世界にとどまらず国際問題として古くから存在するものであり、ICANN の場で今後どのような展開を見せるかが注目される。

118