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