【ITニュース解説】Preventing double-purchases in agentic commerce — the retry-storm problem

システムエンジニアを目指す皆さんにとって、現代のシステム開発は様々な課題に直面しています。特に近年注目されている「エージェント型コマース」という分野で発生する「二重購入」の問題は、設計段階で考慮すべき重要なポイントです。この問題は、一見すると特定のプログラムのバグに見えるかもしれませんが、実はシステムの構造的な設計に起因するもので、その解決には新しい考え方が求められます。

エージェント型コマースとは、人間が直接操作するのではなく、AIなどの「エージェント」と呼ばれるソフトウェアが自律的に商品を探索し、購入手続きを行うような仕組みを指します。例えば、あなたの代わりに最適な航空券やホテルを自動で探し、予約まで済ませてくれるようなシステムを想像してみてください。このような便利なシステムで、最も一般的なトラブルの一つが「二重購入」です。エージェントが航空券を1枚購入したつもりが、なぜか2枚分の請求が来てしまうといった事態がこれに当たります。販売側は確かに2つの有効な注文を受け取り、エージェント側は1つの取引しか記録していない。しかし、購入者の明細には2つ分の支払いがある、という食い違いが生じます。

この問題は、個々のシステムコンポーネントが間違った動作をしているわけではありません。むしろ、それぞれが独立して見れば合理的な三つの設計判断が重なることで、予期せぬ結果として発生します。

一つ目の要因は「エージェントはリトライ（再試行）する」という設計です。ネットワークの接続不良、システムのタイムアウト、あるいはAIが一時的なエラーと誤認識する「幻覚」など、ツール呼び出し（ここでは購入手続きの依頼）は様々な理由で失敗することがあります。信頼性の高いエージェントを設計するためには、このような一時的な失敗に備え、処理が成功するまで何度も再試行するロジックが不可欠です。

二つ目の要因は「購入処理はデフォルトで非べき等である」という性質です。べき等とは、同じ操作を何度繰り返しても結果が常に同じになる性質を指します。例えば、データベースに特定の値を「設定する」操作は、何度実行しても最終的な値は同じなのでべき等です。しかし、商品を購入する操作は違います。ある商品を注文するリクエストを一度送れば一つの注文が生成されますが、全く同じリクエストを二度送れば、通常は二つ目の注文が生成されてしまいます。「これは同じ購入の意図による再試行だ」ということを区別する仕組みがなければ、システムは新しい購入だと認識してしまうのです。

三つ目の要因は「決済処理が非同期である」という点です。エージェントが販売システムに購入手続きを依頼し、販売システムが「注文を受け付けました」という応答を返したとしても、それが即座に決済が完了したことを意味するわけではありません。実際にお金が引き落とされたり、クレジットカードの承認が完了したりする「決済完了」には、通常時間がかかります。この「注文受理」から「決済完了」までのわずかな時間の間に、エージェントはまだ決済が進行中であることを知る術がありません。

これら三つの要因が組み合わさることで、二重購入が発生する「競合状態」が生まれます。エージェントが一度購入手続きを試み、販売システムは注文を受け付けたと返します。しかし、何らかの理由でその「注文受理」の応答がエージェントに届くのが遅れたり、通信経路で失われたりすることがあります。エージェントは「成功の応答がない」と判断し、本来の設計通り、もう一度同じ購入手続きを再試行します。この時、販売システムは最初の注文も、再試行による二度目の注文も、それぞれが有効な購入リクエストとして処理してしまい、結果的に二重購入が発生するのです。

この問題は、私たちが普段経験するクレジットカードの二重請求とは性質が異なります。一般的な二重請求は、支払い処理システムが誤って同じ決済要求を二度送信してしまったり、システムエラーで重複処理されたりする偶発的なバグが原因で発生します。その場合、カード会社や銀行に連絡すれば、重複した請求を取り消すことができます。しかし、エージェント型コマースの二重購入は「構造的」な問題です。エージェントは信頼性を高めるためにリトライするように設計されており、販売システムは有効な購入リクエストを正しく受け付けるように設計されており、決済システムは受け取った有効な決済要求を処理するように設計されています。それぞれのシステムが自身の役割の範囲内では正しく動作しているにもかかわらず、システム間の連携の「隙間」で問題が発生しているのです。具体的には、「エージェントが何を購入しようとしているのか」という「意図」をシステム全体で共有・記録する仕組みが不足していることが根本原因です。

