法律事務所のAIエージェントが停止したときの再開手順－安全監視，プロンプトインジェクション，二重送信・二重公開及び証拠保全（AI作成）

第１　本記事の対象と結論

AIエージェントが安全監視，通信障害又は外部資料中の不審な指示によって停止したとき，「同じ指示をもう一度実行する」だけでは，メールの二重送信，記事の二重公開，ファイルの上書き又は同じ申立ての重複処理を招くことがある。

停止した要求がそれ以上進まないことと，停止前に完了した外部操作が取り消されることは別である。
本記事は，法律事務所がAIエージェントを停止させた後，証拠と外部状態を保全し，弁護士の承認を経て安全に再開するための一般的な手順を整理する。

本記事の対象は，生成AIが検索，文書作成又は要約だけでなく，ファイル保存，メール送信，ウェブサイト更新その他のツール操作まで行う場合である。

結論は，次のとおりである。

①異常又は停止を検知したら，その要求だけでなく，同じ目的のために動いている他の処理もいったん止める。

②要求ID，応答ID，ツール呼出し，時刻，画面，ログ及び作業対象を保存し，停止前に何が実行済みかを確認する。

③メール，WordPress，クラウドストレージその他の外部システムを読み戻し，「未実行」「実行済み」「成否不明」を区別する。

④成否不明の操作を自動で再試行しない。再開票に確認済みの状態，残作業，重複防止策及び必要な承認を記録する。

⑤送信，提出，公開，削除，決済又は権限変更は，弁護士が対象と外部状態を確認した後，一回に限って再開する。

この手順は，法令又は裁判例が定める統一的な様式ではなく，弁護士情報セキュリティ規程等を実務へ落とし込むための提案である。

１　症状から確認先を選ぶ

次の表は，既に述べた再開手順を使うための運用上の整理である。症状だけで原因を断定せず，最初に確認する範囲を絞る。

第２　自動で再試行してはいけない理由

生成AIの安全監視は，入力又は出力に問題があると判断した時点で，その後の処理を止めることがある。しかし，監視処理が非同期で行われる場合，停止までに一部のツール操作が完了していることがある。

OpenAIの開発者向け資料「Misalignment monitoring」は，監視で停止した場合に自動再試行をせず，要求・応答の識別子，ツール呼出し及びアプリケーション側の記録を保存し，既に行われた変更を確認するよう説明している。同資料はOpenAI製品の運用に関するベンダー一次資料であり，日本法上の一般的義務を直接定めるものではないが，「停止は巻戻しではない」という技術上の区別は他のAIエージェントでも有用である。

通信のタイムアウトも同じである。利用者側が応答を受け取れなくても，外部システム側では送信又は保存が完了している場合がある。「エラーになったから未実行」と決めつけず，外部状態を読み戻してから次の操作を決める必要がある。

第３　停止直後に行うこと

停止直後は，原因分析より先に，被害拡大と証拠の散逸を防ぐ。

①同じ案件，同じ送信先又は同じ公開先を扱う他のAI処理を停止する。

②要求ID，応答ID，利用モデル，セッション又は作業ID，実行日時及び利用アカウントを保存する。

③AIが呼び出したツール，入力値，戻り値及びエラーを，表示された順序が分かる形で保存する。

④作業画面，送信済みフォルダ，公開画面，ファイルの版履歴その他の外部状態を取得時刻付きで記録する。

⑤資格情報の不正利用が疑われるときは，当該経路を停止し，失効又は変更を行った者と時刻を記録する。

⑥依頼者情報その他の秘密情報が外部へ送信された可能性があるときは，対象案件と情報の範囲を特定する。

ログをAI自身が変更できる作業フォルダだけに置くと，誤操作又は侵害時に検証できない。監査ログ及び保全コピーは別の管理境界へ保存する。

