ヒートマップは意味ない？アクセスが少ないサイトで判断を急がない使い方

「ヒートマップを入れたのに、どこを直せばいいか分からない」と感じることがあります。

アクセスが少なく、数件のクリックしか表示されなければ、ツールを使う意味そのものに疑問を持つかもしれません。

ただ、データが少ないことと、何も確認できないことは同じではありません。

押せないボタンを再現できたなら修正に進めますが、数件の操作だけで利用者全体の好みを決めることはできません。

ヒートマップを役立てるには、今直せること、追加で調べること、結論を保留することを分けます。

この記事では、アクセスが少ないサイトを想定し、計測条件の見直しから録画・操作テストの使い分けまで解説します。

最後の判断表を埋めれば、データが増えるのを待つ間に何をするかも決められます。

機能や調査方法の説明は2026年10月5日に確認した一次資料に基づき、登場するサイトや件数は説明用の架空例です。

ヒートマップが意味ないと感じる場面

データが少ない状態を確認する

最初に確認したいのは、サイト全体のアクセスではなく、今開いているマップの対象件数です。

サイト全体に訪問があっても、特定のURL・端末・期間で絞ると、調べたいページの記録は少なくなります。

逆に、アクセスが少ないと思っていても、日付やURL条件の指定を間違えている可能性があります。

例えば、スマートフォンの広告流入だけを見たいのに、PCだけのフィルターが残っていると、欲しい記録は出てきません。

次の項目を一つずつ確認してください。

点検すること	確認する内容
計測開始日	タグを設置した日より前を見ていないか
対象URL	正しいドメイン・ページ・URL条件か
期間	調べたい訪問が含まれる日付か
端末・流入	前回の絞り込みが残っていないか
件数の単位	PV・セッション・ユーザーのどれか
取得状況	設置・同意・除外などの条件が意図どおりか

Clarityのヒートマップは、タグが設置された対象ページの記録を使います（参考：Microsoftのヒートマップ機能説明）。

表示されない場合は、現地の画面でタグが動いているかを先に点検しましょう。

公式の導入手順では、ブラウザーの開発者ツールでClarityへの通信を確認する方法も案内されています（参考：Clarityの手動セットアップ）。

通信があることと、期待した内容の記録が完成したことは分けて確認します。

テスト訪問が現れるか、その訪問に対象ページが含まれるかまで追うと、単なるアクセス不足と取得の問題を区別しやすくなります。

改善につながらない状態を分ける

ヒートマップを開いても何も決められないときは、件数だけが原因とは限りません。

調べる問いがない、比較する条件が違う、修正の担当者が決まっていない、といった状態も考えられます。

まず「今、どの判断ができないのか」を短く書いてください。

「ページが良いか知りたい」では広すぎるので、「スマートフォンで相談ボタンまで届いているか」のように範囲を絞ります。

この問いなら、スクロールの状況とボタンの操作を確認する作業に分けられます。

止まっている理由	最初に行うこと
記録そのものがない	計測と対象条件を点検する
色は出るが問いがない	判断したい操作を一つ決める
画面とクリックが合わない	対象時期と画面の版を確認する
問題は見つかるが直せない	担当者と変更できる範囲を決める
前後比較の件数が足りない	効果の結論を保留し、別の確認方法を選ぶ

GOV.UKの調査ガイドも、何を知れば次の判断ができるかを、調査前に明確にする考え方を示しています（参考：調査の目的を決める方法）。

最初から全ページの改善案を出そうとせず、一つの操作に答えを出す使い方に変えてみましょう。

一回の確認で何も変えないという結論になっても、追加で何を調べるかが決まれば前進です。

データの量を増やす前に、調査結果を使う場面を用意することが大切です。

少ないアクセスで見てよいこと

明確な不具合を調べる

一件の録画でも、調べる価値のある不具合が見つかることはあります。

例えば、スマートフォンの固定バナーが送信ボタンを覆い、操作を妨げている場面です。

このとき必要なのは、「全員が困っている」という結論ではなく、同じ条件で障害を再現できるかという確認です。

担当者の端末や検証環境で同じ表示を開き、同じ操作ができないかを試します。

再現できたら、端末・画面幅・ブラウザー・対象URL・操作手順を記録してください。

段階	架空の記録例
観察	送信ボタン付近を押したが、画面が進まなかった
再現	同じ画面幅で固定バナーがボタンを覆った
修正依頼	バナー表示中も送信ボタンを操作できるようにする
完了確認	同条件と別端末で送信の動作を確かめる

