AIに定期的な処理を任せ始めた。おかしな動きをしたときに止められるようにしておきたい。この記事はその段階にいるAI推進担当に向けたものです。従業員10〜20名で、既製のツールを設定画面から使っている会社を想定しています。この記事は手で止める操作から始めます。自動で止まる仕組みは、そのうえに載せるものです。
結論
停止条件の記事は「事前に閾値を設計する」で終わります。しかし実務で困るのは、閾値に引っかからないまま、説明できない違和感があるときです。先にやるべきことは3つです。止める操作を使い始める前に書き出す。止める権限を全員に開放する。空振りを責めないと明文化する。この3つがないと、自動で止まる仕組みを作っても、それをすり抜けた事象に対応できません。止めた後については、外部へ出たものがあるかの確認を最優先にします。社内で完結している処理は後から直せます。止まらない処理には型があります。同じ操作を繰り返して終わらない、誤った前提のまま次の手順へ進む、必要以上に広い権限で外部を操作する、の3つです。いずれも件数と実行時間は正常の範囲に収まりうるため、数値の条件だけでは掴めません。
閾値では止まらない場面がある
事前に条件を決めておく設計は有効です。ただし、次の場面では働きません。
| 場面 | なぜ閾値で止まらないか |
| 1件ずつは正常だが、出力の中身が間違っている | 件数も時間も正常の範囲に収まる |
| 想定していなかった動き方をしている | その動きに対する条件を用意していない |
| 外部のサービス側が変わった | こちらの条件は変わっていない |
| 人が見て「何かおかしい」と感じた | 感覚は条件に書けない |
逆に、数値で止められる場面もあります。1回あたりの最大件数、1回あたりの最大実行時間、連続して失敗したときの再試行回数の3つは数値で書ける条件で、明らかな異常を早く止める役に立ちます。ただし推奨値は製品と業務で変わります。解説記事にも公的資料にも相場は示されていないため、他社の数字を借りずに、自社の1回分の処理量から決めてください。
最後の項目が実務では最も多く起きます。説明はできないが違和感がある、という状態です。このとき止められるかどうかが、被害の大きさを決めます。
「止める手段を持つ」は公的な指針にも書かれている
自社の判断で決める話ではありません。総務省・経済産業省の「AI事業者ガイドライン」は、AIを利用する事業者向けの章で、危害が発生したときの初動措置として次を挙げています。
AIシステムのロールバック、代替システムの利用等による復旧。AIシステムの停止(キルスイッチ)。AIシステムのネットワークからの遮断。危害の内容の確認。関連するステークホルダーへの報告。
そのうえで、事前に準備しておくこととして危害発生時の連絡体制の事前整備と原因調査方法及び復旧作業方法の整理を挙げています。止め方と戻し方を、起きる前に決めておくという構成です。出典: 総務省・経済産業省「AI事業者ガイドライン(第1.2版)別添」PDF 178ページ「別添5. AI利用者向け」(令和8年3月31日/出典の確認日: 2026年8月31日)
なお、同ガイドラインはAIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義しています(本編PDF 12ページ/出典の確認日: 2026年8月31日)。高度な自律だけでなく、ある程度の自律性を持つものも含む、とされています。設定した条件で自動実行されるだけのものも、この記事の対象です。
国際的な枠組みにも同じ要求があります。NIST の AI RMF Playbook は MANAGE 2.4 で、意図した用途と異なる結果を示すAIシステムを置き換える、切り離す、停止する仕組みを整えることに加えて、その責任の割り当てと関係者の共通理解までを同格で求めています。停止やバイパスを発動するインシデントの閾値を特定することも、推奨行動の1つです。手段だけを用意しても、誰の責任で発動するかが決まっていなければ動きません。出典: NIST AI RMF Playbook(出典の確認日: 2026年9月8日)
止める操作を、使い始める前に確認する
既製のツールを使う場合、止め方は製品ごとに違います。問題が起きてから探すのでは間に合いません。使い始める前に、次を確認して書き出します。
| 確認すること | 見るところ | 書き出す内容 |
| 自動実行を止める操作 | 設定画面のスケジュール・自動化の項目 | 画面名と、押すボタンの名前 |
| 実行中の処理を中断する操作 | 実行履歴・タスク一覧の画面 | 中断できるか。できない場合はその旨 |
| 連携を切る操作 | 他システムとの接続設定 | 切ると何が止まるか |
| 連携先の認証を切る操作 | 各SaaSの連携アプリ・APIキーの管理画面 | どのキーやアプリを無効にすると、どの処理が止まるか |
| アカウントを止める操作 | 利用者の管理画面 | 最終手段として使える形か |
| 誰の権限で操作できるか | 管理者権限の設定 | その権限を持つ人の名前 |
| 製品 | オフにしたとき、実行中の処理はどうなるか | 実行中を止める操作 | 出典 |
| Power Automate | 保留中のすべての実行が完了するまで継続する | 実行履歴の「すべてのフロー実行をキャンセル」。状態がキャンセル済みへ変わるまで最大24時間 | Microsoft Learn/同(一括キャンセル) |
| Zapier | 実行中のタスクはその場で停止し、履歴に停止理由が残る | オフにする操作がそのまま中断になる | Zapier ヘルプ |
同じ「オフにする」という操作でも、実行中の処理がどうなるかは製品ごとに逆になります。片方は保留中の分が終わるまで走り続け、もう片方はその場で止まる。どちらの型かを、使い始める前に自社の製品で確かめてください。上の確認表の2番目の項目が、ここに直結します。(出典の確認日: 2026年9月8日)
Power Automate には、もう1つ知っておくことがあります。公式ドキュメントは、フローがオフである場合、キャンセルされた保留中のフローは待機中のままになり、それらが再びオンになるまでキューはクリアされない、と明記しています。つまりオフにする操作と、保留分を取り消す操作は別物です。公式手順でも、一括キャンセルの確認画面で「フローをオフにする」を別のチェックボックスとして指定する形になっており、次回以降を止める指定と保留分を取り消す指定は、そこで分かれています。出典: Microsoft Learn(一括キャンセル)(出典の確認日: 2026年9月8日)
2番目は製品によって差が大きい部分です。実行中のものを途中で止められない製品も存在します。その場合、止められるのは「次回以降の実行」だけになります。この違いを知らないまま運用すると、止めたつもりで動き続けます。書き出したものは、印刷して手の届く場所に置きます。問題が起きているときに、その手順書を同じシステムの中から探すことになると、間に合いません。
誰が止めてよいか|「迷ったら止める」を許可する
止める権限を管理者1人に限定すると、その人がいないときに止まりません。止める操作は、元に戻せる操作です。権限を絞る理由は、実はあまりありません。
| 決めること | 推奨 | 理由 |
| 止めてよい人 | 業務に関わる人全員 | 気付いた人がその場で止められる |
| 止める前の相談 | 不要 | 相談している間に処理が進む |
| 止めた後の連絡 | 必須。担当者と経営者へ | 止まっていることを知らない人が困る |
| 再開の判断 | 担当者と経営者 | 止めるのは全員、動かすのは限られた人 |
止めるのは誰でもよく、再開は限られた人が判断する。この非対称が要点です。逆にすると、止まらないか、勝手に再開されるかのどちらかになります。実行前の承認をどう設計するかはAIエージェントの承認フロー、権限そのものの設計はAIエージェントの権限設計で扱っています。
夜間・休日に異常が起きたら
対応する人を用意するのではなく、対応が要らない状態を作る方向で考えます。
| やり方 | 内容 | 向いている処理 |
| 業務時間内だけ動かす | 自動実行の時間帯を、人がいる時間に限定する | 急がない定期処理のほぼすべて |
| 夜間は結果を保留する | 処理はするが、外部への送信や確定は翌朝に人が承認する | 請求・発注・顧客への連絡 |
| 1回あたりの範囲を小さくする | 一度に処理する件数を制限する | 件数の多い処理 |
| 連絡だけ受け取る | 異常時に通知だけ受け、翌朝に対応する | 止めても損害が小さい処理 |
1番目で足りる処理が大半です。夜間に動かす必要が本当にあるかを先に確認します。「夜のうちに終わらせたい」という理由だけなら、業務時間内に移せます。
2番目は、外部に影響が出る処理で有効です。処理そのものは自動で進めつつ、取り返しのつかない部分だけ人の確認を挟みます。
この形は国際的な指針とも一致します。OWASP の LLM06:2025(Excessive Agency)は、影響の大きい操作について実行前に人が承認すること(human-in-the-loop)と、連携先へ与える権限を必要最小限に絞ることを対策に挙げています。夜間は処理だけ進め、外部への送信は翌朝に承認する、という組み方はこれと同じ考え方です。なお OWASP は2026年9月に2026年版の Top 10 for LLM Applications を公表し、Excessive Agency を3番目のリスクに位置づけました。出典: OWASP LLM06:2025 Excessive Agency(出典の確認日: 2026年9月8日)
止めた後、途中まで進んだ処理をどうするか
| 確認する順序 | やること | 確認方法 |
| 1 | どこまで進んだかを確認する | 実行履歴で、最後に成功した処理を見る |
| 2 | 外部へ出たものがあるか確認する | 送信済みメール、外部システムへの登録 |
| 3 | 取り消せるものを取り消す | 下書きに戻す、登録を削除する |
| 4 | 取り消せないものを一覧にする | 送信済みの連絡など。相手への説明が要る |
| 5 | 手作業で完了させるか、やり直すかを決める | 件数と、途中からの再開が可能かで判断する |
2番目を最優先で確認します。社内で完結している処理は後から直せますが、外部へ出たものは取り消せません。相手先への連絡が必要かどうかが、対応の重さを決めます。
止めるときに、もう1つ気をつけることがあります。IPAの中小企業向けの手引きは、初動対応としてシステムやサービスの停止を行うとしたうえで、「ただし、対象機器の電源を切る等、不用意な操作でシステム上に残された記録を消さないようにします」と注意しています。
止めることと、消すことは違います。電源を落とす、アカウントを削除する、履歴を消去するといった操作は、後から原因を調べる手がかりを失わせます。止めるのは処理であって、記録ではありません。
出典: IPA「中小企業のためのセキュリティインシデント対応の手引き」PDF 3ページ(「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録8/出典の確認日: 2026年8月31日)
情報漏えいの可能性がある場合は、この手順ではなく生成AIで事故が起きたときの初動へ移ります。判断そのものが変わってきます。
空振りを責めない

