障害・メンテ情報の取得＆自動通知スクリプト（Cron設定例付き）

ワードプレス
  1. 1. はじめに｜「気づいたら落ちていた」をゼロにする理由
    1. 1-1 機会損失は何分でいくら？
    2. 1-2 ステータスページだけでは遅い現実
    3. 1-3 本記事のゴール
  2. 2. ステータス情報の取得方法を３分で整理
    1. 2-1 主要レンタルサーバー & クラウドの公開エンドポイント早見表
    2. 2-2 非公開ベンダーの扱い
  3. 3. 環境準備｜必要ツールとフォルダ構成
    1. 3-1 Python と Bash どちらを選ぶ？
    2. 3-2 インストール手順（Xserver例）
    3. 3-3 フォルダ構成
  4. 4. 単一ベンダー版：最小30行のPythonスクリプト
  5. 5. マルチベンダー統合版：クラス設計とプラグイン機構
    1. 5-1 ベースクラス AbstractStatusFetcher
    2. 5-2 具体クラス：Xserver & ConoHa
    3. 5-3 メインスクリプトをプラグイン方式に
  6. 6. 死活監視ツールとの連携で“取りこぼしゼロ”
    1. 6-1 curl + grep 最小ヘルスチェック
    2. 6-2 UptimeRobot API でまとめ通知
  7. 7. 通知テンプレート集
    1. 7-1 Slack Block Kit（視認性◎）
    2. 7-2 Microsoft Teams (Adaptive Card)
    3. 7-3 Notion データベース追記
    4. 7-4 SMS／音声（夜間用）
  8. 8. Cron 設定完全ガイド
    1. 8-1 基礎：書式と例
    2. 8-2 Xserver パネルでの手順
    3. 8-3 ロードアベレージと実行間隔
    4. 8-4 よくある Cron 失敗原因
  9. 9. Docker 化して「どこでも動く」パッケージへ
    1. 9-1 Dockerfile（最小 10 行）
    2. 9-2 自動アップデート（watchtower）
    3. 9-3 マネージドサービスでスケジューリング
  10. 10. セキュリティ＆可用性チェックリスト
  11. 11. ケーススタディ３選
    1. 11-1 月 100 万 PV ブログ
    2. 11-2 24h 稼働 EC サイト
    3. 11-3 SaaS 企業 CS チーム
  12. 12. よくある質問 25
  13. 用語集 40
  14. 14. まとめ｜自動通知で “反応速度 × 信頼” を底上げする
  15. 15. 無料監視スクリプト診断

1. はじめに｜「気づいたら落ちていた」をゼロにする理由

1-1 機会損失は何分でいくら？

  • ブログ広告：1 分停止＝平均クリック5 件損失 → 日商1万円サイトなら約350円の取りこぼし
  • EC：カート決済率3 %・平均客単価8,000円 → 10 分停止で24,000円の売上消失
  • 企業SaaS：SLA 99.9 %（月に44分停止）を超えると違約金

通知が10 分早いだけで“損失・信用・カスタマー対応”すべてが軽減されます。

1-2 ステータスページだけでは遅い現実

多くのレンタルサーバーやクラウドは

  1. 障害検知
  2. エンジニア確認
  3. ステータスページ更新
    ──この流れで最短でも10〜15分の空白が発生。
    自前のスクリプトで API を直接ポーリングすれば、最速1分周期で検知→Slackやメールへ即通知できます。

1-3 本記事のゴール

  1. Python/Bashどちらでも動く30行スクリプトを作る
  2. XserverやConoHaの障害RSS/JSONを読み取り差分を抽出
  3. Slack・メール・Teams・Notionへ自動通知し、Cronで定期実行

読了後には「障害が起きたら1分で全員に届く」仕組みを自サイトに持てます。

エックスサーバーに申し込む

2. ステータス情報の取得方法を３分で整理

種類仕組み代表ベンダーメリット注意点
RSS / AtomXMLフィードXserver／さくら超軽量・ライブラリ豊富ベンダーにより更新遅延あり
JSON API/status.json などCloudflare／Vercel機械判読しやすい仕様変更に追従必要
Webhook障害発生時PushStripe／GitHubリアルタイム・無ポーリング公開していない社も多い
スクレイピングHTML解析一部レン鯖非公開情報を取れる規約違反・構造変化に弱い

