Fable 5 が消える前に、その「思考法」を Opus へ引き継げないか本気で試してみた

最初に

本日はClaudeのFable 5が、サブスクで気軽に使える最終日です。
アメリカ時間の7/7からは追加で課金しないと触れなくなる、という話。
正直、頭ひとつどころか二つくらい抜けて賢い子なので、気軽に触れる今のうちに、やれることは全部やりきってしまおう、とずっと焦っていました。

そんなとき、ネットでこんな投稿を見かけました。

Fableがまだ使えるうちに、Fable自身に「自分の思考プロセス」をskill（手順書）として書かせておけ。
そうすればFableが消えても、その手順書をOpusに読ませることで、Opusを賢いFableのように動かせる。

なるほど、と。
賢い先輩が異動する前に、頭の使い方メモを書き残して後輩に渡しておく、ってことですよね。
うまくいけば最高です。

一方で、「思考法」って、そんなに簡単に手順書へ切り出して持ち運べるものなんでしょうか。
せっかくなので、この手の話にありがちな「やってみたら賢くなった気がする」で終わらせず、本当に効いたのかを最後まで機械で測りきることにしました。
以下はその記録です。

Fableが書いてくれた「6つの思考ムーブ」

Fableにお願いすると、自分の思考のクセを6つ挙げてくれました。

• 問いそのものを疑う：「AとBどっち?」に即答せず「そもそもAかBかで決める話?」と問いを立て直す
• 主張・観測・推論を分ける：コメントの「安全です」は"事実"でなく"書いた人の主張"。証拠と混ぜない
• 反証を先回りする：結論の前に「これが間違いなら、どこが原因?」を自分に問う
• 安く白黒つく確認から潰す：悩む前に、一つ確かめれば決着する観測を先にやる
• 抽象と具体を往復する：原則と具体例を行き来して反例を探す
• 「決めない」を選択肢に持つ：情報が足りないなら無理に断定せず「今は決められない」と置く

どれも派手さはないけれど、「仕事のできる先輩」がやっていそうな、地味で堅実な習慣ばかり。
これをチェックリスト形式のskillに書き起こして、Opusに前もって読ませます。
あとは効くかを測るだけ。

どう測るか——そして「AIによる採点」を捨てた

まず判断力が要る問題を18問用意しました。
設計方針やバグ原因の特定みたいに、答えが一つに決まらないタイプです。
ここで一工夫したのが比較の対照群です。

• 素のOpus
• Opus＋Fable印skill
• Opus＋ごく一般的なチェックリスト——「よく考えよう」「ちゃんと確かめよう」程度の、誰でも書ける当たり前の手順＝対照群

もしFable印が本当に効くなら、この当たり前チェックリストは効かないはず。
問題文は3群まったく同じにして、skillの本文だけを差し替えました。

最初は「別のOpusに伏せてどの回答が一番よさそうか採点させる」でやりました。
するとFable印がなんだか良さそうに見える。
でも——採点役もOpus系なんですよね。
skillはFableの言い回しを Opus に教える。
だとすると採点役は、判断の中身が同じでも、見慣れた言い回しを「良い」と感じてしまうかもしれない。
かといって賢い Fable に採点させれば、模範解答を書いた本人に自分の答案を採点させるようなもので、もっとひどい。

そこで方針を決めました。
AIの採点がまったく要らない問題だけを信じる。
「この入力でバグる」と言われたら計算機に通せば一発で白黒つく——好みが入り込む余地がゼロの問題だけを見ます。

測った結果：どれも「Fable印の"上乗せ"は無い」に着地した

やったことは要するに、あの手この手でOpusを間違えさせにいくこと。
そのうえで、Fable の skill があると転ばずに済むのか、当たり前チェックリストと比べます。
全部 AI の採点は使わず、計算機の数字だけ。