修正の優先度は、観測件数だけでなく、その操作が止まったときの影響も考えて決めます。

購入や問い合わせを完了できない不具合なら、再現できた事実を担当者へ早く共有する価値があります。

ただし、録画の表示が崩れているだけの可能性も残ります。

Clarityの再生には、第三者のiframeやHTML Canvasなど、再現できない領域があります（参考：Clarityの録画プレイヤーと制約）。

録画だけを根拠に画面を作り直さず、実画面でも同じ問題が起きるかを確かめましょう。

不具合を直したことと、CV率が改善したことも別々に報告します。

全体傾向を断言しない

少ない記録では、一件増えるだけで割合が大きく変わります。

架空の例として、対象の10セッション中1件がCTAを押したなら10%、2件なら20%です。

割合は倍になりますが、変わった件数は1件です。

この違いを見ずに「新しいボタンで反応が2倍」と報告すると、根拠より強い結論になります。

レポートには必ず件数と割合を併記してください。

架空の集計	CTAを押した件数	割合	言えること
期間A・10セッション	1	10%	この条件で1件確認した
期間B・10セッション	2	20%	この条件で2件確認した

この表から、ページ全体の改善効果や利用者全体の好みまでは判断しません。

比率の不確かさを扱う統計的方法はありますが、NISTも、小さい標本などでは単純な正規近似が十分でない場合を説明しています（参考：NISTの比率の信頼区間）。

統計処理を付ければ、選び方の偏りや計測漏れまで解消されるわけでもありません。

例えば、困っている録画だけを選んで10件見た結果を、全訪問の困りごとの割合にはできません。

「確認した記録の中にこの操作があった」と、「利用者の何割に起きている」を分けて書きます。

件数が少ないときほど、結論を短く、確認できた範囲を具体的にしましょう。

ヒートマップの収集条件を見直す

対象を広げすぎない

データが少ないからといって、無関係なページまで合算すると判断しにくくなります。

資料請求ページと読み物の記事では、期待する操作もボタンの位置も異なるためです。

最初は、改善したい一つのページと一つの操作を残します。

そのうえで、不要な絞り込みを外す余地があるかを調べてください。

例えば、端末・広告キャンペーン・地域・新規訪問を同時に指定して数件しかないなら、今回の問いに必要でない条件を一つずつ外します。

ただし、スマートフォンの誤タップを調べているのにPCを混ぜると、問い自体が変わってしまいます。

残す条件と外す条件を、次のように理由付きで決めると整理できます。

条件	架空の判断	理由
URL	残す	対象CTAの位置を固定する
スマートフォン	残す	タップの問題を調べる
広告の細かな区分	いったん外す	今回は操作できるかの点検
期間	同じ版の範囲で広げる	画面の変更前を混ぜない

Clarityには端末や行動などのフィルターがあり、条件に応じて記録を絞り込めます（参考：Clarityのフィルター）。

条件を外す際には、比較したい対象が変わったことも記録してください。

また、記録を増やす目的で、利用者の同意や設定を無視して計測範囲を広げてはいけません。

Clarityでも同意の状態に応じた設定が案内されているため、自社の収集方針と実際の実装をそろえて確認します（参考：Clarityの同意管理）。

不足しているデータを無理に埋めるより、取得できた範囲で答えられる問いに調整します。

似たページをまとめる条件を決める

商品詳細など、共通のレイアウトを使うページなら、まとめて調べる方法も考えられます。

ただし、URLの名前が似ているだけでは十分ではありません。

同じ位置に同じ役割の要素があり、利用者が同じ目的で操作するかを確認してください。

架空のECサイトで、同じ商品テンプレートの「配送条件を開く」という操作を調べる例を考えます。

商品によってボタンが別の場所にある、売り切れ時には購入できない、会員向け価格が出る、といった違いがあるなら、まとめ方を見直します。

ClarityではURLを追加して複数ページのヒートマップを作れますが、表示する条件の指定が必要です（参考：複数ページをまとめたヒートマップ）。

機能として合算できることと、分析として合算してよいことは分けて考えましょう。

まとめる前の確認	同じ条件にする理由
ページの目的	読むページと買うページを混ぜない
要素の役割	同じ位置でも機能が違う場合を避ける
レイアウト	クリック位置の解釈をそろえる
在庫や利用状態	操作できない条件を混在させない
公開した版	変更前後の画面を分ける