ベストプラクティス：公開JSON or RSS → 差分取得 → Webhook型（Slack等）で通知。この3層が最も安定します。

2-1 主要レンタルサーバー & クラウドの公開エンドポイント早見表

サービス種別URL例
XserverRSShttps://www.xserver.ne.jp/rss_status.xml
ConoHaJSONhttps://status.conoha.jp/api/v1/status
CloudflareJSONhttps://www.cloudflarestatus.com/summary.json
AWSRSShttps://status.aws.amazon.com/rss/all.rss

（2025-05確認。最新URLは公式で要チェック）

2-2 非公開ベンダーの扱い

  • 公開URLが無い場合はスクレイピングは最終手段。利用規約で禁止される場合も。
  • 公式Xアカウントで障害ツイート→Twitter API で拾う方法もあるが、レート制限に注意。

3. 環境準備｜必要ツールとフォルダ構成

3-1 Python と Bash どちらを選ぶ？

比較軸PythonBash＋curl
可読性◎△
依存ライブラリ管理pip / venvほぼ不要
JSON処理標準jsonで楽jq が必須
拡張性（並列処理など）asyncioで高限界あり

初心者でも保守しやすいPython版を推奨。サンプルはPython、巻末でBashワンライナー例も載せます。

3-2 インストール手順（Xserver例）

bashコピーする編集する# SSH ログイン後
python3 -m venv ~/statusbot-venv
source ~/statusbot-venv/bin/activate
pip install requests feedparser python-dotenv

.env にWebhookやメールAPIキーを置くことで Gitに鍵を入れない セキュア運用が可能。

3-3 フォルダ構成

bashコピーする編集するstatusbot/
  ├ fetchers/
  │   ├ base.py
  │   ├ xserver.py
  │   └ conoha.py
  ├ notifiers/
  │   ├ slack.py
  │   └ email.py
  ├ main.py
  ├ .env
  ├ requirements.txt
  └ logs/
  • fetchers/ : ベンダー別にステータスを取得
  • notifiers/ : 通知チャネルごとに送信
  • logs/ : 実行ログ＋前回取得キャッシュを保存

4. 単一ベンダー版：最小30行のPythonスクリプト

pythonコピーする編集する#!/usr/bin/env python3
import feedparser, json, os, requests, hashlib, pathlib, sys
WEBHOOK = os.getenv("SLACK_WEBHOOK")
RSS = "https://www.xserver.ne.jp/rss_status.xml"
CACHE = pathlib.Path(__file__).with_suffix(".cache")

def fetch_latest():
    feed = feedparser.parse(RSS)
    return feed.entries[0].title + feed.entries[0].link

def changed(text):
    new_hash = hashlib.md5(text.encode()).hexdigest()
    old_hash = CACHE.read_text() if CACHE.exists() else ""
    if new_hash != old_hash:
        CACHE.write_text(new_hash)
        return True
    return False

def notify(msg):
    requests.post(WEBHOOK, json={"text": msg})

if __name__ == "__main__":
    latest = fetch_latest()
    if changed(latest):
        notify(f"🚨Xserver 障害/メンテ更新\n{latest}")
        print("sent")
    else:
        print("no change")

動作概要

  1. RSSを取得 → 最新エントリを文字列化
  2. 前回実行時MD5と比較 → 変化あればSlackにPOST
  3. .cache にハッシュ保存 → 無変更時は何もしない

ポイント

  • MD5のみで差分管理：ファイル1行、SQL不要
  • 環境変数でWebhook隠蔽：.env→os.getenv 読込

5. マルチベンダー統合版：クラス設計とプラグイン機構

単一スクリプトでも動きますが、VPS・CDN・DNS など複数サービスを使うサイトは “横並びで監視” できると便利です。ここでは Python のクラス継承 を使い、ベンダーを追加しても 5 分で拡張 できる土台を作ります。

5-1 ベースクラス AbstractStatusFetcher

