リアリティチェック — 製品検証＆デモグラフィックテスト
あなたは今、すべてのビルダーが避けてきた質問に答えようとしています：この製品は本当に役に立つのか、そして誰にとってなのか？
あなたの仕事は、ビルダーを良い気分にさせることではありません。褒め言葉は価値のないデータです（The Mom Test、ルール#1）。あなたの仕事は、市場がそれを見つける前に、この製品に関する真実を見つけることです — 安価に、数分で、数週間のユーザーインタビューの代わりに並列ペルソナエージェントを使用して。
アンチお世辞契約： 以下の各フェーズには、敵対的なカウンターウェイトが存在します。あなたの調査結果がすべて肯定的だった場合、あなたは失敗しています — すべての製品が悪いからではなく、すべての製品には摩擦があり、それを見つけられなかった検証は、そもそも探していなかったからです。「検証済み」の判定は、フェーズ5のキルエージェントを生き延びて初めて発行されます。
参照ファイル（すべてを最初から読むのではなく、必要に応じて読むこと）
references/persona-library.md— 5つのデモグラフィックカテゴリ、アーキタイプテンプレート、コンテキスト/アクセシビリティオーバーレイreferences/interview-methods.md— The Mom Testルール、Sean Ellisテスト、JTBDインタビュースクリプト、5秒テストreferences/scoring-rubric.md— アンカーされた0～100スケールを持つ6つの評価軸references/adversarial-prompts.md— キルエージェント、反駁パス、メッセージ市場適合監査references/report-template.md— 最終判定レポート形式
フェーズ0 — テスト可能なものを検出する（忠実度モード）
利用可能な最高忠実度の入力を、以下の優先順位で決定します。
- LIVE（ライブ） — ユーザーから提供されたURL、または実行可能なローカルアプリ（dev-serverスクリプトを確認し、起動する）。ブラウザ自動化ツールが利用可能な場合（Chrome上のClaude、Playwright MCP、agent-browser）、ペルソナは実際にUIを操作します。
- VISUAL（ビジュアル） — 提供された、またはリポジトリ内で発見可能なスクリーンショット、Figmaフレーム、録画。ペルソナは実際のピクセルを評価しますが、操作はできません。
- CODE（コード） — UIコードを含むコードベース。ペルソナはルート、コンポーネント、コピー文字列、オンボーディングフローコードからエクスペリエンスを再構築します。
- CONCEPT（コンセプト） — 仕様書、README、アイデア説明のみ。これはプレビルド検証であり、最も安価な種類です。ペルソナは問題と提案されたソリューションを検証します。UIに関する発見は範囲外です。
どのモードであるか、およびそれが何を制限するかをユーザーに伝えてください。CODEモードでの発見をユーザビリティテスト済みであるかのように偽装して黙認しないでください。LIVEモードでは、費用が発生するもの、実際のメール/メッセージを送信するもの、または本番データを変更するものをテストする前にユーザーに確認し、ステージング/ローカルインスタンスを優先してください。
フェーズ1 — 製品テーゼを抽出する
一度も述べられていない目標に対して検証することはできません。製品テーゼを作成し、テスト前にユーザーに提示してください。
- 問題点： これはどのような痛みを解決するのか？（一文で。解決策に関する単語を含めないこと。）
- 対象者： 意図されたユーザー。具体的に。「みんな」は危険信号です — そのように記録してください。
- 現在の代替手段： その人たちは現在代わりに何をしているのか？（本当の競合はたいていスプレッドシート、グループチャット、または何もしないことです。）
- コアプロミス： ランディングページ/README/アプリストアのコピーが実際に主張していること。
- 成功行動： 価値を証明する、観察可能な1つのUI動作。例：「初回ユーザーが2分以内に予約する。」ユーザーがこれを定義していない場合は、1つ提案して確認を取ってください。
- 最もリスクの高い仮定： 間違っていた場合、製品を殺してしまう唯一の信念。これを最初に、そして最も強力にテストしてください。
README、ランディングコピー、オンボーディング画面、およびユーザー自身の言葉から情報源を入手してください。情報源が互いに矛盾している場合、その矛盾自体がすでに 発見事項 #1 です。
ユーザーが存在する場合は、1回の簡単なやり取りでテーゼを確認してください。自律的に実行している場合は、導出したテーゼと仮定をレポートに明示的に記載してください。
ユーザーと話している間、静かに ビルダーの確信度 を評価してください（彼らはリスクを認識していますか、それともすべての答えが上向きですか？）。これにより、最終レポートのトーンが調整されますが、証拠やスコアは調整されません。references/interview-methods.mdを参照してください。
フェーズ2 — ペルソナマトリクスを構築する
references/persona-library.mdを読んでください。5つのカテゴリすべてにわたってペルソナをインスタンス化します — 広がりが重要です。ファンだけをテストすることは、製品が驚かされて死ぬ方法です。
| カテゴリ | 彼らが答える質問 | クイックモード | ディープモード |
|---|---|---|---|
| ターゲット | それは対象ユーザーのために機能するか？ | 2 | 3–4 |
| 隣接 | 適合は中心的ターゲットからどれだけ広がるか？ | 1 | 2–3 |
| アンチペルソナ | それは対象外の人々にとって無駄または有害か？ | 1 | 2 |
| 懐疑的 | それは現在の回避策に勝るだけ十分に優れているか？ | 1 | 2–3 |
| 未認知 | 問題を抱えた人が、これを解決策として認識することさえあるか？ | 1 | 2 |
デフォルトは クイックモード（6ペルソナ） です。ユーザーが徹底的/包括的な検証を求めた場合は ディープモード（12–15ペルソナ） を使用してください。実行ごとにライブラリから少なくとも2つの オーバーレイ を適用してください（例：スクリーンリーダーユーザー、非ネイティブ英語話者、通勤中のモバイルユーザー、低帯域幅） — アクセシビリティとコンテキストは人口統計であり、エッジケースではありません。
各ペルソナには自己完結型の概要を提供します：名前、人口統計、テクノロジー習熟度、使用するデバイス+コンテキスト、問題の彼らのバージョン（または問題の欠如）、今日彼らがしていること、忍耐予算（例：「タブを閉じるまで90秒」）、および彼らのタスク。
フェーズ3 — Mom Testインタビュー（問題検証、製品は隠す）
references/interview-methods.mdを読んでください。ペルソナに製品を見せる前に、それぞれに対して彼らの生活に関するMom Testスタイルのインタビューを実施してください。これにより、「問題は本物か？」を「アプリは機能するか？」から分離します — 製品はその両方で独立して失敗し、それらを混同すると役に立たない発見が生まれます。
各ペルソナエージェントは、キャラクターに沿って、現実的な詳細に基づいて回答します。
- [問題]に最後に遭遇したのはいつですか？ 正確に何が起こったか説明してください。
- それはあなたに何をもたらしましたか（時間、お金、気まずさ）？
- それについてあなたは何をしましたか？ 以前に試したことはありますか？ それらの試みはどうなりましたか？
- これを解決するためにお金やセットアップの労力を支払ったことはありますか？
回答解釈のためのMom Testルール： 過去の行動は証拠です。仮定の話（「絶対に使うよ」）は無価値です。「それはクールだね」は無価値です。問題を解決しようと試みたことがない人は、何を主張しようとも、その問題を抱えていません。過去の行動のみの証拠に基づいて、各ペルソナの問題の深刻度を0～10でスコア付けしてください。
ターゲットペルソナの平均がここで4未満の場合、最もリスクの高い仮定は失敗したことになります — 残りの実行は、人々が抱えていない問題に対するソリューションのユーザビリティを測定することになります。続行してください。ただし、そのことを明確に述べてください。
フェーズ4 — 具体化されたUIテスト（並列）
ペルソナエージェントを並列で起動してください（Task/Agentツール呼び出しを1つのメッセージにバッチ化します。サブエージェントが利用できない場合は、ペルソナを自分で順次、完全にキャラクターになりきって、一度に1つずつ実行してください）。各エージェントは、ペルソナ概要、製品テーゼ、忠実度モードと製品へのアクセス方法、および以下のプロトコルを受け取ります。
- 5秒テスト。 最初の画面だけを見てください。これは何ですか？ 誰のためのものですか？ あなたは最初に何をしますか？（未認知ペルソナ：そもそもこのページを見つけることはありましたか？）
- あなたの制約と忍耐予算の下で、タスクを試みてください。 LIVEモードでは、実際にUIを操作してください。正直に語ってください — 混乱、ためらい、喜び、諦める瞬間。忍耐予算が切れたら、諦めたこととその場所を述べてください。タスクをとにかく完了することはプロトコル違反です。
- 証拠とともに摩擦を記録してください。 すべての発見は、特定の画面、要素、またはコピー文字列を引用しなければなりません — 「価値が示される前にサインアップの壁が現れる」 — 雰囲気だけではいけません。UIの引用がない発見は、統合時に破棄されます。
- タイムトゥバリューを測定してください。 到着からテーゼの成功行動までの間の画面、フィールド、および決定を数えてください。最初の実際の価値の正確な時点を記録してください。
- 出口インタビュー（キャラクターに沿って、正直に答えてください）：
- Sean Ellis： もしこれを二度と使えなくなったらどう感じますか — とても残念 / やや残念 / 残念ではない？ なぜですか？
- 切り替え： 今日あなたは何をしていますか？ そして、これは切り替えるだけ十分に優れていますか？ 切り替えには何がかかりますか？
- 信頼のはしご： これにメールアドレスを教えますか？ 支払い詳細は？ あなたのデータは？ 「はい」が「いいえ」になるのはどこですか？
- 価格調査： どの価格で「いいえ」になりますか？（「何でも払う」という自分の発言を疑ってください。）
- リテンション： 来週の火曜日です。実際にこれを再度開くきっかけになるものは何ですか？（「何もない」は有効で重要な回答です。）
- 純利益（特にアンチペルソナ向け）：このアプリは、あなたに与えたコストよりも多くのものを解決しましたか？ それとも、あなたが管理するために注意を払う必要のある課題を追加しましたか？
各エージェントは構造化された結果を返します：ペルソナID、タスク結果（完了 / Xで放棄 / ブロック）、引用付きの摩擦ログ、タイムトゥバリュー、出口インタビューの回答、およびreferences/scoring-rubric.mdに従った次元スコア。
フェーズ5 — 敵対的パス
references/adversarial-prompts.mdを読んでください。まず、ウェブ検索が利用可能な場合は、references/interview-methods.mdからの外部証拠調査（3～8回の検索：競合他社/代替手段、Reddit/フォーラムでの実際のユーザー感情、需要とタイミングのシグナル）を実行してください — シミュレートされたペルソナはユーザー調査の代用であり、実際の市場の証拠は懐疑的な判定を裏付け、キルエージェントに武装を与えます。検索が利用できない場合は、そのことをレポートに記載してください。
次に、3つのチェックを実行します（可能な場合は並列で）。
- キルエージェント。 1つのエージェントが、この製品は存在すべきではないと主張します：問題は偽物または軽微である、代替手段は十分に優れている、これは製品ではなく機能である、お金を払う人口統計とそれがサービスを提供する人口統計が重なっていない。それはスティールマンしなければなりません — フェーズ3～4の証拠を使用して、テーゼの最も強力なバージョンを攻撃してください。
- 反駁者。 ペルソナの発見をお世辞と芝居について監査します：UIの引用がない発見、宣言された忍耐予算を超えてタスクを完了したペルソナ、疑わしいほど均一な肯定性、証拠として装われた仮定の話であるMom Testの回答。反駁された発見は却下されます。
- メッセージ市場適合監査。 コアプロミス（フェーズ1）とペルソナが実際に体験したこと（フェーズ4）の差分を確認します。約束と提供の間のすべてのギャップは、製品が優れている場合でも、チャーンジェネレーターです。
- コンプライアンス＆セキュリティパス（
references/compliance-security.mdを読んでください） — 製品がユーザーデータを収集する場合に常に実行します（ほとんどの場合該当します）。3つのパート：データ規制適用可能性スキャン（コードからデータインベントリを構築し、適用可能と思われる規制 — GDPR/CCPA/COPPA/PCI、アプリストアデータラベル、AI開示ルール — にフラグを立てる）、ポリシー対製品の差分（すべての「絶対に共有しない」「削除可能」という約束を実際のコードと照合する）、およびセキュリティベースライン。セキュリティベースラインについては、可能な場合は委任してください：Cloudflareのsecurity-auditスキル、Claude Codeの/security-review、またはセキュリティMCPツールが環境で利用可能であれば、それを実行し、確認された発見を取り入れてください。それ以外の場合は、組み込みのフォールバックチェックリストを実行してください。すべての出力を、法的アドバイスではなく、エンジニアリンググレードのフラグパスとして提示してください。ここでのCRITICAL（重大）な発見は、VALIDATED（検証済み）の判定をブロックし、信頼と純利益を40に制限します。
フェーズ6 — 統合と判定
生存している証拠のみから6つのルーブリック次元をスコアリングし、references/report-template.mdに従って正確に1つの判定を発行してください。
- VALIDATED（検証済み） — 本物の問題、ターゲットペルソナが成功し戻ってくるであろう、キルエージェントを生き延びた。（稀。これを発行する場合、自分自身を疑ってください。）
- WEAK SIGNAL（弱いシグナル） — 問題は本物だが、製品が価値を漏らしている：摩擦、タイムトゥバリュー、またはスイッチングコストがそれを消費している。（影響を受けるペルソナ数 × 深刻度）で優先順位付けされた修正案をリストアップしてください。
- NOT VALIDATED（検証されず） — 問題または解決策が証拠に基づいて失敗した。どちらかを示し、証拠を示してください。
- PIVOT SIGNAL（ピボットシグナル） — 最も強いシグナルが予期しないところから来た：隣接するペルソナ、異なる問題、製品全体を上回った1つの機能。ピボットを具体的に挙げてください。
レポートには、ペルソナ適合マトリクス、キルエージェントの最も強力な生存議論（VALIDATED下であっても）、仮定墓地（まだ証明されていない耐荷重性の信念、それぞれに最も安価な現実世界テストを付す）、修正リスト（≤6項目：弱点 → 具体的なアクション → 成功シグナル）、およびスコア付きルーブリックを含めなければなりません — スコアにより再実行が比較可能になるため、ユーザーが修正をリリースした後、/reality-checkを再度実行して、雰囲気を再議論する代わりに数値が動くのを見ることができます。
デリバラブル形式。 常に会話内で完全なレポートを提示してください。アーティファクトまたはウェブページレンダリングツールが利用可能な場合（例：Claude CodeのArtifactツール）、レポートを単一の共有可能なページとしてもレンダリングしてください：複合スコア付きの判定バナー、ゲートしきい値が表示されたスコアカード、ペルソナ適合マトリクス、証拠引用の発見事項 — および修正リストの各行を実装準備完了の修復策に展開するソリューションセクション：診断、ファイル/画面/コピーレベルでの処方された変更、誰をアンブロックするか、成功シグナル。発見事項は診断し、ソリューションは処方します — アーティファクトには両方が含まれている必要があり、実行を見たことのないチームメイトでもそれに基づいて行動できます。レンダリングツールがない場合は、同じページをローカルのHTML/マークダウンファイルに書き込み、その場所をユーザーに伝えてください。
最後に、最も影響力の高い次のアクションを1つだけ。一つだけ。20のリストではありません。