共有前の確認点
ステータスページには「影響を受けているシステム名」「発生時刻」「対応状況」が表示される。これらの情報は正確さが命であり、誤った情報が外部に出ると企業の信頼失墜に直結する。共有前にシステム名の表記ゆれ（例：「決済API」と「Payment API」が混在）がないかを確認し、用語を統一する。
ステータスページはモバイルで閲覧されることが多い。インシデント中にエンジニアがスマホでページを確認したり、顧客がモバイルブラウザでアクセスしたりするため、スマホでの表示速度と視認性を特に重視する。ステータスバッジ（緑・黄・赤）の色がモバイル画面でも判別できるか、文字サイズが12px以上あるかを確認する。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
向いている認証方式
一般ユーザー向けのステータスページは認証なしで外部公開するのが標準だ。ただしインシデント対応中の詳細な技術情報（例：影響範囲のIPレンジ、内部エラーコード）は外部には不要なため、公開版に含めないか、認証付きの内部向けURLを別途用意する。
エンタープライズ顧客に対して「自社専用のステータスページ」を提供するケースでは、会社ドメイン認証で顧客企業の全担当者がアクセスできるようにすると手間が省ける。顧客ごとに異なるパスワードを管理する必要がなく、担当者が変わっても運用を変更せずに済む。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
相手への送り方
インシデント発生時にステータスページURLをメールで送ると、相手の受信ボックスに届くまでのラグがある。SlackのステータスチャンネルやMicrosoft TeamsのGeneralチャンネルにURLを投稿する方が、関係者への周知が速い。件名または投稿本文の冒頭に「【インシデント対応中】」の文字を入れると、未読の中から見つけやすくなる。
定期メンテナンスのステータスページを事前に共有する場合は、メンテナンス開始の24時間前と1時間前の2回通知するのが丁寧だ。URLと一緒に「メンテナンス対象のサービス名」「影響する機能」「復旧予定時刻」を箇条書きで添えると、受信者が追加で質問する手間が省ける。
更新・期限管理
インシデント対応中のステータスページは15〜30分ごとに更新するのがベストプラクティスだ。「調査中」「原因特定」「修正適用中」「復旧済み」の各フェーズで内容を差し替えると、閲覧者が最新状況を把握できる。ギガサイト便のように同一URLで差し替えができるサービスを使えば、更新作業がファイルのアップロードだけで完結する。
インシデントが解消した後も、ポストモーテム（事後分析）を追記した最終版を1週間程度公開し続けると、顧客の信頼回復に繋がる。最終版の公開終了後は、恒久的な稼働実績ページ（過去30日の稼働率グラフなど）にインシデント情報をアーカイブして引き継ぎ、URLを変更しない形で運用すると便利だ。
よくある質問
ステータスページのHTMLをインシデント対応中に素早く更新するための準備は何ですか？
あらかじめ「調査中」「対応中」「復旧済み」のテンプレートHTMLを用意しておき、発生時に日時と影響範囲を差し替えてアップロードするだけで完結する運用を整えておくと、インシデント対応の初動が格段に速くなります。
無料プランのCDNやホスティングでステータスページを公開した場合、インシデント時にそのCDN自体が落ちる可能性はありますか？
あります。ステータスページのホスティング先とプロダクトのインフラを分離することが重要です。ギガサイト便はCloudflare基盤を使用しているため、自社サーバーとは独立して稼働します。
過去のインシデント記録をステータスページに残す場合、SEOで検索に引っかかるデメリットはありますか？
インシデント履歴は透明性の観点では好意的に評価されることも多いですが、意図しない露出が気になる場合はnoindex指定を追加するか、認証付きURLで社内・顧客限定の閲覧に留めてください。