AIチャットボット障害対応の手順｜停止・通知・復旧の実務プレイブック

営業時間を尋ねた利用者へ古い時刻を案内している。会話画面は開くのに、有人対応の通知だけが届かない。管理画面へ入れず、回答を止めたいのに操作できない。AIチャットボットの障害は、画面が完全に停止したときだけ起きるものではありません。

運用責任者が迷いやすいのは、原因を特定する前に決めるべきことが多いためです。回答だけを止めるのか、外部連携を無効にするのか、チャット全体を非公開にするのか。社内、提供者、利用者へ、どの時点で何を知らせるのか。修正後は、誰が何を確認して再開を承認するのか。発生してから連絡先や合格条件を考えると、影響範囲の確認も復旧作業も滞ります。

AIチャットボットの障害対応手順は、重大度、停止範囲、証跡、通知、復旧条件、承認者を平常時に一枚へまとめることが要点です。異常時は原因を急いで断定せず、まず影響拡大を止め、確認できた事実を残します。その後、原因を切り分け、回帰テストを通し、段階的に再開します。

本稿は、契約条件や稼働率を決める記事ではありません。提供者との責任分界やサポート条件を見直す場合は、チャットボットSLAの確認項目を先に整理してください。ここでは、すでに公開中のチャットボットで問題を検知した運用責任者が、発生直後から振り返りまで対応するための手順に絞ります。

AIチャットボットの障害対応は利用不能だけを対象にしない

最初に、社内で「障害」と呼ぶ範囲をそろえます。技術的に応答できない状態だけを対象にすると、画面は動いていても利用者に大きな影響を与える誤回答や、通知の欠落が手順から漏れます。名称はインシデント、品質問題、緊急対応でも構いません。重要なのは、通常運用から外れ、急いで影響を抑える必要がある状態を見落とさないことです。

たとえば営業時間の誤案内は、チャット画面の稼働監視だけでは見つからない場合があります。それでも、来店や問い合わせの機会を損なうおそれがあるため、品質インシデントとして止める判断が必要です。反対に、軽微な表記ゆれまで毎回全停止すると、必要な案内まで失われます。対象を広く定義したうえで、次の重大度判定により対応の強さを変えます。

情報漏えい、個人情報、契約上の責任に関する評価は、運用担当者だけで確定しません。疑いを検知した段階で、社内の情報管理、セキュリティ、法務など所定の担当へ連携し、必要に応じて専門家へ確認します。本稿は法的な報告義務や事故対応を判断するものではなく、初動の抜けを減らすための運用整理です。

手順1：重大度と停止範囲を決める

重大度は、エラー文の種類や問い合わせ件数だけでは決められません。利用者への影響、扱う情報、業務停止の有無、代替手段、影響が広がる可能性を順に確認します。最初の報告時点では情報がそろわないため、仮の重大度を置き、新しい事実が分かるたびに見直します。

社内の重大度は三段階程度から始めると運用しやすくなります。「高」は、情報の取り扱いに問題がある疑い、重要手続の誤案内、外部操作の誤実行、広範囲の利用不能など、直ちに影響を抑える状態です。「中」は、一部の質問や経路に限定され、代替案内を用意できる状態です。「低」は、意味を変えない表記崩れなど、通常の変更手順で対応できる状態です。ただし、この分類名や条件は自社業務に合わせて決めてください。

停止は「全部を止める／何も止めない」の二択ではありません。問題のある回答だけを対象外にする、該当ナレッジを検索対象から外す、予約などの外部操作を止める、有人窓口へ案内を切り替える、チャット表示を一時停止するという段階があります。管理画面や契約上、どの操作が可能かは事前に確認し、操作できない場合の連絡先も記録します。

「15分」は普遍的な復旧目標ではなく、初動表に何を置くかを示すための整理です。自社が何分以内に確認を始めるか、何時間以内に代替案を用意するかは、業務影響、当番体制、提供者との契約を基に決めます。公共調達の仕様書に具体時間が書かれている例もありますが、それは発注者が個別案件へ置いた要件です。自社の標準としてそのまま流用しないでください。

手順2：証跡を保全し関係者へ通知する

