"毎朝8時に、昨日新たに掲載された競合他社の新商品と売り切れた商品だけをまとめて受け取りたいです。"
要件はこの一文で終わりです。しかし見積もりを取ると、話はしきりに「そのサイトは収集できますか」に流れていきます。
この依頼で難しい部分は収集ではありません。
競合他社の商品一覧は、今も画面にすべて表示されています。ページを開けば見えます。
見えないものは一つだけです。その中で、昨日はなかったものが何かです。
価格は今日の画面に書かれています。新商品と売り切れは、昨日の一覧があって初めて存在します。
そしてこの違いは、そのまま売上につながります。競合他社の新商品を一日でも早く知れば対応のリードタイムが生まれ、競合他社の主力商品が売り切れた瞬間を捉えれば、その需要が自社に流れてくる反射的な利益を狙えます。反対に、自社のベストセラーと競合する商品の再入荷を見逃せば、その窓は静かに閉じます。新商品・売り切れモニタリングは「現状把握」ではなく、対応のタイミングを稼ぐ仕事です。
3行要約 (TL;DR)
- 新商品と売り切れはページから読み取る値ではなく、昨日の一覧と今日の一覧の差分(diff)です。そのため最初に設計すべき対象はクローラーではなく、毎日同じ基準で残す基準スナップショットです。
- 二つ目の難関は、売り切れ表記が標準化されていないことです。売り切れ・一時売り切れ・再入荷通知・オプション単位の売り切れはサイトごとに異なります。何を売り切れとして数えるかを定義しなければ、毎日違う物差しで測った数字が積み上がります。
- 「毎朝」は収集時刻ではなく、到着時刻です。8時到着を望むなら、検証・再試行の時間まで逆算しなければならず、しきい値なしにすべて送れば三週目から誰も開かなくなります。
目次
- 新商品モニタリングと売り切れモニタリングとは
- 昨日の一覧を捨てれば今日の新商品は永遠に見えません
- 売り切れはサイトごとに違う言葉で表現されます
- 毎朝は収集時刻ではなく到着時刻です
- 一日200件出るレポートは三週目から誰も見ません
- 方式別比較表: 人による確認 vs ノーコードツール vs マネージド型
- 開始前セルフチェック5問
- 導入5ステップ
- よくある質問
- 結論
新商品モニタリングと売り切れモニタリングとは
新商品モニタリングとは、競合他社・販売チャネルの商品一覧を定めた周期で収集し、基準時点にはなかった商品が新たに登場したかを自動的に判別する活動です。
売り切れモニタリングとは、同じ商品の販売可能状態を定期的に収集し、販売中 → 売り切れ、売り切れ → 再入荷のように状態が変わった瞬間を捉える活動です。
二つの定義には同じ言葉が入っています。なかった、そして変わった。
価格モニタリングと分かれるポイントはここです。
価格は今日のページ一枚だけで答えが出ます。画面に数字が書かれているからです。
新商品と売り切れは、今日のページだけでは答えが出ません。比較する昨日が必要です。
そのためこの業務は、収集より照合に近いものです。価格側の設計基準はEC価格比較・モニタリング用収集サービス、どう選ぶべきかに別途まとめています。
昨日の一覧を捨てれば今日の新商品は永遠に見えません
基準スナップショットとは、特定時点の商品一覧と状態を丸ごと保存し、次回と比較する基準にするデータです。
照合を機能させるには、三つを固定しなければなりません。
- 識別子 — 何を同じ商品とみなすか（商品ID・URL・商品名+オプション）
- 範囲 — 昨日と今日の収集範囲が同じか
- 時刻 — 毎日同じ時刻に取得されているか
最も多く問題が起きるのは二つ目です。
昨日は一覧3ページ、今日は5ページを収集した場合、レポートには新商品が数十件表示されます。一件も新商品ではないにもかかわらず。
さらに厄介な問題が残っています。初めて見る商品が、すなわち新商品とは限りません。
一覧に初めて登場するケースは、少なくとも四つあります。
- 本当の新商品 — 新たに発売されたもの
- リニューアル再登録 — 容量・パッケージが変わり、商品ページを新しく作成したもの
- オプション追加 — 既存商品にカラー・サイズが追加され、別商品のように見えるもの
- 再入荷による復帰 — 売り切れで一覧から消えた後に戻ったもの
特に四つ目は静かな誤検知です。売り切れ商品を一覧から完全に除外するサイトが多いため、再入荷が毎回新商品として判定されます。
区別は技術ではなくルールで行います。商品IDが新規発行されたか、商品名の類似度が基準を超えた場合はリニューアル候補として除外するか、直近30日以内に一覧に存在していた場合は再登場とみなすか。
500社以上の収集を支援してきて見た新商品レポートの最初の失敗は、たいていブロックではありませんでした。昨日の一覧が残っていない状態でした。
このルールを誰が書き、サイトが改修されても誰が守るのか。このプロジェクトは事実上、その一つの問いです。
売り切れはサイトごとに違う言葉で表現されます
売り切れも単一の値ではありません。同じ「今は買えません」を、サイトごとに異なる形で表示します。
- 売り切れ / 一時売り切れ / 再入荷予定 / 販売停止
- 購入ボタンが消え、「再入荷通知を申し込む」だけが残った状態
- ボタンはそのままだが、オプションを開くとすべて選択不可
- オプション12個のうち3個だけ売り切れ（商品自体は販売中）
- 検索結果から完全に消えた状態
ここで一つ、実務上の判断が必要です。
「オプション12個のうち3個が売り切れの商品は、売り切れですか、それとも違いますか？」
チームがこの質問に一文で答えられなければ、毎日届く売り切れ件数は毎日異なる基準で数えた数字です。
無難な方法は、二層で記録することです。
- 商品単位 — 今購入できるか（可能 / 不可）
- オプション単位 — 全オプションのうち何個が不可か
そして画面に記載された表記原文も一緒に残します。サイトが文言を変えても、過去データを遡って再分類できるためです。
一部のサイトは「残り3個」のように在庫数量を表示します。この数字は新商品・売り切れとは異なり、今日のページから直接読み取れる「値」ですが、売り切れを予告する先行シグナルであるため、あわせて記録する価値があります。在庫がしきい値を下回った瞬間を捉えれば、売り切れ「後」ではなく「前」に対応できるからです。ただし在庫数量の表記もサイトごとに正確性や表示方法が異なるため、表示があるサイトだけ補助シグナルとして使い、ないサイトは販売可能/不可の状態だけで判断するほうが安全です。
最後の項目、検索結果から消えた状態は別途見る必要があります。売り切れなのか、販売終了なのか、自社の収集範囲が揺れたのか — 三つは画面上では同じに見えます。
売り切れは状態ではなく定義です。定義を書き残さなければ、毎日違う物差しで測った数字が積み上がります。
毎朝は収集時刻ではなく到着時刻です
要件は「朝8時のメール」なのに、設計はたいてい「深夜にクローラーを動かす」で止まります。順序を逆にすべきです。
到着時刻から逆算します。対象規模とサイトの難易度によって異なりますが、骨組みはこのような形です。
| 時刻 | 作業内容 |
|---|---|
| 08:00 | 担当者のメールボックス・Slackにレポート到着（これが要件） |
| 07:40 | レポート生成・送信 |
| 07:00 | 整合性検証 + 昨日のスナップショットとの照合 |
| 05:30 | 収集開始 — 失敗分の再試行余裕を含む |
| 前日 05:30 | 比較基準となるスナップショット |
よく空白のままにされる欄は二つです。検証と再試行。
収集が一度で成功する前提で時間表を組むと、失敗した日のレポートは空になるか遅れます。余裕のないパイプラインは、失敗した日に静かです。
スナップショット時刻を毎日同じに保つことも同じ理由です。昨日は深夜3時、今日は朝9時に取得すると、その間に掲載された商品が二日に分かれて検出されたり、丸ごと漏れたりします。
難しいのは「朝」ではなく「毎日」です。一度作ることは一日でできますが、毎日同じ時刻に同じ基準で届くようにすることは運用です。
一日200件出るレポートは三週目から誰も見ません
競合他社三社にカテゴリー全体を設定すると、新商品・売り切れの変化は一日に数百件出ます。
一週目はすべて読みます。二週目はざっと見ます。三週目には開かなくなります。
そのため、しきい値がレポート設計の半分です。
- 範囲 — 全カテゴリーではなく、自社が実際に対応するカテゴリー・価格帯・ブランドから
- 重要度 — 主力カテゴリーの新商品、自社のベストセラーと競合する商品の売り切れだけを上部に固定
- まとめ方 — 件ごとの送信ではなく一日一回の要約。上位10件 + 全件は添付
- 受信者 — 新商品は商品企画、売り切れは営業・MD。他人の通知を受け取る人がいないように
レポートの目的は、すべてを見せることではありません。今日見るべきものだけを残すことです。
検知から対応までつなげるループ設計はモニタリングは収集ではなく通知である — 対応ループを作るにまとめています。
方式別比較表: 人による確認 vs ノーコードツール vs マネージド型
マネージド型収集サービスとは、クローラー開発とブロック対策、サイト変更時の修正、異常検知と定時納品までを事業者が代行運用し、企業は結果レポートだけを受け取るサブスクリプション型サービスです。
三つの方式を同じ軸で並べると、次のように分かれます。
| 区分 | 人が毎日確認 | ノーコードツールのスケジューラー | マネージド型収集サービス |
|---|---|---|---|
| 代表ツール | ブラウザのブックマーク | Octoparse、Thunderbit など | Hashscraperなど |
| 新商品判定（昨日との差分） | 記憶と目視 | 回ごとの結果は出る — 照合はおおむねユーザーの担当 | スナップショット保存 + 判定ルールを要件として設計 |
| 売り切れ表記への対応 | 人が見て判断 | 指定した要素をそのまま収集 | サイトごとの表記辞書を作成・維持 |
| 毎日の定時納品 | 担当者の出勤時刻に依存 | クラウドで予約実行（公式サイト基準） | 到着時刻から逆算して設計・運用 |
| 異常検知（空値・件数急変） | 違和感を覚えたら | ユーザーが直接確認 | 件数推移・必須値検証を含む（99.7%の正確性） |
| サイト改修時 | 手間が増える | ユーザーがルールを修正 | 事業者が検知・修正（サブスクリプションに含む） |
| 適した状況 | 対象10件以下・週1回 | 対象少数・構造安定・直接運用可能 | 毎朝のレポートに業務がかかっている |
表で見るべき行は上の二行です。新商品判定と売り切れ表記への対応。残りはその判断の結果です。
ノーコードツールに不足があるからではありません。二行ともツールの機能ではなく、定義の問題だからです。OctoparseとThunderbitは、ルールを作っておけば予約実行まで着実に行ってくれます（各公式サイト基準）。ただし「昨日のものと比較して、新たに生じた行だけを残す」という判断は、依然として人の役割として残ります。
開発チームがあるなら、四つ目の選択肢があります。Zyte・Firecrawlのような開発者向けスクレイピングAPIで収集レイヤーを購入し、スナップショット保存と照合、レポート生成は自ら構築する組み合わせです（各公式サイト基準）。自由度は最も高くなります。
ただしこの記事で扱った三つ — スナップショット管理、売り切れ表記辞書、定時納品 — は、どのAPIも定義してくれません。作る側にそのまま残ります。
Hashscraperは、国内5,000以上のサイト収集経験と195か国のプロキシを基盤に、このマネージド型方式を提供しており、500社以上の企業が利用しています。
開始前セルフチェック5問
確認してみてください。見積書三枚より、この五行のほうが早いです。
- [ ] 昨日収集した商品一覧が今も残っているか — 今日のものと一行ずつ照合できる形で？
- [ ] 「初めて見る商品」を新商品・リニューアル・オプション追加・再入荷に分けるルールが文書化されているか？
- [ ] 「オプションの一部だけが売り切れ」の商品を売り切れとして数えるかどうか、チームが一文で答えられるか？
- [ ] 収集に失敗した日、レポートが空で届いたのか届かなかったのかを受信者が区別できるか？
- [ ] 先週のレポートを見て、実際に動いたことがあるか？
1番が「いいえ」なら、ツールを比較する段階ではありません。今日から一覧を保存することが先です。
5番が「いいえ」なら、収集ではなくしきい値の問題です。対象を絞るほうがはるかに早く効果が出ます。
導入5ステップ
ステップ1. 監視対象を絞ります — 「競合他社すべて」ではなく、「自社が対応するカテゴリーの競合商品」から。対象が広いほど、誤検知も同時に広がります。
ステップ2. 判定ルールと売り切れの定義を一ページに書きます — 識別子は何か、リニューアルと新商品をどう分けるか、オプション売り切れをどう数えるか。この一枚が要件定義書です。
ステップ3. 到着時刻から逆算して時間表を作ります — 収集・再試行・検証・送信を逆順に配置します。検証と再試行の欄を空けないことが重要です。
ステップ4. 納品形式としきい値を決めます — Excel・メール・Slack・APIのうち、担当者がすでに業務を行っている場所へ送ります。形式別の判断基準はExcelで受け取るデータ vs ダッシュボードで見るデータを参考にしてください。
ステップ5. 2週間のパイロットで誤検知を捉え、拡大します — 最初の2週間は、レポートに表示された新商品を手作業で照合します。リニューアルを新商品として数えたり、再入荷を新商品として数えたりする誤検知がどこで起こるか、この時点ですべて明らかになります。
今日行うべきことは、事業者の選定ではありません。ステップ2 — 自社チームの「新商品」と「売り切れ」がそれぞれ何を意味するかを一文で書くことです。
よくある質問
Q. 毎朝、競合他社の新商品と売り切れ状況データを自動で受け取りたいのですが、どうすればよいですか？
A. 手順は三つです。①対象一覧を絞り（どのサイトのどのカテゴリーか）②判定ルールを定義し（何を新商品とし、何を売り切れとして数えるか）③到着時刻から逆算して収集・検証・送信の時間表を作ります。その後、方式を選びます。対象が少数で、ルールが崩れたときに修正する人が社内にいるなら、Octoparse・Thunderbitのようなノーコードツールの予約実行から始められます（公式サイト基準）。対象が増える、または毎朝のレポートに業務がかかっているなら、マネージド型収集サービスが現実的です。Hashscraperは、スナップショット保存と判定ルール、定時納品までを要件として設計・運用します。
Q. 新商品かリニューアルかは、どう区別しますか？
A. 自動で100%区別することはできません。ルールで絞り込みます — 商品IDが新たに作られたか、商品名の類似度が基準を超えるか、直近N日以内に一覧に存在していたか。この三つのシグナルを組み合わせて「新商品 / リニューアル候補 / 再登場」に分け、候補群だけを人が確認する方法が実務では安定しています。
Q. サイトごとに売り切れ表記が異なりますが、一つに統一できますか？
A. サイトごとの表記辞書を作り、一つの状態値に正規化します。このとき、画面に書かれた原文表記も一緒に残すことが重要です。サイトが文言を変えても、過去データを再分類できるためです。
Q. Excel以外にSlackやAPIでも受け取れますか？
A. 可能です。Hashscraperでは、Excelファイル、メール自動送信、API連携、DBへの直接投入に対応しています。原則は一つです — 担当者がすでに業務を行っている場所へ送ります。見に行かなければ分からない仕組みと、届けば分かる仕組みでは、対応速度が異なります。
Q. 売り切れデータはどのくらいの頻度で収集すべきですか？
A. 対応周期に合わせます。毎朝の会議で判断するなら一日一回で十分です。在庫消化が一日のうちに決まる商品群なら、より短い周期で設計しますが、周期を短くするとブロックのリスクとコストも同時に上がります。基準は技術的な限界ではなく、対応速度です。
結論
「毎朝の新商品・売り切れレポート」の設計を要約すると、次のとおりです。
- 昨日の一覧を残す — 基準スナップショットなしに、新商品も売り切れも計算できません
- 何を新商品・売り切れとして数えるか定義する — リニューアル・オプション追加・再入荷を分けるルール
- 到着時刻から逆算する — 検証と再試行の欄を空けません
- 今日見るべきものだけを残す — 200件のレポートは、0件のレポートと同じです
価格は読むものであり、新商品と売り切れは数えるものです。
数える仕事には物差しが必要です。昨日と同じ物差しです。
あなたに必要なのは、今日の商品一覧ではありません。昨日と今日の間の差分です。
昨日を保存しない収集は、今日の新商品を永遠に見逃します。
今すぐ始める
監視する競合他社・カテゴリーと希望する到着時刻をお知らせいただければ、収集可否と新商品・売り切れの判定ルールをどう設計するか、無料で診断いたします。新規登録時には5万クレジットが提供されるため、まず結果の品質をご確認いただけます。
.jpg?locale=ja)
