アテンションヒートマップとは？「赤い場所＝読まれた」と決めない見方

アテンションヒートマップとは、ページ内の滞在などの情報を、位置ごとの色で見られる図です。

赤くなった場所を見つけたら、「よく読まれた」と結論を出す前に、その色が何を数えているかを確認します。

料金表で止まっている人は、丁寧に比較しているのかもしれません。

一方で、条件が分かりにくく、先へ進めない可能性もあります。

この記事では、アテンションヒートマップの定義、長く表示された場所と短く表示された場所の調べ方、改善メモの作り方を解説します。

Clarity・Ptengine・SiTestの公式資料を2026年10月5日に確認し、操作の例は主にClarityで説明します。

途中の料金ページや観察メモは、読み方を説明するための架空例です。

アテンションヒートマップの意味

製品ごとの計測方法を確認する

アテンションヒートマップは、製品名をまたいで一つの共通指標になっているわけではありません。

画面の名前だけでなく、何を計測し、どう集計した色なのかを確認してください。

例えば、ClarityのAttention mapsは、ページの部分ごとの平均滞在時間と、平均セッション時間に対する割合を表示します（参考：Microsoft Learn：Attention maps）。

Ptengineは、アテンションヒートマップを滞在時間に基づく表示として説明しています（参考：Ptengine：ヒートマップ分析の基本手順）。

また、Ptengineの2024年の更新案内には、着色の基準を積み上げた時間から平均時間へ変更した記録があります（参考：Ptengine：アテンションヒートマップの更新）。

古い使い方の記事を読む場合は、現在の集計方法と一致するかを確かめましょう。

SiTestでは、ディスプレイにページが表示されていた時間を可視化する機能を、スクロールヒートマップと呼んでいます（参考：SiTest：ヒートマップ解析機能）。

製品・機能名	公式説明で確認できる対象	読むときの注意
Clarity・Attention maps	部分ごとの時間	時間と割合の列を区別する
Ptengine・アテンションヒートマップ	滞在時間	古い集計方法の説明を流用しない
SiTest・スクロールヒートマップ	ページが画面に表示されていた時間	到達率だけの図だと思い込まない

つまり、「スクロール」と書かれた図が、どの製品でも同じものとは限りません。

ClarityのScroll mapsは到達位置を調べる機能なので、SiTestの名称から内容を推測しないようにします。

実際の分析では、画面名、単位、対象期間、集計条件を一緒にメモします。

視線計測との違いを整理する

ページ上に色が重なっていても、その図が訪問者の目の動きを測った結果とは限りません。

視線計測は、目の位置や動きを捉え、どこを見ているかを推定する技術です。

Tobiiの説明では、カメラなどで取得した目の情報から、視線の位置や動きを計測する仕組みが紹介されています（参考：Tobii：What is eye tracking?）。

一般的なWeb解析の滞在時間は、それとは異なる情報です。

ページが表示されていても、訪問者が隣の画面を見ていたり、別の作業をしていたりする場合があります。

マウスポインターが文章の上に置かれていることも、視線が同じ位置にある証拠にはなりません。

次のように、確認できた範囲で言い換えると誤解を減らせます。

言い切りやすい表現	記録に沿った表現
料金表を熟読した	料金表付近の滞在時間が長かった
見出しに興味がない	対象条件では、その位置の時間が短かった
赤い位置に視線が集まった	対象の指標が、その位置で高かった
内容を理解した	その後、目的の操作へ進んだ

最後の例でも、操作できたことと、説明をすべて理解したことは同じではありません。

理解度を確かめたい場合は、利用者に課題を試してもらい、説明の受け取り方を確認する方法を加えます。

実施の手順は、ユーザビリティテストとWeb録画の使い分けで紹介しています。

アテンションヒートマップを見る前の準備

同じページ版で集計する

最初に、調べたいページを一つ選びます。

ここでは、架空のサービスの料金ページで「料金条件を確認してから、申込へ進めるか」を調べる例を使います。

集計期間の途中で料金表の位置を変えていたら、変更前後を分けてください。

今の画面に以前の記録を重ねると、同じ高さにあった別の説明を見てしまう可能性があります。

Clarityなら、Heatmapsを開き、対象のVisited URL、期間、端末を設定してからAttention mapsを選びます。

そのうえで、表示されているスクリーンショットが調査対象の状態かを確認します。

