changedetection.io徹底解説：31kスター獲得のWeb変更監視OSS、AI要約・100+通知統合

「ECサイトの価格が下がったら通知してほしい」「品切れ商品が再入荷したら知りたい」「自社サイトが改ざんされていないか監視したい」——こういうニーズに、専用の監視サービス（VisualPing・Distill）に毎月課金してきた人は多い。dgtlmoon/changedetection.io は、その監視を自己ホストで無料で動かせるOSSだ。執筆時点でGitHub Stars 31.3k、Apache 2.0ライセンス、Python 81%。100+通知統合（Slack・Discord・Email・Teams 等）、AI要約（GPT/Claude/Gemini対応）、Visual Selector・Browser Stepsまで揃っており、エンタープライズも個人も同じバイナリで運用できる。

この記事ではchangedetection.ioのWeb監視機能を解説します。AI時代の自動化ツール全体像はAI自動化ツール完全ガイド2026をご覧ください。

Source: dgtlmoon/changedetection.io — メインダッシュボード。各監視先のステータスを一覧表示。

changedetection.ioとは：「Webの変更」を全方位で捉えるOSS

changedetection.ioは、Webページの変更を定期的に検知し、変化があったら任意の通知先にアラートを飛ばすOSSだ。シンプルに見えて、実装は深い。

「Webの変化を検知する」という一見ニッチな領域で 31kスターを集めたことが、需要の広さを物語っている。

変更前後を並べて差分をハイライト表示。

主要機能：価格・在庫・改ざん検知の3大ユースケース

changedetection.ioの設計は 3つの典型ユースケース から逆算されている。

ユースケース1：ECサイトの価格・在庫監視

商品の価格下落・在庫復活を検知して通知する用途。Amazonで欲しい商品、楽天のセール時、オフィシャルストアの限定品。価格閾値を条件式で設定できるため、「指定値以下に落ちたら通知」のような細かい指定が可能だ。

在庫復活を検知する画面。複数商品を一覧表示。

ユースケース2：自社サイトの改ざん検知（セキュリティ）

サプライチェーン攻撃でWebサイトのJSが書き換えられたり、CMSが侵害されてフッターにスパムリンクが入る、というインシデントが2026年に増えている。changedetection.ioを特定要素監視で運用すれば、改ざんの早期発見が現実的にできる。XSS・SEOスパム・暗号資産スクリプトの埋め込みを発見できる。

ユースケース3：競合サイト・ニュースの定期巡回

「このブログに新しい記事が出たら教えて」「競合のプライシングページが更新されたら通知」「政府の入札情報が更新されたら知りたい」——定期巡回 + 差分通知の用途。RSSが提供されていないサイトも対象にできる。

インストール：Docker Compose一発が王道

changedetection.io のセットアップは、Docker Composeで完結する。公式の推奨は以下。

# docker-compose.yml
version: "3.5"
services:
  changedetection:
    image: dgtlmoon/changedetection.io
    container_name: changedetection
    hostname: changedetection
    volumes:
      - changedetection-data:/datastore
    ports:
      - "5000:5000"
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000

  # SPAやJSレンダリングを扱う場合のオプション
  playwright-chrome:
    image: dgtlmoon/sockpuppetbrowser:latest
    container_name: chrome
    restart: unless-stopped
    environment:
      - SCREEN_WIDTH=1920
      - SCREEN_HEIGHT=1024
      - SCREEN_DEPTH=16
      - MAX_CONCURRENT_CHROME_PROCESSES=10

volumes:
  changedetection-data:

docker compose up -d

これで http://localhost:5000 にアクセスすればUIが立ち上がる。JavaScriptレンダリングが必要なサイト（モダンなSPA、Cloudflare保護されたサイト）を監視するならplaywright-chrome も同時起動する。

スタンドアロン Docker で動かす場合は以下。

docker run -d --restart always \
  -p "127.0.0.1:5000:5000" \
  -v datastore-volume:/datastore \
  --name changedetection.io \
  dgtlmoon/changedetection.io

