止めるべきだったのか、最後まで走らせるべきだったのか、誰も判断できませんでした
これは、複数のAI導入支援の現場で筆者が見てきた相談内容の一例です。あるBtoB企業では、見込み顧客への一次返信をAIエージェントに任せ始めたものの、想定外の条件分岐によって古い提案資料が添付されそうになりました。Slack上では「いったん止めます」「原因はあとで見ます」という会話が飛び交い、営業企画、情報システム、現場マネジャーのあいだで、誰が最終判断をするのかが曖昧になっていました。
筆者はこれまで、AI活用、業務改革、プロダクト開発の現場で、似たような場面を何度も見てきました。問題は、AIそのものの性能だけではありません。AIが想定外の挙動をしたときに、誰が止め、誰が原因を確認し、誰が再開判断をするのか。その手順が決まっていないことで、技術的には小さな不具合でも、現場全体の判断が止まってしまうことがあります。
この企業ではその後、直近3か月の例外発生ログを対象に、人間介入 AIの基準、フォールバック AIの動作、ロールバック、リカバリー手順、ポストモーテムの流れを整理しました。AIインシデントの記録、対応テンプレート、研修用の事例を社内で共有し、失敗を「誰かのミス」ではなく、改善ループの入口として扱う運用に変えようとしています。
この記事では、AIエージェントの失敗対応に悩む運用担当者やDX推進担当者に向けて、どこで人が介入し、どう原因究明・修正・再発防止につなげるかを整理します。目指すのは、AIが失敗しても現場が慌てず、止める・戻す・調べる・直すを同じ手順で進められる状態です。ただし、手順書を作るだけで万能に防げるわけではありません。ログ設計、教育、定期的な見直しがそろって初めて、自律運用は現実的になります。もし同じ不安があるなら、自社の運用に重ねて読み進めてください。
AIエージェントは止めれば安全、ではない
AIエージェントが想定外の挙動をしたとき、最初に思い浮かぶ対応は「止めること」です。顧客対応、外部送信、契約、金額、個人情報などに関わる処理であれば、一時停止は重要です。
しかし、AIエージェントの失敗対応を「止めるか、止めないか」だけで考えると、運用はすぐに行き詰まります。現場で本当に必要なのは、止めたあとの手順だからです。
たとえば、次のような問いに答えられる状態になっているでしょうか。
- 止めたあとに、誰が影響範囲を確認するのか。
- どのログを見るのか。
- 顧客への連絡は誰が行うのか。
- ロールバックするのか、手動で修正するのか。
- 再発防止策はどこに記録し、誰が研修や運用ルールに反映するのか。
筆者がAI導入の相談を受けるときも、最初は「どのAIツールを使うべきか」「どこまで自動化できるか」という話になりがちです。もちろん、それも大切です。ただ、実際に運用へ入ると、より重要になるのは「AIが失敗したときに、業務をどう守るか」です。華やかな自動化の裏側には、必ず地味な例外対応があります。
AIインシデント対応で重要なのは、失敗をゼロにすると約束することではありません。失敗したときに、被害を広げず、原因を確認し、次の運用に反映できる状態をつくることです。AIリスク管理については、NISTのAI Risk Management Frameworkでも、AIに伴うリスクを組織や社会への影響として継続的に管理する考え方が示されています。
まずは「人間が介入する条件」を決める
AIエージェントの自律運用では、すべての処理に人が入っていては自動化の意味が薄れます。一方で、すべてをAIに任せきると、想定外の挙動が発生したときに影響が広がる可能性があります。
そのため、最初に決めるべきなのは「どの条件になったら人間が介入するか」です。
筆者は、AIエージェントの設計を相談されたとき、まず「どこまで任せるか」よりも「どこから任せないか」を一緒に整理します。自動化の範囲を広げることは魅力的ですが、介入条件が曖昧なまま権限を広げると、あとで現場が苦しくなります。
レベル1：AIが自動でフォールバックする
影響が小さく、外部への送信も伴わない処理であれば、AI自身が代替ルートに切り替える設計が有効です。
たとえば、参照すべき資料が見つからない場合に「回答できません」と返す、信頼度が一定以下の場合に定型文で保留する、対象データが不足している場合に入力項目の追加を促す、といった動きです。
この段階では、人間はすべての処理に介入する必要はありません。ただし、フォールバックが何回発生したかはログに残し、後から確認できるようにします。
重要なのは、AIに「分からないまま進めない」動きを組み込むことです。人間の新人教育でも同じですが、判断できないときに勝手に進める人より、確認できる人のほうが信頼されます。AIエージェントも同じです。
レベル2：担当者確認後に処理を再開する
顧客への返信、社内申請の判定、見積もりの下書きなど、人間の確認を挟めば安全に進められる業務では、AIの処理を一時保留にします。
この場合、AIエージェントは勝手に次の処理へ進まず、担当者に確認依頼を出します。
たとえば、「この顧客にはA資料とB資料のどちらを送るべきか判断できません。確認してください」と通知する形です。人間が承認、修正、差し戻しのいずれかを選ぶことで、処理を再開します。
この設計は、一見すると自動化のスピードを落とすように見えます。しかし、実務では逆に安定性を高めることがあります。確認すべきポイントが明確になっていれば、現場は迷わず判断できます。AIがすべてを進めるよりも、人間が要所だけを見るほうが、結果として運用しやすい場合があります。
レベル3：即時停止・ロールバックが必要なケース
外部送信済みの誤情報、契約条件の誤提示、個人情報の誤参照、権限外データへのアクセスなどは、即時停止の対象です。
このレベルでは、AIエージェント単体の判断に任せるのではなく、あらかじめ決めた責任者へ通知し、処理の停止、影響範囲の確認、ロールバック、関係者への連絡を進めます。
重要なのは、重大インシデントが起きてから体制を決めないことです。誰が止めるのか、誰が事業影響を見るのか、誰が技術的なログを見るのかを、平時に決めておく必要があります。
AIエージェントの運用が不安定になる組織では、「何かあったら誰かが見る」という曖昧な前提が置かれがちです。しかし、本当に何かが起きたとき、その「誰か」はなかなか現れません。だからこそ、介入者を人名または役割名で定義しておくことが必要です。
| 介入レベル | 主な条件 | 対応方針 |
|---|---|---|
| レベル1 | 影響が小さく、外部送信を伴わない処理 | AIが自動でフォールバックし、ログを残す |
| レベル2 | 人間の確認を挟めば安全に進められる処理 | 担当者確認後に承認、修正、差し戻しを行う |
| レベル3 | 外部送信、契約、個人情報、権限外アクセスなど重大な影響がある処理 | 即時停止、影響範囲確認、ロールバック、関係者連絡を行う |
AI 例外対応は「検知、停止、代替、復旧、記録」で考える
AIエージェントの失敗対応は、個別のトラブルごとに考えると複雑になります。そこで、共通の型として「検知、停止、代替、復旧、記録」の5段階で整理します。
この5段階は、特定の業界だけに限った話ではありません。営業支援、問い合わせ対応、社内ヘルプデスク、マーケティング配信、社内申請処理など、多くのAIエージェント運用で共通して使える考え方です。
検知：異常をどう見つけるか
まず、何をもって異常と判断するかを決めます。
エラーが出た場合だけが異常ではありません。AIエージェントの場合、処理自体は完了していても、中身が業務上不適切な場合があります。
たとえば、古い資料を参照している、信頼度が低いまま回答している、想定外の顧客セグメントに配信している、通常より長い処理時間がかかっている、といったケースです。
検知条件を設けないまま運用すると、現場からの指摘や顧客からの問い合わせで初めて問題に気づくことになります。AIインシデントを継続的に観測し、パターンを把握する考え方は、OECDのAI Incidents and Hazards Monitorでも示されています。
筆者は、AIエージェント導入の初期段階では、検知条件を細かく作り込みすぎるよりも、まず「人が見たら違和感を持つポイント」を現場から集めることを勧めています。現場の違和感は、ログ設計の出発点になります。
停止：どこで止めるか
次に、AIエージェントをどこで止めるかを決めます。
すべての処理を一括停止するのか、特定のワークフローだけ止めるのか、外部送信だけ止めるのか。停止範囲を決めておかないと、過剰に止めて業務全体が止まるか、逆に止める範囲が狭すぎて影響が広がる可能性があります。
たとえば、営業メール作成AIであれば「下書き作成は継続するが、自動送信は停止する」という切り分けが考えられます。問い合わせ対応AIであれば「社内向け回答は継続するが、顧客への自動返信は保留する」という設計もあります。
停止とは、必ずしも全部を止めることではありません。業務を守るために、止める範囲を調整することです。
代替：フォールバック AIまたは人手処理へ切り替える
AIエージェントを止めると、業務が止まります。そのため、停止と同時に代替手段を用意しておく必要があります。
代表的なのが、フォールバック AIと人手処理です。
フォールバック AIとは、通常の自律エージェントよりも権限や動作範囲を絞った代替AIです。たとえば、外部送信はせず、回答候補だけを提示する。新しい判断はせず、定型FAQの範囲でのみ返す。一定以上の確信がない場合は「担当者確認」とする。こうした制限をかけます。
一方で、契約、法務、重大な顧客対応などは、人手処理に戻すべきです。自動化を守ることより、影響を最小化することを優先します。
AI活用の現場では、「せっかく自動化したのに手動に戻すのは負けではないか」と感じることがあります。しかし、筆者はそう考えていません。手動に戻せる設計があるからこそ、安心して自動化に踏み込めるのです。
復旧：ロールバックとリカバリー手順を実行する
失敗が外部に影響している場合は、復旧が必要です。
復旧には、技術的なロールバックと、業務上のリカバリーがあります。
技術的なロールバックとは、設定、プロンプト、参照データ、連携先などを、問題発生前の状態に戻すことです。業務上のリカバリーとは、誤って送った資料の訂正、顧客への説明、社内関係者への共有、CRMや管理台帳の修正などです。
AIエージェントの失敗では、この2つが混同されがちです。システムを戻しただけでは、顧客への影響は残ります。逆に、顧客に謝罪しただけでは、同じ誤動作が再発します。
ここで必要なのは、技術と業務を分けて見ることです。エンジニアリングの視点だけでも足りず、現場対応の視点だけでも足りません。両方をつなぐ運用設計が必要です。
記録：次の改善に使える形で残す
最後に、対応内容を記録します。
記録すべき項目は、発生日時、検知方法、影響範囲、実行された処理、使用されたプロンプトや参照データ、人間が介入したタイミング、暫定対応、恒久対応、再発防止策です。
ここで大切なのは、単なる報告書にしないことです。次の研修、ルール改定、プロンプト修正、権限設計の見直しに使える形で残す必要があります。
社内でAI活用基盤を整える場合、AIインシデントの対応テンプレート、振り返りメモ、研修用のケーススタディをプロジェクト単位で整理し、関係者が同じ情報を見ながら改善できる状態をつくることが有効です。たとえば弊社が提供するKanataのように、AIチャット、要約、学習コンテンツ、プロジェクト単位のライブラリを同じ環境で扱えるサービスは、失敗対応をチャット上の一過性のやり取りで終わらせず、組織のナレッジとして蓄積する用途に向いています。
| 段階 | 確認すること | 主な対応 |
|---|---|---|
| 検知 | 何を異常と判断するか | エラー、古い資料参照、低信頼度、想定外セグメント配信などを把握する |
| 停止 | どの範囲を止めるか | 全停止、ワークフロー停止、外部送信停止などを切り分ける |
| 代替 | どの処理へ切り替えるか | フォールバック AIまたは人手処理へ切り替える |
| 復旧 | 何を元に戻すか | 設定やデータのロールバック、顧客説明、管理台帳修正を行う |
| 記録 | 何を残すか | 発生事象、影響範囲、暫定対応、恒久対応、再発防止策を記録する |
原因究明では「ログ解析」と「再現テスト」を分ける
AIエージェントが失敗したとき、現場ではよく「なぜそうなったのか」と問われます。
しかし、AIの挙動は複数の要素が重なって起こります。プロンプト、参照データ、権限、外部連携、入力内容、モデルの出力傾向、業務ルールの曖昧さなどが絡み合います。
そのため、原因究明では「ログ解析」と「再現テスト」を分けて考えることが重要です。
筆者は、原因究明の場に入るとき、まず「犯人探しではなく、分岐点探しをしましょう」と伝えることがあります。AIエージェントの失敗は、誰か一人のミスで説明できないことが多いからです。むしろ、どの分岐で、どの情報をもとに、なぜその処理へ進んだのかを見ていく必要があります。
ログ解析で見るべきもの
ログ解析では、AIエージェントがどのような情報を受け取り、どのような判断をし、どの処理を実行したかを確認します。
具体的には、以下を確認します。
- 入力された指示やデータ
- 参照したドキュメントやナレッジ
- 使用されたプロンプト
- 実行されたツールや外部連携
- 判断分岐の結果
- 出力内容
- 人間の承認や修正の有無
- エラーや警告の有無
ログが残っていない場合、原因究明は推測になります。推測だけで修正すると、別の箇所で同じ問題が再発する可能性があります。
AIエージェントを業務に組み込むなら、「後から説明できる最低限のログ」を残すことは、導入時点からの前提にすべきです。これは監視のためだけではなく、現場を守るためでもあります。
再現テストで確認すること
再現テストでは、同じ条件を与えたときに同じ失敗が起こるかを確認します。
たとえば、同じ入力、同じ参照データ、同じプロンプト、同じ権限設定で再実行し、問題が再現するかを見ます。
再現すれば、設定やルールに原因がある可能性が高まります。再現しなければ、外部データの更新、タイミング、文脈、モデル出力のばらつきなどを疑います。
AIエージェントの再現テストでは、完全に同じ出力が返るとは限りません。そのため、文字列の一致だけでなく、同じ業務上の誤判断が起こるかを見ることが大切です。
AI運用では、複数の小さな条件が重なってインシデントになります。だからこそ、ログ解析と再現テストを分け、感覚ではなく手順で原因を絞る必要があります。
責任所在は「AI」ではなく「運用設計」に置く
AIエージェントが失敗したとき、「AIが勝手にやった」と表現されることがあります。
しかし、業務上の責任をAIに置くことはできません。AIにどの権限を与え、どのデータを参照させ、どこまで自動実行させるかを決めたのは人間の組織です。
そのため、責任所在は個人の感覚ではなく、運用設計として明確にしておく必要があります。
たとえば、以下のように役割を分けます。
- 業務責任者
- AIエージェントに任せる業務範囲を決める
- DX推進担当
- 運用ルール、研修、改善サイクルを設計する
- 情報システム・IT責任者
- 権限、ログ、連携、停止手段を管理する
- 現場マネジャー
- 日々の例外対応と人間介入の判断を担う
- 実務担当者
- AI出力の確認、修正、報告を行う
この分担がないと、トラブル発生時に「誰が判断するのか」が曖昧になります。そして、曖昧なまま急いで対応すると、再発防止ではなく責任回避の会話になりがちです。
AIエージェント運用では、誰か一人の注意力に頼るのではなく、役割として介入ポイントを設計することが重要です。
筆者は、AI導入を「ツール選定」だけで終わらせることに強い違和感を持っています。AIは導入した瞬間ではなく、現場で使われ、例外が起き、それでも改善され続けることで初めて価値になります。そのためには、責任の所在を曖昧にしないことが不可欠です。
ポストモーテムで失敗を改善ループに変える
AIインシデント対応で最も重要なのは、終わったあとです。
一時停止し、顧客対応を行い、設定を戻すところまでは、多くの企業が実施します。しかし、再発防止まで進めるには、振り返りの型が必要です。
ここで必要になるのが、ポストモーテムです。ポストモーテムとは、発生した問題について、事実、原因、対応、再発防止策を整理する振り返りです。ポイントは、特定の担当者を責めるためではなく、仕組みを改善するために行うことです。
AIエージェントのポストモーテムでは、次の項目を整理します。
- 何が起きたのか
- いつ、どこで検知されたのか
- どの業務、顧客、データに影響したのか
- AIエージェントはどの入力をもとに、どの処理を実行したのか
- 人間はどのタイミングで介入したのか
- 介入は早すぎたのか、遅すぎたのか
- フォールバックは機能したのか
- ロールバックやリカバリー手順は十分だったのか
- 次回から何を変えるのか
この振り返りを研修コンテンツやナレッジとして保存しておけば、新しい担当者の教育にも使えます。AIチャット、要約、eラーニング、プロジェクト単位のライブラリを組み合わせられる環境であれば、インシデントの記録を単なる議事録ではなく、次の研修素材や運用改善の材料として再利用できます。
単なる失敗事例ではなく、「次に同じことが起きたときの教材」に変えられることが大切です。
筆者は、よいAI運用とは、失敗が起きない運用ではなく、失敗から学ぶ速度が上がっていく運用だと考えています。現場が萎縮せず、事実を出し、次の改善につなげる。その文化があって初めて、AIエージェントは組織の中で育っていきます。
AIエージェント活用研修では「使い方」だけでなく「止め方」を教える
多くの生成AI研修では、プロンプトの書き方、業務活用のアイデア、効率化の方法が中心になります。
もちろん、それらは重要です。しかし、AIエージェントが自律的に動く段階では、「どう使うか」だけでは不十分です。
現場には、次のスキルが必要になります。
- AIエージェントの出力を鵜呑みにしない判断力
- 異常な挙動に気づく観察力
- 人間介入の基準を理解する力
- ログを読み、原因を切り分ける力
- 例外対応を記録し、改善につなげる力
- AIに任せる業務と、人が判断すべき業務を分ける力
つまり、AIを使う研修から、AIを監督する研修へ進む必要があります。
特に現場マネジャーや運用担当者には、AIエージェントが失敗した場面を想定したロールプレイが有効です。
たとえば、「顧客へ誤った資料が送信されそうになった」「AIが古い規程を参照して回答した」「営業リストの対象条件を誤って抽出した」といったケースを用意し、どこで止めるか、誰に報告するか、どのログを見るかを練習します。
この訓練がないまま本番でAIインシデントが起こると、現場はどうしても場当たり対応になります。
筆者自身、プロダクト開発や業務システムの支援をしてきた中で、優れた仕組みほど「例外時の動き」が丁寧に設計されていると感じてきました。通常時に動くことは、ある意味では当然です。差が出るのは、想定外が起きたときです。
失敗対応は「共有できる運用知」に変える
AIエージェントの失敗対応は、個人の経験だけに閉じると再現性が生まれません。ある担当者はうまく対応できても、別の担当者が同じように対応できなければ、組織としては不安定なままです。
そのため、AIエージェントの失敗対応は「共有できる運用知」に変える必要があります。
たとえば、AIインシデントが起きたら、まず会議メモやチャット上のやり取りを整理します。次に、発生事象、影響範囲、暫定対応、恒久対応、未解決論点を構造化します。そのうえで、確定した対応手順や再発防止策をナレッジとして保存し、次回以降の参照情報として使います。
重要な事例は、研修コンテンツに変えることもできます。単に「こういう失敗がありました」と共有するだけではなく、「このケースでは、どの時点で人間が介入すべきだったか」「ログのどこを見るべきだったか」「どのフォールバックが適切だったか」を学べる形にします。
このような運用には、既存のナレッジ管理ツール、LMS、社内Wiki、チケット管理ツールなど、さまざまな選択肢があります。その中でKanataは、AIチャット、要約、学習コンテンツ、プロジェクト単位のライブラリをひとつの業務支援プラットフォーム上で扱えるため、AIインシデントの記録から研修化までを同じ導線で進めたい組織に向いています。
AIエージェント運用の成熟度は、ツールをどれだけ多く使っているかではなく、失敗からどれだけ速く学べるかに表れます。失敗対応を共有できる運用知に変えることが、継続的な改善の土台になります。
まとめ：失敗しないAIではなく、失敗から戻れるAI運用を目指す
AIエージェントの自律運用では、失敗を完全にゼロにすることは現実的ではありません。
業務ルールが変わることもあります。参照データが古くなることもあります。顧客対応の文脈が複雑なこともあります。人間側の指示が曖昧なこともあります。
だからこそ、目指すべきは「絶対に失敗しないAI」ではありません。目指すべきは、失敗しても早く気づき、影響を抑え、原因を調べ、修正し、次の運用に反映できるAI運用です。
そのためには、次の5つを共通パートとして整える必要があります。
- 人間が介入する条件を決める
- フォールバック AIと人手処理の切り替えを設計する
- ログ解析と再現テストができる状態にする
- ロールバックとリカバリー手順を明文化する
- ポストモーテムを研修・ルール・ナレッジに反映する
AIエージェントが業務に入り込むほど、失敗対応は技術部門だけの問題ではなくなります。経営判断、情報管理、顧客接点、現場教育がつながるテーマになります。
その意味で、人間介入 AIの設計は、自律運用のブレーキではありません。むしろ、安心してAIエージェントに業務を任せるための土台です。
筆者は、AI導入の支援をするとき、最後にはいつも「現場で使われ続ける形になっているか」を見ます。PoCではうまく動いた。デモではきれいに見えた。けれど、失敗時の対応が決まっていなければ、現場では定着しません。
AIエージェントは、企業の業務を大きく変える可能性があります。ただし、その可能性を現実に変えるには、成功パターンだけでなく、失敗したときの戻り方まで設計する必要があります。そこまで含めて、AIエージェントの運用設計です。
Q&A
AIエージェントが失敗したとき、最初にやるべきことは何ですか？
最初に行うべきことは、影響範囲の拡大を止めることです。ただし、すべてを一括停止するとは限りません。外部送信だけを止める、特定のワークフローだけを止める、担当者確認に切り替えるなど、業務影響に応じて停止範囲を決めます。
人間介入の基準はどのように決めればよいですか？
影響範囲、外部送信の有無、金額・契約への影響、個人情報や機密情報の扱い、顧客体験への影響を基準にします。小さな不確実性はフォールバックで対応し、顧客や契約に関わる処理は担当者確認または即時停止の対象にします。
フォールバック AIとは何ですか？
フォールバック AIとは、通常のAIエージェントが安全に処理を続けられない場合に使う、権限や動作範囲を制限した代替処理です。たとえば、外部送信はせず回答候補だけを提示する、定型FAQの範囲でのみ回答する、判断に迷う場合は担当者確認に回す、といった動きが該当します。
AIインシデントの原因究明では何を見ればよいですか？
入力内容、参照データ、使用されたプロンプト、判断分岐、出力内容、外部連携、承認履歴、エラーや警告ログを確認します。そのうえで、同じ条件を再現し、同じ業務上の誤判断が起こるかをテストします。ログ解析と再現テストを分けることが重要です。
AIエージェントの失敗を再発防止につなげるには何が必要ですか？
ポストモーテムを行い、発生事象、影響範囲、原因仮説、暫定対応、恒久対応、再発防止策を整理します。その内容を研修、運用ルール、プロンプト修正、権限設計、ナレッジ管理に反映することで、単なる失敗対応ではなく改善ループに変えられます。
