AIエージェントの異常検知・暴走対策｜停止条件とリカバリー設計の実装方法

このまま走らせて大丈夫ですか。誰が止める判断をするんですか

月曜朝のSlackにそう投稿したのは、業務実行AIエージェントの検証環境を見ていた情シスの藤井さん(仮名)でした。前週、請求データ確認用のエージェントが同じAPIを繰り返し呼び出し、運用担当、SRE、経理担当が会議室に集まり、人手でログを追いながら停止する事態になっていました。過去は、AIエージェント 異常検知の基準も、停止条件 AIとしての閾値も曖昧で、「怪しいと思った人が止める」状態だったのです。

現在は、処理回数、失敗率、タイムアウト、外部API呼び出し数を監視し、サーキットブレーカー、自動停止、ロールバック、アラート通知までを事前に設計しています。たとえば検証期間14日間、対象12ワークフローでは、異常時の一次確認手順が平均45分から15分に短縮されました。ただし、この数値は特定の検証環境における観測例であり、すべての企業や業務で同じ結果が得られるわけではありません。

この記事では、AI 暴走対策を「検知して終わり」にせず、停止、リカバリー AI、ポストモーテムまで含めて設計する方法を解説します。目指すのは、想定外の動きが起きても、誰が見ても止め方と戻し方が分かる状態です。ただし、監視ルールを置くだけで十分ではありません。業務影響の整理、権限設計、定期的な見直しとあわせて考える必要があります。

なぜAIエージェントには「止める設計」が必要なのか

業務実行AIエージェントは、単なるチャットAIとは性質が異なります。

チャットAIは、主に人間の質問に対して回答を返します。一方で、業務実行AIエージェントは、外部ツールを呼び出し、社内データを参照し、チケットを更新し、メール文面を作成し、場合によってはワークフローそのものを進めます。

つまり、AIが「回答する」だけでなく、「操作する」段階に入るということです。

このとき問題になるのは、AIが間違うことだけではありません。むしろ、次のような状態が運用上のリスクになります。

• 同じ処理を何度も繰り返す
• 失敗しているのに再試行し続ける
• 外部APIを過剰に呼び出す
• 想定より広いデータ範囲を処理する
• 人間の確認なしに、業務影響の大きい操作を進める
• エラーは出ていないが、業務上は不適切な結果を出し続ける

こうした異常は、単純なシステムエラーとして検知できない場合があります。HTTPステータスは正常で、ログにも致命的なエラーは出ていない。しかし、業務担当者から見ると「明らかにおかしい」というケースです。

そのため、AIエージェント 異常検知では、技術的な死活監視だけでなく、業務上の正常・異常をどう定義するかが重要になります。

「AIの暴走」は派手な事故だけではない

AI 暴走対策という言葉を聞くと、極端な事故や制御不能なシステムを想像するかもしれません。しかし、実際の業務現場で起きやすいリスクは、もっと地味で、日常的です。

たとえば、次のようなケースです。

請求書チェックAIが、同じ請求書を何度も確認対象として扱う。営業支援AIが、同じ顧客レコードに繰り返しメモを追記する。問い合わせ対応AIが、根拠の弱い回答を自信ありげに下書きし続ける。マーケティング施策AIが、想定より広い顧客リストに対してセグメント処理を開始する。

これらは、ひとつひとつを見ると「少し変な挙動」に見えます。しかし、放置すると業務データの汚染、顧客対応ミス、コスト増、監査対応の複雑化につながる可能性があります。

重要なのは、異常を「大事故になってから気づく」のではなく、「小さな違和感の段階で止める」ことです。

そのためには、AIエージェントを導入する時点で、次の3点を設計しておく必要があります。

1. 何を異常とみなすか
2. どの条件で止めるか
3. 止めた後にどう戻すか

この3つがそろって初めて、AI 監視は実運用に耐えるものになります。

AIエージェント 異常検知で見るべき指標

AIエージェントの異常検知では、一般的なシステム監視に加えて、AI特有の行動指標を見る必要があります。

ここでは、業種や部門を問わず、共通して設計しておきたい監視指標を整理します。

実行回数

最初に見るべきなのは、ワークフローの実行回数です。

通常、業務実行AIエージェントには、ある程度の想定実行頻度があります。たとえば、1時間に数回、1日1回、1案件につき1回などです。

この想定を超えて実行されている場合、ループや誤トリガーが起きている可能性があります。

特に注意すべきなのは、短時間で同じ処理が連続しているケースです。処理そのものが成功していても、同一条件で何度も実行されている場合は、業務上の異常として扱うべきです。

