ClarityをGTMで導入する方法｜タグの発火・同意・二重計測を確認

ClarityをGTMで導入するときは、タグの作成よりも「どのサイトで、いつ動かすか」を先に決めると迷いません。

GTMにタグが保存されていても、本番の訪問が記録されるとは限りません。

逆に、新しいタグを正しく作れていても、テーマに残った古いタグが別の経路で動いている場合があります。

コンテナの確認、同意と発火条件の設定、プレビュー、本番公開、録画の照合までを一続きで進めましょう。

この記事では、GTMのワークスペース内で確認してから公開できる、Clarity公式テンプレートを使う方法を中心に説明します。

画面名と仕様は2026年10月5日に公式資料で確認したもので、表のドメインや担当者名は説明用の架空例です。

特定の読者のコンテナで試験を代行した結果ではないため、最後の検証表に自分のサイトの結果を残してください。

ClarityをGTMで導入する前の確認

コンテナと公開権限を確認する

最初に、GTMのアカウント名、コンテナ名、コンテナID、設置先のURLを一組にして確認します。

同じ会社のアカウントでも、採用サイトとサービスサイトが別のコンテナなら、作業先を取り違えると目的のページには反映されません。

Googleタグマネージャーを開き、作業対象のWebコンテナを選びます。

そのIDが対象サイトに設置されているものと一致するかを、サイトの実装担当者やTag Assistantで確かめます。

既にGTMが動いているサイトへ、今回のためだけに別のコンテナを追加する必要があるとは限りません。

GTMの権限には閲覧・編集・承認・公開の違いがあり、編集権限だけでは本番へ公開できません（参考：GTMのユーザーと権限）。

自分で公開できない場合は、設定を作る担当者と公開する担当者を最初に決めます。

確認項目	記入例	確認する相手・場所
対象サイト	shop.example	サイト管理者
GTMコンテナ	店舗サイト用Webコンテナ	GTM管理画面
作業内容	Clarity公式タグの追加	変更依頼
公開担当	サイト運用担当	公開権限のあるメンバー
計測しない範囲	管理画面・検証環境	運用方針

この表に「不明」が残るなら、タグの追加より先に設置先を確認してください。

直貼りタグが残っていないか調べる

移行作業では、既にあるClarityの設置経路を一覧にします。

GTM内のタグだけを見ると、WordPressのプラグインやテーマ設定から出力されるタグを見落とします。

ClarityのプロジェクトIDと、clarity.ms/tag/ を探すときの手掛かりとして、次の場所を確認してください。

設置経路	確認する場所	今回の扱い
直貼り	共通のHTML・head要素	切り替え時に旧設置を停止
CMSの設定	テーマの解析タグ欄	同じIDが残っていないか確認
プラグイン	解析・タグ挿入機能	出力元を記録
GTM	タグ一覧・カスタムHTML	既存タグの有無を確認
アプリのコード	初期化処理・パッケージ	実装担当者へ照会

Clarityには手動設置やNPMなど複数の導入経路があるため、GTMだけを停止しても他の経路まで止まるとは限りません（参考：Clarityの設置方法）。

新旧の切り替え日時を合わせ、必要な記録が長く途切れる期間と、重複する期間の両方を避けます。

ただし、Clarityへの通信が複数回あるだけで「二重計測」とは決めないでください。

記録の送信は一回で完結するとは限らないので、タグの読み込み元や初期化経路を追って判断します。

GTMでClarityのタグを用意する

公式の連携方法を確認する

Clarity公式には、Clarity側からGTMへ接続する方法、公式テンプレート、カスタムHTMLによる方法が案内されています。

Clarity側の接続には作成と公開をまとめて行う操作があるため、社内レビューを挟む運用では、そのまま実行する前に公開範囲を確認しましょう。

ここでは、GTM内で公式テンプレートを追加して検証する手順を使います。

