Fullstoryとは？セッションリプレイを開発・サポートで使うための確認点

「保存できない」という問い合わせを受けても、担当者の手元では同じ症状が出ない。

そんなときに確認したいのは、利用者が保存ボタンを押す前に何をして、画面に何が起きたかです。

Fullstoryは、Webサイトでの操作をセッションリプレイで振り返り、検索や技術情報と組み合わせて調べられるサービスです。

開発者向けの公式ガイドでも、対象のセッションを探し、操作の場面とエラー情報を確認する流れが案内されています（参考：開発者向けの利用ガイド）。

導入を判断するには、機能名の多さより、いま解決できていない問い合わせを調べられるかが重要です。

この記事では、サポートから開発へ調査を引き継ぐ場面を中心に、導入前の確認手順を整理します。

途中の問い合わせと確認シートは、手順を説明するための架空例です。

製品の仕様は2026年10月5日に公式資料で確認しており、顧客アカウントで実測した成果を紹介するものではありません。

Fullstoryで調べたい業務を決める

最初に、どの仕事で使うかを一つ決めます。

問い合わせ対応、障害調査、画面改善では、必要な情報も調査を終える条件も違います。

不具合対応と改善分析を分ける

不具合対応なら、「保存ボタンを押しても次へ進めない」という具体的な出来事が出発点です。

いつ、どの画面で、どの操作をしたときに起きたかを絞り込みます。

一方、改善分析では、「設定画面を訪れた人が、どこで設定を中断しているか」といった繰り返し起きる傾向を調べます。

一人の操作だけでは、その傾向が利用者全体に広がっているかは分かりません。

業務	最初の問い	調査を終える条件の例
サポート対応	問い合わせの直前に何が起きたか	状況と次の案内を説明できる
不具合調査	どの条件で期待した動作から外れるか	再現条件と修正対象を絞れる
改善分析	同じ場所で止まる操作が繰り返されているか	対象範囲と検証する仮説を決められる

この表のすべてを、最初の試用で達成する必要はありません。

たとえばサポート部門なら、最近調査に時間がかかった問い合わせの種類を選びます。

個人情報を除いた内容から、対象ページと確認したい操作を抜き出してください。

「録画を見られた」で終えず、「開発へ何を渡せるようにしたいか」まで決めると、試す範囲が具体的になります。

既存のエラー監視との役割を決める

すでにエラー監視やサーバーログを使っている場合は、足りない情報を書き出します。

例外の内容は分かるが、その前に選んでいた項目が分からないのかもしれません。

APIの失敗は分かるが、画面にエラーが表示されたか分からない場合もあります。

FullstoryのDev Toolsでは、リプレイに対応するConsoleやNetworkなどの技術情報を確認できます（参考：Dev Toolsの公式ガイド）。

ただし、ブラウザの操作記録だけでサーバー内部の処理をすべて説明できるわけではありません。

ブラウザ側の状況はFullstory、サーバー側の処理は既存ログ、というように照合する場所を決めます。

照合には、時刻、環境、ページ、許可された範囲のリクエスト識別子などを使います。

時刻の表記が日本時間かUTCかも、引き継ぎメモに残してください。

同じエラー名が出ただけで、別の利用者の操作を同一の障害として結び付けないことが大切です。

Fullstoryのセッションリプレイを確認する

セッションリプレイは、利用者の操作を後から確認するための再現画面です。

Fullstoryはページの構造や変更をもとに再構成するため、パソコン全体を撮影した動画と同じではありません（参考：複雑なサイトへの対応）。

操作と技術情報の対応を見る

まず、確認したい条件で検索し、Session Playlistから対象のリプレイを開きます。

画面の動きだけを最初から眺めるより、イベント一覧から問題の操作付近へ移動すると確認しやすくなります（参考：セッションリプレイの基本操作）。

試用では、自社で用意したテスト用の操作を一つ決めてください。

たとえば、設定画面を開き、項目を変更し、保存して完了表示を見る流れです。

