競合他社の価格を追跡する方法：スプレッドシートから完全自動化まで、6つの手法

はじめに

価格設定に関するあらゆる決定は、競合他社がどの程度の価格を設定しているかという賭けに他なりません。多くの小売業者は、古くなった情報に基づいてその賭けを行っています。

問題は、価格追跡が難しいということではありません。競合他社の商品ページを開くのにかかる時間は10秒程度です。問題は、その作業がスケールしないことです。

10社の競合サイトから50商品を追跡している小売業者は、500個のデータポイントを管理していることになります。1回の確認に約30秒かかるとすると、1日1回の完全なチェックには4時間以上の作業時間がかかり、しかもそれは誰かが実際に価格決定を行う前の段階での話です。

だからこそ、手動によるモニタリングは、通常、誰にも気づかれることなく、少数の候補リストを超える段階で静かに破綻してしまうのです。スプレッドシートの更新が単に止まってしまうのです。

このガイドでは、今日の午後にも作成できるスプレッドシートから完全自動化されたモニタリングまで、競合他社の価格を追跡する6つの方法について解説します。

これらは品質ではなく、労力と網羅性の順に並べられています。適切な方法は、販売する商品の数や市場の変動の速さによって異なります。

手法を選ぶ前に：実際に何を追跡するのかを明確にしましょう

このステップを省略することが、価格追跡プロジェクトが頓挫する最も一般的な理由です。順を追って4つの決定事項を挙げます：

どの競合他社か。あなたのカテゴリーを販売しているすべての業者ではありません。顧客が実際に比較検討している3～8社の小売業者に加え、自社ブランドの検索結果に表示されるマーケットプレイスの出品者を含めます。30社の競合他社リストを作成しても、そのいずれについても十分に追跡することはできません。

どの商品を追跡するか。売上は均等に分散しているわけではないため、モニタリングも同様に均等に行うべきではありません。利益率を牽引する商品、顧客が最も価格を比較する商品、そして最近、明らかな理由なく売上を失った商品から始めましょう。

どの属性か。価格だけを見ると誤解を招きます。5％安くても在庫切れの競合他社は、価格競争で勝っているわけではありません。むしろ、顧客を自社に送り込んでいるのです。少なくとも価格、在庫状況、配送料を把握してください。購入を決定づけるのは、最終的な総コストだからです。

頻度は？　ほとんどの商品カタログでは、毎日が妥当なデフォルト設定です。1時間ごとの更新が重要なのは、売れ行きの速いマーケットプレイスの出品に限られます。売れ行きの鈍いカテゴリーでは週次で十分であり、実際に収集できる週次データは、誰も収集していない理想論的な日次データよりもはるかに有用です。

ツールを1つでも評価する前に、これら4つの答えを書き出しておきましょう。これらが、以下のどの方法が自社にとって現実的かを決定づけるからです。

方法1：構造化されたスプレッドシートでの手動チェック

出発点であり、小規模なカタログにとっては真に正しい答えです。

商品ごとに1行、競合他社ごとに1列を作成し、最初の列に自社の価格を入力します。日付列と在庫列も追加しましょう。これらは、多くの人が省略してしまい、後で「入れておけばよかった」と後悔する2つの項目です。

毎日決まった時間に確認してください。価格は日中に変動するため、月曜日の朝の数値と金曜日の夕方の数値を比較しても、全く意味がありません。

2つの工夫を加えることで、手動での追跡は格段に有用になります：

• 価格だけでなく、その差も記録しましょう。最安値の競合他社の価格に対する自社の価格の割合を算出した列があれば、数字の壁を並べ替えや行動に活かせる情報に変えることができます。
• 履歴は残しておきましょう。先週の数値を上書きしないでください。シートをコピーするか、行を追加してください。単一のスナップショットは現在の状況を教えてくれますが、一連のデータは、どの競合他社が、どの程度、どのくらいの頻度で値引きを行っているかを明らかにします。

現実的な上限：3～4社の競合他社を対象に、約20～30商品を週1回確認する。これを超えると、前述の計算式が適用される。

方法2：価格アラートと変動検知

スケジュールに従ってページを確認する代わりに、ページを監視し、数値が変化した際に通知してくれる仕組みを導入しましょう。

Visualpingのような汎用的なWebサイト変更検知サービスは、URLを監視し、ページの内容が異なった際に通知してくれます。ブラウザ拡張機能や価格履歴トラッカーも、主要なマーケットプレイスに対して同様の機能を提供します。設定は数分で完了し、多くの場合、費用はかかりません。

