shirokuronoir

AI決済を任せる前の5つの制御

AI決済を任せる前の5つの制御

AIエージェントが有料APIやコンテンツへ自動で支払える仕組みが、実験段階から本番運用へ進み始めました。しかし、判断をAIへ任せることと、支出上限までAIに決めさせることは別です。

AWSが一般提供を発表したAmazon Bedrock AgentCore paymentsと公式ドキュメントを確認し、実装前に固定すべき制御を整理しました。

先に結論

AIへ決済を任せる前に、予算上限、利用期限、重複実行の防止、人の承認境界、監査ログをモデルの外側で強制してください。

プロンプトに「使いすぎない」と書くだけでは止められません。支払い要求が妥当でも、インフラ側の上限、期限、権限に合わなければ決済処理へ進めない設計が必要です。

AWSの一次情報で確認したこと

AWS公式ブログ「Amazon Bedrock AgentCore payments is now generally available」は、AgentCore paymentsの一般提供と、支出ガードレール、決済オーケストレーション、運用監視を発表しています。

AgentCore paymentsの公式ドキュメントでは、支払いセッションに設定した上限を決済前に確認し、超過する要求を拒否する流れが示されています。許可された要求は外部ウォレット事業者で署名され、元の要求を支払い証明付きで再実行します。成功時は利用額を台帳へ確定し、失敗時は予約額を解放して失敗として記録します。

重要なのは、モデルがカード情報やウォレット認証情報を直接扱わないことです。認証、上限判定、署名、台帳更新をモデルの推論から分離することで、誤判断やプロンプト注入がそのまま送金権限にならないようにします。

今回試したこと

AWS環境や実際の決済は使わず、上限1,000、期限10時30分の架空セッションをPythonで再現しました。6件の固定要求を順に流し、要求ID、金額、時刻、判定、残額を記録しました。

  • 400の要求は許可され、残額は600
  • 続く700は上限超過で拒否
  • 最初と同じ要求IDは重複として扱い、再加算なし
  • 600は許可され、利用額は上限の1,000で停止
  • 残額ゼロでの1は拒否
  • 期限後の100は残額に関係なく拒否

最終利用額は1,000を超えませんでした。これは実サービスの性能検証ではなく、決済前に判定すべき条件と、監査ログへ残す項目を確認するための小さなテストです。

本番前に固定する5つの制御

1. 1回と1セッションの予算上限

セッション全体の上限だけでなく、1回当たりの上限も設けます。100のつもりが1,000になった場合、セッション上限だけでは最初の1回を止められません。上限判定はモデルではなく決済処理の直前で行います。

2. セッションの期限

依頼が終わっても支出権限が残る状態を避けます。開始時刻と期限を記録し、期限後の再試行は新しい承認なしに通さないようにします。

3. 要求IDによる重複防止

タイムアウト後の再試行や画面の二重操作で、同じ業務を2回成立させないための境界です。決済結果だけでなく、注文や予約の業務IDも一意にし、同じIDなら過去結果を返します。

4. 人へ戻す承認境界

新しい支払先、初回の商品、通常より高い金額、返金不能な取引は自動決済から外します。AIが止まった回数ではなく、危険な条件で正しく人へ戻せた割合を測ります。

5. モデル外の監査ログ

要求ID、セッションID、支払先、要求額、確定額、拒否理由、残額、時刻を残します。AWSの仕組みでは決済ライフサイクルをCloudWatchやX-Rayで追跡できます。AI自身の文章ログだけを監査証跡にしないことが重要です。

導入はこの順番にする

1. 実際には送金しないドライランで、許可・上限超過・期限切れ・重複の固定ケースを流す

2. 低い上限と限定した支払先で少額運用を始める

3. 拒否理由と人への引継ぎを毎日確認する

4. 失敗時に予約額が解放され、業務側の注文が重複しないことを確かめる

5. 実績が安定してから対象と予算を広げる

AI運用の計測項目は「複数AI運用で先に測る4つの指標」でも整理しています。決済では完了率と遅延に加え、拒否理由別の件数、支出速度、1業務当たりの確定額を追加してください。

判断基準

上限を超えないだけでは十分ではありません。重複注文が発生せず、期限後に権限が残らず、拒否理由を人が説明でき、返金不能な処理を自動化しないことまで確認できて初めて、本番へ広げられます。

出典

執筆・検証: しろのあ。一次情報、ローカルで確認した範囲、未検証の実サービス部分を分けて記載しています。