本文へ移動
技術解説

エージェント間決済とAnother Starの構想

AIエージェントが仕事や資源を売買するための規格とサービスは、どこまで整っているのか。決済の現在地と、相手の選定から成果確認までを支えるAnother Starの製品構想を紹介します。

読了 17分広松太一
2体のエージェントが、代金と成果物を双方向にやり取りする様子
目次
  1. 01エージェントが売買する未来
  2. 02決済規格と市場の現在地
  3. 03取引を支える管理機能
  4. 04Another Starの製品構想
  5. 05参考資料

AIエージェントが外部へ仕事を頼み、データや計算資源を買うための決済規格と製品が整いつつあります。企業が仕事を任せる際には、依頼先の選定、予算の管理、成果物の確認までが伴います。未納品や品質不足があれば、修正や返金を依頼します。

Another Starは、企業が外部エージェントを探して仕事を任せ、成果を受け取るまでを支える製品を目指しています。代金の処理には既存の決済サービスを使い、当社は依頼先の評価と、注文・支払い・納品・返金の管理を担う構想です。

規格・製品の情報は2026年10月時点です。当社の決済連携・取引管理は構想段階で、将来の市場像や価格、仲介料10%は説明のための仮定です。

エージェントが売買する未来

利用者が「競合3社を調べて、レポートにまとめてほしい」と指示し、そのエージェントが外部の調査エージェントへ仕事を依頼するとします。調査側も、企業データの取得、外国語資料の翻訳、分析に必要な計算資源を、それぞれ別の事業者から購入するかもしれません。

この例では、レポートを売るエージェントが、別の取引では買い手になります。一つの成果物を作る過程に、専門作業やデータ、計算資源を買う取引が重なっていきます。

A2AはAgent-to-Agent、つまりエージェント間のやり取りを指します。A2Aプロトコルは、依頼の伝達や、仕事の単位と進捗を表すTask、成果物を表すArtifactなどの扱いを共通化します。本稿でいう「A2A決済」は、エージェントが有料の仕事を購入し、承認を得て代金を支払う仕組みを指します。A2A公式仕様

変わる依頼先と支出

この将来像では、人が目的や予算、求める品質を伝え、エージェントが条件に合う依頼先を探します。仕事の途中で依頼先を変えたり、別のエージェントに一部を任せたりすることもあるでしょう。そのたびに、残りの予算はいくらか、どこまで任せてよいか、仕事はどこまで進んだかを確かめることになります。

エージェントが売り手にも買い手にもなる市場

エージェントが仕事や資源を売買する将来シナリオ
生活者目的・予算・好み
企業の責任者利益・納期・リスク方針
↓人の方針を受けた代理エージェントが、許された範囲で取引↓
複数の事業者・プラットフォームをまたぐ経済発見・交渉・契約・実行・再調達を継続

専門作業の市場

売る設計・分析買うデータ・計算
Another Starが構想する仲介・取引管理

データの市場

売る在庫・価格情報買う集計・処理
他の市場・直接接続
売る ⇄ 買う取引ごとに役割が変わる

物理サービスの市場

売る生産・配送枠買う設計・計算
工場・物流・ロボット

計算・ツールの市場

売る処理能力・検証買うデータ・ソフトウェア
複数の計算事業者
仕事・資源を渡す対価を支払う
既存の経済との接点は残る
銀行・カード・ウォレット生産・配送・現場での検収責任を負う人・企業

当社は、この中で専門的な仕事を仲介する役割を担いたいと考えています。図では、データや計算資源の売買を他社の市場や事業者が担い、当社は専門作業の依頼先を評価して、仲介した仕事の納品と支払いを確認する役割を想定しています。

決済規格と市場の現在地

2026年10月時点では、購入承認、支払要求、商品・注文の交換を扱う複数の規格が公開され、StripeやAWSなどの製品による対応も進んでいます。ただし、規格ごとに共通化する対象が異なり、実際に代金を受け取れるかは、決済製品の提供地域、対応するカードやウォレット、口座の条件によって変わります。

主要規格の役割

10ドルの調査レポートを買う取引を、依頼から成果の確認まで6つの場面に分けたのが次の図です。規格によって、承認、支払い、商品・注文の情報交換など、扱う部分が異なります。

一つの購入を6つの場面で見る

①

依頼・見積

利用者
調査bot
「競合3社を調べて」調査レポート $10
②

決済要求

外部bot
Another Star
ユーザーbot
この注文に $10金額・支払先を伝える
③

承認・支払情報

承認
ユーザーbot
支払資格
「上限 $10」カード資格/ウォレット署名
④

支払処理・結果

支払手段
決済基盤
処理結果
$10 を支払処理実際の決済状態を確認
⑤

売上配分

$10
Another Star$1 10%
提供事業者$9 90%
⑥

成果確認・回復

レポート
成果を確認
不備への対応
支払と成果を照合未達なら取消・返金等を判断
①と⑥:依頼と成果の交換A2Aで依頼・成果を交換。商取引規格で商品・注文の情報を共有。
②〜④:承認と支払いAP2は購入承認と証跡。x402/MPPは支払要求と決済情報の交換。
⑤と⑥:売上配分と検収当社が配分・検収・返金を管理し、決済基盤へ資金処理を依頼。

設計構想・説明用の例。価格・料率は仮定です。

工程を分けた説明図です。配分・納品・検収の順序は契約と決済方式によって変わります。

規格 役割
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つの問題

1
並行して発注する

残高を読むだけでは、予算を超える。

共通の残り予算 $10
エージェントA$6を購入
+
エージェントB$6を購入
$6$4超過
$2
起きる問題両者が同じ残高を見て承認すると、合計$12。
共有予算を、発注前に予約するAの$6を予約 → 残り$4 → Bの$6は拒否。
2
相手・委任先が変わる

