国際化ドメイン名 (IDN)

国際化ドメイン名（IDN）とは、アラビア語・中国語・キリル文字・デーヴァナーガリー・ヘブライ語・日本語・韓国語などの非ラテン文字、またはフランス語・ドイツ語・ポーランド語・スペイン語などで使われるアクセント付きラテン文字を含むドメイン名のことです。

IDNが登場する以前、ドメイン名システム（DNS）はASCII文字のみをサポートしていました。ラテンアルファベット26文字、数字0〜9、ハイフンがすべてであり、世界の大多数の文字体系はドメイン名にネイティブな形で表記できませんでした。

ICANNは、非英語圏のコミュニティにとってインターネットをより利用しやすくするため、国際化ドメイン名を導入しました。現在では数十の言語向けにIDN TLD（トップレベルドメイン）が存在し、ドメイン拡張子からウェブサイトのアドレスまで、母国語だけでウェブを使えるようになっています。

ASCII以外の文字がドメイン名に含まれる方法には2つの異なるパターンがあり、その違いを理解することが重要です。

IDN TLD（国際化ドメイン拡張子）——このページに掲載されているTLDがこれにあたります。拡張子自体が非ASCIIの文字体系で書かれています。例として .中国（中国）、.рф（ロシア）、.مصر（エジプト）、.한국（韓国）が挙げられます。政府.中国 のような完全な国際化ドメインは、セカンドレベルドメイン名とTLD拡張子の両方でネイティブ文字を使用しています。

通常のTLD下のIDNドメイン名——.com・.netなどの一般的なTLDや、.jp・.deなどのccTLDを運営するレジストリの中には、拡張子がASCIIのままでも、セカンドレベルドメイン名に非ASCII文字を含む登録を許可しているところがあります。たとえば münchen.de や académie.fr はドメイン名部分にアクセント付き文字や非ASCII文字を使っていますが、TLDは通常のASCII拡張子です。

通常のTLDが非ASCII登録を受け入れるかどうかは、そのレジストリのポリシーに完全に依存します。幅広いUnicode文字を許可するレジストリもあれば、ASCII限定のセカンドレベルドメインしか認めないレジストリもあります。一律のルールはなく、希望するTLDのレジストリのIDNポリシーを個別に確認する必要があります。

このちがいがセキュリティの観点で重要な理由：IDNホモグラフ攻撃はほぼ常に2つ目のシナリオを悪用します。キリル文字の а をラテン文字の a の代わりに使うなど、見た目が酷似したUnicode文字を使ったドメイン名を .com のような一般的なASCII TLD下で登録し、アドレスバーで著名ブランドのドメインと視覚的に区別できないものを作り出します。IDN TLD拡張子はレジストリが適用する単一スクリプトポリシーの対象となることが多く、拡張子レベルでのこうした悪用を制限します——ただし完全には防げません。

IDNドメインはユーザーにネイティブ文字で表示されますが、DNSインフラは依然としてASCIIで動作しています。両者をつなぐ橋が Punycode です。RFC 3492で定義されたエンコーディング規格であり、Unicode文字を有効なASCII互換の文字列に変換します。

すべてのIDNドメインは、常に xn-- というプレフィックスで始まるPunycode形式でDNSに保存・解決されます。例えば：

• アラビア語ドメイン مثال.إختبار は xn--mgbh0fb.xn--kgbechtv になります
• ドイツ語ドメイン münchen.de は xn--mnchen-3ya.de になります
• 日本語ドメイン 日本語.jp は xn--wgv71a309e.jp になります

現代のブラウザとメールクライアントはPunycode変換を自動処理するため、ユーザーはアドレスバーで読みやすいUnicode版を目にします。裏では、DNSがxn--のPunycode文字列を通常のドメイン名と同じように解決しています。

Punycode変換ツールを使えば、日本語ドメインを含む任意のIDNドメインをASCII互換エンコーディング（ACE）形式に変換できます。DNSレコードやSSL証明書の設定、生のASCII表記が必要なサーバー設定を行う際に便利です。日本語ドメイン変換が必要な場面では特に役立ちます。

はい——IDNドメインの登録は、Unicodeドメイン名をサポートするICANN認定レジストラを通じて行えます。すべてのレジストラがIDN登録を提供しているわけではないため、希望する文字体系とTLDを特にサポートしているレジストラを探す必要があります。

IDN対応レジストラを選ぶ際のポイント：

• 必要な文字体系・文字セットのサポート（アラビア語・キリル文字・CJK・デーヴァナーガリーなど）
• 希望するIDN TLDの取り扱い——汎用TLD（gTLD）もccTLDもIDNバリアントを持つ場合があります
• 登録プロセス中のPunycode変換が正しく処理されること
• IDN対応のSSL/TLS証明書およびメール設定のサポート

登録の流れ：レジストラを決定し空き確認を済ませれば、手順は通常のドメイン登録と同じです。レジストラが選択したUnicodeドメイン名を自動的にPunycode形式に変換してレジストリに送信します。ドメインはレジストラのコントロールパネルでUnicode版を使って管理します。

IDNドメインの価格はTLDとレジストラによって異なり、更新モデルは他のドメインと同じです。

ccTLD（国別コードトップレベルドメイン）は、特定の国や地域を表すためにICANNが割り当てた2文字のドメイン拡張子です。.jp（日本）・.de（ドイツ）・.cn（中国）・.us（アメリカ）などが該当します。国別コードトップレベルドメインとも呼ばれます。従来のccTLDはすべてASCII文字を使用しており、その国の文字体系に関わらず、拡張子は常にラテンアルファベットで書かれています。

