DNSレコード変更時の反映トラブルとSSLエラー 管理会社の不具合事例と注意点

ホームページ（ウェブサイト）のリニューアルやサーバーの移転、あるいは利用しているシステム間の連携を変更する際、避けて通れない重要な工程がDNSレコードの変更およびSSL証明書の設定です。一般的なホームページ制作や運用の解説においては、管理画面から指定された通りにAレコードやCNAMEレコードを書き換え、一定時間待てば自動的に新しいホームページが表示されるようになると説明されることがほとんどです。しかしながら、実際の制作現場やマーケティング支援の現場においては、マニュアル通りに寸分の狂いもなく正確な設定を行っているにもかかわらず、想定通りにホームページが表示されない、あるいは古い情報がいつまでも消えずにエラーを引き起こし続けるという深刻なトラブルに直面することがあります。

特に事業の集客や取引先との連絡にホームページを活用している企業にとって、数日間にわたって画面が閲覧できなくなったり、ブラウザ上に危険を知らせる警告画面が表示されたりする事態は、信用問題に直結する重大な事態です。発注者である事業主の立場からすれば、費用を支払って専門の制作会社に依頼した以上、スムーズに切り替わって当然であるという認識を持つのは自然なことです。そのため、表示の不安定化が長引けば長引くほど、制作会社の技術力や対応に対する不信感へとつながりやすく、現場で大きな摩擦が生じる原因となります。

今回は、過去に私たちが実際の業務の中で経験した非常に複雑かつ難航したトラブル事例をもとに、DNSレコードの変更に伴う反映遅延の真実や、除したはずのレコードが消えない現象、さらにはそれに起因するSSL証明書の再発行エラーについて、技術的な裏付けとともに徹底的に解説していきます。あわせて、WixやJimdoといった海外発のクラウド型ホームページ作成サービスからWordPressなどへ移行する際に多発する特有の遅延問題や、管理会社側のシステム不具合が疑われる状況において、どのように問題を切り分け、最終的にどう解決へと導くべきかという実践的な知見を共有していきます。

DNSレコードの反映（浸透）に関する基本的な仕組みと時間

ホームページの引っ越しや表示先の変更を行う際、最初に行うのがDNS（ドメイン・ネーム・システム）のレコード設定変更です。ドメインという人間にとって分かりやすい文字列と、サーバーの所在を示すIPアドレスという数字の羅列を紐づけるこの仕組みは、インターネット上の案内板のような役割を果たしています。

（弊社では、DNSレコード設定・変更の対応サービスも提供しています）

まずは、この案内板の書き換えが世界中の端末に行き渡るまでの基本的な仕組みと、一般的に言われている所要時間、そして技術者が行う事前対策について整理していきます。

権威DNSサーバーとキャッシュDNSサーバーの連携によるプロパゲーションの仕組み

DNSレコードの設定を変更した際、その変更内容が即座に世界中のすべてのパソコンやスマートフォンに反映されるわけではありません。この時間差が生じる理由は、インターネット全体の通信負荷を軽減するために設計されたキャッシュという仕組みにあります。ドメインの管理会社が運用しているサーバーは権威DNSサーバーと呼ばれ、ここにはそのドメインに関する正式な設定情報（ゾーン情報）が格納されています。制作会社や管理者が管理画面からAレコードやCNAMEレコードを変更すると、まずこの権威DNSサーバー内の情報が書き換わります。

しかし、私たちが普段パソコンやスマートフォンからホームページを閲覧する際、端末は毎回直接その権威DNSサーバーへ問い合わせを行っているわけではありません。契約しているインターネット回線のプロバイダや携帯電話会社、あるいはGoogleなどが提供しているキャッシュDNSサーバー（フルサービスリゾルバ）という中継地点に対して、目的のドメインのIPアドレスを尋ねています。キャッシュDNSサーバーは、一度問い合わせたドメインの情報を一定期間自分の手元に記憶（キャッシュ）し、同じドメインへの問い合わせが別の利用者からあった場合には、権威DNSサーバーへ聞きに行く手間を省いて手元の記憶から即座に回答を返します。この記憶された古い情報が寿命を迎えて破棄され、新しい設定情報が順番に世界中のキャッシュDNSサーバーへと行き渡っていく過程を、専門的にはプロパゲーション、一般的にはDNSの浸透と呼んでいます。

インターネット上の一般論で語られる最大72時間という目安と発注者の認識

このDNSの浸透に要する時間については、インターネット上の多くの技術解説記事やサーバー会社のヘルプページにおいて、早ければ数時間から半日程度、遅くとも最大72時間（3日間）程度で完了すると記載されています。Jimdoなどの一部のサービスにおいては、公式ヘルプ上で最大24時間程度とさらに短い目安を案内しているケースも見受けられます。こうした情報が広く出回っているため、ホームページの発注者や事業主の方々の間でも、サーバーの切り替えやドメインの設定変更は長くても3日待てば完全に安定するという認識が強く根付いています。 実際に通常の国内レンタルサーバー同士の移転やシンプルな構成でのAレコード変更であれば、数時間から24時間以内に大半の環境で新しいホームページが表示されるようになることが多く、72時間を待たずして作業が完了するケースが大半です。

