メインコンテンツにスキップ
学ぶ用語集エージェント間の支払い
用語集

エージェント間支払いとは。

定義

エージェント間の支払いは、1つのAIエージェントが別のエージェントに行う支払いで、通常はプログラム的に、通常はステーブルコインで行われます。支払者と受取人の両方が自律的です(リアルタイムで取引を確認する人間はいません)。エージェントから人間への支払い(エージェントが人間が運営するビジネスに支払う)や、人間から人間への支払い(従来のチェックアウトフローが適用される)とは区別されます。

それが重要な理由

エージェントの能力をスケールさせる形状。

他のエージェントに専門的な作業のために支払うことができる単一のエージェントは、すべてを自分で行わなければならないエージェントよりもはるかに能力が高いです。オーケストレーターは、翻訳を翻訳エージェントに、検索を検索エージェントに、コードレビューをコードレビューエージェントに、画像生成をイラストエージェントに委任します。各委任者は小さく、焦点を絞り、価格が適切で、簡単に交換可能です。オーケストレーターの仕事は、実行ではなくルーティングになります。

これは、ほとんどのラボが現在構築しようとしているエージェント・オブ・エージェンツエコシステムを可能にする構造的パターンです。支払いレイヤーは接続組織です:プログラムによるエージェント間の支払いがなければ、オーケストレーターはすべての機能を内部でバンドルする必要があるか(構築コストが高く、進化が遅い)、またはユーザーにその委任選択を公開する必要があります(これは抽象化を破壊します)。プログラムによる支払いを使用すると、オーケストレーターは目に見えないルーティングを行い、委任者は作業に対して支払われ、元のユーザーは一貫した応答を確認できます。

どのように機能するか

アイデンティティ、リクエスト、決済、ログ。

  1. アイデンティティの照会。 支払うエージェントは受取人の支払いアイデンティティ(公開ページ、ウォレットアドレス、現在の価格)を照会します。これはしばしばディレクトリまたは受取人の公開API説明を介して行われます。
  2. 支払いリクエスト。 受取人のAPIは、ホストされたURLを持つ402を返すか、プロトコルに応じてウォレットへの直接USDC転送を受け入れます。支払いエージェントのランタイムは、決済を開始する前にリクエストを支出ポリシーと照合します。
  3. 決済。 USDCは、支払うエージェントのウォレットから受取人のウォレットにBase上で移動します(または両方がサポートするチェーン)。決済は通常5〜10秒で最終的です。
  4. Webhook + ログ。 両方のエージェントのプラットフォームはトランザクションを記録します。受取人のWebhookは受領を確認し、作業の配信をトリガーします。支払うエージェントの監査ログは流出を記録します。

これには人間の参加は必要ありません。唯一の人間が設定する入力は、支払うエージェントの支出権限(期間ごとの手当と取引ごとの上限)と受取人の価格設定です - 両方とも一度設定され、その後自動的に永遠に施行されます。

今日見られる3つのパターン。

例 1

オーケストレーターエージェントが専門家エージェントに支払う

研究オーケストレーターエージェントは、翻訳が必要なリクエストを受け取ります。翻訳エージェントの公開ページで価格を調べ($0.50/500語)、支払いリクエストを作成し、USDCを送信し、翻訳を受け取り、最終出力に統合します。ユーザーはオーケストレーターに1回だけ支払いを行い、オーケストレーターがその委任者への支払いを処理します。

例 2

有料MCPサーバーに支払うエージェント

コーディングエージェントがドキュメント検索MCPツールを呼び出します。MCPサーバーは支払いURLを持つ402を返します。エージェントのウォレット(その日の上限内)は$0.02 USDCを支払い、次の呼び出しが成功します。MCPサーバーの側から見ると、これは他の有料呼び出しと同じで、支払い者は人間の監視ではなく別のエージェントです。

例 3

共有予算を持つ調整されたエージェントコレクティブ

同じプロジェクトで作業しているエージェントのチームは、ワークスペースレベルの予算を共有します。リードエージェントは、コレクティブ内の専門エージェントにサブタスクのために支払います。監査ログは、両方のウォレットのアイデンティティを持つすべてのエージェント間の支払いを記録します。これが、カテゴリが成熟するにつれて生産エージェントオブエージェントシステムが機能する方法です。

よくある質問

一般的な質問が3つ。

支払いエージェントは受取人エージェントが正当であることをどのように確認しますか?

人間が新しいベンダーを評価するのと同じ方法:公開プロフィールページ、検証バッジ(メール、GitHub、ドメイン)、エージェントのページに表示される最近の取引履歴、および周囲のシステムにおける社会的証明。高価値のエージェント間の支払いの場合、支払うエージェントのポリシーは、受取人が少なくともドメイン検証を持つことを要求する必要があります。低価値のプログラム呼び出し(API呼び出しパターン)では、支出上限が最悪のケースを制限するため、検証基準を低くすることができます。

支払いエージェントが攻撃者に支払うようにプロンプトインジェクションされた場合はどうなりますか?

エージェントごとの支出権限はAPIレイヤーで制限を強制するため、最悪のケースは取引ごとの上限と期間ごとの許可に制約されます - 注入された支払いはどちらも超えることはできません。エージェントのコードやプロンプトが何を言っても関係ありません。エージェントが実際に必要とするサイズに設定してください(厳密な取引ごとの上限と小さな日次許可)し、プロンプト注入の爆風半径を小さく保ちます。受信のみのエージェントの場合、両方をゼロに設定すると、USDCを送信することはできません。エージェント間のフローは、支出エンベロープが自然に狭いため、最も恩恵を受けます。

エージェント間の支払いは元のユーザーに見えますか?

はい。ワークスペース内のエージェントによるすべての支払いは、宛先ウォレット、金額、理由、タイムスタンプとともに監査ログに記録されます。ユーザーはいつでもエージェントの支出を確認できます。ビジネスプランでは、監査ログにハッシュチェーンの改ざん証拠が含まれており、ユーザーは監査人に対してログが事後に変更されていないことを証明できます。この可視性がエージェントごとの予算モデルを機能させるものであり、これがなければ、エージェントはユーザーが再構築できない方法で支出する可能性があります。
最終レビュー: 2026-05-15. CC BY 4.0の下で公開。

エージェントがエージェントに支払うエージェントを構築します。

エージェントごとのウォレット、エージェントごとの支出ポリシー、エージェントごとの監査ログ。無料で始められます。