AIシステムが止まったら。誤回答と連携障害を切り分ける運用手順書

AIシステムの運用手順書では、切り分けの順序を最初に固定します。同一リクエストの記録をたどり、取得した情報が悪いなら検索、情報は妥当なのに回答が悪いなら生成、回答までは妥当なのに外部処理が失敗したなら後続APIへ振り分けます。

復旧も、再起動や再実行が成功しただけでは完了にしません。原因となったレイヤーを再検証し、影響、対応、変更、テスト、デプロイ、バージョンを記録したうえで、自社が事前に定めた受入条件を満たしたときに通常経路へ戻します。難しいのは「何をもって妥当とするか」なので、判断表と記録欄を一体にして決めます。

AIシステムの運用手順書は処理経路から組み立てる

利用者から見える「答えがおかしい」「処理が終わらない」という症状だけでは、担当先を決められません。検索拡張生成を含む処理では、検索が誤った資料を渡したのか、正しい資料から生成が誤ったのか、生成後の登録や通知で止まったのかによって、確認対象も安全な退避方法も変わります。

だから、問い合わせ文、取得コンテキスト、生成結果、後続APIの要求と応答を、同じリクエストとして照合できることが初動の前提です。Google Cloudの公式資料は、生成AIアプリケーション全体と各コンポーネントの入出力をエンドツーエンドで記録・監視し、事実誤認があった際には、実行コンポーネントの系譜と依存した成果物・パラメータを対応付けて分析できるようにする必要があるとしています（Deploy and operate generative AI applications、2024年11月19日更新、2026年9月21日確認）。

記録がレイヤーごとに別の識別子で保存され、相互にたどれないなら、運用手順書より先に観測設計を直す必要があります。「生成が怪しい」という印象からモデル設定を変えると、検索の欠落やAPIの失敗を残したまま、新しい変更要因まで加えてしまうからです。

一次切り分けの判断表

次の表は、公式資料が定める障害分類ではありません。エンドツーエンドの記録、RAGの観測項目、アプリケーション監視という出典の一般原則を基に、実装担当者が一次対応で使えるように整理した実務上の提案です。

この表の要点は、一つの症状を一つの担当へ直結させないことです。取得結果が妥当かを先に見れば、検索を直すべき事象と生成を直すべき事象が分かれます。生成結果まで妥当かを続けて見れば、後続APIだけを隔離する判断ができます。証跡が足りない状態も「判定保留」として扱えば、推測による変更を復旧作業に混ぜずに済みます。

Google Cloudは、RAGでは取得コンテキストの関連性と回答のグラウンデッドネス、つまり出典への帰属を調べ、ベクトルデータベースのクエリ処理量も監視するよう推奨しています。また、AI・MLアプリケーションではレイテンシ、トラフィック、エラー率、飽和度を監視対象とし、詳細ログは解析の文脈を、分散トレースはコンポーネント間の経路と遅延箇所を示すとしています（AI and ML perspective: Reliability、2025年8月7日更新、2026年9月21日確認）。判断表の各欄は、これらの観測結果へ直接たどれる名称にしておく必要があります。

検索・生成・後続APIごとの確認と復旧

検索に切り分けた場合

検索系では、まず取得コンテキストを人が読み、問い合わせや処理対象との関連性を確認します。次に、生成結果で使われた記述がどの参照元に帰属するかを追います。「誤回答」と判定する前に、その回答を作る直前に何が渡されたかを固定するのが出発点です。

復旧作業には、検索入力、取得結果、参照元、変更した検索条件や対象データ、再検証結果を残します。再取得で期待する資料が見えたとしても、それだけで通常経路へは戻しません。そのコンテキストを使った生成結果まで確認し、検索の変更が後段へどう届いたかを同じ経路で追います。

生成に切り分けた場合

生成系へ進む条件は、取得コンテキストが妥当であることです。そのうえで、モデルに渡った入力、返った出力、実行されたコンポーネント、依存した成果物・パラメータを照合します。運用時には、現在の設定値と、そのリクエストが実際に何へ依存していたかという系譜の両方が必要です。

プロンプトや依存設定を変更したなら、変更前後の理由と対象を残し、同じ確認入力で出力条件を再検証します。合格条件には、文章の自然さに加えて、取得情報に基づいていることと、業務側が決めた形式・制約を満たすことを含めます。この条件は用途とリスクに応じて自社が手順書へ明記するもので、出典が一律に定めた基準ではありません。

