障害アラートのためにベンダーのステータスページを監視する方法

2025年10月19日の太平洋時間深夜直前、Amazon DynamoDBを支えるDNS自動化システムの競合状態（レースコンディション）により、us-east-1における同サービスのリージョンエンドポイントに空のDNSレコードが残される事態が発生しました。そのリージョンでDynamoDBに依存していたあらゆるシステムでエラーが発生し、被害はそれに依存する他のAWSサービスへも波及しました。AWS自身の公式報告によると、このインシデントは約14時間半にわたって続きました。

その朝、多くのチームのサーバーは完全に正常稼働していました。外部の認証プロバイダー、決済代行サービス、あるいはメール配信サービスが致命的な障害に陥っている間も、彼らの死活監視モニターはずっと緑色のままでした。とはいえ、大半の障害はこれほど大規模なものではありません。メール配信ベンダーで送信が40分遅延し、サポートには「パスワード再設定メールが届かない」という問い合わせが殺到し、やがて誰かがベンダーのステータスページを見つけると、そこにはすでに30分前から「パフォーマンス低下」と表示されていた、というようなケースです。

私は公開Webページの変更を監視し、関心のある変化だけをお知らせするツール「Page Deltas」の開発に携わっています。そのため、以下で他社ツールと比較する際はこの点を念頭に置いてお読みください。本記事では、自社が依存しているベンダーのステータスページをPage Deltasで監視する手順を解説します。どのURLを選ぶべきか、ノイズを排除する指示（ブリーフ）の書き方、アラートの送信先、そしてこの手法だけでは対応しきれない限界について説明します。

自社の監視モニターが「緑」のままになる理由

自社の死活監視（アップタイムモニター）は「自社サイトが応答しているか」をチェックするものであり、ベンダーの障害時でも自社サイト自体は通常通り応答します。APM（アプリケーションパフォーマンス監視）ではベンダー宛てのAPIコールでエラーが急増していることが示されますが、その原因が自社コードのバグなのかベンダー側の障害なのかまでは判断できません。それこそがステータスページが答えてくれる疑問であり、その回答によって次のアクションが根本から変わります。1時間前にデプロイしたコードを慌ててロールバックする必要はありません。サポート窓口には外部の既知の障害であると伝え、自社のステータスページの更新を検討することができます。

では、なぜベンダーのステータスページに直接登録（購読）しないのでしょうか？もしそれで十分にカバーできるなら、直接購読すべきです。多くのステータスページはAtlassian Statuspage等で運用されており、ベンダーの設定に応じてメール、SMS、Slack、Teams、Webhookでの購読を受け付けています。しかし問題は、依存するベンダーが8社、10社と増えたときに表面化します。購読手続きはベンダーごとにバラバラで、通知が特定の担当者の受信トレイに埋もれがちになり、フォーマットも統一されておらず、自社が使っている特定のコンポーネントだけを絞り込んで購読できるとは限りません。中には自社運用のページで、そもそも購読ボタンすら用意されていないベンダーも存在します。

Webページ監視ツールを使えば、あらゆるベンダーに対して統一された運用体制を構築できます。ステータスページのURLを貼り付け、関心のある内容を1文で指示するだけで、すべてのアラートが同じチャンネルに同じ形式で届きます。

どのページを監視すべきか？

現在の稼働状況が表示されているページを選びます。通常は status.vendor.com のようなURLです。ベンダーのトップページや、マーケティング用の「信頼性（Trust）」ページは選ばないでください。一般的なSaaSのステータスページは共通の構成を持っています。各コンポーネントの一覧と稼働ステータス、発生中のインシデントを知らせるバナー、予定されている定期メンテナンス、そして過去のインシデント履歴へのリンクです。

まずは、障害が発生した際に自社の顧客が真っ先に影響を受ける依存関係から始めましょう。多くのソフトウェア企業にとって、優先すべき対象は絞られています。

監視できる数に限りがある場合は、リストの上位から順に設定してください。決済や認証の障害は数分以内にサポート問い合わせへと発展しますが、CDNの低速化は初期段階では社内のメトリクスにしか現れないこともあります。無料プランの10 URL枠を使えば、この5項目すべてをカバーした上で、後述の追加ページを登録する余裕も十分に残ります。

