AIエージェントは銀行カードを使えますか？
エージェンシックペイメントはなぜ安定したコインとブロックチェーンを避けられないのか

作者：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は使えないのか？

もしエージェントが、
私の航空券購入やホテル予約、SaaSの継続課金を手伝うだけなら、
既存の決済システムを呼び出すことは理論上全く問題ない。
ユーザが一度権限を与えれば、エージェントは上限とルール内で支払いを実行し、
背後では銀行カード、バーチャルカード、企業アカウント、サードパーティの決済ウォレットを使う。
これは不自然ではない。

だから、「銀行カードが使えるかどうか」が問題ではない。
もちろん使える。
本当の問題は：
銀行カードやクレジットカードは、エージェントの支払いのどの部分に適していて、どの部分に向いていないのか？
AIエージェントは本当に銀行カードを使うのか？
そして、エージェント的支払いが一定段階に達したとき、ほぼ間違いなくステーブルコインとブロックチェーンを避けて通れなくなるのはなぜか？

一、銀行カードはチェックアウトを解決するが、エージェント経済（Agent Economy）を解決しない

もしAgentic Paymentが、
AIエージェントが最後の支払いを手伝うだけのものであれば、
例えば航空券やホテル予約、SaaSの継続課金の支払いを代行するだけなら、
背後で銀行カードやクレジットカード、バーチャルカード、Apple Pay、Stripe、PayPalを呼び出すことに本質的な障壁はない。
銀行カードも使えるし、クレジットカードも使える。

ユーザが事前に権限を与え、エージェントが上限とルール内で支払いを行う。
これは理解しやすいし、実質的にはより賢い自動引き落としや、企業用バーチャルカード、出張用カード、あるいは自動調達システムのようなものだ。

だから、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ユニットベースだ。

しかし、エージェントにとってこのモデルは自然ではない。
エージェントがたまに流量データを呼び出すだけなら、
単にSaaSアカウントを登録したり、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エージェントは、ユーザのブラウジングや商品発見、価格比較、選択を支援し、
商取引はすでにチェックアウト前から始まっている。
これらの自動化されたアクセスは、従来は商人やCDN、ボット対策サービスによりブロックされてきた。

これは、従来の決済ネットワークも同じ問題を認識していることを示す：
Agentic Commerceは、支払いボタンの瞬間だけではなく、
検索・比較・選択・権限付与・最終支払いまでの一連の流れだ。
しかし、カードネットワークは、
「エージェントが既存のコマースフローに入り、権限付与された取引を完了させる」ことに長けている。
一方、
「エージェントがオープンネット上でAPIやデータ、モデル、計算リソース、コンテンツ、ツール、別のエージェントに対して継続的に小額支払いを行う」仕組みは、自然には解決できていない。

だから、銀行カードは不可能ではない。
より正確には、
銀行カードはエージェントのコマースのチェックアウト問題を解決しているが、
Agent Economyが求めるのは、より根底にある支払いプロトコルの新しい枠組みだ。

これが次の層の問題を引き起こす：
もし取引対象が伝統的な商店ではなく、APIやモデル、データインターフェース、さらには別のエージェントだったら、
機械間でどうやって支払いを呼び出し、完結させるのか？
これが、x402、L402、T402といったプロトコルの議論の背景だ。

二、エージェントが本当に必要なのは、機械が理解できる支払いプロトコル

もし取引対象が伝統的な商店なら、
エージェントは既存のチェックアウトフローに入り、
クレジットカードやデビットカード、バーチャルカード、ウォレットを使って支払える。
しかし、取引対象がAPIやモデル、データインターフェース、コンテンツ、さらには別のエージェントだったら、
問題は変わる。

このとき、機械間に必要なのは、「支払いボタン」ではなく、
機械が理解できる支払いの流れだ：
エージェントはリソースをリクエストし、
サービス側はそれに対して：
「このリソースには支払いが必要です。価格はいくらです。受取アドレスはどこです。どの支払い方法をサポートしますか？」と返す。
エージェントは、その支払いがユーザの権限範囲内か判断し、
ルールに合えば支払いを完了させる。
サービス側は支払いを検証し、リソースを解放する。

この流れは非常にシンプルに見えるが、
実はインターネットの過去に欠けていた層を補うものだ：
ネイティブな支払い層だ。
従来、インターネットは情報の流れを自然にサポートしてきた。
ウェブページはリクエストされ、メールは送信され、APIは呼び出され、ファイルはダウンロードされる。
しかし、「支払い」は本来のインターネットプロトコルの一部ではなく、
別のシステムに付加されてきた：
アカウント登録、カード連携、決済ゲートウェイ、パッケージ購入、APIキー管理、月次請求。

