Claude Fable 5.2への移行ガイド — 公式プロンプト指針の要点と実測で見る速度・コスト

はじめに

2026 年 11 月 9 日(米国時間)、Anthropic は Claude Fable 5.2 と Claude Mythos 5.2 を発表しました。Fable 5.2 は API の全顧客がすぐ使える最上位モデルで、価格は Fable 5.1 から 2 割下がり、生成速度は最大 3 割上がったとされています。

ただ、モデル ID を claude-fable-5-2 に替えるだけで移行は終わりません。同時に公開された公式の「Fable 5.2 へのプロンプト」ガイドには、以前のモデル向けに書いた指示が逆効果になる場面が具体的な数字付きで並んでいます。この記事では、仕様の変更点、プロンプト指針の要点、Claude Code での実測結果の 3 つを整理し、移行時に何を確認すればよいかをまとめます。

Fable 5.2 で何が変わったのか

公式ドキュメントによると、主な仕様は次のとおりです。

項目Fable 5.2Fable 5.1
入力 / 出力(100 万トークンあたり)$8 / $40$10 / $50
キャッシュ読み出し$0.20$0.25
コンテキスト1M トークン—
最大出力128K トークン—
既定の efforthigh—

Mythos 5.2 は同じ基盤モデルで、能力も価格も同じです。違うのはサイバーセキュリティと生物学の安全対策で、Mythos 5.2 は審査を通った組織だけが使えます。Fable 5.2 側は安全分類器が動き、該当するリクエストは stop_reason: "refusal" と拒否カテゴリ(cyber、bio など)を返します。The Next Web によると、誤ったブロックは Fable 5.1 より約 55% 減ったとのことです。

コードの修正が必要になる変更もあります。特に影響が大きいのは次の 2 点です。

  • プレフィックスチェックが全アカウントに適用: 以前のターン、system、tools を書き換えると、それ以降の thinking ブロックが無効になり、Messages API は 400 エラーを返します。Fable 5.1 では 2026 年 8 月 31 日以降に作られたアカウントだけが対象でした。
  • computer_20251124 ツールの廃止: Bedrock 以外では 400 エラーになり、computer_toolset_20260801 に置き換える必要があります。

会話履歴を独自に「整形」しているハーネスは、ここで最初につまずきます。公式は、履歴は追記のみにし、短くしたいときはコンテキスト編集やコンパクションを使うよう勧めています。

公式プロンプトガイドの要点

ガイドの中心にあるのは「Fable 5.2 は指示に忠実すぎる」という性質です。代表的な項目を見ていきます。

effort は引き継がず、測り直す

effort は low から max までの 5 段階です。公式は、能力の伸びの大部分は high で得られると説明しています。また、low のスコアが高い effort で動かした Fable 5.1 に近かったとも書いています。注意点は 2 つあります。high 以上では挨拶にも思考が走り、「熟考せず直接答えて」と書いても medium 以上では止まりません。また、effort は返答の長さをほとんど変えません。思考を減らしたいときはプロンプトではなく effort を下げ、長さを変えたいときはプロンプトで指示します。この 2 つは別々に調整するものと考えるのが正確です。

早期停止と「無言」への対策

low や medium で長いタスクを実行すると、残作業を列挙して止まることがあります。ガイドは「作業が残っている間は止まらない」旨の一文をシステムプロンプトに足す方法を示しています。Anthropic のテストでは、作業を残したまま終わるケースが約半分に減りました。その代わり、出力トークンは約 3 割増えます。

もう 1 つの癖は、ツール呼び出しが続く間にユーザー向けの文をほとんど書かないことです。原因がクライアント側にある場合もあります。thinking.display が既定の "omitted" だと、進捗更新が空で返るためです。ハーネスを変えられるなら、無言のステップを数えて「しばらく報告していない」というリマインダーを差し込む方法が紹介されています。最長の無言区間がおよそ半分になったそうです。

コードの「所有者」を明示するかどうか

興味深いのがこの項目です。プロンプトでコードの所有者について何も書かないと、Fable 5.2 は既存の構造に追加するだけで、重複を統合しない傾向があります。「このコードベースはあなたのもの」という一文を入れると、試行の約半分で重複を統合しました。書かない場合は 1 割未満です。代わりに出力トークンは約 1.5 倍になり、頼んでいない変更も増えます。バグ修正以外のタスクでは 6〜10 回に 1 回、既存機能の挙動が変わりました。

