WordPressにMicrosoft Clarityを導入するには？設定と二重設置の確認方法

WordPressにMicrosoft Clarityを入れるなら、まず公式プラグインで接続できるかを確認します。

ただし、プラグインを有効にする前に、テーマやGoogleタグマネージャーから同じタグが出ていないかを調べることが大切です。

「設定できた」と「公開ページの操作を正しく確認できる」は、別の確認項目です。

この記事では、公式プラグインの接続から、キャッシュ、ログイン状態、スマートフォンの録画までを順番に点検します。

最後に残すのは、担当者が変わっても設置場所と動作確認の結果を追える一枚の表です。

手順は2026年10月5日時点の公式資料を基に整理しており、掲載する確認表は記入例で、個別のWordPress環境での動作保証ではありません。

WordPressにClarityを入れる方法を選ぶ

導入方法を増やす前に、いま誰がどこで計測タグを管理しているかを確認します。

公式の導入方法を確認する

Microsoftは、WordPress向けの公式Clarityプラグインを案内しています。

WordPress.orgでは、プラグイン名だけでなく、提供者がMicrosoftであることを確認できます（参考：Microsoft Clarity公式プラグイン）。

基本の導入手順は、次のとおりです。

1. 対象サイトのWordPress管理画面にログインする
2. 「プラグイン」から「新規追加」を開く
3. 「Microsoft Clarity」を検索する
4. 提供者と現在の対応条件を確認してインストールする
5. 有効化し、管理メニューからClarityを開く
6. サインインして、既存プロジェクトへの接続または新規作成へ進む

Microsoftの案内では、この手順はWordPress上のWooCommerceサイトにも適用されます（参考：WordPressプラグインの導入手順）。

プラグイン追加のメニューが見つからない場合は、権限、マルチサイトの管理方法、利用しているホスティングの条件を確認してください。

WordPress.comを利用している場合も、自己管理のWordPressと同じ条件だと決めず、現在のプランでプラグインを利用できるかを確認します（参考：WordPress.comのプラグイン利用）。

すでにGTMで計測を一括管理しているサイトなら、運用担当者と相談し、既存の設置経路を維持する選択肢もあります。

GTMで進める場合の操作は、ClarityをGTMで導入する手順で確認できます。

テーマとGTMの既存設定を調べる

新しくプラグインを入れる前に、Clarityがすでに設置されていないかを棚卸しします。

確認する場所は、テーマの計測設定、コード挿入用プラグイン、GTM、独自のテーマファイルなどです。

制作会社に設置を依頼していた場合は、管理画面だけを見て「未設置」と判断しないようにします。

次の表は、設置場所を調べるための記入例です。

設置候補	確認するもの	記録する内容
Clarityプラグイン	有効状態と接続先	プロジェクトID、管理者
GTM	公開中のタグと発火条件	コンテナ、タグ名、対象ページ
テーマの設定	解析用コードの入力欄	設定名、出力する場所
コード挿入プラグイン	有効なコード	コード名、適用範囲
独自テーマ	共通ヘッダーなど	ファイル、管理担当者

ブラウザーでタグの読込先が見えても、その出力元がプラグインなのかGTMなのかは別に確認する必要があります。

手動設置はサイトのhead要素へコードを入れる方式なので、テーマ経由のコードも確認対象です（参考：Clarityの手動設置）。

二つの経路が見つかった場合は、すぐ両方を消さず、残す経路と停止する経路を決めます。

WordPressとClarityの設定を対応づける

接続先を間違えると、タグが動いていても、見たいサイトの記録を探せなくなります。

対象のプロジェクトを選ぶ

プラグインからサインインしたら、既存プロジェクトの一覧で対象サイトを選び、「Continue」で接続します。

該当するプロジェクトがなければ、「New project」から必要事項を入力して作成できます（参考：プロジェクトを接続する手順）。

ここでは、プロジェクト名が似ていることだけで選ばないようにします。