さらに知っておくべきページが2つあります。1つ目は履歴ページ（多くは /history）で、特に深く依存しているベンダーの2本目の監視対象として有効です。短時間のインシデントの場合、メインページの2回のチェックの合間に発生して解消してしまうことがありますが、履歴ページには記録として残るため、後から確実に把握できます。2つ目は長時間に及ぶ重大インシデントの際、そのインシデント専用の個別ページを一時的な監視対象として追加することです。これにより、状況の進展を逐一受信できます。インシデントが解決したら監視を削除してください。すべての監視がURL上限数としてカウントされるためです。

設定手順

設定は約5分で完了します。手順の流れは当社の変更ログ監視ガイドと同じで、監視指示（ブリーフ）の内容を変えるだけです。

1. アカウント作成と通知チャンネルの設定

無料アカウントを作成し、「Channels（通知チャンネル）」を開いて、アラートを受信したい場所を追加します。#engineering のような雑多なチャンネルに投稿すると埋もれてしまうため、#vendor-status のような専用チャンネルを作成することをお勧めします。Slack、Discord、Microsoft TeamsはIncoming WebhookのURLを指定します。Teamsの場合は、チャンネルを右クリックして「コネクタ」→「Incoming Webhook」→「構成」を選択し、発行されたURLをPage Deltasに貼り付けます。メール通知の場合は、受信者に届く確認メールをあらかじめ承認してください。設定後は各チャンネルの「Send test」をクリックし、正常に届くことを確認します。

2. ブリーフを指定してモニターを追加する

「New monitor」をクリックし、ステータスページのURLを貼り付けます。1つのモニターには1社だけを設定し、ブリーフ内でそのベンダー固有のコンポーネント名を指定できるようにします。チームごとに担当ベンダーが異なる場合は、モニターごとに異なる通知チャンネルを紐付けてください。

ステータスページは、何事もない平穏な日であっても想像以上に頻繁に変更されます。稼働率のパーセンテージが変動し、「最終更新日時」のタイムスタンプが進み、直近のインシデント履歴リストには毎日新しい「インシデントは報告されていません」という行が追加されます。定期メンテナンスの予告は何週間も前から掲載されます。単純なHTML差分比較ツールでは、こうした些細な変化のすべてでアラートが誤作動してしまいます。

モニターの「Description（説明・指示）」は、ページの変更が通知に値するかどうかをAI（LLM）が判断する際のプロンプトになります。自社の代わりにページを見張ってくれている同僚にメモを残すような感覚で記述してください。メール配信サービスの場合、以下のような指示が適しています:

メール配信サービスのステータスページです。当社が利用しているのはUSリージョンの「Email API」および「Webhooks」コンポーネントのみです。
これらのコンポーネントまたは当該リージョンに影響を与える新しいインシデントが報告された場合、ステータスや重要度が変更された場合、または復旧した際にお知らせください。いずれかのコンポーネントが「Operational（正常稼働）」から別の状態に変わった場合も通知してください。
稼働率のパーセンテージ、「最終更新」タイムスタンプ、毎日の「インシデントは報告されていません」の更新行、および他リージョンのインシデントは無視してください。
計画メンテナンスについては、開始まで48時間以内のものに限り記載してください。
影響を受けているコンポーネント、現在のステータス、最新のアップデート内容を要約してください。

この「無視してください（Ignore）」の指示が極めて重要な役割を果たします。これを省略してしまうと、最初の1週間は毎晩深夜にインシデント履歴が更新されるたびにアラートを受信することになります。

大手クラウドプロバイダーの場合、リージョン名とサービス名の絞り込みがさらに重要になります。パブリッククラウドのダッシュボードには数十のリージョンにまたがる数百ものサービスが並んでおり、普段の週でもどこかしらのサービスで軽微な障害が起きています。自社が実際に稼働させているリージョンとサービス名を明記し、それらに関する情報だけを通知するよう指示してください。

3. 初回チェックでベースラインを記録する

モニターを作成すると、すぐに最初の自動チェックが実行されます。このチェックで初期状態のベースラインが保存されるため、2回のチェックの合間に変更が発生しない限り、登録直後にアラートが誤送信されることはありません。初回実行後にモニターを開き、スクリーンショットを確認して想定通りのコンポーネント一覧が取得できているか確認してください。

4. 異常を感じたときは「Check now」を実行

