セッションリプレイを全部見ない分析方法｜毎週見る録画の選び方

セッションリプレイを導入したものの、録画が増える一方で、改善案を出せていない。

一覧の上から再生していると、気になる動きは見つかっても、何を直すべきか決めにくくなります。

毎週の分析は、再生する本数ではなく「今週、何を判断するか」から始めます。

たとえば問い合わせフォームなら、確認画面へ進めない操作を調べる週と、入力前に戻る理由を調べる週では、選ぶ録画が変わります。

この記事ではMicrosoft Clarityの操作を例に、抽出条件の保存、観察の記録、修正担当への引き継ぎまでを説明します。

最後に残すのは、翌週も使える「週次の録画抽出・観察シート」です。

以下の運用例は架空の問い合わせサイトを使った提案であり、特定の本数や時間で改善効果が出ると実証したものではありません。

セッションリプレイを選ぶ前に問いを決める

録画一覧を開く前に、今週の調査対象を一行で書きます。

「スマホ利用者の動きを見る」より、「スマホで確認画面から入力画面に戻った後、送信できなくなる操作があるか」のほうが、必要な記録を選びやすくなります。

成果に近い工程を選ぶ

最初の対象には、購入、問い合わせ、初期設定など、完了しないと利用者が目的を達成できない工程を選びます。

候補が多い場合は、問い合わせ窓口に届いた不具合、集計で変化した工程、直近で変更した画面を並べます。

そのうえで、今週調べると次の判断につながるものを優先します。

背景の色や動きが気になるという理由だけでは、重要な手続きの停止より先に調べる根拠になりません。

調査を始める前に「何を知れば次の行動を選べるか」を整理する考え方は、GOV.UKのユーザー調査計画でも示されています（参考：調査の目的を決める）。

セッションリプレイでも、この問いを判断の軸として使います。

架空の法人向けサービスであれば、「資料請求を増やす」という目標を、そのまま録画の抽出条件にはできません。

まず「資料請求フォームを開いた人が、確認画面に進めているか」に分けます。

完了の定義も、送信ボタンのクリックではなく、受付処理が成功したことに置きます。

ボタンを押してもエラーで止まることがあるため、画面操作と業務上の成功を分けておくと調査がぶれません。

集計側のイベントが何を表しているか不明なら、先に計測担当へ確認します。

調査対象を一つに絞る

一回の調査では、ページ、利用者の条件、確認する工程を絞ります。

架空の例なら「公開中の資料請求フォーム」「スマホ」「確認画面から戻った後」の組み合わせです。

ここで料金ページのスクロールや、PCのメニュー操作まで同時に追い始めると、違う課題が混ざります。

別の気づきは捨てずに、次回候補の欄へ移します。

調査の開始時には、次の項目をメモしておくと、その場で判断対象を共有できます。

項目	架空の記入例
今週の問い	確認画面から戻ると送信に支障が出るか
対象	資料請求フォーム、スマホ、同じ公開版
判断したいこと	不具合として修正へ渡すか、追加調査にするか
今回は扱わないこと	広告文、料金ページ、PCのメニュー

「今回扱わないこと」を残すのは、問題を無視するためではありません。

別の課題へ移ったときに、元の問いが未解決のまま終わることを防ぐためです。

調査を始めてから対象を変える場合は、最初の問いを上書きせず、変更した理由と時点を記録します。

そうしておけば、翌週に見直した際も、どの条件について結論を出したかが分かります。

セッションリプレイを条件で抽出する

見る対象が決まったら、その条件を録画ツールで再現します。

毎週同じ名前の画面を見ていても、URLや期間の指定が違えば、別の集団を比べることになります。

URLと到達イベントをそろえる

ClarityではプロジェクトのRecordingsを開き、Filtersで期間、端末、ページ、イベントなどの条件を指定できます（参考：Clarityのフィルター）。

最初に期間と端末を合わせ、次に対象ページを指定します。

サイト内のどこからでもフォームに来た記録を見たい場合は、訪問したページの条件を使います。

入口ページの条件を使うと、そのフォームから訪問を開始した記録に対象が変わります。

この違いを意識せずにURLだけ合わせると、比較したい行動を取りこぼします。

続いて、確認画面への到達や、定義済みの受付成功イベントなど、調査に必要な条件を加えます。