IDN（国際化ドメイン名）は、セカンドレベルドメイン名・TLD拡張子・その両方のいずれかに非ASCII文字を使用するドメインです。DNSシステムがラテンアルファベットを超えて世界の言語・文字体系を表現できるようにするために存在します。

この2つのカテゴリは重要な点で重なります——IDN ccTLDです。ICANNは2010年からIDN ccTLDの委任を開始し、各国が自国の文字体系で拡張子を表せるようにしました。例えば：

• .рф はロシアのIDN ccTLD——.ruのキリル文字版
• .中国 と .中國 は中国の簡体字・繁体字IDN ccTLD
• .مصر はエジプトのアラビア語IDN ccTLD
• .भारत はインドのデーヴァナーガリー文字IDN ccTLDのひとつ

つまり、すべてのIDN ccTLDはIDNですが、すべてのccTLDがIDNというわけではありません——国別コードドメインの大半は依然としてASCIIのみです。また、すべてのIDN ccTLDは国を表しますが、すべてのIDNがccTLDであるわけでもありません。.游戏（ゲーム）や .شبكة（ウェブ/ネットワーク）のようなIDN gTLDは国際化されていますが、特定の国に紐づいてはいません。

国別ドメイン一覧——ASCIIとIDNの両方——は当サイトの国別TLDディレクトリでご確認いただけます。

IDN TLD（国際化トップレベルドメイン）とは、非ASCIIの文字体系で書かれたトップレベルドメイン拡張子のことです。ICANNのIDNプログラム以前は、.ukや.deなどのccTLDを含むすべてのTLDがASCII文字に限定されており、ラテンアルファベットを使用しない国々においても例外ではありませんでした。

ICANNは2010年からIDN ccTLDの委任を開始し、各国が自国の文字体系でTLDを表せるようになりました。例えば：

• .中国——中国（簡体字中国語）
• .مصر——エジプト（アラビア語）
• .भारत——インド（デーヴァナーガリー）
• .рф——ロシア（キリル文字）
• .한국——韓国（ハングル）

ccTLDに加えて、IDN gTLD（国際化汎用トップレベルドメイン）も利用可能です。アラビア語・中国語・キリル文字・ヘブライ語・日本語・韓国語・タミル語・タイ語など多様な文字体系のドメイン拡張子が揃っています。

ICANNが新たな申請を処理し続けるにつれ、委任済みIDN TLDの総数は増加し続けています。このページでは、現在利用可能なすべてのIDN TLDを、対応文字体系・登録状況・価格とともに一覧表示しています。

IDNホモグラフ攻撃（ホモグリフ攻撃とも呼ばれます）は、悪意のある行為者が正規ドメインと見た目上まったく同じか、ほぼ同一のドメイン名を登録するフィッシング手法です。元のラテン文字に似た別の文字体系のUnicode文字を使って偽装します。

例えば、キリル文字の а（U+0430）はほとんどのフォントでラテン文字の a（U+0061）と見た目が全く同じです。攻撃者はキリル文字の'а'を使って pаypal.com というドメインを登録でき、多くのブラウザでは paypal.com と見分けがつきません。

この種の攻撃は通常、IDN TLD拡張子ではなく .com のような標準ASCIIのTLDを標的にします。セカンドレベルドメイン名で文字体系を混在させながら、見慣れた信頼できそうな拡張子を維持するという手口によるためです。この区別についての詳しい説明は上の質問をご参照ください。

ブラウザとレジストリの対応：

• 現代のブラウザはドメインが文字体系を混在させている場合、アドレスバーにPunycodeバージョン（xn--）を表示し、欺きを可視化します
• 多くのレジストリが単一スクリプトポリシーを実施し、ドメインが異なるUnicodeスクリプトの文字を混在させることを防いでいます
• ICANNはレジストリに対し、ホモグラフ攻撃のリスクを軽減する措置の実施について指針を提供しています

身を守るには：リンクをクリックする際は必ずアドレスバーを注意深く確認してください。信頼しているドメインにxn--のプレフィックスが表示されたり、見慣れない文字が含まれていたりする場合は疑いを持ち、リンクを経由せず直接サイトにアクセスしてください。

非ラテン文字で検索するユーザーを対象とする場合、IDNドメインはSEOに効果的です——特に母国語でクエリやブランド名を入力するユーザーが多い市場で顕著です。日本語ドメインのSEO効果については、日本語圏のユーザーにとっての親しみやすさや信頼性の面でもメリットが論じられています。

技術的なSEOの観点から見ると、Googleをはじめとする検索エンジンはIDNドメインを完全にサポートしており、通常のドメインと同様にインデックスします。IDNのPunycodeバージョンとUnicodeバージョンは同じ場所に解決されるため、重複コンテンツの問題も生じません。

考慮すべき要因：

• ローカルな関連性：ターゲット市場のネイティブ文字を使ったIDNドメインは、地域のユーザーの信頼とブランド認知度を高める効果があります
• キーワードとの一致：対象市場のユーザーがネイティブ文字で検索している場合、一致するIDNドメインがトピックの関連性シグナルを強化する可能性があります
• リンクビルディング：一部のプラットフォームや旧来のシステムではIDNドメインの正しい表示やリンクに問題が生じることがあります——自社のエコシステムとの互換性を確認してください
• メール到達率：IDNメールアドレスをすべてのメールクライアントが完全にサポートしているわけではありません——メールがドメイン戦略の一部であれば考慮が必要です

多くの国際SEO戦略において、hreflangを組み合わせたccTLDまたはgTLDが引き続き主要な推奨事項です——ただし、ネイティブ文字でのブランドアイデンティティが優先事項である場合、IDN TLDは有意義な補完手段となり得ます。