エージェンティックコマースにおける検索

Contents

エージェンティックコマースの現実性

先日、コラムでSHOPTALK FALLで一番よく耳にしたワードに「Agentic」があると書きましたが、エージェンティックコマース(もしくはエージェンティックリテール)がより現実感のある形になってきたと感じています。
去年の段階では、エージェンティックコマースは、AI同士が自律したやり取りをしてショッピングをする、という概念でした。私個人としてはそれはちょっと一足飛びすぎで、実際にはプロトコルを定義した生成AIとサイトの接続(RAG＋α)がまずは現実的ではないかと思い、実際にそのような形として一旦収束してきているという印象です。
一番の違いとしては、ECサイト側に生成AIと会話するAIがいるのではなく、あくまで生成AIから操作が可能な受け口を用意するというパターンです。

UCP(ユニバーサルコマースプロトコル)とは

1月11日に、GoogleがUCP(ユニバーサルコマースプロトコル)という新たな規格を発表しました。
すでにShopify、Etsy、Wayfair、Target、Walmartなどが仕様の策定に参加しているとのことでしたが、まだその実際の仕様についてはよくわかっていません。
断片的な情報をつなぎ合わせると、どうも単独で完結したプロトコルではなく、各種プロトコルをつなぎ合わせるメタプロトコルのような位置付けに見えます。
(なので、Universalというワードを用いているのではないかと思います)

実際の仕様は、MCPと決済とその他商品情報等をGeminiなどの生成AIから網羅的に操作できるようにするということだと思われます。
Googleからすれば、プロトコルのレイヤーや粒度はさておき、MCP、ACP、A2A等と規格が乱立するなかで、とりあえずUCPに準拠すれば良いという状況を作りたかったというのと、あとはOpenAIがWalmart、Target、Shopifyと接続事例を広げていく中で、その差を詰めるもしくは捲りたい、ということではないかと思います。
UCPはオープン規格とのことなので、今後のAIとECの関連を考えると歓迎すべき動きになることが期待されます。

さらに高まる検索の重要性

一方で、当社からすると、GoogleというかGeminiがオープンな規格にシフトしていくことは、大変歓迎です。
RAGであろうがMCPであろうがUCPであろうが、いずれにしても、AIとECが接続していく流れにおいては、ECサイト側でのデータの整備と商品情報検索に対する要求がより高くなるのは間違いなく、それこそが当社がもっとも得意とする部分だからです。
RAGというのはプロトコルではなくて概念ですが、2020年にRAGという概念が提唱され、昨年あたりから一気にRAGの利用例が増加し始めました。
その中で、当初の「RAGによってLLMの非決定性やハルシネーションといった問題をカバーできる」という認識から、実装が進むにつれ「RAGにおける検索のテクノロジーは意外にハードルが高い」という、より具体的な課題にぶつかるケースが増えてきたようにも思います。

そして、同じ課題は、UCPやMCPの利用でも発生するのは間違いありません。繋げば良い、ということではなく、繋いだ状態で「いかに適切な商品検索もしくは商品情報検索の返却ができるか」という課題にぶつかることは、容易に想像できます。
もちろん検索の重要性というのはECに限った話ではありませんが、ECは特にロジックの実装の難易度が高いというのは、まだ十分に認知されていないといえます。
「検索ってそんなに手間がかかるものですか？」というコメントは、今でもまだちょくちょく聞きます。
そして、これは以前のコラムでも触れましたが、生成AIとECが接続すると、検索の難易度はさらに上がる傾向があると予想されます。
理由としては、消費者が「シャツ　白」というような単純なキーワードだけではなく、「来週の○○というイベントで使う、カジュアルすぎない白やモノトーンのシャツ」といった、コンテキストで検索してくる割合が増えるためです。

もちろん、コンテキストがないキーワードだけの検索よりも、コンテキストがあるほうがより適切な結果を出し得る、言い換えると頑張りがいがありますが、そこで要求される検索ロジックの複雑さは当然上がります。
RAGなりエージェンティックコマースなりの活用で、LLMの非決定性やハルシネーションといった問題を回避できるかは、検索で「真っ当な結果」が返却できる場合に限るということです。
ECサイトの検索画面だろうが、ECサイト自体のAIチャットだろうが、生成AIだろうが、いずれにしてもどこかで「キーワードなりコンテキストから適切な検索結果を返す」という動作は必要とされますし、当社の強みはまさにそこにあるので、今後も当社の検索の需要というのは減るどころかさらに高まると考えています。

RAGと検索の、現実的な難しさ

そういえば、UCP発表の直前に、ブレインパッドさんの記事で
「RAG(検索拡張生成)にまつわる「あるある」の沼から抜け出すための３つのチューニングポイント」というものがありました。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
RAG(検索拡張生成)にまつわる「あるある」の沼から抜け出すための３つのチューニングポイント：現場のRAG活用術第1回(2026年1月6日公開)
https://www.brainpad.co.jp/doors/contents/rag_tuning_points/
(出典元：株式会社ブレインパッド「DOORS」)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3つのポイントとして、「データ」「検索ロジック」「プロンプト」とありましたが、プロンプトはLLM側の担当なのでさておき、まさにデータと検索ロジックは当社の守備範囲であると言えます。
今後、RAGやエージェンティックコマースの実装例が増えていく中で、「あれ検索の難易度って思っていたよりも高くない？」という事例も増えていくでしょう。

是非そうしたケースにおいては、当社にご相談ください。