ClarityのSmart eventsには自動検出と独自に設定するイベントがあるため、イベント名だけで業務上の成功と判断しないようにします（参考：Smart eventsの設定）。

想定した操作をテスト環境で行い、どのタイミングでイベントが残るかを先に確かめてください。

条件を適用したら、Save as segmentから新しいセグメントとして保存し、次週はSegmentsから呼び出せます（参考：セグメントの保存と適用）。

名前は「資料請求・スマホ・確認画面到達」のように、条件が分かる形にします。

保存したセグメントはプロジェクト内で共有されるため、個人用メモのつもりで既存条件を書き換えないようにします。

毎週使う際にも、適用された期間と条件を確認し、シートに調査日時を残します。

成功と失敗の両方を選ぶ

問題を探すときでも、気になる動きがある録画だけに偏らせません。

同じ画面と端末で、目的の操作を完了できた記録も見ます。

戻る操作が成功した記録にも現れるなら、戻ること自体が障害とは限らないためです。

実務では、確認する録画を「通常の動きを見るもの」「気になるシグナルから選ぶもの」「成功経路を確認するもの」に分けると整理できます。

これはこの記事で提案する調査用の分類であり、ツールが自動的に偏りのない標本を作るという意味ではありません。

一覧の並び順やおすすめ表示に任せた選び方も、無作為抽出とは区別します。

抽出の目的	選び方の例	言えること
通常の流れを知る	同じ条件から異なる曜日・時間帯を確認	よく調べるべき操作の候補
問題を探す	連打やエラーで絞る	シグナルの前後にある操作
完了経路を知る	受付成功が確認できた記録を選ぶ	成功時に成立している手順

「失敗」は、録画に完了が映らないという理由だけでは確定しません。

外部ページへの遷移、記録範囲、同意の状態などにより、手続きの後半が見えていない場合もあります。

その記録は「結果不明」として、確認済みの失敗と分けます。

分析シートには、各録画を選んだ理由と、除外した記録の理由も短く残してください。

後から観察件数を報告するときに、問題を探す目的で多めに選んだ記録を、全訪問の代表と誤解せずに済みます。

異常操作の録画を優先する

調査時間が限られるとき、連打やエラーなどのシグナルは、確認を始める場所として役立ちます。

ただし、シグナルが付いているだけで利用者の気持ちや原因までは分かりません。

連打や戻る操作を確認する

ClarityではRage clicks、Dead clicks、Quick backsなどを使って記録を絞れます（参考：行動を表すシグナルの定義）。

Rage clicksは狭い範囲への短時間の複数クリック、Dead clicksは期待される反応が見られないクリックを調べる手がかりです。

Quick backsは別ページへ進んでから短時間で前のページへ戻る動きであり、広告経由の離脱全体を表す指標ではありません。

架空のフォームで送信ボタンの連打が見つかったら、まず最初のクリックの前から再生します。

必須項目のエラーが出ていないか、処理中の表示があるか、次の画面へ遷移していないかを確認します。

「急いでいた」「怒っていた」と心理を決める代わりに、画面上で起きた操作を記録します。

待ち時間を調べるときは、再生中の無操作部分のスキップにも注意します。

ClarityのプレイヤーにはSkip inactivityやHighlightsがあるため、短く再生された長さを、そのまま利用者の待ち時間として扱えません（参考：録画プレイヤーの操作）。

問題の前後だけを素早く探した後、必要な区間を通常の流れで見直します。

静止している時間があっても、読んでいる、別の作業をしている、通信を待っているといった理由は、追加情報がなければ区別できません。

再現できる不具合を先に扱う

操作を阻む可能性がある記録を見つけたら、自分の検証環境で同じ手順を試します。

本番の顧客データを使わず、許可されたテストデータで、ページの公開版と端末条件をそろえます。

架空の例では「確認画面へ進む→戻る→項目を修正→送信」の順序を再現します。

初回の送信だけでは起きず、戻った後に限って止まるのであれば、その違いが修正担当にとって重要な情報です。

再現できた場合は、期待する動作、実際の動作、手順、発生した画面、確認日時を一組にします。

エラーの確認方法は、セッションリプレイからJavaScriptエラーを調べる手順でも詳しく説明しています。

