AEO×AIエージェント トランザクション完了のためのコンバージョン設計ガイド【2026年版】——Action Schema・決済フロー・認証設計でAIエージェントに「買ってもらえる」サイトを作る

  1. はじめに——AIエージェントが「買い物」をする時代が来た
  2. 前提知識——AIエージェントのトランザクション処理はどこまで進んでいるのか
    1. エージェントプロトコルの全体像（2026年4月時点）
    2. なぜ「トランザクション完了」がサイト設計の課題になるのか
  3. 【設計ガイド①】MCP経由のAction Schema設計——予約・購入のツール定義
    1. Action Schemaとは何か
    2. ECサイト向けAction Schemaの設計例
    3. Action Schema設計のベストプラクティス
    4. UCP（Universal Commerce Protocol）との連携
  4. 【設計ガイド②】AIブラウジングエージェント向けの確認画面・決済フロー設計
    1. なぜDOM構造が重要なのか
    2. 確認画面のアクセシブルなDOM設計
    3. 決済フローの設計指針
  5. 【設計ガイド③】エージェント向け決済APIの認証設計——OAuth 2.1＋ユーザー委任トークン
    1. なぜAPIキーではダメなのか
    2. OAuth 2.1がAIエージェントに適している理由
    3. IETFドラフト：AIエージェント向けOAuth 2.0拡張
    4. 実装パターン：段階的な権限委任
    5. 支出管理（Spending Controls）の設計
  6. 【設計ガイド④】エージェント経由の注文に対するキャンセル・返金ポリシー設計
    1. なぜエージェント専用のポリシーが必要なのか
    2. 推奨されるポリシー設計
  7. 実装ロードマップ——中小企業がまず取り組むべき5つのステップ
  8. よくある質問（Q&A）
    1. Q1. MCPサーバーを公開しないと、AIエージェントからの購入はまったく受けられない？
    2. Q2. Stripe MPPに対応しないと、エージェント経由の決済は受けられない？
    3. Q3. AIエージェントに決済を委任するのは法的に問題ないのか？
    4. Q4. 小規模なECサイトでも対応すべき？
    5. Q5. GoogleのUCPとStripeのACPはどちらに対応すべき？
  9. まとめ——「見つけてもらう」から「買ってもらう」までをAIエージェントに対応する
  10. 参考リンク

はじめに——AIエージェントが「買い物」をする時代が来た

AIエージェントの進化は「検索して情報を表示する」段階をすでに超え、「比較・判断・購入まで一気に実行する」段階に突入しています。2026年現在、Stripe、Google、OpenAIといった主要プレイヤーが、AIエージェントによる自律的なトランザクション（予約・購入・決済）を実現するプロトコルやAPIを次々と発表しています。

この流れの中で、Webサイト運営者やEC事業者が直面する新たな課題があります。それは「AIエージェントにとって操作しやすいサイトになっているか？」という問いです。

当サイトではこれまで、AIエージェント時代のマーケティング戦略（AEO×エージェント検索のSEO戦略）と、AIエージェント向けの技術インフラ整備（サイトアクセシビリティ）について解説してきました。本記事はその3本目として、「AIエージェントがトランザクションを完了できるサイト設計」に焦点を当てます。

つまり、AIエージェントが人間に代わって実際に予約ボタンを押す・カートに入れる・決済する段階で、自社サイトがAIエージェントにとって「操作しやすい」設計になっているかどうか。ここが、AEOの次のフロンティアです。

前提知識——AIエージェントのトランザクション処理はどこまで進んでいるのか

エージェントプロトコルの全体像（2026年4月時点）

AIエージェントが外部サービスと連携してトランザクションを実行するためのプロトコルは、2026年に入って急速に標準化が進んでいます。全体像を理解するために、レイヤー構造で整理します。

レイヤープロトコル役割主導組織
ツール接続層MCP（Model Context Protocol）AIエージェントが外部ツール・API・データソースに接続する標準インターフェースAnthropic → Linux Foundation
エージェント連携層A2A（Agent-to-Agent Protocol）異なるAIエージェント間のタスク委任・連携Google
コマース取引層ACP（Agentic Commerce Protocol）エージェント間の商取引フロー標準化Stripe + OpenAI
コマース取引層UCP（Universal Commerce Protocol）カタログ発見・チェックアウト・決済の統一スキーマGoogle
決済インフラ層MPP（Machine Payments Protocol）AIエージェント専用のウォレット・決済インフラStripe

