Fanplayrが商品カタログをAI可読に変換する「Catalog Intelligence」を発表、AI可視性スコアは何を測るのか
FanplayrのCatalog Intelligence発表を起点に、AI可視性スコアの8つの評価軸と、GoogleやOpenAIが実際に求めている商品データ要件を突き合わせ、EC事業者がカタログのどこから直すべきかを整理します。
この記事のポイント
- Fanplayrが2026年8月25日、商品カタログをAIが解釈できる構造データに変換する「Catalog Intelligence」を発表しました。全案件が「AI Visibility Assessment」から始まり、商品情報の完全性やカテゴリ属性など8つの観点でAI可視性スコアを算出します
- 同じ問題意識はすでにプラットフォーム側の仕様に現れています。GoogleのMerchant Centerには会話型体験向けの属性が追加され、OpenAIの商品フィードはGoogle互換フォーマットを受け付けています。商品データの整備はベンダーの主張ではなく、供給先の要件として固まりつつあります
- 一方でAI可視性スコアの類は測り方が各社で異なり、絶対値の比較には向きません。価格も導入実績も未開示である以上、識別子とバリアント構造という自社で直せる箇所から着手するのが現実的です
商品カタログは、そもそもAIのために作られていない
Fanplayrが、従来の商品カタログをAI向けの商品インテリジェンスに変換する新ソリューション「Catalog Intelligence」を発表しました。
pressreleasehub.pa.media商品データの不備がAI経由の売上を削っている、という指摘そのものは目新しくありません。今回の発表が興味深いのは、その不備を「診断してスコア化する」ところから商売を始めている点です。
AIによるコンバージョン最適化とパーソナライズを手がけるFanplayrが、2026年8月25日にCatalog Intelligenceを発表しました。同社の基盤であるVerada AIを使い、商品データを分析・エンリッチ・構造化して、AI検索やレコメンドエンジン、マーケットプレイスから商品が理解されやすい状態に整える、というのがその中身です。提供はグローバルで、対応地域は北米・欧州・アジア・中南米とされています。
生成されるのは、カテゴリ固有の属性と分類、商品ファクトと仕様と識別子、想定利用者とユースケースのシグナル、セマンティック検索向けの言語表現、バリエーション同士の関係、そしてエクスポート可能な構造化データです。足りない項目を埋めるだけの作業とは違う、と同社は説明しています。その商品が何で、誰のためのもので、どう分類され、いつ推薦されるべきかという文脈をAIに与えることが目的だ、という位置づけです。
CEOのSimon Yencken氏は次のように述べています。
私たちは、AIが消費者にとって商品を発見し、評価し、購入する主要な手段になりつつある、オンラインショッピングの新しい時代に入りつつあります。ほとんどの商品カタログは、そうした世界のために設計されたものではありません。
なお同社はこの8カ月ほど、同じ方向に段階的に手を伸ばしてきました。2025年12月には、人間の買い物客が理解するのと同じようにAIが商品を解釈し、文脈的なタグを自動生成するVerada AI Tagsを発表しています。今回のCatalog Intelligenceは、そのタグ生成をカタログ全体の構造化と診断まで拡張したもの、と読むのが自然でしょう。
AI可視性スコアが見ている8つの観点
Catalog Intelligenceの案件は、必ずAI Visibility Assessmentから始まります。カテゴリごとにAIが期待する情報と自社の商品データを突き合わせ、AI主導の商品発見に対する準備度をスコアとして示す仕組みです。
評価が及ぶのは、商品情報の完全性、カテゴリ属性、分類、識別子、画像とメディア、オーディエンスと検索シグナル、バリアント構造、そして総合的なAI対応度の8点。cia.fanplayr.com では無償の「AI Visibility Snapshot」が提供され、代表的な商品サンプルを数分で分析するとされています。
ここで注意しておきたいのは、この発表がベンダー自身のプレスリリースであるということです。価格、導入企業名、スコア改善が売上にどう跳ね返ったかの実測値は、いずれも未開示です。スコアの算出方法についても、8つの観点が列挙されているだけで、重みづけや基準の詳細は公開されていません。
プラットフォーム側の要求は、すでに具体的な仕様になっている
ベンダーの主張から離れて、供給先が実際に何を求めているかを見たほうが話は早いはずです。ここ1年ほどで、商品データの要件は「整備したほうがよい」という助言のレベルを超え、公開仕様として書き下されています。
OpenAIは商品フィードの仕様を公開しており、UTF-8のタブ区切りまたはCSVファイルで、1行に1商品または1バリアントを記載することを求めています。必須項目は id、title、description、link、image_link など。興味深いのは、Google互換の商品データフォーマットであれば、列名をOpenAIの項目名に変え直さずにアップロードできると明記されていることです。フィード運用の実務は、事実上Googleの商品データ仕様を土台に統合されつつあります。
バリアントの扱いについては、OpenAIのベストプラクティスがかなり踏み込んでいます。親商品には安定したIDを、購入できる選択肢ごとには固有のバリアントIDを与える。title、url、description、media、availability、price は、バリアントごとに値が異なるならバリアント固有にする。色やサイズといった選択軸は variant_options に入れる。Fanplayrが挙げる「バリアント構造」という評価軸は、この種の要件をそのまま指しています。
Google側の動きはさらに具体的です。同社は2026年1月に、AI Mode・Gemini・Business Agentに向けた多数の商品データ属性を追加し、あわせてUniversal Commerce Protocolを公開しました。Shopify、Etsy、Wayfair、Target、Walmartと共同で策定された、エージェントが商品を発見して決済まで進むための共通規格です。追加された属性のうち popularity rank、document link、question and answer、related product には、Merchant Centerのヘルプ上で「主にAI Modeのような会話型体験での利用を意図している」という趣旨の注記が付いているとPPC Landは報じています。属性の追加が会話型のインターフェースを名指しで想定している、という点が重要です。
供給経路はフィードだけではありません。ShopifyはStorefront MCPを提供し、任意のAIアシスタントがストアのカタログ、カート、ポリシーへ直接接続できるようにしています。フィードを渡す先が増えたというより、商品データがそのまま外部のエージェントに読まれる経路が増えた、と捉えるべきでしょう。
| 供給先 | 受け渡しの形式 | 特に効くとされる項目 |
|---|---|---|
| Google Merchant Center | 商品フィード（属性ベース） | GTINなどの識別子、color / size / material などのバリアント属性、会話型体験向けに追加された popularity rank・question and answer・related product |
| OpenAI（ChatGPTの商品フィード） | UTF-8のTSV / CSVアップロード、またはAPI。Google互換フォーマットも受け付ける | id・title・description・link・image_link などの必須項目、親商品IDと購入単位IDの分離、variant_options |
| Shopify Storefront MCP | MCPサーバー経由でカタログ・カート・ポリシーへ接続 | 商品検索とカート操作にそのまま使える構造化された商品情報 |
| 自社サイト（AIクローラー） | schema.org Product構造化データ | 価格・在庫・レビュー・評価。フィード側の値と食い違わないこと |
これらを並べると、Catalog Intelligenceが謳う機能は独自の発明というより、各プラットフォームが個別に出してきた要件を1本にまとめて代行する、という性格のものだと分かります。
「スコア」という商品を、どう受け止めるか
AI可視性を数値化して売るプレイヤーは、この1年で急増しました。だからこそ、スコアという形式そのものに付きまとう限界を先に押さえておく必要があります。
もっとも根本的な問題は、LLMの出力が確率的である点です。LLM可視性トラッキングツールの比較記事でも指摘されているとおり、同じプロンプトでも回答は毎回同じにはならず、プロンプトの言い回し、モデルのバージョン、その時点のコンテンツ環境によって結果が変わります。1回のスナップショットは信頼性が低く、同一プロンプトを反復サンプリングして初めて統計的に安定した像が得られます。加えて、あるツールはライブセッションを追い、別のツールは合成プロンプトを使う。測り方が違えば、同じブランドに対して大きく異なる数字が出ます。
したがって、無償スナップショットで出た数値を絶対値として受け取るのは適切ではありません。使い道があるとすれば、自社の改善前後の相対比較か、どの項目が欠けているかという定性的な指摘のほうです。
もうひとつ、この領域に既存プレイヤーがいることも見落とせません。SalsifyやAkeneo、Syndigoといった商品情報管理（PIM）ベンダーは、それぞれ商品データのAI対応を打ち出しています。Akeneoは2026年春のリリースで、実世界のシグナルに基づいて商品データを継続的に改善する仕組みを導入したとされます。カタログ整備という機能単体で見れば、Fanplayrの提案は競合の多い市場に入っていくことになります。差別化の軸は、同社が元来持つ行動データとパーソナライズの基盤とどう組み合わさるか、という点になるはずです。
どこから手を付けるか
自社で先に潰せる部分から順に見ていくと、優先順位はおおむねはっきりします。
最初に確認すべきは識別子です。GTINは主要な照合シグナルであり、欠落や誤りがあると複数小売業者の商品が束ねられるクラスタから外れます。ここが崩れていると、後段の属性をいくら足しても効きません。
次がバリアント構造です。親商品と購入単位の分離、色やサイズの選択軸の明示、バリアントごとに異なる価格や在庫の反映。前述のとおり、OpenAIとGoogleの双方が同じ形を求めています。
カテゴリ固有の属性と、用途や対象者のシグナルはその次です。会話型の検索クエリは従来の検索より長く、質問文に近い形になります。「誰向けで、どういう場面で使うのか」という情報がデータ側に無ければ、そうしたクエリには当たりません。
最後に、フィードの値と自社サイトのschema.org Product構造化データが食い違っていないかを確認します。両者が矛盾していると、どちらの信頼度も下がる方向に働きます。診断ツールを使うかどうかにかかわらず、この順番は変わりません。
まとめ
Catalog Intelligenceの発表そのものは、ベンダー1社の新製品リリースです。ただしその裏側にある構図は、もっと広い範囲に共通しています。商品データは長らく、人間が見る商品ページを作るための材料でした。それが今、機械に読ませて推薦させるための入力に変わりつつあります。
診断スコアが乱立する段階は、おそらくもうしばらく続きます。数字の出所と測り方を確かめる手間は、当面どのツールを使っても必要でしょう。一方で、識別子とバリアント構造とカテゴリ属性を整えるという作業は、どのスコアが正しかったとしても無駄になりません。まずはそこからです。
