AI業務自動化の障害対応と再実行の決め方

AI業務の途中で応答が切れると、担当者は完了した処理と止まった処理を同じ不安として見てしまいます。PDFができているのか、メールが送られたのか、もう一度押してよいのかが曖昧なまま動くと、同じ依頼を二重に処理する恐れがあります。

AI業務自動化の障害対応では、結果不明の操作をすぐ繰り返さず、保存済みの成果物、外部送信の履歴、依頼ID、次の担当を照合してから再開します。稼働中の一件について、どこまで終わったか、何がまだ不明か、誰に渡すかを決められます。

AI業務で止まった一件の見方

止まった一件を見る時は、AIの処理全体を失敗と見なす前に、保存済みの成果物、外部へ影響した可能性のある操作、担当者の判断へ戻す操作を分けます。この記事の例は、広告レポートを配信する架空の業務で、依頼R-104を使って集計、PDF作成、メール送信要求の順に状態を確認します。顧客事例や既存システムの実測ではなく、編集部が作った運用案です。

止まった処理と終わった処理

依頼R-104では、集計は保存済みで、PDF作成も完了している前提です。その後、メール送信要求を出したところで応答が切れたため、止まった場所はメール送信要求の後にあります。ここで重要なのは、PDFがあることと、メールが送られたことを同じ完了として扱わないことです。

メール送信要求後に応答が切れた場合、送信結果は不明です。未送信と決めて同じ操作を繰り返すと、送信が実際には済んでいた時に同じ相手へ二重に届く可能性があります。送信済み履歴、送付先、依頼IDを見て、外部へ影響した操作だけを別枠で確認します。

AWSの冪等性に関する資料は、タイムアウトなどで応答が返らない時、処理が実行されたかどうかが呼び出し側から分からない場面を説明しています。（AWS Making retries safe with idempotent APIs（公式））同資料では、単純な再試行が望ましくない副作用につながる例として、同じ意図の操作が複数回起きる問題が示されています。この考え方を業務の復旧に移すと、結果不明の送信要求は未送信ではなく、履歴照合が必要な状態として扱います。

冪等性を平易に捉える

冪等性は、同じ依頼の重複で結果を二重に増やさない性質として捉えると実務に置きやすくなります。たとえば同じ依頼IDで送信処理をもう一度動かしても、すでに処理済みなら新しい送信を増やさない、という考え方です。ただし、すべての操作や外部サービスがこの性質を保証するわけではありません。

運用では、依頼ID、処理済みマーク、送信履歴の照合を組み合わせて、二重処理を避けます。AWSの資料では、同じ呼び出しを識別するための一意なリクエスト識別子を使い、同じ意図の再試行を判別する設計が説明されています。（AWS Making retries safe with idempotent APIs（公式））業務側では、同じ依頼か、処理済みか、外部への影響が出たかを確認できる記録を先に残します。

再開前に分ける三つの状態

再開前の状態は、完了が確認できる、未完了が確認できる、判定できないの三つに分けます。依頼R-104では、PDF作成完了までは確認済みですが、メール送信結果は別に見ます。判定できない時は、同じ操作を押し直すのではなく、確認担当へ渡す状態にします。

障害対応で二重処理を防ぐ流れ

AI業務の障害対応では、止まった操作をそのまま繰り返す前に、保存済み成果物、外部送信の履歴、依頼IDを同じ流れで照合します。AIの答えは原因の断定ではなく、確認順を短くするための切り分け案として使うと、送信結果不明の状態を未送信と誤って扱いにくくなります。

依頼R-104で最後に確認できた結果は、PDFが作られたところまでです。送信結果は不明なので、未送信とは書かず、送信済み履歴、送付先、依頼IDを次の確認対象にします。NISTの管理観点でも、AIシステムのエラーやインシデントは、対応と回復の過程を記録して関係者へ伝える対象として扱われます。（NIST AI RMF Playbook）

送信履歴と依頼IDの照合

送信結果が不明な操作では、まず送信済み履歴を見ます。履歴に依頼R-104と同じ送付先への送信が残っていれば、再送せず、送信まで進んだ一件として扱います。履歴に送信がなく、未送信だと確認できた場合だけ、担当者の判断で再開します。判定できない場合は、同じ操作を押し直さず、送付先、依頼ID、最後に確認できた結果を添えて確認担当へ渡します。

この分岐で使う依頼IDは、同じ依頼の重複を見分ける手がかりです。ただし、すべての操作が重複を自動で防ぐとは限らないため、業務側では履歴と処理済みマークを合わせて見ます。

再試行の回数と間隔

再試行とは、失敗または応答なしになった要求をもう一度送ることです。AWSの資料では、一時的な失敗には再試行が有効な場合がある一方、再試行は呼び出し先の負荷を増やし、過剰に行うと回復を遅らせる可能性があると説明されています。（AWS Timeouts, retries, and backoff with jitter（公式））

バックオフとは、再試行の間隔をすぐ押し直しではなく段階的に空ける考え方です。外部一時障害であれば、回数と間隔を決めて試す余地があります。ただし、結果不明の外部送信は、先に履歴を見るまで再試行の対象に入れません。

AI業務の障害対応を票に落とす

R-104の障害票