設定や画面の切り替えは、Clarityの公式操作説明にまとまっています。

確認項目は、次のように短く残せます。

対象：サービスAの料金ページ
調べる問い：料金条件を確認してから申込へ進めるか
端末：スマートフォン
期間：料金表の変更後
ページの版：月額・年額の切り替えを追加した版
対象の状態：月額を表示した状態
除外して考える条件：旧価格、公開前の社内テスト

月額と年額を切り替える画面なら、どちらの状態を見ているかも必要です。

スクリーンショットを選び直す機能があっても、それだけで対象データが特定の状態に絞られたとは限りません。

画面の見た目と、データのフィルター条件は別々に確認してください。

改修日が分からない場合は、担当者や変更履歴に確認してから前後比較を行います。

端末ごとにデータを分ける

PCとスマートフォンでは、同時に画面へ入る情報の量が違います。

PCで横に並んだ料金プランが、スマートフォンでは縦に続く場合もあります。

この状態で同じ位置の色を比べても、同じ説明を見ているとは限りません。

まず端末を分け、その端末の実際のレイアウトを確認します。

スマートフォンでは、固定ボタンやバナーが本文に重なっていないかも見てください。

表示領域に入った位置でも、上から別の要素が重なれば、説明の読める範囲が変わります。

料金表が横スクロール式なら、縦方向の到達だけで全プランを見たとは判断できません。

表示の違い	実画面で点検すること
プランが縦に並ぶ	後ろのプランへ進めるか
表が横にはみ出す	横スクロールに気づけるか
固定CTAがある	注意書きやリンクを隠していないか
説明が折りたたみ式	開く操作と展開後の内容
文字を拡大する	見出しと説明の対応が保たれるか

端末をそろえたら、必要に応じて流入元や訪問の条件を分けます。

料金を初めて確認する訪問と、申込を決めて戻ってきた訪問が混ざっていないかを考えるためです。

ただし、データが少ない状態で条件を細分化しすぎると、偶然の動きが目立ちます。

色が表示されたことと、比較に十分な記録が集まったことは別に扱います。

長く表示された場所を調べる

比較表や料金の内容を確認する

暖色になった場所は、詳しく調べる候補です。

料金表なら、金額の大小だけでなく、何が含まれ、どこから追加費用が発生するかを確認します。

例えば、月額料金の近くに年払いの条件が離れて書かれていないでしょうか。

利用上限や対象機能が別のページにあり、何度も往復する構成かもしれません。

Ptengineの公式解説も、長い滞在を関心だけで捉えず、内容の分かりにくさがないかを調べるよう説明しています（参考：Ptengine：アテンションヒートマップの読み方）。

読むのに必要な時間と、情報を探し直す時間を、すぐに一つへまとめないようにします。

次の表は、料金表を見るときの確認例です。

対象	調べる問い
金額	月額・年額・税込などの条件が近くにあるか
機能の違い	同じ言葉で比較できるか
利用上限	超えた場合の扱いが分かるか
注釈	どの項目の説明か対応が分かるか
申込ボタン	選んだプランが次の画面へ引き継がれるか

Clarityでは、色に加えて対象位置の平均時間を確認できます。

ただし、同じ赤色だから同じ秒数だと、別の画面や別の製品の図を並べて判断しないでください。

凡例と数値を確認し、報告には色だけでなく、指標名と集計条件も添えます。

「料金表が赤いので人気」という説明から、「料金条件を確認しやすいか調査する」へ、次の作業を具体化しましょう。

操作停止の前後を再生する

滞在が長い箇所を見つけたら、同じページ・端末・期間の録画を確認します。

調べたいのは、停止した画面だけでなく、その直前と直後の操作です。

説明を開いて止まったのか、ボタンを押して反応を待っていたのかで、確認すべき点が変わります。

Clarityの再生画面では、操作のない時間を飛ばすSkip inactivityが使えます（参考：Microsoft Learn：録画の再生操作）。

停止時間自体を調べる場面では、通常の録画再生に戻り、その設定と再生速度を確認してください。

短く再生されたから実際の滞在も短かった、とは限りません。

