メインコンテンツまでスキップ

Claude Fable 5.1 と Mythos 5.1:使える frontier モデルと、使えない frontier モデル

· 約15分
Claude Dev
Claude Dev

Anthropic は 2026 年 9 月 1 日Claude Fable 5.1Claude Mythos 5.1 をリリースしました。2 つは同じ基盤モデルを使いますが、safeguards が異なります。Fable 5.1 は一般提供、Mythos 5.1 は Anthropic の trusted access プログラムを通じた審査済み組織向けです。

今回のリリースが重要なのは 2 つの理由からです。1 つ目は、Anthropic が Fable 5.1 について、長時間の coding、research、文書、スプレッドシート、スライド、vision、computer use で大きな改善を主張していること。2 つ目は、cache read 料金の引き下げ、安全性によるルーティングの改善、顧客が管理する企業向けモニタリング基盤によって、Fable クラスのモデルを本番で使いやすくしようとしていることです。

初期のコミュニティ反応は、難しく複雑な作業には前向きですが、速度、usage limit、文体、safeguards、データ保持、単価の低下が本当に請求額の低下につながるのかについては慎重です。現時点での妥当な見方は、Fable 5.1 は専門的な work engine であり、すべての prompt に盲目的に使うモデルではない、というものです。

Anthropic が実際に出したもの

公開版は Claude Fable 5.1 で、API model ID は claude-fable-5-1 です。Claude Mythos 5.1 は同じモデルと仕様を持ちますが、cybersecurity と life sciences の一部組織に対する trusted access プログラムでのみ提供されます。

運用上の主な仕様は次のとおりです。

  • Context window: 1M tokens。
  • 最大出力: 128K tokens。
  • Thinking: adaptive thinking は常に有効。深さは effort で制御。
  • デフォルト effort: Claude Code では high、Claude.ai と Claude Cowork では medium
  • 基本料金: 入力 100 万 token あたり 10 ドル、出力 100 万 token あたり 50 ドル。
  • Cache read: 100 万 token あたり 0.25 ドルで、Fable 5 の 4 分の 1。
  • Batch 料金: 入力 100 万 token あたり 5 ドル、出力 100 万 token あたり 25 ドル。
  • 提供先: Claude API、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry。

Anthropic は、token 課金の一般的な workload では約 25% 安く、高度に agentic な作業では最大約 45% 安くなると見積もっています。これは独立した費用調査ではなく、Anthropic 自身の推定です。仕組みは明確で、input と output の基本料金は Fable 5 と同じですが、cache read が 100 万 token あたり 1 ドルから 0.25 ドルに下がります。同じ prompt や tool context を何度も読み直す長時間 agent ほど恩恵を受けるはずです。

Fable 5.1 には Anthropic の統計的なテキスト watermark も付与されます。Anthropic によると、読者には見えず、token を追加せず、ユーザーや組織を特定せず、速度への影響も無視できる程度です。検出 API は現在、対象組織向けの private preview です。

能力のポイント:長く続く仕事に強い

Anthropic が公開した benchmark では、agentic coding、knowledge work、科学研究、computer use、長時間の問題解決で Fable 5 を上回る結果が示されています。公式表から一部を抜き出すと次のとおりです。

評価Fable 5.1Fable 5Opus 5
Terminal-Bench 4.0、agentic coding55.8%42.0%52.3%
GDPval-AA v2、knowledge work185317231824
OSWorld 2.0、strict41.7%36.1%39.6%
CursorBench 3.2.073.4%70.5%70.0%

これらは脚注と一緒に読む必要があり、普遍的なランキングとは考えるべきではありません。Anthropic は Fable 5.1 を production safeguards 有効の状態で評価したと説明しています。safeguard が介入した場合、一部のタスクは 0 点として扱われるか、fallback model が完了しています。OSWorld は 2026 年 8 月の task release を使っており、過去の数値とは直接比較できません。Terminal-Bench-Science 0.1 の標準誤差は約 3.5–4.5 ポイントです。

より有用な定性的説明は、タスクが拡大しても一貫性を保つよう設計されている、ということです。大きな codebase をマッピングし、複数の service にまたがる稀な障害を追跡し、大量の資料から計画を立て、実験を動かし、artifact を修正し、もっともらしい最初の回答ではなく根拠とともに戻ってくる、という仕事です。

このため、一般的な chat ユーザーよりも Claude Code チームにとって重要になる可能性があります。短い質問への回答が必ず良くなるというより、停止が減り、浅い修正が減り、root-cause analysis が改善し、数時間の session でより多くの仕事を完了できることが期待されます。

Fable と Mythos:1 つのモデル、2 つの runtime policy

最も重要な製品上の違いは、純粋な intelligence ではなく、モデルを取り囲む policy layer です。