合算した結果で気になる場所を見つけたら、元のURLへ戻って確認します。

一つの人気商品だけが数字を押し上げている場合もあるためです。

まとめた条件と、個別ページで確認した結果の両方を残すと、別の商品にも同じ修正を広げるべきか判断しやすくなります。

少量データを録画で補う

問題の前後を確認する

ヒートマップは操作が集まった場所を示しますが、その前後に何が起きたかは録画で補います。

「同じ場所を押している」という情報だけでは、表示待ちなのか、別の情報を探しているのか分かりません。

見る前に、答えたい問いを一つ決めてください。

架空の資料請求ページなら、「料金の説明を開いた後に、請求ボタンへ進めるか」という問いが考えられます。

対象の場面を含む記録を開き、操作の直前から目的の行動までを確認します。

Clarityのクリックマップでは、要素を選び、その要素がクリックされた録画へ移動できます（参考：クリックした要素の録画を開く方法）。

その機能で選ばれた記録は、クリックした訪問の集まりであり、ページを見た人全体の無作為な標本ではありません。

録画を見た結果は、次の三つに分けて記録しましょう。

区分	架空の記入例
見えた操作	料金の見出しを押した後、同じ位置をもう一度押した
仮説	詳細が開くと思っていた可能性がある
次の確認	実画面の動作と、別の記録を確かめる

GOV.UKの調査分析ガイドも、見聞きした観察と、その意味の解釈を分けて整理する方法を示しています（参考：調査結果の整理方法）。

「料金が高いと思って離脱した」といった心理は、クリックとスクロールだけでは確定できません。

分からないことを仮説として残せば、次に本人へ聞くことや、試す変更を具体化できます。

通常操作も見る

目立つエラーや連打の記録だけを見ると、サイト全体が使いにくいように感じることがあります。

比較のために、同じ条件で目的の操作を完了した記録も確認しましょう。

正常に進めた人が別の経路を使っているなら、問題のある導線を見直す手掛かりになります。

例えば、料金カードでは止まった一方、上部のメニューからは同じ情報へ進めている、といった違いです。

見る対象を選ぶときは、「問題あり」「完了まで進んだ」「途中で終わったが理由不明」など、選んだ理由を残します。

これは発生率の推定ではなく、異なる操作の形を確認するための選び方です。

比較する記録	確認すること
問題が見えた記録	どの操作で止まったか
完了した記録	どの経路なら進めたか
理由不明の記録	判断できない箇所はどこか

ClarityのDead clicksやRage clicksは絞り込みの手掛かりですが、それだけで離脱理由を確定する指標ではありません（参考：Clarityの行動指標）。

正常な記録にも同じラベルがあるなら、その場面の役割を確認する必要があります。

反対に、ラベルがなくても目的を達成できていない記録はあり得ます。

「ラベルが付いたものだけ直す」という運用にせず、今回の問いに答えられる場面を選んでください。

ヒートマップ以外の調査を組み合わせる

少人数の操作テストを行う

実際の訪問が少ない場合は、対象となる利用者に操作を試してもらう方法があります。

その際は「このボタンを押してください」と答えを教えるのではなく、達成したい目的を伝えます。

架空の法人向けサイトなら、「条件に合うプランを確認し、相談を申し込む場所まで進んでください」という課題です。

どこを探し、何を読んで判断し、どこで止まるかを観察します。

GOV.UKは、目的が明確で、利用者にとって自然で、答えを誘導しない課題を作ることを勧めています（参考：操作テストの課題の作り方）。

テスト前には、実際の送信や購入をどこで止めるか、使ってよいデータ、記録の方法を決めてください。

以下は小さく始めるための準備メモです。

準備欄	決める内容
調べる問い	料金を理解して相談の場所へ進めるか
参加者	想定顧客に近い人
課題	答えを示さず、達成したい目的を伝える
終了条件	実送信の前、または許可したテスト完了まで
記録	操作、発言、困った場面、補助した場面
取り扱い	録画の説明・同意・保存先・閲覧者

人数を少なくして始める場合も、それで利用者全体の割合が分かるわけではありません。

GOV.UKの計画ガイドは、インタビューや操作テストと、A/Bテストなどの量的な方法では、必要な参加人数の考え方が異なると説明しています（参考：調査方法と人数の考え方）。

「少人数で問題を発見すること」と「何割の人に起きるかを測ること」を混同しないでください。