この問題に対して、これまで様々な部分的な対策が試みられてきました。一つは「べき等キー」を使う方法です。これは、クライアント（注文する側）が、その購入が特定の意図に基づくものであることを示すユニークなキーを生成し、それをリクエストに含めて送信する方法です。サーバー（販売側）はこのキーを認識し、同じキーを持つリクエストが複数届いても、最初のものだけを処理し、二回目以降は無視することで二重購入を防ぎます。しかし、エージェントは必ずしも「同じ意図」に対して安定したユニークな識別子を常に生成できるとは限りません。セッションの再開やAIモデルのコンテキストリセットなどで、エージェントが以前のリクエストと同じ意図を認識できない場合があるため、この方法は完全な解決策にはなりえません。

他にも、Nonce（一度だけ有効な使い捨ての番号）ベースの認証や、支出の上限額を設定するといった対策があります。Nonceは二重決済を防ぐことには役立ちますが、販売者が決済承認前にすでに二つの注文を受け付けてしまっている「二重注文」自体を防ぐことはできません。支出限度額は、被害を最小限に抑えることはできますが、二重購入そのものを防ぐことはできません。また、エージェント内部でツール呼び出しの重複を検出して排除する仕組みも考えられますが、エージェントが再起動したり、処理が別のプロセスに移ったりすると、重複検出の機能が失われてしまいます。これらの対策は、問題の一部に対処しますが、「重複した購入をそもそも検出するための共通の記録」という最も重要な部分が欠けているのです。

本当に必要なのは、購入手続きを試みる前に生成され、エージェントと販売システムの双方が「これが真実の購入意図だ」と認識し、参照する「コミットメント識別子」です。これはべき等キーとは少し違います。べき等キーはクライアント側が生成し、サーバー側がそのキーに基づいて処理を判断します。しかしコミットメント識別子は、エージェントが購入を試みる前、販売者がリクエストを受け取る前、つまりどちらのシステムもまだ具体的な取引に「コミット（約束）」していない段階で、その購入の「意図」の一部として生成されるものです。

このコミットメントレコードには、エージェントが何を購入しようとしているのかという「具体的な意図」、エージェントが何をどの範囲で購入できるのかという「権限」、そして価格や納期、受入条件といった「取引条件」など、購入に関する全ての重要な情報が含まれます。そして、最も重要なのが、この購入意図をユニークに識別する「コミットメント識別子」です。エージェントが何らかの理由で再試行を行う場合、その再試行のリクエストには必ず同じコミットメント識別子が含まれます。これにより、販売システムは二回目のリクエストを受け取ったとき、それが新しい購入ではなく、最初の購入意図の再試行であることを認識できます。さらに、決済システムもこのコミットメント識別子を参照することで、二重の決済を防ぐことができます。なぜなら、個々の購入試行ではなく、この「コミットメント」こそが取引の真実の単位となるからです。

このような問題を解決するために、現在SAAXプロトコル（Solvent Applied Autonomous Exchange Protocol）という新しいプロトコルが開発されています。これは、様々なベンダーのシステムが連携して動作する自律型コマースにおいて、共通のコミットメントライフサイクルを提供するものです。SAAXプロトコルにおけるコミットメントには、ユニークなコミットメントID、その意図に対する権限参照、取引条件、そして取引の証拠となる情報や問題発生時の回復ポリシーなどが含まれます。エージェントが同じ意図で再試行する際には、同じコミットメントIDを参照することで、販売システム、エージェント、そして決済システムがすべて同じ「真実の記録」に基づいて動作できるようになります。このプロトコルの仕様は公開されており、開発者からのフィードバックも積極的に求められています。

エージェント型コマースは、私たちの生活をより便利にする可能性を秘めていますが、その実現にはこのようなシステム間の構造的な問題を解決する新しい設計アプローチが不可欠です。システムエンジニアを目指す皆さんにとって、これは単なるバグ修正ではなく、複数のシステムが連携する複雑な環境下で、いかに信頼性と整合性を保つかという、より深いシステム設計の課題として捉えるべきでしょう。