pythonコピーする編集する# fetchers/base.py
from abc import ABC, abstractmethod
class StatusFetcher(ABC):
    def __init__(self, name):
        self.name = name          # 例: Xserver
        self.cache_file = f".{name}.cache"

    @abstractmethod
    def fetch(self):
        """最新の障害・メンテ文字列を返す"""
        ...

    def _changed(self, text: str) -> bool:
        import hashlib, pathlib
        new = hashlib.md5(text.encode()).hexdigest()
        path = pathlib.Path(self.cache_file)
        old = path.read_text() if path.exists() else ""
        if new != old:
            path.write_text(new)
            return True
        return False

5-2 具体クラス：Xserver & ConoHa

pythonコピーする編集する# fetchers/xserver.py
import feedparser
from .base import StatusFetcher

class XserverFetcher(StatusFetcher):
    RSS = "https://www.xserver.ne.jp/rss_status.xml"

    def __init__(self):
        super().__init__("xserver")

    def fetch(self):
        feed = feedparser.parse(self.RSS)
        latest = feed.entries[0]
        text = f"{latest.title} | {latest.link}"
        return text if self._changed(text) else None

pythonコピーする編集する# fetchers/conoha.py
import requests, datetime, pytz, json
from .base import StatusFetcher

class ConoHaFetcher(StatusFetcher):
    API = "https://status.conoha.jp/api/v1/status"

    def __init__(self):
        super().__init__("conoha")

    def fetch(self):
        data = requests.get(self.API, timeout=5).json()
        latest = data["incidents"][0]
        jp = datetime.datetime.fromisoformat(latest["updated_at"]).astimezone(
            pytz.timezone("Asia/Tokyo")).strftime("%Y-%m-%d %H:%M")
        text = f'{latest["name"]} ({jp})'
        return text if self._changed(text) else None

5-3 メインスクリプトをプラグイン方式に

pythonコピーする編集する# main.py
import os, importlib, requests
from dotenv import load_dotenv
load_dotenv()

WEBHOOK = os.getenv("SLACK_WEBHOOK")
FETCHERS = ["xserver.XserverFetcher", "conoha.ConoHaFetcher"]

def notify(msg):
    requests.post(WEBHOOK, json={"text": msg})

for path in FETCHERS:
    module_name, class_name = path.split(".")
    cls = getattr(importlib.import_module(f"fetchers.{module_name}"), class_name)
    text = cls().fetch()
    if text:
        notify(f"🚨 {cls.__name__[:-7]} 障害/メンテ更新\n{text}")

ベンダーを増やす手順

  1. fetchers/xxx.py をコピー＆URL修正
  2. FETCHERS リストへエントリを追記 — 以上！

6. 死活監視ツールとの連携で“取りこぼしゼロ”

障害情報は「サーバー側の発表」。しかし 自サイトだけ 404 になるケース（DNS ミス・テーマ更新ミス等）は拾えません。そこで 死活監視 (Heartbeat) を同じ Slack チャンネルに束ねましょう。

6-1 curl + grep 最小ヘルスチェック

bashコピーする編集する#!/bin/bash
URL="https://example.com/health"
if curl -fs --max-time 10 "$URL" | grep -q "OK"; then
  echo "healthy"
else
  curl -X POST -H 'Content-Type: application/json' \
   -d '{"text":"❌サイトが応答しません"}' "$SLACK_WEBHOOK"
fi
  • /health は index.php 直通より軽量な簡易エンドポイントを用意
  • 2xx 以外は Slack 通知

6-2 UptimeRobot API でまとめ通知

UptimeRobot は無料 1 分監視＋Webhook。ステータス変化 Webhook を 受信用小スクリプト に集約し、障害情報と同じ Block Kit で Slack に流すと見やすい。

7. 通知テンプレート集

7-1 Slack Block Kit（視認性◎）

pythonコピーする編集するdef build_block(vendor, text):
    return {
      "blocks":[
        {"type":"header","text":{"type":"plain_text","text":f"🚨 {vendor} 障害情報"}},
        {"type":"section","text":{"type":"mrkdwn","text":text}},
        {"type":"context","elements":[{"type":"mrkdwn","text":"<https://status.example|公式ステータス>"}]}
      ]
    }

requests.post(WEBHOOK, json=build_block("Xserver", text))

7-2 Microsoft Teams (Adaptive Card)

jsonコピーする編集する{
"@type": "MessageCard",
"themeColor": "ff0000",
"title": "ConoHa 障害通知",
"text": "データベース接続障害 (2025-05-08 14:12)"
}

