あなたの決済スタックは `checkout.create()` で壊れる — なぜエージェントは支払えないのか

Dev.to / 2026/3/30

💬 オピニオンDeveloper Stack & InfrastructureIdeas & Deep AnalysisTools & Practical Usage

共有:

要点

自律型エージェントは、リダイレクト後に人がアクションを確認し、3DS2/OTPのチャレンジを完了することに決済のチェックアウトフローが依存している場合、購入を完了できません。
この記事では、現代の決済インフラは本質的に「人間を介した（human-in-the-loop）」状態機械として設計されているため、エージェント主導のフローが停止するのは資金やAPIの制限のせいではなく、必要なユーザー操作ステップが欠けているからだと主張しています。
具体例として、GPT-4搭載の旅行予約エージェントがStripe Checkoutに到達したものの、チェックアウトセッションが（約24分で）期限切れになり予約がキャンセルされてブロックされる様子が示されます。
本質的なポイントは、エージェント型システムは、手動のカード/OTP入力を前提とするのではなく、チャレンジや承認をプログラム的に処理できる、またはサポートされた委任によって扱える決済パターンが必要だということです。
著者は、これは稀な例外ではなく、2024年の決済アーキテクチャやコンプライアンス層における一般的なデフォルトの振る舞いだと述べています。

# これは失敗します。静かに。毎回。
agent = CrewAI.Agent(role="travel_booker")
booking = agent.book_flight(route="SFO->JFK", date="2024-06-15")
# エージェントはStripeのチェックアウトに到達し、リダイレクトを待つ
# セッションの有効期限は24分
# 予約はキャンセルされる。人が戻ってくる。

このパターンが先月の本番デプロイを壊すのを見ました。自律型の旅行エージェント――GPT-4搭載、判断のレイテンシは200ms未満、可用性APIのパースは完璧――が、支払いで停止してしまったのです。不足資金だからではありません。API制限だからでもありません。チェックアウトのフローが「人が『Confirm』をクリックし、3DS2でリダイレクトされ、スマホからOTPを貼り付ける」ことを前提としていたからです。

そのエージェントには運用予算として10,000ドルがありました。340ドルを使えなかったのです。

これは例外ではありません。2024年の支払いにおけるデフォルト状態です。すべてのゲートウェイ、すべてのプロセッサ、すべてのコンプライアンス層が、単純な前提のもとに設計されていました――意識のある人間がループに入っている。そしてその前提が、いまボトルネックになっています。

あなたの決済インフラに開いた「人の形をした穴」

現代の決済システムは、中断を前提にした状態機械です：

Stripeの標準フロー：

チェックアウトセッションを作成（サーバー側）
ユーザーをホストされたページへリダイレクト
ユーザーがカード情報を入力
3DS2チャレンジ（SMS/アプリ通知）
ユーザーが承認
アプリケーションへリダイレクト
Webhookが完了を確認

ステップ2、4、5は人の存在を必要とします。エージェントは「リダイレクト」できません。保持すべきブラウザセッションがないからです。SMSを受け取れませんし、銀行アプリで「承認」をタップすることもできません。

単にリトライループで包むことはできません。セッションは期限切れになります。支払いインテントが古くなります。Stripeは（正しく）放棄されたものとみなし、ホールドをキャンセルします。

APIキーでの回避策も機能しません：

// うまくいきそうに見えます？
const payment = await stripe.paymentIntents.create({
  amount: 34000,
  currency: 'usd',
  payment_method: agent.saved_payment_method,
  confirm: true,
  automatic_payment_methods: { enabled: true }
});
// ❌ 例外：authentication_required
// 3DS2の要請が発動。ヘッドレスによる完了ルートはない。

保存済みの決済手段があっても、欧州および英国の強力な顧客認証（SCA）ルールでは、多くの取引タイプでインタラクティブな検証が必須です。決済サービス指令は、自律ソフトウェアを念頭に書かれていませんでした。

具体的に何が壊れるのか

1. 身元確認は、生体情報または知識要因を前提としている

エージェントは自撮りを撮れません。母親の旧姓を覚えていられません。デジタルIDの枠組み（OAuth、OIDC、WebAuthn）はすべて、「人が実際に存在することを証明する」段階でボトルネックになります。

2. レート制限は、濫用防止のために設計されていて、オートメーションのためではない

ほとんどの決済APIは、リクエストを100/秒に上限設定しています。500個の同時マイクロトランザクションを調整するエージェントの群れは、すぐにこの壁に当たります。レート制限は、人間のチェックアウト行動ではなく、プログラムによるワークフローを想定して調整されていません。

3. コンプライアンスのツールは、人間でないパターンを詐欺としてフラグ付けする

