「おすすめの冷蔵庫は」「この条件で買える店は」と生成AIへ尋ねると、もっともらしい候補が並びます。
しかし、一度表示された順位を「AIでの自社順位」と呼ぶのは危険です。
別のサービス、別の質問、翌日の実行では候補も理由も変わり得ます。
Stellagentが2026年7月に公表した冷蔵庫購入相談の調査は、ChatGPT、Gemini、Claude、Perplexity、Microsoft Copilotの5サービスに、6シナリオを各5回尋ね、150回答を集計しました。
同社は洗濯機でも同様の調査を行い、カテゴリーによって結果が異なりました。
これは有用な事例ですが、一時点、一カテゴリーの結果を市場全体へ広げることはできません。
企業が見るべきなのは、固定順位より「どの条件で自社が現れ、なぜ薦められ、何が誤って伝わったか」です。
本稿では、小規模でも再現しやすい5サービス×3シナリオ×5回、計75回答の検証手順を作ります。
回答が変わる理由は、生成の揺らぎだけではありません。
サービスが使うモデル、Web検索の有無、商品データ、更新時刻、利用地域、言語、ログイン履歴、過去の会話が異なります。
OpenAIのShopping Researchは複数ソースを調べ、条件を対話的に絞る仕組みを案内する一方、価格や在庫に誤りがあり得るため販売店ページを最終確認先としています。
Googleは検索やGeminiをまたぐショッピング体験と、加盟店の商品データを使う仕組みを拡張しています。
ClaudeのWeb検索も現在情報と出典を扱いますが、設定や提供条件が回答へ影響します。
したがって、表面上は同じ「おすすめ」でも、候補を作る過程は同じではありません。
同じサービス内でも、質問が「価格重視」「省スペース」「長期保証」「今日受け取りたい」に変われば評価軸が変わります。
モデル更新や検索インデックスの変化もあるため、調査結果には実施日時を付けます。
.png)
「AIはA社を1位にする」と一般化せず、「この条件、この期間、この実行回でA社が何回現れた」と記録します。
最初に検証票を作り、サービス名、画面に表示されたモデル名、検索・ショッピングモード、ログイン状態、言語、地域、実施日時、新規会話かどうかを残します。
履歴やパーソナライズを切れる場合は切り、各回を新しい会話で始めます。切れない場合は、その状態を条件として明記します。
質問文はサービス間で同一にします。
途中で追加質問をしたら、その文面と順序も保存します。
回答の改善を狙ってサービスごとに質問を変えると、サービス差とプロンプト差を分けられません。
まず共通条件で基準値を取り、次の実験で質問設計を変えます。
価格、在庫、送料、提供地域は変動しやすいため、回答に出た値を当日の公式商品ページで確認します。
販売終了品や存在しない型番、古い料金も誤情報として記録します。正しい候補数だけでなく、購入判断を誤らせる種類を区別することが大切です。
実務の最小構成は、5サービス、3シナリオ、各5回です。
サービスは自社顧客が使いそうなものを選び、実行時点の名称を記録します。
シナリオは「目的」「予算」「制約」を変えます。たとえば、最安重視、品質と保証重視、今日入手したい、という三つです。
.png)
一つのシナリオには条件を詰め込みすぎません。
対象地域、商品カテゴリー、予算、必須条件を2〜4個にします。
候補を3件挙げ、推薦理由、価格または価格帯、参照元、確認すべき注意点を示すよう求めます。
回答形式をそろえると集計しやすくなります。
5回の反復は、揺らぎを見るための最低線です。
差が小さい、重要カテゴリーである、更新直後である場合は10〜20回へ増やします。
n=5の1位率100％も、長期的な確定順位ではありません。
調査日は一日または短期間にそろえ、月次や四半期で同じ条件を再実行します。
Stellagentの150回答調査は、5サービス×6シナリオ×5回でした。
本稿の75回答は運用負荷を下げた設計であり、結果の精度を同等とみなすものではありません。
重要な判断ほど反復数とシナリオ数を増やしてください。
1回答ごとに候補順位、推薦理由、参照元、価格・在庫・仕様の誤り、追加質問を記録します。
自社名の表記揺れは統一しますが、別会社や別商品を誤認した回答は統合しません。
元の回答全文とスクリーンショットまたはURLも、利用規約と社内方針の範囲で保存します。
以下の表を1行1候補で埋めると、出現率と理由を後から集計できます。
基本指標は、出現率＝自社が現れた回答数÷全回答数、1位率＝自社が1位だった回答数÷全回答数です。
これに推薦理由の構成比、誤情報率、公式情報が参照された割合を加えます。
候補を点数化する場合も、順位点だけで優劣を固定せず、シナリオ別に分けます。
「価格で薦められるが、保証では出ない」「出現率は高いが古い在庫情報を伴う」と分かれば、施策が具体化します。
総合点一つにまとめると、何を直すべきかが消えます。
サービス間の差は、品質の断定ではなく、観測条件ごとの違いとして扱います。
推薦理由を確認し、自社の強みが公式ページに明記されていないなら、商品ページ、FAQ、比較ページを直します。
.png)
価格、在庫、仕様は機械で取得しやすい形へ整理し、更新日を示します。
誤解が第三者記事から広がっている場合は、一次情報を明確にして訂正を依頼します。
自社を過剰に持ち上げる説明を量産しても、信頼できる推薦にはつながりません。対象者、向かない条件、追加費用、制約も示します。
AIの回答だけでなく、顧客が公式ページへ到達した後に正しく判断できる情報を優先します。
改善後は、同じ5サービス、同じ3シナリオ、同じ回数で再テストします。
実施日と表示モデルは更新し、前回との差がコンテンツ改善によるものか、サービス更新によるものかを分けて考えます。
一回の上昇を成果と断定せず、2〜3回の定期観測で再現を見る方が安全です。
大量の自動テストを行う前に、各サービスの利用規約、レート制限、APIの提供条件を確認します。
消費者向け画面を無断でスクレイピングせず、規模を広げる場合は公式APIや認められた手段を使います。
個人アカウントの履歴や顧客情報を検証入力へ混ぜないことも必要です。
生成AIの商品推薦は、一回の質問で測れる固定順位ではありません。
サービス、検索モード、地域、履歴、質問、実行日時を記録し、複数回の回答を集めて初めて傾向が見えます。
まず5サービス×3シナリオ×5回の75回答から始め、出現率、1位率、推薦理由、誤情報、参照元を分けてください。
見つかった不足を商品ページやFAQへ反映し、同じ条件で再テストします。
順位を追いかけるより、選ばれる理由と誤解の原因を直す方が、顧客にも長期の情報品質にも役立ちます。
.png){kind=logo}