Teams の Incoming Webhook にそのまま POST。

7-3 Notion データベース追記

pythonコピーする編集するimport requests, os, datetime, json
def notion_create(text):
    url="https://api.notion.com/v1/pages"
    headers={
      "Authorization": f"Bearer {os.getenv('NOTION_TOKEN')}",
      "Notion-Version": "2022-06-28",
      "Content-Type":"application/json"
    }
    data={
      "parent":{"database_id":os.getenv("NOTION_DB")},
      "properties":{
        "Title":{"title":[{"text":{"content":text}}]},
        "Date":{"date":{"start":datetime.datetime.utcnow().isoformat()}}
      }
    }
    requests.post(url, headers=headers, data=json.dumps(data))

7-4 SMS／音声（夜間用）

Twilio で

pythonコピーする編集するfrom twilio.rest import Client
client = Client(SID, TOKEN)
client.messages.create(from_='+123456789', to='+819012345678',
                       body='🚨 Xserver DB障害発生')

着信音＋バイブ で管理者が確実に気づく仕組み。

8. Cron 設定完全ガイド

8-1 基礎：書式と例

rubyコピーする編集する*/5 * * * * /home/user/statusbot/venv/bin/python /home/user/statusbot/main.py >> /home/user/statusbot/logs/run.log 2>&1
  • */5 * * * * → 5 分ごと
  • 標準出力・エラーを run.log に追記

8-2 Xserver パネルでの手順

  1. サーバーパネル →「Cron設定」
  2. */5 分・* 時…をプルダウンで入力
  3. コマンド欄にフルパスを貼り付け
  4. 「実行結果をメールで受け取る」をON
    • 失敗検知が楽＆SSHログイン不要

8-3 ロードアベレージと実行間隔

  • 共用サーバーはロードアベレージ制限あり → 5分〜10分間隔が無難
  • 自社VPSなら 1分間隔もOK だが、ベンダーAPIにもレート制限 があるため要確認（Cloudflareは毎分120リクエスト）

8-4 よくある Cron 失敗原因

症状原因解決
command not foundvenv パス誤り絶対パスを確認
Permission deniedファイルに実行権なしchmod +x script.py or python script.py
メールが大量送信script が毎回エラー2>&1 でログへ、set -e で即停止

9. Docker 化して「どこでも動く」パッケージへ

狙い：自宅 PC、VPS、会社サーバー——どこでも同じコマンドで立ち上げ。依存地獄から解放されます。

9-1 Dockerfile（最小 10 行）

Dockerfileコピーする編集するFROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
CMD ["python", "main.py"]
  1. プロジェクト直下に Dockerfile と requirements.txt を配置
  2. ビルド：docker build -t statusbot:latest .
  3. 実行： bashコピーする編集するdocker run --env-file .env \ --name statusbot \ statusbot:latest

9-2 自動アップデート（watchtower）

bashコピーする編集するdocker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  statusbot --schedule "0 */6 * * *"

6 時間おきに最新イメージへ自動更新→再起動。

9-3 マネージドサービスでスケジューリング

  • AWS ECS/Fargate：CloudWatch Event で 5 分ごと起動
  • Cloud Run：Cloud Scheduler で HTTP ping—無料枠で十分回る

10. セキュリティ＆可用性チェックリスト

項目やることツール例
API キー暗号化.env.enc を sops + GPG / AWS KMSMozilla sops
多重通知抑止送信前に Redis でキー重複チェックpython-redis
スクリプト死活5 分ごとに Heartbeat API へ pingHealthchecks.io
ログ保全logrotate で週次圧縮＋90 日保管logrotate
権限分離Slack Webhook を監視専用チャネルに限定Slack 権限設定
レート制限耐性asyncio.semaphore で同時 API 呼び出しを制御asyncio

11. ケーススタディ３選

11-1 月 100 万 PV ブログ

  • 課題：Xserver 障害情報を手動チェック→反応 30 分遅れ
  • 導入：RSS 監視 + Slack 通知 1 分間隔
  • 成果：広告停止時間 –22 分、月あたり広告損失 –18,000 円

