Clarityの設定方法｜Cookie同意の状態ごとに記録を確かめる手順

ClarityのCookie同意設定は、バナーに「同意する」「拒否する」が表示されれば完了ではありません。

利用者が選んだ状態がClarityへ伝わり、その後のCookieや通信が運用方針と一致しているかまで確かめる必要があります。

特に区別したいのは、「Cookieを使わない」と「Clarityへ何も送信しない」の違いです。

Clarityの同意モードでは、拒否時にもCookieを使わない限定的な収集が行われる場合があります。

この記事では、CMPと呼ばれる同意管理ツールの確認から、未選択・拒否・許可・撤回のテストまで、設定を点検する順番を解説します。

最後に、担当者へそのまま渡せる「同意状態ごとの動作テスト表」を掲載しました。

説明は2026年10月5日に確認したMicrosoftとChromeの公式資料に基づくもので、特定のサイトで法的な対応が完了したことを証明するものではありません。

Clarityの同意設定で先に確認すること

使っているCMPを確認する

CMPは、Cookieなどの利用について選択を受け付け、その状態を保存・管理するツールです。

最初に、自社サイトのバナーをどの仕組みで出しているかを確認してください。

WordPressのプラグイン、外部のCMP、独自に作ったバナーでは、設定場所や連携方法が変わります。

Clarity側の対応一覧には、Cookiebot、CookieYes、Usercentricsなど複数のCMPが掲載されています（参考：Clarityが案内するCMP）。

一覧に名前があるだけで、自社の設定も完了しているとは限りません。

導入している製品名、利用中の連携方法、同意状態を保存する場所を、サイトの担当者と整理しましょう。

先に控える項目	記録する内容
CMP	製品名、設定画面、管理担当者
Clarity	対象プロジェクトと設置方法
タグの設置場所	GTM、CMS、直接設置など
同意の区分	分析、広告などの選択肢
連携方法	対応CMP、Google同意モード、APIなど
選択変更の場所	フッターなどのCookie設定への導線

バナーの「分析」と「広告」を、Clarityへ同じ値で渡していないかも確認します。

分析だけを許可した利用者を、広告も許可した状態に変換してはいけません。

作業を始める前に、誰がCMPを変更でき、誰がGTMやサイトのコードを公開できるかも決めておくと、設定の食い違いを減らせます。

対象地域と運用方針を整理する

Microsoftは、EEA・英国・スイスからの訪問について、2025年10月31日から同意シグナルの要件を適用すると案内しています（参考：Clarityの同意管理）。

日本企業のサイトでも、対象地域からの訪問を受ける場合は確認が必要です。

ただし、この製品上の案内だけで、地域ごとの法的な対応すべてを決めることはできません。

ここでは、まず技術試験の期待値を担当者間でそろえます。

特に、拒否時の動作について次のどちらを求めるかを明確にしてください。

運用として求めること	試験で見るもの
Cookieを使わない収集を許容する	同意状態、Cookieの有無、送信内容
同意前や拒否時はClarityを起動しない	タグの読み込みとClarity向け通信の有無

公式の同意管理資料では、分析の同意が拒否された場合にも、タグが読み込まれ、Cookieなしのデータが収集される動作を説明しています（参考：同意状態とClarityの動作）。

したがって、通信を止める方針なら、同意モードの設定だけで満たせると考えず、CMPやタグ管理側の読み込み制御も確認します。

テスト表には「拒否時に期待する動作」を具体的に書いておきましょう。

この前提が曖昧なままだと、通信が見つかったときに、仕様どおりなのか設定ミスなのか判断できません。

Clarityの同意連携の方法を選ぶ

公式の現行方式を確認する

Clarityの同意設定は、プロジェクト側の設定と、利用者の選択を伝える連携を組み合わせます。

公式資料では、SettingsからSetupへ進み、初期状態でCookieを設定するスイッチをOFFにして同意モードを有効にする手順が案内されています（参考：Clarity同意モードの設定）。

画面の表記を確認し、「Clarity全体を停止する設定」と取り違えないでください。

そのうえで、今のサイトに合う連携を一つの方針として選びます。

現在の構成	確認する連携
対応するCMPを利用中	CMPの公式Clarity連携と有効化条件
Google同意モードを利用中	初期値と変更後のシグナル
独自バナーなど	Clarity Consent V2 APIへの接続
CMSやECアプリで導入	その導入方法の同意対応とタグの重複

ClarityはGoogle同意モードの分析・広告のシグナルを認識する仕組みを案内しています（参考：Google同意モードとの連携）。

