はじめに
私は、これからAI Agentが人間の代わりに経済活動を行う時代が来ると考えています。
これまでのインターネットでは、人間がWebサイトを開き、商品を探し、比較し、購入ボタンを押していました。
しかし、これからはどうでしょうか。
例えば、AI Agentにこう依頼するだけで済むかもしれません。
来月、家族3人で沖縄に旅行したい。予算は20万円以内。ホテルと航空券を予約しておいて。
AI Agentがホテルを探し、航空券を比較し、条件に合うプランを選び、購入まで進める。
人間が個々のWebサイトを操作する必要はありません。
そして、このような世界を実現するうえで、私が特に注目しているのが A2A（Agent2Agent）とAP2（Agent Payments Protocol） です。
この2つは競合する技術ではありません。
むしろ、お互いを補完する関係にあります。
A2AとAP2は何が違うのか？
簡単に整理すると、次のようになります。
| プロトコル | 役割 |
|---|---|
| A2A | AI Agent同士が通信・連携する |
| AP2 | AI Agentによる購入・支払いの権限を証明・検証する |
例えば、
- A2A： ホテルを探してほしい、航空券の料金を教えてほしい
- AP2： このAgentは本当にユーザーから購入を許可されているのか？
という違いです。
A2Aだけでも、Agent同士が協力して旅行プランを作れます。
しかし、実際にお金が動く場面では、単にAgentが「ユーザーに許可されています」と言うだけでは不十分です。
そこでAP2が必要になります。
AP2は、ユーザーの承認や委任された権限を、暗号学的に検証可能な形で扱うための仕組みを提供します。
具体例：AI Agentが沖縄旅行を予約する
次のようなケースを考えてみましょう。
ユーザーの依頼
家族3人で沖縄旅行に行きたい。予算20万円以内で、ホテルと航空券を予約して。
ここでは、次のAgentが登場します。
- パーソナルAgent：ユーザーの依頼を受ける
- ホテルAgent：宿泊施設を検索する
- 航空券Agent：航空券を検索する
さらに、購入時には販売者、ユーザーの承認を取得する仕組み、決済サービスなどが関わります。
全体のイメージ
※この図は理解を助けるための概念図です。金額や処理順序は例示であり、実際のAP2では購入・決済の種類に応じたMandateや検証が必要になります。
STEP 1：A2AでAgent同士が協力する
パーソナルAgentは、A2Aを使って他のAgentに仕事を依頼します。
ホテルAgentへ：
沖縄で家族3人が宿泊できるホテルを探してください。
航空券Agentへ：
家族3人分の往復航空券を探してください。
それぞれのAgentが結果を返します。
例えば、
- ホテル：96,000円
- 航空券：98,000円
- 合計：194,000円
予算の20万円以内です。
パーソナルAgentは、条件に合う旅行プランを組み立てます。
ここまでは、主にA2Aが活躍する領域です。
STEP 2：AP2で購入権限を確認する
では、Agentがホテルと航空券を見つけたら、そのまま購入してよいのでしょうか？
答えは、必ずしもそうではありません。
例えば、次のような問題があります。
- ユーザーは本当に購入を許可したのか？
- 予算20万円以内という条件を守っているのか？
- 許可された商品・サービスを購入しているのか？
- Agentが勝手に購入内容を変更していないか？
AP2は、このような問題に対応するためのプロトコルです。
AP2では、Mandate（委任・承認を証明するデータ） が重要な役割を持ちます。
代表的なものには、次の2つがあります。
Checkout Mandate
- 何を購入することが承認されているのか
- 購入内容と承認の結び付きを検証する
Payment Mandate
- どの支払いが承認されているのか
- 決済手段や金額など、支払いに関する権限を扱う
例えば、ホテルの販売者はCheckout Mandateを検証し、Agentによる購入が適切に承認されているか確認します。
航空券の販売者も、自身が受け付ける取引について必要な検証を行います。
なお、ホテルと航空券が別々の販売者であれば、それぞれのCheckoutに対応した承認・検証が必要です。単一のMandateを無条件にすべての販売者へ使い回せるわけではありません。
また、AP2自体が送金するわけではありません。
実際の決済は決済事業者などが行います。
STEP 3：購入結果をReceiptで確認する
購入処理の結果はReceiptとして記録・確認できます。
これにより、購入や支払いに関する証跡を残せます。
もちろん、Receiptが存在するだけで、予約の履行やサービス提供まで保証されるわけではありません。
それでも、Agentが自律的に取引する世界では、こうした検証可能な記録が非常に重要になると考えています。
実はAP2はA2Aの拡張として利用できる
ここが面白いところです。
AP2は、A2Aと組み合わせて利用できるよう設計されています。
Googleが公開しているAP2公式リポジトリにも、A2Aを使った決済シナリオのサンプルが存在します。
つまり、A2AとAP2の組み合わせは、単なる私のアイデアではありません。
すでに公式プロジェクトでも想定されている利用形態です。
参考：
なお、AP2はA2A専用ではなく、他のCommerce Protocolやシステムとも組み合わせられるよう設計されています。
私が考えるAI Agent経済の未来
ここからは、私個人の考えです。
現在のインターネット経済は、人間の操作を中心に設計されています。
- 人間が検索する
- 人間が比較する
- 人間が購入する
- 人間が契約する
しかし、AI Agentが普及すれば、この構造は大きく変化する可能性があります。
将来的には、
- 個人Agentが購入Agentに買い物を依頼する
- 購入Agentが販売者Agentと交渉する
- 企業Agentが別の企業Agentにサービスを発注する
- Agentが許可された予算内で継続的に支払いを行う
といった活動が増えていくでしょう。
私は、将来、AI Agentによる経済活動の件数が、人間による直接的な操作を上回る可能性も十分にあると考えています。
もちろん、それがいつ実現するかは分かりません。
しかし、その世界では2つの能力が必要になります。
1. Agent同士が自由に協力できること
これを支える技術の一つがA2Aです。
2. Agentの経済活動を安全に検証できること
これを支える技術の一つがAP2です。
Agentが賢くなるだけでは、安心してお金を任せることはできません。
Agentの能力だけでなく、Agentに与えた権限を検証できる仕組みが必要だと考えています。
Rubyでも、この未来に参加したい
私は現在、この2つの領域でRuby向けOSSを開発しています。
1. a2a-rails
GitHub：
RailsアプリケーションをA2A対応Agentとして公開したり、外部Agentと通信したりするためのGemです。
RailsでAgent同士の連携を実装することを目指しています。
2. ap2-mandate-verifier
GitHub：
Ruby向けのAP2 SDKです。
Checkout Mandateの検証を出発点として、Mandateの作成・検証、Payment関連の処理、Receiptの作成・検証などへ対応範囲を広げています。
Rails専用ではなく、Rubyアプリケーション全般から利用できることを目指しています。
両者を組み合わせれば、将来的には次のような構成をRubyで実現できます。
Rails Shopping Agent
|
| A2A
v
Rails Merchant Agent
|
| AP2
v
Mandateの検証
|
v
購入処理・Receipt確認
現時点で両Gemを直接統合した完成済みの商用フローを提供している、という意味ではありません。
しかし、これらを組み合わせたRuby製Agent Commerceのデモは、ぜひ実現したいテーマの一つです。
おわりに
AI Agentは、単なるチャットツールから、実際に仕事を進める存在へと変わりつつあります。
そして、仕事の先には必ず経済活動があります。
商品を購入する。
サービスを契約する。
他のAgentに仕事を依頼する。
そのような世界では、Agent同士の通信と、購入・支払いの権限を検証する仕組みが重要になるはずです。
A2AがAgent同士をつなぎ、AP2がAgentによる経済活動の信頼を支える。
私は、この組み合わせに大きな可能性を感じています。
まだ発展途上の領域ですが、今のうちからRubyのOSSを育てていきたいと思っています。
いつかAI Agentによる経済活動が当たり前になったとき、私の作ったGemが少しでもRuby開発者の役に立てば、うれしいです。
関連OSS
参考資料