仮説検証のやり方：AI時代に仮説を絞って判断まで進める7ステップ

# 仮説は20個出た。それでも何も決まっていない

生成AIに、売上が伸び悩んでいる原因を挙げてください、と頼めば、5分で20個返ってきます。どれももっともらしく、どれも否定しにくい。会議に持っていけば、議論も盛り上がります。

そして、翌週も同じ議論をしています。

決まらない理由は、たいてい仮説の不足ではありません。出た仮説を検証していないから決まらない。検証していないので、どれが正しいか分からない。分からないので、声の大きい人の案か、去年やったことの延長が採用されます。

生成AIが起こした変化は、こう整理できます。仮説を作るコストは大きく下がった。検証するコストは、ほとんど変わっていない。検証は、現場で実際に起きることを待つ工程を含みます。文章を作る速度が上がっても、そこは短くなりません。この差が、新しい詰まり方を生んでいます。以前は仮説の数がボトルネックでした。今は検証の数がボトルネックです。

もうひとつ、新しい失敗も生まれました。AIに聞いて答えが返ってきたことを、確かめたと錯覚するという失敗です。返ってきたのは、その状況についてよく語られる説明です。自社で起きている事実ではありません。ここを混ぜると、検証を飛ばしたまま結論に進んでしまいます。

この記事は、仮説の作り方だけの話ではありません。出た仮説を絞り、確かめ、判断まで持っていくための設計の話です。

# 仮説とは何か、似ている言葉と何が違うのか

言葉の整理から始めます。ここが曖昧なまま進むと、検証できないものを検証しようとして時間を失います。

仮説とは、観察したことに対する仮の説明で、外れたときにそれが分かる形になっているものです。外れることが前提です。むしろ、外れる可能性がないものは仮説ではありません。

一番もっともらしいものを1つだけ選ぶ必要はありません。競合する仮説を複数並べて持っておくほうが、後で絞りやすくなります。

紛らわしい言葉と並べます。

言葉	中身	そのままで検証できるか
アイデア	思いついた案	できない。正しい・間違いの軸がない
予想	こうなりそうな見込み	将来の話なら事後に分かる。過去データで確かめられる場合もある
前提	疑わずに置いている条件	検証対象に入っていないだけで、命題としては確かめられる
施策	これからやること	できない。やるかやらないかの話
仮説	仮の説明。外れたときに分かる形をしている	できる

アイデアと施策は、それ自体では検証できません。ただし、それが何をもたらすかを主張の形にすれば検証できます。ここが実務での分かれ目になります。

会議で仮説と呼ばれているものの多くは、実は施策です。新しい顧客管理の仕組みを入れる、は施策です。仮説にするなら、案件の状況が担当者以外から見えないために対応が遅れている、まで書きます。この形なら、担当者以外が見られる状態を作って、対応速度が変わるかを確かめられます。

そして、前提が一番やっかいです。疑っていないので、そもそも検証の対象に入りません。当社の顧客は価格に敏感だ、当社の商品は説明しないと伝わらない。この手の前提は、いつ誰が確かめたのか誰も覚えていないのに、判断の土台になっています。仮説を出すときは、前提を1つ選んで仮説に格上げしてみる。これだけで、検討の質が変わることがあります。

# 最初に決めるのは仮説ではなく、何を変える判断か

多くの解説は、課題を設定して仮説を立てるところから始めます。順番として、その前に置くべきものがあります。

この検証の結果によって、何を変えるのか。これを先に1行書いてください。

書けない場合、その検証はやらなくて構いません。結果がどちらに出ても行動が同じなら、確かめる意味がないからです。実際、検証してみたが特に何も変わらなかった、という徒労の大半は、ここを決めずに始めています。

書き方は単純です。

• 仮説どおりなら、何を始める・続ける・広げるのか
• 外れなら、何をやめる・変える・保留するのか

この2つの答えが同じなら、検証する必要はありません。逆に、答えが大きく違うほど、その検証には価値があります。優先順位をつけるときの最初のふるいとして使えます。

例を挙げます。値上げをするかどうかを決めたいとします。検証したいのは、値上げしたら既存顧客が離れるか、です。仮説どおりなら段階的な値上げに切り替える。外れなら一律で上げる。行動が変わるので、この検証には意味があります。

