Web改ざん検知SaaSは本当に必要？ 7製品を監視方式から比較

以前、クライアントの要望でWeb改ざん検知SaaSを導入したことがあります。

そのとき引っかかったのが、セキュリティ対策のために外部JavaScriptをページ上部へ追加する構成でした。
守るための仕組みなのに、新しい外部依存を増やし、それを重要な読み込み経路へ置く。
保守対象も増えるので、「そこまでして入れる意味はあるのだろうか」と疑問が残りました。

ただ、改めて現在の製品群を調べてみると、「Web改ざん検知」という名前の下にはかなり違う仕組みが混在しています。
外から定期巡回するもの、サーバー内部でファイル変更を監視するもの、実ブラウザ上のJavaScript挙動を見るもの、CDNやCSPを使って制御するものまであります。

比較するときは、どこで何を監視し、異常を見つけた後に何ができるのかを見る必要があります。
あわせて、検知できることと、その場で攻撃を止められることは別という点も押さえておきたいところです。

この記事では2026年9月時点の公式情報をもとに、代表的な7製品をその観点から整理します。

「Web改ざん対策」は大きく4種類ある

一括りにされがちですが、実際には守っている場所が違います。

1. 外部からWebページを巡回し、前回との差分や悪性コードを検知する
2. サーバー上のファイル変更を監視し、改ざんされたファイルを戻す
3. 実際のブラウザでJavaScriptの実行や通信先を監視する
4. CDNやWAFのレイヤーで、CSPなどを使ってクライアントサイドを監視・制御する

たとえば外部クローラー型は、サイトのコードを書き換えずに導入しやすい一方、チェックの合間に発生した短時間の攻撃や、特定条件だけで発火するコードを捉えにくい場合があります。
反対にブラウザ内へエージェントを入れる方式は、実行時の挙動まで見られますが、その監視コード自体が依存関係になります。

どちらが優れているというより、想定している脅威モデルが異なります。要件に合った方式と製品を選ぶためにも、まずはこの違いを押さえておく必要があります。

7製品を監視する場所で比較

一覧だけでも、同じ市場に見えてかなり別物だと分かります。
ここからは製品ごとの機能を網羅するのではなく、方式の違いが見えやすいポイントを中心に見ていきます。

外から見る：GREDとReflectiz

GRED Web改ざんチェック Cloudは、登録したURLを起点に外部からクローリングし、JavaScriptやリンクタグなどの変化を解析します。
通常の監視ではサイト側への専用JavaScript追加は不要です。

一方、改ざん検知後にメンテナンスページへ切り替えるオプションでは専用タグを使います。
現行のユーザーガイドでは、HTMLのHEAD直後など、できるだけソース上方へ挿入することが推奨されています。
なお、タグやJavaScriptの変更は悪質かどうかに関係なく検知する可能性があると公式FAQでも案内されています。

Reflectizもサイトへ監視用コードを追加せず、外部のサンドボックスブラウザからJavaScript、Pixel、iframe、外部通信、第三者・第四者依存などを観測します。
単純なHTML差分より、実際にブラウザで動くクライアントサイド資産へ踏み込んでいるのが違いです。
PCI DSS向けモジュールではScript inventoryや承認、変更監視、監査証跡も扱います。

「本番コードを増やしたくない」という条件では、外部観測型は分かりやすい選択肢です。
その代わり、ページ内で常時動作して悪性コードをその場で止める仕組みとは役割が違います。

サーバーで戻す：WebARGUS

WebARGUSはOSのファイル・ディレクトリ変更イベントを監視し、改ざんを検知すると正常な状態へ自動復旧します。

外からWebページを巡回するのではなく、サーバー内部で変更そのものを見る方式です。
自社サーバー上のHTMLやJavaScript、画像などを書き換えられる攻撃には有効ですが、正規に読み込んでいる外部JavaScriptの配信元が侵害された場合は別問題です。
ローカルファイルが変わっていなければ、サーバー側のファイル監視だけでは捉えられません。

Edgeへ寄せる：Cloudflare Client-Side Security

Cloudflare Client-Side Security（旧Page Shield）は、Cloudflareをすでに利用しているサイトなら構成に組み込みやすい方式です。

CloudflareはレスポンスへContent Security PolicyのReport-Onlyヘッダーを追加し、ブラウザ標準のCSPレポートからScriptや外部接続を収集します。
仕組みの説明によれば、専用の監視JavaScriptをページ先頭へ常駐させる方式ではありません。

プランによって機能差はありますが、Script monitoring、接続先やCookieの監視、コード変更検知、Content Security Rulesによる制御などを提供しています。
PCI DSS 4.x向け機能はClient-Side Security Advancedが対象です。

既にCDNとしてCloudflareを経由しているなら、監視のためだけに別の実行コードを増やさずに済みます。
依存先をCloudflareへ寄せることにはなりますが、構成上の役割は比較的分かりやすいです。

