Askhub
資料請求 お問い合わせ
お問い合わせ

ナレッジ

AIエージェントの監視と停止 ── 改ざんできない監査ログとキルスイッチ

停止ボタンだけでは、止められない

「停止ボタンがあれば、AIはいつでも止められる」
稟議や審査の場では、そう答えたくなると思います。

管理部門で、月末の請求書照合をAIに夜間に回させたいとします。
審査では、必ず「おかしくなったら止められるのか」と聞かれます。

でも、ボタンがあるだけでは止められない、と私たちは考えています。
夜中に、おかしな照合が始まったとします。誰がそれに気づくのか。気づいた人は、何を根拠に押すのか。押した後、何を戻せるのか。
ボタンは、その最後の一手にすぎません。

この問いが出るのも無理はありません。AIが定められた範囲の外に出た例は、実際に報じられています。
2025年7月には、米国の起業家が試していたReplitのAIエージェントが、本番のデータベースを消しました（eWEEK）。
コードの変更を凍結していた期間です。本人は「承認なしに変えないよう指示していた」と述べています。
2026年7月には、OpenAIが社内で評価していたAIエージェントが隔離を破りました。Hugging Faceの基盤に侵入したと、両社が公表しています。
研究での評価中の出来事で、企業の業務利用ではありません。

スペインのINCIBE-CERTのまとめでは、活動は7月9〜13日。記録された操作は約17,600件でした。
5日間で、1日あたり3,000件を超える計算です。人が横で見ていて追える数ではありません。

公表された範囲では、どちらも外部からの乗っ取りは示されていません。仕事を進める過程で、定められた範囲の外に出たと読めます。
OWASP（国際的なセキュリティ団体）も、こうした「範囲の外に出るAI」を、AIエージェントの主なリスクの一つに挙げています。

範囲の外に出にくくする設計は、AIエージェントの権限設計とプロンプトインジェクションとは？防げない前提の対策と確認8項目で扱いました。
この記事は、それでも起きたことに気づき、止め、説明する側の話です。

要るのは、異常に気づくための記録。記録を読む見張り。気づいたときの止め方。
この3つがそろって初めて、「止められます」と答えられます。

では、何を記録しておけばよいのでしょうか。

辿れなければ、説明できない

監査で聞かれるのは、1つの問いです。
「この記録は、誰の代わりにどのAIが変え、誰が承認し、何を根拠にしたのか」

答えるには、4種類の記録をつなげて辿れることが要ります。
どの記録のどの項目が、いつ、何から何に変わったかという変更履歴。
誰がどの経路から承認・却下したかという承認履歴。自動承認（決めた条件なら人の承認なしで確定する仕組み）なら、どのルールのどの版か。
AIが業務操作を提案・実行したときの入力、根拠、結果を残す判断ログ。業務操作は、「入金を消し込む」のような、あらかじめ定めた業務の単位の操作です。
そして、権限の変更、外部連携の接続、設定の変更、操作の拒否など、業務の記録の外で起きたことを残す監査ログ。

夜間の請求書照合なら、翌朝にこう辿れる状態です。
どの請求書を、どの入金と突き合わせたか。何を根拠に一致と判断したか。誰がその結果を確定したか。

国の指針も、同じ方向を向いています。
総務省と経済産業省のAI事業者ガイドライン（第1.2版、2026年3月31日）は、入出力や判断根拠のログを記録・保存するよう勧めています。保存期間も、事故の原因究明などを踏まえて検討するよう求めています。
拘束力のある規則ではありませんが、審査で示す物差しには十分です。

人とAIの操作を区別して残す項目はAIエージェントは誰の権限で動くのか、承認の記録はAIエージェントの承認はどの粒度で？承認疲れと自動承認ルールで整理しています。

ただ、記録は残すだけでは足りません。

書き換えられる記録は、証拠にならない

