マシンネイティブ取引：現状と欠けているインフラ

この記事を読むのに必要な時間は 68 分

マシン決済レールから自律調達ネットワークへ、「誰が買い手を装備するのか」をめぐるインフラの移行。

原文タイトル：「マシンネイティブ取引：現状と欠けているインフラストラクチャ」

原文ソース：水滴資本

要約

大規模モデルは、質問に答えるツールから、計画を立て、ツールを呼び出し、結果を届けるエージェントへと変わりつつある。同時に、ステーブルコイン決済、HTTPネイティブ決済プロトコル（http 402）、スマートウォレットも組み合わさり、マシン向けの決済インフラストラクチャを形成し始めている。プログラムが実行時に見積もりを受け取り、署名による承認を行い、少額決済を完了できる――これは数年前には概念に過ぎなかったが、今では実際に利用可能な技術的経路となっている。

しかし「マシンが支払える」ことは「マシンが取引を完了できる」ことと同じではない。エージェントが検索、データ、計算資源、コンテンツ生成、専門分析サービスを購入する必要がある場合、依然としてエンドポイントの発見、見積もりの比較、プロトコルをまたぐ支払い、予算管理、納品の検証、統一的な照合といった問題に直面する。決済レールは価値がどのように移動するかを解決したが、需要がどのように供給を見つけるか、そして支払い後に正しいサービスが得られたかどうかは自動的には解決していない。

これは、Agent Paymentの次の段階において、競争の焦点がもはやプロトコルのスループット、決済速度、または何本のチェーンをサポートするかではなく、真のマシン買い手側インフラストラクチャを形成できるかどうかになる可能性があることを意味する。本稿では、需要構造、プロトコルの進化、現実のボトルネック、市場分業の観点から、Agent Paymentがなぜ独立したトラックになるのか、そして規模 adoption までにどのような重要な要素が欠けているのかを議論する。

はじめに：エージェントは制約付きの「可処分予算」を手に入れつつある

過去2年間、エージェント能力の変化は非常に速かった。初期の大規模モデルは主に情報生成を担い、ユーザーが質問し、モデルがテキストを返していた。その後、ツール呼び出しによりモデルはウェブページを検索し、データベースを照会し、コードを実行し、ソフトウェアを操作できるようになった。さらに一歩進んで、エージェントは目標を分解し、計画を策定し、複数ラウンドの実行の中で外部結果に応じて動作を調整し始めている。

実行対象が無料ツールや企業内部システムに限定されている場合、呼び出し権限は開発者が事前に設定できる。しかし、オープン市場における高品質な能力は通常有料である。リアルタイム金融データは従量課金、ウェブスクレイピングはクォータを消費し、推論とGPU計算資源は使用量に応じて課金され、動画生成や専門データベースにも明確な価格がある。エージェントが独立してタスクを完了するには、実行プロセスの中で必然的に買い手とならなければならない。

従来のAPIビジネスモデルは、このような買い手のために設計されたものではない。それは、人間がまずウェブサイトにアクセスし、アカウントを登録し、銀行カードを紐付け、プランを選択し、API Keyを保管し、そのキーをプログラム環境に配置することを要求する。調達の意思決定と実際の呼び出しは2つの時点に分断されている。人間がタスク発生前に調達を完了し、ソフトウェアは購入済みのクォータを消費するだけである。

エージェントは、タスクを実行するある段階に至るまで、自分が何を必要としているのか分からないことがある。どのデータソースを最終的に呼び出すかを事前に判断できず、ユーザーにすべての潜在的なサービスごとに口座を開設するよう求めるべきでもない。その調達は、即時性、少額、複数マーチャント、高頻度、結果志向といった特徴を持つ。エージェントにとって最も自然な体験は、「まず購読し、それから呼び出す」ことではなく、「サービスを発見し、見積もりを取得し、支払いを承認し、結果を得る」ことである。

したがって Agent Payment は、チャットボットに支払いボタンを追加することではない。それは、ソフトウェアが制約された支出権限を持ち、機械独自の調達プロセスを形成し始めることを意味する。人間が目標、予算、リスク境界を設定し、エージェントがその境界内で資金を配分する。これにより支払いは、単なる決済動作から、エージェントの意思決定システムの一部へと変わる。

1. なぜ Agent Payment が独立したトラックになるのか

1.1 ツール呼び出しから経済的行動へ

エージェントと通常の自動化スクリプトの違いは、推論能力だけにあるのではない。スクリプトはあらかじめ定められたフローを実行し、必要なリソースやベンダーは通常すでにコードに書き込まれている。エージェントは環境に応じて経路を選択する。同じ調査タスクにおいて、まず検索結果を購入し、その結果に応じて業界データベースが必要かどうかを判断し、最後に別のモデルを呼び出してクロス検証を行うかもしれない。各ステップの調達が後続の意思決定を変えていく。