再生画面で、変更前、保存のクリック、応答後の表示を順番に確認します。

そのうえでDev Toolsを開き、同じ場面のConsoleやNetworkに対応する記録があるかを調べます。

Consoleの取得設定は、SettingsのData Capture and PrivacyからData Captureを開き、Console Data Captureで確認できます（参考：Consoleの利用方法）。

ブラウザで見える情報が、すべて同じようにFullstoryへ保存されると考えないようにしてください。

Networkのリクエスト本文や応答本文を取得するには、設定や許可リストが関係します（参考：Network Allowlistingの設定）。

最初から本文を広く収集せず、URL、時刻、応答の状態など、調査に必要な範囲から確認します。

認証情報や顧客の入力値が必要かどうかは、画面上のマスキングとは別に検討してください。

再現できる画面を試す

トップページがきれいに再生できても、問い合わせの多い画面を再現できるとは限りません。

自社で使っている画面の作り方に合わせて試します。

試す画面	確認すること	判定の残し方
入力フォーム	エラー表示と入力位置を追えるか	値を隠したまま操作を判断できるか
モーダル	開閉と背面の状態が再現されるか	対象のボタンと閉じる操作を確認
画面遷移の少ないアプリ	URL変更と表示内容が対応するか	遷移前後の画面を記録
図やグラフを描く画面	描画方式が対応範囲に入るか	再現できない要素を別記
外部サービスの埋め込み	自社で取得できる範囲か	見えない範囲を明示

Fullstoryの対応資料では、Canvasには条件があり、WebGLなどにも制限が示されています（参考：描画方式ごとの対応）。

また、ソースを管理できない外部サービスのiframeは、内部まで自由に記録できるものではありません（参考：iframeの取得範囲）。

決済サービスの埋め込みなど、意図的に取得しない領域もあります。

表示できない部分を、直ちにタグの不具合と判断しないようにします。

自社のテスト環境で確認した日、端末、ブラウザ、ページの版を残すと、改修後にも比較できます。

Fullstoryの検索・分析要件を整理する

録画が存在していても、問い合わせに対応する記録を見つけられなければ実務では使いにくくなります。

担当者が普段受け取る情報で、対象を絞れるか試します。

対象のセッションを探せるか確認する

問い合わせフォームに、利用日時、対象画面、端末などの情報があるかを確認します。

検索では、まず期間とページを絞り、その後に端末やブラウザなどの条件を加えます。

条件を一度に増やしすぎると、時刻のずれや入力違いで対象を見失う場合があります。

候補がなければ、一つずつ条件を戻してください。

FullstoryのOmniSearchには、訪問ページ、操作、ブラウザなどの条件が用意されています（参考：検索できるユーザー・イベント条件）。

会員IDで検索したい場合は、Identify APIなどでその識別情報を渡す実装が必要です。

タグを置いただけで、自社の会員IDとすべての記録が自動で結び付くとは考えないでください。

識別子を送る場合も、メールアドレスなどを無条件に追加せず、社内で許可した最小限の項目を選びます。

ユーザー属性には最新の値を使うものがあるため、問い合わせ時点の状態を調べる際は、イベント時点の情報と区別します。

候補のリプレイを開いたら、画面と操作が問い合わせ内容に一致するかを確認します。

検索条件が一致したことと、本人の該当操作を特定できたことは別です。

集計で影響範囲を確認する

一つのリプレイで問題が見つかったら、次に同じ条件で起きている範囲を調べます。

同じエラーが何回起きたかと、何人に影響したかを分けて見てください。

一人が繰り返し操作すると、発生回数だけが大きくなることがあります。

Fullstoryでは、記録されたエラーから関連する集計を開き、発生状況を確認する方法が案内されています（参考：顧客が経験したエラーの調べ方）。

集計する期間は、問題が起きた版の公開後など、調べたい条件に合わせます。

改修前と改修後が混ざると、現在も続いている問題か判断しにくくなります。

ブラウザや端末で偏りがあるかも確認します。

