世界には、AIシステムが関与して実害が出た事象や、被害が出る寸前だった事象を集めた公開データベースが8件あります。いずれも登録せずに無料で読めます。たとえば、2026年7月28日には、本番のデータベースに接続されたコーディングエージェントが22個のテーブルを削除しました。このインシデントは、AI Incident DatabaseにインシデントID 1676として収録されています^[1]。自社で同じ構成を採用する前にこの事例を読めば、同じ設定ミスを防ぐためのチェック項目を用意できます。

事故を記録に残す仕組みは、AIに固有のものではありません。航空、医薬、情報セキュリティの分野でも以前から使われています。AI Incident Databaseも、自らを航空とコンピュータセキュリティのデータベースに似た仕組みだと説明しています^[5]。

ただし、公開AIインシデントDBが航空や医薬の制度と似ているのは、記録を集めて公開する形式だけです。公開AIインシデントDBには、当事者から報告を集めるための制度がありません。それぞれの違いを比べると、公開DBから読み取れる範囲と、読み取れない範囲が分かります。

航空と医薬は、制度によって報告を集めている

航空事故については、国際民間航空条約の第13附属書（ICAO Annex 13）が調査制度を定めています。この附属書によると、事故と重大インシデントを調査する唯一の目的は事故の防止であり、責任や賠償責任の所在を決めることではありません^[2]。締約国は、自国の領域で起きた事故を調査し、30日以内に予備報告を出します。締約国は、実行可能な限り速やかに、または12か月以内に最終報告を出し、再発防止のための安全勧告を付けます^[2]。条約と国内法が調査機関に調査権限を与えているため、調査機関は現場や記録を調べられます。

ただし、航空事故の調査権限だけでは、事故に至らなかったヒヤリハットを把握できません。当事者が報告しなければ、調査機関もその事実を知ることができないためです。そこでNASAのAviation Safety Reporting System（ASRS）は、任意かつ匿名の報告を受け付け、一定の条件を満たす報告者を処分から守ります。報告対象が故意でない違反で、事故や犯罪を伴わず、報告者に過去5年間の違反がなく、本人が気づいてから10日以内にNASAへ書面で報告した場合、民事制裁金や資格停止は科されません^[3]。FAAは報告の提出を求めず、NASAも報告書や報告者を特定できる情報をFAAへ渡しません^[3]。ASRSは、報告者を処分から守ることで、自発的な報告を集めています。

医薬品の副作用情報は、法律による報告義務で集めています。医薬品医療機器等法第68条の10第1項は、製造販売業者等が、副作用によるものと疑われる疾病、障害、死亡の発生を知った場合、厚生労働大臣へ報告するよう義務づけています。2004年4月以降、製造販売業者等はPMDAへ報告することになっています^[4]。報告しなければ、行政処分の対象になります。

航空事故の調査制度、ASRS、医薬品の副作用報告制度は、いずれも情報を集める仕組みを設けています。航空事故の調査機関には法律に基づく調査権限があり、ASRSには報告者を処分から守る仕組みがあり、医薬品の製造販売業者等には法律上の報告義務があります。どの制度も、当事者の善意だけに頼らずに情報を集めます。

公開AIインシデントDBには、報告を促す制度がない

公開AIインシデントDBは、既存の事故・脆弱性データベースと3つの点で似ています。1つ目は、記録ごとに番号を付ける形式です。AI Incident Database（AIID）では、編集者が投稿を確認した後、各インシデントに番号を付けます^[5][6]。2つ目は、共通の尺度で記録を分類する形式です。情報セキュリティの分野では、脆弱性に共通IDを付け、共通の尺度で深刻度を採点します。AVIDも、各記録をCVSSの深刻度スコアやMITRE ATLASの分類に対応させています^[7]。3つ目は、集めた記録を公開する形式です。本稿で紹介する8件は、すべて無料で閲覧できます。

一方、公開AIインシデントDBには、前節で確認した3つの制度がありません。運営者には調査権限がないため、事故調査機関のように現場や記録を調べて原因を確定できません。当事者が説明しなければ、組織の内部で何が起きたかは分かりません。また、医薬品の副作用報告制度のような報告義務もないため、当事者が報告しなくても罰則はありません。ASRSのように報告者を処分から守る仕組みもないため、企業には自社の失敗を投稿する理由がありません。

そのため、公開DBに載るのは、組織の外から確認できたインシデントに限られます。企業が社内で検知して修正したインシデントは、報道も投稿もされなければ公開DBに残りません。OECDのAI Incidents and Hazards Monitor（AIM）も、収録している事例は、世界で起きたインシデントとハザードの一部にすぎないと明記しています^[8]。

