ヒートマップ分析をA/Bテストに使う方法｜仮説づくりと結果の読み分け

ヒートマップで、変更後のボタンがよく押されるようになった。

これだけで、A/BテストのB案を採用してよいのでしょうか。

申込みや購入を増やすテストなら、ボタンのクリックだけで結論を出すことはできません。

ヒートマップは改善の仮説を作るために使い、A/Bテストの勝敗は先に決めた成果指標と判定方法で確認します。

この記事では、仮説づくり、A案・B案の識別、配信中の点検、結果の読み方を順番に解説します。

Clarityの設定例も使いながら、最後に「A/Bテストの仮説・検証シート」を作れるようにまとめました。

操作の説明は2026年10月4日に確認した公式資料に基づき、本文の数値とテスト案は説明用の架空例です。

ヒートマップとA/Bテストの役割

ヒートマップとA/Bテストは、同じ改善作業の中で使えます。

ただし、それぞれが答える質問は異なります。

観察と効果検証を分ける

ヒートマップは、ページのどこが押され、どこまで到達されているかを調べる材料です。

一方、A/Bテストでは、対象者を決めた方法で振り分け、異なる案が成果に与える影響を比較します。

たとえば「送料の説明に到達する前に、購入ボタン付近から戻る操作がある」という観察が得られたとします。

ここから「送料の条件が近くにあれば判断しやすくなるのでは」という仮説を作ります。

そして、条件を追加した案と従来の案で、購入完了への影響を検証します。

段階	答えたい質問	主に見るもの
観察	どこで操作が止まるのか	ヒートマップと録画
仮説	何を変えると進みやすいか	操作と実ページの照合
検証	変更した案で成果が変わるか	A/Bテストの指標
解釈	操作にどんな変化があったか	案ごとのヒートマップ

変更前の1週間と変更後の1週間を比べるだけでは、流入や曜日、広告内容の違いも混ざります。

その比較を、同じ時期に対象者を振り分けたA/Bテストと同じものとして説明しないでください。

成功指標を先に決める

テストを始める前に、何が変わったら採用を検討するかを決めます。

申込みを増やしたいなら、主な指標は申込ボタンのクリックより、受付の完了に置く方が目的に合います。

ボタンを押した後に入力が難しくて止まれば、クリックが増えても成果にはつながりません。

また、成果を増やすために悪化させたくない項目も決めます。

たとえば、入力エラー、ページの表示速度、解約や問い合わせの増加などです。

Microsoftの実験設計資料でも、成果に関わる指標だけでなく、安全性やデータ品質を確認する指標を準備する考え方が示されています（参考：信頼できる実験の事前設計）。

ここで指標の分母も書いておきます。

「テストに割り付けられた対象ユーザーのうち、申込みが完了した人の割合」なのか、「セッションの割合」なのかを途中で変えないことが大切です。

ヒートマップからテスト仮説を作る

目立つ色を見つけたら、すぐにボタンを動かすのではなく、前後の操作を確かめます。

1つの観察から、複数の説明が成り立つこともあります。

根拠になる操作を集める

対象URL、期間、端末をそろえ、調べたい操作を確認します。

たとえば、料金表の近くにある、押せない説明文がクリックされていたとします。

その人が詳細を開こうとした可能性もあれば、文字を選択しようとしただけの可能性もあります。

録画を見て、直前と直後にどのような操作をしたかを記録します。

Clarityのクリックマップでは、要素を選択して関連する録画を確認できます（参考：Clarityのクリックマップ）。

実ページでも、説明文がリンクのような色や形になっていないか点検します。

記録する内容	架空の記入例
観察した操作	料金の注記を押した後、ページを上下に移動
実ページの状態	注記は青い文字だがリンクではない
考えられる理由	利用条件の詳細を開けると思った可能性
変更の候補	注記の近くに条件の説明を置く
確かめたい成果	条件を理解したうえでの申込完了

記録が1件あることと、サイト全体で頻発していることは別です。

観察した件数、対象条件、集計上の規模を残し、印象だけで優先順位を決めないようにします。

一つの変更に絞る

初めてのテストでは、1つの仮説に対応する変更へ絞ると結果を説明しやすくなります。

「条件の説明が足りない」という仮説なら、説明の追加を主な変更にします。

同時に価格、ボタンの文言、背景、フォーム項目まで変えると、どの変更が結果に関係したかを切り分けにくくなります。

ただし、複数の要素をまとめた案のテストが、常に間違いというわけではありません。

新しいページ全体を採用するかが目的なら、変更のまとまり全体として評価します。

その場合は「ボタンの色が効いた」といった、個別要素への説明をしないことが大切です。

仮説は、次の形で書くと具体的になります。

