要点
仮説とは問題の因果構造の説明であり、期待やストーリーとは本質的に異なります。この区別を誤ると、AI投資は設計段階で失敗が確定してしまいます。
その仮説は、本当に仮説なのか
「仮説がないのがAI・データプロジェクトによくある問題だ」と言われますが、多くの人は「いや、我々のプロジェクトに仮説はあるぞ」と思っているのではないでしょうか。
「仮説の有無」という表現にはすれ違いがつきものです。実際のところは、プロジェクトの仮説はしばしば、期待や願望に近いものにすり替わっています。
特に多く散見されたと感じる失敗パターンは、「データとAIで問題が解決できるはず・何かわかるはず」という前提でプロジェクトが始まることです。たしかにこれも仮説だといえば仮説です。が、プロジェクトはまだ設計段階であるにもかかわらず、この時点で迷走化がほぼ決まってしまいます。
なぜこのストーリーが問題なのかというと、プロジェクトの命題を検証していないからです。その代わりに「AIが問題を解決してくれる（ことを証明したい）」という期待が目的になっています。目的がすり替わっているのがわかると思います。「命題に関するこの予想は正しいのだろうか」という調査ではなく、「何かいい結果（ROIやストーリー）が欲しい」が目的になると、最悪のケースでは、「AIガチャ」のような状態に陥ります。
Note: 「AIガチャ」とは、「手元のデータをとりあえずMLやAIツールにかけてみて、精度が出たら採用、出なかったら別のデータで再挑戦、というサイクルを繰り返す」というプロジェクト構造のことです。（私の個人的なスラングです。）ROIが運任せに近づく、プロジェクトが長期化しやすい、といった問題があります。
ROIが求められる条件は、基本的には「合理化する対象の手段があること」です。そのため、上記のような前提を持ってしまう段階ではROIを目的変数にするのは時期尚早です。
こういった問題が繰り返される背景には、「仮説」に対する理解不足（あるいは、とにかくストーリーを作って進めざるを得ない、環境の圧力）があると考えています。そこでこの記事では、仮説の有無の判断基準や、仮説を欠くと何が起きるかという因果関係のイメージを共有して、仮説に対する具体的な理解を深めたいと思います。
仮説とは何か
では何が達成されていれば、問題解決において「仮説がある」と言えるのでしょうか。ここでは仮説の辞書的な定義ではなく、「仮説はプロジェクトにおいてどのように機能すべきものか」について私の見解を書きます。
結論としては、仮説は問題の「抽象化」（あるいは最低でも「一般化」）を達成するものである必要があります。抽象化が達成されていれば、「扱っている問題は一体どんな仕組みのもので、それゆえどんな解決策が有効なのか」という推察に、構造的な必然性や反証可能性が生まれます。つまり、仮説はただの期待や空想ではなく、論理的に信頼性のある「現象の説明」に近づきます。
抽象性：物事が起こる仕組み、なぜ起きるか
現象の因果関係が論理的に説明できるようになると、「ある条件でおそらく何が起こるか」という一定の帰結を導くことができます。この現象の説明からくる推察や予測と、現実のパターンとの間に整合性があるかを確認するのが、仮説検証です。検証が成立すると、扱われている仮説の抽象化は妥当性が高く、事象にはパターンがあり、抽象性と一般性がどちらもある、ということになります。
これを「仮説の蓋然性（がいぜんせい）が高くなった」と表現します。蓋然性は前述のような論理的な筋の良さや、現実のパターンの確認によって検証することができます。蓋然性が100%といえるケースが「必然性」、0%なら「ファンタジー」です。
Note: 冒頭で少し断りましたが、仮説に常に厳密な抽象性を要求すると、「現実的ではなく、やりすぎだ」ということになります。
重要なのは、「抽象化をできる限り試みることで、確度を上げる」というコンセプトです。その上で、「現象の記述化」「因果構造の説明」「反証可能性があること（＝仮説が間違っていることを証明する手段があること）」という条件を満たせるようにプロジェクトをディレクションすることが望ましい、という程度に捉えてください。
一般性：どんなパターンが、どのくらい起きるか
ここで抽象性に対して「一般性」という語が出てきましたが、こちらは単純にいえば「現象のパターン」のことです。抽象性が因果関係やその推察のことだとすれば、一般性は事象の相関に近いものです。「出来事AとBには関連性があり、同時に起こったり、逆に反発したりしやすい（らしい）」「出来事Cでは、ある条件で一定期間スコアが上がり、その後一定期間はスコアが下がる、これを繰り返す」といった内容です。
ただしここで重要なのが、「因果的な仕組みはわからないし、本質的な意味があるかはわからないけれど」という注釈がつくことです。つまり、根拠はないけどどうやら傾向があるっぽいんだよね、という意味で、論理的な確からしさは低いままです。
注意が必要なのは、このパターンには抽象性の裏付けがないという点です。つまり、この2つの関係が見せかけなのか、本質的な良い影響を生むものなのか、といったことはわかりません。
この点を深く追求せずに、とにかく強いパターンだけを探し求めたり、それをただ再現・反復しようとしたりすると、意味のないものを量産して事業にダメージを与えてしまう可能性もあります。これが冒頭に説明した「AIガチャ」の典型例で、手段先行がもたらす悲劇です。
パターンだけでは足りない理由
抽象化を欠いて一般化だけでプロジェクトを進めようとすると、いくつかのリスクが伴います。ここでは2つほど説明します。（後述のGIGOも含めると3つです。）
まず、パターンを際立たせることができる規模のデータが必要なので、結果の目処がついていなくても、先行でコストがかかります。
そもそも際立たせるパターン自体がなく、パターンを探すためにデータを集めようとしているなら、それはくじ引きです。パターンが見つからないことも多いでしょう。有益ではありますが、投資は避けるか、個人の興味関心レベルで取り組む程度が妥当です。
「データは資源だ、データがあればモデルはスケールする」というようなPRによく使われるストーリーもあるのですが、あれはあくまで、何が役に立つデータであり資源たり得るかを選別できる、問題の構造を把握した立場からの発言です。ストーリーの前提が省略されていたり、言語化されていないことに注意してください。
また、顕著なパターンを求めるほど、単純な構造の問題を追いかけることになります。
単純な問題を優先して扱うことは間違いではありませんが、多くの場合、その「構造が単純でパターンが明確な問題」は既知であり、対処も合理化済みです。投資価値の有無は先に決まっているべきことですが、果たして投資をする意味があるのか、途中から悩むことになるでしょう。
こういった状況が揃うと、投資効果が得にくかったり、すでにずれてしまった目的（＝AIが何か問題を解いてくれるはず、という期待の証明）を満たせない、といった結末に繋がります。
抽象性が仮説を成立させ、プロジェクトを成功に導く
問題が抽象化された状態を「仮説がある状態」だと捉えてください。仮説があるということは、問題が論理的に解釈できていることを意味します。問題が論理的に解釈できていれば、問題の観察手段や尺度、また、解決手段を設計可能になります。このあたりの段階になって初めて、データセットが設計できる、手段やツールを選定できる、ということです。そして、解決手段をテクノロジーの語彙で記述できるなら、それを合理的に反復したり再現できる可能性が飛躍的に上がります。
Note: システムによる合理化はある操作の合理的な反復と再生産です。（AIであればここに「曖昧さを許容した、確率的な」という枕詞が入ります。）
そのため、自然言語による問題の記述化 ＞ 論理的な記述による定性化・定量化 ＞ テクノロジー語彙による記述化、という段取りを踏んで、初めて合理的な反復と再生産が実行可能になります。そのため、最後の段階だけができても仕方がありません。
いわゆる「問題は解釈できてないが、反復だけは高度にできる」という状態、GIGO（Garbage In Garbage Out：本質を外した、ゴミの大量生産）になりやすいのです。
もし想像や期待がプロジェクトを先導し、問題解決がAI頼みになっている状況なら、それは残念ながら仮説がまだない段階です。この時点では観察や解決の手段が不透明なので、データやツールに投資しようとすると、無駄になるリスクが大きく上がります。仮説と期待の区別を誤ると、間違った目的に予算を投じてしまいます。この段階では仮説への投資が必要で、お金よりは時間と組織の投資を優先し、ツールやデータへの投資は待つべきです。