スマホのヒートマップ分析｜誤タップ・固定CTA・メニューの見直し方

スマホのヒートマップ分析は、赤い場所を増やすための作業ではありません。

押したい場所を押せるか、必要な情報を確認できるか、目的の操作を終えられるかを調べるために使います。

固定ボタンがよく押されていても、その手前で説明を隠していたら、良い導線とは限りません。

メニューの開閉が多いときも、人気があるのか、目的地を探し直しているのかで対応が変わります。

この記事では、スマートフォンだけ成果が低いページを対象に、誤タップ・固定CTA・メニューを点検する順序を整理します。

具体的な画面名はMicrosoft Clarityの公式資料を例にし、最後にそのまま使える「スマホ操作の点検シート」を用意しました。

操作の説明は公式資料に基づくもので、読者のサイトで検証済みという意味ではありません。

以下のページや記入例は、考え方を示すための架空例です。

スマホのヒートマップを分けて見る理由

同じURLでも、PCとスマホでは情報の並び方も操作方法も変わります。

最初にスマホの表示と記録をそろえると、PCでは起きない問題を探しやすくなります。

PCとの画面差を確認する

PCで横に並ぶ料金表は、スマホでは縦に長くなることがあります。

PCの常設メニューが、スマホではボタンを押すまで開かない構成になることもあります。

同じ説明文でも、スマホでは改行が増え、申込ボタンまでの距離が伸びます。

そのため、PCのヒートマップで人気の場所を見つけても、スマホで同じ位置を直せばよいとは限りません。

Clarityではヒートマップ上部でPC・Tablet・Mobileを切り替えられます（参考：クリックマップの表示項目）。

対象URLを指定したら、まずMobileを選び、背景の画面が調べたいページの版に合っているか確認してください。

メニューの配置や固定ボタンが現在と違う場合は、変更前後の期間を分けます。

架空の資料請求ページなら、「料金説明の後にあるCTA」と「画面下に固定されたCTA」を別の要素として記録します。

どちらも同じフォームへ進むからといって、二つの役割が同じとは限りません。

ページ名だけでなく、端末・画面状態・公開した版までそろえることが分析の出発点です。

タップとマウスの違いを整理する

スマホでは、マウスを重ねて説明を表示する操作を前提にできません。

MDNは、主要な入力機器でホバー操作が使えるかを調べるhoverメディア特性を説明しています（参考：hoverメディア特性）。

「スマホだからすべて同じ」と決めるのではなく、実際に利用する入力方法で説明やメニューへ到達できるかを確認します。

例えば、PCではカーソルを置くと開く商品分類が、タップではリンク先へ移動するだけなら、操作の設計を見直す必要があります。

スマホの録画に現れるタップ位置を、視線の位置として扱わないことも大切です。

指を置いていない時間に、利用者がどこを見ていたかは分かりません。

スクロールの途中で触れた場所と、押す意思を持って触れた場所も、色だけでは区別できません。

同じ場所への連続タップを見つけたら、その前後に何が表示され、何が起きたかを録画で確かめます。

観察メモは「ボタン付近を繰り返しタップした」と書き、「イライラしていた」は別の仮説欄へ分けてください。

意図を決めつけないことで、必要な修正を絞りやすくなります。

スマホの分析条件を整える

スマホ全体の平均では、一部の画面幅やブラウザでだけ起きる問題が隠れます。

ただし細かく分けすぎると、判断に使える記録が少なくなります。

画面幅とブラウザを確認する

最初は「対象ページ・期間・Mobile」の条件で、全体を見ます。

その後、問題がありそうな録画の端末情報を確認し、必要な条件だけを追加します。

ClarityのFiltersにはDevice・Browser・Operating systemがあり、端末やブラウザごとに対象を絞れます（参考：Clarityのフィルター）。

ブラウザ名を一つ選んだ結果を記録したら、別のブラウザも同じ期間・ページで見てください。

画面幅は「Mobile」という分類名だけで済ませず、問題のある録画で確認できる表示寸法や再現用の端末情報も残します。

管理画面に必要な条件がないときは、取得できていない情報を推測で埋めないようにします。

架空の点検メモなら、「iPhoneのSafariで確認」「フォーム入力中」「キーボード表示あり」のように、画面の状態まで書きます。