一方、当社のサービスは他社より優れているか、を検証しても、仮説どおりでも外れでも明日やることは変わりません。だから優先度は低くなります。

# 良い仮説の型と、使えない仮説

仮説の書き方には型があります。埋めるだけで、検証できる形になります。

〈どういう条件のとき〉、〈誰・何〉は、〈どうなる〉。なぜなら〈理由〉だから。

営業の例で埋めてみます。

初回訪問から2週間以内に2回目の接触をした案件は、そうでない案件より受注率が高い。相手の検討が冷める前に、判断材料を足せるから。

この形にすると、数えれば分かる状態になります。過去の案件を2週間以内と以降で分けて、受注率を比べればいい。理由の部分を書いておくのも重要で、理由があると、外れたときに何を疑えばいいかが分かります。受注率が変わらなかったとしたら、検討が冷めるという理由自体が違ったのか、2週間という区切りが違ったのかを次に確かめられます。

使えない仮説は、3つの型に分かれます。

# 型1：外れたことが分からない

何が観測されたら間違いだと言えるのかを、答えられない仮説です。顧客第一で行けば会社は成長する。この文が間違いだと分かる状況を、誰も指定できません。だから永久に議論できて、永久に決まりません。

見分け方は簡単です。この仮説が間違っていたら、何が起きていますか、と自分に聞く。答えが出なければ、まだ仮説になっていません。

# 型2：粒度が粗い

営業力を強化すれば売上が伸びる。この形だと、仮に売上が伸びても、何が効いたのか分かりません。次に再現できないので、検証した意味が薄くなります。

粒度の目安は、その仮説を試すために明日やることが1つに決まるかです。決まらないなら、まだ分解が足りません。

# 型3：結論が先にある

自分が推したい施策を通すために、後から作った仮説です。この場合、検証は儀式になります。都合のいいデータだけが集まり、都合の悪い結果は条件が悪かったことにされます。

見分け方は、外れたときに自分が困るかどうか。困るなら、それは仮説ではなく願望が混じっています。困る自覚があるだけまだましで、無自覚だと検証そのものが機能しません。

# 20個から3個へ、3個から今回の1個へ

AIに仮説を出させると20個返ってきます。20個全部を検証することはできません。ここで絞る作業をしないと、仮説は増え続けて何も進まなくなります。

絞るのは2段階です。まず20個から候補を3つに減らす。次に、その3つの中から今回実際に検証する1つを選ぶ。残りの2つは捨てるのではなく、次の順番として残します。段階を分けるのは、候補を持っておくことと、いま手をつけることが別だからです。

減らす軸は3つです。

軸	問い	高いほど
影響度	当たっていたら、何がどれだけ変わるか	先に検証する
不確実性	今、どのくらい分かっていないか	先に検証する
検証容易性	何日、いくらで確かめられるか	先に検証する

3つとも高いものから手をつけます。組み合わせで見ると、判断がはっきりします。

• 影響度が高く、不確実性が低い：確かめるまでもなく方向が見えています。ただし、見えている答えが効果なしのほうである場合もあるので、方向を確かめてから動いてください。取り返しがつかない判断なら、不確実性が低くても一度は確認します
• 影響度が低く、不確実性が高い：知的には面白いのですが、後回しで構いません
• 影響度が高く、不確実性が高く、検証しにくい：ここが一番厄介です。分解して、確かめやすい部分だけ先に切り出します

この3軸だけで決めきれないときは、取り返しがつくかどうかを4つ目に足してください。次の節で扱います。

絞る作業は人がやってください。AIに、この20個から重要な3つを選んで、と頼むと選んでくれます。ただしAIは、渡していない限り自社にとって影響度が高いかを判断する材料を持ちません。一般的に重要とされる順に並べ替えるだけになります。

# 検証には2種類ある。安いほうから始める

検証と聞くと、実際にやってみることを想像しがちです。実務ではもう1種類あって、そちらを先に使うほうが効率的です。

裏を取る検証は、手元にある材料で確かめます。過去の案件記録、既存のデータ、社内の別部署が持っている情報、すでに取引のある顧客への一本の電話。数時間から数日で終わり、費用はほぼかかりません。

