2026年5月30日

Webサイト公開前の監視設定チェックリスト|制作会社が纏めるべき8項目

公開前チェック 死活監視 制作会社 SSL

「サイトを公開したら終わり」は危険な思い込み

Webサイトの納品日、制作会社のチームは達成感で満たされますが、「本番公開後5分でダウン」「SSL証明書が期限切れで初日からブラウザ警告」といったトラブルが起きることも珍しくありません。公開前の監視設定を一つひとつ確認しておけば、その多くは防げます。

このチェックリストは、制作会社がクライアントサイトを本番公開する前に確認すべき8つの監視設定項目をまとめたものです。プロジェクトの完了チェックリストにそのまま組み込んでご活用ください。

公開前チェックリスト(8項目)

✅ 1. HTTP死活監視の設定

最優先事項です。URLを登録して1〜3分間隔での死活確認を開始します。公開直後のサーバー設定ミスやキャッシュ問題をリアルタイムで検知できます。

# Miterl APIでHTTPモニターを作成する
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - 本番サイト",
    "url": "https://client-site.example.com",
    "type": "http",
    "interval_seconds": 180,
    "alert_contact_ids": [1, 2]
  }'

alert_contact_ids はダッシュボードで作成した通知先のIDです。GET /api/v1/alert-contacts で一覧取得できます。

  • HTTPモニターを作成済み(チェック間隔 1〜3分)
  • アラート通知先(Slack・メール等)を設定済み
  • テストアラートで通知が届くことを確認済み

✅ 2. SSL証明書監視の設定

公開と同時にSSL監視を有効にします。Let's Encryptの自動更新が設定されていても、サーバー移行やDNS変更後に失敗するケースがあります。30日前アラートで猶予を持って対応できます。

# SSL証明書監視モニターを作成する
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - SSL",
    "url": "https://client-site.example.com",
    "type": "ssl",
    "interval_seconds": 86400,
    "ssl_expiry_alert_days": 30
  }'
  • SSLモニターを作成済み(ssl_expiry_alert_days: 30
  • 証明書が正しく発行されていることをブラウザで確認済み(鍵マーク表示)
  • HTTPからHTTPSへのリダイレクトが正常に動作することを確認済み

SSL証明書の管理運用については「SSL証明書の期限切れ事故を防ぐ!自動監視で安全なサイト運用を」も参考にしてください。

✅ 3. DNS監視の設定

特にドメイン管理を代行している場合は必須です。DNS設定が意図せず変更された場合や、ネームサーバー移行後のレコードミスを早期に検知できます。

# DNS監視モニターを作成する
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "クライアントA - DNS",
    "url": "client-site.example.com",
    "type": "dns",
    "interval_seconds": 3600,
    "alert_contact_ids": [1]
  }'
  • DNSモニターを作成済み(チェック間隔 1時間)
  • Aレコード・CNAMEが正しいIPアドレスを指していることを確認済み
  • DNS伝播が完了していることを確認済み(whatsmydns.net等で確認)

✅ 4. TTL(Time To Live)の最適化

公開直前は大きなDNS変更が発生しやすいタイミングです。TTLが長い状態で設定ミスが起きると、修正が反映されるまで数時間かかります。

# 公開前の推奨TTL設定例(Cloudflare等のDNS管理画面で設定)
# 公開1週間前〜公開当日: 低いTTL(300秒)に変更
# 公開後1週間で問題なければ: 標準TTL(3600秒)に戻す
A    client-site.example.com    300    IN    192.0.2.1

# 公開が安定したら通常値に戻す
A    client-site.example.com    3600   IN    192.0.2.1
  • DNS移管・変更が完了する2〜3日前にTTLを短くした(300秒推奨)
  • 公開後1〜2週間の安定確認後にTTLを通常値に戻す予定がある

✅ 5. Heartbeat(ハートビート)監視の設定

