replay-ux-research

Replay UX Research

sentry.io の実際の外部ユーザーによるセッションリプレイを分析し、指定されたプロダクト領域の UX パターン、課題、代表的なユーザージャーニーを明らかにします。Sentry の社内利用組織のデータを使用します。

Inputs

$ARGUMENTS は調査するプロダクト領域です（例：「issues」「traces」「dashboards」「replays」「monitors」「releases」「alerts」）。

$ARGUMENTS が空の場合は、どのプロダクト領域を調査するかユーザーに確認してください。

Prerequisites

このスキルを使用するには、Sentry MCP サーバーが接続されている必要があります。以下のツールを使用します。

• search_events — セッションリプレイを検索します
• get_replay_details — リプレイの詳細情報を取得します
• search_issues — エラーのイシューを検索します
• get_sentry_resource — URL からイシューの詳細情報を取得します

これらのツールを使用できない場合は、作業を進める前に Sentry MCP サーバーを接続するようユーザーに依頼してください。

Step 1: プロダクト領域を URL パターンに対応付ける

references/product-areas.md を読み、指定された領域の URL パターンを確認してください。

プロダクト領域が一覧にない場合は、領域名から URL パターンを推測してください。Sentry のプロダクト領域の多くは、URL パスで /<area-name>/ というパターンに従います。参照ファイルに新しいプロダクト領域が含まれていない可能性があるため、判断に迷う場合は推測が正しいかユーザーに確認してください。

Step 2: リプレイを検索する

外部（Sentry の従業員ではない）ユーザーのリプレイを検索してください。25 件を目安にし、プロダクト領域が複雑な場合、初期段階のパターンが曖昧な場合、またはユーザーがより包括的な分析を希望する場合は、さらに調査してください。

まず過去 24 時間を対象に検索し、目標件数に届かない場合は 48 時間または 7 日間に範囲を広げてください。必要に応じて search_events を複数回実行してください。呼び出しごとに limit: 50 を使用します。

リプレイが十分に見つからない場合（7 日間に広げても 10 件未満の場合）は、見つかった内容をユーザーに伝え、条件を調整できるよう協力を求めてください。より広い URL パターン、異なる期間、または関連するプロダクト領域を含める案を提示してもらえる可能性があります。

クエリの作成：

次のような自然言語クエリを使用してください。

replays from the last 24 hours where url contains "/<area-path>" excluding user emails ending in @sentry.io and @getsentry.com

主なフィルター：

• 期間：過去 24 時間（必要に応じて延長）
• URL パターン：Step 1 のプロダクト領域のパスに一致
• 従業員を除外：-user.email:*@sentry.io -user.email:*@getsentry.com
• 環境：prod

projectSlug フィルターは渡さないでください。リプレイは組織全体にまたがります。

Step 3: リプレイの詳細を取得する

Step 2 で見つかった各リプレイについて、get_replay_details を呼び出してください。処理を高速化するため、これらの呼び出しは並列バッチで実行します。

各リプレイについて、次の情報を記録してください。

• ユーザー：メールのドメインのみ（API はメールアドレス全体を返します。出力に含めないでください）
• ジャーニー：訪問したページを順に記録したリスト（URL とアクティビティのブレッドクラムから取得）
• 継続時間：セッションの合計時間
• リプレイの種類：session（通常のブラウジングからランダムにサンプリング）と buffer（エラー、手動フラッシュ、フィードバックの送信やチェックアウトの進行など、イベントや特定のユーザー操作によってトリガー）。buffer リプレイは一般的なブラウジングではなく、エラーや操作の発生時点に偏っているため、分析ではこの違いを明記してください。
• 流入コンテキスト：最初の URL から、どのようにアクセスしたかを判断します。クエリパラメーター内の referrer=slack、notification_uuid、alert_rule_id（Slack 通知）などのリファラー情報、メールリンクのパターン、またはパラメーターのない URL（ブックマーク／直接アクセス）を確認してください
• エンゲージメントのシグナル：エラー数、レイジクリック、デッドクリック、警告数
• ブラウザー／OS／デバイス：デバイスの分布を把握するため
• アクティビティのブレッドクラム：ページビュー、ナビゲーションのパターン、主な操作

Step 4: 重大なエラーを調査する

リプレイの詳細を収集したら、複数のリプレイで発生している、またはユーザー体験に影響する可能性が高いエラーを特定します。重大なエラーごとに、次の手順を行います。

1. 発生頻度でトリアージする：同じ issue ID（例：JAVASCRIPT-33RM）が3件以上のリプレイに表示される場合は、調査する価値があります。

2. Sentryでイシューを確認する：search_issues を使ってイシューを検索するか、リプレイの詳細に記載されたイシューURLを使って get_sentry_resource を呼び出します。次の点を確認します。

   • エラーの内容（メッセージ、スタックトレースのコンテキスト）
   • 影響を受けるユーザー数／イベント数の合計（このリプレイサンプル以外も含む）
   • 担当者が割り当てられているか、対応が進められているか