この「実行しながら調達する」モデルは、経済的選択をソフトウェアのランタイムに持ち込む。エージェントは、あるツールが利用可能かどうかを判断するだけでなく、それを購入する価値があるかどうかも判断しなければならない。価格が予算を超えていないか、応答速度がタスクを満たすか、過去の履行が信頼できるか、代替サービスがより適切か。従来のツールルーティングは能力のマッチングに注目するが、マシン調達は価格と取引相手リスクも同時に処理する必要がある。この種の取引では、リスクを負う側はエージェント自身である。支払いは成功したが、サービスは納品されないかもしれない。

したがって、Agent Payment の核心的なニーズは、無条件の自動支払いではなく、購買権を制御可能な形でソフトウェアに委ねることである。ユーザーは財布全体をエージェントに簡単に渡すことはしないが、明確なタスクに対して数ドルの予算を設定し、数セント単位の調達を何件か許可することは進んで行う。大きな権限委譲には依然として長期的な信頼構築が必要かもしれないが、小さな権限委譲はすでに実際の価値を生み出せる。

1.2 少額、高頻度、複数マーチャントが支払いの経済学を変える

人間のインターネットの支払いインフラは、比較的低頻度で高額な取引を処理するのが得意である。クレジットカードネットワーク、決済ゲートウェイ、サブスクリプションシステムには固定費があり、そのためマーチャントは多くの呼び出しを月額パッケージにまとめることが多い。1回あたり数セントの価値しかない API リクエストにとって、従来の支払いの手数料、チャージバックリスク、アカウント維持コストは商品そのものよりも高くなる可能性がある。

機械消費はちょうど逆である。エージェントは一つの成果物を完成させるために、数分以内に複数の事業者へ複数の調達を发起できる。一件あたりの金額は低いが、呼び出し頻度は高く、取引数は人間の消費者をはるかに上回る可能性がある。ステーブルコインとオンチェーンでプログラマブルな決済は、こうしたシナリオに新たな経済的基盤を提供する。資金は24時間365日流動し、支払い承認はソフトウェアが署名でき、サービスは呼び出し単位で直接課金できる。

さらに重要なのは、複数事業者からの調達がAPI市場の競争のあり方を変えることだ。サブスクリプション制はユーザーを長期的に一社のサプライヤーに縛り付けるが、都度購入はエージェントが各タスクごとに動的に選択することを可能にする。サービス提供者はもはや年間契約だけで競争するのではなく、ある瞬間の需要をめぐっても競争する。価格、性能、履行実績がすべてリアルタイムでルーティング結果に影響し得る。

1.3 ステーブルコインは取引媒体から決済インフラへ移行しつつある

暗号市場の初期におけるステーブルコイン需要は、主に取引と資金の逃避先としての性格から来ていた。発行、カストディ、コンプライアンス、クロスチェーンインフラが徐々に成熟するにつれ、ステーブルコインは越境決済、企業資金管理、インターネットネイティブ決済へと進出し始めている。マシン決済にとって、ステーブルコインにはもう一つの特別な利点がある。それは通貨であると同時に、プログラムが直接操作できるデジタル資産でもあるということだ。

クレジットカード決済はカード保有者の身元、銀行口座、地域ネットワークに依存する。エージェント自体には自然人としての身元がなく、従来の口座開設プロセスを単独で通過することもできない。ポリシーによって制約されたウォレットは、エージェントの資金インターフェースとなり得る。運用者は限られた残高を注入し、一件あたりおよびセッションあたりの上限を設定し、凍結と取り消しの権限を保持する。エージェントは認可範囲内でのみ支払いに署名する。

これは、オンチェーン決済がすべての従来型決済より本質的に優れているという意味ではない。消費者保護、返金メカニズム、プライバシー、鍵管理、規制責任は依然として解決が必要である。しかし、マシン対マシン、少額の都度課金、グローバルなサービス調達においては、プログラマブルなステーブルコインには明らかな適合性がある。それは「API呼び出し」と「支払いインターフェース」を初めて同じネットワークインタラクションに圧縮する機会をもたらす。

2. 決済レールはすでに登場している：x402、MPP、HTTPネイティブ取引

2.1 402をステータスコードから商業インターフェースへ変える

HTTPは早くから402 Payment Requiredステータスコードを用意していたが、およそ30年の間、それは汎用的なワークフローを形成しなかった。マシン決済プロトコルはこのセマンティクスを再び活性化する。クライアントが有料エンドポイントをリクエストすると、サーバーは402と機械可読な支払い条件を返す。クライアントは受け入れ可能な方式を選択し、署名または支払いを完了し、資格情報を添えてリクエストを再試行する。

このプロセスの重要性は、人間向けの登録ページを不要にする点にある。価格発見、支払い要件、コンテンツ配信はすべて、プログラムが理解できるプロトコル層で行われる。開発者にとって、有料APIはもはやアカウント、プラン、キーを中心とした完全なSaaSポータルを構築する必要がない。エージェントにとって、サービスは通常のウェブページのように発見でき、本当に必要なときに購入できる。