失敗率

次に見るべきなのは、失敗率です。

AIエージェントは、外部API、社内システム、データベース、SaaSなど複数のシステムと連携します。そのため、一部の連携先が不安定になると、同じ処理を再試行し続けることがあります。

失敗率が一定以上に上がった場合は、単にエラーを記録するだけでなく、処理全体を止める判断が必要です。

たとえば、直近10分間で同一ワークフローの失敗率が50％を超えた場合、または同一対象に対して3回連続で失敗した場合は、サーキットブレーカーを作動させる、といった設計が考えられます。

ただし、閾値は業務の性質によって変わります。問い合わせ対応、請求処理、CRM更新、レポート生成では、許容できる失敗率や再試行回数が異なります。

処理時間とタイムアウト

AIエージェントは、思考、検索、判断、実行を複数ステップで行うため、処理時間が長くなりがちです。

しかし、処理時間が想定を大きく超えている場合、プロンプトの解釈に迷っている、外部ツールの応答待ちで詰まっている、再試行が続いているといった可能性があります。

そのため、タイムアウトは必ず設計しておくべきです。

ポイントは、「技術的に待てる時間」ではなく、「業務上待ってよい時間」で決めることです。夜間バッチであれば30分待てるかもしれませんが、有人対応中の問い合わせ補助であれば30秒でも長すぎる場合があります。

外部API呼び出し数

業務実行AIエージェントは、外部ツールを呼び出すことで価値を発揮します。しかし、外部APIの呼び出し数が増えすぎると、コスト増、レート制限、連携先への負荷につながります。

特に、AIが「必要な情報を探すために何度も検索する」「同じ確認を複数回行う」といった挙動をすると、API呼び出し数が急増することがあります。

そのため、1実行あたり、1ユーザーあたり、1時間あたりのAPI呼び出し数に上限を設けることが重要です。

処理対象データ件数

AIエージェントが扱うデータ範囲も監視対象です。

たとえば、本来は1顧客の情報だけを処理する想定だったにもかかわらず、100件の顧客情報を読み込んでいる場合、業務上の異常として扱うべきです。

処理対象データ件数は、業務影響に直結します。誤った対象に対して処理が実行されると、後からの修正やロールバックが難しくなるためです。

したがって、AIエージェントには「処理してよい件数の上限」を設定しておく必要があります。

停止条件 AIとして決めるべきルール

異常検知は、検知するだけでは不十分です。検知した後に、AIエージェントを止める条件を決めておく必要があります。

ここでいう停止条件 AIとは、AIエージェントが自律的に動く中で、「これ以上続けてはいけない」と判断するためのルールです。

停止条件は、少なくとも次の5種類に分けて設計します。

回数による停止

もっとも基本的なのは、実行回数や再試行回数による停止です。

たとえば、次のような条件です。

• 同一タスクの再試行は最大3回まで
• 同一ユーザーへの処理は1時間に5回まで
• 同一レコードへの更新は1日1回まで
• 同一ワークフローの連続実行は10回まで

回数による停止は、ループ対策として有効です。AIが自分で判断を続ける設計では、「もう一度試す」が繰り返されることがあります。再試行は便利ですが、上限がない再試行はリスクになります。

時間による停止

次に、時間による停止です。これは、タイムアウトの設計にあたります。

• 1ステップの処理が30秒を超えたら停止
• 1ワークフロー全体が5分を超えたら停止
• 外部APIの応答待ちが10秒を超えたら中断
• 営業時間外の実行は承認待ちにする

時間による停止は、処理の詰まりを早期に発見するために役立ちます。

ただし、すべての業務に同じタイムアウト値を適用するのは避けるべきです。問い合わせ対応、請求処理、データ分析、レポート生成では、許容される処理時間が異なります。

失敗率による停止

失敗率による停止は、システム連携が多いAIエージェントにとって重要です。

たとえば、次のような条件です。

• 直近10回のうち5回以上失敗したら停止
• 同一APIで3回連続エラーが出たら停止
• 認証エラーが1回でも出たら即停止
• データ不整合エラーが発生したら人間確認に切り替える

特に、認証エラーや権限エラーは重く扱うべきです。AIがアクセスできない情報に繰り返しアクセスしようとしている場合、単なる一時的な失敗ではなく、権限設計やプロンプト設計に問題がある可能性があります。

業務影響による停止

AIエージェントの停止条件で見落とされやすいのが、業務影響による停止です。

技術的には正常でも、業務的に危険な状態があります。

