Auth0が「AI Identity for Agentic Commerce」を発表、AIエージェント購買で誰が認証・認可されるのか
Oktaが発表したAuth0の新機能を解説します。ChatGPT経由の購入で加盟店は何を検証するのか、CIMDとOn-behalf-ofトークン交換の仕組み、Forresterが指摘する未解決点と未開示の条件までまとめました。
この記事のポイント
- Oktaが2026年9月2日、Auth0の新機能群を発表しました。中心にあるのは「AI Identity for Agentic Commerce」で、AIエージェントが会話の流れのまま購入まで進む取引を、加盟店側のID基盤で受け止めるための機能です。
- 技術的な中身は、CIMDによるエージェントの事前登録、On-behalf-ofトークン交換による一時的で範囲を絞った権限付与、そしてMCPサーバーの保護という3点に集約されます。エージェントに恒久的な資格情報を渡さない設計が前提です。
- 一方でForresterは、エージェント認可のリスク定義と計測に成熟した製品解が存在せず、標準そのものが未確定だと指摘しています。価格や日本での提供条件も未開示で、現時点では設計思想を確認する段階の情報です。
AIエージェントが買い物をするとき、加盟店は誰を確認しているのか
Auth0が、事業成長の加速、AIエージェントの保護、シームレスな顧客体験の提供をエージェンティック時代に実現するための新しいID機能を発表しました。
www.okta.com顧客がChatGPTに「登山靴を探して、そのまま買っておいて」と頼んだとします。数分後、加盟店のサーバーに購入リクエストが届きます。このとき加盟店が答えなければならない問いは2つです。この向こう側に実在の人間がいるのか。そしてその人間は、この金額を使う権限を本当に渡したのか。
Auth0のリテール担当プロダクトマーケティングマネージャーであるBradford Peirce氏は、8月末に公開した解説記事でこの2問を並べ、多くの小売システムはどちらにも確実には答えられないと書いています。だからこそ、AIで商品を見つけた消費者の多くは、チャット内で決済まで完結せず、リンクを踏んで自社サイトへ戻ってきている、という整理です。
Oktaが2026年9月2日に発表したAuth0の新機能群は、この2問に答えるための部品を製品として束ねたものです。B2C向けとB2B向けが同時に出ていますが、エージェンティックコマースに直接関わるのはB2C側です。
発表された機能と、それぞれが引き受ける仕事
| 機能 | 対象 | 何を解決するか | 提供状況（発表時点） |
|---|---|---|---|
| AI Identity for Agentic Commerce | B2C | 自社開発のAIアシスタントに、商品推薦と接客を安全に行わせる | 9月下旬に一般提供予定 |
| Auth0 Identity Conversion Suite | B2C | 会員登録前の匿名セッション保持と、サインアップ動線のA/Bテスト | ベータ、9月下旬にアーリーアクセス |
| B2B Connect | B2B | 既存のID基盤を残したままエンタープライズSSOと多テナントを追加 | ベータ、9月下旬にアーリーアクセス |
| Tenancy-as-a-Service | B2B | テナント管理の自己サービス化と委任管理 | 一般提供済み |
主役はAI Identity for Agentic Commerceです。プレスリリースの説明は、事業者が自前で作ったAIアシスタントを保護し、商品推薦と接客をより安全に行えるようにする機能群、というものでした。加えて、ChatGPTのようなサードパーティAIアシスタント経由の購入についても、安全でシームレスなチェックアウトを可能にすると書かれています。つまり自社エージェントと外部エージェントの両方を、同じID基盤で受け止めるという設計です。
Auth0のChief Product OfficerであるGareth Davies氏は、発表のなかでこの狙いを収益とリスクの関係として説明しています。
AIエージェントが消費者に代わって行動し取引するようになるにつれ、事業機会と脆弱性の両方の表面積が広がります。
B2B側のB2B ConnectとTenancy-as-a-Serviceは、SaaS事業者がエンタープライズ顧客を受け入れるための機能で、既存のID基盤を全面移行せずにSSOとフェデレーションを載せられる点が売りです。EC事業者にとっての優先度は高くありませんが、Auth0が「移行させずに上に載せる」形を選んでいる点は、B2C側の設計思想とも共通しています。
CIMD、トークン交換、MCPサーバー
発表そのものは機能名の羅列に近いのですが、実装の中身はAuth0が事前に公開していた解説から読み取れます。サードパーティのショッピングエージェントを受け入れる場合、仕組みは3つの部品でできています。
1つ目がエージェントの登録です。エージェントのメタデータを配布して識別するCIMDと、エージェント自身を主体として扱う「Agent as Principal」モデルを使い、加盟店側がどのプラットフォームにアクセスを許すかを明示的に決めます。ChatGPTは許すがそれ以外は許さない、といった線引きが加盟店の手に残ります。エージェントを匿名のトラフィックとして扱わず、名前のついた主体として登録するという発想です。
2つ目がOn-behalf-ofトークン交換です。買い物客がカートを承認した時点で、エージェントにはその取引だけに紐づいた一時的で範囲の狭いパスが発行されます。エージェントがマスターキーを持つことはなく、パスは短時間で失効します。3つ目がMCPサーバーの保護で、加盟店が商品カタログやカート操作を外部エージェントへ開くときの入口に認証と認可をかけます。
この土台は今回が初出ではありません。Auth0はAuth0 for AI Agentsのドキュメントで、サードパーティAPIの資格情報を預かるToken Vault、CIBAを使って人間の承認を非同期で挟む仕組み、RAGの参照範囲を利用者の権限で絞るFGAをすでに公開していました。金銭が動く操作で人間の承認を挟めることは、エージェント決済では設計上の要になります。
親会社のOktaは8月24日にAgent SSOの一般提供も発表しています。こちらは従業員が使うエージェントを対象にした企業内の話ですが、静的なAPIキーや個別のOAuth付与を短命なトークンへ置き換えるという方向は共通しています。同社の調査では、AIエージェントに人間の従業員と同じセキュリティ管理を適用している組織は34%にとどまると報告されています。Cross App AccessがMCPの企業向け認可拡張として正式に組み込まれた点も、標準側の動きとして押さえておく価値があります。
プロトコル競争のなかでの位置
エージェント決済の議論は、この1年ほどACPとUCPというプロトコルの主導権争いに集中してきました。Auth0はどちらかに賭ける立場を取らず、UCPサーバーの保護、AP2への対応、ID連携の簡素化を「今後の方向」として挙げるにとどめています。現時点でUCPやACPとの統合は完了しておらず、取り組み中という表現です。
見落とされがちなのは、プロトコルが決めているのは主に決済と注文の受け渡しであり、その手前の「誰が誰に何を委任したか」は別レイヤーだという点です。当サイトでもパスキーだけでは認可の証明にならないという論点を扱いましたが、認証（本人であること）と認可（その金額を使ってよいこと）は別物で、Auth0が製品化しようとしているのは主に後者です。同じ問題意識から、エージェント自身の身元を確認するKnow Your Agentの枠組みや、Ping IdentityやSaviyntなどID基盤ベンダー各社の参入も並行して進んでいます。Auth0の発表は、この混戦のなかでCIAM（顧客ID管理）側から入る一手だと見るのが正確でしょう。
数字と、アナリスト側の留保
プレスリリースは、AIエージェントが4年以内に米国ECの最大25%を動かすと予測されると書き、Bainのレポートを参照しています。ただしBainの原文を読むと、2030年までに3,000億から5,000億ドル、EC全体の15%から25%という幅で示されており、Oktaが引用しているのはその上限です。Bain自身は、多くの消費者が端から端までAIに取引を任せることにまだ抵抗があるとも書いています。
より実務的な留保はForresterから出ています。Identiverse 2026の総括で同社は、エージェントの認証はOAuth 2.1とOIDCで成熟しつつある一方、認可のほうが静的なRBAC/ABACから文脈依存の判断へ移行する途中であり、パラダイムが変わりつつあると整理しました。指摘のなかで重いのは次の2点です。
まず、エージェントの行動が生む財務・レピュテーション上のリスクについて、定義も計測も成熟した製品解がなく、事業者は自前のテレメトリで凌いでいるという評価です。同社は具体例として、購買エージェントがサイトをスクレイピングして在庫をカートに押さえ込む、不正な購入を行う、所有者である人間を不満にさせる行動をとる、という3つを挙げています。実際、小売を狙ったエージェント悪用のシナリオはセキュリティベンダー側からも報告されています。
もう1つは標準の未成熟です。関連する仕様の多くが未完成か公開後12か月未満で、商用サポートも出そろっていないため、多くの組織は標準が固まるのを待っている状態だとForresterは書いています。設計原則として同社が推すのはなりすましではなく委任、つまりエージェントに人間のふりをさせるのではなく、一意に識別されたエージェントへ権限を渡す形です。Auth0のOn-behalf-of型の設計は、この推奨と同じ方向を向いています。
発表で開示されていない条件
導入判断の材料として、現時点で未開示の項目を整理しておきます。
- 価格: AI Identity for Agentic Commerceを含む新機能の料金体系は発表に含まれていません
- 対応リージョン: 提供対象地域の限定があるかどうかは示されていません
- 日本語・国内対応: 日本市場での提供条件や国内決済手段との組み合わせについて言及はありません
- プロトコル対応の時期: UCP・ACP・AP2との統合は取り組み中とされ、対応時期は明示されていません
- 導入実績: エージェンティックコマース機能そのものの稼働事例や数値は示されていません。発表で名前が出た顧客の事例は、ロイヤルティ会員のMFA強化とSSO設定に関するものです
なお、プレスリリースには一般提供前の機能について「予定どおり提供されない可能性があり、購買判断の根拠にすべきではない」という趣旨の但し書きが明記されています。9月下旬という時期も確定ではありません。
まとめ
今回の発表で前進したのは、エージェント経由の購入を受け入れるために加盟店側が用意すべき部品が、エージェント登録・スコープ付きトークン・MCPサーバー保護という具体的な単位に分解されたことです。抽象的な「エージェントを安全に」という話から一段降りた点に意味があります。
一方で、認可の妥当性をどう測り、誤った購入が起きたときに誰の責任として追跡するかは、製品側にも標準側にもまだ答えがありません。Forresterが言うとおり、多くの企業が標準の固まりを待っている段階です。
EC事業者が今のうちに整理しておけるのは、ツール選定より前の3点でしょう。自社の商品データを外部エージェントへ開くのか自社エージェントに閉じるのか、開くならどのプラットフォームまで許すのか、そして金額のどこから人間の承認を必須にするのか。この3つに答えが出ていれば、9月下旬以降に出てくる価格と仕様を、自社の条件に照らして評価できます。
