3行でいうと

  • 事故の情報は、書いた人で性格が違います。当事者が出す事後報告（ポストモーテム）、第三者の調査機関の報告、報道から集めた事例集やモニターの3種類を分けると、「誰の視点か」と「どこまで確かめた話か」が見えます。
  • OECDの文書の要約は、AIのリスクが実際の害になった出来事を「AIインシデント」と呼んでいます。まだ害が出ていない、起こりうる危険は「ハザード」で、別の言葉です。「実際に起きたのか、起きたと言われているだけか」を分けて読むことが、手がかりになると思います（見立てです）。
  • 良い報告書は、分かっていることと、分かっていないことを分けて書きます。「再現できなかった」「可能性がある」「確認されていない」といった言葉は、未確定の印として拾います。報道の数や自動で付いた分類を、実際に起きた件数や確定した原因として読むのは危険です。

この記事は、AIの事故を自分で調べたり、再現を試したりした記録ではありません。この記事は、公開されている公式な文書を、2026年10月16日に読んでまとめたものです。特定の会社や製品の事故を評価する記事ではなく、報告書の読み方の記事です。事故の責任や法律上の判断は扱っておらず、助言でもありません。

先に結論

前提：3種類の資料

当事者の事後報告（ポストモーテム）

Googleのサイト信頼性の本（Site Reliability Engineering）は、事後報告を、インシデントの記録、影響、対応の内容、根本原因、再発を防ぐ行動をまとめた文書として説明しています。目的は罰ではなく学びで、特定の人やチームを責めずに、仕組みの問題を探す「責めない（blameless）」形が勧められています。責めると、問題が隠れやすくなるからだ、という理由が書かれています。

読む側にとって、これは次の意味を持ちます。

第三者の調査機関の報告

NTSBのページは、調査を5つの段階として説明しています。事故を知らされて調査を始めるかを決める、現場で事実を集める、分析して「推定される原因（probable cause）」を決める、最終報告を公開する、そして安全のための勧告を出して追跡する、の流れです。目安として、調査は12〜24か月で終えることを目指すが、複雑さで大きく変わる、と書かれています。刑事の件は調べず、犯罪とされた場合は警察やFBIが主導する、ともあります。

見立てです。調査の途中で出る情報は、のちに変わりうると考えておくのが安全だと思います。NTSBのこのページは、途中の報告（プレリミナリー）には触れておらず、報告書が責任追及に使われるかも書かれていません。僕らは、これらの点を確認できていません。

事例集とモニター

事例を集めた仕組みも2つ読みました。

どちらも、「報道で出た話の一覧」です。件数が多いことは、実際の事故が多いことの証拠にはなりません。

「インシデント」の定義を知っておく

OECDの2024年5月の文書は、AIインシデントを、AIのリスクが実際の害になった出来事とし、AIハザードを、将来の害の可能性があるが、まだ害になっていない出来事として説明しています。モニターのページには、インシデントやハザードの定義文そのものは見当たらず、各項目に「なぜインシデントやハザードと判定したか」の理由がAI生成で付いています。モニターでは、続報や対応は「補足情報」として、インシデントとは別に扱われます。

AIインシデント・データベースは、航空の言葉との対比を使っています。事故は大きな損害や人命の喪失があった場合、インシデントは「事故の危険がかなり高まった」場合です。ただし、AIの基礎的な定義は、研究者のあいだで長く議論されてきた、とも書かれています。

OECDは、2025年2月27日に、AIインシデントの報告の共通の枠組みを提案する文書も出しています。29の基準があると書かれていますが、僕らが読めたページには、その一覧が載っていませんでした。

読み方の手順（見立てです）

ここからは、読んだ資料をもとにした、僕らの見立てです。公式の手順ではありません。報告書を読むとき、次の順に確かめます。

  1. 資料の種類と日付。 当事者の報告か、調査機関か、事例集か。いつ書かれ、のちに更新されているか。
  2. 何が起きたか。 日付、影響を受けた範囲、影響を受けた製品やモデル、数字。数字には、何を分母にした割合かが書かれているか。
  3. 分かっている点と、分かっていない点。 「再現できなかった」「確認できていない」「可能性がある」は、未確定の印として拾います。
  4. 原因の書き方。 「原因は〜だった」と断定しているか、「〜と考えている」か。複数の原因が重なったと書かれているか。
  5. なぜ見つけるのが遅れたか。 事後報告には、検知が遅れた理由が書かれることがあります。ここに、仕組みの弱点が出ます。
  6. 対策。 実施済みの対策と、これから行うと約束している対策を分けます。
  7. 足りない情報。 被害を受けた人の数え方、第三者の確認の有無、続報の有無など、書かれていないことを、書き出しておきます。

言い回しを分ける

報告書にある言い方 読み方（見立て）
「〜が起きた」「〜を確認した」 書き手が確認したと述べている事実。だれが確認したかを見る
「〜と考えている」「〜と見ている」 推定。根拠が書かれているかを見る
「再現できなかった」 原因が確定していない印。対策が予防として行われることもある
「〜の可能性がある」「〜にも影響した可能性」 範囲が未確定。確定とは分けて読む
「〜と主張されている」「〜と報じられている」 当事者の確認を経ていない話
当事者の事後報告の一例：構成と、書かれていた「分からなかった点」

Anthropicは、2025年9月17日に、3つの不具合についての報告をエンジニアリングのブログに出しています。ここでは、中身の評価ではなく、報告の構成だけを、読み方の例として取り上げます。

  • 構成は、要約、背景、日付つきの時系列、3つの不具合の順の説明、技術的な詳しい解説、検知が難しかった理由、これからの改善、の順でした。
  • 範囲については、影響を受けた割合や、クラウドごとの数字が出ていました。
  • 書かれていた限界は、次のとおりです（要約から読み取ったもので、細部は確認できていません）。再現できなかった不具合があった。影響が及んだ可能性はあるが、未確認、という書き方がある。症状が条件によって変わる。評価では不具合を捉えられなかった。プライバシーの管理のために、調査が遅れた。

見立てです。この報告は、「分かっていること」と「分かっていないこと」を、同じ文書の中で、分けて書く形の一例として読めます。ただし、この記事は、数字の正しさを検証していませんし、この報告だけで当事者の対応の良し悪しは判断できません。

読み間違えやすい点

気をつけること

出典

更新履歴