【2026年版】Googleポリシー「悪意のあるソフトウェア」停止復旧ガイド｜再審査前にやるべきサイト診断と申請整理
Google広告のキャンペーンが何の予告もなく突然停止し、管理画面に「悪意のあるソフトウェア」というポリシー違反通知が表示されたとき、広告主は数時間のうちに売上を失い続ける緊急事態に陥ります。Googleはこの違反を最も重大な部類の1つに位置づけており、確認されると事前警告なく即時の強制停止、そして再開は原則として困難という、極めて厳しい運用ルールが適用されます。配信を止められた瞬間から指名検索からのリスティング流入が消え、ECサイトの売上やリード獲得がストップします。
本記事では「悪意のあるソフトウェア」違反による広告停止からの復旧手順を、サイト診断フロー、技術原因の切り分け、再審査請求の進め方、再発防止策まで一気通貫で解説します。広告管理画面の操作ではなくサイト側の診断が中心になるため、広告運用担当者だけでなく、サイト保守を行うエンジニアや制作会社との連携が不可欠です。停止からの復旧を1日でも早く実現するための、現場で再現可能な手順書として整理しています。
結論を先に伝えると、停止の原因はほぼ間違いなく広告主側のサイトに技術的な問題が発生しており、サイト側の修正が完了するまで再審査請求を出しても通りません。「広告アカウントを別アカウントで作り直せば回避できる」という民間情報が散見されますが、これは追加でアカウント停止リスクを生む完全に誤った対応です。復旧の唯一の正攻法は、原因の特定→サイト修正→証跡整理→再審査請求の4ステップを正しい順序で踏むことです。緊急事態で困っている広告主の方は、ハーマンドットの緊急アカウント診断もご活用ください。
目次
「悪意のあるソフトウェア」違反でGoogle広告が止まる仕組み
Google広告で「悪意のあるソフトウェア」「マルウェア」「compromised site」と表示される違反は、Google側がランディングページや関連サイトをクロールしたタイミングで、悪意のあるコードが検出されたか、悪意のあるサイトへの強制リダイレクトが確認されたケースで発動します。広告主が意図的に悪質なコードを設置しているケースはまれで、ほとんどは自社サイトが何らかの形で侵害（compromised）されているか、外部のJavaScriptやプラグインに悪意のあるコードが混入したケースです。
Googleの判定アルゴリズムは複数のセキュリティスキャナーを組み合わせており、Google Safe Browsing、PhishTank、自社開発のクロウラーなど多層的な検出を行います。違反検出から広告停止までのタイムラグは通常1〜4時間で、土日や深夜も問わず即時に停止します。停止後はGoogle広告管理画面のキャンペーン一覧に赤いアイコンと「ポリシー違反による配信停止」の表示が出ます。
違反通知に記載されるメッセージは大きく3パターンに分かれます。1つ目は「マルウェアまたは望ましくないソフトウェア」で、サイト内に悪意のあるダウンロード可能ファイルが存在するケース。2つ目は「フィッシングまたは詐欺」で、フィッシングサイトへのリダイレクトや偽装フォームの埋め込みが検出されたケース。3つ目は「compromised site」で、サイト自体が乗っ取られて第三者の悪意あるコードが注入されているケースです。違反種別を最初に特定することが、復旧アクションの方向性を決める出発点になります。
厄介なのは、広告主自身が「自社サイトに悪意のあるコードが入っている」という自覚を持っていないことが大半である点です。WordPressなどのCMSを使っているサイトでは、プラグインの脆弱性を突かれて第三者にコードを注入されているケース、テーマファイルが改竄されているケース、外部から読み込んでいるJavaScriptが乗っ取られているケースなど、検出が難しい侵害が複数パターン存在します。「自社サイトは大丈夫」という思い込みが復旧を遅らせる最大の原因で、客観的なサイト診断ツールを使った調査が必要不可欠です。
サイト診断フローの初動48時間
違反通知を受け取ったら、最初の48時間で必ず実施すべき初動診断があります。この48時間で原因を正確に切り分けられるかどうかが、復旧までの総時間を決めます。慌てて再審査請求を出すと、未修正の状態で出すことになり「同じ違反でまた停止」を繰り返すので、まずは原因特定に集中します。
初動1番目はGoogle Search Consoleのセキュリティ問題セクションを確認することです。広告停止と同時または前後して、Search Consoleにも「セキュリティの問題」として侵害内容の詳細が記録されているケースが多くあります。Search Consoleの「セキュリティと手動による対策」レポートに具体的な感染URLや感染パターンが記載されていれば、それが復旧作業の最初の指針になります。何も表示されていない場合でも、Googleの判定が確定する前に広告だけ先に止まる場合があり、後日Search Consoleに反映されることもあります。
初動2番目はサードパーティのマルウェアスキャナーでサイト全体をスキャンすることです。Sucuri SiteCheck、VirusTotal、Quttera Web Malware Scannerなどの外部ツールに自社サイトのURLを入力すると、感染しているJavaScriptやリダイレクト先の悪意あるURLが検出されます。複数ツールでスキャンして結果を突き合わせると検出精度が上がります。
初動3番目はブラウザのデベロッパーツールを使ったネットワーク監視です。シークレットモードで広告のランディングページを開き、Networkタブで読み込まれるすべてのリクエストを確認します。見覚えのない外部ドメインへのリクエスト、特に短縮URLや暗号化されたパラメータを含むリクエストは、悪意あるコードの可能性が高いため要注意です。同時にConsoleタブでJavaScriptエラーや警告も確認します。
| 診断ツール | 主な検出対象 | 所要時間 | 有料/無料 |
|---|---|---|---|
| Google Search Console | Google判定の侵害内容詳細 | 5分 | 無料 |
| Sucuri SiteCheck | マルウェア・改竄・ブラックリスト | 5〜10分 | 無料（深度版有料） |
| VirusTotal | 複数エンジンによる総合判定 | 5分 | 無料 |
| Quttera | JavaScript・iframe・リダイレクト | 10〜15分 | 無料 |
| ブラウザDevTools | 動的読み込み・リダイレクト挙動 | 20〜30分 | 無料 |
これらの診断と並行して、サーバー側のアクセスログとファイル変更履歴も確認します。WordPressなどのCMSを使っている場合は、wp-content以下のファイル更新日時を最近変更されたものから順に並べ、自社が編集した記憶のない変更がないかをチェックします。FTPアクセスログで深夜帯や海外IPからの不審なログインがないかを確認することも重要です。
技術原因別の対処分岐とサイト修復手順
診断で原因が特定できたら、技術原因別に対処を分岐させます。広告主側で「悪意のあるソフトウェア」違反として最も多いパターンは大きく4種類で、それぞれ修復手順が異なります。複数のパターンが同時発生していることもあるため、1つ修正しただけで再審査請求を出すと再度停止になるリスクが高くなります。
パターン1はWordPressプラグインの脆弱性を突かれた侵害で、最も発生頻度が高いケースです。古いバージョンのプラグインや、長期間メンテナンスされていないプラグインが侵害の入り口になります。対処としては、すべてのプラグインを最新版に更新、不要なプラグインの削除、wp-content/plugins以下の改竄ファイル確認、wp-content/uploads以下に不審なPHPファイルが配置されていないかを確認します。改竄が確認された場合は、サイト全体のバックアップから侵害前の状態に戻すのが最も確実で、部分的な修正で済ませようとすると見落としが残ります。
パターン2はテーマファイルの改竄で、functions.phpやfooter.phpに悪意あるJavaScriptが注入されているケースです。アクセスログで管理画面への不審なログインや、テーマエディタからの編集履歴を確認します。テーマファイルにbase64エンコードされた長い文字列、eval関数、見覚えのない外部URLからのscript src読み込みがあれば、それが攻撃コードです。改竄行を削除し、ファイル所有者・権限を正しい状態に戻します。
パターン3は外部から読み込んでいるJavaScriptライブラリのCDNが乗っ取られたケースで、近年急増しているパターンです。jQueryやその他のライブラリを古いCDNから読み込んでいると、そのCDNが乗っ取られた瞬間にすべての訪問者に悪意あるコードが配信されます。外部CDNの読み込みは公式またはGoogle CDNなど信頼できるソースに限定し、Subresource Integrity（SRI）属性を必ず設定するのが防御策の基本です。
パターン4はサーバー側の侵害で、Webサーバーや関連サービスに対する不正アクセスでファイル全体が書き換えられているケースです。これはサーバー管理者でないと対処が難しく、レンタルサーバー会社のセキュリティ窓口に連絡してログ調査を依頼する必要があります。共有サーバーで同居しているサイトの侵害が波及するケースもあり、必要に応じてサーバー移転も視野に入れます。
サイト修復で絶対にやってはいけない対応
- 改竄ファイルを「とりあえず削除」して、原因究明をスキップしない
- WordPress管理画面のパスワードだけ変更して安心しない
- 侵害発覚時にDB情報まで含む完全バックアップを取らずに修復作業を始めない
- サイト全体を改めてスキャンせずに再審査請求を出さない
- 同じ管理者アカウントで作業を続け、第三者の権限残存を放置しない
復旧優先順位マップと役割分担
復旧作業は広告運用担当者・社内エンジニア・制作会社・サーバー管理者の4者が関与する複雑な対応になります。誰が何をいつまでに完了させるかを明確にしないと、責任の押し付け合いで時間だけが過ぎていきます。ハーマンドットでは緊急対応時に必ず復旧優先順位マップを作成し、関係者全員で共有することを徹底しています。
優先度1は「停止の事実共有と作業体制の確立」で、広告運用担当者が中心となり24時間以内に完了させます。広告停止通知のスクリーンショット、Google広告管理画面の違反詳細、現時点で判明している影響範囲を全関係者にメールやチャットで共有し、対応会議を即座にセットします。初動24時間でこの体制が組めないと、その後の48〜72時間も無駄になるのが緊急対応の鉄則です。
優先度2は「原因特定」で、社内エンジニアまたは制作会社が中心となり48時間以内に完了させます。前章で挙げたサイト診断フローを実行し、技術原因をパターン1〜4のいずれかに特定します。複数パターンが同時発生している場合もあるため、1つ見つけても深掘りを続けます。原因特定が遅れる最大の理由は「自社では分からないからサーバー会社に投げる」という丸投げで、サーバー会社側で対応が始まるまでさらに数日かかります。社内側で初期切り分けまでは必ず実施してください。
優先度3は「サイト修復」で、原因特定の結果を受けて社内エンジニア・制作会社・サーバー管理者が並行作業します。修復作業は概ね72時間以内を目安に進めます。修復作業中はステージング環境で必ず動作確認を行い、本番反映前にもう一度マルウェアスキャナーで再検査することを徹底します。修復したつもりが部分的に残っていた場合、本番反映後にGoogleの再クロールで再度違反検出されると再審査の信頼度が落ちます。
優先度4は「再審査請求の証跡整理」で、広告運用担当者がリードします。Google広告管理画面から再審査請求を出す際には、何を発見し、何を修正したかをテキスト記述するフォームがあり、ここに具体的な事実を時系列で記載できることが審査通過率を大きく左右します。修復作業中から各ステップのスクリーンショットや変更ログを保管しておく必要があります。
| 優先度 | タスク | 主担当 | 完了目安 |
|---|---|---|---|
| 1 | 停止事実共有・対応体制確立 | 広告運用担当者 | 24時間以内 |
| 2 | サイト診断・原因特定 | 社内エンジニア・制作会社 | 48時間以内 |
| 3 | サイト修復・ステージング検証 | エンジニア・サーバー管理者 | 72時間以内 |
| 4 | 証跡整理・再審査請求 | 広告運用担当者 | 修復完了+24時間 |
| 5 | 再発防止策の実装 | セキュリティ責任者 | 修復完了+2週間 |
再審査請求の正しい出し方と通る理由
サイト修復が完了したら、Google広告管理画面から再審査請求を出します。再審査請求は単に「修正したのでチェックしてください」と書いても通りません。何が発生し、原因をどう特定し、どのように修正したかを、Googleの審査担当者が技術判断できる粒度で記述する必要があります。再審査請求のフォームには記述欄が用意されており、ここに記載する内容が審査通過の鍵になります。
再審査請求の文章は、4つの構成要素で組み立てます。1つ目は「違反検出時の状況」で、検出日時、影響範囲、初動で確認した事実を簡潔にまとめます。2つ目は「原因究明のために実施した調査」で、使用した診断ツール、確認したログ、特定した侵害箇所を技術的に記載します。3つ目は「実施した修復作業」で、削除したファイル、更新したプラグイン、変更したパスワード、復元したバックアップなどを箇条書きで明確に記載します。4つ目は「再発防止策」で、今後同種の違反を起こさないための仕組みを記述します。
文章量の目安は400〜800字程度で、長すぎても短すぎても審査担当者の判断を遅らせます。事実関係のみを淡々と記載し、感情的な表現や「Googleさんお願いします」のような懇願は逆効果です。Googleの審査担当者は世界中の事例を毎日処理しており、技術的事実が整理されているリクエストほど通りやすくなります。
再審査請求を出してから審査完了までの所要時間は、通常2〜5営業日ですが、緊急性の高い違反の場合は1営業日以内に判定が出ることもあります。判定結果は広告管理画面の通知と登録メールアドレスに届きます。通過した場合は即座に配信が再開され、通過しなかった場合は同じフォームで追加情報を提示できるので、諦めずに2回目・3回目と粘るのが正攻法です。1回目で通らなかったケースの多くは、修復内容の説明が技術的に不十分だったか、追加で発見されるべき侵害が残存していたケースです。
注意すべきは、再審査請求の処理中に同じサイトで再度違反が検出されると、審査自体がリセットされて初期段階に戻ることです。再審査請求を出した後は、修復後のサイトに対して継続的にマルウェアスキャナーをかけ、新たな侵害が発生していないかを毎日確認します。ステージング環境でテストせずに本番直接修正をすると、修正中に新たな脆弱性が露出することもあります。
再発防止のためのセキュリティ運用設計
復旧が完了しても、再発防止策を講じなければ同じ違反を再度引き起こす可能性が高くなります。1度目の侵害で攻撃者が把握した脆弱性は、修正していない他の経路から再利用されることが多く、再発した広告主のうち6割以上が3カ月以内に2度目の侵害を経験しています。継続的なセキュリティ運用設計が、長期的な広告投資の安全性を担保します。
第1の再発防止策は、WordPressなどのCMSとプラグインを自動更新する仕組みの導入です。手動更新は更新漏れが発生するため、Wordfence、Sucuri Security、iThemes Securityなどのセキュリティプラグインを導入し、自動更新と異常検出を仕組み化します。セキュリティプラグインの月額費用は500〜2,000円程度で、広告停止1回の機会損失と比べれば桁違いに安い投資です。
第2の再発防止策は、サイト全体のバックアップを毎日自動取得する仕組みの導入です。VaultPress、UpdraftPlus、BackWPupなどのバックアップツールを使い、データベースとファイルの両方を毎日異なる場所に保管します。万一侵害された場合に、過去30日間のいずれかの状態に戻せる体制があると、復旧時間を大幅に短縮できます。クラウドストレージ（AWS S3、Google Cloud Storage）への外部保管が、サーバー自体が侵害された場合のリスクヘッジになります。
第3の再発防止策は、管理画面アクセスの制限です。WordPressのwp-loginページに対するIPアドレス制限、二要素認証の必須化、管理者アカウントの最小化を実施します。「admin」「administrator」のようなデフォルトユーザー名は必ず変更し、強固なパスワードと二要素認証を組み合わせるのが基本動作です。退職した社員や取引終了した制作会社のアカウントは速やかに削除します。
第4の再発防止策は、外部から読み込むJavaScriptの管理です。Google Tag ManagerやGoogle Analytics以外の外部スクリプトは、必要最小限に絞り、各スクリプトのドメインを明示的にホワイトリスト化します。Content Security Policy（CSP）ヘッダーをサーバー側で設定し、許可していない外部ドメインからのスクリプト実行をブロックします。CSP設定はSEOやアクセス解析に影響を与える可能性があるため、ステージング環境で十分に検証してから本番反映してください。
停止期間中の機会損失を最小化する代替施策
サイト診断・修復・再審査請求の所要時間は、最短でも4〜7日、複雑なケースでは2〜3週間を要します。この期間中も自社の売上やリード獲得を完全に止めるわけにはいかないため、Google広告以外の流入経路を活用した代替施策を平行して走らせます。1社単独で対応すると人的リソースが足りなくなるため、社内チームと代理店で役割分担します。
代替施策1はYahoo!広告、Microsoft広告、Meta広告など、Google以外の広告媒体の出稿強化です。すべての媒体で同時違反は通常起きないため、Google停止中も他媒体は配信可能です。Google停止が確認できた時点で、Yahoo!広告の予算を1.5〜2倍に増額する運用を即日実施することで、検索面の流入の一部を補填できます。媒体間でクリエイティブを使い回せるよう日頃から整備しておくのが理想です。
代替施策2は自然検索とMEO経由の流入の最大化です。Search Consoleで自社サイトに「セキュリティの問題」が出ている場合、自然検索順位も同時に下落することがあり、両方の影響を受けるとオーガニック流入も大きく減少します。違反が確認された日から1週間以内にサイトの修復を完了させないと、検索順位回復にも数週間〜数カ月かかるため、Google広告だけでなく自然検索保護の観点からも修復スピードが重要です。
代替施策3はメールマーケティングとSNSによる既存顧客への接触強化です。Google広告で新規獲得が止まっている期間は、既存顧客や見込み顧客リストへの能動的なアプローチで売上を補います。メールマガジンの配信頻度を一時的に上げる、SNSアカウントからの投稿を増やす、リターゲティング以外の手段で既存接点を活用します。広告停止期間が長引くほど、これらの自社チャネルの重要性が増します。
代替施策4は、リファラル経由の流入強化です。既存顧客に紹介依頼をする、業界メディアへの寄稿や取材対応を加速する、提携先からのトラフィックを増やすなど、広告に依存しない流入経路を意識的に増やします。これは平時から取り組むべきですが、緊急時には特に重要性が浮上します。
ハーマンドットが緊急停止対応で支援できること
ハーマンドットでは広告運用代行の支援先で「悪意のあるソフトウェア」違反による停止対応を、2024年以降で12社サポートしてきました。広告管理画面操作だけでなくサイト診断・修復・再審査請求まで含めた一気通貫の対応が可能で、最短で停止から復旧までを5日間で完了させた事例があります。緊急時にすぐ動ける体制があるか、そしてサイト診断のリソースを持っているかが、緊急停止対応で代理店を選ぶときの最重要ポイントです。
支援フローとしては、停止通知を受け取った時点で24時間以内に緊急対応会議を設定し、初動48時間でサイト診断を完了させます。社内エンジニアと連携してパターン1〜4の原因切り分けを行い、修復作業の方針を決定します。修復作業自体はサーバー管理権限が必要な部分は広告主側で実施いただきますが、ハーマンドット側でステージング検証、再審査請求文章の作成、Googleとの追加やり取りまでをサポートします。
過去の支援事例として、月額広告予算800万円のEC事業者が「マルウェア」違反で停止したケースでは、WordPressプラグインの脆弱性を突かれたパターン1の侵害が判明し、サイトのバックアップ復元とすべてのプラグイン更新、管理画面アクセス制限の追加で5日間で復旧しました。停止期間中のYahoo!広告増額対応により、Google停止による売上影響を当初想定の60%まで縮減できました。復旧後は同種の違反防止のためにWordfenceの導入、月次のセキュリティ点検レポートの提供、四半期に1回の脆弱性診断を継続支援しています。
もう1つの事例として、月額広告予算300万円のBtoB SaaS事業者がcompromised siteパターンの停止を受けたケースでは、CDNから読み込んでいた古いjQueryライブラリが侵害されていたことが判明しました。CDNを公式版に切り替え、SRI属性を全外部スクリプトに設定し、CSPヘッダーを導入する形で7日間で復旧しています。原因が外部CDNだったため、自社サイト内のスキャンでは検出できず、ブラウザDevToolsでのネットワーク監視で初めて特定できた事例で、診断手法の幅広さが復旧速度を左右することを示しています。
業種別に発生しやすい侵害パターンと事前対策
「悪意のあるソフトウェア」違反は業種を問わず発生しますが、業種ごとに侵害されやすい経路や標的にされやすいファイル構成には傾向があります。自社の業種特性を把握しておくと、事前にリスクが高い部分を重点的に守る運用設計ができ、再発防止の費用対効果も大きく向上します。
EC事業者は商品データ・顧客データを扱う関係でデータベースを狙われやすく、決済関連のJavaScriptがフィッシング目的で改竄される傾向があります。WooCommerce、Shopify以外のEC構築プラグインを使っているサイト、独自開発のショッピングカートシステムを長期間メンテナンスしていないサイトは、脆弱性が累積しているケースが多くなります。EC事業者はPCI DSSの基本対策（決済画面のHTTPS化、決済情報の自社サーバー非保持、3Dセキュア対応）に加え、月次のセキュリティスキャンを必ず実施することが推奨されます。
美容クリニック・医療機関は患者情報を扱う関係でフィッシング目的の侵害を受けやすく、予約フォームに偽装したフィッシングフォームを埋め込まれるケースが報告されています。医療機関向けに開発されたCMSや予約システムには、汎用CMSと比べて利用者数が少なくセキュリティパッチの提供頻度が低いものもあり、注意が必要です。SSL証明書の有効期限切れ、管理画面のIP制限なし、テスト環境を本番と同じドメインで動かしているといった基本不備が侵害の入り口になります。
BtoB企業はリードフォームから情報を抜くタイプの攻撃を受けやすく、HubSpotやSalesforceに送信されるフォームデータを途中で傍受される改竄パターンがあります。コーポレートサイトのプレスリリースページや採用情報ページが、サーバー権限の弱い部分から改竄されているケースもあり、メインの製品ページだけ守っていてもサイト全体の信頼が落ちます。サブドメインや別ドメインで運用している採用サイト・ブログサイトも、本体と同じレベルのセキュリティ運用を適用することが重要です。
採用領域では求職者向けのコンテンツが多くあり、PDF応募書類のダウンロードリンクなどに悪意あるファイルが置き換えられる事例があります。サーバー側で.pdfや.docxファイルへのアクセスログを取り、見覚えのないIPからのアップロードがないかを監視する運用が望ましいです。
停止経験を組織のセキュリティ文化に変換する
「悪意のあるソフトウェア」違反による広告停止は、その場で復旧すれば終わりという性質のものではありません。停止経験を組織のセキュリティ運用文化に変換できるかどうかが、長期的な事業リスクの低減に直結します。停止対応で得られた知見を組織知として残し、関係者全員で共有する取り組みを必ず実施してください。
第1の取り組みは事後検証ミーティングです。復旧完了後1〜2週間以内に、広告運用担当者・社内エンジニア・制作会社・サーバー管理者を集め、何が起こり何を学び何を変えるかを整理します。責任追及ではなく学習を目的とすることが重要で、「誰が悪かった」ではなく「どんな仕組みがあれば防げたか」に議論を集中させます。事後検証で明確にすべきは、発生から検知までの時間、検知から共有までの時間、復旧までの所要時間、再発防止のために変える運用の4つです。
第2の取り組みはセキュリティチェックリストの更新です。今回の侵害で明らかになった脆弱性経路を組織のセキュリティチェックリストに加え、新規Webサイト立ち上げ時や年次のセキュリティ点検時に必ず確認するようにします。チェックリストは紙ベースではなく、運用ツール（NotionやConfluenceなど）で共有し、更新履歴も追えるようにすると属人化を防げます。
第3の取り組みは経営層への報告と予算確保です。停止による機会損失額、復旧費用、再発防止策の費用を試算し、経営層に対してセキュリティ投資の必要性を訴えます。1度の停止で数百万〜数千万円の機会損失が出る業種では、年間のセキュリティ投資を売上の0.5〜1%確保することがリスクとリターンのバランスとして妥当です。経営層に「セキュリティ投資は単なるコストではなく、広告投資全体を守る保険」と理解してもらうことが、継続的な改善のための予算確保に直結します。
第4の取り組みは関係者の継続学習です。WordPressやCMSの新しい脆弱性情報、Googleのポリシー更新、業界全体のセキュリティ動向を月次でキャッチアップする仕組みを作ります。情報収集は社内Slack等のチャンネルで定期共有することで、関係者全員のセキュリティ意識が底上げされます。1人の専門家に依存する体制では、その人が不在のときに対応が止まるため、複数人で知識を共有することが組織のレジリエンスを高めます。
停止直後の関係者コミュニケーション設計
広告停止が発生した瞬間に、社内・取引先・顧客に対してどう伝えるかという情報設計も、復旧と並行して必須の作業になります。沈黙していると関係者の不安が増幅し、噂が広がり、最悪の場合は風評被害につながります。正確な情報を、必要な範囲に、適切なタイミングで伝える設計が、ブランド価値を守る上で重要です。
社内向けには、停止発覚から1時間以内に、経営層・営業部門・カスタマーサポート部門に第一報を入れます。「Google広告のキャンペーンが停止しています。現在原因を調査中で、復旧見込みについては夕方までに第二報を入れます」という事実ベースの簡潔な共有で十分です。営業部門には停止期間中の商談見込みへの影響を伝え、カスタマーサポートには顧客から「広告が出ない」という問い合わせが入った場合の暫定回答を用意します。
取引先や提携先に対しては、影響範囲が明確になってから連絡します。アフィリエイトパートナーや業務提携先がある場合、自社サイトへの誘導が一時的に止まることを伝え、代替手段を提示します。代理店経由で広告運用を委託している場合は、代理店側が状況把握と関係者連絡の主担当を担うため、広告主側は社内連絡に専念できる体制が整っているかが確認ポイントになります。
顧客に対しての公開的な発表は、原則として不要です。広告停止を顧客向けに公表すると不要な不安を与えるだけでなく、攻撃者に「侵害が成功した」というシグナルを送ることになり、追加攻撃を呼び込むリスクがあります。個別の問い合わせには「現在サイトメンテナンス中」「広告システムの再構築中」といった、過度に詳細でない事実説明にとどめるのが原則です。ただし、顧客情報の漏洩が確認された場合は別で、法令に基づく公表義務が発生します。
復旧後30日間の経過観察と再評価サイクル
再審査請求が通過して広告配信が再開されても、そこから30日間は通常運用に戻る前の経過観察期間として位置づけます。完全に修復したと判断していても、同種の侵害が別の経路から発生したり、Googleの再クロールで別の問題が検出されたりするリスクがゼロではありません。経過観察期間中は、通常の月次運用とは別に追加チェックを行います。
復旧後1週目は、毎日サイト全体のマルウェアスキャンを実施し、新たな侵害が発生していないかを確認します。同時に、Google広告管理画面のポリシー違反通知、Google Search Consoleのセキュリティ問題セクション、サーバーログの異常を毎日確認します。復旧後1週目に異常がなければ、攻撃者が同じ経路で再侵害を試みている可能性は大きく下がると判断できます。
復旧後2〜4週目は、スキャン頻度を週2〜3回に下げつつ、サーバーログの分析を深掘りします。アクセスログでBOT判定された不審アクセス、エラーログでの異常なリクエスト、データベースアクセスログで権限外のクエリなどを確認します。攻撃者が一度諦めて、別の経路から再侵入を試みるパターンは1〜3カ月後に発生することが多く、復旧直後だけでなく中長期での監視継続が必要です。
30日経過時点で、復旧対応の事後検証レポートを作成します。発生から復旧までのタイムライン、技術原因、実施した修復、機会損失額、再発防止策の進捗を整理し、経営層に提出します。このレポートが組織知として残ることで、将来同種の問題が発生した際の対応スピードが圧倒的に向上します。事後レポートは個人の暗黙知に留めず、組織のドキュメント管理ツール（Notion、Confluence、SharePoint等）に保管することが重要です。レポートには、停止時の広告管理画面スクリーンショット、Search Consoleの記録、サイトスキャナーの検出結果、修復後の検証結果、再審査請求の文章と通過判定の全文を、添付資料として残しておくと、後で類似事案の参考になります。組織内で年に1回程度、過去の停止事例を振り返り、対応プロセスの改善点を洗い出すレビュー会を実施すると、復旧スキルが組織全体に定着します。
復旧後の経過観察を1人の担当者だけに任せると、その人が休暇や離職した場合に観察が止まります。最低2人の担当者でローテーションを組み、毎日のスキャン結果を交代でレビューする運用が、長期にわたる監視体制を維持するための仕組みになります。経過観察期間中に得られた知見は、再発防止のチェックリストにも順次反映していき、生きた運用ドキュメントとして育てていく姿勢が、組織のセキュリティ成熟度を高めていきます。
30日経過後にすべての異常がゼロであれば、通常運用に戻します。ただし「悪意のあるソフトウェア」違反を1度経験したサイトは、再発リスクが平均より高いことを認識し、月次のセキュリティ点検を半年〜1年は継続することが推奨されます。広告投資の規模が大きいほど、停止1回あたりの機会損失は大きくなるため、点検費用は十分にペイします。具体的な金額感としては、月額広告予算500万円規模の事業者であれば、月次セキュリティ点検に月額3〜5万円を投じても、停止1回の機会損失（広告予算1日分+復旧期間中の売上減）を回避できれば1回でペイします。年間で見ると、点検費用50〜60万円に対して、年1回の停止を防ぐだけで数百万〜数千万円のリスク回避になります。経営層に対しては「保険」として位置づけて説明すると、予算確保の同意を得やすくなります。点検会社の選定では、WordPress特化のSucuri、サーバー保守を兼ねるWPMU DEVのDefender Pro、国内サポート付きのSiteGuard WPプラグインの組み合わせなど、サイト規模と社内体制に応じた選択肢を比較検討してください。複数の事業所・サイトを運営している企業では、横断的に管理できるダッシュボード型ツール（CloudflareのSecurity Center、imunify360など）の導入も検討価値があります。点検プロセスを自社で内製化するか、外部委託するかの判断軸は、社内エンジニアのリソースと専門性、年間に発生する保守対応件数、停止リスクの許容範囲の3点で決めると整理しやすくなります。社内エンジニアが他業務で逼迫している事業者は、外部委託のほうが結果的に安く済むケースが多いです。逆に、サイトを多数運用する大手事業者は内製化のスケールメリットが効きます。なお、社内のセキュリティ担当者がいない事業者は、まずは月額数千円のセキュリティプラグインから始め、3〜6カ月運用しながら社内で知見を蓄積し、必要に応じて外部委託に切り替えるという段階的なアプローチが現実的です。最初から完璧な体制を組もうとして動かないより、最低限の自動化を導入して走り出すほうが、結果的にリスクを下げられます。導入後の1〜2カ月は誤検知やアラートノイズが出ることもありますが、運用しながらチューニングしていくのが現実的です。アラートが多すぎて慣れによる見落としが起きないよう、重要度別にアラートをふるい分けるルール設計を、運用開始から3カ月以内に整備するとよいでしょう。緊急対応すべきアラート、翌営業日対応で十分なアラート、ログとして残すだけでよいアラートの3層に分け、各層ごとに通知先・対応期限・エスカレーション基準を明文化しておくのが基本です。停止経験のない事業者ほど「自社は大丈夫」と思いがちですが、業界平均で年間で数%の事業者が広告停止を経験しているという現実を踏まえて、平時から対策しておくことが、長期的な広告投資を守る最大の保険になります。
まとめ
「悪意のあるソフトウェア」違反による広告停止からの復旧は、サイト診断・修復・証跡整理・再審査請求の4ステップを正しい順序で踏むのが唯一の正攻法です。慌てて再審査請求を出すと未修正の状態で同じ違反を繰り返すため、初動48時間で原因特定に集中することが復旧時間を短縮する最大のポイントになります。停止期間中はYahoo!広告やメール、SNSなど他チャネルの強化で機会損失を最小化し、復旧後は再発防止の継続運用を仕組み化することが、長期的な広告投資の安全性を守ります。
- 初動48時間で原因特定に集中。慌てて再審査請求を出さず、まずはサイト診断ツールで侵害箇所を確定させる
- 修復はステージング検証付きで実施。本番直接修正は新たな脆弱性露出のリスクがある
- 停止期間中は他媒体・自然検索・自社チャネルで機会損失を補填し、1チャネル依存のリスクを下げておく
まずは無料で広告アカウント診断を
「悪意のあるソフトウェア」違反で現在広告が停止している、または過去に停止経験があり再発防止策を組みたい広告主の方は、ハーマンドットの無料アカウント診断をご利用ください。現在のアカウント状況、サイトのセキュリティ運用、復旧の進捗、再発防止策の整備状況を30分のオンラインミーティングで整理し、緊急対応または再発防止の実行プランを提示します。
初回相談は完全無料・所要時間30分・オンライン対応可能です。停止中の方は、対応開始から復旧までを最短ルートで設計し、代替施策による売上補填も含めて全体最適でご提案します。再発防止策を組みたい方も、現状の脆弱性チェックリストと運用設計の改善案までお伝えします。緊急性の高いご相談には優先対応しますので、現在停止中の方はお問い合わせフォームに「緊急」と明記してご連絡ください。