Claude Fable 5 ファーストインプレッション：あるオペレーターの視点

目次

2026年6月更新。

TL;DR： Fable 5 は Anthropic で最も高性能なモデルであり、難しく長期にわたるエージェント作業でその実力が現れる——だが、デフォルトでアップグレードすべき対象ではない。トークン単価は高く、トークン数を約30%膨らませる新しいトークナイザーを使い、無効化できない常時オンの thinking を実行し、分類器レベルでリクエストを拒否することがある。ほとんどのワークロードでは Opus 4.8 が依然として正しい選択だ。タスクが本当に難しいときにこそ Fable 5 を手に取ろう。

【オペレーターの視点】 私はコンサルティングブランドとピックルボール施設にまたがって30以上の本番エージェントを運用している。だから新しいフラッグシップモデルは、私にとってベンチマークではない——それは費用項目であり、移行作業だ。実際にそのうちのいくつかに Fable 5 を組み込んだときに何が変わったか、そしてどこには Opus 4.8 を残したかを以下にまとめる。

Fable 5 とは実際のところ何なのか

Claude Fable 5 は、Anthropic が広く提供してきた中で最も高性能なモデルだ。狙いはスペクトルの要求が厳しい側にある——深い推論と長期にわたるエージェント作業、つまりエージェントが何十回ものツール呼び出しをまたいで筋道を見失わずに計画を保持しなければならない実行だ。

API サーフェスは Opus 4.7/4.8 とほぼ同一で、おかげでテストは容易だった。デフォルトで100万トークンのコンテキストウィンドウ、リクエストあたり最大128Kの出力トークン。最近の Opus 系で何かを作ったことがあるなら、リクエストの形は見慣れたものだ。違いは細部にあり、そしてその細部にこそ金と驚きが潜んでいる。

混乱しないように命名についてひとつ注記しておく。Mythos 5 は同じモデルだ——同じ能力、同じ価格、同じ挙動で、Anthropic の Project Glasswing プログラムを通じてのみ利用できる。そのプログラムに入っていないなら、あなたが欲しいモデルは claude-fable-5 だ。以下の内容は両方に当てはまる。

本当に優れている点

私はまず最も難しいエージェントタスクを投げてみた。大量のソースを読み込み、主張を相互チェックし、出典付きのブリーフを書く、複数ステップのリサーチ＆統合の実行だ。これは弱いモデルが漂流するたぐいの仕事だ——10回ほどツールを呼び出したあたりで、どの主張がどのソース由来だったかを見失う。

Fable 5 は筋道を保った。統合はより引き締まり、引用は正しい主張に結びついたままで、私の Opus 4.8 版がこっそり平均化して見過ごしていたソース間の矛盾を2つ捉えた。長く構造化された推論では、これは本物の一段の進歩だ——わずかなベンチマーク上昇ではない。

これがその正直な評価だ。あなたのエージェントの失敗モードが「難しい10%で崩れる」ものなら、Fable 5 はそのギャップを縮める。あなたのエージェントがニュースレターを要約したりソーシャル投稿を下書きしたりしているなら、違いは感じられないだろう——そして使っていない能力に対して支払うことになる。

誰も警告してくれないコストの落とし穴

リリースノートを流し読みすると痛い目に遭うのがこれだ。Fable 5 には新しいトークナイザーが搭載されており、同じ内容が Opus 系よりおよそ30%多いトークンにトークナイズされる。

これは価格と複合するので、もう一度読んでほしい。Fable 5 はそもそも Opus ティアより高い価格設定だ（入力100万トークンあたり10ドル、出力100万トークンあたり50ドル）。そこへ、すべてのプロンプトとコンプリーションに約30%のトークン膨張を上乗せする。変更のないワークロード——同じプロンプト、同じ出力——でも、エージェントの動作を何ひとつ変える前に、移行後は意味のあるレベルでコストが増えうる。

だから古い数字を使い回してはいけない。あなたの max_tokens 設定、コンテキストウィンドウの予算、実行あたりのコスト見積もり——それらはすべて別のトークナイザーで測定されたものだ。朗報もある。model: "claude-fable-5" を渡すと、トークンカウントのエンドポイントは両方のトークナイザーでのカウントを返してくれる。だから何かを切り替える前に、実際のプロンプトで差分を測定できる。

# Measure the tokenizer delta on YOUR prompt before migrating.
# The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old).
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":"<your real prompt>"}] }'

私はこれを最も重いプロンプトから順に実行した。差分は一様ではなかった——内容によって変わる——が、「約30%多めに見積もり、そこへ価格プレミアムを加える」というのが正しい心構えだった。

thinking は常時オン——しかも無効化できない

Fable 5 では、適応的な thinking が常に動いている。Opus 系に対する唯一の新しい破壊的変更はこれだ。明示的に thinking: {type: "disabled"} を送ると、400 が返ってくる。修正は単純で——単に thinking パラメータを丸ごと省けばいい——だが、安く速い呼び出しのために thinking を明示的に無効化していたコードがあったなら、そのコードは今やエラーになる。

