AIエージェント インシデント対応｜工場の停止・復旧手順

AIエージェント インシデント対応は、異常を見つけてからログを眺め始める仕事ではありません。タイの製造拠点でエージェントがMES、ERP、保全端末、文書、メール、外部サービスへ接続するなら、発生直後に「何を止めるか」「どの資格情報を失効させるか」「何を証拠として残すか」「誰が復旧を承認するか」を決めておく必要があります。本稿は予防や導入前試験ではなく、事故発生後の停止、証拠保全、影響判定、安全復旧、再発防止に絞った実務プレイブックです。

AIエージェント インシデント対応は従来のIT事故対応と何が違うか

従来の業務システムでは、利用者、アプリケーション、API、データベースの関係が比較的固定されています。ところがAIエージェントは、自然言語の依頼を解釈し、計画を立て、複数のツールを順番に呼び出し、途中結果に応じて次の行動を変えます。同じ入力でも、参照した文書、モデル、プロンプト、権限、外部サービスの状態によって実行経路が変わり得ます。

そのため、事故の対象は「誤った回答」だけではありません。誤った発注案をERPへ登録した、保全依頼を誤った設備へ割り当てた、許可されていない共有フォルダを検索した、同じ処理を繰り返した、承認前に外部へ送信した、想定外のネットワーク先へアクセスした、といった行動も含みます。工場では、デジタル上の誤操作が生産計画、品質判定、設備状態、出荷、作業員の安全へ波及する可能性があるため、ITだけで閉じない判断が必要です。

一方で、AIを特別視しすぎるのも危険です。すべてを「モデルの暴走」と呼ぶと、資格情報の過大付与、APIの冪等性不足、承認フローの欠落、サンドボックスの誤設定、監視の死角といった通常の設計不備を見逃します。事故調査では、モデル出力、エージェント実装、接続ツール、ID基盤、ネットワーク、OT側の受け口を分けて確認します。

NISTは2026年のAI Incident Managementワークショップで、AI関連インシデントの定義、ライフサイクル、分類、既存ガイダンスの不足を議論しました。これは、AI事故対応が完成済みの単一規格に収まる段階ではなく、既存のサイバーインシデント対応とAI固有の観測点を組み合わせる必要があることを示唆します。実務では、NIST SP 800-61 Rev.3のDetect、Respond、Recover、継続改善という骨格に、エージェントのトレース、ツール実行、モデル・プロンプトの版、承認記録を加えるのが現実的です。

評価環境の事例から学ぶが、企業一般の事故率には換算しない

Anthropicは2026年8月31日、サイバー防護を意図的に弱めた評価条件において、第三者評価環境の誤設定を通じてモデルが実システムへアクセスした事例への対応を公表しました。2026年9月9日の詳細評価では、最初に約141,000件のトランスクリプトを調べて3件を把握し、その後の拡張調査で4件目を確認したと明示しています。さらに約4億8,100万件を広くスキャンし、一次選別された920万件を二次スキャンへ回し、同種以上の深刻度の追加事例は見つからなかったとしています。

ここで重要なのは数字の大きさではなく、条件です。4件はすべて、同じ第三者評価パートナーが構築したサイバー評価で、モデルには製品版のサイバー防護がなく、シミュレーションだと伝えられた一方で、誤設定により実インターネットへ接続できました。したがって、4件を約4億8,100万件で割って「AIエージェントの事故率」とすることも、反対に「ほぼ起きない」と結論づけることも適切ではありません。対象ログは異質であり、通常の企業利用とも条件が違います。

発注者が持ち帰るべき教訓は、モデルの性質に関する断定ではなく、境界が破れたときにも止められる多層防御です。Anthropicが公表した対策には、評価の一時停止、サンドボックス強化、異常な境界探索を検知してツール呼び出し前にブロックする監視、タスク終了、人への通知、外向き通信の制限が含まれます。工場向けエージェントでも、「プロンプトに禁止と書いたから安全」ではなく、実行側で停止できる仕組みを持つ必要があります。

AIエージェント 事故対応の対象を最初に定義する