停止の前	停止の後	追加確認の候補
料金プランを切り替えた	別のプランへ切り替えた	比較条件と表示の対応
申込ボタンを押した	同じボタンを押し直した	処理中・成功・エラーの表示
注釈を開いた	申込画面へ進んだ	必要な説明を得られた可能性
操作が止まった	記録が終わった	理由は未確定のまま残す

上の表は、観察から次の確認を決めるための架空例です。

最後の行を、直ちに「文章が難しくて離脱」と書かないようにします。

ブラウザには、ページが表示中か、別タブなどで非表示かを通知する仕組みがあります（参考：MDN：Page Visibility API）。

ただし、製品がその情報をどう集計へ反映するかは、各製品の仕様確認が必要です。

表示中という情報があっても、人が実際に読み続けていたことまでは証明できません。

分からない理由を無理に埋めず、確認できた操作だけを残してください。

短く表示された場所を調べる

説明が不要だった可能性を考える

寒色の場所があっても、すぐに削除する必要はありません。

その説明を読む必要がない人が、目的の場所へ進んでいる場合もあるためです。

既存の利用者が料金変更を確認するなら、サービスの基本説明を通り過ぎるかもしれません。

広告で機能を確認した人が、すぐ料金表へ進む場合も考えられます。

こうした背景は仮説として扱い、利用者の知識や意図を色から断定しないようにします。

短い滞在の意味は、そのページの役割と合わせて考えます。

ページの役割	短い滞在で確認すること
必要な情報への案内	目的のリンクへ進めたか
簡潔な回答	回答をすぐ見つけられる構成か
複数商品の比較	必要な比較項目へ移動できたか
申込前の重要条件	条件を確認する機会があるか

すべての説明を長く表示させることが、改善になるとは限りません。

迷わず次の操作へ進めるようになれば、必要な時間が短くなる場合もあります。

反対に、重要な条件を隠して申込だけ増やす変更は、後の問い合わせや取消につながる可能性があります。

時間の長短だけでなく、必要な情報を確認できる構成になっているかを点検してください。

短くなった説明を削る場合も、その情報を必要とする人の入口を残します。

見つけにくい情報を探す

短い滞在の後に上下へ何度も移動しているなら、探している情報が見つけにくい可能性があります。

録画では、最初に止まった位置、戻った見出し、開いたリンクを順に確認します。

例えば、料金表を通過してFAQへ進み、再び料金表へ戻ったなら、条件の説明を探しているかもしれません。

これは仮説なので、実際のFAQの内容と、料金表からの導線を照合します。

ブラウザのページ内検索や端末全体の操作は、Web録画に完全には表れない場合があります。

見えない操作を想像で補わず、自分で同じ問いを持ってページを探してみましょう。

架空の料金ページなら、次のような課題を設定できます。

確認する課題：利用上限を超えた場合の費用を見つける
開始位置：料金ページの上部
確認方法：スマホの実画面で、初見のつもりで探す
残す記録：選んだ見出し、開いた説明、戻った位置
判断しないこと：自分一人の操作を利用者全体の傾向にする

ページ内検索も自分で試すと、使われている言葉が見つけやすいかを点検できます。

「追加料金」と検索しても、説明が別の用語だけで書かれている場合があります。

見出しを変える候補は、利用者の問いと本文の内容が対応するものにします。

言葉を目立たせるだけでなく、必要な情報へたどり着けるかを確認してください。

利用者に試してもらう場合は、答えの位置を先に教えず、探す過程を観察します。

アテンションと他のヒートマップを合わせる

スクロール到達を重ねて見る

時間を読む前提として、その場所へ到達する機会があったかを確認します。

ClarityのScroll mapsでは、位置に応じた到達割合や、スクロール前に見える範囲の平均位置を確認できます（参考：Microsoft Learn：Scroll maps）。

同じURL・期間・端末で、Attention mapsと切り替えて見ます。

一枚の画像へ無理に重ねるより、同じ見出しを対応させて表へ記録すると、指標を混同しにくくなります。

到達と時間の組み合わせ	次に確かめること
到達が多く、時間も長い	必要な比較か、分かりにくさか
到達が多く、時間が短い	すぐ判断できたか、通過したか
到達が少なく、時間が長い	到達した一部の行動と情報の位置
到達が少なく、時間も短い	配置、入口、そもそもの必要性

この表は、色から結論を決める表ではありません。

次に何を調べるかを選ぶための整理です。

特に、平均時間が誰を分母にしたものかは重要です。