Pythonに慣れている人ならpip経由で。

pip3 install changedetection.io
changedetection.io -d /path/to/empty/data/dir -p 5000

「1分でPoCできる」のがchangedetection.ioの大きな強みだ。

Visual Selector：UIで「ここを監視」を指定する

監視対象は通常、CSS Selector や XPath で指定する。しかし「特定の値段だけ追いたい」「この見出しだけ追いたい」のように、コードを書かずにブラウザ画面でクリックするだけで指定したい場合がある。

Visual Selectorの動作。ページ内をクリックして要素をピックアップ。

このVisual Selectorは、非エンジニアの運用担当者にも開放できる仕掛けで、「マーケ担当が競合サイトを監視する」ようなシーンで効く。エンジニアが毎回CSS Selectorを書いてあげる必要がない。

Browser Steps：ログイン・フォーム入力・クリック自動化

「ログインしないと見られないページ」「カートに入れないと表示されない価格」のようなケースを扱うのが Browser Steps だ。チュートリアル形式でログイン・フォーム入力・クリック手順を記録できる。

Browser Stepsで操作シーケンスを定義。

これは内部的にはPlaywrightのスクリプトを生成する仕組みで、Playwrightを書ける人なら手で書く、書けない人ならGUIで作るという段階的な使い分けができる。SaaS版（$8.99/月）にはChrome browserが含まれており、Browser Stepsの実行に必要なJSレンダリング環境を最初から整えてくれる。

AI要約：diffを「日本語で意味」に変換する

2026年版の目玉機能がAI要約だ。変更箇所の差分を、AIが自然言語で要約する。

AI要約。生のdiffの代わりに「価格が15%下がりました。在庫が復活しました」のような形で通知される。

対応プロバイダは広い。

「AI要約は2026年6月のサブスク開始」と公式が予告している機能で、SaaS版で先行提供される。OSS版でも自前のAPIキーを設定すれば使える。

これが効くのは通知量が多い場合だ。EC監視で1日数百件の差分が出ると、生のHTML diffを目で追うのは現実的でない。「価格が10%下がった3件」「在庫が復活した1件」のような形にAIが要約してから通知してくれれば、Slackチャンネルがノイズではなくシグナルになる。

スマートアラート（自然言語フィルタ）と組み合わせれば、「重要な変更だけ通知する」運用が実現する。logbull/logbullのようなログ収集基盤に通知ログを集約する設計と相性がいい。

100+通知統合：Apprise経由で何でも繋がる

通知の選択肢の広さは、changedetection.ioの最大の強みだ。Appriseライブラリを経由することで、100+のサービスに対応している。

Slackへの通知設定は1行で済む。

# Notification URL (Slack)
slack://TokenA/TokenB/TokenC/Channel

Webhookで自前のシステムに繋ぐなら、

json://example.com/webhook?+X-Custom-Header=value

「好きな通知先に好きな形で投げる」が追加コードゼロで実現する。これは独自実装すると地味に大変な部分で、Appriseを採用した設計判断が効いている。

コンテンツフィルタ：XPath/JSON/jq/CSSで「変更したい部分だけ」抽出

Webページ全体を比較すると、広告・タイムスタンプ・ナビゲーションなど本質ではない箇所の変更で誤検知が出る。changedetection.ioは複数のフィルタタイプで「監視したい部分だけ」を切り出せる。

JSON対応は隠れた強みで、REST APIを直接監視できる。例えば「自社のステータスページAPIを叩いて、ステータスがdegradedになったら通知」というモニタリングが、changedetection.io単体で組める。

JSONフィルタ設定の例。

スケジューラ：時間帯・曜日制限の柔軟さ

「営業時間中だけ監視したい」「夜間はチェックを止めたい」「土日は通知を止めたい」のような要件は、運用上極めて多い。changedetection.ioはタイムゾーン対応のスケジューラを備えている。

曜日・時間帯ごとに監視を制御。