x402 はこの経路において最も注目されているオープンプロトコルの一つである。HTTP 402 を中心に支払いチャレンジとクレデンシャルを組織し、サービスプロバイダーがリクエストごとに收款できるようにする。MPP は別のエコシステムから出発し、マシン向けの charge、session などの支払い方式を模索している。両者の具体的な設計は異なるが、共通して一つの方向性を検証している：マシン決済はアプリケーションプロトコルの一部となり得るのであり、アプリケーションの外に別途人手による決済プロセスを構築する必要はない。

2.2 決済レール多元化の長期性

業界はしばしば、最終的に標準プロトコルが一つ、決済ネットワークが一つ、支払いスキームが一つだけ残ると期待する。しかしマーチャントの視点から見れば、多元化には長期的な合理性がある。一回限りのデータクエリには従量課金が適し、継続的な推論やストリーミングサービスにはセッション課金がより適するかもしれない。高価値サービスにはより強力な保証と紛争処理が必要であり、低価値の呼び出しでは速度とコストがより重視される。地域や企業によっても、選択するコンプライアンスと決済ネットワークは異なる。

プロトコル層では今後も革新が続く。マーチャントは直接引き落とし、事前承認、エスクロー、ストリーム決済、バッチ決済を採用するかもしれない。ネットワークはコスト、ファイナリティ、流動性、エコシステムツールにおいてそれぞれトレードオフを持つかもしれない。売り手にとってこれは自由な選択である。買い手にとっては、新たな組み合わせが一つ増えるごとに、新たな統合面が一つ増えることになる。

下図の構成マトリクスは、この多元化の一断面である：プロトコル／支払いスキームが列を構成し、チェーンが行を構成し、各選択は個別に統合が必要な決済構成であり、この表はさらに広がり続けている。

図 1：断片化下における決済レール構成マトリクス

したがって、断片化は市場の成熟に伴って自然に消滅するとは限らない。カード市場は長期的な発展によって一つのカード組織だけになったわけではなく、クラウドコンピューティングも一つのベンダーに収束しなかった。成熟市場は通常、差異を消滅させるのではなく、差異の上に集約、ルーティング、清算の層を形成する。Agent Payment もおそらく同じ進化経路をたどるだろう。この分裂はすでに測定可能である。二つの公開ブラウザ（x402scan と mppscan）の直近30日間のデータによると（2026年9月3日時点）：MPP プロトコルは Tempo チェーン上に 65,591 個のアクティブな買い手ウォレットを持ち、x402 は Base チェーン上に 19,472 個を持ち、両方のレールに同時に存在するウォレットはわずか 365 個で、MPP プロトコル買い手の 0.6% 未満、x402 Base 買い手の 2% に満たない。そのうち両方のレールでそれぞれ十件以上の取引を完了したのはわずか 112 個であり、かなりの部分がデュアルレールアグリゲーターが同一の鍵で代理支払いを行っているのであって、買い手自身が第二の決済レールを採用したわけではない。買い手はレールを跨いで流動しておらず、各レールがそれぞれ独立した買い手群を蓄積している。

2.3 売り手の接続は取引の半分に過ぎない

決済プロトコルはまず、加盟店の収款ハードルを下げた。一つのエンドポイントがオファーを公開し、資格情報を検証し、サービスを返すことができれば、マシン向けに営業する基本条件を備えたことになる。ますます多くの開発者ツール、データサービス、コンテンツインターフェースが、これによってマシン購入可能な状態に入っている。

しかし、供給が支払可能であることは、需要が自動的に到来することを意味しない。加盟店が解決するのは「どうやってマシンから收款するか」であり、エージェントは依然として「誰から買うべきか、どの方法で支払うか、支払い後に納品をどう確認するか」に答えなければならない。もし各買い手がそれぞれ各プロトコルを統合し、異なるネットワークの資金を用意し、独立した台帳を維持しなければならないなら、マシン決済は初期のAPI統合の複雑さを再演することになる。ただ、API Keyがウォレットとプロトコルアダプターに置き換わっただけだ。

真の採用率は、取引の総摩擦によって決まるのであり、決済のその一段階の摩擦だけではない。

3. 業界の真のボトルネック：取引に閉ループがない

図2：マシン調達の完全な流れ

3.1 第一関門：購入可能なサービスの発見

エージェントには、マシン可読なサービスカタログが必要だ。有効なカタログは、名称とURLだけでなく、エンドポイントの能力、入出力、価格単位、利用可能なプロトコル、遅延、地域制限、更新状態を記述しなければならない。自然言語の意図とAPIパラメータの間のマッピングも必要だ。そうでなければ、エージェントは自分が「マクロデータが必要だ」と分かっていても、どのエンドポイントがタスクを満たすかを判断できない。

