AIのインシデントに備える5工程｜起きた日の動き方を決める

「AIが取引先に誤った案内をしていたと連絡が来て、そのあと何をすればいいのか分かりませんでした」「調べようとしたら、そのやり取りの記録がどこにも残っていなかったんです」——AIを業務に組み込んだ会社で、導入から半年ほど経つと、決まってこの順番で出てくる話です。AIのインシデント対応は、情報システムの障害対応をAIに読み替えたものではありません。本当は止まっていないのに壊れている状態を、誰がどうやって見つけ、どこまで届いたかを数える作業です。この記事では、AI起因の事故が起きた日の動き方を、検知・遮断・記録の保全・影響範囲の確定・報告と再発防止の5工程に分けて整理します。

AIの事故は、画面が止まる形では起きない

情報システムの障害には分かりやすい合図があります。画面が開かない、処理が返らない、エラーが記録される。誰かが操作に失敗した瞬間に異常だと分かるので、気づくところまでは自動で進みます。AI起因の事故はここが違います。機械の側は正常に終了していて、記録には成功と残るからです。

問い合わせ対応を自動化した会社で、廃番になった製品の仕様を答え続けた例を考えてみてください。参照する資料を差し替えたときに古い版が残っていた、というだけの話です。応答は毎回返っていて、処理時間も正常、失敗率はゼロのまま。監視の画面には何ひとつ異常が出ません。気づいたのは、購入した相手から仕様が違うと連絡が来たときでした。

この形の事故には、共通する4つの出方があります。誤った内容がそのまま外に出る、入れてはいけない情報が混ざって別の相手に出る、自動処理が想定より広く動く、自社の名前や文面を模したものが外で使われる。どれも停止という合図を伴いません。だから備えの入口は、復旧手順ではなく検知の設計になります。

もうひとつ押さえておきたいのは、被害の広がり方が時間に比例することです。止まる障害は、止まった瞬間から被害が増えません。誤り続ける事故は、気づかない時間の分だけ相手が増えます。発見が1日遅れると、対象の件数が1日分そのまま増えるという構造です。

事故と、事故になりかけを分けて数える

備えを設計する前に、何を事故と呼ぶかを揃えておきます。経済協力開発機構が2024年に整理した定義では、AIインシデントは、AIシステムの開発・利用・不具合が直接または間接に次のいずれかの害につながった事象とされています。人の健康への傷害や危害、重要な社会基盤の管理と運用の混乱、人権の侵害または基本的な権利や労働や知的財産を守る法令上の義務の違反、そして財産や地域社会や環境への害の4つです。

同時に、AIハザードという言い方も置かれています。同じ4つの害に至りうる事象、つまり実害には至らなかった事故になりかけを指します。この2つを分けて数えるかどうかで、社内に残る情報の量が変わります。実害が出たものだけを記録する運用にすると、危なかった事例は誰の手元にも残りません。

実務での使い方は単純です。報告の窓口を1つにして、実害の有無は受け取った側が後から分類する。現場に「これは事故ですか」と判断させないためです。判断を求めた瞬間、迷った案件は報告されなくなります。

なお、この定義は各国で報告の仕組みを揃えるための土台にもなっています。2025年に主要国の枠組みで共通の報告様式が承認され、経済協力開発機構が同じ年の2月に共通の報告枠組みを公表しました。自社の分類を独自に作り込むより、こうした共通の言い方に寄せておくほうが、後で外に説明しやすくなります。

報道に出るAIの事故は、月92件から324件へ。ただし数え漏れがある

規模の感覚を持っておきます。経済協力開発機構が2026年2月に公表した報告書は、報道されたAIの事故と事故になりかけを実時間で集める仕組みのデータを分析しました。それによると、2022年から2025年にかけて、報道された件数は月平均92件から324件へ増えています。3年半でおよそ3.5倍です。

ただし同じ報告書は、AI関連の報道全体に占める比率が2022年の3.2%から2025年には約2.5%へ下がったとも書いています。事故が相対的に減ったのではなく、AIそのものの話題が事故より速く増えたということです。件数と比率のどちらか一方だけを見ると、増えているとも落ち着いてきたとも読めてしまう点に注意してください。