公開DBの収録件数は、自社のリスク統計の代わりにはなりません。公開DBは、他社が公表した事例を探すための索引として使い、自社で起きたインシデントは社内で別に記録します。なお、本稿の調査時点では、AIインシデントを日本語で横断検索できる公開DBは見つかりませんでした。以下で紹介する8件はいずれも英語です。

8件の早見表

AI Incident Database（AIID）

AI Incident Database（AIID）は、非営利団体のResponsible AI Collaborativeが運営しています。誰でもインシデントを投稿でき、編集者が内容を確認した後、各インシデントに番号を付けます^[5][6]。AIIDは、AIシステムが関与した、人、財産、環境への被害、または被害が出る寸前だった事象についての申し立てを1件として数えます^[6]。AIIDの収録件数は1,460件で^[6]、冒頭で紹介したインシデントにはID 1676が付いています^[1]。

AIIDは、8件のなかでも、個々の事例を読んで再発防止策を考える用途に向いています。検索するときは、ツール名ではなくAIの使い方を検索語にします。「ChatGPT」だけで検索すると、報道件数が多い事例から並びます。一方、「coding agent production database」で検索すると、冒頭のインシデントを見つけられます。AIIDは、週次のスナップショットをJSON、CSV、MongoDBの各形式で配布しているため、データを手元に保存して全文検索することもできます。2026年8月31日版の圧縮ファイルは111.32MBです^[9]。

OECD AI Incidents and Hazards Monitor（AIM）

OECD AI Incidents and Hazards Monitor（AIM）はOECDが運営し、加盟国の政策担当者が世界の傾向を把握するために使います。2026年9月7日時点の収録件数は17,417件です^[10]。AIMは、ニュース集約基盤のEvent Registryから事象を取得し、GPT-4o miniで関連性の低い事象を除いた後、GPT-4oで再分類します^[8]。

AIMの収録件数がAIIDの約10倍なのは、実際のインシデントが10倍あるからではありません。AIMは、実際に害が生じた「インシデント」と、害が生じる可能性がある「ハザード」を分けて判定し、両方を総数に含めています^[8]。AIMは、個別インシデントの事実確認よりも、分野や国を指定して報道件数の増減を調べる用途に向いています。現時点では一般からの投稿を受け付けておらず、投稿機能を準備しています^[8]。

AIAAIC Repository

AIAAIC Repositoryは、政府と産業から独立した公益目的の資料として、AI、アルゴリズム、自動化をめぐるインシデントと論争を集めています^[11]。データにはCC BY-SA 4.0が適用されるため、出典を示せば社内資料にも転載できます^[11]。

AIAAIC Repositoryは、被害が確定していない案件も収録する点でAIIDと異なります。訴訟や事故報告に至らなかった批判や撤回も記録に残るため、自社が同じ方法でAIを使った場合に生じうる批判を事前に調べられます^[12]。広報やリスク管理の担当者が事例を探す場合に使えます。

MIT AI Incident Tracker

MIT AI Incident Trackerは、AIIDの報告1,600件を、リスク、原因、被害、深刻度ごとに分類し直したデータベースです^[13]。独自にインシデントを収集するのではなく、AIIDの既存記録に分類項目を追加しています。

MIT AI Incident Trackerは、「誤情報による被害だけ」「意図的な悪用だけ」のように、事例を種類で絞りたいときに使います。AIIDのキーワード検索では検索語によって結果が変わりますが、MIT AI Incident Trackerでは用意された分類項目を使って絞り込めます。

MITRE ATLAS

MITRE ATLASはMITREが運営する公開の知識ベースで、AIシステムを狙う攻撃者の戦術と技術をまとめています^[14]。v2026.08時点で、16の戦術、114の技術、72件のケーススタディを収録しています^[15]。

MITRE ATLASがまとめているのは、被害の一覧ではなく攻撃手順の一覧です。ケーススタディには攻撃者の動作が順番に書かれているため、セキュリティ担当者はその記録をレッドチームの検証項目や、監視対象とするログの選定に使えます。

AVID

AVIDはAI Risk and Vulnerability Allianceが運営し、汎用AI（LLM、APIのみで提供されるAI、開発ツール、エージェント）の失敗パターンを集めています^[7]。AVIDは、個別の発生事例を記録する「報告」と、繰り返し発生する失敗を記録する「脆弱性」の2種類に分けて情報を収録しています^[7]。

AVIDは、本稿で紹介する8件のなかで、情報セキュリティの脆弱性データベースに最も近い形式です。モデル名や製品名で検索すると、採用を決める前に、そのモデルや製品で報告された失敗を確認できます。AVIDの記録はCVSSやMITRE ATLASの分類に対応しているため、既存の脆弱性管理台帳へ転記しやすくなっています^[7]。

