作者：Yokiiiya
先週、香港でWeb3 Festivalに参加したときに感じた明らかなことは： 今やほぼすべてのフォーラムやパネルでAIが避けて通れなくなっていることだ。
もともと支払い、ステーブルコイン、RWA、ウォレット、取引所、規制やインフラについて語っていたとしても、 最終的にはほぼ同じ問題に帰着する： AIが単なるコンテンツ生成を超え、人の代わりにタスクを実行し、サービスを呼び出し、意思決定を行い、さらには資金の流れを処理し始めたとき、 既存の金融・決済システムは十分なのか？
私が参加したあるパネルでは、 「Web3はAIに便乗しているのか？」という直接的な質問も出た。 私はそうは思わない。もちろん、話題に便乗するプロジェクトもあるだろう。 しかし、AI×Web3を単なるストーリーのコラージュと理解してしまうと、 より根底にある変化を見逃すかもしれない： AIは理解・意思決定・行動を担い、Web3は資産・アカウント・決済・検証可能な実行環境を提供する。 この二つは単なる概念の重ね合わせではなく、役割の再分担なのだ。
香港財政司長の陳茂波は、Web3 Festival 2026の演説で、 AIエージェントは将来的に情報を機械の速度で分析し、行動を起こすと述べ、 同時にブロックチェーンインフラを十分に活用し、取引効率を向上させ、 金融、貿易、資産管理、サプライチェーン、物流などのシナリオを再構築すると語った。 AIが行動を始めるとき、問題は「知能」そのものだけではなく、 これらの行動がどう権限付与され、どう決済され、どう記録され、どう責任追及されるかになる。
その中で、**Agentic Payment（エージェンシー型支払い）**は、 ますます無視できなくなるテーマだ。 しかし、最初は素朴な疑問もあった： なぜみんなAgentic PaymentやAgentic Commerceを話すとき、 CryptoやStablecoin、Blockchainとセットで語るのか？
AIエージェントは銀行カードを使えないのか？ クレジットカードは使えないのか？ Apple Pay、Visa、Mastercard、Stripe、PayPalは使えないのか？
もしAgentが、 私の代わりに航空券を買ったり、ホテルを予約したり、SaaSの契約を更新したりするだけなら、 背後で銀行カードやクレジットカード、仮想カード、企業アカウント、サードパーティの決済ウォレットを呼び出すことに本質的な障壁はない。 ユーザが一度権限を与えれば、Agentは規定の範囲内で支払いを実行し、その背後ではカード、仮想カード、企業アカウント、あるいは第三者決済ウォレットを使う。 これは不自然ではない。
だから、「銀行カードやクレジットカードが使えるかどうか」が問題ではない。 もちろん使える。 本当の問題は、 銀行カードやクレジットカードは、Agentic Paymentのどの部分に適していて、どの部分に不向きか？ AIエージェントは本当に銀行カードを使うのか？ そして、Agentic Paymentが一定の段階に達したとき、ほぼ間違いなくステーブルコインとブロックチェーンに頼らざるを得なくなるのはなぜか？
もしAgentic Paymentが、 AIエージェントが最後の支払いを代行するだけのものであれば、 例えば航空券やホテル、SaaSの支払いを行うだけなら、 背後で銀行カードやクレジットカード、仮想カード、Apple Pay、Stripe、PayPalを呼び出すことに本質的な障壁はない。 これらは使えるし、使うべきだ。
ユーザが事前に権限を与え、Agentは規定の範囲内で支払いを実行する。 これは理解しやすいし、実質的にはより賢い自動引き落としや、企業用仮想カード、出張用カード、あるいは自動調達システムのようなものだ。
したがって、VisaやMastercard、Stripeといった従来の決済プレイヤーは消えない。 むしろ、初期のAgentic Commerceの重要な入口となる。
StripeとTempoが提案するMachine Payments Protocolは、その良い例だ。 これは単にステーブルコインを押し付けるのではなく、 商人がエージェントからの支払いを直接受け入れられる仕組みだ。 ステーブルコインだけでなく、カードやBNPL（後払い）などの法定通貨決済もサポートする。 つまり、エージェント支払いの初期段階では、従来の決済とステーブルコインは共存し、すぐにどちらかが置き換わるわけではない。
ただし、これはAgentic Commerceの一部分、チェックアウトの話だ。
チェックアウトの前提は、商品、商人、注文、支払いボタン、返金や紛争処理のフローがすでに存在していることだ。 エージェントは、ユーザの横に立ち、より自動化された購入を手助けするだけだ。
本当の問題は、 もう一つのシナリオにある： エージェントは、すでに整ったショッピングカートに入るだけではなく、 オープンネットワーク上でリソースを連続的に呼び出し、サービスを組み合わせ、タスクを完遂することだ。
例えば、AIリサーチエージェントが業界レポートを作成するために、 複数のデータベースを呼び出し、有料資料を購入し、異なるモデルAPIにアクセスし、クローラーサービスを呼び出し、チャート生成ツールに支払い、さらには別のエージェントから分析結果を購入する。 この中には、従来の意味での「ショップ」もなければ、完全なチェックアウトページも存在しないかもしれない。 APIやデータインターフェース、モデルサービス、計算ノード、コンテンツリソース、自動化ツール、さらには別のエージェントと連携している可能性もある。
私自身も最近、非常に具体的な例に直面した。 流量分析アシスタントを作りたいと考え、必要に応じてSemrushのようなデータソースを自動呼び出し、 ウェブサイトの流量、キーワード、競合、マーケットトレンドを分析させたい。 しかし、実際に計画を整理し始めると、「AIは分析できるか」ではなく、「どうやってデータを取得するか」が問題だった。
多くの商用データソースは、「単一呼び出し・単一課金・即時応答」の方式では設計されていない。 SemrushのAPIは、アカウントやパッケージ、APIユニットの枠組みで管理されている。 APIリクエストは一定のAPIユニットを消費し、ユーザはAPIアクセス権やAPIユニットパッケージを購入する必要がある。 Trends APIも単独購入可能だが、やはりAPIユニットベースだ。
しかし、エージェントにとってはこのモデルは自然ではない。 もしエージェントが、たまに流量データを呼び出すだけなら、 アカウント登録やAPIユニットの購入ではなく、 ウェブページにアクセスするようにリクエストを発行したいだけだ。 「このデータはいくら？」「購入権はあるか？」「予算内なら支払い、すぐに結果を得たい」
これがAgentic Paymentと従来のAPI商用モデルの断絶だ。 今日の多くのAPI課金方式は、「人間の企業がソフトウェアを調達する」ために設計されており、 「機械が必要に応じてリソースを購入する」ためには最適化されていない。
だから、Agentic Paymentの問題は、 最後の一歩の支払いだけではなく、 タスクの連鎖全体で、機械がどう継続的に権限を得て支払いを発し、 納品を検証し、決済を完了させるかにある。
これが、銀行カード体系の限界だ。
単に遅れているわけではなく、 もともと人間の消費シーンを対象にしていたからだ： 人が商店に入り、商品を選び、注文を確定し、支払いを完了させる。 その後は銀行やカード団体、決済業者が権限付与、清算、リスク管理、紛争処理を行う。
しかし、エージェント経済は別の問題を抱えている： このエージェントは何の権限でお金を使うのか？ サービス提供者は、これが悪意のボットではなく、ユーザの真の意図の延長であることをどう確認するのか？ エージェントは、人工的な確認なしに少額・高頻度・クロスプラットフォームの支払いを完了できるのか？ サービス側は、支払い後すぐにリソースを解放できるのか？ エージェントが誤購入・越権・攻撃された場合、責任は誰にあるのか？
これらの問いに答えるために、GoogleはAP2を開発した。 「どの決済手段を使うか」ではなく、 「エージェント支払いの信頼枠」を重視したのだ。 Googleの公式説明では、AP2は「決済に依存しないフレームワーク」とされ、 ユーザ・商人・決済事業者が異なる決済方式間で、より信頼してエージェント主導の支払いを完結できるように設計されている。 また、AP2仕様は、エージェントが安全かつシンプルにスコープ付き権限を取得し、ユーザの代理で行動できる仕組みを明示している。 安全性は、ユーザと商人が暗号署名を行うことで担保される。
したがって、Agentic Paymentの最初の問題は、 「お金はどこから引き落とすのか」ではなく、 「エージェントは何の権限でお金を使えるのか」だ。
この問いに対して、銀行カード体系は一部解決策を提供できる。 仮想カードやトークン化資格情報、権限管理、企業経費管理、リスクルールなどだ。 これらを使えば、エージェントは既存の商用インフラ内で取引できる。
Visaもこの方向を進めている。 その代表例が、Intelligent CommerceやTrusted Agent Protocolだ。 これらは、AIエージェントが商人のネットワーク内で認識・信頼・権限を得て、取引を代行できる仕組みだ。 Visa DeveloperのTrusted Agent Protocolの説明によると、 AIエージェントはユーザのブラウジングや商品比較、選択を支援し、 商取引はチェックアウト前から始まっている。 これらの自動化されたアクセスは、従来はボットとみなされ、ブロックされることもあった。
これは、従来の決済ネットワークも同じ問題を認識していることを示す。 Agentic Commerceは、支払いボタンの瞬間だけではなく、 検索・比較・選択・権限付与・最終支払いまでの一連の流れだ。 しかし、カードネットワークは、 「エージェントが既存の商取引フローに入り、認可された取引を完了させる」ことには長けているが、 「オープンネットワーク上でAPIやデータ、モデル、計算リソース、コンテンツ、ツール、別のエージェントに対して継続的に小額支払いを行う」部分には本質的に対応できていない。
だから、銀行カードは不可能ではない。 より正確には、 銀行カードはエージェントの商取引のチェックアウト部分を解決する。 しかし、エージェント経済には、より根底にある支払いプロトコルが必要だ。
これが次の段階の問題だ： 取引対象が従来の商店ではなく、APIやモデル、データインターフェース、あるいは別のエージェントだった場合、 機械間でどうやって支払いを発し、完了させるのか？ これが、x402、L402、T402といったプロトコルの議論の背景だ。
もし取引対象が従来の商店なら、 エージェントは既存のチェックアウトフローに入り、 クレジットカードやデビットカード、仮想カード、ウォレットを使って支払いを完了できる。 しかし、取引対象がAPIやモデル、データインターフェース、コンテンツ、あるいは別のエージェントだった場合、 問題は変わる。
このとき、機械間に必要なのは、「支払いボタン」ではなく、 機械が理解できる支払いフローだ。 エージェントはリソースをリクエストし、 サービス側は「このリソースには支払いが必要です。価格はいくらですか？支払い先はどこですか？どの支払い方法をサポートしていますか？」と返す。 エージェントは、その支払いがユーザの権限範囲内かどうか判断し、 規則に合えば支払いを行い、サービス側は支払いを検証してリソースを解放する。
この流れは一見シンプルだが、 実はインターネットの過去に欠けていた層を補うものだ： ネイティブな支払い層だ。
従来、インターネットは情報の流れを自然にサポートしてきた。 ウェブページはリクエストされ、メールは送信され、APIは呼び出され、ファイルはダウンロードされる。 しかし、「支払い」はインターネットのプロトコルの一部ではなく、 別システムに外付けされてきた： アカウント登録、カード連携、決済ゲートウェイ接続、パッケージ購入、APIキー管理、月次請求。
これは人間にとっては許容範囲だ。 登録・ログイン・カード連携・承認・調達・経費精算は面倒だが、 人間はできる。
しかし、エージェントにとってはこれが重すぎる。
エージェントは、 API呼び出しごとにアカウント登録をする必要はない。 データアクセスごとにパッケージを買う必要もない。 数セント・数十セントの少額呼び出しのために、 複雑な人間の支払い・調達フローを踏む必要もない。
これがx402のようなプロトコルが登場した理由だ。
x402は、HTTP 402 Payment Requiredという長らく使われていなかった状態コードを復活させた。 これにより、サービス側はHTTPレベルで直接クライアントに伝えられる： 「このリソースにアクセスするには支払いが必要です」。 クライアントは人間でも機械でもよい。 支払いが完了すれば、サービスは検証し、APIやコンテンツ、デジタルサービスを返す。
Coinbaseはx402を次のように定義している： 「HTTPを通じて即時・自動的にステーブルコイン支払いを行い、 人間・機械のクライアントがアカウントやセッション、複雑な認証なしにプログラム的に支払い、アクセス権を得るためのオープンプロトコル」だ。
ここで重要なのは、「使うかどうか」や「USDCを使うか」ではなく、 x402がインターネットのリクエスト-レスポンスの流れに支払いを埋め込んだことだ。
従来は：
だったのが、
x402は：
という流れに変わる。 これがエージェンシー型支払いにとって非常に重要だ。 なぜなら、エージェントの取引は、大きな一回の買い物ではなく、 大量の小額・リアルタイム・オンデマンドのサービス呼び出しになるからだ。
例を挙げると：
これらは、すべてアカウントやサブスクリプション、APIキー、パッケージ、人工的な承認を必要とすると、 エージェントの実行能力を制限してしまう。 だから、x402の意義は、「より暗号通貨的に」することではなく、 「インターネットのプロトコルのように」支払いを可能にすることだ。
L402はまた別のアプローチだ。 HTTP 402を軸にしつつ、Bitcoin Lightning Networkやmacaroonsといったアクセス証明や少額決済を組み合わせている。 Lightning LabsはL402を次のように定義している： 「APIエンドポイントや計算リソースなどのサービスの認証と取引を促進し、 APIエンドポイントに対して課金できる仕組みを提供し、AIエージェントの参加を容易にする」。
これらは、 HTTPアクセス制御・少額決済・デジタルサービス権限の3つを融合させた試みだ。 過去は、これらを一つにまとめる需要が十分ではなかった。
人間は、APIエンドポイントに数セントの支払いをすることはほとんどない。 しかし、エージェントはやる。 人間は、1日に何百ものデータソースを自動呼び出ししない。 しかし、エージェントはやる。 人間は、リアルタイムで複数のサービスを組み合わせて呼び出し、価格を比較し、支払い、検証を行わない。 しかし、エージェントはやる。
だからこそ、AIエージェントの登場により、HTTPネイティブな支払いの道が一気に現実味を帯びてきた。
USDT/Tetherエコシステムでも、似た方向性の動きが出ている。 Tether WDKのx402ドキュメントには、 「x402はAIエージェントにとって重要だ」と明記されている。 なぜなら、エージェントはプログラム的にリソースに支払いを行う必要があり、 x402は支払いをWebスタックの一部にし、 リクエストの中で価格を見つけ、署名し、リソースを得ることを可能にするからだ。 また、t402プロジェクトは、「インターネットネイティブな支払い」のオープンスタンダードを目指し、 Crypto・Fiat・Stablecoin・Tokenなど多様な価値形態をサポートし、Tether WDKとも互換性を持つと自己紹介している。
ここで注意したいのは、 これを「Tether公式の標準」と断定するのではなく、 「USDT/Tetherエコシステムの中で、x402に類似したプロトコルの探索が進んでいる」と表現すべきだ。
この背景には、 Agentic Paymentは単なる企業やプロジェクトの競争ではなく、新たなプロトコルスタックの形成だという大きな流れがある。
これらは一つの階層ではなく、相互に補完し合うものだ。 これらを組み合わせることで、真のエージェント主導の支払いインフラが形成される。
もしエージェントが、 機械が自動的に理解し、実行できる支払いプロトコルを本当に必要とするなら、 なぜ最も議論されるのがステーブルコインなのか？ BTCやETHではなく、なぜ安定した価値の資産なのか？
ポイントは、「crypto asset」そのものではなく、 エージェントが何を支払い手段として必要としているかだ。 エージェントが長期的に資産を保有するなら、値動きやリターン、リスクに関心を持つだろう。 しかし、タスク完了のために支払うエージェントは、 投機的な資産ではなく、安定した価値単位を最優先する。
これらのシナリオでは、 エージェントは取引や投機をしているわけではなく、 あくまでタスクを完了させるための支払いだ。 だから、「このリソースはいくらか」「今回の呼び出しは予算内か」「ユーザの権限内か」「サービス提供後のコストは正確に記録できるか」などを知る必要がある。
もし支払い資産自体が日々大きく変動したら、 エージェントの予算管理は非常に複雑になる。 今日0.1ドルだったAPI呼び出しが、明日には0.12ドルや0.08ドルになったとしたら、 市場には問題ないかもしれないが、 機械が必要に応じてリソースを購入するには不都合だ。
これが、エージェント支払いにはステーブルコインが自然に選ばれる理由だ。
ステーブルコインの第一の価値は、 より現実の商取引に近い価値単位を提供することにある。 今日、多くのAPIやSaaS、データサービス、モデルサービス、クラウドサービスはドル建てだ。 エージェントがこれらをオンデマンドで購入するなら、 ドルステーブルコインを支払い資産とすれば、 予算・価格・権限・請求を一つの単位にまとめられる。
これは一見普通のことだが、 エージェントにとっては非常に重要だ。 エージェントは「支払う」だけではなく、「判断」も必要だからだ。
もし支払い資産が日々変動したら、 予算管理は複雑になる。 今日0.1ドルだったAPI呼び出しが、明日0.12ドルや0.08ドルになったら、 エージェントは混乱する。
だから、エージェント支払いには、 安定した価値を持ち、 機械が直接呼び出せる資産が必要だ。 BTCやETHよりも、ステーブルコインの方が適している。
第二の価値は、 ステーブルコインは小額・高頻度・即時決済に適していることだ。 前述のx402の例でも見た通り、 HTTPを通じて即時・自動的にステーブルコイン支払いを行い、 APIやデジタルコンテンツ、サービスの対価を支払う仕組みは、 まさにこの用途に最適だ。
Tether WDKのx402ドキュメントも、 「AIエージェントはプログラム的にリソースに支払いを行う必要があり、 x402はリクエスト-レスポンスの中で価格を見つけ、署名し、リソースを得ることを可能にする」と述べている。
これは銀行カードの使い方とは異なる。 銀行カードは人間の消費のためのものであり、 ステーブルコインは、機械がリソースを呼び出すときの即時決済資産だ。
もちろん、銀行カードは消えない。 StripeやTempoのMachine Payments Protocolは、 「オンチェーンの暗号資産決済」と「カードやウォレットを使った法定通貨決済」の両方をサポートしている。
したがって、「ステーブルコインが銀行カードの代わりになる」のではなく、 従来の商用ネットワークやチェックアウトの場面には銀行カードが適している。 一方、オープンネットワーク上の機械間呼び出しやリソース呼び出しには、 ステーブルコインとブロックチェーンがより適している。
第三の価値は、 ステーブルコインはクロスプラットフォーム・クロスボーダーに最適だということだ。 エージェントは、アメリカのAPI、ヨーロッパのモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツールなど、 異なる国・地域・システムのリソースを呼び出すこともある。 このとき、銀行口座や決済インフラを国ごとに使い分けると、 全体のタスクチェーンは複雑になり、遅延やコスト増につながる。
しかし、ステーブルコインはインターネットネイティブの資産だ。 24時間365日流通し、クロスプラットフォーム・クロスウォレット・クロスアプリケーションで呼び出せる。 スマートコントラクトや決済プロトコルとも直接連携できる。 これにより、エージェントの実行は銀行の営業時間に縛られず、 週末や跨境、銀行の清算ウィンドウ、商店のアカウント体系に左右されずに済む。
これが、x402やTether WDKのサポート、 そしてUSDT/Tetherエコシステムのt402探索が進む背景だ。 「支払いをエージェントが直接呼び出せるWebスタックのコンポーネントにする」ことを目指している。
ただし、注意も必要だ。 ステーブルコインには問題もある。
とはいえ、 ステーブルコインは完璧な貨幣ではないが、 エージェント支払いのニーズに最も近い、インターネットネイティブな決済資産の一つだ。
その価値は、「分散化のストーリー」ではなく、 次の条件を満たす点にある： 価格が比較的安定している。 プログラムから呼び出せる。 クロスプラットフォームで流通できる。 24時間365日決済できる。 HTTPネイティブ支払い・ウォレット・スマートコントラクト・オンチェーン監査と連携できる。
これが、エージェント支払いにおいてステーブルコインが不可欠とされる理由だ。 すべての支払いが暗号資産決済になるわけではない。 むしろ、取引対象が「人間の消費者」から「ソフトウェア主体」へと変わるとき、 ステーブルコインは「お金」をインターネットのプロトコルの一部にする最初の一歩となる。
ただし、ステーブルコインは一つの問いにしか答えない： 「エージェントは何の資産で支払うのか？」 もう一つの問い、「エージェントがオープンネット上で支出した後、その資金は誰の権限下にあり、どこに使われたのか、越権はないか、サービスはちゃんと提供されたのか？」には答えられない。
この問いこそ、ブロックチェーンの出番だ。
たとえエージェントがステーブルコインで支払う必要があっても、 なぜブロックチェーンが必要なのか？ 中央集権的な台帳でも良いのではないか？ StripeやVisa、銀行、あるいは特定のプラットフォームが記録しても良いのでは？
もちろん可能だ。 もしエージェントが、 Amazonだけで買い物をしたり、特定のSaaSだけを使ったり、 企業内システムだけで調達を完結させるなら、 中央台帳は十分だ。 プラットフォームはユーザやエージェントの権限を把握し、 支払い・サービスの履行・権利管理もできる。
しかし、エージェント支払いの真価は、 むしろ「エージェントが複数のプラットフォームやサービス、ウォレット、国境を越えてタスクを完遂する」場面にある。 このとき、問題は「お金がちゃんと支払われるか」だけではなく、 「誰が権限を与えたのか」「越権はないか」「サービスはちゃんと提供されたか」「何か問題があったとき責任は誰にあるか」だ。
これらの問いに答えるために、 ブロックチェーンは本当に価値がある。 すべての経済行動の記録を、 外部から検証可能な形で残すことができるからだ。
人間の支払いは、 多くの不透明さを許容してきた。 サービス未着、契約違反、カードの誤引き落とし、争議処理などは、 人間社会の長い歴史の中で、 「仕方ない」とされてきた。
しかし、エージェントは違う。 エージェントの取引は、 頻度が高く、金額は小さく、 サービスの数も多く、 実行の連鎖も長い。 すべての取引を人間が後から追跡・証明・検証するのは非現実的だ。
だからこそ、 エージェントは
593.15K 人気度
58.79M 人気度
42.27K 人気度
1.04M 人気度
46.78K 人気度
AIエージェントは銀行カードを使えますか？
Agentic Payment なぜ安定したコインとブロックチェーンを避けられないのか
作者：Yokiiiya
先週、香港でWeb3 Festivalに参加したときに感じた明らかなことは：
今やほぼすべてのフォーラムやパネルでAIが避けて通れなくなっていることだ。
もともと支払い、ステーブルコイン、RWA、ウォレット、取引所、規制やインフラについて語っていたとしても、
最終的にはほぼ同じ問題に帰着する：
AIが単なるコンテンツ生成を超え、人の代わりにタスクを実行し、サービスを呼び出し、意思決定を行い、さらには資金の流れを処理し始めたとき、
既存の金融・決済システムは十分なのか？
私が参加したあるパネルでは、
「Web3はAIに便乗しているのか？」という直接的な質問も出た。
私はそうは思わない。もちろん、話題に便乗するプロジェクトもあるだろう。
しかし、AI×Web3を単なるストーリーのコラージュと理解してしまうと、
より根底にある変化を見逃すかもしれない：
AIは理解・意思決定・行動を担い、Web3は資産・アカウント・決済・検証可能な実行環境を提供する。
この二つは単なる概念の重ね合わせではなく、役割の再分担なのだ。
香港財政司長の陳茂波は、Web3 Festival 2026の演説で、
AIエージェントは将来的に情報を機械の速度で分析し、行動を起こすと述べ、
同時にブロックチェーンインフラを十分に活用し、取引効率を向上させ、
金融、貿易、資産管理、サプライチェーン、物流などのシナリオを再構築すると語った。
AIが行動を始めるとき、問題は「知能」そのものだけではなく、
これらの行動がどう権限付与され、どう決済され、どう記録され、どう責任追及されるかになる。
その中で、**Agentic Payment（エージェンシー型支払い）**は、
ますます無視できなくなるテーマだ。
しかし、最初は素朴な疑問もあった：
なぜみんなAgentic PaymentやAgentic Commerceを話すとき、
CryptoやStablecoin、Blockchainとセットで語るのか？
AIエージェントは銀行カードを使えないのか？
クレジットカードは使えないのか？
Apple Pay、Visa、Mastercard、Stripe、PayPalは使えないのか？
もしAgentが、
私の代わりに航空券を買ったり、ホテルを予約したり、SaaSの契約を更新したりするだけなら、
背後で銀行カードやクレジットカード、仮想カード、企業アカウント、サードパーティの決済ウォレットを呼び出すことに本質的な障壁はない。
ユーザが一度権限を与えれば、Agentは規定の範囲内で支払いを実行し、その背後ではカード、仮想カード、企業アカウント、あるいは第三者決済ウォレットを使う。
これは不自然ではない。
だから、「銀行カードやクレジットカードが使えるかどうか」が問題ではない。
もちろん使える。
本当の問題は、
銀行カードやクレジットカードは、Agentic Paymentのどの部分に適していて、どの部分に不向きか？
AIエージェントは本当に銀行カードを使うのか？
そして、Agentic Paymentが一定の段階に達したとき、ほぼ間違いなくステーブルコインとブロックチェーンに頼らざるを得なくなるのはなぜか？
一、銀行カードはチェックアウトを解決するが、エージェント経済には向かない
もしAgentic Paymentが、
AIエージェントが最後の支払いを代行するだけのものであれば、
例えば航空券やホテル、SaaSの支払いを行うだけなら、
背後で銀行カードやクレジットカード、仮想カード、Apple Pay、Stripe、PayPalを呼び出すことに本質的な障壁はない。
これらは使えるし、使うべきだ。
ユーザが事前に権限を与え、Agentは規定の範囲内で支払いを実行する。
これは理解しやすいし、実質的にはより賢い自動引き落としや、企業用仮想カード、出張用カード、あるいは自動調達システムのようなものだ。
したがって、VisaやMastercard、Stripeといった従来の決済プレイヤーは消えない。
むしろ、初期のAgentic Commerceの重要な入口となる。
StripeとTempoが提案するMachine Payments Protocolは、その良い例だ。
これは単にステーブルコインを押し付けるのではなく、
商人がエージェントからの支払いを直接受け入れられる仕組みだ。
ステーブルコインだけでなく、カードやBNPL（後払い）などの法定通貨決済もサポートする。
つまり、エージェント支払いの初期段階では、従来の決済とステーブルコインは共存し、すぐにどちらかが置き換わるわけではない。
ただし、これはAgentic Commerceの一部分、チェックアウトの話だ。
チェックアウトの前提は、商品、商人、注文、支払いボタン、返金や紛争処理のフローがすでに存在していることだ。
エージェントは、ユーザの横に立ち、より自動化された購入を手助けするだけだ。
本当の問題は、
もう一つのシナリオにある：
エージェントは、すでに整ったショッピングカートに入るだけではなく、
オープンネットワーク上でリソースを連続的に呼び出し、サービスを組み合わせ、タスクを完遂することだ。
例えば、AIリサーチエージェントが業界レポートを作成するために、
複数のデータベースを呼び出し、有料資料を購入し、異なるモデルAPIにアクセスし、クローラーサービスを呼び出し、チャート生成ツールに支払い、さらには別のエージェントから分析結果を購入する。
この中には、従来の意味での「ショップ」もなければ、完全なチェックアウトページも存在しないかもしれない。
APIやデータインターフェース、モデルサービス、計算ノード、コンテンツリソース、自動化ツール、さらには別のエージェントと連携している可能性もある。
私自身も最近、非常に具体的な例に直面した。
流量分析アシスタントを作りたいと考え、必要に応じてSemrushのようなデータソースを自動呼び出し、
ウェブサイトの流量、キーワード、競合、マーケットトレンドを分析させたい。
しかし、実際に計画を整理し始めると、「AIは分析できるか」ではなく、「どうやってデータを取得するか」が問題だった。
多くの商用データソースは、「単一呼び出し・単一課金・即時応答」の方式では設計されていない。
SemrushのAPIは、アカウントやパッケージ、APIユニットの枠組みで管理されている。
APIリクエストは一定のAPIユニットを消費し、ユーザはAPIアクセス権やAPIユニットパッケージを購入する必要がある。
Trends APIも単独購入可能だが、やはりAPIユニットベースだ。
しかし、エージェントにとってはこのモデルは自然ではない。
もしエージェントが、たまに流量データを呼び出すだけなら、
アカウント登録やAPIユニットの購入ではなく、
ウェブページにアクセスするようにリクエストを発行したいだけだ。
「このデータはいくら？」「購入権はあるか？」「予算内なら支払い、すぐに結果を得たい」
これがAgentic Paymentと従来のAPI商用モデルの断絶だ。
今日の多くのAPI課金方式は、「人間の企業がソフトウェアを調達する」ために設計されており、
「機械が必要に応じてリソースを購入する」ためには最適化されていない。
だから、Agentic Paymentの問題は、
最後の一歩の支払いだけではなく、
タスクの連鎖全体で、機械がどう継続的に権限を得て支払いを発し、
納品を検証し、決済を完了させるかにある。
これが、銀行カード体系の限界だ。
単に遅れているわけではなく、
もともと人間の消費シーンを対象にしていたからだ：
人が商店に入り、商品を選び、注文を確定し、支払いを完了させる。
その後は銀行やカード団体、決済業者が権限付与、清算、リスク管理、紛争処理を行う。
しかし、エージェント経済は別の問題を抱えている：
このエージェントは何の権限でお金を使うのか？
サービス提供者は、これが悪意のボットではなく、ユーザの真の意図の延長であることをどう確認するのか？
エージェントは、人工的な確認なしに少額・高頻度・クロスプラットフォームの支払いを完了できるのか？
サービス側は、支払い後すぐにリソースを解放できるのか？
エージェントが誤購入・越権・攻撃された場合、責任は誰にあるのか？
これらの問いに答えるために、GoogleはAP2を開発した。
「どの決済手段を使うか」ではなく、
「エージェント支払いの信頼枠」を重視したのだ。
Googleの公式説明では、AP2は「決済に依存しないフレームワーク」とされ、
ユーザ・商人・決済事業者が異なる決済方式間で、より信頼してエージェント主導の支払いを完結できるように設計されている。
また、AP2仕様は、エージェントが安全かつシンプルにスコープ付き権限を取得し、ユーザの代理で行動できる仕組みを明示している。
安全性は、ユーザと商人が暗号署名を行うことで担保される。
したがって、Agentic Paymentの最初の問題は、
「お金はどこから引き落とすのか」ではなく、
「エージェントは何の権限でお金を使えるのか」だ。
この問いに対して、銀行カード体系は一部解決策を提供できる。
仮想カードやトークン化資格情報、権限管理、企業経費管理、リスクルールなどだ。
これらを使えば、エージェントは既存の商用インフラ内で取引できる。
Visaもこの方向を進めている。
その代表例が、Intelligent CommerceやTrusted Agent Protocolだ。
これらは、AIエージェントが商人のネットワーク内で認識・信頼・権限を得て、取引を代行できる仕組みだ。
Visa DeveloperのTrusted Agent Protocolの説明によると、
AIエージェントはユーザのブラウジングや商品比較、選択を支援し、
商取引はチェックアウト前から始まっている。
これらの自動化されたアクセスは、従来はボットとみなされ、ブロックされることもあった。
これは、従来の決済ネットワークも同じ問題を認識していることを示す。
Agentic Commerceは、支払いボタンの瞬間だけではなく、
検索・比較・選択・権限付与・最終支払いまでの一連の流れだ。
しかし、カードネットワークは、
「エージェントが既存の商取引フローに入り、認可された取引を完了させる」ことには長けているが、
「オープンネットワーク上でAPIやデータ、モデル、計算リソース、コンテンツ、ツール、別のエージェントに対して継続的に小額支払いを行う」部分には本質的に対応できていない。
だから、銀行カードは不可能ではない。
より正確には、
銀行カードはエージェントの商取引のチェックアウト部分を解決する。
しかし、エージェント経済には、より根底にある支払いプロトコルが必要だ。
これが次の段階の問題だ：
取引対象が従来の商店ではなく、APIやモデル、データインターフェース、あるいは別のエージェントだった場合、
機械間でどうやって支払いを発し、完了させるのか？
これが、x402、L402、T402といったプロトコルの議論の背景だ。
二、エージェントが本当に必要とするのは、機械可読の支払いプロトコル
もし取引対象が従来の商店なら、
エージェントは既存のチェックアウトフローに入り、
クレジットカードやデビットカード、仮想カード、ウォレットを使って支払いを完了できる。
しかし、取引対象がAPIやモデル、データインターフェース、コンテンツ、あるいは別のエージェントだった場合、
問題は変わる。
このとき、機械間に必要なのは、「支払いボタン」ではなく、
機械が理解できる支払いフローだ。
エージェントはリソースをリクエストし、
サービス側は「このリソースには支払いが必要です。価格はいくらですか？支払い先はどこですか？どの支払い方法をサポートしていますか？」と返す。
エージェントは、その支払いがユーザの権限範囲内かどうか判断し、
規則に合えば支払いを行い、サービス側は支払いを検証してリソースを解放する。
この流れは一見シンプルだが、
実はインターネットの過去に欠けていた層を補うものだ：
ネイティブな支払い層だ。
従来、インターネットは情報の流れを自然にサポートしてきた。
ウェブページはリクエストされ、メールは送信され、APIは呼び出され、ファイルはダウンロードされる。
しかし、「支払い」はインターネットのプロトコルの一部ではなく、
別システムに外付けされてきた：
アカウント登録、カード連携、決済ゲートウェイ接続、パッケージ購入、APIキー管理、月次請求。
これは人間にとっては許容範囲だ。
登録・ログイン・カード連携・承認・調達・経費精算は面倒だが、
人間はできる。
しかし、エージェントにとってはこれが重すぎる。
エージェントは、
API呼び出しごとにアカウント登録をする必要はない。
データアクセスごとにパッケージを買う必要もない。
数セント・数十セントの少額呼び出しのために、
複雑な人間の支払い・調達フローを踏む必要もない。
これがx402のようなプロトコルが登場した理由だ。
x402は、HTTP 402 Payment Requiredという長らく使われていなかった状態コードを復活させた。
これにより、サービス側はHTTPレベルで直接クライアントに伝えられる：
「このリソースにアクセスするには支払いが必要です」。
クライアントは人間でも機械でもよい。
支払いが完了すれば、サービスは検証し、APIやコンテンツ、デジタルサービスを返す。
Coinbaseはx402を次のように定義している：
「HTTPを通じて即時・自動的にステーブルコイン支払いを行い、
人間・機械のクライアントがアカウントやセッション、複雑な認証なしにプログラム的に支払い、アクセス権を得るためのオープンプロトコル」だ。
ここで重要なのは、「使うかどうか」や「USDCを使うか」ではなく、
x402がインターネットのリクエスト-レスポンスの流れに支払いを埋め込んだことだ。
従来は：
だったのが、
x402は：
という流れに変わる。
これがエージェンシー型支払いにとって非常に重要だ。
なぜなら、エージェントの取引は、大きな一回の買い物ではなく、
大量の小額・リアルタイム・オンデマンドのサービス呼び出しになるからだ。
例を挙げると：
これらは、すべてアカウントやサブスクリプション、APIキー、パッケージ、人工的な承認を必要とすると、
エージェントの実行能力を制限してしまう。
だから、x402の意義は、「より暗号通貨的に」することではなく、
「インターネットのプロトコルのように」支払いを可能にすることだ。
L402はまた別のアプローチだ。
HTTP 402を軸にしつつ、Bitcoin Lightning Networkやmacaroonsといったアクセス証明や少額決済を組み合わせている。
Lightning LabsはL402を次のように定義している：
「APIエンドポイントや計算リソースなどのサービスの認証と取引を促進し、
APIエンドポイントに対して課金できる仕組みを提供し、AIエージェントの参加を容易にする」。
これらは、
HTTPアクセス制御・少額決済・デジタルサービス権限の3つを融合させた試みだ。
過去は、これらを一つにまとめる需要が十分ではなかった。
人間は、APIエンドポイントに数セントの支払いをすることはほとんどない。
しかし、エージェントはやる。
人間は、1日に何百ものデータソースを自動呼び出ししない。
しかし、エージェントはやる。
人間は、リアルタイムで複数のサービスを組み合わせて呼び出し、価格を比較し、支払い、検証を行わない。
しかし、エージェントはやる。
だからこそ、AIエージェントの登場により、HTTPネイティブな支払いの道が一気に現実味を帯びてきた。
USDT/Tetherエコシステムでも、似た方向性の動きが出ている。
Tether WDKのx402ドキュメントには、
「x402はAIエージェントにとって重要だ」と明記されている。
なぜなら、エージェントはプログラム的にリソースに支払いを行う必要があり、
x402は支払いをWebスタックの一部にし、
リクエストの中で価格を見つけ、署名し、リソースを得ることを可能にするからだ。
また、t402プロジェクトは、「インターネットネイティブな支払い」のオープンスタンダードを目指し、
Crypto・Fiat・Stablecoin・Tokenなど多様な価値形態をサポートし、Tether WDKとも互換性を持つと自己紹介している。
ここで注意したいのは、
これを「Tether公式の標準」と断定するのではなく、
「USDT/Tetherエコシステムの中で、x402に類似したプロトコルの探索が進んでいる」と表現すべきだ。
この背景には、
Agentic Paymentは単なる企業やプロジェクトの競争ではなく、新たなプロトコルスタックの形成だという大きな流れがある。
これらは一つの階層ではなく、相互に補完し合うものだ。
これらを組み合わせることで、真のエージェント主導の支払いインフラが形成される。
三、なぜ安定コインか：エージェントは安定した価値単位を必要とする
もしエージェントが、
機械が自動的に理解し、実行できる支払いプロトコルを本当に必要とするなら、
なぜ最も議論されるのがステーブルコインなのか？
BTCやETHではなく、なぜ安定した価値の資産なのか？
ポイントは、「crypto asset」そのものではなく、
エージェントが何を支払い手段として必要としているかだ。
エージェントが長期的に資産を保有するなら、値動きやリターン、リスクに関心を持つだろう。
しかし、タスク完了のために支払うエージェントは、
投機的な資産ではなく、安定した価値単位を最優先する。
例を挙げると：
これらのシナリオでは、
エージェントは取引や投機をしているわけではなく、
あくまでタスクを完了させるための支払いだ。
だから、「このリソースはいくらか」「今回の呼び出しは予算内か」「ユーザの権限内か」「サービス提供後のコストは正確に記録できるか」などを知る必要がある。
もし支払い資産自体が日々大きく変動したら、
エージェントの予算管理は非常に複雑になる。
今日0.1ドルだったAPI呼び出しが、明日には0.12ドルや0.08ドルになったとしたら、
市場には問題ないかもしれないが、
機械が必要に応じてリソースを購入するには不都合だ。
これが、エージェント支払いにはステーブルコインが自然に選ばれる理由だ。
ステーブルコインの第一の価値は、
より現実の商取引に近い価値単位を提供することにある。
今日、多くのAPIやSaaS、データサービス、モデルサービス、クラウドサービスはドル建てだ。
エージェントがこれらをオンデマンドで購入するなら、
ドルステーブルコインを支払い資産とすれば、
予算・価格・権限・請求を一つの単位にまとめられる。
これは一見普通のことだが、
エージェントにとっては非常に重要だ。
エージェントは「支払う」だけではなく、「判断」も必要だからだ。
もし支払い資産が日々変動したら、
予算管理は複雑になる。
今日0.1ドルだったAPI呼び出しが、明日0.12ドルや0.08ドルになったら、
エージェントは混乱する。
だから、エージェント支払いには、
安定した価値を持ち、
機械が直接呼び出せる資産が必要だ。
BTCやETHよりも、ステーブルコインの方が適している。
第二の価値は、
ステーブルコインは小額・高頻度・即時決済に適していることだ。
前述のx402の例でも見た通り、
HTTPを通じて即時・自動的にステーブルコイン支払いを行い、
APIやデジタルコンテンツ、サービスの対価を支払う仕組みは、
まさにこの用途に最適だ。
例を挙げると：
Tether WDKのx402ドキュメントも、
「AIエージェントはプログラム的にリソースに支払いを行う必要があり、
x402はリクエスト-レスポンスの中で価格を見つけ、署名し、リソースを得ることを可能にする」と述べている。
これは銀行カードの使い方とは異なる。
銀行カードは人間の消費のためのものであり、
ステーブルコインは、機械がリソースを呼び出すときの即時決済資産だ。
もちろん、銀行カードは消えない。
StripeやTempoのMachine Payments Protocolは、
「オンチェーンの暗号資産決済」と「カードやウォレットを使った法定通貨決済」の両方をサポートしている。
したがって、「ステーブルコインが銀行カードの代わりになる」のではなく、
従来の商用ネットワークやチェックアウトの場面には銀行カードが適している。
一方、オープンネットワーク上の機械間呼び出しやリソース呼び出しには、
ステーブルコインとブロックチェーンがより適している。
第三の価値は、
ステーブルコインはクロスプラットフォーム・クロスボーダーに最適だということだ。
エージェントは、アメリカのAPI、ヨーロッパのモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツールなど、
異なる国・地域・システムのリソースを呼び出すこともある。
このとき、銀行口座や決済インフラを国ごとに使い分けると、
全体のタスクチェーンは複雑になり、遅延やコスト増につながる。
しかし、ステーブルコインはインターネットネイティブの資産だ。
24時間365日流通し、クロスプラットフォーム・クロスウォレット・クロスアプリケーションで呼び出せる。
スマートコントラクトや決済プロトコルとも直接連携できる。
これにより、エージェントの実行は銀行の営業時間に縛られず、
週末や跨境、銀行の清算ウィンドウ、商店のアカウント体系に左右されずに済む。
これが、x402やTether WDKのサポート、
そしてUSDT/Tetherエコシステムのt402探索が進む背景だ。
「支払いをエージェントが直接呼び出せるWebスタックのコンポーネントにする」ことを目指している。
ただし、注意も必要だ。
ステーブルコインには問題もある。
「ステーブルコインは貨幣体系の重要な基準（単一性・弾力性・完全性）に欠ける」と指摘されている。
とはいえ、
ステーブルコインは完璧な貨幣ではないが、
エージェント支払いのニーズに最も近い、インターネットネイティブな決済資産の一つだ。
その価値は、「分散化のストーリー」ではなく、
次の条件を満たす点にある：
価格が比較的安定している。
プログラムから呼び出せる。
クロスプラットフォームで流通できる。
24時間365日決済できる。
HTTPネイティブ支払い・ウォレット・スマートコントラクト・オンチェーン監査と連携できる。
これが、エージェント支払いにおいてステーブルコインが不可欠とされる理由だ。
すべての支払いが暗号資産決済になるわけではない。
むしろ、取引対象が「人間の消費者」から「ソフトウェア主体」へと変わるとき、
ステーブルコインは「お金」をインターネットのプロトコルの一部にする最初の一歩となる。
ただし、ステーブルコインは一つの問いにしか答えない：
「エージェントは何の資産で支払うのか？」
もう一つの問い、「エージェントがオープンネット上で支出した後、その資金は誰の権限下にあり、どこに使われたのか、越権はないか、サービスはちゃんと提供されたのか？」には答えられない。
この問いこそ、ブロックチェーンの出番だ。
四、なぜブロックチェーンか：上に載せるためではなく、行動の検証性を担保するため
たとえエージェントがステーブルコインで支払う必要があっても、
なぜブロックチェーンが必要なのか？
中央集権的な台帳でも良いのではないか？
StripeやVisa、銀行、あるいは特定のプラットフォームが記録しても良いのでは？
もちろん可能だ。
もしエージェントが、
Amazonだけで買い物をしたり、特定のSaaSだけを使ったり、
企業内システムだけで調達を完結させるなら、
中央台帳は十分だ。
プラットフォームはユーザやエージェントの権限を把握し、
支払い・サービスの履行・権利管理もできる。
しかし、エージェント支払いの真価は、
むしろ「エージェントが複数のプラットフォームやサービス、ウォレット、国境を越えてタスクを完遂する」場面にある。
このとき、問題は「お金がちゃんと支払われるか」だけではなく、
「誰が権限を与えたのか」「越権はないか」「サービスはちゃんと提供されたか」「何か問題があったとき責任は誰にあるか」だ。
これらの問いに答えるために、
ブロックチェーンは本当に価値がある。
すべての経済行動の記録を、
外部から検証可能な形で残すことができるからだ。
人間の支払いは、
多くの不透明さを許容してきた。
サービス未着、契約違反、カードの誤引き落とし、争議処理などは、
人間社会の長い歴史の中で、
「仕方ない」とされてきた。
しかし、エージェントは違う。
エージェントの取引は、
頻度が高く、金額は小さく、
サービスの数も多く、
実行の連鎖も長い。
すべての取引を人間が後から追跡・証明・検証するのは非現実的だ。
だからこそ、
エージェントは