オープンマーケットのカタログは、重複、失効、虚偽の表明にも直面する。どの加盟店も、自分が高品質なデータを提供していると主張できるが、エージェントは人間の調達担当者のように何日もかけて背景調査を行うことはできない。発見レイヤーは、エンドポイントが呼び出し可能か、オファーが真実か、説明が返却内容と一致するかを継続的に検証しなければならない。

これにより、サービス発見は従来の検索とは異なるものになる。検索エンジンが最適化するのは情報の関連性だが、マシン調達カタログは取引可能性も最適化しなければならない。能力が一致するか、価格が受け入れ可能か、支払いが互換か、そして加盟店が納品できるかどうかである。

3.2 第二関門：オファーの理解と比較

表面上、同種のAPIはすべて従量課金で価格を表示できるが、実際にはオファーの比較可能性は非常に弱い。あるものはリクエストごとに課金し、別のものは結果の件数ごとに課金する。あるものはモデル推論を価格に含め、別のものは追加支払いが必要だ。さらに、入力長、実行時間、または成功結果に基づいて動的に課金するサービスもある。

エージェントは名目価格が最も低いエンドポイントだけを選ぶべきではない。総コスト、配信確率、レイテンシ、結果の品質を考慮する必要がある。安価なインターフェースが連続して失敗すると、再試行コストとタスクの遅延により、実際の価格が高くなる可能性がある。したがって、見積もりはサービスレベル、過去の実績、タスクのコンテキストとともに評価されるべきである。

機械可読な見積もりには、有効期限と最終金額を明確にする必要もある。動的価格設定環境では、エージェントが署名するのは確定したコミットメントでなければならず、曖昧な価格帯であってはならない。オペレーターも、サービス料、ネットワークコスト、ルーティング費用を含む費用構成を知る必要があり、それによって信頼できる予算を設定できる。

3.3 第三関門：資金分布とクロスレール流動性

エージェントが複数のチェーンと複数のプロトコルで同時にサービスを購入する場合、最も直接的な方法は各ネットワークに残高を事前に配置することである。しかし、これでは少額の資金が多くの断片に分割されてしまう。資金は一時的に使われないネットワークに眠り、人気のあるネットワークでは残高が不足する可能性がある。残高の補充にはブリッジ、スワップ、Gas、セキュリティ操作が伴う。

単一のユーザーにとって、これはすでに煩雑である。多数のエージェントを管理する企業にとって、問題はさらに拡大する：各エージェントはいくらの残高を保持すべきか、誰が補充するのか、資金が誤って消費されるのをどう防ぐか、異なるネットワーク上の資産と費用をどう集約するか？統一された資金レイヤーがなければ、決済レールが増えるほど財務の複雑さはむしろ高まる。

理想的な状態では、エージェントが見るのは複数のネットワーク残高ではなく、一つの可処分予算である。基盤システムが決済パスを選択し、流動性を管理し、透明な見積もりを提供する。その原則は、旅行者が一枚のカードで異なる国で消費するのに似ている：ユーザーは総限度額と為替レートを気にし、各目的地ごとに事前に現地口座を開設する必要はない。

3.4 第四関門：ポリシーベースの認可

自律型支払いで最も懸念を引き起こすのは、エージェントが制御を失って消費するかどうかである。解決策は「完全禁止」と「完全認可」の二者択一ではなく、多層ポリシーを構築することである。

一回あたりの上限は一度の誤りの損失を制限し、セッション予算は一つのタスクの総支出を制約し、マーチャントのホワイトリストまたはブラックリストは取引相手を制御し、カテゴリルールは購入可能な内容を制限し、レート制限は短時間の異常な呼び出しを阻止する。高リスクまたは高額の取引は、人間による確認をトリガーすることもできる。ポリシーはオペレーターが設定し、エージェントは境界内でのみ行動でき、自ら限度額を引き上げることはできない。

ウォレットも署名機能だけを担うべきではない。タスク、アイデンティティ、監査記録と結びつき、「どのエージェントが、何のタスクのために、どのポリシーでこの支払いを承認したか」に答える必要がある。そうでなければ、企業が最終的に得るのは一連のオンチェーン取引ハッシュだけであり、内部統制とコスト帰属の要件を満たすことができない。

3.5 第五関門：決済成功はサービス提供と等しくない

ブロックチェーンは資金があるアドレスから別のアドレスへ移動したことを証明するのが得意だが、APIが正しい内容を返したことを自然に証明することはできない。取引は決済が完了しても、サーバー側がタイムアウトしたり、エラーステータスを返したり、配信されたデータが宣伝と異なる場合がある。エージェントにとって、これは边缘的な問題ではなく、調達リスクの核心である。

従来のEコマースは物流、評価、返金を通じて支払いと配信を結びつけるが、マシンサービスには実体物流がなく、配信は一瞬のHTTPレスポンスに過ぎないことがある。決済システムが資金の軌跡だけを記録し、商户が自分のレスポンスだけを記録するなら、市場には商户をまたぎプロトコルをまたぐ統一的な履行ビューが欠けている。

