連載「温故知新マーケティング実験室」· 第8編/全13編
その不具合、原因はそこじゃない
直す前に疑うデバッグ(連載 8)
不具合の原因を勘で決めつけて、見当違いを直して時間を溶かすこと、ありませんか。いちばん怪しく見えるものが、たいてい無実。直す前に測る、という習慣を、実際のすれ違いの記録から一緒に。
連載「温故知新マーケティング実験室」· 第8編/全13編
直す前に疑うデバッグ(連載 8)
不具合の原因を勘で決めつけて、見当違いを直して時間を溶かすこと、ありませんか。いちばん怪しく見えるものが、たいてい無実。直す前に測る、という習慣を、実際のすれ違いの記録から一緒に。
何かがうまく動かないとき、原因はきっとあれだ、と直感が働くこと、ありませんか。そして、その直感のまま手を入れて、しばらくしてから、ぜんぜん違うところが原因だったと気づく。費やした時間が、まるごと無駄になる。あの徒労感は、ものづくりをしていると、何度か味わうものだと思います。
前回お話しした無人運用の仕組みを整えるなかで、まさにこの「原因の取り違え」が起きかけました。今日は、そのときのすれ違いを記録としてたどりながら、不具合に出会ったときに直す前にやっておきたい、たった1つの習慣を、一緒に考えてみましょう。結論から言えば、いちばん怪しく見えるものは、たいてい無実です。
起きていた症状は、こうでした。AIへの問い合わせが、ときどき時間切れで失敗する。処理が途中で止まってしまう。無人で動かしている以上、これは放っておけません。
そこで真っ先に疑われたのが、この実験を動かしているパソコンの、ある設定でした。じつはこのマシンでは、通信のやり方のうち新しいほうの方式を、あえて切ってありました。以前それが原因で別のトラブルが起きたので、無効にしてあったのです。ふつうと違う、いかにも特殊な設定。時間切れが起きた瞬間、誰の目にもこれが犯人に見えました。きっとこの切ってある設定のせいだ、戻せば直るはずだ、と。
ここには、デバッグでとても起きやすい心の動きがあります。ふだんと違うもの、特殊なものが目に入ると、それを原因だと思い込みやすい。見た目の異常と、不具合の原因を、つい結びつけてしまうのです。でも、目立つことと、原因であることは、別の話です。
ここで、設定を戻して直そう、と手を動かす前に、1つだけやったことがあります。本当にその通信に問題があるのかを、測ってみたのです。
切っていないほうの方式で、同じ相手に1度だけ問い合わせてみると、答えはあっけないものでした。接続にかかった時間は、コンマ数秒。なんの問題もなく、正常に返ってきたのです。通信そのものは、まったく健康でした。つまり、いちばん怪しいと思われていた容疑者には、しっかりとしたアリバイがあったわけです。ここを測らずに設定を戻していたら、無実のものをいじって、原因はそのままに、時間だけを失っていました。
直す前に測る。たったこれだけのことですが、効き目は大きいものでした。直感は容疑者を指さしますが、その指先が正しいとは限らない。手を動かす前に1度だけ、その容疑者に本当に動機があるのかを確かめる。この一手間が、見当違いの修正を未然に防いでくれます。
測るときのコツは、なるべく小さく、1つだけ動かして試すことです。あれもこれも1度に変えると、何が効いたのか分からなくなります。今回も、複雑な処理ではなく、いちばん単純な問い合わせを1回だけ投げました。条件を1つに絞るほど、結果はくっきりします。原因の切り分けは、派手な調査ではなく、小さな1回の確認から始まります。
では、本当の原因はどこにあったのか。それは、ずっと地味なところでした。
AIへの問い合わせのうち、複数のモデルで念入りに考えさせるものは、1回にかなりの時間がかかります。長いものでは、数分におよびます。その長い問い合わせを、いっぺんにたくさん走らせていた。家庭用の回線は、たくさんの通信を同時に抱えるのが苦手です。長い処理と、多すぎる同時接続。この2つが重なって、いくつかが時間切れになっていたのです。
派手な設定の異常ではなく、ただ「いっぺんにやりすぎていた」だけ。原因は、しばしばこういう、目立たないところに潜んでいます。そして対策も拍子抜けするほど地味で、同時に走らせる数を絞る、それだけでした。前回お話しした、力を抜いてやり直す再試行も、この理解があってこその設計だったのです。
ここに、デバッグでいちばん大事な区別があります。目立つことと、原因であることは違う、ということです。あの特殊な設定は、たしかに目を引きました。けれど、目を引くことと、不具合を起こしていることのあいだに、つながりはありませんでした。一方の真犯人は、ありふれた「やりすぎ」で、ちっとも目立たない。私たちはつい、珍しいものと不具合を結びつけてしまいますが、その2つがただ同時に存在しているだけ、ということは、とても多いのです。並んでいることと、引き起こしていることを、分けて見る。これができると、容疑者選びの精度が一段上がります。
この話で、いちばん怖いところをお伝えします。もし測らずに、怪しい設定を戻して「直した」つもりになっていたら、どうなっていたか。
じつは、この通信環境には、その新しい方式がそもそも通る道がありませんでした。だから、よかれと思って設定を戻していたら、本来つながらない道を先に試そうとして、かえって動作が重くなっていたはずです。直したつもりが、新しい不具合を呼び込む。これがいちばんやっかいなパターンです。原因でないものをいじると、問題が解決しないばかりか、別の問題が増える。確かめずに手を入れる怖さは、ここにあります。
直すという行為は、それ自体がリスクです。正しい場所への修正は薬になりますが、見当違いの場所への修正は、新しい毒になりかねない。だからこそ、どこを直すかを決める前に、その場所が本当に原因かを確かめる順番が要るのです。
今日は、原因の取り違えをめぐる、ひとつのすれ違いの記録をたどってきました。最後に、あなたが不具合に出会ったときに使える形で、3つにまとめます。
1つ、いちばん怪しく見えるものを、すぐには信じない。特殊な設定や、目立つ異常は、犯人に見えるだけのことが多い。2つ、手を入れる前に、その容疑者を測る。本当に動機があるのかを、1度だけ確かめてから直す。3つ、直すこと自体がリスクだと心得る。原因でない場所への修正は、新しい不具合を生みます。
そしてもう1つ。原因が分かったら、その結末を短くでいいので書き残しておくことをおすすめします。今回も、真犯人は同時接続のやりすぎで、あの特殊な設定は無実だった、と記録に残しました。こうしておかないと、次に似た症状が出たとき、また同じ容疑者に飛びついてしまうからです。1度晴らしたアリバイを、何度も調べ直すのは、もったいない。デバッグの記録は、未来の自分が同じ回り道をしないための覚え書きになります。
もしあなたが、いま何かの不具合とにらめっこしているなら——直したい衝動を、ほんの一手間だけこらえて、まずその怪しい場所を測ってみてください。容疑者にアリバイが立つことは、思っているよりずっと多い。原因を当てる近道は、勘ではなく、確かめる順番のほうにあります。急がば測れ、というわけです。少しの確認が、長い回り道を省いてくれます。
次回は、その確かめる目をAI自身に持たせる話——自己改善が、見せかけの数字に踊らされて暴走しないために、を一緒に見ていきます。
この実験のプロジェクト概要は 温故知新マーケティング実験室 に。AIエージェント群の構成や設計思想を、もう少し詳しくまとめています。