試す検証は、実際にやってみて結果を見ます。新しい打ち手を試す、対象を絞って先行導入する、比較して差を見る。数週間かかり、人と費用が要ります。

原則は、安いほうから始めることです。手元の材料で落とせるものを落としてから試す検証に進めば、時間と費用が本命に集中します。

この順番を逆にすると、何が起きるか。過去の案件を10件見れば5分で否定できた仮説に、3週間かけることになります。

ただし、裏を取る検証が常に先とは限りません。手元のデータが古い、集め方に偏りがある、そもそも新しい打ち手でデータが存在しない。この場合は、小さく試すほうが早くて確かです。判断の基準は順番そのものではなく、どちらが安く、判断に足る材料を出せるかになります。

裏を取る検証の材料は、探すと社内に思ったよりあります。案件管理の記録、見積の履歴、問い合わせの一覧、過去の議事録、請求データ。新しく集める前に、すでに持っているものを見る。これだけで検証の速度が変わります。

# 検証の重さを、リスクに合わせて変える

すべての仮説に同じ手間をかける必要はありません。検証をどれだけ重くするかは、間違えたときの損害で決めます。

見る軸	軽くていい	重くする
取り返しがつくか	元に戻せる	元に戻せない
影響する金額	小さい	大きい
影響する人数	一部の顧客・一部の社員	全顧客・全社員
法務・安全・信用	関わらない	関わる

多くの職場は、これを逆にやっています。取り返しのつくメール文面を何日も練り、取り返しのつかない値上げの告知や、人の採用や、システムの入れ替えを勢いで決める。

理由は分かります。取り返しのつく判断は目の前にあって数が多く、取り返しのつかない判断はたまにしか来ないからです。だからこそ、この4軸を判断の前に一度当てる習慣が効きます。4軸のどれかが重い側に振れていたら、検証を1段深くする。それ以外は、小さく試して結果を見るだけで十分です。

# 仮説どおり・外れ・判断不能を、始める前に決める

検証を始める前に書いておくものが3つあります。始めた後に決めると、結果に合わせて基準が動きます。

「仮説どおり」の基準：何がどうなったら、「仮説どおり」と言ってよいのか。数字で書きます。次の10件で受注率が現在の2割から3割以上になったら仮説どおり、のように。

なお、仮説どおりだったからといって、仮説が証明されたわけではありません。その結果と矛盾しなかっただけです。業務を前に進める判断としては、それで足ります。

「外れ」の基準：何がどうなったら、この仮説を採用しないと決めるのか。ここを書かないと、微妙な結果を前向きに解釈してしまいます。

判断不能の条件：ここが抜けている職場が多いです。母数が足りなかった、途中で別の要因が入った、データが欠けていた。この場合は、仮説どおりでも外れでもありません。判断不能を第三の結果として扱ってください。

判断不能を用意しておかないと、5件しか試せなかった結果を、なんとなく手応えがあった、と読み替えてしまいます。そして、その手応えが次の意思決定の根拠になります。

そのうえで、判断不能だったときに何をするかも、先に決めます。母数を増やして再実行するのか、条件を揃えてやり直すのか、この仮説自体を落とすのか。決めておかないと、判断不能の結果は放置されて、なかったことになります。

# AIで回す7ステップ

ここまでの設計を、実際の手順に落とします。AIを使う工程と、人がやる工程を分けてあります。

ステップ1：何を決めたい検証かを1行書く（人）。仮説どおりなら何をするか、外れなら何をやめるかを、両方書きます。

ステップ2：事実だけを並べる（人）。観察したことを、解釈を混ぜずに書きます。売れていない、は解釈です。7月の受注が3件で、前年同月は8件だった、が事実です。ここで解釈を混ぜると、以降の仮説が全部その解釈に引っ張られます。

ステップ3：AIに仮説を広げさせる（AI）。並べた事実だけを渡して、考えられる原因を20個挙げてもらいます。このとき、自分がどれを疑っているかは書かないでください。

以下は観察された事実です。この状況の原因として考えられる仮説を、20個挙げてください。ありがちなものだけでなく、見落とされやすいものも含めてください。私の意見はまだ言いません。

ステップ4：自分で3つに絞り、今回の1つを決める（人）。影響度・不確実性・検証容易性の3軸で候補を3つにして、その中から今回検証する1つを選びます。ここはAIに任せません。

