Microsoft Clarityのプライバシーポリシー対応｜記載前に確認する情報とマスキング

Microsoft Clarityを導入する前に、プライバシーポリシーへ何を書けばよいか迷っていませんか。

最初に必要なのは、文例を探して貼り付けることより、自社のサイトで何を記録し、何に使うかを確かめることです。

説明文に「個人情報は一切記録しません」と書いても、確認画面に氏名が表示され、その部分の設定を確認していなければ、説明と実装がずれるおそれがあります。

記録範囲、利用目的、マスキング、同意の動作を調べたうえで、実態に合う説明にまとめましょう。

この記事では、Clarityの公式開示例を読む観点と、説明文を作る前の事実確認シートを紹介します。

仕様と一次資料は2026年10月5日に確認しています。

法的な対応は事業や利用者の地域、データの扱いで異なるため、ここで整理した事実を法務・プライバシー担当者に渡して判断するための実務ガイドとして使ってください。

Clarityのプライバシーポリシーに書く前に

記録する情報を確認する

Clarityのセッションリプレイは、利用者のPC画面をそのまま動画として撮影する仕組みではありません。

ページの構造や変化、クリックやスクロールなどの操作から、サイト上の行動を再現します（参考：Clarityが収集するデータ）。

そのため、「カメラで撮影しないので確認は不要」とも、「入力欄が隠れるのでページ全体が匿名になる」とも言えません。

まず、タグが動くページを画面の種類で整理します。

画面の種類	確認したい情報	最初の対応
公開記事・商品ページ	表示内容・リンク先・検索条件	記録目的と対象範囲を確認
問い合わせ入力	氏名・連絡先・自由記述	入力欄と周辺表示を点検
入力確認・完了	入力値の再表示	表示要素を別に点検
会員ページ	名前・履歴・契約情報	記録する必要性から見直す
管理画面	顧客や社内の情報	対象外にする方針を検討

画面の本文以外に、URLや送信するカスタム値も確認対象へ入れます。

例えば、メールアドレスをURLのクエリへ含めていないか、問い合わせの内容を独自のイベント名へ渡していないかを調べます。

入力欄のマスキングだけを見て、これらの経路も隠れていると判断しないでください。

棚卸しの段階では、項目ごとに「記録する」「隠す」「対象ページを外す」「未確認」を付けると、後の設定作業につながります。

利用目的を具体化する

利用目的は、社内で実際に行う分析に合わせて書きます。

「サービス向上のため」だけでは、どの情報をどう使うのかを読み手が想像しにくい場合があります。

例えば、押されないリンクの位置を見直すのか、入力フォームの操作上の問題を調べるのかで、必要な記録範囲は変わります。

次の表は、説明を具体化するための架空の整理例です。

分析したいこと	必要な観察	収集範囲を絞る考え方
商品説明の置き場所	スクロールとクリック	公開の商品ページを対象にする
フォームの使いづらさ	入力前後の操作・エラー表示	入力値そのものは必要か再検討
スマホの誤タップ	メニューやボタンの操作	個人別の内容よりUIを確認
不具合の再現	発生前の手順	必要な画面と期間に絞る

担当者には「録画を見ることで、何を変える判断をするのか」を一文で書いてもらいます。

その判断に不要な情報は、最初から残す必要があるかを見直します。

担当者の便利さだけで、ログイン後のすべての画面を対象に広げないことも大切です。

広告への利用や他のデータとの連携がある場合は、サイト改善の説明へ埋もれさせず、その実態も分けて整理します。

この段階で目的をそろえると、プライバシーポリシーの担当者と実装担当者が、同じ対象について話せるようになります。

Clarityの公式開示例を確認する

文例の対象と前提を読む

Microsoftは、サイト上の開示とプライバシーポリシーの説明に使う文例を公開しています。

公式資料は、Clarityの利用、取得する情報、目的、Microsoftのプライバシー声明への案内などを、自社の使い方に合わせて説明する考え方を示しています（参考：Clarityの公式開示例）。

文例にはMicrosoft Advertisingや広告の利用に触れる箇所もあります。

