regulars

レギュラー

概要

それぞれがサイト上で達成すべき特定のタスクを持つ実際のユーザーを演じるサブエージェントのパネルを編成します。エージェントはブラウザー MCP ツールを使ってサイトを操作し、目標の達成を試み、何が機能しなかったか、何に不満を感じたか、成功したかどうかを報告します。基本となる考え方は タスクの完了 です。ユーザーは、やりたいことを実現できるでしょうか？

これは QA テストスイートでも、専門家による監査でもありません。 レギュラーエージェントは実際のユーザーのように行動します。ソースコードを調べたり、すべての要素を確認したり、テストマトリックスに従ったりはしません。実際の人がするように、目標の達成を試みます。

使用するタイミング

• リリース前：「サイトは実際にエンドツーエンドで動作しますか？」
• デプロイ後：「ユーザーフローを壊していませんか？」
• リファクタリング後：「ユーザーは重要な操作を引き続き行えますか？」
• 定期チェック：「重要な経路は引き続き機能していますか？」

ワークフロー

digraph regulars {
  rankdir=TB;
  "User requests smoke test" -> "Identify key user tasks for this site";
  "Identify key user tasks for this site" -> "Present task panel with personas";
  "Present task panel with personas" -> "Ask: add, remove, or adjust?";
  "Ask: add, remove, or adjust?" -> "Finalize panel";
  "Finalize panel" -> "Ensure dev server is running";
  "Ensure dev server is running" -> "Dispatch agents sequentially";
  "Dispatch agents sequentially" -> "After each: report pass/fail + key issue";
  "After each: report pass/fail + key issue" -> "All done?";
  "All done?" -> "After each: report pass/fail + key issue" [label="no"];
  "All done?" -> "Compile results scorecard" [label="yes"];
}

逐次的なディスパッチが必須です。 ブラウザー MCP ツールは単一のブラウザーインスタンスを共有します。

タスクパネルの設計

固定のデフォルトパネルを使う review-squad:experts や、固定の熟練度スペクトラムを使う review-squad:normies とは異なり、regulars のタスクは サイト固有 です。サイトで何ができるかに基づいて設計する必要があります。

ステップ 1： ユーザーに主要なユーザーフローを尋ねるか、サイトのナビゲーションやコンテンツを確認して特定します。

ステップ 2： 各フローについて、目標を持つペルソナを作成します。

要素	例
名前と性格	「Sarah。昼休みにスマートフォンでサイトを見る、忙しい親」
目標	「50 ドル未満の誕生日プレゼントを探してカートに追加する」
行動の傾向	「素早くスクロールし、検索があれば使い、価格順に並べ替える」

ステップ 3： 承認を得るため、パネルをユーザーに提示します。

サイトの種類別パネルの例

個人ブログ／ポートフォリオ：

#	ペルソナ	タスク
1	素早く目を通す採用担当者	この人の仕事内容と経験を確認する
2	ブログ読者	特定のトピックの記事を見つけて読む
3	昔からの友人	連絡先や連絡を取る方法を見つける
4	RSS 購読者	RSS フィードを見つけて購読する
5	ソーシャルメディアからの訪問者	共有されたブログ記事にアクセスし、そこからサイトを見て回る
6	同業の開発者	GitHub やプロジェクトを見つける

Eコマース：

#	ペルソナ	タスク
1	ギフトを探す買い物客	50 ドル未満の商品を見つけてカートに追加し、購入手続きを開始する
2	比較検討する買い物客	カテゴリーを見て、絞り込みや並べ替えを行い、2 つの商品を比較する
3	再訪問者	注文状況や返品ポリシーを確認する
4	ニュースレター購読希望者	登録フォームを見つけて送信する
5	スマートフォンで購入する人	スマートフォンサイズのビューポートで購入を完了する
6	クーポン利用者	購入手続きで割引コードを適用する

SaaS／製品サイト：

#	ペルソナ	タスク
1	導入検討者	製品を理解し、価格を確認する
2	無料トライアルの利用希望者	トライアルアカウントに登録する
3	サポートを探すユーザー	ドキュメントやヘルプを見つける
4	エンタープライズ顧客の購入担当者	エンタープライズ向け情報や営業への問い合わせ先を見つける
5	既存ユーザー	ログインしてアカウント設定を確認する
6	開発者	API ドキュメントや連携ガイドを見つける

エージェントプロンプトのテンプレート

You are [NAME], a [DESCRIPTION].
[1-2 sentences of personality and how you browse.]
You have come to this site to: [SPECIFIC GOAL].

