昔は曖昧だと止まった。今は曖昧でも進む。だからAI時代の方が危ない

はじめに

AIを使うと、仕事が前に進む速度は確かに上がります。

コードのたたき台を作る。文章を整理する。調査の出発点を作る。ひと昔前なら半日かかったことが、数分で返ってくることもあります。

そこは本当に便利です。

でも、その便利さの裏に少し怖さがあります。

昔、ある自動車メーカー向けのCAD関連の仕事で、車体がたわんだときに、ある部品の曲面が別の部品にどう影響するかを計算する処理を作ったことがありました。

CGっぽく言うと、あるボディパネルの影が別のパネルのどこに落ちるか、みたいな計算です。担当の数学者が提示した式を、私がコンピュータで動く形に落とし込んでいました。

ところが、どうしても収束しないケースが出ました。

当然、最初は自分の実装ミスを疑いました。でも調べていくと、実装ではなく、渡されていた計算式のほうに問題があったんです。修正案とエビデンスをそろえて担当数学者に確認し、最終的に必要な機能を満たす形に直しました。

CGなら、ある程度それっぽく見えれば許される場面もあるかもしれません。でも、自動車の部品ではそうはいきません。人を乗せて走るものだからです。

この件を振り返って今強く思うのは、昔の開発は、曖昧さや不具合があると途中で止まるしかなかった、ということです。

人が確認に入る。検証で矛盾が見つかる。計算が収束しない。つまり、曖昧さが早い段階で露出しやすかった。

ところが今は、AIがそこをそれっぽく埋めて前へ進めてしまいます。止まらない。速い。しかも、見た目もそれなりに整っている。

だから私は、AI時代は楽になった部分もある一方で、仕様を伝える難しさはむしろ上がったと思っています。

1. 昔は、曖昧さがあると止まった

昔の開発環境は、今のように気軽ではありませんでした。

• 計算資源が限られていた
• 実行確認の回数も少なかった
• 一回の手戻りが重かった

そんな環境では、「まあ、だいたいこういう意味だろう」で進めるのは危険でした。

数学者や物理学者が考えた内容を、そのまま機械が理解してくれるわけではありません。考え方を整理し、前提を確認し、条件を明文化し、コンピュータが処理できる形に落とし込む必要がありました。

たとえば、次のような点が曖昧なままだと、どこかで必ず詰まります。

• 何を求めたいのか
• どこまでの誤差を許すのか
• 想定外の入力が来たらどうするのか
• 何をもって正しいと判断するのか

昔は、こういう曖昧さがあるとごまかしが利きませんでした。

計算結果が合わない。検証で再現しない。レビューで説明できない。曖昧な部分が、そのまま手戻りや停止として返ってきたのです。

しかも重要なのは、通訳する側が単に受け取って流すだけでは足りなかったことです。成立しているか、破綻しないか、要求を満たすかまで見ないと仕事になりませんでした。

今振り返ると、あの時代に必要だったのは「賢い人の頭の中にあるものを、曖昧さの少ない仕事の言葉に変えること」であり、同時に「それが本当に成り立つかを検証すること」でもありました。

2. 今は、曖昧でも進んでしまう

今はそこにAIが加わりました。

AIは便利です。ですが、読心術は使えません。

こちらが言っていない前提は、本来分からないはずです。それでもAIは、足りない部分を推測して、それっぽく補い、もっともらしい答えを返します。

たとえば、こう頼んだとします。

1

この画面のバグを直して

これでもAIは何かしら返してきます。

でも、本当に必要な情報はかなり抜けています。

• どの画面か
• 何がバグなのか
• 期待する挙動は何か
• 触ってよい範囲はどこまでか
• 何を確認したら完了なのか

人間の実装者なら、「情報が足りません」と聞き返してくれるかもしれません。ところがAIは、そこを自分で埋めて進みがちです。

ここが便利さであり、同時に危なさでもあります。

昔は曖昧だと止まりました。
今は曖昧でも進みます。

進むこと自体は良いのですが、正しい方向に進んでいるとは限りません。

しかもAIは速いので、ズレた前提のまま成果物が量産されやすい。これが人間相手より厄介だと感じる理由です。

3. 危ないのは「間違うこと」より「間違ったまま進むこと」

人間もAIも間違えます。そこ自体は新しい話ではありません。

でもAI時代に少し怖いのは、間違いが露出しにくいことです。

コンパイルエラーのように止まってくれれば気づけます。レビューで「この前提は違います」と返ってくれば立て直せます。

ところがAIは、ある程度もっともらしい文章、コード、設計案を返してきます。見た目が整っているので、「とりあえず前に進んだ感」が出てしまう。

私は、ここにAI時代の落とし穴があると思っています。

危ないのは、AIが間違うことそのものではありません。曖昧な依頼でも、止まらず、確認もせず、もっともらしく前へ進んでしまうことです。

昔の不便な環境には、皮肉にも安全装置がありました。曖昧さや不具合があると、収束しない、説明できない、検証で落ちるといった形で止まりやすかったからです。

今は便利になったぶん、その安全装置が弱くなったとも言えます。

4. では、何が必要なのか

ここで必要になるのは、魔法のようなプロンプトではないと思っています。

必要なのは、昔からある基本です。曖昧な仕事を、相手に渡せる仕様へ変換することです。

特に大事なのは、次の3つです。

4.1 目的

何のための依頼なのか。

• 調査だけでよいのか
• デモ用の暫定対応なのか
• 本番投入前提なのか

目的が曖昧だと、相手は頑張る方向を間違えます。

4.2 制約

どこまでやってよくて、何を守るべきか。

• 触る範囲はどこまでか
• 既存仕様は変えてよいのか
• 締切はあるか
• 優先するのは速度か品質か

制約がないと、優秀な相手ほど広く解釈します。

4.3 完了条件

何をもって終わりとするのか。

• テストが通ればよいのか
• 画面確認まで必要なのか
• 説明文や代替案も必要なのか

完了条件が曖昧だと、成果物の評価も曖昧になります。

要するに、AI時代に大事なのは「うまい聞き方」より先に、「仕事を仕様として言い直す力」ではないでしょうか。

5. 通訳の仕事はなくならない

昔は、数学者や物理学者の考えをコンピュータに通訳する必要がありました。 今は、人間の意図をAIに通訳する必要があります。

相手は変わっても、間に立って整理する仕事は消えません。

むしろAIが曖昧さを抱えたまま前へ進めてしまうぶん、その仕事の価値は上がっているように思います。

AIをうまく使える人とは、特別な呪文を知っている人ではなく、曖昧な依頼を仕事の言葉に変え、それが成立しているかを見に行ける人なのかもしれません。

まとめ

昔は、曖昧だと止まりました。でも今は、曖昧でも進んでしまいます。

だからAI時代の方が、仕様伝達はむしろ難しい。

もしAI活用がうまくいかないと感じたら、モデルの性能やプロンプトや mighty spell などの小手先を疑う前に、まずは依頼の中に次の3つが入っているかを見るのが近道です。

• 目的
• 制約
• 完了条件

便利になった時代ほど、曖昧さは静かに混ざります。

だからこそ今、昔からある「仕様を明文化する力」が、改めて重要になっているのだと思います。