次に担当者が再現するとき、同じ条件を作れることが重要です。

PC版Chromeでスマホ幅へ縮めた表示は、問題を探す入り口には使えます。

ただしChromeのDevice Modeはモバイル端末の近似であり、実機での操作を完全に再現するものではありません（参考：Device Modeの位置づけ）。

録画で気になる組み合わせを絞り、その実機で確認する順序なら、やみくもに多数の端末を試さずに済みます。

広告流入を分ける

スマホとPCの差に見えても、広告の内容や訪問目的が違うことがあります。

例えば、PCは社名検索からの訪問が多く、スマホは初めて見るSNS広告からの訪問が多いなら、端末だけの比較にはなりません。

まず同じページへ入った記録を選び、広告流入とそれ以外を分けます。

ClarityではTrafficのSource・Medium・Campaignなどを使って、UTMに基づく流入条件を絞れます（参考：流入条件のフィルター）。

URLを途中で閲覧した人と、そのURLから訪問を始めた人も区別してください。

広告を押した直後のページを調べたいときは、入口の条件をそろえる必要があります。

条件をそろえたうえで、広告の約束と、最初に見える内容がつながっているかを確認します。

「料金を確認」と案内した広告なのに、スマホでは料金表まで長くスクロールする必要があるなら、情報の置き場所を検討できます。

一方で、その広告を見た人の購入意欲が高いかどうかは、ヒートマップだけでは分かりません。

比較のために広告キャンペーンを新設する必要もありません。

今あるキャンペーンの記録を、同じ計測条件で分けるところから始めます。

比較前に固定する項目	記録する内容
ページ	対象URLと表示の版
期間	開始日・終了日・変更日
端末	Mobileと、確認できたブラウザ・OS
流入	UTM条件、入口ページ
成果	フォーム完了などの定義

条件別の見方は、広告別にLPの反応を比較する手順でも解説しています。

ヒートマップで誤タップを探す

誤タップの候補は、リンクの周辺や、近接したボタンから探します。

見た目の大きさと、実際に押せる範囲の違いに注目してください。

小さいリンクの周辺を見る

文字の周囲に余白があっても、その余白まで押せるとは限りません。

リンク文字だけが反応する設計なら、利用者はボタンに見える場所を押しても先へ進めないことがあります。

調べるときは、まず実ページで押せる範囲を確認し、ヒートマップの反応と照らし合わせます。

ClarityのDead clicksは、クリックに対する効果や反応が見られない場所を探す手がかりです（参考：クリックの種類）。

これを誤タップの確定結果として扱わず、該当要素の録画へ進みます。

ただの文章を触ったのか、押せると思った要素を触ったのかは、前後の操作を見ても断定できない場合があります。

「資料請求」の文字の周囲にタップがあり、その後に文字の中央を押して進んだなら、押せる範囲を広げる仮説を立てられます。

サイズの点検には、WCAG 2.2の達成基準2.5.8が参考になります。

同基準のAAでは原則24×24 CSSピクセル以上のターゲットを求めますが、間隔・文章中のリンク・同等の操作などの例外があります（参考：ターゲットのサイズ・最低限）。

したがって、24という数字だけを測って、ページ全体の適合や使いやすさを判定することはできません。

見える枠ではなく実際の操作範囲を確認し、例外の条件も含めて判断するのが基本です。

隣り合うボタンを確認する

押したいボタンの近くに別の操作があると、意図しない移動が起きる可能性があります。

架空のECページで「サイズ表」と「カートに入れる」が隣り合っているなら、それぞれの範囲と間隔を確認します。

一方を押した直後に戻り、もう一方へ進む記録は、押し間違いの候補になります。

ただし、先にサイズ表を確認してから商品へ戻っただけなら、自然な操作です。

画面の録画だけで結論を出さず、同じ配置を実機で触って確かめます。

WCAGのターゲットサイズには、44×44 CSSピクセルを原則とするAAAの強化基準もあります（参考：ターゲットのサイズ・強化）。

これはAAの最低限の基準とは別なので、「すべて44未満ならAA違反」と説明しないでください。

また、小さい要素をすべて大きくすると、画面の多くを操作部分が占めることがあります。

主な操作を押しやすくしつつ、関連する説明や選択肢が読める配置を検討します。