そのため、事前のスケジュール調整においても、週末や夜間のアクセスが少ない時間帯に作業を開始し、翌営業日や週明けには正常に稼働している状態を想定して取引先への案内などを進めることが一般的です。しかし、この最大72時間という数字は、あくまで権威DNSサーバーが正常に新しいゾーン情報を配信し、かつ単純な構成でスムーズにキャッシュの更新が行われた場合の目安に過ぎません。複数のシステムが絡み合う環境や、管理会社側の内部処理に問題を抱えているケースにおいては、この一般論の枠を大きく超えて不具合が継続することがあります。

DNS反映を早めるための技術的な工夫とTTL値の事前調整およびその限界

より専門的には、ホームページの切り替えに伴う不安定な時間を少しでも短縮するために、事前のTTL（Time To Live）値の調整という技術的な工夫を行うことが定石とされています。TTLとは、キャッシュDNSサーバーに対して「このドメインの情報は指定した秒数だけ記憶しておいてよい」と指示する有効期限の数値です。

たとえばTTLが86400秒（24時間）に設定されている状態でレコードを変更すると、変更直前に情報を記憶したキャッシュDNSサーバーは、そこから丸1日間は古いIPアドレスを返し続けることになります。これを防ぐため、計画的なサーバー移転やレコード変更を行う際には、作業の数日前からあらかじめTTLの値を300秒（5分）や600秒（10分）といった極端に短い数値に変更しておく手法をとります。こうすることで、切り替え作業の当日には世界中のキャッシュDNSサーバーが5分や10分おきに最新の情報を確認しに来る状態が作られるため、レコードを書き換えた後、理論上は数分から数十分程度で素早く新しいサーバーへと誘導することが可能になります。

しかしながら、このTTL短縮による時間短縮テクニックには明確な限界が存在します。第一に、すべてのドメイン管理会社やネームサーバーが任意のTTL設定を許可しているわけではなく、管理画面上でTTLの項目自体が固定されていて変更できないサービスが少なくありません。第二に、仮にこちら側でTTLを300秒と短く指定して配信したとしても、インターネット上の通信回線や中継地点にある一部のキャッシュDNSサーバー（特に一部の海外経由の回線や特定のプロバイダ、モバイル通信網など）は、自社のサーバー負荷を抑えるために、送られてきた短いTTLの設定を無視して独自に数時間から数十時間のキャッシュを強制的に保持するという挙動を見せることがあります。したがって、技術者がどれほど入念に事前のTTL調整を行ったとしても、閲覧する端末や回線によっては古い情報が残り続ける現象を完全にゼロにすることはできません。

一般論の時間経過後も正常反映されない事態と管理会社側の不具合事例

上述した通り、通常の範囲であれば数時間から最大72時間程度で収束するはずのDNSの反映ですが、私たちが過去に経験した事例においては、72時間を経過してもなお設定が正常に反映されず、ホームページの表示が極めて不安定な状態から抜け出せないという異常事態が発生しました。ここでは、実際に起きた事象の詳細と、なぜそのような事態に陥ったのかという根本原因について掘り下げていきます。

制作会社の技術や設定ミスではなくドメイン管理会社のシステム不具合が原因となるケース

この事例における当初の構成は、ドメインの管理およびメールサーバーの運用を国内の某ドメイン・サーバー管理会社で行いながら、ホームページの表示に関しては「wwwなし」のメインドメインを新しい外部のホームページ作成サービス（クラウド型のノーコードツール）へ向け、「wwwあり」のサブドメイン側をJimdoへ接続し、最終的に表示の統一やリダイレクト（自動転送）を図るという複雑な構成でした。発注者からは、新規の取引先との打ち合わせが複数控えているため、ホームページが見られなくなる時間を極力作らずに、wwwあり・なしの両方で正常に閲覧できるようにしてほしいという強い要望が寄せられていました。

私たちはご要望に応えるべく、DNSレコードの仕様に則り、AレコードおよびCNAMEレコードの設定、さらには一時的な向きの変更と再設定を正確に実施しました。しかし、作業完了から1日、2日、そして一般的な最大目安である72時間が経過しても、ホームページが表示されたりされなかったりする不安定な状態が解消されませんでした。

管理画面のレコード設定を何度確認しても、設定記述そのものには一切の誤りがありませんでした。

結論から言えば、このトラブルの真の原因は私たちの設定ミスや技術不足ではなく、ドメイン管理会社の管理画面で操作した内容が、管理会社内部の権威DNSサーバーのゾーン情報へと正常に書き込まれないという、管理会社側のシステム不具合にありました。

管理画面上では削除したはずの古いAレコードが消えずに残存し続ける現象

具体的に発生していた異常は、ドメイン管理会社のコントロールパネル（管理画面）上では確実に削除し、画面上の一覧からも消えているはずの古いAレコード（ドメイン管理会社のサーバーIPアドレスを指し示す設定）が、外部からDNSの状態を調査すると、72時間以上経過しても全く消えずに残り続けているという現象でした。