完全に正当なエージェントの挙動――同じIP、ミリ秒単位で正確な間隔、同一のユーザーエージェント文字列――は、カード詐欺の検出のために設計されたあらゆるヒューリスティックを引き起こします。あなたのエージェントは、整いすぎているためにブロックされます。

4. Webhookによる確認が遅すぎる

StripeのWebhookはP95レイテンシが約2〜3秒です。エージェントが複数ステップのワークフローを実行する（APIアクセスの支払い → API呼び出し → 結果を処理 → 次のステップの支払い）場合、この遅延は積み重なります。10ステップのワークフローでは、支払い確認を待つだけで20〜30秒のデッドタイムが発生します。

インフラはひどく設計されたわけではありません。別のアクター向けに設計されていたのです。エージェントは、人間のようにスループットが高い存在ではありません。支払い主体として別のカテゴリです。

エージェントが実際に必要とするアーキテクチャ

重要な技術プリミティブは3つです：

1. MPCウォレット（カストディアルでも、EOAでもない）

素朴な解決策は共有ウォレットです。つまり、エージェントにEthereumアドレスの秘密鍵を渡し、トランザクションに署名させる。これは2つの理由で致命的です：

露出：鍵はどこかのメモリ上に存在します。もしエージェントの実行環境が侵害された場合（プロンプトインジェクション、依存関係の混同、あるいはただの不適切なnpm install）、攻撃者は取り返しのつかない署名権限を得ます。
帰属：複数のエージェントが同じ鍵を共有すると、トランザクション単位の説明責任がなくなります。どのエージェントが5,000ドルの支払いを承認したのでしょうか？ログは嘘をつけます。オンチェーンデータだけでは意図を切り分けできません。

カストディアルウォレット（Coinbase、Fireblocks）は露出問題を解決しますが、再び「人間がループに入る」問題を持ち込みます。すべてのトランザクションで、署名するかどうかを判断する第三者へのAPI呼び出しが必要になります。鍵管理を外部に任せたものの、承認のレイテンシは残ったままです。

MPC（マルチパーティ計算）ウォレットは、その折衷案です：

署名には、2-of-3のキーストアの保有者が協力する必要があります：

エージェント実行環境 がキーストア1を保持
AgentWallexインフラ がキーストア2を保持
リカバリーサービス（コールドストレージ）がキーストア3を保持

返却形式: {"translated": "翻訳されたHTML"}

エージェントは外部の承認なしでトランザクションを開始し完了できます（keyshares 1+2）。ただし、どちらの当事者も単独では署名できません。エージェントが侵害されると、攻撃者は1つのキーシェアを入手しますが、2つ目がないため役に立ちません。AgentWallexがダウンした場合でも、keyshares 1+3を使って資金を復旧できます。

これはしきい値暗号であり、目新しいものではありません。新しいのは、それをエージェントごとのウォレットに、大規模に適用することです。私たちのMPC実装（Paratro経由）は、各エージェントに対して<300msで一意の2-of-3セットアップをプロビジョニングします。HSMのプロビジョニングなし。手作業の鍵セレモニーなし。

トレードオフ: MPC署名は、生の秘密鍵署名より遅いです（150ms対<10ms）。1時間あたり1,000件の支払いを行うエージェントでは、その影響はごくわずかです。HFTボットにとっては失格です。レイテンシ予算を把握してください。

2. x402: HTTPステータスコードを支払いレールとして

最もシンプルなエージェントの支払いUXはUXがないことです。エージェントがAPIを呼びます。支払いが必要なら支払います。支払いが成功すれば応答を受け取ります。往復1回です。

入ってきたのはHTTP 402 Payment Required。このステータスコードは1997年以来予約されていますが、標準化はされていませんでした。これまで。

仕組み:

GET /api/v1/analyze-image HTTP/1.1
Host: vision-api.example.com
Authorization: Bearer agent_token_xyz

HTTP/1.1 402 Payment Required
Accept-Payment: x402-wallet, amount=0.05, currency=USDC, recipient=0x1234...

APIは402で応答し、ヘッダーに支払いパラメータを含めます。エージェントのHTTPクライアント（AgentWallex SDKで計測・拡張済み）がこれを横取りします:

from agentwallex import WalletClient

wallet = WalletClient(
    agent_id="travel_agent_01",
    policy={
        "max_transaction": 10.0,
        "allowed_recipients": ["0x1234...", "0x5678..."],
        "daily_limit": 500.0
    }
)

# エージェントが通常のHTTPリクエストを行う
response = wallet.authorized_request(
    method="GET",
    url="https://vision-api.example.com/api/v1/analyze-image",
    data={"image_url": "https://..."}
)

# SDKが402を横取りし、支払いを承認して、リクエストを再試行する
# すべて<150ms、手動の承認なし
print(response.json())  # 実際のAPIレスポンス

裏側で：

