Microsoft Clarityのデメリットは？導入前に確かめたい記録・分析・運用の限界

Microsoft Clarityのデメリットは、無料で使える範囲の広さだけを見ていると気づきにくくなります。

たとえば、翌月の会議で先々月の録画を見たい場合、通常の録画の保存期間では間に合いません。

外部サービスの決済画面を埋め込んでいる場合も、その中の操作まで同じように再生できるとは限りません。

導入前に確かめたいのは、自社が調べたい操作を、必要な期間、必要な人が確認できるかです。

この記事では、Microsoftの公式資料をもとに、記録・再現・分析・運用の制約を整理します。

最後の「要件と制約の適合判定表」に、自社の条件を記入すれば、採用するか、他の方法を併用するかを話し合えます。

仕様は2026年10月5日に確認した内容で、具体例は導入判断のための架空のケースです。

Microsoft Clarityのデメリットを考える前に

Clarityはヒートマップやセッション録画を使える行動分析ツールです。

その機能が、自社の調査業務に合うかを先に考えます。

必要な業務から要件を作る

「録画があること」だけでは、採用条件として十分ではありません。

広告LPで押されないボタンを探したい担当者と、半年後の問い合わせから当時の操作を調べたい担当者では、必要な条件が違います。

前者はページ内のクリック傾向と直近の操作を見られれば、調査を始められる可能性があります。

後者は保存期間に加え、問い合わせと記録を適切に照合する設計が必要です。

最初に、調べたい業務を一行で書きます。

架空の資料請求サイトなら「スマホでフォームへ進んだ後、受付完了まで進めない操作を調べる」とします。

次に、対象ページ・確認する頻度・見る担当者を付け加えます。

決める項目	このケースでの記入例
対象	サービス紹介ページと自社フォーム
調べる操作	フォーム表示から受付完了まで
確認頻度	毎週、直近の記録を確認
担当	Web担当が調査し、開発者へ修正を相談
必須条件	入力内容を隠した状態でエラー表示を確認できる

ここまで決まれば、「フォームに入力された名前が読めない」という仕様を、問題として扱う必要はありません。

一方、必要なエラー表示まで見えない場合は、調査方法の追加が必要になります。

要件は「便利そうな機能」ではなく、「この仕事を進められる条件」にします。

無料と無制限を分ける

MicrosoftはClarityを無料のサービスとして説明し、サイトのトラフィックに料金上の上限を設けないとしています（参考：ClarityのFAQ）。

ただし、無料であることは、保存期間や個別機能にも制約がないという意味ではありません。

ヒートマップは一つにつき最大10万ページビューを対象とする制限があります（参考：ヒートマップの機能と制約）。

大量のアクセスを受け付けることと、一つの分析画面が扱う範囲は分けて理解します。

「全アクセスを同じ図で長期間比較したい」という要件なら、期間や対象をどう分けるかを検討します。

料金以外にも、タグの設定・社内確認・録画の確認・修正後の検証には作業が発生します。

無料だからとりあえず設置して、見る人が決まらないまま放置すると、データがあっても改善に使えません。

導入費用を比べるときは、サービス利用料と、継続して分析するための社内作業を別々に書き出します。

Clarityで記録されない・残らない情報

録画が存在しない理由には、最初から取得できなかった場合と、保存期間を過ぎた場合があります。

どちらも、後からフィルターを変えるだけでは解決できません。

取得条件による欠落を確認する

Clarityの記録は、対象のページで計測コードが動作していることが前提です。

タグが設置されていないページや、外部サービスへ移った後の画面まで、自動的に同じ範囲で取得されるわけではありません。

ブラウザの制限や拡張機能、サイト側の同意設定によっても、取得できる内容が変わります。

特にCookie同意を必要とする構成では、同意前・許可後・拒否後を分けて検証します。

EEA・英国・スイスからの訪問では、Clarityの機能を完全に利用するために有効な同意シグナルが必要とされています（参考：ClarityのConsent Mode）。

ここで、Cookieを使わない状態と、タグをまったく起動しない状態を混同しないようにします。

