INSIGHT
AIで問題が起きたときに備える——停止・調査・説明の担当をつなぐ
誰も全体を引き受けない状態を、どう防ぐか。
朝、AIが作った案内に誤った条件が混じっていると現場から連絡が来た。担当者は文面を直したい。情報システム担当はログを見たい。顧客窓口は、誰へ何を伝えるか決めたい。全員が動いているのに、公開を止める人と再開を決める人が見つからない。
問題への備えは、原因をすぐ当てることではありません。影響を広げる操作を止め、確認に必要な状態を残し、届いた範囲を調べ、分かっていることを伝え、再開を判断する。その受渡しを一枚にしておきます。
最初の連絡で、停止する操作を言えるようにする
現場が「回答がおかしい」と気づいたとき、連絡先が製作者個人だけでは、休暇中や契約終了後に止まります。利用前に、兆候を受ける窓口、業務責任者、技術担当、情報管理・法務、顧客窓口を一列にします。
停止は、AI利用を永久に禁止することではありません。誤った回答の公開、顧客への送信、台帳の更新、支払いなど、影響が広がる操作を一時的に止めることです。「回答案の作成は続けても、社外送信を止める」「検索は使っても、確定処理への反映を止める」のように範囲を言います。
最初の連絡には、発見時刻、利用者、画面や機能、入力、出力、すでに行った操作を含めます。原因を「AIの誤り」「古い資料」と決めつけず、観測した事実と推測を分けます。
初動で決めるのは原因ではなく、どの操作を誰が止め、次の確認を誰へ渡すかです。
修正する前に、確認に必要な状態を残す
表示を直せば利用者の影響を止められる場合があります。ただし、設定や記録を上書きすると、いつから何が起きたかを追えなくなることがあります。先に、画面、入力、出力、参照資料、設定や版、時刻、利用者の報告を、社内の既存手順に合う場所へ残します。
ここでいう保全は、担当者を追及するための証拠集めではありません。影響範囲と訂正内容を確認するために、変更前の状態を扱える形で残すことです。個人情報や機密情報を含む記録は、保存先、閲覧者、保持期間を既存の規程や事案ごとの判断に合わせます。何でも長期間保存すればよい、という意味ではありません。
2026年7月7日に公表されたAIセーフティ・インスティテュートの評価観点ガイド第1.20版 には、AIエージェントの観測・制御、権限、実行履歴、介入や停止に関する評価項目例があります。認可や安全保証ではなく、何を見られ、誰が止められるかを事前に確かめる視点です。
時系列と影響範囲を、原因の仮説から分ける
影響範囲は、問題のある出力や操作が届いた利用者、データ、業務の範囲です。最初に「いつからいつまで」「どの機能」「どの利用者」「どの操作」「どこへ渡ったか」を時系列にします。
その後で、可能性を分けます。AIの出力自体が誤った。参照資料が古かった。入力が不足していた。権限や連携先が違った。人の確認で見落とした。外部サービスの変更があった。技術担当、資料の所有者、業務担当、提供者へ、それぞれ確認を渡します。
NISTのGenerative AI Profile は2024年の文書で、虚偽出力、情報、人とAI、第三者依存、継続評価、停止・廃止などを整理しています。公式ページの2026年4月更新は文書の改版ではなく、特定の事故対応手順や日本での報告義務・期限を定めるものでもありません。確認先を分ける一般的な視点として使います。
原因を早く一つに決めるより、事実の時系列と届いた範囲を先に共有した方が、停止と訂正を正しく選べます。
説明は、確認済み・調査中・次の更新を分ける
社内外への説明が必要な場合、技術担当だけで文面を作るのは難しいことがあります。業務責任者は影響と代替手順、技術担当は確認できた状態、情報管理・法務は必要な対応、顧客窓口は連絡先と訂正方法を持ち寄ります。
まだ原因が分からないなら、推測で埋めません。「午前九時から十時の間に、特定画面で誤った案内が表示されたことを確認した。現在は当該回答の外部送信を停止している。対象件数と原因を調査し、午後三時に次の情報を更新する」と、確認済み、実施済み、調査中、次の更新時点を分けます。
法定報告や顧客通知の要否、期限、内容は、事案、情報、契約、適用法令によって異なります。一般的なAIガイドから決めず、権限を持つ担当が個別に確認します。説明担当を後から探さないよう、停止・調査・判断から連絡先まで事前に接続します。
再開は、修正・復元・業務確認の三つで決める
「設定を直した」だけで再開しないでください。同じ条件で問題が再現しないか、止めた操作を安全に戻せるか、停止中に生じたデータや業務をどう扱うかを確認します。
AWS Well-Architectedの復元テストに関する指針 は、復元後のデータ内容と利用可否、所要時間を確認し、業務の復旧目標と比べる考え方を示します。AWS上の一般的な信頼性指針で、AI固有の事故率や自社の復旧能力を示す資料ではありません。復元対象や目標値は自社の業務で決めます。
再開資料には、止めた範囲、修正内容、再試験、復元・データ確認、残る未確認、当面の制限、承認者を書きます。全面再開だけでなく、回答案の作成まで、特定利用者だけ、外部送信なし、といった限定再開も選べます。
すべての問題で、データをバックアップから戻す必要があるわけではありません。誤った回答だけを訂正すればよいのか、台帳の更新まで戻すのかを分けます。復元によって問題と無関係な正しい記録まで失わないよう、戻す対象を業務担当と確認します。
上司と関係者には、この再開資料に初動の連絡先を加えて共有します。その場で、誰が外部送信を止められるか、誰が影響範囲を確定するか、次の説明をいつ出すか、誰が限定・全面再開を承認するかを合意します。担当名だけでなく、不在時の代行先も決めておけば、一人の判断待ちで対応が止まりません。
再開は「直った」という報告ではなく、修正後の結果、戻した業務、残る制限を責任者が引き受ける判断です。
誤った回答を一件見つけた想定で、連絡・停止・保全・再開をたどる
問題対応の準備は、長い手順書を書くことから始めなくても構いません。現場の兆候から、停止、保全、影響確認、説明、再開までの担当を一枚にします。
次の試行では、誤った回答を一件見つけた想定で、連絡先へ届くか、社外送信だけ止められるか、必要な記録を残せるか、誰が限定再開を決めるかをたどってください。空欄になった受渡しが、利用を広げる前に決める仕事です。