11-2 24h 稼働 EC サイト

  • Teams + SMS 併用（営業時間内は Teams、深夜は SMS）
  • 決済 API 死活チェックも同報 → 深夜障害を 4 分で検知→決済切替
  • CS 対応時間 –40 %、購入取りこぼしほぼゼロ

11-3 SaaS 企業 CS チーム

  • Notion データベースへ自動追記 → 全社員が一目で障害履歴を確認
  • 公式アナウンスより平均 12 分速く把握 ⇒ チャットボット即時返信で混乱減

12. よくある質問 25

#質問回答
1API がなく RSS も無いサービスは？Twitter/X の公式アカウントを RSS ハブ経由で取得するか、最終手段として HTML スクレイピング。ただし規約を必ず確認。
2RSS が更新されないことがあるサービス側のキャッシュが原因。1 分→5 分間隔に延ばし、死活監視と併用して補完してください。
3差分判定に MD5 で十分？タイトルとリンクを連結してハッシュ化すれば実質衝突なし。本文差分も見たい場合は全文ハッシュへ変更を。
4Slack 通知が 2 回届くキャッシュファイルが権限エラーで書けていない可能性。実行ユーザーを統一 or キャッシュ保存先を /tmp へ変更。
5Webhook URL が漏えいしたら？Slack 管理画面→アプリ→Webhook→「Rotate」をクリックで即無効化。
6Python じゃなく Bash がいい1 ベンダー 1 行通知なら curl + grep + jq で可能。複数ベンダーなら Python が保守楽。
7メールだけでいい？メールは夜間に埋もれがち。Slack 等リアルタイム＋メールを CC にする二重化がおすすめ。
8実行ログが肥大化するlogrotate で週1 圧縮、rotate 8（8 週保管）程度で十分。
9シェアードサーバーで 1 分 Cron が使えない5 分 Cron + スクリプト内 time.sleep(60) ×5 で疑似 1 分監視。ただし実行時間上限に注意。
10ベンダー API が 429 (Rate Limit) を返すポーリング間隔を延長し、Retry-After ヘッダを respect。
11障害終了通知を受けたいフィードの「Resolved」「Closed」ステータスを別ハッシュで管理して二重通知を実装。
12複数チャンネルに送る方法は？Notifiers をリスト化し、for ループで順に POST。失敗時は例外ログ。
13JSON 解析で UnicodeErrorresponse.json() の前に .text.encode('utf-8', 'ignore') で化け文字回避。
14Teams で Markdown が崩れるAdaptive Card に統一か、改行を <br> に置換。
15Slack アイコンを変えたいWebhook 送信 JSON に "username":"StatusBot","icon_emoji":":siren:" を追加。
16夜間だけ SMS を送りたいif 0 <= now.hour <= 8: 条件で Twilio 通知を発火。
17Docker イメージが大きいpython:slim ベース + --no-cache-dir; multi-stage build で 150 MB 未満に。
18GitHub Actions で定期実行したいschedule: cron: '*/5 * * * *'、Secrets に Webhook を保存すれば GitHub 上でも可。
19シークレット管理が面倒1Password CLI / HashiCorp Vault で自動 inject するワークフローを採用。
20cron が止まっていたHeartbeat サービス（Healthchecks.io）に最後の成功 ping を飛ばし、未受信 10 分で SMS。
21API 仕様変更に気づかないfetch エラー（JSON decode）が連続したら「要メンテ」Slack 通知を投げる try/except を仕込む。
22Slack Free プランで履歴が流れるメールか Notion など長期保管先にも複写し、検索できる状態を確保。
23英語のみの障害文を日本語化したいgoogletrans ライブラリで machine translate、または要約して送信。
24Serverless で完全に管理フリーに？AWS Lambda + EventBridge Scheduler で同スクリプトを動かせばサーバー不要。
25パフォーマンス監視も統合したいPrometheus で up{job="website"}==0 を検知→Alertmanager で同じ Slack 通知に統合可能。

用語集 40