Clarityを入れたという理由だけで、例のすべてが自社の設定と一致するとは判断できません。

一方、自社が広告分析をしていないからといって、提供者側のデータ利用まで「広告には使われない」と言い換えるのも避けます。

自社で行う利用と、Microsoftに関する説明を分けて確認してください。

確認先としては、公式開示例に加え、Microsoftのプライバシーに関する声明を案内できます。

サイト上の短い告知、詳細なポリシー、同意を管理する画面は、それぞれ役割が違います。

ポリシーへのリンクを置いただけで、必要な同意取得や拒否時の制御まで実装できたと扱わないようにしましょう。

自社にない利用を加えない

文面を作るときは、説明する内容と根拠を一行ずつ対応させます。

「利用者を特定できない」「すべての個人情報を除外している」といった強い表現は、設定画面の一項目だけでは裏付けられません。

Cookieのような識別子や閲覧履歴を扱う以上、名前の表示だけを消せば説明が完成するわけでもありません。

個人情報保護委員会は、個人のWeb閲覧履歴が個人関連情報に該当し得ることを示しており、個人情報に該当する場合とは区別しています（参考：個人関連情報の考え方）。

次の対応表で、確認できていない断定を文面から見つけます。

書こうとしている説明	確認する根拠	根拠がない場合
操作の改善に使う	分析担当者の実際の業務	目的を確認して具体化
入力値を記録しない	設定とテスト録画	入力後の再表示も調べる
拒否後は通信しない	同意条件別のNetwork確認	Cookie拒否と分けて再確認
社内だけで閲覧する	メンバー・共有設定	委託先や共有リンクも確認
一定期間で削除する	データ種類別の保持仕様	一律の期間を書かない

文章を整える前に、右側の根拠を埋めるのが順番です。

他社のポリシーに書いてあることは、自社サイトの設定を証明する材料にはなりません。

そのまま公開できる万能文例を作るより、事実の対応表を完成させる方が、後の確認も進めやすくなります。

Clarityのマスキングを設定する

初期設定で隠れる範囲を確認する

Clarityでは、管理者がSettingsからMaskingへ進み、記録に含める内容を調整できます。

公式資料では初期設定がBalancedで、入力欄とドロップダウンはすべてのモードでマスクされると説明されています（参考：Clarityのマスキング仕様）。

Balancedは数字やメールアドレスを対象にするため、あらゆる種類の個人情報を自動判定する設定と考えないでください。

モード	公式説明の要点	選ぶ前に見ること
Strict	コンテンツ全体をマスク	分析に必要な操作が確認できるか
Balanced	数字やメールアドレスなどをマスク	名前や自由記述の表示はどうなるか
Relaxed	入力欄等を除き内容を隠さない	不要な情報が含まれないか

モードを変えたら、設定完了の表示を確認し、対象画面でテストします。

画面が読みにくいという理由だけで全体をRelaxedに変えるより、何を見たいのかを先に絞りましょう。

マスキングと同意は別の設定です。

利用者が許可している場合でも、分析に不要な内容を見える状態にする理由にはなりません。

表示済みの個人情報も調べる

フォームの入力欄だけでなく、確認画面や会員メニューを試します。

「こんにちは、テスト利用者さん」のように、入力要素ではない場所へ名前が表示されることがあるためです。

表示後のデータがどのHTML要素に入るのかを、実装担当者と確認してください。

必要な要素は、Mask by elementでCSSセレクターを指定するか、実装側で data-clarity-mask="True" を付けてマスクする方法があります。

対象と子要素への適用、既存の解除設定との関係は、追加した後に実際の表示で確かめます。

変更は新しい記録に適用され、反映に最大一時間かかる場合があり、過去の録画へさかのぼって適用できません。

また、CSS内の内容は同じ方法でマスクされる対象ではないため、機微な情報をCSSに埋め込まないよう実装側でも確認します。

これらの仕様は、同じマスキングの公式説明で確認できます。

試す画面	ダミーデータで確認すること
入力中	入力値が見えないこと
エラー発生後	入力内容がエラー文へ再表示されていないか
確認画面	名前や自由記述が通常の文字として残らないか
完了画面	受付内容や連絡先を再表示していないか
ログイン後	メニューや履歴の表示が対象になっているか