これがあれば、「平日 9-18 時のみチェック、それ以外は停止」を1ボタンで設定できる。深夜にエラーで起こされる「夜間のSlack通知地獄」を回避できる。

競合比較：VisualPing / Distill / Wachete との位置取り

Webサイト変更検知の市場は、いくつかのSaaSが先行していた。それらと比較する。

「機能の網羅性で大手SaaSに匹敵し、OSSなので無料」というポジショニングは強い。SaaS版が$8.99と相対的に安いのも、自己ホストの運用面倒臭さを払拭したい層に刺さる。

SaaS版とOSS版の違い：何を払うか

OSS版で全機能が使えるなら、SaaS版を契約する理由は何か。実用上の判断軸を整理する。

「データを社内に閉じたい」「機密プロジェクト」ならOSS、「運用に時間を割きたくない」「個人で5〜20サイトだけ監視したい」ならSaaS、というのが妥当な棲み分け。

設計思想：なぜchangedetection.ioが31kスターを集めたか

ここまでの整理で、changedetection.ioが派手なプロダクトでないのは見えただろう。それでも31.3kスターを集めた背景には、3つの設計思想がある。

思想1：「派手な機能より、欠けない機能」

通知100+、フィルタ4種類、Browser Steps、Visual Selector——「これがないと困る」を全部潰している。逆に「これがあると凄い」（AIの予測機能、機械学習による異常検知等）には深入りしていない。

思想2：「Pythonで書く、Pythonで動く」

Python 81%という構成は、OSS貢献者の参入障壁を下げる。Goで書かれたOSSと比べて、コードに手を入れたい人が手を入れられる。31kスターのOSSにふさわしい貢献者層を集めるには、Pythonがコモンランゲージとして強い。

思想3：「OSSとSaaSの二重展開」

完全OSSにしたら維持できない、完全SaaSにしたら自由を求める層を取り逃がす。自己ホスト無料・SaaS $8.99/月の二重展開で両方のニーズを掬い取っている。これがビジネスとしての持続性を確保している。

ELK→Loki→Log Bullの流れで触れた「OSS市場の中位帯」を、changedetection.ioもWeb監視領域で築いている、と言える。

AI/エージェント時代の活用：自動化ハブとしての可能性

changedetection.ioは「通知を受けるだけのツール」ではなく、自動化のハブとして機能する設計だ。Webhook通知を契機にClaude Codeやエージェントを起動するパターンが組める。

[changedetection.io]
   ↓ Webhook（差分検知）
[GitHub Actions / 自前サーバ]
   ↓ Claude Code 起動
[Claude Code]
   ↓ 「変更内容を解析して、対応PRを起こす」
[GitHub PR]
   ↓ レビュー
[マージ]

例えば「競合のプライシングページが変わったら、Claude Codeに自社プライシングへの影響を分析させ、レポートを起票させる」という運用が、changedetection.io + GitHub Actions + Claude Codeで組める。

# .github/workflows/competitor-pricing-update.yml
on:
  repository_dispatch:
    types: [pricing-changed]
jobs:
  analyze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          # changedetection.ioから渡された差分を保存
          echo "$" > /tmp/diff.txt
          # Claude Codeに分析させる
          claude "competitor-pricing-update.mdに従って /tmp/diff.txt を解析"

「Webサイトの変更が起点になる業務オートメーション」が、コード書きを最小限にして組める。これは2025年以前ならZapier等の有料SaaSが必須だった領域で、OSSで完結することの意味が大きい。

オーケストレーション層でApache Airflow（DAG型ワークフロー）を持っているチームなら、changedetection.ioの通知をAirflow DAGの起点にして、データパイプラインを駆動するのも筋がいい。

日本語サイト監視時の論点：文字コード・JS・CAPTCHA

日本のサイトをchangedetection.ioで監視するときに浮上しやすい論点。

