2025年9月09日·2 分
SaaSのステータスページを作る方法（インシデント履歴付き）
インシデント履歴、分かりやすい文言、購読機能を備えたSaaSのステータスページを計画し、構築して公開する方法を学びます。障害時に顧客が情報を得られるようにするベストプラクティスを解説します。
インシデント履歴、分かりやすい文言、購読機能を備えたSaaSのステータスページを計画し、構築して公開する方法を学びます。障害時に顧客が情報を得られるようにするベストプラクティスを解説します。
SaaSのステータスページは、製品が今動いているかどうか、動いていなければ何をしているかを示す公開（または顧客限定）のウェブサイトです。インシデント時の単一の信頼できる情報源になり、ソーシャルメディアやサポートチケット、噂と切り離されます。
思ったより多くの人に役立ちます：
良いサービスステータスサイトは通常、関連するが異なる三つの層を含みます：
目標は明快さです：リアルタイムは「今使えるか？」に答え、履歴は「どれくらい頻繁か？」に答え、ポストモーテムは「なぜ起きたか、何が変わったか？」に答えます。
ステータスページは更新が速く、平易な言葉で、影響について正直であるときに機能します。完璧な診断は不要ですが、タイムスタンプ、適用範囲（誰が影響を受けるか）、次回更新時間は必須です。
ステータスページは、停止（アウトジー）、性能劣化（ログインが遅い、Webhookの遅延）、予定されたメンテナンスなどで頼りになります。
ステータスページをワンオフのオプスページではなくプロダクトの一部と扱えば、オーナーを定義し、テンプレートを作り、監視を接続するなどの準備が容易になります。毎回ゼロからやり直す必要はありません。
ツールやレイアウトを選ぶ前に、ステータスページで何を達成したいかを決めてください。明確な目標と明確なオーナーがあれば、インシデント中の混乱した状況でもページは役立ち続けます。
多くのSaaSチームは現実的な3つの成果のためにステータスページを作ります：
起動後に追跡できる2〜3の測定可能な指標（例：インシデント時の重複チケット数の減少、初回更新までの時間、購読者数）を書き出してください。
主な読者は通常非技術系の顧客です。知りたいことは：
専門用語は最小限に。"一部の顧客がログインできません" は "認証で5xxが増えています" より顧客に親切です。技術的な詳細が必要なら短い補助文に収めてください。
プレッシャー下でも維持できるトーン（落ち着いた、事実重視、透明性ある）を選んでください。事前に決めること：
所有者を明確にしておけば「みんなの仕事」にならず、やがて「誰の仕事でもない」状況を防げます。
一般的な選択肢は2つ：
メインアプリが落ちる可能性があるなら、独立したステータスサイトが安全です。アプリやヘルプセンター（例：/help）から目立つリンクを貼るとよいでしょう。
ステータスページは、その背後にある“地図”の有用性に依存します。色やコピーを書く前に、実際に何を報告するか決めてください。目標は、組織の編成図ではなく顧客が製品をどう体験するかを反映することです。
顧客が「壊れている」と言ったときに想起する要素をリストアップします。多くのSaaSでは実用的な出発点は：
複数リージョンやプランがあるならそれもキャプチャします（例：「API – US」「API – EU」）。名前は顧客向けに："Login" は "IdP Gateway" より明瞭です。
顧客の考え方にマッチするグルーピングを選んでください：
無限にリストを増やすのは避けて。多数のインテグレーションがあるなら親コンポーネント（"Integrations"）と影響の大きい子をいくつか（例："Salesforce", "Webhooks"）にするのが現実的です。
シンプルで一貫したモデルはインシデント時の混乱を防ぎます。一般的なレベル：
各レベルの内部基準を文書化してください（公開しなくてもよい）。例えば「Partial Outage = 一地域のダウン」や「Degraded = p95レイテンシがXを超えてY分継続」など。定義の一貫性が信頼を生みます。
多くの障害はサードパーティに関係します：クラウドホスティング、メール配信、決済、IDプロバイダなど。これらの依存を文書化しておくと更新が正確になります。
公開するかは観客次第です。顧客に直接影響する（例：決済）なら公開コンポーネントに含めると有用です。ノイズになりやすく責任のなすりつけを招くなら内部に留め、更新時に言及する（例：「決済プロバイダでエラーが増加しているため調査中」）にとどめてください。
このコンポーネントモデルがあれば、インシデントごとに「どこか」と「どれくらい悪いか」が即座に決まります。
ステータスページは、数秒で顧客の疑問に答えるときに最も有用です。訪問者は通常ストレスを感じており、ナビゲーションより明快さを求めます。
最上部に必須情報を優先配置：
言葉は平易に。"APIリクエストのエラー率が増加"は"上流の依存で部分的障害"より明確です。技術用語を使う場合は短い解説を添えてください（例：「一部のリクエストが失敗またはタイムアウトする可能性があります」）。
信頼性の高いパターン：
コンポーネントラベルは顧客向けに。内部で "k8s-cluster-2" と呼ぶより "API" や "バックグラウンドジョブ" の方が分かりやすいです。
緊張した状況でも読みやすくするために：
多くのユーザーはスマホでステータスを確認します。
バナーの近く（ヘッダーやバナー直下）に小さなリンク群を置く：
目的は安心感：何が起きているか、何に影響するか、次にいつ連絡があるかを即座に理解させることです。
インシデント発生時は診断、緩和、顧客対応の同時進行になります。テンプレートがあれば更新が一貫し速くなり、異なる人が投稿してもばらつきが減ります。
良い更新は毎回同じコア情報から始まります。最低限標準化すべき項目：
インシデント履歴ページを公開するなら、これらを一貫して保つと過去の比較が簡単になります。
短く、顧客が毎回同じ質問に答えられるようにします。実用的なテンプレート例：
Title: 簡潔で具体的な要約（例："EUリージョンのAPIエラー"）
Start time: YYYY-MM-DD HH:MM (TZ)
Affected components: API, Dashboard, Payments
Impact: ユーザーが見ている現象（エラー、タイムアウト、性能劣化）と影響範囲
What we know: 確認済みの原因がある場合の一文（憶測は避ける）
What we’re doing: 具体的な対応（ロールバック、スケーリング、ベンダーへのエスカレーション）
Next update: 次の更新時刻
Updates:
顧客は情報だけでなく予測可能性を求めます。
予定メンテナンスは落ち着いた構成で。標準化項目：
具体的に何が変わるか、ユーザーが何を感じるかを明記し、過度な約束は避け正確性を優先してください。
インシデント履歴は単なるログではなく、顧客やチームが問題の頻度や傾向、対応を見るための手段です。
透明性は信頼を築きます。定期的な"APIレイテンシ"の再発が見えれば、性能改善投資の判断材料になります。継続的な報告はサポートチケットの自己解決につながり、時間の節約にもなります。
顧客の期待やプロダクトの成熟度に応じて保持ウィンドウを選んでください：
選んだら明記してください（例：「インシデント履歴は12か月保持」）。
スキャンしやすさは一貫性から生まれます。予測可能な命名例：
YYYY-MM-DD — 短い要約（例："2025-10-14 — メール配信遅延"）
各インシデントには最低でも：
ポストモーテムを公開しているなら、インシデントの詳細ページからリンクしてください（例：「ポストモーテムを読む」 -> /blog/postmortems/2025-10-14-email-delays）。タイムラインは簡潔に保ちながら、詳細を読みたい人に深掘りを提供できます。
顧客がページを見に来るのを待つより、購読で自動的に通知を送る方が有効です。購読があればページを何度もリロードする必要がありません。
一般的には少なくとも：
複数チャネルをサポートする場合、登録フローは一貫させて四つに分かれるように感じさせないようにしてください。
購読は常にオプトイン。特にSMSは、確定前に何を受け取るかを明示してください。
購読者に以下の選択肢を与えるとアラート疲れを防げます：
コンポーネント別購読がすぐに提供できない場合は、まず"全更新"で始め、後からフィルタを追加してください。
インシデント中はメッセージ量が急増し、サードパーティがスロットルする可能性があります。確認ポイント：
四半期ごとの定期テストを行い、購読機能が期待通り動くことを確認する価値があります。
ステータスホームページの折りたたまれない領域（上部）に目立つコールアウトを置き、顧客が次のインシデント前に登録できるようにします。モバイルでも表示されるようにし、サポートポータルやヘルプセンターからもリンクしてください。
どう作るかは「作れるか」よりも、何を最優先するか（立ち上げの速さ、障害時の信頼性、運用コスト）で決めます。
ホステッドは通常最速の道です。既製のステータスページ、購読機能、インシデントタイムライン、監視との統合を得られます。
ホステッドツールを選ぶ際のチェックポイント：
フルコントロールが得られますが、信頼性と運用は自分で担保する必要があります。現実的なDIYアーキテクチャ：
セルフホストするなら障害時のフェールモードを計画してください：主要DBが落ちたら、デプロイパイプラインが落ちたらどうするか。多くのチームはメインプロダクトとは別のインフラやプロバイダでステータスページを運用します。
DIYのコントロールを得つつ全てを作り直したくない場合、チャット駆動の仕様からカスタムなステータスサイト（Web UIと小さなインシデントAPI）を素早く立ち上げられるようなプラットフォーム（例：Koder.ai）の利用も検討できます。これにより、コンポーネントモデルやインシデント履歴UX、内部の管理ワークフローをカスタマイズしつつ、ソースコードをエクスポートしてデプロイできます。
ホステッドは月額が予測しやすい一方、DIYはエンジニア時間、ホスティング/CDN、継続的な運用コストがかかります。選択時は予想月額と必要な内部工数を見積もり、予算と照らし合わせてください（参照：/pricing）。
ステータスページは迅速に現実を反映してこそ有用です。問題を検出するシステム（監視）と対応を調整するシステム（インシデント管理）をつなげると、更新が一貫して迅速になります。
多くのチームは三つを組み合わせます：
実用ルール：監視が検出し、インシデントワークフローが調整し、ステータスページが伝える。
自動化は数分を節約できます：
初回の公開メッセージは保守的に："調査中：エラー増加" は 検証中に "障害確定" と出すより安全です。
完全自動は誤報や誤解を招く危険があります：
自動化は下書きや提案の作成に使い、特に Identified / Mitigated / Resolved のステートは人の承認を必須にするのが安全です。
ステータスページを顧客向けのログブックとして扱い、次を答えられるようにしてください：
監査ログは事後レビューや引き継ぎ時の混乱を減らし、顧客からの照会に対する信頼できる回答になります。
ステータスページは、製品がダウンしているときにアクセス可能でなければ意味がありません。最も一般的な失敗は、ステータスページをアプリと同じインフラに構築してしまうことです。するとアプリの障害とともにステータスも消えてしまいます。
可能ならステータスページはプロダクションアプリとは別のプロバイダ（または別リージョン/別アカウント）でホスティングしてください。目標はブラスト半径の分離です：アプリ基盤の障害が通信基盤まで及ばないようにします。
DNSも分離を検討してください。メインドメインのDNSがアプリのエッジ/CDNと同じ場所にあると、DNSや証明書の問題で双方がブロックされることがあります。多くのチームは独立したサブドメイン（例：status.yourcompany.com）と独立DNSを使います。
アセットは軽量に：最小限のJavaScript、圧縮CSS、アプリAPIに依存しないレンダリング。CDNを前段に入れ、静的リソースはキャッシュしてトラフィックピーク時にもロードされるようにします。
実用的な安全策はフォールバックの静的モードです：
顧客はログイン不要で稼働状況を見られるべきです。一方、管理/編集ツールは認証（可能ならSSO）で保護し、強いアクセス制御と監査ログを設けてください。
最後に、フェールシナリオをテストしてください：ステージング環境でアプリ起点を一時的に遮断し、ステータスページが解決・高速に読み込め、必要な更新を投稿できるか確認します。
ステータスページはインシデント時に一貫して更新されて初めて信頼を築けます。その一貫性は偶然には生まれません。明確な所有、単純なルール、予測可能な更新頻度が必要です。
コアチームは小さく明確に：
小規模チームなら一人が二役を兼任しても構いませんが、事前に役割の引き継ぎとエスカレーション経路をオンコールハンドブックに記載しておいてください（参照：/docs/on-call）。
アラートが顧客影響インシデントになったら、再現可能なフローに従います：
実用ルール：初回更新は10〜15分以内に、影響継続時は30〜60分ごとに投稿する（"変化なし、調査中"も可）。
解決後1〜3営業日以内に軽量な事後レビューを実施：
その後、インシデントエントリを最終まとめで更新し、履歴が単なる"解決"のログで終わらないようにします。
ステータスページは見つけやすく、信頼でき、継続的に更新されることが重要です。公開前に実務的なチェックを行い、ローンチ後は軽い改善サイクルを回してください。
コピーと構成
ブランディングと信頼
アクセスと権限
フルワークフローのテスト
アナウンス
自前で構築する場合はステージングで同じチェックリストを回すことを推奨します。Koder.aiのようなツールは、Web UI、管理画面、バックエンドエンドポイントを仕様から生成してエクスポート／デプロイできるため、反復を速められます。
月次レビューでいくつかの成果を追跡：
単純な分類で履歴を実用化：
小さな改善（明瞭な文言、速い更新、よりよい分類）は積み重なって、チケット減少や顧客信頼の向上につながります。
SaaSのステータスページは、現在のサービス稼働状況とインシデントの更新情報を一箇所で提供する専用ページです。これにより「ダウンしているの？」というサポート問い合わせが減り、障害時の期待値を設定でき、タイムスタンプ付きの明確なコミュニケーションで信頼を築けます。
リアルタイムのステータスは「今この瞬間、製品を使えますか？」に答え、コンポーネント単位の状態を示します。
インシデント履歴は「どれくらい頻繁に起きているか？」に答え、過去のインシデントやメンテナンスのタイムラインを提示します。
ポストモーテムは「なぜ起きたか、何を変えたか？」に答え、根本原因と再発防止策を説明する詳細な報告です（インシデントの詳細ページからリンクすることが多いです）。
まず2〜3つの測定可能な成果を決めます。例：
これらを文書化し、月次で見直すとステータスページが陳腐化しません。
明確な所有者とバックアップを割り当てます（多くはオンコールのローテーション）。一般的な役割：
事前に誰が投稿できるか、承認が必要か、最小更新頻度（例：重大インシデント時は30〜60分ごと）を定義しておくと混乱を避けられます。
顧客が問題を説明する言葉に基づいてコンポーネントを選びます。一般的な項目例：
信頼性が地域で異なるなら地域別に分けます（例：「API – US」「API – EU」）。内部のサービス名は避け、顧客向けの名称を使ってください。
小さく一貫したステータスセットを使い、各レベルの内部基準を文書化します。例：
一貫性が重要です。顧客は繰り返し使うことで各レベルの意味を理解します。
有用なインシデント更新は最低でも以下を含みます：
根本原因が不明でも、範囲と影響、次のアクションを伝えれば顧客は状況を把握できます。
初回の「Investigating」更新は速やかに（確認後10〜15分以内が目安）投稿します。それから：
約束した頻度を守れない場合は、短い注記で遅延を知らせて期待値をリセットしてください。沈黙は避けるべきです。
ホステッドツールは立ち上げが早く、購読やインシデント履歴、外部監視との統合を備えている場合が多いです。一方DIYは完全なコントロールを得られますが可用性を自分で担保する必要があります。
DIYの推奨アーキテクチャ：
比較時は月額費用と内部工数の両方を見積もって選んでください（参照：/pricing）。
顧客が普段使っているチャネルを提供します（一般的にはメールとSMS。ビジネス顧客向けにSlack/Teams、技術ユーザー向けにRSS/Atomも有用）。購読はオプトインにし、以下を明確にします：
配信能力、レートリミット、送信ドメインの設定（SPF/DKIM/DMARC）を定期的にテストし、障害時でも通知が届くようにしてください。