ステップ5：AIに反証条件を出させる（AI）。ここが一番効く工程です。

次の仮説について、これが間違っているとしたら何が観測されるはずかを、5つ挙げてください。また、この仮説に合っているように見えて、実は別の原因でも説明がつく状況があれば指摘してください。

間違っていたら何が見えるかを先に決めておくと、都合のいい解釈を防げます。後半の、別の原因でも説明がつくか、という問いも重要です。2つのことが同時に起きているとき、どちらが効いたのかは切り分けないと分かりません。

ステップ6：裏を取る検証で落とす（人＋AI）。手元の材料で確かめます。AIは、どのデータを見れば確かめられるかの整理や、集めた記録の分類には使えます。ただし、AIが確からしいと言ったことは証拠になりません。

ステップ7：残ったものだけ試す（人）。試す前に、仮説どおり・外れ・判断不能の基準を書きます。書いてから始めてください。

7ステップのうち、AIが主役なのは3と5だけです。AIは選択肢を広げる工程と、反証を考える工程で使いやすく、何を採用するかを決める工程では使えません。決めるには、自社にとって何が重要かの判断が要るからです。この分担にしておくと、広げる工程が速くなった分だけ、絞る工程に時間を回せます。

質問の作り方そのものについては質問力の記事で詳しく扱っています。

# 1つの案件を、最初から最後まで通してみる

手順を通しでやるとどうなるかを、1本書きます。題材は、問い合わせは来ているのに商談化しない状況です。

1：何を決めたいか。来期の販促費を、集客に足すのか、初期対応の体制に足すのかを決めたい。

ここで気をつけることが1つ。1本の仮説が外れただけで、二択の反対側が正しいことにはなりません。初期対応に関する仮説がすべて仮説どおりにならなかったときに、はじめて集客側への配分を検討します。だから1本ごとの判断は、仮説どおりなら返信の型を全社で揃える、そうでなければ次の候補に移る、と書きます。

2：事実を並べる。直近3か月の問い合わせは月あたり40件前後で、前年から減っていない。うち商談まで進むのは月5件。初回返信までの平均は1.5営業日。返信後に返事が来ない件が20件ある。

3：AIに広げさせる。返信が遅い、返信内容が定型的すぎる、問い合わせの質が変わった。価格が合っていない、フォームの項目が多くて冷やかしが増えた、競合が先に接触している。ほか十数個が出ます。

4：自分で3つに絞る。影響度と検証容易性から、返信の速さ、返信内容、問い合わせの質、の3つを選びます。

5：反証条件を出させる。返信の速さが原因だとしたら、返信が早かった件の商談化率は高いはずです。逆に、早い件も遅い件も商談化率が変わらないなら、この材料からは裏づけられません。

6：裏を取る。過去3か月の問い合わせ120件を、初回返信が当日だった群と翌日以降だった群に分けて、商談化率を比べます。

ここで注意が1つ。これは過去の記録を後から分けて見ているだけなので、差が出ても返信の速さが原因だとは言えません。急ぎの案件ほど早く返している、担当者によって速さも腕も違う、といった別の要因が混ざります。差が出たときには使えず、差が無かったときにだけ使える材料です。差がまったく無いなら、この仮説を先に試す理由は薄くなります。

実際に差が無かったとしましょう。3週間の施策を打つ前に、半日で候補を1つ後ろに回せました。

7：残ったものを試す。返信内容の仮説が残りました。ここで、いきなり商談化率で判定しようとすると詰まります。月40件の会社で、商談化率が12.5%から18%へ上がったと数字で言い切るには、比べる2群でそれぞれ数百件が要ります。月40件では何年もかかる計算です。

そこで2つ変えます。

指標を、最終結果から途中の反応に降ろします。商談化率ではなく、返信に対して返事が返ってくる率を見ます。直近3か月は120件のうち20件が返事なしなので、現状は83%です。返事の有無は全件で測れるので、母数が最終指標よりずっと多く取れます。

ただし、ここは正確に扱ってください。返事が返らないのは120件中20件です。これをゼロにしても、残り100件が商談にならない問題は解けません。返答率は、返信内容の仮説を早く落とすための入口の指標であって、売上の答えではありません。返答率が動かなければ、この仮説はそこで落ちる。動いたなら、その先を見る価値がある、と分かる。落とすために使う指標です。

