AIエージェントが再試行する前に証拠を必要とする理由

応答が失われても処理が重複しないようにする方法

1件の返金を実行する権限を与えられたサポートエージェントがリクエストを送信したものの、接続が切れたとします。エージェントは処理が成功したという確認を受け取れず、返金リクエストを再送します。最初のリクエストが成功していた場合、エージェントの再送によって2回目の返金が発生する可能性があります。

これはあくまで仮定上の例です。この例が示す問題は、モデルの精度を高めるだけでは解決できません。前回の操作によって環境の状態が変化したかどうかをエージェントが判断できない場合、どのような行動を取るべきでしょうか。

Unite.AIは、モデルにとどまらずエージェントの信頼性についても取り上げてきました。こうした議論では、復旧時の問題にも独自のルールが必要です。重大な影響を伴う操作を再度行う前に、エージェントは何が起きたかを確認するか、重複した効果が生じないという有効な保証を得るべきです。

応答が返らなくても失敗したとは限らない

応答が返らなくても、操作が失敗したとは限りません。実行前にエラーが発生したのか、確認応答がないまま操作が完了したのか、それとも処理が継続中なのかは、応答がないという事実だけでは判断できません。

これは分散システムでよくある問題であり、Amazonも説明しています。Amazonは、再試行の仕組みに副作用の重複を防ぐための具体的な保護策が必要な理由を解説しています。エージェントは、システムの復旧プロセスに新たな意思決定主体を加えます。エージェントは、エラーからの復旧方法について、さらに判断を下すことができます。

こうした判断によって、業務の進め方が変わる可能性があります。たとえば、金額を変えて返金を再試行することは、同じリクエストを単にもう一度実行するのとは異なります。同様に、最初の決済サービスから応答がなくなったときに別の決済サービスを選ぶことも、同じリクエストを単にもう一度実行するのとは異なります。

チームは、操作を実行する許可と、結果が不明な場合に復旧する許可を区別しなければなりません。最初に与えられた承認があるからといって、操作を再度実行しても安全だとは限りません。

最新の研究がリスクを測定

2026年9月のプレプリント「Where Does Exactly-Once Live?」では、LIMBOベンチマークが導入され、9つのモデルで25,930件のエピソードが検証されました。シミュレーション環境のサービスでは、確認応答の消失、処理の遅延、重複配信を発生させてテストが行われました。

著者らの主なテストで重複した効果が生じた1,279件のエピソードのうち、エージェントは90%で処理が正常に完了したと報告しました。つまり、処理に誤りがあっても、エージェントが成功を報告する可能性があります。

これらの結果は管理されたベンチマークに基づくものであり、本番環境における障害発生率を推定したものではありません。サービスはシミュレーションされており、いくつかの分析は探索的なものでした。チームは、エージェントの操作結果と、実行に成功したというエージェントの報告を分けて評価する必要があります。

この論文では、現在の状態を確認するだけでは不十分な理由についても取り上げています。処理中のリクエストは、確認が終わった後に反映される可能性があります。ステータス応答が空であっても、そのリクエストが最終的に反映されないという意味ではありません。

再試行では同じ意図を維持する

リクエストを受け取るサービスは、冪等性キーを使って、1つの操作に対する再試行を識別できます。この方法が適切にサポートされていれば、再試行によって追加の効果が生じないようにできます。すべての再試行で、冪等性キーを同じ値に保つ必要があります。

StripeのAPIドキュメントでは、冪等性キーの仕組みと制限の両方について例を示しています。API v1では、キーは少なくとも24時間が経過した後に削除されることがあります。削除済みのキーを再び使用すると、新しいリクエストとして処理されます。また、Stripeは、リクエスト元が指定したパラメーターが最初のリクエストのパラメーターと一致するかどうかも検証します。

冪等性を実務に取り入れるうえで重要なのは、プロンプトの中だけでなく、統合レイヤーで冪等性を確保することです。操作を送信する前に、承認済みの操作を記録してください。その識別子、正確なパラメーター、該当する場合はプロバイダーの参照情報、そして操作のステータスを保存します。

返金の場合は、承認と元の取引との関連付けに加え、プロバイダーから返された返金識別子があれば、それも保存してください。同額の返金が存在するかどうかを検索するだけでは、証拠としての確実性に欠けます。同額の正当なリクエストが2件存在する可能性があるためです。また、返金リクエストから検索結果に表示されるまで、時間がかかることもあります。最初のリクエストがまだ処理中である可能性もあります。

