- 公開日
AIに購入を代行させるときは、上限金額だけでなく、何を、誰から、誰の負担で、どの条件で買うかを承認対象にします。実行直前にその内容と現在の注文を照合し、変わっていれば止めます。応答が途切れた場合は注文と決済の状態を調べ、取消や返金は、それぞれの成立を確認するまで完了扱いにしません。
ここでは、一般的な物品購入の業務を扱います。AIが商品を選ぶ範囲、購入を決定する人の権限、決済サービスが実行できる処理を分けて考えます。特定の決済サービスの利用許可や、金融商品など別の規制が関わる取引を代行する許可を与える説明ではありません。
金額上限は注文内容と組み合わせる
「1万円以内で買って」という依頼では、金額を満たしていても商品、数量、販売店、配送先が意図と違う可能性があります。上限は使い過ぎを止める条件ですが、注文内容の確定に必要な情報を代わりに決めるものではありません。
承認時には、商品・型番・数量、販売者、税・送料・必須手数料を含む総額、通貨、配送方法・配送先、支払主体、支払方法、単発か継続課金かを提示します。取消料や返品できない条件など、購入判断に影響する制限も同じ場所で確認できるようにします。条件を読み取れない場合は「取消可」と補わず、未確認として購入を保留します。
OWASPのTransaction Authorization Cheat Sheetは、利用者が重要な取引内容を識別できる提示と、承認を実行内容へ結び付ける制御を勧めています。以下の購入項目や承認記録は、その考え方を備品購入へ適用する設計例です。すべての店舗に共通する法的な書式ではありません。
上限を注文一件に適用するのか、依頼全体に適用するのかも決めます。一件ずつ上限を守っても、同じ目的で何度も買えば合計は増えます。一回の依頼で許す注文数と合計予算を決め、未確定の注文がある間に別注文を作らないようにします。送料を商品代から除外したり、別の通貨へ単位だけを置き換えたりしないことも必要です。円の予算を外貨決済へ使うなら、換算時点や手数料、実際に負担する額をどこまで確定できるかを確認します。
支払主体と実行できる人を確認する
支払主体は、購入代金を負担する個人または組織です。購入を依頼した人、購入を承認する人、決済を実行するアカウントが同じとは限りません。会社の予算で買う予定なのに個人の保存済みカードが選ばれていれば、総額が正しくても実行条件は一致しません。
実行側では、対象の支払方法を使う権限、承認者の決裁範囲、販売者と注文内容を照合します。ログインできることや、画面にカードが表示されることだけを支払権限の証拠にしません。AIへ与える操作権限も、対象の購入に必要な範囲へ絞ります。これは、最小限の機能・権限と下流システムでの認可を勧めるOWASP LLM06:2025 Excessive Agencyに沿う考え方です。
確認画面では支払方法を識別できる名称などを使い、カード番号の全桁や認証情報を会話や一般ログへ残さない設計にします。追加認証が必要な場合は、その決済サービスの正規の手順に従います。業務上の「購入してよい」という承認と、カード決済でいうauthorization、つまり決済上の承認・与信に関わる処理も、同じ状態として記録しません。
架空の備品購入で承認内容を固定する
架空の部署で、担当者が「総務予算でUSBハブを2台、税込み・送料込み1万円以内で購入したい」と依頼した場面を考えます。以下の価格、販売者、取消条件、権限は説明用の仮定であり、実際の購入や決済は行っていません。
| 確定する項目 | 承認画面に表示する内容 |
|---|---|
| 注文対象 | 販売店A、USBハブH型を2台。他型番への代替なし |
| 総額と通貨 | 税込み単価4,000円×2台＋送料500円＝8,500円、JPY。ほかの必須料金なし |
| 支払条件 | 負担者は架空のA社、総務用の承認済み支払方法。単発購入 |
| 配送 | 通常配送、社内で確認済みの総務受取先 |
| 取消・返品 | 出荷前は店舗が取消を受け付けると仮定。出荷後の返品は条件未確認 |
| 承認を求める範囲 | 注文案Q-52の第1版による注文1回。1万円は依頼全体の予算上限 |
この例では承認者に、商品・支払条件に加え、出荷後の返品条件も確認してもらいます。判断に必要とされた返品条件が未確認の間は承認待ちにし、販売店の資料で確認して第2版へ反映します。この架空例では「出荷前の取消料なし、出荷後の自己都合返品不可」と確認できた設定にします。承認者は第2版の内容を読み、返品できない条件も踏まえて、権限の範囲内で購入可否を決めます。案の作成時点で条件が一部欠けていても、AIが勝手に「購入可能」と埋めません。
承認記録には、判断者、注文案の識別子と版、確定内容、許可した回数、有効期限、承認時刻を結び付けます。期限や例外許容のルールは業務側が決めるもので、AIが実行直前に都合よく広げません。記録から、上限内で選ぶ裁量まで許したのか、表示した注文だけを許したのかを読み取れるようにします。承認した版と実行内容を結び付ける考え方は、メール送信の宛先・本文・添付を扱うAIによるメール送信を安全に設計するでも説明しています。
ここでは8,500円の第2版を承認したと仮定します。実行前に送料が800円へ変われば、総額は8,800円です。1万円以内でも承認した総額とは違うため、この例のルールでは止めて差額300円を示し、更新した注文案の確認へ戻します。価格変更を許容する幅が別に定義されている業務では、その条件に従いますが、未定義の許容幅を推測してはいけません。
応答の有無と注文・決済の状態を分ける
購入操作は「実行した／していない」の二択だけでは管理できません。注文番号と決済の識別子を関連付け、状態を確認する対象を揃えます。次の表は、注文状態と決済状態を参照できる架空の連携を前提にした期待処理です。
| 状態 | 確認と次の処理 |
|---|---|
| 実行前 | 確定した注文案、権限、現在の総額・支払方法を照合。不一致や未確認は停止する |
| 実行中 | 元の要求と処理状態を追う。処理中の要求を別注文として追加しない |
| 成功確認 | 注文内容と決済結果を承認内容へ照合し、注文番号と確認済み状態を報告する |
| 失敗確認 | 失敗が確定した範囲と理由を確認。注文だけ残っていないかも調べて再開可否を判断する |
| 結果不明 | 同じ注文・決済を照会する。成功とも失敗とも断定せず、新規購入を保留する |
通信が切れたとき、支払処理が完了して応答だけが失われた可能性があります。この問題と重複要求の扱いは、AWSのMaking retries safe with idempotent APIsでも説明されています。冪等性とは、同じ要求を繰り返しても重複した効果を生じさせない性質です。ただし、識別子を付けるだけでどのAPIもその性質を持つわけではありません。対象サービスの同一要求の条件と保持期間を確認します。
例えばQ-52の決済で応答が途切れた場合、注文が受付済みで決済成功も確認できれば再購入せず結果を知らせます。決済処理中なら、サービスの指定する方法と頻度で確認を続けます。注文と決済の対応が分からなければ、金額だけで同じ取引と決めず、担当者へ引き継ぎます。「決済結果は未確認、追加購入は保留」と、確認できた範囲を報告します。
実装例として、StripeはPayment status updatesでPaymentIntentの状態確認とサーバー側のイベント監視を説明しています。クライアント側の画面表示だけで商品の提供処理を判断しない点も示しています。これはStripeの決済連携の説明であり、利用する店舗の注文成立や出荷まで自動的に確定する根拠ではありません。
取消の依頼を「すべて元に戻った」にしない
購入を取り消すときは、店舗への注文取消、決済の取消、確定した支払いへの返金を分けます。商品が未出荷でも決済済みの場合があり、決済を取り消せても店舗の出荷が止まったとは限りません。購入前のプレビューには、どの段階で何を取り消せるか、費用や残る影響を示しておきます。
StripeのCancel a PaymentIntentでは、取消できる状態に制限があります。Refund and cancel paymentsも取消と返金を区別し、返金が失敗する場合を説明しています。同じ文書では、成功した後のPaymentIntentは取り消せず、成功後の対応は返金になると説明されています。これらは2026年10月19日に確認した公式文書の範囲であり、支払方法や状態に依存します。店舗の返品条件や、取消料がないことを保証する資料ではありません。
Q-52を取り消す場面でも、まず元の注文と決済の状態を確認します。取消の承認は対象注文と費用に結び付け、購入承認だけで追加費用を伴う返品手配まで許可されたことにしません。店舗が「取消受付」と返した段階なら、そのまま記録し、出荷停止や決済の処理結果を待ちます。返金処理が始まっても、返金成功の確認とは分けます。
運用記録には、元の承認、注文・決済の識別子、照会結果、取消・返金の要求と状態、残る費用、次に確認する担当者を必要な範囲で残します。照会手段がない取引や、取消条件が判断に必要なのに読めない取引は、AIへ任せる範囲を候補選定までに絞ります。購入を完了できる経路だけでなく、不明な状態を止めて人へ戻せる経路が、代行範囲を決める条件になります。
外部へ影響する操作に承認を挟む基本は「外部へ影響するAIの操作に承認を挟む：承認ゲートの基本」で解説しています。
入札Agentの異常値と自動追随を上限と停止条件で抑える方法は「入札Agentの異常値と自動追随を上限と停止条件で抑える」で解説しています。
出典・参考資料
- OWASP Cheat Sheet Series「Transaction Authorization Cheat Sheet」（確認日：2026年10月12日）
- OWASP「LLM06:2025 Excessive Agency」（確認日：2026年10月11日）
- Malcolm Featonby「Making retries safe with idempotent APIs」（確認日：2026年10月12日）
- Stripe Docs「Payment status updates」（確認日：2026年10月19日）
- Stripe Docs「Cancel a PaymentIntent」（確認日：2026年10月19日）
- Stripe Docs「Refund and cancel payments」（確認日：2026年10月19日）
