「漏れはなさそう?」が、点検を始めさせる

「だいたいできた」のあとに、何を聞くか

何かを作り終えて「だいたいできたな」と思った瞬間、人はそのまま次へ進みたくなります。完成の手応えは、点検の動機を弱めます。けれど、その手応えがいちばん当てにならない局面でもある、というのが今日の話です。

前回は、私が事情を1つ明かすたびに、設計が組み変わっていく話でした。そうしてやり取りを重ね、必要なコードがひととおり揃います。動かす道具も、データの保管庫も、決まった時間ごとに回る仕組みも、形になっている。次の工程へ進める手前で、私は軽く一言、かけてみました。その何気ない一言が、思いがけず1つの工程をまるごと起動させた。問いは、ただの確認ではなく、工程そのものを動かすスイッチでした。今日はその仕組みを、順に見ていきます。

軽くかけた、確認の一言

私が聞いたのは、たいしたことではありません。これまでの話で準備してもらったコードに、実装の漏れは無さそう? その程度の、念のための確認でした。指示というより、確認の語尾を1つ添えただけです。

返ってきた反応は、確認の重さに対して不釣り合いでした。AIは「はい、大丈夫です」と流さずに、こう前置きします。肯定で済ませず、コードを見直しました、と。そして、自分が書いたばかりのものの中から、問題を掘り出してきました。私が頼んだのは「レビューして」ですらありません。「漏れはなさそう?」という、軽い確認だけです。入力の小ささと、起きたことの大きさが釣り合っていない。この落差そのものが、問いの働きを物語っています。軽い確認だけで、点検の工程が動き出しました。

自分のコードから、いくつもの穴が出てきた

見直しから出てきたのは、放っておけば後で痛い目を見るものばかりでした。性質ごとに見ていくと、点検が何を拾うのかがはっきりします。

一番こわかったのは、データをやり取りする順番の落とし穴です。手元の記録と保管庫の記録をそろえるとき、送る順番を1つ間違えると、せっかく自動で埋まった食後の血糖を、空っぽの値で上書きして消してしまう。これは、実際に使い始めてから、ある日とつぜん記録が消える、という形で表に出たはずの問題です。原因が時間差で表れるぶん、後から追うほど厄介な種類でした。それを、動かす前に、机の上で見つけて直せた。ほかにも、2つの作業が同時に走ったときに編集が消えてしまう取りこぼしがありました。さらに、言葉の定義の曖昧さも1つ。日本では炭水化物という言葉が、糖質と食物繊維を合わせたものを指すのに、そこを取り違えると糖質を少なく見積もってしまう。こうした穴が、次々に挙がってきました。

挙がった穴は、大きいものばかりではありません。データを保管する設計に、ある項目を置く場所が抜けていたこと。前から手元にあった古い記録を、新しい形に移しかえる手当てが用意されていなかったこと。一つ一つは小さくても、放っておけば、いざ動かしたときに「あれ、ここが入らない」と詰まる種です。小さな穴ほど、本番のさなかに見つかると、よけいに厄介になります。小さいから後回しでいい、という判断が、いちばん高くつくこともあります。

どれも、本番で起きてから気づいたら、原因を探すのに時間を取られたはずのものです。それが、出荷の前に、紙の上で潰れていきました。

机の上で見つけるのと、本番で見つけるのとでは、同じ1つの穴でも、かかる手間がまるで違います。動かす前なら、直して、もう1度確かめれば済む。でも動かしたあとだと、まず「何かおかしい」と気づくところから始まって、原因を探し、影響の範囲を確かめ、消えてしまったものがあれば取り戻せるかを考える。工程の数が、後ろにずれるほど増えていきます。穴そのものより、穴のまわりの後始末のほうが、ずっと重い。だから、出荷の前のひと手間は、惜しく見えて、いちばん安く付きます。

問いが、そのまま工程になる

ここで立ち止まって、考えてみます。なぜ、あの一言で点検が始まったのでしょう。