中身は14の主題に分類されています。2022年1月から2025年9月までの平均で、合成された映像や音声によるものが12.5%、軍事利用が12.2%、自動運転が10%、プライバシーの侵害が8.9%。健康に関わるものが3.1%、労働市場に関わるものが3.5%です。合成された映像や音声は増え続けていて、直近では記録全体の14%を超えています。

この数字を自社の話に引き写すときに、いちばん大事な但し書きがあります。同じ報告書は、報道は記者が知り得て、なおかつ報じる価値があると判断したものしか捉えないと明記しています。そして提供元が世に出る前に自分で処理した事故は、この分析には入らないと書かれています。集計の元になっているのは閲覧数で上位半分の媒体で、1日15万件を超える記事を監視した結果です。

つまり、自社で起きる事故の大半はどの統計にも現れません。外部の集計は「どういう種類の事故が世の中で起きているか」を知る材料にはなりますが、自社の頻度を推し量る材料にはならないということです。社内で数える仕組みを持つ理由がここにあります。

自社で起きるAI起因の事故を、4つの型に分けておく

備えを具体にするために、社内で起こりうる形を4つの型に分けます。型ごとに最初に気づく人が違い、止め方の勘所も違うので、同じ手順書で流すと初動が遅れます。

型	起き方	最初に気づくのは誰か	止め方の勘所
誤った内容の公開	生成した文章や数値や出典が事実と違うまま外に出る	顧客・読者・取引先	出た面を直す前に、同じ材料で作った他の面を洗い出す
情報の混入	渡してはいけない情報が指示文や参照資料に入り、別の相手への出力に現れる	混ざった情報の持ち主	出力を止めても入力の経路が残っていれば再発する
自動処理の広がり	繰り返しや外部連携が想定より広く動き、同じ処理が何度も外に出る	受信した相手・連携先	機能の停止と外部への送信の停止を別々に押せるようにする
なりすまし・悪用	自社の名前や文面や声を模したものが社外で使われる	第三者からの指摘	自社では止められない。証拠の保全と、こちらからの告知が主になる

表の右端に共通しているのは、目に見えている出口を直しただけでは終わらないということです。誤った内容の公開では、同じ下書きから作った資料や営業メールが別の場所に残っています。情報の混入では、出力を止めても入力の経路がそのままなら翌日また起きます。

4つ目のなりすましだけは性格が違います。社内の設定をどう変えても止まりません。ここで決めておくのは、誰が事実確認をして、どの経路で外に告知するかの2点です。事故が起きてから広報と法務を巻き込む順番を考えると、半日から1日を使います。

情報セキュリティの手順書が、そのままでは使えない3つの理由

多くの会社には情報セキュリティのインシデント対応手順が既にあります。AIの事故もそこに寄せたくなりますが、そのままでは3か所が空欄になります。再現できない、記録が残っていない、どこまで届いたかを数えられないの3つです。

1つ目の再現です。従来の不具合は、同じ操作をすれば同じ結果が出るのが前提でした。生成AIは同じ指示でも出力が毎回変わります。だから「もう一度やってみて」という確認の仕方が成立しません。そのとき出た文章そのものが唯一の証拠で、消したら二度と手に入りません。

2つ目の記録です。会話形式の道具は、既定では個人の画面の中に履歴が残るだけで、組織の記録としては保存されていないことがあります。誰がいつ何を入力したかを組織側で持つには、設定を別に入れる必要があります。事故が起きてから設定を入れても、遡って記録は出てきません。

3つ目が影響範囲です。従来の障害なら、エラーの件数がそのまま影響した件数になります。AIの誤りは正常終了しているので、誤った回答を何人が受け取ったかが、どこにも集計されていません。この3つを埋める仕込みを平時に済ませておくことが、実質的なAIインシデント対策の中身です。

工程1：気づく——検知は監視画面からは来ない

