Claude Fable 5を使ってみた——Mythos級の思考力と、財布に刺さるコストの話
はじめに
つい先日、Anthropic から Claude Fable 5 がリリースされました。「Mythos 相当」と言われているモデルです。
Mythos というのは、Anthropic が Opus の上に置いた新しいモデルティアのことで、これまで一般には提供されていませんでした。Fable 5 は、その Mythos クラスの能力に安全対策を加えて一般提供できるようにしたモデル、という位置づけです。モデル ID は claude-fable-5 で、Claude Code からもそのまま使えます。
「Opus の上」と聞くと身構えますが、毎日 Claude Code を使っている側として気になるのは結局2つだけです。本当に賢くなったと体感できるのか、そしていくらかかるのか。この記事では、実際にこのブログのコードベースをレビューさせてみた体験を軸に、この2点を正直に書きます。
結論を先に言うと、「深く考える力は確かに上がった。ただし常用するモデルではない」です。
実際に使ってみた——コードレビューで体感した「深さ」
新モデルの評価で一番わかりやすいのは、自分がよく知っているコードをレビューさせることだと思っています。自分のコードなら、指摘が的を射ているか、浅いか深いかを自分で判定できるからです。
そこで、このブログ（Next.js 16 + 静的エクスポート構成）の lib/ scripts/ components/ を Fable 5 にレビューさせてみました。出てきた指摘の中で「これは Opus 4.8 では出てこなかったタイプだな」と感じたものを2つ紹介します。
指摘1: OG画像生成の「リスト漏れ」と「エラー握りつぶし」の合わせ技
このブログでは、ビルド時にツールページごとの OG 画像を生成するスクリプトを回しています。Fable 5 はここで、
- OG 生成スクリプト内のツール一覧に、後から追加した5ツールが含まれていない
- 各ツールページのメタデータは存在しない画像パスを参照している（つまり SNS シェア時に画像が出ない）
- しかもスクリプト末尾が
main().catch(console.error)なので、生成に失敗しても exit code 0 で postbuild が成功扱いになり、誰も気づけない
という3点をつなげて指摘してきました。個々の事実は grep すれば見つかるレベルですが、「ツール一覧が4ファイルに重複定義されていて、その不整合が既に本番で実害になっている。さらにエラーが握りつぶされているから今後も気づけない」という因果のつながりとして報告してきたのが印象的でした。実際に public/og/ を確認したら、本当に5ツール分の PNG が存在しませんでした。
指摘2: 過去のバグ修正コメントを読んで「同じバグが再発する経路」を見つけた
もっと驚いたのはこちらです。タグをスラッグに変換する tagToSlug という関数があり、マッピング表に無いタグは toLowerCase() + 空白置換のフォールバックで変換しています。
Fable 5 はこのフォールバックに対して、「マッピング表のコメントに『マッピングが無いとスラッグから元のタグ名に戻せず、タグページのフィルタが0件になり常に noindex 扱いになっていた』という過去のバグの記録がある。フォールバック経路で生成されたスラッグは逆引きマップに載らないので、新しいタグを追加した瞬間に、この記録されている過去のバグがそのまま再発する」と指摘してきました。
つまり、コード中のコメントを「過去にこういう障害があった」という歴史情報として読み、現在のコードにその障害が再発する経路が残っていることを突き合わせたわけです。ついでに「タグ名に / が入ると除去されずルートが壊れる」というエッジケースも添えてきました。
この「コメントを歴史として読む」「修正の意図と現在の実装の矛盾を突く」タイプの指摘は、Opus 4.8 のレビューでもゼロではありませんでしたが、頻度と精度が明らかに違う、というのが率直な体感です。
規模の大きいコードベースでも試してみた
ここまで読んで、「このブログは記事数十本・コンポーネント十数個の小さなサイトだから、その規模なら大した差は出ないのでは」と思った方もいるはずです。私も同じことを思ったので、詳細は書けませんが、業務で関わっている実務レベルの規模のコードベースでも同じようにレビューを実施してみました。複数のモジュールが絡み合い、長い変更履歴と人の入れ替わりを経た、層の厚いコードです。
守秘の関係で具体的な指摘内容には触れられませんが、傾向ははっきりしていて、規模が大きいコードベースほど差を感じやすいというのが結論です。理由はおそらく単純で、
- 小さなコードベースは文脈の総量が少なく、Opus 4.8 でも全体を見渡せてしまうため、差が縮まる
- 規模が大きくなるほど、「モジュールをまたいだ影響の追跡」「過去の修正の意図と現在の実装の矛盾」「コードベース内の暗黙の規約からの逸脱」のような、深く長く考え続けないと拾えない指摘の比率が増える
という構図だからです。Fable 5 の強みは思考の深さと持続力なので、文脈が深いコードほどその強みが乗ります。逆に言えば、このブログのような小規模サイトは Fable 5 にとって最も差を見せにくい土俵で、それでも前述のような差が出た、と捉えてもらうのが正確だと思います。実務規模のコードを持っている人ほど、お試し期間中に自分のコードで一度レビューさせてみる価値があります。
体感のまとめ
深いところまで見る能力、考える能力は、体感でも確かに高くなったと思います。特にコードレビューについては、Opus 4.8 より高い精度のレビューができていることが、上記のような具体的な指摘からわかります。
ただし正直に書いておくと、同じ処理を両モデルにやらせて並べて比較する、という厳密な検証まではやっていません。同一プロンプト・同一対象で Opus 4.8 と Fable 5 のレビュー結果を突き合わせればもっとはっきりするはずですが、そこまでのコストはかけていない、というのが実情です。あくまで「毎日使っている人間の体感差」として読んでください。
コストの話——消費量はかなり激しい
良い話の後は財布の話です。Fable 5 の API 料金は以下の通りです。
| モデル | 入力（/1Mトークン） | 出力（/1Mトークン） |
|---|---|---|
| Claude Fable 5 | $10.00 | $50.00 |
| Claude Opus 4.8 | $5.00 | $25.00 |
| Claude Sonnet 4.6 | $3.00 | $15.00 |
Opus 4.8 のちょうど2倍です。しかも単価だけの問題ではなく、Fable 5 は深く考えるぶん思考に使うトークン自体も多くなる傾向があるので、体感のコスト消費はかなり激しくなりました。Claude Code の利用上限（レートリミット）への到達も明らかに早いです。
このコスト感を踏まえると、使い方は自然と決まってきます。
- 常時使用には不向き。日常の小さな修正、定型作業、ドキュメント更新などは Opus 4.8 や Sonnet で十分
- よく考えてほしい時に切り替えて使う。コードレビュー、設計判断、原因が掴めないバグの調査など
個人的に一番ハマると感じているのは、それなりの規模の計画を立てるときです。Claude Code の plan mode で Fable 5 を使うと、計画段階で考慮漏れやリスクを深く洗い出してくれるので、「計画は Fable、実装は Opus」という分担がコストと品質のバランスとして良さそうだと感じています。
お試し期間と、CLAUDE.mdに書くべきかどうか
ここが今回一番伝えたい実務的な注意点です。
Fable 5 は現在、2026年6月22日までのお試し期間中で、Pro / Max / Team およびシート制 Enterprise プランの利用者は追加費用なしで使えます。問題はその後です。Anthropic の案内によると、6月23日以降はプラン枠から外れ、継続利用には usage credits、つまり API 料金準拠の従量課金が必要になります。
「plan mode のときは Fable 5 を使う」のような運用をするなら、CLAUDE.md やプロンプトにそう書いておけば自動化できます。それ自体は良いアイデアだと思います。ただし、更新が手間な人は、CLAUDE.md のような永続的な設定ファイルにまでは書かない方がいいというのが私の意見です。
理由は単純で、お試し期間が終わった後も設定ファイルにモデル指定が残っていると、気づかないうちに従量課金が発生してしまう可能性があるからです。前述の通り Fable 5 の従量課金は Opus 4.8 の2倍の単価です。「プラン内で使い放題のつもりが、いつの間にかクレジットを消費していた」というのは一番避けたい事故です。6月22日を過ぎたら設定を見直す、とカレンダーに入れられる人だけが md に書く資格がある、くらいの温度感でいいと思います。
私自身は、当面はセッション単位で /model コマンドから手動で切り替える運用にしています。手間ですが、課金境界をまたぐ時期に自動化を仕込むのはリスクの方が大きいと判断しました。
それでも、動かせるうちに動かすことをおすすめしたい
コストの注意点を長々と書きましたが、最後に逆のことを言います。お試し期間中だからこそ、動かせるうちに動かしておくべきです。
理由は2つあります。
1つ目は、追加費用なしで Mythos 級のモデルを自分の実タスクで評価できる機会は、この2週間しかないからです。6月23日以降に「自分の用途で Fable 5 は課金に見合うのか」を判断しようとすると、その検証自体に従量課金がかかります。判断材料はタダで集められるうちに集めておくのが合理的です。
2つ目は、モデルの上限を知っておくと、下位モデルの使い方も上手くなるからです。Fable 5 のレビューを見た後だと、「この種の指摘は Opus でも引き出せるはずだ」とプロンプトの改善点が見えてきます。今回のコードレビューで言えば、「コード中のコメントに記録された過去の障害と、現在の実装の整合性を確認して」という観点は、明示的に指示すれば Opus 4.8 でもある程度引き出せそうです。上位モデルの挙動は、下位モデルへの良いプロンプトの教材になります。
まとめ
- Fable 5 は Mythos 級の能力を一般提供向けにしたモデルで、深く考える力は体感でも確かに向上している。特にコードレビューでは、コメントに記録された過去のバグの再発経路を突くような、Opus 4.8 より一段深い指摘が出てきた
- 実務レベルの規模のコードベースでも試したところ、規模が大きいほど差を感じやすい。深く考え続けないと拾えない指摘の比率が増えるためで、大きなコードベースを持っている人ほど試す価値がある
- ただし厳密な比較検証まではしておらず、あくまで日常利用での体感差として受け取ってほしい
- コスト消費はかなり激しい。API 単価は Opus 4.8 の2倍で、常用には不向き。よく考えたいタスク、特に plan mode での計画立案に絞って使うのが良さそう
- お試し期間は 2026年6月22日まで。それ以降は従量課金になるため、CLAUDE.md にモデル指定を書き残すのは「期限後に見直せる自信がある人」だけにしておくのが安全
- とはいえ、追加費用なしで試せるのは今だけ。動かせるうちに、自分の実タスクで動かして判断材料を集めておくことをおすすめしたい
次のモデルが出る頃には「Fable が日常、Mythos 級が特別」という構図になっているのかもしれませんが、今はまだ「特別な道具を借りられる2週間」です。せっかくなので使い倒しましょう。