これは人間にとっては許容できる。
登録・ログイン・カード連携・承認・調達・経費精算は面倒だが、
人間はそれを理解し、操作できる。

しかし、エージェントにとってはこれが重すぎる。
API呼び出しごとにアカウント登録？
データアクセスごとにパッケージ購入？
数セント・数十セントの少額呼び出しのために、
複雑な人間の支払い・調達フローを踏む必要はない。

これがx402のようなプロトコルが登場した理由だ。

x402はHTTP 402 Payment Requiredという長らく存在しながらほとんど使われてこなかった状態コードを再活性化した。
これにより、サービス側はHTTPレベルで、
「このリソースにアクセスするには支払いが必要です」とクライアントに伝えられる。
クライアントは人でも機械でもよい。
支払いが完了すれば、サービス側は検証し、APIやコンテンツ、デジタルサービスを返す。

Coinbaseはx402の定義をこうしている：
「HTTPを通じて即時・自動的にステーブルコイン支払いを実現するオープンなプロトコルであり、
人間や機械のクライアントがアカウントやセッション、複雑な認証なしに、プログラム的に支払いを行い、アクセス権を得ることを可能にする。」

ここで本当に重要なのは、「Coinbaseを使うかどうか」や「USDCを使うかどうか」ではない。
x402は、支払いをインターネットのリクエスト-レスポンスの流れに組み込んだ点だ。

従来はこうだった：

• アカウント登録
• パッケージ購入
• APIキー取得
• サービス呼び出し
• 月次請求・照合

これをx402はこう変える：

• リソースリクエスト
• 402 Payment Requiredを受け取る
• 支払いを完了させる
• リソースを取得

これがエージェント支払いにとって非常に重要だ。
エージェントの取引は、大きな一回の買い物ではなく、
大量の小額・リアルタイム・オンデマンドのサービス呼び出しになる可能性が高い。

例えば：

• ライティングエージェントが記事作成のために一度データクエリを購入
• 投資リサーチエージェントが一つの質問に対してオンチェーン分析サービスを呼び出し
• 旅行エージェントが複数の価格APIに同時に問い合わせ
• 開発エージェントがモデル推論やコードレビュー、テスト環境を都度購入
• 流量分析エージェントが特定のウェブサイトのSemrush類似データを一度だけ買う（SaaSパッケージを丸ごと買う必要はない）

もし、すべてのサービスがアカウントやサブスクリプション、APIキー、パッケージ、人工の承認を必要とするなら、
エージェントの実行能力は支払い・調達のフローに縛られてしまう。
だから、x402の意義は、「より暗号的な支払い」ではなく、
「インターネットのプロトコルのように、リクエスト・レスポンスの中で支払いを完結させる仕組み」を作ることにある。

L402はまた別のアプローチだ。
HTTP 402を軸にしつつ、Bitcoin Lightning Networkやmacaroonsといったアクセス証明や少額決済を組み合わせる。
Lightning LabsはL402をこう定義している：
「APIエンドポイントや計算リソースなどのサービスの認証と取引を促進し、
サービス側がAPIエンドポイントに対して課金できる仕組みを作る。
これにより、AIエージェントも参加しやすくなる。」

L402は、
この問題はx402が突然発明されたわけではなく、
以前から試みられてきたことだと示す。
HTTPアクセス制御・少額決済・デジタルサービスの権限付与を一体化しようとした動きはあったが、
十分な需要がなかっただけだ。

人間はAPIに数セント払うことはほとんどしない。
しかし、エージェントは払う。
人間は一日に何百ものデータソースを自動呼び出ししない。
しかし、エージェントはやる。
人間はリアルタイムで複数サービスを呼び出し、価格を比較し、支払い、検証を行わない。
しかし、エージェントはやる。

だから、AIエージェントの登場により、HTTPネイティブな支払いの道筋が一気に現実味を帯びてきた。

USDT/Tetherエコシステムでも、似た方向性が出てきている。
Tether WDKのx402ドキュメントには、
「x402はAIエージェントにとって重要だ」と明記されている。
「エージェントはプログラム的にリソースに支払い、
リクエスト・レスポンスの中で価格を見つけ、支払いを署名し、リソースを得ることができる」
と。
また、t402プロジェクトは、「インターネットネイティブな支払い」のオープンスタンダードを目指し、
Crypto・Fiat・Stablecoin・Tokenなど多様な価値をサポートし、Tether WDKとも互換性を持つと自己紹介している。
ただし、これは「Tether公式標準になった」とは言わず、
むしろ、USDT/Tetherエコシステムの中で、x402のようなプロトコルの模索が進んでいる段階だ。