自社の設定を確認するときは、Cookieの有無だけでなく、ブラウザの通信とClarity側の記録も確認します。

架空のフォームで試すなら、同じ操作を複数の同意状態で行い、時刻と対象URLを控えます。

その後、対象時間帯の録画で、ページのつながりや操作がどう残ったかを照合します。

試験条件	確認すること
初回表示で未選択	自社が決めた収集条件どおりか
同意を許可した後	必要な操作が記録されるか
同意を拒否した後	Cookie・通信・記録が想定どおりか
外部ページへ移動	自社の計測範囲がどこで終わるか

記録の欠落がある場合は、その条件のユーザーも含む全訪問者の行動だと説明しないことが大切です。

GA4と件数が違う場合も、直ちにどちらかの故障と決めず、計測対象や同意条件を先に比べます。

保持期間の条件を確認する

Clarityの通常の録画は30日間、ラベルやお気に入りを付けたセッションは9か月間、ヒートマップは9か月間保持されます（参考：Clarityのデータ保持期間）。

同じプロジェクトでも、集計結果が残っている期間と、個別の操作を再生できる期間は一致しません。

月末に前月のすべての録画を見直す運用では、通常の録画を確認できなくなる可能性があります。

必要な記録を見つけた時点でラベルやお気に入りを付ける運用を考えます。

ただし、それでも無期限保存にはなりません。

保持期間を過ぎたデータは、バックアップを含めて削除され、復元できないと公式資料に記載されています。

重要な場面を社内の改善記録へ残すときは、録画リンクだけでなく、発生条件・観察した事実・確認日時を書き添えます。

リンクが期限切れになっても、何を根拠に改善したかを説明しやすくなります。

長期の証拠保存が必須の業務では、この運用で足りるかを別途判断します。

個人情報を含む録画を別の場所へ複製して保存期間だけを延ばす方法は、権限や保管場所の問題も増やします。

保存期間の要件は、ツールの選定と情報管理の両方で確認します。

Clarityの録画で再現を確認したい画面

Clarityの録画は、画面全体をそのまま動画ファイルとして保存する仕組みとは異なります。

ページの構造や変化、操作の情報を使って再生するため、サイトの作りによって再現に差が出ます（参考：Clarityが収集するデータ）。

動的な画面と埋め込みを試す

公式資料では、第三者のiframeやHTML Canvasの中身を記録できないことが示されています（参考：録画プレーヤーの制約）。

外部の予約・決済・チャットなどを埋め込んでいる場合は、その操作をどこまで確認したいかを先に整理します。

埋め込みの枠が見えることと、その中の入力や操作が見えることは別です。

また、CSSや画像などを再生時に読み込めないと、見た目が崩れる場合があります。

録画でボタンが隠れて見えたとしても、実際の訪問時にも隠れていたとは限りません。

実サイトの操作結果と再生結果を照合してから、不具合として開発者へ渡します。

ヒートマップにも別の制約があります。

公式資料には、開閉するメニューなどの動的な領域や、ページ内の独立したスクロール領域を通常のヒートマップで扱えない場合が示されています（参考：ヒートマップの制約）。

録画で見られるか、集計図でも比較できるかを別々に試します。

自社で試す画面	確認する操作
スマホのメニュー	開閉、項目の選択、元の画面への復帰
入力フォーム	エラー表示、修正、次の工程への移動
外部サービスの埋め込み	内部操作が必要な調査に使えるか
ポップアップ	表示中の内容と閉じる操作
ログイン後の画面	再生時の見た目と情報の隠れ方

すべての画面を同じ条件で扱えると考えず、自社で重要な操作を優先して試験します。

伏せ字と再現不具合を区別する

入力した内容が伏せ字になるのは、プライバシー保護のための仕様です。

Clarityでは、入力欄とドロップダウンの内容は、すべてのマスキングモードで隠されます（参考：Clarityのマスキング）。

「何を入力したかを読みたい」という理由で、サイト全体の保護設定を緩める方針にはしません。

フォーム改善で必要なのは、入力内容そのものより、どの項目で操作が止まり、どんなエラーが出たかであることが多いためです。

