公開前テスト自動化ガイド｜制作会社向けリリース前チェックの仕組み化

公開のたびに手作業でチェックしていませんか？

クライアントサイトの本番公開前に、担当者がブラウザを手動で開いてHTTPS確認・SSL証明書の有効期限確認・メール送信テスト——これを毎回繰り返している制作会社は珍しくありません。しかし、案件数が増えると手作業の抜け漏れが起きやすくなります。

公開前テストの自動化は、この問題を根本から解決します。MiterlのAPIを組み合わせれば、リリース前の必須チェックを一本のスクリプトで完走でき、担当者のスキルや経験に依存しない品質を維持できます。

なぜ公開前テストを自動化すべきか

手作業による確認の限界

公開直後の障害がどれだけ信頼に影響するかは「Webサイトのダウンタイムが引き起こすコストとビジネス損失」で数値化されています。公開前テストはその損失を未然に防ぐための最後の砦です。

自動化で得られるもの

• 再現性: 新人でもベテランでも同じチェックを同じ順番で実施できる
• 記録: 結果がログとして残り、クライアントへの説明に使える
• スピード: 確認待ちで公開が遅れるリスクを排除できる

ステップ1：監視モニターを公開前に作成する

テスト自動化の起点は、公開前にMiterlのモニターを作成しておくことです。公開と同時に監視が始まるため、直後の問題を即座に検知できます。

まず通知先（アラート連絡先）を GET /api/v1/alert-contacts で確認し、IDを控えます。

#!/bin/bash
# pre_launch_setup.sh
# 使い方: CLIENT_DOMAIN=example.com ./pre_launch_setup.sh

API_KEY="YOUR_API_KEY"
BASE_URL="https://miterl.com/api/v1"
DOMAIN="${CLIENT_DOMAIN}"
ALERT_CONTACT_IDS="[1, 2]"

# 1. HTTP死活監視
curl -s -X POST "${BASE_URL}/monitors" \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"name\": \"[${DOMAIN}] HTTP\",
    \"url\": \"https://${DOMAIN}\",
    \"type\": \"http\",
    \"interval_seconds\": 180,
    \"alert_contact_ids\": ${ALERT_CONTACT_IDS}
  }" | jq '{id, name, status: .data.status}'

# 2. SSL証明書監視
curl -s -X POST "${BASE_URL}/monitors" \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"name\": \"[${DOMAIN}] SSL\",
    \"url\": \"https://${DOMAIN}\",
    \"type\": \"ssl\",
    \"interval_seconds\": 86400,
    \"ssl_expiry_alert_days\": 30
  }" | jq '{id, name}'

# 3. DNS監視
curl -s -X POST "${BASE_URL}/monitors" \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"name\": \"[${DOMAIN}] DNS\",
    \"url\": \"${DOMAIN}\",
    \"type\": \"dns\",
    \"interval_seconds\": 3600,
    \"alert_contact_ids\": ${ALERT_CONTACT_IDS}
  }" | jq '{id, name}'

echo "Monitors created for ${DOMAIN}"

公開前チェックリストの全8項目については「Webサイト公開前の監視設定チェックリスト」を参照してください。本記事では、その中でも自動化が特に効果的な部分に絞って深掘りします。

ステップ2：HTTPSとリダイレクトを自動検証する

モニター作成後、スクリプトからHTTPSアクセスとリダイレクト動作を確認します。

#!/bin/bash
# verify_https.sh

DOMAIN="${CLIENT_DOMAIN}"

echo "=== HTTPS検証: ${DOMAIN} ==="

# HTTPSへのアクセス確認（200または3xxが期待値）
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "https://${DOMAIN}")
if [ "$HTTP_CODE" -ge 200 ] && [ "$HTTP_CODE" -lt 400 ]; then
  echo "[OK] HTTPS応答: ${HTTP_CODE}"
else
  echo "[NG] HTTPS応答: ${HTTP_CODE} — 要確認"
fi

# HTTPからHTTPSへのリダイレクト確認
REDIRECT_URL=$(curl -s -o /dev/null -w "%{redirect_url}" "http://${DOMAIN}")
if echo "$REDIRECT_URL" | grep -q "https://"; then
  echo "[OK] HTTPリダイレクト: ${REDIRECT_URL}"
else
  echo "[NG] HTTPリダイレクト未設定 — Nginx/Apache設定を確認"
fi

