この記事では、競合他社の公開商品情報を集めて比較可能な表を作るための手順を解説します。
マーケティング担当者が自社商品と競合商品を比較する際、各社の商品ページや公式仕様書における表記揺れ、前提条件の違いが課題となります。価格に送料が含まれているか、仕様の測定条件や単位は揃っているかなど、基準を揃えずに比較すると誤った結論を導く危険があります。
公開された商品情報を共通の列へ揃えれば、価格条件や仕様の違いを自社商品と具体的に比べられます。まずは取得元と時点を追える比較表を作り、広告や企画に使う差分を見つけます。
ここでは、商品ID・名称・価格・在庫・仕様などの情報を、共通のルールで一つの表へ整理する6つのステップを示します。情報が存在しない場合の欠測の扱い方や、色やサイズといったバリエーションをどのように分割して記録するかという実務上の注意点も定義します。
この記事の手順に沿うことで、前提条件の揃った正確な商品比較表を作成し、そこから得られた客観的な差分を、今後の追加調査や事実に基づいたマーケティング施策の仮説構築に役立てられます。
競合カタログ分析は商品の優劣ではなく比較可能な表を作る
競合商品の情報を集め自社商品と比較することはマーケティング担当者にとって重要な業務ですが、取得した情報をそのまま並べるだけでは正確な比較は困難です。競合カタログ分析の目的は、商品の優劣を直感的に判断することではなく、客観的な事実に基づき、各社で異なるフォーマットで提供されている情報を共通の基準で比較可能な表へ整理することにあります。
この記事では、公開された商品ページ、商品データフィード、公式の仕様情報などを入力元としてカタログを比較する方法を解説します。具体的には、商品ID・商品名・ブランド・価格・在庫状況・商品状態を共通の表へ揃えます。詳細な仕様・バリエーション・URL・情報の取得日時も整理する手順を追います。
特定の業界を決める前でも、価格、在庫、仕様の原文と比較用の値を分ける設計は共通です。読者は自社の対象カテゴリを決めたうえで、後続の手順を商品ページやデータフィードに適用できます。
比較表を作る過程で最も注意すべき点は、情報の欠落に対する取り扱いです。競合他社の商品ページや仕様一覧表を確認した際、特定の項目に関する記述が見当たらない事態は頻繁に発生します。このとき、公開されているページ上に情報が記載されていないという事実のみをもって、その商品には特定の機能がない、あるいはその商品の販売がすでに終了していると断定してはいけません。
Webサイト上の情報は様々な要因で表示が変化します。単に仕様表の項目から省略されている非表示の状態をはじめ、閲覧している地域による情報の表示差、会員としてログインした際のみ公開される情報などがあります。
さらに、色やサイズなどのバリエーションを選択して初めてJavaScriptによって動的に取得されるデータや、期間限定でのみ公開されるキャンペーン情報など、記載が見当たらない理由は多岐にわたります。
そのため、比較表を構築する際はデータの不在をひとくくりにせず、状態を正確に分類して記録する必要があります。公開ページに記載がないのか、ページ構成や技術的な都合で取得に失敗したのか、当該カテゴリでは該当しないのか、非公表と明記されているのかを区別します。
欠測、取得失敗、該当なし、非公表といった分類を明確に設けることで、誤った前提に基づく比較や不適切な分析を防ぐことができます。
取得できた値と欠測理由を分けて記録すれば、競合商品のどこに価格差や仕様差があるかを、元ページへ戻って確かめられます。その比較結果から、追加調査する商品を選びます。
商品ID・価格・在庫・仕様を共通スキーマへ揃える
競合各社の公開情報を比較表としてまとめるには、データ形式が異なる各サイトの情報を共通の列定義、すなわちスキーマへ揃える作業が必要になります。
このスキーマを設計する際、Google Merchant Center商品データ仕様やGoogle Merchant Center詳細商品データ仕様、商品属性と値の送信方法といった商品データ仕様が列名の参考になります。
比較の軸となる商品IDについては、取得元のサイトで使われている固有の商品IDと、自社の比較表で管理するためのIDを別々の列に分けて記録します。各社のID体系が一致することはなく、そのままでは商品を突き合わせることができないためです。GTINがサイト上で公開されていれば、共通商品を見つけるための有力な照合候補になります。
しかし、GTINの記載がない商品を同一商品または別商品として自動判定することは避けます。最終的にはブランド・メーカー型番・容量・色・サイズ・パッケージ数などを組み合わせ、人が商品ページを見て同一性を確認します。
商品名や説明文、仕様の項目は、ウェブサイト上の表記をそのまま保存する原文の列と、比較計算用に整えた正規化値の列を必ず分けます。「500 ml」と「0.5 L」のような表記ゆれを揃える単位換算を行う際は、元の記述と換算式を残しておきます。
仕様の値に「約」や「最大」といった範囲指定、あるいは測定条件が付記されている場合、そこから数値だけを抜き出して比較すると実態を見誤ります。原文、正規化値、単位、条件、情報取得日時をひとつの組として管理します。
価格を記録する際は、単に表示されている金額の数字だけを取り出さず、価格条件を細分化して列に定義します。
ローカル商品データ仕様がオンライン商品と店舗在庫の扱いを分けているように、販売経路や条件には多様なパターンがあります。
通貨、税込と税別、通常価格とセール価格を明確に分けます。会員限定価格・対象数量・送料・対象地域・取得時刻も別項目にします。セール価格には適用期間が存在することが多いため、通常価格の列を上書きしないように記録します。送料や内容量が異なる商品を、表示価格だけで安いと結論づけてはなりません。
単位価格を計算して比較する際も分母を揃えることは有効だが、セット内容や利用回数が異なる商品を単位価格だけで同等とみなすことは避けます。
在庫状況の記録も同様に、「在庫あり」「在庫なし」「予約」「取り寄せ」といったサイト上の表示状態を原文で残します。これが全国共通のオンライン在庫なのか、特定店舗の在庫なのか、あるいは指定した配送先に対する在庫なのかを区別します。一度情報を取りに行ったタイミングで在庫なしと表示されていたからといって、それを恒常的な販売終了として扱いません。
定期的に競合カタログを観測する場合は、過去の値を上書きして消すのではなく、スナップショットとして行を追記していくことで時点ごとの変化を記録します。
一行一SKUでバリエーションと仕様を分ける
競合カタログを比較表にまとめる際、公開されている商品ページひとつにつき一行のデータを割り当ててしまうと、後続の分析で正確な比較ができなくなることがあります。これを避けるため、比較表の最小単位を単一の商品ページ単位とするのではなく、在庫管理の最小単位であるSKUに揃えることが重要です。
アパレル製品や家具、日用雑貨などでは、ひとつの商品ページ内に複数の色やサイズ、容量の選択肢が存在することが一般的です。これらの選択肢は、ブランド名や共通の説明文などを引き継ぐ親商品に対して、個別の属性を持つバリエーションとして展開されています。
もし商品ページ単位でデータを無理に一行へまとめようとすると、特定の色の最安価格と、別のサイズの最大重量といった、本来は別々のバリエーションが持つ仕様を同じ行に混在させてしまう危険があります。
GoogleのMerchant Center商品ファイル作成ガイドでも、ファイル形式とともに、必須属性や標準化された値の扱いが示されています。
色やサイズが異なる商品を扱う際には、バリエーションを結びつける親商品のIDと、個別のSKUを明確に分けて管理します。競合情報の比較表でも、親商品・SKU・色・サイズ・容量などの属性を分けます。価格や在庫がバリエーションごとに変わる場合は、一行一SKUとなるよう行を分割して記録します。
商品情報をウェブ上から取得する際は、商品ページに埋め込まれた構造化データと、画面にレンダリングされる表示内容をそれぞれ照合します。
Googleは対応する構造化データ属性において、商品ランディングページの構造化データとMerchant Center属性の対応関係を説明しています。
一方で、schema.orgですべての属性がサポートされるわけではないことも記載しています。そのため、ソースコード上の構造化データだけを基準にはしません。実際の表示ページとJSON-LDを照合し、入手できる場合は商品フィードとも比べます。情報に差があれば記録へ残します。
さらに、商品ごとに異なる複雑な機能や材質、成分などの仕様情報は、主となる比較表の列へ無理に押し込まずに整理します。
Googleの商品詳細属性の考え方では、セクション名、属性名、属性値という構造を用いて任意の追加仕様を表現します。
競合情報の比較でも、カテゴリ固有の仕様を共通の列へ横並びには増やしません。仕様名・仕様値・単位・測定条件をセットにした縦持ちの仕様明細へ切り出します。
親商品とバリエーションの関係性を一行一SKUへ分解し、細かな仕様明細を縦持ちの表へと分離することで、データの整合性が保たれます。最終的にマーケティング担当者が広告や追加調査の根拠となる比較表として書き出す際に、必要な共通項目だけを横持ちの表へと変換することで、破綻のない確実なデータ照合が可能になります。
比較結果を広告へ使う前に根拠と調査方法を確認する
作成した競合カタログ比較表を広告で利用する場合、景品表示法における規制の境界を理解する必要があります。消費者庁は競争事業者との比較自体を禁止していませんが、自社商品が著しく優良または有利と誤認される表示は不当表示として規制します。
消費者庁 比較広告の解説にある通り、比較広告を行う際には守るべき基本要件が存在します。
第一に、比較広告における主張内容は客観的に実証されている必要があります。第二に、実証された数値や事実を正確かつ適正に引用しなければなりません。これらに加えて比較方法が公正であることが求められます。
比較広告に関する景品表示法上の考え方では、これらの要件についての基準が示されています。
一時点の価格差を恒常的に最安と表現することや、競合ページの仕様欄に記載がないだけの欠測状態を機能なしと断定して比較することは、正確な引用とはいえません。条件が異なる単位価格やセール価格を無条件の通常価格と比較することも不当表示の要因になります。
また調査結果を広告に引用する場合、消費者庁は調査機関、調査時点、調査場所などに関するデータを表示することが適当であるとしています。
消費者庁の資料に沿って、比較対象の商品・対象期間・地域・前提条件・集計方法を明確にします。事例資料のように、原典となるページ情報も記録します。
社内で作成した候補表を広告へ流用する前に、これらの調査前提が広告表現から抜け落ちていないかを確認します。取得日時と広告公開日時に開きがある場合、競合商品の価格や仕様がすでに変更されている可能性も考慮します。
公開情報の収集や比較表の整理にAIを使用した場合、AIが情報整理の過程で最安、最大、最も高機能といった強調表現を生成することがあります。しかし、こうした出力をそのまま広告文へ採用することは避けてください。AIが推論した内容を、取得した元データの範囲外へ一般化してはなりません。比較広告の最終的な表現について責任を持つのは発信者です。
そのため、広告へ利用する前には、広告表現が客観的実証に基づいているか、最新の商品ページや根拠資料と齟齬がないかを、必ず人が確認する手順を組み込みます。
AIを使って公開カタログを6ステップで比較表にする
公開されている商品ページや商品フィードの情報から、再現可能な形で競合カタログの比較表を作成する手順を6つのステップで解説します。
第一のステップは、取得範囲の定義とデータ境界の設定です。比較表の前提を揃えるため、対象カテゴリ・競合サイト・地域・通貨を定めます。情報を取得する日時も固定します。この前提条件が定まっていないと、後から価格や仕様を比較する際に条件の違いによる情報のズレが生じてしまいます。
また、ここでAIに処理させるデータとさせないデータの境界を厳密に設けます。AIへは、ログイン後情報や会員限定価格、個人情報、利用規約で取得が禁止されているデータを送ってはいけません。加えて、AIに直接サイトを操作させたり、公開している比較表へ直接書き込む権限を与えたりすることも避けます。
機密性について、OpenAIが提供するビジネスデータに関する方針にあるように、組織向けプランやAPIの利用では入力と出力が既定でモデル学習に使われませんが、契約や管理設定の確認は利用組織が責任を持って行います。
ClaudeやGemini Appsなど別の組織承認済みAIを使用する場合も、各サービスの契約、保持期間、管理者設定を確認します。
第二のステップは、元データの取得とローカルへの保存です。定義した取得範囲に基づき、各社の商品一覧ページと商品詳細ページへアクセスします。同じ入力で抽出をやり直せるよう、調査対象とするURLのリストをcatalog_urls.csvとして人が用意します。
後から根拠を辿れるように、対象ページのURL・ページタイトル・取得の成否を記録します。取得時点の画面テキストとJSON-LD、公式仕様書などもローカルへ保存します。情報を手元に確保することで、AIへ渡す入力データを固定し、再現性の高い抽出処理が可能になります。
第三のステップは、構造化データを活用したデータの一行一SKUへの分解です。商品の中には色やサイズ、容量の異なるバリエーションが存在します。これらをひとまとめにすると、最安価格と別のサイズの仕様が混在してしまう危険があるため、共通の親商品からバリエーションを切り離し、一行一SKUの表へ展開する必要があります。
この工程で、サイト内の元ID、GTIN、ブランド、メーカー型番といった商品の照合に必要な識別情報を記録します。その際、Webページに埋め込まれたJSON-LDなどの構造化データを確認します。
Google Search Centralの商品バリエーション構造化データは、ProductGroupとProductを分けています。variesBy・hasVariant・productGroupIDを読み分けると、親商品とバリエーションの関係を表せます。
ただし、JSON-LDと実際の画面表示が一致しているとは限らないため、この関係性の構築は仮組みとし、後のステップで矛盾を検証する対象として扱います。
第四のステップは、項目の原文保存と正規化を定義するスキーマの作成です。取得した価格、在庫、仕様は、サイトに表示されていた原文と、比較表用に揃えた正規化値の列に分ける必要があります。価格であれば税込か税別か、セール期間の有無、送料、会員限定条件などを原文として残します。
仕様欄において単位の表記揺れがある場合は単位換算を行い数値を揃えますが、この際も換算前の原文と換算式を記録しておくことが重要です。AIにこの整理と統一フォーマットでの出力を担わせるため、抽出したい列定義をまとめたcatalog_schema.csvを作成します。
列にはsource_url・source_quote・observed_at・parent_product_id・sku・gtinを用意します。価格にはraw_price・price_currency・normalized_priceを使い、availabilityとmissing_reasonも加えて1行1レコードにします。
第五のステップは、AIの入出力の設計と欠測の分類です。情報整理を効率化するため、抽出作業をAIに任せます。たとえばChatGPTを開き、公式のデータ分析機能を用いて処理を実行します。
チャット画面へcatalog_urls.csvと、保存した商品ページ本文をアップロードします。JSON-LD・公式仕様書・catalog_schema.csvも添付します。続いて、以下の依頼文を送信し、Pythonによる変換処理と表のCSV出力を実行させます。
アップロードした商品ページ本文、JSON-LD、公式仕様書のファイルを分析し、catalog_schema.csvの列定義に従って競合カタログの比較表候補を作成してください。以下の条件を厳守してください。
1. 抽出と構造化
・データを一行一SKUに分解してください。
・JSON-LD内のProductGroup、Product、variesBy、hasVariant、productGroupIDを手がかりに、親商品とSKUの関係を整理してください。
・抽出結果は、catalog_schema.csvの列（source_url、source_quote、observed_at、parent_product_id、sku、gtin、raw_price、price_currency、normalized_price、availability、missing_reason）にマッピングしてください。
2. 原文の保持と欠測の扱い
・ページ上に情報がない場合、過去の知識で欠測補完をしないでください。missing_reasonの列へ「非公表」「該当なし」「取得失敗」などを正確に分類してください。
・価格や仕様は正規化しつつ、根拠となる元の文字列をsource_quoteへ残してください。
3. 矛盾の検出
・JSON-LD内のデータと、画面本文のテキストの間に矛盾がある場合は、該当箇所をverification_queue.csvとして別に出力してください。
4. 出力ファイル
・正規化された抽出結果の候補表を competitor_catalog_candidate.csv として出力してください。
・前回のデータがある場合は比較を行い、catalog_diff.csv を出力してください。第六のステップは、人による最終確認と変更履歴の管理です。AIが出力したCSVファイルや表はあくまで候補であり、そのまま公開したり業務利用へ移行したりしてはいけません。人がcompetitor_catalog_candidate.csvとverification_queue.csvを開き、各項目の妥当性を確認します。
商品の同一性と、親商品とSKUの切り分けを人が確認します。価格の前提条件・在庫ステータス・仕様の測定条件も原典のURLや保存ファイルと照合し、画面表示との差がない場合に承認します。この原典確認を終えた確実なデータのみを、更新元の表へ反映します。
また、定点観測を行う場合は過去のデータを上書きしてはいけません。取得頻度と対象範囲を揃えたうえで、日時ごとのスナップショットを追記し、変更履歴として残します。商品追加や在庫の変化、説明文の変更といった変更履歴を事実の手がかりとして蓄積することで、比較表を単なる一覧ではなく、継続的な調査基盤として活用できるようになります。
よくある質問
公開ページに仕様が書かれていない場合はどう扱えばよいですか
公開ページに情報がないからといって、「機能なし」や「販売終了」と断定することは避けてください。会員限定表示、地域による出し分け、期間限定の表示など、情報が見えない理由は多岐にわたります。比較表では「非公表」「欠測」「取得失敗」といった分類を設け、推測で空白を埋めないことが重要です。
AIにデータを処理させる際も、欠測を自動補完させず、そのままの状態を維持して後から人が確認できるようにします。
競合商品より価格が安いことを比較表の結論にできますか
単に表示価格の数字だけを比較して「安い」と結論づけるのは適切ではありません。価格には通貨、税込と税別の違い、通常価格かセール価格かといった条件が含まれます。また、送料、会員限定の割引、内容量や単位の基準が異なる商品を単純比較すると、誤った分析につながります。
価格を比較する際は、適用期間や単位を揃え、条件が異なる場合はそれぞれ別列に記録して、正確な前提条件のもとで確認してください。
自社商品と競合商品を同じ商品として自動で照合できますか
GTINのような商品識別コードが双方に公開されていれば、有力な照合候補になります。しかし、GTINがない商品を自動的に同一商品や別商品と判定することは困難です。
各社の商品ID体系は異なるため、ブランド名・メーカー型番・容量・色・サイズ・パッケージ数などを組み合わせます。最後は人が公開ページを目視し、同一性を判断します。
作成した競合比較表をそのまま比較広告に使ってもよいですか
社内分析用の比較表をそのまま広告へ流用することは推奨されません。
消費者庁は比較広告において、主張内容が客観的に実証されていることや、実証された数値を正確に引用することなどを求めています。
広告として発信する際は、調査機関、調査時点、対象地域などの調査方法に関するデータを明示することが基本です。必ず最新のページや根拠資料を人が確認し、調査時点や条件が適切に示されているか検証してください。
調査手法について
こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。
Screenshot
調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。
また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。
ご利用をご希望の方は、こちらよりお申し込みください。
また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。
市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai
コメント