SDKがAccept-Paymentヘッダーを読み取る
ポリシーに対してトランザクションをチェックする（金額、受取人、レート制限）
MPCトランザクションに署名する（keyshares 1+2）
オンチェーンで支払いを送信する（Base上のUSDC）
Payment-Receiptヘッダー付きで元のリクエストを再試行する
APIがレシートを検証し、応答を返す

これは、統合コストゼロの従量課金（pay-per-call）です。 API提供者は私たちのマーチャントSDKを投入します。エージェント開発者は私たちのペイヤーSDKを投入します。プロトコルはHTTPです。カスタムのスマートコントラクトはありません。管理が必要なオフチェーンの支払いチャネルもありません。

レイテンシ分解（P95）:

ポリシーチェック: 8ms（ローカル）
MPC署名: 140ms（ネットワーク＋計算）
オンチェーン決済: 2s（Baseのブロック時間）
レシート検証: 12ms（Merkle証明の検証）

合計: 約2.2秒。Stripeのウェブフックより高速です。オンチェーンの最終確定。

3. ポリシーエンジン: 承認キューではなく、プログラマブルな制約

エージェントには支出の自由は不要です。必要なのは制限された自律性です。目的は監督をなくすことではなく、レイテンシをなくすことです。

ポリシーはMPC署名の前に実行されるコードです:

policy = {
    # シンプルな上限
    "max_transaction_usdc": 50.0,
    "daily_spending_limit": 1000.0,

    # アロウリスト（任意のアドレスへの支払いを防止）
    "allowed_recipients": [
        "0x1234...",  # OpenAI API
        "0x5678...",  # Pinecone
    ],

    # レート制限（暴走ループを防止）
    "max_transactions_per_hour": 100,

    # 条件付きルール
    "require_human_approval_above": 500.0,

    # 時間ベースの制限
    "active_hours": "09:00-17:00 UTC",
}

すべての支払いリクエストは、このエンジンにMPC署名の前に当たります。いずれかのルールが失敗したら、そのトランザクションは中止されます。資金は移動しません。オンチェーンの痕跡も残りません。

サンドボックスからの実際のユースケース:

返却形式: {"translated": "翻訳されたHTML"}

あるドキュメント処理エージェントが、請求書をOCRするためにビジョンAPI（x402）に支払いを行っていました。不正な形式のPDFが1つあるせいで無限リトライループが発生—エージェントは、500エラーが出るたびに「もう一度やり直せ」という意味だと思い込み、APIを呼び続けてしまったのです。

ポリシーエンジンがなければ、ウォレット残高が削り取られていたでしょう。max_transactions_per_hour: 100 を設定していたので、エージェントは失敗した試行100回の後にレート制限に到達しました。総損失：$5（$5,000ではなく）。人間のオペレーターにはSlackのアラートが届き、PDFパーサーを修正し、ポリシーをリセットしました。

競合が見落としている洞察： Catena と Skyfire はウォレットを作っています。Turnkey は鍵管理を作っています。私たちは 制約レイヤー を作っています。ウォレットはインフラです。ポリシーがプロダクトです。