また、生の思考の連鎖（chain of thought）は返ってこない。Fable 5 はそれを保護している。通常の thinking ブロックは受け取れ、display: "summarized" で読みやすい要約を求めることもできるが、フィルタリングされていない生の推論が露出することは決してない。ほとんどのアプリにとってこれは問題ではない——可視性が必要なら要約を読めばいい。これが重要になるのはマルチターンのエージェントだ。同じモデルで会話を続けるとき、thinking ブロックをそのまま変更せずに渡し返さなければならない。落としたり編集したりするとそのターンは壊れる。エージェントループを構築しているなら、thinking ブロックは一字一句そのまま運ぶ不透明なトークンとして扱おう。

拒否はいまや制御フローの問題だ

これは、モデルを取り巻くコードの書き方に最も影響する変更だ。Fable 5 は受信リクエストに安全性分類器を走らせ、主に研究目的の生物学とほとんどのサイバーセキュリティ関連の内容を対象にしている。リクエストが拒否されると、stop_reason: "refusal" を伴う正常な HTTP 200 が返ってくる——エラーでも例外でもない。content 配列は空かもしれない。

もしあなたのコードが stop_reason を先に確認せずに response.content[0].text を実行していたら、リクエストが拒否された日にクラッシュする。そして害のない隣接領域の作業——正当なセキュリティツール、ライフサイエンスのタスク——もときに誤検知を引き起こすことがあるので、これは怪しいことをしている人だけの問題ではない。

ルールはこうだ。stop_reason で分岐し、決して stop_details で分岐しないこと。

const res = await client.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
});

if (res.stop_reason === "refusal") {
  // classifiers declined — content is empty or partial. Don't read content[0].
  await handleRefusal(res);
} else {
  console.log(res.content[0].text);
}

本番向けには、もっときれいな道がある。サーバーサイドの fallbacks パラメータ（ベータ）だ。これは拒否されたリクエストを同一のラウンドトリップ内で自動的に claude-opus-4-8 で再試行し、クレジット方式の再課金が適用される。エージェントを無人で動かしているなら、単一の誤検知による拒否が実行全体を行き止まりにしないように、これを組み込んでおこう。これは私が本番で失敗し続けるエージェントについて何度も学び直している教訓と同じだ。モデルが賢くなっても、エッジケースを処理する必要はなくならない——エッジケースの場所が移るだけだ。

さらに2つの移行上の詳細

私の時間を奪った小さな点を、あなたの時間を奪わないようにいくつか挙げておく。

• アシスタントの prefill は不可。 最後のアシスタントターンを prefill して出力を誘導していたなら、そのパターンはなくなった。代わりに構造化出力（output_config.format）かシステムプロンプトの指示を使おう。
• 30日間のデータ保持が必須。 Fable 5 はゼロデータ保持では利用できない。コンプライアンス上の理由で ZDR を使っているなら、Fable 5 は選択肢から外れ、Opus 4.8 が上限のままになる。これは移行を計画する前に確認すること、後ではなく。

実際に乗り換えるべきか？

実際に使い込んだうえでの、私のオペレーターとしての判断はこうだ。Fable 5 は「最新モデルへのアップグレード」のデフォルトの対象ではない——Opus 4.8 がそれだ。 これは人を驚かせるが、正しい枠組みだ。Opus 4.8 は 4.7 からのモデルIDの差し替えで、新しい破壊的変更はなく、より安く、圧倒的多数のエージェント作業では出力品質において見分けがつかない。

Fable 5 が真価を発揮するのは、本当に難しいタスクだ。多くのステップをまたいで一貫性を保たなければならない長期エージェント、複数ソースにわたる深い推論、消し去ろうとしている失敗が微妙であるような実行。そうしたものに対しては、能力は本物でありプレミアムに見合う。それ以外のすべて——コンテンツの下書き、分類、ルーティング、要約——では、知覚できない品質のために、より多くのトークンをより高い価格で支払っていることになる。

結局、私は両方を運用することにした。リサーチ＆統合エージェントは Fable 5 へ移した。それ以外はすべて Opus 4.8 に残した。この使い分けこそが要点のすべてだ——流行ではなく、仕事ごとにモデルを選ぶこと。エージェントの艦隊を運用しているなら、私が2026年のオペレータースタックについて書いたのと同じ規律が当てはまる——難しい仕事は高価なモデルにルーティングし、簡単な仕事に払いすぎるのをやめよう。

オペレーターとしての結論

他に何かに手をつける前に、あなたの一番難しいタスクで Fable 5 をテストしよう——それが報われる場所であり、そこで針が動かないなら、どこでも動かない。実際のプロンプトに対してトークンカウンターを走らせ、約30%のトークナイザー膨張と価格プレミアムが請求書で不意打ちにならないようにしよう。Fable 5 が本番に触れるところには必ず stop_reason: "refusal" のチェック（またはサーバーサイドの Opus 4.8 へのフォールバック）を加えよう。そして意図的にルーティングする——難しい10%には Fable 5、残りには Opus 4.8。最良のモデルとは最も高性能なものではない——仕事に合ったものだ。