AIが賢くなるほど、俺の工夫は古くなる——そう思って、確かめた

Fable 5——期間限定で使える、今いちばん賢いモデルが、7月7日で枠を終える。その少し前から、Xには同じ話が流れていた。この賢いモデルが使えるうちに開発環境を作り込め、消える前に投資しろ。設定ファイルを配る人、モデルの使い分けを図解する人。みんな、その賢さを自分の環境に持ち出そうとしていた。

俺の関心は、その一つ手前にあった。ずっと引っかかっていたことがある。AIがこの速さで賢くなり続けるなら、俺がこれまで積み上げてきた工夫は、次のモデルが出るたびに古くなって、いずれ全部いらなくなるんじゃないか。だとしたら、今の工夫に時間をかけるのは無駄だ。

だから、一番賢いモデルが手元にあるうちに、それを使うことにした。自分の積み上げがもう古いのか、確かめてみたかった。

煽りを、公式ドキュメントで確かめた

Xで流れていた主張を一行にすると、こうだ。「賢さそのものは買うしかない。でも賢い振る舞いの型なら、ある設定を通して安いモデルへ移せる」。今のうちに賢いモデルで自分のやり方を固めて、あとは安いモデルに同じ振る舞いをさせればいい、と。

本当にそうなのかな、とは思った。振る舞いをコピーするだけで賢さが移るなら、それに越したことはない。俺は自分の環境をそれなりに作り込んできた。本当に移せるものなのか、公式のドキュメントで確かめた。

書いてあったのは、二つ。一つ、賢いモデルには指示を細かく書きすぎると、かえって品質が下がる。古いモデル向けに書いた細かい注意書きは賢いモデルでは邪魔になるから、消すことを検討しろ、と。二つ、あの"振る舞いの型"は、AIに渡す憲法ファイル（CLAUDE.md）にまとめる作法だと名指しされていた。移植の話は、それを別の設定に持ち込もうとしていた。

賢いモデルに指示を足していくのは、どうも向いていないらしい。賢いモデルほど、細かく指図するより、要点だけ渡して任せたほうがいい。公式の話が正しいなら、削る方向になる。ではどこをどれだけ削るのか。ここを自分で「いらない」と決めると、愛着や思い込みが混じる。だから、削るかどうかの判断は俺が下さず、Fableと、Fableが回す検証に任せた。俺は、それがどう出るかを見ている側だった。

自分の憲法を、消させにかかった

その検証は、別のAIにわざと反対意見をぶつけさせて、主張を潰しにかからせるやり方だ（以下、この役を反証役と呼ぶ）。Fableが、俺の憲法（AIに守らせたい作法を全部まとめた、グローバルの CLAUDE.md）を十一体の反証役に配って、全員に同じ読み方をさせた。「これは古いモデル向けの過剰な指示で、賢いモデルにはもういらないゴミだ。消せる条項を挙げて、消しにかかれ」。削除ありきで、十一体が別々に憲法を読んだ。

結果は予想と違った。純粋に消せる条項は、一つもなかった。全部が何かの役に立っていた。しかも、当たり前に見えた五つの条項——消しても困らないだろうと見えたもの——を、反証役はむしろ「これは要る」と押し返した。賢いモデルは放っておくと話が長くなり、頼んでいないことにまで手を出す癖がある。その五つは、ちょうどそれを押さえていた。たとえば「頼まれた範囲だけやる、勝手に広げない」という一条。当たり前に見えて、消せば賢いモデルが自分から仕事を広げ始める、と反証役は示した。当たり前のことほど、書いて守らせておく必要があった。

これが最初の答えだった。より賢いモデルに照らして、俺の積み上げは古くなっていなかった。消せると思って殺しにかかって、全部残った。

散らばったプロジェクトを、一つの席からそろえた

憲法が丸ごと残ったのは、二月から書き溜めた作法がまだ効いている、ということだった。その作法をどのプロジェクトでも効かせるには、フォルダの構成や進め方がそろっている必要がある。俺のプロジェクトは、二月からの間にやり方が変わって、端末ごとに構成も進め方もバラバラだった。だから、憲法を検分するのと並行して、プロジェクトのほうもそろえていった。端末を全部見ると、プロジェクトのフォルダは五十くらいあった。このままだと後で困る。その中の、まだ動かしている十八を、まず一日でひとつの共通の型にそろえた。