• 顧客向け送信前の文章に未確認情報が含まれている
• 金額、契約条件、日付などの重要項目に差分がある
• 処理対象が想定部門を超えている
• 承認者が未設定のまま次工程に進もうとしている
• 重要度の高い顧客データに対する操作が含まれている

このような場合は、AIに判断を続けさせるのではなく、人間の承認に切り替えるべきです。

根拠の有無による停止

AIの出力には、根拠の有無や確からしさに差があります。

特に、社内文書や顧客情報をもとに回答・判断する場合、根拠が見つからないままAIが推測で処理を進めることは避ける必要があります。

そのため、次のような停止条件を設けます。

• 参照元が見つからない場合は停止
• 根拠文書が古い場合は確認待ちにする
• 複数の資料で内容が矛盾する場合は人間にエスカレーションする
• AIが「不確か」と判定した場合は自動実行しない

AIに「分からない」と言わせる設計は、安定運用において重要です。

サーキットブレーカーで被害を広げない

AIエージェントの停止条件を設計するうえで、サーキットブレーカーは重要な考え方です。

サーキットブレーカーとは、異常が一定条件を超えたときに、処理を自動的に遮断する仕組みです。もともとは分散システムで使われる考え方ですが、AIエージェント運用にも応用できます。

たとえば、顧客情報を更新するAIエージェントが、外部CRMへの接続エラーを繰り返しているとします。このとき、何度も再試行させると、CRM側に負荷をかけたり、データ更新が中途半端になったりする可能性があります。

そこで、一定回数以上エラーが続いた場合に、AIエージェントの実行を自動停止し、以降の処理を受け付けない状態にします。

サーキットブレーカーには、主に3つの状態があります。

Closed：通常運転

正常に処理できている状態です。AIエージェントは通常通り実行されます。

Open：遮断中

異常が閾値を超えた状態です。AIエージェントは新しい処理を受け付けず、アラートを出します。

Half-Open：試験的に再開

一定時間後、限定的に処理を再開して問題が解消しているか確認します。成功すれば通常状態に戻し、失敗すれば再び遮断します。

この仕組みを入れることで、異常が発生したときに被害範囲を限定できます。AIエージェントは自律的に動けるからこそ、異常時には自律的に止まれる設計が必要です。

アラートは「鳴らす」より「動ける」ことが重要

AI 監視では、アラート設計も重要です。

ただし、アラートは多ければよいわけではありません。不要な通知が多すぎると、運用担当者は重要な異常を見落としやすくなります。

大切なのは、アラートを受け取った人がすぐに判断できることです。

そのため、通知には次の情報を含めるべきです。

• どのAIエージェントで発生したか
• どのワークフローか
• 実行IDは何か
• どの停止条件に該当したか
• 影響を受ける可能性があるデータや業務は何か
• 現在は停止済みか、実行継続中か
• 次に誰が何を確認すべきか
• ログや管理画面へのリンク

たとえば、Slack通知であれば、次のような形式が考えられます。

【AIエージェント停止通知】

対象：請求データ確認エージェント
ワークフロー：月次請求チェック
実行ID：run_20260512_0018
停止条件：同一APIの連続失敗 3回
現在の状態：自動停止済み
想定影響：請求チェック対象 18件が未完了
確認担当：経理運用担当、SRE
次の対応：ログ確認後、再実行または手動処理を判断してください

このように、アラートは「異常です」と知らせるだけでなく、「次に何をすればよいか」まで含める必要があります。

リカバリー AIは「止めた後」の設計で決まる

AIエージェントの運用では、止めること自体がゴールではありません。

止めた後に、どこまで処理が進んだのか、何を戻す必要があるのか、再実行してよいのかを判断する必要があります。

ここで必要になるのが、リカバリー AIの設計です。

リカバリー設計では、次の4つを整理します。

実行履歴を追えるようにする

まず、AIエージェントが何をしたのかを追える必要があります。

少なくとも、次の情報は記録しておくべきです。

• 実行開始時刻
• 実行終了時刻
• 実行者またはトリガー
• 入力データ
• 参照したデータ
• 呼び出したツール
• 更新したデータ
• 判断理由
• 出力結果
• エラー内容
• 停止条件

これらが残っていないと、異常が起きたときに「どこまで戻せばよいか」が分かりません。

ロールバックできる処理とできない処理を分ける

すべての処理が簡単にロールバックできるわけではありません。

たとえば、社内DBのステータス更新であれば、更新前の値を保存しておくことで戻せる可能性があります。一方で、顧客にメールを送信した、外部システムにデータを連携した、承認フローを進めたといった処理は、単純には戻せません。