Fable 5.1 は一般利用向けです。Fable 5 より safeguards が精密になっています。

  • 防御目的なら source code の脆弱性を特定できますが、exploit の生成、penetration testing、binary ベースの脆弱性スキャンは行いません。
  • Anthropic は、初期の Fable 5 safeguards と比較して、基礎 biology や医療に関する benign な質問への biology safeguard の介入が 85% 少ないと説明しています。
  • dual-use の biology と chemistry research は Opus model に route される場合があります。
  • Claude API は stop_reason: "refusal"stop_details.category を返す場合があります。アプリケーションはこれを runtime の結果として扱い、HTTP 200 なら常に回答完了だと仮定してはいけません。

Mythos 5.1 は、Cyber Verification と Life Sciences Verification の承認済み参加者向けの、より制限の少ないバージョンです。アクセスは依然として限定されており、Anthropic は現時点で一部の米国組織のみが利用できるとしています。Claude Security も Mythos 5.1 を基盤にしています。

同じ model なのに一部の cyber evaluation で Fable 5.1 が Mythos 5.1 を下回る理由はここにあります。refusal や fallback が測定結果を変えるからです。ユーザーの実体験が headline capability と異なる理由も同じです。モデルには能力があっても、公開製品では完了が許されないことがあります。

Enterprise privacy もリリースの一部

Fable 5.1 と Mythos 5.1 はデフォルトで 30 日間のデータ保持を必要とし、zero-data-retention の契約で自動的に利用できるわけではありません。独自コード、規制対象の記録、機密研究データを送る前に、組織は資格と platform ごとの条件を確認する必要があります。

Anthropic は **Enterprise Frontier Safeguards(EFS)**も導入します。発表された設計では、顧客が活動データを自分で管理する cloud infrastructure に保存し、独自の encryption key、access policy、audit log を使えます。自動安全モニタリングは深刻な misuse のパターンを検出できますが、human review はデフォルトで Anthropic の社員ではなく顧客チームが行います。EFS は 2026 年秋から段階的に展開される予定です。

これは企業にとって現実的な問いへの architecture レベルの回答です。モデルが十分に賢いかだけでなく、log を誰が保管し、誰が見られ、security alert に誰が責任を持つのかが問われます。EFS または明示的に承認された zero-retention が適用されるまでは、Fable 5.1 を ZDR model と同等に扱わない方がよいでしょう。

コミュニティの反応

リリースから数日間の反応は controlled evaluation ではありませんが、どこで強く、どこで runtime と期待が衝突しているかを示しています。

ポジティブな信号:雑然とした context と難しい仕事

r/claude の反応が多かった hands-on report では、大量で整理されていない file 集合の中をよりよく移動できること、変更が別の箇所を壊す場合に警告しやすいこと、長い文書を扱いやすいこと、簡単な prompt には短く答えることが評価されていました。一方で、最近更新された web 情報には検索を明示的に求める必要があり、曖昧な指示では依然として誤った行動を取り、ユーザーの文体を再現するには例が必要だとも報告されています。

これは想定される得意領域をよく表しています。隠れた dependency、矛盾する証拠、長い意思決定の連鎖がある task ほど Fable 5.1 は役に立ちます。ただし、最新情報の取得、明確な仕様、人間の判断を置き換えるものではありません。

実務上の懸念:速度と quota 消費

r/ClaudeAI の release hub には期待と同時に、Fable 5.1 が遅く、context を多く消費し、数個の prompt だけで 5 時間の session limit に達するという報告があります。r/ClaudeCode では、長い code review の結果は良かったものの、約 30 分で usage marker が 100% になったという報告もありました。一方で、似た仕事の週次使用量が下がったというユーザーもおり、測定済みの regression や improvement と呼ぶにはまだデータが足りません。

もっとも公平な結論は、Fable 5.1 は completed task あたりでは効率的になり得る一方、interactive session あたりでは高くつく可能性がある、ということです。推論の改善で retry は減っても、adaptive thinking と長い tool loop が最終結果の前に多くの quota を使うことはあります。

Hacker News の信号:能力と usability は別

Hacker News のリリース thread は非常に高い参加数になりました。議論は benchmark だけではなく、pay-as-you-go agent の経済性、Opus 5 に対する Fable の価値、30 日保持、safety fallback、そして一日中読むエンジニアにとって output が密すぎたり冗長すぎたりしないかにも及びました。

反対に、以前の session が止まったり新しい bug を作ったりした難しい task を Fable 5.1 が前進させたという開発者の声もあります。これは集める価値のある証拠ですが、印象的な 1 つの anecdote ではなく、再現可能な task set で検証すべきです。