架空のテストデータを使い、エラーの文言と表示位置が確認できるかを試します。

一方、レイアウト全体が崩れている場合は、伏せ字ではなく、画像やCSSの取得を確認します。

この二つを分けると、必要のないマスキング解除を避けられます。

設定を変えても、過去の録画にはさかのぼって適用されません。

公式資料では、新しい設定の反映に最大1時間かかる場合も示されています。

変更前の録画を見続けて、修正が効かないと判断しないようにします。

テストをやり直す時刻を記録し、その後の新しいセッションで結果を確認します。

Clarityの分析だけでは足りない場面

Clarityは操作の傾向を調べる材料になりますが、会社のすべての成果を自動的に説明するものではありません。

売上の確定や顧客の意図など、別の記録や調査が必要な情報を切り分けます。

売上や顧客情報との照合を考える

ClarityにはEC向けの分析機能もありますが、対応する環境や実装条件を確認する必要があります（参考：ClarityのEC分析）。

どのサイトでも、返金や取り消しまで含む確定売上が自動的に分かるとは考えません。

注文の成立は注文管理、請求の確定は決済や会計など、その情報を管理する仕組みで確認します。

Clarityでは、その前後にユーザーがどんな操作をしたかを調べる役割を持たせます。

資料請求サイトなら、フォーム送信を操作した記録と、会社側で受け付けた記録を分けます。

送信ボタンを押した後にサーバーでエラーになれば、操作があっても受付は完了していないからです。

両者を照合する場合は、必要最小限の識別方法を設計します。

メールアドレスや問い合わせ本文を、分析しやすいという理由だけで追加送信しないようにします。

GA4と連携すれば、すべての記録が自動で一対一につながるわけでもありません。

公式資料では、ClarityはGA4のセグメントをサポートせず、録画URLもGA4へ送信しないとしています（参考：ClarityのGA4連携）。

連携ボタンの有無より、必要なレポートや照合方法を実現できるかを確認します。

心理や因果関係を断定しない

Rage clicksは、狭い範囲で短時間に繰り返されたクリックなどの行動から検出されます（参考：Clarityの行動指標）。

名称に怒りを連想する言葉が含まれていても、本人の感情を直接測っているわけではありません。

例えば、数量を増やすボタンを連打しているだけの場面も、前後の操作を確認する必要があります。

記録には「同じボタンを続けて押した」と書き、理由は「反応が分かりにくかった可能性」と分けます。

同じように、ページの下まで移動したことだけで、文章を理解したとは判断できません。

ヒートマップや録画は、追加で調べる場所を見つけるために使います。

必要なら、本人への質問やユーザビリティテストで、何を探していたかを確認します。

画面を修正した後に成果が増えても、その修正だけが原因とは限りません。

広告の配信先や商品の条件が同時に変わっていないかを確認します。

AIの要約を利用する場合も、元の記録へ戻って確かめます。

Microsoftも生成AIによる分析には根拠のない内容が含まれる可能性があり、出力の確認が必要だと説明しています（参考：ClarityのAI分析に関するFAQ）。

Clarityの運用負担を見積もる

タグを設置しただけでは、改善案を作る担当者も、修正する時間も増えません。

毎週の作業と、管理者が行う設定作業を分けて見積もります。

見る担当と時間を決める

最初から全録画を見る運用にはしません。

「スマホのフォーム送信で止まる操作を調べる」のように、毎回一つの問いを決めます。

期間・ページ・端末などで絞り、問題のある場面と、正常に完了した場面を比べます。

見つかった問題だけを見ると、たまたま目立った操作を全体の傾向だと誤解しやすくなります。

観察した録画の選び方も、報告書へ残します。

たとえば「エラーが検出された録画から選定」と書いておけば、全ユーザーの発生率ではないことが伝わります。

作業	担当の決め方	残す成果物
調査の対象を決める	成果指標を管理する担当	今回の問いと条件
記録を確認する	ページを理解する担当	事実・仮説・該当場面
修正を決める	Web担当と開発担当	優先順位と修正内容
結果を確認する	変更後の指標を見られる担当	同条件での確認結果