AIが乗っ取られていれば、痕跡を消そうとするかもしれません。管理者による改ざんもありえます。
だから記録には、足すことだけを許します。更新も削除もさせません。
AIも管理者も書き換えられず、元の会話やデータを消しても記録は残る。そういう状態を作ります。

大手クラウドなら、標準の機能で用意されています。
たとえばAWSの一度だけ書ける保管場所では、決めた保存期間のあいだ、最上位の管理者でも記録を消せません。
推進者は、「誰も書き換えられない形で、何年残るか」を確かめておけば十分です。

もう1つ気にしたいのが、記録の置き場所です。
AIを動かす仕組みの中にしか記録がないと、欠けや誤りに外から気づけません。サービスが止まれば、記録も失われます。運用者自身による改ざんも防げません。

そこで、記録の写しを自社の側にも置けるようにします。
自社のログの保管場所や、社内のログを集めて異常を知らせる監視基盤（SIEM）です。外部のサービスを使う場合も、内製する場合も同じです。
内製なら、AIの基盤とログの保管は、別の人が管理します。振る舞いと証拠を、同じ手に握らせないためです。

図1 記録と停止の経路 · 写しと止める経路を運用者の外にも持つ
業務の記録は業務システムに、操作の記録はAIサービスに残ります。どちらも写しを運用者1人では消せない保管場所とSIEMへ出し、止める経路はAIサービスと鍵の管理の両方に持ちます。

では、その記録を誰が読むのか。

見張りは、業務の責任者とSOCで分ける

AIの記録をSIEMに乗せると、既存の記録と突き合わせられます。退職予定者の代理で動くAIが、休日に大量の取引先情報を読む。そんな動きにも気づけます。

AIが触れる側のシステムの監視も効きます。
先のHugging Faceの例では、侵入された側が自分の基盤の監視で検知し、止めました。

ただ、監視チーム（SOC）が得意なのは、「いつもと違う」を見つけることです。業務として正しいかの判断ではありません。
夜間の照合の結果が規程に合うかは、経理や管理部門の責任者でなければ分かりません。

だから、見るものを分けます。
業務の責任者が見るのは、自動承認の割合、却下率、修正率の急な変化。停止や拒否の記録。
SOCや情シスが見るのは、いつもと違う時間帯、件数、通信先。失敗や拒否が続く操作。

拒否の記録は、見過ごされがちです。でも、ここに早い合図があります。
金額や取引先が台帳と矛盾しないかなど、実行前にシステムが確かめる条件を、前提条件と呼びます。これに拒否された操作や、失敗した操作は、攻撃の早い段階の合図になりえます。
英国の国家サイバーセキュリティセンター（NCSC）も、失敗した呼び出しを検知して対応すれば、攻撃を早く捉えられるとしています。
だから拒否も、成功と同じように記録に残します。

SOCが無い会社は、外部の監視サービスや、クラウドの標準のアラートから始められます。
業務の責任者が週に1度、却下率と停止の記録を見る。それだけでも、最初の見張りになると考えています。

難しいのは、見つけた動きの見分けです。

意図は問わず、範囲で判定する

与えられた目標に熱心なAIは、断られても別の方法を試します。
その動きは、乗っ取られたAIの動きと、記録の上ではよく似ています。

だから、AIの意図は推し量りません。
「定めた範囲を越えようとしたか」で判定します。

兆候

熱心な試行錯誤でよくある形

乗っ取り・悪意を疑う形

前提条件での拒否

同じ業務操作を、入力を変えて何度か試す

拒否されるたびに、別の操作や別の対象を探し始める

読む範囲

仕事に関係する記録を広めに読む

仕事と無関係な記録、権限の設定、鍵の置き場所を読もうとする

件数と金額

繰り返しのせいで件数が増える

1件ずつは上限の内側だが、小分けにして積み上げる

どちらであっても、最初の対応は同じです。
範囲を越えようとする動きが続いたら、まず止める。調べるのは、その後に記録で。