後続APIに切り分けた場合

後続API系では、生成内容を修正対象にしません。要求と応答、エラー、レイテンシ、トレース上の処理経路を見て、どの接続先で失敗や遅延が起きたかを特定します。再試行を選ぶ前に、同じ処理がすでに受理されていないか、再実行が業務上の重複を起こさないかを、対象APIと自社処理の仕様に沿って確認します。

連鎖障害のおそれがある場合は、運用中の思いつきで退避先を決めません。Google Cloudの同じ信頼性資料は、障害コンポーネントの隔離にサーキットブレーカーパターンを挙げ、エラー率やレイテンシに基づくしきい値と、より単純なモデルやキャッシュデータなどのフォールバックを定めるよう推奨しています。そこで手順書には、監視する信号、隔離へ移る条件、許可する代替経路、通常経路へ戻す条件を事前に記載します。具体的なしきい値や代替手段はシステム固有であり、他社の値を転記せず、自社で検証可能な条件として決めます。

復旧ゲートは記録と再検証で判定する

復旧は、原因レイヤーで修正が効いたか、後段まで含む経路が受入条件を満たしたかの二段で判定します。出典の一般原則を実務へ落とした提案であり、原典所定の義務や分類ではありませんが、少なくとも次の記録を一つのインシデント台帳にまとめます。

• 報告日、発見・報告された事象、影響、重大度
• 検索・生成・後続APIのどこへ切り分けたか、その根拠となる記録
• 実施した対応と変更理由
• 変更方法、テスト内容、デプロイ内容、対象バージョン
• 原因レイヤーの再検証結果と、通常経路へ戻す受入条件の判定

この台帳が復旧判断の入口になります。NIST AI RMF PlaybookのManage 4.1は、稼働後の監視計画にインシデント対応、復旧、変更管理などを含め、検知・報告された悪影響や性能・信頼性上の問題へ対応して記録することを提案しています。Manage 4.3も、報告日・影響・重大度・対応を含むインシデント記録に加え、変更理由、変更方法、テスト、デプロイの詳細、バージョン履歴を維持することを提案しています（Manage - AIRC、2026年9月21日確認）。これらはNISTの提案であり、自社に一律の法的義務が生じるという意味ではありません。

受入条件は「エラーが出ない」の一行では足りません。検索なら関連するコンテキストと参照元を確認できること、生成なら取得情報への帰属と出力条件を確認できること、後続APIなら隔離または代替経路を含めて処理結果を確認できることを、それぞれ記録します。複数レイヤーを変更した場合は、一つずつ再検証し、どの変更が結果へ影響したかを追える状態にします。

平常時に埋めておく運用手順書の構成

障害発生後に決めてよいのは、観測された事実に対する個別対応です。連絡先、記録場所、切り分け順、隔離条件、受入条件までその場で相談していると、復旧と設計会議が同時に始まります。手順書には平常時から次の欄を設けます。

• 対象経路：検索、生成、後続APIの構成と相関に使う識別情報
• 検知入口：利用者報告と監視通知をどの台帳へ集約するか
• 一次判断：判断表の各条件と、参照するログ・トレース
• 制限・退避：停止、隔離、フォールバックを選ぶ条件と承認者
• 復旧作業：変更理由、テスト、デプロイ、バージョンの記録欄
• 復旧ゲート：レイヤー別の再検証と通常経路へ戻す受入条件

各欄に担当名だけでなく、担当者が確認できる記録への導線を置いて初めて実行可能になります。導入時点のデータ境界や責任分担をまだ整理できていない場合は、AI導入を実装まで進めるためのガイドに沿って前提を固めます。検証環境では動くものの、本番の監視・復旧条件が未定なら、AIのPoCを本番運用へ移す判断と合わせて、公開前の受入条件へ反映してください。

AIシステムが止まったときに必要なのは、万能な障害名一覧ではありません。同一リクエストの記録から検索、生成、後続APIを順に切り分け、各レイヤーに固有の証跡で再検証する運用手順書です。自社で実行できる条件は、判断表の各行について「見る記録」「隔離または変更できる担当」「通常経路へ戻す受入条件」が埋まっていること。この三点が空欄なら、運用開始前に観測設計と責任分担から整える必要があります。

課題定義から実装、定着までの間で、どのログを残し、どこまでを自社の復旧判断にするか整理したい場合は、FDEの無料相談・AI活用診断で現在の処理経路と運用条件を確認できます。

FDE・AI実装ガイドへ戻る