--- title: CMP導入後、Cookie制御をどう維持するか？ description: >- CMP導入時に確認したCookie制御は、Webサイトの公開後もそのまま維持されるとは限りません。JavaScriptやテンプレート、GTM、別レイアウトのページ追加などによって起こる制御漏れと、Cookie制御をWebサイト全体で維持するための考え方を紹介します。 canonical: 'https://mixed.co.jp/articles/cmp-cookie-control/' updatedAt: '2026-08-20' --- # CMP導入後、Cookie制御をどう維持するか？ CMP導入時に確認したCookie制御は、Webサイトの公開後もそのまま維持されるとは限りません。JavaScriptやテンプレート、GTM、別レイアウトのページ追加などによって起こる制御漏れと、Cookie制御をWebサイト全体で維持するための考え方を紹介します。 公式ページ: [https://mixed.co.jp/articles/cmp-cookie-control/](https://mixed.co.jp/articles/cmp-cookie-control/) # CMP導入後、Cookie制御をどう維持するか？ Webサイトは、公開した時点の状態がそのまま続くものではありません。 CMSからページが追加され、テンプレートが改修され、新しい外部サービスやJavaScriptが組み込まれます。キャンペーンのためにランディングページが作られ、採用サイトだけ別の制作・運用体制を取ることもあります。 CMP（Consent Management Platform）の導入時には、タグやCookieを棚卸しし、利用者の選択に応じて制御されることを確認します。同意前に、制御対象のCookieを発行しない状態を導入目的にする場合もあります。本稿では、この状態を「ゼロCookie状態」と呼びます。 公開時にゼロCookie状態を確認できたとしても、その確認が将来のページや改修後の挙動まで保証するわけではありません。Cookieバナーが表示されているかを見るだけでは、公開ページの裏側で何が実行されているかを判断できないこともあります。 Webサイトが変わるたびに、Cookie制御には何が起きるのでしょうか。 ## この記事の要点 * CMP導入時に確認したCookie制御は、公開後のWebサイト変更によって崩れることがあります。 * JavaScriptの実行順序、GTMとテンプレートからの二重読み込み、別テンプレートへの導入漏れなど、CMP以外の要因もCookie制御に影響します。 * 維持すべきなのは「CMPが動いている状態」ではなく、利用者の選択に応じてCookieが適切に制御されているWebサイトの状態です。 * その状態を維持するには、CMPだけでなく、CMS、テンプレート、JavaScript、タグ管理、公開後の確認まで含めて設計する必要があります。 ## 公開時に整えた状態は、そのままでは維持されない CMPを導入するときは、公開中のページとタグを調べ、Cookieの用途を整理し、CMPの設定とWebサイトへの実装を行います。最後に、同意前、同意後、拒否時などの動作を確認します。 この時点で確認できるのは、そのとき存在するページと実装の組み合わせです。 公開後のWebサイトでは、次のような変更が続きます。 * CMSのテンプレートが変更される * Google Tag Manager（GTM）にタグが追加される * ページ固有のJavaScriptが追加される * 本体サイトとは異なるテンプレートでページが作られる * 外部サービスの仕様や読み込み方法が変わる * 制作会社や運用担当者が変わる どれも通常のサイト運用で起きる変更です。しかし、Cookieを発行し得るタグの読み込み方が変われば、公開時に確認した制御の前提も変わります。 つまり、公開時の正常な状態は、運用中のある一時点を切り取ったものです。ゼロCookie状態を導入目的にするなら、CMPを設置したかどうかだけでなく、その状態を変更後も確認できるようにする必要があります。 ## Cookieが発行されるまでには複数の経路がある CMPは、Cookieなどの利用について情報を示し、利用者に同意・拒否の選択肢を提供し、その選択状態を管理・判定するための仕組みです。 一方、公開ページで実際にタグを読み込み、JavaScriptを実行するのはWebサイト側です。共通テンプレートから直接読み込むこともあれば、GTMを経由することもあります。CMSとは別に作られたページが、独自のタグを持っている場合もあります。 利用者の選択がCookieの挙動へ反映されるまでには、少なくとも次の状態がそろっている必要があります。 1. 対象ページでCMPが正しく読み込まれる 2. Cookieを発行し得るタグが把握され、適切な区分に登録される 3. CMPの判定より先に対象タグが実行されない 4. 利用者の選択結果が、タグを実行する条件へ反映される 5. どのテンプレートやページでも、同じ制御方針が適用される CMPの管理画面が正しく設定されていても、ページ側の読み込み順序やタグの追加経路が変われば、このつながりは崩れます。反対に、ページ側でタグを停止していても、CMPの判定を正しく受け取れなければ、同意後に必要な機能を動かせません。 このため、確認対象はCMPの管理画面だけではなく、利用者の選択から公開ページ上のタグ実行までをつなぐ、一連の経路になります。 ## 公開後の変更で起きた三つのずれ Webサイトの運用を続けるなかで、公開時にはなかった変更からCookie制御が崩れることがありました。いずれもCMPの機能そのものではなく、CMPと公開ページをつなぐ経路で起きた事象です。 ### JavaScriptの実行順序が変わった 既存のJavaScriptを改修した際、スクリプトの実行順序が変わり、CMPの判定より先にCookieを発行し得る処理が動く状態になりました。 ページの表示には大きな変化がなく、CMPのバナーも表示されます。そのため、画面を見るだけでは異常に気づきにくい状態でした。しかし、初回アクセス時の通信とブラウザの保存データを確認すると、利用者が選択する前にCookieが発行されていました。 新しいJavaScriptを追加した場合にも、同じ問題が起こり得ます。既存の制御経路を通らずに外部サービスを読み込めば、そのタグはCMPの設定対象として認識されないまま実行されます。 この事象から分かるのは、JavaScriptの変更が表示機能だけの改修ではないということです。外部通信やCookie発行を伴う可能性があるため、Cookie制御の確認対象でもあります。 ### CMPが二つの経路から読み込まれた CMPの読み込みタグがGTMに設定されている状態で、Webサイトのテンプレートにも同じタグが追加され、二重に読み込まれていました。 一方だけを見れば、どちらもCMPを導入するための正しい作業に見えます。しかし、サイト全体では初期化が二度行われ、どちらの設定と実行順序を基準に動いているのかが分かりにくくなります。画面上でバナーが一つ表示されていても、読み込み経路が一つとは限りません。 この事象は、実装箇所の管理が分かれていると起きやすくなります。GTMを管理する担当者とCMSテンプレートを改修する担当者が異なる場合、CMPを「どこから一度だけ読み込むか」を決め、共有しておく必要があります。 ### 本体サイトとは異なるページにCMPが反映されなかった 本体サイトの共通テンプレートにはCMPが導入されていても、採用サイトやランディングページでは別のテンプレートが使われていることがあります。 本体サイトの改修だけで導入が完了したと判断すると、これらのページにはCMPが読み込まれません。一方で、アクセス解析や外部サービスのタグは個別に設置されているため、利用者が選択する機会のないままCookieが発行される状態になります。 サイトの一覧をドメイン単位で捉えるだけでは、この漏れを見つけられないことがあります。サブドメイン、ディレクトリ、CMS、テンプレート、制作・運用主体の違いまで含めて、実際のページ群を確認する必要があります。 三つの事象に共通するのは、公開時の設定が間違っていたことではありません。Webサイトが変わった結果、CMPとCookieを発行し得るタグの関係が変わり、当初確認した状態が維持されなくなったことです。 ## 維持したいのは、CMPの稼働ではなくWebサイトの状態 CMPの導入目的がゼロCookie状態の実現であれば、確認すべきなのは「CMPが表示されること」ではなく、「利用者の選択前に、制御対象のCookieが発行されないこと」です。 目的をWebサイトの状態として捉えると、確認する場面も変わります。 * 初めてアクセスし、まだ何も選択していないとき * 必要な区分だけに同意したとき * すべて拒否したとき * 一度与えた同意を撤回したとき * CMPを読み込めない、または判定結果を取得できないとき * 新しいページやJavaScriptが追加されたとき 通常時は、CMPが利用者の選択を判定し、その結果に応じて対象タグが動きます。では、CMPが読み込まれない、導入されていない、二重に読み込まれている、あるいは新しいタグが制御対象として整理されていない場合、Webサイトは何を基準に動けばよいのでしょうか。 ここで決めるべきなのは、正しい判定を取得できないときの初期状態です。判定できないまま対象タグを実行する設計では、何かが欠けたときにCookieが発行されます。反対に、動かしてよいことを確認できるまで対象タグを実行しない設計なら、読み込み漏れや一時的な不整合が直ちにCookie発行へつながる範囲を抑えられます。 この切り分けによって、CMPが担う「選択状態の管理と判定」と、Webサイトが担う「タグの出力と実行」は、別の責任として見えるようになります。 ## 判定できないときに、タグをどう扱うか Webサイト側で取り得る方法の一つに、Cookieを発行し得るタグを、初期状態では実行できない形で出力する設計があります。 たとえば、通常のJavaScriptとして実行されるタグを、`type="text/plain"` として非実行状態で出力し、外部ファイルのURLも `src` ではなく `data-src` などに保持します。この状態ではブラウザからJavaScriptとして実行されず、対象の外部スクリプトも読み込まれません。 CMPから同意状態を取得し、対象区分を動かしてよいと判定できた場合にだけ、Webサイト側で実行可能な状態へ切り替えます。実際の復元方法は利用するCMPの仕様に合わせて設計し、実行順序や重複実行も確認する必要があります。 この構造では、CMPが正常に動いているときは利用者の選択に応じてタグを実行できます。判定を得られないときは非実行状態が残るため、対象タグは動きません。 ## CMS側にも制御を持たせる理由 通常時の同意管理と判定はCMPが担い、Cookieを発行し得るタグはCMS側で初期状態を無効にして出力する。CMPから適切な判定を受け取った場合にだけタグを実行可能な状態へ切り替え、判定を得られない場合は無効状態を保つ。 これはCMPの代わりにCMSで同意管理を行うという意味ではありません。CMPによる選択と判定、CMSによる初期状態の制御、公開後の棚卸しと確認を分け、それぞれの役割をつなぐための設計です。 この構成に至った背景には、CMPを正しく導入した後でも、JavaScriptの変更、読み込み箇所の重複、別テンプレートへの導入漏れによって、当初のゼロCookie状態が崩れるケースがあったことがあります。 こうした考え方を、Movable Type / Movable Type Premium / PowerCMSを利用するWebサイト向けに実装したものが、「[CMPガバナンスパック](https://mixed.co.jp/products/governance-pack/)」です。 Webサイトは公開後も変わり続けます。その変化のなかで利用者の選択を実際の挙動へ反映し続けるには、CMPの稼働だけではなく、Webサイト全体としてCookie制御が維持されているかを見る必要があります。 Cookieを発行させない責任を、CMPだけに負わせない。 そのために、CMP、CMS、テンプレート、タグ管理、公開後の確認を、一つの運用として設計します。