AIシステムの運用保守で何を決める？監視・障害対応・改善のチェックリスト

「動いている」と「使える」を分けて監視する

AIから返事が返っていても、根拠が古い、後続システムへの登録が失敗している、承認待ちが放置されているなら、業務としては未完了です。監視対象をサーバーやAPIの稼働状況だけに限定しないことが重要です。

GoogleのSRE資料は、状態を把握し、問題を診断するための監視を説明しています。AIを含む業務システムでは、処理のどこで止まったかを担当者が追えるようにし、通知を受けた人が取る行動まで結び付ける案を推奨します。

本記事は当社の運用設計案であり、一律の保守契約やサービス水準を示すものではありません。営業時間、業務の重要度、停止が与える影響によって必要な体制は変わります。

開始前に合意しておきたい監視項目

通知は多ければよいわけではありません。同じ事象が繰り返し通知される場合はまとめ、直ちに対応するものと定期確認するものを分けます。通知先だけ決めて、担当者が不在の時間帯を考えない運用は避けましょう。

停止・代替手段・再開条件を決める

問題が起きたら、まず自動送信や登録など影響を広げる機能を止める必要があるか判断します。閲覧や下書きだけを残せるか、すべて止めるかを機能単位で設計します。止めた後に誰が手作業へ戻し、未処理案件をどう引き継ぐかも必要です。

復旧時には、失敗と結果不明を区別します。登録が完了しているか不明な案件を一括で再処理すると、二重登録や重複通知につながるおそれがあります。再開する前に対象案件を照合し、確認できないものを担当者へ渡します。

障害対応の記録は、発生時刻、対象業務、影響件数、実施した対応、未解決事項を残します。原因が分かる前に「AIの不具合」とまとめず、データ、モデル、連携、権限、業務ルールのどこで起きたかを切り分けます。

プロンプトや参照文書も変更管理の対象

コードを変えていなくても、回答指示、参照資料、モデルの版が変われば、業務結果が変わる可能性があります。変更の目的と対象範囲を記録し、既存の評価問題と、変更内容に対応する新しい問題で確認してから反映します。

古い状態へ戻せる範囲も確認します。指示や設定は戻せても、外部へ送信したメールや確定した登録は簡単には戻せません。元に戻す操作を安易に自動化せず、訂正が必要な場合の業務手順を別に用意します。

NISTのAI RMF Playbookも継続的なリスク管理を考える参考になります。導入時の一度の審査だけで終わらせず、利用範囲や連携先が増えるたびに見直す運用を検討します。

運用訓練：AIは応答するが、登録先だけが停止したら

架空の訓練条件として、回答生成は成功する一方、後続のCRMへの登録だけが停止する状況を作ります。画面に成功と表示されないか、未登録の案件を一覧にできるか、通知を受けた担当者が対処できるかを確認します。

担当者は、影響する工程を止めて、すでに完了した処理と残った処理を分けます。代替の手作業で進める場合も、復旧後に同じ案件を再登録しないように、処理済みの記録を残します。復旧したから全件再実行する、という手順にはしません。

次に主担当者が不在という条件を加え、別の担当者が手順書だけで状態を把握できるか試します。管理画面の場所が分からない、必要な権限がない、委託先への連絡が取れない、といった運用上の課題を先に見つけます。

訓練後は、検知から着手までの時間、影響範囲を特定するのに必要だった情報、手順書の不足を記録します。稼働率の目標だけを決めるより、復旧までの仕事を具体化する材料になります。

保守を依頼するときの引き継ぎ内容

• 業務フローと、対象外・人が判断する条件。
• 連携先、利用する権限、秘密情報の管理担当。
• 設定・モデル・参照データの変更履歴。
• 評価データ、既知の制限、再テスト手順。
• 監視画面、通知先、障害対応の連絡経路。
• 停止・手動代替・再開の手順。
• 費用の確認方法、上限到達時の扱い。
• データの保存・削除と契約終了時の扱い。

保守の範囲は、障害対応、品質改善、機能追加で区別します。FAQの更新を誰が行うか、モデル変更の再評価に誰が工数を出すかも、月額費用の比較に必要です。担当者が交代しても判断できる記録を成果物に含めます。

運用開始後の改善は、失敗件数だけでなく、業務担当者が確認・修正にかけた時間から優先順位を付けます。見積もりの比較では運用費の範囲、RAGの評価では変更時に残すテストを詳しく扱っています。