system online · no logs · no tracking · no kyc tor: v3 ready
root@neverkyc:/blog/kyc-fuyou-domain-toroku-icann-2026-gaido$ cat post.md

ICANN 2026下でKYC不要のドメイン登録は今も合法か

// by ~anon · 2026-06-01 · mock,auto-generated,ja

ICANN 2026下でKYC不要のドメイン登録は今も合法か

2026年1月、ICANN理事会は2024年版レジストラ認定契約(RAA)の改正条項——新しい登録データ正確性仕様(Registration Data Accuracy Specification、以下RDAS)の下で義務化されたデータ検証——が、すべてのgTLDで引き続き有効であることを再確認しました。コンプライアンス部門はすでに、WHOISデータを不適切に取り扱ったレジストラに対して140件を超える執行ファイルを開設しており、2026年第1四半期だけで3社のTier-2レジストラが認定を失っています。それにもかかわらず、「匿名ドメイン」「プライベートWHOIS」「No-KYC」などのタグで宣伝されるプライバシー保護型登録の静かな市場は依然として活況です。では、ICANN 2026下でKYC不要のドメイン登録は今も合法なのでしょうか。それとも、パスポートのスキャンを提出せずにウェブサイトを持ちたいユーザーへの窓は、ついに閉じてしまったのでしょうか。

結論を先に申し上げれば、答えは微妙です。ICANNの2026年フレームワークは、規制された取引所のような写真付き身分証によるKYCを要求していません。要求されているのは正確な連絡先データであり、レジストラには特定のフィールドを検証する義務が課されていますが、それでもレジストラ・オブ・レコード方式のプロキシ、トラスティ(受託者)構造、そしてICANNの契約外で運営されるccTLDのための余地は残されています。MoneroSwapperのようなサービスを通じてMoneroで支払うことを計画している方にとって、法的な実態はマーケティング・コピーよりはるかに重要です。本ガイドでは、2026年に何が変わったのか、データ収集を最小化しつつコンプライアンスを維持しているプロバイダーはどれか、そして実際のルールが要求する以上の個人情報を渡さずにドメインを登録する方法を、契約条文に即して解説します。

2026年の規制環境:ICANNの新スタンス

何が許容され、何が許容されないのかを理解するためには、メディアが混同しがちな三つの重なり合う制度を分けて捉える必要があります。ICANNの契約レイヤー、EUのNIS2およびGDPR例外規定、そして各国ccTLDの個別ポリシーです。それぞれが「アイデンティティ」を異なる扱いで定義しており、「No-KYC」はそれら制度の間の隙間に存在しています。

  • ICANN RAA + RDAS:登録データ正確性仕様は2025年8月から完全施行されており、レジストラに対して統語的検証(メールアドレスが正しく構文解析できるか、電話番号がE.164パターンと一致するか)と運用的検証(メールが実際に受信されるか)を実施する義務を課しています。しかし、政府発行身分証の確認、生体認証、金融KYCは要求されていません
  • EU NIS2の国内法化:EU加盟国の法律では、EU圏内のccTLDレジストリに対し「正確かつ完全な」登録データを保持し、「正当なアクセス要求者」に開示することを求めています。これが2025年末に.EU、.DE、.FRで本人確認を厳格化させた制度です。
  • 各国ccTLDルール:一部のレジストリ(.IS、.CH、.LI、.TO、.CC)は今も有効なメール程度の情報で登録を受け付けています。一方、他のレジストリ(.US、.CA、.CN、そして日本のJPRSが運営する.JPも実質的に同様)はネクサスや居住証明を要求し、これが事実上のKYCとして機能します。

ICANNが2026年に行わなかったのは、「身分証を見せろ」という普遍的ルールの押し付けです。執拗に続く混乱の原因は、2025年11月に終了した濫用緩和迅速ポリシー策定プロセス(EPDP)にあります。これは検証可能な悪意あるドメインに対する撤去義務を強化するものでした。大手レジストラのいくつかが過剰反応し、防御策としてパスポートのアップロードを導入した上で、これを「ICANNコンプライアンス」と称して宣伝しました。それは違います——単なるリスク回避策です。法的には、レジストラは検証済みメール、課金経路、そして正確な連絡先メタデータだけで顧客をオンボーディングできます。