The Landscape (And What's Still Missing)

Catena Labs（a16zから$18M）：OAuthのようなフローを備えたウォレット・アズ・ア・サービス。開発者体験に強い一方で、高額取引では依然として人間の承認が必要です。x402ネイティブではありません。利便性のためにレイテンシー最適化されており、エージェントの自律性には最適化されていません。

Skyfire（$9.5M）：エージェント向けのステーブルコイン・ウォレットに注力。優れた基礎機能ですが、ポリシーエンジンがありません—支出制御を構築するのはあなたの責任です。さらにx402ネイティブでもなく、支払いは手動のSDK呼び出しです。

Crossmint：NFT/web3の支払いで、エージェント・ウォレットへ方針転換。フィアットのオンランプが強みですが、アーキテクチャはカストディ（彼らが鍵を保持）です。コンプライアンス重視、レイテンシー後回し。

Coinbase AgentKit：Base上のウォレットSDK。低レベルで柔軟ですが、ポリシーロジック、MPCセットアップ、x402統合を自分で構築する必要があります。インフラチームがあるなら大きな強みですが、LangChainアプリを出荷するだけなら過剰です。

まだ誰も解決できていないこと：

クロスチェーンのマイクロペイメント：現状、私たちはUSDCをBase上でのみ扱っています。エージェントはEthereumのAPI、SolanaのAPI、さらには従来型のカードベースAPIにも支払う必要があります。決済レイヤーがこれを抽象化する必要があります。
インテント（意図）ベースの支払い：いまのところ、ポリシーは静的なルールです。これからは、エージェントの意図を読み取るポリシーへ。たとえば「$500未満で航空券を予約しようとしている」は、構成ファイルを人間が更新することを要求するのではなく、支出制限を動的に調整すべきです。
評判/クレジットシステム：実績のあるエージェントは、より高い上限と、より低い担保要件を得るべきです。これは分散型のアイデンティティレイヤー（DID？アテステーション？）と、非人間の主体向けのクレジットスコアリングモデルが必要です。
紛争解決：エージェントがAPI呼び出しに対して支払いを行い、返ってきたものがゴミだった場合、誰が判断するのか？チャージバックは人間からの申し立てを前提にしています。担保（エスクロー）とチェーン上の証拠を伴う、プログラム可能な紛争フローが必要です。

私たちはまだ#2〜4を解決していません。私たちはプリミティブを提供しています。エージェント向けの支払いインフラを作っているなら、同じ未解決課題でおそらく私たちと競争していることでしょう。

Design Principles That Actually Matter

エージェントの支払いフローを作る（またはベンダーを評価する）のであれば、最適化すべきことはこれです：

機能の網羅性よりもレイテンシー： エージェントは、支払い確認に3秒も待てません。厳しいループの中では、ポリシーチェックは<200ms、決済は<2sを目標に。レイテンシーが増える機能は削るべきです。

ダッシュボードではなくコードとしてのポリシー： 非技術ユーザーはUIを欲しがります。エージェントをデプロイする開発者は、バージョン管理されたYAMLを欲しがります。まずYAMLを出荷しましょう。UIは利便性のためのレイヤーです。

クローズ（失敗時は拒否）し、大声でアラート： ポリシーエンジンがエラーになったら支払いを拒否します。エージェントがレート制限に到達したら、webhookとメールの両方を送信します。無言は、誤検知よりも悪いのです。

監査可能性は妥協できない： 承認されたか拒否されたかに関わらず、すべての支払い試行には変更不能なログが必要です。オンチェーンのtxnハッシュ、ポリシーバージョン、エージェントID、タイムスタンプ。規制当局が尋ねます。デバッグにも必須です。

ブロックチェーンを早すぎる段階で抽象化しない： 開発者は、ガス手数料、確認時間、チェーンの混雑状況を見る必要があります。「うまくいくだけ」は、Baseが落ちているときやUSDCがデペッグしたときには嘘になります。プリミティブを公開してください。

What's Next

私たちは app.agentwallex.com のサンドボックスで稼働中で、ウェイティングリストには3,600+のチームがあります。できます：

支払者（Payer）SDK：LangChain/CrewAIのエージェントにPython/JSを15行分投入するだけで、MPCウォレットとポリシーエンジンが1つのimportで手に入ります。
加盟店（Merchant）SDK：あなたのAPIに<50行でx402の対応を追加。今日からエージェントの支払いを受け付けられます。
テストネット：完全なポリシーエンジン、MPC署名、x402フロー。Base Sepoliaテストネット、蛇口（faucet）から無料USDC。

まだ 準備ができていない ことが3つあります：

Mainnet（2024年Q2）
マルチチェーン（Ethereum、Solana）
フィアットのオンランプ

APIアクセス、データサービス、またはSaaSツールのために支払いが必要なエージェントを作っている—そしてOAuthフローをハックしたり、個別のStripe統合を書いたりするのにうんざりしているなら、これがあなたのためのものです。

支払いスタックは人間のために設計されていました。エージェントは人間ではありません。彼らに本当に必要なものを作りましょう。

サンドボックスへのアクセスを取得： https://app.agentwallex.com

ドキュメントを読む： https://docs.agentwallex.com

x402 spec（draft）： https://github.com/agentwallex/x402-standard

開示：私たちはAgentWallexを開発しています。これは中立的な調査ではありません—エージェントの支払いが壊れている理由と、それをどう直しているかについての私たちの技術的な主張です。私たちには意見があります。なぜなら本番環境に導入しているからです。効果は状況により異なるかもしれません。サンドボックスは無料です。ぜひ触ってみて、どこがおかしいのか教えてください。

Follow & Try AgentWallex

Webサイト： agentwallex.com
サンドボックス（無料）： app.agentwallex.com
ドキュメント： docs.agentwallex.com
Telegram： t.me/AgentWallexOfficial
X / Twitter： x.com/AgentWallex
Bluesky： bsky.app/profile/agentwallex.bsky.social
Dev.to： dev.to/agentwallex
Hashnode： agentwallex.hashnode.dev

Black Hat Asia

AI Business

AIボイスレコーダーの新製品が相次ぐ、早くも懸念されるレッドオーシャン化

日経XTECH

Mr. Chatterboxは（弱い）ヴィクトリア朝時代の倫理訓練を受けたモデルで、自分のコンピュータ上で実行できる

Simon Willison's Blog

チャットボットの先へ：2026年におけるマルチエージェント・エコシステムの実装

Dev.to

ソフトウェア開発における「楽しい」部分を見逃していた