Webサイトで障害が発生した直後の一次報告書は、原因をすべて調べ終えてから作るものではありません。まず「障害または異常を認識していること」「現在確認できている影響」「取っている対応」「復旧見込みの有無」「次回の更新予定」を簡潔に伝え、情報が判明したら続報で補います。
たとえば、公開サイトが閲覧できないという報告を受けた直後なら、「現在、Webサイトの一部でページが開けない事象を確認し、調査しています。影響範囲と復旧時刻は確認中です。次回は15時に状況を更新します」という第一報が書けます。原因を推測して断定したり、根拠なく「すぐ復旧します」と約束したりする必要はありません。
この記事では、Webサイト運用担当者・制作会社・保守会社が使える一次報告の8項目、作成手順、顧客向け・社内向けのテンプレート、障害の種類別文例、続報への引き継ぎを解説します。月次レポートの作り方は一定期間の振り返りに、アラート設計は発見と連絡体制に分け、ここでは障害発生直後に何をどう伝えるかに絞ります。
Webサイト障害の一次報告書に必要な8つの項目
障害発生直後の連絡は、情報を詰め込みすぎると読み手が重要な内容を見失います。最小限の8項目を決め、まだ調査できていない項目は「確認中」「未定」と明記して、最初の報告を組み立てます。
| 報告項目 | 記載する内容 | 第一報での注意点 |
|---|---|---|
| 1．件名・区分 | 対象サービスと障害・調査中の別 | 未確認なら障害確定と書かない |
| 2．報告日時 | いつ状況を共有したか・JSTなど | 検知日時と取り違えない |
| 3．対象サービス | サイト名・機能・公開範囲 | URLを必要な範囲だけにする |
| 4．現象と影響 | 何ができないか・誰に影響するか | 不明な部分を推測で埋めない |
| 5．確認・発生時刻 | 最初に確認した時刻、発生時刻の確度 | 確認時刻を発生時刻と断定しない |
| 6．対応状況 | 調査中・暫定対応中など | 未着手なら対応中と偽らない |
| 7．復旧見込み | 判明していれば予定、なければ未定 | 根拠のない復旧時刻を約束しない |
| 8．次回更新・連絡先 | 次の情報提供時刻・掲載場所・担当窓口 | 復旧見込みとは区別する |
件名は対象サービスと現象を組み合わせる
件名は「Webサイトの障害に関するお知らせ（調査中）」のように、どのサービスのどの状態を伝えるのか分かる形にします。社内向けなら障害IDや担当部署を追記しても構いませんが、外部向けに機密の識別子を載せる必要はありません。
まだ障害が確認できていない場合は「一部のページが開きにくい事象を調査しています」など、把握できた症状を示しましょう。確証のない段階で「サーバー停止」「不正アクセス」と断言することは避けます。
確認日時と発生日時は分けて書く
「14時05分に監視から失敗を確認した」という事実があっても、障害が14時05分ちょうどに始まったとは限りません。定期監視のチェックとチェックの間に、実際の開始時刻が存在する可能性があります。
一次報告では「最初の異常確認：14時05分（JST）」「発生開始時刻：調査中」と分けて記載できます。利用者の報告時刻、監視の検知時刻、社内での確認時刻を混同しないことが重要です。
影響はユーザーの行動に置き換えて示す
「HTTP 503を確認」という技術情報だけでなく、「商品ページを開けない」「応募フォームへ進めない」「ログイン時にエラーになる」など、利用者が困ることを説明すると伝わりやすくなります。
影響対象が一部の環境か全体か未確認なら「一部のアクセスで」と書く根拠があるかを確認してください。範囲が分からないときは「影響範囲を調査中」と書き、全利用者に影響したと決めつけません。
原因・対応・次回の更新は同じものではない
障害原因が分からなくても、担当者が確認していることや、次の進捗を案内する予定は伝えられます。一次報告で重要なのは調査を認識した事実と、読者が次にいつ何を知れるかです。
Atlassianの障害時のコミュニケーション指針でも、早い周知、確認できた影響の簡潔な説明、継続的な更新を勧めています。原因が特定されるまで沈黙する方針を取る必要はありません。
一次報告書と続報・復旧報告・月次レポートの違い
報告書という名前でも、第一報・続報・復旧時の報告・月次報告は目的と作成のタイミングが異なります。第一報に根本原因分析や再発防止策の完成を求めず、段階に応じた情報を載せると実務で使いやすくなります。
| 段階 | 主な目的 | 優先して記載する内容 |
|---|---|---|
| 一次報告 | 異常の認識と現在の影響を伝える | 確認事項・対応・次回更新 |
| 続報 | 前回から何が変わったか知らせる | 追加で判明した影響・状況・見込み |
| 復旧確認の案内 | 利用可能になった状態を伝える | 確認した機能・時刻・継続監視 |
| 事後・原因報告 | 発生原因と対策を整理する | 原因根拠・再発防止・検証 |
| 月次レポート | 一定期間の状態を振り返る | 件数・傾向・前月比較・改善 |
一次報告は原因が未確定でも作成できる
発生直後に必要なのは、何が起きた可能性があり、どこに影響があり、誰が調べているかという事実です。根本原因が判明していなければ「原因調査中」と記載し、状況が変化したら続報で更新します。
一般的なインシデント管理でも、調査中・原因特定・修正後の監視・解決を区別します。Atlassian Statuspageの公式資料はこの状態区分を紹介しています。
障害速報は時系列の最初の記録に位置付ける
最初に何を確認し、どの時点で関係者に共有したかを記録しておけば、あとで情報が修正された際にも経緯を追えます。一次報告の内容を後から黙って書き換えるのではなく、必要に応じて版や更新時刻を残しましょう。
重要な更新は同じ障害IDや告知URLにひも付け、読者が古い情報と新しい情報を区別できる形にします。第一報だけで最終的な影響や発生原因が決まるわけではありません。
月次集計や停止時間の計算は別の目的
発生直後にチェックの失敗が2回見えても、正確な停止時間が2回分の監視間隔に一致するとは限りません。月次報告で扱う合計失敗回数や前月比較まで、第一報へ入れる必要はありません。
集計や比較はWebサイト監視の月次レポート、停止時間の計算は稼働率の計算方法に分けています。ここでは当面の利用者影響と状況共有へ集中します。
障害を認識してから一次報告を書くまでの5つの手順
第一報はすべてを調べた後の報告ではありませんが、確認していない内容をそのまま外部へ発信することも避ける必要があります。検知した内容と実際の状態を最小限確認し、共有すべき情報を整理してから文面を確定します。
手順1：監視通知や問い合わせの事実を記録する
監視画面の失敗、ユーザーからの問い合わせ、社内担当からの報告など、異常を知った入口を記録します。監視の場合は対象URL、チェック時刻、HTTPコード、タイムアウトなどの結果を確認します。
同じ時刻に複数のアラートが来ていても、すべてを別の障害と断定する必要はありません。まず対象と観測した症状を整理し、監視履歴の見方を参考に前後の結果を照合します。
手順2：利用者に起きる現象を安全に再確認する
公開トップページや重要な案内ページで、外部からアクセスできるか確認します。フォームや決済など状態が変化する処理を確認する場合は、権限と実施手順を確認し、本番への不用意なテスト送信を避けてください。
HTTP 503を得られた場合は「アクセスした際に503を確認」と書けます。一方でブラウザーや監視地点が違う場合は結果が変わる可能性があります。完全停止か一部影響か断定できないときは、その範囲を未確認として残します。
手順3：確認済み・未確認・仮説を三つに分ける
確認済みには「14時05分のチェック失敗」「問い合わせページを開けないことを確認」を入れます。未確認には「すべての利用者に影響しているか」「個人情報に関係する事象か」を置きます。仮説には「直前の設定変更が影響した可能性」などを置きます。
一次報告に書く中心は確認済みと未確認です。社外へ仮説を出す場合は必要性と根拠を慎重に判断し、「原因は調査中」以上の断定を急がないことが大切です。
手順4：対象読者に合わせて必要事項を短く書く
顧客向けには、使えないサービス、利用者に必要な対応、現在の調査状況、次回の更新を優先します。社内向けには障害ID、監視結果、担当者、確認済み範囲、技術調査の窓口などを追記できます。
すべての相手へ同じ詳細ログや管理画面URLを渡す必要はありません。社内に共有する非公開URL・顧客情報・認証情報が、外部向けの文章へ混入していないか確認しましょう。
手順5：内容の確認者と次回の更新時刻を決める
一次報告の文面は、できれば障害対応責任者やサービス管理者が確認し、組織の承認済みルールに従って案内します。復旧時刻が分からなくても、次に状況を知らせる時刻は運用に応じて設定できます。
「15時までに復旧」ではなく「15時に次の状況をお知らせ」と書けば、根拠のない復旧の約束になりません。送信・公開は権限を持つ担当者の判断で実施し、記事の例文を自動送信するものではありません。
顧客向けWebサイト障害の一次報告書テンプレート
対外向けの一次報告は、原因を詳しく説明するよりも、影響を受ける利用者が必要な情報を早く把握できることを優先します。以下はコピーして編集できる例文です。架空のサービス名・時刻を自社の事実に置き換えてから使ってください。
サービスが利用できない場合の第一報文例
全体または重要な機能へのアクセスが難しいと確認できた場合は、確認した範囲でサービス停止の状態を説明します。復旧時刻が未確定なら未定と記載し、次回更新時刻を明示します。
一部の機能だけが使えない場合は「サービス全体が停止しています」と書かず、影響する機能に限定します。確認済みの範囲と、調査中の内容を分けて伝えることが重要です。
一部の機能が使えない場合の第一報文例
問い合わせフォームだけが利用できない場合は、通常の閲覧ができるかどうかを別に確認します。確認できた症状を具体的に書き、フォーム送信以外の機能については未確認であれば断定しません。
利用者に代替手段がある場合でも、それが実際に機能し、適切な管理者が承認した方法かを確認するまでは案内を控えます。確かな代替手段がないときは無理に案内する必要はありません。
調査が始まった段階の短い告知文例
初回の症状しか確認できていない段階では、短い文章で「事象を認識した」「調査を開始した」「次の更新を案内する」を伝える方法があります。原因と影響範囲が確認中であることを明示すれば、何も案内しないより状況が分かりやすくなります。
Atlassianの一次・続報テンプレートでも、調査段階と障害確定後の説明が分かれています。自社サイトの現状に合わせて必要な部分だけを使い、根拠のない説明は加えません。
【障害に関するお知らせ（調査中）／架空の例】
2026年9月18日14時05分（JST）ごろ、当社Webサイトの一部ページにアクセスしづらい事象を確認しました。現在、影響範囲と原因を調査しています。復旧見込みは現時点で未定です。次回は14時30分に本ページで状況をお知らせします。ご不便をおかけし、申し訳ございません。
【お問い合わせフォームの不具合／架空の例】
現在、お問い合わせフォームから送信を完了できない事象を確認しています。原因と影響範囲を調査中です。復旧見込みは未定で、次回は15時に最新情報をお知らせします。その他の機能への影響については確認を進めています。
【検知直後・調査中／架空の例】
当社Webサイトへのアクセスに関して、一部の環境で正常に表示できない可能性を確認し、調査を開始しました。影響範囲と復旧見込みは確認中です。続報は確認ができ次第、あらためてご案内します。
社内向け一次報告書は技術情報と対応の担当を明確にする
社内向けには顧客向けの状況説明に加え、対応チームが同じ事象を追える情報が必要です。障害ID、観測結果、サービス影響、確認済み事項、未確認事項、対応者、次回の更新予定を整理します。
| 社内一次報告の欄 | 説明用の記入例 | 確認すること |
|---|---|---|
| 障害ID | INC-20260918-001（架空） | 他の障害と区別できるか |
| 最初の確認 | 2026年9月18日14:05 JST | 検知か実発生かを区別 |
| 対象 | 企業サイトの公開問い合わせ入口 | URLと権限を区別 |
| 症状 | 複数のGETでHTTP 503を確認 | 監視結果と再現条件 |
| 影響範囲 | 公開問い合わせページ、詳細は調査中 | どの利用者に影響するか |
| 状況 | 調査中・復旧未確認 | 原因を断定していないか |
| 担当 | 一次対応：Web運用担当 | 責任者と作業権限の範囲 |
| 次回更新 | 14:30 JSTに社内チャネルへ | 誰がどこへ記載するか |
障害ID・確認時刻・対象を冒頭へ書く
複数のサイトや部門を管理する組織では、障害IDとサービス名を最初に示すと、同じ障害についての複数の連絡を結び付けやすくなります。時刻にはJSTなどのタイムゾーンを添え、監視のチェック時刻と社内で認識した時刻も分けます。
複数の監視URLが同時に失敗した場合、複数の障害なのか一つの共通原因なのかが未確定なら、ひとまず関連する事象として整理する方法があります。発生原因は後から根拠を確認して記載してください。
観測結果と作業を分けて書く
「HTTP 503を3回取得した」は観測結果、「CDN設定の確認を依頼した」は対応の実績、「データベースが原因と思われる」は仮説です。三つを同じ文章に混ぜると、後から状況を追いにくくなります。
たとえば「CDNの影響と考えられるため、データベースを再起動した」など、原因の根拠が弱いまま本番操作を指示する表現は避け、権限を持つ担当者の判断と変更の記録を残してください。
担当者・エスカレーション・更新先を明確にする
一次対応者、障害対応の責任者、サーバー側を確認できる担当者を区別すると、誰へ質問や確認をすべきかが分かりやすくなります。社内の連絡先やインシデント管理ツールを用いる場合は、関係者だけが閲覧できる範囲で共有します。
通知条件や連絡順の詳細な設計はWebサイト監視のアラート設計にまとめています。本記事は実際に連絡を行うときの情報の書き方に限定します。
顧客への案内内容を社内記録と一致させる
社内では原因の候補がいくつか出ている場合でも、対外的には確認済みの事実を中心に伝えます。社内の調査メモをそのまま転載すると、未確認の仮説や機密情報が公開される可能性があります。
外部向けの告知URLや内容を社内の障害IDへひも付け、続報と食い違わないようにします。承認者が定められている場合には、承認前の内容を無断で送信・公開しないことも重要です。
【社内一次報告／架空の例】
障害ID：INC-20260918-001
対象：企業サイト・公開問い合わせ入口
最初の確認：2026年9月18日14時05分 JST（HTTP 503）
再確認：14時08分に同URLでHTTP 503
影響：公開問い合わせ入口でのエラーを確認。その他の範囲は調査中
発生開始・原因・復旧見込み：未確認
対応：Web運用担当が調査中
次回社内更新：14時30分 JST
一次報告の記載例。発生直後の架空の障害を時系列で示す
以下は2026年9月18日に架空の企業サイトで障害が発生したという説明例です。監視結果から実際の停止開始時刻が分からないことを前提に、最初の確認から一次報告までに伝えられる情報を整理しています。
| 時刻（JST） | 分かったこと | 第一報での扱い |
|---|---|---|
| 14:05 | 公開問い合わせ入口の監視がHTTP 503 | 最初の異常確認時刻として記録 |
| 14:08 | 担当が公開URLを再確認し503を確認 | 再現できた症状として記録 |
| 14:12 | Web運用担当が原因と影響範囲を調査開始 | 調査開始を明記 |
| 14:15 | 一次報告を作成・確認 | 報告時刻として記録 |
| 14:30 | 次の状況更新を予定 | 復旧見込みとは別に明記 |
14:05は障害の開始時刻とは限らない
14:05のHTTP 503が最初の確認だったとしても、その前の監視チェックが正常だった時刻から14:05までのどこで利用不能になったかは分かりません。第一報には「最初の異常確認」と書き、正確な発生時刻が不明なら調査中とするのが適切です。
監視間隔によって確認できる範囲は変わります。短い停止や地点別の不具合など、監視で分からない部分を決めつける必要はありません。
14:08に再確認できた症状をそのまま記載する
担当者が公開問い合わせ入口をGETで確認し、HTTP 503を再現できたなら「公開問い合わせページへのアクセスでエラーを確認」と書けます。フォーム送信の完了可否までは確認していない場合、その部分を正常・異常のどちらとも断定しません。
利用者にとって分かりやすい表現を優先し、技術的なHTTPコードは補足にとどめることもできます。端末・地域などに差がありそうでも、データがそろうまでは影響範囲を調査中とします。
14:15の第一報では復旧見込みを未定と記載できる
まだ原因の切り分けができていなければ、14:15の段階で復旧時刻は分かりません。その場合は「復旧見込みは現時点で未定」と記載し、14:30に次回の状況を更新することだけを案内します。
更新予定が14:30でも、その時刻に復旧するという約束ではありません。進展がない場合でも「調査を継続しています」と状況を更新できるようにしておきます。
例文の日時・症状を実際のデータに置き換える
ここで示したHTTP 503や日時はすべて架空のものです。実際の現場で採用するときは、観測ログ、運用担当の確認、現在の提供状況を照合し、影響がないと分からない項目を誤って「影響なし」と書かないようにします。
他社の障害報告や顧客向けお知らせを見本にする場合も、障害内容や対応状況の文章をそのまま使わず、自社で確認できた事実に基づき書き直してください。
障害の種類に応じた一次報告の書き分け
「Webサイトが使えない」という表現が適切かどうかは、停止している範囲によって変わります。サイト全体、ページの一部、ログイン、フォーム送信、表示の遅延など、実際に確認できた現象に合わせて言葉を選びましょう。
| 確認できた現象 | 利用者向けの表現例 | 避けたい断定 |
|---|---|---|
| サイト全体に接続できない | Webサイトにアクセスしづらい状態を確認 | 全利用者で完全停止と決めつける |
| 一部ページで503 | 一部ページの閲覧でエラーが発生 | すべての機能が停止した |
| ログイン時にエラー | ログインできない事象を確認 | アカウントデータが消失した |
| フォーム送信で失敗 | フォームの送信が完了しない事象を確認 | すべての送信データが消えた |
| 表示が極端に遅い | ページ表示に時間を要する事象を確認 | サーバーCPU不足が原因 |
| 監視チェックだけ失敗 | 外部監視で接続失敗を検知し調査中 | 全サイトの障害が確定 |
サイト全体の接続失敗は確認条件を添える
公開URLへアクセスできない状況が複数の方法で確認できた場合、閲覧への影響を第一報で説明します。ただしアクセス元の回線や地域によって異なる可能性があるため、全利用者への影響が確定していないときはその旨を区別します。
障害の重大度はサイトの役割により異なります。ECや申込サイトなど利用者の重要な操作ができない場合、報告の優先度を高くすることがありますが、重大度区分は各組織の運用方針で決めます。
フォームやログインは動かない操作を具体的に書く
「サイトが落ちています」ではなく、「ログイン処理を行うとエラーになる」「問い合わせフォームの送信を完了できない」と書く方が影響を正しく伝えられることがあります。閲覧だけはできる場合には、正常と確認した範囲も慎重に示します。
決済や申込が完了できなかった利用者に対して再操作を促す場合、二重課金・二重申込を防ぐ確認が必要です。安易に「もう一度送ってください」と案内することは避け、担当者が安全な手順を確認してから判断してください。
表示の遅延は通常の監視成功と両立する場合がある
HTTPステータスが200でも応答時間が極端に長くなり、利用者が使いにくい状態になることがあります。ページを表示できているかだけでなく、何の操作に時間がかかっているのかを確認できた範囲で報告します。
遅さの原因は回線、アプリケーション、外部サービスなど複数あり得ます。200 OKでもサイトに不具合がある理由では、その検査範囲を別に解説しています。
監視通知だけの段階では障害を確定扱いしない
一度のタイムアウトは、一時的な通信失敗や観測地点の問題などで起こることもあります。監視で失敗を検知したが、利用者影響がまだ確認できていない場合は、第一報の状態を「調査中」とする方法があります。
死活監視の誤検知を減らす方法は判定条件の設計に限定しています。本記事では一次報告を作る時点の確認済み・未確認の言い分けを扱います。
復旧時刻が分からない場合と次回更新の伝え方
一次報告では復旧時刻が分からないことも珍しくありません。そこで無理に完了時刻を予想するより、現時点で未定であることと、次にいつ状況を知らせる予定かを分けて伝える方が誤解を防げます。
復旧見込みは「未定」「調査中」と明記してよい
根拠なく「数分で直ります」「本日中に復旧します」と書いて守れない約束をすると、さらに利用者を混乱させることがあります。判明していないなら「復旧見込みは現時点で未定です」と示し、調査を進めている事実だけを伝えます。
復旧見込みを案内できるようになった場合も、見込みと確定時刻を区別します。実際の復旧を確認するまでは、予定時刻をもって解決済みと表示しないでください。
次回の状況更新は復旧予定とは別に伝える
「14時30分を目安に次の状況を案内します」は、復旧の約束ではなく連絡の予定です。次回更新の間隔は影響度や対応体制で決めます。すべての事象で一律に15分や30分が正しいわけではありません。
Atlassianの公式解説は、復旧が終わる時刻を約束するのではなく、次に状況を知らせる時刻を伝える重要性を説明しています。
続報で新しい情報がないときも状況を更新する
次回更新時点で原因が判明していなければ、「引き続き調査中」「影響範囲は調査を継続中」など事実を伝えることができます。毎回新しい原因や復旧時刻を出す必要はありません。
ただし「進展なし」という表現だけでは読み手が不安になる場合があります。調査継続の事実と次回の更新予定を伝え、必要なら現在の暫定対応が継続中かを確認してください。
予定した更新時刻が守れない場合は変更を案内する
調査が長引く場合や連絡担当者が交代する場合、予定した更新の時刻や場所が変わる可能性があります。できる範囲でその変更を知らせ、複数のチャネルで案内している場合は時刻の整合性を確認します。
次回の案内時刻に確実に担当できる人がいるかも運用上の確認点です。設定した時刻が形式だけのものにならないよう、実行できる体制に合わせて決めてください。
公開サイト・メール・社内チャネルで情報をそろえる
障害情報を複数の場所で伝える場合、確認できた事実と更新時刻が食い違うと利用者を混乱させます。媒体ごとの文章の長さは違っても、障害の対象・現状・次回更新の情報は同じ内容を基準にすると管理しやすくなります。
ステータスページやお知らせ欄は現状の正本として使う
一般向けのお知らせ欄や障害情報ページで、現在のサービス状態と最終更新時刻を確認できるようにする方法があります。第一報・続報・復旧案内が同じ障害を扱うことが分かるよう、件名や障害IDの対応を取ります。
複数の担当者が同時に告知を編集する場合、どの文章が最新か決まっていないと矛盾が発生します。更新責任者と承認手順を定め、公開範囲を確認してから反映することが重要です。
メールは要点と確認先を短く示す
顧客へメールで案内する場合は件名で障害の対象が分かるようにし、本文は現象・影響・対応・次回更新を中心にまとめます。詳細情報や頻繁な変更は、認められた障害情報ページのURLを案内して参照できるようにする方法があります。
ただし公開していない情報ページを勝手に紹介したり、確認のない外部宛先へ自動送信したりしないようにします。ここで示すのは文面の作成方法であり、実際の送信は権限を持つ担当者が判断します。
社内では作業情報と対外説明を別に管理する
社内チャットや障害対応の管理ツールには、調査担当、詳細ログ、確認済み事項、変更操作の履歴などの技術情報を残せます。顧客向けの説明と共有目的が異なるため、同じ情報量を両方へ流す必要はありません。
障害対応チームの詳細な仮説や未確認の原因は、確定する前に外部向けへコピーしないことが重要です。逆に、顧客向けにすでに案内した時刻・影響範囲は社内で参照できるようにして、整合性を保ちます。
更新情報には時刻と変更点を付ける
障害案内ページに15時更新の表示があっても、前回から何が変わったか分からないと読み手が混乱することがあります。「15時更新：原因は引き続き調査中。影響範囲に変更は確認されていません」など、変更点または継続中の状況を明示します。
最新の情報を上へ置くか、時系列で並べるかは媒体によりますが、以前の記載を意図せず消して経緯が追えなくならないよう、更新履歴を残すことが望まれます。
一次報告で避けたい表現と安全性の注意点
一次報告の誤りは、早く伝えようとして未確認の内容を断定する場面で起きやすくなります。原因、復旧時刻、影響範囲、情報セキュリティについて、何を確認したかに合わせて慎重に書きましょう。
| 避けたい表現 | 何が問題か | 代わりの表現例 |
|---|---|---|
| 原因はサーバー障害です | 原因が未特定なら断定 | 原因を調査中です |
| 必ず15時までに復旧します | 根拠のない完了約束 | 15時に状況を更新します |
| すべてのユーザーに影響しています | 範囲が未確認かもしれない | 影響範囲を確認しています |
| 個人情報の流出はありません | 調査前に安全性を保証 | 関連する影響の有無を確認中です |
| 障害は14:05から始まりました | 最初の検知と開始を混同 | 14:05に初めて異常を確認しました |
| 現在はすべて復旧しています | 一部しか再確認していない | 確認した範囲で復旧を観測しました |
原因を断定する前に根拠を確認する
HTTP 500系や接続タイムアウトを見ただけでは、アプリケーションのバグ、サーバー・CDN・DNS・ネットワークのどこに原因があるかは断定できません。直前に公開作業があっても、それだけで当該作業が原因とは限りません。
原因の可能性は社内で調査していても、対外向けの一次報告では「原因は調査中」と説明する方法があります。確定した後に必要な範囲で補足する方が、後から誤った情報を訂正するリスクを減らせます。
情報漏えいや不正アクセスの有無を安易に否定しない
単にサイトが表示されないという現象から、個人情報への影響がないと証明することはできません。調査に必要な根拠がまだない段階では、流出や不正アクセスの可能性を無条件に否定しないようにします。
反対に、根拠なしで流出や侵入があったと断定することも避けます。もしセキュリティインシデントが疑われる場合は、組織の専門担当へ速やかに引き継ぎ、必要な保存・報告・法令対応を判断してもらってください。
利用者の再操作を促す前に副作用を確認する
申込や決済の障害時に「もう一度送信してください」と案内すると、以前の操作が裏側で完了していた場合に二重申込や二重課金を招く可能性があります。まず処理の状態や安全な代替方法を確認する必要があります。
外部向け一次報告に暫定的な利用方法を載せる場合は、適切な担当者が実際に使えることを確認し、情報の安全性も考慮したうえで案内してください。
謝罪と事実の説明を両立させる
利用者に不便が発生している場合、状況への配慮を示しつつ、対象・現象・現在の対応を明確に伝えることが重要です。謝罪だけを繰り返して原因や見通しを説明しない文章は、読者が次に何をすればよいか分からなくなります。
利用者に関係のない内部の技術用語や責任の押し付けは避けます。外部のサービスが関係している可能性があっても、自社で把握している利用者影響を中心に説明してください。
エンリンクの監視情報を一次報告の根拠に使う方法
エンリンクの公式機能一覧には、HTTP/HTTPS定期監視、直近チェックのHTTPステータスと応答時間、障害・復旧の履歴、監視チェック履歴などが案内されています。一次報告で「どの時刻に何を確認したか」を整理する手掛かりになりますが、原因の自動確定や対外報告の自動送信機能が提供済みという意味ではありません。
監視履歴から「最初に確認した時刻」を探す
エンリンクの機能一覧にはチェック日時・結果・HTTPコード・応答時間・判定理由を時系列で確認する機能が案内されています。障害を疑った場合、前後のチェック結果を見てどのURLでいつ失敗が観測されたかを整理する参考になります。
ただし定期チェックの間で障害が始まっていた可能性があるため、チェックで初めて失敗した時刻を発生開始時刻と同一視しないようにします。また他の地域での利用可否や会員機能の全操作を保証するものでもありません。
障害・復旧履歴と現在の状態を区別する
障害の可能性が記録された時刻と、復旧を確認した時刻を履歴として確認できると案内されています。現在進行中か、監視で成功が確認されたかを追う資料として利用できます。
成功チェックが1回返っても、その時点ですべての利用者・機能について復旧したとは限りません。一次報告では「現在調査中」など確認済みの範囲に合わせ、復旧案内は必要な再確認を行ってから記載します。
エンリンクが自動的に一次報告書を配信するとは記載しない
公開機能一覧では、顧客向け一次報告書の自動生成、外部メールの一斉送信、対外ステータスページへの自動掲載などを提供済みの機能として確認できません。監視結果を参考に、担当者が必要な文面を作成する方法として案内します。
また月次PDFレポートなどの将来構想があっても、それを現在の一次報告の自動作成機能と同一視しないようにします。外部への送信や公開には必ず適切な権限と明示的な操作が必要です。
無料枠と監視頻度の制限を踏まえて時刻を扱う
エンリンクの現行料金プランでは、無料は5サイトまで1日2回、スタンダードは20サイトまで15分間隔、ビジネスは50サイトまで5分間隔、プロは100サイトまで1分間隔と案内されています。これらは設定可能な監視頻度であり、障害が必ずその時間内に見つかるという保証ではありません。
最大5サイトまで無料でエンリンクを始める場合も、監視で確認した結果の時刻と、担当者が障害を認識した時刻を区別して一次報告へ記載することが大切です。
一次報告書を送る前のチェックリスト
文章が短くても、確認済みの情報と未確認の項目を区別できていれば、実用的な第一報になります。共有前には対象、症状、時刻、状況、次回更新と、送信先・機密情報の扱いを点検しましょう。
| 確認項目 | OKの判断基準 | 未確認時の扱い |
|---|---|---|
| 対象サービス | サイト名・対象機能が明確 | 対象範囲は調査中と記載 |
| 日時の意味 | 検知・確認・報告を分けた | 発生開始は不明と記載 |
| 利用者の影響 | 実際の症状を説明 | 影響範囲は確認中と記載 |
| 対応状況 | 担当者が行った作業・調査が事実 | 対応予定と実施済みを分ける |
| 復旧見込み | 根拠のある見込みだけ記載 | 未定と明示 |
| 次回更新 | 担当者と時刻・場所が定まる | 決まり次第案内とする |
| 情報の安全性 | 機密URL・トークン・個人情報がない | 共有前に確認・削除 |
| 送信・公開の承認 | 組織の権限と運用ルールを満たす | 承認まで外部送信しない |
一次報告が遅れないよう事前に文例を整備する
障害が実際に起きてから白紙で文面を作ると、必要事項を落とす可能性があります。対象サービス名・確認時刻・現象・影響・対応・復旧見込み・次回更新・問い合わせ先の枠を作り、確認した値へ置き換える運用が考えられます。
ただしテンプレートに過去の障害の時刻や原因が残っていると誤送信の原因になります。文例は公開や送信前に必ず確認し、今回の障害と異なる項目を削除してください。
複数チャネルへ出す場合は一本の確定情報を参照する
メール・サイトのお知らせ・社内チャットなどに情報を出す場合、更新時刻や影響範囲が違う説明にならないよう注意します。事実の正本となる最新の確認メモを管理し、各媒体の文章を作成します。
更新を重ねると最初の文面に書いた情報が古くなるため、変更箇所と更新日時を分かるようにします。外部向けは必要最小限、社内向けは原因調査に必要な詳細という役割分担も維持してください。
第一報を出した後の更新担当まで確保する
障害の第一報だけを出して続報の担当が決まっていないと、約束した更新時刻に新しい案内が出せない可能性があります。文面を作る人と、次の確認をする人を事前に決めておくことが重要です。
次回更新の時点で原因が判明していなくても、その時点の確認済み事項と調査継続を伝えることができます。正確さを保ちながら、読者が見通しを持てるようにしましょう。
Webサイト障害の一次報告についてよくある質問
実際に障害を認識した直後は、何をどこまで書いてよいか迷いやすくなります。原因が不明な場合、影響範囲が限定されている場合、復旧見込みが分からない場合などを確認します。
原因が分からなくても一次報告を出してよいですか？
はい。異常を認識して調査を開始した事実と、確認できている影響を伝えることができます。原因が分からない場合は「原因調査中」と明記し、推測を事実として説明しないことが重要です。
対外向けには影響する利用者が知りたい内容を優先し、社内では技術調査の内容を分けて記録してください。
障害の発生時刻が不明な場合はどう書きますか？
「14時05分に最初の異常を確認」「障害の発生開始時刻は調査中」のように書き分けます。監視のチェック時刻や利用者からの報告時刻だけでは、正確な発生開始時刻が分からない場合があります。
チェックの失敗が続いた回数を監視間隔と掛けただけで、実際の停止時間だと断定しないようにしてください。
復旧予定が未定でも次回更新時刻は必要ですか？
予定を示せるなら、復旧見込みとは別に次回の情報提供予定を案内すると、利用者が見通しを持ちやすくなります。予定は担当者が実行できる範囲で決めることが重要です。
状況が変わらない場合でも、引き続き調査中であることや追加で確認できた点を案内できます。
メールだけで一次報告を出してよいですか？
連絡手段は顧客との契約や自社の運用によります。メールだけで十分な場合もありますが、多数の利用者へ同じ情報を伝える必要があるときは、障害情報ページなどで最新状態を示す方法も考えられます。
複数チャネルを使う場合は内容と更新時刻を揃え、権限のない外部送信や無承認の公開を行わないことが必要です。
一部機能の障害でも第一報は必要ですか？
影響の大きさによります。問い合わせ・ログイン・購入・応募など重要な機能が利用できない場合、サイト全体が表示されていても利用者への影響は大きい可能性があります。
「一部機能でエラーを確認」と対象を限定し、分からない範囲は調査中と説明する方法があります。
個人情報の漏えいがないと断定してもよいですか？
確認に必要な調査が完了していない限り、漏えいや不正アクセスがないと断定するのは避けてください。障害の原因と情報セキュリティの影響は別々に確認する必要があります。
疑わしい兆候がある場合には組織のセキュリティ担当者へ引き継ぎ、適切な対応を判断してもらいます。
報告先が顧客と社内で違う場合はどうしますか？
顧客向けは利用者への影響、対応状況、次回更新を中心に短く書き、社内向けは障害ID、監視結果、調査担当、未確認の範囲などを追加します。
説明の詳しさは変えても、確認時刻や影響の事実が食い違わないようにしてください。
月次報告や障害原因報告と一緒にしてもよいですか？
目的が異なるため、発生直後の一次報告は独立して短くまとめる方が読みやすくなります。詳細な原因分析、再発防止策、長期間の集計は情報が揃った段階で別資料に整理します。
月次レポートの作り方は定期報告の作成方法を扱っており、本記事とは検索意図を分けています。
エンリンクで一次報告を自動送信できますか？
公開の機能一覧では監視結果と障害・復旧履歴の確認は案内されていますが、顧客向け一次報告書を自動作成・一斉送信する機能は確認できません。
監視履歴を根拠に文面を作る場合も、外部への公開や送信は適切な権限・確認を伴う別の行為です。
まとめ：一次報告では確認できた影響と次回更新を優先する
Webサイト障害の第一報は、原因の完全な分析ではなく、異常を認識したことと現在の状況を、利用者に誤解なく早く伝えるためのものです。対象・影響・対応・復旧見込み・次回更新を短く整理し、未確定事項を明示することが重要です。
原因が分からなくても確認済みの事実は伝えられる
最初の異常確認時刻、影響が見えている機能、現在の調査状況を記載し、発生開始時刻や原因が未確認ならそのまま明示してください。推測で補足したり、利用者が困っている機能を曖昧にしたりする必要はありません。
復旧を確認した段階では続報や復旧案内に切り替え、事後の原因分析や月次集計は適切な別資料にまとめましょう。
監視履歴は一次報告の事実確認に役立つ
エンリンクではHTTP/HTTPS監視結果、時刻、コード、応答時間、障害・復旧履歴などを確認する機能が案内されています。機能一覧で確認できる範囲を把握し、第一報に記載する事実の裏付けとして利用できます。
エンリンクは最大5サイトまで無料で利用開始できます。定期監視の結果と人が確認した症状を区別し、必要な情報を整理してから一次報告を作成しましょう。
参考にした一次資料：Atlassian「インシデント対応ハンドブック」、Atlassian Statuspage「Incident communication tips」、Atlassian「Incident communication templates」、Atlassian Statuspage「Create an incident」、Google SRE「Managing Incidents」（確認日：2026年10月24日）。