指が触れた瞬間に重要な操作を確定する設計も点検対象です。

WCAGは、ポインタ操作を取り消せることなどを通じて、意図しない操作を避ける考え方を示しています（参考：ポインタのキャンセル）。

サイズと間隔だけでなく、「間違えて触れた後に戻れるか」まで、点検シートに残します。

固定CTAとポップアップを点検する

固定CTAは、スクロールした先でも申込先を見つけやすくするための要素です。

その便利さと、他の操作を妨げていないかを別々に確認します。

本文を隠していないか見る

画面下の固定ボタンが料金の注記や入力欄を覆っていると、利用者は必要な情報を確認しにくくなります。

PCでは十分な余白があっても、スマホのキーボードが開いた状態では、使える高さが小さくなることがあります。

最初の画面だけでなく、ページ末尾・フォーム入力中・エラー表示時を確認してください。

画面上の固定ヘッダーと下のCTAが同時にある場合は、その間に何が見えているかを点検します。

押された回数が多いという理由だけで、固定CTAの面積を広げる判断はできません。

ボタンの後ろに隠れた説明や、同意のチェック欄へ到達できるかが重要です。

キーボード操作では、フォーカスが移った項目が固定要素の裏へ隠れないかも確かめます。

WCAG 2.2のAA基準2.4.11は、フォーカスを受けた要素が、制作者のコンテンツによって完全に隠れないことを求めています（参考：フォーカスが隠れない・最低限）。

この基準だけで本文全体の読みやすさまで保証されるわけではありません。

実務では、隠れた説明がないかという読みやすさの点検と、フォーカスの点検を両方行います。

修正候補には、固定部分の高さ調整、本文末尾の余白、入力中の表示条件などがあります。

どの方法が合うかは、ページの操作を妨げずに目的を達成できるかで決めてください。

閉じる操作を調べる

ポップアップを閉じようとした場所にタップが集まる場合は、閉じるボタンの範囲を確認します。

小さな「×」だけが反応し、周囲は反応しない設計なら、押しにくさがないかを実機で調べます。

閉じた直後に同じ表示が再び出る場合は、表示条件や状態の保存も確認対象です。

録画では「閉じる操作→本文へ戻る→再び表示される」という順序を残します。

画面を覆うモーダルは、見た目だけでなく、キーボードで閉じる操作やフォーカスの移動も必要です。

WAI-ARIAのモーダルダイアログのパターンでは、Escapeで閉じることや、見える閉じるボタンを含めることが説明されています（参考：モーダルダイアログの操作）。

スマホの画面上にキーボードのEscapeがなくても、見える閉じる操作は使える必要があります。

通知バナー・同意画面・チャットなどが重なった状態も、一度確認してください。

単独では問題がなくても、重なると閉じるボタンへ届かなくなることがあります。

録画に情報が伏せられている場合は、原因確認のためだけにマスキングを外さないようにします。

テスト環境に同じ表示条件を作り、架空の入力内容で操作を確かめる方法を優先します。

スマホのメニューから目的地まで追う

メニューが押されたことと、必要なページを見つけられたことは別です。

開いた後にどの項目へ進み、その先で何をしたかまで見ます。

メニューを開いた後を見る

メニューボタンの色が濃い場合、そこで分析を終えないでください。

Clarityではクリックした要素からView recordingsを選び、その要素が押された録画を確認できます（参考：要素から録画を見る）。

録画では、メニューが開いたか、どの項目を選んだか、移動先が表示されたかを順に確認します。

開いたメニューの中でタップが見つからない場合も、「何も選ばなかった」と直ちに判断しないようにします。

動的に開く要素と、ヒートマップの背景画像の状態が一致していない可能性があるためです。

Clarityの公式資料も、ページの表示画像にクリックされた要素が現れない場合があると説明しています（参考：クリックマップとページ表示）。

実ページでメニューを開いた状態と照合し、録画で選択先を確認してください。

架空のサービスサイトなら、「導入事例」を探す人が「サポート」を開いて戻る場面を記録できます。

その場合は、分類名から内容を想像しにくいという仮説を立てられます。

ただし、訪問者が本当に導入事例を探していたかは、録画だけでは分かりません。

目的が分からないときは、次の確認として短いユーザビリティテストを組み合わせます。