異常を検知したこと，警報を人が受け取ったこと，停止操作を行ったこと及び処理の停止を確認したことは，別々の状態である。
停止記録には，それぞれの時刻と担当者，停止した処理，停止前後に生じた外部操作及び停止を確認できない処理を残す。
画面の会話が終わっても，子プロセス，予約処理，他のAI又は連携サービスの処理が残る場合があるため，影響する処理の範囲を確認する。

OpenAIの令和8年9月20日のDNS経由の外部通信に関する事故報告は，監視が15分以内に警報を出し，人がその約3分後に受領した一方，予定された自動停止が働かず，受領後約2時間半で手動停止したと説明する。
これは同社の研究環境についての当事者報告であり，法律事務所の事故率や日本法上の責任を示す資料ではない。
警報への応答と実際の停止完了を別に確認する必要性を考える事例として参照できる。

稼働前には秘密情報を含まない試験環境で停止を試し，新たな書込み・外部送信・予約処理が止まったかを確認する。
作業AIが変更できない管理経路から停止できる担当者，代替担当者及び停止確認ができないときの上申先を決める。
再開の許可は，停止指示を出したことだけでなく，外部状態と残存処理を確認した結果に基づいて行う。

第４　停止原因の分類

複数の原因が重なることもある。例えば，外部資料中の指示で不自然な送信を試み，安全監視が止め，さらに送信先の応答がタイムアウトした場合は，プロンプトインジェクション，安全監視及び成否不明の外部操作を別々に確認する。

停止の分類では，失敗した操作の範囲と，外部へ既に生じた可能性のある効果を先に確かめる。
次の表は，既存の分類を実際の問い合わせへ当てはめるための運用例である。

通常の取得失敗と，明示的な拒否を同じ復旧手順へまとめない。
拒否がなく，未終了処理や二重実行の危険もなく，当初の許可範囲内で安全に続けられる読取りは，送信・公開等の再開と分けて判断する方法が考えられる。

一つの画像が取得できなかったことだけで，文章，保存値又は別の確認結果まで取得不能としない。
反対に，文字を読めたことから，画像，レイアウト又は保存・公開まで確認済みと推定しない。

タイムアウトの表示だけでは，通信，ブラウザー接続，画面取得又は外部システムのどこで失敗したか確定できない場合がある。
確認できた層と未確認の層を記録し，同じ条件での反復を増やさず，許された継続経路がなければ停止して担当者へ報告する。

CodexでHTTP 429又は「Too Many Requests」が表示された場合は，応答本文のerror.code，Retry-After，利用経路及びUsage画面を確認する。
429が表示されても，直前の外部操作が未実行であったとは限らないため，本文第５以下の方法で外部状態を読み戻す。
同じアカウント又は同じAPI組織・プロジェクトのまま別IP・別PCへ移っても通常の上限はリセットされないため，原因別の確認方法は，Codexで４２９エラーが出る原因と対策－別IP・別PCで回避できるか（AI作成）を参照されたい。

停止の後にアプリを起動し直しても起動しない場合は，起動を繰り返す前に，表示されたエラーの全文と設定ファイルの更新日時を記録する。
アプリが動いている間に設定ファイルを書き換えていた場合は，その誤りが次の起動の時に初めて表に出ることもあると考えられるため，再開票にも稼働中に変更した設定とその複製の保存先を書いておく。
設定を直すときは，元のファイルの複製を残した上で該当箇所だけを改め，保護機能を一括で外して起動させる方法にはしない。
Codexで「config defines [permissions] profiles but does not set default_permissions」と表示される場合の確認方法は，Codexが起動しない「does not set default_permissions」の原因と直し方―config.tomlの権限プロファイル（AI作成）を参照されたい。

１　AI操作中にブラウザやPCが重くなったとき

画面操作を伴うAIエージェントの利用中にPCが重くなった場合は，開いているタブの数だけで原因を決めない。
ブラウザ内のタブ・拡張機能と，ブラウザ本体，画面読取り等を担う補助プロセスを分け，症状が出た時刻と負荷の推移を対応させて調べる。
ここでいう補助プロセスは，画面操作等のためにアプリとは別に動作するプログラムを指す。