慎重にすべきは、レスポンスを記録することは品質を証明することと等しくないという点だ。しかし支払いとレスポンスを関連付けることで、少なくとも「支払い済みかつ結果を受領」「支払い済みだがサービス失敗」「未決済」といった基本状態を区別できる。これはマシン取引の信頼を構築する第一層の事実である。

3.6 第六関門：統一照合と責任の画定

一つのタスクには十数件のマイクロ調達が含まれることがある。各取引が異なるウォレット、プロトコル、商户のバックオフィスに散在していると、ユーザーは最終的な成果物になぜこれだけの費用がかかったのかを知るのが難しい。企業はさらに支出をプロジェクト、チーム、顧客、コストセンターに帰属させ、監査可能な証拠を保持する必要がある。

統一台帳は調達意図、商户、見積もり、認可ポリシー、決済結果、レスポンス状態、失敗原因を同時に記録すべきである。それは財務に役立つだけでなく、エージェントの最適化にも役立つ。システムはどのデータソースが頻繁に失敗するか、どのルートがより高コストか、ある種のタスクの典型的な調達組み合わせを分析できる。

支払いが推論チェーンに埋め込まれると、コストはモデル意思決定のフィードバック信号となる。統一照合がなければ、エージェントは答えを最適化できても、答えを得る経済的プロセスを最適化できない。Agent Paymentの長期的価値の大部分は、まさにこの可観測性から来ている。

4. 決済プロトコルからマシン調達層へ

4.1 未来の核心的抽象は「Pay」ではなく「Buy」である

支払いは対象と価格が明確になった後の動作であり、調達は需要から検収までの完全なプロセスをカバーする。エージェントにpay()関数を公開しても、既知のアドレスに送金できるだけである。buy()能力を公開して初めて、システムが需要を受け取り、サービスを発見し、方案を比較し、支払いを実行し、検証可能な結果を返せることを意味する。

この違いが業界の分業を決定する。プロトコルは標準化された支払いメッセージを提供し、ウォレットは署名と資産を管理し、決済ネットワークは価値を移動させ、ディレクトリは供給を集約し、調達層はこれらのコンポーネントを一つのタスクに組織する。どの単一コンポーネントも重要だが、単独で完全な取引を代表することはできない。

マシン調達レイヤーはオープンに保つ必要がある。すべての事業者に同一プロトコルへの移行を求めるべきではなく、閉鎖的なディレクトリで誰が購入対象になれるかを決めるべきでもない。より持続可能なモデルは、複数の決済レールに対応し、見積もりにルーティングコストを開示し、エージェントがポリシーに基づいて自律的に選択できるようにすることである。

4.2 買い手の集約は売り手の集約よりも重要かもしれない

インターネットプラットフォームは通常、まず供給を集約し、その後で消費者を引きつける。マシン市場では、供給はすでに API の形で広く存在しており、欠けているのは継続的に購入できる標準化された買い手である。装備されたエージェントは、断片的で偶発的な需要を安定した取引フローに変換できる。

買い手の集約はロングテールサービスの可視性も高める。人間の開発者は新規サプライヤーの評価に高い時間コストがかかるため、馴染みのある大ブランドを好む傾向がある。エージェントが標準化された能力、価格、履行シグナルを読み取れるなら、各タスクでより適切なサービスを選択できる。これは新規事業者の顧客獲得コストを下げる可能性があり、成熟した事業者に実績での競争を迫る。

しかし買い手の入口も新たなプラットフォーム権力を形成する。デフォルトのディレクトリ、ランキング、決済経路を誰が制御するかで、トラフィック配分に影響を与えうる。したがって業界には透明なランキングルール、説明可能な手数料、移行可能な取引記録が必要である。集約は摩擦を減らせるが、オープンプロトコルを閉鎖的なチャネルとして再包装すべきではない。

4.3 実際の取引データに基づく信頼の構築

マシンの買い手は意思決定が速く、長いデューデリジェンスに依存できない。見積もりが現れた時点で取引相手のシグナルを同時に得る必要がある。従来のスコアリングやユーザーレビューは参考になるが、水増し、Sybil アカウント、利害関係者による操作が容易である。レビューが実際の支払いを要求しない場合、攻撃コストは特に低い。最近の ERC-8004——エージェント向けの初の無許可オンチェーン信頼レイヤー——に関する実証研究はこの点を裏付けている [6]。このプロトコルの仕様原文には「Payments are orthogonal to this protocol」（支払いは本プロトコルと直交する）と明記されている——レビューはデフォルトでいかなる実際の有料取引にも紐づく必要がなく、支払い証明は単なるオプションフィールドである。結果として、イーサリアム、BSC、Base の 3 チェーン上で（2026 年 5 月 13 日時点）、それぞれ 73.5%、59.2%、90.6% のレビュアーが協調的な Sybil 行為を示した。

