仮説検証とは、まだ確かめていない「こうなるはず」を、事前に決めた基準で判定する進め方です。判定の結果を見て、次の一手を決めます。
要は、外れたら外れたと分かる形で仮説を書き、合格ラインを試す前に決めておくことです。
株式会社01STARTで、生成AI研修と新規事業の支援をしている芝先です。
グロービス経営大学院編著『27歳からのMBA グロービス流ビジネス基礎力【改訂版】』(東洋経済新報社)で「AIを活用する力」の章を書きました。登壇した生成AI活用セミナーの累計参加者は1万人以上です。
この記事は、会議で「仮説検証を回して」と言われ、何から手をつけるか迷っている方に向けて書きました。PDCAとの違い、明日から使える手順と具体例、生成AIとの付き合い方までを扱います。英語資料の日本語訳は当社によるものです。
仮説検証とは
仮説検証は、仮説を立てる作業と、それを確かめる作業でできています。仮説は、まだ確かめていない「こうなるはず」という見込みです。検証は、その見込みが当たったかを、先に決めた基準で判定する作業です。
例を挙げます。「経理担当者は月末の請求書処理に困っていて、代行があれば申し込む」が仮説です。実際に10社へ案内し、何社が申し込むかを見るのが検証です。
仮説は、当たる前提で書くものではありません。外れたら外れたと分かる形で書きます。
「当たった」という確認をいくら重ねても、正しいとは言い切れません。一方で、はっきり外れる結果が1つ出れば、誤りは分かります。仮説検証は、早く間違いを見つける作業と考えると進めやすくなります。
統計学の「仮説検定」は、観察された差が偶然でも起こりうる程度かを確かめる手法です。この記事で扱う仮説検証は事業の進め方の話で、仮説検定とは別のものです。
仮説検証とPDCAの違い
PDCAのCheck(評価)は、運用によっては「計画どおりにできたか」の合否判定に寄りがちです。仮説検証が見るのは、「予測は当たったか、外れたなら何を学んだか」です。
品質管理の研究者デミング氏は、PDCAではなくPDSAを重視していました。Check(評価)の代わりにStudy(学ぶ)を置いた形です。
デミング研究所の解説では、Planで予測と成功の指標を決めます。Studyで予測と結果を比べ、Actで考え方そのものを直します。
2つの違いを、当社で表にまとめます。
| PDCAのCheck | PDSAのStudy | |
|---|---|---|
| 問い | 計画どおりにできたか | 予測は当たったか、なぜずれたか |
| 事前に決めるもの | 実行計画と目標 | 予測と、当否を判断する基準 |
| 結果の使い道 | 次の計画の手直し | 前提にしていた理論の書き換え |
Studyの考え方は、この記事でいう仮説検証とほぼ重なります。手順の決まった定型業務の改善なら、PDCAで足ります。当たるかどうか分からない新しい取り組みは、Planに予測を書き、Studyで答え合わせをします。
仮説検証型と仮説生成型
研究の世界でも、仮説を作る探索的な研究と、仮説を確かめる検証的な研究は分けて扱われます。この記事では、ビジネスの場面に合わせて2つを次のように呼びます。
- 仮説生成型:観察やインタビューから「こうではないか」を作る進め方
- 仮説検証型:作った仮説を、先に決めた基準に照らして確かめる進め方
2つを混ぜると、話を聞きながら結論を変え続け、何も確かめないまま終わりがちです。検証の途中で、想定していなかった困りごとが何人もの相手から出てきたら、いったん生成型に戻る目安にしてください。
アイデアを広げる段階は、生成AIでビジネスアイデアを生み出す方法で扱いました。ここからは、作った仮説を確かめる段階に絞ります。