不適切な記録が既に存在する可能性がある場合は、新しい設定の確認と、保存済みデータへの対応を別に進めます。

Clarityの同意と記録条件を整理する

未選択・拒否・許可を分ける

同意の動作は、「バナーが表示された」という確認だけでは足りません。

未選択、拒否、許可、許可後の撤回で、それぞれ何が起こるかを見ます。

Clarityには、同意状態に応じてCookieや収集方法を変える同意モードがあります（参考：Clarityの同意管理）。

拒否した場合でもCookieなしの収集が行われる構成があるので、「Cookieがない」と「外部へ通信しない」を同じ意味で説明しないでください。

Cookieの役割を調べるときは、公式の一覧で _clck や _clsk などを確認できます（参考：ClarityのCookie一覧）。

自社の方針が「許可するまで読み込まない」なら、その方針どおりにタグを制御しているかも確認します。

次の表は試験の設計用で、確認済みの結果ではありません。

同意の状態	決めておく期待値	調べるもの
未選択	初期状態で許容する処理	タグ・通信・Cookie
拒否	拒否後に許容する処理	状態の更新と実際の動作
分析のみ許可	広告と分析の扱い	それぞれのシグナル
全許可	記録する範囲	録画とマスキング
許可後に撤回	撤回後の動作	直後・再読み込み・再訪

実装の確認手順は、Clarityの同意状態を試す方法と一緒に使うと整理しやすくなります。

利用地域に関する確認を残す

Clarityの製品仕様として、EEA、英国、スイスの利用者に関する同意シグナルの要件が案内されています。

この要件だけを見て、他の地域ならどのサイトでも同意や説明が不要だとは判断できません。

利用者の地域、扱う情報、目的、事業の条件を担当者へ伝えます。

海外の利用者がいるサイトでは、言語設定だけで対象地域を判断せず、サービス提供の実態も整理してください。

担当者へ渡す項目	確認する内容
サービスの提供地域	国内のみか、海外向けにも提供するか
実際の訪問者	どの地域の利用を想定するか
取得する情報	画面・URL・識別子・独自送信値
データの提供先	契約先と利用するサービス
同意の仕組み	初期値・選択・撤回の方法
保存や移転	契約と現行資料で確認した事項

外国にある第三者への個人データの提供については、個人情報保護委員会のガイドラインに条件や対応が整理されています（参考：外国にある第三者への提供編）。

クラウドが海外にあるという一つの情報だけで、必要な対応を一律に決めないようにしましょう。

技術担当者は、法的な結論を推測するより、判断に必要なデータの流れと設定を明確にする役割を担います。

Clarityの説明と実装のずれを調べる

架空の情報でテストする

公開前の検証では、実在する顧客の名前や問い合わせ内容を使いません。

テスト用のアカウントと架空の情報を用意し、入力から完了まで同じ利用手順を通します。

以下は確認手順の例です。

1. 対象URL、テスト日時、端末、設定版を記録します。
2. 未選択の状態から同意の操作を試します。
3. 架空の文字列を入力し、エラー・確認・完了画面へ進みます。
4. Clarityの新しいテスト録画を探します。
5. 隠すと決めた情報が表示されないかを確認します。
6. 表示だけでなく、通信やURLなど必要な経路も調べます。
7. 結果を説明文の各項目と突き合わせます。

ChromeではApplicationのCookie表示とNetworkを使って、保存と通信を別々に調べられます（参考：Cookieの確認、Networkの確認）。

通信ログを調査担当へ渡す場合も、ログ自体に含まれる値を点検し、必要な範囲に絞ります。

文面の説明	実装での確認	結果の記録例
特定の画面は対象外	直接訪問と遷移後を試す	対象外の条件を記録
入力内容をマスク	入力から完了まで試す	確認画面を追加修正
拒否状態を反映	未選択・拒否・撤回を試す	再訪時も再確認
指定の目的で使う	分析担当者の操作を確認	用途と共有先を記録