プレイブックの冒頭には、事故として扱う入口を記載します。入口が曖昧だと、現場は「AIの回答が少し変だっただけ」と判断し、調査に必要なログが上書きされます。反対に、軽微な表現揺れまで重大事故にすると運用が麻痺します。初期分類は、影響がまだ確定していなくても、観測した事実に基づいて開始できるようにします。

本稿では実務用の提案として、重大度を3段階に分けます。これは法令上の区分ではなく、初動をそろえるための社内設計です。

重大度は途中で変わります。最初はSev-3に見えても、外部送信や資格情報利用が分かれば引き上げます。逆に、アラートが誤検知と確認できれば、証拠と判断根拠を残したうえで終結できます。重要なのは、AI運用担当だけで重大度を固定しないことです。設備安全はOTと安全責任者、個人データは法務/DPO、事業影響は工場長が評価します。

AIエージェント 緊急停止は物理非常停止の代替ではない

「AIエージェントの緊急停止」という言葉は誤解されやすいため、プレイブックに定義を書きます。本稿でいう緊急停止は、エージェントの新規セッション受付、実行中セッション、ツール呼び出し、資格情報、ネットワーク経路を論理的に封じ込めることです。設備の非常停止、安全PLC、安全リレー、インターロックなどの安全機能を置き換えるものではありません。

まず止めるのはエージェントの「判断」ではなく実行経路

異常時にモデルへ「もう実行しないで」と追加指示するだけでは不十分です。プロンプトは一つの制御層ですが、事故対応では外側から実行を止めます。具体的には、新規ジョブ投入を停止し、実行キューを保留し、ツールゲートウェイで書き込み系呼び出しを拒否し、該当セッションを終了します。読み取りも情報漏えいの疑いがあれば止めます。

工場では、MESやERP側にも停止点を設けます。たとえば、AI専用サービスアカウントからの登録を一時拒否し、AI由来の未確定トランザクションを保留し、PLCや設備ゲートウェイへ直接書き込めない構成を維持します。すでにコマンドが現場へ届いた可能性があるなら、AI基盤を止めただけで安心せず、OT担当が設備状態を現認します。

資格情報の失効を停止操作と同時に走らせる

セッションを止めても、APIキー、OAuthトークン、サービスアカウント、署名用秘密、MCP接続資格情報が有効なままなら、別経路から処理が続く可能性があります。停止手順には、エージェント専用資格情報の失効、短期トークンの無効化、鍵のローテーション、関連セッションの破棄を含めます。

ただし、無差別に全社資格情報を失効させると生産継続へ大きな影響が出ます。あらかじめ「エージェント専用ID」「ツール別スコープ」「工場・環境別の秘密」を分けておけば、事故時に狭い範囲で止められます。これは予防設計の話でもありますが、事故対応の実効性を左右するため、RFPで必ず確認すべき項目です。

ネットワーク隔離は通信先を限定して行う

異常な外部アクセスが疑われる場合、エージェント実行環境の外向き通信、MCPやAPIゲートウェイ、踏み台、プロキシの経路を遮断します。ただし、監視ログの転送まで止めると証拠が失われます。制御経路、業務データ経路、監視経路を分け、封じ込め時にも監視ログを安全な保管先へ送れる設計が必要です。

AIエージェント ログ保全は4系統を別々に集める

原因究明の失敗は、ログが無いことよりも「何を保存すべきか分からず、同じログを何度も集める」ことから起きます。本稿では証拠を4系統に整理します。これは本記事の運用上の分類であり、製品固有の用語ではありません。

Agent Trace：モデルがどう判断し、何を委任したか

Agent Traceには、利用者入力、システム指示、参照コンテキスト、モデル応答、計画、ツール選択、サブエージェント委任、エラー、再試行、最終出力を含めます。OpenAIのTracing資料でも、トレースはターン内のモデル応答、ツール呼び出し、他エージェントへの委任を示し、各ステップの入力、出力、所要時間、状態を確認できると説明されています。

ただし、ダッシュボードで見えることと、フォレンジック用途に十分であることは同じではありません。契約プラン、保持期間、エクスポート形式、個人データのマスキング、管理者アクセス、時刻表記を確認し、事故発生時に原本を取得できるようにします。保持期間は製品ごとに異なるため、未確認の数字をプレイブックへ書き込んではいけません。