3. 行動シグナルからユーザーへの影響を推測する：リプレイのメタデータではページのレンダリング内容を確認できず、ブラウザーでリプレイを再生する必要があります。その代わりに、エラー発生後のユーザーの行動から影響を推測します。

   • 同じ操作を再試行した → エラーが表示され、再度試した可能性があります
   • すぐに別のページへ移動した → 操作を妨げられたか、諦めた可能性があります
   • 通常どおり操作を続けた → エラーは気付かれないもの、または見た目だけの問題かもしれません
   • その後、連打やデッドクリックが発生した → UIが応答しなくなった可能性があります
   • そのページに長時間とどまった → エラーメッセージを読んでいるか、戸惑っている可能性があります
   • 行動にまったく変化がなかった → エラーはユーザーから見えなかった可能性が高いです

4. この証拠に基づいて、各エラーを分類します。

   • 操作を妨げている可能性が高い：エラーの後、ユーザーが再試行した、離脱した、または操作を続けられなかったケースです。ユーザーへの影響の確度は高いです。
   • 体験を損ねている可能性が高い：エラーの後もユーザーは操作を続けたものの、通常とは異なる行動が見られたケースです。確度は中程度です。
   • 気付かれない可能性が高い：エラーが発生しても、ユーザーの行動に影響がなかったケースです。ユーザーへの影響の確度は低いです。
   • 不明：判断に十分な行動シグナルがないケースです。手動でリプレイを確認する必要があるものとして記録します。

   必ず確度を記載し、特定のリプレイを再生して確認するよう提案します。分類したエラーごとに、リプレイURLへの直接リンクを記載します。

この分類を「摩擦と問題点」セクションに含めます。気付かれない可能性が高いエラーは問題点として報告せず、網羅性を確保するため、「バックグラウンドエラー（気付かれない可能性が高い）」という別のサブセクションに記載します。

Step 5: パターンを分析する

以下のUXリサーチの観点からリプレイを確認します。

行動パターン

1. よくあるユーザージャーニー：ユーザーはどのような経路で移動していますか？一般的なフローはどのようなものですか？
2. 流入ポイント：ユーザーはどのようにしてページに到達していますか？アラート通知（Slack／メール）、直接ブックマーク、別のページからの自然な遷移に分類します。最初のURLのクエリパラメーターから判別できます。
3. タスクの完了：ユーザーは目標を達成したように見えますか、それともさまよったり、途中で諦めたりしていますか？完了の兆候：詳細ビューに移動してから離れる。中断の兆候：短いセッション、ページ間の往復、流入したページからそのまま離れる。
4. タスクにかかった時間：ユーザーは操作を行うまで、主要なページにどれくらい滞在していますか？

摩擦と機能の発見

1. 摩擦のシグナル：連打、デッドクリック、エラーに加え、同じページを何度も訪れる「ためらい」、ページ間をすばやく往復する「行き来」、同じ操作手順を繰り返す「再試行ループ」にも注目します。
2. 機能の発見：ユーザーはサブ機能（フィルター、検索、並べ替え、一括操作）を見つけて使っていますか、それともメインビューだけを使っていますか？URLのクエリパラメーターやパンくずリストから、機能の使用状況を確認します。
3. ユーザーの意図を示すシグナル：URLのクエリパラメーターから、ユーザーが指定した検索語、フィルター値、並べ替え順、期間を調べます。これらはユーザーの「発言」をそのまま確認するのに最も近い情報です。ユーザー自身の言葉で、何を探しているかが分かります。（例：query=is%3Aunresolved+assigned%3Ame は、ユーザーが自分に割り当てられたイシューをトリアージしていることを示します。）
4. 回避策：機能の不足や分かりにくいフローを示唆する、予想外の移動パターンはありますか？（例：作業の途中で設定に移動する、1つのビューで済む操作のために複数のページを順番に開く）
5. エラーからの復帰：エラーに遭遇したユーザーは、復帰して操作を続けていますか、それとも諦めていますか？

コンテキスト

1. 再生トリガーの内訳：session（ランダムサンプル）とbuffer（イベントトリガー）の割合はどのくらいですか？bufferの再生には、注目すべきこと（エラー、フィードバックの送信、チェックアウトなど）が起きた瞬間が映っており、摩擦の分析には役立ちますが、一般的な閲覧を代表するものではありません。結論を導く際は、この偏りを明記してください。
2. 再訪問者：複数の再生に同じメールドメインが登場しますか？再訪問者は習慣的に利用している可能性があり、その利用経路から、パワーユーザーのパターンや、回避する方法を身につけた継続的な問題がわかる場合があります。
3. ユーザーの多様性：再生は多くの異なる組織・企業からのものですか、それとも特定の組織・企業に集中していますか？組織によって行動に違いはありますか？
4. デバイス／ブラウザーの分布：ユーザーは主に何を使用していますか？
5. 離脱ポイント：ユーザーはどこで離脱したり、別のページへ移動したりしていますか？

ステップ 6：レポートを作成する

references/output-template.mdのテンプレートを使用してください。具体的に記述し、各パターンの根拠として個々の再生を挙げてください。読者が自分で再生を視聴できるよう、再生 URL へのリンクを記載してください。

プライバシー：レポートにユーザーのメールアドレスを完全な形で記載しないでください。「[company domain]のユーザー」や「ユーザー A、B、C」のような匿名の識別子を使用してください。