五十ものフォルダを一人で見て回るのは無理がある。ここで効いたのが、前に作っておいた道具（aiterm）だった。指令を出す席を一つ決める（俺の場合は設定用のプロジェクト）。そこにいる賢いモデルが、aiterm経由で、各プロジェクトのフォルダで動いているそのプロジェクト用のClaudeを呼ぶ。呼ばれた側は、そのプロジェクトの中身をちゃんと知った状態で作業する。遠くから中身を知らずに一括で書き換えると、たいてい壊す。各プロジェクトの担当が自分の担当の文脈を持ったまま手を動かすから、地に足のついた作業になる。

どのプロジェクトをどのAIに回すか。この振り分けは、指令席の賢いモデルに任せた。俺が渡したのは方針だけ。コストと使える回数を節約したいから、安いAIをいくつか使え、と（レビューはCodex、まとまった書き換えは別のAI、というふうに）。最初はうまく振れていなかった。そこで少しずつ要求を足して、うまくいくたびにその振り分け方を憲法ファイルに書き留めた。直しては書き留める、を繰り返して育てた。次に似た作業が来たとき、書き留めた分だけ最初から賢く振れる。この道具自体も、あとで同じ反証役にかけて、粗を一度洗っておいた。

途中でモデルが替わっても、止まらなかった

七月四日、賢いモデルを一日フルで動かして、ここまでの土台をだいたい組んだ。複数のAIの束ね方、プロジェクトの標準化、設定用のプロジェクト、道具のaiterm。翌五日、賢いモデルの枠が尽きた。そこから先は、いつものモデル（Opus）に替わった。

替わっても、作業は止まらなかった。残っていた仕上げを、いつものモデルがそのまま走り抜けて完成させた。最初から、どのモデルでも回るように作ってあったからだ。特定のモデルに縛られない作り方が、三つある。

一つ、モデルの名前を一箇所にしか書かない。「この役割には今いちばん強いモデルを使う」という対応表を一枚だけ持って、コードや掟には日付つきのモデル名を書かない。モデルが世代交代したら、その一枚を書き換えれば全体が追従する。

二つ、プロジェクトのフォルダを同じ型にそろえておく。設計の判断はここ、調べたことはここ、と置き場所が決まっているから、初めてそのプロジェクトに入ったAIが、どのモデルでも同じ場所を見て動ける。

三つ、一度踏んだ罠を覚えておく仕組みを持つ。同じ間違いを二度踏まないよう記録して引けるようにしてあるから、新しいモデルに替わっても、前のモデルが踏んだ罠をそのまま引き継げる。

どれも、特定のモデルの賢さに寄りかかっていない。賢いモデルを使える間に作る値打ちがあるのは、こういう、モデルが替わっても残る作りのほうだった。その証拠が、途中でモデルを替えても完成まで走れた事実だ。

掟は、摩擦で守らせた

仕組みをモデルに縛られないようにするのと同じ考えで、掟の守らせ方も変えた。作業を進めるうちに、自分のやり方に穴が出た。俺のAIは、全体を束ねる側なのに、本来は安いAIに振るべき決まりきった作業（テストを何本も書く、設定ファイルを作る）まで、自分の高い枠で抱え込むことがあった。決まった作業は安いAIに回して、束ねる側は判断だけに専念する。そう決めてある。決めてあるのに、言われないと守らない。

散文で「気をつけろ」と書くだけだと、守るのに意志の力が要る。意志は、放っておくと楽なほうへ負ける。守らせたい行動のほうを既定にして、サボるほうに手間を足すことにした。コードを書き始める前に、その作業を「自分でやる」「安いAIに振る」のどちらかに必ずラベルする。自分でやると決めるなら、その理由を一行書く。理由を書くのが面倒だから、既定の「振る」に自然と寄る。さらに、計画を承認した瞬間に、この作法を思い出させるメモが機械で差し込まれるようにした。

差し込まれるのは思い出させるメモだ。従うかどうかは、読む側のAI次第で、従わなければすり抜ける。作業前のラベルづけのほうは、まだ散文で書いてあるだけで、機械で発火させる所までは届いていない。ここが一番弱い。掟を仕組みに変える途中で、半分は仕組みになって、半分はまだ言葉のままだ。

前に、AIに「気をつけて」と書くのをやめて外側から補強した話を書いた（claudeに「気をつけて」を書くのを諦めて、外側から3つ補強した話）。今回の掟の仕組みは、その続きにあたる。

残ったもの

始める前の心配——AIが賢くなるほど自分の工夫は古くなる——は、この二日については起きなかった。積み上げた工夫は、より賢いモデルに照らしても、全部残った。組み上げた仕組みは、途中でモデルが替わっても止まらずに完成した。賢いモデルを使える間に新しく残ったのは、モデルより長生きする作りと、直しては書き留めて育てた振り分けのやり方だった。