エージェントまたはワーカーが再起動した場合、実行レイヤーはその識別情報を保持する必要があります。同じ操作として送信された変更済みのリクエストは拒否する必要があります。このような変更は新たな操作にあたるため、ワークフローのルールに従って、新たに承認を判断する必要があります。

ツールの説明だけでは不十分

ツールの説明に加えて、リクエストを受け取るサービスの契約で冪等性がサポートされているか確認してください。実装をテストし、実際にどのような保証が得られるかを確かめましょう。

不確実な状態を運用上の状態として扱う

図1. 重大な影響を伴う操作に対する復旧プロセスの提案。再試行のたびに、現在も有効な承認が必要です。

完了が確認された場合、ワークフローは結果を記録し、その操作を繰り返さずに続行します。実行されていないことが確認された場合でも、元のリクエストが保留中ではなく、かつ承認が引き続き有効な場合に限り、再試行できます。

未解決の結果については、さらに多くの点を考慮する必要があります。重複した結果が生じないことをプロバイダーが有効に保証している場合は、同じキーを使って元のリクエストを再試行してもかまいません。そうでない場合は、書き込みを停止し、ステータスの照会、プロバイダーへの問い合わせ、または権限を持つオペレーターを通じて状況を確認してください。結論の出ない確認結果だけでは、再試行を承認する十分な理由になりません。

プロバイダーが処理と可視化に関する上限を文書化している場合も、一時停止は妥当な判断となり得ます。そうした上限がなければ、経過時間だけでその操作が実行されなかったとは確認できません。未解決のケースを誰が担当し、担当者がいつ確認する必要があるのかを定めておく必要があります。

失敗からの復旧には、別の業務プロセスが必要になる場合がある

返金は成功したものの、その後の顧客への通知に失敗した場合、ワークフロー全体を繰り返すと、返金まで再実行されるおそれがあります。復旧では、完了済みの作業の証拠を保持しながら、未完了のステップを完了させることに重点を置くべきです。

すでに完了した操作に対する是正措置が必要な場合は、Microsoftが補償トランザクションに関するガイダンスを提供しています。エラーをどのように補償するのが適切かは、各アプリケーションが判断します。補償によって必ずしも元の状態に戻せるとは限らず、補償そのものが失敗する可能性もあります。

さらに、トランザクションを取り消すと料金が発生する場合があります。メッセージを訂正しても、誰かが以前のバージョンを見ていないとは保証できません。そのため、復旧作業では、エージェントが取り消す、変更する、または確約できる内容を明確に制限する必要があります。こうした制限を超える判断は、必要な権限を持つ担当者に委ねなければなりません。

導入前に2回目の試行をテストする

影響の大きいツールを1つ選び、テスト環境で意図的に復旧テストを実施してください。実行が成功した後、元のリクエストへの応答を破棄します。最初のリクエストの実行を、ステータスを確認した後まで遅らせます。復旧中にワーカーを再起動します。キーの保持期間が切れるまで待ってから、再試行します。再試行の際に、パラメーターを1つ変更します。

ツールの応答だけに頼らず、業務記録の結果を評価してください。重複した処理、未解決の操作、未実施の作業、復旧に要した時間、追加の手動対応を記録します。トランザクションの取り消しや顧客への救済措置を含む、ワークフローの総コストを用いて、正しく完了したタスク1件あたりのコストを算出してください。

さらに、元のリクエストに似た、実際の2回目のリクエストもテストしてください。新たな作業を妨げることなく、システムが重複の発生を防げることを確認します。重複の回避と最終的なタスク完了は、それぞれ別に評価してください。そうしなければ、すべてのタスクを終了させるエージェントが、安全に見える一方で、ほとんど、あるいはまったく価値を提供していない可能性があります。

評価で問う内容は、明確に定める必要があります。システムは次の点を説明できましたか。

• どの操作が承認されていましたか？
• その結果を示す証拠は何でしたか？
• なぜ再試行が許可されていたのですか？

未解決の不確実性を理由に一時停止するエージェントは、デモでは効果が低いように見えるかもしれません。しかし本番環境では、一時停止することで、顧客が当初意図した内容を守れる場合があります。有用な粘り強さとは、承認されたタスクを完了しつつ、同じ操作をひそかに重複して実行しないことです。