Page Deltasではチェック間隔を手動で秒単位に設定する必要はありません。更新頻度の高いページほど頻繁にチェックされる適応型スケジュールを採用しており、有料プランではキュー混雑時にも優先的にチェックされます。ステータスページは通常時は極めて平穏です。そのため自社のエラー率が急増し、ベンダー障害が疑われる場合は、モニター画面の「Check now」をクリックしてください。同じ操作はAPI経由でも実行可能で、モニターごとに毎分1回まで呼び出せます:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

アラートを受信したときの実践的な対応

指示（ブリーフ）に合致する重要な変更が検出されると、平易な要約文とともに変更前後の比較スクリーンショットが届きます。署名付きWebhookを使用している場合、ペイロードは以下のようになります（値はサンプル用のダミーです）:

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "メール配信サービスのステータス",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "新規インシデント：USリージョンにおけるメール配信遅延。Email APIがOperationalからDegraded Performanceに変更されました。ステータス：調査中。",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

最初のアラートを確認した担当者は、自社システムへの影響を直ちにSlack等のスレッドに返信して共有すべきです。サポート担当者は問い合わせが殺到する前に「外部ベンダーの既知の障害」として案内文を固定できます。オンコール担当のエンジニアは無実の最新デプロイの原因究明に無駄な時間を費やさずに済み、顧客に影響が及ぶ障害であれば、顧客が他所で騒ぎ出す前に自社のステータスページを先手を打って更新できます。

チームの運用基盤がPagerDutyなどのインシデント管理ツールに集約されている場合、署名付きWebhookを中継サーバー（リレー）経由で連携できます。当社のペイロードはPagerDuty標準形式とは異なるため、署名を検証してイベントを転送する軽量なサーバーレス関数を数行記述します:

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

JSONパースを行う前に生のボディ（raw body）をハッシュ化してください。そうしないと署名が一致しません。詳細な仕様は通知チャンネルのドキュメントに記載されています。各アラートはチャンネルごとに1回送信され、自動リトライは行われません。そのため、絶対に落とせない最重要ベンダーについては、リレーやSlackの障害に備えて異なる種類の第2チャンネル（Slack＋メールなど）を併用することをお勧めします。

この監視モデルの限界と注意点

この仕組みは「ベンダーが公に発表した情報」を通知するものであり、信頼して運用する前に知っておくべき制限事項がいくつかあります。

第一に、ベンダーの公式発表は遅れることが珍しくありません。自社のエラー監視グラフのほうが、ステータスページが障害を認めるより先に異常を検知することもあります。したがって、ステータスページのアラートは「第一報」としてではなく、「原因の公式な裏付け」として位置づけてください。また、自社APIの外形監視（シンセティック監視）や死活監視の代替にはなりません。それらは自社プロダクトが壊れている事実を教え、ステータスページはその根本理由を教えてくれるものです。

第二に、チェック間隔の合間に発生した変更は次の定期チェックで検知されるため、固定された秒単位の即時性を完全に保証するものではありません。分単位の即時対応が生死を分ける1〜2社の最重要ベンダーについてはベンダー自身の公式配信も購読しておき、残りの多数のベンダーをPage Deltasで一元管理するのが現実的です。また、当社は一般公開されているWebページのみを監視するため、ベンダーの管理コンソール内部にログインしないと見られない非公開ステータスは現時点では対象外です。

第三に、当社はページのテキスト内容を比較します。文字情報の変化がなく「色の付いたランプやドットの画像」だけでステータスを示すベンダーの場合、検知できません。画面のピクセル領域そのものを画像比較したい場合はVisualpingのようなツールのほうが適しています。最後に、ベンダーのステータスページ自体がダウンした場合、アラートは発信されずチェック失敗（エラー）として扱われます。10回連続でチェックが失敗するとモニターは自動的に一時停止され、管理者宛てに通知メールが送信されます。

まずは主要な3社から始めよう

障害が起きた際に自社に最も大きな損害を与える3社のベンダー（多くは決済、認証、メール配信）を選んでみてください。それぞれのステータスページURLを登録し、上記を参考に自社で利用しているコンポーネントやリージョンに合わせたブリーフを作成して、#vendor-status チャンネルにテスト通知を送ってみましょう。無料プランでは10 URLまで登録可能で、AIフィルタリング、全通知チャンネル、API連携がクレジットカード不要で利用できます。無料で監視を始める。

Julien（Page Deltas プロダクトマネージャー）