ただし、Fullstoryで取得できたデータの範囲と、サイト全体の利用状況は一致するとは限りません。

記録を停止した期間、取得対象外の画面、月間上限への到達などがあれば、調査メモに加えます。

影響が大きいと判断するときは、集計の母数と対象条件まで説明できる状態にしてください。

Fullstoryの情報保護を確認する

情報保護は、公開後に録画を見てから考えるのでは間に合わない場合があります。

記録前の設定と、記録を誰に見せるかの両方を準備します。

マスキングの設定を点検する

管理者はSettingsからData Capture and Privacy、Privacyを開き、現在のモードとルールを確認します。

公式資料では、要素、URL、ネットワークなどの設定が分かれており、ルールは利用者側の端末で送信前に適用されると説明されています（参考：Privacy設定の全体像）。

入力欄だけでなく、入力後の確認画面も点検してください。

氏名や住所が入力欄から通常の文章に変わって表示される場合があるためです。

テストでは実在の顧客情報を使わず、識別できるダミー値を用意します。

その値が、フォーム、確認画面、完了画面、エラー表示でどう扱われるかを確認します。

Private by Defaultでは、マスクと除外の扱いが異なります。

マスクは文字を隠しながら操作を残せますが、除外した要素ではクリックなども取得されなくなるため、目的に応じて選びます（参考：Private by Defaultと要素の扱い）。

「クリックが見えない」という理由だけで、機密領域の除外を解除しないでください。

必要な操作を別の安全なイベントで確認する方法も検討します。

画面の文字を隠せたら、NetworkやConsoleなど別の取得経路にも同じ値が入っていないかを確認します。

マスキング済みの画面だけを見て、すべての記録が確認済みとしないことが重要です。

アクセス権を分ける

導入確認シートには、設定を変更する人、録画を見る人、外部共有を判断する人を分けて書きます。

サポート担当者が問い合わせを調べるために、全員へ管理者権限を配る必要があるかは検討してください。

契約と画面で利用できるロールを確認し、実際の担当者と同じ権限で試します。

外部の関係者へ共有する場合は、Guestの仕様も確認が必要です。

Guestは共有されたセッションを見られ、イベント一覧やDev Toolsにもアクセスできます（参考：Guestとのセッション共有）。

「再生画面だけを見せるつもりだった」という認識のずれを防いでください。

Guestを許可するメールドメインの範囲も確認します。

許可ドメインが残っていれば、Guestを一覧から削除しても、別の共有リンクから再び閲覧できる場合があります。

担当者の異動や契約終了時には、ユーザー一覧と共有設定の両方を見直します。

共有リンクを発行する人と、発行前に内容を確認する人を決めると、運用が曖昧になりません。

Fullstoryで調査を引き継ぐ

開発者へリプレイのURLだけを送ると、相手が同じ調査を最初からやり直すことになります。

確認した事実と、まだ分かっていない点を短く添えます。

再現手順を短くまとめる

次は、架空の設定画面で保存が完了しない場合の引き継ぎ例です。

項目	記入例
対象	テスト環境の通知設定画面
条件	対象の版、ブラウザ、端末、確認時刻を記入
操作	設定を変更し、保存ボタンを押した
期待した動作	完了表示が出て、変更後の設定が残る
実際の動作	保存中の表示が続き、完了表示が出ない
記録で確認した事実	ボタン操作後の応答とConsoleの状態を記入
未確認	サーバー側で更新が完了したか
次の担当	開発担当が同時刻のサーバーログと照合

再現手順には、実際に観察した操作だけを書きます。

「通信エラーが原因」と断定する前に、応答の状態と画面上の結果を分けて残してください。

一つのエラーが見えていても、それが利用者を止めた直接の原因とは限りません。

FullstoryのNote and Shareでは、セッションの特定の場面にメモを付けて共有できます（参考：メモとセッションリンクの共有方法）。

時刻付きのリンクには、「この直後に保存が進まなくなる」といった観察内容を添えます。