止める仕組みが機能するかどうかは、技術ではなく止めた人がどう扱われるかで決まります。一度でも「大げさだ」と言われた人は、次から止めません。
次を明文化します。1行で足ります。
おかしいと思ったら、確認する前に止めてよい。止めた結果として問題がなかった場合も、判断としては正しかったものとします。止めなかったことによる損害を、止めた人の責任にしません。
止める判断は、情報が不足している状態で行うものです。後から見れば不要だったと分かる場合が必ず出てきます。それを失敗として扱うと、仕組みは働かなくなります。
止めた記録に残すこと
止めた事実を記録しておくと、次に同じことが起きたときに速く動けます。項目は4つで足ります。
| 項目 | 書く内容 |
| いつ、誰が止めたか | 日時と名前 |
| なぜ止めたか | 気付いたきっかけ。「件数が多かった」など短くてよい |
| 途中まで進んでいたもの | 外部へ出たものがあったか、その対応 |
| 再開したか | 再開の日時と、再開してよいと判断した根拠 |
2番目が後から効きます。何をきっかけに気付いたかが分かれば、自動で検知する条件を作れるようになります。止めた記録は、次の閾値設計の材料です。
何が記録として残っているかの確認はAIエージェントのログ管理で扱っています。
製品側に、自動で止まる仕組みが用意されている場合もあります。Zapier は、実行の95%がエラーになり、かつ過去7日間に20回以上実行された Zap を自動でオフにします。猶予と通知はプランで違い、Enterprise は72時間、Team は24時間で、Professional と Free には猶予の記載がありません。ただしこの自動オフが捉えるのは明らかな失敗の連続だけで、件数も時間も正常なまま中身が間違っている状態は素通りします。人が気付いて止める経路の代わりにはなりません。出典: Zapier ヘルプ(出典の確認日: 2026年9月8日)
止めた後に人の手へ戻す作業はAIに任せた業務を、人へ戻すときで扱っています。戻せる状態を保つ方法です。
よくあるご質問
止める権限を全員に開放して問題ありませんか
止める操作は元に戻せます。誤って止めても、再開すれば処理は続けられます。一方、止められずに進んだ処理は取り戻せないことがあります。両者を比べると、開放するほうが安全です。再開の判断だけを担当者と経営者に限定します。止めるのは全員、動かすのは限られた人、という形です。
実行中の処理を止められない製品を使っています
その場合、止められるのは次回以降の実行だけです。前提として、1回あたりの処理範囲を小さくします。件数を制限すれば、止められないまま進む被害の上限が決まります。あわせて、外部への送信や確定を伴う処理は、実行と分けて人が承認する形にできないかを検討します。
止める条件を数値で決めるべきですか
決められる部分は決めます。ただし数値だけには頼らない前提です。件数も時間も正常なのに中身が間違っている、という状態は数値では捉えられません。数値の条件は「明らかな異常を早く止めるため」のもので、人が気付いて止める経路は別に必要です。両方を用意します。
夜間に動かさないと業務が回りません
その場合は、処理と確定を分けます。夜間のうちに処理は進め、外部への送信や取り消せない確定だけを翌朝の承認にします。これなら夜間に人を置く必要はなく、朝の時点で異常に気付けます。それも難しい処理については、1回あたりの範囲を小さくして、被害の上限を決めます。
止めた後、いつ再開してよいですか
原因が分かり、同じことが起きない状態にしてからです。原因が分からないまま再開すると、同じ事象が繰り返されます。すぐに原因が特定できない場合は、範囲を狭めて再開する方法があります。対象の件数を減らす、対象の部署を1つに限る、といった形です。再開の判断と根拠は記録に残します。
止めたのに、しばらく処理が続きます。故障ですか
仕様である場合があります。製品によっては、オフにしても保留中の実行が完了するまで動き続けます。実行中のものを止めるのは別の操作で、実行履歴から取り消す形になっている製品もあります。オフにしただけでは保留分が待機中に残り、再びオンにするまでキューがクリアされない製品もあるため、保留分の取り消しは別に指定してください。取り消しの反映に時間がかかる製品もあり、Power Automate では状態が変わるまで最大24時間かかります。
今日できることは、使っているAIツールの設定画面を開いて、自動実行を止めるボタンがどこにあるかを確かめ、その画面名を紙に書くことです。それが最初の1歩になります。
自社の状況に当てはめる段階で判断がつかない場合は、お問い合わせからご連絡ください。
ここまでの整理を踏まえて、無料診断で現在の段階を確認できます。
無料診断をはじめる