より信頼できる基盤は、実際の有料呼び出しに関連付けられた結果記録である。あるサービスエンドポイントが何件の決済を完了したか、応答成功率はどうか、一般的なレイテンシはどれくらいか、支払い後に無応答となる割合はどれくらいか。これらの指標は依然としてコンテンツ品質を完全には表せないが、自己申告よりも検証可能な事実に近い。

データの蓄積に伴い、市場では階層的なレピュテーションが生まれる可能性がある。第一層は客観的な取引状態、第二層は再現可能なサービス指標、第三層が特定タスクに対する品質評価である。エージェントは金額とリスクに応じて必要な証拠の強度を選択できる。数セントのデータ照会は統計的シグナルのみに依存すればよいが、高価値の調達には保証、監査、または紛争解決が必要となる。

4.4 予算戦略はエージェントの重要な能力になる

今日のエージェント評価は、主に回答品質、タスク完了率、ツール呼び出しの正確性で判断される。有料環境に入ると、経済指標も追加される。同等の品質を達成するためにいくら費やしたか、予算内で完了したか、いつより高価なデータを購入する価値があるか、そして速度、コスト、信頼性の間でいかにトレードオフするか、である。

これは新たな訓練と評価の方向性を生む。エージェントは「どのツールが質問に答えられるか」だけでなく、「現在のタスク価値の下で、このツールを購入することが割に合うか」も学ぶ。まず低コストのサービスでスクリーニングし、重要な結論に対しては高品質の検証を購入するかもしれない。また、予算が尽きそうなときは呼び出し頻度を下げたり、ユーザーに追加の承認を求めたりする可能性もある。

この意味で、Agent Payment はモデル能力の外側にある財務プラグインではなく、意思決定知能の一部である。真に成熟したエージェントは、リソースを使いこなすだけでなく、リソースに価格をつけることもできるべきである。

5. Agent Payment の想定される進化経路

5.1 第一段階：開発者ツールとデジタルサービスが先行

最も早く規模化するシナリオは、おそらく依然として純粋なデジタル納品である。例えば、検索、データ、プロキシクローリング、モデル推論、コード実行、ストレージ、コンテンツ生成などである。これらのサービス自体は API を通じて提供され、限界納品コストが低く、支払いと応答を同一ネットワークセッション内で完了でき、複雑な物流も伴わない。

この段階の典型的な金額は非常に小さく、ユーザーが関心を持つのは開発の利便性とタスク完了率である。市場はプロトコルを迅速に検証するが、取引量は高度に分散する可能性がある。多くの呼び出しは依然として従来の API Key とサブスクリプションで担われ、マシン決済は一時的なニーズ、事業者をまたぐ調達、事前に口座を開設できないロングテールサービスにより多く使われる。

5.2 第二段階：企業予算とマルチエージェント協調

企業が複数のエージェントを配備し始めると、資金管理は個人ウォレットから組織レベルのアカウント体系へとアップグレードされる。企業は異なる役割に予算を配分し、購入可能なカテゴリを制御し、承認閾値を設定し、支出を財務システムに記録する必要がある。エージェント間でも内部決済が形成される可能性がある。研究エージェントがデータを調達し、分析エージェントが計算資源を購入し、実行エージェントが外部サービスを呼び出すのである。

この時点で、安全性とコンプライアンスの重要性は支払いの新規性を超える。企業は鍵の保管、権限の分離、取引監視、ベンダー審査、監査証跡に関心を持つ。既存の財務プロセスと互換性のあるインフラだけが、試験から本番へ移行できる。

5.3 第三段階：デジタルサービスから現実経済への拡張

航空券、ホテル、物流、広告、専門サービスはエージェントの調達対象になり得るが、現実世界の取引にはより複雑な身元確認、返金、税務、紛争処理が必要である。ステーブルコインは決済問題の一部しか解決できず、消費者保護や商業契約の代替にはならない。

したがって、業界は「自律型支払い」をすべての中介者の排除と誤解すべきではない。むしろ、取引価値の上昇に伴い、保証、保険、信用、仲裁が再び登場するが、それらは機械が呼び出せるサービスへと変換される必要がある。将来のAgent Paymentスタックは、オープンな決済プロトコルと従来型金融の接続を同時に含む可能性があり、単一の路線が別の路線を置き換えるのではない。

5.4 第四段階：プロトコル間ルーティングから市場間執行へ

長期的には、エージェントが購入するのはAPIの応答だけでなく、結果そのものである。ユーザーが「信頼できる業界レポートを生成せよ」と指示すると、システムが検索、データベース、翻訳、モデル、検証サービスを自ら組み合わせる。基盤では複数の取引が発生するが、ユーザーには総予算、証拠ソース、最終成果物だけが見える。

これにより、決済ルーティングは市場執行へとアップグレードされる。システムは複雑な目標を調達ポートフォリオに分解し、失敗したサプライヤーを動的に交換し、総コストと品質の間で最適化する必要がある。プロトコルの互換性は基礎にすぎず、真の障壁は需要の理解、取引データ、実行フィードバックから生まれる。

