AI PdM ノート
Knowledge
▾
AIと開発の基礎
プロンプトと要件定義
検証と計測
組織と意思決定
大規模プロダクトのPdM
すべてのナレッジ
Case Studies
▾
準備中
Tools
▾
Claude Code 早見表
無料テンプレ集
KPIツリー・シミュレーター
About
Contact
ホーム
›
検証と計測
Category
検証と計測
作ったあとに「確かめる」技術。検証の経済学、最小の計測、AIの調査やコードに潜む落とし穴。
「動くものが、組織を動かす」——AIが変えた“検証の経済学”
AIエージェントが下げたのはツールの値段ではなく、仮説を検証するコストだ。1人のPdMが回せる「打席」が増えたとき、PdMの武器は何に変わるのか。
「最小の計測」を回す——作ったあと、何を見れば仮説は確かめられるか
動くものを出したら、次は確かめる番だ。ダッシュボードを作り込む前に、たった一つ「これが動けば仮説は正しい」と言える数字を、先に決める。
70%の罠——プロトタイプが本番で壊れる理由
バイブコーディングはアプリの70%を驚くほど速く作る。問題は残りの30%だ。プロトタイプと本番の境界を、PdMはどう見極めるか。
Deep Researchの落とし穴——AIの調査は、なぜ“もっともらしく”間違えるのか
3日かかった市場調査が30分で終わる。でもDeep Researchの最大の罠は、間違いが“もっともらしく見える”こと。AIリサーチを武器にする検証のコツ。
理解負債とは——コードを読まないPdMが「動くのに、分からない」を防ぐ方法
AIが書いたコードは動く。でも「なぜ動くのか」を誰も分かっていない——その差が積み上がるのが理解負債だ。技術的負債より、たちが悪い。
「A/Bテストで決めればいい」が大規模で通じなくなる理由——干渉・相関・代理指標
個人開発なら「測ってA/Bテスト」で足りる。だが大規模ではユーザー同士が干渉し、A/Bテストの大前提（SUTVA）が崩れる。相関と因果、代理指標の罠まで、計測が壊れる構造を一次情報で。
すべてのナレッジ →