著者： Stablehunter
先週、香港で開催されたWeb3フェスティバルに参加したのですが、そこで強く感じたのは、今やほとんどすべてのフォーラムやパネルディスカッションがAIを中心に展開しているということでした。
当初の議論が決済、ステーブルコイン、RWA、ウォレット、取引所、コンプライアンス、インフラストラクチャのいずれに焦点を当てていたとしても、ほぼ必ず同じ疑問に帰着する。AIがコンテンツを生成するだけでなく、タスクを実行したり、サービスを呼び出したり、意思決定を行ったり、さらには人間の資金の流れを管理したりするようになったとき、既存の金融システムや決済システムは十分なものとなるのだろうか？
私が参加したパネルディスカッションで、ある参加者が「 Web3は単にAIの恩恵を受けているだけなのか？」と直接質問しました。私はそうは思いません。もちろん、流行に乗ろうとするプロジェクトは出てくるでしょう。しかし、AIとWeb3を単なる物語の寄せ集めとしてしか理解しないのであれば、より根本的な変化を見落としてしまうかもしれません。AIは理解、意思決定、行動を担い、Web3は資産、アカウント、決済、そして検証可能な実行環境を提供するのです。これは単に概念を積み重ねるという問題ではなく、役割の再定義なのです。
香港の財務長官であるポール・チャン・モポー氏は、Web3 Festival 2026でのスピーチの中で、AIエージェントが機械のスピードで情報を分析し、行動を起こす一方で、バックグラウンドでブロックチェーンインフラストラクチャを最大限に活用して取引効率を向上させ、金融、貿易、資産管理、サプライチェーン、物流などのシナリオを再構築すると述べました。AIが行動を開始すると、問題は「知能」そのものだけでなく、これらの行動がどのように承認され、決済され、記録され、説明責任が果たされるかという点になります。
これらのトピックの中でも、エージェント決済は無視できないものになりつつあります。しかし、当初私が抱いていた疑問はごく単純なものでした。エージェント決済やエージェントコマースについて語る際、なぜ人々はそれを暗号通貨、ステーブルコイン、ブロックチェーンと必ず結びつけて考えるのでしょうか？
AIエージェントは銀行カードを受け付けられないのですか？クレジットカードを受け付けられないのですか？Apple Pay、Visa、Mastercard、Stripe、またはPayPalを受け付けられないのですか？
エージェントが単に航空券の購入、ホテルの予約、SaaSサブスクリプションの更新などを手伝ってくれるだけなら、理論的には既存の決済システムを最大限に活用できるはずだ。ユーザーが一度承認すれば、エージェントは銀行カード、バーチャルカード、法人アカウント、またはサードパーティの決済ウォレットをバックグラウンドで使用して、限度額とルール内で決済を実行する。これは不合理なことではないだろう。
つまり、問題は「銀行カードは使えるのか？」ではなく、もちろん使える。本当の問題は、エージェント決済のどの部分に銀行カードやクレジットカードが適していて、どの部分に適していないのか、ということだ。AIエージェントは実際に銀行カードを使うのだろうか？そして、エージェント決済が発展するにつれて、ステーブルコインやブロックチェーンがほぼ必然的に関わってくる理由は何なのか？
まず、決済は銀行カードで行うものであり、代理店を介した決済ではない。
エージェント決済が、航空券の購入、ホテルの予約、SaaSサブスクリプションの更新など、最終的な支払いステップをAIエージェントが完了させるだけのものであれば、銀行カード、クレジットカード、バーチャルカード、Apple Pay、Stripe、PayPalなどをバックグラウンドで利用することに根本的な障害はありません。銀行カードはもちろん、クレジットカードももちろん利用できます。
ユーザーが事前承認を与えると、エージェントは指定された限度額とルールに基づいて支払いを実行します。これは理解しにくいものではありません。基本的には、よりスマートな自動引き落とし、法人向けバーチャルカード、トラベルカード、または自動調達システムと似ています。
したがって、Visa、Mastercard、Stripeといった従来の決済事業者が消滅することはないだろう。むしろ、初期のエージェント型コマースにとって重要な入り口となる可能性さえある。
StripeとTempoが立ち上げたマシンペイメントプロトコルは、この点を典型的に示している。このプロトコルはステーブルコインのみに依存するのではなく、加盟店がエージェントから直接支払いを受け取れるようにし、ステーブルコインだけでなく、カードやBNPLといった他の法定通貨決済方法もサポートしている。つまり、エージェント決済の初期段階では、従来の決済方法とステーブルコインが、どちらかがすぐに他方を置き換えるのではなく、共存する可能性が高い。しかし、これはエージェントコマースの1つの側面、つまりチェックアウトの問題しか解決しない。
チェックアウトプロセスは、商品、販売者、注文、支払いボタン、返金、紛争解決といったプロセスが既に存在していることを前提としています。エージェントはユーザーの傍らに立ち、購入手続きをより自動的に完了できるようサポートするだけです。
本当の問題は別のシナリオで発生します。エージェントはもはや既成のショッピングカートに商品を入れるだけではなく、オープンネットワーク内でリソースを継続的に呼び出し、サービスを組み合わせ、タスクを完了させる必要があるのです。例えば、AIリサーチエージェントが業界レポートを完成させるには、複数のデータベースにアクセスし、複数の有料リソースを購入し、さまざまなモデルAPIにアクセスし、Webクローラーサービスを呼び出し、グラフ生成ツールに料金を支払い、さらには別のエージェントから分析結果を購入する必要があるかもしれません。従来の「ストア」や単一の決済ページは存在しない可能性があります。代わりに、API、データインターフェース、モデルサービス、コンピューティングノード、コンテンツリソース、自動化ツール、さらには別のエージェントとやり取りすることになるかもしれません。
最近、私自身も具体的な例に遭遇しました。ウェブサイトのトラフィック、キーワード、競合他社、市場動向を分析するために、必要に応じてSemrushなどのデータソースを自動的に呼び出すトラフィック分析アシスタントを作成したいと考えていました。しかし、実際にソリューションの開発を始めたところ、問題は「AIが分析できるか？」ではなく、「どのようにデータを取得するか？」であることに気づきました。多くの商用データソースは、「1回の呼び出し、1回の支払い、即時返却」モデル向けに設計されていません。たとえばSemrushを見てみましょう。そのAPIシステムは、アカウント、パッケージ、APIユニットのモデルに近いものです。各APIリクエストは一定数のAPIユニットを消費し、ユーザーは対応するAPIアクセスまたはAPIユニットパッケージを購入する必要があります。Trends APIは個別のアクセス購入が可能ですが、それでもデータのリクエストにはAPIユニットに依存しています。
しかし、このモデルはエージェントにとって自然なものではありません。エージェントがトラフィックデータに時々アクセスする必要があるだけであれば、SaaSアカウントを登録したり、APIユニットのパッケージ全体を購入したりするのではなく、ウェブページにアクセスするのと同じようにリクエストを行う方が望ましいのです。「このデータはいくらですか？購入する権限はありますか？」予算内であれば支払い、すぐに結果を取得すればよいのです。
これが、エージェント決済と従来のAPIビジネスモデルとの間の乖離です。今日でも、多くのAPIは「人間がソフトウェアを購入する」というモデルに基づいて価格設定されており、「機械がオンデマンドでリソースを購入する」というモデルにはなっていません。
したがって、エージェント決済における問題点は、最終段階で支払いを差し引くことができるかどうかではなく、タスクチェーン全体を通して、機械が継続的に承認を取得し、支払いを開始し、配送を確認し、決済を完了する方法にある。
これが銀行カードシステムの境界です。
銀行カードが時代遅れだからではなく、元々は人間の消費行動を想定して作られていたからだ。つまり、人が店舗に入り、商品を選び、注文を確定し、支払いを完了すると、銀行、カード会社、アクワイアリング機関、決済サービスプロバイダーが承認、決済処理、リスク管理、紛争解決を行うという流れである。
しかし、エージェントエコノミーには別の疑問点も存在します。このエージェントは、なぜこのお金を使う権利を持っているのでしょうか？サービスプロバイダーは、これが悪意のあるボットではなく、ユーザーの真の意図の延長であることをどのように確認できるのでしょうか？エージェントは、各段階で人間の検証なしに、少額で頻繁なクロスプラットフォーム決済を完了できるのでしょうか？サービスプロバイダーは、支払いを受け取った後、すぐに対応するリソースを解放できるのでしょうか？エージェントがミスを犯したり、権限を逸脱したり、攻撃を受けたりした場合、誰が責任を負うべきなのでしょうか？
そのため、GoogleはAP2の開発において、「どの決済方法を使用するか」ではなく、より汎用的なエージェント決済信頼フレームワークに焦点を当てました。Googleの公式説明では、AP2は決済方法に依存しないフレームワークとして定義されており、ユーザー、加盟店、決済サービスプロバイダーが、さまざまな決済方法にわたってエージェント主導の決済を安心して完了できるようになっています。AP2の仕様では、エージェントがユーザーに代わってアクションを実行するためのスコープ付き権限を安全かつ簡単に取得する方法が必要であることも明記されています。プロトコルのセキュリティは、ユーザーと加盟店による関連情報の暗号署名に依存しています。
したがって、代理人による支払いに関する最初の疑問は、「お金はどこから来るのか？」ではなく、「代理人にこのお金を使う権利を与えるものは何か？」である。
銀行カードシステムは、この問題の一部を解決できる。例えば、バーチャルカード、トークン化された認証情報、信用限度額管理、企業経費管理、リスク管理ルールなどを活用することで、代理店は既存の加盟店システム内で取引を完了させることができる。
Visaもこの方向へ進んでいます。同社のインテリジェントコマースとトラステッドエージェントプロトコルは、既存の加盟店ネットワーク内で、AIエージェントを識別、信頼し、消費者や企業に代わって取引を完了することを可能にするものです。Visa開発者によるトラステッドエージェントプロトコルの説明も簡潔です。AIエージェントは、ユーザーが加盟店のウェブサイトを閲覧し、商品を発見し、価格を比較し、選択を行うのを支援します。ビジネスプロセスは決済のはるか前から始まっており、従来はこうした自動アクセスは加盟店、CDN、またはボット対策サービスによってボットとしてブロックされることがよくありました。
これは、従来の決済ネットワークも同じ問題を認識していることを示しています。エージェントコマースは、決済ボタンをクリックした瞬間だけでなく、検索、比較、選択、承認、最終決済に至るまでのプロセス全体を通して発生します。しかし、カードネットワークは、エージェントが既存の商取引フローに統合され、承認された取引を完了する方法の解決に優れています。しかし、オープンネットワーク内で、エージェントがAPI、データ、モデル、コンピューティング能力、コンテンツ、ツール、その他のエージェントに対して継続的に少額決済を開始する方法については、自然には対応していません。
したがって、銀行カードは悪い解決策ではない。より正確に言えば、銀行カードはエージェントコマースにおける決済問題を解決するが、エージェントコマースにはより根本的な決済プロトコルが必要となる。
これは次の段階の問題提起につながります。取引相手が従来の加盟店ではなく、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 支払いが必要です。
お支払いが完了しました。
資源を入手する。
これはエージェント決済にとって非常に重要です。なぜなら、エージェントの取引は少数の高額な購入ではなく、多数の小規模でリアルタイムなオンデマンドサービス呼び出しだからです。
執筆エージェントは、記事ごとにデータクエリを一度だけ購入することができます。
投資調査エージェントは、特定の質問に対して、オンチェーン分析サービスを一度だけ呼び出すことがある。
旅行代理店は、複数の価格設定APIから同時に見積もりを依頼することができます。
開発担当者は、モデル推論、コードレビュー、またはテスト環境を、使用量に応じて購入することができます。
トラフィック分析エージェントは、まず完全なSaaSパッケージを購入するのではなく、特定のウェブサイト向けにSemrushのようなデータを一度だけ購入したいと考えるかもしれない。
すべてのサービスにアカウント、サブスクリプション、APIキー、プラン、手動承認が必要な場合、エージェントの実行能力は支払いおよび調達プロセスによって阻害されます。したがって、x402の意義は支払いを「より暗号通貨らしく」することではなく、支払いをインターネットプロトコルのように、要求可能、返却可能、検証可能、自動化することにあります。
L402も同様のルートです。
また、HTTP 402 を中心としていますが、ビットコイン ライトニング ネットワークやマカロンなどのアクセス認証情報やマイクロペイメントも組み込まれています。Lightning Labs は L402 を次のように定義しています。API エンドポイントやコンピューティング リソースなどのサービスの認証と取引を容易にし、サービスが API エンドポイントに課金できるようにすることで、AI エージェントの参加を容易にします。
L402エラーは、この問題がx402とともに突然発生したわけではないことを示しています。HTTPアクセス制御、マイクロペイメント、デジタルサービス権限という3つの要素を組み合わせようとする試みは、ずっと以前から行われていました。ただ、過去には相手側からの十分な需要がなかっただけなのです。
人間はAPIエンドポイントへのアクセスに一銭も支払いません。しかし、エージェントは支払います。人間は1日に何百ものデータソースを自動的に呼び出すことはありません。しかし、エージェントはそうします。人間は、タスクを完了するために、異なるサービス間での通話、見積もり、支払い、配送確認をリアルタイムで組み合わせることはありません。しかし、エージェントはそうします。
したがって、AIエージェントの出現により、HTTPネイティブ決済経路が突如として意義を持つようになった。
USDT/Tetherエコシステムでも同様の傾向が見られます。Tether WDKのx402ドキュメントには、AIエージェントがリソースの料金をプログラムで支払う必要があるため、x402がAIエージェントにとって不可欠であると明記されています。x402はWebスタック上で支払いを第一級の要素とし、エージェントが単一のリクエスト・レスポンスサイクル内で価格の発見、支払いの署名、リソースの取得を可能にします。t402プロジェクトは、インターネットネイティブな支払いのためのオープンスタンダードであると自らを説明しています。暗号通貨、法定通貨、ステーブルコイン、トークンなど、複数の価値形態をサポートし、Tether WDKとの互換性を目指しています。ここで注意すべき点があります。「公式のTether標準になった」と直接述べることはお勧めしません。より正確な表現としては、USDT/Tetherエコシステムでx402と同様のプロトコルの検討が進んでいる、というものです。
この背景には注目すべき傾向がある。エージェント決済は、個々の企業の製品間の競争ではなく、むしろ新しいプロトコルスタックの形成を意味する。
AP2は、「代理人が支払いを行う権限を与えられるべき根拠は何か？」という問いに答えているように思われる。
x402、L402、T402などのプロトコルは、エージェントがデジタルリソースを要求した際に、サービスプロバイダーがどのように支払い要求を開始し、エージェントがどのように支払いを完了してリソースを取得するのか、という問いに答えるようなものです。
ステーブルコインとブロックチェーンは、むしろ次のような問いに答えるものです。このお金は最終的にどの資産で決済されるのか、どこで検証されるのか、そしてどのようにすれば低コスト、リアルタイム、プログラム可能、クロスプラットフォームを実現できるのか？
したがって、エージェント決済と暗号通貨が一緒に議論されている理由は、Web3がAIに便乗しようとしているからではない。より正確に言えば、エージェント決済が、インターネットがこれまで解決できなかった「決済の本質」に関する問題を再び前面に押し出したからである。
インターネット上では情報は自然に流通する。しかし、長期的に見ると価値はそうはいかない。エージェントの出現は、インターネットにこのギャップを埋めることを迫っている。
だからこそ、x402、L402、T402といったプロトコルは注目に値するのです。これらは単に「AIが暗号通貨で支払うことを可能にする」という意味ではなく、むしろ新しい相互作用の方法を定義しようとしているのです。
機械はリソースを要求し、価格を理解し、認証を検証し、支払いを完了し、サービスを受け取ります。銀行カードがチェックアウトプロセスを解決する場合、これらのプロトコルは次の問題を解決します。
機械はどのようにして支払いを開始するのか？この疑問が解決されれば、ステーブルコインとブロックチェーンは単なる決済ツールではなく、エージェント決済の基盤となる決済言語および実行環境となる。
III. なぜステーブルコインなのか？ エージェントが必要とするのは、変動の激しい資産ではなく、安定した会計単位です。
エージェントが本当に機械可読で自動実行される決済プロトコルを必要としているのなら、なぜステーブルコインが最も話題になっているのでしょうか？BTCではないのでしょうか？ETHではないのでしょうか？通常の銀行カードではないのでしょうか？
ここで重要なのは「暗号資産」そのものではなく、エージェントが実際にどのような支払い資産を必要としているかという点です。エージェントが単に資産を長期的に保有するだけであれば、価格変動、収益、リスクへの露出を懸念するかもしれません。しかし、エージェントがタスクを完了することで報酬を得る場合、主なニーズは投機的な資産ではなく、安定した会計単位となる資産です。
調査担当者は、データAPI呼び出し1回につき0.10ドルを費やすかもしれません。コーディング担当者は、モデル推論呼び出し1回につき0.03ドルを費やすかもしれません。マーケティング担当者は、トラフィックデータ購入1回につき1ドルを費やすかもしれません。価格比較、発注、支払いを自動的に行う調達担当者は、予算内で全ての支出を管理する必要があるかもしれません。
このようなシナリオでは、エージェントは取引や仮想通貨の売買を行っているわけではありません。タスクを完了させているだけです。そのため、エージェントは以下の点を把握する必要があります。このリソースにはどれくらいの費用がかかるのか？この通話は予算を超えるのか？この支払いはユーザーの承認範囲内なのか？サービス提供後、費用を正確に記録できるのか？
決済資産自体の価格が日々大きく変動する場合、エージェントの予算管理は非常に複雑になります。例えば、API呼び出しの費用が今日は0.10ドルでも、価格変動によって明日は0.12ドルや0.08ドルになるかもしれません。これは取引市場ではさほど問題にならないかもしれませんが、マシンのオンデマンドリソース購入には不必要な複雑さが加わります。
そのため、変動の激しい暗号資産よりも、ステーブルコインの方がエージェント決済においてより自然な形で利用されているのです。
ステーブルコインの主な価値は、現実の商取引の世界により近い会計単位を提供することにあります。現在、多くのAPI、SaaS、データサービス、モデリングサービス、クラウドサービスが米ドル建てで提供されています。エージェントがこれらのサービスをオンデマンドで購入する場合、米ドル建てのステーブルコインを決済手段として使用することで、予算、価格、承認、請求書を同じ単位で直接管理することが可能になります。
これはありふれたことのように聞こえるかもしれませんが、エージェントにとっては非常に重要なことです。なぜなら、エージェントは単に「支払う」だけでなく、判断も下すからです。通話が価値のあるものかどうかを判断する必要があります。予算が十分かどうかを評価する必要もあります。ユーザーの確認が必要かどうかを判断する必要もあります。タスクのコストを記録する必要もあります。そして、エラーが発生した場合に、お金が使われた理由を説明する必要もあります。
したがって、エージェント決済には、プログラムから直接呼び出すことができる、低変動性で機械可読な決済資産が必要となる。ステーブルコインは、BTCやETHのような変動性の高い資産よりも、この要件に近い。
2つ目の価値は、ステーブルコインが少額、高頻度、即時決済に適している点です。この傾向は、先にx402について説明した際にもすでに明らかでした。Coinbaseは、x402をHTTP経由で即時かつ自動化されたステーブルコイン決済を可能にするものと定義しており、API、デジタルコンテンツ、サービスがアカウント、セッション、複雑な認証を必要とせずに、人間と機械の両方のクライアントから支払いを受け取ることができるようにしています。この背後には重要な変化があります。支払いはもはや完全なチェックアウトページ内で行われる必要はなく、単一のAPIリクエスト内で行われる可能性があるということです。
エージェントがリソースを要求する。サービスプロバイダーは「402 Payment Required」レスポンスを返す。エージェントは価格を決定し、承認を与える。エージェントはステーブルコインで支払いを行う。サービスプロバイダーは要求を検証し、リソースを解放する。
このプロセスは、少額、高頻度、オンデマンドの呼び出しを伴うシナリオに最適です。例としては、データクエリ、モデル呼び出し、コンテンツのロック解除、オンチェーン分析、チャート生成などが挙げられます。Tether WDKのx402ドキュメントにも、この点が明確に記載されています。AIエージェントはリソースに対してプログラムで支払いを行う必要があり、x402を使用すると、エージェントは単一のリクエスト・レスポンスサイクル内で価格の検出、支払いの署名、リソースの取得を行うことができます。
これは、銀行カードと同じ使用状況ではありません。銀行カードは、人間が消費する商品の販売決済に適しています。ステーブルコインは、機械がリソースにアクセスする際の即時決済資産としてより適しています。もちろん、これは銀行カードがなくなるという意味ではありません。StripeとTempoのマシンペイメントプロトコルは、2つのパスを明示的にサポートしています。1つはオンチェーンでの直接的な暗号通貨決済、もう1つはカードやウォレットなどの法定通貨決済です。Stripeはまた、加盟店がMPPを通じてエージェントからの支払いを、ステーブルコインとカードやBNPLなどの法定通貨決済方法の両方を使用して受け入れることができると述べています。
したがって、より正確な評価は「ステーブルコインが銀行カードに取って代わる」ではなく、むしろ「銀行カードは既存の加盟店ネットワークや決済シナリオに適している。ステーブルコインはオープンネットワークにおける機械決済シナリオにより適している」というものである。
3つ目の価値は、ステーブルコインがクロスプラットフォームおよびクロスボーダー取引に本質的に適している点にあります。エージェントは必ずしも単一のプラットフォーム上で動作するとは限りません。あるエージェントは、米国のデータAPI、欧州のモデルサービス、アジアのコンテンツインターフェース、オンチェーン分析ツールなどを利用して、別のエージェントと取引を行う可能性があります。各レイヤーが異なる国の銀行口座、アクワイアリング機関、現地の決済方法、決済サイクルに依存している場合、タスクチェーン全体が決済システムによって分断されてしまいます。しかし、ステーブルコインはネイティブなインターネット資産です。24時間365日流通し、プラットフォーム、ウォレット、アプリケーション間でアクセスでき、スマートコントラクトや決済プロトコルによって直接処理できます。人間のユーザーにとっては、これは単に「決済が速くなる」ことを意味するかもしれません。しかし、エージェントにとっては、その意義ははるかに大きいと言えます。なぜなら、エージェントの実行は銀行の営業時間に合わせて行われるわけではないからです。
週末、国境を越えた取引、銀行の決済時間、あるいは加盟店アカウントシステムによって中断されるべきではない。必要なのは、すぐに利用可能で、自動的に呼び出され、検証可能な決済手段である。
これが、x402、Tether WDKのx402サポート、そしてUSDT/Tetherエコシステムを取り巻くt402の探求がすべて同じ方向に向かっている理由です。つまり、エージェントがまず人間が設計した支払いページにアクセスするのではなく、ステーブルコインの支払いを機械が直接呼び出せるウェブスタックコンポーネントに変えようとしているのです。
しかし、これには冷静な視点が必要だ。ステーブルコインにも問題がないわけではない。
ステーブルコインは、準備金の透明性、発行主体、規制上の地位、償還機能、オンチェーン流動性などにおいてそれぞれ異なる特徴を持つ。英国証券取引委員会（BIS）も、2025年の年次経済報告書の中でステーブルコインを明確に批判し、単一性、柔軟性、健全性といった主要な金融システム基準を満たしておらず、現代の金融システムの完全な代替手段として単純に捉えるべきではないと主張した。
より正確に言えば、ステーブルコインは完璧な通貨ではないが、現在、エージェント決済のニーズを満たすのに最も近いインターネットネイティブの決済資産の一つである。
その価値は「分散型」という理念にあるのではなく、比較的安定した価格、プログラム可能な機能、クロスプラットフォームの送金機能、24時間365日の決済機能、そしてHTTPネイティブの決済、ウォレット、スマートコントラクト、オンチェーン監査との統合といった複数の条件を同時に満たしている点にある。
エージェント決済におけるオープンネットワークのリソース使用について議論する際、ステーブルコインが自然と頭に浮かぶのはそのためです。エージェントが必要としているのは「カードをスワイプできる手」ではなく、ソフトウェアが直接理解し使用できる形態の通貨だからです。
クレジットカードが人間が利用するために設計された決済手段だとすれば、ステーブルコインは機械経済のために用意された決済言語のようなものだと言えるだろう。
もちろん、この言語はまだ未成熟です。より優れたコンプライアンスフレームワーク、より安定した発行メカニズム、より明確なリスク管理、そしてより包括的なウォレット権限管理が必要です。また、エージェント決済シナリオの大規模な利用に本格的に参入するためには、AP2、x402、MPPなどのプロトコルとの統合も必要です。
しかし、方向性は明確だ。代理店には、安定した価格単位、即時決済可能な資産、プログラムによって呼び出される資金、そしてプラットフォーム間、国境間、サービス間での決済機能が必要だ。
これが、エージェント型決済においてステーブルコインが不可欠な理由です。すべての決済が暗号通貨決済になる必要があるからではありません。むしろ、ステーブルコインによって、取引対象が「人間の消費者」から「ソフトウェア主体」へと変化する際に、「お金」が初めてインターネットプロトコルの一部としてより身近なものになるからです。
ステーブルコインは、「エージェントが支払いを行う際にどの通貨を使用するか」という一つの疑問にしか答えません。エージェントがオープンネットワーク上で資金を使った後、誰がその支出を承認したのか、どこで使われたのか、権限の逸脱はなかったのか、そしてサービスは提供されたのか、という疑問には答えません。この疑問こそが、ブロックチェーンへと私たちを導くのです。
IV. ブロックチェーンが必要な理由は？単にチェーン上に情報を記録するためだけでなく、エージェントの行動を検証可能にするためです。
たとえエージェントがステーブルコインでの支払いを必要とするとしても、なぜブロックチェーンでなければならないのでしょうか？中央集権型の台帳ではダメなのでしょうか？Stripe、Visa、銀行、あるいは独自の台帳を管理するプラットフォームではダメなのでしょうか？
もちろんです。エージェントがAmazonでの買い物のみ、特定のSaaSプラットフォーム内のサービスのみの呼び出し、または社内システム内での購入のみといった、閉鎖的なプラットフォーム内でのみ活動する場合、中央集権型の台帳で十分です。プラットフォーム自体が、ユーザー、エージェント、権限、支出額、サービスの提供状況を把握しているからです。
しかし、エージェント決済の真に興味深い点は、エージェントが閉鎖されたプラットフォーム内で支払いボタンをクリックするだけではありません。プラットフォーム、サービス、ウォレット、国、さらには異なるエージェントを横断してタスクを完了できる可能性を秘めているのです。この段階では、「お金は支払われるのか？」という問題だけでなく、なぜお金が支払われるのか、誰が承認したのか、エージェントが権限を逸脱していないか、サービスプロバイダーが支払いを届けたのか、そしてエラーが発生した場合の責任は誰にあるのか、といった点が問われることになります。
これらは、エージェント決済におけるブロックチェーンの真価を浮き彫りにする重要な問いです。すべての取引をブロックチェーンに記録する必要があるからでも、オンチェーン取引が銀行取引よりも本質的に高度だからでもなく、エージェントがタスクを実行したり、サービスを呼び出したり、資金を処理したりする際に行うすべての経済活動には、検証可能な記録が必要となるからです。
人間は支払いの際に、ある程度の不透明さを許容できる。サービスを購入しても受け取れない場合は、カスタマーサービスに連絡できる。企業の調達に問題がある場合は、契約書を確認し、財務担当者と話し、メールをチェックし、会議を開いて議論することができる。銀行カードに誤った請求があった場合は、銀行に行って異議申し立てをすることができる。これらの仕組みは煩雑ではあるが、人間社会は長い間このように機能してきたのだ。
エージェントはそれぞれ異なります。エージェントは、取引頻度が高く、取引金額が小さく、サービスプロバイダーが多く、実行チェーンが長い場合があります。すべての取引で、取引後の手動検証、スクリーンショット、メール比較、カスタマーサービスへの問い合わせが必要になる場合、エージェント決済は意味を失ってしまいます。したがって、エージェントに必要なのは、より洗練されたウォレットではなく、より明確な責任の所在です。
例えば、ユーザーがエージェントに「今週は最大100ドルで市場分析をしてほしい。購入するのはデータ、モデル呼び出し、チャート生成サービスのみ」というタスクを与えます。エージェントはデータAPIをリクエストし、サービスプロバイダーはこのクエリに対して0.20ドルを返します。エージェントはこの金額が予算内であると判断し、支払いを完了し、サービスプロバイダーは支払いを受け取った後にデータをリリースします。このプロセスで本当に重要なのは「どのブロックチェーンが使用されたか」ではなく、後からいくつかの質問に答えられるかどうかです。ユーザーはどのような承認を与えたのか？エージェントは何を購入したのか？金額は予算を超えたのか？サービスプロバイダーは実際にデータを返したのか？エージェントが不適切なアイテムを購入するように促されて誤解されたことが後から判明した場合、この情報の出所を追跡できるのか？
だからこそ、エージェント決済について議論する際にビットコインのホワイトペーパーを改めて取り上げるのは、単なる懐古趣味ではないと私は考えています。サトシ・ナカモトが解決しようとしていた根本的な問題は、「取引可能な資産を発明する」ことではなく、信頼できる第三者を介さずに、ネットワークが電子マネーの送金を検証、指示、記録できるようにする方法でした。ホワイトペーパーには、ネットワークがトランザクションをハッシュ化して継続的に成長するプルーフ・オブ・ワーク・チェーンを作成し、作業をやり直さなければ変更できない記録を作成すると明確に記載されています。
エージェント決済は、やや異なる課題に直面します。二重支払いの問題だけでなく、エージェントの承認、権限の逸脱、決済の実施、そして責任問題も含まれます。しかし、共通点もあります。それは、オープンネットワーク内で経済活動が行われるようになると、検証可能な取引記録はもはや二次的なものではなく、インフラストラクチャ自体に不可欠な要素となるということです。
これがブロックチェーンの意義です。ブロックチェーンは支払いを不透明なものにするのではなく、これまでプラットフォームのデータベースに隠されていた状態を、外部から検証可能な状態へと変革します。少なくとも理想的には、支払い記録、認証情報、サービスアクセス、返金条件、予算支出などをすべて、より標準化された方法で記録・検証できるようになります。人間ユーザーにとっては、これは単に「より明確な会計処理」を意味するかもしれませんが、エージェントにとっては、信頼性の基盤となる可能性があります。
エージェントは人間ではないため、「当時こう考えていたことを覚えている」と言うだけでは、その行動を説明することはできません。外部から検証可能な一連の証拠が必要なのです。
そのため、AP2、x402、ステーブルコイン、ブロックチェーンはしばしば同じ図で一緒に議論されますが、これらは同じものではありません。AP2自体は、分散型プロトコルでもブロックチェーンプロトコルでもありません。GoogleはAP2を、ユーザー、加盟店、決済サービスプロバイダーがさまざまな決済方法でエージェント主導の決済を安心して完了できるようにする、決済方法に依存しないオープンフレームワークとして位置付けています。AP2の仕様では、AIエージェントがユーザーに代わって安全かつ自律的に決済を完了できるようにするオープンプロトコルとしても定義されています。
したがって、より正確には、AP2はエージェント決済の認可および信頼レイヤーに近く、ユーザーの意図、認可の範囲、および責任の境界を表現する役割を担います。x402、L402、およびT402は、支払い要求レイヤーに近く、エージェントがリソースを要求したときにサービスプロバイダがどのように支払い要求を開始するかを決定します。ステーブルコインは決済資産であり、エージェントが支払いに使用する安定した単位を決定します。一方、ブロックチェーンは検証可能な状態レイヤーであり、トランザクション記録、決済ステータス、およびその後の実行が外部から検証可能かどうかを決定
これらのレイヤーはそれぞれ異なるものですが、全体として見ると真のエージェント型決済インフラストラクチャに似ています。そうでなければ、不自然な状況に陥ります。エージェントはインテリジェントで、サービスの検索、価格比較、意思決定を支援してくれますが、決済となると、アカウント登録、カード連携、プラン購入、請求書の確認、カスタマーサービスへの問い合わせ、払い戻し処理といった、人間の世界におけるプロセスに戻ってしまうのです。そうなると、それはエージェント型決済ではなく、単にボタンをクリックするのが得意なブラウザアシスタントに過ぎません。
もちろん、過度に楽観的になるべきではありません。オンチェーン決済にエージェントを統合することにはリスクが伴います。実際、リスクはより直接的なものになる可能性があります。従来の決済では、多くの取引が異議申し立て、凍結、または取り消される可能性があります。オンチェーン取引は、一度送信されると、回復がはるかに困難になることがよくあります。エージェントが攻撃された場合、ユーザーの承認範囲が広すぎる場合、サービスプロバイダーがお金を受け取って配送しない場合、悪意のあるウェブサイトがエージェントに支払いを促した場合、またはエージェントが一晩で予算をすべて使い果たした場合、これらはすべて深刻な問題です。
したがって、エージェント決済は、単にエージェントにウォレットを渡して「どうぞ、お金を使ってください」と言うだけのものではありません。それではリスクが高すぎます。本当に必要なのは、限度額、ホワイトリスト、ブラックリスト、承認範囲、リスクレベル、人間による確認、一時停止／有効化スイッチ、監査ログといった包括的な制御メカニズムです。機械が自然に生成する小規模でリスクの低い取引は自動化できますが、現実世界での履行を伴う大規模でリスクの高い取引には、依然として人間による確認が必要です。
したがって、私はエージェント決済におけるブロックチェーンの役割を次のように理解したいと考えています。ブロックチェーンは、Web3が従来の金融よりも優れていることを証明するために使用されるのではなく、エージェントの経済行動に対する検証可能な基盤を提供するために使用されます。エージェント決済にブロックチェーンが必要なのは、すべての決済がオンチェーンであるべきだからではなく、AIエージェントがオープンネットワーク上で支出を開始したときに、支出した金額が承認されていること、購入したものが記録可能であること、行動が追跡可能であること、そして引き起こした問題に責任を負わせることができることを証明する方法が必要だからです。
この問題におけるブロックチェーンの真の役割はここにある。信仰や物語、あるいは力任せの「AI + Web3」アプローチの話ではない。機械が経済活動に参加するようになるにつれて、既存の会計システムやプラットフォームデータベースではもはや十分ではなくなる可能性があるという点だ。機械が読み取り、検証しやすい、よりオープンで標準化された経済状態のレイヤーが必要であり、ブロックチェーンは少なくともその方向性を示している。
第五に、これは銀行カードの代替品ではなく、むしろ段階的な決済システムの始まりである。
したがって、最終的に、エージェント決済が「ステーブルコインが銀行カードに取って代わり、ブロックチェーンが従来の決済ネットワークに取って代わる」という単純な結論にたどり着くとは私は考えていません。
この判断はあまりにも単純化しすぎており、現実と容易に矛盾する。少なくとも当面の間、銀行カード、クレジットカード、Apple Pay、Visa、Mastercard、Stripe、PayPalといったシステムは存続し、数多くの現実世界の消費シーンにおいて決済ゲートウェイとしての役割を果たし続けるだろう。人々がeコマースサイトで商品を購入したり、ホテルや航空券を予約したり、オフラインで買い物をしたり、企業が調達を行ったりといった場面は、エージェントが登場したからといって突然消滅することはない。
エージェントコマースの黎明期においても、エージェントはまず既存の決済システムに接続していた可能性がある。
既存の加盟店ネットワークは既に成熟しており、消費者は既にカードやウォレットを所有し、加盟店は既に決済処理を導入しており、銀行やカード会社は成熟したリスク管理、紛争解決、返金、コンプライアンス、本人確認システムを備えているため、「AIが購入手続きを完了するのを手助けする」といったシナリオにおいては、既存のRailsプラットフォームを直接利用することが最も現実的なアプローチです。
つまり、問題は「カードがなくなるかどうか」ではない。
問題は、エージェント決済がこのレベルにとどまるかどうかだ。エージェントが単に「チェックアウト」ボタンをクリックするだけであれば、銀行カードを使い続けることは可能だ。しかし、エージェントがよりオープンなタスクネットワークに参加し、APIを呼び出し、データを購入し、決済モデルサービスを利用し、コンピューティング能力を決済し、コンテンツをアンロックし、他のエージェントと取引を行うようになると、必要なのはよりスマートな決済ボタンではなく、全く新しい決済プロトコルスタックとなる。
だからこそ、将来私たちが目にする可能性が高いのは「銀行カード対ステーブルコイン」ではなく、階層化された決済システムだと私は考えているのです。
人間の消費活動や既存の加盟店ネットワークにおいては、銀行カード、クレジットカード、ウォレット、銀行口座が引き続き主流となるでしょう。Railsのような従来の決済方法は、エージェントが買い物、チケット予約、ホテル予約、SaaSの更新などを完了させるのを支援する場面で、引き続き重要な役割を果たします。エージェントは既存の商取引フローに統合され、ユーザーがより自動的に取引を完了できるよう支援します。
しかし、ステーブルコインとブロックチェーンは、API、データ、モデル、コンピューティング能力、コンテンツ、オンチェーンサービス、エージェント間取引など、より機械ネイティブなシナリオで登場する可能性が高い。これは、これらのシナリオでは支払いの受取人が従来の商人ではなくデジタルリソースであること、取引金額は少額でも頻度が高いこと、サービスプロバイダーが異なるプラットフォーム、国、システムから提供される可能性があること、そしてプロセス全体が理想的には機械によって自動的に理解、支払い、検証されるべきであることなどが理由である。
要するに、銀行カードは人間による消費の時代における決済問題を解決したが、ステーブルコインやブロックチェーンは、機械経済の時代における決済言語や検証可能な実行環境の問題を解決するようなものだ。
もちろん、これはステーブルコインとブロックチェーンが実用化の準備が整ったという意味ではありません。オンチェーンでの操作は依然として複雑で、ウォレット管理はユーザーフレンドリーとは言えず、ステーブルコインの規制は進化途上にあり、異なるチェーン間での流動性は断片化されています。さらに重要なのは、エージェントが資金を直接管理すること自体が本質的にリスクを伴うということです。アクセス制御、限度額管理、リスク管理メカニズム、手動レビュー、監査システムがなければ、エージェントによる支払いは容易に「自動化」から「自動的に問題を引き起こす」状態へと陥る可能性があります。
したがって、エージェント決済の真の導入は、エージェントがウォレットで無謀にお金を使えるようになることを意味するものではありません。
おそらく段階的な進化となるでしょう。まず、既存の決済システムに組み込まれ、ユーザーがより自動化されたチェックアウトを完了できるよう支援します。次に、予算、ホワイトリスト、使用範囲、時間制限、リスクレベルなど、よりきめ細かな承認機能を獲得します。その後、API、データ、モデル、コンテンツサービスが機械可読な決済リクエストをサポートし始め、エージェントがオンデマンドでリソースを購入できるようになります。そして最後に、特に少額、高頻度、クロスプラットフォーム、クロスボーダーのデジタルサービス呼び出しにおいて、ステーブルコインは一部の機械ネイティブなシナリオにおける決済資産となるでしょう。
この観点からすると、エージェント決済は、単一の企業、ブロックチェーン、ステーブルコイン、あるいはプロトコルだけで実現できるものではありません。むしろ、AIエージェントという新たな存在に直面し、決済システム全体が解体と再編成を余儀なくされていると言えるでしょう。
従来、決済システムは主に個人と企業を対象としていた。将来的には、決済システムは新たなタイプの主体、すなわち認可されたソフトウェアエージェントにも対応する必要が生じるかもしれない。
これは法人格も従来の企業アカウントもありませんが、リクエストを開始し、価格を比較し、サービスを呼び出し、リソースを消費し、支払いをトリガーし、記録を残します。このような主体が多数出現し始めると、決済システムは新たな疑問に答えなければなりません。それは誰なのか、誰を代表しているのか、何が許されているのか、いくらまで使えるのか、何を購入したのか、権限を逸脱していないか、問題が発生した場合の責任は誰にあるのか、といった疑問です。
これらの問題は、単純な支払いボタンでは解決できない。
それでは、記事の冒頭の質問に戻りましょう。AIエージェントは銀行カードを使用するのでしょうか？
ミーティング。
しかし、銀行カードだけを使うわけではない。
銀行カードは引き続き決済処理を担い、ステーブルコインは機械ネイティブな少額の即時決済を担うようになり、ブロックチェーンは検証可能な状態と実行環境を提供し、AP2、x402、L402、T402などのプロトコルは認証、支払い要求、リソースアクセスを連携させようとするだろう。
だからこそ、Agentic Paymentは非常に注目に値するのです。単にAIに決済機能を追加するだけではありません。機械が経済活動に参加するようになるにつれ、インターネットが真に必要とする決済システムとはどのようなものなのかを、私たちに再考させるものなのです。
