単一ユーザーの dogfooding や PMF 前の段階で、North Star や主要指標を「蓄積量」（保存件数・登録数・週あたり生成数など）に置くと、その量は作り手自身の作業量に比例して必ず増えるため、価値仮説（誰かが本当に価値を得る／対価を払う）を一切反証できない。供給側（生成・蓄積・整形・公開面）を作り込むほど数字は伸びるが、それは需要の証拠ではない。

判断基準

• 指標が「作り手の努力に比例して単調増加する量」なら vanity 指標とみなし、価値仮説の合否判定には使わない。価値は需要側の行動変化で測る: 完成した出力を実在の第三者（想定顧客・採用担当・利用者）に見せ、行動（次の面談に進む・対価を払う・継続利用する等）が実際に変わるかを観測する。
• 価値仮説には事前に合否閾値を定義する。「機能が動く／生成される／表示される」を完了条件にしない。それは到達条件であって価値検証ではない。
• 供給側が完成していること自体を進捗と取り違えない。供給が揃った段階で先に要るのは新機能ではなく、既存の出力を需要側にぶつける最小反証実験。

なぜ

作り手は供給側を作り込むほど「進んでいる」感覚を得やすいが、蓄積量や機能到達は需要の不在を隠す。安価で反証力が高いのは、出力を作り込む前または直後に、実在の第三者の行動が変わるかを見ること。早期に反証できれば方向転換のコストが小さい。

適用条件・例外

• PMF 前・dogfooding・単一ユーザー段階で特に効く。利用が既にある段階ではエンゲージメントやリテンションの利用量指標が意味を持つので、量指標を一律に否定はしない。
• 量指標を運用ダッシュボードの health 指標として持つのは可。ただし「価値仮説の合否」を量で代理しないこと。

落とし穴・検証

• 落とし穴: roadmap が「対外メッセージ整備 → 出力強化 → ユーザー検証」のように需要検証を最後に置くと順序が転倒する。需要シグナルは作り込みの前に取る。
• 検証: 主要指標について「この数字は、誰も価値を得ていなくても増えるか？」を問う。Yes なら反証力ゼロ。需要側の行動変化を最低一つ観測する設計になっているかを確認する。