AI自動化が同じ仕事を二度しないようにする方法: 再試行、重複防止、実行台帳

1. 概要: 本当のリスクは途中で止まったあとにもう一度動くときに生まれる

多くのAI自動化デモは初回実行だけを見せます。ボタンを押し、AIが仕事をし、結果が出るとデモは終わります。しかし実運用では、その後が大切です。顧客メールはすでに送られたのに画面がエラーで終わったらどうするのか。決済確認は成功したのにAIが確認応答を受け取れなかったら、もう一度送ってよいのか。ブログ公開がまだ反映中なのに、同じ記事をもう一度公開してよいのか。

クラウドや決済の公式ドキュメントが繰り返し示す教訓も同じです。一時的な失敗は再試行で解決することがあります。しかし、すでに業務上の行動が起きたか分からないまま再実行すると、メール二通、決済二回、投稿二重、レコード二重更新が起きます。

だから信頼できるAI自動化は、強いプロンプトだけでは作れません。同じ仕事を二度しない規則、失敗するほどゆっくり再試行する規則、人が引き継げる記録が必要です。開発者はこれをidempotency、backoff、run ledgerと呼びますが、運用者は重複防止、慎重な再試行、実行台帳と考えれば十分です。

2. 技術語を業務の言葉に直す

Retryは、失敗後にもう一度試すことです。ネット接続が一瞬切れた、外部サービスが少し混んでいた、という場合には役立ちます。ただし、すべての失敗を再試行してよいわけではありません。顧客、お金、公開、正式な記録に触れる仕事は、先に重複防止の規則が必要です。

重複防止、つまりidempotencyは、同じリクエストが二回来ても業務上の結果は一回だけにする性質です。行動ごとに注文番号を付けるイメージです。同じ番号が戻ってきたら、システムは同じ意図だと分かるべきです。

Backoffは、失敗が続くほど長く待つことです。Jitterは、多くの自動化が同じ瞬間に再試行しないよう時間を少しばらすことです。Cooldownは、失敗したツールに回復時間を与えることです。Dead-letter queueは、何度も失敗した仕事を人が見る棚に移すことです。Run ledgerは自動化の業務日誌です。

• 再試行: 一時的な失敗に対してもう一度試すこと。
• 重複防止: 同じメール、決済、投稿、記録変更を二度作らないこと。
• 慎重な再試行: 失敗するほど待ってから試すこと。
• 失敗棚: 無限に繰り返さず、人の確認へ移すこと。
• 実行台帳: 何が実行され、どこで止まり、誰が引き継ぐかを残すこと。

3. 根本理由: AIは不確実な状態でも実際に行動する

通常のチャット回答は間違っても外部世界を直接変えません。自動化は違います。メールを送り、ファイルを編集し、APIを呼び、レコードを更新し、費用を使い、投稿を公開し、次の仕事を予約します。agentが世界に触れた瞬間、主なリスクは幻覚だけではありません。重複実行、部分完了、古い状態、見えない失敗、コスト増幅が起きます。

これがretryとidempotencyが必要な根本理由です。失敗応答は、必ずしも操作失敗を意味しません。外部サービスはオブジェクトを作ったが確認応答だけ失われたかもしれません。ブラウザ自動化はsubmitを押したがスクリーンショット保存前に落ちたかもしれません。cronは再起動前に始まり、再起動後にもう一度始まったかもしれません。台帳がなければ、システムは記憶を失います。

信頼できる自動化は、不確実性を通常状態として扱います。retry前に失敗を分類します。副作用の前後を記録します。同じ意図には同じidempotency keyを使います。一時的でない失敗は早く止めます。お金、顧客信頼、法的判断、公開、戻しにくい状態変更は人に渡します。

4. 再試行してよい仕事と止めるべき仕事を先に分ける

実務では、失敗を五つに分けるだけでかなり安全になります。すぐ再試行できる失敗。入力を直してから再試行する失敗。しばらく待つ失敗。人が見るべき失敗。これ以上進めてはいけない失敗です。

接続が切れたなら再試行できることが多いです。顧客名が欠けているなら入力を直します。rate limitなら待ちます。決済がすでに成功した可能性があるなら人が確認します。権限のないファイルは、AIが十回試しても読めるようにはなりません。

AIは次の試行をもっともらしく説明できます。しかし、もっともらしい説明は安全規則ではありません。ワークフローには、いつ再試行し、いつ待ち、いつ止まり、いつ人に渡すかを先に書く必要があります。

• 一時的: 接続断、一時的なサーバーエラー、外部サービスの混雑。
• 先に修正: 顧客名不足、必須項目不足、ファイル形式エラー。
• 先に待つ: rate limit、メンテナンス、一時ロック。
• 人が確認: お金、顧客信頼、法的判断、公開、戻しにくい変更。
• 停止: 禁止操作、権限なし、業務ルール違反。

5. 重複防止は危険な行動を止めるブレーキ

Idempotencyは決済で理解しやすいですが、AI運用にもそのまま使えます。agentが「このオンボーディングメールを送って」と言うなら、システムは安定したaction idを付けるべきです。送信後にネットワークが切れた場合、retryは新しいメールを作るのではなく、同じaction idの結果を確認します。結果は「すでに送信済み」または元の結果であるべきで、二通目ではありません。