MCPは2026年2月時点で月間9,700万ダウンロードを超え、Anthropic、OpenAI、Google、Microsoft、Amazonなど主要AIプロバイダーすべてに採用されています。MCPは「USBのように、どのツールにも統一的に接続できる標準」として機能しています。

この上に、GoogleのUCPやStripeのACPが商取引に特化したセマンティクス（カタログ参照、注文、決済）を追加し、さらにStripeのMPP（2026年3月プレビュー公開）がAIエージェント専用の暗号ウォレットとプログラマブルな支出管理を提供するという、多層構造が形成されています。

なぜ「トランザクション完了」がサイト設計の課題になるのか

従来のWebサイトは人間のブラウザ操作を前提に設計されています。ボタンをクリックし、フォームに入力し、画面を目視確認する——このUIベースのフローは、AIエージェントにとっては極めて非効率です。

AIエージェントがトランザクションを実行するには、以下の3つの条件が必要です。

1. 操作可能なアクションが機械可読な形で公開されていること（Action Schema）

2. 決済フローがAPIまたはアクセシブルなDOMで処理可能であること（決済アクセシビリティ）

3. エージェントの操作権限が安全に委任されていること（認証・認可設計）

この3つのいずれかが欠けていると、AIエージェントは途中で処理を中断するか、そのサイトをスキップして競合サイトに移動します。つまり、AIエージェント時代のコンバージョンは「サイトの機械操作性」で決まるのです。

【設計ガイド①】MCP経由のAction Schema設計——予約・購入のツール定義

Action Schemaとは何か

Action Schemaとは、AIエージェントが実行可能な「操作」を機械可読な形で定義したものです。MCPの文脈では、MCPサーバーが公開する「ツール（tool）」の定義がこれに該当します。

MCPサーバーは軽量なプロセスで、ツール・リソース・プロンプトを公開します。各ツールはJSON Schemaで入力パラメータが型定義されており、AIエージェントはこの定義を読み取って「何ができるか」「どんなパラメータが必要か」を自動的に理解できます。

ECサイト向けAction Schemaの設計例

たとえば、レストラン予約サイトがMCPサーバーとしてAction Schemaを公開する場合、以下のようなツール定義が考えられます。

{
  "tools": [
    {
      "name": "check_availability",
      "description": "指定日時・人数の空席状況を確認する",
      "inputSchema": {
        "type": "object",
        "properties": {
          "date": { "type": "string", "format": "date" },
          "time": { "type": "string", "format": "time" },
          "party_size": { "type": "integer", "minimum": 1, "maximum": 20 },
          "seating_preference": {
            "type": "string",
            "enum": ["indoor", "outdoor", "counter", "private_room"]
          }
        },
        "required": ["date", "time", "party_size"]
      }
    },
    {
      "name": "create_reservation",
      "description": "予約を確定する。事前にcheck_availabilityで空席確認が必要",
      "inputSchema": {
        "type": "object",
        "properties": {
          "date": { "type": "string", "format": "date" },
          "time": { "type": "string", "format": "time" },
          "party_size": { "type": "integer" },
          "customer_name": { "type": "string" },
          "customer_email": { "type": "string", "format": "email" },
          "special_requests": { "type": "string" }
        },
        "required": ["date", "time", "party_size", "customer_name", "customer_email"]
      }
    },
    {
      "name": "cancel_reservation",
      "description": "予約をキャンセルする。キャンセルポリシーに基づき料金が発生する場合がある",
      "inputSchema": {
        "type": "object",
        "properties": {
          "reservation_id": { "type": "string" },
          "reason": { "type": "string" }
        },
        "required": ["reservation_id"]
      }
    }
  ]
}

Action Schema設計のベストプラクティス

1. 操作を細かいステップに分割する

「検索→確認→予約→決済」を1つの巨大なツールにまとめるのではなく、各ステップを独立したツールとして公開します。AIエージェントはステップ間で推論を行い、ユーザーに確認を求めることができるためです。