最初の工程は検知です。AIの誤りは例外を投げないので、応答時間や失敗率の閾値では拾えません。入口を人の側と突き合わせの側に分けて、3つ作ります。

1つ目は外部からの申告です。顧客窓口、営業、取引先の担当者から上がってくる違和感を、そのまま受ける経路を作ります。ここで大事なのは、受け付ける単位を「AIの不具合」にしないことです。現場は原因がAIかどうかを判断できません。「案内した内容が事実と違った」という業務の言い方で受けます。

2つ目は内部の抜き取り確認です。公開した文章や送信したメールのうち、何割を人が読み直すかを先に決めます。全件は続きません。週に何件、誰が、いつ見るかを業務の予定に入れるところまで決めて、初めて運用になります。始めるときは1日あたり5件から10件で十分です。

3つ目は機械的な突き合わせです。出力に現れる製品名、価格、日付、担当者名を、社内の正しい一覧と照合します。判断は要りません。一覧にない語が出たら知らせるだけの仕組みで、型1と型2の相当部分が拾えます。ここはAIに判定させず、単純な突き合わせで済ませるのが正解です。

そして通報の1行目を決めます。誰に、どの経路で、最初に何を書くか。メールの本文に長々と経緯を書かせると、読む側が状況を掴むまでに時間がかかります。いつ気づいたか、何が出たか、まだ出続けているかの3点だけを最初に受け取る形にします。

工程2：止める——止め方を3段階で持つ

次が遮断です。ここで多い失敗は、止めるか止めないかの二択にしてしまうことです。全部止めれば業務も止まるので、現場は止める判断をためらいます。ためらっている間に件数が増えます。段階を3つに分けておくと、迷わずに一番外側から止められます。

第1段階は出力の停止です。該当の機能だけを止め、人の対応に切り替えます。第2段階は外部への送信の停止です。メール配信、外部システムへの書き込み、公開面の更新を止めます。第3段階は接続の遮断で、外部サービスへの接続や権限そのものを落とします。被害の広がりを止めるのは第2段階で、第1段階だけでは送信待ちの分が出ていきます。

押しやすさも設計に含めます。誰が押せるか、夜間と休日は誰か、押した後に誰へ知らせるか。権限を持つ人が1人だと、その人が不在の時間帯は止まりません。最低でも2人、できれば部門をまたいで3人に持たせます。

止めた後の業務の代替も、先に1行だけ書いておきます。自動応答を止めたら人が返す、資料の生成を止めたら前の版を使う、といった程度で構いません。ここが空欄だと、止める判断が業務停止の判断と同じ重さになってしまいます。

• 止める権限と、止めた責任を切り離す。止めた人が咎められる運用にすると、次から誰も止めない
• 第1段階と第2段階は同時に押せるようにしておく。順番に確認しながら押すと数分から数十分かかる
• 止めたことを外部の相手に知らせる文面を、平時に用意しておく。当日に文面から考えると半日使う

工程3：記録を保全する——直したくなる手を、いったん止める

止めた直後に必ず起きるのが、現場が直しにかかることです。指示文を書き換える、設定を元に戻す、履歴を消す。悪意はまったくなく、早く正常に戻したいだけです。しかしこれをやると、何が原因だったかを後から示す材料が消えます。

この順番は制度の側でも押さえられています。欧州のAIに関する規則の重大インシデント報告の条文は、提供者に対して、当局に知らせる前にAIシステムへ変更を加えないことを求めています。適用範囲は後の章で書きますが、調べる前に直さないという順番自体は、どの会社でも使える実務の原則です。

保全するものは4種類に絞れます。入力（指示文と、渡した資料や参照先）、出力（整形せずそのままの本文）、設定（使った版、接続先、参照している資料の版と更新日）、そして時刻と実行者です。この4つが揃っていないと、原因が指示文にあるのか資料にあるのか設定にあるのかを切り分けられません。