Do NOT read any source code or project files. You are a real user.
Use the browser MCP tools to navigate the site at [URL].
[If mobile persona: First, set viewport to 375x812.]

YOUR TASK:
1. Navigate to [URL]. Take a screenshot.
2. Try to accomplish your goal: [GOAL].
3. Do what feels natural — click what looks right, search if you can,
   scroll where you'd scroll. Don't be methodical — be human.
4. Take a screenshot at each major step.
5. If something doesn't work (broken button, error page, dead end),
   try what a real person would try (back button, refresh, different path).
6. Test one unhappy path: [SPECIFIC EDGE CASE FOR THIS TASK].
7. When you've either completed your goal or given up, STOP.

Report as [NAME]:
- **Goal**: [restate the goal]
- **Result**: COMPLETED / PARTIALLY COMPLETED / FAILED
- **Steps Taken**: numbered list of what you did
- **Where It Broke**: exact moment something went wrong (if applicable)
- **Frustrations**: anything annoying even if it technically worked
- **Time to Complete**: rough estimate (fast / reasonable / painfully slow)
- **Would I Come Back?**: honest yes/no

重要な要素：

• コードを見ないための制約 — 「ソースコードを読まないでください。」レギュラーは開発者ではなく、ユーザーです。
• 具体的な目標 — 「サイトを見て回る」ではなく、「50 ドル未満のプレゼントを見つけてカートに追加する」。
• エージェントごとに 1 つの失敗ケース — 問題が起きたときにどうなるかをテストします（無効な入力、空のカート、操作途中での戻るボタンなど）。
• 人間らしい行動 — 「テストスクリプトに一手順ずつ従う」ではなく、「自然だと感じるやり方で行う」。
• 率直な評価 — 「また利用したいと思いますか？」と尋ね、率直な評価を促します。

ディスパッチのパターン

並列ではなく逐次的に実行します。 ブラウザー MCP は単一のブラウザーインスタンスを共有します。

各エージェントの実行後に、合否と主な問題点をユーザーに簡潔に報告します。

結果の統合

スコアカードにまとめます。

## Regulars Review: [Site Name]

### Scorecard

| # | Task | Persona | Result | Issues |
|---|------|---------|--------|--------|
| 1 | Find and read blog post | Blog reader | ✅ PASS | Minor: date format inconsistent |
| 2 | Subscribe to newsletter | Casual visitor | ❌ FAIL | Form returns 500 error |
| 3 | Find contact info | Old friend | ✅ PASS | |
| 4 | Browse photo gallery | Gallery visitor | ⚠️ PARTIAL | Lightbox doesn't close on mobile |
| 5 | Find RSS feed | RSS subscriber | ❌ FAIL | No visible RSS link anywhere |
| 6 | Navigate from shared link | Social visitor | ✅ PASS | |

### Result: 4/6 PASS, 1 PARTIAL, 1 FAIL

### Blockers (failed tasks)
| Task | What broke | Severity |
|------|-----------|----------|
| Newsletter signup | 500 error on form submit | CRITICAL |
| Find RSS feed | No RSS link discoverable | IMPORTANT |

### Friction (passed but painful)
| Task | What was frustrating |
|------|---------------------|
| Browse gallery | Lightbox close button too small on mobile |

### What Worked Well
- Blog reading flow is smooth end-to-end
- Contact info is easy to find
- Shared link landing experience is clean

レポートの後

1. スコアカードを提示します
2. 完全に失敗したタスクであるブロッカーを優先します
3. 今すぐブロッカーを解決するか、ユーザーに尋ねます
4. 摩擦が生じた項目はバックログに追加します

よくある間違い

• コードを読む — 常連ユーザーはコードベースを知りません。エージェントも知る必要はありません。
• 汎用的なタスク — 「サイトを閲覧する」は有効なタスクではありません。各エージェントには、明確な合否基準を備えた具体的な目標が必要です。
• 問題のないケースだけを試す — 実際のユーザーはエッジケースに遭遇します。各エージェントは、問題が発生するケースを1つテストする必要があります。
• QA テストスクリプト — 「#submit 要素をクリックして、レスポンスコード 200 を確認する」はテストスクリプトであり、常連ユーザーの行動ではありません。エージェントは人間のように振る舞う必要があります。
• 並列実行する — Browser MCP は共有リソースです。順番に実行してください。
• すべてのサイトで同じパネルを使う — タスクはこのサイトが提供する機能に合わせる必要があります。ブログに「チェックアウトフロー」のテスターは必要ありません。