Site KitでConsent API警告対処

警告の正体
Consent Mode / WP Consent API / CMP の3層
私の環境で起きていたこと
放置していいのか、連絡すべきなのか
1. 開発者に送る文面（英語）
自作バナーをWP Consent APIにつなぐ
Consent Modeの二重管理という落とし穴
拒否したあと、本当に止まっているか
関連記事
FAQ

2026年1月。前日まで出ていなかった推奨項目が、WordPressのサイトヘルスに増えていました。

One or more plugins are not conforming to the Consent API.
（Consent APIに準拠していないプラグインがあります）

心当たりはひとつだけありました。前日、Google公式プラグインSite KitでConsent ModeをONにしています。

「GDPR向けの同意バナーを自作しているのが原因か」「未対応プラグインの開発者に総当たりで連絡しろということか」と一瞬ヒヤッとしましたが、どちらも違いました。この表示は致命的エラーではありません。Consent ModeをONにしたことで、WP Consent APIに未対応のプラグインが検出されるようになっただけです。やることは2つ。計測系と広告系が同意拒否でちゃんと止まるかを自分の目で確かめること、そして自作バナーの選択結果をWP Consent APIへ通知する実装を足すこと。仕組みから調べ直した内容を、以下に整理しました。

検証環境：WordPress 6.8.3 / Cocoon 2.8.9 / Site Kit 1.174.0 / Xserver / PHP 8.3.21（2026年1月時点）

警告の正体

サイトヘルスのこの表示は、たいていの場合サイトが壊れているとか即アウトという類ではありません。

Site KitのConsent ModeをONにすると、WordPress側で同意情報を受け渡す仕組みが必要になります。そこで登場するのがWP Consent API、同意の共通言語です。ただ、いまはまだエコシステム全体で対応（宣言・実装）が追いついていないようです。だから未対応プラグインがある、という推奨が出がちになります。

サイトヘルスの推奨項目は、永続オブジェクトキャッシュのときもそうでしたが、出たからといって全部を潰しにいく必要はありません。ここから先は、自分のサイトの構成だと放置していいのか、という判断になります。

Consent Mode / WP Consent API / CMP の3層

混乱するのは似た言葉が3つ並ぶからです。担当範囲が違います。

1) Consent Mode（Google側）

Googleのタグ（Analytics / Adsなど）が、ユーザーの同意状態に応じて動作を変える仕組みです。Site KitはConsent ModeをONにすると、同意状態に沿ってタグのふるまいを制御するための設定・コードを扱います。

2) WP Consent API（WordPress側の共通言語）

WP Consent APIは同意バナーを表示するプラグインではありません。同意を取得する仕組み（CMP／同意バナー）と、同意に応じて動作を変えたいプラグインの間で、同意状態を共通の方法で受け渡すためのAPIです。

プラグインを公開している側から見ると、「準拠」の実体は思ったより小さい話です。同意が要らない挙動しかしないプラグインなら、宣言はフィルタ1行で済みます。

// 「このプラグインはConsent APIに準拠しています」と宣言する
add_filter( 'wp_consent_api_registered_' . plugin_basename( __FILE__ ), '__return_true' );

1 2	// 「このプラグインはConsent APIに準拠しています」と宣言する add_filter( 'wp_consent_api_registered_' . plugin_basename( __FILE__ ), '__return_true' );

Cookieを置いたり外部スクリプトを読んだりする場合は、そこに同意状態を見る分岐が足されます。

if ( function_exists( 'wp_has_consent' ) && wp_has_consent( 'statistics' ) ) {
    // 解析タグを出す
}

if ( function_exists( 'wp_has_consent' ) && wp_has_consent( 'statistics' ) ) {

// 解析タグを出す

}

つまりサイトヘルスに並んでいる未対応プラグインの多くは、対応が技術的に難しいのではなく、まだ宣言していないだけ、という状態です。【要確認：Rapls Works公開プラグイン4本がこの宣言を入れているかを確認して、入れていないなら「自分のプラグインも入っていなかった」と正直に書くほうが強い】

3) CMP（同意管理プラグイン）/ 自作同意バナー

ユーザーの許可・拒否を取って保存し、必要なら各タグやプラグインの挙動を制御する実働担当です。自作の場合は、この実働を自分で作ることになります。

CMPプラグインとしてはComplianzが有名ですが、Cocoonテーマとの組み合わせでスマホメニューが壊れるCSS競合を踏みました。私が自作バナーに切り替えたきっかけの一つがこれです。

