AI失敗事例・事故解剖大全

AI事故をmodel failure単体ではなく、評価・release control・grounding・human verification・権限・tool side effect・通常software/infrastructureを含むsystem incidentとして扱うための調査済みstaging artifact。

本稿の INCIDENT_CHAIN_RECORD と failure-family分類は PROPOSAL / INFERENCE であり、個別事件の事実認定とは分離する。Task1 canonicalは変更しない。

• AI事故はmodel failure単体ではなく、deployment前後の複数防護線を通過したsystem incidentとして記録すべきか。
• offline evalやA/B testが良好でも、定性的signalや未計測behavior dimensionを見落としてrelease incidentへ至ることがあるか。
• AI出力を人間が業務成果物へ転記・提出する場合、human verification gateは事故連鎖の独立層として扱うべきか。
• chatbot/AI surfaceが企業の公式窓口に組み込まれた場合、「AIが言っただけ」と組織責任を分離できるか。
• AI service事故にはmodel挙動以外の通常software、cache、library、configuration、identity基盤等のfailureも含めるべきか。

INCIDENT_CHAIN_RECORD は PROPOSAL / INFERENCE として次の項目を持つ。

• business context
• SUT / product surface
• initiating condition
• model / data / tool / software event
• failed preventive control
• failed detection control
• human / process response
• external impact
• containment / rollback
• corrective action
• residual UNKNOWN
• evidence origin / version

推奨failure familyも PROPOSAL とし、MODEL_BEHAVIOR / GROUNDING_DATA / EVAL_RELEASE / TOOL_ACTION / IDENTITY_PERMISSION / HUMAN_PROCESS / SOFTWARE_INFRA / POLICY_GOVERNANCE を複数付与可能とする。単一root-cause labelへ圧縮しない。

OpenAI sycophancy incidentはbenchmark単体の失敗ではなく、専用behavior metricの欠如と定性的signalのrelease判断への組込み不足を示すprovider self-reportである。Mataはhallucinationに加えてverification/escalation failureを示す。Moffattは内部方式がUNKNOWNでありLLM-specificに分類しない。2023 OpenAI incidentは通常software/SRE/security failureをAI product incident inventoryから除外できないことを示す。

• provider postmortemは当事者の自己報告であり、独立forensic auditではない。
• historical incidentを2026 current product failure rateへ外挿しない。
• Mataのspecific ChatGPT model/versionはUNKNOWN。
• Mata E3のprimary authoritative court-hosted locatorはUNKNOWN。Justiaはsecondary public reproduction。
• MoffattはLLM-specific evidenceではない。chatbot architecture/model/vendorはUNKNOWN。
• Gemini image incidentをGemini全体へ一般化しない。
• 公開事故群からprovider別incident rate、安全度、現在failure rateを推定しない。
• incident absenceをsafety evidenceとしない。

historical incidentの再現可能性とcurrent exposureは分離する。model/version、product surface、plan、region、tenant policy、connector/tool、data source、runtime、rollout cohortはcurrent product claimへ転用する前に再確認する。

事故集はleaderboardではない。failureをfixture化する場合は安全なsynthetic fixtureとし、pass率だけでなくfalse negative、time-to-detect、time-to-containを記録する。

cross-user data visibility、permission boundary、prompt/tool経由data exfiltrationをmodel safetyとは別軸で扱う。incident timeline、model/release identifier、input provenance、retrieved sources、tool calls、approvals、output artifact、human sign-off、rollbackを可能な範囲で相関ID付き保存するが、secret/PIIを無制限に記録しない。canary、feature flag、kill switch、rollback、degraded mode、human fallback、status communicationを事故解剖項目に含める。

AI事故はモデルが誤った瞬間だけを指すものではない。業務上の事故は、モデル・データ・ツール・製品制御・人間確認・通常のソフトウェア基盤の複数層を通って成立する。公開事例は各製品の現在の失敗率を示すものではなく、どの防護線が必要かを学ぶための事例として扱う。