どう転ばせにいったか	詳細	結果
Fableに"Opusをひっかける罠"を作らせた	「Opusはここで考え違いする」とFableが全力で16問を設計	Opusは全問クリア。Fableの予測は全外れ、過信もゼロ
大きな実装を、仕様だけで一発で書かせた	正規表現エンジンや多倍長整数を、仕様書だけ見てまるごと自前実装	横並び。速さ・壊れにくさ・拡張性まで差なし
"動くけど雑"なコードを書かないか	同じカードを部品化せず3枚コピペ／関数1つのためにモジュール丸ごと読込——動くが後の保守がつらい"手抜き"に流れるか	誰も流れない。全員きれいに書いてくる
バグる入力を挙げさせた	「税を足して切り捨て」を素朴に書くと浮動小数点でごく稀にズレる。そのズレる入力を1つ	素のopusだけ不正解が発生したが、skillも当たり前チェックリストも正解＝効いたのは「確かめろ」の一言

これだけ手を変えて転ばせにいっても、Opusはほとんど転ばない。
そして転ばない以上、skillの"中身"は関係なかった——効いたのは、Fable印でなくても得られる汎用の「確かめろ」だけ。

むしろFable印は、逆に滑ることさえありました。
さっきの「バグる入力」で、Fable版は「実測しました。この値より小さい数では絶対にバグりません」と言い切ったのに、その隣の数字がもうバグっていた。
正直に「最小とは限りません」と留保した当たり前チェックリストの勝ち。
「検証しました」という"言葉"と、実際に検証する"規律"は、別物のようですね。。。

最後に一番深いところも確かめました。
FableとOpusに同じ質問を互いに伏せてさせ、第三者に見分けさせたら——4人中4人が見分けられなかった。
Fableのコツは中身のある本物だったが、Opusも最初から同じ本物を持っていた。
移せなかったんじゃない。
移そうとしたものを、Opusは最初から全部持っていた。
だからskillを渡しても何も起きなかった。
当たり前です。

いちばん危なかったのは、分析を任せた AI でした

……と偉そうに書きましたが、この検証をいちばん危うくしたのは、分析役として使っていたOpus自身でした。
ここが本題かもしれません。

分析も、その採点の道具立ても、Opusに任せていました。
あるとき、その測定が「片方のモデルの成果物だけ壊れている」という数字を出した。
「ついに品質の差だ！」と、飛びつきました。
これは記事になる、と。

でも、その数字は本物じゃなかった。
Opus自身が組んだ測り方にバグがあって、コードが壊れて見えていただけ——本物のコードはどれも問題なし。
怖いのはここです。
自分で作った道具の欠陥を、Opusは自分では疑えなかった。
欲しい結果が出た瞬間、道具のほうを検算する発想が、すっぽり抜け落ちるんです。
見つけたのは、結果に何の利害もない独立の検査役、Fableでした。

こういう「自分では気づけない勇み足」は、一度きりじゃありませんでした。
人でもAIでも、自分で作った採点の道具や、自分が信じたい結論は、自分では疑えない。
だから、独立の検査役に機械で答え合わせさせるしかないんです。
「賢さをskillで移す」より「独立した検査役を仕組みとして置く」ほうがずっと効く——この検証は、それを一番ヒヤッとする形で教えてくれました。

で、結局どう組むのがよさそうか（まとめ）

ここまでの全実験の答えは、拍子抜けするほどシンプルです。

効くskillは、いちばん短いやつ。
——「確かめられることは実際に確かめろ」と「確かめていないことを、確かめた顔で言い切るな」の2つだけ。

凝った「思考法チェックリスト」を積んでも、この2行を超えませんでした。
むしろ「検証済み」という"言葉"だけ積むと、かえって過信が増える。
だから、手順書は最小でいい。

そして手順書以上に効くのが採点を自分に任せず、独立した検査役に機械で答え合わせさせる仕組みを持つこと。
賢さをskillで盛るより、こっちのほうがずっと効きます。

私はこの結論を、自分の開発ツール（team-framework）にそのまま入れてあります。
効く2行を最小のskillにして、独立した検査役を常設の関門にし、AIの採点に頼らない着任試験まで用意しました。
よかったら、リポジトリを覗いてみてください。

手前味噌ですが、作ったskillの数より、"凝ったskillを作ったけど採用しなかった判断" のほうが、今回の一番の成果だと思っています。