「日本企業の自社サイトを自社で監視する」のは無問題だが、他社サイトの監視は規約・法的論点が伴う。robots.txtを尊重し、過剰な負荷をかけないことが基本。スクレイピング全体の論点はサプライチェーンセキュリティ2026でも整理した観点が共通する。

1年後の予想：Web監視 + AI が引き起こす3つの変化

予想1：「人間がWebをチェックする」が減る

これまで「毎朝競合サイトをチェック」「在庫を確認するためにECサイトを巡回」していた業務は、全てchangedetection.io+AI要約に肩代わりされる。マーケ・営業・購買がSlackで通知を待つ働き方に切り替わる。

予想2：「Webスクレイピング業務」が縮退する

データ収集のためのスクレイピングジョブは、「変更検知 + 必要なときだけ取得」に変わる。差分のあった瞬間だけクローラを動かす設計が、コスト面でも合理的だ。「毎日1万URLを巡回」は2024年的、「変更があったURLだけ取得」が2026年的。

予想3：「Webサイトの改ざん検知」が標準ツールに

サプライチェーン攻撃でWebサイトのJSが書き換えられるインシデントが増える中、「サイト全体を継続監視する」のがエンジニア組織の標準作業になる。changedetection.ioのようなOSSが社内インフラの一部として常設される。

実装の中身：Pythonベースの分散ワーカー設計

changedetection.ioの内部設計を、運用上関係する範囲で見ておく。

[changedetection.io コンテナ]
   ├ Webサーバ（Flask）
   ├ スケジューラ（APScheduler）
   ├ Watchワーカー（複数並列）
   │    └ HTTPフェッチャ or Playwrightフェッチャ
   ├ 差分検出器（diff-match-patch）
   └ Notifier（Apprise）
   ↓
[Volume: /datastore]
   ├ url-watches.json    （監視リスト）
   ├ <uuid>/             （URLごとのスナップショット履歴）
   │    ├ 1714370512.txt
   │    ├ 1714370612.txt
   │    └ ...
   └ secret/             （API key等）

/datastore 配下が全データの実体で、これをバックアップするだけで完全復旧できる。ファイルベースのデータ管理がシンプルさの根源で、Postgres等の追加の永続層を持たないため、運用の取り回しが楽だ。

監視対象が増えた時のスケール戦略

「100URL→1,000URL→10,000URL」と監視対象が増えるとき、何がボトルネックになるか。

スケジューラは1分間隔のチェックを満たそうとすると秒単位で大量のジョブを起こすため、/datastore のI/O性能が一定の壁になる。1万URL以上の監視は、複数のchangedetection.ioインスタンスでURL群を分割するのが現実的。

RSS/Atom出力：監視結果を別システムへ

変更通知をRSSフィードとして出力する機能も備えている。これがあれば、

• Slackや個人のRSSリーダーで購読
• IFTTT/Zapierで他システムと連携
• 自前のニュースサイトのソースとして使える

http://localhost:5000/rss

これを社内のRSSアグリゲータ（FreshRSS等）に登録すれば、社内共有可能な「Webサイトの変更フィード」が出来上がる。

セキュリティ運用：自社サイトの改ざん検知に使う

サプライチェーン攻撃でJSが書き換えられる、CMSが侵害されてフッターにスパムリンクが入る、といったインシデントは年々増えている。changedetection.io を 自社サイトの定期スキャンに使うのは、低コストで価値の高い使い方だ。

「営業時間中だけ・10分間隔で監視 → 変更があれば緊急SREチャネルへ通知」という運用が、$0で組める（OSS版の場合）。これは外部の有料サービスで同じことをやろうとすると、月数万円かかる領域だ。

開発者にとっての地味な利点：Webhook ペイロードのカスタマイズ

通知BodyテンプレートがJinja2で書けるため、Webhookペイロードを完全にカスタマイズできる。

{
  "watch_uuid": "{{ watch_uuid }}",
  "url": "{{ watch_url }}",
  "title": "{{ watch_title }}",
  "diff": "{{ diff }}",
  "current_snapshot": "{{ current_snapshot }}",
  "previous_snapshot": "{{ previous_snapshot }}",
  "preferred_comms_format": "html"
}