期間を2か月にします。1か月は約40件なので、2群に分けると各群20件にしかなりません。2か月なら各群40件です。

そのうえで、仮説どおりは返答率が95%以上に上がった場合、外れは届かなかった場合、判断不能は各群40件に届かなかった場合。この3つを先に決めます。

あえて、「仮説どおり」と「外れ」の間に空白を作っていません。93%だったらどうするか、を後から相談できる形にすると、結局は前向きに解釈します。基準を先に決める意味がなくなるので、境界は1本にしておくほうが機能します。

それでも、この件数で見えるのは大きな差だけです。数ポイントの違いは、この母数では区別できません。だから最初から、文面を少し整える打ち手ではなく、返事の返り方が明らかに変わりそうな打ち手を選びます。

# 母数が足りない会社が、それでも検証するには

前の節の最後が、中小企業でいちばん詰まるところです。統計的に確からしいと言える件数は、多くの会社では集まりません。

ここで、諦めるか、母数が足りないまま差が出たことにするか。どちらも選ばなくて済みます。現実的な道が3つあります。

1. 指標を手前に降ろす。最終成果の手前にある、件数が多くて早く出る反応を見ます。受注ではなく商談化、商談化ではなく返信への返答、返答ではなく資料を開いた率。手前ほど母数が多く、早く分かります。ただし手前の指標が動いても最終成果が動くとは限らないので、そこは別に確かめます。

2. 小さい差を狙わない。母数が少ないと、小さい差は見えません。だから最初から、大きく変わりそうな打ち手を選びます。見える大きさの差を作りにいく設計です。数ポイントの改善を積む戦い方は、件数のある会社のやり方になります。

3. 分からなかったことを、分からなかったと記録する。件数が足りずに判定できなかった場合、判定できなかったと書く。手応えがあった、と書かない。この1行があるかどうかで、半年後の判断の質が変わります。

そして、数字で決められないときは、数字以外の材料を足します。返事が返らなかった相手に理由を聞く。断った顧客に確認する。件数が少ない代わりに、1件あたりを深く見る。中小企業では、こちらのほうが現実的なことが多いです。

この通し例で一番効いているのは、手順6です。裏を取る検証を挟んだおかげで、外れている仮説に1か月を使わずに済みました。

# 場面別の応用

同じ設計を、それぞれの現場に当てはめた例を並べます。

場面	よくある思い込み	裏を取る検証	試す検証
営業	失注の理由は価格	過去20件の失注理由を分類し、価格以外の要因を数える	提案書の構成を変えて次の10件で比べる
マーケティング	問い合わせが減ったのは検索順位のせい	表示回数・クリック率・到達後の離脱を分けて見る	該当ページの導線を1か所だけ変える
新規事業	この課題に困っている人がいる	直近3か月で同じ相談が何件来たかを数える	先に申し込む人がいるかを実際に聞く
社内改善	この作業に時間がかかっている	1週間だけ実測する	一部の人だけ手順を変えて比べる

営業の失注理由は、特に注意が必要です。断る側は、価格が理由だと言うと角が立ちません。だから価格と言われた件数を数えても、実態は分かりません。同じ相手に、価格が同じだったら決めていましたか、と聞くと違う答えが出ることがあります。

新規事業の課題検証は、聞き方で結果が変わります。困っていますか、と聞けば、たいてい困っていると答えます。今までにその問題にお金や時間を使ったことがありますか、と聞くと、答えの精度が上がります。

マーケティングの訴求を小さく試す進め方は行動経済学の記事でも扱っています。

# 仮説検証がうまくいかない、6つの失敗パターン

設計どおりに始めても、途中で崩れることがあります。崩れ方はだいたい決まっているので、先に知っておいてください。

# 1. 基準を後から決める

検証を始めてから、どうなったら成功かを決める。結果が出てから基準を作れば、どんな結果でも成功にできます。前の節で基準を先に書くと言ったのは、意志の力に頼らないためです。

# 2. 一度に複数を変える

返信を早くして、同時にテンプレートも変えて、ついでに担当も替える。結果が良くなっても、何が効いたのか分かりません。次に再現できないので、検証した意味が半分になります。