本来であれば、管理画面上で古いAレコードを削除し、新しいサーバーのIPアドレスを持つAレコードのみを残して保存ボタンを押せば、権威DNSサーバーのゾーンファイルから古い行が消去され、新しいIPアドレスのみが外部へ応答されるようになります。ところがこの事例では、管理画面の見た目上は新しいAレコード1つだけが設定されているにもかかわらず、裏側のシステムで削除処理が正常に反映されておらず、削除したはずの古いIPアドレスが亡霊のように生き残り続けていました。

その結果、インターネット上からそのドメインにアクセスしようとすると、新しいホームページのサーバーと、何もホームページのデータが入っていない古いドメイン管理会社のサーバーの両方が案内先として存在し続けるという、極めて異常な状態が引き起こされていました。

wwwあり・なしの統一におけるCNAMEとAレコードの優先関係とデフォルト設定の干渉

さらに事態を複雑にしていたのが、「wwwあり」と「wwwなし（ネイキッドドメインまたはゾーンエイペックスと呼びます）」の連携に関わるCNAMEレコードとAレコードの仕様、およびドメイン管理会社特有のデフォルト設定の干渉です。Jimdoなどの外部サービスに「wwwあり」のドメインを接続する場合、通常は「www」のホスト名に対してJimdo指定のアドレスを向けるCNAMEレコードを設定します。

CNAMEレコードが正常に反映されれば、wwwありへのアクセスはJimdo側の設定を参照するようになり、スムーズにホームページが表示されます。 しかし、利用していたドメイン管理会社のシステムでは、初期状態でCNAMEレコードがデフォルト設定として内部的に自動生成されており、管理画面から通常のやり方で新たなCNAMEを追加しようとしても競合して設定できない、あるいは一度Aレコードを設定して削除するとデフォルトの挙動と干渉して名前解決が不能になるという癖の強い仕様が存在していました。

このデフォルト設定を上書きするために、既存のwwwありに対するAレコードを明示的に削除した上でJimdo用のCNAME設定を流し込むなどの対処を行いましたが、前述の通り管理会社側のシステムでレコードの削除反映自体が滞っていたため、古いAレコードやデフォルトのCNAMEの影響がいつまでも抜けず、アクセスするたびに404エラー（ページが見つかりません）が返されたり、接続そのものが失敗したりする事象が繰り返されました。

nslookupを用いた外部からのDNSレコード検証と原因の切り分け

ホームページが正常に表示されないとき、感覚や推測だけで管理画面を何度もいじり回すことは最も避けるべき行為です。DNSの設定は操作をすればするほどキャッシュの状態が混乱し、不安定な時間がさらに延びてしまうためです。問題が起きた際に私たちが必ず実施するのが、コマンドプロンプトやターミナルを用いた「nslookup」などのネットワーク診断コマンドによる、外部からの客観的なDNSレコードの検証です。

nslookupコマンドによる名前解決の調査とSERVFAILエラーが意味する状況

ブラウザ上でホームページが表示されない場合、それがブラウザ自体のキャッシュの問題なのか、ホームページ制作ツール側の問題なのか、それともDNSの名前解決の段階でつまずいているのかを正確に切り分ける必要があります。nslookupコマンドを使用すると、現在インターネット上のDNSサーバーが対象のドメインに対してどのようなIPアドレスやレコード情報を返しているのかを、直接テキストデータとして確認することができます。

このトラブル事例において、私たちが「wwwあり」のドメインに対してnslookupを実行した際、返ってきたのは正常なIPアドレスではなく「server can’t find www.(対象ドメイン): SERVFAIL」というエラーメッセージでした。SERVFAIL（サーバーフェイル）とは、問い合わせを受けたDNSサーバーが、対象の権威DNSサーバーと正常に通信できなかったり、権威DNSサーバー側で内部エラーや設定の矛盾が生じていて正しい回答を生成できなかったりした際に返される深刻なエラーコードです。つまり、単に「まだ古いサーバーを見に行っている」というレベルの浸透待ちではなく、ドメイン管理会社のネームサーバー自体がwwwありの問い合わせに対して正常に応答できていないという決定的な証拠が、この検証によって明らかになりました。

新旧2つのIPアドレスが同時に返却されるラウンドロビン状態の危険性

続いて「wwwなし」のメインドメインに対してnslookupを実行したところ、さらに驚くべき結果が表示されました。管理画面上では新しいホームページのサーバーIPアドレス（仮に35.xxx.xxx.xxxとします）のみを設定し、古いサーバーのIPアドレス（仮に153.xxx.xxx.xxxとします）は3日以上前に削除していたにもかかわらず、nslookupの応答結果には「Address: 153.xxx.xxx.xxx」と「Address: 35.xxx.xxx.xxx」という2つのIPアドレスが同時に並べて返却されました。

このように1つのドメイン名に対して複数のAレコード（IPアドレス）が登録されている状態は、本来は大規模なホームページでアクセス負荷を複数のサーバーに分散させる「DNSラウンドロビン」という手法で使われるものです。しかし、今回のケースでは片方は正しい新しいホームページのサーバーであり、もう片方はホームページの実体が存在しない古い管理会社のサーバーです。

