Solana 財団とGoogleが提携しPay.shを発表、AIエージェント経済におけるWeb2とWeb3の決済経路を開拓できるか？

原文作者：Hendrix、外捕研究（Web3Caff Research）研究員

Web3 業界で起こっている市場のホットトピック、技術動向、エコシステムの進展、ガバナンスの状況などを、いかに簡単に把握できるか？外捕研究（Web3Caff Research）が提供する「市場脈動分析」コラムでは、最前線から現在のホットなイベントを深く掘り下げて選定し、その価値の解釈、解説、原理分析を行います。現象の本質を捉え、すぐに私たちと一緒に Web3 最前線の市場動向をキャッチしましょう。

AI エージェントの能力が向上し、カバーするエンドツーエンドのタスクが増えるにつれ、エージェント向けの決済システムを構築することは、従来の加盟店やサービスプロバイダーにとって必須の変化となっています。しかし、既存のソリューションにはそれぞれ限界があります。従来の決済システム（クレジットカードやサードパーティ決済プラットフォームなど）は、本来、実際の人間ユーザー向けに設計されており、複雑な本人確認やリスク評価などのプロセスが必要で、エージェントには適していません。一方、新興のエージェント決済プロトコル（Coinbase が開発・推進する x402、Tempo と Stripe が開発した MPP（Machine Payment Protocol）など）は、まるで別の門戸を構えるかのように、完全にオンチェーン決済向けに構築されています。決済全体がチェーン上で処理され、オンチェーン検証によって安全性が保証されるため、サービスプロバイダーは従来の決済チャネルとは別に、異なる決済システムを新たに構築する必要があり、利用ハードルが高まっています。従来の決済手段と新興のエージェント決済プロトコルは、まるで平行する車線のように、うまく統合されておらず、その結果、エージェントが自律的に購入できるサービスは通常、Web3 フレンドリーな範囲に限定され、大規模なワークフロー連携ができていません。この課題に対し、Solana 財団は Google Cloud と共同で Pay.sh を発表しました。これは「エージェントとエンタープライズ級サービスインフラ間の決済ゲートウェイ」と位置づけられ、エージェントがより多くのサービスを呼び出すための最後のステップを繋ぐものです。

コンプライアンスに関する注意事項：以下の内容は、Pay.sh とその技術的原理および設計ルールを客観的に分析したものであり、いかなる提案や勧誘を構成するものではありません。本情報に基づいて意思決定を行わないでください。また、お住まいの国・地域の法令を厳守してください（中国大陸の読者の皆様は、『中国大陸におけるブロックチェーン及び仮想通貨関連法規の整理と重点項目の要約』を必ずお読みいただき、お住まいの国・地域の法律で禁止されている金融関連行為には一切関与しないことを強くお勧めします）。

Pay.sh では、ユーザーはクレジットカードまたはステーブルコインを使用して Solana ウォレットに迅速にチャージできます。これにより、Solana ウォレットは Web2 リソースの世界において、エージェントのアイデンティティおよび支払いアカウントのプロキシとして機能します。エージェントがサービスを呼び出す必要がある場合、アカウント登録や API キーの入力は不要です。Pay.sh ゲートウェイは、Google の ID システムのようにエージェントの正当な身元を宣言し、エージェントが統一されたアカウント ID を使用して、Google Cloud や Alibaba 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 の決済エコシステムを繋ぎ、エージェントがリソースを取得するための適切なアイデンティティを付与することです。エージェントのウォレットは、アイデンティティであると同時に支払い手段でもあり、サービスプロバイダーの Web サイトで別途アカウントを登録してサービスを取得する必要はありません（現在、一部のサービスプロバイダーは、エージェントが人間のふりをしてサービスに登録することを規約違反として扱う場合があります）。さらに、Pay.sh は Google との提携により、エージェントが API プロキシとトラフィックスケジューリングを Google Cloud 上で実行できるようにし、アクセス制御とログのコンプライアンスを確保し、エージェントの行動を合理的な範囲内に収めることができます。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 の今後の展開を引き続き観察していくことができます。

要点構造図：

免責事項: 本レポートは外捕研究（Web3Caff Research）によって作成され、含まれる情報は参考目的のみであり、いかなる予測や投資アドバイス、提案、勧誘を構成するものではありません。投資家は本情報に依拠して、有価証券、暗号資産の購入・売却、またはいかなる投資戦略を採用しないでください。本レポートで使用される用語や表明された見解は、業界の動向を理解し、Web3 およびブロックチェーン業界の責任ある発展を促進することを目的としており、明確な法的見解や外捕研究（Web3Caff Research）の見解として解釈されるべきではありません。本レポートの見解は、記載された日付時点における著者の個人的な意見のみを反映しており、外捕研究（Web3Caff Research）の立場