Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / 技術ノート
  3. / 欲しいドメインが買えない? 購入を阻む意外な理由と dig での事前確認方法
ドメイン

欲しいドメインが買えない? 購入を阻む意外な理由と dig での事前確認方法

2026年5月3日 公開 2026年5月3日 更新 7分で読めます

レジストラーの検索画面で「取得可能」と表示されているドメインでも、購入できない、あるいは購入後にトラブルになるケースがあります。原因は商標権の保護メカニズム、レジストリの価格設定、既存登録者のプライバシー保護の 3 つに大別できます。この記事では、ドメイン購入を阻む代表的な理由を整理し、dig や Labee Dev Toolbox の DNS API で事前に確認する方法を解説します。

Trademark Claims 通知が出たドメインは取得してよいのか

ドメインを購入しようとしたとき、「Trademark Claims Notice」という警告画面が表示されることがあります。これは ICANN の Trademark Clearinghouse(TMCH)に商標が登録されていることを示す通知です。

TMCH は、新しい gTLD(.app、.dev、.shop など)が一般登録を開始してから最低 90 日間、商標と一致する文字列のドメイン登録時に警告を出す仕組みです。この通知が出ても、技術的にはドメインを取得できます。登録を進める場合、登録者は「この商標の存在を認識した上で登録する」という確認に同意する必要があります。同時に、商標権者にも「あなたの商標に一致するドメインが第三者に登録された」という通知が届きます。

ここで問題になるのが UDRP(統一ドメイン名紛争処理方針)です。商標権者は、UDRP を通じてドメインの移転または取消を申し立てることができます。UDRP で申立人が勝訴するには、以下の 3 要件をすべて立証する必要があります。

  1. ドメイン名が、申立人の商標と同一または混同を引き起こすほど類似していること
  2. 登録者が、そのドメイン名に対して権利も正当な利益も持っていないこと
  3. ドメイン名が悪意で登録され、かつ使用されていること

UDRP の手続き費用は 1 ドメイン・1 名パネルの場合で 1,500 米ドル です。申立から裁定まで通常 60 日前後で完了し、敗訴した登録者はドメインを失います。損害賠償は認められないため、申立人にとってはコストが低く、権利行使のハードルが高くありません。

注意すべき点があります。商標権者がその商標に対応するドメインをどの TLD でも保有していないケースが存在します。「誰もこのドメインを使っていないから問題ない」という判断は根拠になりません。TMCH に登録されている時点で、商標権者はドメイン名に関する権利保護の意思を明示しています。Trademark Claims 通知が出たドメインを取得する場合は、自社の商標やサービス名との関連性を事前に弁護士や弁理士に確認してください。

Premium ドメインと Reserved ドメインの価格の壁

レジストリ(TLD の管理組織)は、特定の文字列を Premium ドメインや Reserved ドメインとして区別しています。レジストラーの検索画面だけでは、この区別に気づかないことがあります。

Premium ドメインの特徴

Premium ドメインは、レジストリが通常より高額な卸売価格を設定したドメインです。対象になりやすいのは以下の文字列です。

  • 1〜3 文字の短い文字列(例: ab.dev、go.app)
  • 一般的な英単語(例: shop、travel、cloud)
  • 検索ボリュームが大きいキーワード

レジストラーの画面では「取得可能」と表示されますが、価格が年間数百ドルから数千ドルに跳ね上がることがあります。初年度の登録料だけでなく、更新料も同じ Premium 価格が適用されるのが一般的です。「初年度だけ高い」と思って取得すると、毎年同じ金額の更新費用が発生します。取得前に必ず更新料を確認してください。

Reserved ドメインの特徴

Reserved ドメインは、レジストリが販売対象から除外した文字列です。広く認知されたブランド名を商標紛争から保護する目的や、レジストリ自身がインフラ用途に確保する目的で設定されます。検索画面に表示されないこともあれば、「取得不可」と表示されることもあります。

Reserved ドメインはレジストリの方針変更によって将来解放される可能性がありますが、時期は予測できません。目当ての文字列が Reserved に分類されている場合は、別の TLD を検討するのが現実的な対応です。

登録済みなのに所有者がわからないケース

レジストラーで「取得不可」と表示されたドメインの所有者を調べようとして Whois を引いても、実際の所有者情報が出てこないことがあります。これは Whois プライバシー保護サービスが原因です。

Whois プライバシー保護には 2 種類あります。1 つはプライバシー保護サービスで、所有者の連絡先をプロキシー情報に置き換えますが、法的な所有権は登録者本人に残ります。もう 1 つはプロキシー登録で、プロキシー事業者が登録者として記録され、実際の利用者は使用権のみを持ちます。

いずれの場合も、Whois の公開情報からは実際の所有者を特定できません。ICANN は Whois を廃止し、RDAP(Registration Data Access Protocol)への完全移行を完了しましたが、一般ユーザーが閲覧できる情報の範囲は同じです。法執行機関や認定された調査機関だけが、追加の登録者情報にアクセスできる仕組みになっています。

ドメインを譲ってもらいたい場合は、Whois(または RDAP)に記載されたプロキシー事業者の連絡先に連絡を試みるか、レジストラーが提供する仲介サービスを利用する方法があります。

事前に登録状態を確認する方法