2. descriptionに前提条件と副作用を明記する

AIエージェントはdescriptionを読んでツールの使用判断を行います。「事前にcheck_availabilityが必要」「キャンセル料が発生する可能性がある」といった情報は、descriptionに必ず含めます。

3. エラーレスポンスを構造化する

エージェントがエラーを適切にハンドリングできるよう、エラーレスポンスにはエラーコード、人間可読なメッセージ、次に取るべきアクションの提案を含めます。

4. 冪等性（べきとうせい）を確保する

AIエージェントはネットワークエラー時にリトライを行います。同じリクエストを複数回送っても結果が変わらないよう、冪等なAPI設計にすることが重要です。

UCP（Universal Commerce Protocol）との連携

GoogleのUCPは、MCPのツール接続の上に商取引に特化した標準スキーマを追加するプロトコルです。UCPでは、カタログの発見（/.well-known/ucp）、商品検索、チェックアウト、決済確認といった商取引の一連のフローが型付きのリクエスト/レスポンスとして標準化されています。

自社サイトがUCPに対応する場合、AIエージェントはMCP、A2A、REST、ブラウザ組み込みプロトコルなど、どの接続方式でアクセスしても同じチェックアウトフローを利用できます。

【設計ガイド②】AIブラウジングエージェント向けの確認画面・決済フロー設計

なぜDOM構造が重要なのか

すべてのAIエージェントがMCPやAPIを通じてサイトにアクセスするわけではありません。Claudeのブラウジング機能やOpenAIのOperatorのように、実際のWebブラウザを操作してサイトと対話する「ブラウジングエージェント」も急速に普及しています。

ブラウジングエージェントは、DOMを解析してフォームを入力し、ボタンをクリックします。このとき、サイトのHTML構造が適切でなければ、エージェントは操作を完了できません。

確認画面のアクセシブルなDOM設計

注文確認画面は、エージェントが「正しい内容で注文しようとしている」ことを検証する最後のチェックポイントです。以下の設計原則を守ります。

1. セマンティックHTMLを使用する

<!-- ❌ エージェントが解釈しにくい設計 -->
<div class="order-summary">
  <div class="item">商品A</div>
  <div class="price">¥3,000</div>
</div>

<!-- ✅ エージェントが正確に解釈できる設計 -->
<section aria-label="注文内容の確認">
  <table role="table" aria-label="注文明細">
    <thead>
      <tr><th scope="col">商品名</th><th scope="col">数量</th><th scope="col">金額</th></tr>
    </thead>
    <tbody>
      <tr><td>商品A</td><td>1</td><td><data value="3000">¥3,000</data></td></tr>
    </tbody>
    <tfoot>
      <tr><td colspan="2">合計</td><td><data value="3000">¥3,000</data></td></tr>
    </tfoot>
  </table>
  <button type="submit" aria-label="注文を確定する">注文を確定する</button>
</section>

2. 金額は&lt;data&gt;タグで機械可読にする

表示用の「¥3,000」と機械処理用の「3000」を分離することで、エージェントが通貨計算を正確に行えます。

3. ボタンには明確なaria-labelを付与する

「確定」「送信」「次へ」だけでは、エージェントはそのボタンの機能を正確に判断できません。aria-label="注文を確定する"のように、操作の結果を明示します。

4. フォーム入力はautocomplete属性を活用する

<input type="text" name="name" autocomplete="name" aria-label="お名前">
<input type="email" name="email" autocomplete="email" aria-label="メールアドレス">
<input type="tel" name="phone" autocomplete="tel" aria-label="電話番号">

autocomplete属性は、ブラウジングエージェントが各フィールドの意味を理解するための重要な手がかりです。

決済フローの設計指針

1. iframeベースの決済フォームに注意する

StripeやSquareなどの決済サービスが提供するiframeベースの決済フォームは、セキュリティ上の理由からエージェントが直接操作できない場合があります。API経由の決済（Stripe Payment Intentsなど）をバックエンドで処理する設計にすることで、エージェントからの決済を可能にします。

2. 3Dセキュア認証への対応