つまり、この一文は「リファクタリングを任せる」スイッチとして働きます。変更を最小にしたい保守案件では入れない、と使い分けるのがよいでしょう。ガイドによると、「ついでのリファクタ禁止」と別の場所に書いても、所有権の一文の効果は打ち消せません。

蓄積した慎重さを掃除する

エンジニアにとって最も効くのはこの項目かもしれません。メモリ、メモ、エージェントファイルに溜まった「決して〜しない」系の注意書きに、Fable 5.2 は忠実に従います。古い「再試行しない」メモが 1 件あるだけで、本来すべき再試行が約 10 回中 4 回に減りました。「もっと自由に動いて」と言っても変化はありませんでした。効いたのは、例外をルールそのものの中に書くことです。別の行に「承認済みのステップは実行してよい」と書いても、実行率はほとんど変わりませんでした。

実測ではどうだったか

Qiita では、Claude Code 2.1.321 で Fable 5.2、Fable 5.1、Opus 5.5 を比べた記事が公開されています。4 課題を各モデル 3 回ずつ、effort medium で実行した計 36 回の計測です。結果(中央値)は次のとおりでした。

Fable 5.2Fable 5.1Opus 5.5
所要時間24.1 秒31.8 秒34.6 秒
1 回の推定費用$0.290$0.380$0.177
テスト通過全問全問全問

所要時間は Fable 5.1 より約 2 割短く、費用は約 3 割安くなりました。一方で、費用は Opus 5.5 の約 1.6 倍です。課題は易しめで、3 モデルとも正答率に差はありません。著者の提案は、日常の小さな仕事は Opus 5.5 のまま、待ち時間を減らしたいときに Fable 5.2 を使い、Fable 5.1 の利用分は乗り換える、という使い分けです。「難しい仕事で強い」という公式の主張は、この計測の範囲外です。

難しい仕事の例としては、公式ブログが 1,000 体の Fable 5.2 エージェントでフェルマーの最終定理を Lean で形式化した実験を報告しています。前回は 11 日かかった作業が約 29 時間で終わり、出力トークンは約 3 分の 1 でした。ブログが詳しく書いているのは、モデルの性能よりも安全設計の方です。各エージェントにネットワークのない VM を割り当て、連絡手段は共有 DB と Git だけに絞り、全ツール呼び出しを LLM 分類器で監視しました。マルチエージェントを本番で動かす人には、ハーネス設計の参考資料として読む価値があります。

エンジニアへの影響 — 移行チェックリスト

公式ガイドの推奨順序に、実務上の注意を加えると次のようになります。

  1. effort を明示的に high にして評価し、medium と xhigh とも比べる。 Fable 5.1 の設定値は流用しない。
  2. システムプロンプト、スキル、CLAUDE.md、メモリを棚卸しする。 「サブエージェントに回す」常設指示、プロンプト内のトークン予算、「考えすぎない」指示、古い禁止事項を削るか、効果を測り直す。
  3. 履歴を書き換えるハーネスを点検する。 400 エラーが出る前に、追記のみの構成か、コンパクションへの置き換えを検討する。
  4. 最も長いエージェントタスクを流して症状を記録する。 早期停止、不要な承認待ち、無言、過剰な委任を確認し、ガイドの対策を 1 つずつ当ててトークン増加と一緒に評価する。

Claude Code を使っているだけの場合は、会話履歴の管理を Claude Code が担うため、公式の移行ガイドによれば、履歴の書き換えに関わる変更の影響は受けません。それでも、自分の CLAUDE.md やメモリに溜まった注意書きは、Fable 5.2 では以前より強く効きます。モデルを切り替える前に一度読み返しておくと安全です。

まとめ

  • Fable 5.2 は Fable 5.1 より価格が 2 割安く、生成は最大 3 割速い。ただし Opus 5.5 よりは高い。
  • プレフィックスチェックの全面適用と computer use ツールの更新は、コード修正が必要な変更。
  • 指示への忠実さが増したため、古い注意書きや「考えすぎない」指示がそのまま足かせになる。
  • 所有権の一文、完了を促す一文、進捗リマインダーは、効果とトークンコストを測りながら 1 つずつ導入する。

モデルの世代が進むほど、性能差より「溜まったプロンプト資産の掃除」が移行コストの中心になります。Fable 5.2 の公式ガイドは、その棚卸しの手順書として読むのがよいでしょう。

ソース