停止操作を急ぐほど、操作前の状態が分からなくなることがあります。個人情報や機密情報を不要に複製しない範囲で、発見時刻、発見者、ページ、入力、出力、参照した可能性がある情報、画面、エラー、直前の変更を記録します。ログの保存期間や閲覧権限に制限がある場合は、所定の担当者へ保全を依頼します。

利用者が入力した本文を、誰でも見られるチャットや表計算へそのまま貼り付けないようにします。調査用の記録には管理番号を付け、共有範囲を限定します。個人情報を含む可能性がある部分は、原因確認に必要かを判断して扱います。ログを取得できること、取得してよいこと、どこへ保存するかは、それぞれ別に判断する必要があります。

通知は、社内初報、提供者への連絡、利用者への案内を分けます。社内初報には、発生または発見時刻、確認できた事象、仮の影響範囲、実施済みの停止、次回更新時刻を入れます。提供者へは、再現手順、対象環境、エラー、直前変更、緊急度、希望する支援を添えます。利用者向けには、利用できない範囲、代替窓口、次の更新予定を案内し、原因や復旧時刻を確認前に断定しません。

この例で大切なのは、分からないことを埋めないことです。「影響はない」「情報流出なし」「何時に完全復旧」といった表現は、確認できた根拠がある場合だけ使います。途中経過では、前回の連絡後に確認できた事実、継続中の対応、次回更新時刻を記載します。復旧連絡では、再開した範囲、残る制限、利用者に必要な操作、問い合わせ先を示します。

手順3：原因を切り分け修正する

「AIの精度が悪い」とまとめると、修正箇所を特定できません。表示、回答生成、参照資料、権限、有人通知、外部連携に分け、どこまで正常かを確認します。直前の変更だけに原因を決めつけず、同じ質問を変更前後の版や別経路で比較します。

重大な誤回答では、質問と最終回答だけでなく、根拠として使うべき正本を確認します。正本が古いなら資料の更新、正本は正しいのに参照されないなら検索対象や構造、根拠がないのに断定するなら回答ルールが修正候補です。ナレッジ設計の平常時改善は、AIの回答精度を上げる方法で詳しく整理しています。

修正は、小さく戻せる単位で行います。複数の設定、資料、連携を同時に変えると、何が効いたか分からなくなり、別の回答への影響も追いにくくなります。変更内容、理由、実行者、承認者、変更前後の版、戻す手順を変更台帳へ記録してください。

情報の取り扱いや不正アクセスの疑いがある場合は、通常の回答改善だけで終えません。社内の事故対応手順へ切り替え、証跡の扱い、調査範囲、連絡、法的な判断を所定の担当へ渡します。運用担当者が原因や影響を独自に断定せず、チャットボット側で確認した事実と未確認事項を整理して引き継ぎます。

手順4：回帰テストと再開承認を行う

修正した質問へ一度正しく答えたことだけでは、復旧と判断できません。変更が別の質問、権限、通知、外部連携へ影響していないかを確認する回帰テストが必要です。AIの回答には揺れがあるため、重要な質問は表現を変え、複数回確認します。

1. 正常系：主要な質問へ、現行の正本を根拠に回答できる。
2. 境界系：情報不足、曖昧、対象外、古い情報に対して、断定せず確認または保留できる。
3. 安全系：個人情報、権限外情報、不適切な指示を回答や操作へ使わない。
4. 引継ぎ系：人の判断が必要な相談で、利用者への案内と担当者への通知が両方届く。
5. 連携系：失敗、遅延、二重送信を想定し、安全に止まり、実行結果を確認できる。
6. 運用系：ログ、監視、停止、代替導線、復旧連絡が実際に機能する。

公開前や変更時に安全系の境界を整える場合は、AIチャットボットのガードレール設計を参照してください。障害対応で見つかった再現質問は、その場限りの確認で終えず、今後の回帰テストへ追加します。

再開条件は「担当者が直ったと思う」ではなく、事前に決めた確認項目と承認者で判定します。技術担当は修正とシステム動作、業務担当は回答内容と代替導線、情報管理担当は必要な安全確認を担当します。重大な問題では、修正した人と再開を承認する人を分けると、見落としを減らせます。