Stripeは、同じ決済系の操作を二回作らないためにidempotency keyを使う方法を説明しています。AWSはclient request identifierという似た考え方を説明します。言葉は違っても、教訓は同じです。同じ意図のリクエストかどうかを見分けられる必要があります。

小さな会社なら、こう始められます。読むだけの仕事は多くの場合再試行できます。状態を変える仕事にはaction id、つまり行動番号が必要です。費用のかかるlive作業にはbudgetとcooldownが必要です。公開や顧客向け作業にはapprovalまたはrollback経路が必要です。お金が動く作業には重複防止番号と照合記録が必要です。

6. 失敗するほどゆっくり再試行すれば、小さな障害が大きくなりにくい

再試行はシステムを安定させますが、雑に使うと障害を大きくします。外部サービスがすでに苦しい時に、すべてのAIワークフローがすぐ再試行すると、そのサービスは一番悪いタイミングでさらに仕事を受けます。

だから失敗した仕事はゆっくり再試行する必要があります。何度も失敗したら長く待ちます。多くの作業が同じ瞬間に再試行しないようにします。失敗し続けるツールはしばらく休ませます。一定回数を超えたら自動化を止めてレビューに渡します。

例えば、調査自動化は検索制限がかかったら止まるべきです。公開自動化はデプロイが遅い間に同じ記事を再公開してはいけません。scraping自動化はサイト構造が変わったら、同じサイトを叩き続けるのではなく確認に移るべきです。

7. 実行台帳: 自動化がどこで止まったかを示す業務日誌

実行台帳は、AI自動化で最も軽視されがちな部品です。派手ではありませんが、「AIが何かした」と「何が起きたか分かっている」の差を作ります。非エンジニアには、自動化の業務日誌と考えると分かりやすいです。

最小限の台帳は単純です。いつ実行されたか、なぜ実行されたか、何をしようとしたか、何回試したか、成功したか、どこで止まったか、誰が引き継ぐか。開発チームはここにrun id、input hash、idempotency keyを追加できます。

この台帳があると、同じ失敗が繰り返されたときに仕組みを直せます。答えは「AIがまた失敗した」ではありません。「チェックリストを直す」「承認ステップを追加する」「SOPを明確にする」「自動化範囲を小さくする」です。

• いつ実行されたか。
• 何をしようとしたか。
• 何回試したか。
• 成功、失敗、曖昧な状態のどれか。
• 結果や証拠はどこにあるか。
• 誰が引き継ぐか。
• 同じ失敗を減らすために何を変えるか。

8. 実プロジェクトではどう見えるか

ブログ公開自動化は分かりやすい例です。記事ファイルが作られただけでは終わりません。画像があるか、三言語ページが開くか、ブログ一覧に出るか、sitemapに入ったか、本番URLが200で返るかを確認します。これが公開の実行台帳です。

市場スキャンでも同じです。キャッシュされた価格を読むだけなら再試行しやすいです。しかし注文、顧客通知、決済、公開レポートは同じ種類の行動ではありません。外部に影響するステップには、自律性の前に重複防止が必要です。

GUILDEXにも同じ考え方が必要です。顧客に見えるワークフローは、よい下書きを作るだけで終わってはいけません。どの情報源を使ったか、どの顧客文脈に触れたか、人の承認が必要か、重複をどう防ぐか、結果をどこに記録するかを説明できる必要があります。

9. AIが進化するほど、人も一緒に進化すべき理由

AIがよくなるほど、人の役割は消えません。上に移動します。人がすべての反復作業を入力する必要は減りますが、AIに何を任せるか、どこで止めるか、どんな証拠を残すか、どの行動は人が承認するかを決める力はより重要になります。

弱いAI導入は「agentに任せよう」で終わります。強いAI導入は、「目標はこれ、信頼する情報源はこれ、重複防止規則はこれ、承認境界はここ、実行台帳はここ、失敗からこう学ぶ」まで言います。それは人の仕事が消えるという意味ではありません。人の仕事がより価値あるものになるという意味です。

次の実践は単純です。繰り返しワークフローを一つ選び、さらなる自律性を与える前に実行台帳を付けます。次に一度だけ起きるべき行動へ重複防止番号を付けます。次に、いつ再試行し、いつ止めるかを決めます。この流れが見えると、AI自動化は幸運なプロンプトではなく、改善される業務システムになります。

10. AIワークフローを自律化する前に聞く7つの質問

この記事の技術語をすべて覚える必要はありません。下の質問に答えられれば、その自動化は信頼しやすくなっています。答えられない項目があるなら、完全自動化の前に人のレビューを残すべきです。

• この自動化が同じ仕事を二度したら、何が困るか。
• 成功したか失敗したか曖昧なとき、どう確認するか。
• 再試行して安全なステップと危険なステップは何か。
• 何回失敗したら止めて人に渡すか。
• 実行台帳はどこにあるか。
• 顧客、お金、契約、公開に触れる前に承認があるか。
• 同じ失敗が繰り返されたら、どのSOPやチェックリストを変えるか。