#用語かみくだき解説
1ステージング環境本番そっくりに複製したテスト用サイト。
2テスト環境開発者が単体・結合テストを行う場所。ステージングより自由度が高い。
3本番環境一般ユーザーがアクセスする公開サイト。
4差分プッシュ変更されたファイル・データだけを本番へ反映する操作。
5バックポート本番の最新データをステージングへ戻し整合を取ること。
6E2E テスト画面のボタン操作〜結果表示までを自動検証する “端から端” のテスト。
7Unit テスト関数単位の小さな動作テスト。PHPUnit などで実施。
8CypressJavaScript 製のブラウザ自動テストフレームワーク。
9WP-CLIWordPress をコマンドラインで操作する公式ツール。
10GitHub ActionsGitHub に内蔵された CI/CD パイプライン機能。
11CI/CD継続的インテグレーション／継続的デリバリー。テストとリリースを自動化する考え方。
12Blue-Green デプロイ本番と同じ構成を 2 系統用意し、切替で無停止リリースする手法。
13Rollback不具合時に更新前の状態へ即時戻すこと。
14robots.txt検索エンジンのクロール可否を指示するファイル。
15Basic 認証ID とパスワードでサイト全体を簡易保護する仕組み。
16Slack Webhook外部サービスから Slack へメッセージを投稿する URL。
17GUIDWordPress 投稿が持つ一意の識別用 URL。
18Serialize 文字列PHP のデータ構造を 1 本の文字列に変換したもの。
19Search-ReplaceDB 内の文字列一括置換。URL 変更で使う。
20hosts 切替PC の hosts ファイルで DNS をローカル上書きし、テスト先を一時的に変える方法。
21S3 オフロード画像などメディアファイルを Amazon S3 に保存し、サーバー容量や複製時間を減らす手法。
22Lintコードの文法エラーやスタイル違反を自動検出するツール群。
23PHPUnitPHP のユニットテストを実行する公式フレームワーク。
24WPScanWordPress の脆弱性をチェックできるセキュリティツール。
25WAFWeb Application Firewall。攻撃を自動遮断する防御壁。
26Cache Purgeキャッシュを強制的に全削除して最新状態にする操作。
27Edge CacheCDN の最寄りサーバーが保持するキャッシュ。
28Git Flowmain・develop・release など複数ブランチで開発を進めるワークフロー。
29NPSNet Promoter Score。顧客推奨度を測る指標。
30Sandbox モード決済など外部サービスのテスト用環境。実課金されない。
31API キー外部サービスを認証する文字列。漏えいすると不正利用される。
32Feature Flag新機能をコードに含めつつ、ON/OFF スイッチで切り替える手法。
33PR（Pull Request）変更内容を他メンバーにレビュー依頼する GitHub の仕組み。
34Actions SecretGitHub Actions 内で使う暗号化された環境変数。
35Audit Log誰がいつ何を変更したかを記録する監査証跡。
36CSPContent Security Policy。外部スクリプト読み込みを制限し XSS を防ぐ。
37SRISubresource Integrity。外部ファイル改ざんを検知するハッシュ署名。
38Cron Health Checkwp-cron が正常に走っているかを監視する仕組み。
39Headless CMSWordPress を管理画面だけに使い、フロントは別のJSフレームで表示する構成。
40Zero-Downtimeアップデート中でも一切の停止時間を作らない運用方針。

14. まとめ｜自動通知で “反応速度 × 信頼” を底上げする

  1. 公開 API / RSS を 1 分ポーリング
    • ベンダー発表を最速キャッチ
  2. 死活監視と束ねてワンチャンネル通知
    • 自社固有の 404・決済障害も同時検知
  3. Cron / Docker / Watchtower で 24h 無人稼働
    • 運用コストは月 0 円、保守は Git Pull だけ

行動の早さ = 損失の小ささ × 顧客の安心感
今日 30 行のスクリプトを仕込み、明日から “落ちてもすぐ動く” サイト運営へ。

15. 無料監視スクリプト診断

障害情報を朝イチで知り「あ、夜中に落ちてた…」と青ざめていませんか？

その 30 分の遅れが広告費・売上・顧客信頼を確実に削っています。

当サイトでは 監視スクリプト＆Cron 無料診断 を実施中。コードレビュー＋ベストプラクティスを 48 時間以内にレポート化し、即改善ポイントをお渡しします。

先着 15 サイト限定、7 月 31 日申込分で締切。

下のボタンから 60 秒でエントリーし、“最速検知体制” を今日から手に入れましょう！

エックスサーバーに申し込む