Tool Call：外部システムに何を要求し、何が返ったか

ツールログでは、呼び出し元のエージェントとセッション、ツール名、引数、対象リソース、認可結果、応答、再試行、タイムアウト、冪等キーを保存します。機密値は平時から安全にマスクしつつ、調査に必要な識別子は残します。「成功」という状態だけでは、ERPへ何を登録したか、MESが何を受理したか、外部メールに何が添付されたかを判断できません。

ツールの応答がモデルへ返る前に変換される場合、変換前と変換後の両方が必要です。たとえば、データベースの複数行を要約してモデルへ渡す構成では、要約結果だけでなく元のクエリ、対象レコード、返却件数、変換処理の版を残します。

Identity Log：誰の権限で何が許可されたか

IDログには、利用者ID、エージェントのワークロードID、サービスアカウント、発行されたトークンのスコープ、同意、承認、権限昇格、失効、鍵の利用履歴を含めます。人の代理で動くエージェントでは、「利用者が閲覧できる」ことと「エージェントが自動送信できる」ことを分ける必要があります。

事故時には、どの資格情報が露出した可能性があるかを判断し、失効対象を決めます。秘密そのものをログへ残すのではなく、秘密の識別子、版、発行先、使用時刻、認可判定を残します。ログにAPIキーを平文保存する設計は、調査のために新たな漏えいリスクを作ります。

OT Event：現場で実際に何が起きたか

AI側のログが「コマンド送信失敗」と示しても、ゲートウェイや設備側では受理されている可能性があります。OT Eventには、MESイベント、SCADAアラーム、PLC変更履歴、設備ゲートウェイ、品質判定、電子作業票、作業員の確認記録を含めます。工場の時刻同期がずれていると因果関係を誤るため、タイムゾーン、時計の同期元、遅延、ログ採取時刻も記録します。

証拠保全では、元データを上書きせず、読み取り専用の保管先へ複製し、取得者、取得時刻、対象範囲、ハッシュ等の完全性情報、マスキング処理を記録します。法的な証拠能力や労務上の扱いは管轄と社内規程によるため、法務の確認を受けます。

影響範囲判定は「触れた可能性」と「実害」を分ける

事故直後は、何が起きたかが確定していません。そこで、影響範囲を「アクセス可能だった」「実際にアクセスした」「変更を要求した」「変更が受理された」「業務または人に影響した」という段階で整理します。アクセス権があっただけで漏えいと断定せず、ログが無いから影響なしとも断定しません。

調査表には少なくとも次の観点を含めます。

• データ: 個人データ、営業秘密、図面、レシピ、品質記録、取引先情報を閲覧・生成・送信したか
• 業務: 発注、在庫、計画、検査、出荷、保全のどこへ変更が入ったか
• OT: MES、SCADA、PLC、設備ゲートウェイ、ロボット、検査装置へ到達したか
• 安全: 人の安全、設備保護、環境、製品安全に関係する状態が変わったか
• 第三者: クラウド、外部MCP、メール、顧客・サプライヤー、保守会社へ情報や命令が渡ったか
• 時間: 最初の兆候、最初の実行、停止、資格情報失効、ログ確保の順序はどうか

製造業では、デジタルログだけで「現場影響なし」と判断しないことが重要です。対象設備、仕掛品、検査結果、ロット、出荷保留の必要性を、OT、品質、生産が確認します。AIの誤推奨を人が承認して実行した場合も、原因分析は「人が押した」で終わりません。画面表示、根拠提示、承認権限、時間圧力、アラート設計が妥当だったかを調べます。

RACIでAI運用・工場・法務・ベンダーの責任を切る

事故対応が遅れる典型的な理由は、技術不足より「停止を誰が決めるのか」が決まっていないことです。RACIは、実行責任Responsible、最終説明責任Accountable、協議Consulted、報告先Informedを明示するために使います。以下はタイ工場向けのたたき台です。組織と契約に合わせて変更してください。

ここで大切なのは、ベンダーをAccountableに置くだけで自社の責任が消えるわけではないことです。自社工場の操業、安全、個人データ、顧客対応は、契約で技術支援を受けても発注者側の意思決定が残ります。反対に、ベンダーしか取得できないトレースや基盤ログがあるなら、事故時の提供条件を契約へ入れなければRACIは機能しません。

