• HOME
  • .cloud ドメインの注意点｜取得前の確認と、サブドメイン運用・メール・商標で気をつけること

2026年8月5日

  • シェア
  • ツイート

    • 2026年8月5日

    .cloud ドメインの注意点｜取得前の確認と、サブドメイン運用・メール・商標で気をつけること

    .cloud はだれでも登録できる新しい gTLD で、クラウドサービスや SaaS、技術系のブランドサイトによく使われます。登録そのものは .com と同じ手順で済みますが、「更新費用の確認」「サブドメインを顧客ごとに切る設計」「メールの到達性」「他社名を含む名前の商標リスク」の4点は、取得してから気づくと手戻りが大きくなります。この記事では、.cloud を WordPress サイトやサービスのドメインとして使う前に確認したい点と、運用開始後の設定の勘所を順に説明します。

    .cloud ドメインの基本

    .cloud は 2016年ごろに一般登録が始まった新 gTLD です。レジストリ（TLD 全体を管理する事業者）はイタリアの Aruba 系の事業者と案内されています。登録者の国籍や業種による制限はなく、個人でも法人でも取得できます（2026年10月現在）。条件はレジストリの規約で確認してください。

    仕組みの面では .com や .net と違いはありません。DNS のレコードも、SSL/TLS 証明書の発行も、WordPress のインストールも同じ手順で進められます。Google は新 gTLD を他の gTLD と同じように扱うと説明しており、TLD が .cloud であること自体が検索順位を上げたり下げたりすることはありません。

    一方で、.com と比べると次のような違いが出やすいところがあります。

    • レジストラ（販売窓口）によって取り扱いの有無や価格がばらつく
    • 短い名前や一般名詞はプレミアム扱いになっていることが多い
    • 名前に「クラウド」が入るため、大手クラウド事業者の名称と組み合わせると商標の問題になりやすい

    以下、この順に確認方法を見ていきます。

    注意点1：初年度ではなく更新費用で比べる

    新 gTLD は初年度のキャンペーン価格が安く、2年目以降の更新費用が高く設定されていることがよくあります。比較するときは、初年度の金額ではなく「更新費用 × 使う予定の年数」で見積もってください。

    あわせて確認したいのがプレミアムドメインです。レジストリが価値の高いと判断した名前は通常と別の価格帯に置かれ、更新もプレミアム価格のままになっている場合があります。検索画面に表示される価格が初年度だけのものか、更新時も同じ価格帯なのかは、レジストラの料金表や注文画面の注記で確かめておくと安心です。

    レジストラ選びでは、価格のほかに次の点も見ておきます。

    • 自動更新の有無と、支払いに失敗したときの通知方法
    • DNS の管理画面で使えるレコードの種類（CAA、TXT の長い値など）
    • 移管（他社への引っ越し）の手続きと、認証コード（AuthCode）の取得方法
    • 日本語のサポートが必要かどうか

    .cloud は海外のレジストラのほうが取り扱いが多い傾向があるため、日本語サポートを重視する場合は、国内レジストラの取り扱い TLD 一覧に .cloud があるかを先に確認してください。

    注意点2：名前を決める前に商標と紛らわしさを確認する

    .cloud は「〇〇クラウド」という名前を作りやすい反面、既存のクラウドサービスやソフトウェアの名称と重なりやすい TLD です。他社のサービス名や製品名を含む名前を取得すると、商標権者から UDRP などの紛争処理手続きを申し立てられ、ドメインを失うおそれがあります。

    名前を決める前に、少なくとも次の確認をしておくと手戻りを避けやすくなります。

    • 特許庁の商標検索（J-PlatPat）で、同じ名前や似た名前が登録されていないか
    • 同名のサービスや製品が国内外で使われていないか
    • 自社の正式なサービス名と表記がずれていないか

    また、.cloud はフィッシングで「本物のクラウドサービスの管理画面」を装うために使われることもあります。利用者から見て紛らわしい名前（大手サービス名に似た綴りなど）は、たとえ商標の問題がなくても信頼を損ねるため避けたほうが無難です。

    自社ブランドを守る目的で、.com や .jp など主要な TLD の同じ名前もあわせて押さえておくかどうかも、このタイミングで決めておきます。

    注意点3：顧客ごとのサブドメインを使うなら設計を先に決める

    .cloud を SaaS のドメインとして使う場合、customer1.example.cloud のように顧客ごとにサブドメインを割り当てる設計がよく採られます。この方式では、取得後に次の3点で困ることが多いので、最初に決めておきます。

    ワイルドカード DNS と証明書

    サブドメインを都度登録しない場合は、ワイルドカードの DNS レコードを使います。

    *.example.cloud.   3600  IN  A      203.0.113.10