一度に全面再開せず、対象ページ、回答カテゴリ、利用者を限定して戻す方法もあります。限定再開が可能かは製品・設定・契約によって異なります。Socratesを含む個別製品で利用できる停止や公開範囲は、管理画面と公式仕様で確認してください。

手順5：ポストモーテムを運用変更へつなげる

復旧後の振り返りは、担当者を責めるためではありません。同じ条件が起きたときに、より早く検知し、安全に停止し、影響を抑えて復旧できるようにする作業です。事実の時系列と、その時点で得られた情報に基づく判断を分けて記録します。結果を知った後で「なぜ分からなかったのか」と評価するだけでは、次の改善点が曖昧になります。

改善項目には、担当者と期限を付けます。「監視を強化する」「教育する」だけでは完了を確認できません。「旧料金表を検索対象から外す条件を10月14日までに文書化する」「重大な誤回答のテスト質問を5件追加し、次回変更時から実行する」のように、変更する対象と合格条件を記載します。

障害件数がゼロであることだけを目標にすると、報告をためらう運用になりかねません。検知から初報まで、停止判断まで、代替導線の準備、再発テストの追加など、対応能力を確認できる項目も見ます。ただし、目標値は自社の勤務体制と業務影響から決め、他社の数値をそのまま借りないでください。

平常時に作る障害対応プレイブック

プレイブックは長い規程ではなく、異常時に開けば次の行動が分かる一枚から始めます。詳細なセキュリティ事故手順、契約、製品マニュアルは別文書へリンクし、連絡先と版を定期的に確認します。主担当が不在でも、代行者が重大度の確認と停止の連絡を始められる状態にします。

作成後は、机上訓練を行います。「金曜の営業時間後に会話画面が開かない」「旧料金を案内している」「有人通知だけが届かない」など一つの場面を選び、連絡が担当者へ届くか、停止権限を持つ人がいるか、代替窓口が利用できるかを確認します。実際の顧客情報や本番操作を不用意に使わず、安全なテスト条件で進めます。

AIを止めた後に利用者を放置しないため、AIから有人対応へ切り替える設計も合わせて確認してください。受付時間外なら、すぐ返事が来るように見せず、受付済みであることと確認予定を案内します。有人対応の目標時間は、業務の優先度と勤務体制に基づいて決めます。

参考にした公開情報の読み方

AIチャットボットの運用方法では、重大な問題時の停止、ログ保全、変更台帳、回帰テスト、再開承認を運用項目として確認できます。リコーのチャットボット運用課題は、情報の陳腐化や属人化、複数部門での運用体制を整理しています。どちらも自社の製品仕様や契約を置き換えるものではありません。

長野県の公開仕様書には、情報漏えい事故対応手順、障害時の停止最小化、障害内容・対応方法・復旧見込みの連絡に関する要求例があります。公共仕様書は、発注者が個別案件で求めた条件です。法令上の一般義務、業界標準、Socratesの保証内容として引用しないようにします。

障害対応チェックリスト

• 利用不能だけでなく、重大な誤回答、情報の取り扱い、通知・外部連携の失敗を対象にした
• 利用者影響、情報、業務、代替手段、拡大可能性で重大度を仮判定した
• 回答、資料、外部操作、表示のどこまで止めるかを決めた
• 発見時刻、入力、出力、画面、変更履歴、判断理由を安全な場所へ保全した
• 確認済みの事実、未確認事項、次回更新時刻を分けて通知した
• 表示、回答ルール、ナレッジ、権限、通知、外部連携を分けて原因を確認した
• 修正内容、変更前後の版、戻す方法を変更台帳へ記録した
• 正常系、境界系、安全系、引継ぎ系、連携系、運用系を再テストした
• 再開範囲、残る制限、承認者、重点監視の終了条件を記録した
• 振り返りで検知、初動、原因、復旧、連絡を見直し、担当と期限を決めた

AIチャットボットの障害対応は、最初から原因を言い当てることが目的ではありません。影響を広げない停止、確認できた事実の保全、利用者を放置しない代替導線、合格条件に基づく再開を、同じ順番で実行できる状態を作ることが目的です。まずは自社で影響の大きい質問を一つ選び、回答を止める人、代替窓口を案内する人、再開を承認する人を書き出してください。

よくある質問