GoogleのChromeの動作を速くするための案内は，タスクマネージャーによる不要なタスクの確認を説明し，タスクを終了すると未保存の作業が失われることにも注意を促している。
負荷が高いという表示だけを理由に，作業中のブラウザやアプリを一括終了する手順にはしない。

事務所の切分け手順としては，次の順序が考えられる。

1. 同じ画面取得の繰返しを止め，未保存の入力と，既に送信・保存した可能性のある操作を確認する。
2. ブラウザ内のタスクとOS側のプロセスを区別し，対象を識別できる情報と，測定時刻・測定時間・CPU使用率・メモリ使用量を記録する。
3. 補助プロセスだけを停止する場合も，実行ファイルの場所，親プロセス，利用セッション，開始時刻を確認し，別の作業のプロセスを巻き込まない。
4. 一度の変更ごとに，負荷の推移と，同じページの切替え・文字入力等の応答を確認する。
5. 改善しても製品内部の不具合の確定とはせず，問題が残る範囲と，再発した操作を別に記録する。

累積CPU時間と，ある測定区間のCPU使用率は異なる。
また，異なるツールのCPU使用率は表示の基準が同じとは限らないため，数字をそのまま比較して原因を断定せず，測定方法を記録して同じ条件で比較する。
停止・再起動後に応答が改善した場合も，その観測が直接示すのは，当該条件で改善が生じたということである。
製品一般の欠陥や唯一の原因まで確認できたことにはならない。

２　画面読取りの範囲と再試行の上限を決める

MicrosoftのUI Automationの要素検索に関する文書は，デスクトップ全体の子孫要素の探索が長時間を要する等の問題を招き得ることを説明し，対象のアプリのウィンドウ等から探索するよう注意している。
これはUI Automation一般の技術上の注意であり，特定のAIサービスで起きた遅延の原因を証明する資料ではない。

この注意を事務所の運用に取り入れるなら，読取り対象を必要なページ又は特定のウィンドウに限定し，必要のない全文取得を避けることが考えられる。
タイムアウト後は，呼出し側が待つことをやめただけなのか，実際の処理も終了したのかを分けて確認する。
終了が確認できないまま同じ取得を重ねる手順にはしない。

長時間の負荷に備えた自動停止を設ける場合は，停止対象を識別する条件，継続負荷を判断する時間，停止後の待機時間，停止回数の上限及び担当者への報告を定める。
これらの値は製品，PC及び業務に応じて検証する運用上の設定であり，一律の安全値とはしない。
保護処理が作動した後は，同じ画面取得を自動で再開せず，原因調査と再開判断へ戻す。
ソフトウェアを更新した後も，従来の保護条件がそのまま有効であると推定せず，機密情報を含まない試験画面で点検する。

診断資料をAIサービスやサポート窓口へ渡す際の確認は，派生データ条項と守秘義務の記事も参照されたい。

第５　外部システムの実際の状態を読み戻す

AIの画面に表示された「成功」「失敗」だけではなく，外部システム側の状態を確認する。

メール・チャットでは，送信済みフォルダ，メッセージID，宛先，添付及び送信時刻を確認する。下書きが残っていても，同じ内容が既に送られていることがある。

裁判所・行政機関への電子提出では，受付番号，事件番号，提出書面名，提出日時及び受領通知を確認する。受付の有無が画面だけで分からない場合は，システムの公式手順に従い，担当者が確認する。

WordPressその他の公開システムでは，管理画面の保存済み本文だけでなく，未ログイン状態の公開ページ，更新日時，URL及びメタ情報を確認する。画面遷移又は成功通知だけで公開内容を推測しない。

ファイル・データベースでは，ファイル名，保存先，更新時刻，版履歴，件数及び内容のハッシュ値を確認する。同期中の表示だけで保存完了と扱わない。