得られた問題を修正し、次の調査で同じ操作を確認する流れにすると、訪問数が増える前から改善を進められます。

問い合わせの内容も確認する

問い合わせやサポートの記録には、画面だけでは分からない困りごとが残ることがあります。

「料金が見つからない」「送信できない」「会員登録が必要か分からない」といった内容です。

個人情報を広く共有する必要はなく、困っている操作と発生条件を必要な範囲で整理します。

そのうえで、ヒートマップや録画で調べている問いと照合してください。

架空の例として、配送条件の問い合わせがあり、該当する見出しへのクリックも確認できたとします。

この二つは、配送条件への導線を調べる理由にはなりますが、問い合わせがない人も全員困っている証明にはなりません。

問い合わせをする人と、何も伝えず離れる人は同じ集団とは限らないためです。

GOV.UKの運用段階の調査ガイドでも、分析データや問い合わせなどを使って問題を把握し、必要に応じて詳しい調査につなげる考え方を示しています（参考：運用中のサービスの利用者調査）。

情報源	分かる手掛かり	残る確認
問い合わせ	本人が伝えた困りごと	他の利用者にも起きるか
録画	実際に残った操作	操作の理由や目的
ヒートマップ	集計対象の操作位置	個別の前後関係
操作テスト	課題に対する行動と発言	普段の利用でも起きるか

異なる情報源で同じ場面が示されたら、修正候補の優先度を検討します。

ただし、一致したからといって因果関係を確定せず、実画面での確認と修正後の点検を続けましょう。

ヒートマップ分析を続けるか判断する

保留する結論を残す

調査の最後に、結論が出ない項目を消してしまわないことが大切です。

何が足りないかを記録すれば、次回は同じ所からやり直さずに済みます。

次の「少量データの保留・調査判断表」は、そのための記入例です。

確認したこと	今の判断	次に必要なこと
固定バナーがボタンを覆うことを再現した	修正へ進む	対応後の同条件テスト
画像へのクリックを数件確認した	原因は保留	前後の録画と操作テスト
CTAクリック率が少し上がった	効果は保留	同条件の件数と完了数
対象ページに記録がない	分析を止めて計測点検	タグ・URL・同意状態の確認
調べる問いを決めていなかった	閲覧範囲を絞る	一つの操作と担当者

この表の判断は、件数だけで機械的に決めるものではありません。

再現できる障害か、変更の影響をどの程度受けるか、他の確認方法があるかも含めて考えます。

例えば、問い合わせ完了の障害を再現できたなら、全体の発生率が不明でも修正を検討できます。

一方、好みの色を選ぶような変更は、数件の違いで決めず、別の根拠や比較方法を用意します。

保留した項目には、追加確認の担当者を付けてください。

「データが少ない」で終わらず、「何が分かれば判断できるか」まで書くことで、調査を次の作業へつなげられます。

再確認日を決める

ヒートマップに必要なPV数を、どのサイトにも共通する一つの数字で決めることはできません。

調べる操作の頻度、比較したい差、端末や流入の分け方、計測の抜けなどが関係するためです。

「一定のPVを超えるまで何もしない」という運用にも、「少し色が出たので結論を出す」という運用にもせず、問いに合わせて再確認します。

例えば、次の定例で対象ページの件数と新しい問い合わせを見直す、次回の公開後に不具合の再現を確認する、といった日付を決めます。

その日付は統計的に十分なデータが集まる保証ではなく、調査を放置しないための区切りです。

記録の保存期間も、再確認の予定に含めてください。

Clarityの公式資料では通常の録画は30日、ラベルやお気に入りを付けた録画などには別の保持条件が示されています（参考：Clarityのデータ保持）。

必要な場面を参照できるかを確かめつつ、不要な情報を広く保存し続けない運用にします。

次回の確認で同じ問いに答えられない場合は、待つ期間だけを伸ばすのではなく、操作テストや問い合わせ確認へ切り替えることも検討しましょう。

アクセスが少ないサイトでは、全体の傾向を急いで決めるより、再現できる問題を直し、分からないことを次の調査へ渡す使い方が現実的です。

まずは一つのページを選び、判断表の「次に必要なこと」を一つ埋めてください。

録画を見る対象の選び方は、毎週見るセッションリプレイの選び方で詳しく解説しています。

利用者に操作を試してもらう流れは、ユーザビリティテストのやり方を参照してください。

クリックの集計を読み直したい場合は、クリックヒートマップの見方も役立ちます。