「誰が、何に困っている可能性があり、何を変えると、どの成果がどう変わると考えるか」です。

観察、変更内容、成果を1つのつながりで説明できなければ、配信前に案を見直してください。

A/Bテストの計測条件を整える

同じURLでA案とB案を表示する場合、URLだけでは区別できません。

配信する仕組みと、ヒートマップ側の識別方法を合わせます。

パターンを識別する

まず、テストの識別名と、各案の値を決めます。

例として、テスト名を「pricing_note」、従来案を「A」、説明を追加した案を「B」とします。

Clarityでは、カスタムタグにキーと値を渡して、録画やヒートマップを絞る方法があります（参考：Clarityのカスタムタグ）。

以下は、すでにClarityを正しく設置したページで、B案が表示されることを確認した処理から呼び出す例です。

window.clarity("set", "pricing_note_variant", "B");

A案が表示されたときは、同じキーに「A」を送ります。

このコードは、A案・B案を振り分ける機能ではありません。

既存のA/Bテストツールやサイト側で確定した配信結果を、Clarityへ伝えるためのものです。

Clarityの初期化と、必要な同意処理を通った経路に組み込み、未初期化の状態で直接実行しないようにしてください。

また、カスタムタグはセッションに付く情報で、同じキーに複数の値を送ることもできます。

同じセッションにAとBの両方を送ると分類が混ざるため、配信の固定方法と送信タイミングを確認します（参考：ClarityのクライアントAPI）。

設定後は、A案とB案をそれぞれテスト表示し、録画のイベント情報と実際の表示が一致するかを点検します。

管理画面ではFiltersのCustom tagsからキーと値を選び、対象URLも指定して絞ります。

このコード例を特定の契約アカウントへ組み込み、配信結果を測定した実績を示すものではありません。

流入と端末の偏りを見る

テストの配信比率と、実際に記録された対象人数を確認します。

予定どおりの人数になっていない場合は、成果の差より先に計測や配信を調べます。

ただし、半分ずつ配信する設定でも、短い期間に必ず完全な同数になるわけではありません。

偶然のばらつきで説明できない偏りを検出する仕組みとして、SRMという確認があります。

Microsoftは、予定した割付比率と実測人数の不一致を、実験結果の信頼性に関わる問題として扱っています（参考：A/Bテストの割付人数の偏り）。

偏りが見つかったら、片方だけタグが動かない、対象条件が違う、別のURLへの移動で記録が抜ける、といった点を確認します。

成果が出た人だけを後から選んで比較すると、変更の影響を受けた結果で対象者を選ぶことになります。

テスト開始前に決めた対象者の条件を、都合のよい集計になるように変えないでください。

ヒートマップで端末別の操作を見る場合も、テスト全体の成果判定と、原因を探すための追加分析を分けます。

テスト中のヒートマップを読む

配信中は、勝者を急いで選ぶことより、正しく比較できる状態を保つことを優先します。

明らかな不具合を放置する必要はありません。

途中経過で勝敗を決めない

テストには、必要なサンプル数を先に決める方法や、途中の観察を扱える統計手法などがあります。

利用するツールの方式を確認し、その方式に合った終了条件を決めます。

たとえばOptimizelyは、逐次的な判定を行うStats Engineを案内しており、従来型の固定サンプルの計算と区別しています（参考：Optimizelyの実験期間の考え方）。

そのため「A/Bテストは必ず何日」「何人を超えれば十分」と、すべてのサイトに同じ数字を当てはめないでください。

必要な量は、普段の成果率、見つけたい差の大きさ、対象人数、判定方式などによって変わります。

ヒートマップが早く赤くなった案を採用する、といった独自の終了条件も避けます。

開始前には、少なくとも次の内容を残します。

• 主な成果指標と、悪化させたくない指標
• 判定に使うツールと統計手法
• 期間やサンプル数に関する条件
• 不具合や大きな悪化が出たときの停止条件
• 判断できないまま期限を迎えたときの扱い

毎日確認する目的は、不具合や計測異常を見つけることであり、都合のよい瞬間を探すことではありません。

表示崩れを先に確認する

B案だけボタンが押せない場合、そのままテストを続けても、意図したデザインの比較にはなりません。

スマートフォンで追加した説明がボタンに重なるなど、画面幅によって問題が出る場合もあります。

配信前に、両方の案を主要な端末で確認します。

配信後も、録画に出た気になる操作を実ページで再現し、不具合かを確かめます。

点検する場所	確認すること
表示	A案・B案とも必要な文章とボタンが見えるか
操作	ボタン、入力、ページ移動が動くか
計測	配信案と識別タグが一致するか
成果	完了イベントが同じ条件で記録されるか
速度	片方だけ表示の遅延が起きていないか