保存の形も決めておきます。画面の写しだけでは、後で照合するときに文字を拾えません。本文はそのままの文字として保存し、写しは補助にします。保存先は、事故が起きた仕組みとは別の場所に置きます。同じ場所に置くと、切り戻しの操作で一緒に消えます。

そして、この工程には期限を付けます。保全が終わるまで修正に着手しない、というだけだと現場が待たされます。最初の30分で保全を終えると決めて、30分経ったら修正に進む。時間を切ることで、保全と復旧のどちらも動きます。

工程4：どこまで届いたかを数える——AIでは件数が出ない

4つ目が影響範囲の確定です。ここが最も時間を食い、報告が遅れる原因のほとんどを占めます。従来の障害ならエラーの件数が影響件数でしたが、AIの誤りは正常終了しているので、誤った内容を何人が受け取ったかがどこにも集計されていません。

手がかりは3つあります。1つ目は出力の配布経路です。公開面なら閲覧の数、メールなら送信先の一覧、対話なら会話の件数。2つ目は横展開で、同じ材料や同じ下書きから作られた別の成果物を洗います。3つ目が期間の特定です。

3つ目の期間がいちばん漏れます。多くの場合、事故は「ある日突然」ではなく、設定を変えた日、参照する資料を差し替えた日、モデルの版が上がった日から静かに始まっています。起点を1週間前だと思い込んで数えると、実際には2か月分が対象だった、ということが起こります。工程3で設定と資料の版を保全しておくのは、この起点を出すためでもあります。

数え切れない場合の扱いも先に決めておきます。原則は上限で見積もることです。期間の起点が特定できないなら、直近で設定を触った日まで遡って全件を対象にする。正確に数えようとして報告が遅れるより、多めに見積もって早く伝えるほうが、相手にとっては役に立ちます。後から範囲を絞る連絡は入れられますが、遅れた時間は取り返せません。

数え方の基準は、事故のたびに決め直さないでください。上限で見積もる、期間は設定変更まで遡る、横展開は同じ材料から作った全部を含める。この3行を平時に決めておくと、当日は当てはめるだけになります。

工程5：報告と再発防止——順番を間違えない

最後が報告です。順番は4つで、社内の指揮系統、影響を受けた相手、制度上の報告先、必要なら対外の公表。この順番を崩すと、相手に伝わる前に外から知らされるという最悪の形になります。特に、社内の役員向け報告に時間をかけている間に、相手が別の経路で知るのがよくある失敗です。

影響を受けた相手に伝える文面には、3つを入れます。何が起きたか、いつからいつまでか、こちらが取った措置。原因の分析はこの時点で書かなくて構いません。分析を待つと連絡が数日遅れます。原因は分かった時点で追って伝えます。

再発防止は「注意する」「教育を徹底する」で終わらせないことです。仕組みに落とす形は3つしかありません。入力を制限する（渡してよい情報の範囲を機械的に絞る）、出力の確認範囲を広げる（人が見る割合を上げる）、権限を縮める（自動で外に出せる操作を減らす）。この3つのどれかに落ちない再発防止策は、次の四半期には形骸化します。

そして、事故になりかけた段階の事例も同じ様式で残します。実害が出たものだけを記録すると、社内に残る事例は年に数件になり、傾向が読めません。危なかった事例を含めて数十件たまって初めて、どこが弱いかが見えます。

個人データが混ざった瞬間、国内の制度の時計が動き出す

ここからは制度の話です。国内で真っ先に効くのは個人情報保護法の漏えい等報告です。AIの事故そのものを対象にした条文ではありませんが、入力や出力に個人データが混ざった時点で、通常の漏えいと同じ扱いになります。

個人情報保護委員会が示す報告対象は4類型です。要配慮個人情報が含まれる漏えい等、不正に利用されると財産的な被害が生じるおそれがある個人データの漏えい等、不正の目的をもって行われたおそれがある行為による漏えい等、そして本人の数が1,000人を超える漏えい等（行政機関等は100人超）。

