LLMを使うとき、最初に話題になるのはモデルの性能である。
どのモデルが賢いか。
どのモデルが速いか。
どのモデルが長い文脈を扱えるか。
どのモデルがコードに強いか。
どのモデルが自然な文章を書けるか。
もちろん、それは重要である。
道具の性能が上がれば、できることは増える。
作業は速くなる。
調査の入口も広がる。
文章も整えやすくなる。
一人では見落としていた観点を、短時間で並べられることもある。
ただ、LLMを使っていると、別のことも見えてくる。
同じモデルを使っていても、出てくるものがまったく違う。
それは単に、プロンプトが上手いか下手かという話だけではない。
何を聞くか。
どこまで聞くか。
何を聞かないか。
何を急がせないか。
どこで結論にしないか。
どこで人間に戻すか。
そこに、人間側の見方が出る。
LLMへの最大のパラメータは、問いである。
しかし問いは、単なる命令文ではない。
問いには、その人が何を見ようとしているかが出る。
何を消したくないかが出る。
何を急いで確定させたくないかが出る。
誰の判断を残そうとしているかが出る。
前回、LLMを議事録係ではなく、省略検出器として使う話を書いた。
打ち合わせをきれいに要約する前に、
合意したように見える場所へ、まだ揃っていない前提が残っていないかを見る。
そのとき重要になるのは、LLMそのものよりも、LLMに何を聞くかである。
たとえば、同じ打ち合わせメモをLLMに渡す。
ある人は、こう聞く。
「要約してください」
別の人は、こう聞く。
「決定事項とToDoを整理してください」
また別の人は、こう聞く。
「この会議で、合意したように見えるが、後からズレそうな省略を抽出してください」
どれもLLMへの問いである。
しかし、見ているものが違う。
最初の問いは、情報を短くしようとしている。
次の問いは、実行へ移しやすくしようとしている。
最後の問いは、まだ揃っていない前提を見ようとしている。
どれが絶対に正しいという話ではない。
ただ、問いには、その人が仕事のどこを危ないと思っているかが出る。
情報量が多いことを危ないと思う人は、要約を求める。
実行が止まることを危ないと思う人は、ToDoを求める。
合意したように見えて、実は前提が揃っていないことを危ないと思う人は、省略を見ようとする。
ここに、LLM活用の差が出る。
そしてその差は、能力だけでは測れない。
もちろん、問いを作るにも技術はいる。
良い聞き方、悪い聞き方はある。
出力形式を指定する力も必要になる。
曖昧な入力を分解する力も必要になる。
けれど、問いをすべて能力として扱うと、少し狭くなる。
「AIを使いこなせる人」
「プロンプトが上手い人」
「出力品質を高められる人」
そういう見方だけになる。
しかし、問いはもっと手前にある。
問いは、LLMへの命令文である前に、人間側の態度である。
この文章を、ただ整えたいのか。
それとも、整える前に消えそうな違和感を見たいのか。
この会議を、早く結論にしたいのか。
それとも、結論に見えているものの中に、まだ揃っていない前提がないか見たいのか。
この仕様を、問題ないものとして仕上げたいのか。
それとも、現場に入ったときに誰の判断回数が増えるかを見たいのか。
問いの差は、出力の差になる。
そして出力の差は、仕事の進み方の差になる。
LLMは、こちらが急がせれば急ぐ。
こちらが整えさせれば整える。
こちらが結論を求めれば結論を出す。
こちらが曖昧なものを残すように求めれば、曖昧なものの輪郭を出そうとする。
だから、LLMを使うときに本当に見えてくるのは、モデルの能力だけではない。
人間側が、何を良い出力だと思っているかである。
速いこと。
短いこと。
分かりやすいこと。
すぐ使えること。
それらしく整っていること。
これらは確かに良い。
しかし、それだけでは足りない場面がある。
実務には、速く処理すると壊れるものがある。
まだ決めてはいけない前提。
誰も引き受けていない責任。
言葉にはなっているが、立場によって意味が違う合意。
その場では流れたが、あとで現場に効いてくる違和感。
今は小さく見えるが、運用に入ると摩耗になる差分。
こういうものは、きれいな要約の中では消えやすい。
LLMは便利だからこそ、それを消してしまうことがある。
曖昧な会話を、整った議事録にする。
迷いながら話していた内容を、明確な方針のように見せる。
誰も決めていない判断を、自然に決まったことのように並べる。
それは一見、良い出力に見える。
しかし、実務では危ないことがある。
なぜなら、曖昧さそのものが悪いのではなく、どの曖昧さを残すべきか分からなくなることの方が危ないからである。
だから、LLMへの問いは、ただ賢い答えを引き出すためだけにあるのではない。
何を消さずに扱うかを決めるためにもある。
「この会議を要約してください」
ではなく、
「この会議で、まだ前提が揃っていない箇所を出してください」
と聞く。
「この文章を自然にしてください」
ではなく、
「この文章を自然にする前に、読み手によって誤解されそうな箇所を出してください」
と聞く。
「この仕様で問題ないか確認してください」
ではなく、
「この仕様が現場に入ったとき、誰の判断回数が増えるかを見てください」
と聞く。
「この方針で進めてよいですか」
ではなく、
「この方針を採る前に、人間がまだ判断しなければならないことは何ですか」
と聞く。
この使い方では、LLMは人間の代わりに決める存在ではない。
むしろ、人間に戻すべきものを見つける補助線になる。
これは派手な使い方ではない。
出力が劇的に見えるわけでもない。
生産性が何倍になった、という話にもなりにくい。
デモ映えもしない。
けれど、実務ではかなり効く。
なぜなら、人と人の間にある仕事では、答えそのものより、答えにする前の扱い方が重要になるからである。
顧客折衝。
要件定義。
仕様レビュー。
業務改善。
引き継ぎ。
問い合わせ対応。
社内調整。
AI導入そのもの。
こうした場面では、正しい結論を出す前に、まず何を結論にしてよいのかを見なければならない。
何を決めるのか。
何をまだ決めないのか。
誰が決めるのか。
誰の仕事が変わるのか。
どこで戻れるのか。
何が記録されるのか。
どの前提が、まだ揃っていないのか。
そこを見ないままLLMに出力させると、仕事は速く進む。
ただし、速く進んだ分だけ、後からズレが大きく戻ってくることがある。
問いは、出力を変える。
しかしそれだけではない。
問いは、その出力からどこへ戻れるかも変える。
良いLLM活用とは、速くすることだけではない。
速くできる場所は速くする。
しかし、速く決めると壊れる場所では、一度立ち止まる。
整えられるものは整える。
しかし、整えることで消える違和感があるなら、先にその違和感を見える場所に置く。
答えを出せるものは出す。
しかし、答えにしてはいけないものまで答えにしない。
その加減が、問いに出る。
問いが粗いと、LLMは粗く整える。
問いが急ぎすぎると、LLMは急いで閉じる。
問いが成果物だけを求めると、LLMは途中の揺れを消す。
逆に、問いが丁寧だと、LLMはまだ扱いきれていないものを見える形に戻してくれる。
ここでいう丁寧さは、礼儀正しい文章を書くことではない。
誰の判断を奪わないか。
どの前提を勝手に決めないか。
どの曖昧さを残すべきか。
どこで人間に戻すべきか。
何を出力の中で消してはいけないか。
それを見ることだと思う。
LLMを使う人間の良さは、能力の高さだけでは測れない。
どれだけ速く出せるか。
どれだけ上手く書けるか。
どれだけ複雑な指示を出せるか。
どれだけ正確にモデルを制御できるか。
それらは能力である。
しかし、良さは少し違う場所にも出る。
相手の判断を残す問いを置けること。
まだ言葉になっていないものを、すぐに処理しないこと。
関係者の受け取り差を見落とさないこと。
便利さの中で、消えてしまうものを一度見ること。
答えを出す前に、答えにしてよいかを確認すること。
そこに、LLMの使い方の良さがある。
ここでいう良さは、道徳的な正しさではない。
むしろ、仕事を壊れにくくする感覚に近い。
一度の会話を、あとで戻れる形にしておく。
結論だけではなく、適用範囲を残しておく。
相手を評価せず、条件の違いとして扱う。
合意したように見える場所に、まだ残っている分岐を見る。
閉じるべきところは閉じ、変わったら再び開けるようにしておく。
こうしたことは、派手ではない。
しかし、実務では静かに効く。
LLMは、人間より速く出力できる。
人間より広く候補を出せる。
人間より疲れずに言い換えられる。
だからこそ、人間側には別の役割が残る。
何を聞くか。
何を聞かないか。
何を決めるか。
何を決めないまま置くか。
何を人間に戻すか。
LLMへの最大のパラメータは、問いである。
そして問いは、その問いを作る人間から離れられない。
だから、LLMの良い使い方とは、良い答えを得ることだけではない。
良い問いによって、人間がまだ引き受けるべきものを、見える場所に戻すことである。
LLMに、答えを出させる。
それは便利である。
でも、それだけではない。
LLMに、答えにする前の置き場所をつくらせる。
LLMに、消えそうな前提を見つけさせる。
LLMに、人間へ戻すべき判断を照らさせる。
そういう使い方がある。
そして私は、そこにかなり静かな良さを感じている。
