連携は変化する複数のシステムに依存します。公開は運用の始まりです。保守は問題の発見、データ保存、工程の復旧を支えます。
公開前に監視と復旧を合意します。稼働工程には責任者と確認できる履歴が必要です。
故障の原因
API変更、契約終了、トークン期限切れ、CRM項目名の変更などがあります。技術的には動いても、新しい注文が古い規則を通る場合もあります。
AIはモデル、指示、知識の変更で品質が変わります。一度の成功では更新後も正しいと証明できません。
停止や誤動作を検知する
技術エラーだけでは足りません。異常なく終了して誤った状態を付けることもあります。登録、担当割り当て、受け付けと処理の件数を確認します。
ID、失敗段階、次の行動を含む通知が役立ちます。同じエラーの大量通知より、重要な通知を実際に読む担当者が必要です。
有用な履歴を残す
時刻、ID、実行手順、結果を記録します。AIでは指示やモデルの版が再現に役立ちます。秘密や不要な個人情報はログに入れません。
保存期間を工程に合わせ、アクセスを制限します。調査のために全会話を無制限に複製する必要はありません。
検証と復旧を伴う更新
通常入力、情報不足、重複、外部停止の試験例を保持し、変更前に結果を比較します。エージェントが停止や相談をすべき場合も試します。
小さな範囲から更新し、前の設定と復旧方法を残します。データ移行は別に検証し、コードを戻しても形式変更は戻らない場合に備えます。
保守の責任を合意する
監視担当、対応時間、故障分類、継続費の範囲を明確にします。新しい工程追加と既存工程の復旧は違う作業です。
権限、依存関係、バックアップ、手動処理の資料を受け取ります。工程は検査でき、他の専門家にも引き継げる必要があります。
例：CRM の受付停止
必須項目の追加でサイト受付だけ成功する場合があります。オンラインかだけでなく、受信と記録確認の差を監視します。
受信、送信、確認、保留を記録し、個人情報を出し過ぎず担当へ通知します。修復後は重複を避けて再処理し、復旧手順を前もって用意します。
保守の合意
合意機能の欠陥、外部サービス変更、新機能を分けます。別 CRM の接続は通常保守とは限りません。
時間、連絡、優先度、反応期限を明記し、調査開始と解決を区別します。更新料、鍵、上限の担当を決め、夜間対応は別途合意します。
安全な更新
稼働版を保存し、安全な環境で通常と例外を試します。実顧客に誤送信してはいけません。
公開後の誤り、時間、保留を比較し、戻す手段や手動経路を用意します。モデル、指示、知識の変更も回答品質を確認します。
月次確認
量、誤り、人の介入、費用を比べます。利用増と再試行の循環は履歴から区別します。
変更、障害、対応、残る問題を短く報告します。アクセス、手順、代替を事業に残し、絶対に壊れない約束より管理可能性を保ちます。
確認すること
- 通知と復旧の担当者を決める。
- APIエラーと業務成果の両方を見る。
- 代表的な例で変更を試す。
- 保守、資料、手動代替を合意する。
