Clarityの設定で社内アクセスを除外するには？テスト訪問と顧客の記録を分ける

Clarityで自分たちのテスト操作ばかり見えているなら、社内アクセスの扱いを先に決めましょう。

公開前の確認や不具合の再現作業は、通常の顧客とは違う動きをします。

固定IPを除外する設定と、取得したテスト記録を分析画面で分ける方法は、目的が異なります。

この記事では、ClarityのIPブロック設定を中心に、開発環境・在宅勤務・委託先の確認を整理します。

最後の方針表を使えば、どのアクセスを記録せず、どのテストを識別して残すかを共有できます。

公式仕様は2026年10月5日に確認しており、実際の設定画面や回線条件に合わせて検証するための手順です。

Clarityで社内アクセスを分ける理由

社内アクセスの問題は、録画の本数が増えることだけではありません。

分析する人が、顧客のつまずきとテスト担当者の意図的な操作を区別しにくくなります。

少数サイトでの影響を確認する

公開したばかりのページでは、顧客の訪問よりも社内確認が目立つことがあります。

例えば、担当者がボタンを連打して反応を確認した録画を、顧客が困っている場面と読み違えるケースです。

記事の末尾までスクロールする校正作業が多ければ、最後まで到達する割合も通常の読者とは違って見えます。

これは説明用の仮想例ですが、訪問数が少ないページほど影響を確認しておきたい場面です。

最初の点検では、直近のテスト日時と対象URLを担当者へ確認し、その時間帯の記録と照合します。

訪問の動きだけで「これは社員」と断定せず、分かっている作業記録を根拠にします。

確認できたテスト訪問と、社内かどうか不明な訪問は分けて扱ってください。

録画が不自然に見えるという理由だけで除外すると、本当の操作上の問題を見逃す可能性があります。

除外と分析時の絞り込みを分ける

ClarityのIPブロックは、指定した接続元の行動をダッシュボード・録画・ヒートマップの収集対象から外すための機能です（参考：ClarityのIPブロック）。

一方、フィルターやセグメントは、取得したデータの中から分析する対象を選ぶために使います。

目的	方針	確認すること
日常の社内閲覧を記録したくない	収集段階の除外を検討	接続元・対象範囲・適用後の挙動
不具合の再現を録画で見たい	テストと識別して残す	時刻・URL・テスト種別
顧客向けの報告を作りたい	分析条件からテストを分ける	使用した条件と残る不明分

セグメントは複数のフィルターを保存して使い回せる機能ですが、データの送信を止める設定ではありません（参考：Clarityのセグメント）。

「画面に表示されなくなった」と「記録されなくなった」を同じ意味で扱わないようにしましょう。

録画を残す必要がない社内操作と、検証のために残したい操作を最初に分けることが大切です。

Clarityで除外対象を決める

設定へ進む前に、誰がどの環境からサイトを開いているかを整理します。

社員だけでなく、制作会社や運用代行会社の確認作業も対象に含めます。

社内と委託先のアクセスを洗い出す

まず、オフィス・在宅・VPN・モバイル回線・委託先の作業環境を一覧にします。

個人名を細かく集めるより、回線や作業の種類を軸に整理すると、設定へ結び付けやすくなります。

次の表は、導入前に確認する項目のひな形です。

確認対象	担当者へ確認すること	方針を決める材料
オフィス回線	外向きのIPが固定か	IP除外を維持できるか
在宅勤務	接続元が変わるか	回線だけで識別できるか
VPN	出口が固定か、経路が複数か	すべて同じ条件になるか
制作・運用委託先	作業範囲と期間	契約終了時に見直せるか
動作確認用端末	記録を残す必要があるか	通常の社内閲覧と分けるか

外向きのIPとは、サイト側から接続元として見えるアドレスのことです。

PCの設定画面にある社内用のアドレスを、そのまま除外欄へ入れればよいとは限りません。

ネットワーク担当者に確認し、共有回線や複数拠点の関係も含めて対象を決めます。

委託先に設定作業を依頼する場合は、登録してよい範囲と、作業後に返してもらう検証結果を先に伝えておきます。

開発環境を本番から分ける

開発・検証環境では、本番用のClarityタグを配信しない構成をまず検討します。

検証環境で録画が必要なら、本番の顧客データと混ざらないプロジェクトを使います。

Clarityはプロジェクトごとに固有のトラッキングコードを持つため、名前だけでなく、実際に配信されるIDを照合します（参考：Clarityのプロジェクト管理）。

環境名を変えただけで、本番と検証の記録が自動的に分かれるとは考えないでください。

