作者：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エージェントは銀行カードを使うのか？ そして、エージェントが一定段階に達したとき、ほぼ間違いなくステーブルコインとブロックチェーンは不可避なのか？
もしAgentic Paymentが、AIエージェントが最後の支払いを代行するだけのものであれば、 例えば航空券やホテルの予約、SaaSの更新だけなら、 背後で銀行カードやクレジットカード、バーチャルカード、Apple Pay、Stripe、PayPalを使うことに本質的な障壁はない。 使えるし、使うべきだ。
ユーザが事前に権限を与え、エージェントが上限とルール内で支払いを行う。 これは理解しやすいし、実質的にはより賢い自動引き落としや、企業用バーチャルカード、出張用カード、あるいは自動調達システムのようなものだ。
だから、VisaやMastercard、Stripeといった従来の決済プレイヤーは消えない。 むしろ、エージェンシック・コマースの初期段階では重要な入口となる。
StripeとTempoが提案するMachine Payments Protocolは、その良い例だ。 これは単なるステーブルコインの押し付けではなく、 商人がエージェントからの支払いを直接受け入れられる仕組みだ。 ステーブルコインだけでなく、カードやBNPL（後払い）などの法定通貨決済もサポートする。 つまり、エージェントペイメントの初期段階では、従来の決済とステーブルコインは共存し、すぐにどちらかが取って代わるわけではない。 ただし、これはエージェンシック・コマースの一部、checkoutの話だ。
Checkoutの前提は、商品・商人・注文・決済ボタン・返金・紛争処理の仕組みがすでに存在していることだ。 エージェントはあくまでユーザの横に立ち、より自動化された購入を手伝うだけ。
本当に問題になるのは、別のシナリオだ： エージェントは、すでに整ったショッピングカートに入るだけではなく、 オープンネットワーク上で連続的にリソースを呼び出し、サービスを組み合わせ、タスクを完遂する。
例えば、AIリサーチエージェントが業界レポートを作成するために、 複数のデータベースを呼び出し、有料資料を購入し、異なるモデルAPIにアクセスし、クローラーサービスを呼び出し、チャート生成ツールに支払い、 さらには別のエージェントから分析結果の一部を購入する。 この中に伝統的な意味の「ショップ」は存在しないかもしれない。 完全なチェックアウトページもないだろう。 APIやデータインターフェース、モデルサービス、計算ノード、コンテンツリソース、自動化ツール、さらには別のエージェントと連携している可能性もある。
私自身も最近、非常に具体的な例に直面した。 流量分析アシスタントを作りたいと考え、そのためにSemrushのようなデータソースを自動呼び出し、 ウェブサイトの流量やキーワード、競合、マーケットトレンドを分析させたい。 しかし、実際に計画を整理し始めると、「AIが分析できるか」ではなく、「どうやってデータを取得するか」が問題だった。 多くの商用データソースは、「単一呼び出し・単一課金・即時応答」の方式では設計されていない。 SemrushのAPIも、アカウントやパッケージ、APIユニットの枠組みになっている。 APIリクエストごとに一定のAPIユニットを消費し、ユーザはAPIアクセス権やAPIユニットパッケージを購入する必要がある。 Trends APIも単体購入可能だが、やはりAPIユニットベースだ。
しかし、エージェントにとってこのモデルは自然ではない。 もしエージェントが、たまに流量データを呼び出すだけなら、 アカウント登録やAPIユニットの購入ではなく、 ウェブページにアクセスするようにリクエストを発行したいだけだ： このデータはいくら？ 購入権はあるか？ 予算内なら支払い、すぐに結果を得たい。
これがエージェントと従来のAPI商用モデルの断絶だ。 今日の多くのAPI課金方式は、「人間の企業がソフトウェアを調達する」ために設計されており、 「機械が必要に応じてリソースを買う」ことには最適化されていない。
だから、Agentic Paymentの問題は、「最後の一歩の支払いができるか」ではなく、 タスク全体の中で、機械が継続的に権限を得て支払いを発し、 納品を検証し、決済を完了させる仕組みだ。
これが、銀行カード体系の限界だ。
単に遅れているわけではなく、もともと人間の消費シーンを対象にしていたからだ： 人が商店に入り、商品を選び、注文を確定し、支払いを完了させる。 その後、銀行やカード組織、決済代行業者が権限付与・清算・リスク管理・紛争処理を行う。
しかし、エージェント経済は別の問題を抱える： このエージェントは何の権限でお金を使うのか？ サービス提供者は、これは悪意のボットではなく、ユーザの真意の延長だとどう確認するのか？ エージェントは、人工的な確認なしに少額・高頻度・クロスプラットフォームの支払いを完了できるのか？ サービス側は支払い後、即座にリソースを解放できるのか？ エージェントが誤購入・越権・攻撃された場合、責任は誰にあるのか？
これらの問いに答えるために、GoogleはAP2を開発した。 「どの決済手段を使うか」ではなく、 より汎用的なエージェント支払いの信頼フレームワークを構築したのだ。 Googleの公式解説によると、AP2は「決済に依存しないフレームワーク」だ。 ユーザ・商人・決済サービスが異なる決済方式間で、 エージェント主導の支払いをより信頼して完結できるように設計されている。 また、AP2仕様は、エージェントが安全かつシンプルに、 ユーザのスコープされた権限を得て行動できる仕組みを明示している。 セキュリティは、ユーザと商人が暗号署名を行うことで担保される。
したがって、Agentic Paymentの最初の問題は： **「お金はどこから引き落とすのか」**ではなく、 **「エージェントは何の権限でお金を使えるのか」**だ。
この問いに対して、銀行カード体系は一部解決策を持つ。 仮想カードやトークン化資格情報、上限管理、企業経費管理、リスクルールなどだ。 これらを使えば、エージェントは既存の商用インフラ内で取引できる。
Visaもこの方向を進めている。 その代表例が、Intelligent CommerceとTrusted Agent Protocolだ。 これは、AIエージェントが商人のネットワーク内で認識・信頼・権限を得て、 消費者や企業の代理として取引を完結できる仕組みだ。 Visa DeveloperのTrusted Agent Protocolの説明も明快だ： AIエージェントは、ユーザのブラウジングや商品発見、価格比較、選択を支援し、 商取引はチェックアウト前の段階から始まっている。 これらの自動化されたアクセスは、従来はボットとみなされ、ブロックされることもあった。
これからわかるのは、従来の決済ネットワークも同じ問題を見ているということだ： エージェント経済は、支払いボタンの瞬間だけではなく、 検索・比較・選択・権限付与・最終支払いまでの一連の流れだ。 しかし、カードネットワークは得意なのは、 エージェントが既存のコマースフローに入り、権限付与された取引を完結させることだ。 自然に解決できるのは、「オープンネットワーク上でAPIやデータ、モデル、計算リソース、コンテンツ、他のエージェントに対して継続的に小額支払いを行う」仕組みではない。
だから、銀行カードは不可能ではない。 より正確には、エージェント経済のcheckout問題は解決できる。 しかし、エージェント経済が求めるのは、より根底にある支払いの原生性と、 それを支える新しい決済プロトコルだ。
これが次の段階の問いだ： もし取引対象が伝統的な商店ではなく、APIやモデル、データインターフェース、さらには別のエージェントだったら、 機械間でどうやって支払いを呼び出し、完結させるのか？ これが、x402やL402、T402といったプロトコルの議論が始まった背景だ。
もし取引対象が伝統的な商店なら、 エージェントは既存のチェックアウトフローに入り、 クレジットカードやデビットカード、バーチャルカード、ウォレットを使って支払える。 しかし、取引対象がAPIやモデル、データインターフェース、コンテンツ、さらには別のエージェントだったら、 話は変わる。
このとき、機械間に必要なのは、「支払いボタン」ではなく、 機械が理解できる支払いの流れだ： エージェントはリソースをリクエストし、 サービス側はそれに対して「このリソースは支払いが必要です」「価格はいくらです」「受取アドレスはどこです」「どの支払い方法をサポートします」と返す。 エージェントは、その支払いがユーザの権限範囲内かどうか判断し、 ルールに適合すれば支払いを完了させる。 サービス側は支払いを検証し、リソースを解放する。
この流れは非常にシンプルに見えるが、 実はインターネットの過去に欠けていた層を補うものだ： ネイティブな支払い層だ。 従来、インターネットは情報の流れを自然にサポートしてきた。 ウェブページはリクエストされ、メールは送信され、APIは呼び出され、ファイルはダウンロードされる。 しかし、「支払い」は本来のインターネットプロトコルの一部ではなく、 別システムに外付けされていた： アカウント登録、カード連携、決済ゲートウェイ接続、パッケージ購入、APIキー管理、月次請求。
これは人間にとっては許容できる。 登録・ログイン・カード登録・承認・調達・経費精算は面倒だが、 人間はそれをこなせる。
しかし、エージェントにとっては重すぎる。 API呼び出しごとにアカウント登録やパッケージ購入を求められるのは非効率だ。 少額・高頻度の呼び出しのために、 人間の支払い・調達フローを踏む必要はない。
これがx402の登場理由だ。 HTTPの長らく眠っていたステータスコード402 Payment Requiredを再活性化させた。 これにより、サービス側はHTTPレベルで、 「このリソースにアクセスするには支払いが必要です」と直接伝えられる。 クライアントは人でも機械でもよい。 支払いが完了すれば、サービスは検証し、APIやコンテンツを返す。
Coinbaseはx402をこう定義している： 「HTTPを通じて即時・自動のステーブルコイン支払いを実現するオープンプロトコル」だ。 これにより、人間・機械のクライアントは、アカウントやセッション、複雑な認証なしに、 プログラム的に支払い・アクセスが可能になる。
ここで重要なのは、「Coinbaseを使うかどうか」や、「USDCを使うかどうか」ではない。 本当に重要なのは、x402が支払いをインターネットのリクエスト-レスポンスの流れに組み込んだことだ。
従来はこうだった：
これをx402はこう変える：
これがエージェンシック・ペイメントにとって非常に重要だ。 なぜなら、エージェントの取引は少数の大きな買い物ではなく、 大量の小額・リアルタイム・オンデマンドのサービス呼び出しになる可能性が高いからだ。
もしすべてのサービスがアカウントやサブスクリプション、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エージェントにとって重要だ。なぜなら、エージェントはプログラム的にリソースに支払いを行う必要があるからだ。 x402は支払いをWebスタックの一部にし、リクエストの中で価格を見つけ、支払いを署名し、リソースを得ることを可能にする。 また、t402プロジェクトは、インターネットネイティブな支払いのオープンスタンダードとして、 暗号資産・法定通貨・ステーブルコイン・トークンなど多様な価値形態をサポートし、Tether WDKとも互換性を持つことを目指している。 ここで注意したいのは、「すでにTether公式の標準になった」と書くのは早計で、 より正確には、USDT/Tetherエコシステムの中で、x402のようなプロトコルの模索が進んでいる、ということだ。
これは、エージェンシック・ペイメントが、 単一企業や単一チェーンの製品競争ではなく、新たなプロトコルスタックの形成を意味している。
これらは一つの層ではなく、重層的に連携して、 真のエージェンシック・ペイメントの基盤を形成している。 さもなければ、こうなる： AIは賢く、サービスや決定も自動化できるが、 支払いになるとまた人間の従来のフローに戻る。 登録・カード連携・パッケージ購入・請求照合・問い合わせ・クレーム処理。 それでは、エージェンシック・ペイメントではなく、ただのボタン操作のブラウザ補助に過ぎない。
もちろん、楽観しすぎてはいけない。 エージェントがオンチェーン決済に接続するのはリスクも伴う。 従来の決済は争議や凍結・取消も可能だが、 オンチェーンは一度送信すれば基本的に取り消せない。 エージェントが攻撃されたら？ ユーザの権限範囲が広すぎたら？ サービス側が支払いだけして商品やサービスを提供しなかったら？ 悪意のサイトに誘導されたら？ エージェントが一晩で予算を使い果たしたら？ これらは決して小さな問題ではない。
だから、エージェンシック・ペイメントは、 単にエージェントに財布を持たせて「さあ、使え」とすることではない。 むしろ、包括的なコントロールメカニズムが必要だ： 上限設定、ホワイトリスト・ブラックリスト、権限範囲、リスクレベル、人工確認、一時停止、監査記録。 少額・低リスク・機械原生の呼び出しは自動化できるが、 大額・高リスク・実世界の履行を伴う取引は、やはり人間の確認に戻すべきだ。
だから、私はブロックチェーンの役割をこう理解したい： それは、Web3が従来の金融より優れていることを証明するためではなく、 エージェントの経済行動に対して、 「信頼できる証跡」を提供するためだ。
エージェントは人間ではない。 「当時こう考えた」という説明はできない。 外部から検証可能な証拠の連鎖が必要だ。
これが、AP2やx402、ステーブルコイン、ブロックチェーンが、 しばしば同じ図に語られる理由だ。 しかし、それらは本質的に異なる層だ。 AP2は、あくまで「エージェントの権限と信頼の枠組み」。 x402やL402、T402は、「リクエスト時の支払い要求とリソース取得の仕組み」。 ステーブルコインは、「決済資産」。 ブロックチェーンは、「検証可能な状態と履歴の層」だ。
これらは一つの層ではないが、連携してこそ、 真のエージェンシック・ペイメントの基盤となる。 さもなければ、こうなる： AIは賢く、サービスや決定も自動化できるが、 支払いだけは人間の従来のフローに戻る。 登録・カード連携・パッケージ購入・請求照合・問い合わせ・クレーム処理。 それでは、エージェンシック・ペイメントではなく、ただのボタン操作のブラウザ補助に過ぎない。
もちろん、リスクもある。 オンチェーン決済は争議や凍結のリスクが低い反面、 一度送信すれば取り消しは基本的にできない。 エージェントが攻撃されたら？ 権限範囲が広すぎたら？ 支払いだけして商品やサービスを提供しなかったら？ 悪意のサイトに誘導されたら？ 予算を一晩で使い果たしたら？ これらは決して小さな問題ではない。
だからこそ、エージェンシック・ペイメントは、 単にエージェントに財布を持たせて「さあ、使え」とすることではなく、 包括的なコントロールと証跡の仕組みが必要だ。 少額・低リスクの自動呼び出しは自動化しつつも、 大額・高リスクの取引は人間の確認に戻す。
そうしたとき、ブロックチェーンの役割は、 「Web3の優越性を証明するため」ではなく、 「エージェントの経済行動に信頼性を持たせるため」の証跡層だ。
もしエージェントが、機械が理解でき、かつ自動的に実行できる支払いプロトコルを本当に必要とするなら、 なぜ最も多く議論されるのはステーブルコインなのか？ BTCやETHではないのか？ 普通の銀行カードではダメなのか？
ここでのポイントは、「暗号資産」そのものではなく、 エージェントが何を支払い資産として必要としているかだ。 エージェントが長期的に資産を保有するなら、 値動きや収益、リスクに関心を持つだろう。 しかし、タスクを完遂するための支払いなら、 最も必要なのは投機的な資産ではなく、 安定した価値単位だ。
例えば、リサーチエージェントがAPIを呼び出すとき、 0.1ドルかもしれない。 コーディングエージェントがモデル推論を呼び出すとき、 0.03ドルかもしれない。 マーケティングエージェントが流量データを購入するとき、 1ドルかもしれない。 調達エージェントが自動的に価格比較・注文・支払いを行うとき、 予算内でコストを管理したい。
これらのシナリオでは、 エージェントは取引や投機をしているわけではなく、 あくまでタスクを完遂している。 だから、 「このリソースはいくらか」「今回の呼び出しは予算内か」「ユーザの権限内か」「サービス提供後のコストは正確に記録できるか」 が重要になる。
もし支払い資産自体が日々大きく変動したら、 予算管理は非常に難しくなる。 今日0.1ドルだったAPI呼び出しが、明日値動きで0.12ドルや0.08ドルになったら、 市場では問題なくても、機械が必要に応じてリソースを買うには不都合だ。
これが、エージェンシック・ペイメントにおいて、 ステーブルコインがより自然に出現する理由だ。 ステーブルコインの第一の価値は、 より現実の商取引に近い価値単位を提供することにある。 今日、多くのAPIやSaaS、データサービス、モデルサービス、クラウドサービスはドル建てだ。 エージェントがこれらをオンデマンドで買うなら、 ドルステーブルコインを使えば、予算・価格・権限・請求を一つの単位にまとめられる。
これは非常にシンプルだが、エージェントにとっては重要だ。 なぜなら、エージェントは「支払い」だけではなく、「判断」も必要だからだ。 この呼び出しは価値があるのか？ 予算内か？ ユーザの承認は得られているか？ サービス完了後のコストは正確に記録できるか？ もし支払い資産が日々変動したら、 予算管理は複雑になる。 今日0.1ドルのAPI呼び出しが、明日0.12ドルや0.08ドルになったら、 それは市場の問題だが、 機械のリソース購入には不都合だ。
だから、エージェンシック・ペイメントには、 安定した価値単位、すなわちステーブルコインがより適している。 第一の理由は、より現実的な価値単位を提供できること。 今日の多くのサービスはドル建てだ。 エージェントがこれらをオンデマンドで買うなら、 ドルステーブルコインを使えば、予算・価格・権限・請求を一つの単位にできる。
次に、ステーブルコインは、小額・高頻度・即時決済に適している。 前述のx402の例でも見た通り、 HTTPを通じて即時・自動のステーブルコイン支払いを実現し、 APIやデジタルコンテンツ、サービスの支払いを人間・機械の両方に可能にする。 この仕組みは、まさに小額・高頻度・オンデマンドのシナリオに最適だ。
例えば、データクエリ1回、モデル呼び出し1回、コンテンツ解放1回、オンチェーン分析1回、グラフ生成1回。 Tether WDKのx402ドキュメントも、こう述べている： 「AIエージェントは、プログラム的にリソースに支払いを行う必要があり、x402はリクエスト-レスポンスサイクル内で価格を見つけ、支払いを署名し、リソースを得ることを可能にする。」
これは銀行カードの使い方とは異なる。 銀行カードは人間の消費のための決済手段だ。 一方、ステーブルコインは、機械がリソースを呼び出すときの即時決済資産としてより適している。 もちろん、銀行カードも消えない。 StripeやTempoのMachine Payments Protocolは、 オンチェーンの暗号決済と、カードやウォレットを使った法定通貨決済の両方をサポートしている。
したがって、「ステーブルコインが銀行カードの代わりになる」ではなく、 銀行カードは既存の商用ネットワークやチェックアウトの場面に適している。 ステーブルコインは、オープンネットワーク上の機械によるオンデマンド支払いに適している。
第三の価値は、ステーブルコインはクロスプラットフォーム・クロスボーダーに最適だということだ。 エージェントは一つのプラットフォームだけで動いているわけではない。 米国のAPI、ヨーロッパのモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツール、他のエージェントと取引… これらをまたいで動く。 銀行口座や決済代行、ローカルな支払い手段、決済サイクルの違いにより、 全体のタスクチェーンは分断されてしまう。 しかし、ステーブルコインはインターネットネ
492.04K 人気度
58.72M 人気度
37.69K 人気度
1M 人気度
32.45K 人気度
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は使えないのか？
もしエージェントが、私の代わりに航空券を買ったり、ホテルを予約したり、SaaSの契約を更新したりするだけなら、
既存の決済システムを呼び出すことは理論上全く問題ない。
ユーザが一度権限を与えれば、エージェントは上限とルール内で支払いを実行し、
背後では銀行カード、バーチャルカード、企業アカウント、サードパーティの決済ウォレットを使う。
これは不自然ではない。
だから、「銀行カードが使えるかどうか」が問題ではない。
もちろん使える。
本当の問いは：
銀行カードやクレジットカードは、エージェントのどの部分を解決し、どの部分を解決できないのか？
AIエージェントは銀行カードを使うのか？
そして、エージェントが一定段階に達したとき、ほぼ間違いなくステーブルコインとブロックチェーンは不可避なのか？
一、銀行カードはチェックアウトを解決するが、エージェント経済（Agent Economy）を解決しない
もしAgentic Paymentが、AIエージェントが最後の支払いを代行するだけのものであれば、
例えば航空券やホテルの予約、SaaSの更新だけなら、
背後で銀行カードやクレジットカード、バーチャルカード、Apple Pay、Stripe、PayPalを使うことに本質的な障壁はない。
使えるし、使うべきだ。
ユーザが事前に権限を与え、エージェントが上限とルール内で支払いを行う。
これは理解しやすいし、実質的にはより賢い自動引き落としや、企業用バーチャルカード、出張用カード、あるいは自動調達システムのようなものだ。
だから、VisaやMastercard、Stripeといった従来の決済プレイヤーは消えない。
むしろ、エージェンシック・コマースの初期段階では重要な入口となる。
StripeとTempoが提案するMachine Payments Protocolは、その良い例だ。
これは単なるステーブルコインの押し付けではなく、
商人がエージェントからの支払いを直接受け入れられる仕組みだ。
ステーブルコインだけでなく、カードやBNPL（後払い）などの法定通貨決済もサポートする。
つまり、エージェントペイメントの初期段階では、従来の決済とステーブルコインは共存し、すぐにどちらかが取って代わるわけではない。
ただし、これはエージェンシック・コマースの一部、checkoutの話だ。
Checkoutの前提は、商品・商人・注文・決済ボタン・返金・紛争処理の仕組みがすでに存在していることだ。
エージェントはあくまでユーザの横に立ち、より自動化された購入を手伝うだけ。
本当に問題になるのは、別のシナリオだ：
エージェントは、すでに整ったショッピングカートに入るだけではなく、
オープンネットワーク上で連続的にリソースを呼び出し、サービスを組み合わせ、タスクを完遂する。
例えば、AIリサーチエージェントが業界レポートを作成するために、
複数のデータベースを呼び出し、有料資料を購入し、異なるモデルAPIにアクセスし、クローラーサービスを呼び出し、チャート生成ツールに支払い、
さらには別のエージェントから分析結果の一部を購入する。
この中に伝統的な意味の「ショップ」は存在しないかもしれない。
完全なチェックアウトページもないだろう。
APIやデータインターフェース、モデルサービス、計算ノード、コンテンツリソース、自動化ツール、さらには別のエージェントと連携している可能性もある。
私自身も最近、非常に具体的な例に直面した。
流量分析アシスタントを作りたいと考え、そのためにSemrushのようなデータソースを自動呼び出し、
ウェブサイトの流量やキーワード、競合、マーケットトレンドを分析させたい。
しかし、実際に計画を整理し始めると、「AIが分析できるか」ではなく、「どうやってデータを取得するか」が問題だった。
多くの商用データソースは、「単一呼び出し・単一課金・即時応答」の方式では設計されていない。
SemrushのAPIも、アカウントやパッケージ、APIユニットの枠組みになっている。
APIリクエストごとに一定のAPIユニットを消費し、ユーザはAPIアクセス権やAPIユニットパッケージを購入する必要がある。
Trends APIも単体購入可能だが、やはりAPIユニットベースだ。
しかし、エージェントにとってこのモデルは自然ではない。
もしエージェントが、たまに流量データを呼び出すだけなら、
アカウント登録やAPIユニットの購入ではなく、
ウェブページにアクセスするようにリクエストを発行したいだけだ：
このデータはいくら？
購入権はあるか？
予算内なら支払い、すぐに結果を得たい。
これがエージェントと従来のAPI商用モデルの断絶だ。
今日の多くのAPI課金方式は、「人間の企業がソフトウェアを調達する」ために設計されており、
「機械が必要に応じてリソースを買う」ことには最適化されていない。
だから、Agentic Paymentの問題は、「最後の一歩の支払いができるか」ではなく、
タスク全体の中で、機械が継続的に権限を得て支払いを発し、
納品を検証し、決済を完了させる仕組みだ。
これが、銀行カード体系の限界だ。
単に遅れているわけではなく、もともと人間の消費シーンを対象にしていたからだ：
人が商店に入り、商品を選び、注文を確定し、支払いを完了させる。
その後、銀行やカード組織、決済代行業者が権限付与・清算・リスク管理・紛争処理を行う。
しかし、エージェント経済は別の問題を抱える：
このエージェントは何の権限でお金を使うのか？
サービス提供者は、これは悪意のボットではなく、ユーザの真意の延長だとどう確認するのか？
エージェントは、人工的な確認なしに少額・高頻度・クロスプラットフォームの支払いを完了できるのか？
サービス側は支払い後、即座にリソースを解放できるのか？
エージェントが誤購入・越権・攻撃された場合、責任は誰にあるのか？
これらの問いに答えるために、GoogleはAP2を開発した。
「どの決済手段を使うか」ではなく、
より汎用的なエージェント支払いの信頼フレームワークを構築したのだ。
Googleの公式解説によると、AP2は「決済に依存しないフレームワーク」だ。
ユーザ・商人・決済サービスが異なる決済方式間で、
エージェント主導の支払いをより信頼して完結できるように設計されている。
また、AP2仕様は、エージェントが安全かつシンプルに、
ユーザのスコープされた権限を得て行動できる仕組みを明示している。
セキュリティは、ユーザと商人が暗号署名を行うことで担保される。
したがって、Agentic Paymentの最初の問題は：
**「お金はどこから引き落とすのか」**ではなく、
**「エージェントは何の権限でお金を使えるのか」**だ。
この問いに対して、銀行カード体系は一部解決策を持つ。
仮想カードやトークン化資格情報、上限管理、企業経費管理、リスクルールなどだ。
これらを使えば、エージェントは既存の商用インフラ内で取引できる。
Visaもこの方向を進めている。
その代表例が、Intelligent CommerceとTrusted Agent Protocolだ。
これは、AIエージェントが商人のネットワーク内で認識・信頼・権限を得て、
消費者や企業の代理として取引を完結できる仕組みだ。
Visa DeveloperのTrusted Agent Protocolの説明も明快だ：
AIエージェントは、ユーザのブラウジングや商品発見、価格比較、選択を支援し、
商取引はチェックアウト前の段階から始まっている。
これらの自動化されたアクセスは、従来はボットとみなされ、ブロックされることもあった。
これからわかるのは、従来の決済ネットワークも同じ問題を見ているということだ：
エージェント経済は、支払いボタンの瞬間だけではなく、
検索・比較・選択・権限付与・最終支払いまでの一連の流れだ。
しかし、カードネットワークは得意なのは、
エージェントが既存のコマースフローに入り、権限付与された取引を完結させることだ。
自然に解決できるのは、「オープンネットワーク上でAPIやデータ、モデル、計算リソース、コンテンツ、他のエージェントに対して継続的に小額支払いを行う」仕組みではない。
だから、銀行カードは不可能ではない。
より正確には、エージェント経済のcheckout問題は解決できる。
しかし、エージェント経済が求めるのは、より根底にある支払いの原生性と、
それを支える新しい決済プロトコルだ。
これが次の段階の問いだ：
もし取引対象が伝統的な商店ではなく、APIやモデル、データインターフェース、さらには別のエージェントだったら、
機械間でどうやって支払いを呼び出し、完結させるのか？
これが、x402やL402、T402といったプロトコルの議論が始まった背景だ。
二、エージェントが本当に必要なのは、機械が理解できる支払いプロトコル
もし取引対象が伝統的な商店なら、
エージェントは既存のチェックアウトフローに入り、
クレジットカードやデビットカード、バーチャルカード、ウォレットを使って支払える。
しかし、取引対象がAPIやモデル、データインターフェース、コンテンツ、さらには別のエージェントだったら、
話は変わる。
このとき、機械間に必要なのは、「支払いボタン」ではなく、
機械が理解できる支払いの流れだ：
エージェントはリソースをリクエストし、
サービス側はそれに対して「このリソースは支払いが必要です」「価格はいくらです」「受取アドレスはどこです」「どの支払い方法をサポートします」と返す。
エージェントは、その支払いがユーザの権限範囲内かどうか判断し、
ルールに適合すれば支払いを完了させる。
サービス側は支払いを検証し、リソースを解放する。
この流れは非常にシンプルに見えるが、
実はインターネットの過去に欠けていた層を補うものだ：
ネイティブな支払い層だ。
従来、インターネットは情報の流れを自然にサポートしてきた。
ウェブページはリクエストされ、メールは送信され、APIは呼び出され、ファイルはダウンロードされる。
しかし、「支払い」は本来のインターネットプロトコルの一部ではなく、
別システムに外付けされていた：
アカウント登録、カード連携、決済ゲートウェイ接続、パッケージ購入、APIキー管理、月次請求。
これは人間にとっては許容できる。
登録・ログイン・カード登録・承認・調達・経費精算は面倒だが、
人間はそれをこなせる。
しかし、エージェントにとっては重すぎる。
API呼び出しごとにアカウント登録やパッケージ購入を求められるのは非効率だ。
少額・高頻度の呼び出しのために、
人間の支払い・調達フローを踏む必要はない。
これがx402の登場理由だ。
HTTPの長らく眠っていたステータスコード402 Payment Requiredを再活性化させた。
これにより、サービス側はHTTPレベルで、
「このリソースにアクセスするには支払いが必要です」と直接伝えられる。
クライアントは人でも機械でもよい。
支払いが完了すれば、サービスは検証し、APIやコンテンツを返す。
Coinbaseはx402をこう定義している：
「HTTPを通じて即時・自動のステーブルコイン支払いを実現するオープンプロトコル」だ。
これにより、人間・機械のクライアントは、アカウントやセッション、複雑な認証なしに、
プログラム的に支払い・アクセスが可能になる。
ここで重要なのは、「Coinbaseを使うかどうか」や、「USDCを使うかどうか」ではない。
本当に重要なのは、x402が支払いをインターネットのリクエスト-レスポンスの流れに組み込んだことだ。
従来はこうだった：
これをx402はこう変える：
これがエージェンシック・ペイメントにとって非常に重要だ。
なぜなら、エージェントの取引は少数の大きな買い物ではなく、
大量の小額・リアルタイム・オンデマンドのサービス呼び出しになる可能性が高いからだ。
もしすべてのサービスがアカウントやサブスクリプション、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エージェントにとって重要だ。なぜなら、エージェントはプログラム的にリソースに支払いを行う必要があるからだ。
x402は支払いをWebスタックの一部にし、リクエストの中で価格を見つけ、支払いを署名し、リソースを得ることを可能にする。
また、t402プロジェクトは、インターネットネイティブな支払いのオープンスタンダードとして、
暗号資産・法定通貨・ステーブルコイン・トークンなど多様な価値形態をサポートし、Tether WDKとも互換性を持つことを目指している。
ここで注意したいのは、「すでにTether公式の標準になった」と書くのは早計で、
より正確には、USDT/Tetherエコシステムの中で、x402のようなプロトコルの模索が進んでいる、ということだ。
これは、エージェンシック・ペイメントが、
単一企業や単一チェーンの製品競争ではなく、新たなプロトコルスタックの形成を意味している。
これらは一つの層ではなく、重層的に連携して、
真のエージェンシック・ペイメントの基盤を形成している。
さもなければ、こうなる：
AIは賢く、サービスや決定も自動化できるが、
支払いになるとまた人間の従来のフローに戻る。
登録・カード連携・パッケージ購入・請求照合・問い合わせ・クレーム処理。
それでは、エージェンシック・ペイメントではなく、ただのボタン操作のブラウザ補助に過ぎない。
もちろん、楽観しすぎてはいけない。
エージェントがオンチェーン決済に接続するのはリスクも伴う。
従来の決済は争議や凍結・取消も可能だが、
オンチェーンは一度送信すれば基本的に取り消せない。
エージェントが攻撃されたら？
ユーザの権限範囲が広すぎたら？
サービス側が支払いだけして商品やサービスを提供しなかったら？
悪意のサイトに誘導されたら？
エージェントが一晩で予算を使い果たしたら？
これらは決して小さな問題ではない。
だから、エージェンシック・ペイメントは、
単にエージェントに財布を持たせて「さあ、使え」とすることではない。
むしろ、包括的なコントロールメカニズムが必要だ：
上限設定、ホワイトリスト・ブラックリスト、権限範囲、リスクレベル、人工確認、一時停止、監査記録。
少額・低リスク・機械原生の呼び出しは自動化できるが、
大額・高リスク・実世界の履行を伴う取引は、やはり人間の確認に戻すべきだ。
だから、私はブロックチェーンの役割をこう理解したい：
それは、Web3が従来の金融より優れていることを証明するためではなく、
エージェントの経済行動に対して、
「信頼できる証跡」を提供するためだ。
エージェントは人間ではない。
「当時こう考えた」という説明はできない。
外部から検証可能な証拠の連鎖が必要だ。
これが、AP2やx402、ステーブルコイン、ブロックチェーンが、
しばしば同じ図に語られる理由だ。
しかし、それらは本質的に異なる層だ。
AP2は、あくまで「エージェントの権限と信頼の枠組み」。
x402やL402、T402は、「リクエスト時の支払い要求とリソース取得の仕組み」。
ステーブルコインは、「決済資産」。
ブロックチェーンは、「検証可能な状態と履歴の層」だ。
これらは一つの層ではないが、連携してこそ、
真のエージェンシック・ペイメントの基盤となる。
さもなければ、こうなる：
AIは賢く、サービスや決定も自動化できるが、
支払いだけは人間の従来のフローに戻る。
登録・カード連携・パッケージ購入・請求照合・問い合わせ・クレーム処理。
それでは、エージェンシック・ペイメントではなく、ただのボタン操作のブラウザ補助に過ぎない。
もちろん、リスクもある。
オンチェーン決済は争議や凍結のリスクが低い反面、
一度送信すれば取り消しは基本的にできない。
エージェントが攻撃されたら？
権限範囲が広すぎたら？
支払いだけして商品やサービスを提供しなかったら？
悪意のサイトに誘導されたら？
予算を一晩で使い果たしたら？
これらは決して小さな問題ではない。
だからこそ、エージェンシック・ペイメントは、
単にエージェントに財布を持たせて「さあ、使え」とすることではなく、
包括的なコントロールと証跡の仕組みが必要だ。
少額・低リスクの自動呼び出しは自動化しつつも、
大額・高リスクの取引は人間の確認に戻す。
そうしたとき、ブロックチェーンの役割は、
「Web3の優越性を証明するため」ではなく、
「エージェントの経済行動に信頼性を持たせるため」の証跡層だ。
三、なぜステーブルコインか：エージェントは安定した価値単位を必要とする
もしエージェントが、機械が理解でき、かつ自動的に実行できる支払いプロトコルを本当に必要とするなら、
なぜ最も多く議論されるのはステーブルコインなのか？
BTCやETHではないのか？
普通の銀行カードではダメなのか？
ここでのポイントは、「暗号資産」そのものではなく、
エージェントが何を支払い資産として必要としているかだ。
エージェントが長期的に資産を保有するなら、
値動きや収益、リスクに関心を持つだろう。
しかし、タスクを完遂するための支払いなら、
最も必要なのは投機的な資産ではなく、
安定した価値単位だ。
例えば、リサーチエージェントがAPIを呼び出すとき、
0.1ドルかもしれない。
コーディングエージェントがモデル推論を呼び出すとき、
0.03ドルかもしれない。
マーケティングエージェントが流量データを購入するとき、
1ドルかもしれない。
調達エージェントが自動的に価格比較・注文・支払いを行うとき、
予算内でコストを管理したい。
これらのシナリオでは、
エージェントは取引や投機をしているわけではなく、
あくまでタスクを完遂している。
だから、
「このリソースはいくらか」「今回の呼び出しは予算内か」「ユーザの権限内か」「サービス提供後のコストは正確に記録できるか」
が重要になる。
もし支払い資産自体が日々大きく変動したら、
予算管理は非常に難しくなる。
今日0.1ドルだったAPI呼び出しが、明日値動きで0.12ドルや0.08ドルになったら、
市場では問題なくても、機械が必要に応じてリソースを買うには不都合だ。
これが、エージェンシック・ペイメントにおいて、
ステーブルコインがより自然に出現する理由だ。
ステーブルコインの第一の価値は、
より現実の商取引に近い価値単位を提供することにある。
今日、多くのAPIやSaaS、データサービス、モデルサービス、クラウドサービスはドル建てだ。
エージェントがこれらをオンデマンドで買うなら、
ドルステーブルコインを使えば、予算・価格・権限・請求を一つの単位にまとめられる。
これは非常にシンプルだが、エージェントにとっては重要だ。
なぜなら、エージェントは「支払い」だけではなく、「判断」も必要だからだ。
この呼び出しは価値があるのか？
予算内か？
ユーザの承認は得られているか？
サービス完了後のコストは正確に記録できるか？
もし支払い資産が日々変動したら、
予算管理は複雑になる。
今日0.1ドルのAPI呼び出しが、明日0.12ドルや0.08ドルになったら、
それは市場の問題だが、
機械のリソース購入には不都合だ。
だから、エージェンシック・ペイメントには、
安定した価値単位、すなわちステーブルコインがより適している。
第一の理由は、より現実的な価値単位を提供できること。
今日の多くのサービスはドル建てだ。
エージェントがこれらをオンデマンドで買うなら、
ドルステーブルコインを使えば、予算・価格・権限・請求を一つの単位にできる。
次に、ステーブルコインは、小額・高頻度・即時決済に適している。
前述のx402の例でも見た通り、
HTTPを通じて即時・自動のステーブルコイン支払いを実現し、
APIやデジタルコンテンツ、サービスの支払いを人間・機械の両方に可能にする。
この仕組みは、まさに小額・高頻度・オンデマンドのシナリオに最適だ。
例えば、データクエリ1回、モデル呼び出し1回、コンテンツ解放1回、オンチェーン分析1回、グラフ生成1回。
Tether WDKのx402ドキュメントも、こう述べている：
「AIエージェントは、プログラム的にリソースに支払いを行う必要があり、x402はリクエスト-レスポンスサイクル内で価格を見つけ、支払いを署名し、リソースを得ることを可能にする。」
これは銀行カードの使い方とは異なる。
銀行カードは人間の消費のための決済手段だ。
一方、ステーブルコインは、機械がリソースを呼び出すときの即時決済資産としてより適している。
もちろん、銀行カードも消えない。
StripeやTempoのMachine Payments Protocolは、
オンチェーンの暗号決済と、カードやウォレットを使った法定通貨決済の両方をサポートしている。
したがって、「ステーブルコインが銀行カードの代わりになる」ではなく、
銀行カードは既存の商用ネットワークやチェックアウトの場面に適している。
ステーブルコインは、オープンネットワーク上の機械によるオンデマンド支払いに適している。
第三の価値は、ステーブルコインはクロスプラットフォーム・クロスボーダーに最適だということだ。
エージェントは一つのプラットフォームだけで動いているわけではない。
米国のAPI、ヨーロッパのモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツール、他のエージェントと取引…
これらをまたいで動く。
銀行口座や決済代行、ローカルな支払い手段、決済サイクルの違いにより、
全体のタスクチェーンは分断されてしまう。
しかし、ステーブルコインはインターネットネ