そのため、AIエージェントが行う操作は、事前に次の3種類に分類しておくとよいです。

ロールバック困難な処理は、AIに完全自動で任せるのではなく、人間の承認を挟む設計が安全です。

再実行条件を決める

異常停止後に、同じ処理を再実行してよいかどうかも重要です。

再実行条件が曖昧だと、同じ異常を繰り返す可能性があります。

たとえば、次のように決めておきます。

• 外部APIの一時エラーで、データ更新前に停止した場合は再実行可能
• データ更新後に停止した場合は、重複実行を防ぐため手動確認が必要
• 顧客向け通知を含む処理は、再実行前に必ず人間承認を行う
• 同一実行IDでの再実行は禁止し、新しい実行IDを発行する

再実行は便利ですが、二重処理の原因にもなります。特に、請求、契約、顧客連絡、在庫、権限変更などの領域では慎重に設計する必要があります。

復旧手順をテンプレート化する

異常時に毎回ゼロから判断すると、対応が属人化します。

そのため、復旧手順はテンプレート化しておくべきです。

たとえば、次のような項目です。

1. 停止通知を確認する
2. 実行IDをもとにログを開く
3. どの停止条件に該当したか確認する
4. 処理済みデータと未処理データを分ける
5. ロールバック要否を判断する
6. 業務担当者に影響範囲を確認する
7. 再実行、手動処理、中止のいずれかを選ぶ
8. 対応結果を記録する
9. ポストモーテムに反映する

このような復旧テンプレートは、ナレッジベース、運用Runbook、チケット管理ツール、社内Wikiなどに集約できます。Kanataのように、AIチャット、プロンプトライブラリ、学習データライブラリをプロジェクト単位で整理できる環境を使っている場合は、停止判断や復旧手順をチーム内で再利用しやすくなります。

ポストモーテムで停止条件を育てる

AIエージェントの異常は、起きないに越したことはありません。しかし、実運用では小さな異常や想定外の挙動は起こり得ます。

重要なのは、それを次の設計改善につなげることです。

そのために必要なのが、ポストモーテムです。

ポストモーテムとは、障害や異常が起きた後に、原因、影響、対応、再発防止策を整理する振り返りです。AIエージェント運用では、特に次の観点を記録します。

• どのエージェントで起きたか
• どの業務に影響したか
• どの停止条件で検知できたか
• 検知できなかった異常は何か
• 閾値は適切だったか
• タイムアウトは短すぎたか、長すぎたか
• アラートは必要な人に届いたか
• ロールバックは可能だったか
• 再実行判断は迷わなかったか
• 次回までに何を変えるか

ポストモーテムで大切なのは、誰かを責めることではありません。

「なぜ担当者が気づかなかったのか」ではなく、「気づける仕組みになっていたか」を問うべきです。

「なぜ止めなかったのか」ではなく、「止める条件が明文化されていたか」を確認すべきです。

AIエージェントの運用は、一度設計して終わりではありません。実際の異常、現場の判断、復旧時の迷いをもとに、停止条件とリカバリー手順を更新し続ける必要があります。

AIエージェント運用を標準化するための設計観点

AIエージェントの異常検知・停止条件・リカバリー設計は、技術部門だけで完結するものではありません。

業務部門、情シス、SRE、セキュリティ担当、場合によっては経営層も関わります。なぜなら、何を異常とみなすかは、業務の目的やリスク許容度によって変わるからです。

たとえば、同じ「顧客データの更新」でも、営業メモの下書きと契約条件の変更では、求められる停止条件が違います。

そこで重要になるのが、運用ルールを共通の場所に整理することです。

具体的には、次のような設計が必要です。

• 業務ごとにAIエージェントの利用範囲を分ける
• 停止条件や確認手順をRunbookとして管理する
• 障害対応手順や過去のポストモーテムをナレッジとして蓄積する
• 情シス、SRE、業務部門が同じ運用ルールを参照する
• 新しい担当者でも、過去の対応履歴をもとに判断できるようにする

このとき、社内Wiki、チケット管理ツール、監視ツール、ワークフロー管理ツール、生成AI活用基盤など、選択肢は複数あります。

Kanataを利用している場合は、プロジェクト単位でAIチャット、プロンプト、学習データを整理できるため、停止条件や復旧手順を業務ごとのナレッジとして管理しやすい点が特徴です。一方で、既存の監視基盤やインシデント管理ツールを使っている企業では、それらと役割分担を明確にすることが重要です。

AIエージェントの安全運用は、個人の注意力ではなく、組織の仕組みとして整えるべきです。