実ブラウザで見る：Akamai、Jscrambler、GOOSEC

ここからは、単なる配信物の差分よりも「ブラウザ上でScriptが何をしているか」を見る方向です。

Akamai Client-Side Protection & Complianceは実ユーザーのブラウザ内でScriptの実行挙動や外部通信を分析します。
ページコードへJavaScriptを注入して監視するため、Scriptがフォーム情報を読み取る、未知のドメインへ通信するといった実行時の変化を追えます。
その代わり、監視コード自体の性能、障害点、CSP、デバッグ、撤去コストも評価対象になります。

Jscrambler Webpage IntegrityもScript inventory、挙動監視、データ流出制御、PCI DSS対応を扱います。
現在のPCI DSS向け資料では、Agent-basedとAgentlessを選べるHybridFlex Architectureが案内されており、常駐JavaScriptだけが導入方法ではありません。

国内ではGOOSECが、クローラーとWebページ側の検知用JavaScriptを組み合わせています。
Webスキミングや情報流出を対象とし、検知用JavaScript自体の改ざん・削除も監視します。
情報流出が発生した場合に、実害のあったユーザーを個別に特定できると説明している点も特徴です。

このグループまで来ると、「ファイルが変わったか」ではなく「Scriptの振る舞いが変わったか」が中心になります。
その分、導入の深さも運用負荷も大きくなります。

「変更されました」だけでは防御にならない

ここまでの違いを踏まえると、一番注意したいのは検知と防御を混同しないことです。

仮に攻撃コードが10時に配信され、10時5分の巡回で検知し、担当者が10時30分に対応したなら、その間にページを開いたユーザーにはコードが実行されています。

固定できる外部Scriptなら、Subresource Integrity（SRI）で期待するハッシュを指定し、不一致ならブラウザに実行させない方法があります。
Content Security Policy（CSP）なら、Scriptの読み込み元や外部への通信先を制限できます。

もちろん現実のサイトでは、GTM、広告、決済、チャット、A/Bテストなど動的な第三者コードが増え、SRIだけでは管理しにくいケースもあります。
そこにクライアントサイド監視製品の価値があります。

順番としては、まず依存を減らし、固定できるものは固定する。
そのうえで、固定できない領域を監視するのがベターでしょう。

高い理由は、検知より「監査を運用する仕組み」にある

製品の仕組みだけを見ると、「これでこの料金なのか」と感じることがあります。
ただ、現在の製品群を見ると、料金の対象は検知アルゴリズムだけではありません。

特に決済サイトでは、PCI DSS v4.0.1のRequirement 6.4.3と11.6.1への対応が、この種の製品を導入する大きな理由の一つになっています。
6.4.3では決済ページ上のScriptについて、承認、完全性確認、必要性の根拠を含むinventory管理が求められます。
11.6.1では、ユーザーのブラウザが受け取る決済ページやHTTPヘッダーの不正変更を検知し、通知する仕組みが求められます。

これらは2025年3月31日に将来要件から必須要件へ移行しました。
PCI Security Standards Councilは、SAQ Aについて要件の扱いを一部変更していますが、6.4.3と11.6.1自体がPCI DSSからなくなったわけではありません。

つまり企業が買っている、もしくは期待しているのは、

• Scriptの発見
• 差分検知
• 承認ワークフロー
• 必要性の記録
• 変更履歴
• アラート
• 監査向けレポート
• サポート

までをまとめた運用基盤です。

技術的なコード量ではなく、監査で「継続して管理しています」と説明するための証跡をSaaS化していると考えると、価格にもかなり納得感が出てきます。

参考: PCI SSC: 6.4.3 / 11.6.1の概要 / PCI SSC: E-Skimming Guidance / SAQ A変更について

どの方式を選ぶかは「何を守りたいか」で決まる

普通のWebサイトに対して、いきなり高機能なクライアントサイド監視SaaSを入れる必要性はあまり感じません。
まずCSP、SRI、依存関係の整理、アクセス権限、CI/CD、バックアップといった基本対策をきちんとした方が、構成も単純です。

一方で決済ページのように、第三者Scriptが多く、ブラウザ上で扱う情報の価値も高く、監査まで必要な環境では話が変わります。
その場合は「改ざんされたか」だけでなく、「どのScriptが承認済みで、何をし、どこへ通信し、いつ変わったか」を追えることに意味があります。

最初に感じた「セキュリティ対策のために新しい外部依存を増やすのってどうなの？」という違和感は、今でも判断軸の一つです。
ただ、調べ直してみると、それだけで市場全体を懐疑的に見るのも違いました。

外から見る、サーバーで戻す、ブラウザで挙動を見る、Edgeで制御する。
方式ごとに解いている問題が違います。

結局見るべきなのは、「改ざん検知」というラベルではなく、その製品がどこに入り、どういった役割をこなし、どの攻撃まで止められるのかを把握し、適切に運用していくことが大事です。