この記事の後日談
自分が作っているプロジェクト管理アプリで起きた “本当に直すべき不具合” を見つけた話
前回の記事では、DSL を使ってプロダクト上のユーザー行動をどう捉えるか、という話を書きました。
今回はその続編として、自分が実際に開発・運用しているプロジェクト管理アプリ で得られた考察を書きます。
そして今回はもう一つ重要な前提があります。
DSLの生成、実行、結果の分析まで、すべてAIに任せています。
人間は「何を知りたいか」だけを伝えました。
前提：Pendo Aggregation API で Session Replay をデータとして取得できる
今回の分析が成立している前提として、もう一つ重要なポイントがあります。
Pendo は Aggregation API を通じて、
• Session Replay の一覧
• 各セッションの詳細情報
• frustration point（rage click / dead click / error）
• ページ遷移
• イベント発生時刻
• 対象 DOM の情報
といったデータを API 経由で取得できる ようになっています。
つまり、Session Replay は「動画を見るための機能」ではなく、機械処理可能な行動ログとしても扱える ということです。
「Session Replay を AI が読む」というのはどういう意味か
今回やったことは、
• AI が動画を直接見ている
わけではありません。
Pendo Aggregation API から取得した、
• セッション一覧
• frustration 発生回数
• 発生ページ
• 時系列イベント
• DOM 情報
といった 構造化データをAIに渡しています。
AIはそれを元に、
• どのセッションを見るべきか判断し
• どこで何が起きているかを整理し
• 再現性があるかを比較し
• 問題になっていそうな箇所を特定する
ということをしています。
前回の記事で説明したように、Aggregation APIの仕様はDSLとして定義されており、AIはそのDSLを理解したうえで必要なクエリを生成・実行しています。
問題：Session Replay は「人が見る」前提だとスケールしない
rage click や error のデータはどんどん溜まっていきます。
• rage click が大量に出る
• error もそこそこ出る
• セッション数も多い
自分で作っているアプリなので構造は分かっているつもりですが、
それでも全部の Session Replay を見るのは無理 です。
一方で、データ自体は揃っています。
• frustration の種別
• 発生回数
• ページ
• DOM情報
• ページ遷移
• 時系列
ここでやったのが、
人がDSLを書く
人が実行する
人が結果を見る
という流れを、全部やめました。
アプローチ：人は目的だけ渡す、あとはAIに任せる
何を人がやったか
やったのはこれだけです。
「rage click や dead click が多いセッションから、
本当に問題になっていそうな箇所を特定してほしい」
DSLの設計も、条件定義も、実行も、結果の整理もしていません。
何をAIがやったか
AIには次のことをすべて任せました。
• DSLの生成
• DSLの実行
• 結果データの解釈
• セッション間の比較
• 再現性の有無の判断
• 問題箇所の仮説立て
AIが自分で考えて、必要なDSLを書き、実行し、考察しています。
AIが導き出した結果
rage click が集中していた箇所
AI がまず見つけたのは、明確な偏りでした。
• 自作プロジェクト管理アプリの /projects ページ
• 期間フィルタの 「This Month」ボタン
• 同一セッション内で複数回の rage click
「エラーが多い」ではなく、
「同じ操作が、同じ場所で、何度も失敗している」 という点が重要です。
分析レポートの一部：
行動導線の自動整理
さらに AI は、Session Replay を時系列で並べて、ユーザー行動をこう整理しました。
1. Projects ページに来る
2. 「This Month」フィルタをクリック
3. 反応がない
4. 連続クリック（rage click）
5. 一度別ページに移動
6. 再度戻ってきて、同じ操作を繰り返す
人間が動画を眺めているだけだと、
「イラついてるな」くらいで終わりがちですが、
AIは 再訪・再挑戦している点 まで含めて「問題の強さ」を評価していました。
作っている本人が見落としていた原因
ここでコードを見返してみると、
• 特定条件下で click handler が登録されない
• disabled 状態だが見た目で分からない
• 初期描画と状態更新のタイミングズレ
といった、完全に自分の実装ミス が見つかりました。
rage clickは、実際の挙動がズレているサインだというのが、データからはっきり見えます。
今回のSession replay行動は恥ずかしながら自分の操作でした。自分作ったものにイライラしてRage click起こしていましたｗ
さらに：再現用 Playwright テストまでAIが作る
ついでに、
「この rage click を再現する Playwright のテストを書いて」
と投げてみたところ、
• 実際のページ遷移
• 問題の selector
• rage click を再現する連続 click
を含んだテストコードがそのまま出てきました。
DSL → 実行 → 分析 → テスト生成 まで、人間(わたし)は一行もコードを書いていません。
まとめ：AIは「UX分析エンジニア」として普通に使える
今回、自作プロダクトで実運用データを使ってみて思ったのは、
• Session Replay は「人が見る」ものではなくなりつつある
• 人は目的を伝えるだけでいい
• DSLの生成や分析はAIに任せた方が速くて冷静
ということでした。
特に個人開発や小規模プロダクトでは、
• 時間がない
• 思い込みが入りやすい
• UX改善が後回しになりがち
なので、AIに全部任せる前提の設計 はかなり相性がいいと感じています。
おまけ
AIが仕上げたファイルの一部を公開します。
めっちゃ精度高いので必見です。
https://daichi.box.com/s/x1tdv6mge2r7orcjqkdjy6mvpyxub19k