J.A.R.V.I.S.計画 第四十二話
AIエージェントの定期実行を二重処理させない｜cron・予約・再試行を安全に運用する7項目
定期実行は「止まらない」ことより、同じ作業を二度入れないことを保証する設計が大切です。
1. 二重処理が起きるのはなぜ
cron・予約・API再試行は、状況によって「未完了」を誤認し、同じ処理を再起動させます。
1回目が成功したのに送達状態が未確定のままだと、2回目が二重処理として実行されやすいです。
特に、送信・通知・請求・ファイル更新を複数経路で扱う運用では、完了判定が不一致になりやすいので、状態定義を一貫させる必要があります。
重要なのは「再試行の有無」より「再実行を必要としない判定」が先に揃っているかです。
2. 二重処理防止の7項目
| 項目 | 確認ポイント | 実務設計 |
|---|---|---|
| 1. 実行ID | 対象・日時・ジョブ種別で一意化 | 重複時はスキップ |
| 2. 排他ロック | 実行開始前にロック確保 | ロック未取得時は終了 |
| 3. 送達未確定判定 | 外部送信の可否を明確化 | 未確定は次工程へ進まない |
| 4. 再試行条件分離 | 失敗種類ごとに再試行を分離 | 一括再送を禁止 |
| 5. ログ台帳 | 成功／失敗／未確定を1行記録 | 再開可否の根拠を保持 |
| 6. 人間承認点 | 影響の大きい更新は手動承認 | 最終判断は担当者が責任 |
| 7. 監査回収 | 処理済み履歴を保存 | 再発防止に反映 |
3. 業務別に「同じ処理」を決める
「同じ処理」とは、システムごとに同じ意味ではありません。請求、ファイル更新、予約送信、通知は対象と責任が異なるため、重複キーも別に設計します。
- メール: 宛先・件名・本文ハッシュで重複を判定
- 予約: 対象ID・時間帯・回数で再実行条件を分離
- 請求更新: 対象月・取引先・ステータスで幹線と確認履歴を分ける
- ファイル更新: 生成名・差分・更新者で「処理済み」状態を残す
実務側では、情報を扱う範囲と保存先のルールを最初に定義することで、再開時の判定ミスを減らせます。
4. 異常終了後は一件ずつで再開する
失敗時は一気にまとめて再試行せず、未実行・未完了・送達未確定に分け、1件ずつ検証しながら再開します。未確定は監査付きで保留し、確認できたものだけを次に進めます。
再開は「読み取り可能性」を取り戻してから。read-back前提、変更前バックアップ、最小適用、切戻し条件を同時に成立させます。
5. AI特命室で小さく始める
既存運用を壊さず、まずは「1工程ずつ」導入するのが安全です。
既に公開手順・承認ルートがある環境では、cron設定、予約、再試行、通知を一本化し、AI特命室へ接続すると効果が出やすくなります。
ニリアコットAI特命室では、定期実行の重複を防ぐための実務設計として、実行ID・ロック・監査台帳・人間承認点を標準化しています。
30分AI業務診断で進める導入手順
業務対象を絞り、まずは二重処理が起きやすい1工程から再開基準を作って安全に始めます。社内の既存帳票に合わせて最短の運用設計が可能です。
