インターネット資源の管理体制と活 用 に 関 す る 調 査 研 究

1

2

目次
第 1 部 インターネット資源の国際的な管理体制とその在り方に関する議論の動向
1 インターネット資源に関する概説、概況................................................................................ 11
1-1 ドメイン名........................................................................................................................ 11
1-1-1 ドメイン名の種類と性質 ........................................................................................... 11
1-1-2 ドメイン名の登録状況............................................................................................... 12
1-2 IPアドレス ........................................................................................................................ 15
1-2-1 IPv4 アドレス ............................................................................................................ 15
1-3 AS番号............................................................................................................................... 20
1-4 ルートサーバ .................................................................................................................... 21
1-4-1 ルートサーバの性質 .................................................................................................. 21
1-4-2 ルートサーバの配置状況 ........................................................................................... 24
2 インターネット資源管理体制の現状及びそれに関する議論の動向........................................ 31
2-1 インターネット資源管理体制の概要................................................................................ 31
2-1-1 IPアドレスの管理体制の現状 .................................................................................... 33
2-1-2 ドメイン名の管理体制の現状.................................................................................... 34
2-2 インターネット資源管理体制全般に関する議論の動向................................................... 44
2-2-1 第 2 回IGFリオデジャネイロ会合に至るまでの議論................................................. 45
2-2-2 第 2 回IGFリオデジャネイロ会合での議論 .............................................................. 47
2-2-3 共同プロジェクト合意書（JPA）中間レビュー ....................................................... 63
3 インターネット資源管理ポリシーの現状及びそれに関する議論の動向................................. 75
3-1 IPアドレスに関する管理ポリシーの現状および議論の動向 ............................................ 75
3-1-1 IPv4 アドレスポリシー.............................................................................................. 75
3-1-2 IPv6 アドレスポリシー.............................................................................................. 88
3-1-3 AS番号ポリシー ......................................................................................................... 94

第 2 部 ドメイン名の管理と活用に関する世界的な動向及び各国における動向調査
1 ドメイン名の競争環境整備に関する動向................................................................................ 99
1-1 スポンサ付きトップレベルドメイン(sTLD)の導入の状況 .............................................. 99
1-2 新gTLDの導入に関する議論の動向 ............................................................................... 102
1-3 ccTLDに関する国際的な議論.......................................................................................... 115

3

2 ドメイン名の登録方針に関する動向 ..................................................................................... 121
2-1 gTLDにおけるドメイン名登録方針の動向 ..................................................................... 121
2-1-1 .com .......................................................................................................................... 121
2-1-2 .net ........................................................................................................................... 124
2-1-3 .org ........................................................................................................................... 127
2-2 各国におけるドメイン名登録方針の動向..................................................................... 130
2-2-1 概況.......................................................................................................................... 130
2-2-2 各TLDの登録管理体制およびドメイン名登録方針............................................... 131
2-3 WHOISを巡るICANNでの議論の動向........................................................................... 207
2-3-1 WHOISに関する議論の背景.................................................................................... 207
2-3-2 WHOISに関する過去の議論.................................................................................... 207
2-3-3 2007 年 4 月以降の議論 ........................................................................................... 210
2-4 ドメイン名テイスティングに関する議論の動向............................................................ 216
2-5 ドメイン名のフロントランニングに関する議論の動向................................................. 223
2-6 ドメイン名を巡る紛争および紛争処理体制の動向 ........................................................ 227
2-6-1 2007 年におけるドメイン名紛争の概況 .................................................................. 227
2-6-2 gTLDにおけるドメイン名紛争 ................................................................................ 230
2-6-3 JPドメイン名におけるドメイン名紛争 ................................................................... 246
3 国際化ドメイン名の導入及び実装に関する取り組み状況 .................................................... 259
3-1 国際化ドメイン名(IDN)とは .......................................................................................... 259
3-2 国際化ドメイン名導入のための前提とその仕組み ........................................................ 259
3-3 国際化ドメイン名の技術標準......................................................................................... 261
3-4 国際化ドメイン名における言語問題.............................................................................. 264
3-5 各国の導入状況 .............................................................................................................. 265
3-5-1 .com/.net（VeriSign,Inc）の導入状況 .................................................................... 266
3-5-2 .org（Public Interest Registry）の導入状況.......................................................... 268
3-5-3 .info（Afilias）の導入状況 ...................................................................................... 269
3-5-4 .museum（MuseDoma）の導入状況 ...................................................................... 270
3-5-5 .biz（Neulevel）の導入状況.................................................................................... 270
3-5-6 .cat（Fundacio puntCat）の導入状況.................................................................... 271
3-5-7 .jp（日本）（JPRS）の導入状況 .............................................................................. 271
3-5-8 .kr（韓国）（Korea Network Information Center）の導入状況............................ 274
3-5-9 .pl（ポーランド）（NASK：Research and Academic Computer Network）の導入状
況 ....................................................................................................................................... 275
3-5-10 .th（タイ）（ThNIC）の導入状況 ......................................................................... 275
3-5-11 .de（ドイツ）（DENIC eG）の導入状況 ............................................................... 275

4

3-5-12 .ch/.li（スイス／リヒテンシュタイン）（SWITCH Teleinformatics Services）の導入状況 ................................................................................................................................ 276
3-5-13 .at（オーストリア）（NIC.AT Internet Verwaltungs und Betriebsgesellschaft
m.b.H）の導入状況 ........................................................................................................... 276
3-5-14 .dk（デンマーク）（DK Hostmaster A/S）の導入状況 ........................................ 277
3-5-15 .lt（リトアニア）（KTU Information Technology Development Institute）の導入状
況 ....................................................................................................................................... 277
3-5-16 .se（スウェーデン）（NIC-SE）の導入状況 ......................................................... 278
3-5-17 .tw（台湾）（TWNIC）の導入状況 ....................................................................... 278
3-5-18 .cn（中国）（CNNIC）の導入状況 ........................................................................ 278
3-5-19 .hu（ハンガリー）（ISZT Kht）の導入状況 ......................................................... 279
3-5-20 .is（アイスランド）（ISNIC - Internet Iceland ltd.）の導入状況 ....................... 279
3-5-21 .ac（アセンション島）（Ascension Island Network Information Centre）の導入状
況 ....................................................................................................................................... 280
3-5-22 .br（ブラジル）（Comite Gestor da Internet no Brasil）の導入状況 ................. 280
3-5-23 .cl（チリ）（NIC Chile）の導入状況..................................................................... 280
3-5-24 .fi（フィンランド）（Finnish Communications Regulatory Authority）の導入状況........................................................................................................................................... 281
3-5-25 .gr（ギリシャ）（ICS-FORTH GR）の導入状況 .................................................. 281
3-5-26 .io（英領インド洋地域）（IO Top Level Domain Registry）の導入状況 ............. 281
3-5-27 .lv（ラトビア）（University of Latvia）の導入状況 ............................................ 282
3-5-28 .no（ノルウェー）（UNINETT Norid A/S）の導入状況....................................... 282
3-5-29 .nu（ニウエ）（Internet Users Society - Niue）の導入状況 ............................... 282
3-5-30 .sh（セントヘレナ島）（Government of St. Helena）の導入状況 ....................... 283
3-5-31 .hk（香港）(Hong Kong Internet Registration Corporation Ltd.) の導入状況. 283
3-5-32 .vn（ベトナム）(VNNIC) の導入状況.................................................................. 284
3-5-33 .ae（アラブ首長国連邦）(UAEnic) の導入状況 ................................................... 284
3-5-34 .tm（トルクメニスタン）(TM Domain Registry Limited) の導入状況 .............. 284
3-5-35 .tr（トルコ）(Middle East Technical University) の導入状況 ........................... 285
3-5-36 .es（スペイン）（Red.es）の導入状況................................................................... 285
3-5-37 .ir（イラン）（Institute for Studies in Theoretical Physics & Mathematics (IPM)）の導入状況 ......................................................................................................................... 285
3-5-38 .pe（ペルー）（Red Cientifica Peruana）の導入状況 .......................................... 286
3-5-39 .pt（パレスチナ）（Ministry Of Telecommunications &Information Technology,........................................................................................................................................... 286
3-6 IDNに関する動向............................................................................................................ 287

5

3-6-1 IDN TLDのポリシーに関する検討状況................................................................... 287
3-6-2 IDN TLDの技術および運用に関する検討状況........................................................ 291
3-6-3 IDN標準およびアプリケーションの対応に関する状況........................................... 293
3-7 アプリケーションの国際化ドメイン名への対応............................................................ 294

第 3 部 IP アドレスの管理と活用に関する世界的な動向及び各国における動向調査
1 IPv4 アドレスの消費状況と、枯渇に関する議論の動向 ....................................................... 305
1-1 IPv4 アドレスの消費状況と今後の予測.......................................................................... 305
1-2 IPv4 アドレス在庫の枯渇に関する議論の状況............................................................... 308
1-2-1 IPv4 アドレス在庫の枯渇に関するポリシー提案とその議論 .................................. 308
2 IPv6 アドレスの導入状況と、普及に関する議論の動向 ....................................................... 325
2-1 IPv6 アドレスの導入状況 ............................................................................................... 325
2-2 IPv6 普及に関する議論の動向 ........................................................................................ 326

第 4 部 参考資料
1 ドメイン名関連統計資料 ....................................................................................................... 337
1-1 gTLDレジストラ間のマーケットシェア状況 ................................................................. 337
1-2 レジストラ別ドメイン名登録数一覧.............................................................................. 338
1-3 ccTLD別ドメイン名登録数一覧（2008 年 1 月時点） ................................................... 403
2 国毎のIPアドレス割当量等、IPアドレスに関する各種統計資料......................................... 409

6

第1部

インターネット資源の国際的な管理体制とその在り方に関する議論の動向

7

8

1

インターネット資源に関する概説、概況

9101 インターネット資源に関する概説、概況
1-1 ドメイン名
1-1-1 ドメイン名の種類と性質
ドメイン名は、トップレベルドメイン（TLD）を基準として分類すると、分野別トップレ
ベルドメイン（generic Top Level Domain: gTLD）と、国コードトップレベルドメイン（country code Top Level Domain: ccTLD）に大別される。
gTLDは本来分野別に割り当てられたTLDであり、一般的に登録者の居住する地理的制限無しに世界のどこからでも登録することができる1。現在gTLDは、従来からある.com / .net
/ .org などに 2001 年以降新たに 16 種類が加わり、計 19 種類存在する（2008 年 2 月時点）。
この 16 の新gTLDのうち、.museum / .aero / .coop / .jobs / .travel / .mobi / .cat /.asia の 8
つは「スポンサ付きTLD」（sponsored TLD: sTLD）と呼ばれ、それぞれの業界・分野を代表するスポンサ組織が定める方針の下、関係メンバーのみに登録が制限されている。こうした制限のないその他のgTLDは、「スポンサ無しTLD」（unsponsored TLD: uTLD）と呼ばれていて、.com/.net./.orgなどの従来から馴染みのあるgTLDは、スポンサ無しのgTLDである。
一方、ccTLDは、ISO（国際標準化機構）のISO3166-1 リストで規定されている 2 文字の国コードをもとにして2各国・地域に割り当てられたTLDであり、現在 250 種類3存在する（2008 年 2 月時点、.su/旧ソビエト連邦など削除予定のものも含む）。ccTLDは、各国・地域の事情や管理機関の方針によりその性質はさまざまであるが、大きく分類すると、登録を国・地域内に限定しているccTLD（.jp / .au / .usなど）と、全世界からオープンに登録できるccTLD（.tv / .to / .ccなど）に分けることができる。
gTLDとccTLDの他に、インターネットインフラ用のトップレベルドメイン（Infrastructure
TLD）が存在するが、これはユーザの登録対象とはなっていない。

1 .edu / .gov / .milについては、歴史的経緯により米国内の（もしくは米国を中心とした）関係者/組織に使用が限定されている。
これはあくまで原則であり、UK（本来ならばGB）などの例外も存在する。
3 .euの追加やセルビア・モンテネグロの分離など、状況の変化に併せ適宜増減している。
211

表1： ドメイン名の種類

gTLD

ccTLD

Infrastructure
TLD《従来からある gTLD》.jp（日本）.arpa.com（商業組織用）.au（オーストラリア）.e164.arpa.net（ネットワーク用）.kr（韓国）.ip6.arpa.org（非営利組織用）.uk（イギリス）.in-addr.arpa.edu（教育機関用）.us（米国）.gov（米国政府機関用）.de（ドイツ）.mil（米国軍事機関用）.ca（カナダ）.int（国際機関用）.cc（ココス諸島）《新 gTLD》.to（トンガ）.info（制限なし）.tv（ツバル）.biz（ビジネス用）

・.name（個人名用）

・.pro（専門家用）

・.museum（博物館、美術館等用）

・

（いずれも
インターネット
インフラ用）.aero（航空運輸業界用）.coop（協同組合用）.jobs（人事管理業務関係者用）.travel（旅行関連業界用）.mobi（モバイル関係用）.cat（カタロニアの言語／文化コ
ミュニティ用）.asia（アジア太平洋地域の企業／
個人／団体等用）

1-1-2 ドメイン名の登録状況
現在、全世界におけるドメイン名の登録総数は約 1 億 4,600 万件以上になっている4。これは昨年よりも 1.3 倍ほど多い数字である。一昨年から昨年にかけては、前年比で 1.5 倍ほど
出典：“Registrar Connections November 2007”
http://www.verisign.com/Resources/Naming_Services_Resources/Registrar_Connections/page_043137.
html

4

12

の伸びを示していたので、そういう意味ではこの 1 年間の伸びはこれまでと比べてやや落ち着いたとも言える。この 1 億 4,000 万件強のうちの約半数を占めるのが.comであり、2007
年 10 月時点での登録数は約 6,900 万件で 7,000 万件突破目前となっている。おそらく、2007
年の 11 月か 12 月の統計では 7,000 万件を超えるものと思われる。.comが全体に占める割合としては昨年と比べてほんの僅かではあるが減っており、.comの登録数が増加した以上に、他のドメイン名の登録が増えた形である。
その他、登録数の多い大規模な TLD としては、.de（ドイツ）、.cn（中国）.net、.uk（イギリス）、.org などが挙げられる。依然として根強い人気の.com を除くと、.de の登録数がgTLD を含めた中でもかなり突出しており、ccTLD の中では唯一 1,000 万件以上の登録数となっている。また、3 位の.net は、2007 年の 7 月に登録数 1,000 万件の大台を突破し、.com、.net に続いて 3 番目の 1,000 万件越えとなった。昨年から引き続き、.de は順調に登録数を伸ばしているが、登録にあたっての制限が緩く、世界中に登録をオープンにしていることや、また、ISP などと提携してユーザのドメイン名登録にも力を入れていることなどが、大きく影響しているものと思われる。
また、昨年からの大きな動きとしては、.cn の登録数がかなりの伸びを示していることが特筆できる。昨年度の調査では、約 180 万件の登録数で、ccTLD 全体の中では 5 番目の登録数だったが、2008 年 1 月時点の登録数は 900 万件を突破しており、ccTLD の中では.de に次いで 2 番目、gTLD を含めても.com、.de、.net に続いて 4 番目の登録数を誇るまでになっている。しかも、他の TLD に比べて.cn の登録数の伸びは著しいものがあり、このままのペースで増え続ければ、2008 年度の早い内、おそらく第 1 四半期中には登録数 1000 万件を突破し、.net の登録数を超えるのも時間の問題であるように思われる。この.cn の驚異的な登録数増加であるが、中国政府が中国語ドメイン名の普及を目指して積極的に活動を行っていることや、CNNIC が初年度の登録料を 1 元とするキャンペーンを期間限定で行い、またそのキャンペーンを度々延長していることなどが大きく影響しているものと思われる。
なお、昨年新たに登録が開始され、かなりの登録数の伸びを見せた.eu であるが、事前登録の段階で 200 万件近い登録を集め、昨年の調査の時点で約 250 万件の登録数となっていたことからすると、2008 年 2 月時点で約 270 万件というのはやや意外な数字である。これは、優先登録機関の開始から先願登録開始直後にかけて、.eu の登録を希望しているユーザが希望するドメイン名をほぼ登録し終わってしまい、需要が一息ついたからだと考えてもいいのではないだろうか。
新 gTLD の中では.mobi が順調に登録数を伸ばしている。昨年度の調査では「登録開始後数ヶ月の伸びには目を見張るものがあるが、この増加ペースがどこまで続くのかは不明」と

13

していたが、結果としては今年に入っても順調に登録数を伸ばすこととなった。昨年度の調査時点の 37 万件からほぼ倍の登録数とし、.mobi よりも先に登録受け付けを開始した.name の登録数を遙かに上回るほどになった。それ以外の TLD に関しては、二極化の傾向が見られ、下記の表でいうと.cat までと.coop からで大きく傾向が異なっている。前者はどの TLD に関しても、多少の程度の差はあれ順調に登録数を伸ばしていっているが、後者に関しては、昨年度の調査時点からほぼ横ばいの登録数となっている。これは、後者の TLDが新 gTLD の中でも比較的狭い範囲を登録対象としていることから、ある意味当然の状況と言えなくもない。したがって、今後も傾向としては変わらないのではないかと思われる。
表2：

gTLD別登録数ランキング （2007 年 10 月現在）5

順位

gTLD

1

.com

（商業組織用）69,621,530

2

.net

（ネットワーク用）

10,398,432

3

.org

（非営利組織用）

6,325,476

4

.info

（制限なし）

4,956,218

5.biz（ビジネス用）1,917,559

6

.mobi

（モバイル関係用）

722,758

7.name（個人名用）

476,416

8.travel（旅行関連業界用）

28,5299.cat（カタロニア言語／文化用）

24,07910.coop（協同組合用）

6,217

11

.pro

（専門家用）

6,009

12

.aero

（航空運輸業界用）

4,881

13

.museum（博物館、美術館等用）

2,855

登録数

※データが公開されていない.edu/.gov/.int/.mil は除く。

5

登録数データは各レジストリ（またはスポンサ組織）がICANNに提出する月間報告書<
http://www.icann.org/tlds/monthly-reports/>に基づくが、報告書の公開が数ヶ月遅れとなるため、2007
年 10 月時点（.aeroについては 2007 年 9 月時点、.museumについては 2005 年 12 月時点）のデータが最新のものとなっている。

14

表3：

ccTLD別登録数ランキング （2008 年 2 月現在）6

順位

ccTLD

1

.de

（ドイツ）

11,771,605

2

.cn

（中国）

9,001,993

3.uk（イギリス）

6,486,829

4.eu（欧州連合）

2,760,034

5.nl（オランダ）

2,736,351

6.it（イタリア）

1,482,092

7

.us

（米国）

1,386,4128.br（ブラジル）

1,238,113

9.ru（ロシア連邦）

1,070,482

10

.ch

（スイス）

1,056,751

国/地域

登録数

1-2 IP アドレス
IP を使用してインターネットに接続するコンピュータを識別するための番号が、IP アドレスである。
「IP」とは「Internet Protocol」の略であり、インターネットで用いられる、OSIのネットワーク層に対応するプロトコルである。現在広く用いられている IP は、「バージョン 4(IPv4)」と呼ばれるものであるが、アドレスの空間を大幅に拡張した「バージョン6(IPv6)」の利用も進んできている。
IPアドレスは、コンピュータのネットワークインターフェース毎に割り当てられる。IPのバージョン毎に特に区別する際は、IPv4 アドレス、IPv6 アドレスと呼ぶこととなる。IPv4は 32 ビットのアドレス空間（232個のアドレス）を持つが、IPv6 は 128 ビットのアドレス
空間（2128個のアドレス）を持つ。

1-2-1 IPv4 アドレス
前項で述べた通り、IPv4 アドレスは 32 ビットのアドレス空間を持つ。2 進数では 32 桁の数字（0 か 1）で表されるので、IPv4 アドレスの総数は 232個となり、10 進数表記すると、
約 43 億個7となる。IPv4 アドレスの表記は、一般に、8 ビットごとに 4 つに区切って 10 進
67

登録数データは各レジストリの公開データに基づく。
正確には、232=4,294,967,296 個となる。

15

数に直し、ピリオドで区切った表記が用いられる。
例えば、11000000.10101000.00000000.00000001 は、192.168.0.1 と表記される。この表記で表すと、
IPv4 アドレスの範囲は 0.0.0.0 から、255.255.255.255 までということになる。
IPv4 アドレスには、プライベートアドレスとグローバルアドレスという 2 つの概念がある。
前者はインターネットに直接接続されていないネットワークで自由に使って良いとされる
アドレスであり、それ故に複数の利用者で重複があっても問題はない。一方、後者はインターネットに直接接続されているネットワークで、コンピュータを一意に識別するために付けられるアドレスであり、それ故に複数の利用者間での重複は許されない。グローバル
アドレスの一意性を保つことは、IP アドレス管理組織の重要な役割である。
IPv4 アドレスは、ネットワークを識別する部分（ネットワーク部）と、そのネットワーク
内のホストを識別する部分（ホスト部）に分かれている。以前はこの境界を IPv4 アドレスの上位の数ビットによって決定する方式が採られていた。これがクラスと呼ばれる概念である。
クラスはその規模によって、主に「クラス A」「クラス B」「クラス C」に分けられる。これらを 10 進数のアドレスで表記した場合、それぞれのクラスの上位ビット、アドレス範囲、
ネットワーク部のビット数と利用できる最大ホスト数は以下の表のようになる。
表4： クラスフルの割り当て
アドレス範囲ネットワーク部のビット数

クラス

上位ビット

A

0

0.0.0.0 – 127.255.255.255

8 ビット(16,777,216)B

10128.0.0.0 – 191.255.255.255

16 ビット(65,536)C

110

192.0.0.0 – 223.255.255.255

24 ビット(256)（ホスト数）

この他に、マルチキャスト用の「クラス D」、実験用の「クラス E」というアドレスも存在する。クラス E は長らく議論の対象にすらなっていなかったアドレスだが、IPv4 アドレスの枯渇が叫ばれるようになった 2005 年以降、このクラス E アドレスをグローバルアドレス、もしくはプライベートアドレスとして利用できないかという議論がなされるようになった。
この議論はまだ続いており（2008 年 2 月 18 日現在）、結論は出ていない。

16

表5： クラス D、クラス E
クラス

上位ビット

アドレス範囲

D

1110

224.0.0.0 – 239.255.255.255

E

1111

240.0.0.0 – 255.255.255.255

上記で説明したような方式を「クラスフル」と呼ぶ。以前は、ネットワークの規模すなわ
ちネットワークに接続されるコンピュータの数に応じ、クラスのアドレスが分配されていた（これを「クラスフル」の割り当てという）しかし、この方式は世の中のネットワークの規模をあまりに大雑把に分けており、実際には膨大な余剰アドレスを生む原因となった。
こうした分配は「歴史的な割り当て（historical assignment）」とも呼ばれ、現在の分配とは区別して語られている。
そこで現在では、8 ビットごとという単位に縛られることなく、任意のビットでネットワー
ク部とホスト部の境界を定めることができる「クラスレス」と呼ばれる技術が用いられるようになった。クラスレスでは、ネットワーク部のビット長（プリフィクス長という）を明示する必要があるため、アドレスのあとに / で区切ってプリフィクス長を表記する。
表6： クラスフル表記の例
192.168.0.0/28 ＝ 192.168.0.0〜192.168.0.15 （16 ホスト）
→ネットワーク部 28 ビット、ホスト部 4 ビット
192.168.0.0/27 = 192.168.0.0〜192.168.0.31（32 ホスト）
→ネットワーク部 27 ビット、ホスト部 5 ビット
この技術によってネットワークの規模に応じた適切なアドレスの分配ができるようになり、
クラスフルの概念は過去のものとなった。現在 IPv4 アドレスはクラスレスの考え方によって分配されており、IPv4 アドレスの節約に大きく貢献している。しかし 2005 年前後から、
IPv4 アドレスの枯渇時期についての予想及びその分析が各方面から発表されるようになり、再び IPv4 アドレスの枯渇が現実感を帯びて語られるようになった。

17

以下に IPv4 アドレス割り振り量が多い上位 10 ヶ国を示す。詳細については第 4 部の参考資料に詳しくまとめているので、そちらもあわせて参照いただきたい。

米国
日本

141,623,552

中国

136,644,864

欧州連合

120,351,708

イギリス

83,614,522

ドイツ

72,429,360

カナダ

71,920,640

フランス

67,803,168

韓国

59,456,256

オーストラリア1,409,909,248

33,460,736
0200,000,000

400,000,000

600,000,000

800,000,000 1,000,000,000 1,200,000,000 1,400,000,000 1,600,000,000

1-1-2-2 IPv6 アドレス
IPv6 アドレスは 128 ビットからなるアドレスであり、単純計算ではおよそ 43 億の 4 乗個のアドレスが利用可能となる。32 ビットからなる IPv4 アドレス（約 43 億個）よりも格段に多くのアドレスが利用可能であることがその最大の特徴である。
IPv4 アドレスは 8 ビットごとに 4 つに区切って 10 進数に直し、ピリオド(.)で区切った表記を行うが、IPv6 アドレスではこの表記だと長くなり過ぎるので、16 ビットごとに 8 つに区切って 16 進数に直し、コロン(:)で区切った表記を行う。その際、連続して 0 が続く場合、表記を省略できるというルールがある。また、IPv4 と同様にプリフィクス長を表すための「/」を使った表記も使われている。IPv6 アドレスで「/32」と表記した場合、ネットワー
ク部が 32 ビット、ホスト部が 96 ビットとなるので、ホスト数（アドレス数）としては、296個となる。現在、一般のISPが受けるIPv6 アドレス割り振りで最も小さな単位がこの「/32」である。
当初、ISPからユーザへの割り当てサイズは一般的には「/48」とアドレス管理ルール（アドレスポリシー）で定められていた。しかし個人ユーザや企業ユーザの別を問わず一律に/48（280個）を割り当てることが果たして本当に妥当なのかという疑問が呈され、2006 年にはこのアドレスポリシーを変更する提案が出され、APNIC地域においても変更が承認されて

18

いる。
以下に IPv6 アドレス割り振り量が多い上位 10 カ国を示す。詳細については第 4 部の統計
資料をあわせて参照いただきたい。
（単位：/32）

9,658.00

ﾄﾞｲﾂ(DE)
ﾌﾗﾝｽ(FR)8,304.00

日本（JP）

8,300.40

ｵｰｽﾄﾗﾘｱ(AU)8,214.10
6,157.00

欧州連合（EU）

5,191.00

韓国（KR）

4,134.00

ｲﾀﾘｱ(IT)
台湾（TW）

2,309.00

ﾎﾟｰﾗﾝﾄﾞ(PL)2,089.00

ｲｷﾞﾘｽ(GB)0.00

1,153.00
2,000.00

4,000.00

6,000.00

8,000.00

10,000.00 12,000.00

19

1-3 AS 番号「AS」とは「Autonomous System」の略であり、日本語では「自律システム」とも呼ばれる。AS は、統一された運用ポリシーによって管理されたネットワークの集まりであり、
BGP(Border Gateway Protocol)のような外部ネットワークとの経路制御を行うプロトコル
による管理対象となる。
通常、規模の大きい ISP のネットワークは固有の AS を形成する。
AS 番号は AS に割り当てられた識別番号である。AS 番号は従来 2 バイト（10 進数で 0〜65535）の範囲で運用されてきたが、AS 番号への需要の増加に伴い 4 バイト（10 進数で 0〜4294967295）に拡張された。4 バイト AS 番号は 2007 年 1 月 1 日から各 RIR で配布が始まっており、既にいくつかの組織が拡張された 4 バイト AS 番号の割り当てを受けている。
4 バイト AS 番号は、現在の 2 バイト AS 番号のようにそのまま 10 進数で表記すると桁数が多くなってしまうため、（[ 上位 2 バイトの 10 進数表記）（. 下位 2 バイトの 10 進数表記）]のように、2 バイト毎に区切ってそれぞれをピリオド「.」でつなぐ表記方法が取られている。このように表記すると、4 バイト AS 番号の範囲は 0.0 から 65535.65535 と表される。
以下にいくつか例を示す。
表7： 4 バイト AS 番号表記方法
10 進数表記

4 バイト AS 番号表記

0

0.0

23456

0.2345665535

0.65535

65536

1.0

63346

1.10

4294967295

65535.65535

従来の 2 バイト AS 番号で 23456 と表記されたものは、4 バイト AS 番号表記では 0.23456と表される。逆に、4 バイト AS 番号表記で x.y と表されるものは、従来の 10 進数表記だと、65536*x+y となる。

20

以下に AS 番号割り当て量が多い上位 10 ヶ国を示す。AS 番号の配布状況については、第 4部の参考資料に詳しくまとめているので、そちらもあわせて参照いただきたい。

18,341

米国(US)
2,025

ﾛｼｱ(RU)ｲｷﾞﾘｽ(GB)1,542

欧州連合(EU)

1,492

ｶﾅﾀﾞ(CA)

1,208

ﾄﾞｲﾂ(DE)

1,194

ｳｸﾗｲﾅ(UA)1,152

ﾙｰﾏﾆｱ(RO)969

ｵｰｽﾄﾗﾘｱ(AU)839

ﾎﾟｰﾗﾝﾄﾞ(PL)

804
0

5,000

10,00015,00020,000

1-4 ルートサーバ
1-4-1 ルートサーバの性質
ルートサーバとは DNS(Domain Name System)の最上位に存在し、「ルートゾーン」を管理するネームサーバである。ルートゾーンとは、トップレベルの各ゾーンを管理するネー
ムサーバがどこに位置しているのかを管理しているゾーンのことで、ここには.jp や.com な
どの最上位のドメイン名(TLD)の DNS サーバとその IP アドレスなどが設定されている。
このルートサーバは、DNS の仕組み上非常に重要なサーバであり、ドメイン名を利用する
際には必要不可欠な存在である。一般のユーザのほとんどは、Web サイトの閲覧やメールの送受信など、インターネットを利用する際に IP アドレスではなくドメイン名を利用していると思われるが、実際の通信を行う段階では通信相手の IP アドレスを知ることが必要不可欠であり、そのドメイン名と IP アドレスの対応関係を調べる（これを名前解決という）ために DNS は利用される。したがって、ルートサーバの存在はインターネットの運用にお21

いても大変重要であると言える。
なぜルートサーバが DNS の仕組みにおいて非常に重要かであるが、一般に名前解決を行おうとするアプリケーション等のクライアントはまず自組織のネームサーバに問い合わせを行うが、通常、ネームサーバは自分が管理を行っているゾーンについてしか正しい答えを返すことが出来ない。DNS は分散型データベースであるので、各ネームサーバは自分が管理しているドメイン以外の情報は持っておらず、これは正しい挙動である。しかし、これでは自組織以外についての名前解決が出来ないので、ネームサーバは自分が管理しているドメイン以外に関する問い合わせが来た際には、IP アドレスとドメイン名の対応を返答として返す代わりに、ルートサーバの名前と IP アドレスを返すのである。すると次にクライ
アントはルートサーバに対して同じ問い合わせを行う。ルートサーバは、ルートゾーンの情報だけを管理しているので、直接問い合わせの答えを返すことは出来ないが、各 TLD を管理しているネームサーバについては答えることが出来るので、問い合わせを行ったドメ
イン名の TLD を管理しているネームサーバの名前と IP アドレスを返答として返す。それを受け取ったクライアントは、次に TLD を管理しているネームサーバにまた同じ問い合わせを行い、問い合わせを受けたネームサーバは、今度はその TLD にあるセカンドレベルド
メイン(SLD)を管理しているネームサーバの名前と IP アドレスを返答として返す。このようにクライアントは次々と問い合わせを繰り返していき、最終的には目的の名前を解決することが出来るようになっている。
ちなみに、上記のような「自分が管理していないドメインに関する問い合わせに対しては、ルートサーバの名前と IP アドレスを返答として返す」という挙動を実現するために、世の中に存在する全てのネームサーバはルートサーバの名前と IP アドレスを設定したファイル
をローカルに持っている。これは分散型 DB という DNS の仕組みの中で見ると、例外的ではあるが、このようにローカルにルートサーバの情報を持っていないと「ルートサーバの名前を解決するためにルートサーバに問い合わせる」「ルートサーバに問い合わせをしたい
けれどルートサーバの IP アドレスがわからない」という一種のジレンマが発生してしまうためである。したがって、自ドメイン以外の情報を管理する必要がない DNS の仕組みにおいてこのルートサーバの名前と IP アドレスを設定したファイルだけは別で、ルートサーバの IP アドレスが変更された場合などは、手動でこのファイルを更新する必要がある。
ルートサーバの IP アドレス変更は、頻繁にではないものの、これまでにも何度か実施されており、最近では 2007 年 11 月に L サーバの IP アドレスが変更された。この変更にともない、それぞれの DNS サーバ管理者による、各 DNS サーバがローカルに持つルートサー
バの IP アドレスを設定したファイルの更新が行われた。ただ、実際には全ての DNS サー
バ管理者が更新を行っているとは限らず、一部には更新し忘れられた DNS サーバも存在す

22

るものと思われる。とはいえ、そのことがすぐに名前解決が出来なくなる事態に繋がるわ
けではなく、13 あるルートサーバのうち 1 つの IP アドレスが変更されたとしても、残りの12ｆha の IP アドレスが正しければ、到達できないルートサーバに問い合わせてしまう確率は 13 分の 1 に過ぎず、また、問い合わせに失敗した場合は引き続き別のルートサーバに問い合わせが行われるので、利用者から見れば名前解決にかかる時間がやや増加したように見える程度である。また、DNS にはラウンドロビンと呼ばれる仕組みがあり、応答に時間がかかるルートサーバを避け、より応答の速いルートサーバを選んで問い合わせをするようになっているため、名前解決が遅くなるのも最初の 1 回の問い合わせだけである。さらに、ルートサーバの IP アドレス変更については、移行にかかる時間を越して十分に並行運用の期間が取ってあり、しばらくは古い IP アドレスを利用しても問い合わせが行えるよ
うになっている。今回の L サーバの場合だと、IP アドレスの変更が行われたのは 2007 年
11 月であるが、変更前の IP アドレスを用いた問い合わせが出来なくなるのは、最短でも 6ヶ月後とアナウンスされている。
ここまで説明したように、インターネット上で名前解決を行う際に、自ドメイン以外の名
前を解決する際には、必ずルートサーバへの問い合わせが必要となり、そのルートサーバ
から順次下位のサーバに問い合わせを繰り返していくことで名前の解決が可能となっている。そのため、ルートサーバは非常に重要であると同時に負荷が高く、その負荷を下げるために DNS にはキャッシュという仕組みが採用されている。各ネームサーバやクライアン
トは一度問い合わせを行ったらその結果をしばらく保存しておき、同じ問い合わせが発生した場合には、保存してある結果を利用して実際には問い合わせのための通信を行わないようになっている。このキャッシュという仕組みによって、ルートサーバを初めとした各
ネームサーバの負荷が下がり、より安定した DNS の運用が可能となっている。
一方、安定性という意味ではルートサーバの運用が停止しないことも非常に重要で、上記のキャッシュという仕組みがあるので数時間程度なら特に大きな問題が起こらない可能性が高いとはいえ、ルートサーバが停止すると最終的にはインターネット上の名前解決は自ドメイン内を除いて出来なくなってしまう。
そのため、ルートサーバは世界で 13 用意されており、その全てが停止しない限り名前解決が出来るように配慮されている。13 のサーバは A サーバ(a.root-servers.net)から順番に M
サーバ(m.root-servers.net)までアルファベット順に名前が付けられており、A サーバのデータがマスターであり、B から M サーバまでの残りの 12 のサーバは A サーバのデータのミラーが置かれている。
この 13 という数字は DNS のプロトコルによる技術的制限の上限であり、かつては実際に

23

13 台のサーバしか設置することが出来なかった。もっとも、13 台しか設置できないと言っても、実際に全てルートサーバが止まったことは一度もないわけではあるが、近年はさらなる安定性の向上を目指して、IP Anycast などの技術を利用することによってこの 13 台という制限はなくなっている。この IP Anycast という技術は、同一サービスを提供するノードに同一の IP アドレスを割り当てる技術であり、技術的制限であるルートサーバとして 13の IP アドレスしか設定できないという制限はそのままで、実際には 13 台以上のサーバを稼働させることが出来るようになり、ルートサーバの稼働率をより高め、また各サーバの負荷を下げることが可能となった。
また、13 台という制限が無くなったことにより、世界各地にルートサーバを設置することが出来るようにもなり、その結果各クライアントは（ネットワーク的に）距離の近いネー
ムサーバに対して問い合わせが出来るようになることから、応答性を高めるという目的にも IP Anycast は一役買っている。
なお、上記の IP Anycast などの技術により各地にルートサーバが置かれるようにはなった
ものの、インターネットがアメリカ合衆国において発達した歴史的経緯から、ルートサーバの大半は米国国内に置かれている。ちなみに、日本国内においては以前から M サーバがWIDE Project により運用されており、また近年では IP Anycast の導入によって、F サー
バおよび I サーバ、J サーバ、K サーバなどが日本国内でも運用されるようになっている。

1-4-2 ルートサーバの配置状況
2008 年 2 月時点でのルートサーバの配置状況は以下の通りとなっている。
表8： ルートサーバの配置状況8

サーバ
A
B

オペレータ
VeriSign, Inc.
Information Sciences
Institute

所在地
Dulles VA
Marina Del Rey CA

IP アドレス
IPv4: 198.41.0.4
IPv6: 2001:503:BA3E::2:30
IPv4: 192.228.79.201
IPv6: 2001:478:65::53

Herndon VA;
C

Cogent Communications Los Angeles;
New York City;8

出典：http://www.root-servers.org/

24

192.33.4.12

Chicago

D
E

University of Maryland
NASA Ames ResearchCenterCollege Park MD

128.8.10.90

Mountain View CA

192.203.230.10

Ottawa; Palo Alto;San Jose CA;
New York City;San Francisco;
Madrid; Hong Kong;
Los Angeles; Rome;
Auckland; Sao Paulo;
Beijing; Seoul;
Moscow; Taipei; Dubai;
Paris; Singapore;
F

Internet Systems
Consortium, Inc.

Brisbane; Toronto;
Monterrey; Lisbon;
Johannesburg;

IPv4: 192.5.5.241
IPv6: 2001:500::1035

Tel Aviv;Jakarta;
Munich;Osaka;
Prague; Amsterdam;
Barcelona; Nairobi;
Chennai; London;
Santiago de Chile;
Dhaka;Karachi;Torino;
Chicago; Buenos Aires;
Caracas; Oslo;
Panama; Quito
G
H

U.S. DOD Network
Information Center

Columbus OH

U.S. Army Research Lab Aberdeen MD

192.112.36.4
IPv4: 128.63.2.53
IPv6: 2001:500:1::803f:235

25

Stockholm;
Helsinki; Milan;
London; Geneva;
Amsterdam; Oslo;
Bangkok; Hong Kong;
Brussels; Frankfurt;
Ankara; Bucharest;
Chicago;I

Autonomica/NORDUnet

Washington DC; Tokyo;
Kuala Lumpur;

192.36.148.17

Palo Alto; Jakarta;
Wellington;
Johannesburg; Perth;
San Francisco;
New York; Singapore;
Miami; Ashburn (US);
Mumbai;
Beijing; Beijing; Manila;
Doha
Dulles (3 locations);
Vienna; Miami, Atlanta;
Seattle; Chicago;
New York;
Los Angeles;
Mountain View;
San Francisco;
Dallas (US);J

VeriSign, Inc.

Amsterdam (NL);
London (UK);
Stockholm (2 locations)(SE); Tokyo (JP);Seoul (KR);Bejing (CN);Singapore (SG);Dublin (IE);
Kaunas (LT);26

IPv4: 192.58.128.30
IPv6: 2001:503:C27::2:30

Nairobi (KE);Montreal, Quebec (CA);
Sydney (AU);Cairo (EG);Warsaw (PL); Brasilia;
Sao Paulo (BR);
Sofia (BG); Prague (CZ);
Johannesburg (ZA);
Toronto (CA);Buenos Aries (AR);Madrid (ES);Vienna (AT);London (UK);
Amsterdam (NL);
Frankfurt (DE);Athens (GR);Doha (QA);
Milan (IT);Reseaux IP Europeens
K- Network
Coordination Centre

Reykjavik (IS);Helsinki (FI);IPv4: 193.0.14.129

Geneva (CH);

IPv6: 2001:7fd::1

Poznan (PL);
Budapest (HU);
Abu Dhabi (AE);Tokyo (JP);Brisbane (AU);Miami (US); Delhi (IN);
Novosibirsk (RU)

Internet Corporation
L

for Assigned Names
and Numbers

Los Angeles(US);Miami(US)Tokyo(3); Seoul (KR);M

WIDE Project

Paris (FR);San Francisco, CA

199.7.83.42

IPv4: 202.12.27.33
IPv6: 2001:dc3::35

27

28

2

インターネット資源管理体制の現状
及びそれに関する議論の動向

29

30

2 インターネット資源管理体制の現状及びそれに関する議論の動向
2-1 インターネット資源管理体制の概要
ドメイン名は IP アドレスやプロトコル番号などと同様に、インターネット上の論理資源の一つであり、インターネット上で一意（unique）である必要がある。また、2011 年にも在庫が枯渇するとされている IPv4 アドレスほどではないが、ドメイン名もラベルに使用できる文字数には技術上の制限があるなど、取り得る文字列の組み合わせは有限である。
先に述べたとおり、「インターネット上で一意である」ことは非常に重要である。複数の同一ドメイン名が存在しうる事態となってしまうと、通信相手はどちらを相手として通信を行えばよいのかわからなくなってしまう。たとえば、同じドメイン名を持つ Web サイトが2 つ存在するようなことが起これば、通信を行いたいサイトを特定する術がなくなってしま
い、ユーザは非常に混乱することになるだろう。
このような理由から、インターネット上における資源管理に関しては、一元的に管理する組織がどうしても必要であり、そのような管理を行っているのが ICANN(The Internet
Corporation for Assigned Names and Numbers)である。ICANN は IP アドレスやプロト
コル番号などと同様に、ドメイン名も一元的に管理している。実際にドメイン名の管理を行っている各 gTLD・ccTLD レジストリに対しては、ICANN からそのドメイン名の管理が委任されており、その委任された権限に基づいて各レジストリは各 TLD を管理している。
とはいえ、ICANN が当初からドメイン名の管理を行っていたわけではない。ICANN が設立される以前は、南カリフォルニア大学のジョン・ポステル氏を中心に、米国政府の援助も受けつつも基本的に技術者や研究者のボランティアで運営されていた IANA(Internet
Assigned Numbers Authority) がインターネット資源管理の責任を担っていた。しかし、1990 年代後半になるとドメイン名の登録数の爆発的増加にみられるようにインターネット
が急速に発展し、社会への影響力が非常に大きくなり、また NSF（全米科学財団）からの委託を受けてドメイン名の管理を行っていた NSI（ネットワークソリューションズ社）に対して「独占的」との批判が高まる状況となった。
このような状況を受けてインターネットにおける資源管理のあり方についての議論が高まる中で発表された、米国政府による「インターネットの名前およびアドレスの技術的管理の改善についての提案（通称：グリーンペーパー9）」や、それに対するさまざまな批判や意9「インターネットの名前およびアドレスの技術的管理の改善についての提案」
http://www.nic.ad.jp/ja/translation/icann/bunsho-green.html

31

見を反映して再度米国政府が作成した「インターネットの名前およびアドレスの管理（通称：ホワイトペーパー10）」の発表を経て、インターネットの資源管理については、新しい非営利法人を作り、その法人の管理の下で民間主導・ボトムアップという方針に基づき管理されていくことになった。
この非営利法人が ICANN であり、IANA はその役割を ICANN に引き継ぎ、現在ではICANN の資源管理における機能の名称としてその名前を残している。
このように、インターネットの資源管理はカリフォルニア州の非営利法人である ICANN が行っており、米国政府も民間主導の資源管理を認めているが、一方でインターネットが米国政府の投資の下で成立したという主張は崩しておらず、インターネットの元々の管理権
限は米国政府が有しており、それを民間組織である ICANN に委譲するのだというスタンスをとっている。
事実、現在のルートゾーンの管理権限は米国商務省から ICANN に対して契約に基づき期限付きで認められており、ルートゾーンの変更にあたっても商務省の最終承認が必要となっている。もちろん、承認といってもあくまで形式的なものであり、実際に ICANN 側が行おうとした変更に対し商務省が承認しなかった例は聞かないが、一方で形式的とはいえルー
トゾーンの管理というドメイン名の管理における根幹の部分に関して、米国政府が一定の権限を今なお有しているのもまた事実である。
ただし、インターネットの資源管理に関して、いつまでも米国商務省が権限を持つと定められているわけではない。ICANN と商務省の間の覚書では、DNS の管理権限は最終的にICANN に委譲されることが定められており、覚書中に定められている管理権限移管のための条件が整えば ICANN に全ての管理権限が移管されることが規定されている。逆に言えば条件が整わない限りは移管されないということであるが、両者の間の覚書は期限を延長する形でたびたび改訂されており、最新の改訂は「Joint Project Agreement の変更」という題目で、2006 年 9 月 29 日に行われている。この最新の覚書では、2009 年 9 月 30 日が新
たな期限として定められており、ICANN としてはこの期日までに条件を整え、米国商務省からの管理権限の移管を実現させるべく活動していくことになる。2007 年 10 月から 2008
年 2 月にかけ、この延長された覚書に関する中間評価のためのパブリックコメント募集がされている。その内容については、項を改めて報告する。

10 「インターネットの名前およびアドレスの管理」
http://www.nic.ad.jp/ja/translation/icann/bunsho-white.html

32

2-1-1 IP アドレスの管理体制の現状
IP アドレス、及び AS 番号の分配は階層的に行われている。管理階層の最上位となっているのが ICANN(Internet Corporation of Assigned Names and Numbers)/IANA (Internet
Assigned Numbers Authority)であり、次の階層がアドレス管理において実質的に支配的な役割を果たす 5 つの地域インターネットレジストリ（RIR: Regional Internet Registry）と、一部地域の RIR 配下に存在する国別インターネットレジストリ（NIR: National Internet
Registry）である。
RIR は ICANN/IANA からある程度大きなアドレスブロックの割り振りを受け、それをさらに下位の階層へ再分配する。現在定められているアドレスポリシーでは、ICANN/IANAから RIR へは、IPv4 アドレスでは/8 単位で、IPv6 アドレスでは/12 単位で割り振りが行われる。
RIR/NIR はさらに次階層に位置するインターネットレジストリ（LIR：後述）に対して、申請に応じて IP アドレスの分配を行う。RIR は事前に決められた公開ポリシーに従って申請元の需要を精査した上で、正当化された需要に応じたアドレスの分配を行う。分配の最小単位は、IPv4 では/22 もしくは/21（地域によって異なる）、IPv6 では/32 である。
RIR の配下で、特定の国内の IP アドレス、AS 番号の管理を行っているのが国別インターネットレジストリ（NIR）である。NIR は地域内の文化的・言語的差異という特殊事情に特に対応するために存在し、それ故に特に使用言語が多様なアジア地域において発展した。
日本国内でIPアドレス、AS番号の管理を行っているのは、社団法人日本ネットワークイン
フォメーションセンター（JPNIC）である。JPNICは、ここでいうNIRにあたる。アジア
地域のNIRは、以前はAPNICからまとまった量のIPアドレスの割り振りを受け、そのアドレスからLIRに対して再割り振りを行っていた。しかし、そうした運用だと各NIRに分割損としての在庫が残ることから、APNICの在庫から直接NIR配下のLIRに対してアドレス割
り振りを行う運用に変更された。こうした運用は、APNICのポリシー文書として規定されている。11
RIR や NIR から IP アドレスの分配を受ける ISP をローカルインターネットレジストリ（LIR: Local Internet Registry）といい、この LIR がユーザに対して IP アドレスの分配を行うこととなる。従って、LIR は IP アドレス管理構造の一翼を担うと言える。実際にエンドユーザの IP アドレスの需要を把握し、割り当てを行う作業は LIR が行うことから、
11 http://www.apnic.net/policy/operational-policies-nirs.html

33

LIR 無しでは IP アドレスの管理は成り立たないと言っても過言ではない。
日本国内において LIR の役割を担っている組織は 「IP アドレス管理指定事業者」と呼ばれている。 IP アドレス管理指定事業者は LIR となるための一定の基準を満たし、 JPNICから IP アドレス登録管理業務の委任を受けている組織である。日本国内における IP アド
レスの分配は、一部例外を除き、 IP アドレス管理指定事業者が JPNIC から委任を受けた
IP アドレスの中から顧客や自組織のネットワークに対して行われている。
これまで説明した IP アドレス・AS 番号の管理構造を、以下に図で示す。
図1： IP アドレス・AS 番号の管理構造

2-1-2 ドメイン名の管理体制の現状
ドメイン名の管理体制においても、IP アドレスなどと同様に、ICANN が階層構造の頂点に位置し、管理を行っている。しかし、実際のドメイン名の管理については、各 gTLD・ccTLD
ごとにレジストリに管理が委任されており、実際の管理は各レジストリが行っている。また、レジストリは資源管理に特化しており、ユーザとの窓口となるのはレジストラやリセ
ラと呼ばれる組織である。
ドメイン名の管理についても、他のインターネット資源同様、世界中で一意であることが保証されることが求められており重複は許されない。具体的には同一の階層では同じラベ34ルを持つドメイン名は存在できないことになっている。
その一意性を保証するために、TLD ごとにレジストリは 1 組織となっているのが普通である。このようにレジストリは自然独占の傾向を持つことになるが、これはデータベースの一元管理という目的から考えるとある程度やむを得ないことといえる。
このような自然独占を生じさせる仕組みの一方で、ドメイン名の管理構造においては、
ICANN 設立の経緯などからもわかるように、積極的に競争原理も導入されている。これは、公正・中立の原則は守りつつも、サービスや価格面でユーザである登録者が不利益を被らないようにすることが目的である。
ドメイン名の管理構造におけるこのような競争原理の中でおそらく一番有名なものが、
gTLD などに導入されている「レジストリ＝レジストラモデル」である。これはデータベースの一意性を守るためにレジストリに独占的な管理を認めるものの、一方でレジストリはレジストリデータベースの管理に専念し、登録の受け付けなどのサービスはレジストラが提供することにより、一定のルールの下でレジストラ同士で自由に競争を行わせることによって、より良いサービスを登録者が受けられるようにしようという考え方である。
さて、このように IP アドレスの管理構造とは異なり、積極的に競争原理を導入しているドメイン名登録の世界であるが、やはり公平・中立を守るために一定のルールは必要であり、競争が行われる中でもそのルールが守られるようにする仕組みが求められる。いくら安価
な登録サービスを提供する業者が現れても、それが既存の枠組みやユーザにとって悪影響を与えるものであってはいけないし、本来ユーザが受けられるサービスが低価格と引き替
えに受けられないということであってはならないからである。
そういった、レジストリやレジストラの権利と責務、言い換えればレジストリが守らなけ
ればならないルールや各レジストラが守らなければならないルールをポリシーと呼ぶが、これらのポリシーの制定のされ方は gTLD と ccTLD では若干異なっている。次はこのポリシー策定に関する仕組みについて解説していきたい。
・gTLD の管理構造
まず、gTLD の場合は少し特殊な事情があり、RGP(Redemption Grace Period：削除済ドメイン名のための「請戻猶予期間」)や、AGP(Add Grace Period：登録猶予期間)、WLS(Wait
Listing Service)など、gTLD 関連のポリシーはレジストリ・レジストラ双方に深く関わってくるものが大半である。ポリシーを策定するにあたっては、レジストリとレジストラが35

お互いに納得できるものである必要がある。
したがって、gTLD のポリシー策定にあたっては、レジストリ・レジストラのどちらか一方だけで決定することはできず、一般的に ICANN の支持組織のひとつである GNSO
（GenericNames Supporting Organization「分野別ドメイン名支持組織」）でレジストリ・レジスト
ラ双方の議論によって検討される。まず、GNSO 自らの発議、もしくは理事会からの要請に従いポリシー策定の是非やその内容について検討し、その結果を理事会に提案する。そして、その内容を理事会が承認すれば正式なポリシーとなる。また、理事会は GNSO に提案するだけでなく自らポリシーを策定することも可能となっている。
なお、GNSO は、GNSO 評議会と「gTLD レジストリ部会」、「レジストラ部会」、「ビジネ
スユーザ部会」、「非商用ユーザ部会」、「知的財産権関係者部会」、「ISP 部会」の 6 部の部会から成り立っており、2008 年 2 月現在、GNSO 評議会のメンバーは以下の通りとなっている。
表9： GNSO 評議委員一覧

選出母体

氏名

出身

チェア

Avri Doria

北アメリカ

ビジネスユーザ部会

Philip Sheppard

ヨーロッパ

Mike Rodenbaugh

北アメリカ

Bilal Beiram

アジア太平洋Chuck Gomes

北アメリカ

Jordi Iparraguirre

ヨーロッパ

Edmon Chung

アジア太平洋Tony Harris

ラテンアメリカ

Tony Holmes

ヨーロッパ

Greg Ruth

北アメリカ

Robin Gross

北アメリカ

Norbert Klein

アジア

Carlos Souza

ラテンアメリカ

Tim Ruiz

北アメリカ

Thomas Keller

ヨーロッパ

Adrian Kinderis

アジア太平洋gTLD レジストリ部会

ISP 部会

非商用ユーザ部会

レジストラ部会36

知的財産権関係者部会

指名委員会選出委員

リエゾン

Ute Decker

ヨーロッパ

Cyril Chua

アジア太平洋Kristina Rosette

北アメリカ

Jon Bing

ヨーロッパ

Avri Doria

北アメリカ

Olga Cavalli

ラテンアメリカ

Suzanne Sene

GAC

Alan Greenberg

ALAC

これらの手順を経て定められたポリシーは、gTLD レジストリおよびレジストラにとっては拘束力をもったルールとなり、必ず守られることになる。なぜならレジストリやレジスト
ラは ICANN との契約に基づいて業務を行っており、その契約の中でポリシーの遵守もレジ
ストラやレジストリの責務として定められているからである。もし守らない場合は、その契約の条項に基づいて契約解除も含めた何らかのペナルティが課させられることになる。
一方、このように ICANN との契約に基づき多くの制約が課されており、ICANN で定められたポリシーに対しても厳格に遵守を求められるレジストリやレジストラと違い、リセラ
は直接的にポリシーに縛られることはない。これは、リセラは ICANN とは何の契約も結んでいないことが一般的なため、直接 ICANN によって定められたポリシーに従う義務は無いためである。とはいえ、ほとんどのリセラはどこかしらかのレジストラの下に入って業務を行っているため、その上位レジストラが影響を受けるポリシーについては、リセラも同じような影響を受けると考えて良い。また、たとえリセラ自身はポリシーに従う必要がな
く違反をしたところで ICANN から処罰されないとしても、レジストラはポリシーに縛られるため、そのようにポリシー違反をするリセラと契約を継続するとは考えにくい。そのような意味では、リセラにも間接的にはポリシーに従う強制力が働いているとも言える。
・ccTLD の管理構造
一方、ccTLD に関しては gTLD とは大きく雰囲気が異なる。
元々、ICANN の設立以前から IANA から直接管理を委任されていた ccTLD も多く、そのような歴史的経緯から ccTLD については、各国・地域による独自のポリシー策定が認められている。
また、GNSO のように各 ccTLD 管理者が集まって統一されたポリシーを策定する場も無い。
37

一応、GNSO にならって ccNSO(Country Code Names Supporting Organization：国コードドメイン名支持組織))という支持組織が ICANN の内部に設立されたが、元々ccTLD の管理者の中には ICANN の中央集権的な管理体制に対して否定的な感情を抱いている者もまだまだ多く、また金銭的な負担の問題等からも、全ての ccTLD 管理者が参加するという状
況にはいまだなってはいない。
とはいえ、最近では少しずつ ccNSO に参加する ccTLD 管理者の数も増えてきており、一時期に比べると随分と ccNSO でポリシー策定を行うための状況は整いつつある。しかしながら、ccNSO で ccTLD 共通のポリシーを策定するようになるにはまだもう少し時間がかかりそうである。また、もし仮に全ての ccTLD 管理者が ccNSO に参加するようになったとしても、ccTLD の管理には各国・地域ごとの言語や文化の問題、歴史的背景などの違いか
ら、統一的なルールを作るのが難しい部分も残るだろう。そのような点を考慮すると、
GNSO とは違い、全ての分野にわたるポリシーを ccNSO で策定するのではなく、各 ccTLD
で共通であることが求められる部分については ccNSO で策定し、各国・地域の事情に合わせた方がよい部分は各 ccTLD の裁量に任せるという方向性になるのではないだろうか。そういう意味では、従来通り ccTLD については各 ccTLD ごとに独自にポリシーを策定するという、大元の部分は大きくは変わらないのではないかと思われる。
・ICANN/IANA
ドメイン名の管理体制における ICANN(The Internet Corporation for Assigned Names
and Numbers)の関わりは IP アドレスやプロトコルポート番号といった他の分野に比べ、比較的大きいといえる。
これは ICANN の設立経緯とも深く関わっており、ICANN が設立される以前は IANA が(Internet Assigned Numbers Authority) がインターネット資源管理の責任を担っていたわけだが、1990 年代後半になると、・.com ドメイン名の登録数の爆発的増加に象徴的に見られるようにインターネットが社会へ急速に浸透したこと
・当時 NSF からの委託を受けて.com ドメイン等の管理を行っていた NSI に対し、独占だとの批判が高まったこと・gTLD をもっと増やすべきだとの意見が強まったこと・サイバースクワッティングへの対策が強く求められていたことなどの複合的な要因から、今後、インターネット資源の世界規模での調整をどのように行38

えばよいかが問題として取り上げられるようになり、それらの問題を解決するために世界中で議論が行われた結果、最終的に米国政府から発表されたホワイトペーパーにより
ICANN の設立へと繋がることとなった。現在、IANA は ICANN の機能のひとつとして存在しており、そう言う意味では「ICANN＝IANA」と言えなくもないが、厳密に言えば
ICANN の業務と IANA の業務は区別されるべきものである。
このような経緯で ICANN が設立されたわけであるが、当時問題とされたことの多くがドメイン名と関連しており、それらの問題に対処するために設立された組織である ICANN が、
ドメイン名とより深く関わりを持つことはある意味当然と言える。
次に実際に ICANN がドメイン名の分野において果たす役割であるが、まずは上記の「gTLDをもっと増やすべき」という問題への対応として行われた、新 gTLD の承認作業が挙げられる。ICANN が設立されて以降、それまで 7 つだった gTLD は現在では 18 となり、さらに現在も新たな gTLD についての導入についてその基準などが議論されている。
またこれによって新設された gTLD をはじめ、各 gTLD のレジストリはレジストリ業務を行うにあたって ICANN と契約を結ぶことが必要とされており、VeriSign 社をはじめとした各 gTLD レジストリは ICANN と契約を結んでいる。これらの契約は無期限ではなく、2005 年に.net のレジストリ業務において ICANN と VeriSign 社の間の契約が更新されたよ
うに、一定期間毎に見直しが行われることになっている。
一方、ccTLD については全てのレジストリが ICANN と契約を結んでいるわけではない。
歴史的な経緯などから、ccTLD の管理権限は ICANN 設立以前に IANA から個人に委任されていることも多く、お互いの権利と責務を明確にするためにも ICANN と ccTLD 管理者の間で契約締結を進めようという動きがある。この動きの中には「アカウンタビリティ・
フレームワーク」というレターの取り交わしも含まれるが、これについては別項で取り扱う。
レジストリの監督以外に ICANN が果たす責務としては、レジストラの管理も挙げられる。
ドメイン名市場の独占に対する対応として、ICANN は gTLD の管理にレジストリ-レジス
トラモデルと呼ばれる仕組みを導入した。これはドメイン名の登録はレジストリではなくレジストラと呼ばれる業者が行い、そのレジストラ同士に自由に競争を行わせることにより、ユーザが価格やサービス面でのメリットを享受できるようにしようという仕組みである。
gTLD の登録業務を行おうとするレジストラは、レジストリのみならず ICANN とも契約を39

する必要があり、ICANN が定めた様々な規則やポリシーを遵守することが求められる。これは競争環境の導入を行いつつも、ユーザが不利益を被るような不正等がレジストラによって行われないようにするためである。
また、ICANN は gTLD に関する各種ポリシーの策定にも関わっている。
たとえば、登録者やレジストラによるミス、または不正行為(ドメイン名ハイジャッキング
等)などの理由で、 ドメイン名が登録者の意図によらず削除されてしまった場合に、 登録者を救済する目的で導入された Redemption Grace Period; RGP(削除済ドメイン名のための「請戻猶予期間」)や、一定期間内であれば登録を取り消すことができる Add Grace Period;
AGP(登録猶予期間)、登録者が自由にレジストラ間でドメイン名を移転できるレジストラ変更のポリシーなどが例として挙げられる。
・レジストリ
レジストリとは、ドメイン名の登録管理機関であり、主な役割は各 TLD における登録ドメ
イン名のデータベースを管理することである。
ドメイン名は世界中で一意であることが求められることから、そのデータベースは一元管理される必要があり、よってレジストリは自然独占の性質を持っている。したがって、レ
ジストリは 1 つのトップレベルドメインにつき 1 つしか存在しない。
レジストリには、大きくわけて gTLD レジストリと ccTLD レジストリがあり、その大きな違いは ICANN との関わり方の違いである。gTLD レジストリは ICANN との契約が必須であり、レジストリとして業務を行うには ICANN の承認が必要であるが、ccTLD レジスト
リの多くは、ICANN 設立前に IANA から直接管理権限の委任を受けているなどの歴史的経
緯から、ICANN とは直接契約関係には無いレジストリが大半である。
これは ICANN の資金的な問題にも影響を与えており（gTLD は ICANN に対してドメイン
あたり一定の料金を支払うことが規定されている）、また ccTLD 管理責任の所在が曖昧であるということとも併せて、ICANN と ccTLD との間で契約を締結することを ICANN は
積極的に進めている。
ただ、ccTLD 管理者の中には、ICANN との契約に否定的な考え方の者も多く、また ICANNが契約にあたって当該国の政府当局のエンドース（承認）を求めていることから、そのことによる政治的ハードルの高さとも相まって契約締結は遅々として進んでいないのが現状である。現時点においては、ICANN と ccTLD スポンサ契約と呼ばれる正式な契約を結ん40

でいるのは、日本をはじめとした以下の 9 カ国だけである。
表10： ICANN と正式に契約を締結した ccTLD の一覧 (2008 年 2 月現在)

締結日

ccTLD 名2000 年

12 月.auオーストラリア2001 年

11 月

.jp

日本

2002 年

3月

.sd

スーダン

4月

.tw

台湾

6月

.ke

ケニア

10 月

.uz

ウズベキスタン

6月.ky

ケイマン諸島

.pw

パラオ

.eu

ヨーロッパ連合

2003 年

これに対して ICANN は、厳格な契約だけでなく、ICANN と ccTLD 管理者の間で覚書を結ぶことによって一定の関係を構築できるようにやや方針転換を行った。これによって若干 ICANN と覚書を結ぶ ccTLD は増えたものの、それでも関係構築は十分には進まなかった。こちらも現在までで以下の 7 カ国に留まっている。
表11： ICANN と覚書を交わした ccTLD の一覧 (2008 年 2 月現在)

締結日
2002 年

2003 年
2004 年

ccTLD 名
5月

.bi

ブルンジ

6月

.mw

マラウイ

12 月

.la

ラオス

1月

.af

アフガニスタン

12 月

.md

モルドバ

6月

.ng

ナイジェリア.ps

パレスチナ

そこで、ICANN はさらにアカウンタビリティ・フレームワークと呼ばれる仕組みを導入し、ICANN と各 ccTLD の正式な関係構築を進めるための起爆剤としようとしている。幸い、この思惑は現在のところ期待通りの成果を挙げつつあるようで、2008 年 2 月の時点で、ICANN とアカウンタビリティ・フレームワークを利用して関係を構築した ccTLD は
37TLD に上っている。これは昨年の調査時点での 18TLD から比べると、ほぼ倍の数字となっている。

41

このアカウンタビリティ・フレームワークには、ICANN と ccTLD 管理者双方の役割を規定し合意したものを文書にするという形式を取る「2 者間契約」と、ICANN と ccTLD 管
理者それぞれが、自組織の役割について一方的に宣言する形式を取る「書簡の交換」の 2
つの枠組みが存在する。ICANN と ccTLD 管理者双方の責務について合意し明文化するという役割については変わりがないものの、後者の書簡の交換の方がより簡素化された、言い換えればより合意までの敷居が低い枠組みであると言える。
なお、以下が 2008 年 2 月時点での、アカウンタビリティ・フレームワークを利用して ICANNと関係を構築した ccTLD の一覧である。
表12： アカウンタビリティ・フレームワークに基づき ICANN と関係を構築した
ccTLD の一覧 (2008 年 2 月現在)

種別
2 者間契約構築日
2006 年 6 月.nf

ノーフォーク島.cx

クリスマス島

.cl

チリ

7月

.hn

ホンジュラス

8月

.pe

ペルー

9月

.gt

グアテマラ

.ni

ニカラグア

.kz

カザフスタン

.cz

チェコ

12 月

.pa

パナマ

2007 年 5 月

.mn

モンゴル

6月

.sv

エルサルバドル.pr

プエルトリコ

.fj

フィジー

.nl

オランダ

2008 年 1 月

.nu

ニウエ

2006 年 3 月

.de

ドイツ

5月

.uk

イギリス

.lv

ラトビア

6月

.na

ナミビア

7月

.no

ノルウェー

8月

.hu

ハンガリー

11 月

書簡の交換

42

ccTLD 名

12 月

.fi

フィンランド.be

ベルギー

2007 年 2 月

.ly

リビア

3月

.ci

コートジボアール

.ru

ロシア

.am

アルメニア

.sn

セネガル

5月

.br

ブラジル

9月

.se

スウェーデン

10 月

.ck

クック諸島

.fm

ミクロネシア

.rs

セルビア

.nz

ニュージーランド.sb

ソロモン諸島

.it

イタリア

4月

・レジストラレジストラとは、ICANN 設立後に導入された「レジストリ-レジストラ」モデルの導入によって新しくできた組織で、gTLD レジストリと登録者の間に立ち、登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する組織である。
レジストラはレジストリと違い、1 つの gTLD に複数存在し、また複数の gTLD を扱うことが出来る。レジストラは価格面やサービス面で自由に競争を行い、ドメイン名の登録がNSI の独占状態であった時とは違い、登録者はそれらの価格やサービスを見比べて自由に
レジストラを選ぶことが可能である。
ただし、過度な競争や不正な手段により登録者が不利益を被ることが無いように、レジス
トラは ICANN と契約を結ぶことが義務付けられており、権利と責務が明確に定められている。また、ICANN が定める共通ポリシーにも従うことが求められており、ICANN 認定レ
ジストラを利用する限りは、登録者はどのレジストラを使っていても共通のポリシーの適用を受けることが出来る。

43

また、競争を促進する手段として、レジストラ移管というポリシーがある。
これは登録者がよりレジストラを選びやすくして、レジストラ間の競争を高めるための仕組みで、登録者は移管先のレジストラに申請するだけで、移管元のレジストラの許可などは必要無しにレジストラを移管することが出来る。登録者から移管したいという意思を伝えられた移管元レジストラは移管を拒否することが出来ない。この仕組みによって、登録者は価格やサービス面に優れたレジストラにより容易に移管することができ、また移管元
レジストラは登録者を不当な手段で引き留めることが出来ない仕組みになっている。
さらにレジストラの下にリセラというものも存在する。こちらは ICANN との契約関係は特になく、レジストラとのみ契約し、レジストラの下請けのような感じで登録受付を行っている。リセラはレジストラと違って、ICANN が定めるポリシーに従う必要はなく、またレ
ジストラと違い、直接レジストリのデータベースにアクセスする権限も無い。ユーザから登録などの申請は受け付けるものの、実際の処理は自分が傘下に入っているレジストラに
データベース変更などの処理は任せることになる。

2-2 インターネット資源管理体制全般に関する議論の動向
2007 年度におけるインターネット資源管理体制に関する議論のハイライトは、2 回目を迎えたインターネットガバナンスフォーラム（IGF）の開催、および ICANN と米国商務省との覚書（Memorandum of Understanding）のレビューであろう。
まず IGF についてだが、そもそも IGF は 2005 年 11 月に開催された世界情報社会サミット（WSIS：World Summit of Information Society）チュニス会合の結論として、国際連合管轄で設立されることが決まったフォーラムである。マルチステークホルダー参加型のアプ
ローチを採用し、最低 5 年間は維持することが決まっており、第 1 回はアテネで開催され、2007 年にはリオデジャネイロで開催された。
次に ICANN と米国商務省との覚書の件だが、2006 年 9 月 29 日に従来の ICANN と米国
商 務 省 と の 覚 書 を 更 新 す る 形 で 「 共 同 プ ロ ジ ェ ク ト 合 意 書 （ JPA ： Joint Project
Agreement）」が取り交わされた後、中間評価として米国商務省の NTIA（ National
Telecommunications and Information Administration）が ICANN のパフォーマンスについて 10 項目からなるパブリックコメントを求めている。パブリックコメント要請は 2007
年 10 月 30 日付で公開され、2008 年 2 月 15 日がコメント提出の締め切りとされている。
上記それぞれについては、次項より詳細を報告する。

44

2-2-1 第 2 回 IGF リオデジャネイロ会合に至るまでの議論■ 2007 年 2 月 – 最初の検討会議
第 1 回のインターネットガバナンスフォーラム（IGF）がアテネで開催された後、次回のリオデジャネイロ会議に向けた最初の検討会議が 2007 年 2 月 13 日に、IGFの諮問委員会（Advisory Committee）を中心としてジュネーブで開催された。議長はニティン・デサイー氏が務めた。この会議にあたり、第 1 回のIGFの反省点、次回に向けた提案をまとめた資料がIGF事務局によって用意され12、これを基に議論が進んだ。用意された資料のうち、リオデジャネイロに向けた議論がなされている一節を以下に要約する。
[IGF の役割とその性質について]
様々な意見が提出された。WSIS チュニスアジェンダで示された IGF の達成するべき目標からすると、何らかの決定、もしくはポリシー勧告を行うべきではないかとする意見があった。こうした見方は、IGF が何らかの意思決定能力を持つべきという前提に立っている。
「 協力のさらなる強化（Enhanced Cooperation）」や「重要なインターネット上の資源（Critical Internet Resources）」も IGF が取り扱うべき問題とする意見もあった。こういう意見を提出してくる者は、IGF がこのままの議論のやり方を続けていると IGF に課せられた義務を全うできないと感じている。
しかし一方で、IGF はその役割をみだりに拡大させるべきではないという意見もある。そういう見方は、IGF は複数の利害関係者の間で情報やアイディアを交換する場であり、ベストプラクティスを共有する場であるとの前提に立っている。こうした意見を提出する者
は、アテネの会議が成功したのは、正式な決議や結論を出さずに議論を自由に行うというやり方に負うところが大きいと感じている。
[IGF の準備プロセスについて]多くのコメントが、第 2 回の IGF はアテネ会議のやり方を踏襲することを支持していた。
特に複数の利害関係者を参加させてプロセスを進めることの重要性が強調されていた。その上で、諮問委員会のメンバーを一部入れ替える必要があるのではないかといった指摘もあった。委員会のメンバー選びについては、複数の利害関係者からなる指名委員会を組織し、その指名委員会が国連事務総長に勧告を行うといった形を取ればどうか、などの提案があった。

12 http://www.intgovforum.org/Feb_igf_meeting/Synthesis.Paper.Feb.2007.rtf

45

[リオデジャネイロ会議に向けて]
アテネでのテーマ別会合は成功だったという認識はあるものの、今後の会議ではもっと掘り下げた具体的なテーマについて議論してはどうかという提案があった。会議の運営やテーマ選びについては、以下のように様々な提案があった。
全ての地域からバランス良く参加を得ることが重要。特に途上国には優先権が与えられるべき。
途上国に関する問題については、優先して取り扱うべきである。能力開発（Capacity
Building）のテーマは特に重要。
1 年に 1 回の IGF 本会合に加え、その間にワークショップ会合を開催してはどうか。
「動的な連携（Dynamic Coalition）」についてのみ議論するセッションを設け、活動
計画や進捗報告を求めるべき。
パネリストの人数はもっと少なく、時間ももっと短くするべき。
インターネットガバナンスに関係する諸団体、例えば ICANN、ITU、UNESCO、WIPO、
WTO などを招いて公開フォーラムを開催してはどうか。
会議前に提出される寄書について、もっと会議での認知を上げるべき。
ベストプラクティスフォーラムでは、政府が主要な役割を果たせるのではないか。

■ 2007 年 9 月 – 諮問委員会会合
2007 年 9 月 4 日から 5 日にかけ、ジュネーブで IGF 諮問委員会の会合が開催された。
この会合で 2007 年 11 月の IGF リオデジャネイロ会合の概要がほぼ決定となった。議題としては前年のアテネ会議で 4 つのテーマとして挙げられた「アクセス」
「多様性」
「開放性」
「セキュリティ」に加え、「重要なインターネット上の資源（Critical Internet Resource）」
が入ることとなり、議論の目的は「様々な情報と意見を共有すること」とされた。
その他のテーマについては、基本的には前年のやり方を踏襲することとなった。

46

2-2-2 第 2 回 IGF リオデジャネイロ会合での議論
第 2 回インターネットガバナンスフォーラム（IGF）は、2007 年 11 月 12 日から 15 日までの 4 日間、ブラジルのリオデジャネイロで開催された。IGF 最終日の発表によると、109ヶ国から 1,363 人の参加があったとのことである。
昨年の IGF アテネ会合では、「開放性(Openness)」「セキュリティ(Security)」「多様性(Diversity)」「アクセス(Access)」の四つをテーマとした議論が行われたが、今回はそれらに加え、「重要なインターネット資源(CIR:Critical Internet Resource)」も議論のテーマとなった。
CIR とは、間接的に IP アドレスおよびドメイン名を指すことを意味するとされ、それらの管理を行っている ICANN を対象とした議論が行われるのではないか、という見方がICANN、RIR 関係者にはあった。2005 年 11 月の世界情報社会サミット（WSIS）での議論において、どちらかというと ICANN に批判的な立場を取っていたブラジルが今回のホスト国ということもあり、この CIR のセッションでは ICANN 批判が巻き起こるのではないかという予想もされていた。これには、前回の IGF アテネ会合で、ICANN 批判の感情的なコメントがいくつか聞かれたことがその背景にある。
しかし、実際に会議が始まってみると、「ICANN への政府の関与、ICANN での政府の役割についてさらなる明確化が必要」など、いくつか ICANN への批判はあったものの、そのトーンは比較的穏やか、かつ建設的なもののように感じられた。全体的に、ICANN という存在を認めつつ、その組織運営およびプロセスの改善を今後は求めていくべきという方向に収束していったように思われる。ここに至り、ICANN の機能を国際機関の手に移せ、という声はほとんど無くなったと言えよう。
今回の IGF では、本項冒頭の五つのテーマについて話し合うメインセッションに加え、84ものサブセッションが開催された。サブセッションは、ルートサーバに関する ICANN による解説など、インターネット関連団体や市民団体が、それぞれの取り組むテーマについて説明、議論を行うワークショップがその中心だったが、その多くは議論の時間があまり取られておらず、一方的な情報発信に終わってしまったようである。
IGF は対話の場として機能することを目指して作られた会議体であるが、2 回目にして本格的に機能し始めた感がある。しかし、一方では単なる対話の場で終わらせることに不満を抱く参加者もおり、「IGF としての何らかの結論、決議を出すべきではないか」「プログラ
ムを検討する諮問委員会（Advisory Committee）の意思決定プロセスが不明確であり、議47

論する内容、方向性に関して参加者の意見が反映されていないのではないか」といった指摘も最終日の閉会式セッションでなされており、次回会議への課題も残した。
「IGF は ICANN の良き競争相手である。現に WSIS や IGF のプロセスが始まった後、
ICANN は会議参加のための奨学金プログラムの提供や、会議での同時通訳提供など、参加者への気配りが明らかに向上した。
」といった発言をした参加者もいた。この発言に見られるように、ICANN 関係者が IGF を意識しているのは間違いないところである。そういう意味では IGF のプロセスが ICANN に対しても好影響を及ぼし、変革を促しているという見方も成立するであろう。
一方、メインセッションに並行して開催されたサブセッションを通じ、政府関係者や市民
社会への ICANN からの情報提供も活発に行われた。このような双方向の情報交換を基礎として、IGF は利害関係者の間に相互作用を及ぼしつつある。IGF は今回第 2 回の開催を終えたが、最低 5 回は開催されることとなっており、種々の批判を受けながらも今の形を保っていくものと思われる。
次回の IGF は、2008 年 12 月 8 日から 11 日まで、インドのニューデリーで開催されることが決まっており、2009 年はエジプトでの開催となっている。5 年目の区切りとなる 2010年の IGF は、2008 年 1 月末現在、リトアニアとアゼルバイジャンが招致を表明している。
第 3 回の IGF に向けては、初回の準備会合が 2008 年 2 月 26 日にジュネーブで開催されることが既に決まっている。諮問委員会の役割等について議論がされるようであるが、本稿執筆時点（2008 年 2 月 13 日）ではそれ以上の情報は入手できていない。しかし基本的には 2007 年の準備プロセスと同様のプロセスを辿るものと思われる。
メインセッションおよびサブセッションの様子は次ページ以降で報告する。メインセッシ
ョンについては、IGF 最終日の議長総括を要約し報告する。また、サブセッションについては特に正式な報告書が出ていないため、実際に参加したセッションについて、その概要を報告する。

48

■ メインセッション[セッション名] Critical Internet Resources（インターネット上の重要な資源）[開催日時] 2007 年 11 月 12 日(月) 15:00〜17:00[概要] 以下の通り。
パネルディスカッションでは、物理的、論理的なインターネットのインフラストラクチャ
に関する様々なトピックが議論された。IGF の他のセッションで何回も繰り返されたことでもあるが、インターネットへのアクセスすら持っていない 55 億人の人々をインターネッ
トに接続するためのインフラの構築が不可欠だと指摘したパネリストがいた。
様々なインターネット上の資源について議論があったが、主要なトピックはドメイン名とIP アドレスであった。この点については、ICANN が議論の中心となった。多くの発言者
が「インターネット上の重要な資源」を主要テーマの一つとして据えることは WSIS チュ
ニスアジェンダ文書の精神からして重要であるとの認識を示した。議論は DNS の管理、イ
ンターネットプロトコル（IP）、ルートサーバの管理、技術標準、相互接続点、電気通信設備、革新的技術、多言語主義への移行など多岐にわたった。
出席者の多くが一国の政府による ICANN 支配という問題を提起した一方、国際的なコミュ
ニティがより積極的な役割を握るべきだと主張した者もいた。発言者の中には、IGF の枠組みの中で「インターネット上の重要な資源」について検討する作業部会を作ってはどうかと提案する者もいた。
パネリストの中には ICANN が政府から独立することを支持している者もいたが、公共政策
課題に関しては政府がより重要な役割を果たして欲しいとする者もいた。ICANN と米国商務省との共同プロジェクトに関する言及もあった。ボトムアップという ICANN の本来的性
質や、ICANN 組織自体の外部からの定期レビュー、政府諮問委員会（GAC）の役割についても議論となった。
IPv4 アドレスの在庫枯渇についても指摘があり、枯渇がインターネットの崩壊につながる
わけではないものの、IPv4 と IPv6 の相互運用性を保つことが重要との認識が示された。
全体として、「インターネット上の重要な資源」について IGF の枠組みの中で利害関係者が議論しあうことには価値があるということが認識された。

49

[セッション名] Access（アクセス）[開催日時] 2007 年 11 月 13 日(火) 11:00〜13:00[概要] 以下の通り。
パネリストからは、インターネットのアクセスという問題こそが、多くの国、特に発展途
上国にとってただ一つの最も重要な問題であることの指摘があった。セッションの多くは、10 億のインターネットユーザは大きな成功を収めているので、アクセスの無い次の数十億のユーザへ焦点を当てなければならないという問題指摘であった。
出席者からは、IGF の共通テーマである「マルチステークホルダーによる協調」がアクセスを議論する際には重要だという指摘があった。この点では、政府の役割も重要だが、民間、市民社会、インターネットコミュニティと密接に協力し合うことが必要との認識で一致した。同様に、辺境地域におけるアクセス提供のためには、民間企業が政府および市民
社会と協力することが必要との認識も示されたが、地域毎に事情は違うので、画一的な解は無いことも指摘された。
多くの発言者が、地域内における IX の必要性を強調していた。IX は地域におけるコンテン
ツを増やす効果があり、また、域外トラフィックを減らすことによるコスト低減に効果があるという指摘があった。
政府の役割については法的枠組みを作るという点では意見の一致を見たが、市場を重視すべきという見方もあれば、市場を重視しすぎても問題は解決しないという見方もあった。
途上国の世帯の多くは通信に多くの費用を割けないため、往々にして政府が一番の買い手となっている状況である。このような状況下でアクセスを整備するには新しいビジネスモ
デルが必要であるという意見もあった。
全体的には、アクセスの問題は今後も IGF の中心議題であり続けるということの合意が得
られた。

50

[セッション名] Diversity（多様性）[開催日時] 2007 年 11 月 13 日(火) 15:00〜17:00[概要] 以下の通り。
多様性に関する議論は非常に多岐にわたるものであった。デジタルデバイドは同時に知識の格差を生み、それ故に全世界的問題となっているという認識がなされた。また、多様性の意味するところとして、言語的多様性、文化的多様性、メディアの多様性、障害を持っている人に関する多様性など、様々な指摘があった。パネリストからは、インターネット
は全ての人々からアクセスできるものでなければならないとする意見があった。これを実現するためにはユニバーサルデザインや支援技術の採用が鍵である。パネリストの一人からは、表記文字の無い話し言葉や、手話などにも考慮が必要であるという指摘があった。
標準化のもたらすインパクトや、オープンかつ独自仕様でない標準の重要性についても語られた。
昨年の IGF アテネ会合とは異なり、IDN 自体について重点的に話す必要性は薄れたとする
パネリストもいた。IDN の役割と、様々な言語によるコンテンツ提供とは明確に区別するべきという指摘もあった。しかし、IDN の採用はいまだ多様性の重要な一面であるということは明らかである。また、IDN を新たなフィッシングの道具とすることがあってはならないという指摘もあった。
全体として、インターネットは文化的多様性を守るための機会を与えてくれているという認識であった。これを実現するためには、全ての人々がそれぞれの言語で文化的アイデンティティを保ちながらインターネットを使えるようにすることが重要との指摘があった。
最後にパネリストの一人が「多様性を尊重するため、インターネットは思いやりのある、
平和な、バリアフリーの場所であるべきである」と指摘し、終了となった。

51

[セッション名] Openness（開放性）[開催日時] 2007 年 11 月 14 日(水) 11:00〜13:00[概要] 以下の通り。
開放性に関する議論は、アクセスやセキュリティ、多様性といった IGF の他テーマとも相まって複数の切り口のある議論となった。
発言者の中には「２つの IP、つまり、インターネットプロトコルと知的財産（Intellectual
Property）とのバランスをとらなければならない」と指摘した者がおり、複数がこれに同調した。また、表現の自由および情報流通の自由と、他者の成果物を享受する自由とのバ
ランスの問題や、プライバシーと表現の自由とのバランスといった問題を指摘した者もいた。
パネルディスカッションでは、基本的な自由、表現の自由、情報流通の自由が特に強調された。参加者からは、基本的人権というのはインターネットガバナンスというテーマから外れているのではないかと指摘したうえで、クレジットカード詐欺やテロなどを優先して議論すべきではないかといった声もあった。
オープンソースソフトウェアに関する議論もあった。入り口の障害が低ければ低いほど、革新は起こりやすくなるので特に途上国には有効という指摘があった。
どのような形の規制が望ましいかの議論も行った。参加者からは、自己規制の重要さを説く声もあったが、硬軟織り交ぜた法的規制を望む声も強かった。
結局のところ社会が何を望むかというのは、最後は政治的決断になるということであるとの指摘があった。

52

[セッション名] Security（セキュリティ）[開催日時] 2007 年 11 月 14 日(水) 16:00〜18:00[概要] 以下の通り。
多くの参加者がセキュリティは非常に重要な問題であり、アクセスの議論と同じように、国ごとに事情が異なるものであるという認識を共有した。議論の中で大きな問題となったのは、「セキュリティ」という言葉が何を意味するかを定義することであった。参加者からは国家のセキュリティ、ビジネスのセキュリティ、ユーザやネットワークのセキュリティ、
ネットワークの信頼性など、様々な定義づけの案が出された。また、セキュリティが破られる前の対策が重要とする者もいれば、破られた後どう対処するかが重要とする者もいた。
これに対しては、未来を予測することができない以上、100%のセキュリティを確保するのは不可能と発言した参加者がいた。
犯罪はオンラインで行われようとオフラインで行われようと区別する必要は無いという主張があった。95%のオンライン犯罪は現状の法体系の範疇に入るという発言もあった。これに対して、法体系ではなく、法の執行の方が問題だという指摘がなされた。インターネッ
トの持つ特徴としてボーダレスというものがあるためこれに対応する法執行機関が必要ではないかという指摘があった。
一方で、規制のし過ぎは良くないという指摘もあった。多数の発言者が、マルチステーク
ホルダー間による協調行動で十分という指摘を行った。国同士でオンライン犯罪を取り締まる法体系のすり合わせを強く求める声もあった。
議論では、全ての利害関係者間の信頼を築く持続可能な環境が必要という認識が生まれた。

53

■ サブセッション[セッション名] IPv4 to IPv6: Challenges and Opportunities[開催日時] 2007 年 11 月 12 日（月）13:30〜15:00[参加人数] およそ 80 名
[概要] 以下の通り。
日本から JPNIC が共催団体の一つとして参加したワークショップで、「IPv4 在庫枯渇とIPv6 への移行」というテーマを取り上げたもの。総務省の山田真貴子氏も話者として参加
し、日本政府としての IPv4 アドレス在庫枯渇問題や、IPv6 推進の取り組みに関する紹介があった。JPNIC からは、JPNIC 会員に向けて行った IPv4 アドレス在庫枯渇に関するア
ンケートの結果紹介を行った。
他パネリストからは、IPv4 と IPv6 との混在環境をいかに実現するか、IPv6 環境での DNSの挙動の説明など、技術色の濃いプレゼンテーションがなされた。
その後 30 分ほどが質疑応答の時間に割かれ、日本政府の取り組みに対する質問と技術的な質問がほとんどで、IP アドレスポリシーに関する質問は出ずに終了した。

54

[セッション名] Workshop - Qualifying, Quantifying, and Meeting the Challenge ofInternet Access Costs[開催日時] 2007 年 11 月 13 日（火）8:30〜10:00[参加人数] およそ 80 名
[概要] 以下の通り。
途上国におけるインターネットアクセスコストの低減化に向けて、何ができるかをテーマに、世界各国におけるブロードバンドの発展状況、政策を共有するワークショップであった。日本の関係者としては、モデレータを富士通株式会社の加藤幹之氏が務め、パネリス
トの 1 人として総務省の森清審議官が登壇し、日本のケースを紹介した。
会場からは、e-japan 政策実行時の政府からの援助資金と、民間からの投資資金との割合を問う質問があった。その質問に対し、日本の場合はほとんどが民間の投資資金であり、必ずしも援助資金を出さずとも、政策を明確に発表することによって投資を促し、アクセス
コストを低減化させる方向へ導くことは可能ではないかとの回答がなされていた。
また、前日の Critical Internet Resources のセッションで出た IPv4 から IPv6 への移行問
題を取り上げ、途上国としては IPv6 への移行が問題ではなく、インターネットへのアクセス自体が無いことが問題であり、先進国のユーザがわずかずつでも資金供出することが必要ではないかという会場からの発言もあった。
ワークショップの結論として、アクセスコストを低減させる要素としては、政府の政策立
案、国際協力、民間の努力、およびその組み合わせがあるという共通認識を確認し、終了
となった。

55

[セッション名] Workshop - Functioning of the Domain Name System[開催日時] 2007 年 11 月 13 日（火）10:30〜12:05[参加人数] およそ 150 名[概要] 以下の通り。
DNS がどのように機能しているかを説明するワークショップで、CENTR、IANA、APTLD、英国政府、ISOC からのパネリストが、それぞれ現状の DNS 管理状況について説明を行った。説明の中では、英国政府の担当者が、以下の発言を行ったことが注目される。
・ DNS は現在、実際の商取引に欠かせないものだと認識しており、それゆえに現在よりもプロフェッショナルな管理のプロセスが必要である。
・ DNS システム自体の強固さは、IANA の改善によって良い方向に進みつつある。また、システムへの利害関係者の関与は、GAC や CCNSO という枠組みによって、これも良い方向に進みつつある。
・ 米国政府がルートサーバの管理に関与していることについて、脅威と見る見方があることは知っているが、同時にセーフガードという見方もできる。IANA が適正な手続きに基づいてルートサーバの管理を行っていることを、保証しているという考え方もできるのではないか。
会場からは、ルートサーバ運用者同士の連絡はどのように取っているのかといった質問や、
ccTLD 運用者の再委任(Redelegation)の手続き等に関する質問があった。
モデレータのまとめとして、ccTLD と IANA の関係は改善され、ICANN との正式関係構
築のプロセスが進みつつあること、IANA での手続き自動化が進み、その速度も上がっていること、ccTLD は DNS 全体の名前空間において重要な位置を占めるがゆえに、国家主権(sovereignty)との関係にも留意する必要があることを指摘して、終了となった。

56

[セッション名] Workshop - Towards International Standards for a Truly Multilingual
Global Internet[開催日時] 2007 年 11 月 13 日（火）12:40〜14:15[参加人数] およそ 70 名
[概要] 以下の通り。
IDN の進展をテーマとしたワークショップ。Paul Twomey、Vint Cerf、John Kleinseinなどの ICANN 関係者が、ICANN における IDN への取り組みを紹介し、実際のテスト(.test)も行われていることを紹介した。また、ITU や UNESCO からのパネリストからも、IDNの重要性を訴えるプレゼンを行っていた。
ICANN 以外のパネリストはどちらかというと IDN よりも言語そのものがデジタル対応されていない(UNICODE に乗らない）
ことを問題視しているのに対し、ICANN 関係者は IDNへの取り組みをアピールする一方で、IDN 自体が問題を解決するわけではないことも指摘
し、相互運用性の確保や言語別のコンテンツの有無がよりクリティカルであるとの発言もあったのが対照的であった。
参加者からは特に目立った質問なく、IETF における IDN の議論の有無を正す質問があった程度で終了した。

57

[セッション名] Workshop - Open Forum (ICANN)[開催日時] 2007 年 11 月 13 日（火）16:30〜17:30[参加人数] およそ 150 名[概要] 以下の通り。
現 ICANN 理事長の Peter Dengate Thrush 氏がモデレータとなり、ICANN の成り立ちやその役割を説明するセッションとなった。パネリストとして、GAC からカナダ政府代表、
RIR からは Ray Plzak、ccTLD からは Nominet の Emily Taylor、At-Large から Jacqueline
Morris、Didier Kasole、そして ICANN 事務総長 Paul Twomey という面々がそれぞれの組織の説明を行った。
出席者の 4 分の 1 程度が ICANN 関係者ということもあってか、自由質疑の時間になっても特に質問は出ず、モデレータが各パネリストにそれぞれの組織の課題について話を振った。RIR からは IPv4 在庫枯渇の問題、ICANN 全体としては透明性の確保が課題というよ
うな話があった程度で、ICANN の正統性や米国政府の関与といったような話は全く出ず、そのまま終了した。

58

[セッション名] DNSSEC - Securing a Critical Internet Resource[開催日時] 2007 年 11 月 14 日（水）10:30〜12:00[参加人数] およそ 60 名
[概要] 以下の通り。
60 人程度の参加。DNSSEC の技術的な説明を中心としたワークショップであったが、ほとんどチュートリアルという内容で、
Nominet、DENIC、cgi.br などの CCTLD 運用者と IANA
（David Conrad 氏）から DNSSEC 自体の説明、DNSSEC に対する期待、自身のスタン
ス等を披露するものだった。Nominet の担当者は、ユーザの DNSSEC に対するニーズがそれほど高くないことを認めつつも、より安全なインターネットへのニーズは明確にあり、
DNSSEC の導入は Nominet にとっても挑戦であるというコメントをしていた。
会場からは技術的な質問が２、３あったが、特に目立つものではなかった。

59

[セッション名] Workshop - Governance Frameworks for Critical Internet Resources[開催日時] 2007 年 11 月 14 日（水）12:30〜14:15[参加人数] およそ 100 名[概要] 以下の通り。
ISOC、ロンドンメトロポリタンビジネススクール、他 NGO のパネリストから、現状のイ
ンターネットガバナンスに対する意見表明を行い、ガバナンスのあり方を議論するワークショップであった。パネリストの発言では、現在の ICANN が抱える課題を指摘する意見が続出した。主な意見は以下の通り。
・ ICANN は DNS の究極的管理者であり、政治的監視(political oversight)が必要である
ことは明確である。また、理論的には ccTLD のルートゾーン変更や再委任(redelegation)を否定することさえできる。このことをどう整理するのかが課題である。（Fernando
Barrio 氏、ロンドンメトロポリタンビジネススクール教授）
・ いろいろな意味でセキュリティは重要である。重要であることに関してはより多くの人を巻き込んだガバナンスが必要であり、現状それが十分だとは思えない。
（Gurumurthy
Kasinathan 氏、インターネットガバナンスを考えるための NGO "IT for Change"の創立者。）
・ 米国も含め、いかなる国もインターネットのガバナンスに関し、拒否権(veto)を持ってはならない。
（Carlos Afonso 氏、ブラジルインターネット運営委員会のメンバー。）
この後表明された意見について議論が行われた後、モデレータがパネリストに対し、「ICANN には問題があるものの、ICANN の存在を否定するものではないという理解で良いか」という問いかけを行ったところ、全パネリストが同意し、今ある枠組みをどう改良していくかを検討すべきとであるいう結論となり、ワークショップは終了した。

60

[セッション名] Workshop - Broadening the Domain Name Space[開催日時] 2007 年 11 月 14 日（水）14:30〜16:15[参加人数] およそ 60 名
[概要] 以下の通り。
新 gTLD の導入、特に都市名、地域名を作ったドメイン名の導入への動きをテーマにした
ワークショップ。既に認められたドメイン名の代表として、.cat、.asia、.eu のレジストリ
から申請の経緯、現在の登録状況の紹介があり、その後、これから申請を行おうとしている.nyc、.paris、.berlin、.africa、.lat（ラテンアメリカ）の申請計画者からのプレゼンテー
ションがあった。
参加者からは、こういったドメイン名は混乱を生む印象があるといったコメント、都市名をドメイン名に利用する理由が理解できないというコメント、都市名をドメイン名にした
際の行政組織との協力やガバナンスを良く検討すべき、というようなコメントがあった。
これに対し、例えば.berlin の場合は市議会とも話をしており、議会からの支持決議ももらっているというような回答がなされている。
また、ICANN 側の課題として、大都市の申請と小都市の申請を同列に扱うのか、地域名(.africa)をドメイン名とするときの、地域における政府間の調整などがあるとの指摘もあった。
モデレータによるまとめは特に行われず、そのまま終了した。

61

[セッション名] Workshop - The Root Server System[開催日時] 2007 年 11 月 14 日（水）16:35〜18:00[参加人数] およそ 80 名
[概要] 以下の通り。
ルートサーバの仕組み、運用状況をテーマにしたワークショップであった。ワークショッ
プの冒頭で、モデレータが「ここはチュートリアルセッションであり、ガバナンスを議論するところではない」と念押ししたのが印象的だった。
まず、Afilias 社の担当者から、host ファイル管理の時代から、DNS 誕生までの歴史を説明した後、ルートサーバの概要紹介があり、現在はエニーキャスト技術の導入により、実際のルートサーバ数が格段に増加していることについて、説明があった。
この後、I ルート、F ルートの運用者、およびミラーサーバ運用者からの説明が続いた。特にケニア、メキシコ、バングラデシュのルートサーバ運用者から、自国にルートサーバのミラーがあるおかげで、名前解決の速度が速くなった、トラフィックが国内に閉じるようになり、海外インフラへの投資を抑制できたなどのメリットを享受しているという内容のプレゼンテーションが注目を集めていた。
参加者からは、ルートサーバのミラーを各国に置くという勧告をしてもいいのではないかというコメントも出た。

62

2-2-3 共同プロジェクト合意書（JPA）中間レビュー
2-2 で既述した通り、「共同プロジェクト合意書（JPA：Joint Project Agreement）」の中間
評 価 と し て 米 国 商 務 省 の NTIA （ National Telecommunications and Information
Administration）が ICANN のパフォーマンスについて 10 項目からなるパブリックコメン
トを求めている。パブリックコメントは、DNS 管理の民間部門への完全委譲という最終的な JPA の目標に向け、ICANN が 2006 年 10 月 1 日以降いかなる進歩を遂げたかを問うものである。パブリックコメント要請は 2007 年 10 月 30 日付で公開され、2008 年 2 月 15
日がコメント提出の締め切りとされている。NTIA のウェブサイトには提出されたコメントが掲載されており、確認すると 172 通のコメントが寄せられたようである。以下に NTIA
によるコメント要請項目を掲載するとともに、主なコメントを紹介する。
■ NTIAからのコメント要請項目13
1.

JPA では、ICANN はインターネットのセキュリティと安定性について「世界で一意性を持つインターネット上の識別子の全体的な調整を行う。特に、インターネット上の識別子システムの安定した安全な運用について調整する」ことを実行するとしているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう
事項は何か。

2.

JPA では、ICANN は透明性に関して「ICANN 運営の予算立て、およびインターネッ
ト DNS の技術的調整に関するポリシーの検討および採用における透明性、アクセス可能性、効率性、適時性の向上のため、ICANN はプロセスおよび手続の策定、試行、向上を引き続き行う。ICANN は民間部門において管理に関わる組織の透明性の分野で先駆者たる役割となることを望む」としているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

3.

JPA では、ICANN は説明責任（accountability）に関して「インターネット DNS の技術的調整に関するポリシーの検討および採用において、インターネットの世界的な利害関係者に対する責任を果たすべく、説明責任のメカニズムの策定、試行、向上を
引き続き行う。これには、ICANN のボトムアップ参加型のポリシー策定プロセスへのさらなる参加に向けた公開制およびアクセス可能性の向上を含む」としているが、2006

13 http://www.ntia.doc.gov/ntiahome/frnotices/2007/ICANN_JPA_110207.html

63

年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。
4.

JPA では、ICANN はルートサーバのセキュリティおよび関係構築に関し「ICANN は
ルートネームサーバの運用者並びに適切な専門家と、ルートゾーンの安全かつ安定した調整、危機管理計画の策定、ルートゾーン変更の明確なプロセス維持に関し、物理層、ネットワーク層の運用およびセキュリティ上の調整を続ける。ICANN はまた、ルートサーバの運用者と正式関係を構築するよう取り組む」としているが、2006 年 10
月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

5.

JPA では、ICANN は TLD の管理に関して「ICANN は新 TLD の実装や IDN の導入など TLD 管理の意思決定を行う際には、競争、消費者の利益、インターネット DNSの安定、セキュリティ上の問題を特定し、検討することを保証するプロセスを維持、構築する。ICANN は現在のポリシー策定プロセスを発展させ、ICANN の諮問委員会
や支持組織、他の関係専門家による諮問パネル、組織から勧告を考慮に入れるプロセスを策定する。ICANN は WHOIS に関する既存のポリシーの執行を進め、そのポリシーが求めている、登録者、技術担当者、経理担当者、管理責任者を含む正確で完全なWHOIS 情報に適時、非制限、公開でアクセスできるような手段を ICANN が実装するようにする。ICANN はまた、国コードトップレベルドメイン（ccTLD）運用者との間で安定した合意書を取り交わせるよう今後も努める。」としているが、2006 年 10 月 1
日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

6.

JPA では、ICANN はマルチステークホルダーモデルについて「ICANN は、マルチス
テークホルダーモデル、全ての利害関係者の世界的な参加の維持および向上を行う。
これには、既存の諮問委員会や支持組織の見直しも含まれる。また、ボトムアップのポリシー策定プロセスの有効性向上にも引き続き取り組む。ICANN は、ICANN のポ
リシーに影響を受ける人々の参加を促す追加的メカニズムを策定し、民間部門の関与を向上させるよう努める」としているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野
で ICANN がもっと取り組めたであろう事項は何か。

7.

JPA では、ICANN は政府の役割について「ICANN は、インターネットの技術的な調整の公共政策的観点に立った GAC の助言を効果的に検討する助けとして、政府諮問委

64

員会（GAC）のメンバーと協力し、GAC の ICANN 内での役割について再検討を行う。」としているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。
8.

JPA では、ICANN は IP アドレス分配について「ICANN は地域インターネットレジ
ストリ（RIR）での技術的取り組みの継続を許容しつつ、RIR のポリシー策定作業を
ICANN プロセスに組み入れるため、世界的、地域的レベルでの協調を今後も続ける。
ICANN はこの取り組みを反映させた RIR（もしくは他の適切な組織）との法的合意書を維持する。
」としているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果た
すにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

9.

JPA では、ICANN は法人の責任について「ICANN は良好な企業統治、安定した国際的民間組織を保つための組織的手段を含めた運営の優秀さ、効率性を維持し、関連する技術上またはビジネス上の経験を理事、執行陣、スタッフの間で維持する。ICANN
は適切なメカニズムを実装し、インターネットの世界的な利害関係者がより ICANN に参加しやすくなるようにする。例えば、教育のためのサービス提供や、部会構成員間での情報共有、産業毎でのベストプラクティスの奨励などである。」としているが、2006
年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

10. JPA では、ICANN は法人の管理構造について「組織および法人の統治に関するベスト
プラクティスを考慮に入れた、契約執行への適切な資源投入を含め、安定性を保証するための法人の管理構造に関する見直しを行う、必要であれば変更を行う。」としているが、2006 年 10 月 1 日以降、ICANN はこれらの責任を果たすにあたりどのような成果を挙げたか。進捗があったとすれば、どのような進捗があったのか、何故進捗があったと思うのかを説明すること。また、この分野で ICANN がもっと取り組めたであろう事項は何か。

65

■ ICANNからのコメント14要約
ICANN は 2008 年 1 月 9 日付けで、NTIA のパブリックコメント募集に対し回答を行った。
JPA の定める義務については着実に履行されており、DNS の速やかな民間への完全移行を求める内容となっている。
[2008 年 1 月 9 日付け]
ICANN 理事会は、以下の通り確信する。
当初の MoU と同様、JPA は ICANN が安定した組織となる支援となっている。
2006 年 9 月に発効した JPA の契約条件を、ICANN は実行してきている。
ICANN は、JPA で定められている義務を果たしている。
JPA はもはや必要ではなくなっている。これを終結することは、DNS の調整を民間に移行させるための次のステップである。
このステップによって、ホワイトペーパー15によって示された当初の目標が達成されつつあることが今後も確信できる。
JPA を終結させることは、IANA 契約に規定されている既存の説明責任には影響を与えない。米国政府の GAC を通じた参加も、同様に影響を受けない。

14 http://www.icann.org/jpa/#submission
15 1998 年 6 月 5 日に発表された、インターネットの管理体系に関する提案が記述されている、米国政府による文書の通称。原文はhttp://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm、日本語訳は、http://www.nic.ad.jp/ja/translation/icann/bunsho-white.html

66

■ 国際商業会議所からのコメント16要約
国際商業会議所（ICC：International Chamber of Commerce）は 2008 年 2 月 6 日付けでNTIA のパブリックコメント募集に対し回答を行った。ICC 自体、ICANN の GNSO（分野
別ドメイン名支持組織）の一員として活動を行っていることもあってか、ICANN を支持し、
DNS 管理の民間への完全移行に向けた取り組みを行うべきとしている。
[2008 年 2 月 6 日付け]
ICC は、インターネットがうまく機能することを保証するという ICANN の非常に大きな役割を十分に認識している。
我々は、ICANN が与えられた責任を全うし続けられるよう、完全に独立した組織となり、将来さらにこの組織を強化するために、ICANN を適切なマルチステークホルダーモデルおよび組織構成へと移行させるということを決定するための真剣な議論を今すぐ始めるべきであると確信する。
ICC および世界的かつ多様な会員は、引き続き ICANN と密接かつ生産的な取り組みを行う関係であるよう期待している。

16http://www.iccwbo.org/uploadedFiles/ICC/policy/e-business/Statements/ICC%20views%20on%20ICA

NN%20JPA.pdf

67

■ NRO からのコメント要約
NRO（Number Resource Organization）もNTIAのパブリックコメント募集に対し回答を行っている17。現在のICANN体制を支持し、JPAを終了させ、DNS管理の民間への完全移行を求める内容となっている。
NRO は、現行のインターネットのドメイン名およびアドレス割り振りシステムの管理調整モデルへの支持を再確認する。近年 ICANN は、安定かつ信頼に足る組織であろうとするコ
ミットメントを示しており、これを実現するにあたり長足の進歩を遂げた。
NRO は、米国商務省と ICANN との間の JPA は終了させるべきと確信する。このため、我々は ICANN と米国商務省に対し、インターネットの調整業務の民間への包括的な移管を完了させるため、相互に積極的に取り組むことを望む。このプロセスにあたっては、ICANN はコミュニティに対し適宜助言を求めるべきである。
NRO はまた、常に変化していくインターネットの環境においてはどの政府もインターネッ
ト上の資源管理に関して特別な役割を負うべきではないと主張する。既存のメカニズムが他の政府、複数の政府、もしくは条約機構によって置き換わることがあってはならない。

17 http://www.ntia.doc.gov/ntiahome/domainname/jpacomments2007/jpacomment_085.pdf

68

■ カナダ政府からのコメント要約
カナダ政府は 2 月 15 日付けでNTIAのパブリックコメント募集に対し回答を行った18。
インターネットの技術的な調整については民間主導のまま行うべきとする内容である。
カナダは、インターネットの技術的な調整は民間主導のまま行うべきであり、ボトムアップでマルチステークホルダーの参加のあるポリシー策定プロセスによって行われるべきであるという見方を保っている。
カナダの考えでは、ICANN の「説明責任と透明性に関する枠組み」文書などの手段、原則を実際に実行に移すことが次の段階として非常に重要である。
カナダは、GAC（政府諮問委員会）はインターネット上の名前およびアドレスの調整を民間に移行するという目的にかなうよう、助言を行うという役割に留意しながら、現在の組織見直しの努力を続けていくべきだと確信する。ICANN における政府の役割は、情報提供
や能力開発への貢献など、限定されたものであるべきである。
NTIA は、現行の JPA を基に、ICANN の民間化における次のステップに関する諸課題について、ICANN と議論を開始すべきである。

18 http://www.ntia.doc.gov/ntiahome/domainname/jpacomments2007/jpacomment_162.pdf

69

■ 日本政府からのコメント要約
日本政府もNTIAのパブリックコメント募集に対し回答を行っている19。ICANN体制を支持しつつも、さらなる改善を行っていくことが必要とする内容になっている。
日本政府はインターネット上の資源管理のメカニズムは、情報社会のためのチュニスアジ
ェンダにおいてインターネットガバナンスの既存の取り決めが効果的に機能していることが認識されている通り、既存の ICANN を中心とする体制を基礎として、漸進的に向上を続けるべきであると確信する。
日本政府は、民間部門が主導してインターネットの資源管理において透明性を向上させ、責任説明をよりよく果たしていくようにすることの重要性など、JPA の中に規定されている責務を果たすための努力を ICANN が行っていることを認識している。
特に日本政府は、ICANN ミーティングにおける奨学金制度や即時翻訳、教育的サービスや全世界との情報共有などの取り組みを、インターネットに関する全世界の利害関係者の参加を促し、国際化を果たすための効果的な活動として認識している。
未割り振りの IPv4 アドレス空間はここ数年で枯渇することが予想されており、これはすぐにでも取り組まなければならない問題である。インターネットの持続的成長が可能である
よう、かつ、全世界がその利益に預かれるよう、ICANN は IPv6 へのスムーズな採用を積極的に奨励するよう取り組むべきであるし、例えば、IPv4 アドレスがより効率的に使用されるよう、歴史的な経緯を持つアドレスを含め、使われていない IPv4 アドレスの回収についても取り組むべきである。
日本政府は、JPA に規定されている責務を果たしていることで ICANN が満足するべきではなく、ICANN は今後もインターネットの拡張に伴う課題に速やかに対処するため、向上を続けていくべきである。

今回の中間評価は、2009 年 9 月 30 日に満了を迎える現行の JPA の履行状況を世に問うものである。このパブリックコメントによって直ちに ICANN 体制の行く末が決定されるわけではないが、2009 年には、このまま JPA を終了させて DNS 管理を完全に民間へ、すなわ
ち ICANN へ、移行するのか、それとももう一度 JPA の延長を行って様子を見るのか、関19 http://www.ntia.doc.gov/ntiahome/domainname/jpacomments2007/jpacomment_111.pdf

70

係者を巻き込んだ議論になるであろう。その結論を出すための NTIA によるパブリックコ
メント募集も、2009 年初頭にはあるのではないかと思われる。

71

72

3

インターネット資源管理ポリシーの現状
及びそれに関する議論の動向

73

74

3 インターネット資源管理ポリシーの現状及びそれに関する議論の動向
3-1 IP アドレスに関する管理ポリシーの現状および議論の動向
IP アドレスの管理ルールを IP アドレスポリシー、または単にアドレスポリシーというが、このアドレスポリシーには大きくわけて 2 つの種類がある。それは、主に ICANN(IANA)と RIR 間でのアドレス管理ルールを定めるグローバルポリシー(Global Policy)と、RIR 配
下でのアドレス管理ルールを定める地域ポリシー(Regional Policy)である。グローバルポリ
シーは主に IANA から RIR へのアドレス割り振りポリシーを定めるものであるから、必然的に 1 つの資源に対して定義されるアドレスポリシーはただ 1 つとなる。
これに対して地域ポリシーは、世界に 5 つある RIR がその配下のアドレスをどう管理するのかを定めるものである。したがって、その地域の事情を反映したポリシーが地域ごとに定まることになる。従い、同じ IPv4 アドレスを管理するアドレスポリシーでも、その中身
は地域ごとに微妙に異なる。
ここでは、IPv4 アドレスポリシー及び IPv6 アドレスポリシーが現在どのような内容になっており、また、どのような提案がなされているかに関して、グローバルポリシー及び地域ポリシー双方の観点から見ていくものとする。

3-1-1 IPv4 アドレスポリシー
グローバルポリシー
IPv4 アドレスのグローバルポリシーは、各 RIR での提案、承認のプロセスを経て、2005
年 4 月に ICANN で承認されたポリシーが現在（2008 年 2 月）も有効である。その内容を以下に示す。
[割り振りの原則]
IANA は各 RIR へ、/8 単位で割り振りを行う。
IANA は各 RIR へ、当該 RIR の少なくとも 18 ヶ月分の需要を満たす量の割り振りを行う。
IANA は各 RIR がその配下の NIR/LIR に対する独自の割り振りや予約の手法を適用することを認める。

75

[初期割り振りサイズ]
新たに承認された RIR が出た場合、当該 RIR は/8 の割り振りを IANA から受けることができる。
[追加割り振りサイズ]
利用可能なアドレス空間(AVAILABLE SPACE)が、/8 の 50%を切ったとき、もしくは、利用可能なアドレス空間が、今後 9 ヶ月に必要なアドレス空間(NECESSARYSPACE)の大きさよりも小さくなったとき、IANA は当該 RIR が 18 ヶ月で必要とするアドレス空間に見合う割り振りを、/8 単位で行う。
[利用可能なアドレス空間(AVAILABLE SPACE)の定義]
利用可能なアドレス空間は、現在使われていないアドレスの数と今後 3 ヶ月の間に予約が切れるアドレス数の和から、断片化したアドレスの数(RIR の最小割り振
りサイズ以下のアドレス空間)を引いたものである。
[必要なアドレス空間(NECESSARY SPACE)の定義]
必要なアドレス空間は、過去 6 ヶ月に割り振ったアドレス数の月間平均数に、月数を乗じたものである。
（18 ヶ月に必要なアドレス空間は、過去 6 ヶ月に割り振ったアドレス数の月間平均数に 18 を乗じた大きさとなる。）
過去 6 ヶ月の月間平均割り振りアドレス数とはまた別の需要がある場合、必要なアドレス空間は、当該需要を満たすアドレス数と定義される。ただし、RIR はこの需要を正当化するための資料を提出しなければならない。
2005 年 4 月以降はこのポリシーに従って IANA から RIR への IPv4 アドレス割り振りが行われているが、2007 年 1 月に APNIC が IANA から一度に 5 つの/8 の割り振りを受けたことや、近年高まる IPv4 アドレス在庫枯渇の議論の高まりを受け、RIR 側が自発的に「一度に割り振りを受ける空間は、2 個の/8 まで」といういわば自主規制を打ち出し、現在はそれに沿った割り振りが行われている。
また、IPv4 アドレスのグローバルポリシーについては 2007 年に新しい提案が提出されており、現在（2008 年 2 月）も議論中である。提案内容を以下に示す。
[提案趣旨]
IPv4 アドレスの在庫枯渇が目前に迫る中、IANA に残存している IPv4 アドレスの在庫を各 RIR へ公平に分配することを目的とする。

76

[提案内容]IANA から RIR への最後の割り振り分として、/8 を 25 個分あらかじめ確保する。
IANA の IPv4 アドレスの在庫がその確保分だけになった時点で、5 つの RIR に/8
を 5 個ずつ一斉に割り振り、IANA の在庫を終了させる。
この提案は、ラテンアメリカ地域およびアフリカ地域の有志に（Roque Gagliano 氏（ウルグアイ）、Francisco Obispo 氏（ベネズエラ）、Hytham EL Nakhal 氏（エジプト）Didier
Allain Kla 氏（コートジボワール））よって提出されたものである。この提案は、まず 2007
年 5 月の LACNIC ミーティングで提示され、会場の賛同を得てコンセンサスに至った。グローバルポリシーとして成立するためには、5 つの全ての RIR でコンセンサスを得る必要があるので、この後残り 4 つの RIR でも同様の提案が議論されることとなった。
LACNIC ミーティングの次に開催された APNIC ミーティング（2007 年 8 月）では、「最後の割り振りのために 25 個も確保するのは多すぎるのではないか」との懸念を受け、上記の提案への対案として、最後の割り振り分を 5 個の/8 とし、最後は各 RIR が 1 つずつ/8 の割り振りを受けることではどうかとの提案が提出された。提案を行ったのは、2007 年 1 月に JPNIC が設立した「IPv4 アドレス枯渇期ポリシー検討専門家チーム」である。
その後メーリングリスト上での議論でも「25 個（各 RIR が 5 個ずつ割り振りを受ける）は多すぎる」という意見が出たのを受け、当初の提案はミーティング直前に「10 個（各 RIRが最後に 2 個ずつ割り振りを受ける）」に修正された。
こうして迎えた APNIC ミーティングであるが、会場の意見としては「こういった IANAの在庫をどう終わらせるかに関する何らかのポリシーが必要」という声がわずかに優勢という程度で、コンセンサスを得るには至らなかった。また、「IANA 在庫に関するポリシーがあったという前提で、最後に各 RIR に 2 個ずつ配るのが良いのか、1 個ずつ配るのが良いのか」という議長の問いに対しては、挙手した者のほとんどが「各 RIR に 1 個ずつ配る
べき」という反応であった。
この結果、APNIC ミーティングではラテンアメリカ地域・アフリカ地域有志の提案も、IPv4
アドレス枯渇期ポリシー検討専門家チームの提案も、双方ともコンセンサスに至ることはなく継続議論扱いとされた。
APNIC ミーティングの次に開催された AfriNIC ミーティング（2007 年 9 月）でも、両者の提案は当初の文案のまま並列で提出された。すなわち、ラテンアメリカ地域・アフリカ
地域有志提案が「25 個（各 RIR が 5 個ずつ割り振りを受ける）」を主張し、IPv4 アドレス77

枯渇期ポリシー検討専門家チーム提案が「5 個（各 RIR が 1 個ずつ割り振りを受ける）」を主張するという図式となった。
会場の議論では、IANA から RIR への最終割り振りに関するポリシーが必要なこと、および、最後は各 RIR に同じ量のアドレスを割り振ることについては、概ね妥当であるとの結論となった。そして、最後に RIR が受け取るべき/8 の個数をどうするかが次の議論の焦点となり、出席者の挙手を求めた結果、1 個が妥当とする意見と、2 個が妥当とする意見が拮抗する結果となった。3 個〜5 個についても挙手を求めたが、3 個以上に挙手をするものは皆無であった。結局、その場の結論として、「最後に各 RIR が割り振りを受ける/8 の個数として『1 もしくは 2』をミーティングでのコンセンサスとし、その値を最終的にどちらにするかはメーリングリスト上の議論で決定する」ということとなった。
AfriNIC ミーティングの次に開催されたのは ARIN ミーティング（2007 年 10 月）である。
この時のラテンアメリカ地域・アフリカ地域有志提案は、APNIC ミーティングに提出された修正提案として提出された。つまり、「10 個（各 RIR が最後に 2 個ずつ割り振りを受ける）」として提案された。この ARIN ミーティングでも IPv4 アドレス枯渇期ポリシー検討
専門家チームによる「5 個（各 RIR が 1 個ずつ割り振りを受ける）」の提案は提出され、両者をあわせて議論することとなった。
ミーティングの結果としては、IANA における IPv4 アドレス在庫の最後数ブロックを、一律 RIR へ同じサイズで分配する枠組みについては参加者の支持が得られたが、分配するサイズについては結論を出すことなく、継続議論という扱いになった。
ARIN ミーティングの翌週に開催された RIPE ミーティング（2007 年 10 月）でも、ラテンアメリカ地域・アフリカ地域有志による「10 個（各 RIR が最後に 2 個ずつ割り振りを受ける）」提案と、IPv4 アドレス枯渇期ポリシー検討専門家チームによる「5 個（各 RIR が 1
個ずつ割り振りを受ける）」の提案が並列で議論された。会場の出席者の反応としては「そもそもこのような提案が必要かどうか疑問」という意見もあったが、「必要であるとしたら、5 個（各 RIR が 1 個ずつ割り振りを受ける）」を支持するという意見が多数を占めた。2007
年 10 月の RIPE ミーティングではその場で結論を出すことはせず、継続議論という結果になっている。
こうして APNIC を始めとした 5RIR での最初の議論が終了した。この結果、全ての RIRで合意獲得することを目指し、ラテンアメリカ地域・アフリカ地域有志の提案と IPv4 アド
レス枯渇期ポリシー検討専門家チームの提案とを統一する調整が行われ、最終的に「最後に全ての RIR が 1 個ずつ割り振りを受ける」という案で一本化されることで両者が合意し、78

提案の修正が行われた。
修正案はまず 2008 年 2 月 25 日から行われた APNIC ミーティングで議論された。会場の議論では、前回のミーティングの結果を受けた提案の修正、一本化がなされたことを評価する意見があった一方で、「最後に APNIC が割り振りを受ける/8 の使い道を決めておくべき」など、反対意見も表明された。賛否を問う挙手では賛成が反対を上回ったもののコンセンサスとまでは至らず、議長判断で継続議論となった。
今後この統一修正提案は、ARIN（2008 年 4 月）、RIPE（2008 年 5 月）
、LACNIC（2008
年 5 月）、AfriNIC（2008 年 6 月）の順で議論されていくこととなる。APNIC では今回統一案へのコンセンサスが取れなかったため、全 RIR でコンセンサスが取れるのは最速でも次回の APNIC ミーティングが開催される 2008 年 8 月以降ということになる。

地域ポリシー
前述した通り、各RIRではそれぞれ異なるIPv4 アドレスポリシーを採用している。以下では各RIRのIPv4 アドレスポリシーの主な違いを見ていくこととするが、これについては
RIRの連合体として活動しているNRO(Number Resource Organization)が比較表をウェブ
サイトに掲載20している。以下にIPv4 アドレスポリシーにおける主要項目の比較を示すが、詳細についてはNROの比較表を参照いただきたい。

[初回割り振りについて]
RIR
AfriNIC

分野
サイズ

内容
原則/22（直後の需要が/22 を超えることが正当化できる場
合、この限りではない）

要件

申請者は現在上位 ISP から割り当てを受けている IP アドレ
スを効率的に使っていることを証明しなければならない。また、新たに割り振りを受ける際には、既に受けている割り当てアドレスからリナンバする必要がある。

期間

1 年後21までの需要を認める。

20 http://www.nro.net/documents/nro47.html
21

昨年までは「2 年後までの需要」であった。

79

APNIC

サイズ

原則/2122（直後の需要が/21 を超えることが正当化できる場
合、この限りではない）要件

1) APNIC 会員契約を締結しているか、非会員費用を支払っていること。2) 直後に/23 を使用することを証明できること。3) 過去に割り当てを受けたアドレスをポリシーに従って管理していること。4) 1 年以内に/22 を利用する詳細な計画があること。5) 過去に割り当てを受けたアドレスからリナンバすることに同意すること。

ARIN

期間

1 年後までの需要を認める。

サイズ

マルチホームしているネットワークには最小/22、それ以外
は最小/20 の割り振り。
（直後の需要がこれを超える場合、この限りではない）

要件/22 の割り振りを受ける場合：上位 ISP から/23 の割り当てを受け、効率的に使用していること、マルチホームする意思があること、及びリナンバに合意すること。
/21 の割り振りを受ける場合：上位 ISP から/22 の割り当てを受け、効率的に使用していること、マルチホームする意思があること、及びリナンバに合意すること。
/20 の割り振りを受ける場合：上位 ISP から/21 の割り当てを受け、効率的に使用していること、マルチホームする意思があること、及びリナンバに合意すること。
もしくは、上位 ISP から/20 の割り当てを受け、効率的に使用していること。（リナンバは要件ではない）

LACNIC期間

3 ヶ月後までの需要を認める。

サイズ/21 もしくは/20。（直後の需要がこれを超える場合、この限りではない。
）

22 2008 年 2 月のAPNICミーティングで、これを「/22」へ変更する提案が提出され、コンセンサスを得て

いる。

80

要件

/21 の割り振りを受ける場合：/23 の需要があることを証明すること。
/20 の割り振りを受ける場合：上位 ISP から/22 の割り当てを受け、マルチホームしており、12 ヶ月以内にリナンバすること。
マルチホームしていない場合、上位 ISP から/21 の割り当てを受け、使用していること、及び 12 ヶ月以内にリナンバす
ることに合意すること。

もしくは、直後の需要があることを証明すること。

RIPE NCC

期間

3 ヶ月後までの需要を認める。

サイズ/21（直後の需要がこれを超える場合、この限りではない）

要件

RIPE NCC との契約、及び需要の証明

期間

1 年後までの需要を認める。

81

[追加割り振りについて]
RIR
AfriNIC

分野

内容

サイズ

最小サイズ /22

要件

それまでに割り振りを受けたアドレス総量の 80％を効率的に使用していること。

APNIC

期間

1 年後23までの需要を認める。

サイズ

最小サイズ /21、最大サイズの定めは無し。

要件

それまでに割り振りを受けたアドレス総量の 80％を効率的に使用していること。

ARIN

期間

1 年後までの需要を認める。

サイズ

マルチホームネットワークについては/22 が最小サイズ、それ以外の場合/20。最大サイズの定めは無し。

要件

それまでに割り振りを受けたアドレス全てを効率的に使っていること、及び、最後に割り振りされたアドレスの少なくとも 80％を効率的に使用していること。

期間3 ヶ月後までの需要を認める。1 年以上 ARIN の会員である
ISP は 6 ヶ月後までの需要量を申請できる。

LACNICサイズ

最小サイズ/20、最大サイズの定め無し。

要件

それまでに割り振りを受けたアドレス総量の 80％を効率的に使用していること。

RIPE NCC

期間

1 年後までの需要を認める。

サイズ

最小サイズ/21、最大サイズの定め無し。

要件

それまでに割り振りを受けたアドレス総量の 80％を効率的に使用していること。

期間

23
24

1 年後まで24の需要を認める。

昨年までは「2 年後まで」だった。
昨年までは「最大 2 年後まで」だった。

82

[RIR による IP アドレス割り当て（プロバイダ非依存アドレス）]RIR
AfriNIC

分野

内容

サイズ

最小サイズ/24、最大サイズの定め無し。

要件

現在/25 を使用しているか、1 年後に使うアドレス空間の50%を割り当て直後に使うことを証明すること。

APNIC

サイズ

最小サイズ、最大サイズ共に定め無し。

要件

マルチホームすることを証明し、それまでに割り当てられたアドレスからリナンバすることに同意すること。直後に割り当てアドレスの 25％を使用し、1 年以内に 50％を使用するという基準に従い、サイズが決定される。

ARIN

サイズ

マルチホームネットワークは最小サイズ/22、それ以外は/20。最大サイズの定め無し。

要件

直後に割り当てアドレスの 25％を使用し、1 年以内に 50％を使用するという基準に従い、サイズが決定される。

LACNICサイズ

最小サイズ/24、最大サイズの定め無し。

要件

マルチホームしている組織は上位 ISP から/25 の割り当てを受けている場合、/24 の割り当てを受けることができる。

マルチホームしていない組織は、/21 の需要があることを証明した上で/20 の割り当てを受けることができる。
RIPE NCC

サイズ

最小サイズ、最大サイズ共に定め無し。

要件

需要があることを証明すること。

83

[RIR による割り当て審査]
RIR
AfriNIC内容
該当ポリシー無し。

ARIN
APNIC

LIR が RIR に承認を得ることなく割り当てができるサイズが（アサインメント

LACNIC

ウィンドウ：Assignment Window）が定められており、これを超えるサイズのRIPE NCC

割り当てを行う場合、割り当て前に RIR の承認を得る手続きが必要である。
APNIC には、自社インフラへの割り当てに関するアサインメントウィンドウの適用の定めはない。RIPE では初回割り振りを受けた後 6 ヶ月経過すると、自動的にアサインメントウィンドウが/21 に設定される。

84

ポリシー提案の状況
2007 年 4 月から 2008 年 2 月までの間に、各 RIR へ提出された IPv4 アドレスポリシー提案は以下の通りである。

提案提出先
APNIC

2008 年 2 月末

提案概要

現在の状況

IANA の IPv4 アドレス（/8）の在庫が 25 とな 議論中。
った時点で、各 RIR へ 5 個ずつ/8 を配り、割り （その後、各 RIR へ 1 個ずつ振りを終了する。

配る提案へ一本化された。
）

IANA の IPv4 アドレス（/8）の在庫が 5 となった時点で、各 RIR へ 1 個ずつ/8 を配り、割り振
りを終了する。
APNIC メンバー同士での IPv4 アドレスの移管 議論中。
を認める。
IANA の IPv4 アドレスの在庫が無くなった時点 却下。
で、各 RIR が IPv4 アドレスの在庫を自由に融通しあう。
LIR が共同で利用できる「共有アドレス空間」 却下。
を、APNIC が割り振りを受けたグローバルアド
レスの中から指定する。大きさは/8 を 1 個。
IANA の IPv4 アドレスの在庫が少なくなるに従 提案者が提案を取り消し。
い、IPv4 アドレスの追加割り振り基準を厳しくし、かつ IPv6 の実装も要件として課す。
IPv4 アドレスの最小割り振りサイズを、現行の ミーティングでのコンセンサ/21 から/22 へ変更する。

スを得て、最終コメント期間に
入った。

ARIN

IPv4 プロバイダ非依存アドレスの割り当てサ 却下。
イズを、現行の/22 から/24 へ変更する。
エンドユーザが追加割り当てを要求する場合、 採用、実施済み。
エンドユーザは前回割り当てを受けたアドレスの 80％を利用していなければならない。
ISP に差し迫った必要がある場合に ARIN が割 採用、実施済み。
り振りできるアドレス量を、現行の/20 から、最小割り振りサイズ以上/16 以下とする。

85

エンドユーザに差し迫った必要がある場合に 却下。
は、ARIN は最小割り振りサイズ以上/16 以下の割り当てを行うことができる。
IANA の IPv4 アドレスの在庫が残り 30 を切っ 却下。
た時点から 2 年後を IPv4 アドレスの最終割り
振り期日と定め、前もって告知を行う。
エンドユーザに差し迫った必要がある場合、 却下。
ARIN はエンドユーザに対する割り当てを行う可能性がある、という規定を現行ポリシーから削除する。
歴史的経緯を持つプロバイダ非依存アドレスの 提案者が提案を取り消し。
うち、ARIN と契約関係にないものについては
情報更新を凍結する。
IANA の IPv4 アドレスの在庫が少なくなるに従 提案者が提案を取り消し。
い、IPv4 アドレスの追加割り振り基準を厳しくし、かつ IPv6 の実装も要件として課す。
ISP や LIR からアドレス申請があった場合、 議論中。
ARIN は当該組織に対し、過去のアドレス利用まで含め、ポリシーに沿ったものかを監査する。
歴史的経緯を持つプロバイダ非依存アドレスの 議論中。
割り当てを受けている組織とは 1 年に 1 回必ず連絡を取り、6 ヶ月連絡が取れない組織からはアドレスを回収する。
追加割り振りの割り振り量を、6 ヶ月後までの 議論中。
需要に対応する量という現行の規定から 12 ヶ月後までの需要に対応する量へ変更する。
IANA の IPv4 アドレス（/8）の在庫が 5 となっ 議論中。
た時点で、各 RIR へ 1 個ずつ/8 を配り、割り振
りを終了する。
IANA の IPv4 アドレスの在庫が無くなった時点 議論中。
で、各 RIR が IPv4 アドレスの在庫を自由に融通しあう。
ARIN メンバー同士での IPv4 アドレスの移管を 議論中。
認める。
RIPE NCC

プロバイダ非依存アドレスの割り当てを受ける 議論中。
組織と RIPE との直接契約を義務化する。

86

IANA の IPv4 アドレス（/8）の在庫が 5 となっ 議論中。
た時点で、各 RIR へ 1 個ずつ/8 を配り、割り振
りを終了する。
RIPE から既に割り振りもしくは割り当てを受 議論中。
けたアドレスの全部もしくは一部を RIPE メン
バーに移管することを認める。
IANA の IPv4 アドレスの在庫が無くなった時点 議論中。
で、各 RIR が IPv4 アドレスの在庫を自由に融通しあう。
LACNIC

IANA の IPv4 アドレス（/8）の在庫が 25 とな 採用決定するも、他地域の議論った時点で、各 RIR へ 5 個ずつ/8 を配り、割り 待ち。
振りを終了する。

AfriNIC

IANA の IPv4 アドレスの在庫が無くなった時点 議論中。
で、各 RIR が IPv4 アドレスの在庫を自由に融通しあう。
IANA の IPv4 アドレス（/8）の在庫が 5 となっ 議論中。
た時点で、各 RIR へ 1 個ずつ/8 を配り、割り振
りを終了する。

87

3-1-2 IPv6 アドレスポリシー
グローバルポリシー
IPv6 アドレスのグローバルポリシーは、各 RIR での提案、承認のプロセスを経て、2006
年 9 月に ICANN で承認されたポリシーが現在（2008 年 2 月）も有効である。その内容を以下に示す。
[割り振りの原則]
IANA は各 RIR へ、/12 単位で割り振りを行う。
IANA は各 RIR へ、当該 RIR の少なくとも 18 ヶ月分の需要を満たす量の割り振りを行う
IANA は各 RIR が独自の割り振りや予約の手法を適用することを認める。
[初期割り振りサイズ]
新たに承認された RIR が出た場合、当該 RIR は/12 の割り振りを IANA から受けることができる。
[追加割り振りサイズ]
利用可能なアドレス空間(AVAILABLE SPACE)が、/12 の 50％を切ったとき、もしくは、利用可能なアドレス空間が、今後 9 ヶ月に必要なアドレス空間(NECESSARY SPACE)の大きさよりも小さくなったとき、IANA は当該 RIR が
18 ヶ月で必要とするアドレス空間に見合う割り振りを、/12 単位で行う。
[利用可能なアドレス空間(AVAILABLE SPACE)の定義]
利用可能なアドレス空間は、現在使われていないアドレスの数と今後 3 ヶ月の間に予約が切れるアドレス数の和から、断片化したアドレスの数(RIR の最小割り振
りサイズ以下のアドレス空間)を引いたものである。
[必要なアドレス空間(NECESSARY SPACE)の定義]
必要なアドレス空間は、過去 6 ヶ月に割り振ったアドレス数の月間平均数に、月数を乗じたものである。
過去 6 ヶ月の月間平均割り振りアドレス数とはまた別の需要がある場合、必要なアドレス空間は、当該需要を満たすアドレス数と定義される。ただし、RIR はこの需要を正当化するための資料を提出しなければならない。

88このポリシーの内容は、割り振るアドレスの大きさを除いては IPv4 のグローバルポリシーと同一である。2008 年 2 月現在、このポリシーを見直す動きは出てきていない。

地域ポリシー
IPv4 アドレスポリシーの項でも記述した通り、各RIRではそれぞれ異なるIPv6 アドレスポ
リシーを採用している。以下、各RIRのIPv6 アドレスポリシーの主な違いを見ていくこととするが、これについてもIPv4 アドレスポリシーと同様、RIRの連合体として活動しているNRO(Number Resource Organization)が比較表をウェブサイトに掲載25している。以下にIPv6 アドレスポリシーにおける主要項目の比較を示すが、詳細についてはNROの比較表を参照いただきたい。

[初回割り振りについて]
RIR
AfriNIC

分野

内容

サイズ

/32

要件

1) LIR であること。2) エンドサイトでないこと。3) AfriNIC
地域の組織に対し、IPv6 の接続性を提供する詳細な計画があること。4) 12 ヶ月以内に合理的な数の/48 の割り当てを行う計画があり、その割り当てを 1 つの集成されたブロックで12 ヶ月以内に広報する計画があること。

APNIC

期間

1 年後までの需要を認める。

サイズ

/32

要件

1) LIRであること。2) エンドサイトでないこと。3) /48 を割り当てた組織に対し、IPv6 の接続性を提供する計画があり、その経路広告を、割り振られたアドレス一つに集成して行うこと。4) 2 年以内に最低でも 200 の/48 の割り当てを行う計画があること。26
また、閉域網であっても上記の条件を満たす場合には割り振りを行うことが認められている。

期間

2 年後までの需要を認める。

25 http://www.nro.net/documents/nro41.html
26 2008 年 2 月のAPNICで、「200 の/48 の割り当てを行う計画があること」に修正を加える提案が提出され、コンセンサスを得ている。

89

ARIN

サイズ

/32

要件

1) LIR であること。2) エンドサイトでないこと。3) 割り当てを行った組織に対し IPv6 の接続性を提供する計画があり、その経路広告を、割り振られたアドレス一つに集成して行うこと。4) ARIN 地域において既存、既知の ISP である
か、もしくは 5 年以内に最低でも 200 の/48 の割り当てを行う計画があること。

LACNIC期間

5 年後までの需要を認める。

サイズ

/32

要件

1) LIR もしくは ISP であること。2) 他組織に対して IPv6の接続性を提供する詳細な計画を文書化すること。3) 12 ヶ月以内に、割り振りを受けたアドレスの経路広告を割り振られたアドレス一つに集成して行うこと。4) 24 ヶ月以内に、
LACNIC 地域に位置する顧客に対し、IPv6 サービスを提供すること。

RIPE NCC

期間

1 年後までの需要を認める。

サイズ

/32

要件

1) LIR であること。2) 割り振られたアドレスを単一のプリフィクスに集成してインターネット上で使用すること。3)
他組織への割り振り、もしくはエンドサイトへの割り当てを2 年以内に行う計画があること。

期間

90

2 年後までの需要を認める。

[追加割り振りについて]
RIR
AfriNIC

分野
サイズ

内容
初回割り振りサイズと同じサイズ。それを超える場合、正当化が必要。
HD-ratio=0.94 という式を満たす数の/48 の割り当てを行う

要件必要がある。

APNIC

期間

1 年後までの需要を認める。

サイズ

初回割り振りサイズと同じサイズ。それを超える場合、正当

ARIN

化が必要。
HD-ratio=0.94 という式を満たす数の/56 の割り当てを行う

要件必要がある。

LACNIC期間

2 年後までの需要を認める。

サイズ

初回割り振りサイズと同じサイズ。それを超える場合、正当化が必要。
HD-ratio=0.94 という式を満たす数の/48 の割り当てを行う

要件必要がある。

RIPE NCC

期間

2 年後までの需要を認める。

サイズ

初回割り振りサイズと同じサイズ。それを超える場合、正当化が必要。
HD-ratio=0.8 という式を満たす数の/48 の割り当てを行う

要件必要がある。
2 年後までの需要を認める。

期間[RIR による IP アドレス割り当て（プロバイダ非依存アドレス）]（クリティカルインフラストラクチャへの割り当て）
RIR
AfriNIC
APNIC

分野

内容

サイズ

最小サイズ/48

要件

DNS サーバ、ルートサーバの実際の運用者

サイズ

最大サイズ/32

要件

ルート DNS、ccTLD、gTLD、IANA、RIR、NIR の実際の
運用者

ARIN

サイズ

最小サイズ/48

91

ルート DNS、ccTLD、gTLD、IANA、RIR、IXP の実際の要件

運用者
LACNICサイズ

最小サイズ/48、最大サイズ/32

要件

NAP、ルート DNS、ccTLD、gTLD、IANA、RIR、NIR の
実際の運用者

RIPE NCC

サイズ

ルート DNS については申請時に決定。エニキャスト、gTLDの場合、/48
ルート DNS、gTLD、エニキャストを利用する ccTLD

要件[RIR による IP アドレス割り当て（プロバイダ非依存アドレス）]（エンドユーザへの割り当て）
RIR
AfriNIC

分野

内容

サイズ

最小サイズ/48

要件1) LIR でないこと。2) AfriNIC から IPv4 のプロバイダ非依
存 ア ド レ ス の 割 り 当 て を 受 け る 要 件 を 満 た す こ と 、 3)
AfriNIC の既存メンバーであること、もしくはメンバーになることを計画していること。4) 申請承認後 12 ヶ月以内に割り当てられた IPv6 アドレスを使用し、広報する計画がある
こと。

APNIC

サイズ

最小サイズ/48

要件

既にマルチホームしている、もしくは 3 ヶ月以内にマルチホームする計画があること。

ARIN

サイズ

最小サイズ/48

要件

1) IPv6 の LIR でないこと。2) ARIN の IPv4 ポリシー上で割り当てもしくは割り振りを受ける資格があること。

LACNICサイズ（該当ポリシー無し）

RIPE NCC

要件（該当ポリシー無し）

92

ポリシー提案の状況
2007 年 4 月から 2008 年 2 月までの間に、各 RIR へ提出された IPv6 アドレスポリシー提案は以下の通りである。

提案提出先
APNIC

2007 年 3 月

提案概要

現在の状況

IPv6 アドレスの初回割り振りを受ける要件に ミーティングでのコンセンサ「既に IPv4 の割り振りを受けている LIR で、 スを得て、最終コメント期間
他組織に対して IPv6 の割り当てを行う予定が 中。
あり、割り振りを受けた IPv6 アドレスを 2 年以内に広報する」という条件を追加する。

ARIN

同一エンドサイトに複数の/48 の割り当てを行 却下。
う際に必要な RIR の事前承認手続きの撤廃。
IPv6 初回割り振りを受ける条件の一つである 提案者が提案を取り消し。
「既存の ISP」の定義の明確化。
IPv6 アドレスポリシー中の「Interim」という 採用決定。実施済み。
言葉を外す。

RIPE NCC「Unique Local Address」を RIR が割り振り可 議論中。
能とする。
RIPE データベースに登録されている全てのエ 議論中。
ンドユーザに対して、RIPE が/56 の割り当てを行う。
RIPE の全 LIR に対して、RIPE が IPv6 の割り 議論中。
振りを行う。

LACNIC

IPv6 アドレスポリシー中の「まとまったブロッ 議論中。
ク 1 つに集成しなければならない」という制限を撤廃する。
「Unique Local Address」を RIR が割り振り可 議論中。
能とする。

AfriNIC「Unique Local Address」を RIR が割り振り可 議論中。
能とする。
IPv6 のプロバイダ非依存アドレスの割り当て 採用決定、実施済み。
新設。
HD-Ratio の 0.8 から 0.94 への変更。

採用決定、実施済み。

93

3-1-3 AS 番号ポリシー
グローバルポリシー
IPv4 アドレスのグローバルポリシー、IPv6 アドレスのグローバルポリシーの成立に続き、2007 年は AS 番号のグローバルポリシーの成立に向けた動きが活発であった。2007 年 5 月に RIPE に提案されたのを始めとして、同月に LACNIC、7 月には APNIC、8 月に AfriNIC
および ARIN に提案が提出された。今まで IANA と RIR で行ってきた割り振り手順を文書化しただけの内容ということもあって、各地域とも特に異論が出ることなく承認されている。あとは ICANN 理事の承認が行われれば正式にグローバルポリシーとして成立することとなる。
成立するのを待つばかりとなった AS 番号のグローバルポリシーの内容は、以下の通りである。
[割り振りの原則]
IANA は各 RIR へ、1024 個を 1 単位として AS 番号の割り振りを行う。
2009 年 12 月 31 日までは、2 バイト AS 番号と 4 バイト AS 番号とを区別し、別々の割り振りを RIR が IANA から受けることができる。
IANA は各 RIR が独自の割り振りや予約の手法を適用することを認める。
[追加割り振りの原則]
RIR は次のいずれかの条件を満たせば IANA から追加の AS 番号の割り振りを受けることができる。
以前受けた AS 番号の 80%を割り当てたとき
各 RIR の在庫が、2 ヶ月の需要分を切ったとき。この数字は、過去 6 ヶ月行
った AS 番号割り振り数の平均数から算出するが、RIR 側がそれよりも少ない数を申告した際は、その限りでない。
地域ポリシー
AS 番号の割り当てに関するポリシーは全地域ほぼ共通で、マルチホーム接続を既に行っているか、すぐにマルチホームを行う計画があること、とされている。AS 番号に関して 2008
年 2 月現在で提案されているポリシー提案は、上記のグローバルポリシー提案以外には無
い。

94

第2部

ドメイン名の管理と活用に関する世界的な動向
及び各国における動向調査

95

96

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

2

ドメイン名の登録方針に関する動向

119

120

2 ドメイン名の登録方針に関する動向
2-1 gTLD におけるドメイン名登録方針の動向
2-1-1 .com
2008 年 2 月現在での、.com の登録管理組織は VeriSign, Inc.である。

2-1-1-1 登録組織の歴史及び性質
ドメイン名を含むインターネットの資源管理については、米国政府の援助も受けつつも、
基本的には技術者や研究者のボランティアで運営されていた IANA(Internet Assigned
Numbers Authority) が責任を担う時代が長く続いていたが、1993 年、米国政府機関である全米科学財団(NSF)が IANA の活動の一部に対して資金援助を行い、拡大し続けるインターネットに対応しようとするプロジェクトが始まった。この、NSFNET におけるネットワ
ークインフォメーションセンター（NIC）機能強化のためのプロジェクトは InterNIC と呼ばれ、また InterNIC はこのプロジェクトによって提供されるサービスの総称でもあった。
また、具体的なサービスについては、ディレクトリ&データベースサービスを AT&T に、
情報サービスを General Atomics（契約途中で解約になり、後に AT&T が担当）に、そして登録サービスを Network Solutions, Inc.に委託されることとなった。
NSF か ら 委 託 を 受 け た Network Solutions, Inc. は 、 InterNIC の サ ー ビ ス で ある.com、.net、.org、.edu、.gov の登録サービスおよび IP アドレスの登録サービスを開始した。ドメイン名の登録サービスは当初は無料であったが、1995 年に有料化され、それとともに Network Solutions, Inc.が独占的にドメイン名の登録サービスを提供することに対し、価格・サービス面での競争がないことや、登録ビジネスへの新規参入が阻害されるな
どの批判が強まるようになった。
このような批判を受け、1998 年の設立当初から「ドメイン名登録サービスに競争を導入する」ことを責務の一つに掲げ、レジストリ・レジストラ制度の導入などの取り組みを行ってきた ICANN により、ドメイン名および IP アドレスの管理に関する改革が実行された。
まず、1997 年 12 月に、IP アドレスの割り振りが ARIN(American Registry for Internet
Numbers)に移行され、1999 年 11 月には、ICANN と Network Solutions, Inc の間で.com
に関するレジストリ契約が締結された。この契約にあたっては 4 年間という期間が設けられており、Network Solutions, Inc.がレジストリ業務を行えるのは 2003 年までということ

121

になっていたのだが、もし 18 ヶ月以内に Network Solutions, Inc.がレジストリ部門とレジストラ部門を分離し、一方を売却した場合は、さらに 4 年間（つまり 2007 年まで）延長されるという条件付きの契約となっていた。このレジストリ部門とレジストラ部門を分離するという条件は、レジストラ間の競争をより健全なものにするためのさらなる対策として意図されたものであったのだが、その後導入された共有レジストリシステムが当初想定していた以上の効果を発揮し、レジストラ間の競争環境が急速に改善されるようになったという状況の変化もあり、 それほど重要な意味合いを持たなくなってきたのではないかと考えられるようになっていた。
そのような状況を受け、2000 年に Network Solutions, Inc.を買収した VeriSign, Inc.から、2001 年に ICANN に対してレジストリ契約改訂の提案がなされ、以下のような新しいレジストリ契約が締結された。
・「.com」についてはレジストリ業務を 2007 年 11 月 10 日に終了する。
（ただし、基準を満たせば 4 年間の更新が可能）
・「.org」についてはレジストリ業務を 2002 年 12 月 31 日に終了し、他の組織へ移管する。
・「.net」についてはレジストリ業務を 2005 年 6 月 30 日に終了する。
（ただし、VeriSign, Inc.も次期レジストリへの入札は可能）
この新しい契約により、VeriSign, Inc.はレジストリ部門とレジストラ部門を分離しないことの引き換えとして 2002 年 12 月末に.org の登録管理業務を、2005 年には.net の登録管理業務を手放すこととなった（ただし、.org については新しい登録管理組織が選定されたものの、.net については再び応募した VeriSign, Inc.が登録管理組織として選定されており、現在も VeriSign, Inc.が登録管理業務を行っている）。
なお、Network Solutions, Inc.は、2003 年 11 月まで VeriSign, Inc.のレジストラ部門として機能していたが、2003 年 11 月に Pivotal Private Equity に買収され、以来、VeriSign, Inc.
は.com のレジストリ事業のみを行っている。

2-1-1-2 登録管理組織の運営形態
CEO を含む 9 名の取締役から構成される取締役会と、担当役員が会社を運営している。 .com ドメイン名に関するポリシーは、ICANN との契約に基づいており、ICANN のポリシー策定プロセスにしたがって定められる。

122

2-1-1-3 レジストラ数
2008 年 2 月時点での、.com ドメイン名を取り扱うレジストラ数は、873 社となっている。

2-1-1-4 登録可能ドメイン名数の制限の有無
登録可能なドメイン名の数に特に制限は無い。

2-1-1-5 予約ドメイン名
ICANN との契約に基づき、以下のドメイン名が予約されている。
(1) 全レベルでの予約語
・ICANN に関連する名前
・IANA に関連する名前(2) セカンドレベルでの予約語
・1 文字のドメイン名
・2 文字のドメイン名
・ICANN が定める TLD 名(3) タグ付きドメイン名(3、4 文字目にハイフンを含むドメイン名)(4) レジストリ運用のための予約語

2-1-1-6 IDN の登録申請の可否等2000 年 11 月より試験登録を開始した。標準化に対応した仕様でのサービスは 2003 年 12月より開始し、2004 年 4 月に標準化を完了した。350 種類以上の文字による登録が可能となっている。

123

2-1-1-7 登録件数
69,621,530 (2007 年 10 月現在)

2-1-1-8 料金
2008 年 2 月現在、VeriSign,Inc. がレジストラに課すドメイン名登録料金は、1 ドメイン名
あたり年間 6.42 米ドルとなっている。

2-1-2 .net
2008 年 2 月現在での、.net の登録管理組織は VeriSign, Inc.である。

2-1-2-1 登録組織の歴史及び性質
現在の.net の登録管理業務については、.com と同様に VeriSign, Inc.によって行われている。
したがって、登録組織の歴史および性質については、.com と同様である。詳細については.com の項目も併せて参照されたい。
.net の登録管理についても、米国政府の支援を受けつつも、基本的には技術者や研究者のボランティアで運営されていた IANA(Internet Assigned Numbers Authority) が責任を担う時代が長く続いていたが、1993 年に米国政府機関である全米科学財団(NSF)が IANA の活動の一部に対して資金援助を行い、InterNIC と呼ばれるプロジェクトがスタートした。
また、実際の InterNIC のサービス提供については、3 つの組織にそれぞれ委託され、ドメ
イン名および IP アドレスの登録サービスについては、Network Solutions, Inc.に委託されることとなった。
Network Solutions, Inc.は、InterNIC のサービスである.com、.net、.org、.edu、.gov の登録サービスおよび IP アドレスの登録サービスを開始し、その後、独占的サービスを提供する Network Solutions, Inc.に対する批判が高まるとともに、1997 年 12 月に IP アドレスの割り振りが ARIN(American Registry for Internet Numbers)に移行され、1999 年 11 月には、ICANN と Network Solutions, Inc の間で.net に関するレジストリ契約が締結された。

124

この契約にあたっては 4 年間という期間が設けられており、Network Solutions, Inc.がレジストリ業務を行えるのは 2003 年までということになっていたのだが、もし 18 ヶ月以内に
Network Solutions, Inc.がレジストリ部門とレジストラ部門を分離し、一方を売却した場合は、さらに 4 年間（つまり 2007 年まで）延長されるという条件付きの契約となっていた。
このレジストリ部門とレジストラ部門を分離するという条件は、レジストラ間の競争をより健全なものにするためのさらなる対策として意図されたものであったのだが、その後導入された共有レジストリシステムが当初想定していた以上の効果を発揮し、レジストラ間の競争環境が急速に改善されるようになったという状況の変化もあり、 それほど重要な意
味合いを持たなくなってきたのではないかと考えられるようになっていた。
そのような状況を受け、2000 年に Network Solutions, Inc.を買収した VeriSign, Inc.から、2001 年に ICANN に対してレジストリ契約改訂の提案がなされ、以下のような新しいレジストリ契約が締結された。
・「.net」についてはレジストリ業務を 2005 年 6 月 30 日に終了する。
（ただし、VeriSign, Inc.も次期レジストリへの入札は可能）
・「.org」についてはレジストリ業務を 2002 年 12 月 31 日に終了し、他の組織へ移管する。
・「.com」についてはレジストリ業務を 2007 年 11 月 10 日に終了する。
（ただし、基準を満たせば 4 年間の更新が可能）
この新しい契約により、VeriSign, Inc.はレジストリ部門とレジストラ部門を分離しないことの引き換えとして 2002 年 12 月末に.org の登録管理業務を、2005 年には.net の登録管理業務を手放すこととなった。
そして、2005 年に.net の新たな登録管理組織選定のための入札が行われたが、上記の通り
VeriSign, Inc.も応札することが可能であった。新レジストリ募集には、VeriSign, Inc.の他に、「.biz」と「.us」のレジストリである NeuLevel, Inc.と日本の ccTLD レジストリである
株式会社日本レジストリサービス(JPRS)によって設立された、Sentan Registry Services,
Inc.、スイスの ccTLD レジストリである SWITCH、また今回の応募のために新たに設立された組織などが応募したが、2 位の Sentan Registry Services, Inc.を僅差で抑え、VeriSign,
Inc.が.net のレジストリとして選定された。
このような経緯を経て、2008 年 2 月時点においても、VeriSign, Inc.が.net のレジストリ業
務を行っている。また、この新しい契約については、期間が 6 年と定められていることから、2011 年までは現在の体制が継続されることになる。

125

なお、Network Solutions, Inc.は、2003 年 11 月まで VeriSign, Inc.のレジストラ部門として機能していたが、2003 年 11 月に Pivotal Private Equity に買収され、以来、VeriSign, Inc.
は.net のレジストリ事業のみを行っている。
2-1-2-2 登録管理組織の運営形態
CEO を含む 9 名の取締役から構成される取締役会と、担当役員が会社を運営している。.net
ドメイン名に関するポリシーは、ICANN との契約に基づいており、ICANN のポリシー策
定プロセスにしたがって定められる。

2-1-2-3 レジストラ数
2008 年 2 月時点での、.net ドメイン名を取り扱うレジストラ数は、873 社となっている。

2-1-2-4 登録可能ドメイン名数の制限の有無
登録可能なドメイン名の数に特に制限は無い。

2-1-2-5 予約ドメイン名
ICANN との契約に基づき、以下のドメイン名が予約されている。
(1) 全レベルでの予約語
・ICANN に関連する名前
・IANA に関連する名前(2) セカンドレベルでの予約語
・1 文字のドメイン名
・2 文字のドメイン名
・ICANN が定める TLD 名(3) タグ付きドメイン名(3、4 文字目にハイフンを含むドメイン名)

126

(4) レジストリ運用のための予約語

2-1-2-6 IDN の登録申請の可否等2000 年 11 月より試験登録を開始した。標準化に対応した仕様でのサービスは 2003 年 12月より開始し、2004 年 4 月に標準化を完了した。350 種類以上の文字による登録が可能となっている。

2-1-2-7 登録件数
10,398,432 (2007 年 10 月現在)

2-1-2-8 料金
2008 年 2 月現在、VeriSign,Inc. がレジストラに課すドメイン名登録料金は、1 ドメイン名
あたり年間 6.42 米ドルとなっている。

2-1-3 .org
2008 年 2 月現在での、.org の登録管理組織は Public Interest Registry(PIR)である。

2-1-3-1 登録組織の歴史及び性質.org の登録管理についても、.com や.net と同様に、元々は米国政府の支援を受けつつも、
基本的には技術者や研究者のボランティアで運営されていた IANA(Internet Assigned
Numbers Authority)によって行われていた。しかし、1993 年に米国政府機関である全米科学財団(NSF)が IANA の活動の一部に対して資金援助を行い、InterNIC と呼ばれるプロジ
ェクトがスタートすることとなった。また、実際の InterNIC のサービス提供については、
3 つの組織にそれぞれ委託され、ドメイン名および IP アドレスの登録サービスについては、
Network Solutions, Inc.に委託されることとなった。

127

NSF か ら 委 託 を 受 け た Network Solutions, Inc. は 、 InterNIC の サ ー ビ ス で ある.com、.net、.org、.edu、.gov の登録サービスおよび IP アドレスの登録サービスを開始し、その後、独占的サービスを提供する Network Solutions, Inc.に対する批判が高まるとともに、1997 年 12 月に IP アドレスの割り振りが ARIN(American Registry for Internet
Numbers)に移行され、1999 年 11 月には、ICANN と Network Solutions, Inc の間で.org
に関するレジストリ契約が締結された。
この契約にあたっては 4 年間という期間が設けられており、Network Solutions, Inc.がレジストリ業務を行えるのは 2003 年までということになっていたのだが、2000 年に Network
Solutions, Inc.を買収した VeriSign, Inc.から、2001 年に ICANN に対してレジストリ契約
改訂の提案がなされ、さらに以下のような新しいレジストリ契約が締結された。
・「.org」についてはレジストリ業務を 2002 年 12 月 31 日に終了し、他の組織へ移管する。
・「.com」についてはレジストリ業務を 2007 年 11 月 10 日に終了する。
（ただし、基準を満たせば 4 年間の更新が可能）
・「.net」についてはレジストリ業務を 2005 年 6 月 30 日に終了する。
（ただし、VeriSign, Inc.も次期レジストリへの入札は可能）
この新しい契約により、VeriSign, Inc.はレジストリ部門とレジストラ部門を分離しないことの引き換えとして 2002 年 12 月末に.org の登録管理業務を手放すこととなり、2003 年からは新しい組織が.org の登録管理業務を行うこととなった。
この新しい.org の登録管理組織募集に応募するために、ISOC によって設立された組織がPIR(Public Interest Registry)である。ISOC は非営利の国際組織であり、インターネット
技術およびシステムに関する標準化、教育、ポリシーに関する課題や問題を議論し、解決することを目的とした組織である。1992 年から、インターネットの普及促進と関連技術の開発促進という観点から、国際的な調整機関としての役割を果たしてきており、下部組織として IETF(Internet Engineering Task Force)や IAB(Internet Architecture Board)などが存在している。
様々な観点から、応募した数多くの組織について評価が行われた結果、この PIR が新しい.org のレジストリとして選定され、それまでレジストリ業務を行っていた VeriSign, Inc.
から業務を引き継ぐこととなった。
PIR はただちに.org ドメイン名の移管に取りかかり、2003 年 1 月 1 日から.org の登録管理業務が VeriSign, Inc.から PIR に移されることとなったが、移行のための期間として 2003128

年 1 月 1 日から 25 日までの 25 日間が設定され、この間については VeriSign, Inc.が継続して技術面のバックエンドサービスを提供することとなった。この移行期間終了後は、PIRが単独で.org のサービスを提供している。
なお、PIR と ICANN の間で締結された.org のレジストリ契約期間は 2013 年６月までとなっているが、延長が可能な契約となっている。また、PIR は技術的な運用面において、.infoのレジストリである Affilias Limited.から技術面でのサポートを受けつつ、.org の登録管理業務を行っている。

2-1-3-2 登録管理組織の運営形態
PIR には 5 名の理事からなる理事会が存在する。また、.org の運用にあたり、ポリシー策
定や新規事業の実施などに際して、非商用のインターネットユーザから幅広い意見を取り入れることを目的として、諮問委員会が設置されている。この諮問委員会は、世界各地から選ばれた 16 名の委員によって構成されている。

2-1-3-3 レジストラ数
2008 年 2 月時点での、.org ドメイン名を取り扱うレジストラ数は、293 社となっている。

2-1-3-4 登録可能ドメイン名数の制限の有無
登録可能なドメイン名の数に特に制限は無い。

2-1-3-5 予約ドメイン名
ICANN との契約に基づき、以下のドメイン名が予約されている。
(1) 全レベルでの予約語
・ICANN に関連する名前
・IANA に関連する名前

129

(2) セカンドレベルでの予約語
・1 文字のドメイン名
・2 文字のドメイン名
・ICANN が定める TLD 名(3) タグ付きドメイン名(3、4 文字目にハイフンを含むドメイン名)(4) レジストリ運用のための予約語

2-1-3-6 IDN の登録申請の可否等.com や.net と同様、VeriSign, Inc.が登録管理業務を行っていたことから、2000 年 11 月より試験登録を開始している。その後、2003 年の VeriSign, Inc.から PIR への登録管理業務の移管を受けて、しばらくの間は国際化ドメイン名は新規の登録受付および既存の登録ド
メイン名の変更が一切できない状態とされていた。さらに、既存の国際化ドメイン名の登録を廃止する旨のアナウンスが突然出され、それがすぐに覆されるというようなやや混乱した状況と経た後、2005 年からドイツ語文字のウムラウトを使用した国際化ドメイン名の登録を開始している。その後さらに対応言語を増やし、現在では 10 の言語による国際化ド
メイン名の登録が可能となっている。

2-1-3-7 料金
2008 年 2 月現在、PIR がレジストラに課すドメイン名登録料金は、1 ドメイン名あたり年間 6.15 米ドルとなっている。

2-2

各国におけるドメイン名登録方針の動向

2-2-1 概況
2008 年 1 月末時点で、世界には 252 の ccTLD（country code Top Level Domain：国コー
ドトップレベルドメイン）が存在する（http://www.icann.org/announcements/announcement-16oct07.htm より）。ドメイン名の登録件数としては、.de（ドイツ）が最も多く、約 1,180 万件に達している。以下、.cn（中130国）が約 900 万件、.uk（イギリス）が約 650 万件、.eu（欧州連合）が約 280 万件と続く。
特に.cn の伸びが目覚ましく、前年同期比の伸び率が約 400%に達している。
（以上 2008 年
1 月現在）。

2-2-2

各 TLD の登録管理体制およびドメイン名登録方針● はじめに
本報告書では、18 の ccTLD（.jp（日本）、.au（オーストラリア）、.be（ベルギー）、.ca（カナダ）、.ch（スイス）、.cn（中国）、.de（ドイツ）、.eu（欧州連合）、.fr（フランス）、.hk（香港）、.it（イタリア）、.kr（韓国）、.nl（オランダ）、.se（スウェーデン）、.sg（シンガポール）、.tw（台湾）、.uk（イギリス）、.us（米国））について、以下に示す項目ごとに調査した結果をまとめた。
● 調査項目(1)登録管理組織の歴史および性質
登録管理組織の設立の経緯、法的位置付け。
(2)登録管理組織の運営形態
登録管理組織の組織運営の方法、特に当該ドメイン名に関するポリシー決定に関わる意思決定方法。
(3)会員
登録管理組織が会員制組織の形態を取っているか否か、会員制度を採用している場合はその会員数。
(4)登録管理業務の委任体制
登録業務についての委任体制が取られているか否か。委任体制が取られている場合はその内容およびレジストラ（登録代行業者）の数。
(5)ドメイン名の構成
登録可能なドメイン名の種類と登録対象および登録可能文字数など。

131

(6)登録可能ドメイン名数の制限の有無
同一の申請者（組織あるいは個人）が登録できるドメイン名の数に制限を設けているか否か。制限がある場合はその定義。
(7)ローカルプレゼンス要件
ドメイン名の登録を自国・地域内に制限する「ローカルプレゼンス要件」を採用しているか否か。採用している場合はその定義。
(8)個人用ドメイン名
個人用のドメイン名のカテゴリを設けているか。設けている場合は、その種類と登録要件。また、公開されている場合は、個人用ドメイン名の登録件数。
(9)予約ドメイン名
予約ドメイン名の有無、種類、予約ドメイン名リストが公開されている場合はその参照
先 URI。
(10)IDN
IDN（国際化ドメイン名）の登録申請を受け付けているか否か、受け付けている場合は登録可能文字などの詳細。
(11)登録件数
登録ドメイン名の累積総数。
(12)料金ドメイン名の登録にかかる料金。主としてレジストリがレジストラまたは登録者に課す料金を指す。料金額が公開されている場合のみ記載する。
(13)紛争処理
ドメイン名登録に関して、登録者と第三者との間に紛争が生じた場合の処理方針を特に定めているか否か。定めている場合は紛争処理方針文書と紛争処理機関の名称。
(14)その他
その他の特記事項。
(15)出典本調査で参照した URI。

132

● 調査方法
調査は、各 TLD 登録管理組織が発行している文献の調査および各登録管理組織への聞き取りによって行った。
● 調査期間2007 年 12 月から 2008 年 3 月。

2-2-2-1 .jp（日本）
登録管理組織：JPRS（株式会社日本レジストリサービス）(1)登録管理組織の歴史および性質.jp は村井純氏に 1980 年代中盤頃に委任され、1986 年 8 月に IANA のデータベースに登録された。.jp の登録管理は 1989 年 4 月に JUNET において開始されたが、その後、JNIC（Japan Network Information Center）、JPNIC（JaPan Network Information Center）
へと引き継がれた。1990 年代後半になると、社会におけるインターネット利用の拡大に伴い、JP ドメイン名に対するニーズが多様化した。この多様化に対応するため、2000
年 12 月に行われた JPNIC の総会決議に基づき、JPRS が株式会社として設立された。
そして、2002 年 2 月に JPNIC と JPRS との間で「登録管理業務移管契約」が締結され、同年 4 月、JPRS は JPNIC から JP ドメイン名の登録管理業務の移管を受けた。
(2)登録管理組織の運営形態
JPRS は、株式会社として日本の会社法に基づき運営されている。また、JPRS が行う JP
ドメイン名登録管理業務の公平性および中立性を実現するため、JPRS 内に外部委員で構成する「JP ドメイン名諮問委員会（以下「諮問委員会」）」が設置されている。諮問委員
会の委員は、JPNIC、JP ドメイン名指定事業者、インターネットサービスプロバイダ（以下「ISP」）、企業、学識経験者、インターネットユーザからの代表各 1 名（合計 6 名）となっている。諮問委員会は、ドメイン名登録規則その他関連規則、指定事業者の選定や契約終了に関する基準などに関して、JPRS 取締役会の諮問に対する答申および取締役会への勧告を行う。その答申または勧告を受け、取締役会が対応方針を決定する。

133

(3)会員なし。
(4)登録管理業務の委任体制
JPRS は、JP ドメイン名登録申請や DNS 登録申請などの取次を行う事業者を指定事業者として認定し、その取次に関する業務を指定事業者に委任している。なお、地方公共団体とそれらの組織が行う行政サービスに登録資格を限定した LG.JP の登録申請等の取次に関する業務は、財団法人地方自治情報センターに委任している。
以下は、JP ドメイン名指定事業者の数。

属性型・地域型

汎用

600
500
400
300
200
100

2008年1月

2007年1月

2006年1月

2005年1月

2004年1月

2003年1月

2002年1月

2001年1月

0（単位：社）
年月134

属性型・地域型
JP ドメイン名

汎用 JP ドメイン名

合計(のべ数)2001 年 4 月

---

443

443

2002 年 1 月

---

490

490

2003 年 1 月

560

546

1,106

2004 年 1 月

557

559

1,116

2005 年 1 月

553

564

1,117

2006 年 1 月

562

576

1,138

2007 年 1 月

559

572

1,131

2008 年 1 月

557

573

1,130

(5)ドメイン名の構成
第 2、第 3、第 4 レベルへの登録。登録可能な文字列は英数字、ハイフン。また、日本語JP ドメイン名では漢字、平仮名、カタカナ。登録可能な文字数は、ASCII のドメイン名
が 3 文字以上 63 文字以下、日本語 JP ドメイン名が 1 文字以上 15 文字以下。以下の通り分類される。
a) 属性型（組織種別型）JP ドメイン名
・CO.JP：企業（株式会社、有限会社など）
・OR.JP：AC.JP、CO.JP、ED.JP、GO.JP、地方公共団体ドメイン名のいずれにも該
当しない日本国法に基づいて設立された法人（財団法人、社団法人など）
・NE.JP：ネットワークサービス
・AC.JP：高等教育機関（大学、学術研究機関など）
・AD.JP：JPNIC 会員、IP アドレス管理指定事業者などの組織
・ED.JP：初等中等教育機関（小学校、中学校など）
・GO.JP：政府機関、各省庁所轄研究所、独立行政法人、特殊法人（特殊会社を除く）
・GR.JP：任意団体
・LG.JP：地方公共団体など
b) 地域型 JP ドメイン名b-1) 一般地域型ドメイン名
・<組織ラベル>.<市区町村ラベル>.<都道府県ラベル>.JP：
AD.JP、CO.JP、ED.JP、GO.JP、OR.JP、NE.JP、GR.JP のいずれかの属性型（組織種別型）ドメイン名の登録資格を満たす組織、病院、日本に在住する個人b-2) 地方公共団体ドメイン名
・<都道府県属性ラベル〉.<都道府県ラベル>.JP：
都道府県・政令指定都市（例：東京都 metro.tokyo.jp）
・<組織ラベル>.<都道府県属性ラベル>.<都道府県ラベル>.JP：
都道府県・政令指定都市がドメイン名を登録していない場合に、その下部組織が暫定的に登録できる
・<市区町村属性ラベル>.<市区町村ラベル>.<都道府県ラベル>.JP：
市町村・東京都特別区（例：千代田区 city.chiyoda.tokyo.jp）
・<組織ラベル>.<市区町村属性ラベル>.<市区町村ラベル>.<都道府県ラベル>.JP：
市町村・東京都特別区がドメイン名を登録していない場合に、その下部組織が暫定的に登録できるc) 第 2 レベルドメイン名（以下「汎用 JP ドメイン名」）（ASCII）
・.JP：日本国内に住所をもつ個人・法人・その他の組織

135d) 汎用 JP ドメイン名（日本語）・.JP：日本国内に住所をもつ個人・法人・その他の組織(6)登録可能ドメイン名数の制限の有無
NE.JP と GO.JP を除く属性型（組織種別型）および地域型 JP ドメイン名では、1 つの組織が登録できるドメイン名の数は 1 つ。NE.JP の場合は、1 つのネットワークサービ
スごとに 1 つのドメイン名を登録することができ、GO.JP については、1 つの組織で複数のドメイン名を登録することができる。汎用 JP ドメイン名では、登録できるドメイン
名の数に制限はない。
(7)ローカルプレゼンス要件
全ての JP ドメイン名はローカルプレゼンス要件を備えている。具体的な条件は以下の通り。
a) 属性型（組織種別型）JP ドメイン名
・日本に在住する個人、任意団体、または日本国法に基づいて設立された組織であること。CO.JP は日本で外国会社の登記を行っている外国会社も登録可能。
b) 地域型 JP ドメイン名b-1) 一般地域型 JP ドメイン名
・AC.JP、CO.JP、ED.JP、GO.JP、OR.JP、NE.JP、GR.JP のいずれかの属性型（組織種別型）ドメイン名の登録資格を満たす組織であること、または（日本に所在する）
病院または日本に在住する個人であること。
b-2) 地方公共団体ドメイン名
・（日本の）普通地方公共団体およびその機関、特別区およびその機関であること。
c) 汎用 JP ドメイン名
・日本国内に住所を有する個人、法人その他の組織であること。
(8)個人用ドメイン名
個人を登録対象と定義したドメイン名カテゴリは設けていないが、汎用 JP ドメイン名は個人でも登録可能。
(9)予約ドメイン名a) 属性型（組織種別型）
・地域型 JP ドメイン名
・インターネットで使用されている特定の TLD（「com」、「org」、「net」など）
・都道府県ラベル、JP ドメイン名のサービスなどで予約を必要とする名称
・3、4 文字目にハイフンを含む文字列
・その他 JPRS が指定する文字列

136b) 汎用 JP ドメイン名（ASCII）
・ccTLD 以外の TLD として ICANN が定めている以下の文字列「com」、「org」、「net」、「edu」、「gov」、「mil」、「int」、「arpa」、「biz」、「info」、「name」、「pro」、「museum」、「aero」、「coop」
・地域型 JP ドメイン名における「都道府県属性ラベル」および「市区町村属性ラベル」（「pref）、「metro」、「city」、「town」、「vill」）
・都道府県名および政令指定都市名のアルファベット表記
・中核市かつ県庁所在地である都市名のアルファベット表記
・インターネットの管理に関連する組織名（「ICANN」、「IANA」、「WIPO」など）
・3、4 文字目にハイフンを含む文字列
・JP ドメイン名のサービスなどで予約を必要とするドメイン名（「example」、「example」の後に 1 桁の数字（0 から 9）がつく文字列）c) 汎用 JP ドメイン名（日本語）・都道府県名および政令指定都市名
・中核市かつ県庁所在地である都市名・平仮名、片仮名、漢数字、記号などによる１文字
・初等中等教育機関などの名称
・国際的な政府間機関（国際連合など）の名称
・行政・司法・立法に関連する名称
・日本語普通名詞・JP ドメイン名のサービスなどで予約を必要とするドメイン名（「ドメイン名例」）
・その他 JPRS がドメイン名登録に適さないと判断する文字列(10)IDN
汎用 JP ドメイン名で IDN（日本語 JP ドメイン名）を導入している。2001 年 2 月から 4月にかけて段階的なサンライズ期間を設けた後、2001 年 5 月 7 日から先願に基づく一般向け登録申請の受付を開始した。日本語 JP ドメイン名の登録件数は、141,858（2008 年
1 月 1 日現在）。

137

(11)登録件数
JP ドメイン名の累計登録数は、988,886（2008 年 1 月 1 日現在）となっている。以下は、JP ドメイン名登録件数累計の推移。
属性型・地域型

汎用(ASCII)

汎用(日本語)1,000,000
900,000
800,000
700,000
600,000
500,000
400,000
300,000
200,000
100,000

19
93

年
19 1月
94
年
19 1月
95
年
19 1月
96
年
19 1月
97
年
19 1月
98
年
19 1月
99
年
20 1月
00
年
20 1月
01
年
20 1月
02
年
20 1月
03
年
20 1月
04
年
20 1月
05
年
20 1月
06
年
20 1月
07
年
20 1月
08
年
1月

0

年月

属性型・地域型

汎用 JP ドメイン名

汎用 JP ドメイン名

JP ドメイン名(ASCII)

(日本語)

953

---

---

953

1,341

---

---

1,341

2,206

---

---

2,206

4,781

---

---

4,781

15,477------

15,47733,739------33,73958,549------58,549合計

1993 年 1月1994 年 1月1995 年 1月1996 年 1月1997 年 1月1998 年 1月1999 年 1月

1382000 年 1
月

124,573------

124,573

234,294------234,294

2001 年 1月2002 年 1月

283,340

121,992

61,507

466,839

297,413

153,949

51,544502,906

309,193

199,698

45,402554,293

327,742

254,131

63,324645,197

346,340

323,182

116,602786,124

363,768

394,404

124,153882,325

378,903

468,125

141,858

988,886

2003 年 1月2004 年 1月2005 年 1月2006 年 1月2007 年 1月2008 年 1月

以下は JP ドメイン名登録累計の内訳。
※2008 年 1 月 1 日現在

139（単位：件）JP ドメイン名種類

2008 年 1 月 1 日

2007 年 1 月 1 日

登録数

登録数

増減数

属性型・

AC：大学など教育機関

3,421

3,335

+86

地域型

AD：JPNIC 会員など

282

289

-7

JP ドメ

CO：一般企業

315,374

300,899+14,475

イン名

ED：小・中・高校

4,505

4,451

+54

GO：政府機関

878

870

+8

GR：任意団体

8,329

8,592

-263

LG：地方公共団体

2,087

2,225

-138

NE：ネットワークサービ

17,39817,414-16

OR：会社以外の法人

23,51822,368

+1150

地域型

3,111

3,325

-214

汎用 JP ドメ

ASCII

468,125

394,404+73,721

イン名

日本語

141,858

124,153+17,705

988,886

882,325+106,561

ス

JP ドメイン名登録数計(12)料金

汎用 JP ドメイン名の年間登録料金は 1 件あたり 2,500 円（消費税および地方消費税別）。
日本語 JP ドメイン名では上記よりもさらに低いキャンペーン料金を設定している。ただし、これらは指定事業者が JPRS に支払う料金であり、登録者が指定事業者に支払う料
金は各指定事業者の提供するサービスによって異なる。
(13)紛争処理
JPNIC が策定する「JP ドメイン名紛争処理方針」および「JP ドメイン名紛争処理方針のための手続規則」を採用している。現在、JP ドメイン名紛争処理手続きは、JPNIC の認定を受けた日本知的財産仲裁センターが実施している。
(14)その他
・2007 年 3 月より、JPRS は、汎用 JP ドメイン名の廃止後一定期間内であれば、そのドメ
イン名を廃止される直前の登録状態に回復できる手続きを導入した。
・2007 年 8 月に開催した諮問委員会で、JPRS は、フィッシング被害防止においてドメイ
ン名レジストリが担うべき活動の方針を諮問した。また、これまで行ってきた周知啓発活動に加え、諮問委員会での検討をもとに関係各所と協力しつつフィッシング被害の防止に
どのような役割を果たすことができるのか、検討を進めることとした。

140

・2007 年 12 月、WIDE Project と JPRS は、JP DNS のさらなる信頼性向上のため、WIDE
Project が運用する JP DNS サーバ「e.dns.jp」の海外拠点（サンフランシスコ（米国）、
パリ（フランス））を追加し、IP Anycast 技術を導入した。
・マイクロソフト社が Internet Explorer に実装している Web プロキシ自動発見（WPAD）
についての脆弱性を発表したことを受け、2007 年 12 月に、JPRS は一般ユーザおよびサー ビ ス プ ロ バ イ ダ 等 を 対 象 と し た 注 意 喚 起 お よ び 対 策 の た め の Web ペ ー ジ（http://jprs.jp/tech/notice/2007-12-21-Web-Proxy-Auto-Discovery-alert.html）を公開した。また、レジストリとしての対策の一環として、組織ラベルに「WPAD」を使用した属性型（組織種別型）
・地域型 JP ドメイン名を、当面予約ドメイン名に指定することにした。
(15)出典・JPRS
http://jprs.co.jp/
・JPRS JP ドメイン名サービス案内
http://jprs.jp/
・社団法人日本ネットワークインフォメーションセンター
http://www.nic.ad.jp/
・日本知的財産仲裁センター
http://www.ip-adr.gr.jp/

2-2-2-2 .au（オーストラリア）
登録管理組織：auDA（.au Domain Administration Ltd.）(1)登録管理組織の歴史および性質
メルボルン大学のネットワークプログラマを務めていた Robert Elz 氏が、1986 年にIANA（Internet Assigned Numbers Authority）に対して.au トップレベルドメインの創設を要請し、これを受けて、IANA が.au の登録管理責任を Elz 氏個人に委任した。その後、.au の登録管理責任を Elz 氏から民間組織に移すべきとの議論が国内でなされた結果、1997 年 、 .au の 登 録 管 理 を 担 う 組 織 と し て ADNA （ Australian Domain Name
Administration ） が 設 立 さ れ 、 そ の 後 1999 年 に 非 営 利 法 人 .auDA （ .au Domain
Administration）へと再編された。auDA は、2000 年 12 月にオーストラリア政府と契約を締結し、政府から.au の登録管理組織として認定された。auDA の機能は、ドメイン
名ポリシーの策定と実施、第 2 レベルドメインのレジストリの認定、レジストラの認定、登録者保護施策の実施、.au 紛争処理方針の維持である。

141

(2)登録管理組織の運営形態
2007 年の年次総会以後における auDA 理事会は、Supply Class 会員によって選ばれた 4
名、Demand Class 会員によって選ばれた 4 名、CEO（投票権無し）、理事に任命された3 名以下の独立理事から成る。また、課題ごとに、必要に応じ諮問パネルまたは委員会が設置され、理事会へポリシーの提案を行っている。
(3)会員
auDA の会員は、Supply Class および Demand Class で構成される。Supply Class 会員
は、レジストリ、レジストラ、リセラから成る。Demand Class 会員は、登録者、インターネットユーザなど。会員になるためには、理事会の承認が必要となる。会員は、総会での投票権を持ち、Supply Class および Demand Class からそれぞれ理事を選出する。2006
年 8 月の臨時総会において、それまで存在した Representative Association Class 会員（100 名以上で構成する団体）は廃止され、ここに分類されていた会員は、Supply Class
会員または Demand Class 会員に移行した。Supply Class 会員は 35、Demand Class 会
員は 78 となっている（2007 年 12 月現在）。
(4)登録管理業務の委任体制
auDA が実施した競争入札の結果に基づき 、AusRegistry が、ASN.AU、COM.AU、
EDU.AU、GOV.AU、ID.AU、NET.AU、ORG.AU のドイン名について、2010 年 6 月末
までレジストリ業務の委任を受けている。さらに、26 社のレジストラが AusRegistry に対する登録申請の取次を行っている（2008 年 1 月現在）。登録者はレジストラ経由でドメ
イン名の登録をすることができるが、レジストリへ直接申し込みをすることはできない。
また、以下(5)に挙げた一部の SLD については、ポリシー策定機能を auDA から他組織に委任している。
(5)ドメイン名の構成.au のドメイン名空間は、次の 3 種類の SLD（Second Level Domain：第 2 レベルドメイン）に分割されており、登録者は第 3 レベルのドメイン名を登録することになる。.au において登録されるドメイン名ラベルには 2 文字以上の文字が必要であり、登録可能な文字
列は英数字およびハイフンとなっている。
a) Open SLD (組織種別により登録資格を設定している第 2 レベルドメイン名)
・ASN.AU：非営利法人、政党、労働組合、特別利益団体など
・COM.AU：企業
・ID.AU：個人
・NET.AU：企業（COM.AU と同様の規定）
・ORG.AU：慈善団体、非営利組織

142

・INFO.AU：現在は新規登録を受け付けていない。
・CONF.AU：現在は新規登録を受け付けていない。
b) Closed SLD (特定組織に登録が限定されている第 2 レベルドメイン名)
・EDU.AU：国または州レベルで登記された教育機関。この空間のポリシーの策定は、
AICTEC（Australian Information and Communications Technology in Education
Committee）が行っている。レジストラは education.au.limited。 国の管轄下にある大学および教育機関は、通常第 3 レベルに登録するが、その他の学校等は州名の第 3レベルの下に設けられた第 4 レベルに登録する。
・GOV.AU：政府組織。この空間のポリシー策定は、AGIMO（Australian Government
Information Management Office）が行っている。
・CSIRO.AU：CSIRO（Commonwealth Science and Industry Research Organisation：
豪州科学工業研究機構）専用。この空間のポリシー策定は、CSIRO が行っている。
c) Community Geographic SLD（6 つの州と特別区域に登録が限定されている第 2 レベ
ルドメイン名）・CGDN（Community Geographic Domain Names）（ACT.AU、QLD.AU、NSW.AU、
NT.AU、SA.AU、TAS.AU、VIC.AU、WA.AU）：非営利法人でローカルコミュニティを代表する組織。この空間のポリシー策定は auDA が行っている。
※auDA 設立以前に取り 扱いドメイン名に含まれていた Closed SLD の OZ.AU、
TELEMEMO.AU は、取扱いドメイン名には含まれていない。
2007 年 5 月 18 日、auDA は第 2 レベルドメインの開放、ASN.AU、COM.AU、ID.AU、
NET.AU におけるポリシーの緩和、登録者によるドメイン名の再販の許可に関するイシューペーパーを発表し、公開意見募集を行った(意見提出期限は 2007 年 6 月 15 日)。
また、2007 年 8 月 28 日、auDA は CGDN のポリシーの見直しについても、公開意見募集を実施した(意見提出期限は 2007 年 9 月 28 日)。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件
全てのドメイン名の登録にローカルプレゼンスが必要。ローカルプレゼンスの具体的条
件は、SLD ごとに定められている。たとえば COM.AU においては、登録者はオースト
ラリアで登記された会社、オーストラリアでの操業ライセンスを得ている外国会社、オーストラリアでの商標保持者、オーストラリアで法人化された団体などに限定されている。

143

(8)個人用ドメイン名
個人用のドメイン名である ID.AU を設けている。登録者の氏名およびその略称、次のいずれかに該当し登録者と密接に関係していると判断できる文字列が登録可能。
a) 登録者の氏名に含まれている 1 語以上から派生した文字列b) 登録者の氏名に含まれている 1 語以上を含む文字列c) 登録者の通称
登録件数：8,310（2007 年 11 月現在）
(9)予約ドメイン名a) 3、4 文字目にハイフンを含むドメイン名b) 「commonwealth」、「federal」c) 「Anzac」（退役軍人大臣の承認が必要）
d) 「Geneva Cross」、「Red Crescent」、「Red Cross」、「Red Lion and Sun」
（国防大臣の承認が必要）e) 「United Nations」（外務大臣の承認が必要）f) 「University」および｢uni｣などの大学を連想させる略語（文部科学大臣の承認が必要）g) 「Olympic（s）」、「Olympiad（s）」、「Olympic Games」（オーストラリアオリンピック委員会の承認が必要）(10)IDN
導入していない。

144

(11)登録件数
1,024,176（2008年1月現在）。内訳は以下の通り。

（「AusRegistry EOM Report for General Release - High-Level Scorecard, January-08（http://www.ausregistry.com.au/reports/2008/PUBLIC-200801.pdf）」より）(12)料金レジストラに課される 1 ドメイン名あたりの登録料金は以下の通り。
（単位：オーストラリアドル）
AusRegistry への支払（税込） auDA への支払（税込）

合計（税込）

com.au

17.60

3.85

21.45

net.au

17.60

3.85

21.45

asn.au

5.50

3.85

21.45

id.au

11.00

3.85

14.85

org.au

5.50

3.85

9.35

(13)紛争処理
auDA は、ASN.AU、COM.AU、ID.AU、NET.AU、ORG.AU の紛争処理のため「auDRP（.au Dispute Resolution Policy）」を定め、2002 年 8 月 1 日に実施した。また、2003
年 6 月には、EDU.AU のケースも取り扱うようになった。auDA 認定の紛争処理機関は、
LEADR（Leading Edge Association of Dispute Resolvers）、CIArb（The Chartered
Institute of Arbitrators）、IAMA（The Institute of Arbitrators and Mediators Australia）、
WIPO（World Intellectual Property Organisation）の 4 組織。それぞれの組織では、1145

名または 3 名のパネルを任命して裁定を行っている。2007 年 8 月には、auDRP の運用開始から 5 年が経過したことを受け、auDRP の有効性と紛争処理メカニズムとしての適切性を確認するための意見募集が約 1 ヶ月間行われた。
(14)その他
・2007 年 10 月 21 日、auDA は、COM.AU および NET.AU 下の地域名ドメイン名の登録を開放した（例：abbotsford.com.au、abbotsford.net.au）。対象は、2005 年の地域名ドメイン名の抽選で応募がなかった 735 件のドメイン名。
・2007 年 11 月 30 日、auDA は.au の登録件数が 100 万件を突破したと発表した。
(15)出典・auDA
http://www.auda.org.au
・AusRegistry
http://www.ausregistry.com.au/

2-2-2-3 .be（ベルギー）
登録管理組織：DNS Belgium（DNS BE）(1)登録管理組織の歴史および性質.be は、1998 年 8 月に IANA データベースに登録された。.be におけるドメイン名の登録は、1989 年より、Katholieke Universiteit Leuven の Pierre Verbaeten 教授が開始した。
1999 年 2 月、Verbaeten 教授の要請によって非営利法人 DNS Belguim（以下「DNS BE」が設立され、2000 年 1 月 1 日には.be の登録管理が Verbaeten 教授から DNS BE へ移管された。
(2)登録管理組織の運営形態
DNS BEの運営に関する方針は理事会が決定する。また、理事会を支援する組織として、戦略委員会（Strategic Committee）がある。戦略委員会は創立会員（Founding Member）、有効会員（Effective Member）および顧問会員（Advisory Member）の代表で構成され、理事会で決定する方針案の策定や組織運営に関する助言を行う。
(3)会員
DNS BE の会員は、以下のように分類される。

146a) 創立会員
・Agoria（技術関係の業界団体）
・ISPA Belguim（ISP の業界団体）
・Beltug（Belgian Telecommunications Users Group）（電気通信サービスを利用する企
業ユーザの団体）b) 有効会員
・Pierre Verbaeten 教授c) 顧問会員
・BIPT（Belgian Institute of Postal and Telecommunications Services）(4)登録管理業務の委任体制
DNS BE は 2000 年 12 月 7 日に直接登録の受付を停止し、それ以来登録業務を全てレジストラに委任している。レジストラは 364 社（2007 年 12 月現在）。
(5)ドメイン名の構成
第 2 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録可能な文字数は 2
文字以上 63 文字以下。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件
なし。
(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。個人でも.be のドメイン名を登録することができる。
(9)予約ドメイン名
3、4 文字目にハイフンを含むドメイン名は登録することができないが、このほかに予約や登録制限などの措置はとられていない。ドメイン名の登録システムは自動化されており、申請したドメイン名が既に他者に登録されていない限り、登録できる。しかし、ベルギーの商取引法などにおいて、商標権が設定されている文字列を権利保持者以外が登録できないと定められていることから、こうした条項に抵触する形で登録されたドメイ
ン名は、差し止められる可能性がある。

147

(10)IDN
導入していない（2008 年 2 月現在）
。DNS BE は、ベルギーの公用語であるオランダ語、
フランス語、ドイツ語のアクセント記号がついた文字（à、é、è、ê、â など）を使ったドメイン名の登録を 2008 年より開始すると 2007 年 11 月 13 日に発表した。しかし、具体的な導入スケジュールはまだ発表されていない（2008 年 1 月現在）。
(11)登録件数
以下は 2007 年における月ごとの登録件数。

（「Statistics（http://www.dns.be/en/home.php?n=4）」より）(12)料金2008 年 1 月 1 日より、DNS BE がレジストラに課す登録料金がそれまでの 5 ユーロから
3 ユーロに値下げされた。
(13)紛争処理
DNS BE が紛争処理方針および手順を定めている。紛争処理機関は、DNS BE の認定を受けた Cepina（Belgian Centre for Mediation and Arbitration）。
(14)その他
・2007 年 11 月 23 日、DNS BE がレジストラ行動規範を廃止したと発表した。レジストラ
行動規範に含まれていた多くの重要な条件は改訂版レジストラ契約に盛り込まれ、同日

148

までに全てのレジストラがこの改訂版契約に署名した。この契約の中で規定されたレジストラの順守条件は以下の通り。
- 自らの名義でドメイン名を登録しない- ドメイン名のウェアハウジングを行わない- 規定以外の方法でドメイン名の移転を行わない(15)出典・DNS Belgium
http://www.dns.be/en/home.php

2-2-2-4 .ca（カナダ）
登録管理組織：CIRA（Canadian Internet Registration Authority）(1)登録管理組織の歴史および性質
1988 年、.ca は、IANA からブリティッシュコロンビア大学情報工学科コンピュータセン
ターのマネージャであった John Demco 氏に割り当てられた。その後、1998 年 12 月に、カナダ政府およびブリティッシュコロンビア大学などが共同し、.ca の登録管理を改革するための非営利法人として CIRA を設立した。CIRA はブリティッシュコロンビア大学から業務を引き継ぎ、2000 年 12 月から正式な登録管理組織として業務を開始した。
(2)登録管理組織の運営形態
CIRA を運営する理事会は、14 名の理事から構成される。内訳は、インターネットユー
ザ、企業ユーザおよび認定レジストラの各コミュニティから選出された合計 3 名の理事
（任期 1 年）
、会員の選挙により選出された 9 名の理事（任期最長 3 年）、投票権を持たない職権上の理事としてのカナダ政府の代表と CIRA President となっている。
(3)会員.ca のドメイン名を 1 つ以上登録している登録者には、会員資格が与えられる。各会員には、年次総会への出席の権利、規則の変更に関する投票権、取締役の選挙での投票権および会員と取締役に対する問題や懸念事項を提出する権利が与えられる。
(4)登録管理業務の委任体制
94 社の認定レジストラへ登録業務を委任している（2008 年 1 月現在）。

149

(5)ドメイン名の構成
第 2、第 3、第 4 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録文字
数は 2 文字以上 50 文字以下。以下の通り分類される。
a) 第 2 レベルドメイン名
・.CAb) 第 3、第 4 レベルドメイン名（地域別ドメイン名）
・<province>.CA・<city>.<province>.CA(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.ca のドメイン名には、ローカルプレゼンス要件がある。具体的には、登録者は以下の要件を満たさなければならない。カナダ国民（成人）、「Immigration and Refugee Protection
Act（Canada） S.C.2001,c.27」に定める永住者およびその法定代理人、カナダの法律で定める法人、トラスト、パートナーシップ、労働組合、政党、教育機関、図書館、博物館、病院、エリザベス 2 世とその後継者、インディアン、カナダ先住民、政府、カナダで登録された商標、メンバーまたは運営者の 80％以上がカナダ居住者である団体など。
(8)個人用ドメイン名
特に個人用に限定したドメイン名は設けていない。個人でも.ca の第 2 レベルドメイン名を登録することができる。
(9)予約ドメイン名.ca における予約ドメイン名は、以下のように分類される。
「org.ca」、「net.ca」、
a)「ca.ca」、3 文字 gTLD の TLD ラベルを含むドメイン名（「com.ca」、「edu.ca」、「gov.ca」、「int.ca」、「mil.ca」など）。「mil.ca」は、国防省用に予約されている。
b) 「 village.ca 」、「 hamlet.ca 」、「 hameau.ca 」、「 town.ca 」、「 city.ca 」、「 ville.ca 」、「municipal.ca」
c) その他 CIRA の裁量によって定める文字列d) カナダの国名、州名、地域名およびその短縮形、CGNDB（Canadian GeographicalNames Database）に記載された都市名、町名、村名、その他行政地区の名称。

150

(10)IDN
導入していない。
(11)登録件数
947,443（2008 年 1 月 11 日現在）。
(12)料金CIRA からレジストラに対して 1 ドメイン名あたり年間 8.5 カナダドルの登録料金を課している。
(13)紛争処理
CIRA では、2002 年より「CDRP（CIRA Domain Name Dispute Resolution Policy）」 を実施している。紛争処理機関として、Resolution Canada, Inc. および BCICAC（British
Columbia International Commercial Arbitration Center）が任命されている。2006 年 6月 30 日から 8 月 31 日まで、CDRP の公平性、利便性、効率などの観点から改善を加えるため、公開意見募集を実施した。改訂版の CDRP は、2008 年 1 月 1 日時点では発表されていない。
(14)その他
・2007 年 3 月 19 日、CIRA は WHOIS プライバシーポリシーの改定案に関する公開意見
募集の結果を発表した。登録者の個人情報の更なる保護を目的としたこの改定案に対して概ね支持を得る結果となったことから、CIRA では、登録者の個人情報を保護する新しいWHOIS プライバシーポリシーを実施することを目標に、準備を行っている。2008 年 2
月現在、新 WHOIS プライバシーポリシーは確定していない。
(15)出典・CIRA
http://www.cira.ca

2-2-2-5 .ch（スイス）
登録管理組織：SWITCH（Swiss Academic and Research Network）(1)登録管理組織の歴史および性質.ch の登録管理業務は、1987 年 10 月から開始された。登録管理を行っているのは、スイ151

ス連邦と大学のある 8 つの州（バーゼル市、ベルン、フリブール、ジュネーブ、ヌシャ
テル、サン・ガル、ボー、チューリッヒ）により設立された非営利の財団法人である
SWITCH。なお、SWITCH は、.ch に加えて.li（リヒテンシュタイン公国）のドメイン
名登録管理業務も行っている。
(2)登録管理組織の運営形態
SWITCH は、業務を統括する執行理事会と、執行理事会を監視する理事会によって運営されている。
(3)会員なし。
(4)登録管理業務の委任体制.ch におけるドメイン名の登録業務は、SWITCH の認定を受けた 18 社のパートナーが行っている（2008 年 2 月現在）。また、SWITCH でもドメイン名の登録申請を受け付けている。
(5)ドメイン名の構成.ch のドメイン名は第 2 レベルへ登録される。登録可能な文字列は、英数字、ハイフンお
よび IDN。登録可能な文字数は、3 文字以上 63 文字以下。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件
なし。
(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。 .ch のドメイン名は個人でも登録することができる。
(9)予約ドメイン名
以下のドメイン名は登録することができない。
a) 1 文字目および 3、4 文字目にハイフンを含むドメイン名b) スイス連邦通信庁によって予約された語

152

(10) IDN
2004 年 3 月 1 日以降、以下の 31 文字を含むドメイン名の登録が可能となった。

また、2005 年 12 月 1 日には、以下の 1 文字もドメイン名ラベルに利用できるようにな
った。

153

(11)登録件数
1,056,751（2007 年 12 月 31 日現在）。1995 年以来の登録件数の推移は以下の通り。

（「Statistics for Domain Names Ending in .ch and .li （http://www.switch.ch/id/stat）」
より）

154

(12)料金
SWITCH に直接登録申請をする場合、1 ドメイン名あたり年間 22 スイスフランが課される。この料金は、2007 年 9 月 1 日に 27 スイスフランから値下げされた。
(13)紛争処理
SWITCH が「Rules of Procedure for Dispute Resolution Proceedings for .ch and .li」
を定めている。紛争処理機関は、WIPO Arbitration and Mediation Center。
(14)その他
2007 年 8 月 27 日の SWITCH の発表によれば、同日、.ch のドメイン名登録件数が 100万件を突破した。
(15)出典・SWITCH
http://www.switch.ch/en/

2-2-2-6 .cn（中国）
登録管理組織：CNNIC（China Internet Network Information Center）(1)登録管理組織の歴史および性質.cn を登録管理する CNNIC は、CAS（Chinese Academy of Sciences：中国科学院）が国務院の委任を受け 1997 年 6 月に設立した非営利組織。CNNIC の主な事業は、.cn の登録管理のほかに、IP アドレスおよび AS 番号の割り振り、技術研究、調査、情報サー
ビス、ISC（Internet Society of China）におけるインターネットポリシーおよび資源委
員会の事務局などがある。
(2)登録管理組織の運営形態
CNNIC は、情報産業部の監督下にある。また、CNNIC の組織運営は CAS によって行われている。さらに、インターネットに関する専門家および中国国内のインターネット
業界の代表者で構成する CNNIC 運営委員会が、CNNIC の業務を監督、評価している。
(3)会員
ISP が IP アドレスの申請を行うために CNNIC 会員となっているが、この会員は CNNICのガバナンスとは関係がない。

155

(4)登録管理業務の委任体制
国 内認 定レジ スト ラおよ び国 外認定 レジ ストラ へ登 録業務 を委 任して いる 。 米 国
NeuLevel 社が、唯一の「Registry Gateway」として国外認定レジストラをとりまとめている。国内認定レジストラは 40 社、国外認定レジストラは 88 社（2008 年 1 月現在）。
(5)ドメイン名の構成
第 2、第 3 レベルへの登録。登録可能な文字列は英数字、ハイフン、IDN（中国語文字）。
登録可能文字数は 63 文字以下。第 3 レベルへの登録は 20 文字以下。氏名の登録（ASCII
または中国名のピンイン表記）は第 3 レベルへの登録が望ましいとされる。登録者は、組織でなければならないとされる。 .cn のドメイン名は、以下のように分類される。
a) 第 2 レベルドメイン名（ASCII）
・.CN
b) 第 2 レベルドメイン名（中国語文字）・.CNc) 組織種別ドメイン名
・AC.CN：科学技術の研究機関
・COM.CN：企業
・EDU.CN：中国の教育機関
・GOV.CN：中国の政府機関
・MIL.CN：中国の国防関係組織
・NET.CN：ISP など
・ORG.CN：非営利組織
d) 行政区ドメイン名
・<地域略号>.CN（例：北京は BJ.CN）：（34 の省、自治区、直轄市、特別行政区の組織）e) その他
・.中国、.公司、.网络
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.CN（第 2 レベルドメイン名）、COM.CN、NET.CN および ORG.CN は、国外からの登録も可能。それ以外のドメイン名についてはローカルプレゼンス要件がある。

156

(8)個人用ドメイン名なし。
(9)予約ドメイン名a).CN（第 2 レベルドメイン名）、COM.CN、NET.CN および ORG.CN について
・国名、ISO3166 による国名の 3 文字表記
・中国政府機関および指導者名・国家安全保障のための名称
・州および都市名
・「001」などの特定電話番号
・全ての gTLD および一部の第 2 レベル空間（「biz.cn」、「kids.cn」など）
・特定の著名商標（約 350）
・世界文化、遺産を促進するために国連が指定した名称
・中国の大学、単科大学の名称
・国のニュース局に承認されたニュースメディアb) その他の第 3 レベルドメイン名について
・中国の名称に関連する語（「China）、「Chinese」、「CN」、「National」など）
・著名な外国の国名/地域名
・国際機関名・地方自治体（郡以上）の部課名および略称（別途許可を取れば登録可）など(10) IDN
2000 年 1 月 18 日から中国語文字によるドメイン名（例：<中国語文字>.cn）の試験登録を、2000 年 11 月 7 日から政府の承認を受けた正式登録を行っている。その後、2005 年
1 月 17 日に、中国語文字ドメイン名を海外市場に開放した。また、2003 年からは、トッ
プレベルドメインに似た独自の.中国、.公司、.网络 を導入した。これは、クライアント側
で専用プラグインをインストールすることにより、.中国、.公司、.网络 を使用したドメイ
ン名にアクセスしようとすると、自動的にそのドメイン名の末尾に.cn が付加された上でアクセスする仕組みである。この仕組みにおいては、例えば「中国語.公司」を登録した
場合、レジストリのデータベースでは「中国語.公司.cn」というドメイン名として管理されることになる。
(11)登録件数
9,001,993（2008 年 12 月末現在）。内訳は、COM.CN： 2,535,154、NET.CN： 335,312、
ORG.CN： 164,131、GOV.CN： 35,297、AC.CN： 13,268、EDU.CN： 3,234、.CN（第 2 レベルドメイン名）： 5,695,480、行政区ドメイン名： 220,111、MIL.CN： 6。

157

また、以下は 2007 年の登録件数の推移。

（「2007 年域名增长 长 长 （http://www.cnnic.cn/html/Dir/2007/03/02/4445.htm）」より）(12)料金CNNIC がレジストラに課す登録料金は、1 ドメイン名あたり年間 56 中国元。なお、2007
年 3 月初めから 5 月末までの間に登録されるドメイン名については、キャンペーン料金が適用され、1 ドメイン名あたり最初の 1 年間に限り 1 中国元となった。さらに 2007 年
12 月 25 日、このキャンペーンが 2008 年 12 月 31 日まで延長された。
(13)紛争処理「CNNIC Domain Name Dispute Resolution Policy」を定めている。紛争処理は、CNNIC
が認定した CIETAC（China International Economic Trade Arbitration Commission）
および HKIAC（Hong Kong International Arbitration Center）が行う。
(14)その他
・CNNIC が 2007 年 9 月に発表した 2007 年中国農村部インターネット調査報告によると、中国の農村部のインターネット利用者は 3,700 万人を越え、娯楽目的で利用する割合は
農村部と都市部であまり差がないという。CNNIC は、インターネットが農村部においても重要な基盤となっていると分析した。

158

・CNNIC が 2008 年 1 月に発表した「第 21 回中国インターネット発展状況統計報告」によると 2007 年 12 月 31 日時点の中国のインターネット利用者数は 2 億 1,000 万人に達し、米国に次ぐ世界第 2 位となった。一方、インターネット普及率は 16%で、世界平均の 19.1%を下回った。
(15)出典・CNNIC
http://www.cnnic.net.cn

2-2-2-7 .de（ドイツ）
登録管理組織：DENIC（DENIC eG）(1)登録管理組織の歴史および性質.de は、IANA によりトップレベルドメインとして 1986 年 11 月に登録された。当時、.deの登録管理はドルトムント大学のボランティアによって行われていた。1993 年 8 月にな
ると、.de のネームサーバ を運営するために、ドイツにある 3 社の ISP が主導してIV-DENIC（Interessenverbund Deutsches Network Information Center）を設立した。
1996 年 12 月、会員数が 36 社に達したことを機に、IV-DENIC が共同組合としての DENIC
eG（以下「DENIC」）を設立した。DENIC はそれまで IV-DENIC からカールスルーエ
大学が受託していた業務を引継ぎ、1999 年 1 月に登録管理業務の移管を完了した。
(2)登録管理組織の運営形態
DENIC の運営は、執行理事会（Executive Board）、監督委員会（Supervisory Board）
および総会によって行われている。執行理事会は、監督委員会が任命する 3 名以上の執行理事および 2 名の総会選出理事で構成され、DENIC 事務局が実施する事業、財務の状況を管理し、監督委員会に報告する。監督委員会は、総会で選出された 3〜5 名の会員代表で構成される。会員は総会での投票権を持つ。
(3)会員
ドメイン名の登録事業者および ISP が DENIC の会員となっている。会員数は 258（2007年 11 月現在）。
(4)登録管理業務の委任体制
会員へ登録業務を委任している。（上記(3)参照）

159

(5)ドメイン名の構成.de のドメイン名は、第 2 レベルへ登録する形式のみとなっている。登録可能な文字は英
数字、ハイフンおよび IDN（ドイツ語、フランス語、デンマーク語など）。登録できる文
字数は 3 文字以上 63 文字以下。1 文字以上のアルファベットを使用する必要があり、数字のみで構成するドメイン名は登録できない。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件なし。ただし、ドイツ国内に本拠を置いていない登録者は、ドイツ国内に居住し、送達される文書を受け取ることができる住所を有する登録担当者（administrative contact）を指定しなければならない。
(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。個人でも.de のドメイン名を登録することができる。
(9)予約ドメイン名
以下のドメイン名は予約されている。
a) 3、4 文字目にハイフンを含むドメイン名b) 既存の gTLD および ccTLDc) 自動車のナンバープレートに表示される地域コード、または地域コード中のウムラウ
トをそれに相当する 2 文字の母音に置き換えた文字の組み合わせ（「ä」の場合は「ae」、「ö」の場合は「oe」、「ü」の場合は「ue」）.
(10) IDN
2004 年 3 月 1 日から.de における IDN の登録が開始された。2007 年 12 月時点ではドイ
ツ語、フランス語、デンマーク語の特殊文字を含む 92 文字が登録可能であるが、ドイツ
語文字の
日現在）。

160

はドメイン名ラベルに使用できない。登録件数は、387,006（2007 年 11 月 30

(11)登録件数
登録総数は 11,524,091、うち IDN は 387,006。（2007 年 11 月 30 日現在）
以下は 1994 年 1 月以来の累計登録件数の推移。

（「Domain Count（http://www.denic.de/en/domains/statistiken/domainentwicklung/index.html#）」より）(12)料金DENIC が会員に課すドメイン名登録料金は非公開となっている。登録者が DENIC に直接ドメイン名を申請できる DENIC のサービス「DENICdirect」における 1 ドメイン名
あたりの登録料は、年間 58 ユーロ。2007 年 1 月 1 日に付加価値税率が 16%から 19%に上昇したが、DENICdirect の 1 ドメイン名あたりの料金は変更されなかった。
(13)紛争処理.de では、ドメイン名に関する紛争は基本的に裁判によって処理されており、DENIC とし て 紛 争 処 理 方 針 や 手 続 き は 特 に 定 め て い な い 。 し か し 、 DENIC で は 、「DISPUTE-entry」というサービスを無料で提供している。DISPUTE-entry では、係属中のドメイン名の移転を制限でき、対象となるドメイン名が判決によってもとの登録者からリリースされた場合に、このサービスに申し込んだ者がそのドメイン名を自動的に登録できる。なお、このサービスは、第三者がドメイン名に対する権利を持つことを証明でき、当該ドメイン名の登録者との交渉や裁判などをこれから行う、もしくはすで161

に行っている場合に申し込むことができる。
(14)その他
2007 年 10 月、DENIC は、自らが行った WHOIS クエリ対策によって、.de におけるドメイン名登録者宛てのスパムメールが激減したと発表した。対策の概要は、ドメイン名登
録者の電子メールアドレスと登録担当者の連絡先のみを表示することおよび 1 つの IP ア
ドレスから一定時間内に行えるクエリの数を制限することなど。
(15)出典・DENIC
http://www.denic.de/en/index.html

2-2-2-8 .eu（欧州連合）
登録管理組織：EURid（The European Registry of Internet Domain Names）(1)登録管理組織の歴史および性質.eu の登録管理者である EURid は、.be（ベルギー）の登録管理組織 DNS Belguim、.it（イタリア）の登録管理組織 IIT CNR および.se（スウェーデン）の登録管理組織 IIS が共同で設立した非営利組織で、2003 年 4 月にベルギーで非営利法人として登記された。
2005 年 6 月、EURid は ICANN と契約を締結し、正式に.eu の登録管理者となった。その後、.eu のドメイン名運用は、EURid のもとで 2005 年 12 月から開始された。
(2)登録管理組織の運営形態
EURid は、創立会員 3 組織と賛助会員 4 組織から構成される。理事会は総会で任命された 3 名以上の理事で構成される。また、EURid の活動に関し、自発的に、または理事会の諮問に応えて助言する「戦略委員会」が設置されている。戦略委員会は理事および理事会によって任命された委員により構成され、その規模は 10 名以内と定められている。
(3)会員
a) 創立会員
DNS BE、IIT CNR および IIS。
b) 賛助会員
賛助会員として入会するには、理事会の承認が必要となっている。承認の条件は、インターネットに関わる人々の利益に貢献する、あるいは賛助会員の条件に関心を持

162

つ法人または個人であること。2007 年 9 月時点の賛助会員は、.si（スロベニア）の登録管理組織 Arnes、.cz（チェコ）の登録管理組織 CZ NIC、ISOC-ECC （The European
chapter of the Internet Society）、および 33 ヶ国、39 会員で構成する業界団体のBUSINESS EUROPE の 4 組織。
(4)登録管理業務の委任体制.eu ドメイン名の登録は、レジストラを通じて行われる。EURid は、1,057 社のレジスト
ラに登録業務を委任している（2008 年 1 月現在）。
(5)ドメイン名の構成
第 2 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録文字数は、2 文字
以上 63 文字以下。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.eu においては、以下の資格のいずれかに該当しなければドメイン名を登録できない。
a) EC 内に主たる事業所や登記された事務所をもつ企業
b) EC 内に設立され、国内法の適用を阻害することのない組織
c) EC 内に居住する自然人(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。個人でも.eu のドメイン名を登録することができる。
(9)予約ドメイン名a) 3、4 文字目にハイフンを含むドメイン名b) 地理的/地政学的概念を表す名称（各 EU 加盟国が指定したもの）
c) 国の名称を表す 2 文字のコードd) EU 加盟国、加盟準備国、欧州経済地域に所属する非加盟国の政府機関の利用のために予約された名称e) 欧州委員会の利用のために予約された名称
f) .eu 登録管理組織の利用のために予約された名称（「eurid.eu」、「registry.eu」、「nic.eu」、「dns.eu」など）

163

(10)IDN
導入していない。
(11)登録件数
2005 年 12 月 7 日からサンライズ期間を開始、2006 年 4 月 7 日より、一般の登録受付を開始した。2008 年 1 月 11 時点の登録件数は 2,729,673 件。登録者の所在する国ごとの登録件数（2008 年 1 月 11 日時点）は以下の通り。

（「.eu Statistics（http://status.eurid.eu/index.html）」より）(12)料金2008 年 2 月 1 日より、EURid がレジストラに課すドメイン名登録料金は、1 ドメイン名
あたりそれまでの年間 5 ユーロから 4 ユーロへ引き下げられた。
(13)紛争処理「.eu Alternative Dispute Resolution Rules」を定めている。紛争処理機関は、チェコ仲裁裁判所。
(14)その他
・EURid は、2007 年 2 月 6 日より、通常のレジストラ契約とは別に、「レジストラ行動
規範（Code of Conduct）」への署名をオプションでレジストラに求めている。この行動規範の主な目的は、以下の通りである。

164

- 高品質なサービスを提供するレジストラを識別可能にする- 法規制の範囲にないドメイン名業界固有の事象に対応する- ドメイン名登録者がレジストラを選ぶ際に幅広い選択肢を提供する
行動規範への署名は、レジストラから EURid へ申し込むことにより行われる。申し込んだレジストラは、EURid による所定の審査や手続きを経なければならない。その後承認されたレジストラは、EURid の Web 上のレジストラリストで「行動規範に署名したレジストラ」として特別な欄に掲載され、以下の認定ロゴマークを付与される。

(15)出典・EURidhttp://www.eurid.eu/

2-2-2-9 .fr（フランス）
登録管理組織：AFNIC（Association Française pour le Nommage Internet en
Cooperation）(1)登録管理組織の歴史および性質.fr は、1986 年 9 月に IANA データベースに登録され、INRIA （Institut National deRecherche en Informatique et en Automatiqueu）内の NIC France が登録管理を開始した。1998 年 1 月、INRIA およびフランス政府の共同により非営利法人 AFNIC が設立され、NIC France の業務は AFNIC に引き継がれた。AFNIC は非営利法人で、.fr のほかに.re（レユニオン）など、11 の ccTLD を登録管理している。
(2)登録管理組織の運営形態
AFNIC は、理事会、執行部、総会、レジストラ協議会、ユーザ協議会によって運営されている。理事会は、5 名の政府代表、5 名の創立会員（INRIA から 2 名、関係省庁から 3名）と、総会で選出される 2 名のレジストラ会員、2 名のユーザ会員および 1 名の通信会
員（Correspondent Member）により構成される。理事の中から選出された議長が執行部の長である事務局長を任命する。理事会または執行部は、レジストラ協議会（全てのレ165

ジストラ会員で構成）およびユーザ協議会（全てのユーザ会員で構成）に対し、必要に応じ諮問することができる。
(3)会員
AFNIC の会員には、インターネットに関心があれば誰でもなることができる。なお、ドメイン名登録業務を行うにはレジストラ会員になる必要がある。AFNIC 会員の分類は以下の通り。
a) 創立会員
INRIA、郵便・電気通信省（Ministere Delegue a la Poste aux Telecommunications eta l'Espace）、経済・財政・産業 省（Ministere de l'Economie, des Finances et del'Industrie Secretariat d'Etat au Commerce exterieur）および教育・研究・技術省（Ministere de l'Education nationale, de la Recherche et de la Technologie）b) レジストラ会員
レジストラc) ユーザ会員
法人（企業、団体）および個人
d) 通信会員
国外の関係団体など
f) 名誉会員
理事会が決定する個人(4)登録管理業務の委任体制.fr のドメイン名登録業務は、AFNIC からレジストラ会員へ委任されている。AFNIC に
直接ドメイン名の登録を申し込むことはできない。
(5)ドメイン名の構成.fr のドメイン名は、第 2 レベルまたは第 3 レベルへ登録される。登録可能な文字列は、
英数字およびハイフン。登録可能な文字数は 255 文字以内で、各レベル 63 文字以内。 .frのドメイン名は、以下の通り分類される。
a) 第 2 レベルドメイン名
・.FR：組織および個人
b) 属性型ドメイン名（Descriptive Domain Name）
・ASSO.FR：INSEE に登録している団体
・COM.FR：法人または個人
・NOM.FR：フランスに居住する個人およびフランス国外に居住するフランス国籍保持者

166

・PRD.FR：研究開発プロジェクト
・PRESSE.FR：報道関係の組織
・TM.FR：商標保持者
c) 部門別ドメイン名（それぞれに管轄機関があり、機関ごとの規則に従ってドメイン名が登録される。ただし、審査は AFNIC が行う）
・AEROPORT.FR：空港
・ASSEDIC.FR：商工業雇用協会
・AVOCAT.FR：弁護士
・AVOUES.FR：事務弁護士
・CCI.FR：商工会議所
・CHAMBAGRI.FR：農業会議所
・CHIRURGIENS-DENTISTES.FR：歯科医
・EXPERTS-COMPTABLES.FR：専門家
・GEOMETRE-EXPERT.FR：幾何学者
・GRETA.FR：国立教育機関
・GOUV.FR：政府
・HUISSIER-JUSTICE.FR：廷吏・MEDECIN.FR：医者
・NOTAIRES.FR：公証人
・PHARMACIEN.FR：薬剤師
・PORT.FR：港・VETERINAIRE.FR：獣医(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.fr におけるローカルプレゼンスの条件は以下の通り。
a).FR（第 2 レベルドメイン名）の場合
・フランスに本拠がある法人は以下のいずれかにより識別可能でなければならない。
- 商事裁判所レジストリ- INPI（National Corporate and Trade Register）- INSEE（National Institute of Statistics and Economic Studies）- REFASSO（団体の場合）・個人または法人で知的財産研究所にフランス市場向けの商標を登録している場合
は、ICMARQUES（INPI）データベースで識別可能でなければならない。

167

・個人の場合、フランス国内に住所を持つ成人でなければならない。
b)第 3 レベルドメイン名の場合・属性ごとに指定されたフランス国内機関での登記または登録の証明書を提出しなければならない。ただし、NOM.FR はフランスに居住している個人のほか、外国に居住しているフランス国籍保持者も登録可能。COM.FR も、フランスに居住する 18 歳以上の個人のほか、外国に居住している 18 歳以上のフランス国籍保持者が登録可能となっている。
(8)個人用ドメイン名
個人専用のドメイン名空間として、NOM.FRを設けている（上記(5)b）参照）。NOM.FRの登録件数は 1,368（2007 年 2 月現在）。なお、COM.FRも 18 歳以上の個人による登録が可能。2006 年からは第 2 レベルドメイン名も個人が登録できるようになっている。
(9)予約ドメイン名
以下のドメイン名は登録することができない。
a) 1 文字の文字列b) アルファベット 2 文字で構成された文字列c) ハイフンで始まる、または終わる文字列d) 「xn--」で始まる文字列e) 侮辱、人種差別、わいせつな用語、犯罪および違反行為に関することを表す単語
また、以下のドメイン名は特定の条件を満たす主体が登録できるよう予約されている。
f) インターネットの運営に関わる技術的な用語
g) 規制対象となっている職業名h) 国家機能に関連する用語
i) パリ条約調印国の国名j) 国際機関の名称k) フランスの都市名など(10) IDN
導入していない。
(11)登録件数
1,035,479 （2008 年 1 月 31 日現在）
(12)料金168

レジストラが AFNIC に支払うドメイン名登録料金は、レジストラ認定料として年間1,450 ユーロを AFNIC に支払っている場合で 1 ドメイン名あたり年間 4.8 ユーロであり、レジストラ認定料として年間 425 ユーロを支払っている場合は 5.8 ユーロである。
(13)紛争処理「PARL（Les Procedures Alternatives de Resolution des Litiges）」が定められている。
紛争処理は、WIPO（World Intellectual Property Organization）および CMAP（Centrede Mediation et d’ Arbitrage de Paris）が行う。なお、個人により登録された.FR（第 2
レベルドメイン名）の紛争処理にあたっては、フランス政府の支援を受け運営されている Internet Rights Forum が、仲裁サービスを提供している。
(14)その他
・2007 年 4 月 27 日、AFNIC 理事会が.fr の WHOIS データベースへのアクセスに関して
以下の方針を決定した。
- WHOIS データの自動収集防止対策を強化する- レジストラが顧客のドメイン名に関して必要なデータにアクセスできる追加サービスを提案する- ドメイン名リストの公開を中止し、契約に基づくデータ抽出サービスに置き換える。なお、登録者は、このサービスにおいて自らに関するデータが掲載されないように意思表示できることとする
・WHOIS への匿名での登録がドメイン名紛争の申立人にとっては登録者特定の障害となる問題を考慮し、2007 年 11 月 27 日、AFNIC が WHOIS ポリシーの改定を提案した。具
体的には、個人情報を非公開にできる方針を基本的に継続しつつも、所定の申請がなされれば AFNIC がその情報を開示できるようにするというもの。このポリシーは、2008
年前半に実施される予定。
・2008 年 1 月 14 日、AFNIC は、.fr のドメイン名登録件数が累計で 100 万件を突破したと発表した。2007 年を通じての成長率は 40%に達したという。AFNIC によれば、2006
年 6 月に個人も.FR（第 2 レベルドメイン名）を登録できるように資格要件を緩和したこと、料金設定の適切さ、システムの自動化などがこの急成長に寄与したと考えられる。
(15)出典・AFNIC
http://www.afnic.fr/index
・INRIA – History
http;//www.inria.fr/inria/historique.en.html

169

2-2-2-10 .hk（香港）
登録管理組織： HKIRC（Hong Kong Internet Registration Corporation Limited）(1)登録管理組織の歴史および性質.hk が最初に IANA データベースに登録されたのは、1990 年 1 月であった。 .hk におけるドメイン名の登録管理は、1992 年から HKNIC（Hong Kong Network Information
Centre）により行われていた。HKNIC を運営していたのは、香港大学、香港中文大学、
香港理工大学を含む 8 校の公立大学の情報処理センターで構成された JUCC（Joint
Universities Computer Center）という、大学間の調整を行う組織であった。JUCC は
その後 HKDNR（Hong Kong Domain Name Registration Company Ltd.）を設立し、
HKNIC の.hk 登録管理業務を移管した。HKDNR は 2001 年 6 月 1 日から登録管理業務を開始したが、2001 年 12 月に HKIRC（Hong Kong Internet Registration CorporationLtd.）が設立されたことにともなって HKIRC の非営利子会社となった。以来、ドメイン名の登録管理に関する責任は HKIRC が、そしてレジストリとしての実務は HKDNR が担っている。なお、HKIRC は、中華人民共和国香港特別行政区（以下「香港特別行政区」）のエンドースを受けている。
(2)登録管理組織の運営形態
HKIRC の方針は理事会で決定され、その方針に従って Chief Executive Officer 配下の執行部が HKIRC を運営している。HKIRC の理事会は、議長を含み 13 名以下と定められている。理事は、HKIRC 会員 6 分類（ユーザ、サービスプロバイダ、IT 業界、その他
商工業、高等教育機関、政府）の代表として、HKIRC の年次総会において毎年選挙で決められる。また、4 名の名誉顧問が理事会に助言する。さらに、理事会は以下の委員会を設置している。全ての委員会の議長および委員は理事が務める。
a) 事業開発・促進委員会b) 技術委員会c) 財務・管理委員会d) 苦情処理・紛争処理委員会e) 監査委員会f) 制度・統治委員会

170

以下は HKIRC の統治形態を図示したものである。

（ 「 HKIRC

StatusUpdate-APTLD

Meeting

in

Taipeion

26-Feb-08(http://www.aptld.org/taipeifebruary2008/34c-Pres%20on%20%20HKIRC%20during%2
0APTLD%20Meeting%20in%20Taipei%20on%2026%20Feb%2008%20080222.pdf) 」 より）
また、HKIRC の組織構造は以下の通り。

（「HKIRC Organizational Structure（https://www.hkdnr.hk/pdf/OrgStructure.pdf）」より）

171

(3)会員HKIRC の会員は.hk のドメイン名を最低 1 つ登録していなければならない。会員は、ユーザ、サービスプロバイダ、IT 業界、その他商工業、高等教育機関、政府に分類される。
(4)登録管理業務の委任体制.hk のドメイン名の登録は 80 を超える香港内外の service partner（代行業者）を通じて行うことができる（2008 年 1 月 31 日現在）。また、HKDNR に直接ドメイン名の登録を申し込むことも可能。
(5)ドメイン名の構成
第 2、第 3 レベルへの登録。登録可能な文字は英数字およびハイフン。また、中国語文字によるドメイン名も登録可能。登録文字数は「.」を含め全体で 63 文字以内。以下の通り分類される。
a) 第 2 レベルドメイン名（ASCII）
・.HK：香港内外の個人および団体
b) 第 2 レベルドメイン名（中国語文字）
・.HK：香港内外の個人および団体
c) 組織種別ドメイン名
・COM.HK/公司.HK：有効な企業登録（HKSAR）をしている企業
・ORG.HK/組織.HK：非営利組織
・NET.HK/網絡.HK：PNET ライセンスを持つネットワーク関連事業者
・GOV.HK/政府.HK：香港特別行政区
・EDU.HK/教育.HK：教育機関
・IDV.HK/個人.HK：香港住民（11 歳以上の HKID カード保持者）(6)登録可能ドメイン名数の制限の有無なし。2001 年 6 月に登録可能な数の制限を撤廃した。
(7)ローカルプレゼンス要件.HK（第 2 レベル登録）では、ローカルプレゼンスは不要。その他のドメイン名の登録には香港の公的機関での登記や登録が必要。IDV.HK/個人.HK 申請者は香港特別行政区の住民でなければならない。
(8)個人用ドメイン名
IDV.HK を設けている。申請者は香港特別行政区の住民であることを証明する HKID カ

172

ードまたは同等の書類を提出しなければならない。また、個人でも第 2 レベルにドメイン名を登録することができる。IDV.HK および.HK で登録できるドメイン名は、HKID
カードに記載された申請者の氏名と同一の文字列（フルネーム）に限られる。
(9)予約ドメイン名
以下のドメイン名は登録することができない。
a) 1 文字の文字列b) gTLD のトップレベルのラベルc) 地域名、区域名およびその略称d) ISO 3166 に定める 2 文字の国別コードe) 一般的な名字f) 予約ドメイン名リストに掲載された文字列g) （中国語文字ドメイン名の場合）gTLD のトップレベルラベルを中国語訳した文字列h) （中国語文字ドメイン名の場合）中国語を使用している国または地域の名称
i) （中国語文字ドメイン名の場合）一般的な技術用語、関連国際組織名k) （中国語文字ドメイン名の場合）「大學」、「中學」などの学校の分類およびレベル
以下の文字列の登録には制限がある。申請者はそれらの文字列との関連性を示す証拠を提出しなければならない。
l) 「government」または「政府」m) 「bank」または「銀行」n) 「insurance」、「assurance」または「保険」(10) IDN
2007 年 3 月 8 日から先願による中国語文字によるドメイン名の登録が行われている。登録できるドメイン名は、1 文字以上の中国語文字を含み、.hk を除いた文字数が 15 以下のもの。繁体字・簡体字のどちらにも対応しており、さらに双方の文字を組み合わせることも可能。登録件数は 7,945（2008 年 1 月 31 日時点）。

173

(11)登録件数
154,659（2008 年 1 月 31 日現在）。内訳は以下の通り。

（「HKIRC Status Update - APTLD Meeting in Taipei on 26-Feb-08(http://www.aptld.org/taipeifebruary2008/34c-Pres%20on%20%20HKIRC%20during%
20APTLD%20Meeting%20in%20Taipei%20on%2026%20Feb%2008%20080222.pdf)」
より）

174

(12)料金
料金は登録者が HKDNR に直接支払う。料金表は以下の通り（単位は香港ドル）。

（「 Rules for .hk Domain and Sub-domains Version 5.0, 16.4 Fee Schedule（https://www.hkdnr.hk/register/rules.jsp）」より）(13)紛争処理
以下のそれぞれについて、HKDNR が紛争処理ポリシーを定めている。また、認定紛争処理機関は、HKIAK（Hong Kong International Arbitration Centre）。
a) IDV.HK および個人.HK を除く全てのドメイン名
・「Domain Name Dispute Resolution Policy」が適用される。
b) IDV.HK および個人.HK

175

・「Domain Name Dispute Resolution Policy - .idv.hk and .個人.hk Domain Name」が適用される。
(14)その他
・2007 年 7 月、HKDNR はフィッシングまたは spamvertising（Web サイトへのリンクを含んだスパムメール広告を送りつけること）に使用された.hk のドメイン名を一斉に取り消した。取り消されたドメイン名の内訳は以下の通り。
- フィッシング：約 200〜300 件- spamvertising：約 7,000 件(15)出典・HKDNR & HKIRC
https://www.hkdnr.hk/

2-2-2-11 .it（イタリア）
登録管理組織：IIT-CNR(1)登録管理組織の歴史および性質.it は、1987 年に IANA からイタリアに割り当てられた。当時、.it は科学技術振興、調整を役割とする政府機関 CNR（Consiglio Nazionale delle Ricerche、英語名 The National
Research Council）のもとで管理されたが、2003 年 3 月 1 日からは、CNR 傘下の研究機関 IIT（Istituto di Informatica e Telematica、英語名 Institute for Informatics andTelematics）（IIT-CNR、以下「IIT」）によって運営されるようになった。
(2)登録管理組織の運営形態
IIT では、技術諮問委員会である Committee of the rules and technical procedures forthe ccTLD 'it' Registry（以下「Rules Committee」）がドメイン名の登録などに関する規則を策定している。Rules Committee は、国内のインターネットコミュニティの代表者 6
名、IIT の代表者 2 名、GARR（Gestione Ampliamento Rete Ricerca、英語名 Research
Network Widening Management）Consortium の代表者 1 名と定められており、少なくとも 7 名以上で構成される。さらに、政府機関の代表者が 5 名まで、インターネットに関する専門家が 2 名まで参加可能となっている。
(3)会員

176

なし。
(4)登録管理業務の委任体制
Maintainer として契約を結んだ ISP などの 395 組織が、IIT から登録業務を委任されている。なお、IIT 自身も登録者からの直接申請を受け付けている。
(5)ドメイン名の構成
第 2、第 3 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録可能文字数
は 3 文字以上 63 文字以下。以下の通り分類される。
a) 第 2 レベルドメイン名
・<任意の文字列>.ITb) 地域型ドメイン名（以下に示す州、県、都市の地方公共団体のみ登録可能）
・<州名または州の略称>.IT・<県名または県の略称>.IT・ <都市名>.<県名または県の略称>.IT(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.it においては、ドメイン名を登録できるのはイタリアの個人または法人、および EU 加盟国に居住もしくは所属する個人または法人とされている。
(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。個人でも.it のドメイン名を登録することができる。
(9)予約ドメイン名
以下のドメイン名は登録することができない。
a)「xn--」で始まる文字列b) gTLD の TLD ラベルc) 州名、県名とその略称、都市名（該当する州、県、都市の地方公共団体のみ登録可能）
d)イタリアに関する名称（「it」「Italia」「Repubblica-Italiana」「RepubblicaItaliana」「RepubblicaIalia」「Repubblica-Italia」）
e) サービス、ネットワークプロトコル関連の名称(10) IDN

177

導入していない。
(11)登録件数
1,482,092（2008 年 1 月 31 日現在）。
(12)料金IIT では、ドメイン名の登録料金を毎年見直している。2007 年については、レジストラに対する料金として 1 ドメイン名あたり年間 4.91 ユーロ（税別）を課している。IIT で
直接ドメイン名登録を行う登録者に対しては、登録から 1 年後の更新時に 103.29 ユーロ（税別）。
(13)紛争処理「Regulations for the Resolution of Disputes in the ccTLD “it”」を定めている。あるドメイン名の登録に異議がある場合、IIT に異議申し立てを行うことができる。IIT は、当該ドメイン名の登録者と申立人の双方に仲裁手続またはドメイン名再割当手続のいずれかを開始するよう促す。登録者と申立人の双方が合意した場合のみ、仲裁手続を開始する
ことができる。仲裁における判断は 3 名の仲裁人で構成される Arbitration Board が行う。
仲裁人は、IIT が認定している。再割当手続は、IIT が認定した C.R.D.D（Centro
Risoluzione Dispute Domini S.r.l.）、MFSD srl、Arbitronline srl、Studio Legale Tonucci& Partners のうちいずれかの組織を通じて行われる。
(14)その他
・2007 年 10 月 31 日、IIT は ICANN と Accountability Framework に基づく書簡を交換し、関係を正式化した。
(15)出典・Nic.it
http://www.nic.it/en/

2-2-2-12 .kr（韓国）
登録管理組織：NIDA（National Internet Development Agency of Korea）(1)登録管理組織の歴史および性質.kr が IANA から韓国に割り当てられたのは、1986 年であった。それ以来、.kr は NCA（National Computerization Agency：韓国電算院）内の KRNIC（Korea Network

178

Information Center）により管理されていた。KRNIC は、1999 年 6 月に MIC（Ministryof Information and Commerce：情報通信部）の認可を受けて非営利の財団法人となった。
2004 年 1 月には韓国でインターネットアドレス資源に関する法律が制定されたが、ことにともない KRNIC の事業は、同法に基づき 2004 年 7 月に設置された NIDA（National
Internet Development Agency of Korea）に引き継がれた。
(2)登録管理組織の運営形態
NIDA には、ド メイン名登録管理の方針を策定する IAPC（Internet Address Policy
Committee）およびドメイン名紛争を処理する IADRC（Internet Address Dispute
Resolution Committee）という 2 つの専門家委員会が設置されている。NIDA の理事長と理事会は MIC によって任命される。また、NIDA の定款、ドメイン名の登録料金を承認するのは MIC である。
(3)会員
NIDA は会員によって統治される組織ではないが、NIDA の IP アドレスの割り振り事業
において、割り振り先の国内 ISP を「Member ISP」と呼んでいる。Member ISP は 113（2008 年 2 月現在）。
(4)登録管理業務の委任体制
NIDA は、登録業務を担うレジストラを認定し、業務を委任している。レジストラは 27
社（2007 年 12 月現在）。
(5)ドメイン名の構成
第 2 レベル、第 3 レベルへの登録。登録可能な文字列は英数字、ハイフン。第 2 レベルの場合ハングル文字での登録も可能。登録文字数は 2 文字以上 17 文字以下。以下の通り分類される。
a) 第 2 レベルドメイン名（ASCII）
・.KR
b) 第 2 レベルドメイン名（ハングル文字）
・.KRc) 属性別ドメイン名
・CO.KR：企業、営利組織
・GO.KR：政府組織
・MIL.KR：韓国軍
・NE.KR：ネットワーク業者
・OR.KR：非営利組織/グループ179

・PE.KR：個人・RE.KR：研究機関d) 教育機関用ドメイン名
・ES.KR、HS.KR、KG.KR、MR.KR、SC.KR、AC.KRe) 16 の地域ドメイン名
・<地域名>.KR（例：京畿道：gyeonggi.kr）
2006 年から 2007 年にかけて、NIDA は、第 2 レベルドメイン名（ASCII）の優先および同時登録申請受付を、以下のスケジュールで実施した。
フェーズ 1：韓国政府のための優先登録申請受付期間（2006 年 9 月 18 日〜2006 年 11 月 20 日）
フェーズ 2：第 3 レベルドメイン名登録者のための優先登録申請受付期間（2006 年 11 月 21 日〜2007 年 3 月 27 日）
フェーズ 3：韓国にローカルプレゼンスを持つ企業および個人ための同時登録申請受付期間（2007 年 3 月 28 日〜2007 年 4 月 18 日）(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件
全てのドメイン名の登録にローカルプレゼンスが必要。
(8)個人用ドメイン名
個人用ドメイン名としてPE.KRを設けている。PE.KEの登録件数は 16,162（2008 年 1月現在）。また、.KR（第 2 レベル）、CO.KR、OR.KR、NE.KR、RE.KRおよび地域型（全16 地域）でも、個人の登録が可能となっている。
(9)予約ドメイン名.kr では、ドメイン名の安定的な管理および公共の利益のために、以下の予約ドメイン名
リストを公開している。
http://domain.nida.or.kr/policy/rule/20070820.htm(10) IDN
2003 年 8 月より第 2 レベルへのハングル文字ドメイン名の登録を開始した。登録件数累計は 94,178（2008 年 1 月現在）。

180

(11)登録件数
937,705（2008 年 1 月現在）。以下は 1997 年 2 月末から 2007 年 2 月末までの年ごとの登録件数の推移。

（「Internet Infrastructure Statistics（http://isis.nida.or.kr/eng/sub01/sub01_index.jsp?menuflag=10）」より）(12)料金レジストラが NIDA に支払う登録料は、1 ドメイン名あたり年間 9,500 ウォン(税別)。ただし、個人用ドメイン名である PE.KR は、年間 7,000 ウォン(税別)。
(13)紛争処理
ドメイン名と商標に関する紛争を処理する枠組みとして、「Internet Address Dispute
Resolution Policy」を定めている。これに基づき、NIDA の専門化委員会 Internet Address
Dispute Resolution Committee が判断している。
(14)その他
・NIDA は 2007 年 3 月 8 日、CNNIC と覚書を締結し、両国のドメイン名サービスの活性化と安定的なインターネット利用環境造成のために相互協力する事で合意した。この協力には、関連技術の共同研究、情報および人的交流などが含まれる。また、共催で毎年ドメ
イン名関連技術シンポジウムを催すことにも合意した。同年 10 月に韓国でシンポジウムを開催予定。
(15)出典・NIDA

181

http://www.nic.or.kr/index.jsp
2-2-2-13 .nl（オランダ）
登録管理組織：SIDN（Stichting Internet Domeinregistratie Nederland：Foundation
Internet Domain Registration in the Netherlands）(1)登録管理組織の歴史および性質.nl は 、 1986 年 に CWI （ Centrum voor Wiskunde en Informatica: Centre forMathematics and Information Technology）に委任された。その後、CWI を運営する
Piet Berrtema 氏が 1996 年 1 月 31 日に SURFnet、NLnet と共に財団法人（foundation）
SIDN を設立し、登録管理業務を SIDN に移管した。
(2)登録管理組織の運営形態
SIDN の方針は理事会（Management Board）で決定される。また、理事会を監視する組織として、監督委員会（Supervisory Board）が設置されている。
さらに、監督委員会に助言を与える組織として CoP（Council of Participants）がある。
CoP は、SIDN カテゴリ 1 会員およびカテゴリ 2 会員で構成される。理事会は、SIDN の重要な方針に関して CoP に諮問する。CoP はこれに対して答申を出すが、この答申は理事会に対する拘束力を持たない。
(3)会員
SIDN の会員は、カテゴリ 1 とカテゴリ 2 に分類される。
a) カテゴリ 1 会員
CoP の会議に参加する権利を持ち、また、.nl のドメイン名登録業務を行うことができる。EU 内に本拠を置く企業や団体がカテゴリ 1 会員として SIDN に入会できる。カテ
ゴリ 1 会員の数は、2,063（2007 年 10 月現在）。
b) カテゴリ 2 会員
CoP の会議に参加する権利を持つが、ドメイン名の登録業務は行わない会員。オラン
ダに拠点を置く企業、団体およびオランダに居住する個人がカテゴリ 2 会員として入会できる。カテゴリ 2 会員の数は 34（2007 年 10 現在）。
(4)登録管理業務の委任体制
カテゴリ 1 会員に登録業務を委任している（上記(3)a）参照）。
(5)ドメイン名の構成
第 2、第 3 レベルへの登録。英数字およびハイフンを使用できる。登録文字数は 2 文字以182

上 63 文字以下。ドメイン名ラベルの先頭、末尾およびハイフンとハイフンの間にハイフンは使用できない。ドメイン名には、アルファベットを 1 文字以上含めなければならない。以下の通り分類される。
a) 第 2 レベルドメイン名
・.NLb) 個人用ドメイン名
・<個人名>.<3 桁の数字>.NL（例：johnsmith.752.nl）
2005 年 11 月 1 日に、この個人用ドメイン名の新規登録は中止された。2008 年にかけて個人用ドメイン名は廃止される予定（以下(8)参照）。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件なし。ただし、登録者がオランダ以外に拠点を置いている場合は、オランダ国内の住所を連絡先として指定しなければならない。
(8)個人用ドメイン名
2000 年 11 月 15 日より、第 3 レベルに登録する形の個人用ドメイン名が導入された。しかし、2003 年に個人でも企業と同様に第 2 レベルに登録できるように規則が改訂されて以来、第 3 レベルの個人用ドメイン名のニーズが低下した。そのため、2005 年 11 月 1
日、個人用ドメイン名の新規登録は中止された。
2007 年 7 月初旬、SIDN は個人用ドメイン名廃止の方針を発表するとともに、対象者となるドメイン名登録者およびレジストラに対し書面や電子メールで、廃止に応じた場合に SIDN から 25 ユーロを支払う旨を通知した。そして、2007 年 12 月末、廃止に応じていない一部を除き、全ての登録済み個人用ドメイン名が.nl ゾーンから削除された。削除されていない個人用ドメイン名について、SIDN では 2008 年第 1 四半期中の削除完了を目指している。
(9)予約ドメイン名
以下のドメイン名は登録できない。
「directory.nl」、「ftp.nl」、「mail.nl」、「nl.nl」、「www.nl」(10) IDN
導入していない。

183

(11)登録件数
2,736,351 件（2008 年 1 月現在）。
(12)料金SIDN が規定するドメイン名の新規登録にかかる卸料金は 1 ドメイン名あたり 0.5
ユーロ。2008 年からは、1 ドメイン名あたり 0.51 ユーロとなる。
(13)紛争処理
商標権侵害などの紛争処理に関しては、「Regulations for Arbitration on .nl Domain
Names」を定めている。紛争処理機関は、WIPO Arbitration and Mediation Center。
2000 年 11 月 15 日以降に登録されたドメイン名に関しては、公序良俗に反する文字列の登 録に対する苦情、SIDN の決定に対する抗議を C&AB（Complaints and Appeals
Board）に申し立てることができる。C&AB は、SIDN によって任命された 5 名から成る
独立の機関。C&A Body が異議申立に対して下す判断は、その理由と共に全て公開される。
なお、2008 年 1 月 29 日、SIDN が 2 月 28 日から新しい紛争処理ポリシーを実施すると発表した。これにともない、現行のプロセスは廃止される予定。
(14)その他
・2007 年 7 月 6 日、SIDN と ICANN は Accountability Framework に基づく書簡の交換を行ったと発表した。
・2007 年 10 月 14 日、SIDN は、.nl ゾーンファイルの更新頻度を 1 日 12 回に増やした。
なお、更新のタイミング、は中央ヨーロッパ標準時の 2 時、4 時などの偶数時刻。
・2007 年 12 月より、SIDN は第 2 レベルが数字のみで構成される.nl のドメイン名を開放した。同年 12 月 1 日から 14 日の間は商標権保持者のための優先登録期間とされ、先願による登録申請受付は 2008 年 2 月 28 日から開始された。
(15)出典
・SIDN
http://www.sidn.nl/ace.php/c,728,122,,,,Home.html

184

2-2-2-14 .se（スウェーデン）登録管理組織：IIS （II-Stiftelsen：Internet Infrastructure Foundation）(1)登録管理組織の歴史および性質.se は、1986 年 9 月に IANA データベースに登録された。1997 年、ISOC のスウェーデン支部により IIS が設立された。IIS の目的は、ドメイン名の登録管理およびインターネ
ット基盤の開発。なお、当時、登録管理に関する実務は IIS が同時期に設立した子会社
NIC-SE （Network Information Centre Sweden AB）が実施していた。その後、2005
年 12 月の IIS 理事会決議に基づき、2006 年 3 月 1 日付けで NIC-SE が IIS に統合され、IIS が.se の登録管理業務を担うことになった。
(2)登録管理組織の運営形態
IIS の意思決定は理事会が行い、CEO が事務局を運営する。2006 年 7 月 1 日、スウェー
デンのドメイン名に関する法律が制定 され、IIS は PTS（英語名 Swedish Post andTelecom Agency）の監督を受けるようになった。
(3)会員
なし。
(4)登録管理業務の委任体制
202 社のレジストラに登録業務を委任している（2007 年 12 月 19 日現在）。
(5)ドメイン名の構成
第 2 レベルおよび第 3 レベルへの登録が可能。ドメイン名に使用できる文字は、英数字、ハイフンおよび IDN。登録可能な文字数は 2 文字以上 63 文字以下。以下の通り分類される。
a) 第 2 レベルドメイン名（ASCII および）・.SEb) 属性別ドメイン名
・ORG.SE：非営利組織
・PP.SE：国民識別番号またはスウェーデンの調整番号を保持する個人
・PRESS.SE：スウェーデン特許局による証明書を保持する出版社
・PARTI.SE：政党
・TM.SE：商標

185

・<地方名略語>.SE：法人税証明（F-skattesedel）の交付を受け、当該地域に所在する企業、組織(6)登録可能ドメイン名数の制限の有無
2003 年 4 月に制限を撤廃した。
(7)ローカルプレゼンス要件
全てのドメイン名についてローカルプレゼンスが要件となっている。 .SE（第 2 レベル
ドメイン名）の場合、法人登記番号を保持する法人、スウェーデンの公的機関が発行する証明書の保持者、またはスウェーデンの公的機関でなければ登録できない。個人の場
合はスウェーデンの国民識別番号の保持者でなければならない。第 3 レベルへの登録についても、属性ごとにスウェーデンの組織または個人であることが条件となっている。
(8)個人用ドメイン名
個人用の空間 PP.SE が設けられている。PP.SE を登録するには、国民識別番号または調整番号が必要。また、.SE（第 2 レベルドメイン名）はスウェーデン国民識別番号を保持していれば、個人でも登録できる。
(9)予約ドメイン名
以下に該当するドメイン名は登録禁止とされている。
a) 3、4 文字目にハイフンを含むドメイン名
b)「90xxxx-x」および「90x-xxxx」の形式であらわす 900000 から 909000 までの
数字のドメイン名c) 緊急電話番号「90000」d) スウェーデン国民識別番号と同じ「xxxxxx-xxxx（ハイフン以外は数字）」という形式の文字列
以下は登録禁止のドメイン名と定義され、リストが公開されている。
e) 2 文字の国別コードf) xn--skrareinternet-5hb.se などの試験用ドメイン名および example.se などの例示用ドメイン名g) COM.SE、WHOIS.SE など、「誤解を招くもの」として定義されたドメイン名h) サブドメインとして定義される AC.SE および BD.SEi）BRAND.SE、TM.SE などの指定された第 2 レベルドメインj) OPEC.SE、WIPO.SE など、「スウェーデン法に関連するもの」として定義されたドメ
イン名

186

また、以下は適切な主体のために予約されたドメイン名と定義され、リストが公開されている。
k) 国の名称のドメイン名l) 地理的名称のドメイン名m) 特定の数字で構成するドメイン名n) 裁判所名のドメイン名(10) IDN
2003 年 10 月に登録が開始された。まずを使用したドメイン名の登録が可能となり、2007 年 7 月 4 日にスウェーデン国内法で定められた公用少数言語のフィンランド語、メアンキエリ語、サーミ語、ロマ語、イディッシュ語などの文字が追加された。
(11)登録件数
701,268 件（2008 年 1 月 31 日現在）。
(12)料金ドメイン名の新規登録時、登録者は IIS の 1 年分の会費を含んだ料金をレジストラに支払う。レジストラが登録者に課す料金はレジストラによって異なる。登録の 2 年目から
は、ドメイン名 1 件あたり年間 150 スウェーデンクローナ（うち付加価値税 30 スウェーデンクローナ）を IIS に直接支払う。
(13)紛争処理「 ADR （ Alternative Dispute Resolution Procedure for Domain Name Disputes
under .se）」を定めている。ADR は、IIS とは独立した仲裁人が実施し、管理、事務をIIS がとり行う。仲裁人は、大学教授、弁護士などが務めている。
(14)その他
・2007 年 2 月 16 日、IIS が.se の DNS に DNSSEC を導入した。ドメイン名登録に付加されるサービスとの位置づけで、5 社のレジストラを通じて申し込み可能とした。
・2007 年 7 月 6 日、IIS が ICANN と Accountability Framework に基づく書簡を交換し、関係を正式化した。
・2008 年 1 月より、IIS は ADR の申立手数料を 2 割値下げした。値下げ後の手数料は、
仲裁人 1 名の場合 8,000 クローナ、仲裁人 3 名の場合 16,000 クローナ（以上税込み）。

187

(15)出典
・IIS
http://www.iis.se/

2-2-2-15 .sg（シンガポール）
登録管理組織：SGNIC（Singapore Network Information Centre）(1)登録管理組織の歴史および性質.sg のドメイン名は、シンガポール国立大学内の研究ネットワーク TechNet によって登録管理されていた。1995 年 10 月、.sg の登録管理と、地元の ISP および規制当局がシンガ
ポールにおけるインターネットサービスの運営に関する議論の促進を目的として SGNICが設立され、TechNet の登録管理業務は SGNIC に引き継がれた。なお、1997 年 7 月ま
では、SGNIC の業務は政府の公的機関である IDA（Infocomm Development Authority ofSingapore）の NMI（New Media and Internet Cluster）が運営していた。そして、1997
年 7 月、SGNIC は SGNIC Private Limited として法人登記した。
(2)登録管理組織の運営形態
SGNIC は、方針決定を行う理事会、専門分野について理事会に助言を行う DNRSCommittee（Domain Name Registration Service Committee）と DNST Committee（Domain Name System Technical Committee）および日々のレジストリ業務を遂行する事務局で構成される。
(3)会員
なし。
(4)登録管理業務の委任体制
10 社のレジストラに登録業務を委任している（2008 年 3 月現在）。

(5)ドメイン名の構成
第 2 レベル、第 3 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録可
能な文字の数は、2 文字以上 63 文字以下。 .sg のドメイン名は、以下の通りに分類される。

188a) 第 2 レベルドメイン名
・.SG：個人、法人、組織。外国籍の個人、法人、組織はシンガポール国内に所在する代理人を管理連絡先として指定すれば登録が可能b) 第 3 レベルドメイン名
・COM.SG：ACRA（Accounting and Corporate Regulatory Authority）、または IESingapore（International Enterprise Singapore）へ登録している、または登録予定の企業。GOV.SG 下に登録している政府機関は、GOV.SG ドメイン名と同じ文字列をCOM.SG 下で登録可能。
外国企業は、シンガポール国内の登録企業を管理連絡先として指定すれば登録可能。
・NET.SG：シンガポールの情報通信事業者およびネットワークプロバイダ。GOV.SG 下に登録している政府機関であれば、GOV.SG ドメイン名と同じ文字列を NET.SG 下で登録できる・ORG.SG：協会登録局（Registry of Societies）に登録している、または登録予定の組
織・EDU.SG：MOE（Ministry of Education, Singapore）に登録されている教育機関。小中学校は第 4 レベルに登録する（例：「<学校名>.moe.edu.sg」）。GOV.SG 下に登録している政府機関は、GOV.SG ドメイン名と同じ文字列を EDU.SG 下で登録できる
・GOV.SG：シンガポール政府
・PER.SG：シンガポール国民およびシンガポールでの永住権を保持する個人(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.SG（第 2 レベルドメイン名）は、シンガポール国内に所在する代理人を管理連絡先として指定すれば、COM.SG は、シンガポール国内の登録企業を管理連絡先として指定すれば可能。その他のドメイン名の登録者はシンガポール国内に所在し、シンガポールの公的機関に何らかの登録を行っている者でなければならない。
(8)個人用ドメイン名
シンガポール国民およびシンガポールでの永住権を保持する個人のためのドメイン名として、PER.SG が設けられている。登録件数は 751（2008 年 1 月末現在）。
(9)予約ドメイン名.sg では、以下のドメイン名の登録を禁止している。
a) シンガポール国名および政府に関連する文字列（「Singapore」、「President」など）

189b) 「SGNIC」、「NIC」およびこれらを変化させた文字列c) わいせつ、中傷、および法律または道徳に反する文字列d) 地理的名称、国名（「Malaysia」、「Japan」など）
e) gTLD の TLD ラベルf) 「www」、「http」、「https」、「http-www」
g) 他の空間で登録済みの文字列と同一かまたは類似しており、SGNIC が望ましくないと判断する文字列h) 数字のみで構成する文字列i) その他 SGNIC が不適切と判断する文字列j) ISO 3166 リスト掲載された 2 文字の国コードk) PER.SG については、上記に加えてさらに「RPPG（Registration Policies、Procedures
and Guidelines）」の Annex1「Reserved Names of PER.SG Domain」に列挙された文字列。
なお、2007 年 4 月 18 日から 5 月 16 日の間に限り、.SG、ORG.SG、NET.SG、EDU.SG、
GOV.SG、PER.SGにおいてそれまで登録できなかった文字列「Temasek」の登録申請を受け付けた。
(10) IDN
導入していない。IDN の登録実験が 2005 年 7 月 4 日から 2006 年 1 月 3 日まで実施され、専用の IDN.SG 空間において中国語とタミル語のドメイン名が試験的に登録されたが、実験期間終了後は、全て消去された。その後、SGNIC は IDN の需要の程度などを勘案し、必要に応じて IDN を実装するとしていたが、現在のところ実装の是非の判断は行われていない。
(11)登録件数
88,975 （2008 年 2 月 1 日現在）。内訳は、COM.SG： 55,633、EDU.SG： 539、GOV.SG：
455、NET.SG： 205、ORG.SG： 2,298、PER.SG：751、.SG： 29,094。
(12)料金COM.SG、NET.SG、ORG.SG、EDU.SG、GOV.SG のレジストラ向け登録料金は、1 ド
メイン名あたり年間 30 シンガポールドル。
(13)紛争処理「SDRP（Singapore Domain Name Dispute Resolution Policy）」が SGNIC により定められている。紛争処理の実務は、SMC（Singapore Mediation Centre）および SIAC

190

（Singapore International Arbitration Centre）が共同で運営する紛争処理事務局が行っている。紛争処理事務局はパネルを任命し、パネルが裁定を下す。
(14)その他
・SGNIC は、「RPPG（Registration Policies, Procedures and Guidelines）」と「Registration
Agreement」を改定し、2007 年 10 月 23 日に Web サイトに公開した。RPPG の主な変
更点は、ドメイン名の形式、予約ドメイン名、登録資格、登録回復の料金。Registration
Agreement は、RPPG に合わせて改定された。この改定の実施は 2007 年 11 月 22 日。
・2007 年 12 月 28 日から 2010 年 12 月までの間、SGNIC は、IDA および ACRA との共同で、新規設立企業向けの期間限定キャンペーンを実施している。具体的には、企業がACRA への登記と同時に COM.SG および.SG（第 2 レベルドメイン名）のドメイン名を予約できるというもの。申し込みは、このキャンペーンに参加している 7 社のレジスト
ラからのみ行うことができる。
・SGNIC では、第 3 レベルドメイン名を登録すれば同じ文字列の第 2 レベルドメイン名を登録できるキャンペーンを 2005 年 9 月から実施してきたが、これが好評なことから、終了日を 2007 年 3 月 1 日から 2008 年 2 月 28 日に延期した。さらに、2007 年 3 月 1 日より、第 3 レベルと同じ文字列の第 2 レベルドメイン名を登録する場合には、その第 2 レ
ベルドメイン名の初年度の登録料金を無料とした。
・2007 年 10 月 22 日、SGNIC は数字ドメイン名の登録申請受付を開始すると発表した。
申請の受付は、以下のスケジュールによって行われる。
a) サンライズ期間（2007 年 11 月 5 日〜12 月 28 日）
後述のプレミアムドメイン名のみ申請可能。商標保持者は優先を要請できるb) 競争入札期間（2008 年 1 月 18 日〜2 月 22 日）
サンライズ期間中複数の申請があった数字ドメイン名に対する競争入札c) 入札結果発表（2008 年 2 月 25 日）d) 入札結果に対する異議申立期間（2008 年 2 月 25 日〜3 月 10 日）e) 登録が確定したドメイン名の DNS 登録（2008 年 3 月 27 日）f) 先願登録申請受付期間（2008 年 3 月 27 日〜）
後述の一般数字ドメイン名のみ申請可能。この時点で登録されていないプレミアムド
メイン名はいったん予約され、6 ヶ月程度の期間ごとにオークションにかけられる
以下はサンライズ期間から先願登録申請受付期間にいたるまでのスケジュールを図示し
たもの。

191

（「Guidelines for Application of Numeric ‘.sg’ Domain Names During Soft Launch
Period (http://www.nic.net.sg/pdf/ndn_guidelines.pdf)」より）
なお、数字ドメイン名は以下のように分類され、異なる登録料金が設定されている。
‐プレミアムドメイン名
プラチナ：1 桁 （10 件登録可能）
40,000 シンガポールドル。入札の場合は 10,000 シンガポールドルから応札可
ゴールド：2〜11 桁 (約 4,300 件登録可能)
1,000 シンガポールドル。入札の場合は 1,000 シンガポールドルから応札可
シルバー：3〜11 桁 (約 1 万 2,000 件以上登録可能)
600 シンガポールドル。入札の場合は、600 シンガポールドルから応札可‐一般数字ドメイン名：5〜11 桁 (約 1 千億件以上登録可能)
200 シンガポールドル。入札の場合は、200 シンガポールドルから応札可
2008 年 2 月 26 日に SGNIC が APTLD 台北会合で行った発表によれば、2007 年 11 月 5
日〜12 月 28 日のサンライズ期間中に申請されたドメイン名は 74 件で、そのうち 5 件が競争入札の対象になった。
(15)出典・SGNIC
http://www.nic.net.sg/
・TechNet
http://www.technet.sg

192

2-2-2-16 .tw（台湾）
登録管理組織：TWNIC（Taiwan Network Information Center）(1)登録管理組織の歴史および性質
1994 年、TWNIC は 2 年間の予定で試験的に資源管理業務を開始した。2 年後の 1996
年から 1998 年までの間、TWNIC はコンピュータ関係の学会である CSROC（Computer
Society of the ROC）の監督のもとで操業していたが、1998 年から 1999 年までは政府の国 家 情 報 基 盤 政 策 の 一 環 と し て 、 MOTC （ Directorate-General of theTelecommunication）の監督下に置かれた。そして、1999 年 12 月、CSROC および MOTCの出資により、TWNIC は非営利法人に改編された。
(2)登録管理組織の運営形態
TWNIC の方針決定は、ドメイン名および IP アドレスなどの主要な専門委員会を監督す
る理事会によって行われる。ドメイン名登録管理に関する具体的な方針案は、外部委員で構成するドメイン名委員会が作成し、理事会に提案する。
以下は TWNIC の組織図。

（「 TWNIC Current Status Update - APTLD Taipei Meeting 2008/02/25(http://www.aptld.org/taipeifebruary2008/03-Update_on_TWNIC.pdf)」より）
(3)会員
なし。

193

(4)登録管理業務の委任体制
10 社のレジストラに登録業務を委任している（2007 年 11 月現在）。海外レジストラへの窓口は米国 NeuLevel 社が一括して行っている。
(5)ドメイン名の構成
第 2、第 3 レベルへの登録。登録可能な文字列は英数字、ハイフンおよび中国語文字。登録できる文字数は、ASCII ドメイン名の場合は 2 文字以上 63 文字以下。中国語文字によるドメイン名の場合は 4 バイト（中国語の 1 文字）以上 28 バイト（中国語の 14 文字）
以下。中国語文字のドメイン名の場合、使用できる文字は Big5 のみ。
a) 第 2 レベルドメイン名（ASCII）
・.TW：個人、法人、組織b) 第 2 レベルドメイン名（中国語文字）
・.TW：個人、法人、組織c) 属性別ドメイン名（ASCII）
・COM.TW：登記された企業および企業
・EDU.TW：教育・学術機関
・GOV.TW：政府機関
・IDV.TW：個人・MIL.TW：軍関係機関
・NET.TW：認可を受けた電気通信事業者
・ORG.TW：登記された団体および法人、外国の非営利組織
・GAME.TW、EBIZ.TW、CLUB.TW：登録資格制限なしd) 属性別ドメイン名（中国語文字）
・商業.TW、網路.TW、組織.TW、軍事.TW、教育.TW、政府.TW
なお、商業.TW、網路.TW、組織.TW を登録するには、対応する ASCII ドメイン名（COM.TW、NET.TW、ORG.TW）を先に登録しておく必要がある。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件
EDU.TW、GOV.TW、MIL.TW、NET.TW および網路.TW は、台湾の組織のみ登録可能。
それ以外のドメイン名については、ローカルプレゼンス要件は設けられていない。

194

(8)個人用ドメイン名
個人専用のドメイン名として IDV.TW を設けている。IDV.TW の登録件数は 19,912（2007年 12 月現在）。
(9)予約ドメイン名a) 全てのドメイン名について
・3 文字目および 4 文字目にハイフンを含む文字列b) 第 2 レベルドメイン名（中国語文字）について
・国家主権の行使に関連する名称（「中華民国」など）、政府に関連する名称、県、市行政区に関連する名称、政府機関の名称および略称、学校名、および TWNIC が特に定める名称（例：現行の gTLD ラベルの中国語に相当する文字列）c) 属性別ドメイン名（中国語文字）について
・ 職業分類（業界名）、国家、政府機関、地名（県および市の名称）など（第 3 レベルへの登録の場合）(10) IDN
2001 年 2 月 16 日から、繁体字中国語文字ドメイン名の登録申請を受け付けている。
中国語文字ドメイン名の登録件数は 130,651（2007 年 12 月末現在）。

195

(11)登録件数
356,184（2007 年 12 月末現在）。
以下は 2007 年 1 月から 2008 年 1 月までの ASCII ドメイン名の累計登録件数の推移。

（「.tw域名統計查 詢 (http://statistics.twnic.net.tw/item02.htm)」をもとに作成）

196

以下は 2008 年 1 月時点のドメイン名登録数の内訳。

（「 TWNIC Current Status Update - APTLD Taipei Meeting 2008/02/25(http://www.aptld.org/taipeifebruary2008/03-Update_on_TWNIC.pdf)」より）

197

(12)料金.tw におけるドメイン名の登録料金は、その属性ごとに異なる。TWNIC からレジストラに対して課している料金は非公開。以下はレジストラが登録者に課すことのできる最高料金として TWNIC が指定している金額。

（「Standard Domain Name Registration Fee/Management Fee（http://www.twnic.net.tw/english/dn/dn_02_c.htm）」より）(13)紛争処理「財團法人台灣網路資訊中心網域名稱爭議處理辦法（TWNIC Domain Name Dispute
Resolution Policy）」を定めている。紛争処理は、TWNIC の認定を受けた STLC（Science& Technology Law Center）および Taipei Bar Association が行っている。
(14)その他
特記事項なし。
(15)出典・TWNIC
http://www.twnic.net.tw/198

2-2-2-17 .uk（イギリス）
登録管理組織：Nominet UK(1)登録管理組織の歴史および性質.uk は、1985 年 7 月に IANA データベースに登録された。当時、.uk の登録管理は、Naming
Committee というボランティア組織が行っていた。1980 年代にイギリスの教育ネットワ
ーク JANET（Joint Academic Network）が設立され、大学、国防省、研究所などの通信に利用されていたが、1990 年代前半までには、ISP がこのネットワークに参加し、消費者に商業ベースでドメイン名を提供するようになった。この頃からドメイン名の登録件数が増加し、登録管理をボランティアによって担うことが困難になったため、1996 年、登録管理組織として非営利有限責任保証会社 Nominet UK（以下「Nominet」）が設立された。
(2)登録管理組織の運営形態
Nominet の理事会は、2 名の常任理事と会員から 2 年ごとに選出される 4 名の非常任理事で構成される。その理事会に対し、PAB（Policy Advisory Board）が会員の意見を反映した政策や規則を立案し、勧告する。PAB は、2 名の非常任理事、指名を受けた最大 8つの組織の代表者、会員から選出された 8 名で構成される。会員は、非常任理事およびPAB 委員を選出でき、総会での投票権を持っている。
(3)会員
入会金と年会費を払えば誰でも会員になることができる。会員数は 2,800（2008 年 1 月
現在）。会員のほとんどは ISP であるが、法律事務所、警察、専門分野のコンサルタントなども会員となっている。
(4)登録管理業務の委任体制
4,220 社のレジストラに登録業務が委任されている（2007 年 12 月現在）。Nominet も登録申請を受け付けるが、Nominet に申し込む場合、登録者は 2 台のネームサーバの IP ア
ドレスを自ら設定し、その情報をレジストリ（Nominet）に登録しなければならない。
また、以下のドメイン名については、登録管理業務が各機関へ委任されている。
・AC.UK および GOV.UK：JANET（the UK Education and Research Network）
・NHS.UK：National Health Service
・POLICE.UK: 警察・MOD.UK および MIL.UK：国防省

199

(5)ドメイン名の構成
第 3、第 4 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録可能文字数
は、全レベルの文字数を合計して 64 文字まで。ドメイン名の分類は以下の通り。
a) Nominet が登録管理する SLD（第 3 レベルへの登録）
・CO.UK：営利企業など
・LTD.UK、PLC.UK：イギリス会社法に基づく有限責任会社および株式公開会社
・ME.UK：個人
・NET.UK：イギリスで登録された ISP・ORG.UK：非営利組織など
b) その他（Nominet 以外の組織に登録管理を委任）（第 3 レベルへの登録）
・AC.UK：高等教育機関、学術研究機関
・GOV.UK：政府、地方政府
・POLICE.UK：警察・MOD.UK および MIL.UK：軍関係目的用
・NHS.UK：National Health Servicec) Nominet が特定目的用に予約、管理している SLD・NIC.UK：ネットワーク（第 3 レベルへの登録）
・<学校名>.<地域名>.SCH.UK：学校（第 4 レベルへの登録）(6)登録可能ドメイン名数の制限の有無
PLC.UK、LTD.UK、SCH.UK に限り、1 つの組織が 1 つのドメイン名しか登録できないという制限がある。
(7)ローカルプレゼンス要件
LTD.UK、PLC.UK のドメイン名は、イギリスで登記した法人でなければ登録できない。
NET.UK を登録するには、イギリスの会社法人、学術機関、イギリスで登録された ISP
である必要がある。また、SCH.UK のドメイン名はイギリスの学校のみ登録可能。
(8)個人用ドメイン名
ME.UK を設けている。登録件数は 156,887（2007 年 12 月現在）。
(9)予約ドメイン名
以下のドメイン名は登録できない。ただし、a)と b)は、Nominet が認める場合に限り登録可能となっている。
a) NIC.UKb) SCH.UK

200c) 3、4 文字目にハイフンを含むドメイン名d) 1 文字のドメイン名（第 3 レベルに登録する場合）
e) アルファベットのみ、またはアルファベットとハイフンのみの 2 文字で構成するドメ
イン名（CO.UK、ME.UK、ORG.UK、NET.UK の場合）※アルファベットと数字、または数字による 2 文字で構成するドメイン名は登録可能。
f) 第 2 レベルドメイン名ラベルと同一の文字列（CO.UK、ME.UK、ORG.UK、NET.UKの場合）g) ICANN が定める TLD ラベル（CO.UK、ME.UK、ORG.UK、NET.UK の場合）
(10) IDN
2008 年 1 月時点では IDN を導入していないが、2007 年 1 月、PAB 会議において、以下の 2 段階のサンライズ期間を経て IDN を導入する案が採択された。具体的な導入時期は未定。
a) サンライズ 1
対象ドメイン名：登録済み ASCII ドメイン名と同一の語
期間：限定されるb) サンライズ 2
対象ドメイン名：登録している ASCII ドメイン名と同一の語
期間：サンライズ 1 終了後より 12 ヶ月間
登録可能な言語文字は、原則として Unicode で規定された 59 種類（漢字、ひらがなおよびカタカナを含む）を想定している。

201

(11)登録件数
6,486,829（2008 年 1 月現在）。
以下は 2007 年 1 月から 2007 年 12 月までの累計登録件数の推移。

（「Registration Statistics（http://www.nic.uk/intelligence/statistics/registration/）」より）(12)料金Nominet で直接ドメイン名を登録する場合、1 ドメイン名あたりの登録料金は、2 年間で会員は 5 ポンド、非会員は 80 ポンド（付加価値税別）。Nominet がレジストラに課す料金は非公開となっている。
(13)紛争処理
ドメイン名と商標に関する紛争を処理する枠組みとして、「Dispute Resolution Service
Policy」および「Dispute Resolution Service Procedure」を定めている。紛争処理は以下の 5 段階で構成される。
a) 第 1 段階
Nominet 所定の書式を用いて Nominet 経由で登録者に異議申立書を送付する
b) 第 2 段階
Nominet 職員の支援により、申立人と登録者との間で調停を行う
c) 第 3 段階
Nominet が任命する外部の専門家に判断を依頼する
d) 第 4 段階
専門家の判断に異議がある場合、申立を行い、再度の判断を依頼する
e) 第 5 段階
専門家の判断が Nominet の Web 上で公示される

202

Nominet では、紛争処理ポリシーの改定を検討している。具体的には、申立に対し登録者が抗弁しないケースが多いことから、一定期間内に抗弁がなければ申立を認めるという「DRS Default Transfer Process」の導入を検討している。Nominet は、この案について、2007 年 9 月 3 日から 10 月 3 日までの間公開意見募集を実施した。また、このプ
ロセスを導入した場合の紛争処理手数料の引き下げも検討している。現在は、登録者による抗弁の有無に関わらず 750 ポンドとなっているが、抗弁がなかった場合の手数料を200 ポンドに引き下げるというもの。
(14)その他
2008 年 1 月 17 日、Nominet 理事会は、教育、研究および適切なプロジェクトへの資金拠出を通じてイギリスのインターネット関係者に利益をもたらすことを目的とした「Nominet 財団」の設立を発表した。理事会では、初年度に 500 万ポンドを同財団に寄付し、2008 年から同財団の活動を開始させる予定としている。
(15)出典・Nominet UK
http://www.nic.uk

2-2-2-18 .us（米国）
登録管理組織：NeuStar, Inc(1)登録管理組織の歴史および性質.us は、1985 年 2 月に IANA データベースに登録された。当時登録管理を行っていたのは、USC-ISI（University of Sothern California Information Sciences Institute：南カ
リフォルニア大学情報科学研究所）であった。その後、米政府の NTIA（National
Telecommunications and Information Administration：商務省電気通信情報局）が 2001
年 6 月に.us の運用管理者の公募、入札を行い、同年 11 月、米国の NeuStar, Inc.が落札した。NTIA と NeuStar との契約は 2007 年 10 月 25 日までであったが、契約終了に先立つ再入札が行われた結果再び NeuStar が落札し、2010 年 10 月 25 日までの 3 年契約を結んだ。この契約では、2010 年 10 月 26 日以降について、1 年間の契約延長を 2 回行
うことができると定められている。

203

(2)登録管理組織の運営形態
Neustar では、社内に usTLD 実装チーム（「usTLD チーム」と呼ばれることもある）という特別なチームを編成し、.us の登録管理業務を行っている。このチームでは、NeuStar
でインターネットの運用、システム開発、財務、広報、資源管理などを統括している幹部
社員で構成する Executive Oversight Committee の監督のもと、同社の IP サービス担当
Vice President お よ び usTLD 管 理 担 当 Director の 配 下 で 機 能 す る 実 務 部 隊
Implementation and Ongoing Operations Team が日々の業務を遂行している。以下は、
usTLD 実装チームの構成図。

（「NeuStar Response to SB1335-01-Q-0740(http://www.ntia.doc.gov/ntiahome/domainname/usca/cafiles/SectionA.pdf)」より）.us に お い て ド メ イ ン 名 登 録 の 技 術 的 要 件 を 変 更 す る 場 合 は 、 NTIA が 指 定 す る
Contracting Officer の承認を受けなければならない。ポリシー面の要件を変更する場合
は、諮問機関である US Policy Council が見直しを提案し、NeuStar を支援する。
(3)会員
なし。

204

(4)登録管理業務の委任体制.US（第 2 レベルへ登録）の登録業務は、115 社のレジストラに委任されている。また、
KIDS.US への登録業務は 16 社のレジストラに委任されている（2007 年 11 月現在）。さらに、地域ドメイン名はサブドメイン毎に、NeuStar の委任を受けた delegated manager
が取り扱っている（delegated manager が不在のサブドメインは NeuStar が取り扱う）。

(5)ドメイン名の構成
第 2、第 3 レベルへの登録。登録可能な文字列は英数字およびハイフン。登録できる文字の数は 63 文字以下。 .us におけるドメイン名は以下のように分類される。
a) 第 2 レベルドメイン名
・.USb) 属性別ドメイン名
・KIDS.US：子供向けコンテンツc) 地域属性ドメイン名
・K12.<州>.US：公立学校（例：k12.ny.us）
・PVT.K12.<州>.US：市立学校
・CC.<州>.US：コミュニティカレッジ
・TEC.<州>.US：技術、職業訓練学校
・LIB.<州>.US：図書館
・STATE.<州>.US：州政府機関
・GEN.<state-code>.US：他の分類に適合しないもの（クラブ、公園など）
・DNI.US：国立研究所など
・<市>.FED.US：連邦政府機関
・<市/郡>.<州>.US：ビジネス向け（例：new-york.ny.us）
・CI.<市>.<州>.US：市政府機関
・CO.<郡>.<州>.US：郡政府機関※州名には 2 文字の州コードが用いられる。
(6)登録可能ドメイン名数の制限の有無なし。
(7)ローカルプレゼンス要件.us におけるドメイン名は、米国国民または居住者、米国に所在する企業または組織でなければ登録できない。

205

(8)個人用ドメイン名
特に個人用に限定したドメイン名カテゴリは設けていない。個人でも.us ドメイン名を登録することができる。
(9)予約ドメイン名a) 3、4 文字目にハイフンを含むドメイン名b) 国内の地名およびインターネットの相互運用性を守るために必要な用語c) 電話番号、「数字 5 桁-数字 4 桁」（郵便番号の形式）、5 桁以上の数字で構成されたドメイン名
上記のほか、以下のリストに掲載された約 52,000 件の文字列も NeuStar によって予約されている。
http://www.neustar.us/registrars/fcfs/dotus_reservedlist_v3.zip(10) IDN
導入していない。
(11)登録件数
1,386,412（2008 年 1 月現在。NeuStar が登録件数を公開していないため、NameIntelligence による「Domain Counts & Internet Statistics（http://www.domaintools.com/internet-statistics/）」を参照した）。
(12)料金レジストラ向け料金は 1 ドメイン名あたり年間 5.5 米ドル。
(13)紛争処理「USDRP（usTLD Dispute Resolution Policy）」および「NDP（Nexus Dispute Policy）」
を定めている。紛争処理機関は AAA（American Arbitration Association）および NAF（National Arbitration Forum）。
(14)その他
・2007 年 7 月、NTIA による.us レジストリの再入札が行われた際には、NeuStar 以外に
Afilias Ltd.（.info などのトップレベルドメインのレジストリ。本社はアイルランド）とGoDaddy.com, Inc.（米国の大手レジストラ）が設立したジョイントベンチャーも応札していたが、最終的には NeuStar が落札した。

206

(15)出典・.us（NeuStar）
http://www.nic.us/

2-3 WHOIS を巡る ICANN での議論の動向
2-3-1 WHOIS に関する議論の背景
WHOIS とは、インターネットレジストリが管理するインターネット資源の登録情報を提供するサービスであり、その運営は、各レジストリによってそれぞれの情報公開ポリシーに基づいて行われている。
ICANNにおけるWHOISの議論の背景には、「プライバシー擁護派」対「情報公開派」の戦いともいうべき利害の対立がある。そもそもWHOISサービスを提供する主たる目的は、当初はネットワーク運用（特にインターネット上での自律的なトラブル解決）や、登録デー
タの確認、更新のために必要な情報の提供とされていた43が、インターネットが社会で広く使われ始めるにつれ、実社会のルールとの違いが際だつようになり、プライバシー擁護の必要 性などの論点が出てくるようになった。しかし 、上記で触れた当初の目的のために
WHOISを提供することへの支持もなお根強く、それ故にWHOISに関する議論は容易には決着し難い問題をはらんでいると言える。

2-3-2 WHOIS に関する過去の議論
ICANN での WHOIS の議論は以前より行われてきたが、2003 年 10 月の ICANN チュニス
会議における GNSO 評議会会議において、WHOIS 問題を 3 つのタスクフォースにおいてそれぞれ検討を行うことが正式に決定されたことが、現在の議論に至る流れの源である。
各タスクフォースの検討課題としては、(1)マーケティング目的の WHOIS 利用の制限、(2)
収集、公開するデータの見直し、(3)登録データの正確性の向上、が指定された。その後 2004
年 9 月にタスクフォース活動の方向性の整理が行われ、タスクフォース１およびタスクフ

43 「JPNICのIPアドレス割り当て管理業務における情報の取り扱い等に関する規則」によると、情報公開の目的は「（１）申請者および届出者の当センターへの申請、届出のため。（２）ネットワークの運用、特にインターネット上での自律的なトラブル解決のために、当該ネットワークに関する連絡先を知るため。
（３）資源管理が規則に定められたとおり行われていることを示すため。
（４）登録情報の主体およびＩＰ
指定事業者の登録情報の確認、更新のため。」とされている。
http://www.nic.ad.jp/doc/jpnic-00998.html

207ォース２は、(1)登録者への WHOIS ポリシーに関する明確な通知を行うことについて、(2)ICANN のポリシーと国家法が抵触する場合、レジストラと ICANN はそのような抵触に対して何ができるか、(3)WHOIS 登録データへの段階的なアクセスについては、その登録データの閲覧要請者が誰なのかを識別すること、を検討していくこととなった。
その後 2005 年 3 月の ICANN マルデルプラタ会議までに具体的な提案を出すこと、初回レポートの作成を目指して作業が続けられたが、議論が難航し具体的な進展を見ることなく、2005 年 2 月にタスクフォースが 1 つに統合された。このタスクフォースは、まずは WHOISの目的の定義について議論し、合意することを目指して結成されたが、タスクフォース内
でコンセンサスに至ることなく、結局 2 つの案を併記することとなった。それぞれの案を以下に示す。
（案１・原文）The purpose of the gTLD Whois service is to provide information sufficient to contact a
responsible party for a particular gTLD domain name who can resolve, or reliably passon data to a party who can resolve, issues related to the configuration of the records
associated with the domain name within a DNS nameserver.
（案１・日本語訳）
gTLD WHOIS サービスの目的は、ある特定の gTLD ドメイン名において責任を持ち、DNS
ネームサーバ内の当該ドメイン名登録設定に関する問題を解決できる当事者自身、もしくは解決できる者へデータを確実に渡せる当事者にコンタクトするに十分な情報を提供することである。

（案２・原文）The purpose of the gTLD Whois service is to provide information sufficient to contact a
responsible party or parties for a prticular gTLD domain name who can resolve, or
reliably pass on data to a party who can resolve, technical, legal, or other issues related
to the registration or use of a domain name.
（案２・日本語訳）
gTLD WHOIS サービスの目的は、ある特定の gTLD ドメイン名において責任を持ち、ドメ
イン名の登録もしくは利用に関する技術的問題、法的問題もしくはその他の問題を解決できる当事者または当事者集団自身、もしくは解決できる者へデータを確実に渡せる当事者にコンタクトするに十分な情報を提供することである。

208

GNSO 評議会では、レジストラ部会、レジストリ部会、非商用ユーザ部会が定義１への支持を表明した一方で、知的財産部会、ISP 部会、商用ユーザ部会は定義２への支持を表明し、GNSO 内でも意見が真っ二つに分かれた。上記の２つの定義案を見れば分かる通り、定義
１はあくまで技術的な問題解決のための情報提供を念頭に置いているのに対し、定義２はそれよりももっと広い、ビジネス的な問題をも解決するための情報提供を念頭に置いている。この定義の違いは、どのデータを公開するかという結論に直結し、定義２の方が定義
１よりも多くの情報を提供する必要が出てくる。そういう意味では、ここでも「プライバシー擁護派（定義１支持派）」対「情報公開派（定義２支持派）」の戦いが生じているという見方もできよう。
結局 2006 年 4 月に、コンセンサスに至らぬまま多数決で GNSO は定義１を採択した。
その後この定義１に基づいて、WHOIS サービスに関する課題報告書の検討が行われ、2007
年 3 月 12 日に、WHOIS サービスに関する最終報告書が GNSO 評議会に提出されるに至った。この最終報告書の内容を要約すると、以下の通りである。
WHOIS タスクフォースは以下についてコンセンサスを得た。
登録者の多くが、WHOIS 上の連絡先の違いについてその意味や目的を理解していない。（経理担当者、運用責任者、技術連絡担当者）
WHOIS サービスに関して変更を行う際は、認知向上が必要となる。
一部の連絡先情報は公開対象から外す新しいメカニズムを、プライバシー保護の観点に立って採用すべきである。
WHOIS タスクフォースによる以下のポリシー勧告は、特別過半数での採択はされず、単純過半数での採択となった。支持したのは、レジストリ部会、レジストラ部会、非商用ユー
ザ部会、指名委員会指名委員、および、At-Large のリエゾンである。
[ポリシー勧告]「運用上の連絡先（OPoC = Operational Point of Contact）」という項目を新たに作成し、現在の WHOIS 上の連絡先である運用責任者、技術連絡担当者に代える。この運用上の連絡先に登録された人（組織）が、実際の登録者に連絡を取る。
この WHOIS タスクフォースの最終報告書をもとに、2007 年の第 1 四半期もしくは第 2 四
半期に GNSO 評議会が検討を行い、ICANN 理事会に対して何らかのポリシー勧告を行うものとされた。

209

2-3-3 2007 年 4 月以降の議論
WHOIS タスクフォースの最終報告書をもとに、2007 年の第 1 四半期もしくは第 2 四半期に GNSO 評議会が ICANN 理事会に対して何らかのポリシー提案を行うことで一旦は合意に至った WHOIS の議論だったが、その後も議論は紆余曲折を辿ることとなる。以下に時系列順にどのような動きがあったのかを見ていく。
WHOIS に関する作業部会（ワーキンググループ）の立ち上げ、検討作業
GNSO 評議会は WHOIS に関する検討を行う作業部会を立ち上げ、まずは作業部会の取り扱う範囲について議論した。2007 年 4 月 12 日の GNSO 評議会会議において作業部会のチャーターは承認され、作業がスタートすることとなった。このとき合意された作業部会のチャーターの概要は以下の通りである。
「作業部会の目的は、WHOIS タスクフォース最終報告書中で指摘された課題を分析し、それらの問題に関するポリシー勧告（つまり OPoC 項目の提案）をどのように向上させられるかについて勧告を行うことである」
作業部会はその後 2007 年 6 月 21 日付けで報告書のドラフト初版を公開した。そのドラフトをもとに 2007 年 6 月のICANNサンファン会議での議論を経て、その後も細かい議論を経て報告書を改版していくこととなった。主な論点は、OPoC（運用上の連絡先）の役割や責任の明確化、公開されていないデータへのアクセスをどのように許可するか、WHOISデータの表示項目、表示方法等であった。当初 7 月下旬を目標に最終報告書をまとめる予定だったものが大幅に作業が遅れ、最終報告書44が提出されたのは結局 2007 年 8 月 20 日となった。最終報告書の概要を以下に示す。
[背景]
WHOIS 作業部会において検討した事項は以下の 3 項目である。
(1) OPoC（運用上の連絡先）の役割、責任、要件を分析し、それらが満たされなかった場
合には何が起こるか。
(2) どのような正当性があれば、公開されていない登録データへのアクセスが許容されるか。
(3) 連絡先情報の公開は、登録者の性質によって（法人/自然人）決まるのか、登録者のド

44 http://www.gnso.icann.org/drafts/icann-whois-wg-report-final-1-9.pdf

210メイン名利用によって決まるのかを分析する。
[項目(1)についての検討 – OPoC の役割]
OPoC の役割は、ある要請が存在するとき、その要請を登録者に適宜伝えることであり、実装上何らかの要件を満たしていなければならない。また、犯罪の正当な証拠がある場合やWHOIS の登録データが間違っているという正当な証拠がある場合、予め定めた期間中に連絡を取ることができなかった場合において、自然人に関する非公開情報を適宜開示することも OPoC の役割である。3 番目の役割として、登録者の同意がある場合に登録状況の改善策を決定し実施する、というものがあるが、これには反対意見もある。
[OPoC の特徴と要件]
OPoC は 2 人まで指名することができること、OPoC には登録者、レジストラ、もしくは登録者が指名する第三者がその任にあたることができること、全ての登録者（法人か自然人
かを問わず）は OPoC を指名しなければならないことについては作業部会内での合意が取れた。また、OPoC は登録者と合意に基づいた関係を構築していなければならない。
OPoC を実装することによって、現在 WHOIS で表示している連絡先情報が簡素化できる
ことについても作業部会内での合意が取れた。
一方、OPoC が正しく運用されているかの検証を行うべきかについては合意が取れていな
い。電子メールが正しく登録されているかの検証を行うことについては支持する声がある
ものの、レジストラや登録者に負担を強いるという理由から反対を表明する声も大きい。
[OPoC の要件が満たされない場合に何が起こるかの分析]
OPoC が正しく機能しない場合に、何らかの要請を行いたい者は直接レジストラへ連絡する
こ とになるだろうということについては作業部会の合意を得た。その場合の懸念点や、
OPoC が機能しない場合のコストを誰が負担するべきかについては合意が得られなかった。
[項目(2)についての検討 - 公開されていない登録データへのアクセス]
法執行機関は非公開データについて項目を指定したアクセス、及び指定しないアクセスの両方が必要であること、民間においては非公開データへの項目を指定したアクセスが必要であることについては作業部会の合意を得た。レジストラがそのようなアクセスを認める
場合の課金の妥当性についても議論し、課金しても良いという結論を出した。ただしこの結論には異論もある。
非公開データへのアクセスを認めるにあたって認証システムが必要かどうかについても議論となった。こうした認証は手続の遅れとコストを伴うという懸念がある。作業部会は認211

証方式については今後の検討に委ねるべきという結論を出した。
[項目(3)についての検討 - 連絡先情報の公開]
登録者が自然人の場合 WHOIS の表示項目は制限されるべきであり、法人の場合はそうした制限は必要ないということに関し、作業部会の合意を得た。作業部会としては、ドメイン名の利用によって表示項目を変えるのは難しいと感じている。
[実現可能性の検討]
作業部会のメンバーは、いくつかの問題については技術的にも法的にも不明確な点が多く解決することは難しいということを理解した。本報告書では、OPoC 提案を実施するに当たって発生するであろうコスト分析、OPoC がプライバシーに与える影響の検討、認証メカニ
ズムの検討、gTLD 登録者や登録状況の分析、WHOIS データの利用及び不正使用の分析など、様々な検討を行うべきであると提案している。

GNSO 評議会はこの最終報告書を受けて議論を行ったが、いくつかの項目に関してコンセンサスに至っていないということもあり、2007 年 9 月 6 日の GNSO 評議会会議では「現時点では WHOIS およびそれに関連するポリシー勧告は行わない」という決議を採択した。
また、この会議において ICANN スタッフが今までの WHOIS に関するプロセスの概要をまとめた報告書を 9 月 13 日までに作成し、GNSO の各部会へ送付することとなった。
この時点で GNSO 評議会内部では、WHOIS に関するポリシー策定プロセスのその後に関する決議案が 3 つ提出されていた。1 つは「OPoC 提案を支持し、ICANN スタッフに実施のための検討を要請する」もの、2 つめは「OPoC 提案をさらに検討し、ICANN スタッフに 90 日以内に検討報告書の提出を要請する。その検討報告書をもとに、OPoC 提案の採否を検討する」というものであった。3 つめは「コンセンサスが GNSO 内で得られないことから、WHOIS に関するポリシー策定プロセスはポリシー勧告を行うことなく終了する」というものである。
9 月 13 日に公開されたICANNスタッフによる報告書45には上記のGNSO評議会決議案も掲載され、2007 年 10 月 30 日までのパブリックコメントに付されることとなった。その後
10 月 11 日に上記報告書が更新46され、同日にはICANNスタッフによりOPoC提案実施の実現可能性検討レポートも公開47された。GNSO評議会の要請に応じて作成されたレポートで

45 http://www.gnso.icann.org/drafts/icann-staff-overview-whois13sep07.pdf
46 http://www.gnso.icann.org/drafts/icann-staff-overview-of-whois11oct07.pdf

47 http://www.gnso.icann.org/drafts/gnso-whoiswg-report-staff-implementation-notes-11oct07.pdf

212

あったが、GNSO評議会側の検討依頼事項が具体性に欠けるものであるため更なる詳細な指示が必要、とする項目が散見される内容であった。コメント期間終了後、ICANNスタッ
フがパブリックコメントの要約を行った48が、それによると 238 のコメントが寄せられ、そのうち 223 が 2 つめの決議案「OPoC提案をさらに検討し、ICANNスタッフに 90 日以内に検討報告書の提出を要請する。その検討報告書をもとに、OPoC提案の採否を検討する」を支持し、現段階でのOPoC実装には反対するものであった。OPoC提案を支持する意見は 13であった。
これを受け開催された 2007 年 10 月 31 日のGNSO評議会では、2 つめの決議案をもとに以下の決議49が採択された。
[決議要約](1) この 4 年間 WHOIS ポリシーの検討に携わってきた全ての関係者に感謝する。
(2) gTLD WHOIS に関するポリシー策定プロセスは、いかなるポリシー変更勧告を
ICANN 理事会に対して行うことなく、正式に終了する。
(3) 自然人に対するプライバシー保護の手段確保、権利執行機関によるデータへの法的アク
セス、消費者保護、法執行機関や犯罪対策目的など、将来のポリシー策定プロセスの必要性を認識し、以下のような一連の行動を開始する。
評議会はデータの収集や要件の検討に関するさらなる定義づけを行う
スタッフは評議会に対し、これらのデータ収集等にかかる概算コスト見積を 2008
年 2 月 15 日までに行う
評議会はどのようなデータ収集や検討が必要かを検討する
スタッフはデータ収集、検討を行い、その結果を評議会へ報告する(4) 上記データ収集および検討が完了し、その結果次第ではこの分野に関するポリシー策定
活動を開始する。

こうして、ここ 4 年間にわたり続けられてきた WHOIS に関するポリシー策定プロセスは、
何らのポリシー勧告を行うことなく、一旦終了した。しかし上記の決議を見ても分かると
おり、WHOIS に関する課題は解決されておらず、近い将来に新たなポリシー策定活動が必要とされるであろうと想定されており、情報収集、実情調査の内容によっては、新たなポリシー策定活動を開始する可能性も残してはいる。
その後GNSO評議会は 2008 年 1 月 8 日に、今後のWHOISに関するポリシー検討にあたっ
48 http://gnso.icann.org/issues/whois-privacy/whois-comments-summary-30oct07.pdf
49

決議原文はhttp://gnso.icann.org/resolutions/#200710 の 20071031-3 を参照。

213

てどういう項目が検討されるべきか、パブリックコメントの募集を開始した50。パブリック
コメント期間は 2008 年 2 月 15 日までであった。パブリックコメント期間終了後、その要約がICANNスタッフによって作成され、公開51されている。これによると、検討すべきであると提案された事項が 7 項目あった。以下に列挙する。
WHOIS の不正使用の実態調査
各種のデータ保護法、およびレジストラ認定契約のコンプライアンス調査
現在提供されている WHOIS プライバシー保護サービスの実態調査
WHOIS プライバシー保護サービスの需要調査
犯罪や迷惑行為が発生した場合の、WHOIS データ保護が与える影響調査
レジストラが法執行機関の要請や紛争処理要請に応えているかの調査
WHOIS データがどれくらい正確なものかの調査
GNSO 評議会は今後これらのコメントをもとに、どの調査を行うかを検討していくとしている。（2008 年 2 月現在）
ICANN による WHOIS 問題への取り組み
GNSO による WHOIS 問題とは独立し、ICANN は WHOIS の正確性向上のための方策を検討している。2007 年 4 月 27 日には、ICANN は「WHOIS データの正確性と有効性のためのプログラム」を開始した。このプログラムは、gTLD レジストラによる WHOIS のコ
ンプライアンスを改善し、WHOIS の正確性を向上させることを目的とするものであり、2007 年度においても ICANN が WHOIS の提供に関し、監査を行う予定であることを明らかにした。
その後 2007 年 12 月 21 日には、ICANNはWHOISの正確性向上に関し、4 つのアップデー
トがあると発表 52 した。これによると、ICANNはWHOISデータの正確性に関する調査を2007 年 11 月に開始し、調査結果は 2008 年 2 月を目処に公開予定であること、WHOISデータリマインダポリシー（WDRP）がICANN認定レジストラにおいて遵守されているかど
うかの調査を行い、結果を 2008 年 2 月に報告する予定であること、WDRPに基づいてデータの誤りが判明した際の修正手続が遵守されているかも調査しており、これも 2008 年 2 月に結果を報告する予定であること、WHOISサービスについても適切に運用されているかど
うかの調査を行っており、同様に 2008 年 2 月を目処に調査結果を公開予定であるというこ

50 http://www.icann.org/announcements/announcement-08jan08.htm
51 http://gnso.icann.org/issues/whois-privacy/whois-study-suggestion-report-25feb08.pdf
52 http://www.icann.org/announcements/announcement-2-21dec07.htm

214

とである。（ただし、2008 年 2 月末現在ではまだこれらの調査結果は公開されていない。）
こうした中、一部のレジストリがWHOISのポリシーを独自に変更する動きも出てきた。.telのレジストリであるTELNICは、WHOISサービスに関する変更を要請してきており、2007
年 12 月 18 日のICANN理事会53において、個別の変更が承認された。内容は以下の通りである。
TELNIC は、WHOIS サービス提供にあたり、自然人と法人とを区別する。
自然人は、個人情報を一般公開することを拒否することができる。
自然人が個人情報の公開を拒否した場合、以下の情報が一般公開される。
ドメイン名、ドメイン名 ID、レジストラ、レジストラ IANA ID、ドメイン名
登録状態、登録者 ID、登録者名称、ネームサーバ、登録者による情報更新日、レジストラによる更新日、ドメイン名登録日、ドメイン名登録期限日、ドメ
イン名最終更新日
自然人の個人情報にアクセスするために「特別アクセスサービス」を用意するが、これを利用するには正当な理由が必要となる。
「特別アクセスサービス」を利用するには、申請者は Web 上のフォームを記入すれば良い。記入すれば、そのサービスのアクセスできる URL が郵便で送付される。
アクセスは 24 時間以内に 5 回までという制限がある。
TELNIC の WHOIS サービス変更は、GNSO におけるポリシー策定プロセスとは独立した
個別の動きであるが、今後の議論の参考とされる可能性がある。
一旦は終了した WHOIS に関するポリシー策定プロセスであるが、引き続き実態調査や様々な検討が行われており、完全に WHOIS に関する議論が消えてしまったわけではない。
WHOIS は一般社会のルールとは若干違い、原則は登録者の情報を公開するという運用がなされていることもあり、今後も様々な形で議論が巻き起こることは想像に難くないが、合意に達することが非常に難しいことは過去の議論が証明している。WHOIS に関する議論の中では「WHOIS の提供目的さえ合意できないのであれば、レジストリ契約や認定レジスト
ラ契約から、WHOIS に関する規定を削除すべきではないか」という激しい意見まで飛び出したこともあり、今後も引き続き注目されるテーマであることは確かであろう。

53 http://www.icann.org/minutes/minutes-18dec07.htmの「Discussion of .TEL Contractual

Amendment」参照。

215

2-4 ドメイン名テイスティングに関する議論の動向
ドメイン名テイスティングについて
ドメイン名そのものを利益を上げるための商品として捉えるドメイン名売買やサイバース
クワッティングなどとは異なり、最近はドメイン名を利用してそこから派生する利益を得ることを目的とした行動がしばしば見受けられるようになっている。よくある例としては、大量のアクセスが見込めるドメイン名を登録し、そのドメイン名を用いて Web サイトを立ち上げ、その Web サイトにオンライン広告を掲載することなどにより、そこから一定の収入を得ようとすることが挙げられる。
もちろん、いわゆる「良いドメイン名」を登録し、それを用いて合法的に利益を上げること自体には特段責められるいわれはない。しかしながら、現在の状況においては、その「良いドメイン名」を選定・入手するためにインターネット全体に対して過度の負担をかける行為が行われており、そのような行為が非常に問題とされている。このような行為の代表的なものが「ドメイン名テイスティング」と呼ばれる行為である。
ドメイン名テイスティングとは、「良いドメイン名」＝「大量のアクセス数が見込めるドメ
イン名」を選別するために、まず一度に大量のドメイン名を登録し、そこから一定量のア
クセスがあるドメイン名だけを残し、それ以外のドメイン名は全て廃止するという行為を指す。
もちろん、ただ普通に「登録→廃止」を行っているだけであれば、その件数が大量とはいえ通常の申請とは特段変わりはなく、とりたてて問題視することもないが、現在問題となっているのは、その「登録→廃止」という一連の申請に対して費用負担が必要ないこと、
そして無料であるが故に常軌を逸しているとも言えるほどの大量のドメイン名の登録と廃止が日々繰り返されているからである。
このドメイン名の登録が無料で行える理由は、Add Grace Period(登録猶予期間、AGP)という仕組みが利用されていることによる。この AGP は、本来はドメイン名テイスティングのためにある仕組みではない。ドメイン名が登録された時点から課金されるまでの間に猶予期間を設けることで、ユーザの文字列の入力間違いなどを理由に、意図しないドメイン名が登録される場合でも、ユーザに不利益を与えないようにすることを意図した仕組みである。登録者が新規にドメイン名を登録した後、一定期間内（一般的には 5 日間）にその登録を取り消せば登録料が不要となる。

216ただし、登録者が本当に間違いで登録したのかどうかをレジストラ側が調べる術はなく、その点がトラフィックの多いドメイン名を選別したい一部の個人・業者に目をつけられ、より少ないコストでドメイン名を選別するための道具として利用されることとなってしまった。
一度このような方法が発見されると、それが多くの人間に広まるまでに多くの時間は要さず、2006 年 5 月の統計では 616 のレジストラの内、502 のレジストラでこのような行為が見られるような事態となっている54。ドメイン名テイスティングは、さまざまな混乱や不都合をレジストリやレジストラ、ユーザに与えており、その影響はもはや無視できない規模にまで発展している。
たとえば、これまでも短いドメイン名や英単語として意味を持つドメイン名を闇雲に登録していくという行為は存在したし、極端に短いドメイン名であればそれこそ未登録の空いている文字列全てを対象に機械的に登録していくという行為もあったが、それでもドメイン名の登録に費用が発生するのであれば、かかるコストと得られると予想される利益の関係から、実際に登録される文字列にはやはり一定の限度というものが存在した。しかしながら、ドメイン名の登録に費用が発生しないとなると、システム的な限界まで大量のドメ
イン名の登録を試み、登録した後でトラフィックの量に基づいてゆっくりと「良いドメイン名」を選別するという行為を行う者が出てきたのである。
このような行為は、後述するドロップキャッチと言われる行為にも影響を与えており、ドメイン名の登録に費用が発生するのであれば、ある程度アクセスが見込めるドメイン名しかキャッチの対象にならなかったものが、費用が不要なことから期限切れとなったドメイ
ン名は全て対象とするような風潮となりつつある。
こうした大量の登録はシステムや回線に対して非常に大きい負荷となっており、それらに対応するためのコストを発生させ、レジストリやレジストラに対して負担となっているとともに、結局はそのコストは回り回って一般的なユーザが負担することにもなっている。
また、この一連の選別によって選ばれなかったドメイン名は結局廃止されることになるわ
けだが、その廃止されたドメイン名も今度は別の人間のドロップキャッチの対象となるな
どして、そのドメイン名は短期間に登録と廃止が繰り返えされることなる。これはそのドメイン名を普通に登録したいユーザにとっては非常に迷惑な話であり、登録可能な状態となっているかどうか調べようと WHOIS などを使って検索しても、数日おきにドメイン名

54 ICANN Meetings in Marrakech, Morocco

Domain Name Marketplace Workshop
http://icann.org/meetings/marrakech/captioning-dn-27jun06.htm

217

の状態が変化しているというわかりにくい状況となってしまう。一方、レジストリやレジ
ストラにとっても、システム的な負荷やコスト負担だけでなく、一般ユーザからの問い合
わせ等が増えることも予想され、それらに対応するための余計な人員やコストがさらに必要となるなど、多くの関係者にマイナスの影響を与えている。
ドメイン名のドロップキャッチについて
ドメイン名テイスティングと並んで問題となっている「ドロップキャッチ」と呼ばれる行
為は、ドメイン名テイスティングが登録の際に行われるのに対して、廃止時に行われている行為である。
ドロップキャッチとは、文字通り期限切れなどで廃止される（ドロップする）ドメイン名を登録（キャッチ）する行為である。現登録者が使わなくなりその登録者の意志に基づいて廃止されるドメイン名を新しい登録者が登録するというパターンもあれば、現登録者が登録期限を忘れていてうっかり廃止されてしまった場合のように、登録者の意志に反して廃止されたドメイン名をいわば横取りするようなパターンもある。
このように廃止されるドメイン名が注目されるのには、それなりの理由がある。それは廃止されたドメイン名は過去に Web サイトなどで実際に使われていたドメイン名であることが多く、そのドメイン名を利用して Web サイトを立ち上げれば、従来の Web サイトのユー
ザなどがそのまま勘違いしてアクセスしてきてくれるなど、ある程度のアクセス数が見込
める可能性が非常に高いからである。これは Web サイトなどに掲載したオンライン広告などで利益をあげることを目的とする人間にとっては大きなメリットである。なぜなら、ドメイン名の登録料や維持料は使用歴のあるドメイン名も無いドメイン名も同じであり、同じコストを払って登録するのであれば、そこから得られる利益が大きいと予想される方がより有利だからである。
このドロップキャッチという行為は、従来からもそれなりの頻度で見受けられる行為であったが、前述した AGP という仕組みにより、ドロップキャッチしたドメイン名を数日の内に選別し、アクセス数の見込めないドメイン名は手放してしまえば余計な登録料が発生しないという状況となったため、現在では「登録期限切れで廃止されたドメイン名は全て登録対象とする」というような状況となりつつある。
このような状況により、従来であればそれほど大規模なサイトなどで使っていたドメイン
名ではなく、また文字列もある程度特異性のあるものであれば、仮にドメイン名を期限切
れで取り消されてしまっても再登録可能になるのを待って登録し直すという行為が可能で218

あったが、現在ではほぼ全てのドメイン名において、一度期限切れなどで廃止されてしま
うと、RGP55（Redemption Grace Period：削除済ドメイン名のための「請戻猶予期間」）
を利用すること無しに再び自分の手に取り戻すことはほぼ不可能な状況になりつつある。
ICANN マラケシュ会議での議論（2006 年 6 月）
このように大きな問題となっているドメイン名テイスティングやドロップキャッチという行為については、近年のICANN会議でも大きな問題として取り上げられており、2006 年 6月にモロッコで行われたICANNマラケシュ会議では、この問題を特別に話し合うためのド
メイン名マーケットプレイスワークショップ56が開かれるまでになった。
このドメイン名マーケットプレイスワークショップでは、ドメイン名テイスティングやド
ロップキャッチの概要説明や、ドメイン名の登録から期限切れを経て登録削除に至るまでのサイクルにおいてどのような行為が行われているかの解説が行われた。
会合に出席したパネリストからは、一部の登録者によるドメイン名テイスティングなどの行為が、多くの一般的な顧客に対して大きな影響を与えるとともに混乱を生じさせており、それらの顧客に対応するためのレジストラのサポートコストの増大に繋がっているという意見や、AGP が本来の意図に反した使い方をされていることは明らかであり廃止を検討す
べきではないかという意見などが発表された。また一方では、現状起こっていることこそがマーケットのニーズであり、闇雲に排除をするのではなく、早急にポリシー策定プロセスの対象としてルール作りを進めるべきではないかという意見も出た。さらに、レジスト
リ側からは、ドロップキャッチなどではキャッチを試みるコマンドが大量にレジストリ側のシステムに対して発行されていて、それがレジストリに過大な負荷を与えている現状などが説明された。
このような議論を経て、ドメイン名マーケットプレイスに関する問題については継続的に議論していくことが確認され、以降の ICANN 会議においても引き続きこのドメイン名マー
ケットプレイスにおける問題について議論されることとなった。

55削除済ドメイン名のための「請戻猶予期間」
http://www.nic.ad.jp/ja/dom/gtld-policy/rgp.html
56 ICANN Meetings in Marrakech, Morocco
Domain Name Marketplace Workshop
http://www.icann.org/meetings/marrakech/captioning-dn-27jun06.htm

219

ICANN サンパウロ会議での議論（2006 年 12 月）
このマラケシュ会議の次に行われた、2006 年 12 月のブラジル・サンパウロ会議においてもドメイン名マーケットプレイスワークショップが開催され57、現在の状況についてアップ
デート報告がなされるともに、特にAGPに絞って集中的に議論が行われた。この会合では、AGPの見直しを求めるコメントが多数寄せられ、ALACの要請によりICANNスタッフがイ
シューレポートを提出することになった。
ICANN サンファン会議での議論（2007 年 6 月）
2007 年 6 月 14 日に、ICANNスタッフよりイシューレポート58が提出され、それに基づきサンファン会議で議論が行われた。
イシューレポート内では、ICANN スタッフや法律顧問が多面的に検討した結果、ドメイン
名テイスティングに関する問題は ICANN のポリシープロセスや GNSO のスコープの範囲内にあるものであると考え、GNSO で PDP を開始すべきであると勧告している。また、
PDP を開始する前には、さらなる事実調査を行うことや、PDP 以外にも解決方法がないか検討するようにも伝えている。
GNSO 評議会では、GNSO メンバーと ICANN スタッフでアドホックグループを結成し、ドメイン名テイスティングについてさらなる情報収集を行うこととした。また、その結果により PDP を開始すべきかを判断することとなった。
アドホックグループは、事実に基づくデータ収集を行うために、2007 年 8 月 10 日から 9
月 15 日までドメイン名テイスティングに関する情報要請（Request for Information, RFI）
59を行い、知的財産部会もRFIを同時に行った。情報要請に対して寄せられた内容を反映したレポートは、10 月 4 日までに提出することがGNSOで決定された。

57 ICANN Meetings in São Paulo, Brazil

Captioning - Domain Name Marketplace Workshop
http://www.icann.org/meetings/saopaulo/captioning-dnmarket-06dec06.htm
58 GNSO Issues Report on Domain Tasting – English
http://gnso.icann.org/issues/domain-tasting/gnso-domain-tasting-report-14jun07.pdf
59 Request for Information on Domain Tasting
http://www.icann.org/announcements/announcement-2-10aug07.htm

220

ICANN ロサンゼルス会議での議論（2007 年 10〜11 月）
RFIには約 220 の回答が寄せられ、それらをまとめたアドホックグループの報告書60が 10
月 4 日に提出された。
RFI への回答は、大半が知的所有権者とドメイン名登録者からのもので、ドメイン名テイ
スティングは利益よりもはるかに不利益をもたらすものであると明確に主張する内容となっている。ドメイン名テイスティングを減らす手段については、他の提案もあったが、回答者の多くが AGP を廃止することに肯定的であった。回答者の大半が、無料でドメイン名を登録できてしまうことがドメイン名テイスティングを助長すると考えており、また登録に対して ICANN がミニマムチャージを課すべきとも考えているが、中にはミニマムチャー
ジの課金は ICANN の権限を越えるものであると考える者もあった。
報告書には、レジストリが ICANN に提出する月次レポートのデータのうち、ドメイン名テイスティングが最も行われている.com と.net の登録ドメイン数と削除ドメイン数のグラフも掲載されている。このグラフからは、登録ドメイン数はほぼ一定のペースで増加していることが分かる。それに比して、削除されるドメイン名については、2005 年 1 月ごろまでは登録されるドメイン数に対して微々たる割合であったが、それ以降急激に増加し、2007
年 3 月時点では登録ドメイン数 7,300 万件前後に対し削除されるドメイン数が 6,000 万件に届きそうな勢いにまで伸びていることが分かる。
アドホックグループは、RFI や情報収集で得られた結果を報告書内で客観的に報告するとともに、GNSO からの要請に基づき、PDP を行う際の評価委任事項（Terms of Reference,
ToR）のドラフトも掲載している。ドラフト ToR の内容は次の通りである。
1.

ドメイン名テイスティングとして認識されるすべての行為の影響を見直し評価する
こと

2.

ドメイン名テイスティングがもたらす影響を鑑み、ドメイン名テイスティングを防ぐための手段を導入することが正当化できるかどうか判断すること3.

上記 2.に対する回答が肯定的なものであるならば、様々な手段が各部会にもたらす
潜在的インパクトを考慮し、ドメイン名テイスティングを防ぐための手段を提案すること

以上の内容をもとに、ICANN ロサンゼルス会議における GNSO 評議会にて検討した結果、

60 Outcomes Report of the GNSO ad hoc group on Domain Tasting
http://gnso.icann.org/drafts/gnso-domain-tasting-adhoc-outcomes-report-final.pdf

221

ドメイン名テイスティングに関する PDP を開始することが決議された。また、GNSO 評議
会は、AGP の期間中に登録と削除が行われるドメイン名についても課金する料金体系とす
るよう、ICANN スタッフに勧告した。
ICANN ニューデリー会議での議論（2008 年 2 月）
2008 年 1 月 7 日には、ICANNスタッフより初回レポート61が提出され、1 月 28 日までパブリックコメントに付された。本レポートには、ドメイン名テイスティングにまつわるこれまでの内容のまとめの他、GNSO内の各部会から寄せられたドメイン名テイスティングに関する声明文が含まれている。声明の内容は部会により多岐にわたるものの、ドメイン
名テイスティングを減らすための手段を講じるべきであるという点についてはコンセンサ
スが得られている。
また、ロサンゼルス会議におけるGNSOの勧告に対応して、2008 年 1 月 29 日には、ICANN
理事会からの勧告62が公開された。2008 年 7 月 1 日から始まる新年度予算より、ドメイン名が登録されたらすぐに課金するよう提案するものであり、ドメイン名テイスティングの廃止に向けて理事会が大きく動き出したことが見て取れる内容である。
ニューデリー会議の議論においても、ドメイン名テイスティングは否定的に捉えられるのが趨勢であったと言える。しかしながら、登録時の誤入力の修正といった本来の目的に AGPを利用する登録者も依然として存在すると考えられるため、「ドメイン名テイスティングの防止＝AGP の廃止」と結びつけるのはいささか早計との意見も上がった。そこで、GNSO
としては AGP 期間中における一定割合の削除件数を許容した上で、それ以外の登録に課金することと、レジストラ認定契約内の AGP に関する条項の修正を理事会に提案しようとしていることが伝えられた。
ドメイン名テイスティングに関する議論に呼応するように、.biz のレジストリである
NewStar と.info のレジストリである Afilias より、レジストリ契約内の AGP に関する条件の修正案が 2 月 5 日に提出され、2 月 28 日にパブリックコメントに付された。両社とも別々に修正案を提出しているが、内容は似通ったものである。AGP 期間中に削除されるドメイ
ン名のうち、課金が猶予されるドメイン数の上限を設定しており、月に 50 件もしくはレジ
ストラにおける月の新規登録数の 10%のうちどちらか大きい方を上限とすることを提案している。レジストラが AGP 期間中に削除するドメイン数に制限は設けられないが、月締め
61 GNSO Initial Report on Domain Tasting

http://www.icann.org/announcements/announcement-07jan08.htm
62 ICANN Board Recommends Action on Domain Tasting
http://www.icann.org/announcements/announcement-29jan08.htm

222

の時点で、上限を超える数のドメイン名すべてに対して課金されることになる。ICANN は、
この修正案がインターネットの安定性・安全性や競争原理に対して重大な問題を引き起こすことはないと判断しており、パブリックコメント期間が終わる 3 月 26 日以降に ICANN
より修正案が提出されて再びパブリックコメントが行われ、理事会へと持ち込まれることになる。
2008 年 6 月に予定されているパリ会議では、理事会にて新年度予算が審議されるため、理事会提案が反映されるかどうか気になるところである。また、NewStar と Afilias からの修正案などを含め、2008 年度のドメイン名テイスティングに関する議論の進展が期待される。

2-5 ドメイン名のフロントランニングに関する議論の動向
あるドメイン名を登録しようとする場合、そのドメイン名が登録可能かどうかを確認する
ために、WHOIS 等を利用して検索することが考えられる。未登録の状態、つまり登録可能な状態であることが確認でき、実際にそのドメイン名を登録することに決めれば、登録手
続きへと進むことになり、場合によっては、多少の時間をおいてから改めて登録手続きを行うこともあるだろう。ところが、WHOIS 等で確認した時点で直ぐに登録せず、時間をおいてから登録しようとすると、少し前まで未登録であったドメイン名が既に登録済みの状態に変わっていた、という場面に遭遇したケースを時折耳にする。
ドメイン名の登録を考えているユーザがそのようなケースに直面すれば、これまで登録されていなかったドメイン名が、ステータスの確認後に直ちに登録されてしまうのは、WHOIS 等で検索したことがきっかけとなっているのではないか、と疑念を持つことも不思議ではない。WHOIS 等で検索した情報がモニタリングされ、その情報を利用してサイバー
スクワッティング等の不正の目的を伴う行為を企てる第三者によりドメイン名が登録されたのではないかと考えられてしまうことも無理はない。
WHOIS 等で検索した情報が利用され、他人が登録しそうなドメイン名が先回りして登録されていると疑われているこれらのケースは、ドメイン名の横取り（domain name grabbing）
や先行予約（preemptive registration）と呼ばれ、クレームとして ICANN、レジストラ、
知的財産を専門とする弁護士に対しある程度の頻度で寄せられていたようである。
SSACとしては、これらのケースが行われているという確証はないものの、コミュニティ内にそのような疑念が存在するという事実を鑑み、事前研究およびコミュニティへの問題提223

起のために、2007 年 10 月に勧告書63を提出した。勧告書では、ドメイン名が先回りして登録される状況が証券取引の世界で言われるフロントランニングの状況と似ていることから、それになぞらえドメイン名フロントランニング（domain name front running）と呼ぶこととしている。
ドメイン名フロントランニングが行われる理由としては、インターネットユーザが関心をもつドメイン名をペイパークリックサイトに使って、ユーザをおびき寄せ広告費を稼ぐ目的であったり、ドメイン名の商品価値に目をつけセカンダリマーケットで売ることなどが考えられている。また、ドメイン名フロントランニングと思われても、実はドメイン名テイスティングの結果として、ドメイン名が登録されてしまっているとも考えうるという。
ドメイン名フロントランニングがどのようにして行われるのかについては、DNS 運用者、
レジストリ、レジストラ、リセラが行っていることも考えうるし、現状では WHOIS で検索された情報を外部に提供することが禁止されていないため、ドメイン名フロントランニ
ングを行う者（勧告書では、ドメイン名フロントランナーと呼んでいる）に売っていることも考えられるとしている。その他にも数例が挙げられているが、いずれも考えうるものを検討のための例示として記しているもので、この限りではないと考えられるし、例示したものがドメイン名フロントランニングの方法として利用されていると明言しているわけでもない。
SSAC としては、ドメイン名テイスティングが行われている事実があると断言することは避けているものの、苦情が寄せられたり疑念を持たれているという状況は、ドメイン名事業に対する信頼感を失わせているとしている。また、WHOIS 等を用いて希望するドメイン名を確認することは、そのドメイン名に関心があるということを第三者に知らせてしまう可能性につながるため、慎重に行うよう忠告している。この時点では、WHOIS 等の検索情報をモニタリングすることが容認されるものかそうでないかを結論付けるだけの状況証拠などを持ち合わせていないため、次の 10 項目を掲げ事例報告を呼びかけ勧告書の結びとしている。
・

ドメイン名が登録可能であるかを確認した方法（例：ウェブブラウザ、アプリケ
ーション）

・

利用している ISP

・

ドメイン名の確認サービスを提供するプロバイダもしくは運用者

・

ドメイン名が登録可能であるかを確認した日時

63 SAC 022 SSAC Advisory on Domain Name Front Running

http://www.icann.org/committees/security/sac022.pdf

224

・

ドメイン名が登録可能であるかを確認した際の回答（例：WHOIS クエリへのレスポンス）の写し・

ドメイン名が登録可能であるかを確認した際の回答に、当該ドメイン名がこれまでに登録されたことがある、もしくは登録されていないと記されていたか・

これまでに当該ドメイン名が登録されていたことを伝える回答（例：WHOIS クエ
リへのレスポンス）の写し

・

ドメイン名フロントランナーと思しき者との通信内容の写し

・レジストラもしくはドメイン名の確認サービスを提供する業者との通信内容

・

ドメイン名の確認サービスを提供する業者とドメイン名を先取りした者とが関係していると思われることが分かる情報

事例報告の呼びかけに対しては、2007 年 10 月 20 日から 2008 年 1 月 5 日までの間に約 170の回答があり、そのうちの 120 件はドメイン名フロントランニングに関係する内容であったという。これらの回答を分析した結果として、2008 年 2 月にSSACから報告書64が提出された。
回答の分析にあたり、SSAC メンバーは、情報が不十分と思われる点については回答者に追って確認した上で、WHOIS やドメイン名登録情報を確認し、ウェブホスティングの履歴等も検証した。しかしながら、やはりこの段階でも、ドメイン名の確認サービスを提供する業者による何かしらの手段によりドメイン名フロントランニングが行われていると結論付
けるには情報が乏しいとしている。ただ、ドメイン名フロントランニングは行われている
かもしれないが、その証拠を捉えることは難しいとしつつも、その可能性が疑われている
ことはコミュニティがドメイン名登録のプロセスの中で感じる不満の表明と認識できることにも触れている。
回答結果からは、ドメイン名登録プロセスやそこに関係するマーケットが、インターネッ
トユーザの理解を超えて複雑なものとなっている現状が浮かび上がっている。平均的なエ
ンドユーザにとってはドメイン名フロントランニング、ドメイン名ハイジャック、ドメイ
ン名テイスティング等が意味するところの違いを区別できず、それがゆえに登録プロセスは信頼できないものであるという印象を与えているとしている。ドメイン名登録に関わる業者は、ドメイン名登録に関わってくる様々な事柄についてユーザへ啓蒙したり、業界特有の専門用語の使用をできるだけ控えるよう勧告している。また、ユーザは、ドメイン名のキャンセル待ちサービスを使えば、希望するドメイン名が期限切れとなり更新されないと、変わりに登録してくれるはずと思い込んでいるので、そのようなサービスを提供する

64 Report on Domain Name Front Running
http://www.icann.org/committees/security/sac024.pdf

225レジストラやリセラはユーザの誤解を正す手段を講じるよう勧告している。
また、レジストラやリセラとドメイン名登録のための手続きを進める際には、登録者からすれば、契約に明示されていようとなかろうと、一連の手続きに関係する情報が断りもな
しに第三者に公開されることなどないだろうし、ましてや登録者が費用を負担して提供した情報が、レジストラやリセラ自身のために使われることもないと考えるはずである。このようなことを業者が行うとしたら、ユーザとの信頼関係を破ることとなり、また登録者が費用を負担して提供した情報を利用して業者がドメイン名市場において優位性を獲得しようとすれば、さらに事態を悪化させることになると危惧している。登録者とレジストラとの信頼関係が損なわれつつある状況を SSAC は感じており、ICANN やコミュニティは登録プロセスにおける信頼関係の喪失について検討すべきであると勧告している。また、レジストラは、ドメイン名の登録可否が検索された際の情報をどのように扱うかについての注意事項を、ユーザに対して明確に伝えるべきと勧告している。
ドメイン名の登録可否が検索され登録されれば、他者がそのドメイン名に関心を持つ可能性も高くなる。そこで、ドメイン名の登録可否を検索し登録した登録者は、そのドメイン
名を大切に思うならばなおさら、ドメイン名をチェックし登録する際に得られる次の情報を記録しておくべきであるとしている。
・

ドメイン名が登録可能であるかを確認した方法（例：ウェブブラウザ、アプリケ
ーション）

・

利用している ISP

・

ドメイン名の確認サービスを提供するプロバイダもしくは運用者

・

ドメイン名が登録可能であるかを確認した日時

・

メイン名が登録可能であるかを確認した際の回答（例：WHOIS クエリへのレスポ
ンス）の写し・

メイン名が登録可能であるかを確認した際の回答に、当該ドメイン名がこれまでに登録されたことがある、もしくは登録されていないと記されていたか・

これまでに当該ドメイン名が登録されていたことを伝える回答（例：WHOIS クエ
リへのレスポンス）の写し

・

レジストラもしくはドメイン名の確認サービスを提供する業者との通信内容

また、登録しているドメイン名が登録期限を越えてしまうと、そのドメイン名を登録していたレジストラで更新手続きを取るか、失効させるかのどちらかの方法しかなくなるので、登録しているドメイン名を失うと困る場合には、登録期限を迎えるまえに前もって対処す

226

るよう注意を喚起している。65
なお、同報告書の冒頭の注記には、Network Solutions 社(NSI) が 2008 年 1 月 8 日に導入したドメイン名登録サービスの改定について触れられているが、SSAC の報告書の内容が完成した段階での改定リリースであったため、分析内容に NSI のサービスは含まれていない。
NSI の新内容のサービスでは、ユーザがドメイン名の登録可否を同社のサービスを利用して検索し、登録可能であるものの登録しない場合、NSI がそのドメイン名を 4 日間予約しておくとするものである。NSI としては、これはユーザのためのサービスであり、ドメイ
ン名の登録可否を検索したがためにドメイン名フロントランニングの対象になることがな
いようにするためと説明している。しかしながら、このサービスが果たしてユーザのためのものであるかどうかについては、議論が分かれるところであるとしている。
.info のレジストリである Afilias 社は、2008 年 1 月 14 日にプレスリリースを発表し、同社
はドメイン名の登録可否が検索された際のデータを売ったことはなく、.info についてドメ
イン名フロントランニングが行われるている事実を認めない、とドメイン名フロントラン
ニングに反対の姿勢を示していることを伝えている。
ドメイン名フロントランニングについては、議論がはじまったばかりであり、今後の議論の動向が注目される。

2-6 ドメイン名を巡る紛争および紛争処理体制の動向
2-6-1 2007 年におけるドメイン名紛争の概況
登録者と商標権者等との間に起こるドメイン名紛争解決のために、ICANNは 1999 年 10 月にUniform Domain Name Dispute Resolution Policy66（統一ドメイン名紛争処理方針、以下「UDRP」という）及びRules for Uniform Domain Name Dispute Resolution Policy67（統一ドメイン名紛争処理方針のための手続規則、以下「UDRP Rules」という）を採択した。
gTLDおよび一部のccTLDのドメイン名紛争解決のために導入され、今日まで運用されている。

参考文書：SAC 010 Renewal Considerations for Domain Name Registrants
http://www.icann.org/committees/security/renewal-advisory-29jun06.pdf
66 UDRP原文：http://www.icann.org/dndr/udrp/policy.htm
UDRP 日本語訳：http://www.nic.ad.jp/ja/translation/icann/icann-udrp-policy-j.html
67 UDRP Rules原文：http://www.icann.org/dndr/udrp/uniform-rules.htm
UDRP Rules 日本語訳：http://www.nic.ad.jp/ja/translation/icann/icann-udrp-rules-j.html
65227

UDRPに関する申立は、ICANN認定紛争処理機関68で受け付けられる。例年の傾向として、
gTLDのドメイン名に関する紛争の申立先は、World Intellectual Property Organization（WIPO）69のarbitration and mediation center（スイス共和国ジュネーブ）とNational
Arbitration Forum（NAF、米国ミネソタ州ミネアポリス）70の 2 機関に集中している。2006
年においては 2 機関で約 98%を占めていた。2007 年については、UDRPの申立を取り扱う
紛争処理機関が 3 つとなり、もう１つの紛争処理機関であるADNDRCの取り扱い件数がすべて公表されていないため、正確な割合の把握ができない。WIPOとNAFの取り扱い件数を見ると、前年対比でWIPOにおいては約 18%、NAFにおいては約 8%増えており、申立数全体としては 2007 年までの過去数年間は増加傾向にあると言える。
更に、WIPO と NAF の近況より、2007 年における gTLD のドメイン名紛争の概況を確認
してみたい。
WIPOの 2007 年 3 月 12 日付けプレスリリース ”Cybersquatting Remains on the Rise
with Further Risk to Trademarks from New Registration Practices”71 では、サイバース
クワッティングが増加傾向にあると伝えている。サイバースクワッティングとは、不正の目的のためにドメイン名を利用する行為を指し、他人の商標等と同一又は類似のドメイン名を登録し、商標権者に不当に高い額で転売を図ったり、商標権者等の信用を傷つけるウェブサイトのドメイン名として使用する等の行為が例としてあげられる。サイバースクワ
ッティングが増加している理由として、ドメイン名登録の技術的な進歩により、ソフトウ
ェアで期限切れのドメイン名を自動的に拾って登録できるようになったことや、ドメイン
名テイスティングと呼ばれる行為が助長していると指摘している。ドメイン名の自動登録やドメイン名テイスティングは、一度に大量のドメイン名を取り扱うことを可能とするため、第三者が有する商標権等の利益に配慮することなくドメイン名の登録が行われ、正当な利益を有する者を脅かす結果となっている。
本稿を執筆している 2008 年 2 月時点において最新のリリースが確認できないため、WIPO
において確認される最近の傾向を把握できないが、ICANN にてドメイン名テイスティングが問題視され、対応策を検討していくポリシー策定プロセスが開始したことから考えると、この傾向は続いているものと推測される。なお、ドメイン名テイスティングの詳細については、「ドメイン名テイスティングに関する議論の動向」の項にてご確認いただきたい。

68 http://www.icann.org/dndr/udrp/approved-providers.htm
69 http://www.wipo.int/amc/en/domains/
70 http://domains.adrforum.com/

71 http://www.wipo.int/pressroom/en/articles/2007/article_0014.html

228

他方、NAFの 2007 年 5 月 23 日付けのプレスリリース”National Arbitration Forum Issues
Three Decisions on Internet Domain Name Disputes”72においては、ドメイン名の紛争は、訴訟よりもUDRPを利用して申し立てられる傾向が見て取れると伝えている。また、2007
年 9 月 13 日付けのプレスリリース” The National Arbitration Forum Resolves Univision,Webkinz and Hershey's Kisses Domain Name Disputes”73においては、弁護士Kristine
Dorrain氏のコメントとして「ドメイン名は、商標権者にとってかけがえのない価値を持っており、サイバースクワッティングやタイポスクワッティングのような不正行為は、紛争に持ち込まれ得る。」といった内容の引用がある。
以上の 2 機関のプレスリリースにある通り、ドメイン名の持つ価値が商標権者等にとって高まる中で、サイバースクワッティングは新たな技術を用いて進化しており、DRP を用いた紛争解決に持ち込まれるケースが多くなっていると考えられる。これは、各紛争処理機
関における取り扱い件数の堅調な推移からも見て取ることができる。今後のドメイン名紛争においても、この傾向が続くものと推察される。
次に、JPドメイン名紛争処理方針（以下、「紛争処理方針」という）及びJPドメイン名紛争処理方針のための手続規則（以下、「手続規則」という）74に基づき行われるJPドメイン名の紛争処理についても確認したい。2006 年の件数は 8 件で、過去最多の 11 件の申立があった 2005 年より減ったが、2007 年は 10 件の申立があり増加傾向に転じた。
紛争処理方針の運用面については、
2007 年度も JPNIC に DRP 検討委員会が設立され、2006
年度に改訂作業が進められ、2007 年 6 月 1 日より実施された改訂版紛争処理方針をより理解してもらうための解説の作成を進めてきた。紛争処理方針および手続規則の改訂では、
JP-DRP の策定当初からの理念は変えることなく、利用者にとってより簡易、迅速な手続を容易にすることを主要な目的として、不明確な規程の書きぶりの見直しと実務を進める過程で判明した不具合の修正がされた。2008 年 3 月を目処に完成する解説により、紛争処理
方針改訂の目的がより一層実現されるものと期待される。
以下では、gTLD、ccTLD、JP ドメイン名におけるドメイン名紛争に関する近年の動向を概観する。

72 http://domains.adrforum.com/newsroom.aspx?itemID=1176

73 http://www.adrforum.com/newsroom.aspx?&itemID=1274&news=3
74 JP-DRPおよびJP-DRP手続規則は、以下のページで確認できる。

http://www.nic.ad.jp/ja/drp/index.html

229

2-6-2 gTLD におけるドメイン名紛争
2-6-2-1 gTLD におけるドメイン名紛争の概況
ICANN により認定され、UDRP 及び UDRP Rules に基づきドメイン名紛争を扱う紛争処
理機関は、下記の 3 機関である。かつては、eRes (eResolution)および CPR (International
Institute for Conflict Prevention and Resolution)も ICANN 認定の紛争処理機関として機能していたが、eRes は 2001 年 11 月の活動停止以降は稼動しておらず、CPR は 2000 年 5
月 22 日に ICANN より認定され、同年 6 月以降ドメイン名紛争処理に携わっていたが、2007
年 1 月以降はドメイン名紛争処理を行っていない。ADNDRC が認定されたのを最後に、新たに認定された紛争機関はない。
なお、2007 年 5 月 25 日付けのICANNのアナウンスメントにて、Czech Arbitration Court(CAC)がUDRPの認定紛争処理機関となることの関心表明をICANNに提出したことが通知され、提案書等は同年 6 月 25 日までパブリックコメントに付された。寄せられたコメント
やその後のICANN会議における議論などを反映した修正版の提案書等をもって、同年 11
月 12 日から 12 月 2 日まで再度パブリックコメント期間が設定された。2008 年 1 月 23 日のICANN理事会でCACの申請が承認され、紛争処理機関としてのサービス提供に向けて法律顧問とCACは検討に入るよう要請している。2008 年 2 月時点では、UDRPの認定紛争処
理 機 関 を 掲 載 す る ウ ェ ブ サ イ ト ” Approved Providers for Uniform Domain-Name
Dispute-Resolution Policy”75 においてCACの名前が確認できていないが、近い将来他の 3機関と共に名を連ねるものと思われる。
各紛争処理機関の名称と活動開始時期は以下の通りである。
表13： 紛争処理機関と活動開始時期
紛争処理機関名

活動開始時期

WIPO (World Intellectual Property Organization)

1999/12/01

NAF (The National Arbitration Forum)

1999/12/23

ADNDRC (Asian Domain Name Dispute Resolution Centre)

2002/02/28

75 http://www.icann.org/dndr/udrp/approved-providers.htm

230また、各紛争処理機関の活動開始以降の処理件数は、以下の通りである76。
表14： 紛争処理機関別処理件数推移
WIPO

NAF

CPR

ADNDRCeRes

合計

1999 年

1

-----

-----

-----

-----

1

2000 年

1,857

860

19

-----

250

2,986

2001 年

1,557

836

14

-----

96

2,503

2002 年

1,207

870

32

22

-----

2,131

2003 年

1,100

854

24

27

-----

2,005

2004 年

1,176

931

9

30

-----

2,146

2005 年

1,456

1,119

25

43

-----

2,643

2006 年

1,824

1,427

2477

46

-----

3,321

2007 年

2,156

1,539

-----

3278

-----

3,727

合計

12,334

8,436

147

200

346

21,463

2000 年以降 2003 年前後までは、各紛争処理機関の処理件数は減少傾向にあったが、2005
年と 2006 年は 3 機関の処理件数が増加した。2007 年については、ADNDRC の”Case
Statistics”のページにおいて、6 月 29 日付け KR-0700019 事件以降の情報が公開されていないように見受けられることと、”Decisions”のページについては北京事務所と香港事務所の情報は確認できるものの、ソウル事務所の情報が掲載されていないため、いずれにしても 2007 年の総数を確認できない。ただ、2006 年時点において ADNDRC の取り扱い件数をはるかに凌いだ WIPO と NAF において 2007 年も増加していることから、過去数年間においてはドメイン名紛争が全体として増加傾向にあると見て差し支えないだろう。

76

処理件数は、各紛争処理機関のWebサイトを基に集計したものである。

77 CPRのウェブサイトの記述によると、ドメイン名の紛争処理機関として活動していたのは 2000 年 6 月から 2007 年 1 月となっているが、申立の受理は 2006 年内に受け付けたものが最後となっている。
78 2007 年 6 月下旬以降の数値が公開されていないため、記載しない。

231

2007 年の申立先を紛争処理機関ごとに分けると以下の通りとなる。なお、上述の「紛争処理機関別処理件数推移」と同様に、ADNDRC については”Case Statistics”のページにおいて 6 月 29 日付け KR-0700019 事件までで確認できる 32 件を参考数値として掲載する。
図2： 2007 年の申立先
ADNDRC
0.9%

NAF
41.3%

WIPO
57.8%

例年の傾向として、WIPO、NAF の順に割合が高く、両者で 95％以上の割合を占めている。
ADNDRC の数値がつかめないため確証は得られないが、2007 年についても似た傾向があるように想像される。

232

2-6-2-2 紛争処理機関の比較
2-6-2-2-1 手数料
申立人は、申立先の機関に手数料の全額を支払わなければならない。ただし、申立人が 1
名パネル（1 名のパネリストによる裁定）を希望し、1 名パネル分の料金を納付した後、被申立人（ドメイン名の登録者）が 3 名パネルを希望する場合には、すべての料金を申立人と被申立人で均等に負担することになる（UDRP 第 4 節 g.項）。
料金は、各紛争処理機関が定める補則等により定められている。以下のごとく、紛争処理機関ごとに料金設定に若干の差がある。
表15： 各紛争処理機関の料金設定(1) WIPO
紛争対象のドメイン名の数

裁定パネルの構成

裁定パネルの構成（1 名パネル）（3 名パネル）

1–5

US$1,500

US$4,000

6 – 10

US$2,000

US$5,000

11 以上

相談により決定

相談により決定(2) NAF
紛争対象のドメイン名の数

裁定パネルの構成

裁定パネルの構成（1 名パネル）（3 名パネル）

1–2

US$1,300

US$2,600

3–5

US$1,450

US$2,900

6 – 10

US$1,800

US$3,600

11 – 15

US$2,250

US$5,000

16 以上

相談により決定

相談により決定(3) ADNDRC
紛争対象のドメイン名の数

裁定パネルの構成

裁定パネルの構成（1 名パネル）（3 名パネル）

1–2

US$1,000

US$2,500

3–5

US$1,200

US$3,000

6–9

US$1,600

US$3,600

10 以上

US$3,000

US$7,000233

紛争の対象となるドメイン名が１つである場合で比べると、１名パネルでも３名パネルでも、高い順に WIPO ＞ NAF ＞ ADNDRC となる。最も多くの申立を扱うのは WIPO であるが、WIPO に申立が集中する理由が価格面でのメリットを感じているわけではないことがうかがえる。
料金面については、いずれの紛争処理機関も比較的廉価であり、各紛争処理機関ともドメ
イン名紛争を引き受けることが収益に貢献しているとは考えづらい。
WIPO と ADNDRC は、パネリストとセンター側の分配割合も公表している。そこで、WIPOの Schedule of Fees under UDRP（http://arbiter.wipo.int/domains/fees/index.html）を見てみると、申立の対象となるドメイン名が１つで単独パネルで審理される場合、センターの取り分は US$500 で、3 名パネルの場合でも US$1,000 である。WIPO のドメイン名紛争取り扱い部門には 20 人ほどの職員が在籍すると聞いたことがあり、年間の取り扱い件数が減少していないことから、現在も同数程度の構成であると仮定すると、2007 年の年間取り扱い件数が 2,000 件を超えたとはいえ、その手数料では必要な人件費すら充当することが難しいことも予想される。実際には人件費以外の費用も運営に必要となるため、ドメイ
ン名紛争取り扱い部門に限って言えば収益を確保できない体質であることが推察される。

234

2-6-2-2-2 Supplemental Rules（補則）各紛争処理機関の補則比較を以下に示す。
表16： 各紛争処理機関の補則比較
WIPO
紙媒体の場合のNAF

ADNDRC

1 名パネルの場合 3 部、34 部（原本に”Original”と名パネルの場合 5 部

記す）

申立書・答弁書ともに主張

申立書・答弁書ともに主張

申立書・答弁書ともに主張

部 分（手続規則の第 3 条

部分（手続規則の第 3 条

部分（手続規則の第 3 条(b)(ix)及び第 5 条(b)(i)に関(b)(ix)及び第 5 条(b)(i)に関(b)(ix)及び第 5 条(b)(i)に関する部分）は 5,000 ワードする部分）は 10 ページ以する部分）は 3,000 ワード

以内

内

以内

センターにより任命

明確な記載は ないが事件センターにより任命

4部

申請書式送付部数

字数制限

事件管理者の選出方法
答弁書提出期限の管理者は置く
記載なし

延長

答弁書の提出期限までに、 記載なし
延長に関する両当 事者 の合意を書面にて提出（延長が必要な事情も記載）すれば、100$の支払いにより最長 20 日の延長が可能

追加提出物

記載なし

答弁書の提出より 5 日以内

記載なしに提出し、US400$を支払う。

ADNDRC の supplemental rules(3 つとも内容は同じ)：
北京事務所：http://www.adndrc.org/adndrc/bj_supplemental_rules.html

香港事務所：http://www.adndrc.org/adndrc/hk_supplemental_rules.html
ソウル事務所：http://www.adndrc.org/adndrc/kre_supplemental_rules.html
NAF の supplemental rules：

http://domains.adrforum.com/main.aspx?itemID=631&hideBar=False&navID=237&news=26

235

WIPO の Supplemental Rules：

http://www.wipo.int/amc/en/domains/rules/supplemental/index.html
この中で特徴的なのは、NAF において料金を支払うことで答弁書の提出期限を延長させることができたり、US$400 の料金を支払えば申立書・答弁書の内容を修正できるものではないが追加の提出物が認められるという点である。ただ、実際にはどの程度利用されているのかについては不明である。

2-6-2-2-3 勝敗率と紛争処理機関の選択
各紛争処理機関における勝敗率の統計を調査した。各紛争処理機関の Web サイトに公表されている裁定結果を集計したもので、以下の方法で移転率を計算している。

[移転及び取消しの数]
移転率(％)＝

×[全裁定数]

236100

表17： ICANN 認定紛争処理機関「移転」率一覧表
ADNDRC
2002 年

2003 年

2004 年

2005 年

2006 年 2007 年79① Transferred

11

14

21

34

69

14

163

② Cancelled

0

0

1

0

0

0

1

③ Rejected

6

4

2

2

6

2

22

④ Withdrawn

10

12

18

5

2

0

47

合計

27

30

42

41

77

16

233

①＋②

11

14

22

34

69

14

164

①＋②＋③

17

18

24

36

75

16

186

移転率 (%)

64.7%

77.8%

91.7%

94.4%

92.0%

87.5%

88.2%

合計

NAF
2000 年 2001 年 2002 年 2003 年 2004 年 2005 年 2006 年 2007 年

合計① Transferred

614

632

683

650

669

838

1,129

1,172

6,387

② Split Decision

2

3

7

6

3

4

3

3

31

③ Cancelled

12

7

0

0

2

2

0

2

25

④ Claim Denied

133

109

88

100

125

121

122

137

935

Withdrawn

99

85

90

98

112

188

176

210

1,058

Recommenced

0

0

0

0

0

0

0

0

0

合計

860

836

868

854

911

1,153

1,430

1,524

6,912

①＋②＋③

628

642

690

656

674

844

1,132

1,177

6,443

①〜④の合計

761

751

778

756

799

965

1,254

1,314

7,378

移転率 (%)

82.5%

85.5%

88.7%

86.8%

84.4%

87.5%

90.3%

89.6% 87.3%

79 ADNDRCのウェブサイトの”Case Statistics”において確認できる、6 月 29 日付けKR-0700019 事件までの情報に基づき参考数値として掲載する。

237

WIPO
1999 年 2000 年 2001 年 2002 年 2003 年 2004 年 2005 年 2006 年 2007 年① Transfer

合計

1

1,183

983

792

753

770

927

1,125

1,243

7,777

0

1

0

1

1

1

3

1

0

8

0

7

10

6

3

2

2

5

2

37

0

7

6

5

5

5

7

8

5

48

0

0

0

0

0

0

0

1

0

1

0

7

12

11

8

9

7

11

22

87

0

0

0

0

0

0

1

0

0

1

0

0

0

0

0

0

1

0

0

1

0

262

245

148

110

108

142

183

192

1,390

0

11

3

4

2

3

0

4

3

30

0

4

6

3

3

0

1

0

1

18

0

0

0

1

0

0

1

0

0

2

Terminated

0

375

292

236

215

278

364

486

536

2,782

合計

1

1,857

1,557

1,207

1,100

1,176

1,456

1,824

2,004 10,178①〜⑧の合計

1

1,205

1,011

815

770

787

948

1,151

1,272

6,688

①〜⑫の合計

1

1,482

1,265

971

885

898

1,092

1,338

1,468

7,932

100.0% 81.3% 79.9% 83.9% 87.0% 87.6% 86.8% 86.0% 86.6%

84.3%

Transfer,② cancellation in
part

③

④

Transfer with
dissenting opinion
Transfer,denied in part
Transfer, denied in⑤ part with
dissenting opinion⑥ Cancellation⑦⑧

Cancellation,
denied in part
Cancellation,transfer in part

⑨ Complaint denied
Complaint denied⑩ with dissenting
opinion⑪

Complaint denied,transfer in part
Complaint denied,⑫

transfer in partwith dissenting
opinion

移転率 (%)

238

ADNDRC については、やはり参考数値として掲載しているため、分析を避けたい。NAFと WIPO について集計結果を見ると、移転や取消しといった申立人側に有利な裁定結果となった割合が高い傾向が続いていると言え、2006 年度大差ない推移と言える。
2-6-2-2-4 パネリスト
いずれの紛争処理機関も、Web サイト上でパネリスト候補者を公表している。2008 年 2 月
時点で、最も多くのパネリスト候補者を有しているのは WIPO であり、その人数は 395 人
で、昨年同時期の 389 人より増えている。このうち、日本人は 8 人含まれており、昨年度と変わりない。NAF のパネリスト候補者は 145 人（昨年同時期は 147 名）で、そのうち日本人が１人含まれている。ADNDRC は、北京、香港、ソウルの各事務所のページにパネリ
スト候補一覧を掲載しているが、内容は同一であり、66 人（昨年同時期は 60 人）のパネリ
スト候補者が掲載されている。ADNDRC の一覧には、日本在住のパネリスト候補者の氏名は見られない。パネリスト候補者の中には、WIPO に候補者として登録されていると同時に NAF や CPR にも重複して登録されている候補者もいる。
紛争処理機関とパネリスト候補者との連絡方法等、各紛争処理機関内の業務内容は外部からは伺い知れない。また、各事件に対してパネリストを指名する際の方法等についても、内部では何らかの基準があると思われるが、公開されていないため不明である。
また、ADNDRCのWebサイトには「Procedures for Inclusion on the Asian Domain Name
Dispute Resolution Centre Administrative Panel80」というページがあり、パネリスト候
補者の評価システムが存在することが分かる。これは、他の 2 機関では見当たらないため、
ADNDRCの特徴の 1 つと言えるだろう。このパネリスト評価システムは、UDRP、UDRP
Rules、ADNDRCの補則に則りドメイン名紛争処理を行うための最低限の基準を定め維持することや、ドメイン名紛争処理に携わる専門家としての質の維持、向上等を目的としている。パネリスト候補者となるための要件は、仲裁や知的財産に関する経験やIT関連の知識といった裁定を行うにあたり最低限必要となるであろう経験、知見のみならず、年齢が75 歳以下であることや、ADNDRC Panel Selection Committeeが認定する 1 日セミナーに参加すること等が含まれている。また、任期は 3 年で、更新を希望する場合には最新の履歴書を添付して申請を行う必要があり、更新前の 3 年の間にADNDRCが認定するセミナーを受講しているか、少なくとも 3 件の裁定を出していないといけないといった要件もある。

80

事務所ごとにURLは異なるが、内容は同一である。
北京：http://www.adndrc.org/adndrc/bj_pip.html
香港：http://www.adndrc.org/adndrc/hk_pip.html
ソウル：http://www.adndrc.org/adndrc/kre_pip.html

239

2-6-2-3 WIPOⅡを巡る動き
WIPOⅡとは、WIPOセカンド・プロセス（the Second WIPO Internet Domain Name
Process）の検討プロセスの結果を受けて、WIPOよりICANNに提出された検討要請のことを指す。2003 年 2 月 21 日付のレター「Letter from Francis Gurry, WIPO, to Vint Cerf andStuart Lynn」81が文書による正式要請となる82。WIPOは、ドメイン名について国際的な政府間機関名（International intergovernmental organizations, IGOs）及び国家名を保護す
べくUDRPを改訂することを、このレターでICANNに要請している。
このレターを受けて、ICANNでは 2003 年 10 月 6 日にWIPOⅡ検討のための合同ワーキン
ググループが組成された。2004 年 7 月 14 日にはICANNに最終報告書83が提出されたが、合同ワーキンググループ内では合意に至らなかったため、相矛盾する意見が残った内容となっている。
ICANN内におけるWIPOⅡを巡る動きは、この最終報告書提出までは迅速に進展したが、以降は停滞の一途であった。WIPOは 2004 年 11 月中旬に、レター要請の論拠を示す文書とその別紙をICANNに送付し84、国連も 2005 年 3 月 23 日付で催促のレターをICANNに送付した85。このレターは、WHOやILO、IMF、IAEA、WTO等を始めとする 24 の国際機関（WIPO含む）を代表して送付されたもので、この中で国連は、国際機関名がドメイン名
上保護されるべきという、当該機関の法律専門家の集合見解を通知するとしてUDRPの改訂を迫っている。
しかしながら、2005 年のICANNの活動においては、本件に関してほとんど進展が見られなかった。WIPOは再度ICANNに 2005 年 11 月 15 日付で催促のレターを送付した86が、これについては、ICANN側はレターの受領をWIPO側に通知したのみとのことである。更に引き続き、2006 年のICANN会議においても、アジェンダ上にWIPOⅡに関する項目は上がっておらず、WIPOもしくは関連組織からの催促のレターも受信せずに 2007 年を迎えた。
ところが、2007 年の春以降になると流れが変化した。新 gTLD 導入の議論に関連して、IGOのための DRP を新たに策定しようとの議論が持ち上がったのである。これは、フィッシン
グ等の詐欺行為に IGO の名称が使われるケースが出てくるようになったことが理由である。
81 http://www.icann.org/correspondence/gurry-letter-to-cerf-lynn-21feb03.htm
82 WIPOが同レターをICANNに送付するまでの経緯は以下に記述がある。

http://www.wipo.int/amc/en/processes/process2/index.html

83 http://www.icann.org/committees/JWGW2/final-report/

84 http://gnso.icann.org/mailing-lists/archives/council/msg00660.html
85 http://www.icann.org/correspondence/michel-to-cerf-23mar05.pdf

86 http://www.icann.org/correspondence/gurry-to-cerf_twomey-15nov05.pdf

240

工業所有権の保護に関するパリ条約で、政府間国際機関の略称及び名称は商標などに登録できないよう保護されている IGO が使われたドメイン名には UDRP を適用できないため、IGO のための新たな DRP を作ろうという議論になったのである。
2007 年 5 月 24 日のGNSO評議会にてスタッフレポートを要請することが決議され、6 月
15 日には既存のURDPを修正してIGO向けの新しいDRPを作ることを提案する”GNSO
Issues Report on Dispute Handling for IGO Names and Abbreviations”87 が提出された。
2007 年 6 月下旬のICANNサンファン会議では、新DRPを導入する場合に必要となる事項について引き続き検討することを要請し、その後の報告の内容によりポリシー策定プロセス（Policy Development Process, PDP）を開始するかを検討することとなった。
その後、検討内容や新DRP案を含む次のスタッフレポートである” Staff Report on Draft
IGO Name Dispute Resolution Procedure”88が 2007 年 9 月 28 日に提出された。2007 年
10 月末から 11 月はじめにかけて開催されたICANNロサンゼルス会議のGNSO評議会では、
PDP開始の決議を行う前にアドホックグループを結成して、報告書の検討を行いGNSO評
議会に勧告を行うことを知的財産部会が提案したが、否決されてPDPについての決議はペンディングになった。その後、GNSO評議会メンバー内で検討が進められたが、2007 年 12月 20 日のGNSO評議会においてもPDPの開始は否決された。ただ、PDPの開始がこれまでに否決された理由は、議論が熟していないことによるものが大きく、IGO向けの新しいDRPを作ることについては引き続き議論されるものと思われる。

2-6-2-4 ドメイン名の移転に関する紛争処理（TDRP）
ドメイン名登録者がレジストラ変更を行おうとする際、レジストラ間のトラブルが生じた
場合に、それを解決する手段としてTDRP（Transfer Dispute Resolution Policy）がある。
TDRPは、「Policy on Transfer of Registrations between Registrars（レジストラ変更（レジストラ間のドメイン名移転）に関するポリシー）89」の一部であり、ICANNにより 2004
年 7 月 12 日に策定され、同年 11 月 12 日に施行された。登録者と商標権者等とのドメイン
名紛争の解決手段であるUDRPとは根本的な性質は異なるが、TDRPもまた、ドメイン名に関する紛争のための規定である。
ICANN が TDRP に基づくレジストラ間のドメイン名移転に関する紛争処理機関を募った

87 http://gnso.icann.org/issues/igo-names/issues-report-igo-drp-15jun07.pdf
88 http://gnso.icann.org/drafts/gnso-igo-drp-report-v2-28sep07.pdf
89 http://www.icann.org/transfers/policy-12jul04.htm

241ところ、下記の 2 機関が応募し、承認された。TDRP の施行以降は、紛争処理機関が増えることなく、今日に至っている。
•

NAF (The National Arbitration Forum90)•

ADNDRC (Asian Domain Name Dispute Resolution Centre91)

いずれの機関も、ウェブサイトにて TDRP に関する情報の他に補則や書式等を掲載している。なお、ADNDRC は北京、香港、ソウルの 3 ヶ所に事務所を有するが、TDRP の紛争処理を取り扱うのは北京事務所と香港事務所の 2 ヶ所である。
2008 年 2 月末日現在、いずれの紛争処理機関においても、これまでに TDRP に基づくドメイン名紛争があったことは確認できない。レジストラ移転をめぐるトラブルの対応に Policy
on Transfer of Registrations between Registrars が奏功しているとも考えられるが、TDRPが利用されていない理由は明らかではない。

2-6-2-5 ccTLD におけるドメイン名紛争
その他、主要 ccTLD におけるドメイン名紛争処理システムの概要は以下の通りとなっている。

2-6-2-5-1 .au
UDRP をモデルにした.AU Dispute Resolution Policy (auDRP)に基づいて処理されており、手続きは WIPO を含む４つの紛争処理機関に委任している。UDRP は商標をベースにしているが、auDRP は人名等の申立者が権利を有する名称も保護の対象としている点が、UDRPと auDRP の違いの一つとして上げられる。また、不正の目的は、ドメイン名の登録時または使用時のどちらかにあれば auDRP の適用対象になるとされている。

2-6-2-5-2 .us
90 The National Arbitration ForumのTDRPに関するページ

http://domains.adrforum.com/main.aspx?itemID=282&hideBar=False&navID=265&news=26
91 Asian Domain Name Dispute Resolution Centre

http://www.adndrc.org/adndrc/index.html

242

USDRP がある。UDRP と異なる点としては、不正の目的はドメイン名の登録時または使用時のどちらかにあれば USDRP の適用対象になることが上げられる。USDRP に基づくドメイン名紛争は、American Arbitration Association （AAA）と NAF が扱っている。

2-6-2-5-3 .kr.krドメイン名登録のThe General Terms and Conditions92 の 12 項によると、Internet
Address Dispute Resolution Policy（IDRP）に則りInternet Address Dispute Resolution
Committee(IDRC) 93 が.krのドメイン名紛争の申立を受理すると記されている。現在は、Korean Internet address Dispute Resolution Committee (KIDRC)という名称で.krの唯一の紛争処理機関であり、ADNDRCの事務所の 1 つとなっている。

2-6-2-5-4 .ch
Rules of Procedure for Dispute Resolution Proceedings for .ch and .li Domain Names に則り、WIPO のみにより紛争処理が行われている。適用されるルールは調停がモデルになっているため、その手続は UDRP のものとは異なる。例えば、申立があるとまず電話により調停が行われる。調停が不成立や被申立人側が応じない場合等は、申立人側は判断を下すためのパネルの任命を求めることができる。また、申立人は、国家法上における知的財
産権の法的侵害を受けたことを立証しなければならない。

2-6-2-5-5 .de
登録契約上、紛争処理の制度を持たないため、当事者同士の和解が不可能な場合は国家法により裁判所で処理することになる。

2-6-2-5-6 .fr

92 http://domain.nida.or.kr/eng/policy.jsp
93 http://www.idrc.or.kr/eng/index.htm

243適用されるルールは UDRP をモデルにしており、WIPO が取り扱う。商標以外にもその他の知的財産権や諸権利を申立の根拠として認めており、また、不正の目的はドメイン名の登録時または使用時のどちらかにあれば適用対象と認められる。3 人パネルを選択することができない。
なお、個人間もしくは個人対法人において法的解決が求められる場合には、Internet Rights
Forum という組織の手続きに依ることもできる。

2-6-2-5-7 .nl
これまで適用されていたルールは、仲裁がモデルになっていた。しかしながら、簡易・迅
速・低費用を目指し、2008 年 2 月 28 日以降は WIPO を紛争処理機関とする紛争処理方針を導入する。

2-6-2-5-8 .uk
UKDRP がある。UDRP をモデルとしているが、問題としているのは紛争にかかるドメイ
ン名の登録が「abusive registration（他害的な登録）」であるか否かで、「bad faith」という用語を用いていない。これは、意味合いとしては「bad faith」に近いのかもしれないが、実際にどのように運用されているのかについては把握し切れていない。

244

その他、WIPO にドメイン名紛争を委任している ccTLD は以下の通りである。
表18： WIPOがドメイン名紛争を扱うccTLD94
ccTLD

国名

ccTLD

国名

.ac

アセンション島

.ma

モロッコ

.ae

アラブ首長国連邦

.md

モルドバ

.ag

アンティグァ・バーブーダ

.mw

マラウイ

.am

アルメニア

.mx

メキシコ

.as

アメリカンサモア

.na

ナミビア

.au

オーストラリア

.nl

オランダ

.bs

バハマ

.nr

ナウル

.bz

ベリーズ

.nu

ニウエ

.cc

ココス諸島

.pa

パナマ

.cd

コンゴ

.pe

ペルー

.ch

スイス

.ph

フィリピン

.co

コロンビア

.pk

パキスタン

.cy

キプロス

.pl

ポーランド

.dj

ジブチ

.pn

ピトケアン島

.ec

エクアドル

.pr

プエルトリコ

.es

スペイン

.re

レユニオン

.fj

フィジー

.ro

ルーマニア

.fr

フランス

.sc

セイシェル

.gt

グアテマラ

.sh

セントヘレナ島.ie

アイルランド.tk

トケラウ諸島

.ir

イラン

.tm

トルクメニスタン

.ki

キリバス

.tt

トリニダーゴ・トバゴ

.la

ラオス

.tv

ツバル

.lc

セントルシア

.ug

ウガンダ

.li

リヒテンシュタイン

.ve

ベネズエラ

.ws

サモア
（以上 51ccTLD）

94 http://www.wipo.int/amc/en/domains/cctld/245

2-6-3 JP ドメイン名におけるドメイン名紛争
2-6-3-1 JP ドメイン名におけるドメイン名紛争と 2007 年の概況
JP ドメイン名の紛争は、社団法人日本ネットワークインフォメーションセンター（以下、「JPNIC」という）が策定した JP-DRP および JP-DRP 手続規則により処理されている。
JP-DRP 及び JP-DRP 手続規則は、UDRP 及び UDRP Rules をモデルとし、2000 年 7 月
19 日に策定され、同年 10 月 10 日に施行された。
JP-DRP の紛争処理手続きは、JP-DRP 手続規則に基づき JPNIC の認定した紛争処理機関
により行われる。2000 年 8 月、JPNIC は工業所有権仲裁センター（2001 年 4 月に、組織名を現在の「日本知的財産仲裁センター」に変更）と JP ドメイン名に係わる紛争処理業務を行うことについて協定書の締結を行い、同年 10 月の施行と共に同センターが第 1 号の認定紛争処理機関として JP ドメイン名に関する紛争処理業務を開始した。現在も唯一の認定
紛争処理機関として、JP-DRP 及び JP-DRP 手続規則に基づくドメイン名紛争を処理して
いる。

246

同センターにおけるこれまでの処理件数は、次のとおりである。
図3： 日本知的財産仲裁センターの処理件数
12
11

11
10

10

8

8
7
（件数）

6

6

4

4

2

2

0

2000年

2001年

2002年

2003年

2004年

2005年

2006年

2007年

（年）

2005 年は過去最多の 11 件の申立があり、2006 年は減少した。なお、2005 年には、1 登録者に対して大手 ISP8 社が共同で申立を行った 8 件の事件（事件番号：JP2005-0003〜
JP2005-0010）が含まれていることに留意する必要がある。2007 年は 10 件の申立があり、増加傾向に転じた。

2-6-3-2 手数料
JP ドメイン名紛争処理手数料規則により以下のように定められている。
表19： JP-DRP の手数料
（税込）
申立にかかる1 名パネル

3 名パネル

3 ドメインまで¥189,000¥378,000

4 ドメイン以上

1 ドメイン名につき、¥10,500 追加

1 ドメイン名につき、¥21,000 追加

ドメイン名の数

247

UDRP に基づくドメイン名を処理する 3 紛争処理機関と比べて、金額設定にそれ程大きな開きはない。申立を取り下げる場合、センターがパネルを指名する前であれば、これらの手数料のうち¥31,500 を差し引いた額が、パネリスト指名後は、審理の進捗状況を勘案した金額を差し引いた額が払い戻される（同規則第 2 条）。
審問が発生する場合については、審問手数料¥15,750 を追加納付する（同規則第 3 条）。ただし、これまでに審問が行われたことはない。

2-6-3-3 JP ドメイン名紛争処理方針のための手続規則の補則
JPドメイン名紛争処理手続を行う際の細則を定めた「ＪＰドメイン名紛争処理方針のための手続規則の補則」は、日本知的財産仲裁センターのWebサイト内95で確認することができる。
この中では、書類提出方法などの他、第 9 条にて申立書及び答弁書の字数制限の規定が設けられている（申立書のうち申立の理由は 1 万字以内、答弁書は全体で 1 万字以内にて作成されなければならない、とされている）。

95

日本知的財産仲裁センターWebサイト（http://www.ip-adr.gr.jp/）内にて、次の階層を辿って確認できる。「D業務の詳細」→「６．JPドメイン名紛争処理」→「６．８ JPドメイン名紛争処理の規則等」

248

2-6-3-4 裁定結果の割合
これまでの裁定結果（移転/取消し/棄却）の割合は以下の通りとなっている96。
図4： JP-DRP における過去の裁定結果

棄却
6%
取消
7%

移転
87%

裁定結果を件数で表すと、過去の裁定（54 件）のうち、47 件が移転を命じ、残りは 4 件が取消し、3 件が棄却となっている。移転と取消しの割合を足すと 94％であり、圧倒的に申立人側に有利な裁定結果となる傾向があることが見て取れる。これまでに棄却されたのは、2004 年の申立（事件番号：JP2004-0001、紛争にかかるドメイン名：enemagra.co.jp）、
2006 年の申立（事件番号：JP2006-006、紛争にかかるドメイン名：rabiton.co.jp）、2007
年の申立（事件番号：JP2007-008、紛争にかかるドメイン名：firefox.jp）の 3 件となっている。

取下げは、これまでに 4 件あったが、それらは含まれていない。また、2008 年 2 月までに裁定が実施された事件のみを含めている。

96

249

図5： JP-DRP における 2007 年の申立の結果

係属中
10%
棄却
10%

移転
80%

2007 年には 10 件の申立があり、そのうち 2007 年 2 月時点での状況を見ると、移転が命じられた裁定結果が 8 件、棄却が 1 件、係属中が 1 件となっている。2007 年も、前述の過去の傾向と同様に、申立人に対して有利な結果で終わっている。
なお、かつては、UDRP の裁定に比して JP-DRP の裁定結果は圧倒的に申立人側に有利な結果となることが多かった。しかしながら、UDRP の指定紛争処理機関におけるここ数年の傾向を見ると、JP-DRP に基づく裁定の結果が突出して申立人側に有利であるとも言えな
い結果となっている。ただ、JP-DRP の場合は、申立件数そのものが多くはなく、1 件の差が割合の計算に与える影響が大きいため、申立件数が伸びた場合に状況が変化する余地も残していると言える。

2-6-3-5 パネリスト
日本知的財産仲裁センターに登録され、JPドメイン名紛争の解決に取り組むパネリスト候補者の一覧および詳細は、同センターのWebサイト内97で確認することができる。現在、3597

日本知的財産仲裁センターWebサイト（http://www.ip-adr.gr.jp/）内にて、次の階層を辿って確認でき

250

名が登録されており、構成は次の通りである。
弁護士

7名

弁理士

7名

弁護士および弁理士

14 名

大学教員

1名

大学教員および弁護士

1名

大学教員および弁理士

1名

大学教員、弁護士および弁理士

1名

大学院教員

2名

大学院教員および弁護士

1名

2-6-3-6 答弁書提出割合
これまで行われた裁定の答弁書提出割合と、2007 年（2008 年 2 月までに裁定が下されたもの）における答弁書提出割合は次の通りである。

る。「D業務の詳細」→「６．JPドメイン名紛争処理」→「６．４

パネリスト」

251

図6： JP-DRP における答弁書の提出割合
これまでの答弁書提出の割合

答弁書提出あり48%
答弁書提出なし
52%

2007年における答弁書提出の割合

答弁書提出あり
33%

答弁書提出なし
67%252これまでの答弁書提出割合に比べて、2007 年における提出割合は低かった。なお、答弁書の提出がないケースは、単に提出期限までに提出されなかったものがほとんどであるが、中には、登録者が裁判所に申立を行ったため、当該ドメイン名に係わることを裁判手続以外でコメントすることを差し控えるため、などの理由によるものも数件含まれる。

2-6-3-7 JP-DRP の改訂
UDRP 及び UDRP Rules をモデルとして策定された JP-DRP 及び JP-DRP 手続規則は、
2000 年 10 月に施行されて以降、７年余りが経過した。過去に数回の改訂があったものの、それらは実質的な変更を伴うものではなく、基本的には策定時の内容でこれまで運用されてきた。ところが、JP-DRP 及び JP-DRP 手続規則に基づき下されたこれまでの裁定結果を見てみると、規定類の改訂がなされなかったにも関わらず、策定時の理念とは乖離して運用されるケースも見られるようになってきた。
その問題に気付いたのは、2004 年 11 月から 2006 年 2 月まで活動した「JP-DRP 裁定例検討専門家チーム」の検討によるものである。この専門家チームでそれまでの裁定例を検討するきっかけとなったのは、JP-DRP と UDRP の勝敗率を比較した場合に、JP-DRP の方が圧倒的に申立者側に有利な裁定が下りている率が高いという事実であった。JP-DRP は
UDRP をモデルとしているため、判断基準などが UDRP に準ずるものであると想像できるわけだが、実際は異なることに疑問を感じたことにはじまる。
同専門家チームでは、JP-DRP と UDRP との裁定結果の違いを生み出す理由、つまりJP-DRP の裁定が申立人側に有利となる理由を探るために過去の裁定例の検討を行ったわ
けだが、その結果として、JP-DRP には策定当初に意図していた内容とは異なって理解される余地を含んでいることに気付くに至ったのである。
そこで、そういった問題に対応すべく、JPNIC では 2006 年 8 月に DRP 検討委員会を設立
し、JP-DRP 及び JP-DRP 手続規則の在り方について検討を行うこととなった。
では、JP-DRP 及び JP-DRP 手続規則「策定時の理念」とは何であるのか。それは、JP-DRP
及び JP-DRP 手続規則が手本とした UDRP 及び UDRP Rules の流れを汲んでいる。
そもそも、UDRP 及び UDRP Rules は、なぜ策定されたのか。1999 年 10 月に ICANN に
おいて UDRP 及び UDRP Rules が策定された背景には、インターネットの飛躍的な発展・普及に伴うドメイン名の役割の変化が影響している。ドメイン名は本来、インターネット

253

上のいわば住所を表す識別子としての機能を持つに過ぎなかった。ところが、商取引においてインターネットが利用されるようになるにつれ、ドメイン名は識別子としての機能のみならず、商業的な価値を有すると見なされるようになり、gTLD の利用においてはドメイ
ン名と商標を巡る紛争が国際的な問題に発展するケースが見られるようになった。
ドメイン名紛争が起こる理由の１つとして、ドメイン名登録の原則の悪用が挙げられる。
ドメイン名を登録する行為そのものには法的な権利があるわけではなく、登録を希望する
ドメイン名が未登録であれば誰でもが先着順に登録することができる「先願主義」を採っており、この原則が悪用されるのである。他人の商標等と同一または類似したドメイン名を登録し、サイバースクワッティングと呼ばれる不正な行為（商標権者に不当に高い額で転売を持ちかけたり、商標権者等を中傷するようなウェブサイトのドメイン名として使用する等）が頻繁に発生するようになった。
紛争処理手続には、既存の裁判や仲裁といった手段もあったが、それらはドメイン名紛争の解決手段としては煩雑で時間と費用が膨大にかかるなどの問題があり、使い勝手が良いとは言えなかった。そこで、低費用・短期間・簡易な手続きで対応できるようにするために、UDRP 及び UDRP Rules が策定されたのである。日々、膨大な数のドメイン名が登録されるため、個々の登録について詳細な審査を行うことは現実的ではない。そのため、あくまでもドメイン名の登録は先願主義とした上で、不正の目的によるドメイン名の登録・使用のみを対象として、移転もしくは取消しの申立を行える仕組みとしたのが UDRP 及び
UDRP Rules である。この特徴は、「ミニマル・アプローチ」と呼ばれており、JP-DRP 及
び JP-DRP 手続規則の特徴でもある。
つまり、今回の改訂では、策定時からの理念であるミニマル・アプローチを追求すべく、策定当初に意図していた内容とは異なって理解される部分の見直しを行い、当事者・パネ
ルともに判断に迷う部分を最小にしようと試みたのである。
2006 年度 DRP 検討委員会を設立して以降、以下のスケジュールで改訂が行われ、改訂
JP-DRP は、2007 年 6 月 1 日に実施された。
2006 年 8 月

2006 年度 DRP 検討委員会を設立
2007 年 1 月まで、7 回の会議を開催し改訂案を検討

2007 年 1 月 23 日

JP-DRP 改訂案を公開
JPNICのウェブサイト上にて、意見募集開始98

98「JPドメイン名紛争処理方針等改訂案」に対するご意見募集のお知らせ
http://www.nic.ad.jp/ja/pressrelease/2007/20070123-01.html

254

2007 年 2 月 19 日

意見募集締め切り2007 年 2 月 21 日

DRP 検討委員会にて JP-DRP 最終改訂案を作成

2007 年 3 月 9 日

JPNIC 理事会にて JP-DRP 最終改訂案を承認

2007 年 6 月 1 日

改訂 JP-DRP 実施

2007 年度も引き続き DRP 検討委員会が設立され、2006 年度の JP-DRP 及び JP-DRP 手
続規則の改訂案検討の経験を踏まえて、JP-DRP への理解促進を図るための方策が検討されてきた。特に、改訂版 JP-DRP をより理解してもらうための解説の作成に注力し、2008 年
3 月中の完成を目処に検討が進められた。パネリストや法曹関係者といった法律の専門家だ
けではなく、JP ドメイン名紛争処理の当事者ともなり得るエンドユーザが読み手になることを意識した内容構成になっている。この JP-DRP 解説の公開により、JP-DRP 改訂の目
的がより一層実現されるものと期待される。

255

256

3

国際化ドメイン名の導入及び実装に関する取り組み状況

257

258

3 国際化ドメイン名の導入及び実装に関する取り組み状況
3-1 国際化ドメイン名(IDN)とは
国際化ドメイン名とは、従来は英数字とハイフン（いわゆる 7bit ASCII）という限られた文字しか使えなかったドメイン名に、漢字やひらがな、カタカナといった日本語や、中国語、ハングル文字、アラビア文字などといったマルチバイト文字を利用できるように国際化拡張するための技術のことを指す。また、これらのマルチバイト文字を使ったドメイン
名そのもののことも国際化ドメイン名と呼ぶ。この国際化ドメイン名を導入することによって、ドメイン名のラベルに使用できる文字の種類が従来と比べて飛躍的に増加することになった。
また、国際化ドメイン名のメリットとしては、ドメイン名に利用できる文字が増えたというだけではなく、ドメイン名に各国の言語や文化を反映したものを用いることが出来るよ
うになるという点が挙げられる。特に西欧圏以外の国においては、日常生活においてアルファベットと全く接点が無いというユーザも存在し、そのようなユーザにとっては従来のASCII 文字のみからなるドメイン名は決して馴染みやすいものではなかった。しかし、国際化ドメイン名であればこのようなユーザにとってより馴染みやすいドメイン名を利用することができる。また、国際化ドメイン名の技術自体も、様々な文字セットや様々な表記法（アラビア文字のように右から筆記する言語など）に対応できるように設計されている。
なお、かつては多言語ドメイン名という呼び方もされていたが、複数の言語を使えることにするというよりも、これまでシングルバイトの ASCII しか利用できなかった DNS 上で、マルチバイトのドメイン名を扱えるように拡張することが目的であり、そういう意味では
複数の言語などで利用できるようにするためにローカライズすることを指すことが多い多言語化(M17n: Multilingualization)よりも、国際化（I18n: Internationalization）という表
現の方が正確であり、現在では国際化ドメイン名と呼ぶ方が一般的である。また、特定の言語を用いて登録されたドメイン名を「○○ドメイン名」と呼ぶこともあり、例としては「日本語ドメイン名」や「中国語ドメイン名」などが挙げられる。

3-2 国際化ドメイン名導入のための前提とその仕組み
まず、国際化ドメイン名の実現において大きなウェイトを占めている技術標準について簡単に説明する。

259

国際化ドメイン名を実現するための方法およびそのために必要となる個々の技術は、IETF
において標準化が進められ、2003 年 3 月 7 日、それぞれ RFC として発行された。それら
RFC の内訳は、国際化ドメイン名全体の枠組みを規定する IDNA（RFC3490）、国際化ドメイン名における文字列の正規化のための方法としての NAMEPREP（RFC3491）、入力
された国際化ドメイン名を ASCII 文字列にエンコードするための技術としての Punycode（RFC3492）である。国際化ドメイン名に関連した技術が標準化されるまでは、少数のレジストリが試験的なサービスとして提供するのみであったが、これらの RFC の発行により、各レジストリが国際化ドメイ ン名を本格的に導入することが可能となった。なお、
STRINGPREP(RFC3454)を国際化ドメイン名関連の技術標準のひとつに数えることもあ
るが、STRINGPREP は Unicode 文字列を扱う際に、文字コードとしては異なる文字だがインターネットのプロトコルにおいては同じ文字として扱いたい文字を同一のものとして扱うための技術標準であり、国際化ドメイン名の実現には必要不可欠ではあるものの、国際化ドメイン名の技術標準ではないため、ここでは技術標準として含めていない。ただし、
NAMEPREP を実現するためには必要不可欠な技術であり、国際化ドメイン名で重要な意
味を持つ「文字列の正規化」を理解するためには STRINGPREP を理解することも必要であるため、後述の解説では STRINGPREP も併せて解説している。
これらの技術を RFC として標準化する際には、既存のインターネット空間、特に DNS 名
前空間に大きな影響を与えないことが何よりも重視された。もし、国際化ドメイン名の実現に必要な技術が、既存のインターネット空間に大きな変更を伴うものであっては、導入に際して無用な混乱や、最悪の場合、DNS による名前解決が不可能になるなどといった事
故を引き起こし、現在無事に動いているインターネットの仕組みを壊してしまう可能性が出てきてしまう。これではレジストリ、ユーザともに導入には慎重にならざるをえず、国際化ドメイン名普及の妨げとなってしまう。したがって、国際化ドメイン名関連技術の標準化作業を行う際には、既存の枠組みへの影響を最小限に抑えることが重要な課題とされた。
このような目標を達成するために、国際化ドメイン名を実現するための具体的な仕組みとして、ネームサーバ側でマルチバイトの国際化ドメイン名を直接扱うのではなく、ユーザ側のアプリケーションにおいて、その国際化ドメイン名を一定の法則に従って従来同様の英数字のみから成るドメイン名に変換するという方法が採用された。ネームサーバとの通信には、これまで通り 7bit ASCII だけで構成される文字列を用い、国際化ドメイン名から
7bit ASCII への変換は各アプリケーションに任せることとした。こうすることによって、既存のネームサーバソフトウェアに変更を加える必要はなくなり、またネームサーバから見た場合、扱うドメイン名は従来通りの 7bit ASCII の文字列として扱うことができ、既存の ド メ イ ン 名 空 間 に 影 響 を 与 え る 影 響 は 最 小 限 で 済 む 。 こ の 技 術 は 、 ACE （ ASCII

260

Compatible Encoding）と呼ばれる。
この ACE という技術の導入によって、既存の DNS プロトコルと互換性を持たせたまま、国際化ドメイン名を実現することが可能となった。このため、TLD のネームサーバを管理するレジストリにおける実装、また、個々のドメイン名のネームサーバにおける実装は、
純粋に技術的な観点から見るならば、大雑把な言い方をすれば各レコードの情報量が若干増える程度であり、それほど困難なものではないと言える。
一方、各アプリケーションにドメイン名の変換をまかせる実装を採用したことによって、サーバ側への問題は比較的少なく抑えることが出来た一方、技術的な観点から見た場合の課題がユーザ環境に多く発生することとなった。ACE を用いることによって、ユーザ側のアプリケーションに国際化ドメイン名対応の仕組みを加えるだけで、国際化ドメイン名が利用できるようになると同時に、そのような方式の導入は、各アプリケーション・ベンダ
ーが実装を行わない限り、ユーザが国際化ドメイン名を利用できるようにはならないことを意味することとなった。国際化ドメイン名に関する技術標準化が完了した時点で、技術的には実用化された技術となったわけだが、実際にユーザが一般的に使うようになり、真に「使える技術」となるためには、各アプリケーションへの実装がより一層進んでいくことが大変重要であると言える。

3-3 国際化ドメイン名の技術標準
次に、国際化ドメイン名の技術標準について、それぞれの概要を説明する。
国際化ドメイン名は次の三つの技術標準によって実現されている。また、先に述べた通り、
厳密には国際化ドメイン名の技術標準とは言えないが、国際化ドメイン名に深く関わる技
術標準であるため、STRINGPREP についても併せて取り上げる。それら技術標準の標準の概要は次のとおりである。
(1) IDNA（RFC3490）99
国際化ドメイン名を使って通信を行う際には、ASCII 文字列からなるドメイン名に変換を行った上で通信が行われることになるが、この変換の際に使われる技術と処理手順を規定

99 RFC3490
http://www.ietf.org/rfc/rfc3490.txt（原文）http://www.jdna.jp/survey/rfc/rfc3490j.html（日本語訳）

261

しているものが IDNA(Internationalizing Domain Name in Applications)と呼ばれる技術である。
この IDNA では、ユーザ側のアプリケーションで国際化ドメイン名の解釈を行うことや、入力された文字列を NAMEPREP という仕組みで正規化すること、既存の DNS との互換性を保つために国際化ドメイン名を Punycode と呼ばれるアルゴリズムで ASCII 文字列に変換することなどが定められている。
国際化ドメイン名を利用する際には、各アプリケーションはこの IDNA に従って国際化ド
メイン名をネットワークに送出することになる。
(2) NAMEPREP（RFC3491）100
STRINGPREP（RFC3454） を国際化ドメイン名に対して適用するため、その具体的な方法を規定したものが NAMEPREP である。
文字列の文字種や互換文字の統一、ラベル区切り文字の変換などが行われる。
具体的な例を挙げると、たとえば日本語の場合は、アルファベットの大文字・小文字は全て小文字に、全角英数字は半角に、半角カナは全角カナに統一される。また、全角の「．」
や句点「。」は半角の「.」に変換されるなど、文字の正規化が行われる。
(3) STRINGPREP（RFC3454）101
国際化ドメイン名で使用される Unicode という規格ではアクセント記号などは他の文字と組み合わせて合成することになっているが、よく使われるものについては最初から合成済
みの文字も定義されており、その場合は同じ文字を表すのに二つの方法(文字コード) が存在することになる。 また、他の文字セットとの互換性のために一つの文字に複数の文字コードが割り当てられていることもある。
このように、表示上は同じ文字であってもコンピュータの内部では異なる文字コードとなっていることがありえるわけだが、インターネットのプロトコルにおいてそれら文字列が100 RFC3491

http://www.ietf.org/rfc/rfc3491.txt（原文）http://www.jdna.jp/survey/rfc/rfc3491j.html（日本語訳）
101 RFC3454
http://www.ietf.org/rfc/rfc3454.txt（原文）http://www.jdna.jp/survey/rfc/rfc3454j.html（日本語訳）

262

識別子として利用される場合には、そのような文字を同一のものとして扱えないと混乱が生じてしまうことになる。
このような、「文字コードとしては異なる文字だがインターネットのプロトコルにおいては同じ文字として扱いたい文字」について、 あらかじめ設定しておいた基準に従って標準形へと変換(文字列の正規化) するための枠組みを規定したものが STRINGPREP である。
(4) Punycode（RFC3492）102
国際化ドメイン名で使用される Unicode による文字列を、ASCII 文字のみからなる文字列に変換するためのアルゴリズムを Punycode と呼ぶ。
国際化ドメイン名の検討段階では、ACE（ASCII Compatible Encoding）変換のための方式の一つである RACE（Row-based ACE）と呼ばれるアルゴリズムが利用されていたが、RACE よりも優れた方式として AMC-ACE-Z (Adam M Costello 氏が考案した 26 番目の変換方式の意) と呼ばれる方式が提案され、標準として採用されることになった。その後、この AMC-ACE-Z は考案者により Punycode と名付けられた。
国際化ドメイン名を表すプレフィックスとして、 RACE では「bq--」（例：日本語ドメイン
名 EXAMPLE.com/bq--3bs6kzzmrkpdbsjq4eykimhtkqgqaziapaagcadnabyaa3aamu.
com）が使われていたが、 Punycode では「xn--」（例：日本語ドメイン名 EXAMPLE.com/
xn--example-6q4fyliikhk162btq3b2zd4y2o.com）が国際化ドメイン名を表すプレフィック
スとして規定されている。
なお、国際化ドメイン名の技術標準では無いが、非常に関係の深いURIの国際化に関連した技術標準として、RFC3986103とRFC3987104があり、特にRFC3987 が国際化ドメイン名との関連が深いRFCである。このRFCではIRI（Internationalized URI）が規定されており、URIに日本語などのマルチバイト文字を利用するための技術標準が定められている。
また、メールアドレスの国際化についても検討が進められており、ローカルパートの国際化に向けてIETFなどで標準化策定に向けて議論が続けられている。このローカルパートの
102 RFC3492

http://www.ietf.org/rfc/rfc3492.txt（原文）http://www.jdna.jp/survey/rfc/rfc3492j.html（日本語訳）
103 RFC3986
http://www.ietf.org/rfc/rfc3986.txt
104 RFC3987
http://www.ietf.org/rfc/rfc3987.txt

263

国際化に関するRFCとしては、現在のところRFC4952105が発行されている。

3-4 国際化ドメイン名における言語問題
IETF における国際化ドメイン名の標準化作業が進められた結果、2003 年 3 月 7 日に IDNA
（RFC3490）、NAMEPREP（RFC3491）、Punycode（RFC3492）の計三つの RFC が発行され、国際化ドメイン名の利用開始に必要な条件は、技術的には全て整ったことになった。
とはいえ、上記三つの RFC は、「文字」が持つ性質にのみ基づいた技術標準であり、「言語」の概念に対する配慮はなされていない。（ドメイン名は本来「言語」の概念を含まない「識別子」として設計されている。）これは技術標準としての性格から当然といえば当然ではあるのだが、実際に国際化ドメイン名の運用を行うにあたってはこれだけでは問題が発生してしまう可能性がある。これは、現在ではユーザがドメイン名の文字列自体に意味を見い出しつつあることに加え、従来の ASCII 文字列のみからなるドメイン名に対して国際化ド
メイン名が強く持つ、言語的・文化的側面が大きく影響している。
例を挙げると、言語の中には等価または等価に近い意味を持つ文字が存在する場合があり、このような中で国際化ドメイン名の登録に特段の制約も設けない場合には、サイバースク
ワッティング、あるいは、誤解や混乱を招くような文字の組み合わせで登録がなされるとの懸念がある。
特に、中国、台湾においては、繁体字（e.g. 國）と簡体字（e.g. 国）の問題があり、どの文字とどの文字を等価とすべきかについても、国際化ドメイン名の技術標準策定の際に大いに議論となった。また、ccTLD と異なり「国」との関連性を持たない gTLD においても、「言語」概念をどのように扱うべきかについても大きな問題となっていた。
これらの問題の解決については技術標準に頼るべきではない（技術標準に言語や文化に基づいた問題を持ち込むべきではない。技術標準は純粋に技術的要件についてのみ規定すべき。）という考えが強く、上記のような問題は、技術標準に関する議論に含めるべきではな
く、技術標準とは別の形で解決を図る方が望ましいという結論になった。その解決策として示されたのが IDN-admin ガイドラインおよび ICANN ガイドラインである。この
IDN-admin ガイドラインの内容については後述するので、ここでは詳細には触れない。
105 RFC4952

http://www.ietf.org/rfc/rfc4952.txt

264

3-5 各国の導入状況
本項では gTLD、ccTLD の順に、各 TLD における国際化ドメイン名の導入状況について説明する。
まず各レジストリへの国際化ドメイン名への対応を見ると、対応 TLD 数の増加という点では一昨年までは急速に増加していたものの、昨年はそれほどの増加を見せておらず、今年度の調査においてもその傾向に特に変化は無い。これは国際化ドメイン名の導入に積極的な TLD については既にレジストラがほぼ対応を終えているからだと考えてもよいのではないだろうか。
しかしながら、本年の調査より新たに国際化ドメイン名に対応した TLD もあり、また既に国際化ドメイン名の登録を開始していた TLD においても、新たに対応する言語が増えた
TLD があるなど、やはり国際化ドメイン名の普及は着実に進んでいると言える。また、特に対応する言語が増えていない TLD においても、これまで追加されていなかった IANA への言語テーブルの追加が、新たに行われた TLD もある。
国際化ドメイン名への対応方法には、大きく分けて二つの傾向があり、Unicode を元にしてその国や地域の言語に関係無くほぼ全ての文字を登録可能とするレジストリと、ウムラ
ウトなどに代表されるようなその国や地域などで使用されている言語独特の文字を追加的に利用可能としているレジストリに大別できるが、今回の調査によって新たに国際化ドメ
イン名への対応が判明した TLD は全て後者であった。これは昨年度の調査結果と同様である。
これはやはり、国際化ドメイン名の導入がより進んできたことにより、国際化ドメイン名
が、単に「どんな文字でも登録できるサービス」ではなく、「その国・地域の文化的・言語的背景を反映した文字列が利用できるサービス」として考えられている傾向が、ますます強まってきていると考えてよいのではないだろうか。
また、今回の調査でも、少しずつではあるが、中東圏で国際化ドメイン名のテストが開始されたことが確認できた。全体の傾向としては、昨年度までと同様にヨーロッパ系の言語を中心にサービスが展開されてきた国際化ドメイン名ではあるが、それ以外の言語圏についても、国際化ドメイン名のサービスが着実に広がりを見せてきており、この傾向は国際化ドメイン名導入の目的の一つでもある、地域ごとの言語や文化を反映した文字列を登録できるという特徴から考えても、もっともなことだと思われる。

265

また、ユーザへの情報提供の一環として、国際化ドメイン名で使用する言語テーブルを
IANA に登録することがレジストリの義務として掲げられているが、この言語テーブルの登録に関しても、徐々にではあるが各レジストリによる IANA への言語テーブルの登録が進んでいる。

3-5-1 .com/.net（VeriSign,Inc）の導入状況
昨年度の調査以降、.com/.net における国際化ドメイン名関連の大きな動きは特にない。
ただし、.com/.net は.jp と並び、最も早くから国際化ドメイン名の登録サービスが提供された TLD のひとつである。したがって、導入に際してはテストベッドの下での試行錯誤が行われるなど、他の TLD とは若干異なる経緯をたどっている。以下で、その導入の状況について説明する。
VeriSign,Incは、2000 年 11 月、テストベッドという位置付けにて.com/.net/.orgの国際化ド
メイン名の登録を開始した（その後、.orgの国際化ドメイン名は、.orgレジストリのPIR移管に伴い、VeriSign,Incの管理下ではなくなる）。このテストベッドの第一目的は、IETFにおける国際化ドメイン名の標準化作業への貢献とされたが、登録料は通常どおりに課金された。なお、IETFにおける標準化作業が当初の予想よりも長引いたこともあり、登録された国際化ドメイン名のその後の更新料請求は、数度にわたって延期された。
テストベッドは三つのフェーズに分けて進められた。第 1 フェーズは「レジストラの準備期間」である。国際化ドメイン名を扱うレジストラは別途そのための認可をVeriSign,Inc から受けなければならず、運用のためのテストを受けた後、認可されるという手続きがとられた。
（2007 年 2 月現在、VeriSign,Incの下で国際化ドメイン名を取り扱うレジストラの数
は 58 社であり、昨年の調査時の 62 社106からは微減となっている）。第 2 フェーズは「国際化ドメイン名の登録」である。これは文字どおり国際化ドメイン名の登録であるが、その一方でDNSのゾーンファイルへの設定はまだされないという段階である。登録されたドメ
イン名は「Registry Hold」というステータスとなり、他の人が登録できないものとの位置
付けがなされた。第 3 フェーズは「国際化ドメイン名の名前解決」である。これは、登録された国際化ドメイン名をDNSゾーンファイルに設定し、実利用できる状態に置くという

106 VeriSign,Inc Find IDN Registrars

http://www.verisign.com/information-services/naming-services/internationalized-domain-names/page_001397.html

266

ことを意味するが、既存のインターネットの名前空間への影響を考慮し、<国際化ドメイン
名>.mltbd.com という形で第 3 レベルに登録された文字列（国際化ドメイン名）を置くという措置がとられた。
第 3 フェーズに入った後、VeriSign,Incは国際化ドメイン名を促進するために、二つの対策をとっている。
(1) i-Navプラグイン
国際化ドメイン名は、レジストリ側が対応しても、エンドユーザのクライアント側（各種のアプリケーションソフトウェア）が対応しなければ利用することができない。国際化ドメイン名の標準化が定まらない段階においては、アプリケーション・ベンダーが対応する
可能性も小さく、この状態では、国際化ドメイン名を登録し、DNS のゾーンファイルに設定したとしても実際には使えないものとなってしまう。VeriSign,Inc はこの状況に対して、
自ら「i-Nav」というプラグインを開発。利用できる環境は一部に限定されているものの、
そのプラグインをブラウザ（Windows 98, ME, NT, 2000, XP 環境下の Internet Exporler
5.0, 5.5, 6.0）にインストールすることにより、アドレスバーへの国際化ドメイン名の入力
で、目的の Web サイトにアクセスできる環境づくりを実現した。また、同プラグインを利用することで、Outlook, Outlook Express を使って国際化ドメイン名を使ったメールアド
レスにメール送信ができるという環境も実現した。
なお、Internet Explorer 7 のリリースにより、今後は i-Nav プラグインを必要としないユーザが増えてくると思われるが、一方で Windows Vista および XP 以外の Windows OS には現在のところ Internet Explorer 7 はリリースされない予定であるため、そのような OSを使っているユーザにとっては、i-Nav を利用する状況はしばらくは続くものと思われる。
ただし、各 OS に対するサポート 期間の終了や、Windows Update 等の自動更新でのInternet Explorer 7 の配布などが始まっていることから、i-Nav を必要とするユーザは、徐々に減っていくことが予想される。
(2) Web Based Navigation
VeriSign,Inc は 2003 年 1 月より.com/.net を対象に Web Based Navigation というサービスを開始した。これは、国際化ドメイン名に対応していないブラウザから <国際化ドメイ
ン名>.com、<国際化ドメイン名>.net へのアクセスがあった場合、DNS を管理するレジス
トリ側でそれを感知し、そのアクセスユーザに対して、国際化ドメイン名対応環境（i-Nav
プラグイン）を案内する Web ページを表示するというものである。

267

その後、国際化ドメイン名は、2003 年 2 月に、3 つの RFC の発行によって標準化作業が完了したが、先に述べた言語問題があるため、レジストリは、技術標準への準拠とは別に
ICANN ガイドラインへの対応が迫られることとなった。
これに対して VeriSign,Inc は、その対応作業を進め、2003 年 10 月 13 日、ICANN に対して、対応方針を伝えると共に国際化ドメイン名の正式サービス開始の認可を求めるレターを送った。この結果、ICANN は 2003 年 12 月に VeriSign,Inc を認可。VeriSign,Inc は、
12 月 13 日より RACE から Punycode への移行作業を開始した。2004 年 4 月 23 日には従来の RACE でのドメイン名の登録受付を終了、Punycode でのみ登録を受け付けるようになった。
一方、VeriSign,Inc が運用するネームサーバの応答に関しては、Punycode への移行開始と共に、Punycode による名前解決の要求に応答するように変更が加えられたが、RACE による名前解決要求にも応答するように並行した運用が行われており、移行作業が完了してからかなり経つと見られる現時点においても、一部のドメイン名に関しては RACE での名前解決がまだ可能な状態となっている。
なお、ICANN が定めるガイドラインへの対応についてであるが、2003 年 10 月 13 日に国際化ドメイン名の登録をユーザに提供するための承認要請を ICANN に提出したものの、
ICANN からは 2008 年 2 月時点においても承認は下りておらず、そのため IANA のデータベースにも.com および.net の言語テーブルは登録されていない状況である。

3-5-2 .org（Public Interest Registry）の導入状況
2005 年までは大幅に対応言語を増やしていた.org だが、昨年の調査に引き続き、今回の調査においても.org の国際化ドメイン名を巡る状況に大きな変化はなかった。2007 年 3 月より、対応言語として新たにスペイン語が追加されたのみである。
このように現在でこそ落ち着いた動きを見せているが、.org の登録者は国際化ドメイン名
導入当初、激しい混乱に見舞われた。以下でその状況について説明する。
.org は、国際化ドメイン名の導入当初はまだ VeriSign,Inc が登録管理業務を行っており、そのような状況から.com/.net と同様の状況であった。しかし、.org の登録管理業務が PIRに移管されたことから、その後は.com/.net とは異なる展開を辿ることとなった。

268

2003 年 1 月の VeriSign,Inc から PIR への登録管理業務の移管後、.org の国際化ドメイン
名は新規の登録受付および既存の登録ドメイン名の変更が一切できない状態とされていた。
その後、2003 年 12 月、レジストラに対して、既存の国際化ドメイン名を一切廃止し、今後その登録はしない旨のアナウンスが突然出されるという事態が発生したが、レジストラ等の強い反対により、その方針が覆されるという状況になっている。
このように紆余曲折のあった.org の国際化ドメイン名だが、2005 年 1 月 18 日付のプレス
リリースでドイツ語文字のウムラウト(“a”“o”および“u”の変音文字)を使用した国際化
ドメイン名の登録を開始したと発表した。PIR では、さらに対応言語を増やし、現在では、
ドイツ語、デンマーク語、ハンガリー語、アイスランド語、韓国語、ラトビア語、リトア
ニア語、ポーランド語、スウェーデン語、スペイン語を使用した国際化ドメイン名の登録を受け付けている。また、これらの言語テーブルは IANA にも登録されているが、直近に登録の受け付けが開始されたスペイン語だけは、まだ IANA には登録されていない。

3-5-3 .info（Afilias）の導入状況
昨年度の調査以降、.info における国際化ドメイン名関連の大きな動きは無い。
以下で.info への国際化ドメイン名の導入状況について説明する。
2004 年 3 月 16 日、.info を管理している Afilias 社は、ドイツ語文字のウムラウト(“a”“o”
および“u”の変音文字)を使用したドメイン名の登録を開始、翌日 3 月 17 日 13:00（協定世界時）の時点で、13,000 件を超えるドイツ語文字を使用したドメイン名が登録されたことが発表された。
なお、3 月 16 日から 4 月 14 日の間に登録されたドメイン名については、紛争の発生に備
え、レジストリによりロック状態に置かれた。紛争が発生しなかったドメイン名については、その後ロック状態が解除され通常の使用が可能になるという仕組みである。また、4 月
14 日以降に登録されたドメイン名については、ロックされることなく通常の登録が行われた。
その後、2006 年 10 月に、ポーランド語、スウェーデン語、デンマーク語、ハンガリー語、
アイスランド語、ラトビア語、リトアニア語、韓国語の登録受け付けが開始され、現在に至っている。

269

ただし、現在のところ IANA に登録されている言語テーブルはドイツ語のみとなっている。

3-5-4 .museum（MuseDoma）の導入状況.museum は国際化ドメイン名の導入に積極的なレジストリであり、一昨年の調査まではかなりの勢いで対応言語を増やしていたが、今回の調査では特に新しい動きはなかった。
.museum を管理している Museum Domain Management Association（MuseDoma）は、2004 年 1 月 22 日、国際化ドメイン名の登録を開始したと発表した。
当初対応するのは、一部のヨーロッパ系言語（デンマーク語、ノルウェー語、スウェーデン語）のみだが、MuseDoma では、グローバルコミュニティのニーズにこたえるため、できるだけ早急に対応する文字を拡大する姿勢を見せており、現在ではドイツ語、フランス
語、ポーランド語、スペイン語など、計 25 の言語をサポートしている。
ただし、IANA に言語テーブルが登録されているのは、デンマーク語、アイスランド語、ノルウェー語の三つである。スウェーデン語については、一昨年の調査時点では登録されていたが、現在では IANA から登録が削除されている。
また、対応予定の言語としては、MuseDoma のサイトで、アラビア語、中国語、日本語、
韓国語、キリル文字、ギリシャ文字、ヘブライ文字などが挙げられている。

3-5-5 .biz（Neulevel）の導入状況.biz の導入状況だが、昨年度の調査時点と比べて登録可能な文字が大幅に追加された。
昨年度の調査時点では 6 言語だったものが、15 言語と倍以上に増えている。
以下、.biz のこれまでの状況について説明する。
.biz を管理している NeuLevel,Inc.は、ドイツ語文字のウムラウト (“a”“o”および“u”の変音文字)を使用した国際化ドメイン名の登録を 2004 年 10 月 12 日より開始した。 .museum、.info に続き、ICANN の定めるガイドラインに沿った形での国際化ドメイン名が導入される gTLD としては、この.biz が 3 番目の TLD となった。その後、登録可能

270

な文字の追加が次々と行われた。2007 年には大幅に文字の追加が行われ、まず 4 月には従来のドイツ語、デンマーク語、アイスランド語、ノルウェー語、スペイン語、スウェーデ
ン語の六つの言語に加え、中国語と日本語が登録可能となった。続いて、8 月には韓国語の登録受け付けが開始された。また、2008 年 1 月からは、フィンランド語、ハンガリー語、ラトビア語、リトアニア語、ポーランド語、ポルトガル語の文字が登録可能となっている。
当初、IANA には言語テーブルとしてドイツ語のみが登録されていたが、現在ではそれに加え中国語、デンマーク語、アイスランド語、日本語、韓国語、ノルウェー語、スペイン度、
スウェーデン語が登録されている。中国語、日本語、韓国語の三つは、この 1 年間で新たに登録された言語である。

3-5-6 .cat（Fundacio puntCat）の導入状況.cat は新しく承認された gTLD であり、言語および文化的特徴の強い gTLD である。
一昨年の調査で国際化ドメイン名への対応を予定していることが新しく判明したものの、昨年の調査においては特に具体的な動きは判明していなかったが、今年の調査では 11 のカ
タロニア文字のサポートが開始されていることが判明した。ただし、具体的な登録開始時
期は不明である。
.cat はカタロニアの言語／文化用のドメイン名との位置付けから、.cat を管理している
Fundacio puntCat では、カタロニア語でのドメイン名登録をサポートしている。
IANA への言語テーブルの登録については、2008 年 2 月時点ではまだカタロニア語の言語
テーブルは登録されていない。

3-5-7 .jp（日本）（JPRS）の導入状況.jp も.com/.net と並び、もっとも早くから国際化ドメイン名に取り組んできた TLD のひとつである。技術標準などへの対応についても他のレジストリに先駆けて取り組みを行っており、そのような意味で、.jp における導入状況という点では昨年度と比較して特に大きな
動 きは無い。技術的な要素については既に対応を終えており、また懸念事項であったInternet Explorer の国際化ドメイン名対応も完了したことから、ユーザへの周知や新しい利用法の提案などに対応の比重を移しているように見受けられる。現在、JPRS は国際化ドメイン名のユーザへの普及・啓発という点に非常に力を入れている。

271

.jp の国際化ドメイン名への取組みは、JP ドメイン名の登録管理業務が社団法人日本ネット
ワークインフォメーションセンター（JPNIC）によって行われていた時代にまで遡ることが出来る。
1999 年 5 月に JPNIC 内に iDNS 調査研究タスクフォースが設立されたのを皮切りに、本格的に国際化ドメイン名実現に向けた取組みが開始されることになる。
JPNIC ではその後も検討を進め、2000 年の 11 月には、
「汎用 JP ドメイン名登録等に関する技術細則」
が制定され、
日本語 JP ドメイン名として利用可能な文字が明確に定義された。
このことにより、国際化ドメイン名を導入するための前提がまずは一つ整ったことになる。
続いて同じく 11 月に、日本語 JP ドメイン名のエンコード方式として ACE（ASCII
Compatible Encoding）という変換方式の一種である RACE（Row-based ACE）と呼ばれる技術を用いる方式で、日本語 JP ドメイン名運用試験のフェーズ 1 が開始された。
もっとも、このフェーズ 1 においては、実際に各種アプリケーションを利用して日本語 JP
ドメイン名を利用するというものではなく、日本語 JP ドメイン名が DNS にどのような形
で設定・運用されるのかを確認するための環境を提供するという基本的なものであった。
そして、このフェーズ 1 の結果を受けて、2001 年には日本語 JP ドメイン名の登録が開始された。日本語 JP ドメイン名は汎用 JP ドメイン名として受け付けられ、2001 年 2 月には優先登録が、4 月には同時登録が開始され、実験段階から実際に登録が可能となるという次のステップへと移行した。
しかし、登録は開始されたものの、IETF などによる国際化ドメイン名の技術標準化にはまだ時間がかかっており、そのためまだテスト的な意味合いも強い部分が残っていたのも事実であり、検討と運用が同時に行われるような状態がしばらく続くこととなった。
その後、2001 年 3 月には ICANN に IDN Committee が設立されるなど、IDN に関する検討も徐々に進展し、現在標準となっている ACE や NAMEPREP、IDNA といった技術が主流とみなされるような状況となったことから、徐々にではあるが国際化ドメイン名の実用化に向けた環境が整うようになってきた。
そして、JPNIC は 2001 年 5 月に日本語ドメイン名運用試験のフェーズ 1 を終了し、フェーズ 2 を開始した。このフェーズ 2 では、汎用 JP ドメイン名として登録された日本語 JP
ドメイン名について、RACE を用いた方式での名前解決が可能となり、実際に登録した国272

際化ドメイン名を使って名前解決をすることが可能となった。
その後、JPNIC から JPRS へと JP ドメイン名の登録管理業務が移管された後も、JPRS
において日本語ドメイン名に関する検討は続けられ、2003 年 3 月の国際化ドメイン名の技
術 標 準 を 規 定 し た 3 本 の RFC （ IDNA:RFC3490 、 NAMEPREP:RFC3491 、Punycode:RFC3492）の発行、および 2003 年 6 月に ICANN から発表された「IDN 実装のためのガイドライン」を受け、2003 年 6 月 30 日に日本語ドメイン名運用試験のフェー
ズ 2 終了をアナウンスした。
実際のフェーズ 2 終了は 2003 年 7 月 10 日に行われ、9 月 3 日までかけて日本語 JP ドメ
イン名のサービスを RFC に準拠したサービスへと移行させるための作業が行われた。移行にあたっては、次の 3 つのステップを踏むことによって、ユーザの混乱を最小限に抑える
ための努力が払われた。
(1) JP DNS での RACE と Punycode の併用期間開始（7 月 10 日）
JPRS が運用している.jp の DNS サーバに、これまでの RACE に加えて Punycode でもドメイン名が登録されるようになった。これにより、RFC に完全準拠した、Punycode で名前解決を行うアプリケーションからも日本語 JP ドメイン名の利用が可能となった。
(2) InternetExplorer 用 plug-in ソフト(i-Nav)の内部動作切り替え（7 月 30 日）
JPRS が配布しているブラウザ用のプラグインソフトである i-Nav の内部動作について、
RACE 優先から Punycode 優先へと切り替えが行われた。
(3) JP DNS での RACE の運用終了（9 月 3 日）
.jp の DNS サーバから RACE の設定の削除が行われた。
これにより、JP ドメイン名の RFC への準拠作業は完全に終了したことになる。
現在、.jp では携帯電話からの国際化ドメイン名を使ったアクセスのためのサイトを用意したり、駅名でアクセスできる駅周辺の情報提供ポータルサイトを用意するほか、登録者が希望した場合に、国際化ドメイン名に対応していないブラウザからアクセスしたユーザを、
国際化ドメイン名のナビゲーションサイトに誘導するように出来るサービスを提供するな
ど、国際化ドメイン名の普及に大変力を入れている。またこれらの他にもレジストリ自らが国際化ドメイン名を用いた新しいサービスを積極的に展開しており、コミュニティに対して国際化ドメイン名ならではの利用方法を積極的に示し続けている。また、VeriSign 社とならんで技術情報の公開などにも積極的である。

273

このように、.jpは世界でも最も国際化ドメイン名を利用する環境が整っているTLDのひとつであると思われる。実際、登録数の方にもその結果は反映されており、JPRSの発表によると、2008 年 2 月時点での国際化ドメイン名の登録数は約 14 万件であり、全体の登録数
約 99 万件のうちの約 7 分の 1 を占めるまでになっている。107
なお、IANA の言語テーブルには日本語が登録されている。

3-5-8 .kr（韓国）（Korea Network Information Center）の導入状況.kr では昨年度の調査以降、特に大きな動きはない。
.kr を管理している KRNIC(NIDA:韓国情報通信開発振興庁)は、2003 年 8 月 19 日から国際化ドメイン名の登録を開始した。
国際化ドメイン名の登録にあたっては、混乱を避けるために 3 段階の登録期間が設けられた。
まず、1 段階目の期間(8 月 19 日から 6 週間)には公共機関、ブランド、商号名などを基にしたドメイン名の登録が受け付けられた。
次に、2 段階目の期間(10 月 7 日から 2 週間)には、住民登録証や事業者登録証を基にドメイン名の登録を受け付けた。
この１段階目と 2 段階目で重複した申込みがあれば抽選で登録者を決める方式を取り、これらの手順が全て完了してから、最後に 3 段階目として通常の先願制による登録受付が開始された。
IANA の言語テーブルには韓国語が登録されている。

107 JPドメイン名の累計登録数

http://jpinfo.jp/stats/domains.html

274

3-5-9 .pl（ポーランド）（NASK：Research and Academic Computer Network）の導入状
況.pl は国際化ドメイン名の導入に積極的な TLD である。
一昨年の調査まではかなりの勢いで対応言語を増やしていたが、対応が一通り終了したのか、昨年に引き続き、今回の調査でも特に新しい動きはなかった。
2003 年 9 月 11 日に国際化ドメイン名の登録を開始。当初はポーランド語のみの登録受付であったが、2003 年 10 月 6 日にはドイツ語文字のウムラウト (“a”“o”および“u”の変音文字)を利用したドメイン名の登録受付も開始した。
その後もラテン文字やギリシャ文字、ヘブライ文字、アラビア文字など次々とサポートする言語を増やしており、2004 年 2 月 26 日にはキリル文字のサポートも開始している。現
在 IANA に登録されている言語テーブルは 37（アルバニア語、ベラルーシ語、ブルガリア語、カタロニア語、クロアチア語、チェコ語、デンマーク語、オランダ語、エスペラント語、エストニア語、フィンランド語、フランス語、ドイツ語、ヘブライ語、ハンガリー語、
ギリシャ語、アイスランド語、アイルランド語、イタリア語、ラトビア語、リトアニア語、
ルクセンブルグ語、マケドニア語、マルタ語、モルダビア語、ノルウェー語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、セルビア語、スロバキア語、スロベニア語、スペイン語、スウェーデン語、トルコ語、ウクライナ語）となっており、gTLD、ccTLD を併せた全ての TLD の中で最も多い登録となっている。ただし、一昨年の調査時点からは特に増えておらず、そういう意味では予定していた言語をほぼ全てサポートし終えたと考えてもよいのかもしれない。

3-5-10 .th（タイ）（ThNIC）の導入状況.th では昨年度の調査以降、特に大きな動きはない。
2004 年 7 月からタイ語での国際化ドメイン名の登録を開始している。
IANA にはタイ語の言語テーブルが登録されている。

3-5-11 .de（ドイツ）（DENIC eG）の導入状況.de では昨年度の調査以降、特に大きな動きはない。

275

2004 年 3 月から国際化ドメイン名の登録を開始、従来の 7bit ASCIIで表現される 37 文字に加え、新たに 92 文字がドメイン名のラベルとして利用できるようになった。利用可能な文字の一覧は、DENICのWebページ108で公開されている。
現時点では IANA に言語テーブルは登録されていない。

3-5-12 .ch/.li（スイス／リヒテンシュタイン）（SWITCH Teleinformatics Services）の導入状況.ch および.li の双方とも、昨年度の調査以降特に大きな動きはない。
SWITCH は.ch（スイス）と.li（リヒテンシュタイン）のレジストリを兼ねている。
2004 年 3 月から国際化ドメイン名の登録を開始している。
新たに登録可能となった文字として、SWITCH の Web サイトでは 31 文字の変音文字が挙げられている。
現時点では IANA に言語テーブルは追加されていない。

3-5-13 .at（オーストリア）（NIC.AT Internet Verwaltungs und Betriebsgesellschaft
m.b.H）の導入状況.at では、昨年度の調査以降、特に大きな動きはない。
2004 年 3 月から国際化ドメイン名の登録を開始している。
従来の 7bit ASCII の文字に加え、新たに 34 文字がドメイン名のラベルとして利用可能になっている。
現時点では IANA に言語テーブルは追加されていない。

108 IDN character list

http://www.denic.de/en/domains/idns/liste.html

276

3-5-14 .dk（デンマーク）（DK Hostmaster A/S）の導入状況.dk では昨年度の調査以降、登録規則の改訂が行われた。ただし、国際化ドメイン名に関連する規定の変更は無い。また、登録規則改定以外に特筆すべき大きな動きは無い。
dkの登録規則（General conditions for the assignment, registration and administration of
domain names under the .dk top level domain (Version 04 March 1, 2008)）109 の「12.1文字セットを拡張する権利」によると、登録可能文字の追加については次のようなルールとなっている。

12.1

文字セットを拡張する権利

デンマークドメイン名の文字セットは、www.dk-hostmaster.dk の Web サイトにていつでも一般に見られるものとする。文字セットの拡張は、DIFO（Dansk Internet
Forum）との協議の上、最低 1 ヶ月の予告期間をもって、DK Hostmaster によって行われる。なお、変更部分が有効とされるにあたっては、事前に新規文字セットが十分な
技術力によって確実にサポートされることとする。また、正当な疑義の申し立てであると認められる範囲内において、提案されている変更に対して一般の人々がコメントを述べる機会を設けるものとする。

現在、登録可能な文字としては 7 文字(å,æ,ø,ä,ö,ü,é)が挙げられている。110
また、現時点では IANA に言語テーブルは追加されていない。

3-5-15 .lt（リトアニア）（KTU Information Technology Development Institute）の導入状
況.lt では昨年度の調査以降、特に大きな動きはない。
2003 年 3 月 30 日から国際化ドメイン名の登録を開始している。
リトアニア語として 9 文字(ą, č, ę, ė, į, š, ų, ū, ž)の登録が可能となっている。

109 http://www.dk-hostmaster.dk/fileadmin/filer/pdf/generelle_vilkaar/generelle_vilkaar_EN04.pdf
110 Et domænenavn er en navngivet og afgrænset del af internettet

http://www.dk-hostmaster.dk/index.php?id=21277

登録可能な文字については、以下の URL にて示されている。
Allowed characters in .lt second level IDN domain name Unicode representation
http://www.domreg.lt/static/doc/public/idn_symbols-en.pdf
なお、現時点では IANA に言語テーブルは追加されていない。

3-5-16 .se（スウェーデン）（NIC-SE）の導入状況.se では昨年度の調査以降、新たに五つの言語での登録受け付けが開始された。
2003 年 10 月より、5 つの文字（a、a、o、u、e）を登録可能文字として追加する形で IDNの登録を開始していたが、2007 年 9 月に新たにデンマーク語、フェロー語、アイスランド
語、ノルウェー語の登録が可能となった。これらの言語は、フィンランドに住む五つの少数民族の公用語である。
IANA には、現時点ではスウェーデン語の言語テーブルのみが登録されている。

3-5-17 .tw（台湾）（TWNIC）の導入状況.tw では昨年度の調査以降、大きな動きは特にない。
2003 年 11 月 17 日より、Punycode を用いる形での、RFC に準拠した IDN 登録サービスへの移行を行った。
IANA には言語テーブルとして繁体中国語が登録されている。

3-5-18 .cn（中国）（CNNIC）の導入状況.cn では昨年度以降、大きな動きは特にない。
「.公司」、「.网絡」という３つの中国語 TLD の下に CDN（Chinese.cn では、従来から「.中国」、
Domain Name：中国語ドメイン名）が登録できるようになっており、さらに、「.中国」には「.CN」の CDN がバンドルされる形になっていた。

278

しかし、国際化ドメイン名のトップレベルドメインはまだ ICANN で承認されておらず、したがって上記三つの中国語 TLD はルートゾーンには含まれていないものと考えられる。
このように、国際化ドメイン名に関してはやや独自の路線を取っていた中国であるが、2005 年 1 月 17 日から海外からの「中国語.cn」の形での国際化ドメイン名の登録を開始したと発表した。これにより、他の TLD で行われている国際化ドメイン名のサービスと同様に、セカンドレベル以下にマルチバイト文字列を登録出来るようになった。
なお、この登録受付開始に関しては、CNドメイン名の国外での登録受付を行っている
Neulevelからプレスリリースが出されている。111
また、IANA には言語テーブルとして中国語が登録されている。

3-5-19 .hu（ハンガリー）（ISZT Kht）の導入状況.hu では昨年度の調査以降、大きな動きは特にない。
登録規則によると、通常のASCII文字に加えて 9 文字(á,é,í,ó,ö,ő,ú,ü,ű)のハンガリー語の文字が登録可能となっている。112
なお、現時点では IANA に言語テーブルは追加されていない。

3-5-20 .is（アイスランド）（ISNIC - Internet Iceland ltd.）の導入状況.is では昨年度の調査以降、大きな動きは特にない。
以下に.is での国際化ドメイン名の導入時の状況について説明する。
2004 年 7 月 1 日から国際化ドメイン名の登録受付を開始。登録が認められる文字として、
従来の ASCII 文字に加えて新たに 10 文字(þ,á,í,æ,é,ó,ö,ý,ð,ú)が追加された。なお、通常の

111 NeuLevel Introduces Chinese Language Internationalized Domain Names (IDNs) In China’s .CN
Domainhttp://www.neulevel.BIZ/press/press_release/IDN.CNrelease1-18-05.pdf
112 DOMAIN REGISTRATION RULES AND PROCEDURES
http://www.domain.hu/domain/English/szabalyzat/szabalyzat.html

279

登録に先立って、2005 年 1 月 1 日までがサンライズ登録期間とされた。
なお、現時点では IANA に言語テーブルは追加されていない。

3-5-21 .ac（アセンション島）（Ascension Island Network Information Centre）の導入状
況.ac では昨年度の調査以降、大きな動きは特にない。
現在、NIC.ACのサイトでは、登録可能な文字として 84 文字が挙げられている。113
なお、現時点では IANA に言語テーブルは追加されていない。

3-5-22 .br（ブラジル）（Comite Gestor da Internet no Brasil）の導入状況.br では昨年度の調査以降、大きな動きは特にない。
2005 年 5 月 4 日に Registro.br は、ポルトガル語でのドメイン名の登録受付を開始する旨の発表を行い、5 月 9 日より実際に登録の受付を開始した。
IANA にはポルトガル語の言語テーブルが登録されている。

3-5-23 .cl（チリ）（NIC Chile）の導入状況.cl では、昨年の調査時点ではまだ行われていなかった、IANA への言語テーブルの登録が行われた。
NIC Chileは 2005 年 9 月 21 日よりスペイン語でのIDNの登録を開始しており、114
Webサイトでは、登録可能な文字として 7 文字(á, é, í, ó, ú, ü, ñ)が挙げられている。115

113 IDN Code Points Policy for the .AC Top Level Domain

http://www.nic.ac/AC-IDN-Policy.pdf

114 Comenzo la inscripcion de dominios IDN en .CL

http://www.nic.cl/anuncios/2005-09-21.html

115 SYNTAX RULES FOR DOMAIN NAMES UNDER .CL

http://www.nic.cl/CL-IDN-policy.html

280

IANA にはスペイン語の言語テーブルが登録されている。

3-5-24 .fi（フィンランド）（Finnish Communications Regulatory Authority）の導入状況.fi では昨年度の調査以降、大きな動きは特にない。
FICORAは 2005 年 9 月 1 日より、登録可能な文字として新たに 3 文字(å,ä,ö)を追加すると発表している116。
現時点では IANA に言語テーブルは追加されていない。

3-5-25 .gr（ギリシャ）（ICS-FORTH GR）の導入状況.gr では昨年度の調査以降、大きな動きは特にない。
ICS-FORTH GR は、2005 年 7 月 4 日よりギリシャ文字でのドメイン名登録を開始すると発表した。Webサイトでは登録可能な文字として 22 文字が挙げられている117。
現時点では IANA に言語テーブルは追加されていない。

3-5-26 .io（英領インド洋地域）（IO Top Level Domain Registry）の導入状況.io では昨年度の調査以降、大きな動きは特にない。
登録の開始時期は不明であるが、現在、NIC.IOのサイトでは、登録可能な文字として 84
文字が挙げられて118いる。
現時点では IANA に言語テーブルは追加されていない。

116 http://www.ficora.fi/en/index/palvelut/fiverkkotunnukset/aakkostenkaytto.html
117 GREEK HOMOGRAPH CHARACTER TABLE

https://grweb.ics.forth.gr/CharacterTable2_en.jsp

118 IDN Code Points Policy for th .IO Top Level Domain

http://www.nic.io/IO-IDN-Policy.pdf

281

3-5-27 .lv（ラトビア）（University of Latvia）の導入状況.lv では昨年度の調査以降、大きな動きは特にない。
NIC.LVは、2004 年 3 月 1 日よりラトビア語でのドメイン名登録の受付を開始したと発表した。現在、登録可能な文字として 13 文字(ā, ē, ī, ū, ō, ķ, ļ, ņ, ŗ, ģ, š, č, ž)が挙げられて119いる。
現時点では IANA に言語テーブルは追加されていない。

3-5-28 .no（ノルウェー）（UNINETT Norid A/S）の導入状況.no では昨年度の調査以降、大きな動きは特にない。
Noridは 2004 年 2 月 9 日に登録規則の改訂を行い120、ノルウェー語でのドメイン名登録の受付を開始した。現在、Webサイトでは、登録可能な文字として 23 文字が挙げられている
121。

現時点では IANA に言語テーブルは追加されていない。

3-5-29 .nu（ニウエ）（Internet Users Society - Niue）の導入状況.nu では昨年度の調査以降、大きな動きは特にない。
.nu では、厳密には国際化ドメイン名とは言えないものの、類似のサービスを提供している。
ただし、サービスの開始時期は不明である。
.nuドメイン名では、Multi-Lingual Web Addressesというサービス名で、UNICODE ISO-10646 に準拠したドメイン名の登録を受け付けており122、スウェーデン語やデンマー

119 Vispārīgie noteikumi domēna vārda lietošanas tiesību iegūšanai

http://www.nic.lv/DNS/
120 Change of regulations February 9th 2004
http://www.norid.no/regelverk/forslag/idn-2003/2004-02-09.en.html
121 New characters permitted under .no
http://www.norid.no/domeneregistrering/idn/idn_nyetegn.en.html
122 .NU Domain Multi-Lingual Web Addresses282

ク語、ノルウェー語、ドイツ語、スペイン語などでのドメイン名の登録が可能と謳っている。
また、それ以外の日本語や中国語、韓国語、アラビア語、キリル文字、ヘブライ文字を用いたドメイン名登録についても、WorldNames 社が提供しているサービスを用いることによって登録が可能としている。
なお、IANA への言語テーブルの登録は行われていない。

3-5-30 .sh（セントヘレナ島）（Government of St. Helena）の導入状況.sh では昨年度の調査以降、大きな動きは特にない。
登録開始時期は不明であるが、現在、NIC.SHのWebサイトでは、登録可能な文字として 84
文字が挙げられている123。
現時点では IANA に言語テーブルは追加されていない。

3-5-31 .hk（香港）(Hong Kong Internet Registration Corporation Ltd.) の導入状況.hk では、昨年度の調査以降、大きな動きは特にない。
HKIR&HKDNR(Hong Kong Domain Name Registration Company Limited)では、2006
年 10 月より、中国語ドメイン名の登録を受け付けている。
IANA に言語テーブルは登録されていないが、HKIR の Web サイトに掲載されている FAQによると.cn および.tw の言語テーブルをベースとした言語テーブルを用意しているとのことで、繁体字および簡体字を用いたドメイン名の登録が可能と思われる。
なお、現時点では IANA に言語テーブルは追加されていない。

http://www.nunames.nu/Local-Language.cfm
123 IDN Code Points Policy for th .SH Top Level Domain
http://www.nic.sh/SH-IDN-Policy.pdf

283

3-5-32 .vn（ベトナム）(VNNIC) の導入状況.vn では昨年度の調査以降、大きな動きは特にない。
登録開始時期は不明であるが、.vn では国際化ドメイン名の登録を受け付けており、
VNNICのサイトでは、ベトナム語の登録可能な文字が公開されている。124
なお、現時点では IANA に言語テーブルは登録されていない。

3-5-33 .ae（アラブ首長国連邦）(UAEnic) の導入状況.ae では昨年度の調査以降、大きな動きは特にない。
.ae では、登録開始時期は不明であるが、国際化ドメイン名のテストサービスを行っている。
UAEnicでは、現在アラビア語ドメイン名のテストを行っており、UAEnicのWebサイトで詳細を見ることができる。125現在は 18 のアラビア語ドメイン名が使用可能となっている。
126

なお、現時点では IANA に言語テーブルは登録されていない。

3-5-34 .tm（トルクメニスタン）(TM Domain Registry Limited) の導入状況.tm では昨年度の調査以降、大きな動きは特にない。
.tmでは、登録開始時期は不明であるが、国際化ドメイン名の登録を受け付けており、TM
Domain RegistryのWebサイトでは、登録可能な文字として 84 文字が挙げられている。127

124 Các ký tự dùng cho tên miền tiếng Việthttp://www.tenmientiengviet.vn/bangma.htm
125 Trial of Arabic Domain Names
http://nic.ae/english/arabicdomain/index.jsp
126 http://idn.nic.ae/daleel/
127 IDN Code Points Policy for the .TM Top Level Domain
http://www.nic.tm/TM-IDN-Policy.pdf

284なお、現時点では IANA に言語テーブルは登録されていない。

3-5-35 .tr（トルコ）(Middle East Technical University) の導入状況.tr では昨年度の調査以降、大きな動きは特にない。
.trでは、2006 年 11 月から、登録可能な文字列にトルコ語が追加された128。現在のところ、登録可能な文字は 6 文字(ğ, ı, ü, ş, ö, ç)となっている。
なお、現時点では IANA に言語テーブルは登録されていない。

3-5-36 .es（スペイン）（Red.es）の導入状況.es では今年度の調査で国際化ドメイン名の登録を開始していることが判明した。
登録は 2007 年 10 月より開始され、登録可能な文字列にスペイン語が追加された。登録可
能な文字として、Red.esのWebサイトで 13 文字が公開されている。129
なお、現時点では IANA に言語テーブルは登録されていない。

3-5-37 .ir（イラン）（Institute for Studies in Theoretical Physics & Mathematics (IPM)）の導入状況.ir では今年度の調査で国際化ドメイン名の登録を開始していることが判明した。
ただし、従来の TLD（.ir）での登録は受け付けておらず、IPM(Institute for Studies in
Theoretical Physics & Mathematics )が行っている、「dot-iran ( .‫)اﯾـــــــــران‬. 」と呼ばれる
IDN TLD のサービスでのみ登録を受け付けている。

128 Turkish character encoded domain name system is launched!

https://www.nic.tr/announcebox.php?PHPSESSID=11709197332021230161210880&ann_id=221

129 ORDER ISSUED BY THE DIRECTOR-GENERAL OF THE PUBLIC BUSINESS ENTITY RED.ES

ON MULTILINGUAL CHARACTERS UNDER “.ES”
https://www.nic.es/descargas/idn_executive_order_2007.pdf

285

登録が可能な文字については、IPMのWebサイトで公開されている。130
また、IANA にも言語テーブルとしてペルシャ語が登録されている。

3-5-38 .pe（ペルー）（Red Cientifica Peruana）の導入状況.pe では今年度の調査で、国際化ドメイン名の登録を開始していることが判明した。
登録の開始時期は不明であるが、2007 年 9 月に解放されたセカンドレベルにおいて、スペ
イン語の登録が可能となっており、Red Cientifica PeruanaのWebサイトでは、登録可能な文字として「á, é, í, ó, ú, ñ, ü」が公開されている。131
なお、現時点では IANA に言語テーブルは登録されていない。

3-5-39 .pt（パレスチナ）（Ministry Of Telecommunications &Information Technology,
Government Computer Center.）の導入状況.pt では今年度の調査で国際化ドメイン名の登録を開始していることが判明した。
Fundacao para a Computacao Cientifica Nacionalでは、2005 年 7 月よりポルトガル語の登録を受け付けている。132
また、Web サイトでは、登録可能な文字として「à,á,â,ã,ç,é,ê,í,ó,ô,õ,ú」の 12 文字が公開されている。
なお、現時点で IANA への言語テーブルの登録は行われていない。

130 Allowable Characters (under dot-iran)

http://www.nic.ir/Allowable_Characters_dot-iran

131 COMISION MULTISECTORIAL DE POLITICAS DE NOMBRES DE DOMINIO

http://www.nic.pe/InformeFinalComision.pdf

132Domínios IDN (Internationalized Domain Names)

https://online.dns.pt/dns_2008/do?com=DS;3068250627;111;+PAGE(4000002)+K-NOTICIA(714)+K-CA
T-CODIGO(C.128)+RCNT(1);2863-6 IDN に関する動向
現在、ドメイン名の最も右側の文字列（「com」、「jp」など）は約 270 種類存在する。これは、TLD（Top Level Domain：トップレベルドメイン）と呼ばれている。近年、世界の各
TLD において、英数字でなく日常的に使用している文字を第 2 レベル以下のドメイン名ラベルとして用いる動きが広がっている。これは、IDN（Internationalized Domain Name：
国際化ドメイン名）と呼ばれ、世界で約 40 の TLD がすでに導入しているといわれる。
さらに 2006 年頃からは、非英語圏の地域、国々、ユーザから、日常的に使用している文字
を TLD でも使いたいという要求が高まってきた。これらは、IDN TLD と呼ばれ、特に ccTLDに相当する IDN TLD は IDN ccTLD、gTLD に相当する IDN TLD は IDN gTLD と呼ばれることが多い。
IDN TLD については、IETF と ICANN を中心に、技術的な検証と技術ガイドラインの作成、実証実験が先行していたが、2007 年に入ると、実際の導入に向けてポリシー面の検討
が ICANN で急速に進展してきた。以下では、IDN TLD のポリシーに関する検討状況、技術と運用に関する検討状況、IDN 標準およびアプリケーションの対応に関する状況を述べる。

3-6-1 IDN TLD のポリシーに関する検討状況
3-6-1-1 gTLD
gTLD におけるポリシーの検討や調整は、ICANN GNSO（Generic Names Supporting
Organisation：分野別ドメイン名支持組織）で行われている。最近、GNSO では、新しい
gTLD の創設に関するポリシーの検討に力を入れており、そこでは、ASCII 文字だけからなる gTLD のみでなく、IDN gTLD も対象として扱われている。
GNSO では、2009 年第 1 四半期中の新 gTLD（ASCII および IDN の双方）の創設を目標とし、分科会を設けるなどして各種の検討を行ってきた。2007 年 8 月、GNSO は新 gTLD
創設のポリシーに関する最終報告書を ICANN 理事会に提出し、その報告書は同年 11 月に理事会に承認された。この報告書に含まれる主なポイントは以下の 3 点である。
・新 gTLD の文字列は、既存 TLD の文字列または予約名と誤認するほど類似してはならない

287

・新 gTLD の文字列は、他者の法的利益（商標権など）を侵害してはならない
・新 gTLD の文字列は、倫理と社会的秩序に関する法的規範に反してはならない
ただし、上記の「予約名」には「国の名称」および「その略称」が含まれていない。その理由は、「国の名称」および「その略称」とは何かという定義が実質的に困難であるというものであり、明示的に「国の名称およびその略称は予約名にすべきでない」と判断した訳ではない。そのため、国の名称およびその略称を持つ gTLD が創設された場合、ccTLD との混乱が生じる可能性がある。また、IDN gTLD および IDN ccTLD においては文字の種類
および TLD を表す文字数が増えるため、混乱はさらに大きくなるおそれもある。さらに、
このような混乱が生じた場合、国の名称に関する主権の議論にも発展しかねない。
これを問題視した ccNSO（Country Code Names Supporting Organisation：国コードド
メイン名支持組織）および GAC（Governmental Advisory Committee：政府諮問委員会）
がこの点に関する強い懸念を表明し、国の名称およびその略称（ASCII および IDN の双方）
を gTLD として認めないように求める書簡を、ICANN 理事会に提出した。
さらに、後述するように、ccNSO は、Fast Track と呼ばれる「迅速な IDN ccTLD 導入」の検討促進を ICANN 理事会に要請し、ICANN 理事会はそのためのワーキンググループの設置を承認した。この Fast Track において、国名と無関係な IDN ccTLD が出現し、gTLDの領域が侵される可能性があるということに GNSO は危惧を抱いた。
そこで、これらに対する動きとして、2008 年 1 月、GNSO は ICANN 理事会に対し、IDN
ccTLD と IDN gTLD の区別を明確に定義するため、GNSO と ccNSO との共同による新たな検討プロセスを開始するよう要請した。しかし、2008 年 1 月中旬、ICANN 理事会はこの要請に対する正式な回答を避けた。さらに、ccNSO は、この GNSO の提案に対する反応
として、共同検討が不適切である旨の書簡を出すとともに、2 月中旬の ICANN ニューデリー会合にて ccNSO と GNSO 双方の評議委員による合同会議を行って今後の進め方を検討すべきであるとの対案を出した。
この両評議委員会による合同会議は、ICANN ニューデリー会合中の 2008 年 2 月 11 日に実現した。その中では、ccNSO は国の名称以外のドメイン名を ccTLD として創設する意図はなく、むしろ国の名称以外のドメイン名が創設されないような基準を作ろうとしている
ことが ccNSO 側より説明された。この説明によって、GNSO と ccNSO との間で一定の相互理解は進んだものの、「ccTLD と gTLD の区分を前もって行いたい」という GNSO の意
見と「そうした長い時間のかかるポリシー定義を行いつつも、そのポリシーに反しないであろう範囲で、限定数であっても迅速に IDN ccTLD を導入したい」という ccNSO の意見

288

の相違部分について十分な合意を作れず、さらに意見交換を進めることとなった。
本合意形成が、IDN gTLD および IDN ccTLD 双方の創設に向けた活動促進の鍵を握っているといえる。

3-6-1-2

ccTLD

ICANN における ccTLD に関する議論および調整は、ccNSO を中心に行われている。
(1) ccNSO における IDN ccTLD 正式ポリシーの策定状況
2007 年 6 月の ICANN サンファン会合以来、ccNSO と GAC が共同して IDN ccTLD 導入にあたり考慮すべき課題を洗い出し、以下の内容のリストにまとめた。このリストは、2007
年 12 月から 2008 年 2 月下旬まで公開意見募集にかけられている。
a) 一般的な課題
・IDN ccTLD はどういう国・地域に対応するものとすべきか
・IDN ccTLD として用いるラベルは、意味があるものであるべきか
・1 つの ccTLD において、1 つのスクリプト(*)に対して IDN ccTLD はいくつとするか
・1 つの地域に対して、IDN ccTLD を作るスクリプトはいくつか
・IDN ccTLD のラベルの長さはどうするか・与えられたスクリプトに対して、何らかの権利が付与されるものとするか(*)スクリプト：言語を表記するのに使用する特定の体系に則ってまとめられた文
字の集合のこと。たとえば、日本語で使う主なスクリプトは、漢字、ひらがな、カタカナの 3 種である。
b) 導入に関する課題
・IDN ccTLD ラベルのリストは、強制されるべきか
・IDN 導入の過程で、どのような優先権を既存の ccTLD に与えるべきか
・強制されるリストがない場合、使用する IDN ccTLD ラベルを選択するのは誰か
・IDN ccTLD の展開についてどのようなコーディネーションが行われるべきか

289

c) 委任に関する課題
・既存の ccTLD 委任のポリシーは、IDN ccTLD に対して適用されるかd) 運用に関する課題
・一般的な IDN 標準に加えて、既存の ASCII TLD と異なる技術的な要求事項はあるのか。もしそれがある場合、どのようにそれらを開発し、また誰がそれらを開発するのか
ccNSO は、このリストにあげられた全ての課題に対する回答を作成し、IDN ccTLD を正式に導入するためのポリシーに発展させることを意図している。なお、ここで作られるポリ
シーは、将来にわたり適用されるものを想定しているため、周到で十分な検討が必要となり、結果を出すまでに 2 年以上を要することが想定されている。さらに、そのポリシーの確定後は、そのポリシーに沿って IDN ccTLD の文字列および管理者を決めていくことになるが、この決定にはさらに数年かかることが想定される。
(2) Fast Track アプローチにおける早期導入ポリシーの検討状況
上述のように、ICANN の規定するプロセスに従って正式なポリシーを確定し、そのポリシーに沿って IDN ccTLD が創設されるためには、数年以上の期間を要する。このため、IDN
ccTLD の導入がこの正式プロセスのみに則って検討された場合、IDN ccTLD 導入に対する緊急性の高い需要に時宜を得て応えられないのではないかという懸念が、非英語圏諸国を中心に提起された。
そこで ccNSO は、2007 年前半から、上記の正式ポリシーの策定作業と並行する形で、技術、運用、ポリシーなどの問題が発生しない範囲で 1 つの ccTLD ごとに 1 つもしくは極めて少数の IDN ccTLD を限定的かつ早期に導入するための「Fast Track」と呼ばれるアプローチを検討してきた。
ccNSO では、まず、この Fast Track の必要性を定量的に知るため、緊急性の高い需要を持つ ccTLD がどれくらいあるかを調査した。その結果、30〜40 程度の ccTLD は、至急 IDN
ccTLD の導入を必要としているとの結果が出た。
この調査結果を背景に、ccNSO は ICANN 理事会に対し、Fast Track アプローチを通じた
IDN ccTLD 導入の方針を検討するワーキンググループの設立を働きかけた。この結果、2007 年 10 月には、ICANN 理事会の指示により IDNC WG が設立されるに至った。IDNC
WG は、ccNSO のみならず、以下の関連ステークホルダを包含した構成となっている。

290

・ALAC（At-Large Advisory Committee：At-Large 諮問委員会）
・GAC
・GNSO
・SSAC（Security and Stability Advisory Committee：セキュリティと安全性に関する諮問委員会）
・技術コミュニティ
・ICANN スタッフ
IDNC WG では、2007 年 12 月下旬から、Fast Track アプローチによって IDN ccTLD を導入するために必要な、文字列選定および管理者委任のメカニズムを検討している。これらのメカニズムを検討するにあたって考慮しなければならないポイントとして、以下が洗い出されている。
a) 文字列選定メカニズム・選定するスクリプトには何らかのステータス（公の場で使用されることが正式に認められているかどうかなど）が必要か・選定するスクリプトの数に制限を設けるべきか
・誰が文字列を提案するのか
・文字列選定後の異議申立は可能か、どのような仕組みにすべきかb) 管理者委任メカニズム・管理者となるための基準は必要か・IDN または TLD の運用実績は必要か
IDNC WG は、2008 年 2 月初旬にこのポイントを盛り込んだ Initial Report を公開し、意見募集を開始した。2008 年 2 月中旬の ICANN ニューデリー会合においても、この Initial
Report が集中的に討議された。

3-6-2 IDN TLD の技術および運用に関する検討状況
3-6-2-1 IDN TLD の安全性に関する SSAC の見解
ICANN SSAC は、IDN TLD の導入に関し、まずルートゾーンに試験用の IDN TLD を
NS-record として追加して試験を実施することが望ましいとの見解を、2007 年 7 月に発表
した。

291

3-6-2-2 「.test」試験プログラム
2007 年 10 月 9 日、評価を目的とした 11 の IDN TLD（「.test」を 11 の言語に翻訳したもの）がルートゾーンに追加され、13 のルートサーバにも配布された。
(1) 設備「.test」の試験は、以下の設備を用いて行われている。
・2006 年後半から 2007 年前半にかけて Autonomica による試験（後述）で使用された、逐次に同期する複製 DNS サーバ
・エンドユーザ、アプリケーション開発者、レジストリその他の参加者が IDN を試験しフィードバックできるオンラインの評価設備
また、「.test」試験プログラムは、以下の活動で構成されている。
a) Autonomica による研究室試験
・スウェーデンの Autonomica 社が、研究室環境において、IDN TLD を DNS ルートゾーンの NS-record として挿入する試験を行った。試験は完了し、2007 年 2 月の報告で悪影響がないことが示された。
b) ルートゾーンへの IDN TLD 挿入に関する IANA での手続きの作成
・評価を目的とした IDN TLD の DNS 挿入、管理、緊急削除の手続きが作成された。こ
の手続きは、RSSAC（Root Server System Advisory Committee：ルートサーバシス
テム諮問委員会）からの意見および勧告を考慮した上で、2007 年 8 月から実施された。
c) ルートサーバのパフォーマンスと耐久性維持に関する文書の作成
・この文書は、上述の緊急削除の手続き、すなわち、ルート DNS に何らかの技術的な問題が発生した際、すみやかに当該 IDN TLD を削除するための手順が説明されたものである。IDN TLD がルートゾーンに追加された後に実際のルートサーバでこの手順が試験された結果、2008 年 1 月、悪影響を生じないことが Autonomica から報告された。
d) IDN TLD アプリケーションの評価
・各種のアプリケーションにおいて、以下の方式で IDN TLD の試験および評価を行っている。
1）Autonomica 社による研究室試験のライブ・レプリケーション

2922）オンライン試験と評価（エンドユーザ、アプリケーション開発者、TLD 管理者および関心を持つ参加者が IDN TLD を使い、使いやすさを評価し持ち寄る）
なお、上記のオンライン評価は、2007 年 10 月 15 日に運用開始された 11 の IDNwiki（http://idn.icann.org）により評価内容を共有しつつ進められている。今後、各 IDNwikiのモデレータが中心となり、評価を報告にまとめていく予定となっている。

3-6-2-3 IDN 実装ガイドラインの更新
IDN 実装ガイドラインは、サイバースクワッティングのリスクや利用者の混乱を最小限にとどめることを目的として、IDN 登録における一般則や経験則を ICANN のワーキンググ
ループがまとめたものであり、2003 年 6 月にその初版が発行された。その後、gTLD や
ccTLD での IDN の実装経験をもとにガイドライン更新が行われており、2006 年 2 月には、
2.1 版が発行された。
現在、2.2 版の草案に対する公開意見募集が行われている。意見募集の期間は明確にされていないが、いずれにせよ、この版から IDN TLD も対象に含めることが明示されている。

3-6-3 IDN 標準およびアプリケーションの対応に関する状況
3-6-3-1 IDNA プロトコルの見直し
IETF において、「デザインチーム」と称される専門家の非公式パネルが、2003 年以来のIDNA の導入に関する報告を評価し、今後の作業の核となる数件の課題を特定した。そして、これをきっかけにして、IDNA プロトコルの修正が行われることになった。
IDNA プロトコルの主な修正点は、以下の通りである。
・有効な IDN ラベルの定義
・ Unicode におけるスクリプトの分類を考慮した上で、IDN で使える文字を選ぶモデルの採用（現在のモデルは IDN で使えない文字を除外するモデル）
・混乱を招く、もしくは非可逆な文字マッピングの排除
・STRINGPREP（RFC 3454）の「右から左への横書き」に関する誤りの修正
・Unicode のバージョンへ非依存化

293この修正の目的は、IDN でより多くのスクリプトが使えるようにすることである。今回の修正の動きに繋がった現在の IDN モデルの課題は、RFC 4690 で検討されている。
最新の IDNA 改定案は、以下の通りである。
http://tools.ietf.org/html/draft-klensin-idnabis-issues
http://tools.ietf.org/html/draft-klensin-idnabis-protocol
http://tools.ietf.org/html/draft-faltstrom-idnabis-tables
http://tools.ietf.org/html/draft-alvestrand-idna-bidi
また、過去の議論が繰り返し行われることを避けるため、これまでにどのような提案があり、なぜ現在の IDNA 方式が選択されたのかを記した以下の文書も検討されている。
http://tools.ietf.org/html/draft-klensin-idna-alternatives

3-6-3-2 IDN 対応アプリケーションの状況
アプリケーションにおいては、Web ブラウザの IDN 対応は進んでいる。PC 用の主要なWeb ブラウザでは、現在までに IDN の直接入力やリンククリックによるサイトアクセスな
どの基本的な機能の実装が終了している。今後、電子証明書や JavaScript などの高度な機能の IDN 対応が進むと考えられる。携帯電話用の Web ブラウザでも IDN 対応は進んでいるが、携帯電話への標準搭載はまだ少数にとどまっている。
メーラ（メールクライアント）の IDN 対応は、メール本文内に記載された IDN を含む URLの自動認識が進み始めている。メールアドレスの IDN 対応は、ユーザ名（メールアドレスの@の左側）部分を国際化する規格が確定していないため、進んでいない。また、PC 用の
主要なオフィスソフトでは、メーラと同様に、本文内に記載された IDN を含む URL の自動認識が進み始めている。

3-7 アプリケーションの国際化ドメイン名への対応
国際化ドメイン名が普及していくためには、技術仕様の策定、管理方法の標準化、各アプ
リケーションの国際化ドメイン名への対応などの問題を解決していく必要がある。このう
ち、技術仕様に関しては、RFC3490、3491、3492 の発行により、既に国際化ドメイン名を使用するための技術標準は策定されている。また管理方法の標準化に関しても、既にICANN によるガイドラインが策定されている。したがって、残された課題は各アプリケー

294

ションの国際化ドメイン名への対応だけであり、近年においてはこの分野に最も力が注がれている。
2006 年までは、このアプリケーションの対応が国際化ドメイン名普及に関しての一番のネックと考えられおり、その中でも特に Web ブラウザの対応が遅れていることが問題視されていた。実際には、主要な各ブラウザにおいては、Mozilla や Firefox、Opera、Safari な
どといったブラウザはそれ以前から国際化ドメイン名に対応していたわけだが、おそらく世界で最も大きなシェアを持つであろう Microsoft 社の Internet Explorer については、当時の最新バージョンであるバージョン 6 であっても追加プラグインが必要であった。しかし、一般的なユーザにとってプラグインを追加でインストールするということはかなりの敷居の高さであり、これが国際化ドメイン名の使いにくさや、ひいては「国際化ドメイン
名はまだ使えない」などというような誤解すら生む背景となっていた。しかし、2006 年の11 月に行われた Microsoft 社の Internet Explorer 7 のリリースにより、状況は大きく変わりつつある。国際化ドメイン名を利用する上で、ユーザが最も目にする機会が多く、また利用する機会も多いであろう Web 関連のサービスにおいて、世間一般で最もシェアを持っていると思われる Internet Explorer が標準で国際化ドメイン名に対応したことは非常に大きな出来事である。これまでも i-Nav と呼ばれるプラグインをインストールすることによって国際化ドメイン名は利用できたが、標準で対応しているのと追加の作業が必要となるのとでは大きな違いがある。Internet Explorer の国際化ドメイン名対応は、国際化ドメイ
ン名に関係するものにとってこれまでずっと要望してきたことであり、Internet Explorer7の標準対応によって、国際化ドメイン名の普及に大きな弾みがつくと期待されている。また、これまでは Internet Explorer7 をインストールするためには、ユーザ自らが Microsoft
社の Web サイトなどからダウンロードしてインストールする必要があったが、2008 年 2月からは、Windows の自動更新に含まれるようになった。実際には、OS と深く関連した
Web ブラウザがアップデートされることにより、ユーザ環境において大きな混乱を招くことも予想されることから、他のアップデートと違いインストールまで自動で行われるわけではなく、ユーザにインストールの可否を問う形になっている。とはいえ、これまでと比べれば、一般ユーザにとっては遙かに Internet Explorer7 へアップグレードするきっかけが増えるわけで、これを機にますます国際化ドメイン名が使われる機会が増えていくものと予想される。
このように Web ブラウザをはじめ、国際化ドメイン名の普及に向けて何よりも必要なのは、各アプリケーションの国際化ドメイン名への対応であり、これはサーバ側でなく、アプリ
ケーション側で対応する方式を選択した現在の国際化ドメイン名の技術標準から、避けては通れないことである。そして、いくら国際化ドメイン名の登録が増加しようとも、実際にそのドメイン名を利用できないのであれば利用者にとって魅力的なものとはなりようも

295

なく、またそのような状況で登録者が増加し続けるということも考えにくい。
したがって、国際化ドメイン名の普及にあたっては、各アプリケーションの対応は非常に重要な要素であるが、その対応具合はアプリケーションによってまちまちな状況となっている。
現在、国際化ドメイン名への対応が最も進んでいるのは Web ブラウザである。これはインターネットユーザの多くにとって、最もドメイン名に接する機会が多いのが URL の一部としてのドメイン名であろうことを考えると、ある意味最も国際化ドメイン名への対応が望まれるソフトウェアであると言える。また、最近では、広告などにそれを見た人間が Web
サイトにアクセス出来るように URL を表示する事も多く、そのような際に漢字のようなユーザにとってわかりやすいドメイン名を使えることもメリットであろう。
その Web ブラウザの対応状況であるが、Microsoft Windows 上で動くブラウザとしては、
Microsoft 社の Internet Explorer もバージョン 7 より国際化ドメイン名に対応しており、The Mozilla Foundation が提供している Mozilla と Firefox、Mozilla の成果物を利用している Netscape 社の Netscape、Opera Software 社が提供する Opera など、主要なブラウ
ザは全て標準で国際化ドメイン名に対応している。
一方、Mac OS 上で動く Web ブラウザとしては、OS に標準で提供されている Safari、The
Mozilla Foundation が提供している Firefox や Camino などで国際化ドメイン名を利用することが可能である。
上記以外の OS としては、Linux や FreeBSD といった PC-UNIX 系の OS でも上記 Mozillaや Firefox などを利用することが可能であり、国際化ドメイン名の利用にあたって特段の不都合は無いと言えよう。
最近では、携帯電話などを使っての Web ブラウズも一般的になってきているが、日本国内で使われている携帯電話向けの各種 Web ブラウザについても、国際化ドメイン名対応がほぼ完了している。
このように Web ブラウザの分野においては、国際化ドメイン名を利用するための障壁はほぼ無くなったといえ、今後はユーザへの周知や普及とともに、利用が促進されていくものと考えられる。もちろん、Internet Explorer のバージョン 5 や 6 を始めとした、各種ブラ
ウザの古いバージョンを使っているユーザはある程度確実に存在し、また使っている OS の制限からそれら全てのユーザが新しいバージョンにアップグレード出来るわけではない。

296

ただし、各 OS のサポート期間終了の影響や、機器の買い換え需要などにより、そのようなユーザについても、緩やかではあるが状況の改善が進んでいくものと思われる。
一方、Web ブラウザ以外のアプリケーションにおける、国際化ドメイン名への対応状況については、Web ブラウザほど進んでいないのが現状である。一部の FTP クライアントやメールクライアントソフトなどで対応しているものが見受けられるが、Web ブラウザほどの対応状況になるにはもう少し時間がかかるものと思われる。
特に、欧米などを中心とした国々では、国際化ドメイン名以前に、マルチバイトの文字を扱う前提でソフトウェアが設計されていないことも多く、それらのソフトウェアについてはまずソフトウェア自体の国際化を行った後に、国際化ドメイン名に必要な実装を行う必要があり、そのような点からも対応にはやや時間が必要であると言えよう。
そのような状況と比較して、日本などのマルチバイトの文字を使うことが一般的な国においては、普及しているソフトウェアはマルチバイトの扱いに問題が無いことが多く、そのようなソフトウェアに関しては国際化ドメイン名と Punycode を変換する仕組みを追加することによって、比較的容易に対応が可能であると考えられる。とはいえ、これも国際化
ドメイン名に対するユーザの要望が少なければ、わざわざ手間をかけて実装しようという
ソフトウェア制作者も少ないであろうし、そういう点から考えると、ユーザが利用しないから対応しないのか、ソフトウェアが対応しないからユーザが利用しないのかといった、「鶏が先か卵が先か」という話にもなってしまいなかなか難しい点があるのも事実である。
とはいえ、国際化ドメイン名の普及というものを考えた場合、まずはユーザが容易に利用できる環境を整備することは必要不可欠であり、そのような点から考えると、やや先行投
資的に各ソフトウェア会社が国際化ドメイン名への対応を進めることが重要であり、そのような動きを進めるためにも、レジストリ等は継続的にソフトウェア業界への働きかけを行っていくことが必要であろう。事実、Internet Explorer の国際化ドメイン名対応に向けては、JET のメンバーが Microsoft 社に書簡を送付して要望を出すなど、コミュニティやレジストリが積極的に働きかけた影響も大きい。
また、現在は Web ブラウザへの対応が中心であるが、これは一般ユーザにとっての国際化
ドメイン名の利用目的を考えた場合、まずは Web の URL としての利用が最も要望が高いと思われることから当然の状況とは言える。とはいえ、URL として国際化ドメイン名を利用するようになれば、次にそのドメイン名をメールアドレスとしても利用したいという要
望が出てくると考えるのが自然であり、そういう意味では、Web ブラウザの対応が進むと同時に、メールクライアントソフトにおいても国際化ドメイン名への対応が進むことが、

297

国際化ドメイン名の普及に向けて非常に重要である。
現在、メールアドレスの国際化については、ローカルパートの国際化に向けてIETFなどで標準化策定に向けて議論が続けられており、関連したRFCとしてはRFC4952133などが発行されている。ただし、技術標準の策定が終わってもそれがすぐにソフトウェアに反映されるわけではなく、またそのソフトウェアがユーザに浸透するまでにはさらに時間がかかることから、実際にユーザが国際化されたメールアドレスを一般的に使えるようになるまでには、まだもう少し時を待つ必要があると思われる。
もちろん、国際化ドメイン名の登録サービスを提供する各レジストリにおいても、このよ
うな状況を時間の経過による解決にまかせて座視しているわけではなく、.jpを管理する
JPRSのように、メールを利用するユーザやメールクライアントソフトウェア作者向けのガイドラインを発表する134など、環境を整えるために積極的に活動しているレジストリも存在する。
なお、VeriSign,Inc が国際化ドメイン名に対応しているアプリケーションの情報を Web サイトで提供しているが、そのサイトの情報によると、現在国際化ドメイン名に対応している主なアプリケーションは以下のものとなっている。もちろん、ここに挙げられているのは主要なソフトのみであり、これ以外にも対応しているソフトウェアは多くあると思われる。
とはいえ、国際化ドメイン名の対応に関する傾向を見て取ることは可能であり、対応表を見てもわかるように、国際化ドメイン名に積極的に対応しているのは、Microsoft Windows上で動くアプリケーションが多いようである。

133 RFC4952

http://www.ietf.org/rfc/rfc4952.txt

134 JPRS「電子メール本文中の日本語ドメイン名URLをクリックできるようにするには」

http://xn--wgv71a119e.jp/support/mail_guide/298

表20： 国際化ドメイン名に対応している主なアプリケーション
ソフトウェア種別

製品名

サポート OSWeb ブラウザ用 Plug-in

i-Nav

Windows

Web ブラウザ

CaminoMac OS X

Epiphany

Linux 等
Windows

Firefox

Mac OS X,Linux 等

GaleonLinux 等

Konqueror

Linux 等Internet Explorer

Windows
Windows

Netscape Navigator

Mac OS X,Linux 等
Windows

Opera

Mac OS X,Linux 等

SafariMac OS X

電子メールソフト

FoxmailWindows

FTP クライアント

Core FTP

Windows

FTP Voyager

Windows

Secure FTP

Windows

Smart FTP

Windows

NextFTP

Windows

TELNET/SSH クライアント Absolute Telnet

Windows

Secure NetTerm

Windows

Merak MailServer

Windows

PHlyMail

Windows

VisNetic MailServer

Windows

Active Server Pages

Windows

電子メールサーバソフト

プログラム言語/ActiveX
Windows
C/C++

Mac OS X,Linux 等
Windows

Java

Mac OS X,Linux 等
Windows

PERL

Mac OS X,Linux 等

299Windows
PHP

Mac OS X,Linux 等
Windows

ユーティリティ/その他

PythonMac OS X,Linux 等

3d Traceroute

Windows
Windows

Curl

Mac OS X,Linux 等

JabberD

Linux 等
Windows

Hiki

Mac OS X,Linux 等

SMTPToWindows（参考：IDN-Enabled Applications
http://www.verisign.com/information-services/naming-services/internationalized-domain-names/page_002201.html）

300

第3部

IP アドレスの管理と活用に関する世界的な動向
及び各国における動向調査

301

302

1

IPv4 アドレスの消費状況と、枯渇に関する
議論の動向

303

304

1 IPv4 アドレスの消費状況と、枯渇に関する議論の動向
1-1 IPv4 アドレスの消費状況と今後の予測
IPv4 アドレスの枯渇予測は過去に何回も議論の対象となってきた。古くは 1994 年にIETFのALE(Address Lifetime Expectations)ワーキンググループによって、2008 年±3 年に枯渇するという予測135がされたのを始めとして、2001 年にはJawad Khaki氏が 2009 年に枯渇するとの予測を発表 136 、他にも様々な予想が提示されたが、2003 年にAPNICのGeoff
Huston氏の独自予測が発表され、結果としてRIR関係者により信頼の置ける予想として広く受け入れられた。この後、Huston氏の予測はIANAからの割り振り量の増加等の要因に伴い何回か見直されたが、現在（2008 年 3 月）に至るまで広くRIR関係者の支持を得ている。このHuston氏の予測によると、IANAのIPv4 アドレス在庫が尽きるのは 2010 年 12 月、
RIRのIPv4 アドレス在庫が尽きるのは 2012 年 5 月とされている。現在世界各地でIPv4 ア
ドレス在庫枯渇にどう対応するかの議論が活発化しているが、そのほとんどはこの予測をもとに行われていると言える。
Huston氏は、日々更新される割り振りデータを基に自身の枯渇時期予測を毎日自身のウェブサイト上137で更新している。2007 年 3 月時点ではIANA在庫アドレス枯渇時期 2012 年 7月 15 日とされていたので、IANAにおけるIPv4 アドレス枯渇の予測時期は、この 1 年でさらに 1 年半ほど早まったということになる。
IPv4 アドレスの消費ペースが落ちている兆しは今のところ見られない。IANA から RIR への割り振り状況を見ても、2004 年には/8 が 9 個、2005 年には 13 個が割り振られている。
2006 年には 10 個、2007 年には 13 個が割り振られ、概ね年間で 10 個前後の/8 が消費し続けられている状況と言える。2008 年は 3 月現在、2 個の/8 が割り振られており、実際にグ
ローバルアドレスとして利用できる/8 の IANA における在庫数は 2008 年 3 月現在で 41 個となった。過去の割り振り状況から将来の枯渇時期を予測するという Huston 氏の予測手法に立脚した予測時期が段々早まっていることからも、消費状況が漸増していることは明らかであり、今後の割り振り状況が注目される。
こうした中、JPNICではHuston氏の予測手法とは別の方法でIPv4 アドレスの在庫枯渇時期の予測、再検証を行った。情報通信技術関連の需要要因を示すさまざまな経済指標を基にJPNIC 独自の予測を行ったものであるが、この独自予測も 2010 年から 2011 年にIPv4 ア

135 http://www3.ietf.org/proceedings/94dec/ipng/ale.html
136 http://www.jp.ipv6forum.com/2001/program/slides/K1.ppt
137 http://www.potaroo.net/tools/ipv4/305

ドレスの在庫枯渇に到達するという結果を得て、Huston 氏の予測の信頼性を確認している。
JPNICの予測手法の詳細については、「IPv4 アドレス在庫枯渇問題に関する検討報告書(第一次)」138を参照いただきたい。
同報告書では、分配済みの IPv4 アドレスの回収可能性についても検討している。
歴史的 PI アドレスをはじめとする既存（分配済み）アドレスの中には未利用の状態である
ものが相当数存在しており、それらを回収すれば IPv4 アドレスの在庫枯渇時期を遅らせることができるという意見が多く出ている。歴史的 PI アドレスに関する取り組みは既に開始されているものの、在庫枯渇対応といった大きな目的を持って未利用アドレスを回収することに関して本格的な検討が行われていなかったことを背景に、在庫枯渇問題に大きく寄与できるほどの回収量が期待できるのかどうかについて検討するとともに、回収できたア
ドレスについて本当に利用しやすい状態となっているのかどうかについて検討したものである。
検討によると、未利用アドレスを回収し活用することの可能性、課題は以下のようにまとめられる。
小分けされた形の返納を許すことで、回収再利用の可能性は高まる。
一方で、回収により再度割り振り供給に回せるアドレス量は最大でも/8 が数個程度と考えられる。
上記アドレス量は、直近 2 年間で見たとき、数ヶ月分のアドレス需要を満たす分量に過ぎない。
したがって、未利用アドレス空間の回収、再利用は短期的には有効かつ不可欠の活動ではあっても、長期的に見たときの有効な解決策にはならないものと考えられる。
小分けにされたルーティングが増えることで、事業者にとっては設備増強等の負担増が必要となる。コミュニティ全体として、このコスト負担が可能かは不確実であり、到達性において不安定なアドレスブロックが発生する可能性がある。
積極的な IP アドレス返納を可能とする新たな仕組み作りが必要であり、IP アドレス
在庫が深刻な状況になる前に、短期間の間に世界的コンセンサスを形成する必要がある。
この見方はJPNICのものだけではなく、IANAの担当者も同様な見方をしている。IANAの担当者がICANN blogに投稿した記事139によると、これ以上歴史的PIアドレスの返却が進むとは考えにくく、返却されたとしても長期にわたる需要を支えるには圧倒的に供給が不足

138 http://www.nic.ad.jp/ja/ip/ipv4pool/ipv4exh-report-071207.pdf
139 http://blog.icann.org/?p=271

306

するだろうとの見方が示されている。
一方、2008 年 2 月の APNIC ミーティングでは、非常に限られた数の ISP が、2007 年に割り振られたアドレスの大部分を消費しており、今後もそれら ISP の割り振り申請が続くのか、もしくは新興国の需要が今後活発化してきた際に同様の需要の伸びを示すのか、慎重に見極める必要がある、との指摘もなされている。
一部では既に IPv4 アドレスの駆け込み需要が発生しているという見方もあり、なお実際の枯渇時期は流動的であるともいえるだろう。しかし、複数の予測が IANA における在庫枯
渇を 2010 年前後としており、残された時間は多いとは言えない状況であることは確かである。
以下参考として、2008 年 1 月末現在で IANA 予約アドレスとされている IPv4 アドレスを示す。この空間には実際にはグローバルアドレスとして利用できない空間が含まれている。
グローバルアドレスとして使えないものにはその旨注記したので確認いただきたい。

アドレスブロック

利用状況、備考

0.0.0.0 – 0.255.255.255

IANA 予約空間。グローバルアドレスとしては利用不可。

1.0.0.0 – 2.255.255.255

IANA 在庫。利用可。（2 * /8）

5.0.0.0 – 5.255.255.255

IANA 在庫。利用可。（1 * /8）

23.0.0.0 – 23.255.255.255

IANA 在庫。利用可。（1 * /8）

27.0.0.0 – 27.255.255.255

IANA 在庫。利用可。（1 * /8）

31.0.0.0 – 31.255.255.255

IANA 在庫。利用可。（1 * /8）

36.0.0.0 – 37.255.255.255

IANA 在庫。利用可。（2 * /8）

39.0.0.0 – 39.255.255.255

IANA 在庫。利用可。（1 * /8）

42.0.0.0 – 42.255.255.255

IANA 在庫。利用可。（1 * /8）

49.0.0.0 – 50.255.255.255

IANA 在庫。利用可。（2 * /8）

92.0.0.0 – 95.255.255.255

IANA 在庫。利用可。（4 * /8）

100.0.0.0 – 115.255.255.255

IANA 在庫。利用可。（16 * /8）

173.0.0.0 – 187.255.255.255

IANA 在庫。利用可。（15 * /8）

197.0.0.0 – 197.255.255.255

IANA 在庫。利用可。（1 * /8）

223.0.0.0 – 223.255.255.255

IANA 在庫。利用可。（1 * /8）

224.0.0.0 – 239.255.255.255

IANA 予約空間（マルチキャスト）グローバルアドレスとしては利用不可。

240.0.0.0 – 255.255.255.255

IANA 予約空間。グローバルアドレスとしては利用不可。

上記で示すとおり、240.0.0.0 – 255.255.255.255 はいわゆるクラスEとして実際にはグロ307

ーバルアドレスとしては使えない空間である。しかし、これを大規模ISPの内部ネットワー
ク用として、プライベートアドレス的に使う空間に指定しようという動きがある。2007 年
9 月に行われたAPNICミーティングでこの活動が紹介された140が、2008 年 3 月現在、この空間はまだ内部ネットワーク用途に使えるような状態にはなっていない。

1-2 IPv4 アドレス在庫の枯渇に関する議論の状況
各地域においてどのような IP アドレス管理ポリシーが提案され、議論されているかについては本報告書内の第 1 部 3-1 で概説したが、本項では特に IPv4 アドレス在庫の枯渇に関するポリシー提案について詳しく触れる。また、アドレスポリシーの議論とは別に IPv4 アド
レス在庫の枯渇に関してどのような議論が行われているかもあわせて見ていく。

1-2-1 IPv4 アドレス在庫の枯渇に関するポリシー提案とその議論
グローバルポリシー
IPv4 アドレスの在庫の枯渇が迫る中、IANA が管理するグローバル IPv4 アドレスの最後の割り振り方式を今のうちに決めておこうという動機から、残存 IPv4 アドレスの IANA から RIR への割り振りポリシー（グローバルポリシー）が提案されている。内容については
第 1 部 3-1-1 で詳述したのでそちらを参照いただきたい。
地域ポリシー[APNIC – IPv4 アドレス移管]
2007 年 9 月に開催された APNIC ミーティングでは、IPv4 アドレス枯渇関連ポリシーとして「IPv4 アドレスの移管を認める」という提案が提出された。提案の全文訳を以下に示す。
■ 提案日本語訳141(1) 序論
この提案は、APNIC ポリシー中の、APNIC アカウント保持者間での IPv4 アドレス割り振
り登録及び IPv4 PI アドレス登録の移管禁止の制限を撤廃するものである。この提案は、140 http://www.apnic.net/meetings/24/program/sigs/policy/presentations/wilson-class-e.pdf
141

原文は http://www.apnic.net/policy/proposals/prop-050-v001.html を参照。

308

歴史的 PI アドレス移管ポリシーの改良版であり、現在の APNIC アカウント保持者が持っている IPv4 資源に適用される。
(2) 要約
アドレス保持者の移管登録に関する現在の APNIC ポリシーでは、移管の資格を、運用されているネットワークを管理する組織の合併、買収の場合に制限している。
割り振られていない IPv4 アドレスプールは 2009 年から 2011 年という時間に枯渇することが予想されている。アジア太平洋地域では、大変な量の投資が IPv4 ベースのサービスになされており、IPv6 ベースのサービス提供への移行はおそらく IPv4 アドレスプールが枯渇するまでよりも時間がかかると思われる。従って、IPv4 アドレスへの需要は IPv4 アド
レスプール枯渇後も続き、その需要を満たすため、アドレス保持者間のアドレス移動が起こる期間が到来すると思われる。
現在のアドレス配布状況を正確に記録することが、APNIC アドレスレジストリの目的である。
この提案は、APNIC が現在の APNIC アカウント保持者間のアドレス移管を認めることを唱えるもので、APNIC によって IPv4 アドレス移管の登録がなされるよう、移管を行う者に前提条件としていくつかの制限を設けるものである。
(3) 他 RIR の状況
現在どの RIR も、移管を認めるポリシーは施行していない。
(4) 提案詳細
このポリシーが採用されると、APNIC は以下の条件に従い、IPv4 アドレスの移管申請を進める。
[IPv4 アドレスブロックの条件]/24 もしくは/24 より大きい IPv4 アドレスブロックのみが移管できる。
アドレスブロックは、APNIC によって管理されているレンジでなければならない。これは、IANA が APNIC に割り当てた/8 ブロックの一部か、歴史的経緯を持つアドレス
で現在 APNIC が管理しているアドレスのいずれかである。
アドレスブロックは、現在 APNIC アカウント保持者へ割り振り、もしくは割り当てさ309

れているものでなければならない。
アドレスブロックは、移管後は現在の APNIC ポリシー全てが適用される。これは、「歴史的経緯を持つ」とされていたアドレスブロックも同様である。
[移転元に関する条件]
移転元は現在の APNIC アカウント保持者でなければならない。
移転元は現在 IPv4 アドレス資源の保持者として登録されていなければならず、それらの資源の状況について、何ら紛争に巻き込まれていないこと。
移転元は移転後 24 ヶ月は APNIC から追加の IPv4 割り振りもしくは割り当てを受けることはできない。
APNIC から IPv4 アドレスが入手可能である限りにおいて、24 ヶ月の割り振り、割り当て禁止期間の後、APNIC へ IPv4 アドレスの申請を将来行う際は、移転元は IPv4
アドレス割り振りを必要とする理由を文書で示さなければならない。
[移転先に関する条件]
移転先は、現在の APNIC アカウント保持者でなければならない。
移転先組織は、現在の APNIC ポリシーの適用を受ける。特に、APNIC へ追加の IPv4
割り振り申請を行う場合、移転先は移転を受けたアドレスを含め全てのアドレスについて説明を求められる。
APNIC へ払う維持料は、全ての保持資源をベースに計算される。
[アドレス移管プロセス]
APNIC が移転元及び移転先双方から通知を受けた後、1.

移転の対象となったアドレスに関する登録記録を APNIC が更新する。
APNIC が移転元のアドレス保持を、移転の時点で調整する。メンバーシップ料金及び（もしくは）サービス料金の観点からは、その時点で APNIC に返却があった場合と同様に取り扱われる。

310

APNIC が移転先のアドレス保持を、移転の時点で調整する。メンバーシップ料金及び（もしくは）サービス料金の観点からは、その時点で APNIC が割り振りもしくは割り当てを行った場合と同様に取り扱われる。
以下の移管に関する詳細情報は、APNIC によって資源移管の記録として公開される。
- 移転元
- 移転先
- アドレス資源- 移転日[移転費用]APNIC は移転のトランザクション毎に移転先に対し課金を行うことができる。課金額は移転されるアドレスブロックの量に応じて決定される。
移転費用は、このポリシーの採用時には当初 APNIC EC によって決定される。移転費用は
将来 APNIC の料金レビューの対象に含まれる。

(5) 提案の長所・短所[長所]
APNIC アカウント保持者が持っている IPv4 アドレスの実際の状況を、APNIC レジストリが反映し続けることができる。
登録されない IPv4 アドレス移転から生じる、ネットワークの完全性、ルーティングやアド
レッシングのインフラへのリスクを軽減することができる。この提案は、アドレス移転の存在を認め、その結果を登録することで、APNIC アドレスレジストリが資源及び資源保持者の正確なデータを維持し続けられるようにするものである。この提案はまた、この登録の正確性に依拠している者も、現状及びその情報の正確性に今後も依拠し続けられるようにする提案である。
使われていない IPv4 アドレスを、使えるようにするより強いインセンティブを与え、IPv6への移行に向けた残りの IPv4 アドレス需要を満たすための一助となる。
[短所]

311

将来において IPv4 アドレス空間を得るための唯一の手段として市場ベースのシステムができることに関する懸念が表明されている。また、出し惜しみや投機、価格操作などの市場の失敗の可能性への懸念も表明されている。
これらのリスクを低減させる要因は多数ある。IPv6 への移行が進むにつれ、IPv4 アドレスの市場価値は下がり、増加する IPv6 ネットワークにおける IPv4 ベースのサービスという、低価値のサービスと同等にまでになる。また、APNIC にまだ IPv4 アドレス空間があるう
ちにこのポリシーを採用すれば、APNIC の現在確立された IPv4 アドレス割り振りプロセスが続くので、これが市場へ供給される代替物となり得る。
(6) APNIC メンバーへ及ぼす効果
APNIC メンバーは、APNIC アカウント保持者間での IPv4 アドレス移転を登録することができる。
(7) NIR へ及ぼす効果
本提案は、NIR で管理されている IPv4 アドレスについてはその範囲外である。また、移転
元、移転先が NIR 管理の組織である場合も同様である。
この提案は現在原則として認められていない IPv4 アドレスの移管を認めるものである。提案では、移管元と移管先の当事者同士がどういうルールで移管を取り決めるかについては何も規定していないため、実質的には「売買」を黙認するだと捉える見方もある。
提案者としては「アドレス売買といった移管は IPv4 アドレスの在庫が少なくなるにつれ必ず起こるものであり、現に起こっているケースも見られる。そうであれば、今のうちから移管を通常ルールの下で可能にし、使用の実態が正しく WHOIS データベースに反映する
ようにルールを整備するべきだ」と主張している。
2007 年 9 月の会場での議論では、IP アドレスは売買されるべきではないが、現実にそれが起こる可能性がある以上、こういったポリシーを施行するのはやむを得ないとする意見がある一方で、移管が現実化することをポリシー面が後押しすることに躊躇する意見もあった。移管ポリシーの制定に積極的な意見の中でも、RIR 間での移管を認めるべきではないかとする意見や、移管可能なサイズを/24 に限定すべきではないのではないかといった条件面での異論が出てきたため、2007 年 9 月の APNIC ミーティングでは、提案自体に対してコンセンサスを求めることはせず、継続議論の扱いとなった。

312

この提案は引き続き 2008 年 2 月のAPNICミーティングでも議論された。提案は一部変更がなされていたが、その変更内容は以下の通り142である。
(3) 他 RIR の状況(前回から追加)RIR 間での移管を認めることは提案者の目的ではない。RIPE では同様な提案が提出されている。
[アドレス移管プロセス](前回から追加)集約可能性を保つため、移転先組織は APNIC に対し、移転を受けたアドレスを未割り振りプールに返却することを通告し、同じ大きさのアドレスブロックを移転
先組織に登録することができる。このオプションは、移転先組織の判断により、移転先組織が利用することができる。
上記の通り修正は最小限にとどまっており、主要部分に変更はない。2008 年 2 月の APNIC
ミーティングでは、「この提案は実質的に IP アドレスの市場化を生む。市場化はされるが規制は実質的に無いということであれば、規制当局が必ず介入してくる。規制当局に対して、この提案が IPv4 アドレスのみに適用され、IPv6 には適用されないなどということを説明することは非常に困難である。結局、今の IP アドレス管理体制が様変わりする危険もはらんでおり、パンドラの箱を開けるようなものだ。」という強い懸念が表明された。また、「リースという概念を維持するよう提案を見直すべき。」という意見や「/24 以上の大きさのアドレスに限定する、ということはポリシーではなく、実際の運用に任せるべき」という意見も出された。一方で「こうした枠組みは絶対に必要。大枠は正しいのだからまずは施行して、細部は必要に応じて変えていけばよい」という意見や、「RIPE で提出されているような（注：後述）一時的な移転という考えと取り入れるべきだ」という意見も出た。
全体として、移転を認めることもやむなしとする意見が多数となり、その実装方法に様々な異論があるという状況になってきている。
この議論を受け、2008 年 2 月の APNIC ミーティングでも結論を出すのは避け、継続議論を行うこととなった。提案者である APNIC の Geoff Huston 氏は、2008 年 8 月の APNIC
ミーティングに向け本提案の再修正を行い、再提出を図る構えである。

142

修正提案の全文（原文）は http://www.apnic.net/policy/proposals/prop-050-v002.html を参照。

313

[APNIC – RIR 間で IPv4 アドレスの在庫を融通しあう提案]
2008 年 2 月の APNIC ミーティングに、RIR 間で IPv4 アドレスの在庫を融通し合う提案が提出された。概要を以下に示す。
■ 提案概要143
いずれかの RIR の IPv4 アドレスの在庫が残り 30 日分になった時点で、他の 4RIR の在庫が何日分あるかの調査を行う。在庫枯渇まで最も時間的余裕がある RIR は、他 RIR へ IPv4
アドレスの割り振りを行う。割り振り手順は、割り振り元の RIR の手順に従う。
割り振りを受ける RIR は、3 ヶ月の需要を満たすだけの割り振りを要請することができる
が、その量は割り振り元 RIR の総在庫の 8 分の 1 を超えてはならない。
割り振り元 RIR の在庫の 8 分の 1 が、割り振り先となる RIR の 30 日分に達しない場合は、割り振り先の RIR は配下の LIR からの割り振り申請をまとめて毎週 1 回、割り振り元のRIR へ提出するものとする。

この提案は、IANA における IPv4 アドレスの在庫が枯渇した後なお残っている RIR の在庫
を RIR 同士で融通し合い、全 RIR における在庫の枯渇を同時期に揃えようというものである。2008 年 2 月の APNIC ミーティングでは、「この提案は本質的に、先進国が発展途上国
から在庫アドレスを奪いに行くようなものだ」という強い反対意見、「手続が複雑すぎて実施できないのではないか」という懸念、「何を解決しようとしているのか理解できない」などという意見が出され、支持されることなく却下となった。

143

提案本文（原文）は http://www.apnic.net/policy/proposals/prop-052-v001.html を参照。

314

[ARIN/APNIC – ソフトランディングポリシー]
ARIN および APNIC には、IPv4 アドレスの在庫が少なくなるにしたがって追加 IPv4 アド
レス申請の要件を厳格化し、あわせて IPv6 の実装を義務づけ、円滑な IPv6 への移行につなげようという「ソフトランディングポリシー」が提案された。提案の概要は以下の通りである。
■ 提案概要IPv6 への円滑な移行を図るため、IANA の IPv4 アドレス在庫が減少するに従い、LIR への IPv4 割り振り要件を順次厳しくする。IANA の/8 の在庫がそれぞれ 40、25、10 を切ったときで 3 つのフェーズに分けられており、最も厳しいケース(10 を切ったとき)の要件は以下の通り。
IPv6 の移行計画に関する調査に対し回答すること。
過去に割り振りを受けたアドレスの 100%を効率的に使っていること、かつ、一番最近に割り振りを受けたアドレスの 90%を使用していること。
割り当てを行う場合、その割り当ての 75%を直後に、90%を 1 年後に使うこと。
自社インフラに使用しているグローバルアドレスのプライベートアドレスもしくはIPv6 への移行計画を提示すること。移行不可の場合、その理由を提示すること。
IPv6 インフラ及び接続サービスを提供していること。

この提案の目的の一つに、「IPv4 アドレスの延命を図る」というものがあったが、APNICの Geoff Huston 氏がこの提案が実施されたと仮定して在庫がどれほど延命できるか独自の予測モデルにあてはめて試算したところ、約 1 ヶ月という答えが出た。提案者はこの予測結果を聞き、それではこの提案の目的の半分が達成できないということで APNIC/ARIN へ提出した提案を撤回し、取り消している。

315

[RIPE – IPv4 アドレスの再割り振り(reallocation)を認める提案]
2007 年 10 月に、IPv4 アドレスの全部もしくは一部の第三者への再割り振りを認める提案
が RIPE に提出された。概要を以下に示す。
■ IPv4 アドレスの再割り振りを認める提案144
いかなる LIR も、それまでに RIPE NCC もしくは IANA から割り振りを受けた IPv4 アド
レ ス空間（現在割り当てが行われていないアドレス）の全部もしくは一部を再割り振り(re-allocate)することができる。
再割り振りは、RIPE NCC のサービス提供エリア内の LIR に対してのみ行うことができる。
再割り振りするアドレス空間は、その時点における最小割り振りサイズを下回る大きさであってはならない。
再割り振りは RIPE データベースに反映される。この再割り振りは、恒久的でも良いし、一時的でも良い。この再割り振りは RIPE NCC に通知され、RIPE NCC が割り振り先の変更を記録する。
再割り振りされたアドレス空間は、現在の割り振り先を明確にするためその旨表示される。

この提案は一見 LIR が別の LIR に対して「インターネットサービスを提供して」IP アドレスの割り振りを行うことを可能にするものであるかのように見えるが、実はそうではなく、「インターネットサービスを提供することなく」IP アドレスのみを再割り振りすることを可能にするものである。実質は移管と同じ効果を持つとも言える。
2008 年 2 月現在のところ、RIPE でも APNIC 地域での議論と同じく「IP アドレスの移転は好むと好まざるとに関わらず起きるのだから、こういうポリシーが必要だろう」という意見がある一方で、今までの基本的ルールを覆す提案に不安を示す意見もあり、結論は出ておらずメーリングリスト上の議論が続いている状況である。

144

原文は http://www.ripe.net/ripe/policies/proposals/2007-08.html を参照。

316

[ARIN – アドレス移転提案]
ARIN 地域においても、IPv4 アドレスの移転を認める提案が提出されている。
以下に詳細を示す。
■ IPv4 アドレスの単純移転を認める提案145
IANA の IPv4 未割り振り空間が枯渇した後、ARIN は以下の条件で IPv4 アドレス移転の申請審査を進める。
[移転元の要件]
移転元が ARIN サービス提供エリアに存在していること。
移転元が IPv4 アドレス移転の記載がなされている契約書にサインしていること。
移転元が ARIN に対し未払い債務がないこと。
移転元が過去 24 ヶ月の間に ARIN から割り振り、割り当て、アドレス移転を受けていないこと。
移転元は移転を行ってから 24 ヶ月の間は ARIN に対し IPv4 アドレス割り振り申請、割り当て申請、移転申請を行うことができない。
[移転先の要件]
移転先が ARIN サービス提供エリアに存在しており、移転を受けた IPv4 アドレスをARIN サービス提供エリアで使用すること。
移転先が ARIN に対し未払い債務がないこと。
移転先のアドレス必要性は、現在の ARIN ポリシーにしたがって ARIN が判断を行う。
その際には過去の IPv4 アドレス割り振りの利用率、割り当ての利用率、過去に移転を受けたアドレスの利用率の確認を含むが、これに限らない。
移転先が IPv4 アドレス移転の記載がなされている契約書にサインする（している）こと。
移転先が過去 24 ヶ月の間に ARIN から割り振り、割り当て、アドレス移転を受けていないこと。
移転先は移転を受けてから 24 ヶ月の間はさらなる移転を行うことはできない。ただし、倒産などの場合を除く。
移転先は、6 ヶ月に 1 個の IPv4 アドレス移管のみ受けられる。

145

原文は http://www.arin.net/policy/proposals/2008_2.html を参照。

317

[移管される IPv4 アドレス空間に関する条件]
IPv4 アドレスブロックは、最小割り振りサイズの規定を満たすものでなければならない。ただし、/24 より大きく、最小割り振りサイズより小さいアドレスについてはそのまま移管はできるが、分割してはならない。
IPv4 アドレスブロックは ARIN サービス提供エリア内での使用として登録されていなければならない。これは、IANA から ARIN に割り当てられたアドレスの一部である
か、ARIN サービス提供地域への歴史的割り当てである必要がある。
移転元の IPv4 アドレスブロックの割り振り、割り当ての状態において紛争があってはならない。
移転元は、自分の利用用として、当初受けた割り振りもしくは割り当てのうち、１つの連続した空間を保持し続けることができ、その他の空間を移転することができる。
移転されるアドレス空間が複数の集約不能な CIDR ブロックからなる場合は、それぞれを個別に移転することができる。保持し続けるアドレスは 12 ヶ月の間、分割したり移転を行うことはできない。
[料金]
移管完了に伴い、ARIN 料金体系に基づく移転費用支払いが発生する。
移転先は、移転先が保持するアドレス総量に応じ、将来の ARIN メンバーシップと費用の規定の適用を受ける。
[事前審査]
移転先は移転を受ける前に、移転を受ける資格があることを ARIN に証明する必要がある（現在の ARIN ポリシーに従った必要性を満たしていることの証明を含む）。事前審査が終了次第、ARIN は移転を受けることができる最大のアドレスサイズを含んだ証明書を提供する。
移転元は、移転の申し出を行う前に、移転を申し出る資格があることを ARIN に証明する必要がある（未払い債務がないこと、契約にサインしていることを含む）。事前審
査が終了次第、ARIN は移転元が移転することができるネットワークアドレスとサイズ、及び移転を行うことのできる期日を含んだ証明書を提供する。
[本プロセスによる IPv4 アドレス移転のセーフハーバールール]
移転できると認められた IPv4 アドレスについては、事前審査によって定められた移転期日の到来もしくは移転の完了まで、ARIN の監査の対象から外れる。事前審査によって定められた期日が到来した場合、さらに事前申請をを受けて監査対象から外れるまでに、監査実施のため 90 日までの期間待つことができる。これは監査免除の終了期日を延長しない。

318

[IPv4 アドレスを共同保有、管理している組織へ（から）の移転]（略）[単純 IPv4 移転の記録管理と公開]
ARIN は移転先と移転元の便宜を図るため、事前審査を通過した移転可能 IPv4 アドレスブ
ロックおよび事前審査を通過した IPv4 アドレス需要を中央管理するリスティングサービスを提供する。
移転完了後、ARIN は IPv4 アドレスの登録情報を更新する。ARIN は移転先および移転元の情報も更新する。
移転後、ARIN は移転されたアドレスブロックについて現在の割り振りもしくは割当先を反映した WHOIS データを公開する。ARIN はまた、当該アドレスブロックの過去の割り振
り先、割当先も公開する。全ての移転、アドレスブロック、移転先、移転元、日付についても同様である。

この提案は 2008 年 2 月に ARIN のメーリングリストに提出された。この提案は 2008 年 4月の ARIN ミーティングで議論される。今のところ、移転の細かい条件に関して異論を唱える意見が多数見られるものの、移転を認めること自体を問題視する意見は少数派のようである。APNIC や ARIN に提出された提案に比べ、かなり厳しい、かつ細かい要件を課していることもあり、今後の議論が注目される。なお、これらの移転に関する提案は 3 地域
でそれぞれ別の提案者から提出されており、今のところこれらの提案を統合しようという動きは出てきていない。しかし、2008 年 2 月の ARNIC ミーティングでは、RIPE に提出された提案を検討すべきという意見が出されたこともあり、場合によっては APNIC/RIPE
地域の提案が統合されるという可能性も残っている。

319

その他の議論[ICANN、RIR、NIR 等の声明]
2007 年の RIR ミーティングは、IPv4 アドレス枯渇対策が主要な議題とも呼べる状態でどの RIR に行っても IPv4 アドレス枯渇の議論の紹介、ポリシー議論が行われていた。そんな中、各組織から続々と IPv4 枯渇に関する声明が発表された。主なものを以下に示す。
発表組織

発表日

主な内容

ARIN146

2007/5/21

1.

2010 年前後に IPv4 アドレスの在庫は枯渇する。

LACNIC147

2007/6/20

2.

将来のインターネットの成長を支えるのは IPv6 である。

AfriNIC148

2007/7/1

3.

IPv6 の採用を広く推奨する。

APNIC149

2007/9/7

4.

在庫枯渇及び IPv6 の採用に関する周知活動に注力する。

RIPE NCC

2007/10/26

5.

既存の意思決定プロセスを尊重し、今後もボトムアップ

150

で IP アドレスポリシーの策定を行っていく。

この他にも、ICANN理事会決議やメキシコのNIRであるNIC Mexico151、APNIC地域のNIRであるTWNIC152やCNNIC153も声明を発表している。いずれの組織もIPv4 アドレス在庫枯渇に対応する策はIPv6 の採用であるということが共通している。
JPNICも 2007 年には独自の検討チームによる検討を重ね、2007 年 12 月 7 日に「IPv4 ア
ドレス在庫枯渇問題に関する検討報告書」を公開154した。これによると、IPv4 アドレスの需要予測を各種経済指標から再検討し、在庫枯渇が 2010 年から 2011 年になることが再確認された。また、IPv4 アドレス在庫枯渇への対応策としては、(1) 自網内からの捻出など
何らかの方法でIPv4 アドレスを確保する、(2) プライベートIPv4 アドレスを利用して新規顧客を収容し、NAT（ネットワークアドレス変換機構）を介してインターネットに接続する、(3) IPv6 を利用して新規顧客を収容することの 3 つの方法が考えられることという見解を示した。また、それら 3 つの解の中では、長期的なインターネットの発展を考えた場合、(3) が唯一の解となり得る、という踏み込んだ見方を示している。ただし、IPv6 の普及推進に関する検討、分配済み未利用IPv4 アドレスの回収・再在庫化、再分配の検討、利用者
146 http://www.arin.net/announcements/20070521.html
147 http://lacnic.net/en/anuncios/2007_agotamiento_ipv4.html

148 http://www.afrinic.net/news/position-on-the-future-of-IP.htm

149 http://www.apnic.net/meetings/24/program/sigs/policy/presentations/wilson-resolution.pdf
150 http://www.ripe.net/news/community-statement.html
151 http://www.nic.mx/es/Noticias_2?NEWS=220
152 http://www.twnic.net.tw/file/07801b.htm

153 http://www.cnnic.cn/html/Dir/2007/07/09/4698.htm

154 http://www.nic.ad.jp/ja/pressrelease/2007/20071207-01.html

320

の意見を反映するための施策の検討など残された課題は多く、JPNICは今後それらの課題に対し、関連各組織と連携した取り組みを進める、としている。
この報告書は 2008 年 2 月の APNIC ミーティングで紹介され、英訳版が出席者に配布された。会場の反応は非常に好意的なものであったが、そろそろ技術的検討から、いかにして
IPv6 へ移行させる経済的インセンティブを設計するかの検討に入る時期に来ているのではないか、という指摘もあった。IPv6 への移行はレジストリだけで何とかできる問題ではな
く、様々なステークホルダー間の対話が今後も引き続き必要となってくると思われる。

[アドレスの回収]
IPv4 アドレスの在庫枯渇の議論で必ず出てくる意見として、「未利用のアドレスを回収すれば、在庫は枯渇しない」というものがある。IANA や RIR では未利用のアドレスを回収するべくあらゆる努力を行っているが、2007 年はこれまでになくまとまったアドレスが回収される年になったと言える。
2008 年 2 月にIANAの担当者であるLeo Vegoda氏がICANN blogに投稿した記事155によると、IANAは 2007 年から 2008 年にかけて 4 つの/8 を回収している（46.0.0.0/8、49.0.0.0/8、50.0.0.0/8、14.0.0.0/8）。しかし同時に、IANAの調査によればあとのアドレスブロックは少なくとも一部は使われているということがわかっており、/8 がまとまった形でこれ以上戻ってくるのは望み薄であること。仮に一部が戻ってきたとしても、現在の消費ペースだと/8 を 1 個使い切るのに 1 ヶ月かからない状況であり、延命にはほとんどつながらないであろうという見解が示されている。
また、Leo Vegoda氏の別のレポート156によれば、使えるとされている未割り振りのグロー
バルアドレス在庫の中にも、実際には使えない可能性の高いアドレスが含まれているという。1.0.0.0/8、5.0.0.0/8、42.0.0.0/8 がそれであり、1.0.0.0/8 は大規模組織でプライベート
アドレス代わりに使われているケースが多く、5.0.0.0/8 はVPNサービスなどのアプリケー
ションで使われているケースがあり、42.0.0.0/8 については、アプライアンスサーバのNAT構成に使われているケースがあることが報告されている。これらのアドレスがグローバル
アドレスとして実際に割り振りが行われたときの影響は不明だが、いよいよ最後のアドレスを割り振りするという際に問題になる可能性はあるだろう。

155 http://blog.icann.org/?p=271

156 http://www.apnic.net/docs/apster/issues/apster24-200712.pdf

321

322

2

IPv6 アドレスの導入状況と、普及に関する
議論の動向

323

324

2 IPv6 アドレスの導入状況と、普及に関する議論の動向
2-1 IPv6 アドレスの導入状況
日本の ISP への IPv6 アドレス割り振り状況は、2008 年 3 月 7 日現在で 102 個が割り振られている。IPv6 アドレスの最小割り振りサイズは/32（IX 用は当初/64、後に/48。プロバイ
ダ非依存アドレスについては/48。）であるが、その大きさを越える割り振りについて以下に示す。
アドレスレンジ

割り振り年月日

2400:2000::/20

2005 年 7 月 12 日

2001:a000::/21

2004 年 12 月 1 日

2400:4000::/22

2005 年 8 月 15 日

2408::/222007 年 11 月 2 日

2001:f60::/28

2004 年 8 月 23 日

2001:d70::/30

2003 年 9 月 12 日

上記の通り、IPv6 アドレスの最小割り振りサイズである/32 を大きく超える割り振りを受けている ISP も散見されるようになってきた。今後 IPv6 の採用が進むにつれ、割り振りの大きさも増えてくると思われる。
また、IPv6 接続サービスの提供状況については 2007 年 3 月 30 日付けでIPv6 普及・高度化推進協議会が当該状況の調査結果を発表157している。それによると、確認できただけで 9社が商用IPv6 サービスを提供しており、全国レベルのプロバイダにおいては、個人、法人
ともに、IPv6 のサービスが利用できるようになっているとのことである。具体的なISP名等については、当該報告書を参照いただきたい。
またこの調査では、ISP へのアンケートを実施しており、IPv6 サービスを提供開始する時期についてもヒアリングを行っている。これによるとアンケートに回答した ISP のうち、2010 年〜2011 年を目処に IPv6 サービスの提供を開始するとの回答が最も多かったとのことである。これは RIR 関係者における、IANA での IPv4 在庫枯渇の予測時期とも重なっており、この予測が ISP の間にも浸透していることをうかがわせる。
一方、JPNICでは 2007 年 12 月 7 日に発表した「IPv4 アドレス在庫枯渇問題に関する検討

157 http://www.v6pc.jp/pdf/H18ServiceResearchResult.pdf

325報告書(第一次)」158の中で、JPNICの会員に対して実施したアンケートの結果をまとめている。アンケートでは、(1) IPv4 アドレス在庫枯渇時期の認識、(2) IPv4 アドレス在庫枯渇に対する懸念、(3) IPv4 アドレス対策実施の検討の有無、(4) JPNICへ期待すること、(5) その他自由記入、という設問を設定している。アンケートの結果によると、設問(1)によって、回答した会員のうち（以降回答会員と記す）76%の会員が 2011 年前後のIPv4 アドレス在
庫枯渇予想を認識していることが判明した一方で、過半数（56%）の回答会員が対応策の必要性は理解しているがまだ検討を行っていないということが、設問(3)によって明らかになり、IPv6 の採用はまだ進んでいないことが見て取れる。
設問(2)においても、ケーブルモデムセンター装置の IPv6 対応がされていないという懸念や、
いわゆる足回りキャリアの対応見通しが見えないことに対する懸念などが表明され、IPv6の採用に不安を感じている様子がわかる。
設問(5)の自由記入欄では、「IPv6 への対応を進めるにあたり、IPv4/IPv6 混在環境におけるネットワーク構築技術の情報を早めに提供してほしい」という声や「移行に関する技術的な対応方法のわかりやすい解説があればありがたい」という要望、、IPv6 の割り振り条
件の緩和を求める意見などが表明された。全体として、IPv6 移行の必要性を判断し、実施するための情報が不足しているという意見が多く、それらの要望に応えていくことが今後必要になってくると思われる。

2-2 IPv6 普及に関する議論の動向
1-2 において、ICANN や RIR をはじめとする各レジストリが「IPv6 の採用を推奨する」という内容の声明を行ったことを報告したが、実際の推奨策や採用に向けた取り組みはどのように進められているのか、以下、声明の詳細に触れつつ見ていく。
ICANN
ICANNはRIRコミュニティでの残存IPv4 アドレスの分配ポリシーに関する議論の高まりを受け、2007 年 6 月 29 日の理事会において「On the Deployment of IPv6」という決議を採択159した。内容は以下の通りである。

158 http://www.nic.ad.jp/ja/ip/ipv4pool/ipv4exh-report-071207.pdf
159 http://www.icann.org/minutes/resolutions-29jun07.htm#n326

IPv6 の実装に関してIANA 及び地域インターネットレジストリが保有している未割り振り IPv4 アドレス空間
は、ここ数年のうちに全て分配されることが予測されている。
したがい、インターネットの将来の成長は IPv6 の入手性と時宜にかなった採用にますます依存していくことになる。
ICANN 理事会とコミュニティは、アドレス支持組織（ASO）、NRO、地域インターネット
レジストリ、政府諮問委員会その他からの、この事項に関する認知度向上と解決策の推進への行動要求に関し合意する。
理事会はインターネットコミュニティが、インターネットの将来の可能性に対する課題に立ち向かうことを確信しており、ボトムアップで包括的、ステークホルダー主導のプロセスが機能し、必要なポリシー変更がなされることを確信している。
さらに理事会は、地域インターネットレジストリ及び他のステークホルダーと共に、IPv6の時宜にかなった採用を奨励することでインターネットの将来の成長をサポートすることを目的として、教育、アウトリーチ活動に取り組むことを決議する。

IPv6 の採用に関し、ICANNが積極的に取り組む意思を見せたのはこれが初めてではないかと思われる。その後 2007 年 12 月 18 日の理事会会議では以下の決議が採択160され、ルートサーバシステムにおいてIPv6 の採用が進むこととなった。
ルートサーバシステムにおける IPv6 採用に関する議論
IPv6 の採用を手助けするという関心において、ICANN 理事会はルートサーバシステムに対し IPv6 の機能を必要以上の遅れなく追加するべきであると信じている。
RSSAC（ルートサーバシステム諮問委員会）及び SSAC（セキュリティと安定に関する諮
問委員会）の報告書では、ルートへ IPv6 アドレスを追加することに関する技術的課題の注
意深い検討がなされている。

160 http://www.icann.org/minutes/minutes-18dec07.htm

327ここに、理事会は IANA スタッフに対し、個々の IPv4 ルートサーバ運用者からの申し出に応じ、IPv4 アドレスの追加や変更の際になされる手法と同様に、45 日の周知期間の後、既存のルートネームサーバに対し IPv6 機能を追加することを要請する。

この後実際に、A、F、H、J、K、Mの 6 つのルートサーバに対し、IPv6 アドレスが追加されることとなった。ICANNは 2008 年 2 月 4 日のアナウンス161でその旨周知している。今後ICANNとしては、まずはICANN自身のインフラを中心にIPv6 対応を進めていくことと
なる。

ARIN
ARINの理事会は 2007 年 5 月 21 日付けで声明を発表162し、コミュニティに対しIPv6 への移行を呼びかけた。決議内容は以下の通りである。
インターネットプロトコル番号資源の在庫に関する ARIN 理事会決議
コミュニティがインターネットプロトコル(IP)番号資源を利用できることは、インターネッ
トの良好な成長に不可欠である。
一方、コミュニティが今後もインターネットプロトコルバージョン 4(IPv4)番号資源を利用できるかについて、無期限の保証をすることはできない。
また、インターネットプロトコルバージョン 6(IPv6)番号資源は利用可能であり、様々なイ
ンターネットのアプリケーションに適したものである。
これらに鑑み、本理事会はここにインターネットコミュニティに対し、今後も ARIN に対し連続した IP 番号資源の申請が必要であれば、IPv6 番号資源への移行が必要になることを助言することを決議する。
また、本理事会はここに ARIN スタッフに対し、ARIN に対してなされる IPv4 番号資源申請の信憑性を保証するために必要なあらゆる手段を講じることを命じる。
さらに、本理事会はここに ARIN 評議会(Advisory Council)に対し、可能な限りにおいて
161 http://www.icann.org/announcements/announcement-04feb08.htm
162 http://www.arin.net/announcements/2007/20070521.html

328

IPv6 番号資源への移行を促進するためのインターネット番号資源ポリシー変更が勧告可能かの検討を要請することを決議する。
ARINはその後、2007 年 7 月 19 日にIPv6 の実装に役立つと思われる情報を集積したサイトを開設163した。このサイトはwiki形式で作成されており、関心のある者は誰でも情報の投稿を行うことができる。2008 年 3 月現在では、IPv6 実装に関するプレゼンテーション、
アドレス割り当て方法の情報、実装計画の立て方、IPv6 の管理ツールの情報などが投稿さ
れている。

APNIC
APNICは 2007 年 9 月 7 日に、コミュニティ全体として決議文を採択164した。IPv6 の奨励に関する部分を以下に抜粋する。
…我々はインターネットの未来の成功のために、IPv6 が決定的に重要であることを認識している。我々は、アジア太平洋地域における IPv6 の包括的な採用に向け我々の努力を集中する。
我々は、開かれたボトムアップのコンセンサスをベースとした意思決定への支持を確認する。しかし、我々はまたこのコミュニティの先達メンバーや専門家に対し、アジア太平洋
地域にとどまらず全世界において、IPv4 アドレス管理と IPv6 への移行という問題解決のための調査検討を行うための強いリーダーシップを要請する。
ただし、2008 年 3 月現在特に APNIC において IPv6 の採用に関して特筆すべき事項は見当たらない。

RIPE NCC
2007 年 10 月に行われた RIPE ミーティングの中で、APNIC と同じようにコミュニティ全体としての決議文を採択した。内容は以下の通りである。

…IPv6 は将来の成長に必要なアドレス空間を提供する。したがい、我々はより広範な IPv6
アドレスの採用を奨励する必要がある。既存の IPv4 インターネットは現在と同様機能し続けるが、将来の IP ネットワークの成長のためには IPv6 の採用が必要である。…我々は、
163 http://www.arin.net/announcements/2007/20070719_wiki.html

164 http://www.apnic.net/meetings/24/program/sigs/policy/presentations/wilson-resolution.pdf

329

サービス提供者がそれぞれのサービスを IPv6 上で提供可能にするよう勧告する。我々は、非常に多くの新しいアドレス資源を必要とする者は、IPv6 を採用することを要求する。我々は政府に対し IPv6 の採用において政府の役割を果たすことを奨励する。特に、全ての市民が将来の情報社会に参加できるよう保証することを奨励する。我々は、全ての利害関係者が IPv6 の広範な採用を優先課題とすることを要求する。

RIPE 地域においては以前から IPv6 の割り振り量が多かったが、2007 年 10 月には 24 回の割り振りが行われ、さらに 11 月には 31 回の割り振りが行われた。RIPE NCC によると、
これらは従来の月間割り振り回数の記録を抜き、過去最高だとのことである。
こうした旺盛な需要を反映してか、2008 年 3 月現在特に RIPE NCC における IPv6 の採用に関して特筆すべき事項は見当たらない。

LACNICLACNICは 2007 年 6 月 20 日に声明を発表165した。IPv6 の採用に関しては以下のように述べている。
複数名の調査者による予想により、2011 年までに IPv4 アドレスの中央在庫が完全に枯渇するということが示されているが、これに対応して LACNIC は 2011 年 1 月 1 日までに地域内の全てのネットワークが IPv6 を採用するよう地域キャンペーンを実施することを発表した。
Raul Echeberria 氏は、…政府、そして公共機関はできるだけ早期に IPv6 を採用するための必要な準備を行うべきだとも述べている。
…Echeberria 氏はまた、LACNIC 理事会の決定に基づき、当組織が IPv6 利用を推奨する
ための地域内でのイベントや会議からなるキャンペーンを開始すると述べた。このキャン
ペーンの補完として、この問題に関する関連情報を継続的に公開する。キャンペーンの目
標は、ラテンアメリカ及びカリブ海地域が 2011 年 1 月 1 日までに IPv6 採用プロセスを終了することである。
…地域内のネットワークが移行及び対応を行うことを推奨するため、LACNIC による IPv6
割り振りは費用無しで行われる。

165 http://lacnic.net/en/anuncios/2007_agotamiento_ipv4.html

330

LACNIC地域では、レジストリが目標期日（2011 年 1 月 1 日）を設定してIPv6 採用を働
きかけ、費用の面からも積極的にIPv6 の採用を促す施策をとっていることがその特徴といえるだろう。また、IPv6 への移行に関する情報を集めた「portal IPv6」という専用ページ
166も設けられており、レジストリ自ら積極的にIPv6 の採用を働きかけようという姿勢が見て取れる。

AfriNIC
AfriNIC は 2007 年 7 月 25 日付けの会員向けレターの中で、IPv6 の採用を呼びかけている。
内容は以下の通りである。
…アフリカ地域におけるネットワーク運用者に対して、ネットワークインフラに IPv4 と同時に IPv6 を採用することへ明確なアクションを取ってもらうことは我々の責務である。パニックになるほど切羽詰まってはいないが、後から緊急事態になることを避けるため、今そのアクションを起こすことが重要である。
AfriNIC では会員向けの IPv6 割り振りは、初回割り振りへの課金免除を続けている。
また、AfriNICにおいてもIPv6 に関する基本情報を提供するポータルサイトを開設167している。報道機関向けの資料168では、「2011 年 1 月１日までに、全てのアフリカ地域にIPv6が配布されていることが必要である」と明確な目標を設定している。

166 http://portalipv6.lacnic.net/en
167 http://www.afrinic.net/IPv6/index.htm

168 http://www.afrinic.net/news/press/press_release_ipv4_exhaustion_press.pdf

331

332

第4部

参考資料

333

334

1

ドメイン名に関する各種統計資料

335

336

1 ドメイン名関連統計資料
1-1 gTLD レジストラ間のマーケットシェア状況
現在のレジストリ・レジストラモデルは、1999 年 4 月にICANNが共有レジストリシステ
ム（Shared Registry System: SRS）でのテストベッドレジストラ 5 社を選定したことに始まり、その後本格運用に入ったのであるが、ICANNが認定するレジストラの数は年々増加（そのうち、日本国内のレジしており、2008 年 2 月 29 日現在では 908 社に上っている169。
ストラは 7 社。）

gTLD

レジストラの数.com/.net

873 社

http://www.verisign.com/information-services/naming-services/com-net-registry/page_002166.html

.org

293 社

http://www.pir.org/index.php?db=content/Website

参照 URL&tbl=Registrants&id=2

.info

295 社

http://www.nic.info/register/find/alphabetical

.biz

235 社

http://www.neulevel.biz/partners/registrars.html

.name

590 社

http://www.nic.name/registrarlist.html

.aero

16 社

http://www.information.aero/cgi-bin/registrar_list.cgi

.coop

9社

http://www.nic.coop/registrarlist.asp.museum

3社

http://about.museum/registrars/

.pro

15 社

http://www.registrypro.pro/partners_findaregistrar.htm

.jobs

22 社

http://www.goto.jobs/buy_now.asp.travel

29 社

http://www.travel.travel/dnr.htm

.cat

15 社

http://www.domini.cat/registrar.html

.mobi

147 社

http://mtld.mobi/domain/find

169 ICANN認定レジストラ一覧：

http://www.icann.org/registrars/accredited-list.html

337

1-2 レジストラ別ドメイン名登録数一覧
レジストラのマーケットシェア状況については、各レジストリが ICANN に提出する月間報告書に記載されているレジストラ別ドメイン名登録数一覧を以下に添付する。（主要 gTLD
のみ）
● .com レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

● .org レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

376

377

378

379

380

● .info レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

381

382

383

384

385

386

● .biz レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

387

388

389

390

391

● .aero レジストラ別ドメイン名登録数一覧（2006 年 9 月時点）

● .museum レジストラ別ドメイン名登録数一覧（2005 年 12 月時点）

※ .museum のゾーンに登録されているが、公認レジストラの管理下に移っていないドメ
イン名を含めた登録総数は 2855
● .coop レジストラ別ドメイン名登録数一覧（2007 年 10 月）

392

● .pro レジストラ別ドメイン名登録数一覧（2007 年 10 月）● .name レジストラ別ドメイン名登録数一覧（2007 年 10 月）

393

394

395

396

● .travel レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

397

● .cat レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

398

● .mobi レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

399

400

401

● .jobs レジストラ別ドメイン名登録数一覧（2007 年 10 月時点）

402

1-3 ccTLD別ドメイン名登録数一覧170（2008 年 1 月時点）

ccTLD

国／地域

登録数

1

de

ドイツ

Germany

11,771,605

2

cn

中国

China

9,001,993

3

uk

イギリス

United Kingdom

6,486,829

4

eu

欧州連合

European Union

2,760,034

5

nl

オランダ

Netherlands

2,736,351

6

it

イタリア

Italy

1,482,092

7

us

アメリカ合衆国

United States

1,386,412

8

br

ブラジル

Brazil

1,238,113

9

ru

ロシア連邦

Russian Federation

1,070,482

10

ch

スイス

Switzerland

1,056,751

11

fr

フランス

France1,035,479

12au

オーストラリア

Australia

1,024,176

13

jp

日本

Japan

996,170

14

ca

カナダ

Canada959,355

15

kr

大韓民国

Korea, Republic of

937,209

16

dk

デンマーク

Denmark

874,832

17

pl

ポーランド

Poland833,417

18

es

スペイン

Spain

805,327

19

be

ベルギー

Belgium

746,02220

atオーストリアAustria

724,99721

se

スウェーデン

Sweden701,268

22

cc

ココス諸島

Cocos (Keeling) Islands

581,147

23

ar

アルゼンチン

Argentina

479,549

24

tv

ツバル

Tuvalu473,168

25

cz

チェコ

Czech Republic

384,929

26

no

ノルウェー

Norway365,067

27

tw

台湾

Taiwan356,184

28

hu

ハンガリー

Hungary

350,000

29

ua

ウクライナ

Ukraine319,637170

登録数が公表されていないccTLDは除く。
また、登録数データは各レジストリの公開データに基づく（レジストリによる公開データが存在しない
ccTLD は一般の統計情報に基づく）。

403

30

nz

ニュージーランド

New Zealand

311,198

31

in

インド

India

300,000

32

ws

西サモア

Western Samoa

253,029

33

mx

メキシコ

Mexico234,11234fi

フィンランドFinland168,148

35

hk

香港

Hong Kong

152,405

36

tr

トルコ

Turkey149,214

37

my

マレーシア

Malaysia

107,61138

ie

アイルランドIreland

93,69939

sg

シンガポールSingapore

88,975

40

lt

リトアニア

Lithuania

68,433

41

vn

ベトナム

Viet Nam

63,983

42

hr

クロアチア

Croatia (Hrvatska)

54,241

43

si

スロベニア

Slovenia

52,55144li

リヒテンシュタイン

Liechtenstein

52,37845

lu

ルクセンブルク

Luxembourg

36,135

46

ma

モロッコ

Morocco25,873

47

pe

ペルー

Peru

21,952

48

co

コロンビア

Colombia

21,06149

is

アイスランドIceland20,500

50

uy

ウルグアイ

Uruguay

14,26051sa

サウジアラビア

Saudi Arabia

12,245

52

tn

チュニジア

Tunisia

10,031

53

cr

コスタリカ

Costa Rica

7,400

54

py

パラグアイ

Paraguay

6,801

55

ba

ボスニア・ヘルツェゴビナ

Bosnia and Herzegowina

6,553

56

uz

ウズベキスタンUzbekistan

6,005

57

ps

パレスチナ

Palestinian Territories

5,500

58

bg

ブルガリア

Bulgaria

4,894

59

jo

ヨルダン

Jordan

3,716

60

ni

ニカラグア

Nicaragua

3,432

61

mt

マルタ

Malta

2,691

62

lb

レバノン

Lebanon

2,100

63

mo

マカオ

Macau

2,075

64

re

レユニオン

Reunion

1,831

404

65

mc

モナコ

Monaco

1,444

66

bb

バルバドス

Barbados

1,048

67

an

オランダ領アンティル

Netherlands Antilles

793

68

bt

ブータン

Bhutan

84

405

406

2

IP アドレス、AS 番号に関する各種統計資料

407

408

2 国毎の IP アドレス割当量等、IP アドレスに関する各種統計資料
IP アドレスの管理原則の一つに、「登録」というものがある。これは、「インターネットアドレス
空間の割り当てと割り振りは、インターネットコミュニティの全メンバーがアクセス可能な、公開されているレジストリデータベースに登録されなければならない」という原則を表している。
この原則に従い、RIR では自身の行った割り振り、割り当ての情報をインターネット上に公開している。この章で掲載する統計は、その公開資料を集計したものである。
公開資料の保存箇所は以下の通りである。
AfriNIC：ftp://ftp.afrinic.net/pub/stats/afrinic/
APNIC：ftp://ftp.apnic.net/pub/stats/apnic/
ARIN：ftp://ftp.arin.net/pub/stats/arin/
LACNIC：ftp://ftp.lacnic.net/pub/stats/lacnic/
RIPE NCC：ftp://ftp.ripe.net/ripe/stats/
ここでは上記で提供されている情報をもとに統計をまとめた。なお、本章で集計した統計は全て2008 年 1 月 31 日現在のデータを使用した。次ページ以降、資源種別（IPv4 アドレス、IPv6 ア
ドレス、AS 番号）毎に、国・地域別の分配状況を示す。

409

表21： 割り当て済み IPv4 アドレス分配状況 − 国・地域別

順位

国・地域

割当数

順位

国・地域

全リスト

割当数

1

米国(US)

1,409,909,248

32

ｱﾙｾﾞﾝﾁﾝ(AR)5,191,9362

日本(JP)

141,623,552

33

ﾁｪｺ(CZ)

4,924,800

3

中国(CN)

136,644,86434

ﾁﾘ(CL)

4,244,736

4

欧州連合(EU)

120,351,708

35

ｼﾝｶﾞﾎﾟｰﾙ(SG)4,173,312

5

ｲｷﾞﾘｽ(GB)83,614,52236

ﾀｲ(TH)

4,076,800

6

ﾄﾞｲﾂ(DE)

72,429,360

37

ｱｲﾙﾗﾝﾄﾞ(IE)

4,012,800

7

ｶﾅﾀﾞ(CA)

71,920,640

38

ﾍﾞﾄﾅﾑ(VN)

3,840,2568

ﾌﾗﾝｽ(FR)

67,803,168

39

ｲｽﾗｴﾙ(IL)3,757,248

9

韓国(KR)

59,456,256

40

ﾎﾟﾙﾄｶﾞﾙ(PT)3,552,832

10

ｵｰｽﾄﾗﾘｱ(AU)33,460,736

41

ﾍﾞﾈｽﾞｴﾗ(VE)

3,527,16811

ｲﾀﾘｱ(IT)

24,046,016

42

ﾊﾝｶﾞﾘｰ(HU)

3,384,192

12

ﾌﾞﾗｼﾞﾙ(BR)23,463,424

43

ﾏﾚｰｼｱ(MY)3,286,528

13

ﾒｷｼｺ(MX)

21,504,000

44

ｷﾞﾘｼｬ(GR)3,182,336

14

ｽﾍﾟｲﾝ(ES)20,551,840

45

ｺﾛﾝﾋﾞｱ(CO)3,099,904

15

ｵﾗﾝﾀﾞ(NL)

19,890,216

46

ｳｸﾗｲﾅ(UA)2,881,088

16

台湾(TW)

19,865,344

47

ｲﾝﾄﾞﾈｼｱ(ID)2,814,464

17

ﾛｼｱ(RU)17,256,328

48

ﾌﾞﾙｶﾞﾘｱ(BG)

2,508,800

18

ｽｳｪｰﾃﾞﾝ(SE)16,891,616

49

ﾌｨﾘﾋﾟﾝ(PH)2,376,960

19

ｲﾝﾄﾞ(IN)

13,906,688

50

ｴｼﾞﾌﾟﾄ(EG)2,177,280

20

南ｱﾌﾘｶ共和国(ZA)

13,610,240

51

ﾘﾄｱﾆｱ(LT)1,969,792

21

ﾎﾟｰﾗﾝﾄﾞ(PL)12,222,732

52

ｻｳｼﾞｱﾗﾋﾞｱ(SA)1,706,240

22

ﾌｨﾝﾗﾝﾄﾞ(FI)8,638,592

53

ｱﾗﾌﾞ首長国連邦(AE)1,495,040

23

ﾄﾙｺ(TR)8,430,016

54

ｲﾗﾝ(IR)

1,446,400

24

ﾃﾞﾝﾏｰｸ(DK)

7,902,048

55

ｽﾛﾊﾞｷｱ(SK)1,391,104

25

ｽｲｽ(CH)7,537,856

56

ｺｽﾀﾘｶ(CR)1,307,392

26

香港(HK)

7,246,33657

ﾍﾟﾙｰ(PE)

1,253,120

27

ﾉﾙｳｪｰ(NO)6,731,808

58

ﾗﾄﾋﾞｱ(LV)

1,252,416

28

ｵｰｽﾄﾘｱ(AT)6,709,216

59

ｽﾛﾍﾞﾆｱ(SI)1,097,75429

ﾙｰﾏﾆｱ(RO)6,675,584

60

ｴｽﾄﾆｱ(EE)

1,003,008

30

ﾍﾞﾙｷﾞｰ(BE)5,445,504

61

ｸﾛｱﾁｱ(HR)895,072

31

ﾆｭｰｼﾞｰﾗﾝﾄﾞ(NZ)

5,422,33662

ﾊﾟﾅﾏ(PA)872,448

410

順位

国・地域

割当数

順位

国・地域

割当数

63

旧ﾁｪｺｽﾛﾊﾞｷｱ(CS)763,904

97

ﾓﾙﾄﾞﾊﾞ(MD)187,136

64

ﾊﾟｷｽﾀﾝ(PK)727,296

98

ﾌﾞﾙﾈｲ(BN)174,592

65

ﾁｭﾆｼﾞｱ(TN)631,04099

ﾊﾞｰﾚｰﾝ(BH)

165,888

66

ｶｻﾞﾌｽﾀﾝ(KZ)

598,016100

ｵﾏｰﾝ(OM)

163,84067

ﾓﾛｯｺ(MA)585,984

101

ﾍﾞﾗﾙｰｼ(BY)

158,720

68

ﾌﾟｴﾙﾄﾘｺ(PR)572,416102

ﾏｶｵ(MO)

146,68869

ｴｸｱﾄﾞﾙ(EC)553,216103

ｱｾﾞﾙﾊﾞｲｼﾞｬﾝ(AZ)

141,31270

ｸｳｪｰﾄ(KW)

542,208104

ｶﾞｰﾅ(GH)

129,53671

ｱｲｽﾗﾝﾄﾞ(IS)530,688105

ｳｽﾞﾍﾞｷｽﾀﾝ(UZ)

129,024

72

ｳﾙｸﾞｱｲ(UY)

441,600

106

ｼﾘｱ(SY)

128,000

73

ｷﾌﾟﾛｽ(CY)435,232

107

ﾆｶﾗｸﾞｱ(NI)124,92874

ｱｼﾞｱ太平洋地域(AP)421,120108

ｳｶﾞﾝﾀﾞ(UG)

116,22475

ﾏｹﾄﾞﾆｱ(MK)408,320

109

ｱﾙﾊﾞﾆｱ(AL)110,848

76

ﾏﾙﾀ(MT)

394,240

110

ｱﾙﾒﾆｱ(AM)109,344

77

ﾊﾞﾝｸﾞﾗﾃﾞｼｭ(BD)382,464

111

ｼﾞｬﾏｲｶ(JM)

105,47278

ｶﾀｰﾙ(QA)

372,736

112

ﾊﾞﾙﾊﾞﾄﾞｽ(BB)103,168

79

ﾙｸｾﾝﾌﾞﾙｸﾞ(LU)

351,488

113

ｷｭｰﾊﾞ(CU)101,37680

ﾎﾞﾘﾋﾞｱ(BO)343,296

ｷﾙｷﾞｽﾀﾝ(KG)

101,37681

ｴﾙｻﾙﾊﾞﾄﾞﾙ(SV)336,896

115

ﾓﾝｺﾞﾙ(MN)

100,608

82

ﾎﾞｽﾆｱ･ﾍﾙﾂｪｺﾞﾋﾞﾅ(BA)327,680

116

ｶﾝﾎﾞｼﾞｱ(KH)

98,81683

ｽﾘﾗﾝｶ(LK)

303,104

117

ｺｰﾄｼﾞﾎﾞｱｰﾙ(CI)91,39284

ﾅｲｼﾞｪﾘｱ(NG)301,568

ﾌｨｼﾞｰ(FJ)

91,39285

ﾘﾋﾞｱ(LY)

294,912119

ﾊﾟﾗｸﾞｱｲ(PY)

90,11286

ｱﾙｼﾞｪﾘｱ(DZ)

266,240120

ﾈﾊﾟｰﾙ(NP)88,57687

ﾄﾞﾐﾆｶ共和国(DO)265,984

121

米領ﾊﾞｰｼﾞﾝ等(VI)82,94488

ｸﾞｱﾃﾏﾗ(GT)262,144122

ﾀﾝｻﾞﾆｱ(TZ)

82,43289

ﾖﾙﾀﾞﾝ(JO)253,696

123

ﾊﾞｰﾐｭｰﾀﾞ(BM)79,36090

ｸﾞﾙｼﾞｱ(GE)249,856

124

ﾙﾜﾝﾀﾞ(RW)

77,82491

ﾄﾘﾆﾀﾞｰﾄﾞ･ﾄﾊﾞｺﾞ(TT)242,432125

ｸﾞｱﾑ(GU)73,98492

ﾊﾟﾚｽﾁﾅ(PS)241,664126

ﾎﾞﾂﾜﾅ(BW)72,70493

ｹﾆｱ(KE)

214,016127

ｽｰﾀﾞﾝ(SD)67,58494

ﾚﾊﾞﾉﾝ(LB)

205,056

128

ｱﾌｶﾞﾆｽﾀﾝ(AF)65,53695

ﾓｰﾘｼｬｽ(MU)

202,496

ﾊﾞﾊﾏ(BS)

65,53696

ｵﾗﾝﾀﾞ領ｱﾝﾃｨﾙ(AN)200,704

ﾓﾅｺ(MC)64,832

130

411

順位

国・地域

割当数

131

ﾎﾝｼﾞｭﾗｽ(HN)61,696132

ﾘﾋﾃﾝｼｭﾀｲﾝ(LI)

133

順位

割当数

ｴﾁｵﾋﾟｱ(ET)16,38455,328ｸﾞﾘｰﾝﾗﾝﾄﾞ(GL)16,384

ｶﾒﾙｰﾝ(CM)53,760ｶﾞｲｱﾅ(GY)16,384134

ｾﾙﾋﾞｱ(RS)53,504

ﾓﾝﾃﾈｸﾞﾛ(ME)16,384135

ﾍﾞﾘｰｽﾞ(BZ)

49,664169

ｻﾞﾝﾋﾞｱ(ZM)

13,568136

ｼﾞﾌﾞﾗﾙﾀﾙ(GI)47,104170

ﾐｬﾝﾏｰ(MM)12,288137

ｱﾝｺﾞﾗ(AO)

46,336

北ﾏﾘｱﾅﾃ諸島(MP)12,288138

ｾﾈｶﾞﾙ(SN)43,264ｾｲｼｪﾙ(SC)12,288139

ﾆｭｰｶﾚﾄﾞﾆｱ(NC)43,008ﾄｰｺﾞ(TG)

12,288140

ﾅﾐﾋﾞｱ(NA)39,936174

西ｻﾓｱ(WS)

11,520141

ﾌﾗﾝｽ領ﾎﾟﾘﾈｼｱ(PF)39,424175

ｶﾞﾝﾋﾞｱ(GM)11,264142

ｱﾝﾃｨｸﾞｧ･ﾊﾞｰﾌﾞｰﾀﾞ(AG)38,912176

ｹｲﾏﾝ諸島(KY)

9,216

ﾓｻﾞﾝﾋﾞｰｸ(MZ)

38,912177

ﾏﾗｳｲ(MW)

8,704

144

ﾊﾟﾌﾟｱﾆｭｰｷﾞﾆｱ(PG)

34,560

ｿﾛﾓﾝ諸島(SB)

8,704

145

ﾌｪﾛｰ諸島(FO)33,792

ｸｯｸ諸島(CK)

8,192

146

ｶﾞﾎﾞﾝ(GA)33,280

ﾓｰﾘﾀﾆｱ(MR)8,192ｼﾞﾝﾊﾞﾌﾞｴ(ZW)

33,280ﾅｳﾙ(NR)

8,192

ﾊｲﾁ(HT)

32,768ﾂﾊﾞﾙ(TV)

8,192

ﾚﾕﾆｵﾝ島(RE)32,768ﾊﾞﾁｶﾝ市国(VA)

8,192

150

ｲﾗｸ(IQ)

30,720

ﾚｿﾄ(LS)

6,400

151

ﾀｼﾞｷｽﾀﾝ(TJ)

28,672

ﾊﾞﾇｱﾂ(VU)

6,400

152

ｱﾝﾄﾞﾗ(AD)24,576

ﾍﾞﾅﾝ(BJ)

6,144

ｲｴﾒﾝ(YE)

24,576

ﾏﾝ島(IM)

6,144

154

ﾗｵｽ(LA)

22,784188

ﾄﾝｶﾞ(TO)

4,352

155

ﾌﾞｰﾀﾝ(BT)22,528189

ｱﾝｷﾞﾗ(AI)

4,096

156

ｽﾜｼﾞﾗﾝﾄﾞ(SZ)

21,248ｱﾒﾘｶﾝｻﾓｱ(AS)

4,096

157

ﾓﾙﾃﾞｨﾌﾞ(MV)20,992

ｵｰﾗﾝﾄﾞ諸島(AX)

4,096

158

ﾏﾀﾞｶﾞｽｶﾙ(MG)20,480ｶｰﾎﾞﾍﾞﾙﾃﾞ(CV)4,096

ﾏﾘ(ML)

20,480ｼﾞﾌﾞﾁ(DJ)4,096

ｻﾝﾏﾘﾉ(SM)20,480

ｴﾘﾄﾘｱ(ER)

4,096

161

ｽﾘﾅﾑ(SR)

19,456

ｸﾞｱﾄﾞﾙｰﾌﾟ(GP)

4,096

162

ｱﾙﾊﾞ(AW)

18,432ﾊﾟﾗｵ(PW)

4,096

ｼｴﾗﾚｵﾈ(SL)18,432

ﾀｰｸｽ･ｶｲｺｽ諸島(TC)4,096

ﾌﾞﾙｷﾅﾌｧｿ(BF)

17,152

ﾄﾙｸﾒﾆｽﾀﾝ(TM)

4,096

148

164

412

165

国・地域

179

184
186

順位

国・地域

199

中央ｱﾌﾘｶ共和国(CF)3,072

英領ｲﾝﾄﾞ洋地域(IO)

3,072

ｷﾘﾊﾞｽ(KI)3,072

ｾﾝﾄｸﾘｽﾄﾌｧｰ･ﾈｲﾋﾞｽ
(KN)

割当数

3,072

203

ｺﾝｺﾞ民主共和国(CD)

2,560

204

ﾌﾞﾙﾝｼﾞ(BI)

2,304

205

ﾐｸﾛﾈｼｱ(FM)2,048

ﾌﾗﾝｽ領ｷﾞｱﾅ(GF)

2,048

ｶﾞｰﾝｼﾞｰ(GG)2,048

赤道ｷﾞﾆｱ(GQ)

2,048

ｼﾞｬｰｼﾞｰ(JE)

2,048

ﾏｰｼｬﾙ諸島(MH)2,048

ｾﾝﾄﾋﾞﾝｾﾝﾄ･ｸﾞﾚﾅﾃﾞｨｰﾝ
(VC)

2,048

ﾜﾘｽ･ﾌﾃｭﾅ諸島(WF)

2,048

213

ﾉｰﾌｫｰｸ島(NF)

1,280

214

ｺﾝｺﾞ(CG)

1,024

ｷﾞﾆｱﾋﾞｻｳ(GW)1,024

ﾆｳｴ(NU)

1,024

米領ﾊﾞｰｼﾞﾝ諸島(VG)

1,024

218

ｸﾞﾚﾅﾀﾞ(GD)

256

ｾﾝﾄﾙｼｱ(LC)256

ﾓﾝﾄｾﾗﾄ(MS)

256

413

表22： 割り当て済み IPv6 アドレス分配状況 − 国・地域別

順位

国・地域

割当数

順位
32

1

ﾄﾞｲﾂ(DE)

9,658.02

ﾌﾗﾝｽ(FR)

3

全リスト（/32 単位）

国・地域

割当数

ﾍﾞﾙｷﾞｰ(BE)13.0

8,304.0

ﾀｲ(TH)

13.0

日本（JP）

8,300.4

ﾍﾞﾈｽﾞｴﾗ(VE)

13.0

4

ｵｰｽﾄﾗﾘｱ(AU)8,214.1

南ｱﾌﾘｶ共和国（ZA）

12.0

5

欧州連合（EU）

6,157.0

ﾃﾞﾝﾏｰｸ(DK)

12.0

6

韓国（KR）

5,191.0

ﾎﾟﾙﾄｶﾞﾙ(PT)

11.0

7

ｲﾀﾘｱ(IT)

4,134.0

香港（HK）

11.0

8

台湾（TW）

2,309.0

ｲﾗﾝ(IR)

10.0

9

ﾎﾟｰﾗﾝﾄﾞ(PL)2,089.0

ﾄﾙｺ(TR)

10.0

10ｲｷﾞﾘｽ(GB)

1,153.0

ｴｽﾄﾆｱ(EE)

9.0

11ｵﾗﾝﾀﾞ(NL)

571.0

ﾌﾞﾗｼﾞﾙ(BR)

9.0

12

米国（US）

334.0

ﾊﾝｶﾞﾘｰ(HU)

8.0

13

ﾉﾙｳｪｰ(NO)273.0

ﾌｨﾘﾋﾟﾝ(PH)

8.0

14

ｽｳｪｰﾃﾞﾝ(SE)157.0

ﾙｸｾﾝﾌﾞﾙｸﾞ(LU)

7.0

15

ｽｲｽ(CH)

68.0

ﾁﾘ(CL)

7.0

16

ｶﾅﾀﾞ(CA)38.0

ｼﾝｶﾞﾎﾟｰﾙ(SG)

7.0

17

ｱﾙｾﾞﾝﾁﾝ(AR)34.0

ｽﾛﾊﾞｷｱ(SK)

6.0

18

中国（CN）

31.0

ｺﾛﾝﾋﾞｱ(CO)

6.0

19

ｵｰｽﾄﾘｱ(AT)29.0

ﾍﾟﾙｰ(PE)

6.0

20

ﾁｪｺ(CZ)

22.0

ﾌﾞﾙｶﾞﾘｱ(BG)

5.0

21

ｽﾍﾟｲﾝ(ES)21.0

ﾊﾞﾝｸﾞﾗﾃﾞｼｭ(BD)

5.0

22

ﾛｼｱ(RU)

20.0

ﾊﾟｷｽﾀﾝ(PK)

5.0

23

ﾆｭｰｼﾞｰﾗﾝﾄﾞ(NZ)

18.0

ﾙｰﾏﾆｱ(RO)

5.0

ｱｲﾙﾗﾝﾄﾞ(IE)

18.0

ｲｽﾗｴﾙ(IL)4.0

ｳﾙｸﾞｱｲ(UY)

18.0

ﾍﾞﾄﾅﾑ(VN)

4.0

ｱｼﾞｱ太平洋（AP）

18.0

ｴｼﾞﾌﾟﾄ(EG)

4.0

27

ｲﾝﾄﾞﾈｼｱ(ID)16.0

ｸﾞｱﾃﾏﾗ(GT)

4.0

28

ﾌｨﾝﾗﾝﾄﾞ(FI)15.0

ｽﾛﾍﾞﾆｱ(SI)4.0

ﾏﾚｰｼｱ(MY)15.0

ｳｸﾗｲﾅ(UA)4.0

ｲﾝﾄﾞ(IN)

14.0

ｺｽﾀﾘｶ(CR)

3.0

ﾒｷｼｺ(MX)

14.0

旧ﾁｪｺｽﾛﾊﾞｷｱ(CS)

3.0

30

414

35
37
39
41
43
45

48

51

55

61

順位
61

71

83

国・地域

割当数

順位

ｷｭｰﾊﾞ(CU)

3.0

83ﾄﾞﾐﾆｶ共和国(DO)

国・地域

割当数

ｶﾞｰﾅ(GH)

1.0

3.0

ﾊｲﾁ(HT)

1.0

ｷﾞﾘｼｬ(GR)3.0

ﾏﾝ島(IM)

1.0

ｱｲｽﾗﾝﾄﾞ(IS)3.0ｽﾘﾗﾝｶ(LK)

1.0

ﾘﾄｱﾆｱ(LT)3.0

ﾓﾅｺ(MC)

1.0

ﾗﾄﾋﾞｱ(LV)

3.0

ﾓﾙﾄﾞﾊﾞ(MD)

1.0

ﾏﾙﾀ(MT)

3.0

ﾏｹﾄﾞﾆｱ(MK)1.0

ﾊﾟﾅﾏ(PA)

3.0

ﾏﾘ(ML)

1.0

ｸﾛｱﾁｱ(HR)2.0

ﾏﾗｳｲ(MW)1.0

ﾀﾝｻﾞﾆｱ(TZ)

2.0

ﾅｲｼﾞｪﾘｱ(NG)1.0ｱﾙﾒﾆｱ(AM)2.0

ﾆｶﾗｸﾞｱ(NI)1.0

ﾎﾞﾘﾋﾞｱ(BO)2.0

ｵﾏｰﾝ(OM)

1.0

ｺｰﾄｼﾞﾎﾞｱｰﾙ(CI)2.0ﾊﾟﾌﾟｱﾆｭｰｷﾞﾆｱ(PG)

1.0ｷﾌﾟﾛｽ(CY)

2.0

ﾊﾟﾗｸﾞｱｲ(PY)

1.0

ｴｸｱﾄﾞﾙ(EC)

2.0

ｶﾀｰﾙ(QA)

1.0

ﾓﾛｯｺ(MA)

2.0

ﾙﾜﾝﾀﾞ(RW)

1.0

ﾏｶｵ(MO)

2.0

ｾｲｼｪﾙ(SC)1.0

ﾓｰﾘｼｬｽ(MU)

2.0

ｽｰﾀﾞﾝ(SD)1.0

ｻｳｼﾞｱﾗﾋﾞｱ(SA)2.0

ｾﾈｶﾞﾙ(SN)

1.0

ﾄﾘﾆﾀﾞｰﾄﾞ･ﾄﾊﾞｺﾞ(TT)2.0

ｴﾙｻﾙﾊﾞﾄﾞﾙ(SV)1.0

ﾌｨｼﾞｰ(FJ)

1.0

ｽﾜｼﾞﾗﾝﾄﾞ(SZ)

1.0

ｹﾆｱ(KE)

1.0

ﾁｭﾆｼﾞｱ(TN)1.0

ｱﾝﾄﾞﾗ(AD)1.0

ﾊﾞﾁｶﾝ市国(VA)

1.0

ｱﾗﾌﾞ首長国連邦(AE)1.0ｼﾞﾝﾊﾞﾌﾞｴ(ZW)

1.0

ｵﾗﾝﾀﾞ領ｱﾝﾃｨﾙ(AN)1.0ﾌﾟｴﾙﾄﾘｺ(PR)0.0ｱﾝｺﾞﾗ(AO)

1.0

ﾎﾞｽﾆｱ･ﾍﾙﾂｪｺﾞﾋﾞﾅ(BA)1.0

ﾊﾞｰﾚｰﾝ(BH)

1.0

ﾍﾞﾅﾝ(BJ)

1.0

ﾊﾞｰﾐｭｰﾀﾞ(BM)1.0

ﾊﾞﾊﾏ(BS)

1.0

ｶﾒﾙｰﾝ(CM)1.0

ｼﾞﾌﾞﾁ(DJ)1.0

ｱﾙｼﾞｪﾘｱ(DZ)

1.0

121

415

表23： 割り当て済み AS 番号分配状況 − 国・地域別

順位

国・地域

割当数

順位

全リスト

国・地域

割当数

1

米国(US)

18,34131

ﾀｲ(TH)

187

2

ﾛｼｱ(RU)

2,025

33

台湾(TW)

184

3

ｲｷﾞﾘｽ(GB)

1,542

34

ﾗﾄﾋﾞｱ(LV)

161

4

欧州連合(EU)

1,492

35

ﾃﾞﾝﾏｰｸ(DK)

154

5

ｶﾅﾀﾞ(CA)

1,208

ﾌｨﾘﾋﾟﾝ(PH)1546ﾄﾞｲﾂ(DE)

1,194

37

ｷﾞﾘｼｬ(GR)148

7ｳｸﾗｲﾅ(UA)

1,152

38

ﾁｪｺ(CZ)

147

8

ﾙｰﾏﾆｱ(RO)96939

南ｱﾌﾘｶ共和国(ZA)

144

9

ｵｰｽﾄﾗﾘｱ(AU)

839

40

ｼﾝｶﾞﾎﾟｰﾙ(SG)

124

10

ﾎﾟｰﾗﾝﾄﾞ(PL)

804

41

ﾌｨﾝﾗﾝﾄﾞ(FI)

123

11

韓国(KR)

763

42

ﾍﾞﾙｷﾞｰ(BE)

120

12

日本(JP)

729

43

ｽﾛﾍﾞﾆｱ(SI)

119

13

ﾌﾞﾗｼﾞﾙ(BR)

514

44

ﾉﾙｳｪｰ(NO)109

14

ｲﾀﾘｱ(IT)

513

45

ﾁﾘ(CL)

103

15

ﾌﾗﾝｽ(FR)

498

46

ﾘﾄｱﾆｱ(LT)97

16ｵﾗﾝﾀﾞ(NL)408

47

ｱｲﾙﾗﾝﾄﾞ(IE)

86

17

ｽｳｪｰﾃﾞﾝ(SE)

369

48

ｺﾝﾛﾝﾋﾞｱ(CO)85

18

ｽｲｽ(CH)

367

49

ﾊﾞﾝｸﾞﾗﾃﾞｼｭ(BD)74

中国(CN)

367

50

ｽﾛﾊﾞｷｱ(SK)63

20

ﾌﾞﾙｶﾞﾘｱ(BG)

349

51

ｲﾗﾝ(IR)

61

21

ｵｰｽﾄﾘｱ(AT)302

ﾎﾟﾙﾄｶﾞﾙ(PT)6122

ﾄﾙｺ(TR)301

旧ﾁｪｺｽﾛﾊﾞｷｱ(CS)60

23

香港(HK)

267

ｻｳｼﾞｱﾗﾋﾞｱ(SA)6024ｽﾍﾟｲﾝ(ES)265

ｸﾛｱﾁｱ(HR)58

25

ｲﾝﾄﾞﾈｼｱ(ID)262ﾏﾚｰｼｱ(MY)58

26

ﾒｷｼｺ(MX)218

ﾊﾟﾅﾏ(PA)

58

27

ｲｽﾗｴﾙ(IL)207

58

ﾍﾞﾈｽﾞｴﾗ(VE)

54

28

ﾆｭｰｼﾞｰﾗﾝﾄﾞ(NZ)

201

59

ﾍﾞﾄﾅﾑ(VN)

47

29

ｱﾙｾﾞﾝﾁﾝ(AR)

193

60

ｷﾌﾟﾛｽ(CY)46

30

ｲﾝﾄﾞ(IN)

192

61

ｱｼﾞｱ太平洋(AP)4531

ﾊﾝｶﾞﾘｰ(HU)

187

62

ﾍﾞﾗﾙｰｼ(BY)

44

416

53
55

順位
62

国・地域

割当数

ｴｼﾞﾌﾟﾄ(EG)44ｶｻﾞﾌｽﾀﾝ(KZ)

44

65

ﾊﾟｷｽﾀﾝ(PK)3866

ﾅｲｼﾞｪﾘｱ(NG)3467ﾌﾟｴﾙﾄﾘｺ(PR)32

68

ﾚﾊﾞﾉﾝ(LB)

69
70

順位

割当数

ｽﾘﾗﾝｶ(LK)12

ﾏｹﾄﾞﾆｱ(MK)12

ﾎﾞﾘﾋﾞｱ(BO)11ｷﾙｷﾞｽﾀﾝ(KG)

11

ﾊﾞｰﾐｭｰﾀﾞ(BM)1029

ｼﾞｬﾏｲｶ(JM)

10

ｴｸｱﾄﾞﾙ(EC)28ﾆｶﾗｸﾞｱ(NI)10ｴｽﾄﾆｱ(EE)26104ｺｽﾀﾘｶ(CR)9ｸｳｪｰﾄ(KW)

26

105

ｱﾗﾌﾞ首長国連邦(AE)8

ｹﾆｱ(KE)24

ｱﾙﾊﾞﾆｱ(AL)8

ﾏﾙﾀ(MT)

24

ｱﾝｺﾞﾗ(AO)

8

ﾎﾞｽﾆｱ･ﾍﾙﾂｪｺﾞﾋﾞﾅ(BA)23

ｺｰﾄｼﾞﾎﾞｱｰﾙ(CI)7

ｱｲｽﾗﾝﾄﾞ(IS)23

ｼﾞﾌﾞﾗﾙﾀﾙ(GI)776

ｶﾝﾎﾞｼｱ(KH)

22

ﾊｲﾁ(HT)

7

77

ｸﾞﾙｼﾞｱ(GE)21

ﾘﾋﾃﾝｼｭﾀｲﾝ(LI)7

ｸﾞｱﾃﾏﾗ(GT)21

ﾓﾛｯｺ(MA)

7

ﾓﾝｺﾞﾙ(MN)

21

ﾓｰﾘｼｬｽ(MU)

7ｵﾗﾝﾀﾞ領ｱﾝﾃｨﾙ(AN)20

ﾓｻﾞﾝﾋﾞｰｸ(MZ)

7ﾊﾞｰﾚｰﾝ(BH)

20

ﾊﾟﾗｸﾞｱｲ(PY)

7

ﾖﾙﾀﾞﾝ(JO)20

ｾﾙﾋﾞｱ(RS)7

ﾙｸｾﾝﾌﾞﾙｸﾞ(LU)

20

ﾄﾘﾆﾀﾞｰﾄﾞ･ﾄﾊﾞｺﾞ(TT)784ｱﾙﾒﾆｱ(AM)19

ﾎﾞﾂﾜﾅ(BW)685

ｱｾﾞﾙﾊﾞｲｼﾞｬﾝ(AZ)

18ｷｭｰﾊﾞ(CU)6

ﾓﾙﾄﾞﾊﾞ(MD)18

ﾄﾞﾐﾆｶ共和国(DO)6

ﾈﾊﾟｰﾙ(NP)17

ﾅﾐﾋﾞｱ(NA)6

ﾍﾟﾙｰ(PE)

17

ﾊﾞﾙﾊﾞﾄﾞｽ(BB)5ｳﾙｸﾞｱｲ(UY)

17

ｶﾒﾙｰﾝ(CM)590

ﾎﾝｼﾞｭﾗｽ(HN)

16

ﾌｪﾛｰ諸島(FO)591

ﾊﾟﾚｽﾁﾅ(PS)14

ｸﾞｱﾑ(GU)5

ｴﾙｻﾙﾊﾞﾄﾞﾙ(SV)14

ﾗｵｽ(LA)

5

ｶﾞｰﾅ(GH)13

ｳｶﾞﾝﾀﾞ(UG)

5

ﾀﾝｻﾞﾆｱ(TZ)

13ｼﾞﾝﾊﾞﾌﾞｴ(ZW)

5ｳｽﾞﾍﾞｷｽﾀﾝ(UZ)

13ｱﾌｶﾞﾆｽﾀﾝ(AF)4ｱﾙｼﾞｪﾘｱ(DZ)

12

ﾊﾞﾊﾏ(BS)

4

72
74

80

87

93

96

96

国・地域

99
101

108

118

122

129

417

順位
129

141

156

418

国・地域

割当数

順位

ﾌﾞｰﾀﾝ(BT)4156

ﾍﾞﾘｰｽﾞ(BZ)

国・地域

割当数

ﾄﾝｶﾞ(TO)

2

4

栄領ﾊﾞｰｼﾞﾝ諸島(VG)

2ﾌｨｼﾞｰ(FJ)

4

ﾊﾞﾇｱﾂ(VU)

2

ｶﾞﾎﾞﾝ(GA)4

ｲｴﾒﾝ(YE)

2

ｶﾀｰﾙ(QA)

4

ｱﾝﾄﾞﾗ(AD)1

ｽｰﾀﾞﾝ(SD)4

ｱﾝｷﾞﾗ(AI)1

ｼｴﾗﾚｵﾈ(SL)4

ｵｰﾗﾝﾄﾞ諸島(AX)1

ｼﾘｱ(SY)

4

ﾌﾞﾙｷﾅﾌｧｿ(BF)

1

ﾀｼﾞｷｽﾀﾝ(TJ)

4

ﾍﾞﾅﾝ(BJ)

1

米領ﾊﾞｰｼﾞﾝ諸島(VI)4

ｸｯｸ諸島(CK)1

ｱﾒﾘｶﾝｻﾓｱ(AS)3ｼﾞﾌﾞﾁ(DJ)1

ﾌﾞﾙﾈｲ(BN)3ﾄﾞﾐﾆｶ(DM)1

ｸﾞｱﾄﾞﾙｰﾌﾟ(GP)3

ｴﾘﾄﾘｱ(ER)1

ｲﾗｸ(IQ)

3

ｴﾁｵﾋﾟｱ(ET)1ｹｲﾏﾝ諸島(KY)

3ﾐｸﾛﾈｼｱ(FM)1

ﾚｿﾄ(LS)3

ｸﾞﾚﾅﾀﾞ(GD)

1

ﾓﾝﾃﾈｸﾞﾛ(ME)3ｶﾞｰﾝｼﾞｰ(GG)

1

ﾏﾘ(ML)

3ｸﾞﾘｰﾝﾗﾝﾄﾞ(GL)1

ﾏｶｵ(MO)

3

ｶﾞﾝﾋﾞｱ(GM)1ﾓﾙﾃﾞｨﾌﾞ(MV)3

ｶﾞｲｱﾅ(GY)1

ﾏﾗｳｲ(MW)3

英領ｲﾝﾄﾞ洋地域(IO)

1

ｾｲｼｪﾙ(SC)3

ｺﾓﾛ(KM)

1

ｽﾜｼﾞﾗﾝﾄﾞ(SZ)

3

ｾﾝﾄｸﾘｽﾄﾌｧｰ･ﾈｲﾋﾞｽ(KN)1

西ｻﾓｱ(WS)

3

ﾘﾋﾞｱ(LY)

1

ｻﾞﾝﾋﾞｱ(ZM)

3ﾏｰｼｬﾙ諸島(MH)1

ｱﾝﾃｨｸﾞｧ･ﾊﾞｰﾌﾞｰﾀﾞ(AG)2

北ﾏﾘｱﾅ諸島(MP)1

ｱﾙﾊﾞ(AW)2

ﾓｰﾘﾀﾆｱ(MR)1

ﾌﾗﾝｽ領ｷﾞｱﾅ(GF)

2

ﾉｰﾌｫｰｸ島(NF)1

ﾏﾝ島(IM)2

ｵﾏｰﾝ(OM)

1

ﾐｬﾝﾏｰ(MM)2

ﾌﾗﾝｽ領ﾎﾟﾘﾈｼｱ(PF)1ﾆｭｰｶﾚﾄﾞﾆｱ(NC)2

ﾊﾟﾗｵ(PW)

1

ﾊﾟﾌﾟｱﾆｭｰｷﾞﾆｱ(PG)

2

ﾚﾕﾆｵﾝ島(RE)1ﾙﾜﾝﾀﾞ(RW)

2

ｽﾘﾅﾑ(SR)1

ｻﾝﾏﾘﾉ(SM)2

ﾀｰｸｽ諸島･ｶｲｺｽ諸島(TC)

1

169

順位
169

国・地域

割当数

ﾄｰｺﾞ(TG)1

東ﾃｨﾓｰﾙ(TL)

1

ﾄﾙｸﾒﾆｽﾀﾝ(TM)1

ﾁｭﾆｼﾞｱ(TN)1ｾﾝﾄﾋﾞﾝｾﾝﾄ･ｸﾞﾚﾅﾃﾞｨｰﾝ(VC)

1

419

420