既にその経路で正しく連携している場合、同じ状態を送る独自コードを闇雲に追加しない方が、管理する場所を増やさずに済みます。

独自実装では、現在推奨されるconsentv2を使い、分析と広告の選択を別々に渡します（参考：Clarity Consent V2 API）。

例えば、利用者が実際に「分析は許可、広告は拒否」を選んだ際の呼び出しは、次の形です。

window.clarity("consentv2", {
  analytics_Storage: "granted",
  ad_Storage: "denied"
});

この断片は同意バナーの代わりではなく、選択結果を伝える部分だけです。

ページ表示時に誰にでも固定で実行せず、CMPが保持する実際の状態と、選択が変わったイベントへ接続してください。

初回だけでなく、再訪時の状態復元と撤回時の更新も同じ設計に含めます。

古いコードが残っていないか調べる

以前の設置コードが残っていると、新しい連携で拒否を送っても、別の場所から許可が送られる可能性があります。

GTMだけでなく、テーマの設定、プラグイン、共通レイアウトなども確認します。

サイトの実装を管理している人へ、次の検索項目を渡すと調査しやすくなります。

探すもの	確認する理由
ClarityのプロジェクトID	別経路で重複していないか
consentv2	状態を送る箇所と値を確認する
旧consent呼び出し	古い同意連携が残っていないか
analytics_storage・ad_storage	Google同意モード側の初期値と更新
CMPの連携設定	API以外の送信経路を把握する

Consent V2 APIのキーはanalytics_Storageとad_Storageで、Google同意モード側の小文字のキーと表記が異なります。

見た目が似ていても、別のAPIのコードをそのまま貼り替えないでください。

Microsoftは旧Consent APIを新規の方式として使わず、V2を利用するよう案内しています（参考：Consent V2の位置付け）。

移行時はコードを消すことだけを目的にせず、現在どの箇所が有効な状態を送っているかを確かめてから整理します。

特に、許可後の再読み込みで状態が戻るなら、初期化処理を点検しましょう。

変更前の設定と公開した版を残しておくと、想定外の動作が起きた際に比較できます。

Clarityで未選択時の動作を試す

新しいブラウザ状態で開く

未選択の試験は、前回の許可が残っていない状態で行います。

既に同意したブラウザーでバナーを閉じただけでは、初回訪問の試験になりません。

検証専用のブラウザープロファイルなどを用意し、ログインやCookieの状態を区別してください。

シークレットウィンドウを使う場合も、別のシークレットウィンドウと状態を共有していないか、ブラウザーの制限が通常時と違わないかを記録します。

同意の保存場所がCookie以外の場合もあるため、Cookieだけを消して未選択になったと決めないようにしましょう。

準備ができたら、次の手順で確認します。

1. テスト日時、ブラウザー、対象URLを記録する
2. 開発者ツールのNetworkを開く
3. 対象ページを読み込み、バナーは操作しない
4. ページをスクロールし、次のページにも移動する
5. 同意状態、Cookie、Clarity向け通信をそれぞれ確認する

ChromeのNetworkは、開発者ツールを開いている間の通信を記録し、Preserve logを使うとページ移動をまたいで確認できます（参考：Chromeの通信記録）。

バナーを押した後から記録を始めると、押す前の読み込みを見落とすので、先に準備してください。

通信の記録を残す場合は、ログイン情報などを含む可能性があるため、共有先と必要な部分を絞ります。

試験環境では通信しない設計なら、意図しない送信が起きた時刻も記録すると、どの読み込みが先に動いたかを調べやすくなります。

送信とCookieを分けて確認する

Cookieは、ChromeのApplicationからStorage、Cookiesへ進み、対象のサイトを選んで確認できます（参考：ChromeでCookieを確認する方法）。

ClarityのファーストパーティCookieには、利用者の識別に使う_clckと、ページ表示を一つのセッションへつなぐ_clskがあります（参考：ClarityのCookie一覧）。

名前だけでなく、ドメインや有効範囲も確認してください。

一方、通信はNetwork側で確認します。

clarityなどで候補を絞り、Clarity関連の送信先や/collectの通信があるかを確認すると、Cookieの確認とは別に記録できます。

さらに、Clarityが読み込まれている構成では、公式資料の確認用APIで同意状態を表示できます。

window.clarity("metadata", (_data, _upgrade, consent) => {
  console.log("consentStatus:", consent);
}, false, true, true);

これは同意を許可するコードではなく、状態を確認するために案内されている呼び出しです（参考：同意実装の確認手順）。

