3行でいうと

  • 公開される報告書には、おおまかな型があります。要約、影響、時系列、原因、復旧、再発防止です。GoogleのSRE Bookは、これに加えて、検知の方法と「うまくいったこと、まずかったこと、運がよかったこと」を書く例を示しています。
  • 公開の基準や形式は会社ごとに違います。AWSは「広範で重大な影響」が出た場合に公開すると基準を書き、Google Cloudは暫定の報告と最終の報告を分けて出す形が見られ、Anthropicは複数の問題が重なった経緯を1つの技術記事としてまとめています。
  • 報告書は「全部を書いたもの」ではありません。時刻のタイムゾーン、影響の割合の分母、担当者や期限の有無は、読む側が自分で確かめる必要があります。

この記事では、これらの報告書を要約の形で読んだだけで、隅々まで確かめたわけではありません。この記事は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。報告書の読み方は、読者の立場（利用者、開発者、情報システム担当）によって変わります。この記事は助言ではなく、公開資料を読んだ範囲のまとめです。

先に結論

前提：報告書の種類

「事故報告書」と呼ばれるものには、少なくとも3種類があります。

種類 読み手 例
組織内のポストモーテム 社内の担当者 SRE Bookの例（担当者、行動項目の担当と状態まで書く）
状況更新（ステータスページ） 利用者 Google Cloudの事件ページの短い更新、各社のステータスページ
公開の事後報告 利用者と一般 AWSのPost-Event Summary、Google Cloudの「Incident Report」、Anthropicの技術記事

この記事が主に扱うのは、3つ目です。1つ目は、公開の事後報告の「元になる型」として読みます。

型を知る：SRE Bookの例

GoogleのSRE Book（第15章と付録D）は、ポストモーテムを、インシデントの影響、緩和と解決、根本原因、再発を防ぐ行動を記録した文書、と説明しています。目的は、完全な記録、すべての寄与原因の理解、効果的な再発防止です。

付録Dの例の見出しを、次にまとめます。

SRE Bookの例のポストモーテムの項目（2026年10月16日に確認）

公式の例（例として載っているインシデント「Shakespeare Sonnet++」）にある項目です。

  • ヘッダー：Date（日付）、Authors（書いた人）、Status（状態）、Summary（要約）、Impact（影響）、Root Causes（根本原因）、Trigger（引き金）、Resolution（解決）、Detection（検知）。
  • Action Items（行動項目）：表で、行動の内容、種類（mitigate＝被害を減らす、prevent＝防ぐ、process＝手順、other）、担当者（Owner）、バグ番号を書き、各行に完了（DONE）か未了（TODO）がつきます。例の表に、優先度の列はありませんでした。
  • Lessons Learned：What went well（うまくいったこと）、What went wrong（まずかったこと）、Where we got lucky（運がよかったこと）の3つ。
  • Timeline：時刻はUTCで、「HH:MM」と出来事を並べます。OUTAGE BEGINS（停止の開始）、INCIDENT BEGINS（インシデントの開始）、OUTAGE MITIGATED（緩和）、OUTAGE ENDS（停止の終了）、INCIDENT ENDS（インシデントの終了）が目印です。インシデントの終了は、30分間正常だったあと、とされています。
  • Supporting information：補足の情報。
  • 脚注に、根本原因の掘り下げ方（「5 Whys」）と、早まった行動項目は極端になりうる、という注意があります。

SRE Bookの本文は、ポストモーテムを書くきっかけの例も挙げています。利用者に見える停止や劣化が閾値を超えた、データの損失があった、オンコール（当番）の担当者が介入した（ロールバックや経路の変更）、解決に時間がかかった、監視が失敗して人が手作業で気づいた、などです。

ここで気づくのは、組織内の型には「担当者」「行動項目の担当」「状態」が入っていることです。次に見る公開の報告書では、僕らが読んだ範囲で、これらが同じ形では載っていませんでした。理由は公式の文書には書かれていません。社内向けの文書と、外に出す文書とでは、書く目的が違うからではないかと思います（見立てです）。

公開の報告書の構成を、3つ並べる

次の表は、各社の公開ページを読んで、構成の形だけを並べたものです。個々の事故の原因や良し悪しには触れません。

AWS（Post-Event Summary） Google Cloud（事件ページ） Anthropic（技術記事）
公開の基準 「広範で重大な顧客への影響」が基準として書かれている 履歴ページに事件が並ぶ。暫定か最終かの見分け方は、そのページには書かれていない 基準は読んだページに書かれていない
時刻 PDT（太平洋夏時間） US/Pacific 読んだ要約では、日付が中心
構成 概要、サービスごとの節、結び 状況更新の積み重ね、暫定報告、最終報告 序文、提供の仕組み、時系列、3つの問題、技術的な深掘り、検知が難しかった理由、変更点
影響の書き方 サービスごとに、開始と終了、症状 影響を受けた場所、サービス、期間 問題ごとに、日付、影響したモデル、割合（ある問題のみ）
再発防止 結びの直前の段落にまとめて 「Remediation and Prevention」の節 「What we're changing」の節