定期バッチ・SSL自動更新・バックアップスクリプトが「動いているはずなのに動いていない」という状況を検知するための監視です。スクリプト実行後にMiterlのHeatbeatエンドポイントにPINGを送ることで、正常実行を確認できます。

# バックアップスクリプト実行後にHeatbeatを通知する例(cron)
0 3 * * * /path/to/backup.sh && \
  curl -s https://miterl.com/api/v1/monitors/YOUR_HEARTBEAT_MONITOR_ID/heartbeat \
    -H "Authorization: Bearer YOUR_API_KEY" > /dev/null

Heartbeatモニターはダッシュボードの「+ モニターを追加」でタイプ heartbeat を選択して作成します。一定時間PINGがなければアラートを発報します。

  • SSL自動更新スクリプトにHeartbeat通知を追加済み
  • バックアップスクリプトにHeartbeat通知を追加済み
  • Heartbeatモニターのタイムアウト(期待間隔)を適切に設定済み

✅ 6. クライアント向けステータスページの公開

公開日からクライアントが稼働状況を自分で確認できる環境を用意しておくと、些細な問い合わせが減ります。Standard プラン以上ではホワイトラベル対応(独自ドメイン・Powered by非表示)で提供できます。

  • ステータスページを作成し、公開設定済み
  • クライアントにステータスページのURLを共有済み
  • 独自ドメイン(status.クライアントドメイン.co.jp)のCNAMEが設定済み(Standard以上)

ステータスページの運用方法は「クライアント向けステータスページの活用法」で詳しく解説しています。

✅ 7. アラート通知チャンネルと担当者の確認

公開直後のトラブルは深夜・休日に起きることもあります。誰がアラートを受信して、誰が初動対応を行うかを事前に決めておきましょう。

# 設定済みのアラート連絡先一覧を確認する
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, name, type}'
  • Slackの通知チャンネルに関係者が参加済み
  • メール通知先がアクティブなアドレスであることを確認済み
  • 深夜・休日の緊急連絡先(LINE・SMS等)を設定済み(高重要度サイトのみ)
  • オンコール担当者のローテーションを決めてある

✅ 8. Bing Webmaster Tools・Googleサーチコンソールへのサイトマップ送信

監視とは少し異なりますが、公開直後のSEO観点での必須確認事項です。サイトマップを各サーチエンジンに送信しておくことで、クロールと初期インデックスを早期に確保できます。

  • sitemap.xml が正しく生成・公開されていることを確認済み
  • Google Search Console でサイトマップを送信済み
  • Bing Webmaster Tools でサイトマップを送信済み
  • robots.txt が正しく設定されていて、重要なページをブロックしていないことを確認済み

公開後の初動確認(公開後24時間以内)

チェックリストが完了しても、公開直後の24時間は集中的に監視します。

  1. 公開直後(0〜1時間): 全モニターが「UP」になっていることを確認
  2. 公開当日(〜8時間): レスポンスタイムの急変がないことを確認
  3. 翌朝(〜24時間): 夜間の障害アラートが届いていないことを確認

障害が発生した場合の初動対応は「サイト障害発生時の対応フロー完全ガイド」を参考にしてください。

まとめ

公開前の監視設定は「後でやる」では遅い場合があります。公開直後のトラブルは制作会社への信頼を最も損ないやすいタイミングであり、このチェックリストを納品フローに組み込んでおくことで、クライアントとの長期的な信頼関係を最初から積み上げられます。

  • HTTP・SSL・DNS監視は公開と同時に設定する
  • TTLは公開前に短くし、安定後に通常値へ戻す
  • Heartbeat監視でcronジョブ・自動更新の動作確認を自動化する
  • ステータスページをクライアントに共有して問い合わせを減らす

監視設定の詳細はドキュメントをご覧ください。無料プランから始めて、公開前チェックリストを実際に試してみてください。保守契約への監視組み込みの全体像はユースケース一覧でも紹介しています。