仮説の構築と検証方法の整理

なぜこう書くのか

このプロンプトは5個のブロックでできています

ブロックを押すとその段落が見られます

文脈材料 · AIが知るべきこと

私は{{企画のアイデア}}を実際に開発するか判断する前に、まず何を確認すべきかを整理したいと考えています。利用者は{{対象顧客}}で、現在最も懸念している点は「{{確認事項}}」です。

材料 AIが知るべきこと ×1
やること 何をどう進めるか ×3
仕上がり どんな形で受け取るか ×1

仮説検証のプロンプトを一度に投げると、AIの結論はたいてい「アンケートを実施しましょう」になりがちです。何を聞くべきか、何人がどう答えれば開発を決断するのかといった肝心な基準が抜けてしまいます。検証すべき対象が文章として固定されないまま、手法から尋ねてしまうためです。

解説をもっと読む · 3段落

そのため、第2段落で今回の回答範囲を仮説までにとどめています。仮説と検証計画を分けて尋ねることがこのプロンプトの骨子です。一度に指示すると、AIは適当に立てた仮説の上にそれらしい実験を重ねてしまい、人間が途中で介入する余地がなくなります。まず仮説を確認して不要なものを除外した上で、以下の派生パターンに進むのが効果的です。

第3段落の3つのステップは順序が重要です。前提をすべて洗い出す前に重要なものを選ばせると、最初に思いついた2〜3個の中からしか選ばれません。特に②の「間違っていた場合に企画全体が破綻するもの」という基準が、確認の優先順位を決めてくれます。確認しやすいものから手をつけるのではなく、企画を覆しかねない急所から検証すべきです。

形式の「判断基準」列が、この表を実際の実験へとつなげます。数値がなければ、結果を見ても人によって解釈が分かれてしまいます。最後の段落でセルフチェックを求めているのは、仮説を書いているうちに最後の1〜2個が単なる希望的観測に戻ってしまうことが多いためです。サービス企画における仮説構築で最も多い失敗は、真偽を判定できない文章を仮説と呼んでしまうことです。

用語が分からなければAha AIで: chain-of-thought, self-consistency

悪い例との比較

悪い例にないもの: 課題 · 手順 · 形式 · 自己チェック

よくある悪い例

宿題の写真をアップしたら保護者に要約を送るアプリを作りたいんだけど、うまくいくかどうやって検証すればいい？

アンケート、インタビュー、LP（ランディングページ）テストが教科書通りに提示されます。どこにでもある一般的な手法ばかりで、そのアイデアにおける最大の致命傷が何かがわかりません。「講師が毎日写真をアップしてくれるか」が核心であるにもかかわらず、そこを狙った実験がなく、何人がどう答えればクリアなのかの基準もないため、結果が出ても次の意思決定ができません。

バリエーション

1

仮説を選んだ後に検証計画を作成する

仮説を選定した後に続けて使う第2ステップです。「撤退基準」もあわせて求めることで、結果を都合よく解釈してしまうのを防ぎます。

プロンプトを見る

先ほどの表から私が選んだ1つの仮説について、今週中に確認できる方法を3つ提案してください。それぞれ「何を行うか / 何日かかるか / 何人必要か / どのような結果が出れば仮説成立とするか / どのような結果が出れば撤退・見送りとするか」を明記してください。アプリを開発せずに確認できる手法を1つ以上含め、{{確認事項}}と直接関係のない手法は除外してください。

2

作成済みの仮説をレビュー・壁打ちする

自分で書いた仮説には、無意識に希望的観測が混ざりがちです。修正させる前にまず問題点を指摘させることで、どこに論理の穴があるかを把握できます。

プロンプトを見る

以下は私が作成した仮説です。新しい仮説は作らず、この仮説のチェックのみを行ってください。①観察によって成否（白黒）を判定できるか ②{{対象顧客}}の実際の行動に関する文章になっているか（自分の願望になっていないか） ③間違っていた場合、何が破綻するか。項目ごとに1行で回答し、最後にブラッシュアップした修正文を提示してください。

仮説：{{確認事項}}

モデル別の注意

表の出力とセルフチェックを同時に指示すると、チェックの経緯だけを出力して表を省略してしまうケースがあります。もし表が出力されなかった場合は、「最終的な表をもう一度出力してください」と追加で指示してください。