AIの自動処理が止まったときの再開手順｜重複処理を防ぐ設計

AIの自動処理が止まったら、どの段階まで完了したかを確認してから再開します。送信や登録の返答が届かなかった場合、処理自体は既に完了している可能性があります。最初からすべてやり直すのではなく、対象を識別する記録、実行状態、手作業の対応を照合し、重複しない再開範囲を決めます。

「返答がない」と「実行していない」を分ける

外部ソフトへ登録した後に通信が途切れた場合、こちらが結果を受け取れていないだけかもしれません。未完了と決めつけて同じ処理を行うと、二重の登録や送信が起きる可能性があります。相手側の状態を確認できる方法と、確認できない場合の保留を設計します。

AIの文章生成だけが止まった場合と、外部への動作が止まった場合でも再開の扱いは違います。生成をやり直す原価、承認済みの版、既に実行した処理を分けて確認します。動作の種類ごとに、再実行してよい条件を決めます。

処理方式の比較は固定手順とエージェントへ渡せます。どちらの方式でも、途中状態を把握できないまま再開する設計は避ける必要があります。

一件を識別する記録を持つ

依頼、入力、生成、承認、外部実行へ同じ処理番号を対応させます。番号には、必要以上の顧客名や個人情報を含めないようにします。記録から、何を、どの版で、いつ行ったかを追える状態にします。

連携先が重複を防ぐための識別情報や仕組みを提供する場合は、その仕様を確認します。例えばStripeのAPIには再試行時の重複を防ぐ仕組みが公式に説明されています。ただし、それが任意のメール送信や他のソフトへも同じように使えるとは限りません。採用する接続先ごとに条件を確認します。

識別番号を付けただけで必ず重複を防げると説明しないようにします。番号を相手側がどう扱い、どの処理へ有効か、保存期間や同じ内容の条件がどうなっているかが関わります。業務の記録と実際の機能を合わせて設計します。

状態を四つへ分ける

不明を失敗へ一括で変えないことが重要です。外部に影響する処理は、実際に完了したかを調べます。確認する担当と方法がないなら、自動再開せず保留する案を顧客と合意します。

状態の記録を更新するタイミングも決めます。実行前、実行後、返答の受領、結果の確認が違うなら、それぞれを区別します。画面に完了と出たことだけで、顧客の業務上の完了まで保証しないようにします。

仮定例：案内メールの送信で止まる

仮定として、AIが作った案内文を担当者が承認し、顧客へ送信する工程を考えます。送信の結果を取得できず止まった場合、まず使用した宛先、文面の版、実行時刻、送信側の記録を確認します。

送信済みと分かれば再送しません。未送信と確認できた場合は、承認した文面が現在も使えるか、担当者が既に手作業で送っていないかを確認します。不明なら、顧客側の担当へ渡して対応を決めます。

手作業の送信を行ったら、その結果を自動処理の記録へ反映します。自動側が後で再開し、同じメールを送らないようにするためです。手作業へ切り替えるだけでは、自動処理との重複がなくなるとは限りません。

再開前の五項目

1. 停止の原因が分かる範囲で確認できた。
2. 既に完了した工程が分かる。
3. 顧客や担当者の手作業を確認した。
4. 再開する対象と版が確定している。
5. 必要な承認と監視の担当がある。

条件が揃わない場合は、再開する範囲を狭めるか、確認を続けます。復旧を急ぐために、重要な結果が不明なまま全件を再実行しないようにします。顧客へ状況と次の報告を伝え、業務上必要な代替案を相談します。

失敗時の連絡は停止、報告、修正の決め方へ渡せます。技術的に再開できることと、顧客の判断として再開してよいことを分けます。

再試行を上限のある工程にする

一時的な接続の問題では再試行が適する場合がありますが、入力の誤りや権限不足を同じ条件で繰り返しても直らない可能性があります。再試行する問題と、人へ返す問題を分類します。

回数、間隔、時間、使用量などの上限を置きます。具体的な条件は連携先と商品の用途へ合わせ、公式仕様と実際の動作で確認します。無制限の再試行によって費用や外部負荷を増やさないようにします。

再試行の費用は需要と再実行を含むAPI見積もりへ渡せます。原価に加えて、顧客が返答を待つ時間と、担当者が監視する時間も考えます。

承認済みの内容が変わった場合

停止中に商品条件や宛先が変わる場合があります。以前の承認を使って新しい版を送らないようにします。変更した内容を顧客へ提示し、再開する動作と承認を対応させます。

文章を再生成した場合も、同じ意味だから前の承認を使えると推測しません。数字、条件、表現が変わっていないかを点検します。外部動作へ使う版を一つに揃え、元の版と区別します。

判断の分担は外注する工程と残す権限を参考にできます。制作側が設定を修正する権限と、顧客の名義で実行する権限を混ぜないことが必要です。

確認用の環境で再現する

原因を調べる際、外部へ実際の送信や登録を繰り返さないようにします。検証用の環境、仮の入力、外部動作を止めた方式などを用意します。ただし顧客情報を別環境へ移す場合は、その許可と条件を確認します。

入力と記録の基本はAI契約と情報管理へ、資料の利用は原稿とデータの権利へ渡せます。復旧のためという理由だけで、資料を任意の人やサービスへ渡さないようにします。

再開後の点検を決める

最初は少数の対象で結果を確認する案があります。正しく完了するか、重複がないか、未処理が残っていないかを見ます。再開できた一件だけで全件が正しく終わったと説明しないようにします。

顧客へ返す報告には、停止した対象、既に完了していた対象、再開した対象、未解決を分けます。件数と記録を照合し、作業の抜けを確認します。問題が再発した場合の停止と連絡も準備します。

納品前に再開の練習をする

再開の対象を選ぶ資料には、処理番号、顧客の案件、状態、使用する版、確認者を並べます。途中の記録が複数ある場合は、どれが最新の状態かを揃えます。古いログへ基づいて未完了と判断しないようにします。

停止が長く続いた場合は、入力の期限や顧客の予定が変わっていないかを確認します。以前は必要だった処理でも、顧客が別の方法で完了している場合があります。機械的に残る一覧をすべて処理するのではなく、現在も実行すべき対象へ絞ります。

復旧後に記録を消す場合も、顧客との条件と必要な確認を踏まえます。完了したかを説明するための記録と、原因調査へ使った顧客資料を分け、必要な範囲だけを保存します。復旧できたことが、資料の無制限な保持や再利用の許可になるわけではありません。

通常動作の試験だけでなく、途中で止まる例を用意します。どの状態が記録され、顧客の担当者が何を見て判断できるかを確認します。復旧する人が制作へ参加していなかった場合も、資料だけで理解できるかを試します。

一般的な引継ぎの条件は感覚へ依存しない運営の引継ぎを参考にできます。再開に向くのは、対象を識別し、実行状態と手作業を記録できる設計です。停止したから最初からやり直すという方法を避け、既に完了した仕事を守りながら復旧してください。