期限は速報と確報に分かれます。速報は発覚した日から3日から5日以内、確報は30日以内。不正の目的をもって行われたおそれがある場合の確報は60日以内です。ここで押さえておきたいのは、いずれも「漏えいした」ではなく「漏えいしたおそれがある」段階で対象になる点です。

AIが絡むと、この「おそれ」の判定に時間がかかります。従業員が対話の画面に顧客の情報を貼り付けたかどうか、外部の仕組みに何が渡ったのか。組織側の記録がないと、本人に聞いて回ることになります。工程3で入力の記録を保全する設計は、この確認の速さに直結します。

なお、報告の期限は発覚した日から数えます。事故が起きた日ではありません。気づくのが遅れても期限は延びますが、その間に被害は増えています。検知の設計を最初の工程に置いた理由がここにも重なります。

欧州の重大インシデント報告は2026年8月2日から。名宛人は限定されている

海外の制度も押さえておきます。欧州のAIに関する規則には、重大なインシデントを当局へ報告する条文があります。適用が始まるのは2026年8月2日です。

名宛人は、高リスクに分類されるAIシステムの提供者です。報告先は、その事故が起きた国の市場を監督する当局。期限は、事故との因果関係またはその合理的な可能性を認めた後ただちに、遅くとも15日以内。広範な権利侵害などにあたる場合は気づいてから2日以内、死亡に至った可能性がある場合は10日以内とされています。

あわせて、提供者には調査と危険性の評価、是正措置、当局への協力が求められ、当局に知らせる前にAIシステムへ変更を加えないことも定められています。運用の手引きの草案と報告様式のひな形は2025年9月26日に公表され、意見の募集は同年11月7日まで行われました。

ここが誤解されやすいところなので、はっきり書きます。この条文は、日本国内で社内業務に生成AIを使っているだけの企業に、直ちに報告義務を課すものではありません。欧州の市場に、高リスクに当たるAIシステムを提供する立場になったときに関わってくる規定です。自社が名宛人にあたるかどうかは、提供している製品と市場を見て個別に判断する必要があります。

ただし、義務がないから無関係というわけでもありません。実務では、欧州に製品を出す取引先から、契約や調達の条件として同等の対応を求められる形で降りてくることがあります。報告の期限や様式に合わせられる記録を平時から持っているかどうかが、そのときの回答の速さを決めます。

起きた日の動き方を、30分・2時間・24時間で区切る

5つの工程を、時間で区切った形に並べ直します。ここまでの内容を当日に使える形にしたものです。所要の目安は関係者3人から5人で、決めるだけなら半日です。

時間で区切る理由は、判断の質を上げるためではありません。止まらないことを防ぐためです。区切りがないと、影響範囲を正確に出そうとして半日が1日になり、連絡が翌々日になります。

起きる前に配っておく役割と、決めておく1行

当日に走れるかどうかは、平時に何を配ってあるかで決まります。配るのは4つの役割です。止める権限を持つ人、記録を保全する人、影響範囲を数える人、外部に連絡する人。兼務で構いませんが、名前で決めます。部署名で決めると、当日に誰が動くかで数十分を使います。

そのうえで、決めておく1行があります。「どの範囲まではAIに任せず、人が確認してから外に出すか」です。事故の後にこれを決めると、たいてい過剰に厳しくなり、翌月には守られなくなります。平時に狭く決めて守り切るほうが、事故の後に広く決めて形骸化させるより効きます。

外部に委託している場合は、委託先との取り決めにも1行を足します。事故が起きたときに、何を何時間以内に自社へ知らせるか。委託先が自社の判断で対処を終えてから報告してくると、記録の保全ができません。止める権限をこちら側が持つのか、委託先が持つのかも明記します。

演習は年に1回、机上で30分から1時間あれば足ります。実際に止めてみる必要はありません。誰に第一報が入り、誰が止めるかを口頭で回すだけで、名前が抜けている役割が見つかります。

やってはいけない初動

事故の直後に起きやすい動きを並べます。どれも善意から出ていて、しかも結果として対応を長引かせるものです。