比較の設計をせずに、複数を同時に変えないでください。複数を一度に調べたいなら、どの組み合わせを誰に当てるかを割り付ける設計が要ります。そこまでやらないなら、変えるのは1回に1つです。

まとめて変えたくなるのは、早く結果を出したいからです。設計なしにまとめて変えると、結局はもう一度やり直すことになります。

# 3. 母数が足りないのに結論を出す

3件試して2件うまくいったので成功率67%。計算は合っています。問題は、3件では幅が大きすぎて、次の判断の根拠にならないことです。報告するなら、67%ではなく3件中2件と書いてください。分母が見えていれば、読んだ人が自分で確からしさを判断できます。

何件あれば十分かは、見たい差の大きさで変わります。差が大きいほど少ない件数で見え、小さいほど多く要ります。実務では、判断不能の条件として最低件数を先に書いておき、それに届かなければ判定しない、という運用で足ります。

# 4. 検証する人と、決める人が離れている

現場が検証して、結果を報告して、決めるのは別の人。この形だと、報告の過程で結果が丸められます。悪い結果ほど、伝わる途中で角が取れます。

対策は、検証の設計段階で、決める人に基準を見せて合意しておくことです。基準に合意していれば、結果はそのまま届きます。

# 5. 期限を決めていない

検証がずるずる続くと、実質やっていないのと同じです。もう少しデータを集めてから、が半年続く。いつまでに判断するかを、始める前に書いてください。期限が来たらデータが足りなくても、判断不能として次に進みます。

# 6. 記録が残らない

半年後に、同じ議論がゼロから始まります。これは次の節で扱います。

# AIの回答は、証拠ではない

ここは、はっきり線を引いておきます。

AIが可能性が高いと答えても、それは自社で起きた事実ではありません。学習した中で、その状況に対してよく語られる説明が返っているだけです。一般論として正しいことと、自社で起きていることは別です。

この線を引かないと、検証を飛ばします。AIに聞いたら原因が分かった、と会議で言った時点で、確かめる工程が省略されます。AIに聞いて分かるのは、確かめる価値のある候補までです。

いくつか、実務で効く注意点を挙げます。

問い方によって、返ってくる答えの傾向が変わります。返信が遅いのが原因だと思うんだけど、どう？と聞けば、その考えを補強する材料に偏ることがあります。こちらが置いた前提に沿って答えが組み立てられるためです。

対策は2つあります。自分の考えを明かさずに事実だけ渡す。あるいは、この仮説を否定する材料を挙げてください、と明示的に頼む。明示的に頼んだほうが偏りは減りますが、それで無くなるわけではありません。反証が返ってきたら、それも自社の事実と照らして確かめてください。

接続も提供もされていない自社データは、参照できません。手元の数字を渡せば計算はできます。社内の保管先とつないだ環境なら、そこにあるデータは読めます。それ以外の、渡してもつないでもいない情報について語り始めたら、そこは推測です。自社の数字らしきものが出てきたら、どこから来た数字かを必ず確かめてください。

出させた数字は実データではありません。業界平均は何%ですか、と聞くと、それらしい数字が返ってきます。資料に載せる数字は、自分が出典を示せるものだけにしてください。

2つのことが同時に動いたとき、割り付けを設計していなければ、どちらが効いたかは判定できません。返信を早くすると同時にテンプレートも変えたなら、結果が良くなっても原因は分かりません。何をどう分けて試すかを決めるのは、人がやる仕事です。

そもそも原因の候補が思い浮かばない場合は、個別の出来事から共通点を取り出す練習が先かもしれません。具体と抽象の記事で扱っています。

# 記録は、事実と解釈を分けて残す

検証を1回やって終わりにすると、次に活きません。記録の形を決めておいてください。項目はこれで足ります。

• 日付
• この検証で何を決めたいか
• 仮説（1行）
• 事前に決めた基準（仮説どおり・外れ・判断不能）
• 観察した事実
• その解釈
• 結果と、次にやること

事実と解釈を別の欄にするのが肝です。混ぜて書くと、後から読んだときに何が起きたのか復元できません。返信を早くしたら手応えがあった、では、何件で何%だったのかが失われています。

