制約を明かすたび、設計が組み変わる

自分の事情を1つ伝えるたびに、答えが変わった

AIに作り方を相談していると、自分の状況を1つ付け足しただけで、返ってくる設計がまるごと組み変わることがあります。今日は、その組み変わりがなぜ起きるのか、何が引き金になっているのかを、一緒に見ていきます。

前回は、調べていくうちに、本当のボトルネックが最初の想定と別の場所にあった話でした。血糖を自動で取りに行く、という方針が立ったところから、いよいよ具体的な作りに入ります。ここで起きたのは、私が自分の事情を1つ明かすたびに、相棒のAIが設計をそのつど引き直す、という連鎖でした。設計を動かしていたのは、賢いアイデアではなく、私だけが知っている地味な事情のほうだった。同じ相談相手に、同じ目的を投げても、こちらが渡す前提が1つ変わるだけで、戻ってくる形が変わります。その仕組みを、4つの場面に分けて追っていきます。

「これはブラウザで動くアプリなんだ」と伝えたら

まず、私のアプリの形を伝えました。特別な土台の上ではなく、ブラウザだけで動く、ごく素朴な作りです。データも、サーバーには送らず、ブラウザの中だけに置いている。これを聞いたAIは、すぐに2つの制約を指摘しました。

1つは、ブラウザからは、さっきの血糖の窓口を直接たたけないこと。安全の決まりごとがあって、間に「取次役」を1つ置く必要がある、と。もう1つは、ブラウザのアプリは、開いている間しか動けないこと。だから、食後の血糖を後から埋めるには、次にアプリを開いたときに過去にさかのぼって埋める、という回りくどいやり方になる、と。形を伝えただけで、設計の前提が2つ、その場で書き換わりました。

ついでに釘も刺されました。ブラウザの中のデータは、ふとした拍子に消えることがある。だからバックアップの仕組みが要る、と言いかけたところで、私は次の事情を明かします。

「バックアップはもう入れた」と伝えたら

データを書き出して持ち出す機能は、もう自分で入れてあったのです。それを伝えると、AIの提案は、長い説明から一行に縮みました。なら、残りはブラウザに「このデータは消さないで」とお願いする、ほんの一手だけでいい、と。

これは小さな一幕ですが、象徴的でした。AIは、私がすでに何をやったかを知りません。だから黙っていれば、親切にも、もう済んでいる作業まで一から提案してくる。済んだことを「これは入れた」と伝えるだけで、提案から重複が消えて、残りの一手に話が絞られる。聞かれてから答えるのではなく、聞かれる前に渡す。それだけで、回り道がひとつ減りました。私の手の内を見せるたびに、AIの設計は、無駄を削って身軽になっていきました。

「サーバーとデータベースもありかな」と聞いたら

ここで私は、別の選択肢を口にします。さっきの取次役を、ちゃんとしたサーバーの仕組みで用意して、ついでにデータの保管庫も足すのはどうか、と。AIの答えは、単なる賛成ではありませんでした。それを足すなら、設計が一段変わる、と言うのです。

保管庫があるなら、アプリを開いていなくても、決まった時間ごとに血糖を勝手に集めておける。すると、さっきの「次に開いたときにさかのぼって埋める」という回りくどいやり方が、まるごと要らなくなる。後から埋めるのではなく、最初から溜まっている状態にできる。事情を1つ足しただけで、前の段で決めた回りくどい設計が、丸ごと不要になりました。ここに、設計という作業の性質が出ています。設計は、上へ上へと積み上げていくだけの作業ではありません。前提が変わると、前に建てたものを潔く取り壊して、土台から組み直すほうが早いことがある。足し算ではなく、引き算や建て替えも、設計のうちに含まれます。

ここで、もったいない、と粘らなかったのが結果的に効きました。前の段で考えた回りくどいやり方も、それなりに頭をひねった設計です。けれど、より良い前提が出てきたなら、惜しまず捨てる。すでに注いだ手間は戻ってこないので、それを惜しんで判断すると、選ぶ基準が現在ではなく過去に引っぱられます。作りかけを守ろうとして古い前提にしがみつくと、せっかく見つかった良い道のほうを見送ることになる。捨てる判断もまた、設計に含まれる一手です。

「その契約はもう使っている」と伝えたら

最後に、私はもう1つの事情を明かしました。そのサーバーの仕組みを、有料の枠で個人的にもう契約している、と。これを聞いて、AIは最後の遠慮を外しました。無料の範囲では、決まった時間ごとに動かす回数に制限がかかる。でも、その制約はもう外れている。なら、最初から、全部が自動で回る構成で組んでしまっていい、と。

ここでも、動いたのは私の事情でした。同じ「サーバーを使う」でも、無料か有料かで、組める設計の天井が違う。その天井の高さは、私の契約状況を伝えるまで、AIには分かりませんでした。

設計を動かしていたのは、私の現場情報だった

ふりかえると、この一連は、私が事情を小出しにするたびに、AIが最適な形を引き直していく、その繰り返しでした。アプリの形。すでにやったこと。足してもいい道具。契約している枠。どれも、AIが外から知りようのない、私の現場の情報です。

賢いアイデアを出していたのは、たしかにAIでした。でも、そのアイデアを正しい方向へ向けていたのは、私が明かす制約のほうでした。制約は、設計を縛るやっかいもののように聞こえます。けれど実際には、制約こそが、無数にある選択肢の中から、いま自分に合う1つを選び出す道しるべでした。選択肢が多すぎると、かえって決められません。制約は、その広すぎる候補を削って、現実に組める範囲へと絞り込んでくれます。事情を隠したまま相談すると、AIは一般論の中で迷います。手の内を見せるほど、答えは自分専用に近づきます。

なぜ、私たちは事情を後出しにしてしまうのでしょう。たぶん、自分にとって当たり前すぎて、わざわざ言うほどのことだと思えないからです。ブラウザだけで動くアプリだ、ということも、もうバックアップは入れた、ということも、私の中では前提でした。前提は、息を吸うのと同じで、いちいち口に出しません。でも、その当たり前こそ、相手にとっては最初の手がかりです。自分の中で透明になっている前提を、あえて声に出してみる。それだけで、相談の質はずいぶん変わります。

あなたがAIに相談するとき

もしあなたが、AIに何かの作り方を相談していて、なんだか一般論ばかり返ってくるな、と感じたら、自分の事情を、もう1つ明かしてみてください。どんな環境で動かすのか。もう何をやってあるのか。使える道具や、契約しているものは何か。

AIは、あなたの状況を知りません。だから、あなたが伝えた分だけ、答えはあなた専用に近づきます。設計を動かすのは、たいてい、あなたしか知らない地味な事情のほうです。いちばん大事な情報は、AIの中ではなく、あなたの手元にあります。

今日からできるのは、相談のはじめに、自分の前提を3つだけ書き出してみることです。どんな環境で動かすのか、もう何をやってあるのか、何が使えるのか。丸投げするのではなく、自分の事情を渡す。その渡し方の丁寧さが、返ってくる答えの精度を、静かに決めていきます。次回は、そうやって組み上がったコードに、私がかけた何気ない一言の話を。その一言が、思いがけず点検の工程を起動させました。

---

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

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