日本の文脈で補足すると、JPRS(株式会社日本レジストリサービス)が管理する.jpドメインは独自ポリシーを持っており、登録には日本国内の連絡先が必要です。これは事実上、日本居住者または日本に拠点を持つ法人にしか登録できないことを意味し、結果としてICANN契約外のレベルで本人特定が容易になります。プライバシーを最優先するなら、.jpは出発点として最適ではありません。一方、個人情報保護委員会(PPC)が運用する個人情報保護法(APPI)は、レジストラがどのデータをどのように扱うかを規律しますが、登録自体に身分証要件を加えるものではないという点も押さえておく必要があります。

「No-KYC」がドメイン登録において実際に意味すること

ドメインの世界で「No-KYC」は曖昧な傘語です。それは少なくとも四つの非常に異なるものを意味する可能性があり、これらを混同することで、停止されたドメインや凍結された支払いを経験することになります。

1. 身分証なし、WHOISは完全に透明

登録者は本名、メールアドレス、住所を提供しますが、身分証は一切アップロードしません。これは大半の一般向けレジストラのデフォルトであり、ICANN 2026に完全準拠しています。正確性仕様が気にするのはデータに到達可能かどうかであって、運転免許証で証明したかどうかではありません。

2. プロキシまたはプライバシー・サービスによる登録

登録者の実情報はプライバシー・サービス(例:Njallaのトラスティ・モデル、1APIのWhoisGuard相当、Porkbunの無料プライバシー)が保持します。公開WHOISにはサービスの連絡先が表示されます。ICANNの2024年RAAは、プライバシー・プロキシ・サービス認定プログラム(PPSAP)構造を通じて、この方式を明示的に許可しています——もっとも、実際のPPSAP発足は何度も延期されていますが。

3. トラスティまたは実質的所有者構造

法的なトラスティが、ユーザーに代わってドメインを自らの名義で登録します。これがNjalla、OrangeWebsiteのドメイン部門、そしていくつかのアイスランド系レジストラの仕組みです。法的にはトラスティが登録者そのものであり、その下にある顧客との関係は私的なサービス契約によって規律されます。ICANN 2026は、WHOISに公開される登録者データがトラスティに関して正確である限り、この方式に異論を唱えていません。

4. ICANN契約外のccTLDおよびオルト・ルート

国別コードトップレベルドメイン(ccTLD)は、レジストリ運営者と独自のポリシーを交渉します。.IS、.CH、.LI、.CC、.TO、そしていくつかの太平洋系ccTLDは最小限のデータで登録を受け付けます。Handshake(HNS)、ENS(.eth)、Unstoppable(.crypto、.x、.nft)のようなオルト・ルート・システムは、そもそもICANNの管轄下にはなく、純粋に暗号学的所有権で運営されています。

もしレジストラが写真付き身分証を要求し、これを「ICANN要件」と称するなら、契約条項を引用するよう求めてください。彼らにはできません。なぜなら、その条項は存在しないからです——そして、ルールを誤って表示するレジストラ自身が、コンプライアンス違反の状態にあります。

2026年にデータ収集を最小化する合法レジストラ

下の表は、2026年5月時点で政府発行の身分証をアップロードせずに登録を許可しつつ、契約上クリーンな状態を保っているレジストラとレジストリ種別をまとめたものです。価格は中位TLD(.com、.net、.org)の1年更新料を反映しており、プロモーション初年度割引は除外しています。