仮説検証のやり方4ステップ
仮説検証は、次の4ステップを1周として繰り返すサイクルです。ステップごとに、そのまま使えるフレームワークがあります。
| ステップ | やること | 使えるフレームワーク |
|---|---|---|
| 1 | 仮説を洗い出し、1文で書く | リーンキャンバス、カスタマージャーニーマップ、ロジックツリー |
| 2 | 外れたら困る仮説から並べる | 望ましさ、実現可能性、事業性による仕分け |
| 3 | 検証方法と合格ラインを先に決める | Test Card |
| 4 | 結果を考察し、次の一手を決める | Learning Card |
1周は小さく回します。外れた仮説は書き直して、次の周に入ります。
仮説を洗い出し、外れたら分かる1文で書く
仮説の材料は、観察と手元のデータと現場の声です。問い合わせや解約の理由、営業が商談で聞いた話から、「こうではないか」を書き出します。
新規事業なら、事業の前提を1枚に並べるリーンキャンバスが洗い出しの枠になります。キャンバスの欄の一つひとつが、まだ確かめていない仮説です。書き方はChatGPTでリーンキャンバスを作る手順にまとめました。
既存事業の改善なら、顧客がどの段階でつまずくかを並べた図から仮説を拾えます。図の作り方は、ChatGPTでカスタマージャーニーマップを作る方法で紹介しています。
売上の減少のような大きな問題なら、ロジックツリーで分解する手もあります。問題を要素に枝分かれさせ、原因の候補を洗い出す図です。
ただ、ロジックツリーが出してくれるのは仮説の候補までです。この記事でTest Cardを主に据えるのは、どう確かめ、何をもって当たりとするかまで1枚で決められるからです。
書き出した仮説は、誰が、どんな行動をして、どうなるかが分かる1文にします。「若手社員は研修に興味がある」は外れようがないので、検証できません。
「入社3年目までの営業担当者は、商談の準備に毎週2時間以上かけている」なら確かめられます。「短くする方法があれば上司に相談する」まで続けたいなら、文を分けます。1文に詰めると、外れたときにどちらが外れたのか分かりません。
対象の人物像を絞るときは、ChatGPTを使ったペルソナの作り方が使えます。
外れたら困る仮説から並べる
並べる順番は、外れたら事業が成り立たなくなる順です。確かめやすいものからではなく、危ないものから確かめます。
どれが危ないかを1人で決めると、自分の立場から見えるリスクに偏ります。当社では、営業と開発のように立場の違う人と一緒に並べることを勧めています。
仕分けには、次の3つの観点が使えます。
- 望ましさ:人にとって大事な問題を解いているか
- 実現可能性:今の技術と能力で作れるか
- 事業性:現実の制約の中で成り立ち、続けられるか
私は学生の起業相談でメンターをしています。サービスを作りたいという学生の最初の相談で、事業で最も大きなリスクは売れないことだと伝えました。作れるかどうかは、その次です。
まず確かめるよう勧めたのは、お金を払ってでも解決したい課題が本当にあるかでした。この観点でいえば、実現可能性より先に、望ましさと事業性を確かめる順番です。
Test Cardで検証方法と合格ラインを先に決める
検証方法と、測る指標と、合格ラインは、試す前に書いておきます。
後から決めると、出た数字で「これなら成功」と言えてしまうからです。
この段階で使えるのが、Strategyzer社のTest Card(検証を計画するカード)です。カードの様式は同社のサイトで公開されています。欄は4つです。
| 欄 | 書くこと |
|---|---|
| 〜だと考える(We believe that) | 仮説 |
| 確かめるために〜する(To verify that, we will) | 検証方法 |
| 〜を測る(And measure) | 指標 |
| 〜なら正しい(We are right if) | 合格ライン |
欄の外には、費用、データの信頼度、かかる時間、その仮説の重要度を書く枠もあります。費用と時間を先に書いておけば、1つの検証に何週間もかける事態を防げます。
冒頭の請求書処理の仮説で埋めると、次のようになります。説明のために作った例です。
〜だと考える:経理担当者は月末の請求書処理に困っていて、代行の話なら聞きたい。 確かめるために〜する:5社の経理担当者に先月の処理の様子を聞き、最後に代行の説明の場を提案する。 〜を測る:次回の打ち合わせに応じた社数。 〜なら正しい:5社中3社以上が応じる。
合格ラインは「5社中3社が次回の打ち合わせに応じる」のように数字で書きます。「反応が良ければ」では、人によって判定が割れます。
線を引くときは、「これを下回ったら案を変える」と言える数にします。下回っても続けるつもりの線なら、引く意味がありません。
何人に当たり、いつ締めるかも、ここで決めます。人数は、事業が成り立つのに必要な顧客数から逆算します。見分けたい差が小さいほど、多くの人数が要ることも踏まえておきます。
検証方法は、得られる証拠の強さで選びます。目安として、購入や利用、継続といった実際の行動は強い証拠です。「使うと思う」という意向はその次で、意見は弱い証拠です。
代表的な手法を、一言ずつ説明します。
- 課題インタビュー:困りごとと今の対処を、相手の過去の事実で聞く面談
- アンケート:多くの人に選択式で聞く調査
- スモークテスト:広告や告知ページだけを出し、申し込みの反応を測る試験
- コンシェルジュ:仕組みを作らず、最初の数人に人手でサービスを提供する試験
- ウィザード・オブ・オズ:表側は本物らしく見せ、裏側を人の手作業で回す試験
証拠の強さの考え方に沿って、当社で並べると次のとおりです。
| 手法 | 得られる証拠 | 確かめられること |
|---|---|---|
| 課題インタビュー | 意見と過去の行動 | 課題が本当にあるか |
| アンケート | 意見と意図 | 仮説を作る材料 |
| スモークテスト | 軽い行動 | 関心があるか |
| コンシェルジュ | 支払いや継続 | お金を払う価値があるか |
| ウィザード・オブ・オズ | 利用の行動 | 実際に使われるか |
製品を作り込む前に、告知ページや人手の試験で反応を見るのが近道です。作ってから誰も欲しがらないと分かると、かけた時間がそのまま無駄になります。
Learning Cardで結果を考察し、次の一手を決める
結果が出たら、観察したことと、そこから考えたことを分けて書きます。そのうえで、続けるか、変えるか、やめるかを決めます。一般に「考察」と呼ばれるのが、この部分です。
使うのは、Test Cardと対になるLearning Card(学びを記録するカード)です。4つの欄でできていて、欄の外には、データの信頼度と、必要な行動を書く枠もあります。
| 欄 | 書くこと |
|---|---|
| 〜だと考えていた(We believed that) | 検証前の仮説 |
| 〜を観察した(We observed) | 観察した事実(数字、発言、行動) |
| そこから〜を学んだ(From that we learned that) | そこから学んだこと |
| だから〜する(Therefore, we will) | 次にやること |
考察で気をつけたいことを挙げます。
- 観察と解釈を分ける:「5社中2社が応じた」は観察で、「導入の手間が壁らしい」は解釈
- どれくらい確かかを書く:5社の聞き取りなら、市場全体の結論として扱わない
- 次の仮説につなげる:外れた理由の見立てを、次の周で確かめる1文に書き直す
上のTest Cardの結果を書いた記入例です。これも説明のために作った例です。
観察:5社中2社が次回の打ち合わせに応じた。断った3社は、いずれも導入の手間を理由に挙げた。 解釈:価格より、導入の手間が壁になっているようだ。 確かさ:5社の聞き取りなので低い。 次の仮説:導入作業を当社が代行すれば、断った3社のうち2社以上が打ち合わせに応じる。
合格ラインの3社に届かなかったので、仮説を書き直してもう1周回します。超えていたら、次に困る仮説へ進みます。
書き直しても手応えが出なければ、その案はやめます。