この2つが同時に返却されているということは、アクセスするたびにサイコロを振るような状態で、50パーセントの確率で新しいホームページが表示され、残り50パーセントの確率で古い空っぽのサーバーへ誘導されてエラー画面になるということを意味します。管理画面のスクリーンショットを確認しても古いIPアドレスの記述はどこにも存在しないにもかかわらず、外部からnslookupで叩くと確実に2つのアドレスが返ってくるという事実から、管理会社側のデータベースと実際のDNS配信システムの間に同期不全（バグ）が起きていることを特定できました。

権威サーバーの応答不全と浸透の不安定化による接続断絶

また、Jimdo側の管理画面においてドメインの接続ステータスを監視していると、ある時間帯には「接続されています」と正常な表示になるものの、別の時間帯には突如として接続が切れたような表示に変わるなど、システム間の連携確認すら安定しない状況が見受けられました。これも、Jimdoのシステムが定期的にCNAMEやAレコードの疎通確認を行う際、ドメイン管理会社の権威DNSサーバーが不安定な応答（SERVFAILや古いIPアドレスの返却）を繰り返していたために発生していた現象です。このように、コマンドレベルでの検証を行うことで、表面上のブラウザ表示に惑わされず、裏側で起きている通信の断絶を正確に把握することができます。

メールサーバー用のMXレコードやAレコードとウェブ表示用レコードの明確な区別

DNSトラブルの対応中に発注者との間でよく生じる誤解の一つに、ホームページ表示用のAレコードと、メール送受信用のレコードの混同があります。今回の事例でも、私たちが「古いサーバーのIPアドレス（153.xxx.xxx.xxx）を指しているAレコードが消えずに残っているため、これを削除する必要がある」とご説明した際、発注者から「そのIPアドレスのAレコードはメールサーバー用ではないのか。それを消してしまうと会社のメールが使えなくなってしまうのではないか」という不安の声が上がりました。 企業の事業活動においてメールの停止は致命的であるため、発注者がこの点に敏感になるのは当然のことです。ここで重要になるのが、ホスト名（サブドメイン）の有無によるレコードの役割の明確な区別です。

メールの配送先を指定するMXレコードが「mail.(対象ドメイン)」というホスト名を向いている場合、メールサーバーの実体を示すために必要なのは「mail.(対象ドメイン)」というサブドメインがついたAレコード（値：153.xxx.xxx.xxx）です。この「mail.」がついたAレコードとMXレコードさえ維持されていれば、メール機能は問題なく古いサーバー（ドメイン管理会社のメールサーバー）で稼働し続けます。 一方で、今回問題を引き起こし、削除しなければならなかったのは、サブドメインが何もつかない「(対象ドメイン)のみ」に対するAレコード（値：153.xxx.xxx.xxx）です。同じIPアドレスが記載されていても、先頭に「mail.」がついているかいないかで、制御している対象がメールなのかホームページ（wwwなし）なのかが全く異なります。専門知識を持たない発注者に対しては、管理画面のどの行がメール用であり、どの行がホームページ表示用で悪影響を及ぼしているのかを、テキストで並べて視覚的に分かりやすく解説し、メールが消えることはないという安心感を持ってもらう配慮が求められます。

SSL認証用のTXTレコード（_acme-challenge）の役割と残存による影響の判断

さらに、トラブルの過程で発注者が管理画面のレコード一覧を確認した際、「以前は存在しなかったはずのTXTレコード（_acme-challengeから始まる長い英数字の文字列）が勝手に増えている。すべてを元の状態に戻してほしい」と指摘される場面がありました。見慣れない複雑な文字列がレコード内に残っていると、それが原因でホームページが表示されなくなっているのではないかと疑心暗鬼になるケースは少なくありません。

この「_acme-challenge.(対象ドメイン)」というホスト名を持つTXTレコードは、Let’s Encryptなどの無料SSL証明書を自動発行・更新する際（ACMEプロトコルによるDNS-01認証）に、システムが「本当にこのドメインの管理者であるか」を確認するために一時的に生成する認証用のテキストデータです。具体的には、今回の対応の途中で古いサーバー側のSSL証明書を再発行しようと試みた際、サーバーシステム側が認証のために自動生成したものでした。

このTXTレコード自体は、あくまでSSL証明書の所有権確認のためだけに参照される文字列であり、これが存在しているからといってホームページの表示先（ドメインとサーバーの連携）やメールの送受信に悪影響を与えるものではありません。ただし、発注者の不安を解消し、不要な設定を整理するという観点から、一時的な作業後に不要となったこのTXTレコードについては手動で削除の対応を行いました。このように、各レコードが何の目的で生成され、削除するとどうなるのか（今回であれば、削除してもドメインとサーバーの連携には影響しないが、万が一古いサーバー側へアクセスが向いた際にSSL証明書エラーが出るようになることなど）を正確に説明できる知識が、トラブル収束においては非常に重要です。

閲覧環境による表示状況のばらつきとキャッシュが引き起こす混乱

DNSレコードの反映が不安定な期間や、前述のように新旧2つのIPアドレスが混在して返却されている状況下では、ホームページを閲覧するパソコンやスマートフォンの環境によって「見られる人」と「見られない人」、あるいは「見られるブラウザ」と「見られないブラウザ」がバラバラに発生するという現象が起こります。これが現場の混乱をさらに拍車をかけます。

