リニューアルやサーバー移行で当日にバタつく原因は、「作業ミス」より 「決めていなかったこと」 です。
切替手順を丁寧に作り、チェックもして、時間も確保した。それでも「なぜか詰む」。制作会社側の現場だと、こういう経験が一度はあるはずです。
- 「切替したのに反映されない」（人によって見え方が違う）
- 「証明書で開けない」（一部環境だけエラーも含む）
- 「CDNで表示が古い」（直ったように見えない）
これらは、手順の問題というより「前提が未確定のまま当日を迎えた」ときに起きます。
つまり必要なのは、コマンドや作業手順以上に、「切替していいか／戻すべきか」をYes/Noで言える状態です。
制作会社のディレクター/PM（移行当日の司令塔）の仕事は、手を動かすことよりYes/Noを止めないこと。
関係者（クライアント、既存保守、インフラ、開発など）に同じ状況を共有し、判断を前に進める役割です。
この記事のゴールは、既存保守会社に確認する前に未確定を埋め、当日の判断が止まらない状態にすること。
ここで言う「確認前の整理（棚卸し）」は、DNS／証明書／CDN／戻し条件／連絡体制を、先に 「決める項目」として並べることです。
「乗り換え相談」を前面に出すのではなく、まずこの整理を進めて、確認が止まる前に早めに相談できる状態を作ります。
移行でつまずくのは手順ではなく「未確定」が残ったとき
移行当日、現場で起きていることを一言で言うと、未確定が連鎖して判断材料が揃わない です。
判断材料が揃わないと、手順があっても進められません。なぜなら、手順は「やること」を示しても、「やっていいか（GO/NG）」までは示さないからです。
移行当日に起きがちな“詰まり”を先に洗い出す
- 表示が人によって違って、確認結果が揃わない
同じURLを見ているのに、ある人は新サイト、別の人は旧サイト。
「反映されてません」「いや反映されてます」の応酬で、検証の前提が揃わず、確認が前に進まなくなります。 - 担当・権限が曖昧で、“確認待ち”が発生する
DNSは誰が変える？証明書は誰が更新？CDNのパージ権限は誰が持ってる？
「聞けば分かる」と思っていたら、当日になって「担当者が不在」「権限がない」「契約名義が異なる」ことが判明し、確認作業そのものが止まります。 - 戻す基準がなく、判断が遅れて影響が広がる
不具合が出たとき、戻すのか、粘るのか。
判断基準が決まっていないと、誰も決められず時間だけが過ぎ、関係者と対応範囲が増えていきます。
ここが腹落ちすると、やるべきことは「手順を増やす」ではなく、未確定を減らす（決め切る） ことに変わります。
次に、制作会社PMが抱えがちな詰まりを、もう少し具体に落としていきます。
制作会社の司令塔が抱えがちな「移行当日の詰まり」一覧
DNSでつまずく：反映のズレと戻しの遅れ
DNSは「正しく変更したのに、すぐ反映されない」ことが起きます。
これは手順の問題ではなく、DNSのキャッシュ（期限付きで情報が残る仕組み）上、起こり得ます。
切替直後に「見える人／旧のままの人」が混在して確認結果が揃わない（TTL）
司令塔として一番困るのがこれです。確認結果が揃わないと、関係者の不安が増え、説明コストが跳ね上がります。
「誰の画面が正しいか」を争う時間が増えるほど、切替作業より 説明と確認対応に時間が取られます。
※TTL：DNSの「キャッシュ有効期限」。例えばTTLが3600秒（1時間）だと、DNSを切り替えても一部のユーザーは最大1時間、古い情報を見続ける可能性があります。
TTLを下げ忘れて“戻しても効かない”状態になる
切替して不具合が出た。戻したい。でも戻しても反映が遅い。
こうなると「戻す／戻さない」の判断が遅れやすい状態になります。
SSLでつまずく：証明書エラーが致命傷になりやすい理由
SSL※周りの難しさは、失敗したときの影響が分かりやすく、かつユーザー側で回避できないケースがあることです。
「サイトが開けない」は、そのまま問い合わせ・クレームにつながりやすいです。
※SSL（HTTPS）：通信を暗号化する仕組み。証明書はその暗号化を成立させるための設定要素で、問題があると警告や閲覧不可につながります。
HSTS※が効いていて、証明書ミスが「ユーザーが回避できない」事故になる
「警告を無視して開く」ができない挙動に当たると、ユーザーはそこで詰みます。
つまり、検証で気づいても、ユーザー側では 「開けない」状態が発生している可能性があります。
※HSTS：「このサイトは必ずHTTPSで開く」という設定。一度設定されるとブラウザが記憶するため、証明書エラーが出ると警告を無視できなくなります。
中間証明書（チェーン）※不備で“一部環境だけ”エラーになり原因特定が遅れる
自分のPCではOKなのに、特定の端末や特定の経路だとNG。
こういう「再現性が薄い」エラーは、司令塔目線だと特に厄介です。調査が長引くほど、切替判断も戻し判断も遅れます。
※中間証明書：証明書を正しく検証するために必要な「つなぎ」の証明書。欠けていると、一部のブラウザや端末だけがエラーになることがあります。
CDNでつまずく：キャッシュが原因で「直っていない」に見える
CDNがあると、切替直後に キャッシュのせいで表示が揃わない ことがあります。
原因は単純で、キャッシュが残るからです。
※CDN（Content Delivery Network）：サイトのコピーを複数の配信拠点に置いて表示を高速化する仕組み。キャッシュが残ると、切替後も旧サイトが表示されることがあります。
キャッシュが残って「古い表示」のまま → 更新が反映されていないように見える
実際は切替できているのに、見た目が変わらない。
この瞬間に「移行失敗では？」という疑念が生まれると、焦りから確認作業が増え、判断が遅れます。
困ったら全消しパージ → オリジン負荷増で二次的な影響
「キャッシュを全消しすれば解決する」と考えたくなりますが、短期的な対処にとどまります。
アクセス規模やオリジン余力次第では、オリジン負荷が上がって「遅い／落ちる」 などの二次的な影響を誘発する可能性があります。
※パージ：CDNのキャッシュを手動で削除する操作。全消しすると、一時的にすべてのアクセスが元のサーバー（オリジン）に集中します。
切替判断でつまずく：GO/NGが決まらず意思決定が止まる
移行当日の本当の課題は「バグ」ではなく 意思決定の停止です。
止まる理由は多くの場合、「基準がない」か「役割が曖昧」のどちらかです。
成功条件（GO）と失敗条件（戻す）が曖昧で、誰も決められない
「だいたい大丈夫そう」で進めると、後から問題が顕在化して対応が長引きます。
逆に、判断基準がないまま保留が続くと、切替判断そのものができません。
司令塔／決裁者／検証担当の役割が曖昧で意思決定が止まる
司令塔が検証も承認も抱えると、判断が滞ります。
役割が分かれていないと承認の往復が増え、対応時間が増えます。
ここまで読んで「うちも起きそう」と感じたら、次のチェックリストがそのまま使えます。
「未確定」を潰すチェックリスト
このチェックリストは「作業の手順」ではありません。
移行当日に必要な Yes/Noの材料 を、事前に揃えるための質問集です。
チェックが付かない項目があれば、未確定が残っています。未確定が多いほど、当日に判断が止まりやすくなります。
順番も重要です。上から埋めるほど、当日の詰まりの芽が減ります。
1）DNS：切替方式・TTL・責任者を確定す
誰がDNSを触るか（管理者・当日作業者・承認者）
「クライアントが管理」「既存保守が管理」「制作会社が管理」のどれかを明確にします。
「当日に確認すればよい」と後回しにすると、MFA（追加認証）や名義違いで詰まることがあり、当日の作業が開始できません。
切替方式（IPを切り替える／別ドメイン参照で切り替える、段階切替の有無）
いきなり本番を切るのか、サブドメインで先行確認するのか。
切替方式が曖昧だと、当日になって方針決めから始まり、作業に入れません。
TTL計画（いつ下げる／いつ戻す）
「下げる」だけではなく、「いつから下げるか」まで決めます。
当日になってTTLを下げても、すでにキャッシュされている分はすぐには変わりません。
旧環境をどれくらい残すか（戻し先としての寿命）
「戻す」が選択肢として機能するよう、旧環境の保持期限を決めます。
旧環境を先に消すなら、戻しの代替案が必要です。
影響範囲の洗い出し（メール系DNS、外部SaaS連携など）
メール、フォーム、計測、外部連携。
この範囲が漏れると、サイト表示は問題なくても業務が止まることがあります。
2）SSL：終端・証明書の更新責任・HSTS有無を確認する
SSL終端はどこか（CDN／LB（ロードバランサー）／サーバ）
HTTPSの終端（CDN/LB/サーバ）が変わると、証明書を配置する場所も変わります。
ここが未確定だと、当日になって証明書の配置先の確認が発生し、作業が止まります。
証明書の発行・更新の責任者は誰か（自動更新か手動か）
失敗の多くは、更新責任の曖昧さから起きます。
現時点で問題がなくても、更新タイミングで不具合が表面化することがあります。
対象ドメイン範囲（www／サブドメイン／必要なドメイン全て）
wwwだけ、サブドメインだけ、両方。漏れがあると一部だけ開けません。
「対象範囲の棚卸し」は地味ですが、影響が一番分かりやすい項目です。
HSTSの有無（あるなら影響が跳ねる前提）
HSTSがあるなら、証明書ミスの影響が大きくなり得ます。
その前提で、切替判断と戻し条件を固めます。
3）SSL：証明書チェーン（中間証明書）の抜けを防ぐ
チェーンの確認方法（どのツール／どこを見るか）
「確認済み」の基準を揃えます。
ブラウザ表示だけでOKにせず、証明書チェーンの診断結果も確認対象に入れます。
旧環境／新環境で証明書チェーンが同一か（差分の芽を潰す）
旧環境では正常でも新環境で一部だけエラーになる場合、設定差分が原因のことが多いです。
同一にできない場合は、差分の理由と影響範囲を説明できる状態にします。
“一部だけエラー”が出た時の切り分け順（ブラウザ・端末・経路）
迷うと切り分けが長引くため、順番を決めます。
例：端末差 → 経路差 → 証明書チェーン → CDN/終端…の順で潰す。
4）CDN：キャッシュとパージ方針を先に決める
CDNの有無（意図せず挟まっていないか含む）
以前の施策で入れたCDN/WAFが残っていることがあります。
「誰も知らない中間レイヤー」があると、当日の原因特定が難しくなります。
※WAF（Web Application Firewall）：サイトを攻撃から守るセキュリティ機能。設定によってはアクセスをブロックすることもあります。
パージ対象の決め方（全消し前提にしない）
どのURLを消すか、どこまで消すか。
ルールがないと、全消しが判断のデフォルトになりがちです。
切替直後の「表示差分が出る前提」を関係者に共有する
ここは期待値調整です。
先に「切替直後は表示が混在し得る」と共有しておくと、不要な誤解や疑念が生まれにくくなります。
全消しパージを使う条件（アクセス規模・オリジン余力・代替手段）
条件化しないと、判断が場当たり的になります。
実施する場合は、いつ実施するか／どの条件で実施するか／代替がない場合に限るかまで明確にします。
5）切替判断：成功条件（GO）と判断体制を揃える
成功条件（3〜10個に絞る）
何でも確認しようとすると、確認が分散して要点が押さえられません。
停止すると影響が大きい機能に絞ります（トップ、主要導線、フォーム、決済、ログイン、管理画面など）。
検証担当・承認者・司令塔の分離
司令塔が検証で詰まると、全体が止まります。
役割を分け、司令塔は判断の交通整理に集中します。
監視・ログ確認の“見る場所”を決める（誰が何を見るか）
監視は「ある/ない」ではなく「誰がどこを見るか」。
見る場所が決まっていないと、当日にログや監視画面の所在確認が発生します。
6）ロールバック：戻す条件と手順を1枚にする
ここだけは、あえて「1枚」にする価値があります。
理由としては、戻す判断は短時間で決める必要があるからです。
戻す条件（症状／影響／時間で定義）
「何分以内に復旧しなければ戻す」
「決済が通らないなら即戻す」
のように、判断を数値や事実に寄せます。
戻し手順を1ページ化（DNS/CDN/SSL/LBまで含める）
戻しはDNSだけでは済まず、CDNや証明書、LBの戻しも必要になる場合があります。
戻す経路と手順を、司令塔が迷わない形にしておきます。
戻した後に失われる可能性があるもの（投稿・注文・問い合わせ等）
戻しで欠損し得るデータを把握し、関係者への連絡方針と対応方針まで決めます。
7）体制・連絡：役割分担と連絡網を先に固定する
当日のチャネルを一本化（Backlog／Slack／Teams等）
連絡が散ると、司令塔が情報の取りまとめに追われます。
決定事項を記録する場所を一つにします。
指揮系統（最終決裁者／エスカレーション先）
誰が最終判断するか。
ここが曖昧だと、GO/NGが止まります。
外部連絡先（既存保守、ホスティング、CDN、ドメイン管理者）
連絡先が分かっているだけでは、当日の運用には足りません。
「何が起きたら誰に」「何を依頼するか」までセットで用意し、当日に迷わず依頼できる状態にします。
まとめ：移行当日の混乱を減らすために、先に決め切る
多くのケースで原因は、技術力不足というよりDNS・SSL・CDNの未確定が残っていることです。
未確定を先に潰せば、司令塔の仕事は「調整地獄」から「判断の交通整理」になります。
逆に、未確定が残ったままだと、作業がうまくいっていても判断停止で詰まります。
チェックリストで「未確定」が残ったときの次の一手
- 未確定が 3つ以上 残るなら、当日リスクが高いサイン
- その状態で既存保守会社に確認しても、質問が曖昧 → 回答も曖昧 → 決まらない、になりやすい
- まずやるべきは「手順作り」ではなく、未確定項目を埋めて質問を具体化することです
コーポレートサイトをクラウドでセキュアに
サーバー管理
クロジカガイドブック
- コーポレートサイト構築・運用の課題を解決
- クロジカサーバー管理の主な機能
- 導入事例
- 導入までの流れ
