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