公開直前の最終確認 — ざっくり確認で済むのが理想、ただし 5 重大リスク領域は確実に

第 8 章のスタートです。 ここまでで企画・制作・集客の話を扱ってきました。 本章は「サイトが公開されてから、運用フェーズに入るまで」を扱います。 最初に置くのは公開直前の話で、最終確認の場としての公開直前を、どう設計するかが論点になります。 本記事の核は 「公開直前は本来ざっくり確認で済むのが理想」 という捉え方と、ただし 「ざっくり = 省略」ではない 5 重大リスク領域の扱いです。

1. 公開直前は「最終確認の場」、新しい作業の場ではない

1-1. 制作・修正・追加は公開直前の数日前までに止める

公開直前(前日・前々日)に新規制作や大幅修正を入れると、確認時間が削られて事故率が跳ね上がります。 プロジェクトの後半工程では「いつ作業終了で、いつから確認モードに切り替えるか」をスケジュールで明示しておきます。

1-2. 直前に新しい作業を持ち込むほど、事故リスクが一気に高まる

• 新規追加で他要素との整合が崩れる
• 修正後の検証時間が足りない
• 関係者の確認が追いつかない
• 業者の納品手順との整合が取れない

1-3. Lesson 5-6「公開前チェックで『要素の変更』を始めるのがよくある失敗」の延長線

第 5 章で扱った「公開前の要素変更」が、本記事の出発点です。 要素変更を止めた上で、公開直前は「最終確認」に集中するという捉え方が、本章の基本姿勢になります。

1-4. 「直前にチェックがざっくり確認で済む状態」が、プロジェクトが健全だった証

本記事の中心メッセージです。 各工程で順次チェックされていれば、直前は本当に大事なポイントだけを念入りに、それ以外はざっくりで済みます。 「直前で全部見直さないと不安」というのは、プロセスがどこかで崩れているサインで、本来は前工程に戻って原因究明すべきです。

2. 最優先 ① — 古い版が本番に戻る「データの先祖返り」チェック

ここでいう データの先祖返り とは、最終確認した版より古いファイルや設定が、本番に戻ってしまう事故のことです。

2-1. 公開時に何が上書きされ、何が消えるのかを明確にする

• 本番公開ディレクトリにアップロードするファイル一覧
• 既存ファイルとの差分(新規 / 更新 / 削除)
• DB の更新内容、上書きされるレコード
• 残るデータ(ユーザー入力データ・解析データ・問い合わせ履歴)

2-2. 業者のサーバ作業で「古い版が公開ディレクトリに上がる」事故は、現場で本当に起きる

制作の最終版が確定した後、業者のローカル環境で古い版が混ざる、誤ったファイルがアップロードされる、ステージング版が本番に上がる、といった事故が現場では珍しくありません。 担当者側のチェックで気付くしかない事故が、これに該当します。

2-3. 公開前に「最終版のファイル一覧」を担当者がスナップショットで持っておく

• 最終確認した版のファイル一覧(更新日時・サイズ・チェックサム〈ファイルの同一性を確認する値〉)
• 主要ページのスクリーンショット
• 主要 HTML のソースコード保管

2-4. 公開直後に同じスナップショットと照合して、上がった内容が想定通りかを確認する

本番に上がった内容を、確認した最終版と照合します。 差分があれば、業者にすぐ確認。 特に CMS(WordPress など、管理画面からページを更新する仕組み)の場合は 下書きと公開状態の取り違え も多いので、ページ単位の公開状態を一覧で確認します。

3. ステージング環境の活用 — テスト環境と本番環境の橋渡し

3-1. 開発時のテスト環境とは別に、本番に近いステージング環境を用意

• ローカル環境:制作中の作業環境(担当者は見られないことも)
• 制作会社の検証用環境:制作会社内での確認用
• ステージング環境(本番公開前に、本番に近い条件で確認する検証環境):本番に近い構成(URL・SSL・サーバ・DB を本番相当に)

3-2. ステージング環境で「公開時に上げるデータ」をそのまま流して、本番と同じ挙動を確認

本番にアップする予定のデータを、ステージングに先にアップして挙動を確認します。 ここで問題が出れば本番に上げる前に直せる、これがステージングの最大の価値です。

3-3. SSL・リダイレクト・解析タグ・フォーム送信先など、本番でしか確認できないものも事前に試せる