これがあれば自前のシステムが期待するフォーマットに合わせて通知できる。GitHub Actions の repository_dispatch トリガに合わせる、Slack Block Kit に合わせる、Discord embeds に合わせる、何でも可能。「通知の自由度の高さ」は、changedetection.ioを長期間使っていく上で地味に効く。

まとめ：「Webの変化を捉える」インフラとして

changedetection.ioは、「Webサイトに変更があったら通知する」というシンプルな機能を、本気で網羅的に実装したOSSだ。

• 個人：欲しい商品の値下げ・在庫復活通知に使える。趣味で簡単に立てられる。
• 小〜中規模事業者：自社サイトの改ざん監視・競合サイトのウォッチに使える。
• エンタープライズ：データ主権・コンプライアンス的に安心の自己ホスト型。
• 開発者：Webhook・JSON API・XPath/jq filter、Pythonで拡張可能。

Apache 2.0 / 31.3kスター / 100+通知統合 / AI要約——これだけ揃っている上で自己ホストならタダというのは、強烈なバリュー提案だ。「Webの変化はchangedetection.ioが見ておく」という運用が、2026年の標準になる予感がある。

実例運用：個人・小チーム・エンタープライズの3パターン

パターン1：個人の趣味用途（5〜20サイト監視）

Raspberry Pi 4 + Docker で十分動く。電気代のみで運用可能。

通知先は個人のSlack（無料プラン）またはTelegram。月額0円で運用できる。

パターン2：小チームの業務監視（50〜500サイト）

社内のVMまたは小型VPS（4GB RAM）で1コンテナ運用。

通知はSlackチャンネル別。マーケ系は#marketingへ、セキュリティ系は#sec-alertへ、というふうにカテゴリで分離するのが運用の肝。

パターン3：エンタープライズの全方位監視（500〜10,000サイト）

Kubernetes上で複数インスタンスを URL群ごとに分割運用。SaaS版$8.99/月では足りない規模で、自己ホスト一択になる。

この規模では、専任の運用担当 + Slack/Datadog/PagerDuty統合が標準構成。

通知の「ノイズ問題」と対策

監視対象が増えるほど深刻化するのが通知のノイズ問題だ。1日500件のSlack通知が来ると、誰も読まなくなる。changedetection.ioで運用する際の対策を整理する。

実務では「即時通知 / デイリーサマリ / 月次レポート」の3階層で運用するのが現実的。即時通知は緊急のものだけ、それ以外は1日1回まとめてレビューする運用にすれば、Slackチャンネルが正しく機能する。

自社のWebコンテンツ品質を継続監視するという発想

最後に少し独自視点の使い方を提案する。「自社サイトの品質監視」。

「Webサイトのリンクが切れていないか」「画像のサイズが大きすぎないか」「タイポが入っていないか」——通常は別ツール（Lighthouse・broken-link-checker等）で監視するこれらの内容を、changedetection.ioで広く監視することもできる。

監視対象: https://example.com/sitemap.xml
チェック頻度: 毎日
フィルタ: 全文
通知条件: 任意の変更
通知先: コンテンツ担当チャンネル

これだけで「サイトマップに載るURLが変わった瞬間」を捕捉できる。新規ページの追加・削除・URL構造の変更が、人間に届く。

サイトマップやrobots.txtの監視は、SEO担当にとっても価値が高い。「競合のサイトマップ更新を検知して、新規記事のURLを即座に取得する」運用を組めば、競合の新規コンテンツを最短10分以内に把握できる。

FAQ

Q. 監視できるサイト数に上限はありますか？

A. OSS版は事実上無制限です（マシンリソースとネットワーク帯域の範囲内）。SaaS版はプラン依存で、$8.99/月で個人利用には十分な数を監視できます。

Q. 監視頻度はどこまで上げられますか？

