AI実務ログ：AIで仮説を早く出そうとしたら、逆に迷走した話

0｜実験ログ：仮説を早く出すための仕組みを作った

業務効率化のプロジェクトに入る前に、毎回ひとつ気になっていたことがあった。

クライアントと会話を始める前の段階で、
「この業務はどこまで効率化できるのか」という仮説を、
もう少し精度高く、かつ早く持てないか。

本来このフェーズは、

業務理解
↓
仮説構築
↓
すり合わせ

というプロセスを何度も往復しながら進める。
しかし、どうしても初動に時間がかかる。

そこで試したのが、業務効率化の「試算」をAIで事前に組み立てる仕組みだった。

対象となる業界の業務を洗い出し、
カテゴリーごとに分解し、
各タスクについて「どの程度効率化できるか」を仮説として算出する。

さらに、その結果をもとに、提案のたたき台となるスライドまで一気に生成する。

目的はシンプルだった。

クライアントと話す前に「当たり仮説」を持ち、初動のスピードを上げること。

このプロセスは、できるだけ恣意性を排除するために、複数のAIを役割分担させて構築していた。

業界選定やリサーチはPerplexity。
業務分解や粒度調整はClaude。
全体の統合やアウトプット生成はChatGPT。

さらに、最終的な判断は人間が行う前提で設計し、一つのAIの出力に依存しないようにしていた。

構造としては、

業界選定
↓
業務構造の整理
↓
タスク分解
↓
効率化手段の整理
↓
時短効果の試算
↓
スライド生成

という流れを、チェーンプロンプトでつないでいく。

自分なりに、かなり綿密に設計したつもりだった。

抜け漏れなく、ダブりもなく、それぞれの工程がきちんとつながっている。
どこか一部だけが良いのではなく、全体として矛盾のない構造になっている、という感覚があった。

実際に出てきたアウトプットも、かなりそれらしく見えた。

業務ごとに整理された効率化案。
具体的なツールの適用可能性。
そして、それぞれのタスクに対する削減時間の試算。

数値も出ており、構造も整っていて、提案資料としてそのまま使えそうな状態まで仕上がっていた。

「これは使えるかもしれない」

そう思えるだけの完成度だった。
少なくとも、初動の仮説としては十分に機能するはずだと感じていた。

1｜違和感は、かなり遅れてやってきた

違和感は、かなり遅れてやってきた。

最初は、アウトプットの完成度に意識が向いていて、細かい中身を疑うことはほとんどなかった。

むしろ、

ここまで整理されている
数値も具体的に出ている
論理的にも破綻していない

という状態を見て、「よくできている」と評価していた。

ただ、いくつかのタスクを並べて見ていたときに、ふと引っかかるものがあった。

削減率が、どれも似たような数値に収まっている。

50％前後。

60％を少し超えるものもあれば、40％台のものもある。
しかし全体としては、きれいにそのあたりに分布している。

その瞬間に、「こんなに揃うはずがない」と思った。

業務効率化は、そんなに均一に進むものではない。

あるタスクは大きく削減できる一方で、ほとんど変わらないものもある。
むしろ現実は、ばらつきが出る方が自然だ。

それにも関わらず、この結果は妙に整いすぎている。

そこで初めて、この試算そのものを疑い始めた。

2｜本当に引っかかったのは、数字ではなかった

ただ、本当に引っかかったのは、その数字そのものではなかった。

それまで、この違和感に気づけなかったことだった。

自分自身、この業務はある程度理解しているつもりだった。

どこが効率化しやすく、どこが難しいかも、感覚としては持っている。

それにも関わらず、このアウトプットを見たとき、最初に出てきたのは疑問ではなく、納得だった。

「それっぽい」と思ってしまった。

構造も整っている。
説明も一貫している。
数値も現実的に見える。

その状態を前にすると、内容の妥当性よりも、整合性の方を先に信じてしまう。

結果として、疑うべきポイントを見逃したまま、そのまま進めてしまいそうになっていた。

もしあのとき、あの「揃いすぎた数字」に違和感を持たなければ、この仮説を前提に、そのまま議論を進めていたと思う。

そしてその場合、議論の方向そのものが、最初からずれていた可能性がある。

3｜起きていたのは、単純な試算ミスではなかった