3Dセキュア（3DS）認証はユーザーの介入が必要なステップです。エージェント経由のトランザクションでは、3DS認証が必要になった場合にユーザーに通知し、認証完了後にエージェントが処理を再開できるフローを設計します。

3. 決済完了のステータスを構造化データで返す

決済完了後のレスポンスには、注文ID、決済ステータス、配送予定日などを構造化データ（JSON-LDまたはmicrodata）で含めます。エージェントがこの情報をユーザーに正確に報告するために必要です。

【設計ガイド③】エージェント向け決済APIの認証設計——OAuth 2.1＋ユーザー委任トークン

なぜAPIキーではダメなのか

AIエージェントに決済を任せるとき、最大のセキュリティ課題は「誰の権限で、何を、どこまで実行してよいか」を制御することです。

従来のAPIキー方式では、以下の問題があります。

権限の粒度が粗い：APIキーを持っていれば何でもできてしまう（全権委任）

ユーザー同意がない：ユーザーが具体的に「この操作を許可する」という明示的な同意プロセスがない

監査証跡が不明確：「どのエージェントが、誰の代理で、何をしたか」をトレースできない

これに対し、OAuth 2.1 + ユーザー委任トークンの設計パターンが業界標準として確立しつつあります。

OAuth 2.1がAIエージェントに適している理由

MCPの2026年仕様では、リモートMCPサーバーの認証基盤としてOAuth 2.1が採用されています。OAuth 2.1はOAuth 2.0のベストプラクティスを集約した仕様で、以下の特徴があります。

特徴エージェントにとっての意味
PKCE必須認可コードの傍受攻撃を防ぎ、パブリッククライアント（エージェント）でも安全に認証できる
スコープベースの権限制御「予約の作成」「予約の閲覧」「決済の実行」など、操作ごとに細かく権限を制限できる
ユーザー同意画面「このAIエージェントが、あなたの代理で予約を行うことを許可しますか？」という明示的な同意を取得できる
短命アクセストークン + リフレッシュトークントークンが漏洩しても被害を限定でき、長期的なアクセスはリフレッシュトークンのローテーションで管理できる

IETFドラフト：AIエージェント向けOAuth 2.0拡張

2025年8月にIETFに提出された「OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents」は、AIエージェントの委任認証に特化した仕様です。この仕様の核となる考え方は、エージェントの認可を明示的・粒度的・監査可能にすることです。

この仕様のポイントは以下の通りです。

1. requested_actorパラメータ：認可リクエストに「どのAIエージェントが権限を必要としているか」を明示します。これにより、ユーザーの同意画面に「AIアシスタントXが、あなたの代理で予約の作成と会議室の予約を行うことを許可しますか？」と具体的に表示できます。

2. actor_tokenパラメータ：エージェントが自身のIDを証明するためのトークンです。ユーザーのIDとエージェントのIDを分離することで、監査ログに「エージェントXが、ユーザーYの代理で、操作Zを実行した」という完全なトレーサビリティを実現します。

3. 動的な同意取得：エージェントがリソースにアクセスしようとした時点で、リソースサーバーが必要な権限の不足を検知し、動的にユーザーの同意取得フローをトリガーできます。

実装パターン：段階的な権限委任

実際の実装では、以下のような段階的な権限委任パターンが推奨されます。

ステップ1：初回接続時——ユーザーがAIエージェントに自社サイトへのアクセスを許可する際に、最小限のスコープ（例：catalog:read、availability:read）のみを付与します。

ステップ2：購入意思確認時——エージェントが「この商品を購入する」という操作を実行しようとした時点で、追加スコープ（例：order:create、payment:execute）の同意をユーザーに求めます。この「インクリメンタルスコープ同意」は、MCP 2026仕様でも推奨されています。

ステップ3：高額取引時——一定金額を超える取引の場合、Step-Up認証（追加の本人確認）をトリガーして、ユーザーの意図を再確認します。

支出管理（Spending Controls）の設計

StripeのMPP（Machine Payments Protocol）では、人間のプリンシパル（本人）がエージェントに対してプログラマブルな支出制限を設定できます。以下のような制御が可能です。

