2022年9月のある日曜日の午後、何者かがFast CompanyのCMS（コンテンツ管理システム）に侵入し、トップページのすべての見出しを卑劣な人種差別的メッセージに書き換えました。同社チームはサイトを一時停止し、約2時間後に復旧させました。しかしその2日後、同じ攻撃者がFast CompanyのApple Newsフォロワーに向けて同様のメッセージを一斉配信し、結果としてサイトは8日間にわたって完全停止を余儀なくされました。
これは最も劇的な事例ですが、日常で起こるトラブルはずっと静かに発生します。新しいデプロイによって価格表コンポーネントが空のテーブルを描画してしまう。CMSの編集者がヒーローセクションにダミーテキストを残したまま下書きを誤公開してしまう。誤字を修正するついでに誰かが昨年のプライバシーポリシーを誤って復元してしまう。サーバー自体は稼働しており全ページが正常に応答するため、アラートで呼び出される人は誰もいません。
私はPage Deltasの開発に携わっています。これは多くのチームが他社のウェブサイトの動向を追跡するために利用しているツールです。しかし本記事では、このツールを「自社のサイト」に向ける方法について解説します。どのページを監視すべきか、何が「異常」なのかをAIフィルターに的確に指示（ブリーフ）する方法、デプロイ直後に自動でチェックをトリガーする方法、そしてこのツールが適さない境界線について説明します。
なぜ既存のツールでは見逃してしまうのか
ほとんどのウェブサイトにはすでに稼働監視（Uptimeモニター）が導入されています。稼働監視が確認するのは「ページが応答するかどうか」という1点のみです。改ざんされたトップページであっても、HTTPステータスとしては完璧に応答します。料金テーブルが崩れた価格ページも同様です。稼働監視は「部屋の電気が消えた」ことを知らせるのには優れていますが、「誰かが勝手に壁を塗り替えた」ことまでは教えてくれません。
サーバーサイドのツールにも別の死角があります。ファイル整合性監視（FIM）は自社サーバー内のファイルのみを監視するため、サードパーティ製スクリプト（チャットウィジェット、タグマネージャー、広告コードなど）が訪問者の表示画面を改変しても検知できません。また、ドメインが別のサーバーへ向けられ自社サーバーが無傷のまま放置されるDNSハイジャックも検知不可能です。Visualpingのウェブサイト改ざん対策ガイドでも同様の点が指摘されており、まさにその通りです。検知は「訪問者に実際に何が表示されているか」を基準に行わなければなりません。
それこそがウェブサイト変更監視ツールの役割です。外部から実際の訪問者と同じようにページを取得し、前回のチェック結果と比較します。ここで投げかける問いは、「このページは、意図しない形で変更されていないか？」という点です。
どのページを監視すべきか？
サイト全体の全ページを監視する必要はありません。問題のある変更が生じた際に、金銭的損失や信用の失墜が最も速く発生するページ、そして社内の人間よりも先にお客様が気づいてしまうページから始めましょう。
| ページ | 問題のある変更の例 | ブリーフ（指示文）に書くべき内容 |
|---|---|---|
| トップページ | 見出しの書き換え、公開していない言語のテキスト混入、未知のドメインへのリンク | 見出し、ヒーローのテキスト、メインCTA、価格へのあらゆる変更でアラート通知 |
| 料金プラン（Pricing） | プランの欠落、誤った価格表示、空のテーブル | 価格、プラン内容、制限値のあらゆる変更でアラート通知 |
| 主要ランディングページ | ダミーテキスト（プレースホルダー）、セクションの消失 | セクションの消失やダミーテキストの表示を検知してアラート通知 |
| 利用規約・プライバシーポリシー | 過去バージョンの誤復元、条項の欠落 | 条項の追加、削除、言い回しの変更があればアラート通知 |
| サイトマップ | チームの誰も公開していない身元不明のURLが出現 | 指示文は不要（サイトマップ監視は新規URLをそのまま一覧化します） |
最初の4行はページ監視です。最後の1行はサイトマップ監視で、sitemap.xml に新しいURLが現れた際に通知します。これは、サイト上に何百ものスパムページが気付かれぬまま作成される特定のハッキング被害に役立ちますが、CMSがそれらのページをサイトマップに追加する場合にのみ有効です。
無料プラン（Free）では最大10個のURLを監視でき、サイトマップ監視も1個としてカウントされます。これだけで、トップページ、価格ページ、主要LP 3ページ、法的文書 2ページ、サイトマップをカバーでき、さらに2つの枠が余ります。
設定手順
基本的な設定は、当社のウェブサイト変更を監視する方法に関するガイドと同じですが、1つだけ大きな違いがあります。期待する変化を追うのではなく、「何が絶対に起きてはならないか」を記述する点です。
1. 指示文（ブリーフ）を添えてページを登録する
無料アカウントを作成し、「New monitor」をクリックしてURLを貼り付けます。説明（Description）欄は、当社のLLMが変更の重要性を判断する際に参照するプロンプトになります。そのため、自分の代わりにページを見張ってくれている同僚への指示メモを書くような感覚で入力してください。
自社のトップページであれば、次のような指示文が効果的です：
自社のトップページ（example.com）。正式リリース時以外に変更されることは稀です。
見出し、ヒーローコピー、メインCTA、または価格に変更があった場合はアラート通知してください。
自社製品と無関係なテキスト、不快な表現、または当社が公開していない言語のテキストが表示された場合も通知してください。
回転表示される導入企業のロゴや、最新ブログ記事のプレビューウィジェットは無視してください。「無視する」という行は、想像以上に重要な役割を果たします。ほぼすべてのページには自律的に変化するウィジェットが存在しており、それを明記しておかないと、運用開始の最初の1週間は不要な通知の対応に追われることになります。
2. アラートの通知先を2箇所設定する
「Channels」を開き、アラートの送信先を追加します。Slack、Discord、Microsoft Teamsは着信Webhook（Incoming Webhook）URLで連携できます。メールは初回確認メッセージの承認が必要で、署名付きWebhookを使えば自社の内部システムに直接フィードすることも可能です。各チャンネルで「Send test」をクリックし、正常に届くことを確認してください。
自社サイトの監視では、異なる種類のチャンネルを2つ設定することをお勧めします。例えばSlackと、当番エンジニア向けのメーリングリストです。各アラートはチャンネルごとに1回送信され、自動再試行は行われません。そのため、2つ目の経路を確保しておくことで、Slackの一時的な障害によってトップページの改ざん通知を見落とす事態を防げます。
3. デプロイ直後に即時チェックを実行する
Page Deltasではチェックの固定頻度を手動設定しません。頻度はアダプティブ（適応型）になっており、頻繁に変更されるページは高頻度で、動きの少ないページは低頻度でチェックされ、キュー混雑時は有料プランが優先されます。自社のトップページは通常静的であるため、チェック間隔が広がりがちですが、誰かが変更を加えた直後にはまさに最速で確認したいはずです。
その解決策は、自身でチェックを即時トリガーすることです。各モニターには「Check now」ボタンがあり、API経由でも同じ操作が可能です。そのため、デプロイパイプラインの最後に次の呼び出しを1行追加するだけで済みます：
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now手動チェックはモニター1件につき毎分1回に制限されていますが、デプロイの検証用途には十分です。APIキーは「Settings」→「API keys」から作成でき（editorまたはadminロールが必要）、作成時に1度しか表示されないため、直ちにCI/CDのシークレットに保存してください。モニター自体の作成もスクリプトで自動化したい場合は、当社のあらゆるウェブサイトを変更検知API化する方法の記事でAPIの全容を解説しています。
アラートを受信した際の対応
以上の設定が完了すると、重要な変更が発生した際に、自然言語による要約と変更前後のスクリーンショットを含む通知が届きます。署名付きWebhookを利用した場合、ペイロードは以下のようになります（値は例示用のダミーです）：
{
"event": "change.detected",
"monitor_id": "01HW2X...",
"monitor_url": "https://example.com/pricing",
"monitor_name": "自社の料金ページ",
"change_id": "...",
"detected_at": "2026-10-08T07:12:00Z",
"summary": "ProプランとBusinessプランが表示されなくなりました。価格表には現在Freeプランのみが表示されています。",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}自社サイトに関するアラートの多くは、チームが意図してリリースした変更です。それは全く問題ありませんし、むしろ有益です。スレッドで「これは自分たちの作業、本日リリース済み」と一言返信するだけで、そのチャンネルは何がいつ本番反映されたかの実行ログになります。本当に警戒すべきなのは、チームの誰も心当たりのないアラートです。
不明なアラートが届いた際、スクリーンショットは2つの役割を果たします。現在訪問者に何が見えているのかを直ちに確認できること、そして後からセキュリティチームや保険会社に提出を求められた際のタイムスタンプ付き証跡となることです。履歴はFreeプランで14日間、有料プランではさらに長く保存されます（Starterで30日間、Scaleで最大730日間）。保管が必要なものはダウンロードしておきましょう。
時には、最初の予兆がアラートではなく、お客様がSNSに投稿したスクリーンショットである場合もあります。そうした兆候もいち早く把握したい場合は、当社の姉妹製品であるKWatch.ioをご利用ください。Reddit、X、LinkedIn、Facebook、Hacker News上で貴社のブランド名が言及された際にリアルタイムで通知します。
ツールの適用範囲と限界
この設定では検知できないケースもいくつか存在します。信頼して運用する前に、その限界を把握しておく必要があります。
当社は各ページのメインテキストを比較します。ナビゲーション、フッター、広告は比較前に自動的に除外されるため、フッターに不正挿入されたスパムリンクは検知されません。また、テキストを一切変更せずロゴ画像のみを差し替えるような、純粋に視覚的な画像変更も対象外です。
また、これは死活監視（Uptimeモニター）の代わりにはなりません。サイトがダウンした場合、アラートは発報されずチェック失敗となり、10回連続で失敗するとモニターが自動停止して管理者に通知されます。これでは障害対応には遅すぎるため、サーバーダウンの検知には既存の死活監視ツールを引き続き併用してください。
デプロイの合間に発生した変更は、次回のスケジュールチェック時に検知されますが、間隔は固定されていません。特定のページに対して数分ごとの厳密な定期巡回が必要な場合は、ページごとに固定頻度を設定できるVisualpingの方が適しています。また、当社は公開ページのみを対象としているため、ログイン認証の奥にある管理画面などは監視できません。
最後に、Page Deltasが伝えるのは「何かが変わった」という事実です。攻撃者がどのように侵入したかまでは特定できないため、根本原因の究明は引き続きセキュリティツールの役目となります。
まずはトップページから始めましょう
まずはトップページと料金ページを登録し、上記の見本をベースに自社固有の除外ルールを反映させ、両方のチャンネルにテスト通知を送信してみてください。その後、デプロイスクリプトに即時チェックのAPI呼び出しを追加しましょう。無料プランなら、AIフィルタリング、全5種の通知チャンネル、API連携を備えた10件のURLまたはサイトマップをクレジットカードなしで利用できます。無料で監視を始める。
Julien（Page Deltas プロダクトマネージャー）