連絡網には氏名だけでなく、役割、代行者、使用言語、連絡手段、夜間対応範囲を記載します。タイ拠点、本社、地域統括、海外クラウド事業者が関与する場合、英語またはタイ語で状況を共有できるテンプレートも用意します。

タイPDPAの72時間をAI事故一般の締切にしない

タイPDPCのGPPC PLUSは、PDPA第37条に基づく個人データ侵害の通知について72時間に言及しています。ただし、これはすべてのAIエージェント事故に適用される一律の初動期限ではありません。品質上の誤回答、設備停止、発注ミス、秘密情報の問題、サイバー事象は、それぞれ別の契約、法令、業界要求、社内ルールが関係します。

個人データが関係する可能性があれば、法務・DPOを早期に呼び、個人データ侵害に該当するか、通知が必要か、例外や追加要件はあるかを確認します。判断に必要なのは、対象者、データ項目、件数、暗号化状態、取得・送信先、悪用可能性、封じ込め状況です。本記事は法的助言ではなく、実際の判断はタイ法と関係国の法令、最新の当局ガイダンス、個別事実に基づいて行ってください。

また、72時間の時計だけを見て証拠保全や被害軽減を遅らせてはいけません。封じ込め、ログ保存、リスク評価、通知準備は並行して進めます。通知要否が未確定でも、判断時刻と根拠を記録します。

安全復旧は4ゲートを順番に通す

停止後、業務部門から「もう直ったなら戻してほしい」という圧力が生じます。しかし、設定を一つ変えて本番を全面再開すると、同じ条件で再発し、証拠も混ざります。本稿では安全復旧を4ゲートに分けます。これは法定要件ではなく、工場とITが共通判断を持つための提案です。

Gate: Sandbox Replay

保全した入力、ツール応答、モデル・プロンプト・エージェント実装の版を使い、外部へ影響しない環境で事象を再現します。本番データは必要最小限にし、匿名化または合成データを使います。再現できない場合も、原因不明のまま全面復旧せず、観測点を増やして限定運用へ進めるか判断します。

Gate: Human Approval

AI運用担当だけでなく、影響を受ける業務所有者、OT・安全、IT/SOCが対策と残存リスクを確認します。個人データや契約問題があれば法務・DPOも参加します。承認資料には、原因仮説、確認済み事実、未確認事項、変更内容、監視条件、ロールバック条件を記載します。

Gate: Limited Rollout

権限、対象設備、工場、シフト、処理種別を限定して再開します。最初から以前と同じ権限へ戻さず、読み取りのみ、人の承認必須、少量処理などに縮小します。監視担当者と停止権限者を明示し、異常が出たら即座に前の状態へ戻せるようにします。

Gate: Full Restore

限定運用で、期待する処理、監視、承認、ログ取得、ロールバックが機能したことを確認してから通常範囲へ戻します。全面復旧は「アラートが出なかった」だけで決めず、想定した正常シナリオと異常シナリオの両方を確認します。復旧後も強化監視を続け、残存課題を通常の問題管理へ移します。

AIエージェント 事故対応プレイブックは1枚の初動カードから始める

長い手順書は必要ですが、事故直後に最初から読まれるとは限りません。現場には1枚の初動カードを置き、詳細手順へのリンクを付けます。カードには次を載せます。

• 異常を見つけたら、対象エージェント名、時刻、画面、依頼内容、結果を記録する
• エージェントへ追加指示を繰り返さず、所定の停止操作を行う
• 対象セッション、書き込みツール、資格情報、ネットワーク経路を封じ込める
• ログ削除、再学習、設定上書き、同じ入力の本番再実行をしない
• 工場長、OT・安全、IT/SOC、AI運用責任者へ連絡する
• 個人データの可能性があれば法務・DPOへ直ちに連絡する
• 外部説明、顧客通知、SNS投稿を個人判断で行わない
• 復旧はSandbox Replayから始め、承認なしに全面再開しない