パソコンとスマートフォンや通信キャリアごとに異なるDNSキャッシュの保持時間

実際のやり取りの中でも、私たちの社内検証環境（WindowsのFirefoxなど）では新しいホームページやJimdoの画面が安定して表示されているにもかかわらず、発注者の手元の環境（WindowsのChromeやEdge、およびiPhoneのSafari、Chrome、Edge）では「wwwなしは見られるが、wwwありは全く見られない」「iPhoneのEdgeでは見られるがJimdoの新しい画面ではなく古い画面が出る」といったように、端末や環境ごとに全く異なる症状が報告されました。 なぜ同じ時間帯に同じURLへアクセスしているにもかかわらず、これほどまでに表示結果が異なるのかというと、利用している通信回線（光回線などの固定回線と、ドコモ・au・ソフトバンクなどの携帯キャリア回線）ごとに参照しているキャッシュDNSサーバーが異なり、それぞれが記憶しているレコード情報が違うためです。

さらに、スマートフォン端末（iOSやAndroid）は、通信量を節約し表示速度を高めるために、OSレベルおよびブラウザレベルで非常に強力なキャッシュ機能（データの一時保存機能）を持っています。そのため、パソコン側ではすでに新しいDNS情報を取得して正常に表示できていても、スマートフォン側では過去の古いアクセス経路やエラー画面のデータを端末内部に強く握りしめており、手動でブラウザの閲覧履歴やキャッシュデータを完全にクリアしない限り、いつまでも古い状態やエラーが表示され続けるという事象が頻繁に発生します。

ChromeやEdgeやSafariなどブラウザごとの挙動の違いとリダイレクト情報の記憶

また、同じパソコンや同じスマートフォンを使っていても、Chrome、Edge、Safari、Firefoxといったブラウザの種類によって表示結果が分かれることも珍しくありません。これは、現代の主要ブラウザがOSのDNSキャッシュとは別に、ブラウザ独自の内部DNSキャッシュやソケットプール（通信経路の保持機能）を持っているためです。さらに厄介なのが、リダイレクト（自動転送）に関するブラウザの記憶機能です。

たとえば、「wwwあり」にアクセスした通信を「wwwなし」のメインドメインへ転送する設定（301リダイレクトなど）を行っている場合、一度ブラウザがその転送設定やその時点でのレコード情報を読み込むと、ブラウザは次回以降のアクセスを高速化するためにその経路情報を内部に記憶します。DNSの浸透が不安定で、古いサーバーと新しいサーバーの情報が入り乱れている最中にブラウザでアクセスしてしまうと、ブラウザが古いレコード情報を引き継いだまま転送処理を行おうとし、結果としてドメイン管理会社内の仮データやエラーページを参照し続けてしまうという挙動を見せることがあります。

一部の高性能なレンタルサーバーでは、DNS設定のレベルで直接wwwの有無をスムーズに転送する仕組みを備えているところもありますが、そうした機能を持たない管理会社の場合、サーバー側の転送設定とDNSのレコード情報が少しでも食い違うと、ブラウザごとに異なるエラーを引き起こす原因となります。

事業活動への支障を最小限に抑えるための検証体制と状況共有の難しさ

制作会社側としては、こうした環境ごとの差異を正確に把握するため、Windows環境でのChrome、Edge、Firefox、Opera、さらにはiOS（iPhoneおよびiPad）でのSafari、Chrome、そしてAndroid端末でのChromeなど、考え得る複数のOSとブラウザの組み合わせを総動員して表示確認を行います。しかし、どれほど制作会社の手元で「徐々に安定してきています」と確認できたとしても、発注者自身のスマートフォンや、まさにその日打ち合わせを行う新規取引先のパソコンでホームページが表示されなければ、発注者にとっては「全く直っていない」「業務に支障が出ている」という評価になってしまいます。

特に、制作会社が伝える「一般的な反映時間は最大72時間ですが、Aレコードが分散しているためさらに時間が延びる場合があり、操作をすればするほど不安定になるため待つしかありません」という技術的に正しい説明も、発注者からすれば無責任な言い逃れのように聞こえてしまう危険性があります。この認識のギャップを埋めるためには、なぜブラウザによって見え方が違うのか、裏側でどのレコードが引っかかっているのかという客観的なデータを提示し続ける姿勢が求められます。

切実な問題となるSSL再発行エラーとリダイレクト不全の連鎖

DNSレコードの反映トラブルと密接に絡み合い、現場を最も苦しめる切実な問題が、SSL証明書の発行・更新エラーおよびそれに伴うホームページの接続ブロックです。現代のインターネット環境において、通信を暗号化するSSL（https化）は必須の仕様となっていますが、DNSの紐付きに少しでも問題があると、このSSLが大きな壁となって立ちはだかります。

非SSL（http）ホームページのSSL化（https化）

SSL証明書の有効期限切れとブラウザによる接続ブロックおよび警告表示

今回の事例において、「wwwあり」のドメインへアクセスした人々を「wwwなし」の新しいホームページへと転送（リダイレクト）させるため、wwwありのレコードを一度ドメイン管理会社のサーバーへ向け、そこでリダイレクト設定を稼働させようと試みました。ところが、いざ設定を行ってアクセスしてみると、ブラウザの画面いっぱいに「この接続ではプライバシーが保護されません」という赤い警告画面が表示され、ホームページの閲覧および自動転送が完全にブロックされる事態となりました。