1取引あたりの上限金額：「1回の購入は1万円まで」

カテゴリ制限：「飲食店のみ利用可」

加盟店ホワイトリスト：「指定した店舗のみ利用可」

時間枠別予算：「月間5万円まで」

これらの制限を超える決済リクエストは、エージェントが自律的に処理する前にブロックされ、人間の承認が必要になります。自社サイト側では、エージェントからの決済リクエストにこれらの制限情報が含まれている場合に適切に処理できる設計にしておくことが重要です。

【設計ガイド④】エージェント経由の注文に対するキャンセル・返金ポリシー設計

なぜエージェント専用のポリシーが必要なのか

AIエージェント経由の注文には、人間が直接操作する注文とは異なるリスクがあります。

意図の齟齬（そご）：ユーザーの意図をエージェントが誤解釈して注文を実行するケース（例：「来週の金曜」を「今週の金曜」と解釈）

重複注文：ネットワークエラーやリトライにより、同一注文が複数回実行されるケース

権限の逸脱：ユーザーが意図していない金額や商品でエージェントが注文を確定するケース

これらのリスクに対応するため、エージェント経由の注文に対しては、通常のキャンセルポリシーに加えて以下の仕組みを設計します。

推奨されるポリシー設計

1. クーリングオフ期間の設定

エージェント経由の注文に対して、注文確定後の一定時間（例：15分〜1時間）は無条件キャンセル可能な「クーリングオフ期間」を設けます。この期間中にユーザーが注文内容を確認し、エージェントの判断が正しかったかを検証できます。

2. 注文のステータスを段階的に管理する

ステータス意味キャンセル可否
pending_confirmationエージェントが注文を作成したが、ユーザーの最終確認待ち無条件キャンセル可
confirmedユーザーが確認済み、処理開始前クーリングオフ期間内なら無条件キャンセル可
processing処理中（調理開始、発送準備など）条件付きキャンセル可（キャンセル料あり）
completed処理完了（配送済み、サービス提供済み）返金ポリシーに準拠

3. エージェント経由であることの識別

注文データに「この注文はAIエージェント経由で作成された」ことを示すメタデータを含めます。これにより、カスタマーサポートが問い合わせを受けた際に、エージェントの誤動作による注文かどうかを迅速に判断できます。

Stripe MPPでは、エージェントが作成したPayment Intentにmachine payment metadataが自動付与され、人間による注文とエージェントによる注文を区別できます。自社システムでも同様のメタデータ設計を採用すべきです。

4. 返金フローの自動化

エージェント経由の注文でキャンセルが発生した場合、返金処理もAPIで自動実行できる設計にします。エージェントがcancel_orderツールを呼び出した際に、キャンセルポリシーに基づいて返金額を自動計算し、決済APIの返金エンドポイントを呼び出す——このフローが自動化されていれば、ユーザーはエージェントに「あの注文をキャンセルして」と言うだけで済みます。

実装ロードマップ——中小企業がまず取り組むべき5つのステップ

ここまで解説した内容をすべて一度に実装する必要はありません。以下のステップで段階的に進めることを推奨します。

ステップ1：確認画面・決済フローのセマンティックHTML化（すぐに対応可能）

既存のサイトの注文確認画面とフォームに、適切なaria-label、autocomplete属性、構造化データを追加します。コストをかけずに、ブラウジングエージェントからの操作性を大幅に改善できます。

ステップ2：主要アクションのAPI化（1〜3ヶ月）

「空席確認」「在庫確認」「予約作成」「注文作成」といった主要アクションを、内部APIとして整備します。既存のバックエンドロジックをAPIエンドポイントとして公開する作業です。

ステップ3：MCPサーバーの構築（3〜6ヶ月）

ステップ2で整備したAPIをMCPサーバーのツールとして公開します。MCPサーバーの構築は比較的シンプルで、Node.jsまたはPythonのSDKが公式に提供されています。

ステップ4：OAuth 2.1認証基盤の導入（6〜12ヶ月）

エージェントからの決済を安全に処理するために、OAuth 2.1ベースの認証基盤を導入します。既存のIDプロバイダー（Auth0、Keycloak、Descopeなど）にMCP認証フローを統合する形が最も効率的です。