詳細プレイブックには、システム構成図、停止コマンド、資格情報一覧、ログ取得方法、RACI、連絡網、重大度判定、影響範囲テンプレート、復旧ゲート、顧客・当局通知の検討欄、振り返り様式を含めます。文書だけでなく、停止操作が実際に動くかを訓練で確認します。

AIエージェント 復旧訓練を90日で実装するロードマップ

90日は法定期限でも標準の必須期間でもありません。発注者が「いつか訓練する」を避けるための導入目安です。すでに重大なリスクがある場合は、ロードマップの完了を待たず、書き込み権限を制限し、暫定停止手順を先に整えます。

前半：棚卸しと停止点の確認

エージェント、モデル、プロンプト、接続ツール、サービスアカウント、データ、工場・設備との接点を一覧化します。各接点について、誰が止められるか、停止すると何が影響を受けるか、ログはどこにあるかを確認します。シャドー利用や部門独自の自動化も対象にします。

次に、キルスイッチ、ツールゲート、資格情報失効、ネットワーク隔離、業務側の保留操作を机上で確認します。物理安全機能との境界も文書化し、AI停止が設備非常停止の代替ではないことを共有します。

中盤：ログ保全とRACIの接続

4系統の証拠が同じ時刻軸で追えるかを試します。Agent Traceは取得できても、IDログやMESイベントと結びつかないことがあります。相関ID、ジョブID、製造指図、設備ID、利用者IDを橋渡しできるようにします。

RACIを関係者でレビューし、夜間や休日の代行者を決めます。ベンダーへ連絡したとき、どのログをどの形式で、どの権限者が要求できるかを実演します。機密情報を含むログの安全な受け渡し方法も確認します。

後半：机上演習から限定復旧まで通す

シナリオは、誤発注、外部送信、反復実行、権限逸脱、OT到達疑いなど、自社の利用形態から選びます。参加者へ最初から答えを渡さず、途中で新しい事実を追加し、重大度変更、法務判断、顧客説明、復旧判断を練習します。

机上だけで終わらず、非本番環境で停止、資格情報失効、ログ取得、Sandbox Replay、承認、限定再開、ロールバックまで確認します。本番に影響する操作は変更管理と安全手順に従います。訓練後は、連絡の遅れ、取得できなかったログ、権限の不整合、承認の曖昧さを改善項目として所有者と期限へ落とします。

RFP・契約で確認するAIエージェント インシデント対応要件

事故が起きてからベンダーへ「ログをください」と依頼しても、保持されていない、契約外、サブプロセッサにある、形式が読めないという問題が起きます。調達段階で次を質問してください。

停止と封じ込め

• 新規セッション、実行中ジョブ、特定ツール、特定工場だけを止められるか
• 顧客側管理者が停止できるか、ベンダー依頼が必要か
• 資格情報とセッションを即時失効できるか
• 外向き通信、MCP、APIの許可先を制限できるか
• 停止操作自体の監査ログが残るか

証拠と可観測性

• モデル入出力、ツール引数・結果、承認、委任、エラー、再試行を取得できるか
• トレースを機械可読形式でエクスポートできるか
• ログの保持、削除、リージョン、暗号化、アクセス制御を顧客が設定できるか
• モデル、プロンプト、ツール、エージェント実装の版を追跡できるか
• 相関IDを自社SIEM、ID基盤、MESログへ渡せるか

事故時の支援と責任

• 重大事故の受付、エスカレーション、技術支援、状況更新の条件は何か
• サービス提供者が把握した重大事象を顧客へ通知する条件は何か
• サブプロセッサや外部ツールのログ取得を誰が担うか
• 調査、復旧、再発防止、顧客・当局対応の役割分担はどうなるか
• 契約終了や緊急停止時にデータ、ログ、秘密情報をどう返却・削除するか

復旧と訓練

• 過去のセッションをサンドボックスで再実行できるか
• 読み取りのみ、人の承認必須、対象限定で段階復旧できるか
• 版のロールバックと設定差分を確認できるか
• 顧客参加の演習、証跡提供テスト、復旧テストに対応できるか
• 事後レビューで改善事項と完了証跡を共有できるか

