.dev は誰でも登録できる開発者向けの gTLD で、TLD 全体が HTTPS 必須になっているのが最大の特徴です。選ぶときのポイントは、証明書を公開前に用意できるか、サブドメインもすべて HTTPS にできるか、ローカルの開発環境で .dev を使っていないか、の3点です。この記事では、.dev の仕組みを踏まえて、取得前に確かめること、WordPress で使うときの手順とつまずきやすい点を説明します。
なお、.or.jp と .dev の違い（登録できる組織や団体サイトでの使い分け）は別の記事で扱っています。この記事は .dev を実際に選んで運用する人向けの内容です。
.dev ドメインの基本
.dev は Google Registry が管理する gTLD で、2019年に一般の登録が始まりました。登録者の国や職業の条件は無く、個人の技術ブログ、OSS のドキュメント、開発ツールの紹介ページなどで使われています。検索での扱いはほかの gTLD と同じで、.dev だから順位が変わることはなく、国や地域の手がかりにもなりません。
ポイント1：TLD 全体が HSTS プリロード済み
HSTS（HTTP Strict Transport Security）は、「このサイトは HTTPS でだけ開く」とブラウザーに覚えさせる仕組みです。通常はサイトがレスポンスヘッダーで宣言しますが、ブラウザーには「最初から HTTPS で開くドメイン」の一覧（HSTS プリロードリスト）が組み込まれています。.dev は TLD ごとこの一覧に登録されているため、example.dev を取得した時点で、主要なブラウザーは HTTP での接続を行いません。
ここから、次のことが分かります。
- 証明書が無い状態では、ブラウザーからサイトを開けない
- 証明書のエラーが出ても、利用者が警告を無視して先へ進むボタンは表示されない
www、staging、docsなどのサブドメインもすべて対象になる- サイト側の設定で HSTS を外すことはできない
一方で、メールや API のサーバー間通信など、ブラウザー以外の通信には HSTS プリロードは関係しません。たとえば curl はブラウザーのプリロードリストを参照しないため、curl http://example.dev は HTTP で接続を試みます。ブラウザーで開けないのに curl では応答がある、という食い違いは、この違いで説明できます。
ポイント2：証明書を公開前に用意できるか
.dev では「HTTP でとりあえず公開して、後から SSL を入れる」という順番が取れません。サーバーを選ぶときは、独自ドメインに無料の証明書（Let's Encrypt など）を自動で発行・更新できるかを確かめます。
サブドメインを多く使う予定なら、ワイルドカード証明書（*.example.dev）を使うと管理が楽になります。Let's Encrypt でワイルドカード証明書を取るには DNS-01 チャレンジが必要で、DNS の TXT レコードを自動で書き換えられる DNS サービスを使っていると運用しやすくなります。CAA レコードで証明書を発行できる認証局を限定している場合は、使う認証局が許可されているかも確かめます。
証明書の期限切れは、.dev ではそのままサイトが開けない事故になります。自動更新が動いているかを、定期的に確かめておきます。
# 証明書の有効期限と対象ドメインを確認する
openssl s_client -connect example.dev:443 -servername example.dev </dev/null 2>/dev/null \
| openssl x509 -noout -subject -datesポイント3：ローカルの開発環境で .dev を使っていないか
以前は、ローカルの開発環境で mysite.dev のような名前を使うことがよくありました。しかし .dev が実在の TLD になり、ブラウザーが HTTPS を強制するようになった（2017年ごろから）ことで、こうした環境はブラウザーで開けなくなりました。古いチュートリアルや、昔作った仮想ホストの設定に .dev が残っていると、「ローカルなのに HTTPS に飛ばされる」という症状になります。
ローカル環境の名前には、テスト用として予約されている .test や、自分のマシンを指す .localhost を使います。.local はマルチキャスト DNS（mDNS）で使われるため、ローカル開発用の名前には向きません。社内ネットワーク向けの名前としては、2024年に ICANN が私的な用途向けに .internal を予約しています。
また、取得した example.dev と同じ名前をローカルの hosts ファイルに書いて開発していると、本番と開発環境の区別がつかなくなります。開発環境は example.test のように別の名前にしておくと安全です。
ポイント4：利用者と用途に合うか
.dev は開発者には「技術系のサイト」と伝わりやすい一方、一般の利用者には見慣れない TLD です。技術ブログや OSS のドキュメント、開発者向けサービスには向いていますが、一般消費者向けの店舗サイトや、会社の代表サイトには .com や .jp 系の方が伝わりやすい場合があります。
更新料はレジストラによって違い、短い名前はプレミアム価格になっていることもあります。初年度の価格ではなく更新料を見て判断してください。価格や扱うレジストラは変わることがあるため、取得の直前に確かめます（2026年10月現在）。
WordPress で使うときの手順
順番は「DNS → 証明書 → インストール」
- サーバー側でドメインを追加し、DNS の A レコード（必要なら AAAA レコード）をサーバーに向けます。
- DNS が反映されたら、サーバーの管理画面などで SSL 証明書を発行します。
https://example.devでアクセスできることを確かめてから、WordPress をインストールします。
既存サイトを .dev に移す場合は、作業前にデータベースとファイルのバックアップを取り、ステージング環境で試してから本番に反映します。ステージングを staging.example.dev にするなら、そのサブドメインの証明書も先に用意します。
リバースプロキシの裏で動かすとき
ロードバランサーや CDN で HTTPS を終端し、WordPress のサーバーには HTTP で転送している構成では、WordPress が自分を HTTP で動いていると判断し、ログイン画面や管理画面でリダイレクトが繰り返されることがあります。WordPress のドキュメントでは、プロキシが付ける X-Forwarded-Proto ヘッダーを見て HTTPS と判定させる方法が案内されています。wp-config.php の「編集はここまで」のコメントより上に追加します。
// 信頼できるプロキシ経由のときだけ使う（プロキシ側でヘッダーを上書きしていること）
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}このヘッダーは利用者が偽装して送ることもできるため、プロキシを経由しない直接のアクセスを受け付けない構成で使います。
HSTS の状態を確かめる
Chrome では chrome://net-internals/#hsts を開くと、ドメインが HSTS の対象になっているかを調べられます（画面の構成はバージョンによって変わることがあります）。.dev のドメインであれば、プリロードの対象として表示されます。サイト側で Strict-Transport-Security ヘッダーを送る必要はありませんが、送っても問題はありません。
まとめ
.devは誰でも登録できる gTLD で、TLD 全体が HSTS プリロード済みです。サブドメインを含めて HTTPS でしか開けず、サイト側で解除はできません。- 証明書は公開前に用意し、自動更新が動いているかを定期的に確かめます。サブドメインが多いならワイルドカード証明書と DNS-01 チャレンジを検討します。
- ローカル開発環境には
.devではなく.testや.localhostを使います。 - WordPress は「DNS → 証明書 → インストール」の順で進め、プロキシの裏では
X-Forwarded-Protoの扱いに注意します。