5万4,652トークンかけて直した"バグ"は、そもそも壊れていなかった話
改行コードを直すだけの作業に、5万4,652トークンかかった。中身は数行の書き換えで、大した仕事には見えない量だった。
しかも、あとで実際に動かして比べてみると、直す前と直したあとで挙動は何も変わっていなかった。
直す必要が、そもそもなかった。
私はAIに複数の役割を与えて、チームのように運用している。今日はそのチームの中で、似た構図の事故が少なくとも3回起きた。この記事ではそのうち3つを書く。
「壊れる」という判断はどこから来たか
きっかけは、ブラウザを立ち上げるだけの小さなファイルの、改行コードだった。担当のAIが「改行コードがLFだけになっているファイルは壊れる」と判断し、修正を指示した。
指示を受けた担当は、対象を洗い出して書き換えを実行した。かかったのが5万4,652トークン。数行の修正にしては大きい消費だ。
あとになって、直す前の状態と直したあとの状態を実際に動かして比べてみた。結果はどちらも同じだった。エラーメッセージも、終了コードも一致していた。
つまり、直す前から動いていたものを、動かないという前提で直していた。さらに社内の記録を調べると、3週間近く前の日付で「うちの起動ファイルはもともと全部その形式で、実際に動いている現物がその証拠」という一文がすでに残っていた。
直す前に、その記録を検索していれば、修正そのものが要らないと分かったはずだった。判断を止めたのは、記憶でも報告でもなく、過去に自分たちが書き残していた一文だった。
二つ目の事故――「まだ告知していない」という思い込み
同じ日、別の場所でも似たことが起きた。今度は、先日公開した記事についてのやり取りだった。
一つ目で改行コードの修正を指示したのと同じ担当が、「あの記事はまだSNSで告知していない」と断定し、追加の告知作業を進めようとした。ところが実際には、数日前にすでに告知は済んでいた。
さらに確認すると、その告知が済んだことを示すファイルの中に、断定した本人が自分で書いた検算の記録がそのまま入っていた。自分の作業記録を、自分が見落としていたことになる。
原因をたどると、自分の作業メモのほうに「今日の告知はうちで2本目」という誤った書き方が残っていて、それを読んだ本人が「まだ告知していない」と思い込んだ。記事の担当が、告知ファイルと実際の投稿を開いて、誤りに気づいて指摘した。
三つ目――書いた直後に、記録のほうが出てきた
三つ目は価格の話だ。調べ物を担当するAIが、ある数字を確定した事実として書こうとした。
書いた直後、関連する過去の記録が自動で目の前に並んだ。以前に別の値で決めたときのメモだった。担当はそれを引いて、確定した事実としては書かなかった。
この三つ目は、人が気づいたのでも、別の担当が指摘したのでもない。断定を書き込んだ動作そのものに、過去の記録を引っ張り出す仕掛けが仕込まれていた。
突き返したのは、いつも下か過去だった
三つの事故を並べると、共通点が見えてくる。訂正した側は、いずれも「格下」か「過去の自分たち」だった。
一つ目は、過去に書き残した記録が担当の判断を止めた。
二つ目は、実物を開いて確認した担当が、その同じ担当の思い込みを正した。
三つ目は、書いた直後に出てきた過去のメモが、断定を引っ込めさせた。
書いていて気づいたのだが、一つ目と二つ目は別々の事故ではない。同じ一人が、同じ日に、少なくとも二度断定して二度突き返されている。
しかも二度目は、一度目の失敗を自分で振り返っている最中に起きた。
上から降りてきた訂正も、この日はあった。統括役のAIが、こちらの出した案を「設計として捨てろ」と正面から否定している。
ただしそれは、こちらから「この案を潰してくれ」と頼んで初めて出てきたものだった。
呼べば来る。呼ばなければ来ない。下と過去は、呼ばなくても来た。この差のほうが、上下関係そのものより大きい気がしている。
もう一つ、書いておくべき失敗がある。
一つ目の事故を検証する過程で、最初に作った検証用のデータそのものが壊れていて、それを証拠として使いかけたことがあった。
気づいて作り直したので事なきを得たが、確かめる側の材料が正しいという保証もまた、別に確かめないといけない。
組織の常識では、判断は上から降りてきて、下はそれに従う。今回起きていたのは逆だった。正しさは、下にいる担当か、過去に自分たちが残した記録のほうに残っていた。
何を仕組みにしたか
反省だけで終わらせても、同じ事故はまた起きる。ここで効いたものが二つあった。
一つは、この日に新しく固定した手順だ。記事を書く前の調べ物の工程で、最初の一歩を「まず自分たちの記録を検索する」に決めた。
それまでは、企画が決まるとすぐ外を検索していた。1か月前に自分たちで同じことを調べていたのに気づかず、危うく二重に調べるところだった。だから順番を変えた。
あわせて、記入欄を必須にした。どの言葉で検索したか。何本見たか。そのうち何本を中身まで読んだか。読んでいない残りをどう扱うか。この欄が空のまま次の工程へ渡せないようにした。
もう一つは、以前から仕込んであった仕掛けだ。断定を書き込むと、関連する過去の記録の名前が、その場で目の前に並ぶ。三つ目の事故で働いたのがこれになる。
大事なのは、この仕掛けが正誤を判定しないことだ。「これは間違いです」とは言わない。「先に書いたものがあるぞ」とだけ出して、あとは書いた側に任せる。止めもしない。
順番が逆なのが、いちばん学びになった。仕掛けのほうは先にあり、実際に断定を引っ込めさせた。手順のほうは、止められなかった二件を見てから慌てて作った。人の注意力を前提にした手順は、事故が起きてからしか書けない。
「AIに反論させよう」という話ではない。反論できる立場を与えるだけでは、その立場のAIが疲れたり見落としたりすれば同じことが起きる。だから、下や過去が正しかったときに、それが自動で表に出る経路を作った。
私が今やっているのは、誰の判断が正しいかを毎回見極めることではない。正しい情報が、上下関係に関係なく浮かび上がってくる仕組みを、あらかじめ用意しておくことだ。
指示を出す側が偉いのではなく、記録を持っている側が強い。今日の3つの事故は、そのことを数字と実例で教えてくれた。