プロバイダーモデルMonero支払い標準1年.com備考
Njallaトラスティ方式、ユーザーに代わってドメインを保有はい、ネイティブXMR約€15ネイビス拠点、2017年設立、2026年監査で最強の法的保護と評価。
OrangeWebsiteアイスランド拠点、ccTLDフレンドリーはい、処理業者経由約€18.ISでの長い実績、ホスティングをバンドル、メールのみで登録可。
1984 Hostingアイスランド、ID不要のgTLD登録はい、ネイティブXMR約€20データ過剰収集への公然たる反対姿勢、.ISとgTLDをサポート。
Porkbun標準レジストラ+無料WHOISプライバシーいいえ(BTCのみ)約$11主流価格帯、XMRを事前にオフプラットフォームで変換する必要あり。
Handshake (HNS)非中央集権型ルート、オンチェーン所有権DEXスワップ経由オークション形式ICANN管轄外、HNS対応リゾルバまたはブラウザ拡張で解決。
ENS (.eth)Ethereumスマートコントラクト名DEXスワップ経由約$5/年+ガス代ICANN範囲外、Brave、MetaMask、Operaでネイティブ解決。

ここで「Monero支払い」とは、プロバイダーがXMRを直接受け付けるか、アカウント連携を要求しない統合型決済処理業者を通じて受け付けることを意味します。Porkbunのように法定通貨またはBTCのみを受け付けるレジストラの場合、MoneroSwapperユーザーは決済直前にXMRをBTCまたはUSDTに変換するのが一般的です。これにより、Monero側のオンチェーン・プライバシーを保ちつつ、レジストラの利用規約に違反することもありません。

ステップ・バイ・ステップ:2026年に最大プライバシーでドメインを登録する手順

レジストラの選択と同じくらい、手順そのものが重要です。完全に匿名のレジストラであっても、特定済みウォレットから支払えば、あるいは本名と紐づいた決済処理業者のクッキーを渡せば、アイデンティティは漏洩します。以下は、ICANN 2026下で合法性とプライバシーの両方を優先するユーザーに私たちが推奨するワークフローです。

  1. まず正しいTLDを選びます。他の何かを決める前に、ICANN下のgTLD(.com、.org)が必要なのか、ID要件の軽いccTLD(.is、.ch、.li、.cc)が良いのか、それともICANN範囲外のチェーン名(.eth、.crypto、HNS名)が適切なのかを決定してください。TLDの選択が、それ以降のすべてのプライバシー判断を制約します。
  2. クリーンなメールIDを生成します。プライバシー尊重型メール・プロバイダー(Tutanota、Proton、Disroot、あるいは既に所有しているドメイン上の自前ホスト・アドレス)を使用してください。そのメールボックス外から送受信して動作確認をしましょう。ICANNの正確性仕様は到達可能性を検査します。
  3. 上記表からレジストラを選びます。現在の利用規約で次の二点を確認してください。登録時に政府発行身分証を要求しないこと、そしてICANN 2024年RAAに準拠していることです。両方とも通常、アカウントを作成せずに確認できます。
  4. アカウント不要のスワップでMoneroを取得します。MoneroSwapperあるいは同等のインスタント・スワップ・サービスを使用して、登録なしで別のコインをXMRに変換します。XMRを新しいウォレットに送ってください——理想的にはこの購入専用に作成したウォレットで、ドメインがあなたの広範なオンチェーン履歴と結び付かないようにします。
  5. レジストラがXMRを直接受け付ける場合は、その新しいウォレットから支払います。そうでない場合は2段階目を実行してください。MoneroSwapperを通じてXMRの一部をBTCまたはUSDTにスワップし、請求額に必要な分だけ送金し、残高追跡可能性を最小化するために即座にレジストラに支払います。
  6. チェックアウトでWHOISプライバシーまたはトラスティ・モードを有効化します。デフォルトで連絡先データを公開するレジストラであっても、登録時にプライバシーを有効化すれば最初のWHOISスナップショットの漏洩を防げます。事後にプライバシーを適用しても、アーカイブされたWHOIS履歴は消去できません。
  7. 正確な連絡先データをプライベートに記録します。提出したデータのオフライン記録を保管してください。後にレジストラがRDASに基づいて検証を要求した場合、同じメールから返信して住所を確認でき、身分証をアップロードする必要はありません。