6. リスクと未解決の問題

Agent Paymentの想像力は大きいが、現実の制約を無視できない。第一にセキュリティである。プロンプトインジェクションはエージェントを悪意あるサービスの購入へ誘導する可能性があり、サプライチェーン攻撃は受取アドレスを差し替える可能性があり、誤ったポリシーは大量の重複支払いを引き起こす可能性がある。支払いアクションは信頼できないコンテンツから分離され、限度額、シミュレーション、取消、異常検知を備える必要がある。

第二にプライバシーである。調達記録はエージェントがどのようなタスクを実行しているかを暴露し、オンチェーンの公開データはユーザー身份と商業意図を結びつける可能性がある。システムは機密メタデータの漏洩を最小限に抑え、監査要件とプライバシーのバランスを取る必要がある。

第三に責任である。エージェントが誤って購入した場合、加盟店が納品しなかった場合、プロトコル変換が失敗した場合、損失は誰が負担すべきか？少額取引では自動化リスクを受け入れられるが、高額取引では責任の境界を明確にする必要がある。紛争メカニズムのない決済ネットワークが、高価値商業に直接参入するのは難しい。

第四は規制である。ステーブルコインの発行、ウォレット管理、クロスボーダー送金、加盟店収納は、異なる司法管轄区のルールの影響を受ける。機械は実行者であり、法的責任の主体ではない。インフラストラクチャは、各自律的取引を明確な操作者、認可ポリシー、資金源まで追跡できるものでなければならない。

第五は商業的持続可能性である。マイクロペイメントの収入は、ネットワークコスト、流動性、リスク管理費用に容易に食い尽くされる。プラットフォームが隠れた上乗せで体験を補助すれば、買い手の信頼を損なう。手数料は透明でなければならず、規模、ルーティング効率、付加サービスを通じて合理的なビジネスモデルを構築する必要がある。

これらの問題はこの分野を否定するものではなく、Agent Payment が単一のプロトコルだけで完成するものではないことを示している。最終的には、決済、アイデンティティ、権限、ディスカバリー、レピュテーション、照合の複合インフラストラクチャとなる。

7. SELAT：マシンネイティブ商業に買い手能力を装備する

「SELAT」はマレー語で「海峡」を意味し、例えばマラッカ海峡（Selat Melaka）である。数百年にわたり、貨物がどの港から来てどの市場へ向かおうとも、東西貿易の主流はこの水路を通ってきた。SELAT はマシンネイティブ商業におけるその海峡となることを目指す。加盟店がどのトラックに接岸しようとも、エージェントの需要はここを流れることができる。

SELAT は AI ネイティブ企業であり、買い手側からマシン決済に参入することを選択した。SELAT はマシンネイティブ商業の買い手層であり、核心的な目標は加盟店の移行を要求する新たな決済トラックを再創造することではなく、エージェントが既存のトラックを横断して調達を完了できるようにすることである。それは二つの核心的問題に焦点を当てる。第一に決済設定の断片化であり、トラック、プロトコル、チェーン、クレデンシャルがそれぞれ異なり、各加盟店が新たな統合を行う必要がある。第二に取引相手リスクの測定不足であり、決済成功はサービスが提供されたことを意味しない。

図 3：SELAT 買い手層の概略図

断片化問題に対して、SELAT CLI はプロトコル、決済スキーム、決済ネットワークの差異をインフラストラクチャ層に留め、エージェントが一つのコマンドでトラック横断調達を完了できるようにする。ディスカバリー、見積もり、認可、決済、配送ステータス記録、照合は、すべて同一の調達フローに組み込まれ、各呼び出しも同一の台帳に記録される。

• 一つの資金庫、N 本の決済トラックを使用

エージェントはセルフカストディの USDC 残高を保有し、チェーンごとに資金を事前配置する必要も、異なるプロトコルごとに異なるクライアントを維持する必要もない。

• 集約型エンドポイントカタログ

SELAT CLI は Circle、MPP、Apify、pay.sh の4つのサードパーティサービスレジストリと SELAT 独自のカタログを統合し、エージェントがリアルタイムの意図に基づいて4,000以上のサービスエンドポイントを発見・比較できるようにします。

• ハード支出上限

オペレーターは1回あたりの上限とセッション予算を設定でき、いつでも支出権限を凍結できます。エージェントが自ら上限を引き上げることはできません。

• マーチャントのゼロ移行

マーチャントは自身が選択した決済レールを維持でき、SELAT への再登録なしにエージェントから発見・購入されることが可能です。

資金側では、SELAT は Circle や MetaMask のエージェントウォレットを含む任意のエージェントウォレットと組み合わせて使用できます。SELAT は x402 や MPP などの決済レール間で各購入をルーティングし、リアルタイムの見積もりに基づいて処理します。

7.1 ERC-8004：プリミティブは正しいが、シグナルに疑問あり

