AI Agentのための「明文化」の必要性
こんにちは、CCCMKホールディングスAIエンジニアの三浦です。毎年春になるとどこかそわそわするような落ち着かない気持ちになります。
私たちは最近開発周りの「明文化」「可視化」の必要性を感じて取り組みを始めています。タスクの可視化、実装前のissueの発行、開発ドキュメントの作成など、これまでは「暗黙の了解」で済んでいたことを見直し始めています。その理由はAI Agentの性能を最大化するためです。
AI Agentにタスクを依頼する際には「暗黙の了解」が通じないものと考えて、これまでのタスクの内容や仕様、開発環境などを明文化してAI Agentが常に参照できるようにしています。その粒度が人によって変わってしまうとAI Agentのタスクの精度がぶれ、成果物の品質にも影響してしまいます。 ある程度決まった標準規格の元で明文化することが重要です。
さて、最近Agenticコマースという、AI Agentが商品の検索から購入まで代行させるという新しい商取引の形がホットになってきています。普段使っているチャットAgentに「週末どこどこにいくからホテルを予約しておいて」と入力したら、ホテルの検索から予約、支払までAgentを通じて完了できてしまう、そんなことがAgenticコマースでは実現できると言われています。
商取引において、さまざまな業態や事業が取引先になりますが、それらとAI Agentがやり取りをする場合、どのような形式で情報をやり取りをし、どのようなフローが手続きを進めるのかを明文化してAI Agentに知らせる必要があります。しかもそれらの仕様が取引先ごとにバラバラだとAI Agentが正確な取引が出来ない可能性も出てきます。AI Agentが商取引に参加するための標準化され、明文化されたルールが必要になります。
Universal Commerce Protocol (UCP)
Googleが公開しているUniversal Commerce Protocol (UCP)はEコマースにおける事業者間のデータのやり取りやフローを定め、AI AgentがEコマースに参加出来るようにするための取り決め(プロトコル)です。UCPに対応したAI Agentやアプリ(プラットフォーム)はUCPに対応した事業者サービス(ビジネス)と連携し取引をすることが容易になります。
UCPの仕様が記載された開発者向けのドキュメントが公開されています。
最近Overviewのページを一通り目を通すことが出来、色々と勉強になったので、こちらの記事でまとめていきたいと思います。
UCPの仕様概要
プラットフォームとビジネス
UCPの仕様の概要では主に「プラットフォーム」と「ビジネス」という主体が登場します。プラットフォームはユーザーが直接使用するアプリやチャットAgentに該当し、ビジネスがサービスや商品を販売する販売事業者に該当します。UCPの仕様の概要では主にプラットフォームとビジネスのやり取りに関する仕様が述べられています。
サービス(service)とケーパビリティ(capability)
UCPではプラットフォームとビジネスはそれぞれ自身がどのような機能を提供しているのかを提示します。サービスはどのようなサービス(たとえば"Shopping"だと買い物が出来ることが分かります。)を提供しているのかと、それがREST APIやMCPに対応しているのか、対応しているのであればエンドポイントやどんなパスが用意されているのかを定義します。
ケーパビリティはそのサービスの中でどんな機能が使えるのか(たとえばShoppingサービスであれば"checkout"(購入手続き)や"discount"(割引)などの機能が挙げられます。)、やり取りするデータのスキーマなどを定義します。
サービスやケーパビリティには命名規則があります。たとえば買い物を提供するサービスだとdev.ucp.shopping、購入手続きのケーパビリティはdev.ucp.shopping.checkoutのようになります。
最初のdev.ucpはそのサービスやケーパビリティを管理する主体のドメインを逆順にしたものです。dev.ucpはucp.devというドメインが管理するサービスやケーパビリティであることを示しています。次のshoppingがサービス名、checkoutがケーパビリティ名です。
プラットフォームとビジネスのやり取りの基本フロー
ケースによって細かいところは変わりますが、たとえばアプリ（プラットフォーム）から商品販売店（ビジネス）に購入手続きを依頼する場合、プラットフォームとビジネスの基本的なやり取りは次のようになります。
まず、プラットフォームはそのビジネスがどんな機能を提供しているかを知る必要があります。ビジネスは自身のUCPプロファイルを/.well-known/ucpに公開しており、プラットフォームはそこにアクセスすることで、そのビジネスが対応しているサービスやケーパビリティ、利用できるtransportやendpointを知ることができます。たとえばcheckoutやdiscountといった機能に対応しているかは、このプロファイルから確認します。
一方で、プラットフォーム側にも「自分が扱える機能」の範囲があります。たとえば商品検索まではできても、購入手続きの開始や完了には対応していないアプリもあります。そのためプラットフォームは、ビジネスのプロファイルと自分のプロファイルをもとに、双方で共通して利用できそうなサービスやケーパビリティを把握し、必要なスキーマを解決してリクエストを組み立てます。
プラットフォームはビジネスにリクエストを送る際、自分のプロファイルURLをヘッダに含める必要があります。ビジネスはそのURLからプラットフォームのプロファイルを取得し、自分のプロファイルと突き合わせて、今回のやり取りで使用するケーパビリティを決定します。リクエストを処理し、レスポンスにはその処理で使ったUCPのバージョンや有効なケーパビリティを含めて返します。
ケーパビリティの拡張
UCPのケーパビリティにはベースとなるものとそれを拡張したものがあります。たとえばcheckoutやcartがベースのケーパビリティでdiscountが拡張したケーパビリティとして挙げられます。
ケーパビリティの拡張は、もう少し具体的に述べるとベースのケーパビリティのスキーマを拡張することに対応します。たとえばcartというケーパビリティのスキーマが
{ "line_items": [ { "item": { "id": "prod_1", "quantity": 2, "title": "T-Shirt", "price": 2000 } } ] }
だったとします。もしcartの拡張discountが有効な取引の場合、このスキーマは以下のように拡張されます。
{ "line_items": [ { "item": { "id": "prod_1", "quantity": 2, "title": "T-Shirt", "price": 2000 } } ], "discounts": { "codes": ["SUMMER20"] } }
ビジネス側はdiscountsの値を見て適切な割引処理を実行します。
discountからはcartは親のケーパビリティになります。親のケーパビリティは複数持つことが可能で、たとえばdiscountであればcartだけでなくcheckoutも親になります。つまり割引処理はカートに追加する時だけでなく、購入手続きにおいても適用できるようになります。
プラットフォームの認証
UCPではビジネス側でプラットフォームの認証を行う仕組みが複数用意されています。API KeysやOAuth 2.0など、事前にプラットフォームを登録しておく方法もありますが、HTTP Message Signaturesという事前のやり取りを必要としない方法も使用することが出来ます。
HTTP Message Signaturesによる認証手続きは次のように行われます。まずプラットフォームがリクエストを送信する際に自身が持っている秘密鍵を使ってメッセージを署名し、署名も合わせて送信します。ビジネスはリクエストを受け取るとリクエストに含まれているプラットフォームのプロファイルのURLからプロファイルを取得します。プロファイルには先に述べたようにプラットフォームが対応しているケーパビリティなどの情報が含まれていますが、公開鍵も含めることが出来ます。ビジネス側ではその公開鍵を使って署名を検証し、そのリクエストがそのプロファイルに対応する秘密鍵の持ち主によって送信されたことを確認できます。
支払処理フローの概要
UCPの支払処理フローではビジネスとプラットフォームに加え、Payment Credential Providerが関係してきます。Payment Credential Providerは決済代行会社などが該当し、支払処理に必要な手順を決め、その手順をまとめたhandlerを公開します。ビジネスは自店で対応するhandlerを決めてそのhandlerを利用するための設定情報をcheckoutの応答などでプラットフォームに返します。たとえば、どの支払い手段を受け付けるか、どのhandlerを使うか、処理に必要な加盟店IDや公開鍵などがここに含まれます。プラットフォーム側ではビジネスのプロファイルに記載された支払い手段の中から選択してPayment Credential Providerとやり取りをし、得られた結果をビジネスに渡し、ビジネスはその結果を使って決済代行会社に課金処理を実行し注文を確定する、という流れです。
まとめ
今回はコマースシステムの標準規格「Universal Commerce Protocol (UCP)」の概要について調べたことをまとめてみました。読んでみて、特にビジネスとプラットフォームの間で動的にメッセージのスキーマを決定するという考えが面白かったです。特定のアプリやAgentに限定されないようにする工夫なのかな、と感じました。UCPのロードマップでは今後ロイヤリティプログラム周りの対応も行っていくようです。
今後もUCPの仕様に注目していきたいと思います。