この手順に従えば、ICANN 2026への契約遵守を維持しつつ——連絡先データは正確で到達可能です——支払いの紙幅も生体認証の足跡もレジストラに残しません。

Moneroでドメインを匿名支払いする方法

支払いの段階こそ、ほとんどの「No-KYC」登録が静かに失敗する場所です。レジストラの登録時にアイデンティティ要件がゼロであっても、クレジットカードやKYC取引所と紐づいたBTC出金で支払えば、その取引自体が紐付けになってしまいます。Moneroはこれをプロトコル・レイヤーで解決します。RingCT、ステルス・アドレス、Bulletproofs+により、レジストラの決済処理業者は資金源やウォレット履歴を導出できません。

2026年において、Moneroを優雅に受け入れるレジストラには三つのクラスがあります。ネイティブXMRレジストラ(Njalla、1984 Hosting、処理業者経由のOrangeWebsite)は、単にステルス・アドレスでXMR請求書を表示します。ブリッジ対応レジストラは、Moneroプラグイン付きBTCPay Serverのような決済ゲートウェイか、BTC同等額を引用するサードパーティ処理業者を使用します。仮想通貨対応のみのレジストラはBTCまたはUSDTを受け付けます——これらに対しては、MoneroSwapperのインスタントXMR→BTCまたはXMR→USDTルートが、レジストラの請求アドレスに直接資金を届け、スワップ自体はアカウント不要です。

法的なポイントを繰り返す価値があります。Moneroでの支払いは、私たちが把握するいかなる法域においても「KYC回避」にはあたりません。なぜなら、ICANN 2026はドメイン購入に対して金融KYCをそもそも要求していないからです。あなたは単に、代替可能性を尊重する決済方法を選んでいるに過ぎません。この区別は、将来レジストラとの紛争が生じた場合に重要となります。

日本国内の文脈では、資金決済法および犯罪収益移転防止法(犯収法)は暗号資産交換業者にKYCを義務化していますが、ドメイン登録自体には個別の本人確認義務はありません。MoneroSwapperのような非カストディアル・スワップは交換業者には該当せず、これを利用したXMR取得自体は個人情報保護法(APPI)の下でも問題視されていません。とはいえ、確定申告における雑所得計算や所得申告は依然として個人の責任であり、これはMonero支払いの匿名性とは独立した論点であることに注意してください。

日本のユーザーが特に注意すべき法的論点

日本国内からKYC不要のドメイン登録を行う場合、海外ユーザーには関係しない固有の検討事項がいくつか存在します。これらは「違法か合法か」という二元論ではなく、グレーゾーンを正しく歩くための実務的な座標として理解する必要があります。

  • 個人情報保護法(APPI)と登録者保護:個人情報保護委員会(PPC)が運用するAPPIは、日本のレジストラがあなたの登録データをどう扱うかを規律します。海外レジストラを利用する場合、APPIの直接適用は限定的ですが、データの国外移転に関する規律はGDPRと類似した方向で強化されています。Njallaやアイスランドのレジストラは、データを欧州データ保護基準で扱うため、APPI観点でも実質的なリスクは低いと考えられます。
  • JPNICとAPNICの枠組み:日本のインターネット番号資源を管理するJPNICは、ドメイン名そのものを管理してはいません。.jpの登録ポリシーはあくまでJPRSが定めますが、JPNICがIPアドレス・ASNレベルで透明性を要求する文脈は、ホスティング選択時に間接的に影響します。海外VPSとccTLDを組み合わせれば、この層も回避できます。
  • 金融庁(FSA)と暗号資産規制:Moneroは、金融庁の指導により2018年から日本国内の認可取引所では上場廃止されています。ただし、これは取引所が国内で取り扱えないという話であって、個人がMoneroを保有・送金することを禁じているわけではありません。MoneroSwapperのような非カストディアル・スワップを海外サービスとして利用することは、現行法では制限されていません。
  • 確定申告と雑所得:暗号資産を法定通貨やドメイン購入のための別の暗号資産にスワップした時点で、含み益が雑所得として課税対象になる可能性があります。これは国税庁の現行ガイダンス(2025年12月版)に基づきます。ドメイン登録という経済行為自体は無関係ですが、その前段の交換に伴う所得計算は記録しておく必要があります。