今回起きていたことを振り返ると、単純に「AIの試算が間違っていた」という話ではなかった。

むしろ問題だったのは、そのアウトプットが「間違っているように見えなかった」ことだった。

AIの出力は、一つひとつを見ると、それなりに妥当な要素で構成されている。

業務の分解も、効率化の手段も、使われている用語も、
どれも間違っているわけではない。

それらが矛盾なくつながり、一貫したストーリーとして並べられると、全体としての整合性が生まれる。

そしてこの整合性が、内容の妥当性よりも先に、信頼を作ってしまう。

今回のケースでも、

業務構造は整理されている
タスク分解も粒度が揃っている
効率化手段も一般的に妥当
数値も極端ではなく現実的に見える

という状態が積み上がっていた。

その結果、「一つひとつを疑う理由が見つからない」状態になる。

しかも、対話の中で改善を重ねていくと、この感覚はさらに強くなる。

修正を入れるたびに、

表現が整う
構造が整理される
抜け漏れが補完される

という変化が起きる。

すると、「より良くなっている」という実感が生まれる。

ただ、この「改善している感覚」の中で起きているのは、必ずしも質の向上とは限らない。

今回起きていたのは、むしろ逆の現象だった。

4｜改善していたのではなく、適応していた

AIの出力に合わせて、思考の前提そのものが少しずつ調整されていく。

最初は仮説として置いていたはずの前提が、整合性のある形で繰り返し提示されることで、
徐々に「疑わなくてよいもの」に変わっていく。

その結果、仮説が固定化されていく。

しかもこの固定化は、破綻や違和感を伴わず、むしろ「きれいに整理されていく」形で進む。

だからこそ、気づきにくい。

今回の一連のプロセスも、

仮説を出し
↓
それを整え
↓
さらに精緻化する

という流れの中で、

結果的には「特定の評価軸に適応した状態」に収束していた。

それは、現実の業務を反映した仮説というよりも、「もっともらしく見える構造」に最適化された仮説だった。

改善していたように見えて、実際には、特定の前提に沿って思考が整形されていただけだった。

5｜そこで初めて見えた、設計上の問題

今回の経験から、ひとつ明確に感じたことがある。

仮説を早く出すために使っていたはずのAIが、結果的に、判断を遅らせていた。

そしてその原因は、単純な精度の問題ではなかった。

むしろ、

構造が整っている
論理が一貫している
数値もそれらしく見える

という状態そのものが、判断を鈍らせていたように思う。

つまり、問題は「間違った出力」が出ることではなく、「疑いにくい出力」が生まれることだった。

この前提に立つと、AIの使い方も少し変わってくる。

たとえば、数値をそのまま受け取るのではなく、
その数値が成立するための前提や、成立しないケースを先に洗い出す。

あるいは、一つの仮説を精緻化するのではなく、
あえて複数の仮説を並べて、どれか一つに固定されない状態を保つ。

「整える」方向ではなく、「揺らす」方向の使い方に寄せる、という発想である。

ただ、こうした対応を入れたとしても、まだ十分ではない気もしている。

制約を加えることも、仮説を分岐させることも、結局は同じ構造の中での調整に過ぎない可能性がある。

今回起きていたのは、出力の問題というよりも、
「思考が特定の枠に収束していく構造」そのものだったのではないか。

そう考えると、単純にプロンプトを改善するだけではなく、AIを使う前提として、

どの段階で疑うのか
何を疑うのか
どこまでを仮説として扱うのか

といった「扱い方」自体を、もう一段上で設計し直す必要があるのかもしれない。

6｜今回止まったのは、ここだった

まだはっきりした答えは出ていない。

ただ、少なくとも今回の経験から、強く意識しておくべき前提は見えた。

改善は中立ではない。整っているものほど、疑いにくい。

AIは仮説を速く出してくれる。それ自体は間違いなく強い。

ただ、その速さと整合性が、そのまま判断の質につながるとは限らない。

むしろ、「改善している感覚」の中で、気づかないうちに一つの前提へと適応してしまうことがある。

今回、逆に迷走したのは、AIの精度が足りなかったからではなかった。

整っているものを、整っているという理由で信じかけてしまったからだった。

この構造を見落としたままAIを使うと、仮説を早く出すための手段が、逆に判断を遅らせるものになってしまう。

今回止まったのは、まさにその地点だった。