仮説検証の具体例
新規事業、営業、マーケティングの3つの場面で、Test Cardを埋めた設例を示します。いずれも型を示すために作った例で、実在の企業の事例ではありません。数字も置き方の例で、業界の目安ではありません。
| 欄 | 例1 新規事業 | 例2 営業 | 例3 マーケティング |
|---|---|---|---|
| 仮説 | 従業員50人以下の工場の工場長は、設備点検の記録づけに困っていて、月額の代行なら試したい | 昨年研修を2回以上発注した人事担当者は、来期の予算づくりの前に相談したい | 資料請求する経理担当者は、費用の安さより作業時間の短さで申し込みを決める |
| 検証方法 | 工場長8人に先月の点検の記録方法を聞き、最後に有料の試行を提案する | 該当する12社に、期末の2か月前に相談枠を案内する | 見出しだけを変えた告知ページ2つに、同じ条件で広告を出す |
| 指標 | 有料の試行に申し込んだ人数 | 案内から1か月以内に相談日程が入った社数 | 資料請求の率 |
| 合格ライン | 8人中2人以上 | 12社中4社以上 | 時間を訴えるページが、費用を訴えるページの1.5倍以上 |
実在の企業での新規事業研修の実施例は、トヨタ車体さまでのセミナーレポートで紹介しています。
新規事業の例(結果から判断まで)
例1を、結果が出たところから最後まで進めます。結果の数字も設例です。
8人のうち7人が、点検の記録に毎週手間がかかっていると話しました。一方、有料の試行に申し込んだのは1人で、合格ラインの2人に届きませんでした。
これをLearning Cardに書くと、次のようになります。
| 欄 | 記入内容 |
|---|---|
| 〜だと考えていた | 小さな工場の工場長は記録づけに困っていて、月額の代行なら試したい |
| 〜を観察した | 8人中7人が記録の手間を話した。有料の試行の申し込みは1人 |
| そこから〜を学んだ | 困りごとの仮説は当たり、代行という解決策の仮説が外れた可能性が高い。ただし8人の範囲の話 |
| だから〜する | 変える。点検表の書式を配るだけの案を、別の工場長8人で試す |
判断は「変える」です。困りごとがある手応えは得たので、案をやめる段階ではありません。外れたのは解決策のほうなので、次の周では解決策だけを差し替えます。
営業とマーケティングの例
例2の営業は、昨年研修を2回以上発注した12社が相手です。期末の2か月前に相談枠を案内し、1か月以内に4社以上が日程を入れるかを見ます。
結果は6社が日程を入れたとします(設例)。合格ラインを超えたので、判断は「続ける」です。
次の周では、発注が1回だけの会社に広げても同じ反応があるかを確かめます。変えるのは相手だけで、案内の時期は据え置きます。時期と相手を同時に変えると、どちらが効いたのか切り分けられないからです。
例3のマーケティングは、資料請求する経理担当者が、費用の安さと作業時間の短さのどちらで申し込むかを比べる設例です。見出しだけを変えた告知ページを2つ用意し、同じ条件で広告を出します。
ここでは、各ページに何人訪れたら判定するかも先に決め、Test Cardの合格ラインの欄に書いておきます。見分けたい差が小さいほど、要る訪問数は増えます。1.5倍の差なら、1.1倍の差を見分けるより少ない訪問数で判定できます。
結果は、時間を訴えるページの資料請求率が、費用のページとほぼ同じだったとします(設例)。合格ラインの1.5倍には遠く届きません。
判断は「やめる」です。作業時間を前面に出す案はやめ、費用を訴えるページを残します。差が偶然でも起こりうる程度かを確かめたいときは、統計の仮説検定を使います。