重大な操作の停止が確認できたら、毎週の定例会まで待つ必要はありません。

担当者へ早めに渡し、復旧の判断を依頼します。

一方、再現しなかったものを「問題なし」で閉じるのも早計です。

ブラウザ、ログイン状態、入力順序、公開版の違いなどを未確認条件として残します。

再現性は証拠の強さを判断する材料ですが、影響の大きさとは別に扱ってください。

セッションリプレイの観察を揃える

録画を分担して見るなら、担当者ごとに違う形式の感想を残さないようにします。

同じ欄を使うことで、録画を全部見直さなくても、次の担当者が確認すべき点を追いやすくなります。

共通の記録欄を使う

観察メモは、事実、仮説、追加確認を分けます。

事実には「確認画面から戻り、項目を変更した後、送信ボタンを複数回押した」のように、映像で確認できることを書きます。

仮説には「戻る操作の後に、送信処理の状態が戻っていない可能性」を置きます。

追加確認には「同じ順序でテストし、エラーと受付処理を確認する」と書きます。

観察と解釈を分けて整理する進め方は、GOV.UKの調査分析ガイドでも案内されています（参考：観察から分析につなげる方法）。

以下は架空の観察シートです。

記録欄	架空の記入例
抽出条件	資料請求・スマホ・確認画面到達
選んだ理由	送信付近の連打を確認
見えた事実	戻る操作の後に送信を繰り返す
仮説	再送信時の処理に問題がある可能性
次の確認	テストデータで同じ順序を再現
状態・担当	要再現・開発担当

録画の識別子、問題が始まる時刻、画面の版も、権限を管理したシートに添えます。

氏名やメールアドレスなど、調査に不要な情報をメモへ転記しないでください。

ClarityではMore detailsのInfoからLabelsを付け、後からラベルで絞れます（参考：録画のラベル）。

ラベル名は「要再現」「確認済み」「次週確認」などの作業状態にすると、見る人によって意味が変わりにくくなります。

「困っている人」のように心理を含む名称は、観察事実と混ざるため避けます。

担当者ごとの解釈を比べる

分担を始める前に、同じ録画を見て、それぞれが独立して事実を書いてみます。

最初から一人の説明を聞いてしまうと、別の人も同じ解釈に引っ張られることがあります。

メモがそろったら、時刻、操作、画面の反応に分けて照合します。

一人が「送信できず離脱」と書き、別の人が「成功画面が記録されていない」と書いた場合、後者のほうが観察範囲を正確に表している可能性があります。

結論を多数決で決めるのではなく、確認できた範囲と不足する証拠をそろえます。

ClarityのAIによるセッション要約は、注目する場所を探す補助に使えます（参考：セッションのAI要約）。

ただし、要約の表現をそのまま確認済みの事実にしないようにします。

Microsoftも生成AIの回答には誤りがあり得ることを説明しているため、重要な判断は元の記録に戻って確かめます（参考：ClarityのResponsible AIに関する説明）。

自動要約と人の観察が食い違う場合は、どの時点の何を見て違ったかを残します。

判断の根拠を再生可能な位置へ戻せることが、毎週の分析を引き継ぐうえで重要です。

録画から出た課題を優先づける

観察が終わったら、見つけた動きの派手さではなく、利用者への影響と判断に必要な証拠を整理します。

「気になる録画があった」で終わらせず、修正、追加調査、保留のいずれかにつなげます。

影響人数と重要度を確認する

問題を探すために選んだ録画は、全体の発生割合を測る標本とは限りません。

たとえば架空の調査で、連打を条件に選んだ録画の多くに送信の繰り返しが映っていても、全利用者の多くが送信に困っているとは言えません。

影響の広さを知るには、対象画面の利用数、受付成功、エラー発生など、別の集計と照合します。

分母がセッション、利用者、申込件数のどれなのかも合わせます。

同じ人が複数回試した記録を、影響を受けた人数としてそのまま加算しないようにしてください。

また、発生が少なくても、購入できない、必要な情報へ進めないといった問題は重要です。

件数が多いけれど操作を妨げない現象と、件数は少なくても目的を達成できない現象を分けます。

