TITLE

Claude Fable 5 を1日運用して分かったこと──「頂点に戻す」ではなく「検証の引き金」

投稿日：2026.07.03

復帰 ≠ 頂点復帰

まず確認から入ります。昨日の私は「頂点モデルとして常時使う設計には戻さない」と書きました。1日運用してみて、この判断は正しかったと言えます。ただし正しかった理由が、想定していたものと少し違いました。

私は当初、コストと拒否リスクを理由に用途を絞るつもりでした。しかし実際に使ってみると、絞り込みの本当の理由はコストではありませんでした。Fable 5 が力を発揮する場面は、日常的な実装や調査ではなく、すでに下した判断を疑わせる場面に集中していたのです。つまり「頂点に立たせて全部の判断を任せる」のではなく、「他のモデルが出した結論に、後から突っ込ませる」使い方の方が価値が出ました。これは事前には分からなかったことで、実際に動かしてみて初めて見えた輪郭です。

2段の敵対的レビューでも、揃って見逃した

今日いちばん書いておきたいのは、この発見の中身です。

私たちは判断の精度を上げるために、重要な設計判断には最初から2段のレビューを組んでいます。ひとつのモデルが判断を起草し、それとは別のセッションで、同じくらい能力の高いモデルが敵対的な立場からその判断をチェックする、という構成です。「1人で決めるより2人で見た方が漏れが減る」という、ごく普通の発想です。

直近の判断のひとつで、私たちはこの2段構成のレビューを、対外的に影響し得るツールのローンチ判断に対して実際に走らせました。起草したモデルも、それを敵対的にチェックしたモデルも、同じ水準の上位モデルです。両者は独立に、しかし同じ結論に達しました。結論自体は妥当なものでしたが、後から振り返ると、2人とも共通して見落としていた点がありました。特に重大だったのは2つです。ひとつは、何か異常が起きた時に処理を即座に止める緊急停止の手段が、設計に組み込まれていなかったこと。もうひとつは、扱うデータの保持期間や削除の経路、万一データが侵害された場合の通知手順が、どこにも定義されていなかったことです。どちらも、ローンチしてから気づいたのでは遅い種類の抜け漏れでした。

この2点を実際に見つけたのは、起草にも敵対レビューにも参加していなかった、さらに別のモデル(Fable 5)による単発の検証でした。2段の敵対的レビューという構成をもってしても抜けられなかった盲点を、視点を変えただけで拾えた。設計として知っていたことと、自分たちの判断が実際に穴を見逃す場面を見ることは、重みがまったく違います。

ここは正直に留保しておきます。この発見が Fable 5 という特定のモデルの能力によるものなのか、それとも単に「起草にも敵対レビューにも関わっていない、独立した視点を挟んだこと」自体の効果なのかは、まだ切り分けられていません。今の私の見立ては後者寄りです。だからこそ次の節で書く運用ルールは「Fable 5 を常時挟め」ではなく「独立した検証を挟め」という形にしています。

この1日の運用期間の中では、別の場面でも似た構図がありました。OS の権限設計に関わる技術判断で、上位モデルの推奨は一見合理的でした。しかしその推奨をそのまま実行していたら、実機では「エラーも出ないまま、直したはずの機能が無音のまま壊れる」という、気づきにくい形のバグを出荷するところでした。こちらは2段のレビューではなく単独の判断でしたが、それでも単発の検証によって、出荷の直前で撤回されています。

2つの事例に共通するのは、判断した本人が「もう十分検討した」「これは上位モデルの判断だから大丈夫」と確信している時ほど、その確信自体が盲点の温床になるということです。敵対レビューを2段重ねても、同じモデルの水準・同じ思考の枠組みの中にいる限り、その枠組みの外にある見落としには気づけません。盲点は定義上、内側からは見えないのだと、実地で確認した形です。

「上位モデルで十分」を GO でなく検証の引き金にする

この経験から、私たちは運用のルールを1つ具体化しました。

自分が「これは上位モデルの判断で十分だ」「消せば済む話だ」「実害はないはずだ」と確信している時、その確信こそを疑う対象にする、というルールです。ただし全ての判断にこれをやると、検証コストが判断コストを上回ってしまいます。線を引く基準は、判断が取り返しのつかない結果につながるか、プラットフォームの方針や外部への影響に関わるか、コンプライアンス上のゲートを伴うか、この3つのどれかに触れる場合に限定しています。先に挙げた2つの例で言えば、緊急停止とデータ削除経路の話はコンプライアンス上のゲートに、OS 権限の話はプラットフォームの方針にそれぞれ該当します。日常的な実装判断や、後から修正が効く設計には、この検証を挟みません。

「上位モデルが出した結論だから、もう一段検証しなくていい」という判断は、それ自体が検証すべき対象になります。この線引きは、1日運用しなければ言語化できなかったものです。

コストと、次に同じ盲点を拾うための仕込み

単発の検証にかかるコストは、1件あたりおおよそ0.2〜0.6ドルです。入力100万トークンあたり10ドル・出力100万トークンあたり50ドルという価格(昨日の記事で確認した通り)だけを見ると高く感じるかもしれませんが、この検証は判断の要点だけを渡す単発の呼び出しであって、実装作業のように大量のコードやログを読ませるわけではありません。だからこの桁に収まります。出荷寸前で盲点入りの判断を1件止められるなら、割に合う投資です。

ただ、同じ種類の盲点を見つけるたびに毎回この検証を呼んでいては、いずれコストも手間も膨らみます。そこで私たちは、今回捕捉した盲点を、そのまま再利用できる形に落とし込みました。対外的に影響し得る、あるいは機微なデータを扱うツールのローンチ判断では、次のような点を機械的に確認するチェックリストです。