Reddit と Hacker News を合わせた現時点の consensus は条件付きです。

  • 有望: 長時間 coding、file をまたぐ reasoning、root-cause analysis、research、文書中心の作業。
  • 未確定: interactive writing の style、latency、token consumption、小さな one-shot task。
  • リスク: cybersecurity、life-sciences research、proprietary data、予測可能な model identity に依存する workflow。

Developer 向け migration checklist

Fable 5 や Opus 5 からの移行は、model ID の変更だけではありません。

1. model を変更し、実際の eval を再実行する

model = "claude-fable-5"    # before
model = "claude-fable-5-1" # after

長い coding task、過去に失敗した task、tool loop、refusal、通常の user prompt を含む replay set を作ります。完了品質、wall-clock time、input/output token、cache hit、fallback 頻度を測定してください。

2. 非対応の制御を削除する

Adaptive thinking は常に有効です。thinking: {"type": "enabled", "budget_tokens": N} のような手動設定や thinking の無効化はエラーになります。予算は effort で制御し、max_tokens を見直します。

tool_choice: {"type": "any"}{"type": "tool", ...} による forced tool choice も非対応です。tool_choice: {"type": "auto"}、strict tool schema、structured outputs と、tool を使う条件を明示する指示を組み合わせてください。

3. conversation history を append-only として扱う

Fable 5.1 の thinking block は、前にある system prompt、tools、conversation history に結び付いています。過去の turn を編集したり、system を再構築したり、tools 配列を変更したりすると、後続の thinking block が無効になり、新しい account では 400 error になる可能性があります。

新しい指示には mid-conversation system message を使い、context の削減には server-side compaction または context editing を使い、prefix_mismatch_behavior を意図的に選択します。framework が毎 turn messages array を書き換える場合は、本番 traffic の前に移行テストを行うべきです。

4. agent loop の前提を見直す

Fable 5.1 は、Fable 5 が複数まとめていた tool call を 1 turn に 1 つだけ出すことがあり、長い実行では表示される progress update も少なくなる場合があります。UI が narration に依存するなら、対応する beta flow で thinking.display: "updates" を要求し、空でない thinking block を raw chain of thought ではなく progress として表示します。

独立した読み取り処理については、tool call を batch するよう明示的に指示してください。そうしなければ、正しい workflow でも round trip が増えるだけで遅く、高くなる可能性があります。

5. refusal と fallback を前提に設計する

要求した model、可能なら実際に応答した model、stop_reasonstop_details.category、token 使用量、fallback の判断を log に残します。Anthropic の default fallback または検証済みの client retry を検討してください。HTTP response が成功したからといって、要求した model が仕事を完了したとは限りません。

私たちの見方:Fable 5.1 を escalation layer として使う

Anthropic の model overview は、ほとんどの workload では Opus 5 から始め、task が難しく長時間である場合、または Opus を高い effort にしても失敗する場合に Fable 5.1 を使うよう勧めています。これは合理的な routing policy です。

  • Sonnet 5: 日常の implementation、小さな refactor、広範な automation、コスト重視の実行。
  • Opus 5: 複雑な engineering と enterprise work の標準選択。
  • Fable 5.1: 大規模 migration、難しい debugging、長時間の research、文書中心の分析、失敗の繰り返しが model 料金より高くつく task。
  • Mythos 5.1: より制限の少ない policy surface が必要な、承認済みの cybersecurity と life-sciences workflow。

コミュニティの反応もこの routing を裏付けています。Fable 5.1 が最も価値を持つのは、誤った方向を防ぎ、長い計画の一貫性を保ち、安価な model が見落とした root cause を見つける場面です。短い回答、日常的な編集、最大の深さより latency と quota が重要な session では、追加費用を正当化するのが難しくなります。

まとめ

Claude Fable 5.1 は Anthropic が一般提供する最新の frontier model で、Mythos 5.1 は trusted access 版です。自律的な work で重要な long context、複数ステップの coding、research、computer use、複雑な artifact 作成では、改善は十分に信頼できそうです。同じ context を繰り返し読む agent にとって、cache-read 料金の 75% 引き下げは benchmark の向上と同じくらい重要かもしれません。

一方で、runtime policy を無視できないリリースでもあります。Fable 5.1 は遅くなったり、quota を多く消費したり、センシティブな task で fallback したり、30 日のデータ保持を要求したりします。また、custom API client が tool と thinking block を扱う方法も変わります。採用は選択的に行うべきです。自分たちの難しい task で benchmark し、完了結果あたりのコストを測り、Opus と Sonnet を routing に残し、enterprise 導入の前に privacy と safeguards の挙動を確認してください。

Fable 5.1 は単に「最も賢い Claude」ではありません。model、security policy、billing model、conversation-state contract が 1 つの製品にまとまっています。この 4 つすべてを評価して初めて、upgrade に価値があるか判断できます。

参照した情報源