調査を行った結果、そのドメイン管理会社のサーバー内に設定されていた過去のSSL証明書が、数年前に有効期限切れを迎えたまま放置されていたことが判明しました。「http（暗号化なし）」でアクセスした場合には設定したリダイレクトが正常に機能して新しいホームページへと転送されるものの、「https（暗号化あり）」でアクセスした場合には、リダイレクトの処理が行われるよりも前の段階（ブラウザとサーバーが最初の通信を確立するSSLハンドシェイクの段階）で証明書期限切れが検知され、ブラウザが利用者の安全を守るために通信を強制遮断してしまう仕様となっています。

警告画面にある「詳細設定」から「安全ではありませんがサイトにアクセスする」という小さなリンクを手動でクリックすれば転送はされますが、一般の閲覧者や新規の取引先がそのような危険な操作を行ってくれるはずもなく、実質的にhttpsでのwwwありアクセスが完全に機能停止に陥りました。

レコード分散時におけるSSL認証エラーとサーバーの向き先を一時的に統一する手順

この警告を解消するためには、ドメイン管理会社のサーバー側で期限切れとなったSSL証明書を再発行（更新）する必要があります。SSLの設定作業自体は、管理画面から申請ボタンを押すだけのさほど大した作業ではありません。しかし、ここで極めて厄介な技術的制約が発生します。無料SSL（Let’s Encryptなど）をはじめとする多くのSSL証明書システムは、証明書を発行する際、「wwwあり」と「wwwなし」の両方のドメインが、その申請を行う同じサーバーのIPアドレスを向いているかどうかを自動的にチェック（認証）します。

今回のケースでは、「wwwなし」のAレコードはすでに新しい外部ホームページのサーバー（35.xxx.xxx.xxx）を向いており、「wwwあり」だけがドメイン管理会社の古いサーバー（153.xxx.xxx.xxx）を向いているという、レコードが2つの異なるサーバーに分散した状態でした。この状態でドメイン管理会社のサーバーからSSL証明書の再発行申請を行っても、認証システムが「wwwなしのドメインが自社のサーバーを向いていないため、ドメインの正当な所有権を確認できない」と判定し、SSLの更新処理がエラーとなって弾かれてしまいます。 このSSL再発行エラーを突破するための唯一の方法は、現在正常に稼働している「wwwなし」のAレコードを、一時的に古いドメイン管理会社のサーバー（153.xxx.xxx.xxx）へと引き戻してwwwあり・なしの両方を同一サーバーに統一し、その状態でSSL証明書を再発行・反映させた上で、完了後に再び「wwwなし」のAレコードを新しいホームページのサーバー（35.xxx.xxx.xxx）へと向け直すという、非常に手間とリスクを伴う手順を踏むことでした。

https通信の停止が引き起こすリダイレクトの失敗と検索エンジン評価への影響

当然ながら、SSL証明書を再発行するために「wwwなし」のレコードを一時的に古いサーバーへ引き戻している間は、これまで正常に見られていた「wwwなし」の新しいホームページまでもが一時的に閲覧できなくなる（動作を停止する）という犠牲を払わなければなりません。レコード変更の反映に数時間、そこからSSLの設定と認証反映に1時間から24時間程度、そして完了後にレコードを元の新しいサーバーへ戻して再び浸透するまでに数時間から数十時間を要するため、どれほど夜間のアクセスが少ない時間帯（たとえば16時以降に作業を開始し、夜間にSSL反映を待ち、翌朝にレコードを戻すなど）を狙って最短で作業を行ったとしても、一定期間ホームページの表示が不安定になることは避けられません。

さらに深刻な問題として、仮に今回この手順を踏んで無事にSSLを再発行できたとしても、無料SSL証明書は通常90日（3ヶ月）ごとに自動更新のタイミングが訪れます。将来その自動更新の時期が来た際、再びレコードが2つのサーバー（153.xxx.xxx.xxxと35.xxx.xxx.xxx）に分かれたままになっていると、自動更新の認証がまたしても失敗し、数ヶ月後に突然「この接続ではプライバシーが保護されません」というSSL警告が再発すると推測されます。 また、SEO（検索エンジン最適化）の観点から見ても、Googleの検索結果に「wwwあり」のURLがインデックス（登録）されている状態でhttpsのリダイレクトが機能しなくなると、検索結果からクリックしたユーザー全員がセキュリティ警告画面に直面することになり、直帰率の悪化や検索評価の下落を招きます。

本来であれば、こうした綱渡りのような分散運用を行うのではなく、wwwありとなしを完全に同一のサーバーに紐づけるか、新しいホームページのデータを単一のサーバーへ移管・再構築し、Google Search Console等を用いて正規URLの統一処理を適切に行うことが、長期的な事業運用の安定においては強く推奨されます。

WixやJimdoなど海外サービスからの移行とドメイン移管における特有の遅延