A. 数秒間隔から数日間隔まで自由に設定可能ですが、1分以下のチェックは対象サイトへの負荷が高すぎるため、相手サイトの規約と相談してください。リソース面では Browser Steps + JSレンダリングを併用すると、1チェックあたりのコストが上がるため上限が下がります。

Q. ログイン後のページを監視するには？

A. Browser Steps機能を使います。ログイン手順（メール入力 → パスワード入力 → ログインボタンクリック）を記録すれば、毎回そのフローを実行してから差分を検出します。MFA必須のサイトは別途仕掛けが必要です。

Q. AI要約は OSS 版でも使えますか？

A. 使えます。 自分のOpenAI/Anthropic/Gemini APIキーをchangedetection.ioに設定すれば、OSS版でもAI要約が動きます。OllamaでローカルLLMを使う構成もサポートされており、機密データを外部APIに出したくない場合の選択肢になります。

Q. SaaS版の$8.99/月は安いですか？

A. 個人で5〜20サイト監視するなら圧倒的に安いです。VisualPingが$13〜、Distillが$15〜、Wacheteが$4.99〜なので、機能と価格のバランスでは最良クラスです。OSS版で十分という人は自己ホストで0円なのも強み。

Q. Webhookでどんなペイロードが飛びますか？

A. JSON形式で、変更前のURL・変更後のURL・差分テキスト・タイムスタンプ・監視IDなどが含まれます。json://スキーマでカスタムヘッダー追加も可能。GitHub Actions・Slack Workflows・Zapierと組み合わせる定石です。

Q. プロキシ経由でアクセスしたい場合は？

A. OSS版でも環境変数 HTTP_PROXY HTTPS_PROXY を設定すればプロキシ経由になります。SaaS版はresidential proxyが同梱されているため、追加設定なしでアクセス制限の厳しいサイトにも対応します。

Q. データのバックアップ方法は？

A. /datastore ボリュームに全データが入るので、tar で圧縮 → S3 に同期 が最もシンプルです。データ量はサイト数に比例し、画像が多くなければ数百MB〜数GB程度です。

Q. 商用利用はできますか？

A. Apache 2.0なので商用利用は問題ありません。SaaS事業者として再販する場合でも、ライセンス上の制約は最小限です。

Q. 既存の監視（Datadog Synthetics等）と併用しますか？

A. 併用が現実的です。Datadog Synthetics は 「サイトが落ちていないか」（可用性監視）、changedetection.ioは 「サイトの内容が変わったか」（コンテンツ監視） で役割が異なります。両方を持つのが堅実です。

Q. 監視対象のサイトに「拒否されたら」どうなりますか？

A. 多くのサイトはUser-Agentでアクセス元を判定します。changedetection.ioは User-Agent をカスタマイズ可能で、サイトに合わせて調整できます。アクセス頻度が高すぎる場合はRate limitingで弾かれることがあるので、スケジューラで頻度を抑えるのが基本です。住宅プロキシ経由でアクセスする選択肢もあります（SaaS版は同梱）。

Q. 監視結果のスナップショット履歴はどれくらい残せますか？

A. デフォルトでは直近のいくつかを保持します。設定で履歴の保持件数や保持期間を調整可能です。長期保管が必要な場合は、定期的にスナップショットを別ストレージへエクスポートする運用がおすすめです。

Q. 同じURLを複数の条件で監視したい場合は？

A. 同じURLを別Watchとして登録できます。例えば「価格セクションだけ監視するWatch」と「在庫ステータスだけ監視するWatch」を別々に作って、それぞれ異なる通知先・通知条件を設定できます。

Q. 監視を一時停止したい場合は？

A. UIで個別Watchをミュート（一時停止）できます。Schedulerで時間帯指定するのと組み合わせれば、メンテ時間中の通知を完全に止める運用も可能です。

参照ソース

• dgtlmoon/changedetection.io — GitHub
• changedetection.io 公式サイト
• Apprise（通知統合ライブラリ）