AIワークフローが途中で失敗したら、どこから再実行する？

文章を作成し、画像を生成し、動画の書き出しを始めたところでタイムアウト。「最初からやり直す」を押したくなりますが、有料の処理はすでに完了しているかもしれません。応答が届かなかったことと、相手側で処理が実行されなかったことは別です。

業務自動化を発注する前に、この場面を実演してもらいましょう。何が完了し、どこで失敗し、次の操作で何を繰り返すのか。担当者が画面から判断できることが大切です。

自社の動画制作フローで変えたこと

2026年9月、Jidoの動画下書きで復旧処理を見直しました。素材の準備、画像処理、ナレーション、外部サービスの状態確認、書き出しを別々のステップとして扱います。一部の一時的な障害では、5秒後と15秒後に追加で2回試行します。完成した素材や外部サービスの処理IDは、同じ下書きに紐づけて保持します。

有料処理を開始するリクエストは扱いを分けています。受け付けられたか不明なら、確認のために停止します。同じ作成リクエストを自動で送り直すことはしません。途中まで進んだ生成処理全体をスケジューラーが最初から再実行する動作も廃止しました。これは自社システムでの設計判断であり、すべての外部サービスに同じ保証があるという意味ではありません。

本番環境で管理されたテストを行い、書き出し前に意図的に失敗させた下書きを、再試行の操作で復旧しました。下書きのレコードは1件のまま、18.5秒の動画が完成しました。このテストでは有料の素材生成は行っていません。確認できたのはこの復旧経路です。システム全体の成功率や、結果不明の外部処理を必ず復旧できることまでは示していません。

状態ごとに次の操作を決める

完了済み: 保存した成果物が現在の入力に対応することを確認し、再利用する。

安全に繰り返せる処理の一時障害: 回数と時間を制限して、そのステップを再試行する。

入力不備、内容の審査不合格、予算上限: 停止し、変更が必要な点を説明する。

外部サービスの結果が不明: 既存の処理を確認してから、新たな作成リクエストの可否を判断する。

エラー画面には失敗したステップを表示し、完了した成果物にはアクセスできるようにします。「再試行」が状態確認なのか、既存ファイルの書き出しなのか、有料素材の再作成なのか。操作する人が推測しなくて済む表示が必要です。

処理IDは、同じ処理として扱ってこそ役に立つ

APIによっては、同じ操作の再送を識別する「冪等性キー」を利用できます。Stripeは、同じキーのリクエストに対して、エラーを含む保存済みの結果を返すと説明しています。保存期間やパラメーターの条件があるため、提供元の仕様を確認する必要があります。

社内でジョブIDを発行するだけでは、外部APIにその保証は生まれません。外部の処理ID、入力の版、保存結果、現在の状態を対応づけて管理します。依頼内容が変わった場合は明示的に改訂し、以前の素材がそのまま新しい成果物に混ざらないようにします。

検収前に確認したい4つの失敗

テスト用の入力を使い、課金や第三者への連絡を伴う外部操作は必要に応じて模擬します。期待する結果を先に合意してください。

ブラウザーに応答が届かない: 再度開くと、新規作成ではなく既存の試行が表示される。

後半のステップが失敗する: 確認済みの成果物を保持し、必要な処理だけを繰り返す。

外部で受け付けられた可能性がある: 不確実な状態を表示し、既存処理の確認か人への引き継ぎを行う。

再試行では解決しない: 入力不備、審査不合格、予算上限では、理由を示して停止する。

画面だけでなく、保存レコードや外部への操作回数も確認します。成功の表示だけでは、下書きや請求、メッセージの重複を防げた証拠にはなりません。

復旧も受け入れ条件に含める

発注時には、次のように書けます。「部分的な失敗の後も、完了済みの成果物と試行IDを保持する。結果不明の外部操作を明示し、範囲と回数を制限した復旧手順を用意する。合意した障害ケースで実演する」。

未解決のジョブを誰が担当し、どう気づくかも決めます。人によるレビューは、実際に届ける成果物と結びつけてください。復旧で内容が変われば、以前の承認をそのまま適用できない場合があります。

ご相談の際は、繰り返し行う業務を1つ、現在止まりやすい箇所、最終的に必要な成果物をお知らせください。業務の流れを相談する。その情報から、確認すべき範囲を具体化できます。