タグ自体を止める構成では、Clarityがまだ定義されていないこともあるため、確認コードが動かないだけで不具合と判断しません。

見る場所	記録するもの
バナー	まだ選択していない状態か
CMP	保存済みの選択が残っていないか
Clarityの状態	分析と広告の許可・拒否
Cookie	名前、ドメイン、存在の有無
Network	読み込み・送信の有無と時刻

録画一覧に見つからないことは、送信がなかった証拠にはなりません。

未選択の試験は、これらの観測を別々に残して判断してください。

Clarityで同意拒否時の動作を試す

拒否後の状態を記録する

未選択の状態を記録したら、バナー上で拒否を選びます。

その直後に、CMPの選択、Clarityの分析・広告の状態、Cookie、通信をもう一度確認してください。

独自APIの連携では、両方を拒否した実際の選択を次のように渡します。

window.clarity("consentv2", {
  analytics_Storage: "denied",
  ad_Storage: "denied"
});

このコードを手動で呼べたことだけでは、バナーとの連携を検証したことになりません。

試験は利用者と同じバナー操作から始め、実装が状態を更新したことを確認します。

公式説明では、同意拒否時はCookieを使わないモードに移る動作が示されています（参考：Cookie拒否時のClarity）。

したがって、Cookieが消えても通信が残る場合、直ちに設定ミスと断定せず、先に決めた方針と照合します。

観測した状態	次に確認すること
バナーは拒否、状態は許可	連携イベントや別経路の上書き
状態は拒否、Cookieが残る	ドメイン、更新順序、再訪時の動作
Cookieなし、通信あり	Cookieなし収集を許容する方針か
タグ停止の方針なのに通信あり	読み込み制御と重複設置

「拒否したので何も記録されないはず」という前提で進めると、製品仕様との違いを見落とします。

想定していない動作は、値を無理に合わせず、発生条件を添えて実装担当者へ引き継ぎましょう。

再訪や撤回も確認する

拒否直後に問題がなくても、再読み込みすると許可へ戻る可能性を試験から外してはいけません。

保存された選択を復元する処理と、バナー操作の更新処理は、別々の場所に書かれていることがあるためです。

次の状態遷移を一通り確認してください。

1. 拒否した後にページを再読み込みする
2. 同じサイトの別ページへ移動する
3. 一度許可してからCookie設定を開き、拒否へ変更する
4. 拒否へ変更した状態で再訪する
5. 分析のみ許可した状態で再読み込みする

特に、広告は拒否したまま分析を許可する組み合わせを、両方許可へまとめないことが重要です。

Clarityでは分析用と広告用の同意を別に扱い、広告の同意はMicrosoft Adsとの共有に関係すると説明しています（参考：Clarityの同意区分）。

自社のバナーの区分が、この意味と対応しているかを確認しましょう。

撤回時は、既に読み込まれたタグがどう動くかも見る必要があります。

次回のタグ発火を止めただけでは、今開いているページの通信まで止まったとは言えません。

通信を止める運用では、撤回のイベントから現在のページと次回訪問までの動作を、CMPの仕様と実装の両方で確かめてください。

テスト結果には「拒否できた」だけでなく、どの状態から変更したかも残します。

Clarityで同意許可時の記録を確認する

許可後のテスト訪問を探す

許可の試験では、同意状態の変化と、実際のテスト訪問を結び付けます。

テスト日時、URL、端末、ブラウザーを控え、個人情報を含まない決まった操作を行ってください。

例えば、説明ページを開き、料金ページへ移動し、テスト用のボタンまで進む、といった短い経路です。

その後、ClarityのRecordingsで期間や端末などを絞り、対象の訪問を探します。

一覧にない場合は、直ちにもう一つタグを追加せず、次の順に点検します。

点検する順番	確認内容
対象プロジェクト	設置したIDと閲覧先が一致するか
同意の結果	分析の許可が伝わっているか
タグの動作	通信やブラウザーのブロックがないか
取得条件	社内アクセスの除外などに該当しないか
一覧の条件	日時・タイムゾーン・端末が合っているか

Clarityの導入資料には、タグ設置後の通信確認も案内されています（参考：Clarityの設置確認）。

許可すれば、すべてのブラウザーで必ず同じ記録が残ると保証されるわけではありません。

また、Cookie同意が必要な地域で同意がない場合、ページ表示ごとにセッションが分かれるなど、レポートの読み方が変わると案内されています（参考：同意なしの場合のレポートへの影響）。

同意設定を変更した前後でセッション数が変化しても、すぐに集客の増減と結び付けないでください。