本番サイト、制作中のサイト、旧ドメインのサイトを、URLとプロジェクトIDで照合してください。

クライアントのサイトなら、将来も管理を続けるアカウントに必要なアクセス権があるかも確認します。

担当者個人だけが接続先を把握している状態では、契約終了や異動のときに確認が止まります。

WordPressのログイン権限と、Clarityプロジェクトのメンバー権限は、それぞれ別に管理します（参考：Clarityのチーム管理）。

接続後は、公開ページを一度操作し、その訪問を選んだプロジェクトで探します。

管理画面に接続済みと表示されたことだけで、対象サイトとの対応確認を終えないようにしてください。

変更前の状態を記録する

作業前の記録は、あとで不具合が起きたときに戻すためにも役立ちます。

有効なテーマ名、プラグイン名、接続先、キャッシュの設定場所を控えます。

GTMを併用している場合は、公開中のバージョンと、Clarityに関係するタグ名も残してください。

次は、導入作業のための架空の記入例です。

項目	記入例
対象	本番の企業サイト
残す設置経路	Microsoft Clarityプラグイン
接続先	対象サイトのプロジェクトIDを記入
旧経路	GTM内の旧Clarityタグを確認中
同意の管理	現在利用しているCMPと担当者を記入
キャッシュ	配信キャッシュの更新担当を記入
確認ページ	トップ、記事、LP、問い合わせ
戻す方法	変更前の設定記録に基づき復元

表にパスワードや認証コードを貼る必要はありません。

変更対象を具体的に残し、バックアップや復元の方法はサイトの管理手順に合わせます。

複数の担当者がいる場合は、誰が公開反映を行い、誰が未ログイン状態で確認するかを分けておくと進めやすくなります。

WordPressのページでClarityを動かす

最初の確認は、WordPressの管理画面ではなく、訪問者が実際に開く公開URLで行います。

投稿・固定ページで確認する

トップページで記録できても、すべてのテンプレートで同じように動くとは限りません。

通常の投稿、固定ページ、独自のLP、問い合わせページを、それぞれ開いて確認します。

ページビルダーで作ったLPや独自テンプレートは、ほかのページと表示の仕組みが違う場合があります。

検証時には、操作時刻、URL、端末、ログイン状態、同意の選択をメモしてください。

ブラウザーの開発者ツールでは、Networkを開き、ページを再読み込みしてClarity関連の通信を調べます。

Microsoftは、サイトを操作したときのclarity.ms/collectへのPOSTリクエストを、設置確認の方法として案内しています（参考：Clarityの設置を検証する）。

ただし、通信が見えたことと、期待するページの録画を確認できたことは分けて記録します。

次の順番で見ると、途中で止まっている場所を整理できます。

1. 公開ページに対象のタグが出ているかを確認する
2. 同意の選択後に想定どおり通信するかを確認する
3. 対象プロジェクトでテスト訪問を探す
4. URLと操作時刻を照合する
5. メニューやフォームの操作が再現されるかを見る

読み込みのたびにデータ送信が複数回発生しても、それだけで二重設置とは断定できません。

二重設置を調べるときは、送信件数の多さではなく、初期化コードの出力元、プロジェクトID、タグの発火元を確認します。

キャッシュ更新後のHTMLを確認する

設定を保存したのにタグが出ない場合は、キャッシュに変更前のページが残っていないかを調べます。

WordPressのキャッシュには、生成したページを保存するものや、ブラウザーにファイルを保持するものなどがあります（参考：WordPressのキャッシュ）。

管理者として開いた画面と、一般の訪問者へ配信される画面が同じとは限りません。

まず対象ページを未ログインのブラウザーで開き、変更後のタグが配信されているかを確認してください。

更新が必要な場合は、利用しているキャッシュ機能の手順で、対象範囲を確認して更新します。

ページキャッシュ、CDN、ブラウザーのどこを更新したかも作業記録に残します。

JavaScriptの遅延実行や最適化を利用している場合は、同意の選択や画面操作の前後で、タグがいつ読み込まれるかを調べます。

