Web録画をクライアントへの改善提案に変える方法｜セッションリプレイ報告書の作り方

クライアントとの定例会でWeb録画を再生しても、「それで、どこを直せばよいですか」と聞かれてしまう。

セッションリプレイを改善提案に使うなら、録画を見せるだけでは足りません。

どの課題を調べ、何を確認し、次に何を変えるかまで整理する必要があります。

報告書は、録画の感想を並べる資料ではなく、クライアントが次の対応を選ぶための資料です。

GOV.UKの調査共有ガイドでも、調べたこと、分かったこと、次の行動を伝える構成が示されています（参考：調査結果を共有する考え方）。

この記事では、Web録画を使って、観察から修正案と検証方法までつなぐ報告書の作り方を紹介します。

説明には、架空の法人向けサービスサイトと、資料請求フォームの改善案を使います。

掲載する数値と操作例は説明用であり、AgentSignalや実在するクライアントの成果ではありません。

製品の共有仕様などは2026年10月5日時点の公式資料を確認しています。

Web録画の報告書で伝えること

最初に決めるのは、何本の録画を見せるかではありません。

今回の報告で、クライアントに何を判断してもらいたいかです。

顧客の課題を最初に置く

報告書の冒頭には、クライアントが困っていることを置きます。

「Web録画を分析しました」より、「資料請求の入力途中で止まる操作を調べました」の方が、調査の目的が伝わります。

ただし、録画を見る前から「入力項目が多いから離脱する」と原因を決めないようにしてください。

まずは「どの項目の前後で操作が止まるか」という確認可能な問いに変えます。

GOV.UKの調査計画では、根拠のない前提や意見を調査の問いに変えることが勧められています（参考：調査の目的を決める）。

架空の資料請求フォームなら、報告の冒頭は次のように整理できます。

項目	記入例
業務上の課題	資料請求の完了数を増やしたい
今回の対象	スマートフォンの資料請求フォーム
調べる問い	入力開始後、どの操作で進みにくくなるか
判断してほしいこと	修正候補を一つ選び、検証に進むか
今回の対象外	広告配信の変更、営業対応後の受注率

一回の報告で扱う範囲を決めておくと、関係のない録画を大量に見せずに済みます。

クライアントの担当者と開発担当者で、知りたいことが違う場合もあります。

冒頭は判断に必要な内容へ絞り、細かな再現手順は後ろに添えると読みやすくなります。

成果と観察を分ける

録画で確認した操作と、事業上の成果は別の情報です。

「同じ入力欄へ戻った」という観察だけで、「この欄が原因で売上が下がった」とは言えません。

報告書では、成果指標、観察した事実、改善の仮説を分けます。

種類	書く内容	架空の例
成果指標	実際に達成した行動	資料請求の完了
観察	記録で確認した操作	送信後に会社名欄へ戻った
仮説	操作が起きた理由の候補	入力条件が事前に伝わっていない可能性
検証	仮説を確かめる方法	入力条件を追加して再確認

GA4のフォーム計測にはform_startやform_submitがありますが、事業上の受付完了と同じものとして扱うかは実装の確認が必要です（参考：GA4の拡張計測イベント）。

ボタンを押した回数、送信処理を始めた回数、受付が成功した件数を混ぜないでください。

成果指標が正しく計測できていないなら、最初の提案を「完了を確認できる計測の整備」にする判断もあります。

見栄えのよい改善率を急いで作るより、何を成果として測るかをクライアントとそろえます。

提案に使うセッションリプレイを選ぶ

録画は、提案したい結論に合うものだけを選ぶと、偏った報告になります。

先に対象条件と確認する行動を決め、その条件に沿って見ます。

課題に合う場面を抽出する

資料請求フォームの課題なら、フォームに到達して入力を始めた記録が候補です。

トップページを数秒見ただけの記録を、フォームの使いにくさの根拠にはしません。

Clarityでは、期間、端末、ページ、行動などのフィルターを使って対象を絞れます（参考：Clarityのフィルター）。

完了しなかった記録だけでなく、同じ条件で完了した記録も確認します。

同じ欄へ戻る操作があっても、その後に問題なく完了しているかもしれません。

「戻った」という場面の前後を見て、繰り返し修正しているのか、単に確認したのかを区別します。

一つの特徴だけで利用者の気持ちを決めつけないことが重要です。

見せる場面は、問題が起きる直前、操作、直後の結果が分かる長さにします。

途中から再生すると、必要な条件を見落とす場合があります。

録画には、どの時刻に何を確認したかを短くメモしてください。

ClarityのAdd noteでは特定の場面へメモを付けられるため、後から同じ箇所を探しやすくなります（参考：録画へのメモと再生操作）。

対象条件を残す

録画のURLだけでなく、どう選んだかを残します。

同じ録画を別の担当者が見ても、選び方が分からなければ、報告の範囲を判断できません。

最低限、期間、ページ、端末、流入条件、ページの版、閲覧した本数を記録します。

対象全体から無作為に選んだのか、エラーのある記録に絞ったのかも明記してください。

次は、架空の調査条件を記入する例です。

