公開前に、4タイプの「初めての利用者」役のサブエージェントにLPから最初の成功まで通しで触らせ、詰まった場所をスクショ付きの表にする
せっかち・慎重派・スマホ・壊し屋の4人をブラウザで順番に歩かせ、迷った・止まった・閉じたくなった場所を「何人が引っかかったか」順に並べる。直したら、表を見ていない新しい4人でもう一度歩かせて比べる。
どんな問題を解決するか / いつ使うか
観点別のチェック(デザイン・モバイル・状態など)は画面単位の粗探しになりがちで、「初めて来た人がどこで離脱するか」という流れの問題は見落としやすい。LP→登録→最初に価値を感じる操作(最初の成功)までを、性格の違う利用者として通しで操作させると、ボタンが見つからない・横スクロールが出る・規約が分かりにくい・二重送信されるといった離脱ポイントが、再現できるスクショ付きで集まる。リリース直前のサービスやLP、オンボーディングの見直しに使う。
やり方
Claude Code(ブラウザ操作のMCP、例:Playwright MCP が使える状態)に、次の内容を頼む(要点を日本語にしたもの)。
text
公開前に、初めての利用者がどこで詰まるかを調べてほしい。
1. まずブラウザ操作のMCPが使えるか確認する。使えなければ止まって、Playwright MCPを入れるコマンドを教えて。
2. コードから「最初の成功」にあたる操作を特定し、レポートの一番上に書く。
3. 初めての利用者役のサブエージェントを4人、ブラウザを1人ずつ順番に使って送り込む。全員LPから最初の成功まで進む。
- せっかち:流し読みして最初のボタンを押し、最初のエラーでタブを閉じる
- 慎重派:登録前に料金・規約・プライバシーポリシーを読み、分かりにくい所で止まる
- スマホ:375pxの画面と遅い回線。隠れたボタンや横スクロールは「詰まり」扱い(回線を絞れなければそう書く)
- 壊し屋:フォームにでたらめな値を入れる、途中で戻る、ボタンを連打して二重送信されないか試す
4. 迷った・詰まった・閉じたくなった所は全部スクショを撮り qa/first-users/ に保存。どのステップか、何が見えたか、何をしようとしていたかを書く。
5. 最後に各自、また来たいか、成功まで何クリックかかったかを答える。
6. ローカルかプレビュー環境だけで実行し、登録はテスト用メール、決済はテストモード。
7. 同じページの同じ場所の問題は1件にまとめ、何人が引っかかったか順に並べる。
8. 料金・規約・プライバシーの問題は書き出すだけ(直さない)。それ以外は一度にまとめて直す。
9. 直したら、問題の一覧を見ていない新しいサブエージェント4人を同じ条件で通し、前後の比較を出して。注意点
- 再テストは「一覧を見ていない新しい」サブエージェントにさせるのが肝。直した本人や一覧を知っている役だと、問題を知っているので素通りしてしまう。
- 料金・規約・プライバシーは事業や法務の判断が絡むので、エージェントには直させず人が決める。
- 本番環境・本物のメール・本番決済は使わない。
- ブラウザを1人ずつ順番に使わせるのは、同時に操作して状態が混ざるのを防ぐため。
- 画面単位の監査と組み合わせると抜けが減る:リリース前のUI監査を、観点別の読み取り専用サブエージェントで並列実行する、公開前に、エージェントに「データが0件のとき」の画面を全部点検させ、空の状態を作らせる
- 同じ投稿者は、同じ形式(サブエージェントに分けて点検→一度に修正)で、セキュリティの攻撃テスト14項目(投稿)や表示速度の20項目(投稿)も公開している。
出典
- 投稿者: @Voxyz_ai
- 投稿: @Voxyz_ai · 2026-10-20
- 収集日: 2026-10-20(JST)