AIエージェントがSaaSを契約する時代へ Vercel × Stripe Projectsから整理するエージェンティックコマース
こんにちは、豊島です。
2026年に入ってから、AIエージェントが商取引の主体になる未来を示すニュースが立て続けに出ています。
一見バラバラに見える動きを並べてみると、ひとつの潮流として読み解けそうだったので、所感を交えて整理してみました。
- VercelがStripe ProjectsからProプランの契約・アップグレードに対応(2026年4月29日)
- Anthropicが「Project Deal」という社内マーケットプレイス実験の結果を公開(2026年4月24日)
- AnthropicとOpenAIが共同でMCP Appsを公式拡張として公開(2026年1月26日)
- Stripe Linkが「エージェント向けウォレット」として消費者側を担う動き
- アンソロピックのClaudeが拡大するほど儲かる企業──評価額1.5兆円「Vercel」とは何者か(Forbes Japan、2025年12月)
これらを並べると、エージェンティックコマースは次の4つの方向で同時並行に動いているのが見えてきます。
- 技術プロトコル側(SPT、ACP、MCPなど)
- 消費者側(Linkなど)
- 売り手側(Agentic Commerce Suite)
- マーケティング側(AEO)
本記事は技術解説というより、ここ数ヶ月の動向を整理した上での所感を中心にした考察記事です。
何が起きているのか
VercelがStripe Projects経由の契約に対応
2026年4月29日、Vercelは公式changelogで「Stripe Projects経由でVercel Proプランへのサインアップとアップグレードができるようになった」と発表しました。
stripe plugin install projects
stripe projects init my-app
stripe projects add vercel/pro
これだけ見ると「ダッシュボードに行かずに済む便利機能」ですが、ここで使われているShared Payment Tokens(SPT)は、Stripeが推進するAgentic Commerce(エージェンティックコマース)の中核技術です。
AIエージェントが人間の代わりに自律的にサービスを契約・課金できるよう設計された決済プロトコルで、クレジットカード番号をエージェントに渡す代わりに、用途・金額上限・有効期限などの制約を含んだトークンを渡すことで安全に代理購入を許可する仕組みです。
このリリースの本質は「CLIから契約できる」ではなく、「VercelがAIエージェント経由で契約される側のSaaSになる準備を整えた」という宣言です。
Anthropic Project Deal:エージェント同士が取引する実験
ほぼ同時期、AnthropicがProject Dealの実験結果(2026年4月24日)を公開しました。
2025年12月、サンフランシスコオフィスを1週間だけCraigslist風のマーケットプレイスに変え、69名の従業員にそれぞれ100ドルの予算と「自分専用のClaudeエージェント」を割り当てた実験です。
まずClaudeが各参加者に10分弱のインタビューをして、売りたい物、希望価格、買いたい物、交渉スタイルといった情報を聞き出します。その内容を個別のシステムプロンプトに落とし込み、エージェント同士をSlack上の市場に放って自由に交渉させました。
実験が始まったあとは人間が一切介入せず、最後の合意までエージェントの判断に任せています。
結果は以下の通りです。
- AIエージェント同士で186件の取引が成立
- 500点以上が出品され、総取引額は約4,000ドル
- 取引対象はスノーボードからピンポン玉まで多岐
- 人間が関与したのは、最後の物理的な受け渡しのみ
商品の出品(リスティング)から、相手の出品物の発見(ディスカバリー)、価格の交渉(ネゴシエーション)、合意して支払う(決済)まで、コマースを構成するこの一連の流れが、すべてエージェント間で完結したわけです。
さらに面白いのが、Anthropicが裏で仕込んでいた並行実験です。4つのマーケットプレイス(Run A〜D)を同時に走らせ、Run AとDでは全員がフロンティアモデルのClaude Opus 4.5、Run BとCではOpus 4.5と廉価モデルのHaiku 4.5がランダムに割り当てられる設計になっていました。
ここから2つの発見が出てきます。
- エージェントの「賢さ」がそのまま経済格差につながったこと
Opusに代理された売り手は同じ商品を平均$3.64高く売り、Opusに代理された買い手は平均$2.45安く買えました。同じ壊れた折りたたみ自転車が、Haiku経由では$38、Opus経由では$65で売れたケースもあります(70%の価格差) - Haikuモデルに代理された参加者が、自分が不利な取引をしていることに気づいていなかったこと
取引が公平だったかを1(不公平)から7(公平)の7段階で事後アンケートしたところ、Opus組の平均が4.05、Haiku組が4.06とほぼ同一でした。両モデルを経験した28名のうち、Opus側のRunを高く評価したのは17名、Haiku側を高く評価したのが11名で、主観的な満足度には統計的に有意な差は出ませんでした。
客観的には損をしているのに、主観的には満足している。この構造は後段の「論点1」で改めて取り上げます。
MCP Apps(Model Context Protocol Apps)の標準化
3つ目の動きは、AnthropicとOpenAIが共同でMCP Appsを公開した件です。(2026年1月26日に正式リリースされました)
MCP Appsは、ひとことで言うと「エージェントとの会話のなかにアプリ画面を埋め込むための共通仕様」です。
たとえば「来週の金曜にディナー予約して」とエージェントに頼んだとき、これまでなら外部サイトに飛ばされたり、テキストで店候補を返されたりしていました。MCP Appsに対応していれば、チャット画面のなかに予約フォームのUIがそのまま表示され、ユーザーはそこで時間や人数を選んで決定できます。エージェントとアプリの境界が消えて、会話のなかで取引が完結する形に近づきます。
機能や仕組みの詳しい解説は、MCP Appsの紹介記事に分かりやすくまとまっています。
この仕様に対応すると、Claude(web/desktop)、ChatGPTといった主要なエージェントランタイムのどれでも、同じUI定義が動くようになります。
アプリ提供者は「ChatGPT用」「Claude用」と作り分けなくてよくなり、ユーザーはどのエージェントから入っても同じ操作感で取引できます。
Launchパートナーには、OpenAI、Anthropic、MCP-UI、Block、Microsoft(VS Code)、JetBrains、AWS、Google DeepMindが並びます。
競合関係にあるはずのAnthropicとOpenAIが共同で標準化に動いた事実からは、「エージェント経由の商取引のためのインフラを業界全体で整備していく」という大きな流れが見えてきます。
SPT(Shared Payment Tokens)を理解する
SPTはエージェンティックコマース全体を支える基盤技術なので、独立したセクションで詳しく見ます。
なぜ既存の決済の仕組みでは足りないのか
従来のEコマース決済は「人間が決済の起点に存在する」前提で組まれていました。
カード番号を画面に入力するのも、3Dセキュアの本人確認に応えるのも、ボタンを押して決済を確定するのも、すべて人間です。エージェンティックコマースでは起点がAIエージェントに移るため、次のような問題が出てきます。
- カード情報をエージェントに渡すのは難しい。攻撃者がエージェントを乗っ取れば全資産にアクセスでき、プロンプトインジェクションで想定外の購買が走るリスクもある
- カード情報は粒度が粗い。「いくらまで」「どの売り手で」「いつまで」といった制約を直接設定できず、一度渡せば全権委任に近い状態になる
- 3Dセキュアなど既存の認証フローはエージェントが応答できない
これらを解決するために、Stripeが2025年9月29日にOpenAIと共同でAgentic Commerce Protocol(ACP)を発表し、その中核となる仕組みとしてSPTを導入しました。
SPTは「使い捨ての制限付き支払い権」
SPTを一言で表現すると、「特定の売り手で、特定の金額まで、特定の期間内に限って、買い手の支払い手段を使ってよいという、使い捨ての権限委譲トークン」です。
クレジットカード番号は、家の鍵を渡すようなものです。一度渡せば、相手はその家のすべての部屋に入れてしまいます。
SPTは「玄関だけ・1時間だけ・1回だけ開けられる、入退室記録も自動で残るカードキー」のようなもので、用途と範囲が最初から制限されています。万が一エージェントが乗っ取られても、被害はそのトークンに設定されたスコープ内に限定される、というのがエージェント時代の決済の基本発想です。
SPTのライフサイクル
シーケンス図にするとこんな感じになります。
買い手のカード情報はStripe側に保管されたPaymentMethodとしてのみ存在し、エージェントも売り手もそれを直接扱わずSPT越しに決済を回します。SPTが期限切れになったり取り消されたりすると、Stripeから両者にWebhookが飛んで状態が同期される仕組みです。
3Dセキュアなど追加の本人確認が必要な場合は、SPTが一旦 requires_action ステータスに移ります。エージェント側で買い手に認証フロー(stripe.handleNextAction())を案内し、完了すると active に戻り、改めて売り手側のPaymentIntentが処理される、という流れです。
SPTの主要パラメータ
Stripe公式ドキュメントによると、エージェント側がSPTを発行する際の主要パラメータは次のようになっています。
| パラメータ | 意味 |
|---|---|
payment_method |
顧客の支払い手段ID |
seller_details[network_business_profile] |
対象の売り手のプロフィールID |
usage_limits[currency] |
通貨 |
usage_limits[max_amount] |
上限金額 |
usage_limits[expires_at] |
有効期限(Unixタイムスタンプ) |
return_url |
リターンURL |
ここで効いてくるのがmax_amountとexpires_atです。エージェントは「100ドルのジャケット1枚分」という非常に狭いスコープでSPTを発行し、トークンは数分〜数時間で失効します。万が一漏洩しても被害は1取引分に限定される設計です。
Webhookによるライフサイクル可視化
主要なWebhookイベントを整理しておきます。
| イベント | 通知先 | 用途 |
|---|---|---|
shared_payment.granted_token.deactivated |
売り手 | SPTが失効・取消されたことを検知 |
shared_payment.issued_token.requires_action |
エージェント | 追加アクションが必要 |
shared_payment.issued_token.active |
エージェント | トークンが有効化された |
shared_payment.issued_token.used |
エージェント | 顧客への決済完了通知に使用 |
shared_payment.issued_token.deactivated |
エージェント | トークン失効をトラッキング |
エージェントと売り手の双方が「いま誰がどのトークンをどう使ったか」をリアルタイムに把握できる構造になっています。
SPTの上位プロトコル、ACP(Agentic Commerce Protocol)とMPP(Machine Payments Protocol)
SPTは単独機能ではなく、より大きなプロトコル階層の一部です。Agentic Commerce Protocol(ACP)は、エージェントと売り手の間で「カートの作成・確認・決済・配送」までを標準的なやり取りで完結させるAPI仕様で、SPTはその決済層を担います。一度ACPに対応すれば、売り手はChatGPT、Claude、その他任意のエージェントから注文を受けられるようになります。
さらに2026年3月、StripeはMachine Payments Protocol(MPP)を発表しました。MPPはStripeが「インターネット上の決済プロトコル」と位置付けているもので、クライアントが有料リソースをリクエストするとサーバーがHTTP 402レスポンスで決済詳細を返す仕組みになっています。後述のx402と同じくHTTP 402を起点にしますが、MPPはStripeが推進するエージェント間決済の枠組み、x402はオープンプロトコルとしてAIクローラー課金を含む幅広い用途、という立ち位置の違いがあります。
MPPの中で実際の決済を担う仕組みが、次に説明するSPT(法定通貨決済)です。
それぞれの位置付けを表にまとめると次のとおりです。
| プロトコル | レイヤー | 役割 |
|---|---|---|
| ACP | 商取引フロー層 | エージェント↔売り手間で「カート作成 → 内容確認 → 決済 → 配送」を進めるためのAPI規格 |
| MPP | 支払いプロトコル層 | HTTP 402を起点としたエージェント間支払いの上位プロトコル。SPTを中核に据えて運用される |
| SPT | 決済トークン層 | MPPのなかで法定通貨の決済を担う層。カード・後払い決済・ネットワークトークンを統一インターフェースで扱う |
図にするとこんな関係性になります。
※公式の階層定義そのものではなく、私のイメージで整理した図です。
ACPは商取引のフロー全体(注文・カート・配送)を扱う規格で、そのなかの決済ステップだけがSPTに委譲される、という関係です。MPPはより広い「支払いプロトコル」の上位概念で、SPTはMPPのなかで、カードや後払い決済など法定通貨側の決済を担当する仕組みとして位置付けられます。
実際の取引の流れに沿って言い換えると、各層が「どこで効いてくるか」が見えやすくなります。たとえば、買い手がエージェントに「このジャケットを100ドルで買って」と依頼したとします。
- カート作成・内容確認 → ACP層
エージェントが売り手のACPエンドポイントを叩いてカートを作成し、内容を確認します。ここはACPの中だけで完結します。 - 決済 → ACPからMPP/SPTへ委譲
ACPの「決済ステップ」に来たタイミングで、エージェントがStripeに対してSPTを発行します。MPPの中で実際の決済を担うのがSPTで、ここで法定通貨の支払いが処理される形です。 - 配送 → ACP層
売り手側がSPTで決済を確定したあと、配送状況をACP経由でエージェントに返します。ここでまたACP層に戻ります。
「カート → 確認 → 配送」はACP一本で扱い、「決済の瞬間」だけMPP/SPTを呼び出す、という役割分担です。
採用状況
SPTはすでにEtsy、URBN(Anthropologie、Free People、Urban Outfittersの親会社)が採用済みで、ChatGPTのInstant CheckoutもこのSPTで動いています。2025年12月11日に発表されたAgentic Commerce SuiteではCoach、Kate Spade、Revolve、Ashley Furnitureなどが導入を進めています。
決済手段の面でも2026年3月にSPTのサポート範囲が拡張され、Mastercard Agent Pay、Visa Intelligent Commerce、Affirm、Klarnaが統合されました。売り手はSPT 1つを実装すれば、ネットワークトークン経由のエージェント決済も後払い決済も自動的にカバーされる構造です。
Stripe Link:消費者側のウォレット
ここまでは売り手側の視点でしたが、エージェンティックコマースが成立するには消費者側にも対応する仕組みが必要です。それを担うのがStripe Linkです。
Linkが担う4つの機能
link.com/jp/agentsの説明によると、Linkは今後「自分のエージェントに、自分が管理するウォレットへのアクセス権を付与する」ためのインターフェースになります。提供される機能はだいたい4つです。
- リアルタイム承認通知
エージェントが何かを購入しようとするたびにユーザーのスマートフォンに「XXが17.99ドルの商品を購入しようとしています」といった通知が届き、ユーザーは承認・拒否を選べます。 - アイデンティティと購買履歴の保持
ChatGPT、Claude、PerplexityなどのAIサーフェスを横断してもLinkを経由することで「同じ消費者」として認識され、配送先や好みが引き継がれます。 - きめ細かなエージェント管理
エージェントごとに「いくらまで承認なしで使ってよい」「どのカテゴリは禁止」を設定できます。 - 取引の完全な可視化
Linkアプリで過去の購入を全て確認できます。
LinkとSPTの対称的な役割
| 視点 | SPT | Link |
|---|---|---|
| 誰のためのもの | 売り手側 | 消費者側 |
| 役割 | エージェントから受け取った決済権限を実行する | エージェントに与える決済権限を管理する |
| ユーザーが指定するもの | スコープ、上限、有効期限 | 承認ルール、購入履歴、エージェント別権限 |
SPTが「特定取引への権限委譲トークン」を表現する仕組みなら、Linkはその権限を「消費者が日常的に管理するUI」を提供します。両方が揃って初めて、エージェンティックコマースの取引フローが実用レベルで成立します。
skill.mdという新しいオンボーディング
Linkのサイトで特に興味深いのは、開始方法として示されている指示です。
代理人に以下のことを伝えます:
"Read link.com/skill.md and get me set up with Link"
これはAnthropicが提唱したAgent Skillsの応用例です。「このURLのskill.mdを読んでセットアップして」と人間がエージェントに伝えるだけで、連携が自動的に完了する仕組みになっています。
従来「サインアップ → 認証 → 連携設定」というオンボーディングは、人間がブラウザ画面を操作する前提で設計されていました。それを「エージェントが読んで実行できるMarkdownファイル」に置き換える発想の転換です。これは後述するAEO(Agent Engine Optimization)の先駆的な実装パターンと言えそうです。
Vercel × Stripe Projectsの意味を再読する
ここまでの理解を踏まえると、冒頭のVercel × Stripe Projectsは、Vercelが「売り手側」としてSPTを受け取る側に名乗りを上げた、ということが見えてきます。これまでSPTの主な用途はB2Cの物販でしたが、これがB2B SaaSの領域に拡張された最初期の事例がVercelです。
StripeとVercelの設計を見るかぎり、将来的にはコーディングエージェントが「このアプリ本番化するからVercel Pro契約しといて」という指示を受けたときに、SPTを発行してプラン契約を完了するような使い方が想定されているように見えます。同じ仕組みは技術的にはSupabase、Upstash、Auth0、その他の開発者向けSaaSにも展開しうるので、各社にも対応の可能性はありそうですね。
もうひとつの方向: AIクローラーに課金するx402
ここまでは「エージェントが人間の代わりにお金を払う」というシナリオを見てきました。実は反対方向の流れもあって、こちらも同時に立ち上がりつつあります。コンテンツ提供者側がAIクローラーから収益を上げる仕組みです。
x402: HTTP 402 Payment Requiredを使ったマイクロペイメント
x402はHTTPステータスコードの402(Payment Required)を活用したマイクロペイメントプロトコルです。AIクローラーがコンテンツをリクエストすると、サーバーは402を返し、暗号通貨での支払い情報を提示します。クローラーが支払うとコンテンツが返される、という流れです。
エージェント決済の世界はいくつかの階層に分かれていて、Komlock Labさんのエージェントが払う仕組みが6層モデルでわかりやすく整理しています。
x402はそのうちのプロトコル層を担い、その下のFacilitator層が暗号通貨の決済処理と参加者の検証を引き受けます。サイト運営者から見るとHTTPの知識だけで402を返せばよく、暗号通貨周りの細かいロジックはFacilitatorに丸投げできる構造になっています。
USDC on Solanaがメインネットで動き始めた
決済はUSDC(米ドル連動のステーブルコイン)で行われ、超マイクロペイメントに耐えるためにSolanaチェーンが採用されています。2026年4月時点で、Coinbase CDP FacilitatorがUSDC on Solana メインネットでの運用を開始したので、テストネット段階を抜けて実際にUSDCを受け取れるフェーズに入りました。
実装事例: ChatGPTから現金を受け取れているサイト
公開されている事例として、HonoとCloudflare Workersでx402を実装し、ChatGPTから実際に支払いを受け取っているサイト(ベルリン・Berghainクラブのレイバー向けデータベース)があります。実装の詳細はZennの記事にまとまっています。
私もVercelプロジェクトのEdge Functionで試してみましたが、ルーティング層で「AIクローラーかどうか」を判定して402を返すだけなので、Honoや他のフレームワークでもさっと組めます。
ポイント: 人間と検索クローラーには影響なし
課金対象を「AIクローラーだけ」に絞っているのが特徴です。
- 通常のブラウザからのアクセスはそのまま通す
- Googlebotなどの検索クローラーも通す
- ChatGPT-User、PerplexityBot、ClaudeBotなどのAIクローラーだけ402を返す
ユーザー体験はゼロインパクトで、SEOにも影響しません。サイト側のリスクが極めて少ない設計です。robots.txtとllms.txtも整えると、AIクローラー向けに「ここから先はお金を払って読んで」という明示的な動線ができあがります。
コンテンツ提供者にとっての意味
ここから先は完全な所感ですが、AIクロールに対するモヤモヤ感は多くの開発者・コンテンツ提供者が持っているように思います。「自分のコンテンツが学習に使われていることは分かるけど、何をいくら持っていかれているか可視化されない」というやつです。
x402はその不透明さに対するひとつの答えになりそうです。Berghain Raversのダッシュボードを見ると、どのAIクローラーがいくら支払って何回読んだかがリアルタイムで確認できる形になっています。
ニュースサイトや専門メディア、技術ブログのような「LLMの学習に価値があるテキスト」を持つサイトは、x402を組み込むだけで新しい収益源を確保できそうです。しかも実装は意外とシンプルで、Cloudflare WorkersでもVercel Edge Functionでも動きます。
4つの動きをひとつの絵として読む
| パラダイム | 担い手 | 関連する動き |
|---|---|---|
| インフラ調達のエージェント化 | Stripe + Vercel | Stripe Projects + SPT |
| C2C/B2C取引のエージェント化 | Anthropic | Project Deal |
| エージェント間の相互運用標準 | Anthropic + OpenAI | MCP Apps |
| コンテンツのAIクローラー課金 | Coinbase + Hono + x402 | x402 + USDC on Solana |
買い手側(エージェントが買う)、売り手側(SaaSが売る)、コンテンツ側(クローラーから取る)、そして相互運用標準。エージェンティックコマースの構図はこの4つの方向で同時並行に動いていて、人間からエージェントへの主体移譲が並行して進んでいます。個別のプロダクト施策の積み重ねというより、業界横断の動きとして眺めるほうが整理しやすそうです。
Project Dealから見えた論点
論点1: エージェントの質が新たな格差を生む
廉価モデルを使った人は、自分が不利だったことに気づかない。Project Dealで一番引っかかったのがこの発見です。Opus担当エージェントは同じ商品を平均$3.64高く売り、$2.45安く買えていたにもかかわらず、フェアネス評価は両者ほぼ同じでした。
開かれたマーケットプレイスにスケールさせると、フロンティアモデルを使える富裕層・大企業と、廉価モデルしか使えない一般消費者の間に、見えない情報格差が生じる可能性がありそうです。怖いのは、不利な側に「自分が不利である」という認識すら持てない点です。
論点2: 責任の所在が定義されていない
エージェント同士が取引した結果、何かが間違ったとき、誰が責任を負うのか。エージェントベンダー(Anthropic、OpenAIなど)、デプロイした個人や企業、エージェントそのもの、システムプロンプトを書いた人。私の観測範囲では、EU AI Actや日本の法制度のどちらにも、エージェント間の商取引そのものを直接扱う明示的な規定は見当たらないように思います。実際にケースが起きた際は、法律専門家の見解を確認する必要がありそうです。
論点3: ガバナンスと暴走時の課金リスク
「エージェントがプランを勝手にアップグレードできる」設計は便利な反面、誤操作や暴走時の課金リスクを伴います。エンタープライズ導入には、月次・案件別の支出上限、カテゴリ別ホワイトリスト、一定額以上での人間承認、監査ログ、異常検知と自動停止といった統制が不可欠そうです。これらは現在の経理・購買統制では想定されていない要件で、新しいガバナンスレイヤーが必要になります。
GTM(Go-To-Market)はどう変わるか
エージェント経由の購買が広がると、SaaSのGTM戦略にも影響が出てきそうです。これまで美しいランディングページ、説得力のあるセールス、カスタマーサクセスによるオンボーディングが顧客獲得の鍵でした。しかしエージェント経由ではこれらが効きにくくなります。エージェントは美しいLPを読まず、APIドキュメントを読むからです。
新しい時代に重要になりそうなポイントを並べてみます。
- エージェントが見つけやすいAPIドキュメント(機械可読性、構造化されたエラー)
- エージェント向けのプロビジョニングプロトコル(Stripe Projectsのような仕組み)
- エージェントが選好するデフォルト設定(プラン体系のシンプルさ、課金の予測可能性)
- 公式MCPサーバの提供
Vercelが「Stripe Projectsのローンチ&デザインパートナー」を名乗っているのは、この新しいGTMチャネルでファーストムーバーアドバンテージを取りに行っている動きでしょう。
AEO(Agent Engine Optimization)という新しい競争軸
Forbes Japanが2025年12月に掲載したアンソロピックのClaudeが拡大するほど儲かる企業──評価額1.5兆円「Vercel」とは何者かという記事は、AIエージェントの普及がVercelのようなインフラ提供者の評価額を押し上げる構造を解説していました。AIエージェントが選定の主体になる時代には、誰が「選ばれる」立ち位置にいるかが事業成長を大きく左右します。技術が整えば、その上に乗るマーケティングの世界も書き換わっていきそうです。
顧客が人間ではなくなるとき
人間の顧客は美しいビジュアル、ブランドストーリー、SNSの評判、限定感に反応します。AIエージェントはその代わりに、構造化された商品データ、客観的なレビュー集約、仕様の明示性、価格の予測可能性、機械可読な保証・返品ポリシーを評価します。
人間向けマーケティングが不要になるわけではなく、エージェントの背後には常に人間がいて、エージェントは人間の意図を反映します。ただし、エージェントというフィルターを通ることで、各要素の重み付けが大きく変わります。スペック優位な無名ブランドが、エージェント経由では選ばれやすくなる可能性も出てきそうです。
Agent Engine Optimization(AEO)
検索エンジン時代のSEOに対応する概念として、エージェント時代のAEOが立ち上がりつつあります。
| 観点 | SEO | AEO |
|---|---|---|
| 最適化対象 | キーワード、被リンク、コンテンツ量 | 構造化データ、APIスキーマ、機械可読仕様 |
| 評価指標 | 検索結果の順位 | エージェントの推論で「候補に挙がる」「比較で選ばれる」 |
| ゴール | 人間にクリックしてもらう | エージェントに購買決定してもらう |
| 観測性 | 順位がほぼ見える | 内部の判断はブラックボックス |
Project Dealでは「廉価モデルを使ったエージェントの代理人は不利に気づきにくい」という発見が得られました。ただし、社内マーケットプレイスという実験環境と、実際のコマースのマーケットプレイスでは条件が大きく異なるため、同じ構造がそのまま再現するかは検証が必要です。今後の検証が必要な論点として、「売り手側も、自社が廉価モデルを使うエージェントから不公平に評価されていることに気づきにくい」という見えない不利が議論されうるところです。
AEOの実装パターン
具体的には次のような「AIエージェント向けの仕様書」を整える方向になりそうです。
/robots.txt
AIクローラーごとのアクセス可否を明示します。学習用クロールを許可するか、x402で課金するか、完全にブロックするかを切り分け、GPTBot、ClaudeBot、PerplexityBotなどのUser-Agentを個別に制御します。/llms.txt
LLM向けに最適化されたサイト要約です。サイト構造や主要ページをLLMが理解しやすい形でまとめておきます。/agent-spec.md
自社サービスのエージェント連携仕様書です。エージェントが「このサービスは何ができるのか」を読み取るためのドキュメントになります。/skill.md
エージェントへのオンボーディング指示です。Stripe Linkの先行事例がそのまま参考になります。/.well-known/mcp.json
MCPサーバの自動検出用メタデータです。エージェントランタイムから自社のMCPサーバを見つけてもらうための入口として機能します。- 構造化されたOpenAPIスキーマ、Schema.orgメタデータ
APIや製品情報をエージェントが機械的に読み取れる形に整備しておくための土台です。
robots.txtは伝統的なファイルですが、AIクローラー時代に役割が広がっています。ブロックするだけでなく、x402のような課金前提のアクセスを許可するための入口としても使えるので、llms.txtや402ペイウォールと組み合わせて整えるのが現実的です。
これらは技術文書を書くだけの話ではなく、マーケティング部門と開発部門の境界を再定義する取り組みです。「自社製品をどう世界に伝えるか」というマーケティングの本質的な問いに、エンジニアリング的な実装が直接効いてきます。
ブランドの意味が再定義される
これまでブランドは、買い手が見聞きするうちに積み重なる、サービスへのイメージや信頼感のようなものを指していました。エージェント時代には、ブランドはここに別の軸が加わりそうです。人間向けブランド(従来通りの感情的・文化的なイメージ)と、エージェント向けブランド(返品率、サポート品質、APIの安定性、配送遅延の少なさといった検証可能な実績)の2軸です。
過去の取引履歴をどの程度保持し、推薦判断に反映させるかは、各エージェント開発企業の設計に依存していて、実装の詳細は公開されていません。ただし設計思想としてエージェントが履歴を活用しやすいことは確かで、理論的には、一度配送遅延があった売り手がエージェントの推薦リストから外れ続ける、といった挙動が生じる可能性はありそうです。人間の顧客が時間とともに忘れていくのに対して、機械的に履歴を扱う側の挙動はやや違うものになる、という想定です。
日本企業にとっての特殊な課題
私の観察した範囲では、PDFカタログ、お問い合わせフォーム、画像化されたテキストで情報を提供しているサイトは、エージェントから見えにくい構造になりがちです。「お電話にてお問い合わせください」と書かれたサイトは、エージェント時代には発見されにくい状態に置かれそうです。もちろんこれが日本企業全体に当てはまるわけではなく、すでに構造化データの整備を進めているところもあります。
加えて、主要AIエージェントは英語圏の情報をより多く学習しているため、日本語のみで情報発信している企業は構造的に不利です。「まず名刺交換」「最初は見積もりベース」「契約書は紙で印鑑」といった暗黙のプロトコルは、エージェントが処理できない手続きとなり、取引コストとして可視化されていきそうです。
個人的な所感と読者へのアクション
VercelのchangelogもProject Dealも単独では「ふーん面白いね」で終わるニュースかもしれません。
しかし並べて見てみると、「ソフトウェアが他のソフトウェアを購買する時代」への準備が、業界の主要プレイヤーによって並行的に進んでいることが見えてきます。
インフラ側(Stripe + Vercel)、消費者側(Anthropic Project Deal)、相互運用標準(MCP Apps)、コンテンツ側(x402)の4つが同時並行で動いています。
また、過去を振り返ると似た変化点がありました。Webブラウザ、スマートフォン、クラウド、生成AI。そして今、エージェントの登場で「商取引の主体」が変わろうとしています。過去の変化点では早くから対応した企業が大きなアドバンテージを得ました。
先述の論点2で触れたとおり、エージェント間の商取引そのものに特化した法制度や明示的な規定は、私の観測範囲ではまだ限られているように見えます。技術側が一足先に動いている一方で、社会の受容や制度整備が追いついていないように感じる場面が増えてきている印象です。Project Dealが示した「廉価モデルを使った人は自分の不利に気づかない」という発見も、そのギャップを示す一例として読み取れる気がします。
特にx402については個人的にミライを感じた動きです。原理自体は前から存在しており、「402 Payment Requiredを使ったマイクロペイメント」というイメージはあったものの、私自身は「まあ仮に実装したところで誰も払わないだろう」と思っていてスルーしていた領域です。
ただ先に紹介した事例では、実際にChatGPTがUSDCで支払ってきているという結果が出ています。理屈で「動くはず」と分かっていても、実際の支払い実績が並んでいる事例を見ると、印象が少し変わります。
「サイト運営者は自分のコンテンツが誰に消費されているかを知る権利があり、AI企業は学習データの取得方法に説明責任を負うべき」という主張も、個人的には頷けるところがありました。自分でサイトを運用している中でも、AIクローラーの挙動にモヤっとした場面が何度かあったので、こうした言語化には共感を覚えます。
買い手側(エージェント)と売り手側(SaaS)だけでなく、コンテンツ提供者側にも収益化の選択肢が用意されつつある、という意味で、エージェンティックコマースは思った以上に多面的な動きです。
GTMエンジニア・プロダクト責任者として今すぐ手を打てそうな項目を、6つ挙げてみます。
- 自社サイトに
/llms.txtを置く。サイトの要約、主要ページ、製品の核となる価値を機械可読な形でまとめておきます。1ファイル追加するだけで、LLMが自社サイトを理解する入口として機能するので、AEO対応の最初の一歩として始めやすいです。 - オンボーディング手順を
skill.md化する。「サインアップ → 認証 → 連携設定」を、エージェントが読んで自律的に完了できる形式に書き換えます。Stripe LinkのRead link.com/skill.md and get me set up with Linkが参考事例として分かりやすく、実物のskill.mdをそのまま読めます。 - APIドキュメントの構造化を進める。OpenAPIスキーマやSchema.orgメタデータを整備して、エージェントが機械的に仕様を読み取れる状態にしておきます。既存のドキュメントから自動生成できるツールも増えてきているので、思ったほどコストはかかりません。
- 公式MCPサーバの提供を検討する。ClaudeやChatGPTといったエージェントランタイムから、自社サービスを直接呼び出してもらうための仕組みです。SaaSとして「エージェントから操作される側」になる準備の中でも、効きやすい打ち手のひとつです。
- プライシングの予測可能性を見直す。「お問い合わせ」「カスタム見積もり」中心のプラン体系は、エージェント経由の比較では候補から外れやすくなります。ティアと従量課金の組み合わせなど、エージェントが比較しやすい構造に整える方向が考えられます。
- AIクローラー向けに x402 を試す。Hono や Vercel Edge Functionで、ルーティング層に402を返す処理を仕込みます。まずは検証用のサブドメインで仕掛けて、どのクローラーが何回叩いてくるかを観測するところから。収益化を本格化する前段として、可視化だけでも始める価値があります。
まとめ
- Vercel × Stripe Projects、Anthropic Project Deal、MCP Appsはバラバラに見えて、エージェンティックコマースに向けたインフラ整備としてひとつにつながる
- SPTは「使い捨ての制限付き支払い権」で、エージェント時代の決済プリミティブとしてACP/MPPの中核を担う
- Stripe Linkが消費者側で「エージェントに与える権限を管理するUI」を提供し、SPTと対称な役割を果たす
skill.mdというオンボーディング形式は、AEO(Agent Engine Optimization)の先駆的な実装パターン- x402はAIクローラーから対価を取る逆方向の動きで、Hono / Vercel Edge Functionで簡単に組める。robots.txt + llms.txt + 402という新しい3層構造のサイト設計が成立する
- Project Dealは「廉価モデルを使った人は不利に気づかない」という、エージェント時代特有のリスクを浮き彫りにした
- GTMの世界では、APIドキュメント、skill.md、llms.txt、構造化データといった「AIエージェント向けの仕様書」の整備が新しい競争軸になりそう
ここに挙げた動きはどれも単独では小さな進歩ですが、並べて見るとエージェンティックコマースという同じ方向を向いていることが見えてきます。
