レスポンスの消失により、AIエージェントが二重課金を行ってしまう問題
AIエージェントがカード決済のためのツールを呼び出した際、ネットワークの問題でレスポンスが消失した場合、エージェントは不適切な挙動を示します。エージェント自身が気づかないうちに、顧客に二重課金を行ってしまうのです。
お金はすでに移動しています。しかし、エージェントには「ok」という返答が届きませんでした。すると、エージェントはあらゆるリトライループがそうであるように、再試行を行います。同じプロンプトと同じ引数を使用して再度実行するため、これが二重課金を引き起こします。
リトライは単なるネットワークイベントではありません。それは、すでに発生しているかもしれない「副作用」に関する意思決定なのです。
バックオフ（backoff）やジッター（jitter）のような標準的なリトライツールは、リトライの頻度を適切に調整するだけで、二重課金を防ぐことはできません。
必要なのは「べき等性台帳（idempotency ledger）」です。これは一意のキーを使用することで、あるアクションが最大で一度しか実行されないことを保証します。
ツール呼び出しが失敗するパターンは2つあります：
- リクエストが消失した：アクションは実行されていない。リトライは安全。
- レスポンスが消失した：アクションはすでに実行済み。リトライすると重複が発生する。
エージェントにとって、これら2つは区別がつきません。どちらもタイムアウトや接続断のように見えます。
決済、メール送信、返金などの副作用を伴うツールの場合、単純なリトライに頼ることはできません。必ず「べき等性キー（idempotency key）」を使用する必要があります。
解決策：
- ツールにタグを付ける：どのツールが不可逆的な副作用を持つかを特定します。
- 決定論的なキーを使用する：ワークフローID、ステップ、および引数に基づいて、安定したキーを作成します。これは、LLMが引数を変更してしまう前に行う必要があります。
- プロバイダーのキーを使用する：Stripeを使用している場合は、そのべき等性キーを渡します。課金を停止させるには、プロバイダー側がリピート（重複）を認識できる必要があります。
- 自社ツール用の台帳を構築する：自身で管理する副作用については、一意制約（unique constraint）を持つデータベーステーブルを使用します。これにより、再試行する前にシステムが結果を記録できるようになります。
「少なくとも1回（at-least-once）」と「正確に1回（exactly-once）」を混同しないでください。分散システムにおいて「正確に1回」を実現するには、「最大1回の配信（at-most-once delivery）」、「少なくとも1回のリトライ（at-least-once retries）」、そして「重複排除台帳（deduplication ledger）」を組み合わせる必要があります。
書き込み（write）を読み取り（read）と同じように扱わないでください。読み取りのリトライは無料ですが、書き込みのリトライはコスト（金銭的損失）がかかります。
出典: https://dev.to/0012303/your-ai-agent-will-double-charge-on-a-lost-response-5eed
学習コミュニティ（任意）: https://t.me/GyaanSetuAi