長い録画を丸ごと見る負担を減らしながら、相手が前後の操作も確認できるようにしてください。

修正後は、同じ手順を再実行し、完了表示と実際の保存結果の両方を確かめます。

顧客への説明と内部記録を分ける

社内の調査メモには、技術情報、仮説、調査中の不明点が含まれます。

それをそのまま顧客へ転送すると、不要な情報や未確定の説明まで伝わることがあります。

顧客向けには、確認できた状況、現時点の回避方法、次に連絡する内容を整理します。

たとえば架空の案内なら、「保存完了の表示が出ない状態を確認しており、反映状況を調査しています」と、確認できた範囲を伝えます。

顧客側で再操作が必要かどうかは、二重登録などの可能性も確認してから案内してください。

共有メモは個人的な下書きとは限りません。

公式のメモ機能では組織内の他の利用者も内容を参照できるため、不要な個人情報や推測を書き込まない運用にします（参考：共有メモの扱い）。

また、特定時刻へのリンクは、その場面だけを切り出して他の部分を隠す機能とは別です。

顧客へ原本を共有する必要がない場合は、承認された説明文や、情報を除いた手順で伝えます。

社内で使うリンクについても、保存期間が過ぎた後に何を記録として残すかを決めてください。

Fullstoryの試用を評価する

試用の評価は、録画本数ではなく、予定していた調査を進められたかで行います。

試す前に確認項目を決めると、導入後の担当や費用も検討しやすくなります。

解決できた調査を記録する

次の確認シートを、開発とサポートで一緒に埋めてください。

これは製品の採点表ではなく、自社の業務で不足している条件を見つけるためのひな型です。

確認項目	試すこと	結果・残った課題
対象業務	問い合わせの種類を一つ選ぶ	何を説明できれば完了か
検索	日時と画面から対象記録を探す	足りない識別条件は何か
再現	問題が起きる画面を再生する	見えない部品は何か
技術情報	操作とエラー・通信を対応させる	別のログが必要な箇所はどこか
情報保護	ダミー値で画面と記録を点検する	隠す設定を追加する場所はどこか
権限・共有	担当者と同じ権限で利用する	誰に何が見えるか
引き継ぎ	開発担当へ再現手順を渡す	相手が追加で聞いたことは何か
保持・費用	必要な量と調査期間を照合する	契約で確認する条件は何か

調査にかかった時間を測る場合は、開始点と終了点を決めます。

問い合わせの受領から一次回答までなのか、開発者が再現条件を理解するまでなのかで意味が変わります。

難易度の違う問い合わせを並べて、ツールだけで短縮できたと結論づけないようにします。

見つけられなかった記録や、再現できなかった部品も評価対象です。

追加の実装や運用で補えるか、別の方法が必要かを担当者と決めます。

料金と保持条件を確認する

2026年10月5日時点のFullstoryFreeは、月間3万セッション、10ユーザー枠、リプレイと分析データの各1年間の保持が案内されています（参考：FullstoryFreeの現在の条件）。

無料登録には業務用のメールドメインが必要で、利用できない機能もあります。

無料版のデータ利用条件には、匿名化した非個人情報の研究開発やAI学習などへの利用が記載されているため、社内方針と照合してください。

有料プランは公式料金ページでBusiness、Advanced、Enterpriseが案内されており、見積もり対象と必要な機能を確認します（参考：Fullstoryのプラン）。

セッション数だけでなく、担当者の人数、必要な機能、保存期間を合わせて比較します。

保持条件は、SettingsのAccount ManagementからSubscriptionで確認できます（参考：データの保存期間）。

集計用のデータが残っていても、リプレイやConsole、Networkを同じ期間まで見られるとは限らないため、両方を分けて確認します。

上限到達時の取得停止も、問い合わせ対応には影響します（参考：セッション上限に達した場合）。

まずは一つの問い合わせの種類で、検索、再現、引き継ぎまでを試してください。

その結果を確認シートに残せば、Fullstoryをどの部署で、どの範囲まで使うかを具体的に判断できます。