私の環境で起きていたこと

同意バナーは自作（JavaScriptで表示・保存）、計測はGoogle AnalyticsをSite Kit経由で連携、そこにConsent Modeの有効化が乗りました。

この状態でConsent ModeをONにしたことで、WordPress側は同意を受け渡す基盤としてWP Consent APIを前提にした世界に入ります。そしてサイトヘルスが「このプラグインたちはConsent API対応（宣言／実装）してないよ」と教えてくる、という流れでした。

ただし未対応イコール悪、ではありません。そもそも同意に関係しないプラグイン（必須Cookieだけを扱うものなど）もあれば、同意が要るのに対応が追いついていないものもあります。

放置していいのか、連絡すべきなのか

全開発者への総当たり連絡はやめました。代わりに、サイトヘルスに出ている未対応プラグインを、同意に関係する可能性で3段階に分けました。

優先度高は、広告タグ・Google Ads・アフィリエイト計測、Analytics・ヒートマップ・アクセス解析、外部読み込みのあるSNS埋め込み、GTMなどのタグ管理系。同意と絡みやすいので、まず「同意拒否でも動いていないか」を確認します。拒否しても動いていたなら、置換を検討するか開発者に連絡、が現実的なところです。

優先度中は、会員・EC・フォーム・チャットのように、Cookieを置く可能性がある機能系。同意が必要な種類のCookieなのか、必須Cookieなのかで判断が変わります。

優先度低は、キャッシュ、セキュリティ、バックアップ、管理画面の便利系。同意の文脈と直接関係しないことも多く、推奨項目として残っていても実害がないケースがほとんどです。

複数のWordPressサイトを保守している立場で言うと、この推奨項目自体はそれなりの頻度で見かけます。まだ移行期なので、未対応が数個並ぶのはむしろ普通の状態です。だから未対応の数を0にすることを目標にせず、優先度高だけ対応方針を決めて、中は必要なら確認、低は残ったままでいい、という線を引きました。【要確認：この一段落、クライアント案件の内情に踏み込んでいないか最終確認を】

開発者に送る文面（英語）

連絡する場合も、短く済ませました。

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!

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につなぐ

ここが一番手を動かした部分です。自作バナーのままだと、Site Kit（Consent Mode）も、同意を参照したいプラグインも、ユーザーが何を選んだのかを知る手がかりを持てません。バナーが取った選択結果を、WP Consent APIへ通知してやる必要があります。

書くコードは概念としてはこれだけです。

// 1. 同意タイプを宣言する（地域・方針に応じて optin / optout を決める）
window.wp_consent_type = 'optin';
document.dispatchEvent(new CustomEvent('wp_consent_type_defined'));

// 2. バナーで「同意」が押されたとき
wp_set_consent('statistics', 'allow');
wp_set_consent('marketing',  'allow');

// 3. 「拒否」が押されたとき
wp_set_consent('statistics', 'deny');
wp_set_consent('marketing',  'deny');

// 1. 同意タイプを宣言する（地域・方針に応じて optin / optout を決める）

window.wp_consent_type = 'optin';

document.dispatchEvent(new CustomEvent('wp_consent_type_defined'));

// 2. バナーで「同意」が押されたとき

wp_set_consent('statistics', 'allow');

wp_set_consent('marketing', 'allow');

// 3. 「拒否」が押されたとき

wp_set_consent('statistics', 'deny');

wp_set_consent('marketing', 'deny');

前半の2行は、このサイトはオプトインで運用します、という宣言です。カスタムイベントを飛ばすところまでがセットで、これを忘れると受け取る側が同意タイプを判断できません。後半は、バナーの保存処理から呼ぶだけ。カテゴリは statistics（解析）と marketing（広告）のほかに functional、preferences、statistics-anonymous があるので、自分のサイトが実際に置いているCookieに合わせて増減させます。

上のコードはイメージで、実際は自作バナーの保存処理の中に組み込みます。【要確認：実装時に何行足したか／どのファイルのどこに入れたかを一言入れると、ここが体験の証拠になる】

注意点として、WP Consent APIは入れただけで全プラグインを止めてくれる仕組みではありません。CMP（または自作バナー）が同意状態を提供し、参照側のプラグインがそれを見て自分の挙動を変える、という役割分担です。提供する側が黙っていると、受け取る側は何もできません。