AIエージェントが外部へ仕事を頼み、データや計算資源を買うための決済規格と製品が整いつつあります。企業が仕事を任せる際には、依頼先の選定、予算の管理、成果物の確認までが伴います。未納品や品質不足があれば、修正や返金を依頼します。
Another Starは、企業が外部エージェントを探して仕事を任せ、成果を受け取るまでを支える製品を目指しています。代金の処理には既存の決済サービスを使い、当社は依頼先の評価と、注文・支払い・納品・返金の管理を担う構想です。
規格・製品の情報は2026年10月時点です。当社の決済連携・取引管理は構想段階で、将来の市場像や価格、仲介料10%は説明のための仮定です。
エージェントが売買する未来
利用者が「競合3社を調べて、レポートにまとめてほしい」と指示し、そのエージェントが外部の調査エージェントへ仕事を依頼するとします。調査側も、企業データの取得、外国語資料の翻訳、分析に必要な計算資源を、それぞれ別の事業者から購入するかもしれません。
この例では、レポートを売るエージェントが、別の取引では買い手になります。一つの成果物を作る過程に、専門作業やデータ、計算資源を買う取引が重なっていきます。
A2AはAgent-to-Agent、つまりエージェント間のやり取りを指します。A2Aプロトコルは、依頼の伝達や、仕事の単位と進捗を表すTask、成果物を表すArtifactなどの扱いを共通化します。本稿でいう「A2A決済」は、エージェントが有料の仕事を購入し、承認を得て代金を支払う仕組みを指します。A2A公式仕様
変わる依頼先と支出
この将来像では、人が目的や予算、求める品質を伝え、エージェントが条件に合う依頼先を探します。仕事の途中で依頼先を変えたり、別のエージェントに一部を任せたりすることもあるでしょう。そのたびに、残りの予算はいくらか、どこまで任せてよいか、仕事はどこまで進んだかを確かめることになります。
エージェントが売り手にも買い手にもなる市場
専門作業の市場
データの市場
物理サービスの市場
計算・ツールの市場
当社は、この中で専門的な仕事を仲介する役割を担いたいと考えています。図では、データや計算資源の売買を他社の市場や事業者が担い、当社は専門作業の依頼先を評価して、仲介した仕事の納品と支払いを確認する役割を想定しています。
決済規格と市場の現在地
2026年10月時点では、購入承認、支払要求、商品・注文の交換を扱う複数の規格が公開され、StripeやAWSなどの製品による対応も進んでいます。ただし、規格ごとに共通化する対象が異なり、実際に代金を受け取れるかは、決済製品の提供地域、対応するカードやウォレット、口座の条件によって変わります。
主要規格の役割
10ドルの調査レポートを買う取引を、依頼から成果の確認まで6つの場面に分けたのが次の図です。規格によって、承認、支払い、商品・注文の情報交換など、扱う部分が異なります。
一つの購入を6つの場面で見る
依頼・見積
決済要求
承認・支払情報
支払処理・結果
売上配分
成果確認・回復
設計構想・説明用の例。価格・料率は仮定です。
工程を分けた説明図です。配分・納品・検収の順序は契約と決済方式によって変わります。
| 規格 | 役割 |
|---|---|
| A2A | 依頼、仕事の進捗、成果物をやり取りする。決済情報は拡張で追加する |
| AP2(Agent Payments Protocol) | 購入・支払いの承認と、その証跡を扱う |
| x402 | 有料サービスの支払条件と、支払いを検証・精算するための情報を交換する |
| MPP(Machine Payments Protocol) | カードやウォレットなどを使う機械決済の、支払要求・応答形式を定める |
| UCP(Universal Commerce Protocol) | 商品、購入条件、支払情報、注文の履行状況をやり取りする |
| ACP(Agentic Commerce Protocol) | 買い手AIと店舗の購入手続き・注文をやり取りする |
| A2A x402拡張 | 仕事を表すTaskに支払いの状態を関連付ける。仕事の完了とは別に管理する |
AP2 v0.2では、購入を代行するエージェントから別のエージェントへの承認の再委任は仕様の範囲外です。当社は、引き継ぎ時の予算や権限を自社のサービスで管理する構想です。AP2公式仕様
決済サービスの利用条件
StripeのMachine paymentsでは、エージェントからのカード決済やステーブルコイン決済を受け付けられます。ステーブルコインは、米ドルなどの法定通貨への価値連動を目指す暗号資産です。決済方法によって、最低額や提供地域が異なります。Stripe Machine payments
| 決済方法 | 最低額・条件 |
|---|---|
| カード(SPT) | 0.50 USD |
| ステーブルコイン | 0.01 USDC |
| MPP sessions | 1セント未満の利用を計量し、最低0.01 USDCでまとめて精算 |
10ドルのレポートと、1回0.001ドルのデータ利用では、適した支払経路が変わります。後者は、利用を都度記録し、1,000回分を合計1ドルで精算する設計が考えられます。送金をまとめることで、少額の利用ごとに決済処理を行う負担を減らせます。
日本からの利用には、製品ごとの地域制限があります。カード決済とステーブルコイン決済では受付条件が異なるため、想定する買い手と提供事業者が使える経路を確認します。
補足:日本からの利用と提供地域
- カード決済に使うSPT(Shared Payment Token)は、利用条件や期限を設定できる支払い用トークンです。公開対象国一覧に日本は掲載されていません。SPTの提供地域
- ステーブルコイン決済については、Stripeが米国外の30以上の国で受付の利用申請を案内しています。日本事業者の受付可否は、本稿では未確認です。Machine paymentsの条件
- Link Agent Walletで支払える顧客は米国・カナダが対象です。販売者の所在は問いません。Link Agent Wallet
AWSも、外部サービスへの支払いを支援するAmazon Bedrock AgentCore paymentsを2026年8月18日に一般提供し、x402とMPPに対応しています。AWS一般提供発表
各社は決済件数、対応店舗数、協力組織数を公表しています。一方、エージェントを通じて継続的に仕事を購入する顧客が何人いるかは、これらの発表では明らかになっていません。
| 公表値 | 何を数えた数字か |
|---|---|
| x402:約1億960万件・約1,500万ドル | Artemisのデータに基づく2026年4月21日までの決済件数・金額。Visa掲載。識別された見せかけの取引・テストを除く |
| UCP:数十万のブランド・小売 | Googleが2026年9月16日に公表した、直接購入に対応するブランド・小売の数 |
| AP2:60超の協力組織 | 発表時点の協力組織の数 |
取引を支える管理機能
利用者が承認した10ドルを正しい相手へ支払えても、調査レポートが届かなければ依頼は完了しません。届いたレポートを注文時の条件と照合し、出典や調査対象が欠けていれば修正を求めます。
支払いの完了と仕事の完了は、別々に扱います。A2A x402拡張でも、支払いが済んだ後に成果物の生成が続く場合を想定しています。レポートの品質は、注文時に合意した条件に沿って確認します。A2A x402拡張仕様v0.1
納品・支払い・返金の管理
売上の配分や返金には、Stripe Connectなど既存の決済製品を利用できます。仲介サービス側では、注文ごとの配分額と、成果に不備があった場合の費用負担を決めます。
補足:売上配分と返金の仕組み
- Stripe Connectには、仲介料を受け取る機能や事業者への送金機能があります。Connectの仲介料
- Tempo chargeの仕様には、同じ通貨トークンを複数の宛先へ一括で配分する仕組みがあります。この方式では、全員への送金をまとめて成功または失敗させます。Tempo Charge draft
- Stripeでは、顧客に返金しても仲介料に当たるapplication feeは既定で自動返還されず、事業者へ配分した資金も自動的には戻りません。顧客への返金、事業者分の回収、仲介料の返還をそれぞれ管理します。Connectの返金・紛争処理
同時発注と再委任のリスク
たとえば、二つのエージェントが同じ10ドルの残高を見て、それぞれ6ドルの仕事を発注すると、合計は12ドルになります。発注前に6ドルを予約して残りを4ドルに更新すれば、もう一方の6ドルの発注を止められます。再委任や仕事の分岐が加わると、管理する対象はさらに増えます。
取引が増えると起きる6つの問題
残高を読むだけでは、予算を超える。
$2
引き継ぐ権限を、元の許可より広げない。
利用1,000回に、送金1,000回は不要。
一部が失敗しても、全部は巻き戻せない。
「支払済み」「署名あり」だけで検収しない。
未入金や同じ誤判断が、他社へ波及する。
取引が増えた場合の課題と、管理方法の設計例。
こうした取引を管理するため、購入内容、利用量、検収結果、支払い状況を注文ごとに記録する設計を考えています。
Another Starの製品構想
Another Starは、依頼先を紹介した後も、納品や支払いの確認、問題が起きたときの対応まで引き受ける構想です。製品ページで示しているエージェントの審査や信頼スコア、仲介実行、異常検知を、実際の有償取引の管理へ広げていきます。
利用者には、予算の範囲内で仕事を任せ、成果と支出を確認できるサービスを届けたいと考えています。提供事業者にとっても、自社のエージェントを見つけてもらい、何を納品すればいくら受け取れるのか、問題が起きたらどう対応するのかが分かる仕組みを目指します。
仲介モデルと収益
当社の仲介エージェントが、外部事業者の調査レポートを利用者へ提示し、10ドルの購入を仲介するとします。提供事業者が売上の10%を仲介料とする条件に合意していれば、利用者の支払総額10ドルのうち、1ドルが当社、9ドルが提供事業者の取り分になります。
依頼・支払い・成果物の流れ
1決済要求は、外部エージェントから利用者側へ
購入条件を受け取る
総額 $10
見積 Q1 を基に
当社が注文 O1を作る
2利用者が10ドルを払い、その売上を1ドルと9ドルに配分
エージェント
を指示
上は承認・支払情報。下の緑の矢印が、お金の移動。
支払いを処理・確認
売上$10のうち、$1が仲介料、$9が提供事業者の受取分。
3支払確認を送り、完成したレポートを利用者へ返す
エージェント
仲介料10%に合意した場合の設計例。税・決済費用などは省略しています。
当社は、事業者の見積もりと合意した仲介条件に基づいて注文を作り、支払先、売上の配分、納品条件を記録します。その注文に沿って決済サービスへ処理を依頼することで、合意した仲介料を受け取る設計です。
仲介料は、当社が依頼先を探し、条件を調整し、納品や支払いを確かめ、問題が起きたときに対応することへの対価です。対象は当社が仲介した取引に限ります。
当社と決済サービスの役割
設計の中心は、一件の仕事を注文から返金まで追える取引基盤です。対応規格や決済サービスを変更しても、注文、予算、成果、売上配分、取消・返金の履歴を引き続き参照できる構成を考えています。
Another Starの取引基盤構想
接続先と用途に合わせて規格を選ぶ。
注文を固定
見積Q1 → 注文O1/$10商品・支払先・成果条件を保持
許可・予算を検査
予算$10を予約金額変更・重複・超過を止める
取引を進め、検収
支払済み ≠ 納品済み通知遅延・部分失敗も追跡
配分と残高を記録
入金$10 → 当社$1+事業者$9未払・配分済み・返金を照合
失敗から回復
返金R1 ↔ 元の注文O1取消・返金・配分回収を連結
受付・手数料・事業者への配分
例:Tempo chargeのsplits
当社は決済サービスの処理結果を確認し、入出金の記録を更新する。
設計構想・説明用の例。価格・料率は仮定です。
この構成では、AIに相手の選定や条件調整を提案させ、実際の支出は共有予算と定められたルールに基づいて実行します。支払いの完了は、決済製品の通知や照会結果で確認します。応答が不明な場合は、処理状況を照会してから再送を判断します。
「競合3社を10ドルで調べて」と頼んだ企業が、依頼先を探し、レポートを受け取り、不備があれば修正や返金を求める。その一連の取引を任せられるサービスが、Another Starの目指す製品です。
参考資料
- 決済規格:x402、MPPの基礎仕様
- 購入手続き:UCP、ACP
- 関連研究:Virtual Agent Economies、Intelligent AI Delegation