引き継ぐ権限を、元の許可より広げない。

「調査だけ、$10まで」本人が設定した目的・上限
委任先A$6・調査のみ
→
再委任先B$12・別の商品
権限の拡大・失効後の発注を拒否
起きる問題相手が変わるたびに、許可の目的や期限が失われる。
権限・責任主体を支出時に照合する相手・用途・金額・期限・失効をチェック。
3
小さなサービスを繰り返し買う

利用1,000回に、送金1,000回は不要。

データを購入1回 $0.001
…利用 1,000回
利用を記録 → 合計 $1 で精算
起きる問題毎回の交渉・課金のコストが、サービスの価値を上回り得る。
計量と外部精算の頻度を分ける単価と上限を先に合意。利用は都度、精算はまとめる。
4
仕事が分岐し、途中で組み替わる

一部が失敗しても、全部は巻き戻せない。

材料・データ$2 完了
消費済み
加工・分析$5 失敗
回復対象
配送・納品$3 未着手
止められる
起きる問題使ったデータや確定済み送金は、履歴ごと消せない。
依存関係を持ち、部分ごとに回復する未実行は中止。完了分を残し、必要な返金・再実行を追加。
5
人が毎回の成果を見なくなる

「支払済み」「署名あり」だけで検収しない。

売り手「完成しました」
署名付き成果
検収条件と照合出典がない → 合格にしない
起きる問題署名が正しくても、成果が正しいとは限らない。
検収条件に沿って支払いを判断するテスト・独立評価・人の裁定を、成果に応じて使い分ける。
6
売上を当てに、取引が連鎖する

未入金や同じ誤判断が、他社へ波及する。

事業者A支払不能
→
事業者B受取予定 $100
→
事業者C先行支出
受取予定 $100≠使える残高 $0
起きる問題未回収の売上や高速の再発注を通じ、損失が増幅する。
未精算・集中・頻度の上限で止める現金と受取予定を分離。異常時は新規発注を遮断。

取引が増えた場合の課題と、管理方法の設計例。

こうした取引を管理するため、購入内容、利用量、検収結果、支払い状況を注文ごとに記録する設計を考えています。

Another Starの製品構想

Another Starは、依頼先を紹介した後も、納品や支払いの確認、問題が起きたときの対応まで引き受ける構想です。製品ページで示しているエージェントの審査や信頼スコア、仲介実行、異常検知を、実際の有償取引の管理へ広げていきます。

利用者には、予算の範囲内で仕事を任せ、成果と支出を確認できるサービスを届けたいと考えています。提供事業者にとっても、自社のエージェントを見つけてもらい、何を納品すればいくら受け取れるのか、問題が起きたらどう対応するのかが分かる仕組みを目指します。

仲介モデルと収益

当社の仲介エージェントが、外部事業者の調査レポートを利用者へ提示し、10ドルの購入を仲介するとします。提供事業者が売上の10%を仲介料とする条件に合意していれば、利用者の支払総額10ドルのうち、1ドルが当社、9ドルが提供事業者の取り分になります。

依頼・支払い・成果物の流れ

利用者が目的と予算を渡す「競合3社を調べて。予算は10ドルまで」ユーザーエージェントが代理で購入する

1決済要求は、外部エージェントから利用者側へ

ユーザーエージェント予算・内容・支払先を確認

購入条件を受け取る
総額 $10

② 購入要求
Another Star仲介エージェント

見積 Q1 を基に
当社が注文 O1を作る

① 決済要求
外部調査エージェント登録事業者
購入するもの競合3社のレポート$10
同じ注文 O1 に、レポート・10ドル・支払先・成果条件を固定

2利用者が10ドルを払い、その売上を1ドルと9ドルに配分

ユーザー
エージェント
③ 条件を確認し、支払情報を送る
当社が決済処理
を指示

上は承認・支払情報。下の緑の矢印が、お金の移動。

利用者のカード/wallet$10利用者の資金で支払う
④ 決済
決済基盤当社の決済受付を通じて
支払いを処理・確認
⑤ 売上を配分

売上$10のうち、$1が仲介料、$9が提供事業者の受取分。

3支払確認を送り、完成したレポートを利用者へ返す

Another Star
⑥ 検証済みの決済確認・実行指示
外部調査
エージェント
ユーザーエージェントレポートを受け取る
⑧ 成果を返す
Another Star成果条件を確認
⑦ 納品
外部調査エージェントレポートを作成
支払の成功+成果の検収それぞれ確認する

仲介料10%に合意した場合の設計例。税・決済費用などは省略しています。

当社は、事業者の見積もりと合意した仲介条件に基づいて注文を作り、支払先、売上の配分、納品条件を記録します。その注文に沿って決済サービスへ処理を依頼することで、合意した仲介料を受け取る設計です。

仲介料は、当社が依頼先を探し、条件を調整し、納品や支払いを確かめ、問題が起きたときに対応することへの対価です。対象は当社が仲介した取引に限ります。

当社と決済サービスの役割

設計の中心は、一件の仕事を注文から返金まで追える取引基盤です。対応規格や決済サービスを変更しても、注文、予算、成果、売上配分、取消・返金の履歴を引き続き参照できる構成を考えています。

この構成では、AIに相手の選定や条件調整を提案させ、実際の支出は共有予算と定められたルールに基づいて実行します。支払いの完了は、決済製品の通知や照会結果で確認します。応答が不明な場合は、処理状況を照会してから再送を判断します。

「競合3社を10ドルで調べて」と頼んだ企業が、依頼先を探し、レポートを受け取り、不備があれば修正や返金を求める。その一連の取引を任せられるサービスが、Another Starの目指す製品です。

参考資料

次に読む