DNS TTLとは — 設定を変えたのに古いサイトが見えると言われる理由と、あと何分待てばいいかの調べ方
TL;DR
TTL（Time To Live）は、DNSの回答をキャッシュサーバーが保持してよい秒数です。設定を変えても、古いTTLの時間が過ぎるまで各地のキャッシュサーバーは古い情報を返し続けます。WindowsのPowerShellで
Resolve-DnsName -Name 自分のドメイン -Type A -Server 8.8.8.8を実行するとTTL値を確認できます。その秒数が経過すれば反映が完了します。
設定は変えた手応えがある。それなのに、別の拠点の同僚から「まだ古いサイトが表示されている」と連絡が来ていませんか。
自分の画面では新しいサイトが見えているのに、相手には古いものが見えている。この状況に置かれると、設定が間違っているのか、それとも待てばいいだけなのか、判断がつかずに焦ることがあります。
答えから言うと、これは多くの場合ミスではなく仕様によるものです。「待てばいい問題か、やり直すべき問題か」——この切り分けができれば、落ち着いて対処できます。
本記事では、TTLとは何か、あと何分待てばいいかの確認方法、CloudflareでTTLが変えられない場合の理由、そして次のサーバー移転に備えた事前準備の手順を、順番に整理します。
DNS設定を変えたのに古いサイトが表示されるのはなぜですか？
TTLで指定した秒数のあいだ、世界中のキャッシュサーバーは古いDNS情報を保持し続けます。設定変更は即時には広がらず、TTLの時間が切れた時点で各キャッシュが更新されます。
DNSの変更がすぐに全世界に届かない理由は、途中に「キャッシュサーバー」という中継地点が存在するためです。キャッシュサーバーとは、問い合わせ結果を一時保存してトラフィックを効率化する仕組みで、プロバイダやCloudflareの 1.1.1.1、GoogleのDNSサーバーである 8.8.8.8 などがその役割を担います。
Aレコード（ドメインをIPアドレスに向けるDNSの基本レコード）を変更したとき、権威DNSサーバー（設定の正本を管理するサーバー）はすぐに更新されます。しかし世界各地のキャッシュサーバーはすでに古い情報を持っており、そのキャッシュが有効な間は古い情報を返し続けます。
情報の流れを整理するとこうなります。
あなたのDNS変更
↓
権威DNSサーバー（設定の正本）← 変更はすぐ反映される
↓
世界各地のキャッシュサーバー ← TTLが切れるまで古い情報を保持し続ける
↓
各拠点のPC・スマートフォンTTL（Time To Live）とは、このキャッシュサーバーが情報を保持してよい秒数のことです。TTLが3600秒であれば、変更後から最大1時間は古い情報が返ってくる可能性があります。
「自分の画面では新しいサイトが見えているのに相手には古いものが見える」という状況が起きるのも、この仕組みによるものです。自分のPCからアクセスしているキャッシュサーバーはすでに更新されていても、相手の拠点のプロバイダが管理しているキャッシュサーバーはまだ古い情報を持っている——という状態が同時に存在します。
DNSの基本的な仕組みやレコードの種類については、DNSレコード全体の解説をご覧ください。
「48時間かかる」はいつの話か
「DNS浸透に48時間かかる」という情報を目にすることがあります。これは現在の標準的な運用とは状況が異なります。
以前はレジストラのデフォルトTTLが86400秒（24時間）以上に設定されているケースが多く、変更が全域に届くまでに2日前後かかることがありました。現在は多くのサービスでデフォルトのTTLが300〜3600秒（5分〜1時間）に短縮されています。
実際の待ち時間はTTLの設定値によって変わります。TTLが3600秒なら最大1時間、TTLが300秒なら最大5分です。通説の「48時間」という数字が正しいかどうかは、実際のTTL値を確認することで判断できます。
あと何分待てばいいですか？ — TTLの残り時間を確認する
Resolve-DnsName -Name ドメイン -Type A -Server 8.8.8.8を実行するとTTL値が確認できます。表示された秒数が経過した時点でキャッシュが更新されます。WindowsのPowerShellでそのまま使えます。
WindowsのPowerShellで確認する（推奨）
スタートメニューで「PowerShell」と検索して開き、以下を入力してください。example.com の部分は確認したいドメインに置き換えます。
Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8実行すると次のような結果が返ってきます。
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
example.com A 3600 Answer 203.0.113.10TTL 列の数値がキャッシュの残り秒数です。3600 と表示されていれば、最大3600秒（1時間）待てばキャッシュが更新されます。IPAddress 列に新しいIPアドレスが表示されていれば、少なくともGoogleのDNSサーバー経由では設定が正しく反映されています。
確認ポイントのまとめ
| 確認項目 | 見るべき値 | 判断 |
|---|---|---|
| IPAddress | 新しいサーバーのIPアドレスか | 古いIPなら権威DNS側がまだ更新されていない |
| TTL | 何秒か | この秒数が経過すれば他のキャッシュも更新される |
| エラーの有無 | エラーが出ていないか | エラーがなければ「待てばいい問題」 |
よく使うTTL秒数の目安は次のとおりです。
| TTL秒数 | 待ち時間の目安 |
|---|---|
| 60 | 約1分 |
| 300 | 約5分 |
| 3600 | 約1時間 |
| 86400 | 約24時間（1日） |
Windowsのコマンドプロンプト（nslookup）で確認する
PowerShellが使いにくい場合は、コマンドプロンプトでも確認できます。
nslookup -debug -type=A example.com 8.8.8.8-debug オプションを付けると詳細な出力が表示されます。出力の中に次のような行があります。
-> example.com
type = A, class = IN, datalength = 4
internet address = 203.0.113.10
ttl = 3600 (1 hour)ttl = 3600 (1 hour) のような行でTTL値を確認できます。出力量は多くなりますが、ttl = が含まれる行を探してください。
-debug なしの nslookup -type=A example.com 8.8.8.8 ではTTL値は表示されないため、TTLを確認するときは必ず -debug を付けてください。
MacやLinux環境（digコマンド）で確認する
MacやLinux、またはWindowsでGit Bashが使える場合は dig コマンドが便利です。
dig example.com A @8.8.8.8ANSWERセクションに次のような形でTTL値が表示されます。
;; ANSWER SECTION:
example.com. 3600 IN A 203.0.113.10左から2番目の数値（ここでは 3600）がTTL秒数です。
複数の場所から確認したい場合
自分のPCからは新しいサイトが見えているのに別の拠点では古いものが見えるという場合、相手のプロバイダが管理しているキャッシュサーバーのTTLがまだ切れていない状態です。
こういった場合は、Google（8.8.8.8）とCloudflare（1.1.1.1）という2つの異なるDNSサーバーに対してそれぞれ確認コマンドを実行してみてください。2つとも新しいIPアドレスを返しているなら、主要なキャッシュサーバーには反映済みで、あとはプロバイダ固有のキャッシュが切れるのを待つだけという状況です。
# Googleで確認
Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8
# Cloudflareで確認
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1両方とも新しいIPを返しているなら、上司や相手への説明はこう言えます。「主要なDNSサーバーには反映済みです。ご利用のプロバイダ側のキャッシュが切れれば表示が切り替わります。TTLが○○秒なので、あと最大○○分で確認できる見込みです。」
CloudflareでTTLが変えられないのはなぜですか？
Cloudflareのプロキシ（オレンジ雲）がONのレコードは、TTLが自動（300秒）に固定されユーザーは変更できません。これは仕様であって操作ミスではありません。
CloudflareのDNS管理画面でTTLを変更しようとしたとき、選択肢がグレーアウトして変更できない場合があります。エラーメッセージも出ないため、自分の操作が間違っているのか仕様なのか判断がつきにくい——これはCloudflareを使い始めたばかりの時期によく遭遇する状況です。これは操作ミスではなく仕様です。
原因はレコードのプロキシ設定にあります。
| プロキシ設定 | 管理画面の表示 | TTL変更 | TTL値 |
|---|---|---|---|
| プロキシON | オレンジ雲 | 変更不可（仕様） | 自動（300秒固定） |
| プロキシOFF（DNS-onlyモード） | グレー雲 | 変更可能 | 60秒〜86400秒 |
オレンジ雲がついているレコードは、CloudflareがDDoS対策やCDNとしてトラフィックを中継しています。この状態ではTTLはCloudflare側が自動（既定値300秒）に固定し、ユーザー側での変更は受け付けない仕様になっています。
TTLを変更したい場合の操作手順
TTLを自分で指定したい場合は、次の手順でプロキシをOFFに切り替えてください。
- CloudflareのダッシュボードでDNSの管理画面を開く
- 対象レコードの「プロキシ済み（Proxied）」トグルをクリックしてOFFに切り替える
- 雲のアイコンがオレンジからグレーに変わる（DNS-onlyモード）
- TTLの選択肢が有効になるので、任意の秒数を選択する
プロキシをOFFにすると、CloudflareのDDoS保護やキャッシュ機能は無効になります。通常のAレコードであれば影響は限定的ですが、CloudflareのProxy機能を意図的に使っている場合は注意が必要です。
この制限はCloudflareの公式ドキュメントに明記されています（参考：Cloudflare — DNS TTL reference）。
サーバー移転前にTTLを短くしておく手順
サーバー移転の24〜48時間前にTTLを300秒（5分）に変更し、古いTTLが切れるのを待ちます。その後Aレコードを変更すると、新サーバーへの切り替えが5分以内に完了します。
ベンダーや外部の担当者から「移転前にTTLを短くしておいてください」と言われても、何をどうすればいいかが分からないまま話が進むことがあります。以下の手順でそのまま対応できます。
移転前のTTL短縮手順
ステップ1：移転の24〜48時間前にTTLを300秒に変更する
DNS管理画面（Cloudflare、お名前.com、各レジストラの管理画面）で、移転対象のAレコードのTTLを300秒（または最小値）に変更します。Cloudflareの場合はプロキシをOFFにしてからTTLを変更してください。
ステップ2：旧TTLが切れるまで待つ
変更前のTTLが3600秒（1時間）であれば、その1時間が過ぎるまで待ちます。この待機時間が必要な理由は、すでにキャッシュされた古いTTL値が「有効期限まで保持される」ためです。旧TTLが切れた後の問い合わせから、新しいTTL（300秒）が適用されます。
| 変更前のTTL | 待機が必要な時間 |
|---|---|
| 86400秒（1日） | 約24時間 |
| 3600秒（1時間） | 約1時間 |
| 300秒（5分） | 約5分 |
ステップ3：移転当日にAレコードを変更する
待機時間が経過したら、Aレコードの向き先を新サーバーのIPアドレスに変更します。この時点でキャッシュサーバーはすでに300秒のTTLを持っているため、5分以内に新サーバーへの反映が完了します。
ステップ4：移転が安定したらTTLを元に戻す
新サーバーで問題なく動作していることを確認したら、TTLを3600秒に戻してください。TTLを短いままにしておくと、キャッシュへの問い合わせ頻度が高まり、DNSサーバーへの負荷が増えます。
AレコードとCNAMEレコードの使い分けについてはCNAMEとAレコードの使い分けを参照してください。
TTL短縮を忘れて移転当日を迎えてしまった場合
事前にTTLを短縮しておかなかった場合、移転当日にAレコードを変更しても全拠点に届くまで現在のTTLの時間がかかります。
この場合も、対処は同じ手順です。
- 移転当日でもまずTTLを300秒に変更する
- 旧TTLが切れるまで待つ（現在が3600秒なら最大1時間）
- 旧TTLが切れたことを確認コマンドで確認してからAレコードを変更する
当日に変更せざるを得ない場合でも、この順序で進めると影響を最小限に抑えられます。「TTL短縮を忘れた」ことそのものは、設定ミスではありません。
ベンダーへ渡せるメモ（コピペ用）
移転の段取りをベンダーや外部の担当者と共有するときは、次の文面をそのまま使えます。
ご依頼のとおり、移転の前日にTTLを300秒に変更します。変更前のTTL（現在3600秒）が失効するまで約1時間かかります。旧TTLが切れた後にAレコードを新サーバーのIPアドレスへ変更します。その後5分（300秒）で新サーバーへの反映が完了する見込みです。
社内向けの進捗説明が必要な場合は、前述の「複数の場所から確認したい場合」で示した言い方をそのまま使ってください。反映済みの範囲と残りの待ち時間を伝える形になっています。
TTLに関してよくある誤解とトラブルシュート
TTLを変えたのに即反映されないのはなぜですか？
TTLを変えた時点では、すでにキャッシュされた古いTTL値がまだ生きています。古いTTL値の時間が切れた後、次の問い合わせから新しいTTL値が適用されます。TTLを変えること自体は正常ですが、切り替わりには「旧TTLの残り時間」の待機が必要です。
具体例で言うと、TTLを3600秒から300秒に変更したとしても、各地のキャッシュサーバーはすでに「3600秒間保持してよい」という情報とセットで古いレコードを持っています。その3600秒が切れてから初めて新しいTTL（300秒）が効き始めます。
削除したはずのレコードが「ない」と言われるまでに時間がかかるのはなぜですか？
DNSには「存在しない」という回答もTTLの時間だけキャッシュする仕組みがあります（ネガティブキャッシュと呼ばれる仕様で、RFC 2308として定義されています。参考：JPRS用語辞典）。
「削除したはずのレコードがまだ存在するとエラーが出る」「新しく作ったレコードがしばらく『ない』と言われ続ける」——どちらもこの仕組みによるものです。設定の問題ではなく、キャッシュのTTLが切れるまでの正常な状態です。
メール関連のDNS設定についてはメールのDNS設定（MXレコード）を参照してください。
TTLはどれくらいの値に設定するのが一般的ですか？
通常の運用時は3600秒（1時間）が一般的な設定値です。
サーバー移転や設定変更を予定している前後は300秒（5分）に下げ、作業が安定したら3600秒に戻すというサイクルが実務上の標準的な使い方です。TTLを短くしすぎると各地からのDNS問い合わせ頻度が上がるため、日常的な運用では1時間程度が適切です。
| 場面 | 推奨TTL |
|---|---|
| 通常の運用 | 3600秒（1時間） |
| サーバー移転前後 | 300秒（5分） |
| 頻繁に変更が発生する設定中 | 300秒（5分） |
| 移転完了後の戻し | 3600秒（1時間） |
同じドメインで複数のレコードにTTLが設定されている場合はどうなりますか？
各レコードはそれぞれ個別にTTLを持っています。Aレコードのみ変更しても、MXレコード（メール用）やCNAMEレコードのTTLは独立しています。サーバー移転の際にメール設定も変更する場合は、MXレコードのTTLも別途短縮しておく必要があります。
移転後にサイトを確認する際のブラウザキャッシュの注意点
DNSのTTLが切れて新しいIPアドレスに更新されても、ブラウザが過去のアクセス情報をキャッシュしている場合、古いサイトが表示されることがあります。この場合はブラウザのキャッシュをクリアするか、シークレット（プライベート）ウィンドウでアクセスして確認してください。
DNSキャッシュとブラウザキャッシュは別物であるため、どちらの問題かを切り分けることが大切です。別のデバイスや別のネットワーク（スマートフォンのモバイル回線など）からアクセスして確認するのが手軽な方法です。
まとめ
「待てばいい問題か、設定を間違えている問題か」は、次の手順で判断できます。
Resolve-DnsName -Name ドメイン -Type A -Server 8.8.8.8を実行して新しいIPアドレスが返っているか確認する- 新しいIPアドレスが返っていればTTLの時間だけ待てばよい状態。エラーが出ていなければ「待てばいい問題」
- Cloudflareのオレンジ雲がONのときにTTLが変えられないのは仕様。300秒（5分）固定で正常な状態
- 次回の移転に備えるなら、24〜48時間前にTTLを300秒に下げておくことで当日の待ちを5分以内に抑えられる
設定変更後に古いサイトが見えていると言われるのは、ミスではなく仕様です。TTLの時間が切れるまで、各地のサーバーは古い情報を持ち続けます。あなたがやるべきことは、残り時間を確認して待つか、次回の作業のために事前に短くしておく手順を覚えることです。それだけです。
DNSの設定変更やサーバー移転まわりで詰まっている場合は、メールでご相談ください。