確認結果は，「未実行」「実行済み」「一部実行」「成否不明」の四つに分ける。成否不明の操作は，確認できるまで再開対象から外す。

第６　再開票に記録する事項

停止後の引継ぎは，長い会話履歴だけに依存せず，次の事項を一枚の再開票に固定する。

①案件名又は作業ID

②当初の目的と成果物

③停止を検知した日時，検知者及び停止理由

④最後に確認済みのチェックポイント

⑤既に完了した外部操作

⑥未実行の操作，一部実行の操作及び成否不明の操作

⑦保全したログ，画面，ファイル，要求・応答ID及び保存先

⑧失効させた資格情報と残っている権限

⑨再開後に実行する操作と実行しない操作

⑩重複を防ぐための識別子，内容のハッシュ値又は外部状態

⑪弁護士の承認を要する事項，承認者及び承認時刻

⑫再開担当者と完了を確認する方法

再開票は，AIが自ら「問題が解決した」と判断するためではなく，人が外部状態と残作業を短時間で確認するための記録である。

再開票の停止日時は一つの欄で済ませず，①異常検知，②警報受領，③停止操作，④停止完了の確認及び⑤再開承認の日時・担当者を対応させる。
自動停止の設定，実際の停止経路，残っている子プロセス・予約処理，その確認方法及び不明な外部操作も記載する。
停止完了を確認できない処理がある場合は，その処理と影響する操作を再開対象から外し，管理者へ確認を求める。

１　再開票の記入例

次は架空の請求メールについての記入例であり，特定のサービスの送達仕様を示すものではない。

結果を確認できなかった場合には，この例の結論を流用せず，「結果不明」として確認を続ける。履歴の表示と実際の成立状態がどこまで対応するかは，利用サービスの仕様により確認する。

第７　二重送信・二重公開を防ぐ設計

同じ操作の重複を防ぐ技術として，固有の作業ID，操作番号，送信済み台帳，内容のハッシュ値及び外部システムの受付番号を使う方法がある。APIが冪等キー（同じキーの要求を重複処理しないための識別子）に対応している場合は，その仕様を確認して利用できる。

ただし，すべてのシステムが冪等キーに対応するわけではなく，同じキーの有効期間や対象となる操作も異なる。技術用語だけで重複防止ができたと考えず，次の順で確認する。

①外部システムの状態を読み戻す。

②送信先，対象，内容，更新前後の版及び受付番号を照合する。

③既に実行済みなら，残作業だけを新しい操作番号で実行する。

④成否不明なら，同じ操作を直ちに再送せず，管理者又は公式の確認手段を使う。

⑤再開後の一回の操作について，再び管理画面と公開状態を読み戻す。

第８　プロンプトインジェクションが疑われる場合

ウェブページ，電子メール，PDF，OCR結果又は相手方から受領した文書には，AIに対して「これまでの指示を無視せよ」「秘密情報を送信せよ」等と働きかける文字列が含まれることがある。これは間接プロンプトインジェクションの一例である。

外部資料は，調査又は証拠の対象となるデータであって，法律事務所の操作権限を与える命令ではない。外部資料中の指示だけを根拠に，秘密情報の送信，ファイル変更，公開，削除，決済又は権限変更を行わせない。

OWASPは，検索拡張又は追加学習だけではプロンプトインジェクションを完全に防げないと説明している。OpenAIのGPT-6 Astra System Cardも，攻撃者がエージェントをデータ窃取，破壊的操作等へ誘導し得ることを示している。同System CardのGray Swanによる評価では，安全対策を有効にしたGPT-6 Astraについて，1シナリオ当たり15回の試行のうち少なくとも1回成功した攻撃の割合を8.5％と推計している。

この8.5％は，1810件の選定された攻撃シナリオに対する評価指標であり，法律事務所における現実の事故率ではない。しかし，モデルを新しくするだけでは残余リスクがなくならず，最小権限，接続先制限，資格情報の分離，人の承認及びログが必要であることを示す資料になる。