ERC-8004 はアイデンティティ、レピュテーション、検証の3種類のレジストリを定義し、買い手が売り手に評価を提出することを可能にしています。この方向性は正しいですが、支払いとレピュテーションを明確に分離しています。フィードバックは実際の取引に由来する必要がなく、支払い証明の添付も任意です。

デプロイ済みエコシステムに関する実証研究によると、Base 上では93.8%の評価者が一度も x402 支払いを行ったことがないにもかかわらず、94.9%のフィードバックを提供しています。また、多くのフィードバックが協調的なシビル行為を示しています [6]。レジストリが記録するのは主張であり、買い手が本当に必要としているのは結果です。

7.2 実際の取引データに紐づいたレピュテーションこそ買い手が必要とするもの

決済レールは資金が決済されたかどうかを確認できますが、サービスが何を返したかは見えません。マーチャントは自身のレスポンスを見ることができますが、市場全体は見えません。レジストリはエンドポイントを列挙できますが、評価が実際の購入に由来することを証明できません。

購入を実行する買い手レイヤーこそ、取引の両端を接続する最大の機会を持ちます。SELAT を通じて完了した各購入は、どのエンドポイントに支払い、いくら決済し、支払い後の配信ステータスメタデータ（2xx、4xx、5xx）を記録します。これらの記録はマーチャントと決済レールごとに継続的に蓄積され、「決済—配信グラフ」（Settlement–Delivery Graph）のデータ基盤を構成します。

正確に区別する必要があります。支払いと配信ステータスを紐づけた記録は、配信品質や見積もり精度の独立した証明と同等ではありません。しかし、登録型レピュテーションに欠けている基盤——実際の有料呼び出しに関連付けられた結果データ——を提供します。

7.3 取引前に取引相手の信用を取得する

人々がちょうどX上で第四世代インターネット向けにGoogle PageRankのようなTrustメカニズムをどう設計するかを議論していたとき、SELATはすでに決済—配送グラフの上に「取引可能性指数」（Transactability Index）を実装・ローンチしており、その目標は、エージェントが実行時に実際の取引結果に裏付けられた取引相手の信用データを取得できるようにすることである。

指数は見積もりとともに返され、エージェントにタスクを一時停止して別途マーチャントを調査することを求めない。それはリスクを注記するが市場に門を設けない：エンドポイントは依然として発見・購入可能であり、エージェントは予算、タスクの重要性、リスク選好に基づいて決定を下す。

エージェントにはブランドストーリーを読む時間はない。支払い前に知る必要があるのは：このエンドポイントが実際の取引でどう機能するかである。マシンネイティブ商業の信用は、宣言からではなく、結果から来るべきである。

図3：見積もり段階の取引可能性シグナル

現在、SELAT CLIはClaude Code、Codex、Cursor、Gemini CLI、OpenClaw、Hermes、Grok Botなどのエージェント実行環境に適合済みである。

8. まとめ：マシン経済に必要なのはより速い決済レールだけではない

Agent Paymentは、過大評価されやすく、また過小評価されやすい段階にある。過大評価されやすいのは、技術的にステーブルコイン決済を一度完了することが、エージェントがすでに成熟した商業自治能力を備えていることを意味しないからである；過小評価されやすいのは、ソフトウェアが明確な制約の下で外部能力を購入できるようになれば、マシン経済の組織方式、価格設定方式、競争の境界が変化するからである。

決済プロトコルはすでに、マシンが見積もりを受け取り決済を完了できることを証明している。次の鍵は、孤立した一回の支払いを完全な調達へと拡張することである：エージェントが適切なサービスを見つけ、真のコストを理解し、予算内でクロスレール決済を行い、配送を確認し、そしてすべての取引を監査可能で学習可能な記録へと変換できるようにすること。

未来のマシン経済は、一本のチェーン、一つのプロトコル、一つのウォレットだけではない。多元的な供給は長期的に存在し、真に価値のあるインフラは買い手がこの複雑さを横断するのを助ける。Agent Paymentはレール、供給、デフォルト決済、信頼メカニズムを組み合わせて初めて、技術的容量を真の需要へと変換できる。

ソフトウェアが買い手になり始めるとき、支払いはただその第一歩にすぎない。より重要な問題は常にこれだ：それは制御可能で、透明で、検証可能な方法で、真に有用な取引を完了できるのか。

参考資料

[1] Circle、「Building the Open Agentic Economy」、2026年。https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT、「Counterparty Risk in Agentic Payments: The Unmeasured Half」、2026年。https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud、「Powering AI commerce with the new Agent Payments Protocol (AP2)」、2025年。https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation、「x402：オープンなインターネットネイティブ決済標準」。https://github.com/x402-foundation/x402

[5] Machine Payments Protocol、「MPP：HTTP 402 に基づくマシン決済プロトコル」。https://mpp.dev/

[6] Xiong ほか、「Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem」、arXiv、2026年。https://arxiv.org/abs/2606.26028