この背景には、
Agentic Paymentは単なる企業やプロジェクトの競争ではなく、
新たなプロトコルスタックの形成を促しているという大きな流れがある。

• AP2は、「エージェントは何の権限で支払うのか？」という問いに答える枠組み
• x402、L402、T402は、「エージェントがリソースをリクエストしたとき、サービス側はどう支払い要求を出し、エージェントはどう支払い・取得を完了させるのか？」という問いに答える
• Stablecoinとブロックチェーンは、「この資金は何の資産で決済され、どこで検証されるのか、低コスト・リアルタイム・プログラム可能・クロスプラットフォームをどう実現するのか？」に答える

これらは一つの層ではなく、重層的に連携してこそ、
真のAgentic Paymentの基盤となる。
さもなければ、
AIは賢いが、支払いは人間のやり方のまま、という状態になってしまう。

三、なぜ安定コインか：エージェントは安定した価値単位を必要とする

もしエージェントが、
機械が理解できて自動実行できる支払いプロトコルを本当に必要とするなら、
なぜ最も議論されるのはステーブルコインなのか？
BTCやETHではダメなのか？
普通の銀行カードではダメなのか？

このポイントは、「暗号資産」そのものではなく、
エージェントが何を支払い資産として必要としているかにある。
エージェントが長期的に資産を持ち続けるなら、
値動きやリターン、リスクに関心を持つだろう。
しかし、タスク完了のために支払うエージェントにとっては、
投機的な資産よりも、安定した価値単位が最優先だ。

例えば、リサーチエージェントがAPIを呼び出すのに0.1ドルかかるとしよう。
コーディングエージェントがモデル推論を呼び出すのに0.03ドル。
マーケティングエージェントが流量データを購入するのに1ドル。
調達エージェントが自動的に価格比較・注文・支払いを行うとき、
予算内でコストを正確に管理できる必要がある。

これらのシナリオでは、
エージェントは取引や投機をしているわけではなく、
あくまでタスクを完遂している。
だから、
「このリソースはいくらか？」
「今回の呼び出しは予算内か？」
「支払いはユーザの権限範囲内か？」
「サービス提供後のコストは正確に記録できるか？」
といった情報を知る必要がある。

もし支払い資産自体が日々大きく変動したら、
エージェントの予算管理は非常に複雑になる。
今日0.1ドルだったAPI呼び出しが、明日には0.12ドルや0.08ドルに変動したら、
取引市場には関係なくとも、
機械による必要資源の購入には余計な複雑さをもたらす。

だからこそ、Agentic Paymentには、
高い変動性を持たず、機械が理解でき、
プログラムから直接呼び出せる支払い資産が求められる。
それが、BTCやETHよりも、安定コインのほうが適している理由だ。

二つ目の価値は、
安定コインは小額・高頻度・即時決済に適していることだ。
前述のx402の話でも見た通り、
Coinbaseはx402を通じて、
HTTP上で即時・自動的なステーブルコイン支払いを実現し、
APIやデジタルコンテンツ、サービスの対人・機械クライアントへの課金を可能にしている。
この仕組みは、
支払いが「完結したチェックアウトページ」だけでなく、
「APIリクエストの中で完結」することを意味している。

エージェントはリクエストを送り、
サービス側は402 Payment Requiredを返し、
エージェントは支払いを行い、
リソースを取得する。

この流れは、小額・高頻度・オンデマンドのシナリオに最適だ。
例：データクエリ、モデル呼び出し、コンテンツ解放、オンチェーン分析、チャート生成。
Tether WDKのx402ドキュメントも、
「AIエージェントはプログラム的にリソースに支払い、
価格を見つけ、署名し、リソースを得る」ことを明示している。

これは銀行カードの使い方とは全く異なる。
銀行カードは人間の消費のための決済手段だ。
一方、安定コインは、
機械がリソースを呼び出すときの即時決済資産として最適だ。
もちろん、銀行カードが消えるわけではない。
StripeやTempoのMachine Payments Protocolは、
「オンチェーンの暗号資産決済」と「カードやウォレットを使った法定通貨決済」の両方をサポートしている。

したがって、より正確な理解はこうだ：
「安定コインは銀行カードの代わりではなく、
機械によるリソース呼び出しのための即時決済資産」だ。