1. 対象のGTMコンテナで「タグ」から新規タグを作ります。
2. 名前を「Clarity｜本番サイト」など、用途が分かるものにします。
3. タグの設定から、コミュニティテンプレートギャラリーを開きます。
4. Clarityを検索し、「Microsoft Clarity - Official」を選びます。
5. テンプレートの内容を確認してワークスペースへ追加します。
6. ClarityのプロジェクトIDを入力します。
7. 次の節で決めるトリガーを設定して保存します。

提供元と名称は、追加時にも公式案内と照合してください（参考：MicrosoftのGTM導入手順）。

テンプレートの追加、タグの保存、本番への公開は別の操作です。

保存ができた時点では、検証を進めるための設定ができた状態として扱います。

カスタムHTMLを採用する事情がある場合も、公式の現行コードを使い、同じプロジェクト用のテンプレートタグを重ねて追加しないようにします。

プロジェクトIDを取り違えない

ClarityのプロジェクトIDと、GTMのコンテナIDは別のものです。

名前が似た案件を扱っているときは、記事のサンプルや別案件のメモからIDをコピーせず、対象のClarityプロジェクトを開いて確かめます。

Clarityで表示しているサイト、GTMへ入力したID、確認する録画一覧を同じ組にそろえてください。

検証用と本番用の区別も、ここで記録します。

用途	サイトのホスト名	Clarityの送り先	本番公開の対象
本番の訪問を分析	shop.example	本番用プロジェクト	対象
実装検証	staging.example	検証方針に応じた送り先	本番用には含めない
管理操作	admin.example	計測しない方針	対象外

これは環境を整理するための架空例で、実際の構成はサイトごとに決めます。

GTMの環境機能を使う場合は、環境ごとのスニペットと公開先の対応も必要です（参考：GTMの環境機能）。

検証環境が別URLだから自動的に計測対象から外れる、と考えないことが大切です。

同じGTMコンテナが複数のドメインで使われているなら、次の発火条件で対象を明示します。

Clarityの発火条件をGTMで決める

対象ページの条件を決める

トリガーは、タグを動かすきっかけと条件です。

初期導入では、対象ドメインと計測するページを先に書き出します。

例えば、公開の商品ページを調べたいのに、管理画面や顧客情報を表示する画面まで同じ条件で対象にする必要はありません。

GTMではトリガーの種類と条件を組み合わせられ、ページのURLなどを条件にできます（参考：GTMのトリガーと条件）。

次は、公開ページを対象とする場合の設計例です。

項目	方針の例	試すケース
ホスト名	shop.exampleに限定	本番とstagingの両方
対象ページ	商品・記事・案内ページ	それぞれ一つずつ
除外ページ	管理・個人情報の表示画面	直接アクセスも確認
同意条件	採用する運用方針に合わせる	未選択・許可・拒否

変数が一覧に出てこない場合は、対象の組み込み変数が有効かを確認します。

広すぎる「含む」条件では、意図しないURLも対象になることがあります。

ホスト名の一致、パスの条件、例外の組み合わせを、実際に存在するURLで検証してください。

ページビュー系のトリガーには実行タイミングの違いがあるので、早く動かしたいという理由だけで同意初期化用のトリガーを選ばないようにします（参考：ページビュートリガーの種類）。

同意状態に合わせる

Clarityの同意連携と、GTMがタグを読み込む条件を分けて考えます。

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

ただし、同意モードでCookieを制御することと、タグや通信を一切動かさないことは同じではありません。

Clarityの同意モードには、拒否時でもCookieなしの限定的な収集を行う動作があるためです（参考：Clarityの同意管理）。

「許可されるまでClarityを読み込まない」方針なら、その読み込み条件もGTMとCMPの構成に合わせて設計します。

GTMの追加同意チェックは、トリガーが評価された時点で必要な同意が許可されているかを確認します（参考：GTMの同意設定）。

後からバナーで許可しただけで、前に止めたタグが必ず再実行されると考えないでください。

利用するCMPが同意更新をどう伝え、その後にどのイベントでタグを動かすのかまで確認します。