example.cloud.     3600  IN  A      203.0.113.10

    証明書もワイルドカード（*.example.cloud）が必要になります。Let's Encrypt でワイルドカード証明書を取得するには DNS-01 チャレンジが必須で、DNS の API で TXT レコードを自動作成できるかどうかが運用の分かれ目になります。使う予定の DNS サービスが certbot などの ACME クライアントのプラグインに対応しているかを確認してください。

    Cookie の範囲

    サブドメインを顧客に分けているのに、Cookie を親ドメイン（.example.cloud）に向けて発行すると、ある顧客のサブドメインから別の顧客向けの Cookie が見えてしまう設計になりかねません。WordPress で COOKIE_DOMAIN を親ドメインに設定する例を見かけますが、顧客が自由にコンテンツを置けるサブドメインがある構成では避けてください。

    顧客が HTML や JavaScript を自由に置けるサブドメインを提供するなら、Public Suffix List（ブラウザが「ここから下は別の組織」と判断するための一覧）への登録を検討する価値があります。登録には要件と審査があり、反映にも時間がかかるため、公式サイトの説明を読んでから判断してください。

    WordPress マルチサイトで使う場合

    WordPress のマルチサイトをサブドメイン型で動かす場合は、wp-config.php に次のような定数が入ります（ネットワーク作成時に WordPress が表示する内容をそのまま使ってください）。

    define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.cloud' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

    ワイルドカード DNS とワイルドカード証明書がそろっていないと、新しいサイトを追加しても表示できません。本番で試す前に、ステージング環境でサイトの追加から表示までを一度通しておくと安全です。

    注意点4：メールを使うなら SPF・DKIM・DMARC をそろえる

    迷惑メール対策の統計では、一部の新 gTLD が悪用の多い TLD として名前が挙がることがあり、受信側のフィルタが新 gTLD のドメインに厳しめの判定をする場合があります。.cloud で問い合わせ返信や通知メールを送るなら、送信ドメイン認証の設定は前提と考えてください。

    • SPF：送信を許可するサーバーを TXT レコードで宣言する
    • DKIM：送信メールに署名し、公開鍵を DNS に置く
    • DMARC：SPF・DKIM の結果をどう扱うかと、レポートの送り先を宣言する

    DMARC は最初から厳しいポリシーにせず、p=none でレポートを集め、正規の送信元がすべて認証に通っていることを確かめてから段階的に強めるのが一般的な進め方です。

    注意点5：取得後すぐにやっておく設定

    取得直後は、次の作業をまとめて済ませておくと後のトラブルを減らせます。

    1. 登録者メールアドレスに届く確認メールを開き、認証を済ませる（放置すると一時停止される場合があります）
    2. 自動更新を有効にし、支払い方法の有効期限を確認する
    3. レジストラロック（移管ロック）が有効になっているか確認する
    4. WHOIS（登録情報）の公開代行やプライバシー保護の状態を確認する
    5. 管理画面のアカウントに二要素認証を設定する

    登録状態は、ICANN の Lookup サービスや RDAP で確認できます。ターミナルからは次のように調べられます。

    # 登録状態（status）と有効期限（events の expiration）を確認する
# rdap.org は該当するレジストリの RDAP サーバーへ転送する案内サービス
curl -sL https://rdap.org/domain/example.cloud | python3 -m json.tool

# 権威 DNS サーバーが意図したものになっているか
dig +short NS example.cloud

    gTLD の登録情報の照会は、従来の WHOIS から RDAP に移行しています。whois コマンドで情報が出ない場合は RDAP を試してください。

    まとめ

    • .cloud は登録制限のない新 gTLD で、仕組みや SEO 上の扱いは .com と変わらない
    • 比べるときは初年度ではなく更新費用で見積もり、プレミアム扱いかどうかを確認する
    • 他社のサービス名を含む名前は商標トラブルとフィッシングの両面で避ける
    • 顧客ごとのサブドメインを使うなら、ワイルドカード DNS・証明書・Cookie の範囲を先に設計する
    • メールを送るなら SPF・DKIM・DMARC をそろえ、取得直後に確認メール・自動更新・ロックを済ませる
    Views: 35

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