• SSL 証明書の適用(Lesson 1-4 のサブドメイン SSL 注意)
• 301 リダイレクト(リニューアル時の旧 URL → 新 URL)
• 解析タグ・広告タグの発火
• フォーム送信先のメールアドレス

3-4. 小規模案件でステージングがない場合は、公開直前に本番の別ディレクトリで一時公開する方法もある

• 本番サーバの別ディレクトリ(例:/preview/)で先行公開
• Basic 認証(ID・パスワードで閲覧を制限する簡易認証)や noindex(検索結果に出さない設定)で外部から見えないように
• 動作確認後、本番ディレクトリへ移動

3-5. 「上げるデータと、上がった時にどうなるのか」を事前に明確化できる環境を持つこと自体が、担当者の打ち手

ステージング環境を 業者契約の段階で要求 しておきます。 「直前で確認します」ではなく、「ステージングで先に確認します」と仕組みで支える。 これが担当者の重要な打ち手です。

4. 最優先 ② — CV 直結部分の念入り確認

CV(コンバージョン。問い合わせ・購入など、成果につながる行動)に直結する部分は、担当者が自分の手で確かめます。

4-1. 問い合わせフォーム — 送信が通る、メールが届く、サンクスページに遷移、エラー時の挙動

• 全項目を入力して送信、確認画面 → 完了画面の遷移
• 担当者宛メールが届く、自動返信メールが申込者に届く
• 必須項目のバリデーション(入力内容のチェック)、エラー時の表示
• 送信先メールアドレスが本番のものになっている(テスト用のままになっていないか)

4-2. フォームの送信先 — 担当者宛・自動返信・スレッド管理ツール連携が想定通りか

• 担当者宛の通知先(複数なら全員に届くか)
• 自動返信のフォーマットと文言
• スレッド管理ツール(Slack / Chatwork / CRM〈顧客管理〉)への連携
• 営業ステータス管理ツールとの連携(SFA〈営業支援〉・MA〈マーケティング自動化〉)

4-3. CV ボタン・リンクのリンク先と動作 — 全 CV 経路を担当者が手で踏む

トップから CV まで、想定される全ての経路を担当者自身が手で踏みます。 スマホ・PC・主要ブラウザの全て。 ここは業者に任せず、担当者自身がやる領域です。

4-4. EC・予約系の場合 — 決済テスト、在庫連携、注文完了メール、キャンセル処理

• テスト決済(各決済手段で 1 回ずつ)
• 在庫システムとの連携(在庫減算、在庫切れ時の挙動)
• 注文完了メール、配送通知メール
• キャンセル・返金処理

4-5. 電話 CV の場合 — タップで発信できるか、表示電話番号と転送先の整合

• スマホからのワンタップ発信
• 表示の電話番号が古い番号のままになっていないか
• 転送先・受電者の体制
• 営業時間外の留守電メッセージ

4-6. CV 計測タグが正しく発火するか、テストイベントで確認

• GA4 の CV イベント
• Google 広告のコンバージョン計測
• Meta ピクセル
• テストモードで発火するか、本番タグへの差し替え忘れがないか

5. 「ざっくり」でも必ず確認する 5 重大リスク領域

「ざっくり確認で済むのが理想」(H2-1)は 目視で「問題なし」が確定できる効率的なチェック のことです。「ざっくり = 省略」ではありません。Lesson 5-6 で扱った 5 重大リスク領域(個人情報・法定表示・セキュリティ・noindex・計測タグ)は、ざっくりでも 確実に確認 しておきたいところです。一見問題なく見えても、確認しないと致命傷になりかねません。

5-1. 重大リスク領域 5 つ(Lesson 5-6 完全連動)

• 個人情報：フォーム送信先・問い合わせ受信メールアドレス・プライバシーポリシーリンク・Cookie 同意 UI の動作
• 法定表示：特定商取引法表記(EC)、業種別必須表示(金融商品取引法 / 宅建業法 / 薬機法 等)、運営会社情報、表記場所と最新性
• セキュリティ：SSL/TLS(通信を暗号化して HTTPS 表示にする仕組み。全ページ HTTPS か)、サブドメイン SSL(Lesson 1-4 連動)、フォームの XSS〈不正なスクリプトを埋め込まれる攻撃〉/ CSRF〈意図しない送信操作をさせられる攻撃〉/ Bot 対策、管理画面の認証強度
• noindex / robots.txt(検索エンジンの巡回ルールを伝えるファイル)：ステージングの noindex を本番で外し忘れる事故(SEO 致命傷)、テストページの除外漏れ、サイトマップ整合
• 計測タグ：GTM(タグをまとめて管理する仕組み)・GA4(Google の無料アクセス解析)・広告タグ(Google 広告 / Meta / Yahoo)、コンバージョン計測、本番タグと開発タグの混在事故、サンクスページ(送信完了ページ)の CV タグ