AIは、動くコードを書けます。けれど、書いたばかりの自分のコードを疑う、という工程は、放っておいても自動では始まりません。作った直後は、人もAIも、できあがったものを肯定したい引力がはたらきます。その引力に逆らって「本当に漏れはないか」と疑いにかかるには、外から問いを向ける必要がある。私の「漏れはなさそう?」は、答えがほしかったというより、点検という工程の起動ボタンでした。問いが、工程を呼び出す名前として働いたわけです。

ここに、AIと組むときのこつが1つあります。何をしてほしいかを、作業として頼むだけでなく、問いとして手渡す。「これで合っている?」「見落としはない?」「逆の場合はどうなる?」。こうした問いは、それ自体が、確認や点検や反証という工程の名前になっています。作業として「点検して」と命じるより、問いの形で渡したほうが、相手はその問いに答える過程で点検を実行する。問いの立て方が、そのまま、走らせたい工程を選んでいます。

これは、人どうしの仕事でも同じかもしれません。同僚に「これでいい?」と聞けば、たいてい「いいと思うよ」が返ってきます。でも「どこが弱そう?」と聞けば、相手は弱点を探しにいく。同じ相手でも、こちらの問いが、相手の頭の使い方を決めている。AIが相手だと、命令と問いの差が答えにそのまま映るぶん、その効き目がもっとはっきり出ます。

肯定で流されないために

もう1つ感じたのは、聞き方しだいで、返ってくるものが変わるということでした。「これで大丈夫だよね?」と同意を求めると、相手はつい「大丈夫です」と寄り添いたくなります。人もAIも、肯定のほうへ流れやすい。だから、点検を本当に走らせたいなら、同意を求めるのではなく、穴を探すように頼むほうがいい。

今回うまくいったのは、AIが、私の確認を同意の催促と受け取らずに、点検の依頼として扱い直してくれたからでした。とはいえ、それを毎回あてにはできません。だからこそ、こちらから「漏れはないか」「逆の場合は」と、疑う向きの問いを最初から渡しておく。肯定の引力に、問いの形で先回りしておくわけです。確認を、お墨付きをもらう場ではなく、穴を探す場に変える。そのひと工夫で、見つかるものがずいぶん変わります。

私自身、いつもこの一言をかけられているわけではありません。早く終わらせたい日ほど、できあがったものを、できあがったことにして、次へ行きたくなる。点検は、終わりを少しだけ遠ざける作業だからです。でも、その少しの遠回りが、後の大きな回り道を防いでくれる。終わらせたい気持ちと、確かめたい気持ちは、いつもせめぎ合います。だからこそ、点検を気分まかせにせず、問いという形で習慣にしておくと、忙しい日でも、この工程だけは抜け落ちずに済みます。

あなたが「だいたいできた」と思ったら

もしあなたが、何かを作り終えて「だいたいできた」と感じたら、その手前で、1つだけ問いをかけてみてください。漏れはないか。見落としはないか。逆の場合はどうなるか。相手がAIでも、あるいは自分自身に対してでも、同じです。

できあがったものを肯定したい気持ちは、自然なものです。でも、その気持ちのまま先へ進むと、本番で表に出るはずだった穴を、見送ってしまいます。点検は、勝手には始まりません。始めるのは、いつも1つの問いです。発注していない工程は走らない。けれど、問いを1つ渡すだけで、それは静かに動き出します。次回は、AIの知識そのものが、古いことがある、という話を。確かめずに信じると、足をすくわれます。

---

これは、自分の治療のために作っている自作自用版での話です。広く公開しているのは記録と集計に絞った carb-icr（無料・通信なし・ブラウザで動くPWA）。プロジェクトの概要は carb-icr のプロジェクトページ に。

本アプリは記録と集計の補助で、表示される値はすべて参考です。診断・治療、インスリン投与量の計算、治療パラメータの決定は行いません。投与量・治療方針は必ず主治医の指示に従ってください。