三つ目の価値は、
安定コインはクロスプラットフォーム・クロスボーダーに最適だということだ。
エージェントは一つのプラットフォームだけで動いているわけではない。
米国のAPI、ヨーロッパのモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツール、さらには別のエージェントと取引することもある。
もし、それぞれの段階で銀行口座や決済代行、ローカルな支払い手段、決済サイクルに依存していたら、
全体のタスクはバラバラになってしまう。
しかし、安定コインはインターネットネイティブの資産だ。
24時間365日流通し、クロスプラットフォーム・クロスウォレット・クロスアプリケーションで呼び出せる。
スマートコントラクトや決済プロトコルとも直接連携できる。
これは人間にとっては「早く着金」だが、
エージェントにとっては、
「時間に縛られず、いつでもどこでも自動的に決済できる」ことを意味する。

これにより、
週末や跨境、銀行の清算窓口、商店のアカウント体系に左右されずに、
エージェントのタスクは中断されない。
いつでも、どこでも、誰でも、どんなサービスとも自動的に支払い・決済できる資産が必要だ。

これが、x402やTether WDKのサポート、そしてUSDT/Tetherエコシステムのt402探索が進む背景だ。
「安定コイン決済を、機械が直接呼び出せるWebスタックのコンポーネントにする」ことを目指している。

ただし、ここに一つ冷水を浴びせる必要もある。
安定コインには問題もある。

異なる安定コインの準備金の透明性、発行主体、規制状況、償還能力、オンチェーンの流動性はさまざまだ。
BISの2025年年次経済報告でも、
安定コインは「単一性」「弾力性」「完全性」の観点で貨幣体系の重要基準を満たしていないと批判されている。
それらは、現代の貨幣体系の完全な代替にはならない。

より正確には、
安定コインは完璧な貨幣ではないが、
Agentic Paymentのニーズに最も近い、インターネットネイティブな決済資産の一つだ。

その価値は、「分散化の物語」ではなく、
次の条件を満たす点にある：
価格が比較的安定している。
プログラムから呼び出せる。
クロスプラットフォームで流通できる。
24時間365日決済できる。
HTTPネイティブな支払い、ウォレット、スマートコントラクト、オンチェーン監査と連携できる。

これが、Agentic Paymentにおいて安定コインが自然に出てくる理由だ。
「クレジットカードのような人間の手」が必要なのではなく、
ソフトウェアが直接理解・利用できる「お金」が必要なのだ。

もし、クレジットカードが人間の消費のために設計された決済手段なら、
安定コインは、
機械経済のための決済言語に近い。

もちろん、この言語はまだ未成熟だ。
より良い規制枠組み、安定した発行メカニズム、明確なリスク管理、権限管理の改善、
AP2やx402、MPPといったプロトコルとの連携も必要だ。
それらが揃って初めて、大規模に使えるAgentic Paymentのシナリオに入る。

しかし、方向性は明確だ：
エージェントは安定した価格単位を必要とし、
即時決済できる資産を必要とし、
プログラムから呼び出せるお金を必要とし、
クロスプラットフォーム・クロス国境・クロスサービスの決済能力を求めている。

これが、安定コインがAgentic Paymentにおいて無視できない理由だ。
すべての支払いが暗号資産になるわけではない。
しかし、取引対象が「人間の消費者」から「ソフトウェア主体」に変わるとき、
安定コインは「お金」をインターネットプロトコルの一部にする最初の一歩となる。

ただし、安定コインは一つの問いにしか答えていない：
「エージェントは何の資産で支払うのか？」
もう一つの問いには答えていない：
「エージェントがオープンネットで支出した後、その資金は誰に権限付与され、どこに使われ、越権はないか、サービスはちゃんと提供されたか？」
この問いこそが、ブロックチェーンの出番だ。

四、なぜブロックチェーンか：上に載せるためではなく、エージェントの行動を検証可能にするため

たとえエージェントが安定コインで支払う必要があっても、
なぜブロックチェーンが必要なのか？
中央集権的な台帳ではダメなのか？
StripeやVisa、銀行、あるいは特定のプラットフォームが記録しても良いのでは？

もちろん可能だ。
もしエージェントが、
Amazonだけで買い物をしたり、
特定のSaaSだけを呼び出したり、
企業内システムだけで調達したりするなら、
中央台帳は十分だ。
プラットフォームはユーザやエージェントを把握し、
権限や支出も管理できる。

しかし、
Agentic Paymentの本質は、
エージェントが複数のプラットフォームやサービス、ウォレット、国境を越えて、
一つのタスクを完遂