5-2. なぜ「ざっくりでも確実に確認」が必要か

これら 5 領域は 「目視で問題なし」までの確認はざっくりでよい(=効率的に確認できる)、ただし「確認しない」と致命傷になりかねません。

• noindex 戻し忘れ → SEO で数ヶ月圏外
• 特商法表記不備 → 景表法・特商法違反、行政指導
• GA4 タグ実装ミス → 数ヶ月後にデータ欠損が判明、判断材料が消える
• SSL 設定漏れ → ブラウザの「保護されていない通信」警告で離脱率急増

一見問題なく公開できても、1〜3 ヶ月後に致命傷として露呈する タイプのリスクです。

5-3. 業者から「確認書」を受け取って記録に残す

• 業者から「タグ実装完了報告書」「セキュリティ・SSL 確認書」「noindex 除外確認書」を必ず受け取る(Lesson 5-6 と整合)
• 担当者が承認したという記録を残す(Lesson 5-6「最終承認者の全体責任」と整合)
• 公開後に何かあったときの根拠

5-4. 中小企業ほど油断する領域

• noindex の戻し忘れ、特商法表記の文言ミス、GA4 二重計測は中小企業の頻発インシデント
• 「業者がやってくれているはず」「公開できているから大丈夫」が罠
• 公開前チェックリストに必ず組み込む

6. 公開直前の「真にざっくり」で済ませて良いもの

以下は 真にざっくりで済む 項目です。H2-5 で挙げた 5 重大リスク領域とは別物として扱います。

6-1. 文字校正

• 公開直前の全文校正は前工程の問題、目立つ箇所のみざっくり
• 本来は制作中に複数回チェック済みであるべき
• 直前で全文校正が必要なら、前工程の品質を見直す

6-2. 表示崩れ

• 主要ブラウザ × デバイスで代表ページを通しで確認
• 細部の崩れは公開後に修正可能、致命的なもの(レイアウト全壊)だけ見る

6-3. 細部のデザイン微調整

色のトーン・余白・フォントサイズの微調整は、公開後でリカバリ可能です。 直前で手を入れると別の事故を呼ぶので、原則ストップします。

6-4. SEO 設定(meta / OGP / 構造化データ)の細部

• OGP(SNS でシェアされたときの表示設定)や構造化データの細部は、公開後の修正で対応可能
• 致命傷にならない範囲は許容
• ただし noindex / robots.txt / canonical(正規 URL を検索エンジンに伝える設定)は H2-5 の重大リスク領域

6-5. 「ざっくり確認」で済ませて良い理由は、ここまでに段階的にチェック済みだから

制作工程・修正工程・検証工程で順次チェックされていれば、直前は最後の念押しで十分です。 ざっくりで済むこと自体が、プロジェクト全体の品質の証になります。

7. 担当者によくある失敗 ① — 業者だけに確認させて承認責任を放棄する

7-1. 「業者がチェックしました」を素通りで承認していないか

業者のチェック結果をそのまま信用して、担当者は確認せずに承認の判子を押す。 これが 承認責任の放棄 につながってしまいます。 業者を信頼することと、自分で確認しないことは別の話だからです。

7-2. 担当者が承認して公開されたデータは、担当者が認めたデータ

承認の判子を押した瞬間、それは担当者が認めたデータになります。 業者の手によるミスでも、担当者の責任が発生します。 だから自分の目を通すチェックが必然になるのです。

7-3. 「業者のミスです」と言いたくなる場面ほど、承認した担当者にも責任が及ぶ

社内・社外への説明責任は、承認者が引き受けるしかありません。 「業者のミス」と言いたくなるほど、自分が確認しなかったツケが回ってきます。

7-4. 承認には責任が伴うからこそ、自分の目を通すチェックが必然になる

本書を通底する「承認には責任が伴う」の考え方です。 Lesson 5-6「最終承認者の全体責任」と整合します。 Lesson 7-1 のリスク領域 2「炎上時の権限」とも同型の論点です。

8. 担当者によくある失敗 ② — 致命的な誤りでも公開日を動かさず直前修正する