ステップ5：UCP / ACP対応とエージェント専用ポリシーの整備（12ヶ月以降）

UCP（/.well-known/ucp）やACPへの対応により、Google、Stripe、OpenAIなどのエコシステムに参加するエージェントから自動的に発見・利用される状態を実現します。あわせて、エージェント経由注文のキャンセル・返金ポリシーを整備します。

よくある質問（Q&A）

Q1. MCPサーバーを公開しないと、AIエージェントからの購入はまったく受けられない？

いいえ。MCPサーバーがなくても、ブラウジングエージェント（ClaudeのブラウジングやOpenAI Operatorなど）はWebサイトを直接操作できます。ただし、セマンティックHTMLやaria-labelが適切に設定されていないと、操作の精度が大きく低下します。まずは確認画面やフォームのアクセシビリティ改善から始めるのが現実的です。

Q2. Stripe MPPに対応しないと、エージェント経由の決済は受けられない？

MPPは2026年3月時点でまだ開発者プレビュー段階であり、USDC（ステーブルコイン）での決済のみに対応しています。通常のクレジットカード決済であれば、Stripe Payment Intentsなどの既存の決済APIで十分にエージェント経由の決済を処理できます。ただし、将来的にはMPPがフィアット通貨にも対応する計画があるため、動向を注視しておく価値はあります。

Q3. AIエージェントに決済を委任するのは法的に問題ないのか？

現時点では、AIエージェントによる決済に特化した法規制は日本にはありません。ただし、特定商取引法に基づく「注文確認画面の表示義務」はエージェント経由の注文にも適用される可能性があります。また、消費者契約法の観点から、エージェントの誤操作による注文の取り消しが認められるケースも考えられます。法的リスクを最小化するには、エージェント経由の注文に対してユーザーの最終確認ステップ（pending_confirmationステータス）を設けることが重要です。

Q4. 小規模なECサイトでも対応すべき？

最低限、確認画面のセマンティックHTML化とフォームのautocomplete属性設定は、小規模サイトでも今すぐ対応すべきです。これらはSEOやアクセシビリティの観点からも有益で、コストはほぼゼロです。API化やMCPサーバー構築は、事業規模や競合状況に応じて判断してください。

Q5. GoogleのUCPとStripeのACPはどちらに対応すべき？

どちらか一方ではなく、将来的には両方への対応が望ましいです。UCPはGoogleのエコシステム（Gemini、Google Shoppingなど）との連携に強く、ACPはStripe/OpenAIエコシステムとの連携に強いです。ただし、いずれも2026年4月時点ではまだ標準化の初期段階にあるため、まずはMCPサーバー対応を優先し、UCP/ACPはプロトコルの成熟を見て対応するのが合理的です。

まとめ——「見つけてもらう」から「買ってもらう」までをAIエージェントに対応する

AIエージェント時代のコンバージョン最適化は、3つのレイヤーで構成されます。

レイヤー1：発見（Discovery）——AIエージェントに自社サイトを見つけてもらう（→ AEO×エージェント検索記事で解説済み）

レイヤー2：アクセシビリティ（Accessibility）——AIエージェントが自社サイトの情報を正確に読み取れる（→ サイトアクセシビリティ記事で解説済み）

レイヤー3：トランザクション（Transaction）——AIエージェントが自社サイトで予約・購入・決済を完了できる（→ 本記事）

この3つのレイヤーすべてが揃って初めて、AIエージェント経由のコンバージョンファネルが完成します。

2026年はMCP、UCP、ACP、MPPなどのプロトコルが急速に成熟し、エージェントコマースの基盤が整う年です。今のうちにセマンティックHTML化やAPI整備といった基礎的な対応を進めておくことが、近い将来の大きな競争優位につながります。

参考リンク

免責事項：本記事は2026年4月時点の公開情報に基づく情報提供であり、特定のプロトコルやサービスの利用を推奨するものではありません。各プロトコル・APIの仕様は急速に変化しているため、実装にあたっては最新の公式ドキュメントを必ず確認してください。法的判断については弁護士等の専門家にご相談ください。

コメント

タイトルとURLをコピーしました