競合の製品・価格ページを毎週巡回して変更点を一覧にする

処理の起点を決める

曜日と時刻を決めた定期起動にします。n8n の Schedule Trigger ノードは、秒・分・時・日・週・月の単位、またはCron式で起動間隔を指定できます。週次であれば「Weeks」で曜日と時刻を指定します。

タイムゾーンには注意が必要です。n8n のタイムゾーンは、ワークフロー個別の設定があればそれが使われ、無ければインスタンスの設定が使われます。セルフホスト版の既定値は America/New_York です。日本時間で動かすつもりが、前日の夜に走っていたという取り違えが起きるため、ワークフロー側でタイムゾーンを明示してください。

週次にする理由は、価格や機能の改定が日単位で起きる市場はまれだからです。日次にすると差分の量に対して得られるものが釣り合いません。四半期に一度しか改定がない市場なら、隔週でも足ります。

入力データを集める

4番目を渡すと、判定の質が変わります。 「competitorが月額5,000円に改定」だけでは影響度が判断できませんが、自社が月額6,000円だと分かっていれば「自社より安い水準に入った」と書けます。

データの取得方法を決める

巡回対象： スプレッドシートで管理します。列は「競合名／ページ種別（価格・機能・事例・お知らせ）／URL／確認観点／最終取得日時／状態」です。ここを人が足し引きできる形にしておくことが、この構成を続けられるかどうかを決めます。

ページの取得： n8n の HTTP Request ノードでURLを取得します。取得時には次を守ります。

• 相手サイトの利用規約と robots.txt を事前に確認する。 自動取得を禁じているサイトは対象に入れない
• 1ページごとに数秒の間隔を空け、短時間に連続して叩かない
• User-Agent に自社が分かる情報と連絡先を入れる
• 会員登録やログインが必要なページには入らない。ログインが要る時点で対象外とする

この確認を飛ばさないでください。 技術的に取得できることと、取得してよいことは別です。判断に迷う場合は法務に確認し、対象から外します。外しても構成は成立します。その競合だけ手動で見る運用にすればよいだけです。

JavaScriptで描画されるページ： HTTP Request で取得したHTMLに本文が入っていない場合があります。ヘッドレスブラウザを使えば取れますが、負荷と保守の手間が増えます。まずは対象外にして、静的に取れるページだけで始めることを勧めます。

AIへ渡す前に整形する

ここがこの構成の要です。生のHTMLを差分にかけると、毎回大量の差分が出ます。

1. 本文テキストの抽出 … ナビゲーション、フッター、サイドバーを落とし、本文だけを取り出します。タグの属性やクラス名は捨てます
2. 動的要素の除去 … 現在日時、アクセス数、ランダムに並ぶ「おすすめ記事」、広告枠を落とします。ここを残すと毎回差分が出ます
3. 表記の正規化 … 全角と半角、空白の連続、改行位置を揃えます。「5,000円」と「5000円」を別物として扱わないようにします
4. 差分の抽出 … 前回分と行単位で比較し、追加・削除・変更された行だけを取り出します。変わっていないページはここで処理を終え、AIに渡しません
5. 差分量の上限 … 差分が一定量を超えたページは、サイトの全面リニューアルである可能性が高いので、「大規模変更」として人に回し、AIには渡しません

4番と5番でAPIの呼び出し回数が大きく減ります。8社分を毎週渡す構成にすると費用も時間も無駄になります。

AIに処理させる

差分テキストを渡し、次の判定をさせます。

「対象外」を積極的に出させることが重要です。 判定の価値は、拾うことより捨てることにあります。

指示内容を固定する

あなたは競合調査の担当者です。
あるページの前回と今回の差分を渡します。自社にとって意味のある変更かを判定してください。

【厳守事項】
- 差分に現れていない内容を推測しないでください。
  「おそらく値下げの前触れ」といった解釈を書かないでください。
- 金額、プラン名、機能名は、差分に書かれたとおりに転記してください。
  概算や言い換えをしないでください。
- 次のものは category を「対象外」としてください。
  更新日の表示、キャンペーンバナー、記事の並び替え、誤字修正、
  画像の差し替え、問い合わせ導線の文言変更。
- 影響度は、下に示す自社の価格・機能と比べて判断してください。
  自社情報と比べられない場合は "unknown" としてください。
- 差分の解釈に自信がない場合は confidence を low にし、
  needs_human_check に確認すべき箇所を書いてください。

【自社の価格・機能】
{own_product}

【対象ページ】
競合: {competitor}  種別: {page_type}  URL: {url}

【前回との差分】
{diff_text}

「対象外」の列挙を具体的に書くことが効きます。 抽象的に「重要でない変更は除外して」と書くと、判断が毎回ぶれます。実際に出てきたノイズを、この列挙に足していく運用にします。

出力形式を固定する

{
  "competitor": "",
  "page_type": "",
  "url": "",
  "checked_at": "",
  "changes": [
    {
      "category": "価格改定 | プラン追加・廃止 | 機能追加 | 表現変更 | 事例追加 | その他 | 対象外",
      "before": "",
      "after": "",
      "summary": "",
      "impact": "high | medium | low | unknown",
      "confidence": "high | medium | low",
      "needs_human_check": ""
    }
  ],
  "large_change": false,
  "fetch_error": ""
}

before と after には、差分の該当部分をそのまま入れさせます。要約だけを受け取ると、後から「本当にそう書いてあったか」を確認できません。

fetch_error を出力に持たせているのは、取得できなかったことを「変更なし」と区別するためです。ここを分けないと、ページ構造の変更で取得に失敗し続けているのに、「今週も変更なし」と報告され続けます。

システムへ連携する

出力は2か所へ流します。

Slackへの投稿は、競合ごとにスレッドをまとめます。1変更1投稿にすると、改定のあった週にチャンネルが埋まります。

Salesforce など営業側のシステムへの自動連携は、最初は作らないでください。競合の動きを案件へ自動で紐づけると、誤判定が商談の判断材料として流れてしまいます。 担当者が確認したものだけを、人の手で共有する形から始めます。

人が確認する

社内へ流す前に、必ず人が確認します。

理由は、差分の解釈を誤ったまま「競合が値下げした」と社内に流れると、営業が現場で誤った前提で話すためです。訂正しても、一度流れた情報は止まりません。

確認を速くするための設計が要ります。

• Slackの投稿に、該当ページのURLと該当箇所を必ず含める
• 影響度 high は、担当者が実際のページを開くまで「未確認」の印を付ける
• 前回の巡回で「対象外」と判断した変更と同じ文面は、まとめて折りたたむ
• 取得エラーは、変更とは別のチャンネルへ流す

例外に対処する

記録を残す

• 取得したページの本文テキスト（日付付き。1ページ1ファイル）
• 抽出した差分
• AIの判定結果（対象外を含む全件）
• 担当者が社内へ流したもの・流さなかったもの
• 取得エラーの履歴

1番目を残すことが、この構成の資産になります。 半年分たまると、「競合A社は毎年4月に価格を見直している」といった周期が見えます。これは毎週の差分からは分かりません。

保存先は自社のストレージにします。取得したページの内容は、社内での検討材料としての利用にとどめ、社外への転載や公開資料への引き写しはしないでください。