判断軸	確認すること
影響する操作	購入・問い合わせなどの完了を阻むか
広がり	特定端末だけか、複数条件で起きるか
証拠	再現、受付結果、エラー記録を確認できたか
対応の見通し	修正範囲と副作用を説明できるか

この表は、機械的な点数で順位を決めるためのものではありません。

「なぜ今週これを扱うのか」を、担当者同士で説明するための確認欄です。

全体の数値と録画の役割を整理したい場合は、GA4とヒートマップを組み合わせる考え方も参考になります。

すぐ直す課題と調べる課題を分ける

再現できた入力エラーや、押しても目的の画面へ進めない不具合は、修正内容を具体化して担当者へ渡します。

一方、「説明が足りない気がする」という仮説には、別の証拠が必要です。

問い合わせ内容を確認する、利用者に操作してもらう、改善案を比較するなど、問いに合う調査を選びます。

録画を追加で見るだけでは、利用者が理解した言葉や、買わなかった事情が分からない場合もあります。

そのときは観察件数を増やすことを目的にせず、調査方法を変えます。

課題の管理には、「修正する」「追加確認する」「現時点では保留する」の状態と、理由を残します。

保留する場合も、「記録が少ない」だけでは次の行動が決まりません。

「同じ公開版でPCにも発生するかを確認してから決める」のように、何が分かれば判断が変わるかを書きます。

修正案が出た場合は、担当、対象画面、完了条件、確認日を付けます。

クライアントへ説明する資料にまとめる際は、Web録画を改善提案に変える報告書の作り方の形式を使えます。

セッションリプレイ分析の時間を管理する

毎週の分析を続けるには、見る時間だけでなく、判断と引き継ぎの時間も確保します。

録画を最後まで再生することが、必ずしも調査の完了ではありません。

調査を止める条件を決める

「毎週何本見れば十分か」に、すべてのサイトで使える固定の答えはありません。

一件の記録から再現可能な不具合が分かる場合もあれば、多くの記録を見ても、選択の理由は分からない場合もあります。

始める前に、今回の調査を終える条件を決めます。

架空のフォームの例なら、「問題の手順を再現して修正担当へ渡せた」「追加で必要な条件が特定できた」「録画だけでは分からないため別の調査へ切り替えた」のいずれかです。

同じ行動が繰り返し現れたときも、まだ見ていない曜日や端末、成功経路が残っていないかを確認します。

繰り返しを見たという感覚だけで、サイト全体を調べ尽くしたとは言わないようにします。

時間を区切る場合は、抽出、観察、判断、引き継ぎの各作業に枠を分けます。

観察に時間を使い切ったら、最後に一行でも「分かったこと」「分からないこと」「次に行うこと」を残します。

無操作のスキップやAI要約は閲覧を助けますが、根拠を確認する工程を省く理由にはしません。

録画の保存期間も考慮し、必要な記録を再確認できるうちに担当者へ渡します。

共有にはClarityのチーム向け共有などを使い、閲覧者に必要な範囲を選びます（参考：Clarityの共有方法）。

再生開始位置を指定したリンクであっても、その部分だけを切り出した動画とは限らない点に注意してください。

翌週の確認につなげる

次週は新しい録画から始める前に、前週の課題の状態を見ます。

修正が反映されたなら、同じ手順で操作できるかをテストし、その後の記録と集計を確認します。

不具合が消えたことと、問い合わせ件数が増えたことは、別の確認です。

広告の流入や営業日、ページの変更なども動いていれば、件数の差を修正だけの効果と断定できません。

週次シートは、次のように更新すると経緯を追いやすくなります。

欄	架空の引き継ぎ例
前週の問い	確認画面から戻った後に送信できるか
行ったこと	開発担当が戻る操作後の処理を修正
今週の確認	同じ操作と通常の送信の両方を再テスト
残る問い	別ブラウザでも同じ結果になるか
次の担当	検証担当が条件を追加して確認

同じ抽出条件を使い続けるだけでなく、特定の端末や時間帯だけを毎回見ていないかも振り返ります。

調べる対象を変える週は、変更理由を残し、前週と単純比較しないようにします。

今週の問いを決め、必要な録画を選び、次の担当が動ける記録を残すことが、週次分析の一巡です。

まずは一つの重要な操作を選び、このシートの「問い」と「抽出条件」を埋めるところから始めてください。