この表の結果欄は架空例なので、自社で確かめた内容に置き換えてください。

設定変更後に文面を見直す

プライバシーポリシーの確認は、最初に導入したときだけの作業にしません。

例えば、商品ページだけを見ていたプロジェクトへ会員ページを追加すれば、記録される情報の前提が変わります。

同意管理ツールを変更したときも、以前と同じバナーに見えて、初期値や連携先が変わっている可能性があります。

変更のたびに、実装担当が影響する項目を示してから、説明文の担当へ渡します。

変更内容	見直す説明・設定
記録ページの追加	対象情報と利用目的
CMPの変更	同意・拒否・撤回の動作
広告関連の連携	自社と提供者側の利用の説明
テーマやフォームの変更	マスキングする要素
外部メンバーの追加	閲覧と共有の範囲
独自ID・カスタム値の追加	送信する情報と必要性

変更記録には、日付、設定版、確認した画面、結果、文面の更新有無を残します。

「前と同じはず」で終えず、変わった部分の再試験ができる形にしましょう。

マスキングの見直しと、ポリシーの更新を別々の担当が行う場合も、同じ変更番号で結び付けると取りこぼしを減らせます。

Clarity導入の社内確認を進める

未確認事項を一覧にする

社内確認では、完成した文章だけでなく、その根拠と未確認事項も渡します。

確認する人が、文言だけを見て実装まで終わっていると思わないようにするためです。

データの保持は種類によって異なり、公式資料では通常の再生データが30日、ラベルやお気に入りを付けたセッションとヒートマップなどが9か月と案内されています（参考：Clarityのデータ保持）。

「すべて30日で消える」という説明は、この違いを反映できていません。

また、公式FAQは一部の録画の長期保持や、特定利用者のデータ削除にプロジェクト削除が必要な点も説明しています（参考：ClarityのFAQ）。

データ削除の約束を文面へ入れる前に、実際に取れる手続きを確認してください。

説明文作成前の事実確認シートは、次の形でまとめられます。

項目	確認した事実	根拠・確認先	残る作業
対象ページ	記入	設置一覧	未確認ページを確認
利用目的	記入	分析担当者	用途の整理
取得情報	記入	公式資料・実装	独自送信値を点検
マスキング	記入	設定・テスト録画	必要な修正
同意と撤回	記入	CMP・試験表	条件別に再確認
保持・削除	記入	現行の公式仕様	対応手順を確認
閲覧・共有	記入	メンバー・共有設定	不要な権限を見直し
地域・契約	記入	契約・法務担当	適用条件の判断

確認していない行は、空欄か「未確認」と書き、確定情報に混ぜません。

承認後の点検担当を決める

運用開始後は、Clarityの管理者、サイト実装、文面確認、問い合わせ窓口の担当を決めます。

Clarityのプロジェクトには管理者とメンバーの役割があり、マスキングなどの設定を変更する権限にも違いがあります（参考：Clarityのチーム管理）。

必要な人が設定を確認でき、不要になった人のアクセスを見直せる体制にしてください。

共有リンクも含め、録画を誰に見せるかは、分析担当者だけの判断に任せないようにします。

次は運用を割り振るための例です。

担当	受け持つ確認	見直しの契機
サイト実装	タグ・同意・マスキング	画面やCMPの変更
分析担当	利用目的と必要な範囲	分析テーマの追加
プロジェクト管理	メンバー・共有・保持	人員や委託先の変更
法務・文面担当	説明と実態の整合	利用条件や対象地域の変更
問い合わせ窓口	利用者からの連絡と対応手順	問い合わせ・問題の発見

定期点検の時期を決めたうえで、表にある変更が起きた場合は、その時点でも確認します。

ポリシーのページを更新した日と、技術設定を確認した日を両方残しておくと、問い合わせ時にも経緯を追えます。

Clarityのプライバシーポリシー対応は、文章・設定・運用の三つを一致させる作業です。

まずは一つのフォームについて、入力から完了までを棚卸しし、事実確認シートの最初の行を埋めてみてください。

保存・共有を含む導入全体の整理には、セッションリプレイの社内確認項目も使えます。