GTMで配信している場合は、本番のホスト名などを条件にして、対象環境だけでタグが発火する構成を確認します（参考：GTMのトリガー設定）。

設定変更後は、本番・検証・ローカルの各URLを開き、想定したタグが読み込まれるかを確認します。

本番からコピーして作った検証環境は、タグやプロジェクトIDまで残っていないかを点検する必要があります。

開発者には「検証側を除外する」だけでなく、対象ホストと送信先の対応表を渡すと認識をそろえやすくなります。

ClarityのIP設定を確認する

固定IPで分けられるアクセスは、Clarityの管理画面で設定します。

設定できる権限と、利用できるIPの種類を確認してから作業してください。

利用できる除外方法を確認する

IPブロックの変更には、対象Clarityプロジェクトの管理者権限が必要です。

公式手順では、プロジェクトの「Settings」から「IP blocking」を開きます。

1. 対象プロジェクトを選ぶ
2. 「Settings」→「IP blocking」を開く
3. 「Block IP address」を選ぶ
4. 識別用の名前と、確認済みの対象IPを入力する
5. 「Add」で登録し、一覧へ反映されたことを確認する

現在の接続元を指定する選択肢もありますが、今いる場所が除外したい回線かを先に確認します。

反映には約15分かかると案内されているため、登録直後の結果だけで失敗と判断しないでください（参考：IPブロックの設定手順）。

作業記録にはプロジェクトID、設定名、登録時刻、検証予定時刻を残します。

一度に広い範囲を指定する前に、必要な接続元を正しく特定できているかを確認しましょう。

変動するIPへの限界を理解する

ClarityのIPブロックはIPv4が対象で、IPv6や動的IP、安定しないモバイル回線には制約があります。

IPv4とIPv6を併用する場合も、期待どおりブロックできない可能性が公式資料に示されています（参考：IPブロックの対応条件）。

そのため、オフィスで一度成功した試験を、在宅勤務やスマホにもそのまま当てはめることはできません。

VPNという名前だけで判断せず、接続先ごとに出口が固定されているか、通信経路が変わるかを担当者に確認します。

また、除外対象の回線を顧客も共有する場合は、社内操作だけを分けられない可能性があります。

回線による識別が合わない場合は、ログイン権限などを使ったサイト側の配信条件を検討します。

その際も、一般会員と管理者を区別し、顧客まで一括で記録しない設定にならないようにします。

IPブロックだけで全員を完全に分類できると考えず、対象ごとの限界を方針表へ残してください。

Clarityのテスト記録を見分ける

不具合の再現など、録画を残したいテストは、分析用の顧客データと識別できるようにします。

最初は時刻とURLを記録するだけでも、探しやすさが変わります。

時刻とURLを残す

テスト開始前に、対象URL・端末・ブラウザ・開始時刻・作業内容をメモします。

「スマホで問い合わせフォームのエラーを確認」のように、何を試した訪問かを一行で残してください。

終了時には、操作が終わった時刻と、期待した結果になったかを追記します。

Clarity側で該当する訪問を探したら、録画の前後を見て、メモの操作と一致するかを確認します。

URLと時間が近いだけで同じテストと決めず、確認した画面や操作の順序も照合します。

確認できた録画には、ラベルを付けて後から探せるようにできます。

Clarityの録画では「More details」→「Info」→「Labels」からラベルを追加できます（参考：録画のラベル機能）。

ラベルは「社内テスト」「フォーム検証」など、目的が伝わる名前に統一すると共有しやすくなります。

社員の名前やメールアドレスをラベルへ入れなくても、検証目的は整理できます。

必要なら識別方法を追加検討する

テスト訪問が多い場合は、サイト側でカスタムタグを付ける方法を検討します。

Clarityはキーと値を渡すカスタムタグを用意しており、録画やヒートマップの絞り込みに使えます（参考：Clarityのカスタムタグ）。

例えば、開発担当がテストと確認できた訪問だけに、次のような識別値を渡す方法があります。

// テスト対象と判定済みで、Clarityの初期化と同意条件を満たす箇所で実行する例
clarity("set", "visit_purpose", "qa_test");

この一行はテスト利用者を自動判定するものではなく、全員に実行すれば顧客の訪問にも同じ値が付きます。

判定条件はサイト側で設計し、通常の訪問へ誤って付与されないことを検証します。

タグは識別用であり、収集を停止する機能ではありません。

設定したタグは「Filters」の「Custom tags」で確認し、必要な値を選んで適用します。

公式資料では反映に30分〜2時間かかる場合があるため、実装直後に見当たらなくても、送信条件と反映待ちを分けて確認します。