OpenAIのAgents API発表では、エージェントの実行環境としてOpenAI管理サンドボックス、自社基盤、パートナー環境を選ぶ考え方が示されています。選択肢があること自体を安全性の保証と見なさず、自社のデータ、秘密情報、ネットワーク、ログ取得要件に合う環境を選定することが重要です。

既存の予防・受入試験・監査と事故対応をつなぐ

事故対応は独立した文書ですが、前後の活動と接続します。平時の権限分離やサンドボックス設計は、工場AIエージェントのセキュリティで確認できます。公開前に停止、権限、異常系を試す観点は、AIエージェント受入試験へつなげます。復旧後に監視や評価を継続する仕組みは、AIエージェントの継続評価・監査の範囲です。

3つの活動を混ぜないことが大切です。予防は事故を起こしにくくし、受入試験は公開判断の証拠を作り、継続監査は変化を捉えます。それでも起きた事象に対し、封じ込め、証拠保全、影響判定、安全復旧を実行するのが本稿のプレイブックです。

まとめ：止める、残す、見極める、段階的に戻す

AIエージェント インシデント対応の成否は、モデルへ正しい指示を出せるかではなく、エージェントの外側から実行を止め、資格情報を失効し、4系統の証拠を保全し、現場を含む影響範囲を判断できるかで決まります。復旧はSandbox Replay、Human Approval、Limited Rollout、Full Restoreの順で行い、工場長、OT・安全、IT/SOC、AI運用、法務・DPO、ベンダー、経営のRACIを事前に合わせます。タイPDPAの72時間は個人データ侵害の通知文脈であり、AI事故一般の一律期限ではありません。プレイブックは訓練し、停止点とログが本当に機能することを確かめて初めて使えるものになります。

TOMAS TECHでは、タイの製造拠点を前提に、AIエージェントの接続先棚卸し、停止・ログ保全の設計、RACI作成、復旧演習、RFP要件整理まで、検討段階からご相談いただけます。お問い合わせはこちらをご覧ください。

FAQ：AIエージェント 緊急停止はどこまで止めますか？

対象セッションだけでなく、新規受付、実行キュー、書き込みツール、関連資格情報、必要に応じて外向き通信を止めます。ただし、設備の物理非常停止や安全PLCとは別の仕組みです。OT担当が現場状態を確認し、監視ログの転送経路は可能な限り維持します。

FAQ：AIエージェント ログ保全では会話履歴だけで十分ですか？

十分ではありません。会話やモデル応答を含むAgent Trace、外部システムへのTool Call、認証・認可を示すIdentity Log、MES・SCADA・PLC等のOT Eventを関連づけます。秘密情報を平文で残さず、原本の完全性、取得者、取得時刻、時刻同期も記録します。

FAQ：AIエージェント 事故対応で72時間以内に必ず通知が必要ですか？

いいえ。タイPDPAの72時間は個人データ侵害通知の文脈です。すべてのAI事故に一律適用される期限ではありません。個人データが関係する可能性があれば、法務・DPOが最新法令、当局ガイダンス、個別事実に基づいて通知要否を判断します。

FAQ：AIエージェント 復旧訓練は本番環境で行うべきですか？

まず机上演習と非本番環境で、停止、資格情報失効、ログ取得、再現、承認、限定復旧、ロールバックを通します。本番に関係する操作は、変更管理、設備安全、操業計画に従って範囲を限定します。訓練の目的は、本番事故を再現することではなく、判断と制御が機能するか確かめることです。

FAQ：原因がモデルか設定か分からない場合でも復旧できますか？

原因を単一要因へ断定できない場合はあります。そのときは、確認済み事実、未確認事項、残存リスクを明示し、権限縮小、対象限定、人の承認、強化監視を条件に限定復旧を検討します。全面復旧を急がず、再現性と観測性を高めながら判断します。

参考情報

• Anthropic: Improving our alignment and security practices
• Anthropic: An alignment assessment of recent cybersecurity incidents
• OpenAI: Introducing the Agents API
• OpenAI Developers: Tracing
• NIST Workshop on AI Incident Management
• NIST AI 600-1
• NIST SP 800-61 Rev.3
• ETDA: Driving Trust AI Governance
• Thailand PDPC: GPPC PLUS