第９　復旧用バックアップと証拠保全を分ける

スナップショット，チェックポイント又はバックアップは，直前の状態へ戻し，作業を継続するための資料である。他方，停止原因や外部送信の有無を後で立証するには，取得元，取得日時，原本，ハッシュ値，保管経路及び変更履歴を別に記録する必要がある。

バックアップから復元したことだけで，停止時の証拠が取得後に変更されていないこと，又は裁判上の真正が当然に認められるわけではない。復旧のために上書きする前に，必要なログ及び状態を読み取り専用の形で保全する。

NISTの「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」は，生成AIについてインシデント対応及び復旧計画を整え，必要に応じて機能停止又は利用中止を行うことをリスク管理策として挙げる。これは米国の任意のリスク管理資料であり，日本の法律事務所に直接適用される法令ではない。

１　復旧作業の前に保全するもの

復旧のためのキャッシュ削除やアカウントの接続解除を，無条件の第一手にしない。Googleのパソコン版ドライブの案内には，接続解除で削除される一時保管用フォルダの未同期ファイルを，先に安全な場所へコピーする注意がある。Googleの公式案内

運用上は，未保存・未同期データと原因調査の記録を確認し，対象処理を特定してから終了・修復する方針とする。同じ名前のプロセスを一括終了する方法や，広範囲の設定削除を，通常業務のデータ保全を確認せずに実行しない。

第１０　弁護士の承認を経て再開する

再開承認では，単に「続けてよい」と言うのではなく，次の事項を確認する。

①当初の依頼及び作業目的が現在も有効であること

②停止前に完了した外部操作と残作業が区別されていること

③秘密情報，送信先，公開先及び利用アカウントが正しいこと

④プロンプトインジェクションその他の停止原因が除去又は隔離されていること

⑤再開する一回の操作と，その完了を確認する読戻し方法が定まっていること

⑥失敗した場合の再停止条件と連絡先が定まっていること

承認後は，残作業を小さな単位に分け，一回実行するごとに外部状態を確認する。送信，提出，公開，削除，決済及び権限変更を一括して再開しない。

CodexとChromeの接続を新しいチャットで回復できても，切断前の送信，公開又は保存が未実行であったことは証明されない。接続確認は読み取りだけの小さな作業で行い，停止前の外部状態を読み戻した後に，残作業だけを承認する。接続の確認順序は，CodexがChromeに接続できないときの対処法―拡張機能，Computer Use，@Chrome及び新しいチャット（AI作成）を参照されたい。

第１１　法律事務所向けチェックリスト

停止直後

□　同じ案件・目的の処理を止めた。

□　ホストPCが停止した場合は，発生時刻，停止範囲及び直前の外部操作を別端末にも記録した。

□　要求・応答ID，ツール呼出し，時刻及び画面を保存した。

□　秘密情報の外部送信又は資格情報の不正利用の可能性を確認した。

□　警報を受け取ったこととは別に，対象処理の停止完了を確認した。
□　子プロセス，予約処理及び連携先の残存処理を確認し，不明な処理を再開対象から外した。
□　停止操作・停止完了確認・再開承認の時刻と担当者を記録した。

再開判断前

□　外部システムを読み戻し，実行済み・未実行・成否不明を分けた。

□　送信先，受付番号，公開URL，更新時刻，版又はハッシュ値を記録した。

□　成否不明の操作を自動再試行の対象から外した。

□　再開票に残作業，重複防止策及び必要な承認を書いた。

再開後

□　承認された一回の操作だけを実行した。

□　保存済み本文，送信済み記録又は受付結果を読み戻した。

□　未ログインの公開画面その他の利用者側表示を確認した。

□　原因，影響範囲及び再発防止策を事故記録へ反映した。

第１２　法令・会規・判例との関係