項目	記入例
調査対象	資料請求フォームの入力開始後の操作
期間	対象版の公開後の一週間
端末	スマートフォン
流入	対象の広告から来た訪問
ページ版	入力項目を変更する前の版
抽出	対象条件に合う記録から、未完了と完了を分けて確認
閲覧数	各条件で見た本数を記入
除外	社内テスト、再生が崩れて判断できない記録

これは調査条件の見本であり、どの案件でも一週間で十分という意味ではありません。

必要な期間は、利用量や更新の頻度に合わせて決めます。

後から条件を変更した場合は、変更した理由も記録します。

結果に都合のよい条件へ変えていないか、自分でも確認できるようにしてください。

Web録画を共有できる状態にする

報告書を作る前に、誰へ何を見せられるかを確認します。

クライアントへの共有でも、別案件の情報や不要な個人情報が混ざっていてよいわけではありません。

個人情報と顧客情報を確認する

再生画面の入力欄だけでなく、確認画面、検索語、URL、注文内容、画面上の名前などを確認します。

メモや添付したスクリーンショットも対象です。

入力欄が隠れていても、次の確認画面に値が表示される場合があります。

Clarityのマスキング変更は新しい記録に反映されるため、設定を直しただけで過去の録画まで共有可能になると考えないでください（参考：マスキングの反映範囲）。

報告の目的が操作の説明なら、個人を特定する情報は必要ないことが多くあります。

原本を見せる必要があるかを検討し、必要な場面を情報のない図や文章で説明する方法も選びます。

GOV.UKの調査データ管理では、共有する成果物の識別情報を取り除き、必要な相手に閲覧を絞る考え方が示されています（参考：調査結果を共有するときの情報保護）。

この考え方を参考に、案件で合意した利用目的と共有範囲に合わせて準備してください。

匿名化した見本を作る場合は、顧客名を別の名前に置き換えるだけで十分かも確認します。

珍しい注文内容や細かな日時など、他の情報との組み合わせで分かる内容が残っていることがあります。

確認者を決め、共有用の資料と内部の調査記録を分けて保管します。

権限と有効範囲を確認する

共有リンクには、閲覧できる相手と期限の違いがあります。

Clarityではプロジェクトチーム向けと、リンクを知っている人向けの共有を選べます（参考：Clarityの共有設定）。

後者はリンクが転送されれば別の人にも見られるため、送信先だけで閲覧者を限定できるとは考えないでください。

外部向けのリンクでは、有効期間を設定することも確認します。

一方、リンクの期限と録画そのものの保存期間は別です。

リンクが有効でも、対象の記録が保持期間を過ぎれば同じように参照できるとは限りません。

Clarityの通常の録画保持と、お気に入りにした記録などの条件は公式資料で確認してください（参考：録画の保持条件）。

また、再生開始時刻を指定することは、他の場面を見られなくする編集とは異なります。

共有前には、リンク先で見られる記録全体を確認します。

複数のクライアントを担当している場合は、プロジェクト名、資料名、送信先の組み合わせも点検してください。

定例会が終わった後のリンク管理まで、担当者を決めておくと引き継ぎやすくなります。

観察から改善提案を組み立てる

録画から改善案へ進むときは、間に「なぜそう考えたか」を置きます。

ただし、理由の推測を観察した事実と混ぜないようにします。

事実と仮説を別に書く

GOV.UKの分析手順では、まず見聞きした内容を記録し、その後で意味を整理して行動を決めます（参考：観察から調査結果を整理する）。

Web録画でも、この順序でメモを分けると説明しやすくなります。

架空の資料請求フォームで、会社名を入力し直す場面があったとします。

次のように書けば、どこまでが確認できた内容かが伝わります。

区分	報告文の例
事実	送信操作の後、会社名欄の近くにエラーが表示された
事実	利用者は会社名欄へ戻り、再び送信した
仮説	入力条件を送信前に理解しにくい可能性がある
未確認	実際にどの説明が不足していたかは録画だけでは不明
追加確認	テスト入力でエラーの条件と説明を確認する

「利用者がイライラしている」といった気持ちは、操作だけから断定しません。

録画に音声や本人の発言がないなら、存在しない発言を引用の形にしないでください。

クライアントへは、「この操作があったので、この点を次に確認したい」と説明します。

仮説を弱く見せるための表現ではなく、何を確かめれば前に進めるかを明らかにする書き方です。

修正案と検証方法を添える

改善案には、どこをどう変えるかを書きます。

「フォームを使いやすくする」だけでは、作業内容も確認方法も決まりません。

架空の例なら、「会社名欄の前に入力条件を追加し、エラー時は対象欄と修正内容を文章で示す」と具体化します。

エラーを色だけで表さず、内容をテキストで示すことは、WCAGのエラー識別の説明にも沿う考え方です（参考：エラーを識別できる表示）。

実施前に、対象項目の仕様とアクセシビリティを開発担当へ確認してください。

提案書の一枚目は、次の構成でまとめられます。