これらの論点はいずれも、ICANNフレームワークやレジストラの利用規約とは独立に存在します。つまり、ドメイン登録のレイヤーで「No-KYC」を達成できたとしても、税務や送金経路のレイヤーで自分の足跡を整理しておくことは別途必要です。本ガイドはあくまで登録の合法性に焦点を当てており、税務助言ではないことを明記しておきます。

実例:ジャーナリストのケース

2026年、報道に厳しい法律を持つ法域で活動するジャーナリストが、個人公開用ドメインを欲しがっている場合を考えましょう。彼らに必要なのは、(a) 不正確なWHOISで取り消されない、合法的に登録されたドメイン、(b) ドメインと法的アイデンティティの間に公開リンクがないこと、(c) 銀行口座まで召喚できない支払い経路——の三つです。

2026年に実際に機能する道筋はこうです。1984 Hostingを通じてProtonメール連絡先で登録した.is ccTLD、6ヶ月前にピア・トゥ・ピアで購入した少額のBTC残高からMoneroSwapper経由で調達したXMRで支払います。ICANNのRDASは.isには適用されず(これはISNICルール下のccTLDです)、連絡先メールは実在し到達可能、決済処理業者が見るのは新規のステルス・アドレスだけです。開示された全アイデンティティは、解決可能なメール一つ。アップロード文書は総数ゼロ。違反したICANNポリシーも総数ゼロ。2026年の総コストは€25未満です。

これを、「ICANNコンプライアンスのため」と称してパスポートのアップロードを「要求」する米国拠点のレジストラを利用した同じジャーナリストと対比してみてください。今や、サードパーティCRMにパスポート・スキャンが、クレジットカードとの紐付けが、そしてICANNが命じてもいない自前のKYC義務を構築したレジストラが存在することになります。プライバシーは失われ、法的保護は何ら改善されていません。

FAQ

ICANNは2026年にドメイン登録で写真付き身分証を要求していますか?

いいえ。2025年8月から施行されているICANNの登録データ正確性仕様は、レジストラに連絡先データが統語的に正しく運用的に到達可能であることを検証する義務を課しています。パスポート、運転免許証、その他いかなる政府発行身分証のアップロードも要求していません。写真付き身分証を要求するレジストラは、ICANNの義務ではなく自社の内部ポリシーを押し付けているのです。

Njallaのようなトラスティを通じてドメインを登録することは2026年も合法ですか?

はい。トラスティが登録上の登録者であり、自身の名義で正確なWHOISデータを提供します。実際のウェブサイト運営者との間の私的契約は、ICANNの範囲外にあります。2026年5月時点で、いかなるICANNポリシーも注目すべき各国規制当局もこのモデルに異議を唱えておらず、ネイビス拠点およびアイスランド拠点のトラスティは、法的堅牢性を優先するユーザーにとって最強の選択肢であり続けています。

真にKYC不要のドメインを欲しいなら、偽名で登録できますか?

いいえ、これこそ避けるべき罠です。ICANNの正確性仕様は、検証可能な虚偽データを持つドメインを停止する権利(そして増大する義務)をレジストラに与えています。「No-KYC」とは身分証アップロードなしという意味であって、虚偽情報という意味ではありません。実在する氏名と実際に到達可能なメールがあればルールを満たします。連絡先アイデンティティを捏造すれば、数週間以内にドメインが停止されるリスクに晒されます。

.ethやHandshake名はICANN下のドメインに該当しますか?