日本弁護士連合会の弁護士情報セキュリティ規程4条は，弁護士等を取扱情報の情報セキュリティの責任者とし，組織的，人的，物理的及び技術的な安全管理措置を求める。同規程7条は，漏えい，滅失又は毀損等の事故について，影響範囲の把握，被害拡大防止，原因調査及び再発防止策の検討等を求める。

本記事の停止，外部状態の読戻し，再開票及び重複防止は，これらをAIエージェントの作業へ落とし込む実務上の提案である。同規程がAIエージェントの要求ID，冪等キー又は再開票を明文で義務付けているわけではない。

経済産業省・総務省のAI事業者ガイドライン（第1.2版）は，リスクベース・アプローチ，人間の判断・関与及び入力情報の管理等を示すが，法的拘束力のないソフトローである。

本記事の作成時に，判例秘書で「AIエージェントの安全監視後の自動再試行」「二重送信・二重公開」等について認証済みの裁判例検索は実施していない。このため，関連する裁判例がないとは評価しない。個別事件で過失，債務不履行，秘密保持義務違反又は証拠能力等を論じる場合は，事案に即した裁判例検索が別途必要である。

第１３　本記事の資料の位置付け

資料の位置付けは，次のように分ける。

①弁護士情報セキュリティ規程は，法律事務所の情報管理に関する会規である。

②経済産業省・総務省のAI事業者ガイドライン及びNISTの資料は，リスク管理の公的又は公的機関の指針であり，個別事件の法的結論を直接示す判例ではない。

③OpenAIの開発者向け資料及びSystem Cardは，同社製品の挙動，監視及び評価結果に関するベンダー一次資料である。他社製品又は日本法上の一般的義務を直接証明しない。

④OWASPの資料は，プロンプトインジェクションという技術上の脅威と対策を整理した業界資料である。

⑤本記事の再開票，四分類及びチェックリストは，上記資料から導いた法律事務所向けの実務提案であり，公的な標準様式ではない。

第１４　関連記事

事務所全体の利用ルールは，法律事務所の生成AI利用ガイドラインの作り方－許可サービス，入力情報，出力確認，委託先及び事故対応（AI作成）で整理している。

専用PC，最小権限及び承認疲れは，法律事務所がAIエージェントに専用PCを与えるときの安全設計－全権委任，承認疲れ，最小権限及び敬語の限界（AI作成）を参照されたい。

モデル切替え前の比較評価は，法律事務所で生成AIのモデルを使い分け・切り替えるときの設計―モデル単位の許可台帳，データ条件の確認及び切替え時の再検証（AI作成）で扱っている。

サンドボックス，通信制限，スナップショット及び証拠保全の違いは，法律事務所のAIサンドボックス入門－コンテナ，gVisor，MicroVM，通信制限，スナップショット及び証拠保全（AI作成）を参照されたい。

AIを動かすPC自体が停止した場合の期限確認，Windowsログの保全及び別PCからの安全な再開は，弁護士・税理士のAI業務用PCがフリーズしたときの初動－期限管理，送信成否，ログ保全及び安全な再開（AI作成）を参照されたい。

第１５　出典・参考資料

①OpenAI「Misalignment monitoring」（停止，自動再試行の禁止，要求・応答ID及び既実行の変更確認に関するベンダー一次資料）

②OpenAI「GPT-6 Astra System Card」（間接プロンプトインジェクションの評価に関するベンダー一次資料）

③OWASP「LLM01:2025 Prompt Injection」（技術上の脅威と対策を整理した業界資料）

④NIST「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（NIST AI 600-1，令和6年7月）

⑤日本弁護士連合会「弁護士情報セキュリティ規程」（会規第117号）

⑥経済産業省・総務省「AI事業者ガイドライン（第1.2版）」

⑦OpenAI Alignment「An agent used DNS to reach an external chatbot（https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/）」（令和8年9月20日の事案，同月25日更新の当事者報告。Summary及びInvestigation and responseの検知・警報受領・自動停止不作動・手動停止の説明を確認。）