ドメインが実際に登録済みかどうかは、NS レコードの有無で判断できます。NS レコードが存在すれば、そのドメインはネームサーバーが割り当てられた状態、つまり誰かが登録済みです。

dig で NS レコードを確認する

まず dig で確認します。example.com を確認したいドメインに置き換えて実行してください。

dig NS example.com +short
a.iana-servers.net.
b.iana-servers.net.

NS レコードが返ってくれば、そのドメインは登録済みです。レジストラーの検索画面で「取得可能」と表示されていても、NS が存在するなら既に利用されている状態です。

何も返ってこない場合は、未登録か、NS が設定されていない状態です。ただし dig の結果はローカルのリゾルバーを経由するため、キャッシュの影響を受けることがあります。

Labee Dev Toolbox の DNS API で外部から確認する

自分のネットワークを経由せず、外部のリゾルバーから確認するには Labee Dev Toolbox の DNS API を使います。example.com を自分のドメインに置き換えて実行してみてください。

curl "https://labee.dev/api/dns?domain=example.com&type=NS"
{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "NS": ["a.iana-servers.net", "b.iana-servers.net"]
    }
  },
  "error": null,
  "meta": { "responseTime": 40 }
}

records.NS に値があれば登録済みです。null であれば未登録の可能性が高いですが、Whois(または RDAP)での最終確認を行ってください。

dig と API の両方で確認する理由は、dig がローカルのキャッシュを経由するのに対し、API は DNS over HTTPS で外部のリゾルバーを使うためです。社内ネットワークや VPN 経由で dig を実行している場合、ローカルの結果と外部の結果が異なることがあります。

SOA レコードによる補足確認

NS レコードだけでは判断がつかない場合、SOA レコードも確認すると追加の情報が得られます。

dig SOA example.com +short
ns1.example.com. admin.example.com. 2026040101 7200 3600 1209600 86400

SOA レコードが返ってくれば、そのドメインの DNS ゾーンが存在することを意味します。NS が返らないのに SOA が存在する場合は、ネームサーバーの移行中やレジストラーの設定変更中の可能性があります。

API でも確認できます。

curl "https://labee.dev/api/dns?domain=example.com&type=SOA"
{
  "success": true,
  "data": {
    "domain": "example.com",
    "records": {
      "SOA": [
        {
          "mname": "ns1.example.com",
          "rname": "admin.example.com",
          "serial": 2026040101,
          "refresh": 7200,
          "retry": 3600,
          "expire": 1209600,
          "minimum": 86400
        }
      ]
    }
  },
  "error": null,
  "meta": { "responseTime": 45 }
}

ドメイン購入前のチェックリスト

ドメインを購入する前に、以下の手順で確認すると想定外のトラブルを防げます。

  1. レジストラーの検索画面で価格を確認する。表示価格が年間数十ドル程度か、それとも数百ドル以上かで Premium 設定の有無を判断できます
  2. 更新料を確認する。レジストラーの FAQ やヘルプページで、初年度の登録料と 2 年目以降の更新料が同じかを調べてください
  3. Trademark Claims 通知が表示されたら、その商標と自社の事業に正当な関連があるかを確認する。不明な場合は弁護士や弁理士に相談してください
  4. dig と DNS API で NS レコードを確認し、ドメインが実際に未登録かを検証する
  5. 取得不可の場合は Whois または RDAP でプロキシー情報を確認し、必要に応じて仲介サービスの利用を検討する

事前の確認を省略すると、購入後に UDRP の申立てを受けたり、想定外の更新費用が発生したりするリスクがあります。dig での確認は数秒で完了します。ドメインに投資する前に、まず自分の手元で確認してみてください。ブラウザーから DNS レコードを確認する場合は Labee Dev Toolbox の DNS チェック画面も利用できます。

ドメインを取得した後の初期設定(NS・A・MX レコード、SPF/DKIM/DMARC、SSL の設定と確認)は「ドメインを取得したら最初にやる DNS チェック」で順番に解説しています。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す

Pro プラン(準備中)

DNS 変更の自動検知・SSL 期限アラート・複数ドメイン管理など、継続して確認し続けるための機能を準備中です。

関連記事

メール認証

SPF・DKIM・DMARC を外部から確認する方法 — dig と API で設定漏れを検出する

dig コマンドと外部 API を使って、SPF・DKIM・DMARC の設定状況を外部視点から確認する手順を解説します。DKIM セレクターの自動検索、Gmail のバルクセンダー要件との照合、よくある設定漏れパターンの特定方法も紹介します。

2026-04-01 ・ 7分

メール認証

DKIM セレクタの見つけ方 — プロバイダー別の命名規則と自動検知の限界

DKIM セレクタ名はメールサービスごとに異なります。Google Workspace、Microsoft 365、SendGrid、AWS SES など主要プロバイダーのセレクタ命名規則と、dig・API を使った確認方法、自動検知できないケースの対処法を解説します。

2026-04-22 ・ 8分

メール認証

DMARC の organizational domain とは — サブドメインのメール認証で親ドメインが重要な理由

サブドメインに DMARC レコードがない場合、受信サーバーは親ドメイン(organizational domain)のポリシーにフォールバックします。この判定に使われる Public Suffix List の役割、.co.jp 等の日本ドメインでの挙動、sp= タグとの優先順位を解説します。

2026-04-29 ・ 8分

コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集