8-1. 公開直前で重大な不具合が見つかった時、まず考えるのは「公開日を動かす選択肢」

重大な不具合 = 全 CV 経路が動かない、法定表示が完全に抜けている、データ先祖返りで一部ページが消える、など。 こうした場合、まず考えるのは 「公開日を動かせるか」 です。 直前修正は二次被害を呼ぶので、選択肢として優先度を下げます。

8-2. 公開日を動かす不利益 < 不完全なまま公開する不利益、のケースは想像より多い

• 関係者周知の調整(1〜2 日の延期は意外と調整できる)
• プレスリリースの再調整
• 広告・SNS の出稿タイミング調整
• これらの調整コスト vs 不完全公開の信用リスクを冷静に比較

8-3. 直前修正は「修正による事故」「修正後の検証不足」で二次被害が出やすい

修正によって別の部分が壊れる、検証時間が足りなくて確認漏れが出る、これが直前修正の典型的な二次被害です。 時間に追われた状態で修正すると、新しい不具合を生みやすくなります。

8-4. 関係者周知や告知は調整できる、サイトの信頼は一度失うと取り戻しにくい

• 事情を説明すれば、告知や関係者への周知は調整できる余地がある
• サイトの信頼は一度失うと取り戻しに数ヶ月かかる
• 不完全公開の代償の方が、調整コストよりはるかに重い

8-5. 「公開日を動かす判断」は経営層も含めた合意で行う、担当者が一人で抱え込まない

公開日の延期は、経営層・営業・関係者を巻き込む大きな判断です。 担当者が一人で抱え込まず、致命的不具合を見つけたら、同時に上長・経営層へエスカレーション(上長や経営層へ判断を上げること)します。 判断は組織で、ただし提案は担当者から、という構図です。

延期を検討する目安 は、全 CV 経路の停止・法定表示の重大な欠落・noindex や本番タグの重大な設定ミス・個人情報に関わる誤送信 など、公開後に利用者や売上へ直接影響する不具合です。

9. 担当者主導のチェックフロー — 段取りと役割分担

9-1. 1 週間前 — 業者にチェックリストを共有、ステージング環境で初回確認

• 業者用チェックリスト(技術系・タグ・セキュリティ)
• 担当者用チェックリスト(コンテンツ・CV 導線・データ整合)
• ステージング環境での通し確認

9-2. 3 日前 — CV 導線・データ整合・公開手順を担当者が手で踏む

• CV 導線の全経路を担当者が踏む(H2-4)
• データ先祖返りチェック(H2-2)
• 業者のサーバ作業手順書を確認
• 緊急時の対応フロー再確認

9-3. 前日 — 公開直前の最終確認、関係者への公開時刻周知、緊急連絡網の確認

• 5 重大リスク領域のざっくり確認(H2-5)
• 関係者への公開時刻と作業フローの周知
• 緊急連絡網と意思決定者の在席確認
• 公開後 24 時間の対応体制

9-4. 公開当日 — 公開作業立ち合い、公開直後の動作確認、CV 計測の発火確認

• 公開作業立ち合い(または事後即時確認)
• 主要ページの通し確認
• CV 計測の発火確認(テスト送信)
• SSL・リダイレクトの動作確認

9-5. 公開後 2 時間 / 当日 / 翌日 — 段階的に確認、問題があれば即対応

• 公開後 2 時間:緊急対応モード、即時の不具合への対応
• 公開当日:継続的に主要指標を観察
• 翌日:初動の振り返り、Lesson 8-2 の運用フェーズへの移行

10. 公開後の運用準備は別物(Lesson 8-2 への橋渡し)

• 公開直前の段階で「公開後の運用準備」まで一緒に固めようとすると、両方とも中途半端になる
• 公開後の初期運用(問い合わせ対応・解析・初期改善)は、Lesson 8-2 で別軸として扱う
• 公開直前は「公開を成功させる」、公開後は「軌道に乗せる」、フェーズを分けて考える

公開直前というと、つい「最後に全部見直さなきゃ」と気負ってしまいがちです。 でも本来は、ここまで一つずつ丁寧に進めてきた工程があれば、直前はざっくり確認で十分なはず。 大事なのは、データの先祖返りと CV 導線、そして 5 重大リスク領域という「外せないところ」だけを、落ち着いて確実に押さえることです。 その優先順位さえ自分の中にあれば、公開当日も慌てずに済みます。 肩の力を抜いて、一つずつ確かめていきましょう。