# SSL証明書の有効期限（残日数）
EXPIRY_DATE=$(echo | openssl s_client -servername "${DOMAIN}" -connect "${DOMAIN}:443" 2>/dev/null \
  | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
if [ -n "$EXPIRY_DATE" ]; then
  DAYS_LEFT=$(( ( $(date -d "$EXPIRY_DATE" +%s 2>/dev/null || gdate -d "$EXPIRY_DATE" +%s) - $(date +%s) ) / 86400 ))
  if [ "$DAYS_LEFT" -gt 30 ]; then
    echo "[OK] SSL有効期限: あと${DAYS_LEFT}日"
  else
    echo "[警告] SSL有効期限: あと${DAYS_LEFT}日 — 更新検討を"
  fi
fi

ステップ3：DNSレコードを自動検証する

#!/bin/bash
# verify_dns.sh

DOMAIN="${CLIENT_DOMAIN}"
EXPECTED_IP="${EXPECTED_IP}"  # 正しいサーバーIPを事前に確認して設定

echo "=== DNS検証: ${DOMAIN} ==="

# Aレコードの確認
RESOLVED_IP=$(dig +short A "${DOMAIN}" | head -1)
if [ "$RESOLVED_IP" = "$EXPECTED_IP" ]; then
  echo "[OK] Aレコード: ${RESOLVED_IP}"
else
  echo "[NG] Aレコード: ${RESOLVED_IP} (期待値: ${EXPECTED_IP}) — DNS設定を確認"
fi

# TTL確認
TTL=$(dig +noall +answer A "${DOMAIN}" | awk '{print $2}' | head -1)
if [ -n "$TTL" ] && [ "$TTL" -le 300 ]; then
  echo "[OK] TTL: ${TTL}秒（低TTL設定中）"
elif [ -n "$TTL" ]; then
  echo "[情報] TTL: ${TTL}秒 — 公開直前は300秒推奨"
fi

# SPFレコードの確認
SPF_RECORD=$(dig +short TXT "${DOMAIN}" | grep "v=spf1")
SPF_COUNT=$(echo "$SPF_RECORD" | grep -c "v=spf1")
if [ "$SPF_COUNT" -eq 1 ]; then
  echo "[OK] SPFレコード: 1件"
elif [ "$SPF_COUNT" -eq 0 ]; then
  echo "[警告] SPFレコード: 未設定"
else
  echo "[NG] SPFレコード: ${SPF_COUNT}件（重複 — メール到達性に影響）"
fi

# DMARCレコードの確認
DMARC_RECORD=$(dig +short TXT "_dmarc.${DOMAIN}" | grep "v=DMARC1")
if [ -n "$DMARC_RECORD" ]; then
  echo "[OK] DMARCレコード: 設定済み"
else
  echo "[警告] DMARCレコード: 未設定 — メール到達性に影響する場合あり"
fi

SPFやDMARCのより詳細な設定・監視手順は「SPF・DMARC・DKIM・MXレコードの設定と常時監視の方法」で解説しています。メール認証が崩れると問い合わせフォームのメールが迷惑フォルダに入るトラブルが発生します。

ステップ4：Heartbeatモニターでcronジョブを監視する

バックアップやSSL自動更新など、サイト公開時に同時に設定するcronジョブが正常動作しているかを確認するには、ハートビート監視が必要です。

# crontabに追記: 毎日3:00にバックアップを実行し成功時だけPINGを送る
0 3 * * * /path/to/backup.sh && curl -fsS https://miterl.com/heartbeat/YOUR_HEARTBEAT_TOKEN

ハートビート監視の仕組みと設定手順の詳細は「ハートビート監視とは？cronジョブの死活確認を自動化する方法」で解説しています。「動いているはずなのに実は止まっていた」というケースを防ぐために、公開時に同時設定することをおすすめします。

ステップ5：CI/CDに組み込んで全チェックをワンコマンドで実行する

上記のスクリプトをCI/CDパイプライン（GitHub Actions等）に組み込めば、デプロイのたびに自動実行されます。

# .github/workflows/pre-launch-check.yml
name: Pre-Launch Check

on:
  workflow_dispatch:
    inputs:
      client_domain:
        description: 'チェック対象ドメイン'
        required: true
      expected_ip:
        description: '期待するサーバーIP'
        required: true

jobs:
  pre-launch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: HTTPS検証
        env:
          CLIENT_DOMAIN: ${{ github.event.inputs.client_domain }}
        run: bash scripts/verify_https.sh

      - name: DNS検証
        env:
          CLIENT_DOMAIN: ${{ github.event.inputs.client_domain }}
          EXPECTED_IP: ${{ github.event.inputs.expected_ip }}
        run: bash scripts/verify_dns.sh

      - name: Miterlモニター作成
        env:
          CLIENT_DOMAIN: ${{ github.event.inputs.client_domain }}
          API_KEY: ${{ secrets.MITERL_API_KEY }}
        run: bash scripts/pre_launch_setup.sh

Webhook連携で障害検知後の自動ロールバックも実装したい場合は「Webhook連携で監視を自動化」を参照してください。

ステップ6：チェック結果をSlack通知する

スクリプトの実行結果を Slack に通知することで、チーム全員がリリース状況をリアルタイムで把握できます。

#!/bin/bash
# notify_slack.sh

WEBHOOK_URL="${SLACK_WEBHOOK_URL}"
DOMAIN="${CLIENT_DOMAIN}"
STATUS="${CHECK_STATUS:-OK}"

COLOR="good"
if [ "$STATUS" = "NG" ]; then COLOR="danger"; fi

curl -s -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d "{
    \"attachments\": [{
      \"color\": \"${COLOR}\",
      \"title\": \"公開前チェック完了: ${DOMAIN}\",
      \"text\": \"すべての自動チェックが完了しました。\",
      \"fields\": [
        {\"title\": \"ステータス\", \"value\": \"${STATUS}\", \"short\": true},
        {\"title\": \"対象ドメイン\", \"value\": \"${DOMAIN}\", \"short\": true}
      ]
    }]
  }"

公開後24時間の自動監視

スクリプトによる事前チェックが完了しても、公開後24時間は集中監視が必要です。Miterlのダッシュボードで以下を確認します。

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

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

まとめ

公開前テストの自動化は、制作会社の品質とスピードを同時に向上させます。

• モニター作成・HTTPS確認・DNS検証・SPF/DMARC確認をスクリプト化することで、担当者依存の手作業を排除できる
• CI/CDに組み込めば公開のたびに自動実行され、チェック漏れがなくなる
• Heartbeat監視との組み合わせで、バックアップやcronジョブの動作も自動確認できる
• Slack通知でチーム全員がリリース状況をリアルタイム把握できる

詳しいAPI仕様はドキュメントを参照してください。無料プランから始めて、公開前チェックスクリプトを実際に試してみてください。監視を保守契約に組み込む料金設計の参考はユースケース一覧でも紹介しています。