マシンネイティブ取引：現状と欠落しているインフラ
Tapbit Wire出典：Waterdrop Capital
概要
大規模モデルは、単に質問に答えるツールから、計画立案・ツール起動・結果提供が可能な知的エージェントへと進化しています。一方、ステーブルコイン決済、HTTPネイティブ支払いプロトコル（HTTP 402）、スマートウォレットが融合し、機械向けに設計された支払いインフラが形成され始めています。プログラムは実行時に見積もりを受領し、承認署名を行い、マイクロペイメントを完了できます——これは数年前までは単なる概念にすぎませんでしたが、今や実現可能な技術的道筋となっています。
しかし、「機械が支払える」ことと「機械が取引を完遂できる」ことは等しくありません。知的エージェントが検索・データ・コンピューティングリソース・コンテンツ生成・専門的分析などのサービスを購入する際には、エンドポイントの発見・見積もり比較・跨プロトコル支払い・予算管理・納品確認・精算統合といった課題に依然直面しています。支払いレイルは価値の移動方法を解決しますが、需要と供給のマッチングや、支払い後の適切なサービス提供の保証は自動的に解決しません。
つまり、次世代のエージェントペイメントでは、競争の焦点はもはやプロトコルスループット・決済速度・対応ブロックチェーン数に限定されず、真に「機械買い手」向けインフラを構築できるかに移行する可能性があります。本稿では、需要構造・プロトコル進化・現実のボトルネック・市場における分業の観点から、なぜエージェントペイメントが独立したトラックとなるのかを考察し、スケールド採用に至るまでに残された主要な欠落要素について議論します。
序論：知的エージェントが制限付き「裁量予算」を獲得しつつある
過去2年間で、知的エージェントの能力は急速に進化しました。初期の大規模モデルは主に情報生成を担い、ユーザーの質問に対しテキストを生成していました。その後、ツール起動機能により、ウェブ検索・データベース照会・コード実行・ソフトウェア操作が可能になりました。さらに一歩進み、エージェントは目標を分解・計画立案し、外部からの結果に基づいて複数ラウンドにわたり行動を調整できるようになりました。
実行対象が無料ツールや社内システムに限定される場合、開発者が事前にアクセス権限を設定できます。しかし、オープン市場における高品質な機能は通常支払いを伴います：リアルタイム金融データはAPI呼び出し単位で課金、ウェブスクレイピングはクレジット消費、推論・GPUコンピューティングは使用量課金、動画生成や専門データベースも明確な料金体系があります。知的エージェントがタスクを自律的に完了するには、実行中に必然的に「買い手」として振る舞う必要があります。
従来のAPIビジネスモデルは、このような買い手を想定していません。ユーザーがまずウェブサイトを訪れ、アカウント登録・銀行カード連携・プラン選択・APIキーの管理を行い、それをプログラム環境に設定する必要があります。購入判断と実際の呼び出しは時間的に分断されており、人間がタスク実行前に購入を完了し、ソフトウェアは既に購入済みのクォータを消費するだけです。
エージェントはタスク実行中の特定ステップに到達するまで、何が必要かを把握できません。どのデータソースを最終的に利用するかを事前に予測できないだけでなく、あらゆる潜在的サービスごとにユーザーが個別にアカウントを開設することも現実的ではありません。その調達は即時性・低額・多事業者・高頻度・成果志向が特徴です。最も自然な体験は「事前購読→後続呼び出し」ではなく、「サービス発見→見積もり取得→支払い承認→結果取得」です。
したがって、エージェントペイメントとはチャットボットに支払いボタンを追加するだけではありません。ソフトウェアに制限付き支出権限を持たせ、機械固有の調達プロセスを構築することを意味します。人間が目標・予算・リスク境界を設定し、エージェントがその範囲内で資金を配分します。支払いは単なる決済行為から、エージェントの意思決定システムの一部へと転換します。
1. エージェントペイメントが独立したトラックとなる理由
1.1 ツール起動から経済的行動へ
エージェントと一般の自動化スクリプトの違いは、推論能力のみにとどまりません。スクリプトは予め定義されたプロセスを実行し、必要なリソースやベンダーは通常コードに固定されていますが、エージェントは環境に応じてパスを選択します。同一の調査タスクにおいて、まず検索結果を購入し、その結果に基づき業界データベースの必要性を判断し、最後に別のモデルを呼び出して検証を行うことがあります。各調達ステップが以降の判断を変化させます。
この「実行中調達」モデルにより、経済的選択がソフトウェアの実行時にもたらされます。エージェントはツールの可用性を判断するだけでなく、購入価値も評価しなければなりません：価格が予算を超えていないか、応答速度がタスク要件を満たすか、過去の納品実績が信頼できるか、代替サービスがより適しているかなどです。従来のツールルーティングは機能マッチングに焦点を当てますが、機械による調達では同時に価格と取引先リスクも処理する必要があります。こうした取引においてリスクを負うのはエージェント自身であり、支払いは成功してもサービスが提供されない可能性があります。
よって、エージェントペイメントの本質的なニーズは無条件の自動支払いではなく、ソフトウェアへの購買権限の制御可能な委譲です。ユーザーは財布全体を容易にエージェントに委ねませんが、明確なタスクに対して数ドルの予算を設定し、数セント単位の複数購入を許可することは十分に可能です。大規模な権限付与には長期的な信頼構築が必要ですが、小規模な権限付与でもすでに実質的な価値を創出できます。
1.2 マイクロペイメント、高頻度取引、および複数の販売者による支払い経済の変化
人間向けインターネットの支払いインフラは、比較的低頻度・高額な取引を処理することに長けています。クレジットカードネットワーク、決済ゲートウェイ、サブスクリプションシステムにはいずれも固定コストがあり、販売者は多くの場合、複数の呼び出しを月単位のパッケージにまとめます。1回あたり数セント程度のAPIリクエストでは、従来型支払いの手数料、チャージバックリスク、口座管理コストが商品価値を上回る可能性があります。
機械による消費は正反対です。エージェントは、単一の成果物を完了するために、数分以内に複数の販売者から複数の購入を開始できます。1取引あたりの金額は極めて小さい一方で、呼び出し頻度は高く、取引数は人間消費者を大幅に上回る可能性があります。ステーブルコインとオンチェーンでのプログラム可能決済は、こうしたシナリオに新たな経済基盤を提供します：資金は24時間稼働し、支払い承認はソフトウェアによって署名可能であり、サービスは1回の呼び出し単位で直接課金できます。
さらに重要なのは、複数販売者調達がAPI市場における競争の在り方を変える点です。サブスクリプションモデルではユーザーが長期的に1ベンダーに縛られがちですが、使い捨て課金（pay-per-use）ではエージェントが各タスクごとに動的に選択できます。サービス提供者は年間契約獲得だけを競うのではなく、瞬時のニーズ獲得も競わねばなりません。価格、パフォーマンス、履行実績などがリアルタイムでルーティング結果に影響を与える可能性があります。
1.3 ステーブルコイン：交換手段から決済インフラへ
初期の暗号資産市場では、ステーブルコイン需要は主に取引や安全資産への逃避に由来していました。発行・保管・コンプライアンス・クロスチェーンインフラが徐々に成熟するにつれ、ステーブルコインは国境を越えた決済、企業のトレジャリー管理、インターネットネイティブな支払いへと進出しています。機械支払いにおいては、ステーブルコインにはもう一つの特有の利点があります：それは通貨であると同時に、プログラムが直接操作可能なデジタル資産でもあることです。
クレジットカード支払いは、カード保有者の本人確認、銀行口座、地理的ネットワークに依存します。エージェント自身には自然人の身分がなく、従来の口座開設プロセスを独立して通過できません。しかし、ポリシー制約付きウォレットはエージェントの資金インターフェースとなり得ます：運用者が限定的な残高を注入し、1取引・1セッションごとの上限を設定し、凍結・取消権限を保持します。エージェントは許可範囲内でのみ支払いに署名します。
これは、オンチェーン支払いがすべての従来支払いに対して本質的に優れていることを意味しません。消費者保護、返金メカニズム、プライバシー、鍵管理、規制上の責任などは依然として解決すべき課題です。しかし、機械間通信、低額・使い捨て課金、グローバルサービス調達という文脈では、プログラム可能ステーブルコインは明確な適合性を示します。初めて、「インターフェースを呼び出す」と「インターフェースに支払う」が同一ネットワークインタラクションに統合される機会が生まれました。
2. 支払いレールは既に登場：x402、MPP、HTTPネイティブトランザクション
2.1 402ステータスコードを商業インターフェースへと転換
HTTPは長年にわたり402 Payment Requiredステータスコードを予約していましたが、ほぼ30年間、一般化したワークフローは形成されませんでした。機械支払いプロトコルがこの意味論を再活性化しました：クライアントが有料エンドポイントを要求し、サーバーが402を返して機械読み取り可能な支払い条件を提示；クライアントが受諾可能なオプションを選択し、署名または支払いを完了した後、資格情報を付与して再リクエストします。
このプロセスの重要性は、人間向け登録ページを不要にすることにあります。価格発見、支払い要件、コンテンツ配信はすべて、プログラムが理解可能なプロトコル層で行われます。開発者にとって、有料APIはアカウント・プラン・キーを前提とした完全なSaaSポータル構築を必要としなくなり、エージェントにとって、サービスは通常のWebページ同様に発見でき、実際に必要になった時点で購入できます。
x402は、この道筋で最も注目されているオープンプロトコルの一つです。HTTP 402を中心に支払いチャレンジと資格情報を整理し、サービス提供者が1リクエスト単位で支払いを回収できるようにします。一方MPPは異なるエコシステムから出発し、チャージやセッションといった機械志向支払い手法を探求します。両者は具体的設計に違いがありますが、共に「機械支払いがアプリケーションプロトコルの一部となり得る」という方向性を検証しています。これは、アプリケーション外部に手動決済プロセスを別途構築する必要がないことを意味します。
2.2 支払いレール多様化の長期性
業界では、最終的に単一の標準プロトコル・単一の決済ネットワーク・単一の支払い方式のみが残ると期待されることが多いです。しかし販売者視点では、多様化には長期的な合理性があります。一度限りのデータ照会には1回呼び出し単位課金が適し、継続的な推論やストリーミングサービスにはセッション課金が適しています。高額サービスには強固な保証と紛争処理が求められ、低額呼び出しには速度とコストが重視されます。また、地域や企業によって選択されるコンプライアンス・決済ネットワークも異なります。
プロトコル層は引き続き革新を続けます。販売者は直接引き落とし、事前承認、エスクロー、ストリーミング支払い、一括決済などを採用するかもしれません。ネットワークはコスト・確定性・流動性・エコシステムツールの間で異なるトレードオフを図ります。売り手にとっては選択の自由であり、買い手にとっては新たな組み合わせごとに追加の連携面が生じます。
下図の設定マトリクスは、この多様化の一断面です：列はプロトコル／支払い方式、行はチェーンを表し、各セルは個別連携が必要な支払い設定です。この表は今なお拡大中です。
図1：断片化下における支払いレール設定マトリクス
つまり、市場の成熟とともに断片化が自然に解消されるとは限りません。銀行カード市場は長期発展の末に単一カード組織に収束せず、クラウドコンピューティングも単一ベンダーに集約されませんでした。成熟市場は差異を排除するのではなく、それらの上に集約・ルーティング・清算レイヤーを構築するのが一般的です。エージェント支払いも同様の進化を遂げる可能性が極めて高いです。この分断はすでに測定可能です。2つの公開エクスプローラー（x402scanおよびmppscan）による過去30日間（2026年9月3日時点）のデータによると：Tempoチェーン上でMPPプロトコルを利用するアクティブな買い手ウォレットは65,591件、Baseチェーン上でx402を利用する買い手ウォレットは19,472件であり、両レールで共通するウォレットは365件（MPP買い手の0.6％未満、x402 Base買い手の2％）に過ぎません。そのうち、各レールで10回以上の取引を完了したのは112件のみであり、多くはユーザー代行で同一鍵を使って両レールで支払いを行うダブルレール集約者であり、買い手自身が第2の支払いレールを採用しているわけではありません。買い手はレール間を流動しておらず、各レールは独自の買い手ベースを蓄積しています。
2.3 販売者の登録は取引の半分に過ぎない
支払いプロトコルは、まず商人が支払いを受け付ける際の障壁を下げます。エンドポイントが見積もりを公開し、資格情報を検証し、サービスを返却できるようになれば、機械向け商業の基本条件を満たします。これにより、増加する開発者ツール・データサービス・コンテンツインタフェースが、いずれも機械による購入が可能になります。
しかし、支払可能な供給があるからといって、需要が自動的に後を追うわけではありません。商人は「機械からいかに支払いを集めるか」を解決しますが、エージェントは依然として「誰から購入すべきか、どの支払い方法を使うべきか、支払い後の納品をどう確認するか」を判断しなければなりません。すべての購入者が各プロトコルを個別に統合し、異なるネットワークで資金を準備し、独立した台帳を維持しなければならない場合、機械による支払いは初期のAPI統合と同様の複雑さを再現することになります——単にAPIキーをウォレットやプロトコルアダプターに置き換えるだけです。
実際の普及は、決済ステップのみならず、取引全体の摩擦度合いに依存します。
3．業界の真のボトルネック：取引に閉じたループがない
図2：機械による調達の完全なプロセス
3.1 最初のハードル：購入可能なサービスの発見
エージェントには、機械が読み取れるサービスディレクトリが必要です。有効なディレクトリは名称とURLのみを含むのではなく、エンドポイントの機能、入出力仕様、価格単位、利用可能なプロトコル、遅延、地理的制限、更新状況なども記述しなければなりません。また、自然言語による意図とAPIパラメータ間のマッピングも必要です。そうでなければ、エージェントは「マクロ経済データが必要」と理解しても、どのエンドポイントがそのタスクを満たすかを特定できません。
オープン市場のディレクトリは、重複・期限切れ・虚偽申告にも直面します。任意の商人が高品質なデータ提供を主張できますが、エージェントは人間の調達担当者のように数日かけて背景調査を行うことはできません。発見レイヤーは、エンドポイントが実際に呼び出せるか、見積もりが実在するか、記載内容と返却された内容が一致するかを継続的に検証しなければなりません。
これは従来の検索とは異なります。検索エンジンは情報の関連性を最適化しますが、機械調達用ディレクトリは取引可能性——機能の適合性・価格の妥当性・支払い互換性・商人の納品能力——も同時に最適化しなければなりません。
3.2 二番目のハードル：見積もりの理解と比較
一見すると類似したAPIはすべて「呼び出し単位課金」となるかもしれませんが、実際には見積もりは比較困難です。あるものはリクエスト単位、別のものは結果アイテム単位で課金し、あるものはモデル推論費用を含み、別のものは追加支払いを要求します。さらに、他のサービスは入力長・実行時間・成功結果に基づいて動的に課金されます。
エージェントは単に名目価格が最も安いエンドポイントを選ぶことはできません。総コスト・納品確率・遅延・成果品質を考慮する必要があります。安価なインタフェースが繰り返し失敗すれば、再試行コストやタスク遅延によって実質的な価格が高くなる可能性があります。したがって、見積もりはサービスレベル・過去の実績・タスク文脈とともに評価されるべきです。
機械可読の見積もりには、有効期間と最終金額の明記も不可欠です。動的価格設定環境では、エージェントが署名するものは曖昧な価格帯ではなく、確固たる約束でなければなりません。また、事業者はサービス手数料・ネットワークコスト・ルーティング手数料など、手数料構成を把握して信頼できる予算を設定する必要があります。
3.3 第三のゲート：資金配分とクロスレール流動性
エージェントが複数のチェーン・複数のプロトコルにまたがってサービスを同時購入する必要がある場合、最も単純な方法は各ネットワークに事前に資金を積むことです。しかし、これにより少量の資金が多数に分割され、未使用ネットワーク上では資金が遊休化し、人気ネットワークでは残高不足が生じます。残高補充にはブリッジング・スワップ・ガス代・セキュリティ操作が必要です。
単一ユーザーにとってですら既に煩雑ですが、多数のエージェントを管理する企業にとっては問題がさらに拡大します：各エージェントがどれだけの残高を持つべきか、誰が補充責任を負うか、不正使用をどう防ぐか、異なるネットワーク間で資産と手数料をどう集計するか？ 統合された資金レイヤーがなければ、支払いレールが増えれば増えるほど財務的複雑さも高まります。
理想としては、エージェントが見るべきは複数のネットワーク残高ではなく、単一の利用可能予算です。基盤システムが決済経路選択・流動性管理・透明な見積もり提供を担います。これは、旅行者が1枚のカードで各国で支払いを行うのと同様の原理です：ユーザーは総与信枠と為替レートを気にするだけで、各目的地ごとに現地口座を開設する必要はありません。
3.4 第四のゲート：ポリシーに基づく承認
自律型支払いで最も容易に引き起こされる懸念は、エージェントが制御不能に支出することです。解決策は「完全禁止」と「完全承認」の二者択一ではなく、多層的なポリシーを構築することです。
取引ごとの上限額は単一のミスによる損失を制限し、セッション予算はタスク全体の支出を制約し、取引先ホワイトリスト／ブラックリストは相手方を管理し、カテゴリルールは購入対象を制限し、レート制限は短時間内の異常な呼び出しを防止します。高リスクまたは高額取引には手動確認をトリガーさせることも可能です。ポリシーは運用者が設定し、エージェントはその範囲内でしか行動できません——自ら上限を引き上げることは許されません。
ウォレットは署名処理のみを担うべきではなく、タスク、アイデンティティ、監査記録と統合される必要があります。「どのエージェントが、どのタスクのために、どのようなポリシーに基づいてこの支払いを承認したか？」という問いに答えるためです。そうでなければ、企業が得るのは単なるオンチェーン取引ハッシュの羅列となり、内部統制やコスト帰属要件を満たせません。
3.5 第五段階：決済完了＝サービス提供ではない
ブロックチェーンは資金が一つのアドレスから別のアドレスへ移動したことを証明するのに優れていますが、APIが正しい内容を返したことを本質的に証明できません。取引が決済を完了しても、サーバーがタイムアウトしたり、エラー状態を返したり、宣伝された内容と異なるデータを提供したりすることがあります。エージェントにとってこれはエッジケースではなく、調達リスクの本質です。
従来のECでは、物流・レビュー・返金を通じて支払いと納品を結びつけますが、マシンサービスには物理的物流がなく、納品は一時的なHTTPレスポンスに過ぎない場合があります。支払いシステムが資金の流れのみを記録し、販売者が自社のレスポンスのみを記録するなら、販売者とプロトコルを横断する統一的な履行ビューが市場に欠けます。
注意すべきは、レスポンスを記録することと品質を証明することは同義でない点です。しかし、支払いとレスポンスを相関付けることで、「支払済みかつ結果受領」「支払済みだがサービス失敗」「未決済」などの基本状態を区別できます。これがマシン取引の信頼性構築における第一層の事実です。
3.6 第六段階：統一的な調整と責任定義
一つのタスクには数十のマイクロ購入が含まれる場合があります。各取引が異なるウォレット・プロトコル・販売者バックエンドに分散すると、ユーザーは最終成果物の費用がなぜその金額になったのかを把握できなくなります。企業は支出をプロジェクト・チーム・顧客・原価センタに帰属させ、監査可能な証拠を保存する必要があります。
統一台帳は、調達意図・販売者・見積もり・承認ポリシー・決済結果・レスポンスステータス・失敗理由を同時に記録すべきです。これは財務部門だけでなく、エージェント最適化にも役立ちます。システムは、どのデータソースが頻繁に失敗するか、どの経路が高コストか、特定タイプのタスクにおける典型的な調達構成を分析できます。
支払いが推論チェーンに組み込まれると、コストはモデル判断へのフィードバック信号になります。統一的な調整がなければ、エージェントは回答のみを最適化でき、回答を得る経済プロセスは最適化できません。Agent Paymentの長期的価値の大部分は、まさにこの種の可観測性に由来します。
4. 支払いプロトコルからマシン調達レイヤーへ
4.1 将来のコア抽象化は「支払う（Pay）」ではなく「購入する（Buy）」
支払いは対象と価格が明確になってからの行動ですが、調達は需要から受諾までの全プロセスをカバーします。エージェントにpay()関数を公開しても、既知のアドレスへの送金しかできません。一方、buy()機能を公開すれば、システムは需要を受け取り、サービスを発見・比較し、支払いを実行して検証可能な結果を返すことができます。
この違いが業界の分業を決定します。プロトコルは標準化された支払いメッセージを提供し、ウォレットは署名と資産を管理し、決済ネットワークは価値を移動させ、ディレクトリは供給を集約し、調達レイヤーはこれらを単一タスクに統合します。個々のコンポーネントは重要ですが、いずれも完全な取引を単独で代表できません。
マシン調達レイヤーはオープンである必要があります。すべての販売者が同一プロトコルへ移行することを強いるべきではなく、閉鎖的ディレクトリによって誰が購入可能かを決定すべきでもありません。より持続可能なモデルは、複数の支払いルートとの互換性を確保し、見積もりにルーティングコストを明示し、エージェントがポリシーに基づいて自律的に選択できるようにすることです。
4.2 買い手の集約は売り手の集約よりも重要
インターネットプラットフォームは通常、まず供給を集約し、その後消費者を惹きつけます。マシン市場では、供給はすでにAPIという形で広く存在していますが、欠けているのは継続的な購入が可能な標準化された買い手です。装備されたエージェントは、断片的・偶発的な需要を安定した取引フローに変換できます。
買い手の集約はロングテールサービスの可視性も向上させます。人間の開発者は新規サプライヤー評価の時間コストが高いため、馴染みのある大手ブランドを使いがちですが、エージェントが標準化された機能・価格・履行シグナルを読み取れるなら、各タスクに最も適したサービスを選べます。これにより新規販売者の顧客獲得コストが低下し、既存販売者も実際のパフォーマンスで競わざるを得なくなります。
ただし、買い手の入り口は新たなプラットフォーム権力を生む可能性もあります。デフォルトディレクトリ・ランキング・支払い経路を支配する者がトラフィック配分に影響を与えるかもしれません。そのため業界には、透明なランキングルール・説明可能な手数料・移植可能な取引記録が必要です。集約は摩擦を減らしますが、オープンプロトコルを閉鎖的チャネルに再パッケージしてはなりません。
4.3 実際の取引データに基づく評判構築
マシン買い手は極めて迅速に意思決定し、長時間のデューデリジェンスには依存できません。見積もり表示と同時に取引相手のシグナルを必要とします。従来の評価やユーザーレビューは参考になりますが、ウォッシュボリューム・シビルアカウント・関係者による操作が容易です。レビューに実際の支払いが不要なら、攻撃コストは特に低くなります。ERC-8004（エージェント向け初のパーミッションレスなオンチェーン信頼レイヤー）に関する最近の実証研究はこれを確認しています［6］。プロトコル仕様には明記されています：「支払いは本プロトコルとは直交する」——レビューはデフォルトで実支払いと紐づける必要がなく、支払い証明は任意フィールドです。その結果、イーサリアム・BSC・Base（2026年5月13日時点）では、それぞれ73.5％・59.2％・90.6％のレビュアーが協調的なシビル行為を示しました。
より信頼性の高い基盤は、実際の支払い済み通話に紐づく成果記録である：サービスエンドポイントが完了した決済件数、レスポンス成功率、一般的な遅延時間、支払い後の無応答割合の高さなど。これらの指標は依然としてコンテンツ品質を完全に表すことはできないが、自己申告よりも検証可能な事実により近い。
データが蓄積されるにつれ、市場は階層化された評判システムを発展させる可能性がある。第1層は客観的な取引状況、第2層は再現可能なサービス指標、第3層は特定タスク向けの品質評価である。エージェントは金額とリスクに応じて必要な証拠の強度を選択できる：数セントのデータ照会には統計的信号で十分だが、高価値調達には保証・監査・紛争解決が求められる。
4.4 予算戦略はエージェントにとって重要な能力となる
現在、エージェントは主に回答品質・タスク完了率・ツール呼び出し精度で評価されている。有料環境へ進出すると、経済指標も追加必須となる：同一品質達成にいくら支出したか、予算内でのタスク完了可否、高価データ購入の妥当時期、速度・コスト・信頼性のバランス取り方など。
これにより訓練・評価に新たな方向性が生まれる。エージェントは「どのツールが質問に答えられるか」だけでなく、「現タスクの価値を考慮し、このツール購入が妥当か」も学ぶようになる。低コストサービスで初期フィルタリングを行い、重要結論のみ高品質検証を購入するケースや、予算枯渇時に呼び出し頻度を減らす、あるいはユーザーから追加承認を求めるケースも想定される。
この意味で、エージェント支払いはモデル機能外部の金融プラグインではなく、意思決定知能の一部である。真正に成熟したエージェントはリソースを利用するだけでなく、リソースの価格付けも行うべきである。
5. エージェント支払いの今後の進化パス
5.1 第1段階：開発者ツールとデジタルサービスが先行
最初の大規模シナリオは、検索・データ・プロキシスクレイピング・モデル推論・コード実行・ストレージ・コンテンツ生成など、純粋なデジタル配信サービスが中心となる可能性が高い。これらはAPIで提供され、限界配信コストが低く、同一ネットワークセッション内で支払いと応答が完結し、複雑な物流を伴わない。
この段階の取引金額は極めて小さく、ユーザーは開発利便性とタスク完了率を重視する。市場はプロトコルを迅速に検証するが、取引量は高度に分散化する。多くの呼び出しは従来のAPIキー・サブスクリプションで処理され、機械による支払いは一時的ニーズ・他事業者調達・事前アカウント開設が困難なロングテールサービスで主に活用される。
5.2 第2段階：企業予算とマルチエージェント連携
企業が複数のエージェントを展開し始めると、資金管理は個人ウォレットから組織レベルの口座システムへと昇格する。企業は役割ごとの予算配分・購入可能カテゴリ制御・承認閾値設定・経費の財務システムへの記録を必要とする。エージェント間の内部精算も発生しうる：調査エージェントがデータを購入し、分析エージェントがコンピューティングパワーを購入し、実行エージェントが外部サービスを呼び出す。
この時点で、支払いの新規性よりセキュリティ・コンプライアンスが重要となる。企業は鍵管理・権限分離・取引監視・ベンダー審査・監査証跡を重視する。既存財務プロセスと統合可能なインフラのみが、実験段階から本番導入へと移行できる。
5.3 第3段階：デジタルサービスから実体経済への拡張
航空券・ホテル・物流・広告・専門サービスなどもエージェントの調達対象となり得るが、現実世界の取引にはより複雑な本人確認・返金・課税・紛争処理が必要となる。ステーブルコインは決済問題の一部しか解決できず、消費者権利や商用契約を代替できない。
したがって業界は、「自律的支払い」をすべての中間業者排除と誤解すべきでない。むしろ取引価値が増すほど、保証・保険・信用・仲裁が再登場する——ただそれらが機械呼び出し可能なサービスへと変容するだけである。将来のエージェント支払いスタックは、オープン支払いプロトコルと従来型金融接続を併存させ、一方が他方を置き換えるものではない。
5.4 第4段階：クロスポトコルルーティングからクロスマーケット実行へ
長期的には、エージェントが購入するのは単なるAPI応答ではなく成果である。「信頼性の高い業界レポートを作成せよ」というユーザー要求に対し、システムは検索・データベース・翻訳・モデル・検証サービスを自動的に統合する。裏側では複数の取引が発生するが、ユーザーは総予算・根拠情報源・最終納品のみを見る。
これにより支払いルーティングはマーケット実行へと進化する。システムは複雑な目標を調達ポートフォリオに分解し、失敗ベンダーを動的に置き換え、総コストと品質の最適化を行う必要がある。プロトコル互換性は単なる基盤であり、真の差別化要因は需要理解力・取引データ・実行フィードバックである。
6. リスクと未解決課題
エージェント決済には莫大な創造的潜在能力があるが、現実の制約を無視することはできない。第一にセキュリティがある。プロンプトインジェクションによりエージェントが悪意あるサービスを購入するよう誘導される可能性、サプライチェーン攻撃による受取先アドレスの置換、不備なポリシーによる大量の重複支払いなどだ。支払い操作は信頼されていないコンテンツから分離され、制限・シミュレーション・取消・異常検知機能を備える必要がある。
第二にプライバシーがある。調達記録はエージェントが実行中のタスクを露呈し、オンチェーンの公開データはユーザー識別子と商業的意図を結びつける可能性がある。システムは機密性の高いメタデータ漏洩を最小化し、監査要件とプライバシーのバランスを取る必要がある。
第三に責任（ライアビリティ）がある。エージェントが誤った購入を実行した場合、販売業者が納品を怠った場合、あるいはプロトコル変換が失敗した場合、誰が損失を負うべきか？低額取引では自動リスク受容が可能だが、高額取引では明確な責任境界が必要だ。紛争処理メカニズムのない決済ネットワークは、高額商業取引への直接参入が困難になる。
第四に規制がある。ステーブルコイン発行、ウォレット管理、国境を越えた送金、販売業者向け支払いは、各国の異なる法域における規則の対象となる。機械は実行者であって法的責任主体ではない。インフラは、すべての自律的取引を明確な運用者・承認ポリシー・資金出所へと追跡可能でなければならない。
第五に商業的持続可能性がある。マイクロペイメント収益は、ネットワークコスト・流動性・リスク管理手数料によって容易に侵食される。プラットフォームが隠れたマーアップで体験を補助すると、買い手の信頼を損なう。手数料は透明性を持たねばならず、スケール・ルーティング効率・付加価値サービスを通じて健全なビジネスモデルを構築する必要がある。
これらの課題は当該分野を否定するものではなく、むしろエージェント決済が単一プロトコルのみで完結しないことを示している。最終的には、支払い・ID・権限・発見・評判・調整を統合した複合型インフラとなるだろう。
7. SELAT：マシンネイティブ商取引の買手側を支援する
「SELAT」はマラヤ語で「海峡」を意味し、マラッカ海峡（Selat Melaka）に由来する。何世紀にもわたり、貨物がどの港から来ようと、どの市場へ向かおうと、東西貿易の主流はこの水路を通ってきた。SELATは、マシンネイティブ商取引におけるそのような海峡を目指す：どの支払いレイルに販売業者が接続していようと、エージェントの需要はここを通じて流れる。
SELATはAIネイティブ企業であり、マシン決済分野に買手側から参入することを選択した。SELATはマシンネイティブ商取引の買手側レイヤーである。その核心的目標は、販売業者に移行を強いる新たな支払いレイルを作成することではなく、エージェントが既存のレイル上で調達を完了できるようにすることにある。焦点は二つの核心課題に当てられている：第一に、支払い設定の断片化——レイル・プロトコル・チェーン・資格情報がすべて異なり、各販売業者ごとに新たな連携が必要になること；第二に、取引相手リスクの測定不足——決済成功＝サービス提供完了ではない点である。
図3：SELAT買手側レイヤーの概念図
断片化への対応として、SELAT CLIはプロトコル・支払いスキーム・決済ネットワークの差異をインフラ層に閉じ込め、エージェントが単一コマンドでマルチレイル調達を完了できるようにする。発見・見積もり・承認・支払い・納品状況記録・調整はすべて同一調達プロセスに統合され、すべての呼び出しは同一台帳に記録される。
• 1つのトレジャリーでN種類の支払いレイル利用
エージェントはセルフカストディのUSDC残高を保有し、チェーンごとの事前入金やプロトコルごとの異なるクライアント管理は不要。
• 統合エンドポイントカタログ
SELAT CLIはCircle・MPP・Apify・pay.shの4つの第三者サービス登録簿に加え、SELAT独自カタログも統合し、リアルタイムの意図に基づき4,000以上のサービスエンドポイントを発見・比較可能にする。
• 厳格な支出上限
運用者は取引単位の上限およびセッション予算を設定でき、任意の時点で支出許可を凍結可能。エージェント自身による上限引き上げは不可。
• 販売業者の移行ゼロ
販売業者は希望する支払いレイルを維持でき、SELATへの再登録なしにエージェントから発見・購入可能。
資金面では、SELATはCircleやMetaMaskのエージェントウォレットを含むあらゆるエージェントウォレットと連携。x402やMPPなどの支払いレイルをリアルタイムの見積もりに基づき最適ルーティングする。
7.1 ERC-8004：正しいプリミティブ、疑わしいシグナル
ERC-8004は、アイデンティティ・レジストリ、評判・レジストリ、検証・レジストリの3種類を定義し、買い手が売り手にレビューを提出できるようにする。方向性は正しいが、支払いと評判を明示的に分離しており、フィードバックは実際の取引から来なくてもよく、支払い証明の添付は任意である。
展開済みエコシステムに関する実証研究によると、Baseではレビュアーの93.8％がx402支払いを一度も行っていないにもかかわらず、全フィードバックの94.9％を提供している。また、多くのフィードバックには協調的なシビル攻撃的行動が見られる［6］。レジストリは主張を記録するが、買い手が本当に必要としているのは「結果」である。
7.2 実取引データと連動した評判こそ買い手が求めるもの
支払インフラは資金決済の有無を確認できるが、サービスの返答内容までは見えない。事業者は自社の応答は見えるが、市場全体は見えない。レジストリはエンドポイントを一覧表示できるが、レビューが実購入から来ていることを証明できない。
購入を実行する買い手層こそ、取引の両端を結ぶ最適な位置にある。SELATを通じて完了したすべての購入は、支払先エンドポイント、決済金額、および支払後の配信状況メタデータ（2xx／4xx／5xx）を記録する。これらの記録は事業者および支払インフラごとに継続的に蓄積され、「決済－配信グラフ」のデータ基盤を構成する。
明確な区別が必要である：支払いと配信状況を関連付ける記録は、配信品質や見積もり正確性の独立した証明とは等価ではない。しかし、それはレジストリベースの評判が欠いていた基盤——実支払 invocation に紐づく結果データ——を提供する。
7.3 取引前の取引相手の信頼性の取得
人々がX上で第4世代インターネット向けGoogle PageRank風信頼メカニズムの設計を議論していた頃、SELATはすでに「トランザクタビリティ指数」を決済－配信グラフ上に立ち上げ、エージェントが実取引結果に基づく取引相手の信頼性データをランタイムで利用できるようにしていた。
この指数は見積もりとともに返されるため、エージェントはタスクを中断して事業者を個別に調査する必要はない。リスクを示すが市場へのアクセスゲートは設けず、エンドポイントは引き続き発見・購入可能であり、エージェントは予算・タスク重要度・リスク許容度に基づき意思決定を行う。
エージェントにはブランド物語を読む時間はない。支払い前に知りたいのはただ一点：このエンドポイントは実取引でどの程度のパフォーマンスを発揮するか？ 機械ネイティブな商業における信頼性は、主張ではなく結果から得られるべきである。
図3：見積もり段階におけるトランザクタビリティ・シグナル
現在、SELAT CLIはClaude Code、Codex、Cursor、Gemini CLI、OpenClaw、Hermes、Grok Botなど、さまざまなエージェントランタイム環境に対応済みである。
8．まとめ：機械経済には高速化された支払インフラ以上のものが求められる
エージェント支払いは、過大評価されやすく、また過小評価されやすい段階にある。過大評価されやすいのは、ステーブルコイン支払いを技術的に完了させても、エージェントが成熟した商業的自律性を獲得したわけではないからである。過小評価されやすいのは、ソフトウェアが明確な制約のもとで外部機能を購入できるようになると、機械経済の組織手法・価格モデル・競争境界がすべて変化するからである。
支払プロトコルは既に、機械が見積もりを受領し決済を完了できることを実証済みである。次なる鍵となるステップは、孤立した支払いを完全な調達へと拡張すること——すなわち、エージェントが適切なサービスを発見し、真のコストを理解し、予算内で複数の支払インフラを横断して支払い、配信を確認し、すべての取引を監査可能・学習可能な記録へと変換すること——である。
将来の機械経済には単一のブロックチェーン・単一のプロトコル・単一のウォレットは存在しない。多源供給は長期にわたって継続し、真に価値あるインフラストラクチャは買い手がこの複雑性を乗り越えるのを支援する。エージェント支払いは、支払インフラ・供給源・デフォルト支払い・信頼メカニズムを統合し、技術的能力を実需要へと転換する必要がある。
ソフトウェアが買い手として振る舞い始めるとき、支払いはその最初の一歩に過ぎない。より重要な問いは常にこうである：ソフトウェアは、制御可能・透明・検証可能な方法で、本当に有用な取引を完遂できるか？
参考文献
[1] Circle, 「オープン・エージェント経済の構築」, 2026年. https://www.circle.com/blog/building-the-open-agentic-economy
[2] SELAT、「エージェント型支払いにおけるカウンターパーティリスク：測定されていない半分」、2026年。https://selat.ai/insights/counterparty-risk-agentic-payments
[3] Google Cloud、「新しいエージェント支払いプロトコル（AP2）によるAIコマースの推進」、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ら、「信頼できないエージェントを信頼できるか？ERC-8004分散型AIエージェントエコシステムに関する実証的研究」、arXiv、2026年。https://arxiv.org/abs/2606.26028
[7] SELAT公式サイト：https://www.selat.ai
本稿は寄稿によるものであり、BlockBeatsの見解を反映したものではありません。
