WordPressでGDPR向けの同意バナーを自作して運用していた私が、Google公式プラグインSite KitでConsent Modeを有効にしたところ、サイトヘルス（Site Health）にこんな推奨項目が出ました。
One or more plugins are not conforming to the Consent API.
（Consent APIに準拠していないプラグインがあります）
「え、昨日まで出てなかったのに？」「自作バナーが原因？」「開発者に総当たりで連絡しろってこと？」と、一瞬ヒヤッとしたので、仕組みから徹底的に調べて整理しました。
この記事は“実体験ベースの調査メモ”として、同じ表示に出会った人が最短で状況判断できるようにまとめています。
結論：これは致命的エラーではなく、移行期に出やすい「注意喚起」
まず安心ポイントから。サイトヘルスのこの表示は、たいていの場合サイトが壊れているとか即アウトという類ではありません。
- Site KitのConsent ModeをONにすると、WordPress側で同意情報を受け渡す仕組みが必要になります
- そこで登場するのがWP Consent API（同意の“共通言語”）です
- ただ、現状はまだエコシステム全体で対応（宣言・実装）が追いついていないため、未対応プラグインがあるという推奨が出がちです
大事なのは、ここから先で「自分のサイトの構成だと放置して良いのか」を判断することです。
まず整理：Consent Mode / WP Consent API / CMP（同意バナー）の関係
混乱の原因は、似た言葉が多いこと。ここを一度だけ整理します。
1) Consent Mode（Google側）
Googleのタグ（Analytics / Adsなど）が、ユーザーの同意状態に応じて動作を変える仕組みです。Site Kitは、Consent ModeをONにすると、同意状態に沿ってタグのふるまいを制御するための設定・コードを扱います。
2) WP Consent API（WordPress側の“同意の共通言語”）
WP Consent APIは同意バナーを表示するプラグインではありません。同意を取得する仕組み（CMP／同意バナー）と、同意に応じて動作を変えたいプラグインの間で、同意状態を共通の方法で受け渡しするためのAPIです。
3) CMP（同意管理プラグイン） / 自作同意バナー
ユーザーの「許可/拒否」を取って保存し、必要なら各タグやプラグインの挙動を制御する実働担当です。自作の場合は、この“実働”を自分で作ることになります。
なぜ突然サイトヘルスに警告が出たのか（私のケース）
私の環境はこうでした。
- 同意バナー：自作（JavaScriptで表示・保存）
- 計測：Google Analytics（Site Kitで連携）
- 最近やった変更：Site KitでConsent Modeを有効化
この状態でConsent ModeをONにしたことで、WordPress側は「同意を受け渡す基盤」としてWP Consent APIを前提にした世界に入り、サイトヘルスが「このプラグインたちはConsent API対応（宣言/実装）してないよ」と教えてくる、という流れでした。
ここで重要なのは、“未対応＝必ず悪”ではないということです。プラグインによっては、そもそも同意に関係しない（必須Cookieなど）場合もあるし、同意が必要でもまだ対応が追いついてない場合もあります。
放置していい？ 連絡すべき？ 判断のコツ（連絡地獄を回避）
私は「全開発者に連絡」はやめました。代わりに、サイトヘルスに出ている未対応プラグインを“同意に関係する可能性”で分類しました。
A：優先度 高（要チェック）
- 広告タグ、Google Ads、アフィリエイト計測
- Analytics、ヒートマップ、アクセス解析
- SNS埋め込み（外部読み込みがあるもの）
- タグ管理系（GTMなど）
これらは同意と絡みやすいので、「同意拒否でも動いていないか」をまず確認。未対応が明確に問題なら、置換検討 or 開発者に連絡、が現実的です。
B：優先度 中（状況次第）
- 会員/EC/フォーム/チャットなど、Cookieを置く可能性がある機能系
「同意が必要な種類のCookieなのか」「必須Cookieなのか」で判断が変わります。
C：優先度 低（基本スルーでOK）
- キャッシュ
- セキュリティ
- バックアップ
- 管理画面の便利系
この辺は同意の文脈と直接関係しないことも多く、警告が出ていても実害がないケースが多いです。
一番大事：自作同意バナーをWP Consent APIに“接続”する
ここが今回の核心でした。
自作バナーのままだと、Site Kit（Consent Mode）や、同意を参照したいプラグインが同意状態を参照する手がかりを持てません。そこで、自作バナーの「ユーザーの選択結果」をWP Consent APIへ通知します。
概念としてはこうです。
- （地域や方針に応じて）同意タイプ（opt-in / opt-out）を定義する
- ユーザーの選択に応じて、カテゴリごとに allow/deny をセットする
例（イメージ）：
// 例：opt-inとして扱う（地域・方針に応じて決める）
window.wp_consent_type = 'optin';
document.dispatchEvent(new CustomEvent('wp_consent_type_defined'));
// 例：ユーザーの選択結果をカテゴリ別に通知
wp_set_consent('statistics', 'allow'); // 解析OK
wp_set_consent('marketing', 'deny'); // 広告NG
ポイント：WP Consent APIは「入れただけ」で勝手に全プラグインを止めてくれる仕組みではありません。CMP（または自作バナー）が同意状態を提供し、参照側（プラグイン）がそれを見て制御する、という役割分担です。
ありがちな落とし穴：Consent Modeが二重に動く（競合）
Site KitのConsent ModeをONにしたのに、別の同意系プラグインやタグ管理側でもConsent Mode相当をONにしていると、設定が競合して挙動が読めなくなることがあります。
私は「Consent ModeはSite Kit側に寄せる」「同意の取得は自作バナー」「同意の受け渡しはWP Consent API」を基本方針にしました。
確認方法：同意拒否時に“本当に止まっているか”を見る
説得度を上げるなら、ここをスクショ付きで書くと強いです。
おすすめの確認手順
- 同意バナーで「拒否」を選ぶ
- ブラウザの開発者ツールで Network / Application（Storage/Cookies）を見る
- Analyticsや広告系のリクエスト（例：collect系）が飛んでいないか確認
- Cookieが意図せず作られていないか確認
「未対応プラグイン」が多すぎるときの現実解
- まずはA（計測/広告/外部読み込み）だけ対応方針を決める
- Bは必要なら（本当に同意が必要なCookieかを確認）
- Cは基本放置（推奨項目として残ってもOK）
開発者への連絡をする場合も、「同意が必要な挙動があるならWP Consent API対応を検討してほしい」という形で、短く丁寧に依頼すると良いです。
開発者に送る連絡テンプレ（英語）
Hi! I’m using WP Consent API via Site Kit Consent Mode on WordPress.
Your plugin appears in Site Health as “not conforming to the Consent API”.
If your plugin sets cookies or runs tracking scripts, could you consider adding WP Consent API integration
(or at least declaring compliance if consent isn’t needed)?
Thank you!まとめ：私の最終判断
- この警告は多くの場合、致命的エラーではない
- 重要なのは、計測/広告系が同意に従って止まるかを確認すること
- 自作バナーの場合は、WP Consent APIに同意結果を渡す実装が肝
- 未対応プラグインの総当たり連絡はせず、優先度で仕分けして対応
FAQ
Q. これが出たらGDPR的に即アウト？
この表示自体が「違反確定」を意味するわけではありません。WP Consent APIは同意取得を行わず、同意の受け渡しの仕組みなので、まずは自サイトの同意設計と実装の整合性を確認するのが先です。
Q. 自作バナーのままでも運用できる？
可能ですが、Consent Modeや他プラグインが同意状態を参照できるように、WP Consent APIへ同意結果を通知する設計にすると安全です。
Q. Site Healthの推奨項目が気になるので消したい
どうしても気になる場合は、Consent Mode運用の方針（ONにする必要があるか）から見直すのが近道です。目的がなければOFFに戻すのも選択肢です。
※本記事は技術的な整理であり、法務判断（GDPR等の遵守）を保証するものではありません。運用方針は必要に応じて専門家に確認してください。
コメント