ここまで解説してきたDNSレコードの反映遅延やSSL証明書の認証トラブルですが、私たちがこれまで数多くのホームページ制作やリニューアルを手掛けてきた経験上、特定のサービスが絡む案件においてこうしたトラブルが顕著に多発する傾向があります。はっきりと言及すると、WixやJimdoといった海外発のクラウド型ホームページ作成サービスを利用しているケース、あるいはそれらのサービスからWordPressを用いた本格的なホームページへとリニューアル・移行する際のドメイン管理移管やDNS変更において、トラブルや大幅な遅延が発生する確率が非常に高くなります。

WixやJimdoからWordPressへリニューアルする際のDNS変更と独自仕様の壁

事業を立ち上げた初期段階では、専門知識がなくても手軽に画面を作れるWixやJimdoを利用し、その後、事業の拡大や本格的なSEO集客を目指してWordPressで構築したホームページへと移行する企業は数多く存在します。この際、これまで使っていた独自ドメインをそのまま新しいWordPressのサーバーへ引き継ぐことになりますが、WixやJimdoは独自の閉じたシステム環境（クラウド基盤）でドメインとホームページを紐づける仕様を採用しているため、一般的なレンタルサーバー同士の引っ越しとは勝手が大きく異なります。

たとえばWixでは、ポインティング方式（AレコードとCNAMEレコードの書き換え）ではなく、ネームサーバー自体をWix指定のものに向ける方式が推奨されており、いざ外部のWordPressサーバーへ切り替えようとした際、Wix側の管理画面の深い階層にあるDNS設定やドメイン接続の解除処理が直感的に分かりづらく、古い接続設定がシステム内部にキャッシュとして残り続けることがよくあります。

Jimdoにおいても、今回の事例で見られたようにCNAMEレコードによる接続確認やJimdo側でのSSL自動発行の仕組みが独自のタイミングで動いており、公式ヘルプには「最大24時間で反映」と書かれていても、実際には他のレコードとの兼ね合いで72時間以上経過しても接続ステータスが安定しないケースが多々あります。

海外サービスからのドメイン転出（移管）において国内事業者より時間を要する傾向

さらに問題が長期化しやすいのが、WixやJimdoを通じて取得・管理していた独自ドメインを、国内の一般的なドメイン管理会社やレンタルサーバー会社へと「ドメイン移管（転出）」するケースです。インターネット上の一般的な解説記事では、DNSの変更はTTLを短縮すればすぐ終わる、あるいは移管作業も数日でスムーズに完了するかのように書かれているため、発注者としては「最大でも3日程度で新しいホームページに切り替わる」という認識を強く持っています。しかし、海外サービスからのドメイン転出を伴う場合、国内事業者間の移管と比べて圧倒的に時間がかかる傾向があります。

その理由は、WixやJimdoが自らドメインの直接の管理機関（レジストラ）として動いているのではなく、海外の提携レジストラ（TucowsやNetwork Solutions、Key-Systemsなど）のシステムを裏側で仲介してドメインを管理しているためです。ドメインを転出するために必要なオースコード（AuthCode / EPPコード）の発行申請を行ってから実際にコードが届くまでに数日を要したり、ドメインロック（移管制限）の解除が海外レジストラのデータベースに反映されるまでにタイムラグが生じたりします。

さらに、移管承認メールが英語や翻訳調の分かりにくい文面で届き、承認手続きが完了した後も、移管元の海外レジストラ側がドメインの送り出し（承認処理）を即座に行わず、規定の待機期間ギリギリまで保留し続けるといったケースが珍しくありません。

ドメインとサーバーの紐付き不安定によりSSL証明の完了まで7日から10日を要する現実

このように、WixやJimdoからWordPressサイトへ変更する際のドメイン移管やネームサーバー変更においては、海外レジストラと国内サーバーの間で権威DNSの切り替え情報が完全に同期するまでに、通常の何倍もの時間を要することがあります。そして、この期間中に最も深刻な影響を受けるのが、新サーバー（WordPress側）でのSSL証明書の発行です。前述の通り、新しいレンタルサーバー側でWordPressを公開し、無料SSLを設定する作業自体は数分で終わる簡単な操作です。

しかし、海外サービス側からのドメイン転出やネームサーバーの切り替えが完全に落ち着かず、インターネット上で「古いWix・Jimdoのサーバー」と「新しいWordPressのサーバー」の情報がまだら模様に行き交っている不安定な状態では、新サーバー側のSSL認証システムがドメインの紐付きを確認できず、何度申請してもSSLの発行エラーが繰り返されます。

結果として、ドメインの移管手続きやDNS変更を開始してから、ドメインと新サーバーの紐付きが完全に安定し、SSL証明書の認証が通ってエラーなくhttpsでWordPressのホームページが表示されるようになるまでに、7日から10日程度（1週間以上）を要することが過去の事例において非常に多くありました。ネット上の「最大72時間」という一般論を信じてギリギリのスケジュールを組んでいると、この7日〜10日間の空白期間に「ホームページがずっと見られない」「プライバシーエラーが消えない」というパニックに陥ることになるため、海外サービスからの移行時には、通常よりもはるかに長いバッファ（予備期間）を見込んでおくことが極めて重要です。

正常な反映と早期解決に向けたドメイン管理会社への適切なアプローチ

