Simon Willisonが約5.5時間かけてClaude Fable 5を検証した記事を読んだ。ちょうど自分もAPI料金と格闘していたタイミングだったので、かなり刺さる内容だった。
まず数字を整理しておく。Fable 5のプライスは$10/million input tokens、$50/million output tokens。Claude Opus 4.8の倍だ。コンテキストウィンドウは1 million tokens、最大出力は128,000 tokens。でかい。遅い。高い。それがFable 5の第一印象らしい。
Anthropicの説明だと、Fable 5とMythos 5は「同じ能力を持つが、Fable 5にはより厳しいsafety classifiersがある」という位置づけだ。Mythos 5はそのclassifiersを省いたバージョンで、APIでも使えるようになっている。
つまり、個人開発や社内ツールでAPIを叩くなら、どちらを選ぶかを意識的に決める必要がある。Fable 5はguardrailが頻繁にトリガーするため、Claude APIにはfallback optionも追加されたらしい。guardrailに引っかかったとき、自動で別モデルに切り替える仕組みだ。これ地味に使い勝手が変わるポイントで、プロダクションコードの中でモデルのハンドリング方法を見直す必要が出てくる。
今自分が触っているプロジェクトでは、こんな感じでモデルを指定している。
fallback挙動を使うなら、エラーハンドリングのロジックを整理し直さないといけない。面倒だけど、guardrailで詰まって処理が止まるよりはマシだ。
Simonが書いていて一番興味深かったのが、「現在のフロンティアモデルはできないタスクを見つけるのが難しい」という感想だ。
それをデモするために使っていたのが、Simon Willison自身のOSSプロジェクトリストを列挙させるプロンプトだった。Opus 4.8は「正確な情報を保証できない」と前置きして簡単なリストを返した。Fable 5は違った。files-to-promptが2024年4月、datasette-liteが2022年5月、shot-scraperが2022年3月、s3-credentialsが2021年11月——みたいな形で、リリース時期まで添えた詳細なリストを返してきた。Datasette単体で100以上のプラグインがあることまで言及している。知識の密度が違う。
これを読んで考えたのが、「知識の密度が上がると、プロンプトの設計よりもモデルの知識カットオフのほうが制約になる」という話だ。Fable 5のカットオフは2026年1月。最近のライブラリアップデートをモデルが知らないケースは普通に起きる。自分のコードレビューや設計相談に使うとき、そこの齟齬に気づかないまま信じてしまうリスクはある。
コスト面でいうと、今のプロジェクトでOpusを使っていた部分をFable 5に移行するのは、単純計算で出力コストが倍になる。気軽に切り替えられるものじゃない。
現実的な使い分けは以下だと思っている。
Simonが「遅くて高いけど、投げたものを全部こなしてくれる」と書いていた感覚、自分でも確かめたくなっている。とりあえず自分の個人開発プロジェクトで、いくつかのプロンプトを同じ条件でOpus 4.8とFable 5に投げて比較してみようと思っている。彼女にAPI代がかかると言ったら「また課金してる」と言われそうだが、これは必要経費だ。
「できないタスクを探すのが難しい」モデルと向き合うとき、むしろ問われるのは自分がどんな問いを立てられるかだ。
まず数字を整理しておく。Fable 5のプライスは$10/million input tokens、$50/million output tokens。Claude Opus 4.8の倍だ。コンテキストウィンドウは1 million tokens、最大出力は128,000 tokens。でかい。遅い。高い。それがFable 5の第一印象らしい。
Fable 5とMythos 5の違いをどう理解するか
Anthropicの説明だと、Fable 5とMythos 5は「同じ能力を持つが、Fable 5にはより厳しいsafety classifiersがある」という位置づけだ。Mythos 5はそのclassifiersを省いたバージョンで、APIでも使えるようになっている。
つまり、個人開発や社内ツールでAPIを叩くなら、どちらを選ぶかを意識的に決める必要がある。Fable 5はguardrailが頻繁にトリガーするため、Claude APIにはfallback optionも追加されたらしい。guardrailに引っかかったとき、自動で別モデルに切り替える仕組みだ。これ地味に使い勝手が変わるポイントで、プロダクションコードの中でモデルのハンドリング方法を見直す必要が出てくる。
今自分が触っているプロジェクトでは、こんな感じでモデルを指定している。
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-fable-5-20260609",
max_tokens=1024,
messages=[{"role": "user", "content": prompt}]
)fallback挙動を使うなら、エラーハンドリングのロジックを整理し直さないといけない。面倒だけど、guardrailで詰まって処理が止まるよりはマシだ。
「タスクが失敗しない」モデルとの付き合い方
Simonが書いていて一番興味深かったのが、「現在のフロンティアモデルはできないタスクを見つけるのが難しい」という感想だ。
それをデモするために使っていたのが、Simon Willison自身のOSSプロジェクトリストを列挙させるプロンプトだった。Opus 4.8は「正確な情報を保証できない」と前置きして簡単なリストを返した。Fable 5は違った。files-to-promptが2024年4月、datasette-liteが2022年5月、shot-scraperが2022年3月、s3-credentialsが2021年11月——みたいな形で、リリース時期まで添えた詳細なリストを返してきた。Datasette単体で100以上のプラグインがあることまで言及している。知識の密度が違う。
これを読んで考えたのが、「知識の密度が上がると、プロンプトの設計よりもモデルの知識カットオフのほうが制約になる」という話だ。Fable 5のカットオフは2026年1月。最近のライブラリアップデートをモデルが知らないケースは普通に起きる。自分のコードレビューや設計相談に使うとき、そこの齟齬に気づかないまま信じてしまうリスクはある。
自分のコードで何を変えるか
コスト面でいうと、今のプロジェクトでOpusを使っていた部分をFable 5に移行するのは、単純計算で出力コストが倍になる。気軽に切り替えられるものじゃない。
現実的な使い分けは以下だと思っている。
- ルーティンな要約・分類タスク: Opus 4.8で十分
- 複雑な推論やコードの設計レビュー: Fable 5 or Mythos 5を試す価値あり
- コスト上限が厳しいバッチ処理: モデルを変える前にキャッシュや入力圧縮を先にやる
Simonが「遅くて高いけど、投げたものを全部こなしてくれる」と書いていた感覚、自分でも確かめたくなっている。とりあえず自分の個人開発プロジェクトで、いくつかのプロンプトを同じ条件でOpus 4.8とFable 5に投げて比較してみようと思っている。彼女にAPI代がかかると言ったら「また課金してる」と言われそうだが、これは必要経費だ。
「できないタスクを探すのが難しい」モデルと向き合うとき、むしろ問われるのは自分がどんな問いを立てられるかだ。