AWSの一覧のページは、公開の約束と対象を説明しています。重大な割合のコントロールプレーンAPIの失敗、サービスの重大な割合の資源への影響、電源やネットワークの大きな障害、などが例に挙がっています。要約は少なくとも5年間閲覧でき、アーカイブは2011年4月からあります。対象に当たらない事故をどう扱うかは、そのページには書かれていません。

Google Cloudの事件ページでは、短い状況更新が時刻順に積まれ、その後に「Preliminary Incident Report」（暫定報告）と「Incident Report」（最終報告）が加わる形でした。暫定の報告には、情報が改訂されうること、包括的な報告があとに続くことが書かれています。暫定のほうが「Preliminary Root Cause」（暫定の根本原因）、最終が「Root Cause」と、原因の見出しも変わります。つまり、暫定の報告に書かれた原因は、最終の報告で変わる可能性を前提にした文書です。

Anthropicの記事は、1つの事故ではなく、重なった3つの問題を扱っています。それぞれに日付、影響したモデル、解決の日が書かれ、ある問題には影響の割合（当初と最悪の時間帯）が出ている一方、別の問題には、読んだ要約では割合の記載が見当たりませんでした。「割合がない」ことを隠している、と読むのではなく、測れなかった、またはまだ分からなかった、という書き方の違いとして見るのが公平だと思います。

読み方の順番：7つの問い

ここからは僕らの見立てです。公式が「こう読め」と書いているわけではありません。

1. 自分に当たるか

報告書の冒頭で、日時、地域、サービス、モデルの名前を見ます。AWSやGoogle Cloudの報告書は、地域（us-east-1、us-west1など）を明記します。自分が使っていない地域なら、読み飛ばしてよい場合があります。ただし、AWSの報告書には、他の地域にも影響が及んだ例（資格情報の問題や、複製の遅れ）が書かれていました。地域が違っても、サービスの種類によっては確かめる価値があります。

2. 時刻のタイムゾーンを揃える

AWSはPDT、Google CloudはUS/Pacific、SRE Bookの例はUTCでした。日本時間に直す必要があります。日本標準時（JST）は、夏時間の期間のPDTより16時間進んでいます（この換算は一般的な時差で、報告書の記載ではありません）。夏時間の切り替えの時期をまたぐ事故では、換算を間違えやすくなります。

報告書の中で、時刻が複数出てくることもあります。僕らが読んだGoogle Cloudの事件ページの取得結果では、ページ上部の開始時刻と、報告書の説明にある影響の開始時刻が、30分以上ずれて見えました。これは取得結果の要約で、原文で確かめていませんし、定義の違い（監視が検知した時刻と、影響が始まった時刻など）かもしれません。ですから、自分のログと突き合わせるときは、定義が書かれているかを探します。

3. 影響の「分母」を見る

「X%の要求に影響」という書き方は、何の中の何%かで意味が変わります。全体の平均か、最悪の1時間か、特定のモデルや特定のプラットフォームか。Anthropicの記事は、ある問題について、当初の割合と最悪の時間帯の割合を書き分けていました。分母が書かれていない数字は、そのまま比べないほうがよいと思います。

4. 引き金と根本原因を分ける

SRE Bookの例は、Trigger（引き金）とRoot Causes（根本原因）を別の項目にしています。引き金は「最後の一押し」、根本原因は「そうなる状態が前から潜んでいたこと」と読めます。Anthropicの記事は複数の問題が重なったと説明し、Google Cloudの報告書は、予定された保守と、自動の迂回が想定どおりに働かなかったことを書いていました。型は同じでも、原因の形はさまざまです。「原因はこれ1つ」と読まず、重なりの形を見るのが大事だと思います。

5. 検知の節を探す

SRE Bookの型には、Detection（どう気づいたか）の項目があります。Anthropicの記事には、検知が難しかった理由の節があり、評価が利用者の報告した劣化を捉えなかったこと、プライバシーの管理のため、エンジニアが利用者のやり取りを見にくかったこと、症状がプラットフォームごとに違ったことが書かれていました。利用者の側から見ると、この節は「自分の側で何を監視すればよいか」のヒントになります。

6. 再発防止の「具体さ」を見る

「監視を強化する」のような抽象的な文と、「この検知テストを加える」「この手順を変える」のような具体的な文は違います。SRE Bookの型は、行動項目に種類、担当、完了の状態を持たせます。公開の報告書では、同じ形では載っていなかったので、具体さは文の中身で判断するしかありません。ただし、公開の報告書に担当者や期限がないことは、実行していない、という意味ではありません。

7. 書かれていないことを確かめる

報告書は、読む人全員の疑問に答える文書ではありません。たとえば、自分の会社のこの時刻の失敗が、この事故によるものか、は報告書からは決まりません。自分のログに残ったエラーの時刻、request_idのようなID、使っていた地域と照らして、自分で確かめます。

自分の側の記録にどう生かすか

見立てです。公開の報告書の型は、自分の組織の記録にも使えます。

気をつけること

出典

更新履歴