これは、競合他社の動きに対して即日対応が求められる、少数の重要な商品を監視するという特定の用途には最適です。

それ以外の用途には不向きです。通知は届きますが、データは得られません。分析できる履歴もなく、カタログ全体を俯瞰することもできず、「先月、当社のカテゴリーに何が起きたのか」という問いにも答えられません。

監視対象のページが数ページを超えると、アラート疲れが生じます。そうなると、メールを無視し始め、事実上、監視を全く行っていない状態に戻ってしまいます。

活用方法：他の手法の補完として利用し、決してメインのシステムとしては使用しないでください。

方法3：すでに手元にある無料の競合データ

この方法は一貫して十分に活用されていません。主要なプラットフォームで広告を出稿したり販売を行ったりしている場合、おそらく一度も開いたことのない競合価格に関するシグナルをすでに手元に持っているはずです。

Google Merchant Centerには、すでに送信済みの商品フィードを用いて、同じ商品を広告掲載している他の小売業者との価格競争力を比較するレポート機能が含まれています。

マーケットプレイスの販売者ダッシュボードにも、同様の指標が表示されます。具体的には、バイボックスの競争力、注目オファーの価格、同じ出品ページ上の競合オファーに応じて反応する自動価格設定ルールなどです。

ただし、これが何であるかを明確に理解しておく必要があります。完全な解決策だと誤解されがちだからです。

これは「体温計」であって、「診断」ではありません。単に「体温がやや高い」ことを知らせるだけで、その原因や対処法までは教えてくれません。

具体的には、このデータからは以下の情報は得られません：

• 競合他社ごとの詳細。ベンチマークより8％高いという事実がわかるだけで、どの小売業者がどの商品で自社より安く販売しているかはわかりません。
• 独立系ウェブショップの網羅性。現在利用しているプラットフォームしか把握できず、実際の競合他社の多くは他の場所で販売しています。
• そのプラットフォームに掲載していない商品のカバー範囲。そのチャネル外の商品は一切把握できません。
• 実用的な履歴データ、アラート機能、在庫や配送状況に関するコンテキスト。
• 小売業者ではなくブランドの場合、MAP（最低広告価格）の可視性が全くない。

活用方法：モニタリング体制が整っていない場合の、無料の現状確認ツールとして活用してください。何もしないよりは明らかに優れており、問題が実際に存在することを社内で証明する最も手っ取り早い手段となる場合が多いです。

しかし、このデータでは、その目的のために構築されたツールが持つ詳細な分析能力には代えられません。具体的には、関心のある特定の製品について、独立系ウェブショップやマーケットプレイスを横断して競合他社ごとの価格を、履歴、在庫状況、アラート機能とともに把握できるようなツールです。

プラットフォームのレポートは「何かがおかしい」ことを教えてくれます。Altosightのような専用ツールは、「何が」「どこで」「どの程度」問題なのかを具体的に示してくれます。

何も持っていない場合はここから始めましょう。ただし、ベンチマークを全体像と混同しないようにしてください。

方法4：半自動のスプレッドシート

Sheetsに慣れている人にとって、自然な次のステップは、スプレッドシート自体に価格を取得させることです。

Google Sheetsでは、IMPORTXML関数を使用してページからデータを取得でき、XPath式を用いて価格要素を指定することができます：