導入前に決めておきたいチェックリスト

AIエージェントを業務実行に使う前に、最低限確認しておきたい項目を整理します。

異常検知のチェック

• 通常時の実行回数を把握しているか
• 失敗率の閾値を決めているか
• タイムアウトを業務ごとに設定しているか
• 外部API呼び出し数を監視しているか
• 処理対象データ件数の上限を決めているか
• 業務上の異常を定義しているか

停止条件のチェック

• 再試行回数の上限を決めているか
• サーキットブレーカーを設計しているか
• 高リスク操作には人間承認を挟んでいるか
• 権限エラー時に即停止する設計になっているか
• 根拠がない出力で処理を進めない設計になっているか

リカバリーのチェック

• 実行履歴を追跡できるか
• 更新前の状態を保存しているか
• ロールバック可能な処理を分類しているか
• 再実行条件を明文化しているか
• 復旧手順をテンプレート化しているか
• ポストモーテムの記録先が決まっているか

組織運用のチェック

• 異常時の一次対応者が決まっているか
• 業務部門への連絡ルールがあるか
• アラートの優先度が整理されているか
• 定期的に停止条件を見直しているか
• 運用ナレッジをチームで共有しているか

このチェックリストを満たしていない状態で、AIエージェントに重要業務を任せるのは避けた方がよいです。

まずは影響範囲の小さい業務から始め、停止条件とリカバリー手順を検証しながら広げていくことが現実的です。

よくある失敗パターン

最後に、AIエージェントの運用で起こりやすい失敗パターンを整理します。

異常検知をシステムエラーだけで考える

AIエージェントの異常は、エラーコードだけでは分かりません。

システム上は成功していても、業務上は異常というケースがあります。たとえば、対象データが多すぎる、処理対象が違う、根拠が不明確、承認が必要な操作を進めている、といった状態です。

AI 監視では、技術的な正常性と業務的な正常性を分けて考える必要があります。

停止条件を後回しにする

「まず動かしてから考える」という進め方は、検証段階では有効な場合もあります。しかし、業務実行AIエージェントでは、停止条件を後回しにするとリスクが高まります。

特に、外部システム更新、顧客連絡、金額変更、権限変更などを含む場合は、最初から止め方を決めておくべきです。

動く設計と同じくらい、止まる設計が重要です。

リカバリーを人力に頼りきる

異常が起きたときに、毎回ベテラン担当者がログを見て判断する運用では、拡張性がありません。

リカバリー手順は、誰が見ても同じ判断に近づけるようにテンプレート化する必要があります。

もちろん、最終判断を人間が行う場面は残ります。しかし、その前段の情報整理や確認観点は、標準化できます。

アラートが多すぎる

アラートを増やせば安全になるわけではありません。

重要度の低い通知が多すぎると、運用担当者は通知を見なくなります。その結果、本当に重要な異常を見逃す可能性があります。

アラートは、緊急度と業務影響で分類することが重要です。

ポストモーテムが形骸化する

ポストモーテムを書いても、停止条件や運用ルールに反映されなければ意味がありません。

振り返りの目的は、報告書を作ることではなく、次回の異常を早く検知し、早く止め、早く戻すことです。

ポストモーテムは、AIエージェント運用の改善サイクルとして位置づける必要があります。

まとめ：AIエージェントは「安全に止まれる」ことで業務に組み込める

業務実行AIエージェントの価値は、人の代わりに作業を進められることにあります。

しかし、自律的に動けるAIほど、想定外の挙動が起きたときの影響も大きくなります。だからこそ、AIエージェント 異常検知、停止条件 AI、リカバリー AIは、導入後の運用課題ではなく、導入前から設計すべき基盤です。

重要なのは、次の3つです。

1. 何を異常とみなすかを、技術と業務の両面から定義すること
2. どの条件で止めるかを、閾値、タイムアウト、サーキットブレーカーで明文化すること
3. 止めた後にどう戻すかを、ロールバック、再実行条件、ポストモーテムで標準化すること

AIエージェントの安定運用は、「AIを信じる」ことでは実現しません。むしろ、AIが間違える前提で、検知し、止め、戻し、改善する仕組みをつくることで実現します。

最初から完璧な監視設計を目指す必要はありません。まずは影響範囲の小さいワークフローで、実行回数、失敗率、タイムアウト、処理対象件数を監視し、停止条件を試すところから始めるのが現実的です。

AIエージェントは、賢く動くだけでは業務に定着しません。安全に止まり、確実に戻せるからこそ、現場は安心して任せられるようになります。

Q&A