仮説検証でつまずく4つの失敗
仮説検証が「やったつもり」で終わる典型を4つ挙げます。どれも、手法の知識より運用の癖から起きます。
結果を見てから合格ラインを決めてしまう
3社から反応があったとき、合格ラインがなければ「3社も反応した」とも「3社しか反応しなかった」とも言えます。
Test Cardの4つ目の欄を、試す前にチームと共有しておけば防げます。決裁者がいるなら、その人とも先に合意しておきます。
自分の説に合う証拠ばかり集めてしまう
人は、自分の仮説に合う証拠を探しがちです。都合のよい発言ばかりが記憶に残り、外れを示す声は聞き流してしまいます。
対策は、検証方法を決める段階で「この結果が出たら外れ」という条件を書いておくことです。
意向だけ聞いて、事実を聞かない
「このサービスがあったら使いますか」と聞くと、相手は気をつかって答えがちです。「使うと思います」は意向で、証拠としては弱いものです。
聞くべきなのは、先月その困りごとにどう対処したか、いくら払ったか、という過去の事実です。アンケートも同じで、未来の意向を聞く設問は合格ラインの判定に向きません。
外れた仮説を失敗として片づけてしまう
外れた仮説は、検証が1つ済んだという成果です。確かめる前より、確かなことが1つ増えています。
外れを失敗として片づけると、Learning Cardが書かれず、学びが残りません。次の周で、同じ前提をもう一度試すことにもなりかねません。
外れた仮説ほど、観察と学びを書き残します。