タグ未設定の訪問をすべて顧客と断定せず、判定前のページや未対応の端末が残っていないかも調べましょう。

Clarityの除外設定を検証する

除外の確認は、社内の記録が見えないことだけでは完了しません。

通常の顧客に相当する訪問が引き続き記録されるかも試します。

除外側と通常側の両方で試す

まず、設定した接続元から対象ページを開きます。

公式の確認方法では、ブラウザの開発者ツールのコンソールに、プロジェクト設定により収集しない旨のメッセージが出るかを確認します（参考：IPブロックの確認方法）。

その後、除外対象ではない別の接続条件で、同じページを開いて記録を確認します。

試験時は同意状態をそろえ、Cookie拒否やブラウザの拡張機能による未記録を、IP除外の成功と混同しないようにします。

同意の状態によって収集や識別の動きが変わるため、試験結果と一緒に残します（参考：Clarityの同意管理）。

試験条件	期待する状態	確認方法
除外対象の固定回線	対象訪問が収集されない	ブロック案内と設定を照合
対象外の通常回線	条件を満たす訪問が記録される	時刻・URL・操作を照合
検証環境	本番プロジェクトへ送らない	配信タグと接続先を確認
記録を残すテスト	テストだと識別できる	メモ・ラベル・タグを確認

両方とも記録されない場合は、タグの停止や接続先の誤りなど、除外以外の原因を調べます。

両方とも記録される場合は、対象IP・通信経路・反映時間・プロジェクトを見直します。

試験の時刻を残しておけば、古い録画を新しい設定の結果と取り違えにくくなります。

過去データへの影響を確認する

除外の設定を追加した日から、過去のテスト記録まで削除されたと考えないでください。

収集条件の変更、表示フィルター、保存済みデータの削除は、別の操作として扱います。

保存期間もデータの種類によって異なるため、過去の録画を探す際は対象期間を確認します（参考：Clarityのデータ保持期間）。

以前のデータでテストと確認できるものは、ラベルなどで識別し、分析対象に含めるかを決めます。

確認できないものは、社内アクセスの混入可能性を注記し、無理に顧客だけの数字へ補正しません。

過去の録画を整理する目的で、安易にプロジェクトごと削除しないでください。

Clarityのプロジェクト削除は関連データを復元できなくなる操作であり、通常の除外設定とは異なります（参考：プロジェクト削除の説明）。

まずは、新しい除外条件が有効になった後の期間を、比較の基準として整理します。

Clarityの除外ルールを更新する

社内アクセスの除外は、一度設定して終わるものではありません。

回線・委託先・サイト構成が変わったときに、設定と分析条件を見直します。

回線と委託先の変更を反映する

次の表を、社内アクセスの除外・識別方針として使えます。

実際の環境に合わせて担当と確認日を記入し、設定を変える人と分析する人の両方で共有してください。

対象	採用する方針	見直すきっかけ
固定IPのオフィス	確認済み範囲をIP除外	移転・回線変更・拠点追加
在宅・変動する回線	別の識別や配信条件を検討	VPN・端末・接続方法の変更
検証環境	本番タグを配信しない	環境複製・新ドメイン
再現テスト	必要な記録を識別して残す	テスト手順の変更
制作・運用委託先	作業内容に応じて除外か識別	担当変更・契約終了

設定台帳には、根拠となる回線情報の確認先と、最後に両側の試験をした日を残します。

古い除外設定が残ったままだと、新しい担当者が「なぜこの訪問が記録されないのか」を判断できません。

新しい設定を足すときには、使わなくなった設定がないかも確認します。

範囲を広げる変更では、通常の訪問を巻き込まないかの試験を必ず組み込みます。

集計の注記に残す

除外を始めると、訪問数やクリック数が減って見える場合があります。

それだけで集客が悪化したとは判断せず、設定変更の日を分析レポートへ残してください。

注記には「いつから」「どの対象を」「どの方法で」分けたかを書きます。

例えば「確認済みの社内固定回線を除外し、以後の期間を比較対象にした」という記載なら、数字の前提が伝わります。

カスタムタグによる絞り込みを使った場合は、その条件と未識別の訪問が残る可能性も添えます。

保存したセグメントはプロジェクト内で共有されるため、用途が分かる名前と条件で管理します（参考：セグメントの共有と条件）。

最初に固定回線・開発環境・再現テストの三つを整理すると、必要な設定を決めやすくなります。

社内操作を適切に分け、顧客が迷っている場面へ分析の時間を使える状態を作りましょう。