DAIL（Database of AI Litigation）

Database of AI Litigation（DAIL）は、ジョージ・ワシントン大学ロースクールのEthical Tech Initiativeが運営しています。採用、与信、量刑に使われたアルゴリズムのほか、生成AIの学習データやAIコンパニオンの責任をめぐる訴訟を収録しています^[16]。

DAILは、判決が出た案件だけを載せる判例集ではありません。訴状が提出された時点から、判決の有無にかかわらず案件を収録します^[16]。そのため、「どのようなAI利用が訴訟になりうるか」ではなく、「どのようなAI利用が実際に訴えられているか」を確認できます。法務や契約の担当者が、実際の訴訟事例を調べる場合に使えます。

Political Deepfakes Incidents Database

Political Deepfakes Incidents Databaseは研究者チームが運営し、政治に関わる人物、機関、出来事を扱ったディープフェイクの画像と動画を集めています^[17]。各事例には、本物として提示されたか、第三者が検証したか、誰が対象になったか、どのような被害が描かれたかが記録されています^[17]。

このデータベースは政治に関する事例だけを扱うため、一般企業が日常的に参照する用途には向きません。ただし、なりすまし動画への対応手順や、AI生成物の表示ルールを社内で決める際の事例集として利用できます。

自社の使い方を書き出してから引く

8件のデータベースを最初から順に読んでも、自社に関係する事例を選び出すのは困難です。先に自社でのAIの使い方を書き出し、その記録を1行ずつ使ってデータベースを検索します。

AIの使い方は、「誰が、どのデータを、どのツールに、どの権限で渡しているか」という単位で書き出します。たとえば、次のように記録します。

• 経理部が、取引先の請求書PDFを、個人契約のChatGPTに、貼り付けで渡している
• 開発チームが、本番データベースの接続情報を、コーディングエージェントに、書き込み権限つきで渡している
• 採用担当が、応募者の職務経歴書を、外部の書類選考サービスに、一括アップロードで渡している

誰が何をどのように渡しているかまで記録すれば、その内容をデータベースの検索語に使えます。一方、AI台帳の用途欄に「文書要約」「議事録作成」とだけ書いても、類似事例を探すための検索語を作れません。当社が支援する現場でも、用途欄がこのような作業名だけで埋まっていることがあります。その状態では、台帳を作成しても公開DBの事例と結び付けられません。

検索語には、ツール名だけでなく、AIへ渡しているデータや権限も含めます。「ChatGPT」だけで検索すると、報道件数の多い事例が上位に並びます。上記の2行目であれば、「coding agent production database」で検索すると、冒頭のインシデントを見つけられます。

検索で見つけたインシデントを読み、自社ではどの操作を防ぐか決めます。冒頭のインシデントでは、開発者がデータベースの構造を修復するため、コーディングエージェントに本番データベースの接続情報を渡しました。エージェントは、その接続情報を検証用の使い捨てデータベースへ接続するためのものとして使用し、22個のテーブルを削除しました^[1]。削除されたテーブルの多くは、復旧または再作成されています^[1]。

この事例から作るチェック項目は、「権限を絞る」のような広い表現ではなく、具体的な設定にします。1つ目は、検証用データベースの接続情報を本番用とは別に用意することです。2つ目は、エージェントへ最初に渡す接続情報を読み取り専用にすることです。どちらも設定ファイル上の1行で指定できます。

このインシデントは、海外で起きたという理由だけで自社と無関係だとは判断できません。PrismaとSupabaseの組み合わせは、国内の受託開発でも使われています。自社が同じ製品を同じ権限構成で使えば、同じ操作によってテーブルが削除される可能性があります。

公開DBで確認できるのは、他社が公開したインシデントです。自社内で起きたインシデントは、自社で記録しなければ公開DBにも社内台帳にも残りません。また、従業員が報告による処分を心配すれば、社内のヒヤリハットも集まりません。ASRSが報告者を処分から守ったように、企業も、報告した従業員を不利に扱わないとあらかじめ定める必要があります。そのルールがあれば、担当者が替わった後も、過去の記録を再発防止に使えます。

参考・一次ソース

■お問い合わせ

自社でのAIの使い方を「誰が、どのデータを、どのツールに、どの権限で渡しているか」まで書き出す作業や、公開DBで見つけたインシデントから本番投入前のチェック項目を作る作業には、担当者が手を動かす時間が必要です。従業員が不利益を受けずに社内インシデントを報告できる運用も整えなければなりません。これらの作業に手が回らない場合は、アハクラフトにご相談ください。

お問い合わせ