採用する方針	確認すること
同意前は読み込まない	タグが未選択・拒否で動かず、許可後に必要な処理が動くか
同意モードで制御する	連携した状態とCookie・通信の実際が方針に合うか
再訪時は前の選択を使う	保存された選択が初期化時から反映されるか
利用者が撤回できる	撤回直後と次のページで期待した状態になるか

同意状態ごとの詳しい確認は、ClarityのCookie同意設定でテスト表付きで説明しています。

GTMプレビューでClarityを検証する

想定ページで一度だけ発火するか見る

GTMのプレビューは、未公開のコンテナ設定を使ってサイトの動作を調べるための機能です。

ワークスペース右上のPreviewを押し、Tag Assistantで対象サイトのURLを入力して接続します（参考：GTMのプレビューとデバッグ）。

接続後は、テストするページを開いた時刻と操作をメモしておきます。

Tag Assistantで対象イベントを選び、Clarityタグが発火したか、発火しなかったかを確認してください。

同意を待つ構成なら、許可する前と後を分けて見ます。

タグを開いて、使われたプロジェクトID、変数の値、トリガー条件を照合します。

「一度だけ」の意味は、同じページでタグを初期化する経路が不要に重なっていないか、ということです。

GTMには一イベントごと・一ページごとなどの発火オプションがありますが、これは同じタグの実行を制御するもので、別の直貼りタグを消す機能ではありません（参考：タグの発火オプション）。

ページを再読み込みせず画面が変わるサイトでは、画面遷移のたびに初期化を増やす前に、既存の記録がどう続くかを確認します。

操作	見る場所	判定の観点
対象ページを開く	Tag Assistantのイベント	期待したタグが動く
同意を変更する	同意状態と後続イベント	方針どおりに変わる
次の画面へ進む	ページ遷移とタグ履歴	不要な再初期化がない
再読み込みする	新しいページの履歴	送り先と条件が変わらない

発火した表示だけで、Clarityへ届いたと判断するのは早いので、公開後には受信側でも照合します。

拒否時や対象外ページでも試す

成功するケースに加え、記録したくないケースも試します。

ブラウザに前回の許可が残っていると初回訪問を再現できないため、新しいテスト用プロファイルなどで未選択の状態を用意してください。

その状態で、バナーを触る前、拒否した後、許可した後を別々に記録します。

対象外ページは、対象ページからの遷移だけでなく、そのURLを直接開いた場合も確認します。

SPAのように同じページ上で画面が切り替わる構成では、最初に読み込んだスクリプトが残る点にも注意が必要です。

GTMの次回発火を止める条件だけで、既に動いている記録まで停止できるとは限りません。

以下の表は実測前に使う空欄付きの検証表です。

ケース	期待する動作	実際の動作	結果
対象ページ・未選択	採用した同意方針どおり	記入	未確認
対象ページ・拒否	同意・通信・Cookieが方針と一致	記入	未確認
対象ページ・許可	正しい送り先へ記録	記入	未確認
対象外ページへ直接訪問	計測対象外の方針どおり	記入	未確認
対象から対象外へ遷移	継続中の記録も含めて確認	記入	未確認
検証環境	本番用の記録に混在しない	記入	未確認

未確認の行は、確認済みに置き換えず、公開前に残っている作業として渡します。

Clarityのタグを公開して確認する

公開バージョンに説明を残す

プレビューで必要な条件を確認したら、変更一覧を見直して公開します。

GTMの公開対象には、今回のタグ以外のワークスペース変更が含まれている可能性があります。

Clarityだけを追加したつもりでも、他の担当者が編集した広告タグを一緒に公開しないように、差分を確認してください。

Submitから公開用のバージョンを作り、変更内容を説明してPublishを実行します（参考：タグの検証と公開）。

バージョン名には、何を変えたかが後から分かる言葉を入れます。

例えば「Clarity導入・商品ページのみ」のように、ツール名と対象範囲を組み合わせます。

公開記録の項目	記入例
変更内容	公式テンプレートのClarityタグを追加
発火条件	対象ホストとページ条件を限定
同意連携	利用中CMPの更新イベントを確認
旧設置	テーマの直貼りを同時に停止
検証結果	別紙の全ケースで結果を記入
戻し先	公開直前のバージョンを記録