「高速化を全部無効にすればよい」と考えると、原因を特定しないまま別の影響を増やしてしまいます。

切り分けは検証環境で一つずつ行い、変更した条件と結果を対応づけてください。

正常に記録されたあとも、通常のキャッシュ設定へ戻した状態で、もう一度同じページを確認します。

WordPressの管理者訪問をどう扱うか

記事を編集する人の訪問と、内容を読む人の訪問では、目的も操作も違います。

ログイン中と未ログインで試す

WordPressにログインした状態で公開ページを開くと、管理バーなど、一般の訪問者にはない要素が表示される場合があります。

そのため、導入確認はログイン中と未ログインの両方で行います。

同じURLを開き、同じメニュー操作を行って、タグの有無と録画の結果を比較してください。

「ログインしている人は全員スタッフ」とは限らない点にも注意が必要です。

WordPressには管理者、編集者、投稿者、購読者などの権限があり、会員サイトでは一般の利用者もログインします（参考：WordPressの権限と役割）。

ログイン状態だけで計測を止めると、分析したい会員の行動まで除外する可能性があります。

社内の確認作業を除外したい場合は、どの役割や環境を対象にするのかを先に決めます。

ClarityのIPブロックを使う場合も、固定IPかどうかなどの条件を確認します（参考：ClarityのIP除外）。

具体的な切り分けは、Clarityで社内アクセスを除外する方法にまとめています。

WordPressの管理画面にClarityのメニューが表示されることと、管理画面の操作を録画することも同じ意味ではありません。

確認するのは、各URLへどのタグが出ているかと、そのときの収集条件です。

問い合わせ情報の表示範囲を確認する

問い合わせフォームは、入力欄だけでなく、確認画面と送信後の表示まで確認します。

入力した値が、確認画面では普通の文章として表示される構成があるためです。

Clarityは入力欄などをマスクしますが、ページ上のすべての個人情報を無条件に判別できると考えないようにします（参考：Clarityのマスキング）。

検証では実在する顧客情報を使わず、確認用のダミー値を用意してください。

入力、エラー、確認、完了の各状態で、表示される情報と録画上の見え方を照合します。

確認する状態	注目する場所	記録する結果
入力中	入力欄、入力補助	値が適切に隠れるか
エラー表示	メッセージ、再入力欄	値を文章で表示していないか
確認画面	名前、住所、問い合わせ本文	追加マスクが必要か
送信完了	受付内容、会員情報	記録対象に含めるか
遷移先URL	クエリ文字列など	個人情報を載せていないか

追加マスクの設定後は、新しいテスト訪問で確認します。

過去の録画にも同じ設定が自動で反映されると考えないようにしてください。

Cookie同意を扱う場合は、バナーの表示だけでなく、選択内容が計測へ渡るかも別に検証します（参考：Clarityの同意管理）。

Clarityの録画でWordPressの表示を確認する

録画を再生するときは、映像の印象だけでなく、自分が行った操作の順序と照合します。

スマホのメニューを試す

スマートフォンでは、メニュー、追従ボタン、目次、Cookieバナーが重なる場面を確認します。

最初の表示がきれいでも、メニューを開いたあとに閉じられなければ、訪問者は先へ進めません。

検証時は、次のように短い操作順を決めておきます。

1. 記事ページを開く
2. メニューを開いて閉じる
3. 目次から本文へ移動する
4. 下へスクロールして追従ボタンを見る
5. 問い合わせページへ進む

Clarityでは、この順序が録画で追えるかを確認します。

押した場所、移動先、メニューが開いていた状態を、実際の操作と見比べてください。

録画でクリックだけが見えても、開閉の状態を読み取れなければ、その記録だけで「訪問者が迷った」と判断しないようにします。

開発者ツールのスマートフォン表示は確認の補助になりますが、実際の端末の操作感まで同一ではありません。

