リリースの事故は、難しい技術ではなく「確認したつもり」から起きます。プロジェクトに合わせて削ったり足したりしながら、毎回の出発前点検として使ってください。

✅機能・品質の最終確認

「動くはず」を「動いた」に変えるパート。

主要シナリオが本番相当の環境で通るローカルで動いても本番構成で動くとは限らない。ステージングで通しで確認。

回帰テストを実施した今回の変更で、既存の機能が壊れていないか。影響範囲の周辺は特に。

異常系（エラー時の挙動）を確認した通信断・入力ミス・権限なしなど、失敗したときに壊れないか。

対応ブラウザ・端末で表示を確認したSafari / Android / 実機の小さい画面でのレイアウト崩れ。

文言・リンク・画像の差し替え漏れがない「サンプルテキスト」「test@example.com」「ダミー画像」の残り。

キーボード操作・文字コントラストを確認したマウスなしで操作できるか、色のコントラストが薄すぎないか（アクセシビリティ）。

空・最大・極端なデータでも表示が崩れない0件のエンプティ表示、長文・大量件数でのレイアウト崩れ。

🛠️リリースの段取り

「誰が・いつ・どう戻すか」を出す前に決めておく。

リリース日時・担当・連絡経路が共有されているいつ出して、何かあったら誰に連絡するか。

ロールバック手順が用意され、誰が戻すか決まっている出す前に決める。問題が起きてから考えるのでは遅い。

DBマイグレーションの順番・後戻り可否を確認一度流すと戻せない変更がないか。バックアップは取れているか。

環境変数・APIキー・シークレットが本番用になっているテスト用のキーのまま公開、は典型的な事故。

外部サービス（決済・メール等）が本番設定になっているサンドボックスのまま、Webhook先がテスト向き、を防ぐ。

🔐セキュリティ・データ保護

出してから気づくと、取り返しがつきにくいパート。

全ページが HTTPS で配信されるhttp でアクセスしたら https へリダイレクトされるか。混在コンテンツがないか。

パスワード・トークン・個人情報をログに出していないデバッグ用の console.log やサーバーログに機密が残っていないか。

認証・権限の境界を本番でも確認したURL直打ち・API直叩きで、権限のないデータが見えてしまわないか。

バックアップ・復旧手順が用意されているデータが壊れたとき、いつの時点まで・どう戻せるか。

依存パッケージの既知の脆弱性を確認した古いライブラリのまま公開していないか。監査コマンドで確認。

個人情報の取り扱いとプライバシーポリシーが整合している新しく集める情報が、ポリシーの記載と矛盾していないか。

🌐公開まわり（Web）

検索・SNS・解析まわりの取りこぼし防止。

noindex の外し忘れがないテスト中に付けた検索除外を外し忘れ → 公開したのに検索に出ない、を防ぐ。最重要級。

旧URLからのリダイレクトを設定したURL構成を変えたとき、古いリンク・検索流入を切らさない。

sitemap.xml / robots.txt を更新した新規ページの追加・クロール許可。更新後はSearch Consoleに送信。

OGP・メタ情報・favicon を確認したSNSシェア時のタイトル・画像が正しく出るか。

アクセス解析（GA等）が本番で動いている計測タグが入っているか、本番のIDになっているか。

📡公開後の確認

出して終わりじゃない。出した直後が一番危ない。

本番で主要動線をスモークテストしたログイン・購入・送信など、お金と信用に直結する動線を実際に1回触る。

エラーログ・監視ダッシュボードを確認した公開直後にエラーが急増していないか。

表示速度・初回ロードに問題がない本番のデータ量・アクセスで重くなっていないか。

障害時の連絡先・問い合わせが機能しているいざという時の受け皿が動くか。

しばらく様子を見る人を決めておく特に金曜・連休前は、誰も見ていない時間に問題が育つ。

リリース前チェックリスト