AI受託サービスで失敗が起きたときの連絡と修正の決め方

AI受託サービスで誤りや処理の失敗が起きたら、まず影響が広がる処理を止め、分かっている事実を依頼者へ知らせます。その後、原因、影響範囲、修正方法、再確認を分けて進めます。AIが作ったから責任を負わないと説明するのではなく、契約と実際の作業を確認し、依頼者が次の対応を判断できる情報を整えます。

仮定例：納品した案内に古い条件が入っていた

仮定として、顧客の商品案内を制作した後で、旧版の条件が一か所残っていたと分かったとします。顧客がまだ配布していないなら、使用を待ってもらい、該当箇所と関連する記載を確認します。既に配布している場合は、どの版を誰へ渡したかを顧客と確かめます。

この時点で、原因が旧資料の混在なのか、AIの出力なのか、最終確認の漏れなのかは未確定かもしれません。原因を推測して顧客の資料不足へ帰属させるのではなく、問題の記載、使用した版、確認した時刻を整理します。最初の連絡に必要なのは、すべての原因分析を終えた報告ではありません。

修正版を急いで送る場合も、同じ条件が表や注記へ残っていないかを確認します。正しい版と旧版を区別し、どのファイルを使うかを顧客へ明示します。黙って差し替えるだけでは、旧版が使用され続ける可能性があります。

最初の連絡で伝える四項目

1. 確認できた問題と発見した時刻。
2. 現時点で分かる対象と影響。
3. いま止めた処理、顧客へお願いする対応。
4. 次の報告時期と連絡担当。

不明なことは不明と示します。影響がないと確認できていない段階で、軽微な問題と決めつけないようにします。一方、すべてのデータが壊れたなど、根拠のない大きな断定も避けます。顧客が判断できる範囲の事実を先に伝え、追加確認の予定を示します。

顧客の連絡先と緊急性をあらかじめ決めておくと、問題が起きた際に迷いにくくなります。通常の窓口、管理担当、承認者のどこへ連絡するかを契約と運用に合わせて確認します。社外へ公表する必要があるかは、制作側だけで独断せず、実際の問題と制度へ応じて確認します。

広がる処理と確認の作業を分ける

外部への送信、公開、登録などを含むサービスでは、同じ問題が繰り返されないよう対象処理を止める必要がある場合があります。止める権限と方法を確認し、顧客の通常業務へ影響するなら代替手順を相談します。止めた範囲と継続する範囲を共有してください。

確認のために再処理する場合も、元の処理をそのまま実行してよいとは限りません。検証用の環境へ分ける、外部動作を止めた状態で調べるなど、影響を増やさない方法を選びます。再開時の重複防止は停止後の再開手順で詳しく扱います。

問題の記録を残す際は、元資料、入力、出力、実行状態、確認の履歴を必要な範囲で保存します。原因調査のためでも、顧客の個人情報や秘密情報を無制限に別環境へ集めないようにします。基本はAI利用と情報管理の条件へ渡せます。

原因と影響を別々に調べる

原因が一つ分かっても、影響がすべて分かったとは限りません。共通の資料や処理を使う他の納品物へ同じ問題がないかを見ます。別の顧客へ確認が必要な場合も、顧客同士の情報を混ぜず、それぞれ必要な事実を伝えます。

資料の取扱いと再利用は原稿とデータの権利を参照できます。調査の記録を後で見本や研修資料へ使う用途は、問題対応とは別に許可を確認します。

修正案は完成条件まで示す

修正する場所、必要な情報、確認者、予定日、納品形式を具体化します。文の誤りを直す、関連する表を更新する、既存の出力を再点検するなど、何をもって対応完了とするかを顧客と揃えます。単に再生成したことを修正完了とは扱いません。

顧客が別の内容も追加したい場合は、問題の補正と新しい依頼を分けます。ただし自分の誤りの訂正を、回数制限だけを理由にすべて有料へ変える説明にはしません。料金と責任は契約と実態に応じて確認します。

変更範囲の整理は差戻しと追加作業、再確認の基準は納品物の受入条件へ渡せます。合意した条件へ戻ったかを点検してから、顧客へ使用できる版を示します。

納期を守れない場合の伝え方

必要な確認が予定より長いなら、理由、残る工程、代替案を示します。修正版を先に一部だけ渡す、対象外の箇所を除いて使う、全体を確認してから納品するなど、顧客が業務上の判断をできる案を出します。

確認を省いて当初の期限へ無理に合わせると、再び問題が出る可能性があります。未確認の部分を確定版へ混ぜず、暫定資料を渡す場合も使用範囲を明示します。顧客が社外へ配布するなら、その用途に必要な確認を優先してください。

差戻しの基本は確認項目と修正の整理を参照できます。顧客の不安に対して何でもすぐ直すと約束するより、実行できる工程と次の報告時刻を示す方が状況を共有しやすくなります。

再開は、原因を直しただけで決めない

修正した内容が適切か、通常例と問題の例で確認します。設定を変えた結果、別の条件へ影響していないかも見ます。顧客の承認が必要な処理は承認してもらい、再開する対象と時刻を記録します。

再開直後には限定した範囲で状況を見ます。大量処理へすぐ戻す必要がないなら、少数から確認する方法があります。再発した場合の停止と連絡も決め、顧客が状況を把握できる状態にします。

対応後に残す振り返り

原因が未確定のまま時間がかかる場合も、顧客へ途中の報告を返します。何を確認し、何が分かり、次に何を調べるかを示します。原因が分からないから連絡しない状態では、顧客が使用や配布を判断できません。次の報告予定を変える場合も、その前に伝えます。

顧客へ渡す修正一覧は、問題の箇所、変更内容、確認した条件を対応させます。顧客が全部を読み直す必要があるか、影響する部分だけを確認できるかも示します。ただし関連する条件が広い場合は、部分確認で十分と説明しないようにします。

提供者自身が対応できない場合の連絡先も考えます。協力者へ依頼する場合は、顧客情報を渡せる条件と必要な権限を確認します。緊急だから無断で別の人へ資料を転送してよいとは扱いません。顧客が管理者として状況を把握できる記録を残してください。

再発防止は、確認項目を増やすだけとは限りません。正の資料を一つにする、未確定の入力を止める、外部動作前に承認を入れるなど、問題が起きた工程へ対応する案を選びます。変更によって日常の作業が増える場合は、その負担と費用も顧客へ説明します。

発生、発見、停止、連絡、修正、確認、再開の時系列をまとめます。何が原因だったか、どの確認で発見できるか、どの手順を変えたかを残します。顧客が悪い、AIが悪いという説明だけでは、次の改善へ使えません。

最初の依頼条件が不明だったなら、受注前の情報を見直します。考え方は発注設計の確認を使えます。一方、指示が明確だったのに反映していない場合は、制作側の工程を直します。原因によって対策を選んでください。

失敗時の対応に向く準備は、連絡先、停止権限、必要な記録、修正の確認者です。事故が起きてから全てを決めるより、提供前に対象と担当を揃えます。責任を一律に免れる説明を置くのではなく、契約と実際の作業に合う対応を進めることが必要です。