ヒートマップのスクリーンショットにも、案ごとの見た目が反映されているか確認します。

異なる版の画面にクリックの分布を重ねて、押された場所を読み違えないようにしてください。

Clarityではスクリーンショットを切り替えられますが、それだけで配信案のデータが分離されるわけではありません（参考：ヒートマップの画面状態を変更する）。

不具合で止めた場合は、通常終了と分けて記録し、修正後の再開条件を決めます。

テスト結果とヒートマップを照合する

判定の条件を満たしたら、まずデータの品質と主な成果を確認します。

操作の違いは、その後で結果を考える材料として使います。

成果の差を先に確認する

次の表は、クリックと申込完了を分けるための架空例です。

各案の対象者は1,000人で、同じ人の複数回のクリックは1人として数えた設定です。

指標	A案	B案
対象ユーザー	1,000人	1,000人
ボタンを押した人	200人	260人
申込完了した人	40人	39人
対象者に対する申込完了率	4.0％	3.9％

B案のボタンは、人数としては多く押されています。

しかし、これだけで申込完了が増えたとは言えません。

また、40人と39人の違いだけを見て、B案が悪化させたと断定することもできません。

テストの判定方式で示される不確実性や効果の範囲、実務上必要な差を確認します。

指標の分母が変更の影響で動いていないかも重要です。

Microsoftの実験後の分析資料でも、率の分母の変化が解釈を難しくする点を取り上げています（参考：実験結果の信頼性を確認する）。

「押した人の中では申込みが多い」だけを根拠にせず、最初に決めた対象者全体への影響を確認してください。

操作変化を説明の補助に使う

成果を確認した後、A案とB案のヒートマップを並べます。

ClarityではCompareを開き、同じURLの両側に異なる条件を適用して比較できます（参考：Clarityのヒートマップ比較）。

同じ期間と端末を選び、各案のカスタムタグで分けてください。

ただし、記録対象や同意状況などにより、ヒートマップの対象とテスト全体の対象が一致しない場合があります。

人数が違う理由を確認し、ヒートマップで見えた人だけをテストの全員として扱わないようにします。

比較では、追加した説明の位置まで到達しているか、ボタンの周辺で往復する操作が変わったかなどを確認します。

結果を書くときは、次のように観察と解釈を分けます。

「B案では説明付近への到達とボタンのクリックが増えたが、主な成果指標では採用条件を満たさなかった」という形です。

「不安がなくなったから売れた」といった心理や因果の説明は、操作記録だけでは確定できません。

必要ならアンケートやユーザビリティテストを使い、別の方法で確かめます。

A/Bテスト後の次の案を決める

採用できなかった案にも、次の調査につながる情報があります。

都合のよい結果だけを残さず、仮説と判定の記録を保管します。

差が出ない場合も記録する

「有意な差が出なかった」と「同じ効果である」は、同じ意味ではありません。

十分な情報が集まっていない場合もあれば、実務上の判断を変えるほどの差が見つからない場合もあります。

なぜ判断を保留したのかを、必要なサンプルや効果の範囲と一緒に残します。

アクセスが少ないサイトでは、細かい色の違いを多数試すより、ユーザビリティテストや問い合わせの確認を先に進める判断もあります。

次のシートに記録すると、同じ仮説を根拠なく繰り返すことを減らせます。

項目	記入すること
対象	URL、読者、配信対象の条件
観察	ヒートマップや録画で確認した操作
仮説	課題の可能性と、変更が役立つ理由
変更	A案とB案の具体的な違い
計測	識別タグ、成果指標、分母
判定	終了条件、データ品質、結果の不確実性
次の行動	採用、見送り、追加調査、再テスト

判定できなかったテストは「成功」として集計せず、その状態のまま共有します。

仮説のどの部分を確かめられなかったかを書くと、次の案が具体的になります。

採用した版で再確認する

採用を決めたら、本番で意図した版が表示されることを確認します。

テスト用の設定を終えた後も、成果イベントや主要なリンクが動くかを点検してください。

実装担当者には、採用する内容と、残す識別情報、終了する配信設定をまとめて渡します。

テスト後に余分な処理だけ残ったり、計測タグが外れたりしないようにします。

全面反映後の数字がテスト期間と違っても、すぐにテストが間違っていたとは判断しません。

対象者の範囲、流入、季節要因、他の変更を確認し、必要なら新しい条件で検証します。

LPOの改善順序全体は、LPで先に見直す場所でも整理しています。

まずは1つの観察から仮説を作り、変更内容、成果指標、終了条件をシートに書いてみてください。

ヒートマップで「なぜ試すか」を明確にし、A/Bテストで「採用する根拠」を確認する流れを作りましょう。