OWASPも、想定した振る舞いを基準線として定め、そこからの外れを監視することを対策に挙げています。ただ、その基準線をまだ持たない組織が多い、とも指摘されています。
夜間の請求書照合なら、「1晩に何件照合し、何件を人に回すか」。これが最初の基準線になります。

まず止める、と書きました。
では、どう止めるのか。

止め方は、小さい順にそろえる

キルスイッチとは、AIを作業の途中でも止める手段のことです。
AI事業者ガイドラインの別添も、侵害や危害が起きたときの初動として「AIシステムの停止（キルスイッチ）」を、復旧や遮断と並べて挙げています。

ただ、「全部止める」ボタンが1つだけでは、押せません。
業務も一緒に止まるので、確証がないと踏み切れないからです。
だから、小さく止める手段から段階を分けて用意します。1件の実行だけ。1つの業務やルールだけ。下の図はその一例です。

図2 止め方の5段階 · 小さく止める手段から順に
まず小さく止め、足りなければ次の段に進みます。段が分かれていれば、迷わずに最初の一手を打てます。夜間の請求書照合なら、おかしな照合が続いたときに、その処理だけを止め、他のAIの仕事は動かしたままにできます。

そのうえで、決めておくことが3つあります。

1つ目は、誰が押せるか。
段階ごとに、止める権限を持つ人と代理を決めます。夜間や休日にも、連絡がつくようにしておきます。

2つ目は、本当に止まるか。ここが一番の落とし穴だと思います。
実行中の処理は止まっても、定期実行や外部からの呼び出しが動き続ける。そうした抜けが起きやすいからです。
だから、検証用の環境で試しておきます。たとえば四半期に1度、各段を実行する。新しい処理が始まらないこと。実行中の処理が止まること。鍵が使えなくなること。確かめた結果は記録に残します。

3つ目は、止めた後どうするか。
途中まで進んだ業務操作を、取り消しの業務操作でどう戻すか。誰が再開を決めるか。

止めるべきものは、AIの動きだけではありません。

通知では、費用は止まらない

AIの利用料は、従量課金が中心です。
同じ処理の繰り返し。漏れた鍵の不正利用。どちらでも、請求は一気に膨らみます。

2026年4月には、国内のクラウド事業者G-genが注意を促しました（@IT）。APIキーが漏れてGeminiを不正に使われ、数百万円の請求が出た事例があるというものです。
鍵の漏れは、そのまま請求になります。

ここで気をつけたいのは、知らせる仕組みと止める仕組みが別物だという点です。
利用額のアラートは通知だけで、利用は続くことがあります。OpenAIも、アラートは通知のみで、上限で止めるには別の設定が要ると明記しています。
しかも、止める上限でも反映は即時ではなく、わずかに超えることがあります。
Googleが2026年3月にGemini APIへ入れたプロジェクトごとの月額上限も、反映に約10分の遅れがあります。その間の超過は、利用者の負担です。

勢いよく回る水道メーターの隣で、人の手が赤い止水栓のハンドルを回して閉めている。配管の先の蛇口からは水が滴っている
メーターを見るだけでは水は止まりません。元栓を閉めても、しばらくは滴ります。費用の上限も、反映に遅れがあります。

だから、費用の守りは2か所に置きます。
1つは、AIの提供者の側。月ごとの利用額の上限を、通知ではなく止める設定で入れます。用途ごとに鍵とプロジェクトを分け、漏れたときの影響を限ります。
もう1つは、自社の業務の側。業務操作ごとに、1日の件数や合計金額の上限を置きます。1件ずつは上限の内側でも、小分けに積み上げる動きを止めるためです。

上限は、低すぎれば業務が止まり、高すぎれば守りになりません。
小さく始め、実績を見て広げれば十分です。

それでも何かが起きたら、止めた後の仕事が始まります。

止めた後は、範囲を特定して戻す

