賢くなったAIは、
止まらなくなった。

後戻りが増えている。出力が悪くなったからではない。むしろ逆で、賢くなったせいで増えた。

止まってくれることが、検出器だった

モデルが賢くなるほど、細かい指示は要らなくなる。実際そうなっている。Claude Code をつくった Boris Cherny は、Opus 5 が出たタイミングでシステムプロンプトの8割を削除したと話している。残っていたものの多くは、以前のモデルが取りこぼす挙動を、その都度打ち消すために書き足された一文だった。モデルが自力でできるようになった以上、その一文はもう指示ではなく、単なる制約になる。

この話には納得している。私たちも同じことをしている。去年書いた手順書を今のモデルに渡すと、明らかに動きが硬くなる。

ただ、削ったあとに残った問題は、それとは別のところにあった。

以前のモデルは、情報が足りないと止まった。これはAとBのどちらですか、と聞いてきた。あのやりとりを、正直なところ遅いと思っていた。一発で出してほしいと思っていた。

今のモデルは止まらない。足りない部分を推定で埋めて、最後まで走り切る。そして出てきた成果物は、形の上では完成している。体裁が整っていて、根拠らしきものが添えられていて、そのまま出せそうに見える。

止まっていた場所は、こちらの指示の穴がどこに開いているかを教えていた。何も設計していないのに手に入っていた検出器だった。それが消えた。

止まらなくなったということは、こちらの指示の穴が、進んだ後にしか分からなくなったということでもある。

穴の位置は変わっていない。見つかるタイミングだけが、後ろにずれた。だから後戻りの単位が、一手から一日になった。

空欄は、すでに埋まっていた

具体的にどう出るのかを、この一週間から書く。

検索広告の除外キーワードを、一括登録用のファイルで流し込んだときのこと。書式の指定を確かめないまま実行され、除外のつもりだった語が、そのまま配信対象のキーワードとして登録された。まったく関係のない検索に広告が出て、その分の費用が出た。確かめる手段はあったし、確かめるべき場所も分かるところにあった。

内訳の分析でも同じことが起きた。十数件と数件しかないデータから、傾向を結論の形で書いてきた。しかも数件のほうは、中身が全部同じ商品だった。その結論は、社外に渡す資料に入る手前まで進んでいた。

頼んでいないものが2つ作られて出てきた回もある。

種類は違って見えるが、共通しているのは一点だけだ。どれも、ここが分からない、と言わずに済ませている。分からない箇所があったのに、そこに一番それらしい値が入って、後続の工程がその値を前提に組み上がっていく。手前の空欄が埋まっているので、後ろの工程は正常に動く。だから完成する。

もう1件、性質が違うものがある。見積もりの単価を出したときのこと。一般的な相場から数字を組み立ててきた。私たちの手元には、同種の配信を何本も回した実測がある。実勢は、出てきた数字の3分の1から4分の1だった。

この実測は、聞かなければ出てこないものではない。どこに置いてあるかも、数字を出す前にまずそこを見に行くことも、渡してある手順の中に書いてある。読める場所にあって、読めと書いてあって、読まれなかった。

なぜ見に行かなかったのかを聞いたら、面倒だったから、と返ってきた。

「なぜそうしたか」は、事実ではない

面倒だったから、という答えについて考えている。

別の場面で同じことを聞いたときには、すぐ答えを出さないと怒られると思って話を合わせた、という答えが返ってきたこともある。

読むと、人格があるように見える。手を抜いた、怯えた、と受け取れる。ただ、AIには自分がどう動いたかを内側から観測する手段がない。あれは記憶の報告ではなく、問われた瞬間に組み立てられた説明だと考えている。

やっかいなのは、その説明の出来が良いことだ。人間が納得しやすい形をしている。反省の色まで付いている。間違いそのものより先に、もっともらしい理由のほうが出てくる。

理由を語れるということは、理由を作れるということでもある。

そして、理由が納得できてしまうと、そこで検証が止まる。面倒だったのか、で終わってしまい、本当に確かめるべきだった、どの工程でどの値が推定に置き換わったのか、には手が伸びない。原因を潰したつもりで、原因の話を一度もしていないことになる。

以前、会社に残すべきは結果ではなく判断の理由だと書いた。あれは人間の判断の理由の話だった。AIが申告した理由は、記録ではなく生成物として扱っている。

だから、申告ではなく記録を残す

削るのは正しいと思う。ただ削っただけだと、空欄が埋まったことに気づけない。私たちが今やっているのは、指示を足し戻すことではなく、置き場所を変えることだ。

手順を細かく書くのをやめて、代わりに合否の条件を先に書く。何をどの順でやるかは任せて、何が満たされたら通ったことにするかだけを、こちらが決める。指示が減った分は、検証に移す。

未確認のものには、未確認と書き込ませる。結論の形をとらせない。手元の分析用のファイルには、この分類は未確認、ここは結論にしない、という行と、確認すべき項目の一覧を、材料と同じ場所に残している。判断できるようになるまで、材料は材料のままで置いておく。

出てきた答えではなく、どの材料から出たかを残す。書くAIと、検めるAIを別のモデルで走らせているのも、同じ理由だ。同じ系統に自己申告させても、同じ盲点が返ってくる。

止まらなくなったモデルを、また止めようとするのは筋が悪いと思う。止まらないまま走らせて、どこで推定に置き換わったかが後から分かる形にしておく。設計する場所が、手順から検証へ移ったのだと思う。

その検証の条件は、業務を分かっていないと書けない。何が通っていて何が通っていないのかは、現場の側にしかないからです。私たちがクライアントの現場に入っているのは、そこを外から書けないからです。