AIエージェントへ調査、資料作成、データ更新をまとめて任せたものの、数時間後に止まり、どこまで終わったのか分からなくなっていないでしょうか。最初から実行し直すと、同じメール送信や同じレコード登録が重なる不安もあります。
原因は、長時間タスクを長い会話として保存し、業務の進捗と外部システムで確定した操作を別に記録していないことです。モデルが直前の文脈を読めても、送信や公開が実際に成功したかは会話だけでは確定できません。
この記事では、AIエージェントの長時間タスクを、実行ID、工程、チェックポイント、外部操作IDで管理し、中断後に二重実行を避けて再開する方法を解説します。特定製品に依存せず、小さな業務で試せる形に落とします。
株式会社ラクボは、AI自動化を作るだけでなく、停止、再開、人の確認、公開後の検証まで含めて運用設計しています。少人数の会社でも担当者が現在地を説明できる、壊れにくい自動化の考え方をお届けします。
長時間タスクは会話履歴ではなく実行状態で管理する
長時間タスクで保存すべきなのは、会話全文より先に『業務が今どの状態か』です。一つの実行へ固有の実行IDを付け、受付済み、準備済み、外部操作待ち、検証待ち、完了、要確認のように状態を分けます。各状態には開始時刻、担当、入力の版、次の一手、停止理由を残します。
OpenAIが2026年9月10日に公開したAgents APIの発表は、数日にわたる作業で文脈、ツール利用、途中成果を管理する実行基盤の重要性を示しています。ただし、基盤が長く動けることと、自社業務が安全に再開できることは同じではありません。
たとえば競合調査から提案書を作る業務なら、検索済み、根拠採用済み、構成確定、本文完成、承認待ちを別工程にします。『70％完了』という曖昧な数字ではなく、再開者が次の一手を一つ選べる状態名と成果物の場所を残すことが重要です。
チェックポイントに結果と外部操作IDを残す
チェックポイントは、再開地点を示す記録です。最低限、実行ID、工程名、使用した入力のハッシュ、完成成果物、確認結果、外部操作の要求ID、保存時刻、再開条件を持たせます。ファイルを作った工程なら保存先と内容ハッシュ、CRM更新なら対象レコードIDと更新後の値を記録します。
Googleの耐久性のあるAIエージェント例では、モデル呼び出しとツール実行を工程として永続化し、ワーカー停止後も完了済み処理を再実行せずに進める考え方が示されています。重要なのは製品名ではなく、完了した工程と副作用を分けて保存することです。
チェックポイントは細かすぎても管理負荷が増えます。検索一件ごとではなく、入力確定、下書き確定、外部書き込み完了、公開確認完了など、やり直し費用または二重実行リスクが変わる境界で残します。人の承認待ちも独立した状態にし、承認前の再開が送信を越えないようにします。
再開前にサーバー側の副作用を照合する
タイムアウトは失敗を意味するとは限りません。送信先が処理を終えた後、応答だけ届かなかった可能性があります。そのため再開時は、同じ要求をすぐ繰り返さず、外部操作ID、固有スラッグ、対象レコード、送信済み履歴をサーバー側で検索します。成功が確認できれば検証工程へ進み、存在しないと確定した場合だけ再実行します。
この照合を入れないと、投稿、請求書、顧客通知などの不可逆な操作ほど事故が大きくなります。既存のAI業務自動化の例外処理と組み合わせ、結果を成功・失敗の二択ではなく、成功確認済み、未実行確認済み、結果不明、手動確認待ちに分けます。
入力の版も照合します。停止中に顧客一覧や価格表が更新された場合、古いチェックポイントをそのまま再開すると、現在の条件と違う処理になります。入力ハッシュが変わっていたら、自動再開ではなく再計画へ戻すルールを置きます。
1本の無人業務で停止・再開テストを行う
最初の試験は、日次レポート作成のように元データを再取得でき、外部送信を下書きで止められる業務が向いています。工程を四つ程度に分け、二つ目の完了直後、外部書き込み直後、検証直前で意図的に停止します。再開後に、完了工程を繰り返さないか、成果物が重複しないか、次の工程から進むかを確認します。
見る指標は、完了率だけでは足りません。再開成功率、重複操作件数、手動確認へ回った件数、復旧時間、古い入力を検知した件数を記録します。3回連続で重複ゼロ、結果不明を正しく止められる、別担当者が状態記録だけで再開できることを合格条件にします。
長時間のAI業務を現場へ組み込む場合は、ラクボのAI顧問・期間限定AI部署で、対象業務の分解からチェックポイント設計まで支援できます。停止中の自動化を安全に直したい方は、長時間AIタスクの相談窓口をご利用ください。