ページ全体の訪問を含むのか、対象位置へ来た記録だけなのかなど、製品の指標定義を確認してください。

説明が確認できない場合は、独自に人数や時間を計算して断定しないようにします。

また、改修でページの長さが変わると、同じ50%地点が同じ説明とは限りません。

比較するときは、割合だけでなく、見出しや要素の名前を基準に対応づけます。

クリックと成果を確認する

滞在と到達を見たら、次の操作を確認します。

料金表の後で、対象プランの申込へ進んだか、別の説明を開いたかを調べます。

Clarityのクリックマップでは、要素ごとのクリックを確認し、その要素を操作した録画を調べられます（参考：Microsoft Learn：Click maps）。

ただし、クリック数とクリックした人数は同じではありません。

一人が何度も押した操作を、複数人の反応だと思わないようにします。

クリック後に申込画面へ進めたか、エラーで止まったかも分けてください。

最終的な成果は、申込完了や購入完了など、そのサイトで定義した結果で確認します。

GA4を併用する場合は、対象期間・URL・端末のほか、回数と人数のどちらを比較するかもそろえます。

両方の役割は、GA4とヒートマップの違いと併用方法で詳しく説明しています。

例えば料金の説明を簡潔にした後、滞在が短くなり、申込へ進む操作が増えることはあり得ます。

その結果を、色が薄くなったという理由だけで悪化と扱わないでください。

一方で、訪問者の流入条件も変わっていれば、文章修正だけの効果とはまだ言えません。

アテンションヒートマップの改善メモ

事実と理由の仮説を分ける

調査の結果は、滞在・到達・クリックの読み分け表にまとめます。

最初の欄には、管理画面や実機で確認できた事実を書きます。

次の欄には、考えられる理由と、それを確かめる方法を書いてください。

次は、架空の料金ページを調べたときの記入例です。

項目	確認できた事実	理由の仮説・次の確認
滞在	追加料金の注釈付近で時間が長い	条件の比較か、説明の分かりにくさか
到達	対象期間では注釈位置への到達が少ない	上部から案内があるか点検
クリック	FAQへのリンクが押されている	リンク先で解決する問いを確認
録画	料金表とFAQを往復した記録がある	同じ課題を実機で試す
成果	申込完了との関係は未集計	対象条件をそろえて別途確認

色の画像だけを貼るより、次の担当者が何を確かめればよいかが明確になります。

観察した録画の件数と、選んだ条件も残しましょう。

問題がありそうな録画だけ選んだ場合、その中の割合をサイト全体の発生率にはできません。

操作停止の多い録画を意図的に見たなら、その選び方を明記します。

画像を保存する場合は、期間・端末・対象ページの条件を付け、後から取り違えない名前にします。

個人情報などが映る可能性のある資料は、共有範囲と表示内容を確認してから渡してください。

修正対象を一つ選ぶ

改善メモができたら、最初の修正を一つの問いに絞ります。

例えば「追加料金の条件を、料金表の近くで確認できるか」という問いです。

その場合は、該当条件の短い説明と、詳細への導線を修正対象にできます。

同時に価格、プラン、広告、ボタンの色まで変えると、何が結果に関係したかを調べにくくなります。

修正前に、確認方法と比較条件も残します。

問い：追加料金の条件を見つけられるか
変更：料金表の近くに条件の要約と詳細リンクを配置
操作確認：スマホで対象条件を探し、詳細から戻れるか
計測確認：同じ版・端末・流入条件で到達と次の操作を見る
成果確認：申込完了と問い合わせ内容を別に確認
結論の条件：記録が少なければ効果の断定を保留する

これは実績ではなく、改善計画の記入例です。

変更後は、最初に実画面の動作を点検し、その後のデータを確認します。

Clarityには二つのヒートマップを比較する機能がありますが、比較表示そのものが因果関係を証明するわけではありません（参考：Microsoft Learn：Heatmaps Compare）。

条件をそろえたA/Bテストを行う場合の考え方は、ヒートマップをA/Bテストに使う手順も参考になります。

アテンションヒートマップを使う目的は、ページを赤くすることではありません。

必要な情報を見つけ、理解を助け、次の操作へ進めるかを調べるために使います。

滞在・到達・クリックを分けて記録すれば、色の印象を、具体的な確認と修正へつなげられます。