そして、外れた仮説を消さないでください。外れた記録は、次の仮説を作るときの材料になります。同じ仮説を半年後に別の人が思いつくのも防げます。外れた記録が残っている組織は、同じ検証を二度やりません。

記録を残す形式は、既存の議事録や案件管理に列を足すだけで十分です。新しい仕組みを入れる話にすると、それ自体が検証されていない施策になります。根拠と結論を分けて残す考え方はビジネスフレームワークの記事でも触れています。

# 日常で仮説思考を鍛える4つの練習

大きな検証は、そう何度も回せません。仮説を立てる筋力は、日常の小さな練習で維持できます。どれも3分以内です。

# 練習1：他社の動きに、理由の仮説を3つ立てる

競合の値上げ、新しいサービス、業界のニュース。目にしたら、なぜそうしたのかの仮説を3つ書きます。3つ書くのが要点です。1つだと、最初に思いついたものに固定されます。

答え合わせはできませんが、それで構いません。複数の説明を並べる動作そのものが練習になります。

# 練習2：予想を先に書いてから、結果を見る

会議の結論、営業の返事、月末の数字。見る前に、自分の予想を1行書いてから見ます。当たり外れを記録してください。

1か月続けると、自分がどの領域で当たって、どの領域で外すかが見えてきます。外す領域は、自分が確かめずに持っている前提が多い領域です。

# 練習3：週に1つ、前提を仮説に格上げする

社内で当たり前になっている前提を1つ選び、検証できる形に書き直します。確かめるかどうかは後で決めて構いません。書き直す作業自体が練習です。

前提が思いつかない場合は、会議で誰も質問しなかった発言を探してください。全員が同意した箇所に、たいてい前提が隠れています。

# 練習4：結論を出す前に、AIに反証させる

何かを決める前に、この考えが間違っているとしたら何が観測されるか、を一度聞きます。30秒です。

この練習の要点は、聞くまで出てこない材料があることです。人は自分の考えを補強する材料を先に思い出します。反証は、意識的に取りに行かないと集まりません。

# KOIYALの見解：これから差がつくのは、間違いを早く認める速さ

仮説を作る力は、もう希少ではありません。AIが5分で20個出す以上、量では差がつきません。切り口の意外さでも、そこまで差はつかなくなりました。

では、どこで差がつくか。捨てる速さです。

出した仮説の大半は外れます。外れているものを早く見つけて手を引けば、残ったものに時間を使えます。逆に、自分が最初に思いついた仮説に固執すると、AIが20個出してくれても意味がありません。

そして、間違いを認めるのは、能力ではなく設計の問題です。「外れ」の基準を先に書いていれば、認めるかどうかは自分の意志の問題ではなくなります。基準を満たさなかった、という事実の問題になります。この記事が、基準を先に書くことにこだわっているのはそのためです。

もうひとつ、組織で決めておくと効く規律があります。検証していない仮説を、検証済みと呼ばない。AIに聞いた、他社もやっている、経験上そうだ。これらは検証ではありません。呼び分けるだけで、会議で扱われ方が変わります。

# 次の一歩

今日から始めるなら、1つだけで構いません。

いま社内で当たり前になっている前提を1つ選んで、仮説の形に書き直す。当社の顧客は価格に敏感だ、を、価格を下げた案件は、そうでない案件より受注率が高い、に書き換える。そして、手元の記録で数えられるかを確かめてください。

数えられる形になった時点で、それは検証できる問いになっています。数えてみて、思っていた通りだったなら前提が裏付けられます。違ったなら、もっと大きな発見です。どちらに転んでも、次の判断が変わります。

仮説検証の設計は、初回だけ経験者と一緒にやると精度が大きく変わります。KOIYALでは、検証の設計と撤退基準づくりを、経営者・個人事業主向けのAI顧問・コンサルティングと法人向けのAI研修で支援しています。「この仮説、どう検証すればいいか」という持ち込みも歓迎です。お問い合わせからご相談ください。

# 出典・確認日

• 本記事の内容は、当社の伴走支援での検証設計と、自社業務での実践に基づいています
• 自社での実践例: 2026年7月時点のKOIYALのハーネス・ループエンジニアリング（撤退基準・キルテストを先に決めて運用している実録）
• 最終確認日: 2026年8月9日