「設定変更」とだけ書くより、障害時に戻す対象を判断しやすくなります。

公開する環境が複数ある場合は、最後に公開先も照合します。

実サイトの記録と照合する

公開後はプレビューを終了し、通常の訪問としてもう一度動作を確認します。

Tag Assistantでの成功と、本番サイトへの反映を別のチェックにするためです。

テスト用のデータで対象ページを開き、必要な同意操作をしたうえで、リンクを一つ進むなど識別しやすい操作を行います。

このとき、URL、時刻、端末、同意状態、実施した操作を控えてください。

ブラウザのNetworkでは、Clarityへのスクリプト取得や収集通信を見て、送信先と失敗の有無を確認できます（参考：ChromeのNetworkパネル）。

通信先へ正常に送れたことと、期待する録画が閲覧できることも別の確認です。

Clarityで正しいプロジェクトを開き、該当する時刻やページ条件でテスト訪問を探します。

観察した状態	次に確認する場所
GTM自体が動かない	コンテナの設置先・読み込みエラー
GTMは動くがタグが動かない	トリガー・同意・例外条件
タグは動くが通信が失敗	ブロック・ネットワーク・ブラウザのエラー
通信はあるが録画が見つからない	プロジェクトID・期間・フィルター
録画はあるが見た目がおかしい	CSS・画像・再現可能な範囲

見つからないときに新しいタグを追加するのではなく、どこまで確認できたかを切り分けましょう。

録画の見た目の問題は、Web録画の再現トラブルを調べる手順で詳しく扱っています。

GTMでClarityの設置を変更するとき

タグを停止する手順を用意する

導入時には、止める担当者と操作も決めておきます。

タグを一時停止したい場合は、GTMで対象タグを開き、メニューからPauseを選んで保存し、その変更を公開します（参考：GTMのタグを一時停止する）。

保存しただけでは、公開済みのサイトの動作は変わりません。

停止後は新しいページ読み込みでタグの動作を確認し、既に開かれていたページでの状態も別に調べます。

過去のコンテナバージョンを使って復旧する方法もありますが、Clarity以外の変更まで戻る可能性があります（参考：GTMのバージョンと公開）。

現在の変更との差を見て、タグ単体の停止とコンテナ全体の復旧を選び分けてください。

停止は既に保存された録画を削除する操作ではありません。

記録の保存や削除が必要な案件は、その対応を別の作業として管理します。

状況	対応の考え方	確認する結果
Clarityだけを止めたい	対象タグの一時停止を公開	他のタグは維持される
コンテナ変更全体に問題	差分を確認して復旧版を公開	必要な機能が戻る
別経路でも動いている	その設置元も確認	目的の経路が停止する
記録内容に問題がある	計測停止と保存済みデータの対応を分離	両方の担当が明確になる

後からタグが重複しないよう管理する

導入が終わったら、サイトの運用台帳へ設置場所を残します。

後日、別の担当者がWordPressの解析プラグインを入れたときに、Clarityも重ねて有効化するのを防ぐためです。

「Clarity導入済み」だけでなく、「どのコンテナのどのタグで管理しているか」まで書きます。

同意連携の担当、マスキングの設定、対象外ページも同じ記録からたどれるようにしてください。

引き継ぐ情報	残す内容
設置元	GTMコンテナID・タグ名
送り先	Clarityプロジェクト
対象範囲	ホスト・ページ・例外
同意連携	CMP・更新の仕組み・検証表
公開履歴	バージョン・日時・担当
再確認の契機	テーマ変更・CMP更新・プラグイン追加
停止手順	一時停止と公開・確認方法

サイトを更新したときは、以前の検証表を使って影響するケースを再確認します。

同じ表が残っていれば、正常だった条件と今回変わった条件を比較できます。

GTM導入の完了は、タグがあることではなく、必要な条件で正しく記録され、対象外では運用方針どおりに動くことです。

記録が確認できたら、Clarityの録画から改善点を探す手順へ進み、最初に調べるページを一つ決めましょう。