AIならではの作業は、影響の範囲を特定して戻すことです。
止めた時点までに、そのAIが変えた記録を、判断ログと変更履歴から洗い出す。それを、取り消しの業務操作で戻す。
自動承認で通ったものは、どのルールのどの版かが分かれば、対象を絞れます。
最初に残した記録が、ここで効きます。

個人データの漏えいが疑われるときの報告先や相談先は、相次ぐ不正アクセスはなぜ止まらない？原因と今すぐ確かめる8項目にまとめています。

AIのインシデントを業界で共有する仕組みは、まだ発展途上です。
OECDは、AIインシデントを報告する共通の枠組み（29の基準）を示しました。ただ、開示を義務づける業界のルールはまだありません。
事業者の側で何か起きたとき、何日以内に何が知らされるか。これは契約の段階で確かめておきます。

ここまでをシステムでそろえても、人にしか決められないことが残ります。

上限も、保存期間も、再開も、人が決める

件数・金額・利用額の上限と、記録の保存期間は、会社の判断です。
保存期間は、監査の対象期間と、不正に気づくまでの日数より長くします。帳簿や書類にかかわる記録は、法定の保存期間より短くしません。
たとえば会社法は、会計帳簿と事業に関する重要な資料を、帳簿の閉鎖から10年保存するよう求めています。法人税法は、帳簿書類を原則7年（欠損金が生じた年度は10年）です（国税庁）。

再開も、人が判断します。原因が分かり、戻し終えてから再開するのか。
記録を読む人も決めます。記録は、読まれて初めて役に立ちます。

システムと運用の責任の分け方はAIエージェントの責任は誰が負う？システムと運用の責任分界で整理しています。

導入がスムーズに進みやすいAIの選び方

次の基準を満たすAIなら、情シスへの説明が短く済み、導入がスムーズに進みやすくなります。

  • 記録がAIにも管理者にも書き換えられない形で残り、元の会話を消しても消えない
  • 記録を自社でも受け取れ、SIEMなどに取り込める
  • 人の操作とAIの操作を区別し、誰の依頼で動いたかまで記録する
  • 全部止める以外に、1つの処理や業務だけを止められる
  • 利用額や件数に、通知だけでなく止める上限を置ける

情シスに説明するときの要点

  • AIの操作は、変更履歴・承認履歴・判断ログ・監査ログとして、誰も書き換えられない形で残ります
  • 記録の写しは自社のSIEMなどにも取り込め、既存の監視に載せられます
  • 見張りは、業務の正しさを業務の責任者が、いつもと違う動きをSOCや情シスが見る分担です
  • 止め方は1件・1業務から全体まで段階で用意し、誰が押すかを夜間・休日も含めて決めています
  • 費用は、通知だけでなく止める上限を、提供者の側と業務の側の両方に置きます

止められるから、任せられる

「止められるか」という問いに、ボタン1つでは答えられません。
記録が残り、誰かが読み、小さい順に止められる。この3つがそろえば、答えられます。

記録は書き換えられない形で、写しを自社にも。見張りは業務の責任者とSOCで分担。止め方は小さい順に、費用には止める上限を。

夜間の請求書照合も、上限を低めにして小さく始めれば十分です。
記録を見ながら、任せる範囲を広げていけます。
止められる形さえ作れば、人が見ていない時間の仕事も、AIに任せられる。私たちは、そう確信しています。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

本文の「記録を自社でも確かめられるようにする」に対して、Askhubは監査ログを、書き換えを防ぎ全ての版を残す設定の保存先に置き、10年間保存しています。元の会話やデータを消しても、記録は残ります。人の操作だけでなくAIやトリガーの操作も残り、その場合は誰の依頼で動いたかも記録されます。個人情報を必要以上に残さないよう、会話や文書の本文、メールアドレスは監査ログに含めません。監査ログはご要望に応じてお客様に提供するので、自社のSIEMなどに取り込んで、写しを手元に置けます。管理者は、必要なときにエージェントの動きを柔軟に止められます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：AIエージェント、製品の全体像

ナレッジの記事をもっと見る