録画を確認する時間だけでなく、修正案を共有して判断する時間も予定に入れます。

調査結果が毎回「様子を見る」で止まるなら、閲覧件数を増やすより、修正の判断者を決める方が先です。

サイトの表示速度への影響も、導入前後で確認します。

第三者のJavaScriptは読み込み方によって影響が変わるため、自社の代表ページと操作で測定します（参考：第三者のJavaScriptの読み込みを確認する）。

無料のツールだから確認不要とも、録画ツールだから必ず重いとも決めつけません。

社内ルールとの適合を確認する

Clarityのチーム管理では、管理者とメンバーで扱える設定が異なります。

メンバーは単純な閲覧専用ではなく、プロジェクト内の読み書きの権限を持ちます（参考：Clarityのチーム管理）。

社内で細かな職務分担を求めている場合は、その権限構成で足りるかを確認します。

代理店なら、あるクライアントの担当者が、別のクライアントの記録を見られない構成にします。

共有先を増やす前に、プロジェクトへの招待と、個別の録画共有を使い分けます。

保存先・共有先・削除の手順も、社内の確認項目に入れます。

「マスキングがある」ことだけで、自社の情報管理要件をすべて満たすとは判断しません。

入力後の確認画面やURLなど、ページの別の場所に情報が出ていないかもテストします。

運用担当が交代したときに、管理者だけが分からなくなる状態も避けます。

設定の責任者と、収集を止める必要が生じた場合の連絡先を残します。

Clarityを採用するか判断する

採用判断は、長所と短所の数を数えるだけではできません。

必須要件に合うか、足りない部分を別の手段で補えるかを一つずつ確認します。

必須要件を試用で確かめる

次の表は、自社で記入するための「要件と制約の適合判定表」です。

記入例は架空であり、実際のClarityプロジェクトで検証済みという意味ではありません。

要件	公式仕様との照合	自社で残す判定
直近のフォーム操作を毎週見る	通常録画の保持は30日	対象フォームで再現を試験
半年前の全録画を後から選ぶ	全通常録画の保持条件と合わない	要件の変更または他の方法を検討
外部iframeの入力を再生する	第三者iframeの中身は対象外	外部サービス側の調査手段を確認
氏名を読まずにエラーを見る	マスキングと再現の両方が関係	架空データで表示を試験
閲覧だけの権限で招待する	標準メンバーの権限と要照合	必要な権限分離を再確認
注文の確定を把握する	注文管理の記録も必要	照合方法を別途設計

判定は「適合」「条件付き」「不適合」「未検証」に分けると整理しやすくなります。

未検証の項目を、導入できそうという印象だけで適合へ変えないようにします。

各行に確認した日付と担当者を付け、対象のページや設定の条件も残します。

必須要件が不適合なら、他の便利な機能が多くても、その用途での採用は見直します。

一方、ある部署の要件に合わないことだけで、他の用途にも使えないとは判断しません。

広告LPの改善に絞れば使える、といった利用範囲の調整も考えられます。

足りない部分の補い方を考える

売上の確定は注文管理、流入の比較はGA4、操作の確認はClarityという役割分担もできます。

同じ指標名でも、対象や集計方法が違う場合は、その違いを書き添えます。

画面の再現が足りない場合は、別の録画ツールでも、同じ画面を使って試験します。

有料サービスに変えれば、すべてのiframeやマスキングの制約がなくなるとは限りません。

比較時には、保存期間・再現範囲・権限・共有方法・自社で必要な運用をそろえます。

ツールを追加するほど、タグや情報管理の点検も増えるため、目的が重なるものを無条件で増やさないようにします。

まずは一つの対象ページで、必要な操作を確認できるかを試します。

その結果を適合判定表へ記入してから、対象を広げると判断の根拠が残ります。

Clarityの基本機能はMicrosoft Clarityの入門記事、日々の確認方法は毎週見る録画の選び方でも解説しています。

情報管理の項目を先に整理したい場合は、セッションリプレイ導入の確認項目も併せて使ってください。