AI自動化を納品した後の保守は何をする？変更点を整理

AI自動化の納品後の保守は、止まった処理を直す仕事だけではありません。接続先の仕様、AIの利用条件、顧客の入力や承認ルールが変わっても、合意した業務を続けられるか確認する仕事です。ただし、新しい業務の追加まで保守に含めるかは別の判断です。変更の種類と対応範囲を納品時に分けてください。

納品時の状態を残しておかないと、変更が分からない

保守の出発点は、何が正常だったかを確認できる資料です。接続先、使用するAI、入力の項目、指示文、承認者、出力先、停止条件を残します。実行できたという記録だけでなく、どの条件を試験したかも必要です。後から結果が変わったとき、元の設計と現在の運用を比較できます。

画面の写真だけでは、処理する条件や権限の範囲が分からない場合があります。設定の一覧と確認用の入力を合わせて保管します。秘密情報をそのまま資料へ載せるのではなく、管理する場所と確認する担当を示します。顧客が担当者を替えても、引継ぎ先が状態を理解できる形にします。

納品後に顧客が変更できる項目と、制作側へ連絡してから変える項目を分けます。たとえば入力欄の表示名だけを直す操作と、AIへ渡す内容を増やす操作では影響が違います。自由に変更できる部分を広げるなら、何を変更したか記録する方法も渡してください。

保守対象を、原因ではなく変更の層で整理する

同時に複数が変わる場合もあります。一つの更新を直しただけで完了とせず、入力から最終成果物まで試します。変更の責任を自動的に顧客やソフト提供会社へ押し付けるのではなく、自分の契約でどこまで調査と説明を行うかを明らかにします。

モデルを替えるときは、出力の見栄えだけで決めない

別のAIへ切り替える候補があっても、文章が自然になったという印象だけで本番へ移しません。必要な項目を落とさないか、分からない内容を推測しないか、指定形式を守るかを試します。既存の確認担当が読み直す時間も含めて比較します。変更前の出力が常に正解とは限らないため、業務の基準へ照らします。

代表的な入力だけでなく、以前に止めた入力や修正した入力も試験用に残します。実際の顧客情報を使う場合は使用と保存の条件を確認し、試験に不要な内容は省きます。切替先へ無条件で秘密情報を渡してよいわけではありません。利用条件はAIツールの契約と情報の扱いを参考に確認してください。

提供元がモデルの情報や利用条件を案内している場合は、対象の名称と環境を確認します。一般的な紹介記事を見ただけで、導入中の機能が今後も使えると判断しないようにします。移行に必要な期間と試験の担当を決め、顧客へ影響が出る前に判断できる窓口を置きます。

顧客のルール変更は、意外な場所へ影響する

仮定として、問い合わせの分類を三種類から五種類へ増やす変更を考えます。AIの指示だけを直しても、振り分け先の担当や報告表が三種類のままなら運用は続きません。変更の依頼では、入力、分類、担当、通知、報告のどこが変わるかを一緒に確認します。

担当者の変更も対象です。前任者へ承認依頼が送られ続けると、システムは動いていても仕事が止まります。顧客側の連絡事項として、担当、営業日、確認期限、扱ってよい資料の変更を示します。すべてを制作側が自動で察知できるという条件にはしません。

新しい仕事を追加するなら、既存業務を維持する修正と分けて依頼します。制作側からも、変更理由と影響する処理を説明して追加費用の対象を示します。範囲の合意には外注する仕事の切り分け方を使えます。保守契約があることを、無制限に開発を頼める意味にしないようにします。

受付、調査、復旧を同じ約束にしない

問い合わせに返信する時間と、原因を調べる時間と、利用を戻せる時間は違います。連絡を受けたらすぐ復旧させるという曖昧な表現を避け、受付する曜日や時間、緊急と判断する条件、状況を再報告する時点を決めます。原因が接続先にある場合は、制作側だけで修正できないこともあります。

保守担当が最初に受け取る情報を定めます。対象の処理、発生時刻、最後に正常だった時点、変更した設定、顧客への影響を揃えると調査へ進めます。顧客の文章や個人情報をすべて連絡欄へ貼る方法にせず、必要な記録へ適切な権限でアクセスする方法を用意してください。

停止している間は、自動処理を続けるか手動へ戻すかを判断します。復旧したら、途中の案件が実行済みかも確認します。再開時の重複を防ぐ手順はAI自動処理の停止後の再開で扱います。保守は「直した」という説明だけで終わらず、顧客が残っている仕事を把握できるようにします。

定期確認で行うことを具体的にする

毎月の支援を商品にするなら、何を調べ、何を報告するかを記載します。エラーの確認、権限や契約の点検、試験用入力での動作確認など、必要な対象を選びます。作業がない月でも何を確認したか示せれば、顧客は継続費用の意味を判断できます。

一方、すべての出力を毎回人が読む支援を含めるなら、その工数を料金と範囲へ入れます。定期的な技術確認と日々の成果物の監視を混ぜないようにします。業務品質の指標を設ける場合は処理件数以外の監視項目を選び、顧客が行う確認との分担も決めます。

報告には確認した期間、変更した箇所、未解決の事項、顧客へ求める判断を載せます。単に「異常なし」と送るのではなく、どの範囲で異常が見つからなかったか示します。確認していない機能があるなら、それも伝えてください。監視しているという言葉を全業務の保証に広げないことが必要です。

修正した設定を戻せるかも点検します。古い設定へ戻すだけでよい場合と、変更後に処理した案件まで確認する必要がある場合を分けます。変更が不適切だったときの担当と判断材料を用意しておくと、修正を重ねて元の状態が分からなくなることを避けやすくなります。

保守の原価は、変更と問い合わせで変わる

費用を見積もるには、対象の処理数だけでなく変更の頻度と確認の深さを見ます。顧客が毎週ルールを変える仕事と、入力形式が安定している仕事では必要な工数が違います。小規模な設定の調整と、新たな接続先の追加を同じ料金で無制限に受けないようにします。

料金を比較するときは、更新作業だけでなく試験、記録、顧客への説明が入るか確認します。見積書の読み方は制作費に含まれるものと別料金を参照できます。保守の費用相場を一律に決めるより、自分の対象業務で実施する作業から積み上げてください。

保守を終えるときにも、業務を残す

契約が終わる前に、最後に確認した設定、未解決の問題、接続先の契約、今後の変更予定を引き継ぎます。顧客が別の担当へ保守を頼む場合、どの資料を渡せるかを契約時に説明しておきます。設定を保管している場所や利用権限が不明なまま、問い合わせ窓口だけを閉じないようにします。

引渡しの一般項目は納品後に受け取る資料と管理情報を基に、AIと連携の版、試験条件、停止手順を加えます。保守に向くのは変更を共有できる顧客との仕事です。変更を知らせず結果だけを保証してほしいという案件は、支援条件を見直してから受けてください。