• 原因が分かるまで止めない。調べている時間の分だけ、対象の件数が増える
• 現場が先に設定や指示文を直す。原因を示す材料が消え、同じことが再発したときにも切り分けられない
• 出た画面だけを直して終える。同じ材料から作った他の資料やメールが残ったままになる
• 影響範囲を正確に出そうとして連絡を遅らせる。相手には多めに見積もった数を早く伝えるほうが役に立つ
• 第一報を長文の経緯報告にする。いつ気づいたか、何が出たか、まだ出続けているかの3点で足りる
• 報告の窓口を「AIの不具合」という単位にする。現場は原因がAIかを判断できないので、報告されなくなる
• 事故になりかけた事例を記録しない。実害が出たものだけでは件数が少なすぎて、弱い場所が見えない
• 止めた人の判断を後から責める。次から誰も止めなくなり、検知の仕組みごと動かなくなる

この一覧は、事故が起きてから読むものではありません。手順書の1ページ目に置いて、平時に一度読んでおくものです。当日はほぼ読む余裕がありません。

備えのチェックリスト

最後に、平時に埋めておく項目をまとめます。上から順に確認して、空欄が3つ以上あれば、当日に走れない状態だと考えてください。

• 検知の入口が3つある（外部からの申告・内部の抜き取り確認・機械的な突き合わせ）
• 第一報の宛先と、最初に書く3点（気づいた時刻・出た内容・継続の有無）が決まっている
• 止め方が3段階に分かれ、それぞれを押せる人が2人以上いる（夜間と休日を含む）
• 保全する4種類（入力・出力・設定・時刻と実行者）の保存先が、事故が起きる仕組みとは別にある
• 対話形式の道具の履歴が、個人の画面ではなく組織の記録として残る設定になっている
• 影響範囲の数え方が3行で決まっている（上限で見積もる・設定変更まで遡る・横展開を含める）
• 個人データが絡む場合の報告先と期限（速報は発覚日から3日から5日以内、確報は30日以内）を担当者が知っている
• 4つの役割が名前で決まっている（止める・保全する・数える・外部に連絡する）
• 委託先との取り決めに、事故を何時間以内に知らせるかと、止める権限の所在が書いてある
• 事故になりかけた事例も、実害が出た事例と同じ様式で残す運用になっている

この10項目のうち、当日に作れるものはひとつもありません。すべて平時にしか用意できないものだけを並べてあります。逆に言えば、ここが埋まっていれば、当日にやることは工程に当てはめるだけになります。

まとめ

AI起因の事故は、画面が止まる形では起きません。機械の側は正常に終了し、記録には成功と残ったまま、誤った内容が出続けます。だから備えの入口は復旧手順ではなく検知の設計になり、被害は気づかない時間の分だけ増えていきます。

難しいのは復旧ではなく、再現できない、記録が残っていない、どこまで届いたかを数えられないという3点です。この3つは事故が起きてからでは埋められません。出力そのものを保存する、組織の記録として履歴を残す設定を入れる、数え方を3行で決めておく。いずれも平時にしかできない仕込みです。

制度の側も押さえておきます。国内では、入力や出力に個人データが混ざった時点で漏えい等報告の対象になり得ます。速報は発覚した日から3日から5日以内、確報は30日以内、不正の目的をもって行われたおそれがある場合は60日以内。欧州の重大インシデント報告は2026年8月2日から適用されますが、名宛人は高リスクに当たるAIシステムの提供者で、国内で社内利用しているだけの企業に直ちに義務が生じるものではありません。

最後に、規模の話をもう一度。報道されたAIの事故と事故になりかけは、2022年から2025年で月平均92件から324件へ増えました。ただしこの数字には、提供元が世に出る前に自分で処理した事故が入っていません。自社で起きることの大半は、どの統計にも現れないということです。だから外の数字を見て身構えるより、社内で数える仕組みを持つほうが確実です。AIに判断させず、人が確認する範囲を先に決め、止める権限を複数の人に配っておく。起きた日の動き方を決めておくことは、AIを疑うことではなく、任せられる範囲を広げるための準備だと考えてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。