欄	架空の記入例
提案の見出し	会社名の入力条件を送信前に伝える
対象	スマートフォンの資料請求フォーム
根拠	エラー表示後に同じ欄へ戻る操作を確認
仮説	入力条件を先に示すと、修正の手間を減らせる可能性
修正案	項目の近くに条件を追加し、エラー文を見直す
確認方法	テスト入力と、公開後の同条件の操作を確認
成果指標	入力開始から受付完了までの到達状況
確認する副作用	不正な値の受付、重複送信、問い合わせ増加
担当・予定	開発担当と公開予定日を記入

これは匿名化した改善提案書の構成見本であり、実際に改善が起きたという報告ではありません。

修正案を複数出す場合も、どの仮説を確かめる案なのかを一つずつ対応させます。

影響の大きい変更では、公開範囲や戻し方も事前に相談してください。

Web録画の報告に集計を添える

録画は、具体的な操作を説明するのに役立ちます。

どれほど広く起きているかを説明するには、集計の条件を別に確認します。

どれくらい起きたかを確認する

「確認した20本のうち6本で同じ欄へ戻った」という架空の結果があったとします。

この20本が未完了の記録を選んだものなら、「全利用者の30％が同じ問題を経験した」とは言えません。

報告できるのは、選んだ条件の20本で6本確認した、という範囲です。

録画の閲覧結果と、計測システム全体の集計を同じ列に入れないようにします。

情報	架空の値	何を表すか
集計	対象フォームへの訪問400セッション	対象期間・条件の訪問規模
集計	入力開始80セッション	入力を始めたセッション数
集計	受付完了20セッション	完了を確認できたセッション数
録画の観察	選んだ20本中6本で同じ欄へ戻った	閲覧した記録内での観察

この表の数値は、計算と報告の区別を説明するためのものです。

集計の前三行が同じ期間と条件で、入力開始したセッションのうち20セッションが完了したなら、完了は20÷80で25％です。

フォームへの訪問を分母にすれば20÷400で5％となり、答えている問いが変わります。

報告書には、率だけでなく分子と分母も書いてください。

同一セッション内での完了か、後日の再訪も含めるかといった定義もそろえます。

定義が異なるデータを足し合わせる前に、同じ行動を数えているかを確認します。

影響を確認できない場合を残す

録画から問題の候補が見つかっても、影響件数を集計できない場合があります。

該当する操作のイベントがなく、録画を見た範囲でしか確認できないこともあります。

その場合は、「影響範囲は未集計」と明記します。

未集計の箇所を空欄にすると、確認済みなのか、問題がなかったのか分かりません。

同じように、取得対象外のページ、同意条件、再生できない記録、社内アクセスの混入も記録します。

問題の候補を示すことと、事業への損失額を推計することは別です。

録画の数に平均単価を掛けただけで「これだけ売上を失った」と報告しないでください。

購入する意思があったか、別の訪問で完了したかなど、分からない条件が残るためです。

必要なら、影響を確認するためのイベント整備やユーザビリティテストを次の作業として提案します。

不足する情報を明らかにすることも、改善提案の一部です。

改善提案の実施後に報告する

提案を出しただけで、改善が完了したとは扱いません。

採用された内容と実際の変更を確認し、結果を同じ定義で追います。

採用案と見送った案を記録する

定例会では、提案ごとに実施、追加調査、見送りを決めます。

見送りも理由を残せば、同じ議論を繰り返さずに済みます。

予算がないのか、技術的な制約があるのか、根拠が足りないのかで、次の対応は違います。

案	判断	理由	次の対応
入力条件を近くに表示	実施	仕様を変えずに説明を補える	表示と入力テスト
入力項目を削除	追加調査	営業で使っている可能性がある	利用目的を確認
フォーム全体を変更	見送り	今回は原因を絞って確認したい	個別修正後に再検討

これも架空の判断例であり、項目削除や全面改修を常に避けるという意味ではありません。

実施する案には、担当者、公開予定日、確認日を付けます。

公開予定が変わったら、検証期間も見直してください。

変更していない期間を、変更後の集計として報告しないためです。

次回の報告書には、前回提案の判断と実施状況を短く載せます。

同じ条件で結果を確認する

修正後は、まず予定した変更が正しく表示されているかを確認します。

スマートフォンで説明が見切れたり、新しいエラー文が隠れたりしていないかを試してください。

その後、変更前と同じ対象ページ、端末、流入条件、成果定義で集計します。

広告の配信量、曜日構成、キャンペーン、在庫などが変わった場合は、比較条件の違いとして残します。

単純な前後比較で数字が変わっても、修正だけの効果と断定できるとは限りません。

因果関係を確かめたい場合は、適切な対象割り当てや判定方法を決めたA/Bテストなどを検討します。

録画は、狙った操作の変化が見られるかを確認する材料として使います。

会社名欄へ戻る操作が減ったかだけでなく、その後の受付完了まで進めているかも見てください。

良くならなかった場合は、仮説が違ったのか、修正が十分でなかったのか、計測条件が変わったのかを整理します。

報告の最後には、「続ける変更」「戻す変更」「次に調べること」を書きます。

Web録画を課題、事実、仮説、修正案、検証結果の順に整理すれば、クライアントが次の行動を選べる報告書になります。