生成AI時代の仮説検証
生成AIで速くなるのは、仮説の洗い出しと記録の整理です。顧客の代わりにAIに答えさせても、検証にはなりません。
AIで速くなる作業と、任せてはいけない作業
AIに任せてよいのは、仮説の候補出し、Test Cardの下書き、インタビュー記録の整理です。任せてはいけないのは、顧客の役を演じさせて合否を判定すること、要約だけ読んで元の発言を読まないことです。
要約だけで判断すると、顧客が口にした細かな言葉を取りこぼします。AIで見栄えのよい試作品がすぐ作れると、仮説が当たっている気になりやすい点にも気をつけてください。
社内でAIの使い方を揃えるなら、生成AI研修の選び方で扱った観点が参考になります。
AIを顧客の代わりにしない
UXリサーチの調査会社Nielsen Norman Groupは、合成ユーザーの限界を挙げています。合成ユーザーとは、AIで作った仮想の顧客のことです。
同社の記事によれば、AIは人の行動を非現実的に描き、相手に合わせて楽観的になりがちです。行動データも生み出せません。そのうえで記事は、合成ユーザーから得たデータを、検証が必要な仮説として扱うよう勧めています。
私は、生成AIを使った新規事業の講座で、インタビュー結果を付箋で分類する作業をAIに任せる場面を扱いました。受講者には、そのまま使えるのは4〜5割ほどなので、人が進行役として入る前提で使ってほしいと伝えました。講座で伝えた目安で、測った数字ではありません。
仮説検証を続けるための記録の残し方
当社では、2枚のカードを仮説1つにつき1組にするよう勧めています。置き場は、チーム全員が見られる1つの表です。
表には、仮説、合格ライン、締め日、結果、判断(続ける、変える、やめる)を1行で並べます。合格ラインは、試す前に決裁者と合意しておきます。振り返りは、Test Cardに書いた締め日ごとに行います。
表が1つにまとまっていれば、AIに過去の観察を読ませて、次の仮説の下書きを作らせることもできます。

まとめ
- 仮説検証は、まだ確かめていない見込みを、試す前に決めた合格ラインで判定し、次の一手を決める進め方です
- やり方は4ステップです。仮説を1文で書き、外れたら困る順に並べ、Test Cardで合格ラインを先に決め、Learning Cardで考察します
- 証拠は、意見より意向、意向より実際の行動のほうが強く、外れた仮説も学びとして書き残します
- 生成AIは仮説出しと記録の整理を速くしますが、顧客の代わりにはなりません
最初の1枚として、今の企画で外れたら困る前提を1つ選び、Test Cardを埋めてみてください。記事の欄を日本語にした空欄を置いておきます。
【Test Card】
仮説(〜だと考える):
検証方法(確かめるために〜する):
指標(〜を測る):
合格ライン(〜なら正しい):
締め日:
かける費用と時間:
仮説の重要度:生成AIを使って新規事業の仮説検証を社内で回したい場合は、AI駆動新規事業支援サービスで進め方をご紹介しています。