主要な端末で、指によるタップと画面の向きの変化も確認すると、録画と実画面の差を整理できます。

テスト結果には「実機」か「ブラウザーの端末表示」かを記録し、検証した範囲を区別してください。

画像とフォームの状態を照合する

録画の一部が白い場合は、実サイトの不具合なのか、録画の再現範囲なのかを切り分けます。

Clarityの再生画面では、第三者のiframe内の内容など、表示できない範囲があります（参考：Clarityの録画プレイヤー）。

外部サービスの予約フォームや埋め込みコンテンツでは、この制限が関係する可能性があります。

画像が遅れて表示される構成なら、スクロール前と後の状態を実画面でも確認してください。

フォームでは、送信ボタンを押したことだけでなく、完了表示へ進んだことを確認します。

業務上の受付完了は、必要に応じてフォーム側のテスト結果とも照合します。

次のように記録すると、再現上の制限をサイトの障害として誤って報告しにくくなります。

実画面	録画	次に調べること
正常に表示	入力値だけ隠れる	マスキングの想定と一致するか
正常に表示	外部フォームが白い	iframeなどの再現範囲
画像が出ない	画像が出ない	元ページの画像配信
送信が失敗	エラーも再現される	フォームの検証条件と通信
操作できる	状態を読み取れない	録画以外の確認手段

録画の見え方だけを直すために、必要なマスクを外すことは避けます。

切り分けを詳しく進める場合は、Web録画がずれる・白くなるときの確認手順も利用できます。

WordPress更新後のClarity点検

Clarityの設置は、初回の作業だけでなく、テーマやプラグインの更新後にも確認します。

テーマ変更時にタグを再確認する

テーマの設定欄へタグを入れていた場合は、テーマ変更後も同じコードが出るかを確認します。

親テーマのファイルへ直接加えた変更は、更新で失われることがあるため、コードの管理方法も見直します（参考：WordPressの子テーマ）。

一方、公式プラグインから設置していても、テーマ変更でメニューやフォームの構造が変われば、録画の確認対象は変わります。

マスキングに使ったCSSの指定が、新しいページ構造でも対象へ当たるかを確認してください。

更新前にテストしたURLを、そのまま更新後の確認リストに使うと比較しやすくなります。

次は、WordPress用の設置経路と動作確認表のひな型です。

対象ページ	設置経路	確認条件	結果	次の対応
トップ	プラグインなど	未ログイン・PC	記入	記入
通常の記事	同上	未ログイン・スマホ	記入	記入
独自LP	出力元を確認	同意の選択前後	記入	記入
問い合わせ	出力元を確認	ダミー入力・確認画面	記入	記入
会員ページ	方針に基づく	会員ログイン中	記入	記入

表の上部に更新日、テーマ、プラグインのバージョン、担当者を添えて保存します。

計測の確認が必要だからといって、セキュリティ更新を放置する運用にはしないようにします（参考：WordPressのプラグイン・テーマ更新）。

不要な設置経路を整理する

重複が見つかったら、維持する設置経路を一つ決め、その経路の動作と同意条件を確認します。

たとえば、公式プラグインを残すなら、GTM側のClarityタグを停止する変更を整理します。

GTMでほかの計測も行っている場合、コンテナ全体を取り外す必要はありません。

Clarityに関係する変更だけを確認し、公開時にほかの担当者の変更が混ざっていないかも確認してください。

古い経路を止めたあとは、未ログインの公開ページで再読み込みし、残した経路が動くことを確かめます。

タグが見えなくなった場合に戻せるよう、停止した場所と変更日時を記録しておきます。

整理後の引き継ぎには、「プラグインを入れた」という説明だけでは足りません。

接続先、設置経路、同意の管理、社内訪問の扱い、テストしたページを一緒に渡します。

これで、担当者が交代しても、次のテーマ更新で何を確かめるべきかが分かります。

まずはトップページ、記事、問い合わせの三つを選び、設置経路と確認結果を表に埋めるところから始めてください。