どれほど技術者が正しい手順でDNSレコードを設定し、一般的な浸透時間である72時間、あるいはそれ以上の時間を耐えて待ったとしても、ドメイン管理会社やサーバー会社側のシステム不具合によって設定が反映されていない場合、ただ待っているだけでは永遠に問題は解決しません。最後に、今回の事例が最終的にどのようにして解決に至ったのか、その決定的な打開策と制作会社がとるべき姿勢について解説します。

制作会社の操作権限の限界と第三者からの問い合わせが拒否される契約上の壁

今回のトラブルにおいて、削除したはずのAレコード（153.xxx.xxx.xxx）が72時間経過後も消えずに残存し続け、外部からnslookupで確認しても古い情報が返り続けるという異常事態に対し、私たちが管理画面上からできる操作はすべてやり尽くしていました。管理画面上にはすでにそのレコードは存在しないため、もう一度削除ボタンを押すことすらできません。

つまり、管理画面（フロントエンド）と実際のDNS配信サーバー（バックエンド）の連携が内部で詰まっている状態であり、これはドメイン管理会社のエンジニアが内部システムを直接操作してゾーン情報を強制更新しない限り、外部の人間にはどうすることもできない領域の問題でした。

こうした場合、すぐにでもドメイン管理会社のサポート窓口へ連絡して内部システムの調査を依頼したいところですが、ここに「契約者本人確認の壁」が立ちはだかります。ドメインやサーバーの契約名義が発注者（顧客）である場合、個人情報保護やセキュリティの規定上、契約者本人ではない制作会社（第三者）が直接サポート窓口に問い合わせを行っても、「契約者ご本人様からのお問い合わせでないため、個別のアカウント状況や設定内容に関する調査・回答はいたしかねます」と門前払いされてしまいます。

契約者本人から管理会社へ不具合確認の連絡を入れた直後に即時反映された実例

そこで私たちは、これまでの検証結果と問題点をすべて整理した上で、発注者に対して「私たちの側で操作できる部分はすべて完了しているが、管理会社内で設定が反映されない事象については外部からは対応できないため、契約者様ご自身からドメイン管理会社のサポートへ不具合がないか確認の連絡を入れていただきたい」と正式にお願いしました。

その際、専門知識のない発注者がサポート窓口に状況を正確に伝えられるよう、現在設定しているレコード内容と、nslookupで外部から参照した際に返ってくる異常なデータ（削除後72時間経過しても古いAレコードが表示される事実など）をそのままコピー＆ペーストして送れる問い合わせ用の文面を作成してお渡ししました。

また、必要であれば私たちの会社名義のメールアドレスから先方へ技術的な状況説明を行う用意があることもお伝えしました。 発注者には最初こそ大変なご心配とご不満をおかけしていたものの、この要請を受けて発注者自身からドメイン管理会社のサポート窓口へ「設定を削除したはずのレコードが反映されず不具合が起きているのではないか」と確認の連絡を入れていただきました。すると驚くべきことに、発注者が管理会社へ連絡を入れた後、これまで何日間も頑なに消えなかった古いAレコードがすぐさま消滅し、CNAMEをはじめとするDNS設定が瞬く間に正常反映され、すべてのブラウザや端末でホームページが安定して表示されるようになりました。

管理会社側が内部で滞留していたゾーン情報のキャッシュを手動でクリアしたのか、あるいはバグで止まっていた同期バッチ処理を再実行したのかは定かではありませんが、私たちが設定した内容は最初から完全に正しかったにもかかわらず、管理会社側のシステム不具合によって反映が止まっていたことが、この結末によって明確に証明されました。

トラブル発生時に制作会社が用意すべき技術的根拠と堂々とした対応姿勢

ホームページの制作や保守運用に携わる以上、どれほど万全を期していても、外部のドメイン管理会社や海外サービスのシステム不具合、あるいは通信環境の仕様によって、予期せぬ表示トラブルに巻き込まれることがあります。技術的な確信を持たない制作会社であれば、慌てて無意味な再設定を繰り返して事態を悪化させたり、曖昧な謝罪に終始して信頼を完全に失ったりしてしまいます。

このような極限の状況において最も重要なのは、感情的なやり取りに流されることなく、nslookupによる応答結果や各レコードの役割、ブラウザごとの検証結果といった揺るぎない技術的根拠をすべて正確に記録・開示することです。また、発言の食い違いや言った言わないのトラブルを防ぐため、電話での場当たり的な対応は避け、すべて正確なテキスト（メール等）で履歴を残しながら説明を尽くすことも実務上の重要な危機管理です。自分たちが実施した正確な作業内容と、管理会社側で起きている反映不全の問題点を明確に切り分けて全て開示し、制作会社として対応できる範囲と限界を誠実かつ堂々とした態度で伝え抜くことが、最終的に真実を明らかにし、問題を根本解決へと導く唯一の道となります。

DNSレコードの変更やSSLの設定、そして海外サービスからのドメイン移管において万が一長期化するトラブルに直面した際は、制作会社側のミスだけを疑うのではなく、管理会社側のシステム不具合という可能性も視野に入れ、客観的な検証データをもとに管理会社へ直接確認を入れるというアプローチをぜひ実践してみてください。

ホームページの更新・修正料金 価格表