AIエージェントが二度実行したら。再試行でも業務を重複させない設計

AIエージェントの二重実行を防ぐには、失敗らしい応答だけで注文を送り直さず、同じ業務上の意図に同じ実行IDを使います。そのIDにひもづく処理結果を照合してから、再送してよい状態かを決めます。

注文を送信済みか分からないなら、原則は止めます。ただし「同じ実行ID・同じ内容なら結果が再利用される」という接続先の契約を確認でき、結果照会または安全な再送ができる場合だけ、自動処理を続けられます。難しいのは、この原則を実装可能な状態遷移へ落とすことです。

AIエージェントの二重実行は「失敗」と「不明」を分ける

注文登録APIがタイムアウトしたとします。AIエージェントから見えるのは「応答を受け取れなかった」という事実だけです。注文作成が失敗したとは限りません。接続先では作成を終え、応答だけが戻らなかった可能性も残ります。

このとき新しい要求として送り直せば、同じ注文が増えるおそれがあります。すべてのタイムアウトを放置する運用では、実行されていない注文まで止まります。そこで成功・失敗の二択に「不明」を加え、結果を確定できない状態を独立して扱います。

AWSの公式解説も、作成要求への応答が得られない場合は処理済みか否かが分からず、実際の状態との照合が必要になると説明しています（2026年9月21日確認）。したがって、通信エラーをそのまま業務失敗へ読み替えてはいけません。

ここでいう冪等性は、同じ意図を再送しても、注文が二つになるなど業務上の効果を増やさない性質です。「何度呼んでも無条件に成功すること」を意味せず、入力が誤っていれば同じ失敗結果を返す設計もあり得ます。

一つの実行台帳に何を結ぶか

注文登録では、AIエージェントの会話履歴だけに実行済みの印を残しても足りません。実務上は、少なくとも次の情報を一つの実行台帳で関連付けます。

• 実行ID：一つの注文意図を識別する値
• 要求内容の照合用情報：同じIDで内容が変わっていないかを判定する情報
• 状態：未実行、処理中、不明、完了、失敗など
• 結果：作成された注文ID、または確定した失敗結果

この台帳が次の処理を許可する制御面になります。同じ実行IDで内容が違えば実行せず、完了済みなら保存結果を返し、処理中なら新しい注文を作らない、という判断に使うため、参照するだけのログとは役割が異なります。

もう一つ重要なのが記録の境界です。実行IDだけ確保して注文が作られない状態と、注文だけ作成されて実行IDを残せない状態は、どちらも再試行の判断を壊します。AWSの公式解説では、呼出元が一意なリクエストIDを渡し、IDの記録と業務を変更する操作を原子的に扱う必要性が示されています（2026年9月21日確認）。

自社のデータベース内で注文を作るなら、実行台帳の確保と注文作成を同じ確定単位に含められるかを検討します。外部APIへの送信は、自社の処理だけで確定単位を閉じられません。接続先の冪等キー、結果照会、後続イベントのいずれで結果を照合できるかを先に確認します。この構成は公式情報を注文登録へ適用した実務上の設計提案です。実際の保証範囲は製品ごとの公式仕様に従います。

状態遷移と判断表で再送可否を決める

中心に置く遷移は、未実行 → 処理中 → 完了に結果不明時の経路を加えたものです。応答を確認できなければ処理中 → 不明へ移し、注文IDや後続イベントとの照合によって完了または未実行確認済みへ進めます。照合しても決められなければ手動確認へ送り、自動再送はしません。

表では「業務上の効果が発生していないと確定できるか」を分岐点にします。エラーの名称だけでは、注文の有無を判定できないためです。不明のまま別の実行IDを発行すると、接続先からは別注文に見えます。新しいIDを再送の逃げ道にしてはいけません。

公式仕様から読み取れること、設計側で決めること

Stripeの冪等リクエスト仕様では、冪等キーごとに最初の要求のステータスコードと本文を保存し、同じキーの後続要求へ同じ結果を返します。同じキーで元と異なるパラメータを送るとエラーになります（2026年9月21日確認）。これは「実行IDと要求内容を照合し、完了済みなら保存結果を返す」という判断の具体例です。

同じ公式仕様では、入力検証の失敗や同時実行中の要求との競合によりエンドポイントの実行が始まらなかった場合、結果を保存せず再試行できると説明されています（2026年9月21日確認）。ここから、注文登録でも「実行開始前の失敗」と「開始後の結果不明」を分ける必要があると判断できます。

これらはStripeの公式仕様であり、保存方法、エラー分類、再試行条件は接続先APIごとに異なります。導入時には対象APIの公式契約を確認し、少なくとも次の問いに答えられる状態にします。

• 同じ実行IDと同じ要求を再送したとき、業務効果は増えないか
• 実行IDに対する結果を照会できるか
• 同じ実行IDで要求内容が変わった場合、拒否されるか
• どの応答なら「実行開始前」と確定できるか
• 結果不明時に、注文IDや後続イベントで照合できるか

一つでも答えが曖昧なら、自動再送を前提にしません。仕様で保証されない振る舞いを、AIエージェントの推測で埋めないためです。

「送信済みか不明」を止める条件

ネットワーク障害では、要求がサーバーへ届いたか判断できません。Stripeの高度なエラー処理は、この場合、確定した結果を受け取れるまで同じ冪等キーかつ同じパラメータで再試行するよう説明しています。また、サーバーエラーを不確定な結果として扱い、新しい冪等キーでの再試行を推奨せず、後続イベントとローカルIDを照合する方法を示しています（いずれも2026年9月21日確認）。

注文登録へ適用するなら、自動処理を継続してよいのは、同じ実行IDと同じ内容による再送が接続先の公式契約で安全と確認できる場合です。結果照会で注文IDを得られるなら、再送より照会を先にします。後続イベントしかないなら、実行IDと照合可能な識別情報を事前に結びます。

契約がない場合、または照合後も結果を確定できない場合は、状態を不明のまま固定して手動確認へ送ります。担当者には、接続先の注文を検索し、該当する注文の有無を確定してから台帳状態を更新できる手段が必要です。「再送」ボタンだけでは解決になりません。確認できない限り新しい注文を許可しない制約が、最後の重複防止になります。

新しい実行IDを発行してよい条件

新しい実行IDを発行するのは、元の処理が始まっていないと確認でき、修正後の要求を別の意図として実行するときに限ります。たとえば、実行開始前の入力検証で拒否され、注文が作られていないことが契約上明らかで、内容を修正して登録する場合です。

同じ実行IDのまま注文内容を変えてはいけません。元の要求との照合ができなくなるからです。結果が不明なまま新しいIDで同じ内容を送るのも避けます。別の要求として受理され、二重注文になる余地を自ら作るためです。

この判断は、実行台帳とAPI呼び出し層の制約として実装します。プロンプト上の指示は補助にとどめ、AIが注文登録を提案しても、台帳が不明または処理中なら呼び出しを拒否する形です。AI導入全体の責任分界や実装の進め方は、AI導入を構想から定着まで進める実践ガイドで整理できます。検証段階の動作確認を本番運用の制御へつなげる観点は、AI PoCを本番運用へ移すための設計も参考になります。

注文登録の可否は、最終的に次の順序で決めます。実行IDで台帳を引く。要求内容が同じかを照合する。完了なら保存結果を返す。処理中なら待つ。不明なら下流の結果を照合する。未実行を確認でき、同じIDでの再送契約がある場合だけ再送する。確定できなければ止める。この順序なら、AIエージェントが再試行を選んでも、業務の二重実行は状態遷移の側で防げます。

FDE・AI実装ガイドへ戻る