「来月の出張に使うホテルを、予算3万円以内で予約しておいて」

こうした指示を受けたAIエージェントが、条件に合う商品やサービスを探し、比較し、購入まで実行する。そんな購買体験が現実になりつつあります。

エージェントが人間に代わって商品を選び、取引を行う仕組みは「エージェンティックコマース」と呼ばれます。OpenAIとStripeが2025年9月に発表したAgentic Commerce Protocol（ACP）や、Googleなどが推進するUniversal Commerce Protocol（UCP）など、実現に向けた標準化も進んでいます。

一方で、AIが買い物をするには、商品情報を取得できるだけでは足りません。誰の許可で購入するのか、何をいくらで購入したのか、そして取引を確実に完了できるのか。こうした課題を解決するうえで、APIが重要な役割を担います。

エージェントが「買い手」になる

従来のECでは、人間がWebサイトやアプリを操作し、商品を選び、カートに入れ、決済ボタンを押していました。購入の意思決定も、最終的な操作も、人間が担うことが前提です。

エージェンティックコマースでは、この前提が変わります。

ユーザーの依頼を受けたAIエージェントが、条件に合う商品を探し、価格や在庫、配送条件などを比較し、場合によっては注文や決済まで実行します。人間は一つひとつの画面を操作するのではなく、目的や条件を伝え、実行を委ねる立場になります。

ただし、購入をエージェントに任せることは、単に操作を自動化することとは違います。エージェントが誤った商品を選んだり、意図しない金額で購入したりした場合、その影響は実際の取引に及びます。

重要になるのは、エージェントが何をできるかだけでなく、誰の許可を得て、どの範囲で行動しているかです。

コマースと決済を支えるプロトコル

エージェンティックコマースの実現に向けて、複数のプロトコルが登場しています。それぞれが完全に競合しているわけではなく、役割が一部重なりながら、組み合わせて利用されることが想定されています。

たとえば、OpenAIとStripeが発表したACPは、ChatGPT上で商品を探し、購入する仕組み「Instant Checkout」として2025年9月に動き始めました。当初はユーザーが商品や支払い内容を確認して購入する形で、エージェントが購買プロセスを担う商用サービスの一例となっています。

一方、GoogleのAP2は、購入そのものよりも、その取引が本人の許可に基づいていることを検証できる仕組みに重点を置いています。

MCPがエージェントと外部ツールをつなぐ仕組みであるのに対し、ACPやUCPはコマースの流れを、AP2は認可と証跡を担います。これらは構成に応じて組み合わせられます。

そして、こうした連携の主要な経路を支えるのがAPIです。エージェントが商品を探し、予約内容を組み立て、注文や支払いを依頼するまで、システム間のやり取りはAPIを介して進みます。

「誰が許可したのか」を証明する

エージェントに購入を任せる際、決済を受ける側には一つの疑問が生まれます。

この支払いは、本当に本人が許可したものなのか。

従来の決済にも本人認証や不正利用を防ぐ仕組みはあります。しかし、カード情報を使えることと、ユーザーがエージェントにどの範囲の購入を許可したかを証明できることは別です。

この課題に対応する仕組みの一つが、AP2の「マンデート（Mandate）」です。ユーザーやエージェントに与えられた権限と取引内容を、暗号学的に検証できるデジタルデータとして表します。

たとえば、ユーザーが「予算3万円以内でホテルを予約して」と指示した場合、購入内容や支払い権限を示す情報を記録し、誰が何をどの条件で承認したのかを、取引に関わる関係者が後から検証できるようにします。

購入のたびに本人が確認する方法だけでなく、あらかじめ条件を承認し、その範囲内でエージェントに実行を任せる方法も考えられます。

ただし、こうした仕組みがあればすべて安全になるわけではありません。署名によって「誰が何を承認したか」は検証できても、エージェントが選んだ商品そのものがユーザーの意図に合っていたかまでは保証できないからです。認可の仕組みと、エージェントの判断を適切に制御する仕組みは、両方必要になります。

APIは「つながる」だけでなく「確実に動く」必要がある

もう一つの課題は、取引を確実に完了できるかという点です。

エージェントがAPIを呼び出す際、認証に失敗したり、必要なエンドポイントを見つけられなかったり、データ形式の不一致で処理が止まったりする可能性があります。人間であれば画面を見て操作をやり直せますが、エージェントが同じように対処できるとは限りません。

こうした問題は、取引件数が増えるほど無視できなくなります。

Postmanが公開した「APIFlow-Bench」は、AIエージェントが認証、エンドポイントの発見、スキーマの修復、複数ステップの操作、エラーからの復帰などを、どこまで確実に実行できるかを評価するベンチマークです。単発の応答が正しいかではなく、複数のAPI操作を最後まで完了できるかを測定します。

エージェントに買い物を任せるには、APIが存在するだけでは不十分です。エージェントがAPIを発見でき、正しく理解し、エラーが起きても処理を継続できる設計が求められます。

企業は何を準備すべきか

エージェンティックコマースへの対応は、ECサイトにAIチャットを追加すれば完了するものではありません。商品情報、在庫、価格、注文、決済といった既存の仕組みを、エージェントが利用できる形で連携させる必要があります。

企業が確認すべきポイントは、次の3つです。

• 商品・サービス情報の機械可読性：商品情報や価格、在庫、配送条件などを、エージェントが正しく取得・理解できるか。
• APIによるシステム連携：商品探索から注文、決済まで、必要な情報や処理をシステム間で連携できるか。
• 認可と取引の検証可能性：誰がどの範囲の購入を許可したのか、取引内容を後から検証できるか。

特に重要なのは、APIを後から付け足すだけでなく、最初からAPIを通じた連携を前提にシステムを設計する「APIファースト」の考え方です。

エージェンティックコマースは、購買体験の変化であると同時に、企業のシステム設計やガバナンスを見直す契機でもあります。

次回は、書籍『APIファースト：Postmanで学ぶ効率的かつ柔軟な開発アプローチ』の著者に話を伺い、APIファーストの考え方や、既存システムをどのようにエージェント時代に対応させていくべきかを掘り下げます。

• Postman株式会社