Web3業界で起こっている市場のホットトピック、技術動向、エコシステムの進展、ガバナンスの状況などを簡単に把握するには？ 外捕研究（Web3Caff Research）が提供する「市場パルス分析」コーナーでは、現場で起こっているホットイベントを調査・選別し、その価値を解説・評価し、原理を分析します。現象の背後にある本質を見抜き、すぐにWeb3の第一線の市場動向をキャッチしましょう。
執筆者：Hendrix、外捕研究（Web3Caff Research）研究員
出典：Web3Caff Research
AIエージェントの能力が強化され、エンドツーエンドのタスクへの対応範囲が広がるにつれ、エージェント向けの支払いシステムを構築することは、従来の商家やサービスプロバイダーにとって避けられない変化となっている。しかし、現在のソリューションにはそれぞれ限界がある。クレジットカードやサードパーティ支払いプラットフォームなどの従来の支払いシステムは、実在のユーザーを対象に設計されており、複雑な本人確認やリスク評価プロセスを必要とするため、エージェントには適していない。一方で、新興のエージェント支払いプロトコルであるx402（Coinbaseが開発・推進）や、TempoとStripeが開発したMachine Payment Protocol（MPP）などは、別途のシステムとして構築され、完全にチェーン上支払いに特化している。これらのプロトコルでは、支払い全体がチェーン上で処理され、チェーン上の検証によってセキュリティを確保するため、サービスプロバイダーは従来の支払いチャネルとは別に、異なる支払いシステムを構築する必要があり、利用のハードルが高くなる。従来の支払い方案と新興のエージェント支払いプロトコルは、まるで並行する二つのレーンのように互いに融合しておらず、その結果、エージェントが自律的に購入できるサービスはWeb3に配慮した範囲に限定され、ワークフローの大規模な連携が実現できない。この課題に対応するため、Solana財団とGoogle Cloudは、「エージェントとエンタープライズサービスインフラ間の支払いゲートウェイ」としてPay.shを共同で発表し、エージェントがより多くのサービスを呼び出すための最後の一歩を実現した。
コンプライアンス通知：以下はPay.shおよびその技術的原理と設計ルールに関する客観的な分析であり、いかなる提案またはオファーを構成するものではありません。この情報に基づいて意思決定を行わないでください。また、お住まいの国や地域の法律・規制を厳守してください（中国本土の読者は『中国本土におけるブロックチェーンおよび仮想通貨関連の法律・規制の整理と重点ポイント』を必ずご参照ください）。お住まいの国や地域の法律で禁止されている金融行為には一切関与しないでください。
Pay.sh は、ユーザーがクレジットカードまたはステーブルコインを用いて Solana ウォレットに迅速にチャージできるようにし、その後、Solana ウォレットは Web2 リソースの世界においてエージェントの身份と支払いアカウントエージェントとして機能します。エージェントがサービスを呼び出す際、アカウント登録や API キーの入力は不要で、Pay.sh ゲートウェイは Google 認証システムのようにエージェントの正当な身份を認証し、エージェントが Google Cloud や阿里雲などのこれまで取得が困難だった開発リソースを、統一されたアカウント身份で購入できるようにします。
現在、Pay.sh でサポートされている API サービス 画像提供：プロジェクト公式サイト
Pay.sh の支払いフローは、先ごろ話題となった x402 プロトコルと類似しており、両者とも HTTP 402 ステータスコードに基づいています。エージェントが外部サービスの呼び出しを必要とすると、有料リソースに対してリクエストを送信し、サーバーはステータスコード 402（支払いが必要）を返し、同時に支払い金額、支払いプラン、受取アドレス、支払い有効期限などの詳細情報を付与します。Pay.sh はこの内容を解析してウォレットに承認を要求し、ウォレットが支払いを完了して支払い証明書を生成すると、Pay.sh はその証明書を含めて再度サービスリクエストを送信することで、通常の応答を得ることができます。しかし、さまざまな API 使用シナリオに対応するため、Pay.sh は x402 と MPP の両方の支払いロジックを互換性を持たせています。サーバーがステータスコード 402 を返した場合、Pay.sh は対象サービスの支払い方法をさらに判断します。一度限りのデータアクセス（支払いにより一度のアクセス権を取得）または使用量に基づくアクセス（支払いにより固定量のアクセス権を取得）である場合、Pay.sh は一度限りの固定金額の送金を構築し、チェーン上でブロードキャストします。継続的な課金またはセッションベースの課金（使用量に応じて一括請求）である場合、Pay.sh は MPP（Machine Payment Protocol）が導入したセッション認可証明書をサポートし、予算上限を認可に記録してサーバーに返送します。これにより、エージェントは短時間内に同じサービスを繰り返し呼び出せるようになり、同種の認可を頻繁にリクエストする必要がなくなります。Pay.sh は各呼び出し時に残高を更新し、残高が尽きた場合やサービスが期限切れになった場合、自動的にセッション認可を再開します。Pay.sh は対象サービスの要件に応じてより適切な支払い経路を自動的に選択し、利用コストと管理コストを削減します。また、Pay.sh はウォレットが常にローカルで安全に保存されることを保証し、支払いが必要な場合のみユーザーの確認を求めます。情報が返却された場合、Pay.sh はデータとコマンドを区別します。サービスプロバイダーが返すすべての外部コンテンツ（タイトル、本文、API 説明など）は、Pay.sh によって信頼できない入力と見なされ、エージェントはサービスプロバイダーからのコマンドを直接実行せず、悪意のあるプロンプトインジェクションやその他の攻撃を防ぎます。
Pay.sh の最大の利点は、サービス提供者向けに簡単にデプロイ可能なゲートウェイを提供している点です。サービス提供者は、自社の支払いパスまたは API を大規模に変更することなく、支払いゲートウェイを自社のサービスネットワークに統合できます。サービス提供者は、支払い関連パラメータを記述した宣言的ファイルを提供するだけで、ルーティングルールを定義することで、エージェントが一定量までは無料でサービスを利用し、定額を超えた場合に課金するといった複雑な使用シナリオ、さらには段階的課金（使用量に応じて異なる料金を設定）などに対応できます。また、Pay.sh は支払い分割機能も提供しており、サービス提供者が受け取った料金は自動的に複数のアドレスに分配されます。たとえば、2% を支払いデータの著作権料として、5% をクラウドコストとして、残りを自社運営に残すといった設定が可能です。サービス提供者は、受取アドレスを設定する際に異なる割合または金額を定義するだけで、複数アカウントの決済を一度に実現できます。登録完了後、サービス提供者は自社が提供する API サービスデータを Pay Skill Registry に公開でき、エージェントは登録表を照会して適切な API サービスを発見・選択できます。
Pay.sh は x402 および MPP の競合相手ではありません。x402 と MPP プロトコルがチェーン上のエージェント支払いをより信頼可能にする一方で、Pay.sh は Web2 と Web3 の支払いエコシステムを統合し、エージェントがリソースを取得するための識別情報を付与することを目指しています。エージェントのウォレットは識別情報であり、支払い手段でもあり、サービスプロバイダーの公式サイトでアカウントを登録する必要がなくなります（現在、一部のサービスプロバイダーは、エージェントが人間のようにサービスに登録することを違反行為と見なす可能性があります）。さらに、Pay.sh は Google との提携を通じて、エージェントが Google Cloud 上で API プロキシおよびトラフィックスケジューリングを実行できるようにし、アクセス制御とログのコンプライアンスを保証し、エージェントの行動を適切な範囲内に収めます。Pay.sh は厳選されたサービスディレクトリと価格発見を提供し、エージェントが無防備なネットワーク環境でサービスをランダムに発見する必要がなくなり、同時に x402 および MPP の異なる支払い方法を呼び出すことができ、サービスプロセスは Google Cloud 上で企業コンプライアンス要件を満たすことができます。これらは、単一の支払いチャネルである x402 と MPP がカバーできないエージェント支払い機能を補完し、同時にエージェントビジネスが Web3 へ流れ込む入口を開きます。さらに、Pay.sh は Google が導入した複数のエージェントビジネスプロトコルの最終的な支払いフェーズを補完します。たとえば、A2A（Agent2Agent Protocol）はエージェント間の通信とタスク委譲を実現し、AP2（Agent Payments Protocol）はコンプライアンス検証を実現し、UCP（Universal Commerce Protocol）はサービス発見と実行を実現します。Pay.sh は最終的なサービス価値のスムーズな決済を担当します。Pay.sh の登場は、Web2 エージェントビジネスのプロセスも補完し、二つの世界の価値移動の交差点となります。これは同時に Solana プロトコルエコシステム自体のアップグレード機会でもあります。x402 プロトコル環境では多数のラッピング API が存在し、サービス提供者が元のサービスプロバイダーの利用規約に違反してサービスを転売するケースがあります。たとえば、データベースサイトのデータを悪意を持ってスクレイピングして転売したり、大規模モデル API をラッピングして他人に転売したりするケースです。このような環境では、エージェントは許可されたサービスと悪意のあるスパムサービスを区別できませんが、Pay.sh の支払いゲートウェイと Google の協力により、エージェントが Pay.sh を通じてサービスを利用する際、潜在的なリスクを低減できる可能性があります。Pay.sh の導入は、Solana プロトコルがエージェント支払いに背書とインフラ支援を提供することを示しており、これにより Solana 自体にさらに多くの Web2 支払い流量が誘引され、Solana ウォレットの機能がさらに強化され、普及が加速します。
しかし、Pay.shは現在、完璧な支払いゲートウェイソリューションとは程遠い状況です。Pay.shのサービスプロバイダーレジストリには、現在、アクセス制御メカニズムや分散型検証メカニズムが欠けており、未承認のサードパーティ製ラッピングサービスや悪意のあるサービスを効果的に区別することが依然として困難です。エージェントは偽のサービスに接続する高いリスクにさらされており、ユーザーに損失をもたらす可能性があります。さらに、Pay.sh自体が基本的な支払いプロトコルの設計を行っていないため、支払いプロセスのセキュリティは主に下層プロトコルの設計に依存しており、これはPay.shに制御不能な外部リスクをもたらし、さまざまなプロトコルへの対応不足により支払い失敗の潜在的リスクも生じる可能性があります。サービスプロバイダーの観点から見ると、Googleプラットフォームの後ろ盾があるにもかかわらず、各国・地域のAPIベンダーは、サービス自体のデータプライバシー管理および支払いに関するコンプライアンス要件から、Pay.shが提供するサービスを敬遠する可能性があります。これは、Pay.shを利用するサービスプロバイダーの数を制限するだけでなく、将来的にPay.shがより多くのコンプライアンス対応を迫られる可能性もあります。しかしいずれにせよ、Pay.shのリリースは、エージェント支払いインフラがWeb2とWeb3の融合を現実のものにする第一歩を踏み出したことを示しており、チェーン上ウォレットがエージェントの多様なタスク参加を裏付ける機会を得ることになります。したがって、今後もPay.shの今後の展開を注視していくべきです。
キーポイント構造図：