障害票とは、止まった一件を再開する前に、対象、最後に見えた結果、不明点、次の担当へ分けて渡す記録です。R-104の記入例を下の表に示します。送信結果は不明なので、未送信とは書きません。

業務担当へ渡す連絡文

確認担当へ渡す文は、依頼ID、送付先、最後に確認できた結果、判断してほしいことの順にします。たとえば「依頼R-104は集計保存とPDF作成まで確認済みです。メール送信要求後に応答が切れたため、送信済み履歴、送付先、依頼IDの照合をお願いします」と書けば、外部送信した事実を作らずに渡せます。

短文の目的は、AIに原因を断定させることではなく、業務担当が履歴と責任範囲を見て次の動きを決められる状態にすることです。

• 依頼ID
• 送付先
• 確認済み結果
• 不明点
• 判断してほしい内容

分岐の行は、再送の可否だけでなく、担当者と残す内容までを一組で決めます。資料不足の行では、同じ再試行をしても送付先や依頼内容の不足は解消しないため、担当者への確認に戻します。

広告業務への置き換え

広告レポート配信や制作承認では、入力資料、担当者の承認、外部送信の有無が分岐点になります。広告レポート自動化では、媒体から取得した数字を正本化し、欠損や集計粒度を承認できる形に整える考え方が示されています。（SynClip advertising-）止まった一件でも、取得済みの数字、PDF化した資料、送信要求後の状態を同じ完了にまとめない方が扱いやすくなります。

制作承認の業務では、商品資料、参考広告、台本案、素材リスト、編集指示、検証観点のように工程ごとに入力が変わります。（SynClip ai-agent-for）広告AIエージェントの工程整理では、入力、任せる処理、人の承認を同じ行で比べる形が示されています。障害対応でも、どの入力がそろい、どの承認が残り、どの外部操作が結果不明なのかを分けると、AIの出力品質と業務の再開判断を混ぜずに済みます。

日常運用へ渡す判断では、誰が毎日入力し、誰が出力を確かめ、止まった時にどの作業へ戻るかも残します。（SynClip ai-poc-to-pr）SynClipの移行判断表案では、確認資料、担当者、未解決、次の確認方法を行ごとに置き、品質の合格だけで運用可能とはしません。障害票も同じように、AIが処理を再開できるかより先に、業務側が何を見て止めるかを記録します。

障害時の判断者を含む業務の分担 関連記事を読む

自動化の復旧前に見る項目

すぐ押し直さない条件

復旧前に避けたい操作は、結果不明のまま同じ処理を押し直すことです。外部副作用とは、外部送信、課金、台帳更新、担当者通知のように、処理の外側に結果が残る動きです。応答が切れただけでは、その動きが失敗したとは限らないため、先に履歴を見ます。

• 結果不明の操作を、未完了と決めずに履歴で見る
• 外部送信、課金、台帳更新、担当者通知を外部副作用として分ける
• 依頼IDを送信履歴や処理記録と照合する
• 処理済みマークがあれば同じ結果を増やさない
• 再開点を保存済み成果物の後ろに置く
• 担当者が判断できない時は確認担当へ渡す

原因別の戻し先

認証切れは、同じ再試行で解決する問題ではなく、権限の確認へ戻します。広告運用の自動化でも、権限がない業務は取得や変更の設計へ進む前に、誰の権限で何を見られるかを確認する考え方が示されています。（SynClip advertising-）処理を押し直す前に、利用者の権限、接続先の権限、変更できる範囲を分けると、失敗の原因を出力品質へ混ぜずに済みます。

資料不足や出力品質不足まで同じ再試行に入れると、足りない入力や判断条件を直さないまま同じ失敗を重ねます。回数と間隔を決めた再試行の対象になるのは、外部一時障害だけです。

資料不足は担当者への確認へ戻し、出力品質不足は指示や資料の再検討へ戻します。NISTの管理観点では、AIシステムが目的に合うか、負のリスクと便益を追い、必要に応じて対応や回復の手順を文書化する考え方が示されています。（NIST AI RMF Playbook）稼働中の一件では、原因を大きな改善計画へ広げるより、今の処理をどの担当へ戻すかを短く分ける方が復旧に使いやすくなります。

• 認証切れは権限確認へ戻す
• 外部一時障害は回数と間隔を決めて待つ
• 資料不足は担当者へ不足内容を確認する
• 出力品質不足は指示や資料の再検討へ戻す

次回へ残す短い欄

次回へ残す欄は、次に見る人が押し直す前に判断できる記録に絞ります。

依頼IDだけを残しても、どこから再開するかは分かりません。下の項目に加えて、保存済み成果物の位置と外部副作用の有無も残すと、判定不能な状態を個人の記憶へ戻さずに済みます。

• 処理ID
• 再開点
• 二重処理を避ける根拠
• 処理済みマークの確認結果
• 次の担当

自社の業務で試す

広告レポート配信など広告制作・運用の業務で、止めて戻す判断の流れを試したい場合は、インパクトトライアル（最短1ヶ月のスピード検証）で相談できます。対象業務は相談のうえ決め、自社の業務資料や確認記録を使った試作を毎週更新し、合意した指標で変化を確かめます。

インパクトトライアルを見る