設定変更日を分析担当者へ共有し、数字の比較条件にも残します。

マスキングの状態を点検する

同意を得ることと、記録に含めない情報を隠すことは別の設定です。

分析を許可した人の情報なら、画面に表示されたすべての内容を記録してよいとは考えません。

氏名、連絡先、会員情報など、自社で記録対象にしない内容を整理しましょう。

ClarityではSettingsのMaskingからモードや要素ごとの設定を選べます（参考：Clarityのマスキング設定）。

初期のBalancedは数字やメールアドレスなどを対象としますが、サイト固有の表示をすべて自動で隠す保証として扱わないでください。

テストでは、実在する顧客情報を入力せず、検証用の内容で表示を確認します。

確認する場面	点検したいこと
入力欄	入力した内容が再生で見えないか
確認画面	入力欄の外へ表示された情報も隠れるか
会員ページ	名前や契約情報などが表示されないか
エラー表示	入力値を含むメッセージが露出しないか
URLなど	マスキング以外の記録項目を確認したか

公式資料では、マスキングの変更は新しい録画に適用され、過去の録画へ遡って適用できないと説明しています（参考：マスキング変更の適用範囲）。

変更後すぐに古い録画を開いても、修正の結果は確認できません。

反映までの時間も考慮し、変更後に新しいテスト訪問を作って確かめてください。

同意の試験を通過したことと、マスキングの試験を通過したことを、別々の欄で残すと引き継ぎやすくなります。

Clarityの同意設定を保守する

CMP更新時に再試験する

CMP、GTM、CMSのプラグインやテーマが変わると、同意連携の動作も再確認が必要になります。

初期化の順番やイベント名が変われば、バナーが同じ見た目でも結果が変わる可能性があるためです。

公開作業に、次のテスト表を添えてください。

試験する状態	操作	記録する結果
未選択	新しい状態で開き、選ばず移動	状態・Cookie・通信
全拒否	バナーで拒否する	分析と広告の拒否
分析のみ許可	広告は拒否のまま保存	二つの状態が分かれているか
全許可	バナーで許可する	状態とテスト訪問
撤回	許可から拒否へ変更する	Cookie・現在の通信・再訪
再訪	保存済みの選択で再読み込み	初期化で上書きされないか
マスキング	検証用データで対象画面を開く	記録に残す内容の範囲

この表に、期待値、実測値、実施日、担当者、公開版を追加すると、そのまま試験記録として使えます。

未選択と全拒否を一つの行にまとめないことがポイントです。

利用者が何も選んでいないときの初期処理と、拒否を選んだ後の更新処理を別々に調べられるためです。

複数のドメインやサブドメインを使っている場合は、同意の保存範囲と移動後の状態も確認します。

一つのページで成功した結果を、そのまま全ドメインの確認済みとして扱わないでください。

スマートフォンでもバナーの選択と設定の開き直しができるかを点検し、操作できない場合は設定の問題と表示の問題を分けて修正します。

未確認の挙動を引き継ぐ

試験中に想定外の状態が出たら、「同意設定が壊れている」という一文だけで引き継がないようにします。

開始状態、行った操作、期待値、観測した結果を並べると、担当者が再現できます。

以下は、引き継ぎ方を示す架空の例です。

項目	架空の記入例
開始状態	分析を許可、広告を拒否して保存済み
操作	料金ページを再読み込み
期待値	分析は許可、広告は拒否を維持
観測	広告の状態が許可に変わった
次の確認	CMPの復元処理と旧コードの呼び出し
担当	実装担当者とCMP管理者

Cookieの値や通信ログの全部を公開する必要はありません。

再現に必要な情報に絞り、個人情報や認証情報を含まない形で共有してください。

Microsoftの仕様とCMPの資料が一致しないように見える場合は、確認した日付と参照先も残します。

最終的な記録では、「技術試験で確認したこと」と「運用・法務の判断が必要なこと」を分けます。

技術的にCookieが消えたことだけで、すべての対応が完了したという結論にはしません。

Clarityの同意設定は、バナーの選択から再訪・撤回まで、利用者の状態が正しく引き継がれることを確かめて完成させます。

まずは未選択の訪問で、同意状態・Cookie・通信の三つを別々に記録してみてください。

タグ自体の導入を確認したい場合は、Microsoft Clarityの導入方法を参照してください。

利用範囲や保存・共有の整理は、セッションリプレイ導入の確認項目で解説しています。

機能の制約を先に把握したい場合は、Microsoft Clarityのデメリットも参考になります。