課題の作り方は、ユーザビリティテストとWeb録画の使い分けを参考にしてください。

途中で戻る操作を調べる

メニューから移動してすぐ戻る操作には、複数の理由が考えられます。

行き先が予想と違った場合もあれば、情報を確認して元のページへ戻った場合もあります。

「戻った回数が多いから失敗」とせず、戻った後に目的の操作へ進めたかを確認します。

架空の料金ページなら、プランの条件を別ページで確認し、料金表へ戻って申し込む流れは自然です。

一方で、同じ二つのページを往復した後にフォームへ進めない場合は、必要な説明が不足している可能性があります。

記録には、出発ページ・押した項目・移動先・戻った後の操作を残します。

ブラウザの戻る、サイト内の戻る、メニューの閉じるも区別してください。

これらを一つの「戻る」にまとめると、どこを直すべきか分からなくなります。

ページ遷移の全体傾向を確認するときは、GA4の経路探索も補助になります（参考：GA4の経路探索）。

ただし、その集計と、抽出した録画の件数は同じ母数とは限りません。

全体の経路で調べる範囲を決め、録画で具体的な操作を確認する役割分担にします。

スマホのヒートマップから修正する

見つけた候補は、一つずつ再現してから修正します。

「色が変わった」だけで終わらず、利用者が目的を果たせるかまで確認してください。

実機で変更案を試す

以下は、社内で使うためのスマホ操作の点検シートです。

各行に、確認した端末・ブラウザ・ページの版・結果を追記してください。

点検対象	実際に試す操作	残す結果
小さいリンク	文字と周辺の余白をそれぞれタップ	反応する範囲と誤った移動
隣り合うボタン	目的の操作を続けて実行	間違えて押した場所と戻り方
固定CTA	末尾までスクロールして入力	隠れた説明・入力欄・エラー
ポップアップ	開く・閉じる・元の操作へ戻る	閉じる範囲と再表示の有無
メニュー	目的のページを選んで到達	分類名・移動先・往復の内容
完了操作	テスト用の内容で最後まで進む	完了画面と計測イベント

点検は、縦向きだけでなく、対象サービスで想定する横向きや文字を大きくした状態でも行います。

入力フォームは、キーボードを閉じた状態と開いた状態の両方を確認してください。

ChromeのDevice Modeで幅を変えて候補を探し、その後に実機で確かめると効率的です。

ただし、エミュレーションで通った結果を、そのまま実機合格として記録しないようにします。

修正前に問題が再現しない場合は、「再現できなかった条件」を残します。

録画があるからといって、再現確認まで済んだことにはなりません。

また、操作不能や重大な情報の隠れなどが見つかった場合は、色の濃さより影響の大きさで優先順位を決めます。

ヒートマップで目立たない利用者の問題も、点検から漏らさないことが重要です。

成果までの操作を再確認する

修正後は、同じページ・端末・流入条件で記録を確認します。

押し直しが減ったかに加え、目的のページへの到達やフォームの完了も見てください。

CTAのタップ回数が減っていても、何度も押す必要がなくなった結果かもしれません。

反対に、タップ回数が増えても、その後の入力で止まっているなら、導線全体の改善とは言えません。

フォームでは、送信操作のイベントと、サーバー側で正常に受け付けた完了を区別します。

GA4の拡張計測ではform_startとform_submitを記録できますが、業務上の完了は別途定義して確認する必要があります（参考：GA4の拡張計測）。

修正前後で広告の配信先やページの内容も変わっている場合は、結果の違いを一つの修正の効果に決めつけないでください。

点検シートには、「操作の再確認」と「成果の比較」を別の欄で残すと整理しやすくなります。

判断する内容	確認の例
修正が反映されたか	押せる範囲、表示条件、重なりを実機で確認
操作が通るか	メニューから目的地、入力から完了まで実行
記録が取れるか	対象イベントとテスト記録を確認
成果が変わったか	同じ定義・対象条件の集計を比較

最初からサイト全体を点検する必要はありません。

まずはスマホで成果が低いページを一つ選び、固定CTAかメニューなど、調べる操作を一つ決めてください。

条件をそろえたヒートマップ、前後の録画、実機での点検をつなぐことで、具体的な修正案へ進めます。