=IMPORTXML(“https://competitor.com/product-page”, “//span[@class=‘price’]”)

これに丸一日を費やす前に、期待値を明確にしておきましょう。現代のECサイトでは、うまくいくよりも失敗するケースの方が多いでしょう。

現在のほとんどのECサイトでは、最初のページ読み込み後にブラウザ上で価格が表示されるようになっており、IMPORTXMLは最初に到着した生のHTMLしか認識しないため、セルは空のまま返されてしまいます。

この手法を基に何かを構築する前に、実際の競合他社のURLを10件ほどテストしてみてください。そのうち3件で価格が返ってくれば、それは正常な結果です。

その他の失敗パターンも同様に重要です：

• サイトのリデザインにより、あらゆる計算式が黙って破綻します。CSSクラスの変更により、価格欄がエラー表示になったり、さらに悪い場合には、誰も気づかないまま古い数値が残されたりすることがあります。
• ボット対策が一切行われていません。1つのソースからの繰り返される自動リクエストは、レート制限をかけられたりブロックされたりしますが、その処理はしばしば断続的であり、明らかな障害ではなく、データに空白が生じる結果となります。
• 動作が停止したことを知らせるものは何もない。手動のシートは更新が停止すると明らかに放置されていることがわかるが、自動更新のシートが静かに更新を停止しても、依然として信頼できる情報のように見え、人々はそれに基づいて価格設定を行う。

現実的な上限：単純で静的な商品ページが適度な数あり、数式が壊れるたびに修正してくれる人がいてくれる場合。実験としては有用ですが、インフラとしては脆弱です。

方法5：独自のスクレイパーを構築する

エンジニアリングリソースがあれば、まさに理想通りのものを構築できます。つまり、スケジュールに従って競合他社のページを取得し、価格と在庫情報を解析して、独自のデータベースに書き込むスクリプトです。

静的なページであれば、これは実に単純で、Pythonで数十行程度ですむでしょう。難しさは、その周辺のすべてにあります：

• ブラウザ内でコンテンツを生成するページのレンダリング
• 適切な市場を比較できるよう、地域ターゲティング、通貨、ロケールのバリエーションを処理する
• リクエストを適切にローテーションさせ、ボット対策に耐える
• 失敗時の再試行、「価格が利用不可」と「スクレイパーの不具合」の区別
• 生データに基づくスケジューリング、保存、アラート、レポート作成

これらを個別に考えれば難しいことではありません。しかし、それらを組み合わせると、単なるスクリプトではなく、一つの「製品」となります。

真のコストは構築ではなく、メンテナンスにあります。競合他社がページデザインを変更するたびにパーサーは機能しなくなり、しかもその不具合は黙って発生します。チームは往々にして、このコストを桁違いに過小評価してしまいます。

適しているケース：余剰のエンジニアリングリソースがある場合、ベンダーが対応していない特殊なデータソースがある場合、あるいは生データを自社システム内に保持するという厳格な要件がある場合。

手法 6：専用の価格監視プラットフォーム

カタログの規模が一定以上になると、問題は「どうやってこれらの価格を取得するか」から、「誰かを雇って監視させずに、何千もの比較データを正確に維持するにはどうすればよいか」へと変わります。そこが、専用ソフトウェアのコストに見合う価値が生まれるポイントです。

支払っている対価は、単なるスクレイピングそのものではありません。クロールインフラ、商品マッチング、正規化、価格履歴、アラート機能、そしてその後の処理（再価格設定ルール、実行ワークフロー、購買チーム向けのレポートなど）への連携機能に対する対価なのです。

まず、1つの質問から始めましょう。「URLを指定するのはあなたですか、それともツールが商品を検索するのですか？」

これは最初に確認すべき点であり、最も見落とされがちな点です。

URLベースのモニタリングとは、比較したいたびに競合他社の商品URLを貼り付けることを意味します。これは正確ですが、設定作業はユーザー自身が行う必要があり、競合他社がURLを変更すると機能しなくなります。

チャネルベースのモニタリングとは、競合他社のサイトやマーケットプレイスを指定すると、プラットフォームがそのサイト上で自社製品を自動的に検出して照合する方式です。これは、大規模なカタログ全体を通じて管理可能な唯一のアプローチです。

ハイブリッド型は両方を組み合わせたもので、優れたプラットフォームはすべてのモデルに対応しており、精度が重要な箇所では正確なURLを指定し、それ以外の箇所ではプラットフォームに商品検出を任せることができます。

競合他社の価格モニタリング用に候補に挙げたツールがどれであれ、トライアルを開始する前に、そのツールが3つのモデルのうちどれを採用しているかを確認してください。その答えによって、継続的な設定作業の負担がベンダー側ではなく、自社チームにどれだけかかるかが決まります。

その後、残りの作業を進めてください

• あらゆるウェブサイトを追跡できるのか、それともマーケットプレイスに限られるのか？ 多くのツールは大手マーケットプレイスにはうまく対応できるものの、独立系オンラインショップには不向きです。競合他社にはおそらくその両方が含まれているでしょう。
• 識別子がない商品をどのように照合するのか？次のセクションを参照してください。これは最も重要な質問であり、最も見過ごされがちな点でもあります。
• どの国と通貨に対応していますか？ 越境販売を行っている場合、単一の市場を前提としたモニタリングは、モニタリングとは言えません。
• データをエクスポートできますか？APIと整理されたエクスポート機能の有無が、そのツールが価格設定プロセスに統合されるか、あるいは誰も開かないもう一つのダッシュボードになってしまうかを決定します。
• データを使って実際に実施している業務をサポートしていますか？小売業者であれば、厳格なマージン下限を設定した自動価格改定。ブランド側でMAP（最低販売価格）を適用している場合は、違反の検出と記録機能が必要です。

誰もが過小評価しがちな部分：商品マッチング

上記のどの手法も、どの競合他社のページが自社のどの製品に対応しているかを、すでに把握していることを前提としています。実際には、この前提こそが価格追跡を機能不全に陥らせる原因となります。

同じ製品でも、小売業者によって異なる商品名、異なるセット構成、異なるバリエーション構造で掲載されることがあります。識別子が欠落していたり、間違っていたり、再利用されていたりします。

ある小売業者は単品を販売し、別の業者は2個セットを販売し、さらに別の業者はアクセサリーを同梱しています。信頼できる識別子がなければ、価格を比較する前に、掲載商品の相当な割合について曖昧さを解消する必要があります。

だからこそ、この作業を「500件のURLをまとめたスプレッドシート」と表現するのは誤解を招くのです。500件の価格を取得するのは、作業の簡単な半分に過ぎません。

その500件の価格が、想定通りの商品に対応していることを確認し、競合他社がカタログの構成を変更してもその整合性を維持し続けることこそが、時間を要する部分なのです。

また、これが、マッチングの精度とその検証方法が、あらゆる自動化手法の評価において最優先されるべき理由でもあります。

実際にどのくらいの頻度でチェックすべきでしょうか？

ほとんどのカタログには、毎日のモニタリングが適しています。競合他社のオファーが1日に数回変わるような、動きの速いマーケットプレイスの出品や、誤りが大きな損失につながる少数の商品については、頻度を増やす必要があります。

繁忙期については別途計画を立ててください。夏場に快適だと感じる頻度でも、ブラックフライデーの週になると遅く感じられるでしょう。この時期、競合他社は1日の中で価格を変更するため、1日1回のスナップショットではその動きを完全に見逃してしまいます。

モニタリングの頻度を年に1回だけ更新するのであれば、10月に行うようにしましょう。

データの活用法と避けるべきこと

競合他社の価格追跡において最もコストのかかる過ちは、観測された最低価格を「指針」として扱うことです。

競合他社の値下げのうち、かなりの割合は在庫一掃セールやフィードのエラー、あるいは単なるミスによるものです。自動化された無差別な価格追従は、こうしたミスを数時間のうちに市場全体に広めてしまい、ある小売業者の入力ミスの代償を、すべての業者の利益率が負担することになります。

いかなる自動対応にも、価格の下限設定、マージンルール、そして不自然な値下げを追いかけるのではなく無視する妥当性チェックといった「ガードレール」が必要です。

また、「常に最安でなければならない」という前提についても検証する価値があります。在庫状況、配送速度、信頼性は、わずかな価格差よりも重要視されることが多く、「何としても最安」という戦略は、デフォルトの設定というよりは、純粋なコモディティ製品向けの戦略です。

適切なモニタリングは、次の3つの問いに答えられるべきです：

• どの市場で価格競争力に欠けているのか？
• どこで利益を逃しているのか？
• 今週、知っておくべき変化は何か？

もし現在の設定でこれら3つの問いに答えられないのであれば、データを増やしても意味がありません。

どの手法が適しているか

状況	以下の条件から始めます
30品目未満、競合他社が少ない	体系化されたスプレッドシート（方法1）
注視すべき重要な製品が数点	変更検知アラート（方法2）
主要プラットフォームですでに広告掲載または販売中	無料のプラットフォームレポート（手法3）
シンプルな商品ページが数ページあり、予算がない場合	半自動のスプレッドシート（方法4）
特殊なデータソースと余剰なエンジニアリングリソースがある場合	カスタムスクレイパー（方法5）
数百の商品、または識別子なしでのマッチング	専用プラットフォーム（方法6）

ほとんどの小売業者はこのリストの順に段階を踏んで進みますが、それ自体に何の問題もありません。

失敗の原因は、規模が小さすぎる状態で始めることではありません。信頼できる数値を出さなくなってからずっとその手法に固執し、それに基づいて価格設定を続けてしまうことです。