いいえ。ENSの.eth名およびHandshake(HNS)名は、ICANNルートの完全な外部に存在します。それらはブロックチェーン上の暗号学的所有権記録であり、それらのオルト・ルートをサポートするブラウザまたはリゾルバ(Brave、Opera、MetaMask、そしてHNSDまたはHNS DNSオーバーレイ)でのみ解決されます。それらの合法性は所有者が居住する法域によって規律されるのであって、ICANNによってではありません——そして現時点で、個人所有を制限した主要法域は存在しません。日本でも個人所有を禁じる法律はなく、ENS名を著作権登録のように扱う動きもありません。

レジストラが後でアイデンティティを検証するよう要求してきたら、どうなりますか?

2026年フレームワーク下では、レジストラが到達可能性の再検証——リンクをクリックしてメールを確認、電話検証コールに応答、古い住所を更新——を要求することは契約上許容されています。あなたのドメインに対する特定の濫用シグナルがある場合、身分証を要求する段階にエスカレートすることもあります。準拠レジストラに正確なデータで登録し、濫用履歴がなければ、書類のアップロードなしで通常は検証をクリアできます。

日本居住者がNjallaのような海外トラスティを使うことに法的問題はありますか?

現行の日本法では、個人が海外のドメイン・トラスティ・サービスを利用することを禁じる規定は存在しません。Njallaのようなネイビス拠点のトラスティと結ぶサービス契約は、私法上の委任契約に類似し、外為法上の規制対象にもなりません。ただし、サイトを商用利用する場合は、特定商取引法や景品表示法といった国内法が運営者に課す情報開示義務(事業者の氏名・住所・連絡先)とは別途両立させる必要があります。匿名で運営できるのは、商用要素がない個人ブログや調査用サイトに限られる、という点は押さえておく必要があります。

2026年、レジストラはMonero支払いを疑わしいものとして扱いますか?

すでに受け付けているレジストラでは扱いません。Njalla、1984 Hosting、OrangeWebsite、そしていくつかのより小規模な欧州・アジア系プロバイダーは、長年XMRを受け付けており、通常の決済手段として扱っています。法定通貨のみまたはBTCのみのレジストラでは、MoneroSwapperのようなサービスを通じてサポート対象コインに変換するだけです。非カストディアル、アカウント不要のスワップを使用する限り、変換自体はどこにもフラグされません。

結論

KYC不要のドメイン登録は、ICANN 2026下で引き続き合法です——ただし「No-KYC」が実際に何を意味するかを理解している場合に限ります。それは虚偽情報を提供する権利ではありません。ICANNの契約が一度も要求してこなかった身分証書類をアップロードせずに、正確に登録できる自由のことです。2024年から2025年にかけてのポリシー引き締めはデータ正確性と濫用撤去を標的にしており、金融KYCではありませんでした。上記のレジストラは、ルール内に完全に留まりつつ、現実世界のアイデンティティをレジストラのハードディスクと公開WHOISの両方から守ることを可能にしてくれます。

支払い側では、Moneroが依然として最もクリーンな経路であり、MoneroSwapperを通じたアカウント不要のスワップにより、取引所アカウントを一度も開設することなくドメイン登録の資金を調達できます。個人ブログを保護していようと、研究プロジェクトを運営していようと、あるいは単にホスティングとアイデンティティを別々の箱に保ちたいだけだろうと、2026年フレームワークは依然として扉を開いたままにしてくれています——あなたはただ、どの扉を通って歩けばよいかを知りさえすればよいのです。

最後に強調しておきたいのは、本ガイドが示した手順はいずれも、現行のICANN契約条項、日本の個人情報保護法、そしてアイスランドやネイビスといった主要なトラスティ法域の判例に照らして合法であるという点です。コンプライアンス・チームが恐れているのは「ID不要のドメイン」そのものではなく、「不正確なWHOISデータ」と「明らかな濫用」です。正確に、しかし最小限のデータで登録するという姿勢を取り続ける限り、あなたは法的に脆弱な立場ではなく、むしろICANNがRDASで意図した正確性原則の理想的な体現者となります。プライバシーは違法行為ではありません。それは2026年のインターネットにおいてなお、明示的に保護された選択肢の一つなのです。