本番・検証・旧ドメインの入れ替えの状況を固定する
新ドメイン公開時に、旧本番サイトとステージング環境もまだ稼働しています。 この場面を「本番・検証・旧ドメインの入れ替え」として扱います。変更前に、現在有効なURL、権限、認証情報、所有者を記録します。新旧を同時に動かす期間があるなら終了条件も必要です。
具体例は、新サイトを月曜に確認、DNSを水曜に切替、旧本番を金曜まで読み取り専用にし、確認後に許可URLを新本番へ置き換えるという状況です。申請、確認、切替、旧状態の失効を時系列にすると、技術作業が終わったのに契約や権限だけ残るずれを発見できます。
本番・検証・旧ドメインの入れ替えを証拠と数字で判断する
確認材料は、旧本番、新本番、検証環境、DNS切替時刻、AI通信の疎通、注文・問い合わせ、旧URLの失効です。新しい状態が動くことと古い状態が使えないことを別々に試し、両方の証跡がそろって初めて入れ替え完了にします。
判断境界は、Unlimitedでも正式ホスト名の管理は必要とし、staging・.local・.testの契約上の扱いは現行条件を確認して記録することです。例外的な一時併用には期限と承認者を付け、期限を過ぎた登録を自動的に次回監査へ出します。
- 旧本番、新本番、検証環境、DNS切替時刻、AI通信の疎通、注文・問い合わせ、旧URLの失効
- Unlimitedでも正式ホスト名の管理は必要とし、staging・.local・.testの契約上の扱いは現行条件を確認して記録する
- 旧URL・旧権限・旧認証情報が実際に無効になったか
本番・検証・旧ドメインの入れ替えで避けるべき失敗と実行順
よくある失敗は、新ドメインを先に登録したまま旧本番を無期限に残し、どちらが顧客データを扱う正式環境か不明にすることです。短時間で安心を得られる行動ほど、影響範囲を広げたり、比較可能な状態を壊したりします。元に戻せる単位まで操作を小さくし、実施前後で顧客影響と費用の両方を確認します。
実行順は、移行対象を列挙する、新本番を検証する、切替を承認する、許可URLを入れ替える、旧本番を失効確認するです。各工程に実施者、承認者、期待する結果、失敗した場合の戻し方を付けます。途中で前提が変わった場合は、残りのチェックを惰性で進めず、その時点の事実から順番を組み直します。
本番URL切替・失効チェック票を運用へ組み込む
Agencyは正規化済み本番ホスト名10件まで、Unlimitedは管理ホスト名数の上限なしというライセンス範囲を前提にします。無制限はAI利用量やプロバイダー費用まで無制限という意味ではなく、自社および管理顧客サイトという利用条件も別に確認します。 「本番・検証・旧ドメインの入れ替え」に適用する範囲を「本番URL切替・失効チェック票」の冒頭に書いておくと、記事で扱う保護・費用・契約・法令の境界を実際の運用で取り違えません。
複数サイトでは設定値の統一より、変更受付、承認、反映、旧状態の失効を同じ手順で追えることが重要です。会社名、本番ホスト名、責任者、契約状態を一元管理画面の正本にします。 完成した「本番URL切替・失効チェック票」は、チェック票はDNS、WordPress、ライセンスの三担当が共有し、各自の完了だけで全体完了にしないために使います。作成して保管するだけでなく、次回確認日、更新責任者、参照する正本を決めて日々の作業へ組み込みます。
ドメイン切替後に、旧サイトの有料処理経路まで閉じる
新ドメインでページが表示できても、旧システムが止まった証明にはなりません。Webhookの送信先、定期実行のコールバック、DNSレコード、プロバイダーの認証情報が、廃止したWordPressへ処理を送り続けることがあります。新しい顧客導線の受け入れが完了し、旧経路から有料処理を開始できなくなるまでは、新旧二つのシステムが動いているものとして扱います。
切替7日前に、機能を起動できる入口と送信先を棚卸しします。対象はWebhook URL、Cronのコールバック、DNS、登録済み本番ホスト名、プロバイダーキーの所有者、各項目を失効できる担当者です。名称に旧ドメインが含まれるという理由だけで共有キーを失効せず、他の本番経路で使っていないことを先に確認します。
新経路の機能試験に合格し、旧エンドポイントがコールバックを受け付けず、合意した観測期間で旧経路に帰属するプロバイダー利用量が0になった時点で移行完了とします。1時間後と24時間後の証拠を切替記録へ添付しておけば、後日届く請求とも照合できます。
| 時点 | 実施内容 | 残す証拠 | 合格条件 |
|---|---|---|---|
| T−7日 | 新旧URL、コールバック、DNS、Activation Code、キー、担当者を一覧化 | 日付入り棚卸表とキー所有者の記録 | すべての処理起点に担当者がいる |
| T0 | 新経路を受け入れ、ライセンス対象ホスト名を入れ替えて切替を記録 | 成功したリクエストID、応答、承認者、入れ替えイベント | 新経路が動き、入れ替えにより旧Activation Codeが失効している |
| T+1時間 | 旧エンドポイントが処理を受け付けないことを確認 | 旧URLの試験結果とサーバーまたはプロバイダーのログ | 旧経路で有料処理が始まらない |
| T+24時間 | 新旧経路別にプロバイダー利用量を照合 | 合意した期間の利用量出力 | 旧経路に帰属する利用量が0 |
| 完了 | 旧コールバックやプロバイダーの専用認証情報を失効 | 失効イベント、担当者、実施日 | 以前の認証情報では有料処理を開始できない |
本番・検証・旧ドメインの入れ替えを次の改善につなげる
確認順序とステージングの契約上の扱いを決め、切替完了後に旧本番サイトを無効化します。 ただし、実施したという事実だけでは完了ではありません。期待した結果、顧客への影響、残った不確実性、元に戻したかどうかまで確認し、例外には期限と責任者を付けます。
この課題の結論は、本番・検証・旧ドメインの入れ替えを一度の勘や一括操作で処理せず、証拠、判断境界、実行順、完了条件を一つの記録につなぐことです。最後に「旧URL・旧権限・旧認証情報が実際に無効になったか」を確認し、答えが曖昧なら「本番URL切替・失効チェック票」の未完了欄として次の担当者へ渡してください。
「本番・ステージング・ドメイン移行を混乱させない入れ替え手順」の運用判断を、いきなり全顧客へ展開しないでください。まず1つのWordPressサイトへAI Cost Guardrails-CNXTを無料でダウンロード・導入し、「本番URL切替・失効チェック票」を再現できると確認してからAgency・Unlimitedを検討できます。