Claude Fable 5.1 と Mythos 5.1 — 同じ重みを2つのセーフガードで出し分ける構成が定着した

要約

2026-09-01、Anthropic が Claude Fable 5.1 と Claude Mythos 5.1 を公開しました。

まず、この2つの関係を正確に押さえてください。両者は同一のモデル重みを持つ、2つの構成です。 別のモデルが2つ出たわけではありません。違いはセーフガードの水準だけです。

Fable 5.1 は一般提供。 Claude API で claude-fable-5-1 として全顧客が使えます。AWS（Bedrock と Claude Platform on AWS）、Google Cloud、Microsoft Foundry でも同日提供。claude.ai では Pro / Max / Team / Enterprise が対象です。

Mythos 5.1 は、サイバーセキュリティとライフサイエンスの領域でセーフガードを緩めた構成で、審査を通った組織（Project Glasswing 参加者）にのみ提供されます。 現時点では米国の組織に限られ、Anthropic は米国政府と調整しながら国内外へ拡大する方針を示しています。

この「同じ重みを、セーフガード水準で出し分ける」という構成は、Fable 5 / Mythos 5 の世代で導入され、今回定着した形になります。 能力の高いモデルを広く出すことのリスクと、防御側・研究者が能力を必要としている現実——この2つを、モデルを分けるのではなくアクセス制御で分けることで両立させるという設計判断です。

性能の伸びは大きい。 前世代 Fable 5 との比較で、Terminal-Bench-Science 0.1 が 24.7% → 52.6%、Terminal-Bench 4.0 が 42.0% → 55.8%（Mythos 5.1 では 60.9%）、AutomationBench が 17.1% → 31.4%、GDPval-AA v2 が 1723 → 1853。いずれも Opus 5 を上回っています。

そして価格です。ここが実務上いちばん効きます。

Fable 5.1 の入力・出力単価は Fable 5 と同一で、キャッシュ読み込みだけが値下げされました。 公式の見積もりは「典型的なワークロードで約25%安く、エージェント的な用途では最大約45%安くなる」。性能が上がって価格が下がるため、Fable 5 に留まる経済的な理由がほぼ消えます。

もう1つ、効率の使い方が変わります。 公式のグラフは、Fable 5.1 を Low または Medium の effort に落としても、Fable 5 の結果と同等以上であることを示しています。つまり「最高性能を取りに行く」だけでなく、「同じ品質をより安く取る」という使い方が選べるということです。既定値は Claude Code が High、Claude Cowork と claude.ai が Medium です。

セーフガードの変更も、実務に直接効きます。

サイバーセキュリティ領域の誤検知が従来比60%減。 その一因として、Fable 5.1 はソースコード中の脆弱性の発見に使えるようになりました。 ただしエクスポイトの開発は引き続き不可で、ペネトレーションテストとバイナリベースの脆弱性スキャンも制限対象のままです。**「見つけることはできるが、攻撃可能な形にすることはできない」**という線引きです。

生物領域では、良性のリクエストへの介入が Fable 5 の launch 時比で85%減。 介入が発生した場合は Opus 系モデルへフォールバックする仕組みになっています。

何が変わったか

• Claude Fable 5.1（claude-fable-5-1）が一般提供開始。 Claude API 全顧客、AWS / Google Cloud / Microsoft Foundry、claude.ai の Pro / Max / Team / Enterprise
• Claude Mythos 5.1（claude-mythos-5-1）は Project Glasswing 参加組織限定。 現時点では米国組織のみ
• 両者は同一のモデル重み。違いはセーフガードの水準だけ
• 仕様: 1M トークンのコンテキスト（全域が標準単価）、最大出力 128k トークン、adaptive thinking は常時オンで effort パラメータで深さを制御
• 価格は Fable 5 と同一。キャッシュ読み込みのみ値下げ。典型ワークロードで約25%減、エージェント用途で最大約45%減
• ベンチマーク: Terminal-Bench-Science 0.1 52.6%（Fable 5 は 24.7%、Opus 5 は 29.0%）、Terminal-Bench 4.0 55.8%（Mythos 5.1 は 60.9%）、AutomationBench 31.4%、GDPval-AA v2 1853、Humanity’s Last Exam 60.9%（ツールなし）
• サイバー領域のセーフガード誤検知が60%減。 Fable 5.1 でソースコードの脆弱性発見が可能に（エクスポイト開発、ペネトレーションテスト、バイナリベースのスキャンは引き続き不可）
• 生物領域の良性リクエストへの介入が85%減。 介入時は Opus 系へフォールバック
• データ保持は別発表の Enterprise Frontier Safeguards（EFS）と連動。 EFS 提供までの間、対象顧客は Fable 5 / 5.1 でゼロデータ保持を受けられる

業務インパクト（一般企業向け）

まず、移行判断は簡単な部類に入ります。

性能が上がり、価格が据え置かれ、キャッシュ読み込みが安くなった。 この組み合わせなら、Fable 5 を使い続ける技術的・経済的理由はほとんどありません。検証すべきは「既存のプロンプトとワークフローが同じように動くか」だけです。

ただし、モデル ID を固定していない実装は注意してください。 Claude Code の既定 Fable モデルは、同日リリースの 2.1.257 で Fable 5.1 に切り替わりました。明示的にバージョンを固定していない環境は、更新のタイミングで自動的に新モデルへ乗ります。 挙動の変化を検知したい場合は、モデル ID の固定と、切り替えの意思決定を分ける運用が必要です。

次に、コスト設計を見直す機会になります。

effort を下げても前世代の品質が出るという事実は、コスト最適化の余地が増えたことを意味します。これまで「品質を取るか、コストを取るか」の二択だった箇所で、「同じ品質を安く」という第三の選択肢が使えます。

実務としては、まず既存のワークロードを Low / Medium の effort で走らせて、品質が許容範囲に収まるかを測る。収まるなら、そのまま下げてよい。測らずに High のままにしておくのは、単に高いお金を払い続けることです。

そして、セキュリティ用途の線引きが変わった点は、社内ルールの更新対象です。

「Claude はセキュリティ関連の作業に使えない」という前提で運用ルールを書いている組織は、その記述が古くなりました。 Fable 5.1 はソースコード中の脆弱性の発見に使えます。 一方で、エクスポイト開発とペネトレーションテスト、バイナリベースのスキャンは依然として制限されます。

この境界は曖昧ではなく、明確です。 「脆弱性を見つける」までは可。「攻撃可能な形にする」からは不可。社内のセキュアコーディング支援やコードレビューの文脈では、実用的な範囲が明確に広がりました。

運用ルールを書くときは、この境界をそのまま書き写してください。 「セキュリティ関連は禁止」という粗い書き方だと、使える用途まで塞いでしまいます。 逆に「セキュリティに使える」と粗く書くと、制限に引っかかる作業を前提にした計画が立ちます。境界を正確に書くことが、そのまま実務の可用性になります。

Mythos 5.1 については、多くの日本企業にとっては現時点で選択肢ではありません。 米国の審査済み組織に限定されているためです。「Mythos があるらしい」という情報だけで導入計画に織り込むのは危険で、まずアクセス可否の確認から始まります。

データ保持については、同日発表の EFS と合わせて読む必要があります。 2026-06 に導入された「Fable / Mythos クラスの全トラフィックに30日保持」というポリシーへの対応が EFS で、それが使えるようになるまでの間、対象顧客は Fable 5 / 5.1 でゼロデータ保持を受けられます。 規制産業でこのポリシーを理由に導入を止めていた組織は、再検討の条件が揃ったことになります。

副業・個人活用視点

個人利用者にとって、いちばん実利があるのはキャッシュ読み込みの値下げです。

長い文脈を繰り返し参照する使い方——コードベース全体を読ませる、長い資料を何度も参照する、エージェントに長時間の作業をさせる——で効きます。 公式が「エージェント的な用途では最大約45%」と言っているのは、この種の使い方でキャッシュ読み込みの比率が高いためです。

Claude Code を日常的に使っているなら、体感としてのコスト差は小さくないはずです。 同じ作業が安くなる、という単純な話です。

次に、effort の使い分けを覚えておく価値があります。

Claude Code の既定は Highです。すべての作業に High が必要なわけではありません。 定型的な修正、既存パターンの適用、単純なリファクタリング——こうした作業は Medium や Low で十分なことが多い。/effort で切り替えられるので、作業の性質に応じて意識的に落とす習慣をつけると、月額の消費が変わります。

逆に、難しい作業では High や xhigh を使う。 「常に最高設定」でも「常に最低設定」でもなく、作業に応じて選ぶ——これがこのモデル世代の使い方です。

案件の観点では、2つの方向があります。

1つは、モデル移行の支援。 「Fable 5 から 5.1 へ切り替えたい。何を検証すればいいか」という相談は、プロンプトの回帰テストの話になります。モデルを変えると出力が変わりうるという当たり前の前提を、検証手順に落とせる人は多くありません。評価用のテストケースを整備するところから入ると、単発の移行支援が継続的な品質管理の仕組みづくりに広がります。

もう1つは、コスト最適化の相談。 effort の使い分けとキャッシュの効かせ方は、知っていれば実行できて、知らなければ気づかない類の話です。「同じ作業を3割安くする」という提案は、経営層に説明しやすい。

ただし、提案の前に実測してください。 「理論上安くなるはず」ではなく、「あなたの実際のワークロードで測ったらこうだった」という数字を出せるかどうかで、提案の説得力は決定的に変わります。

セキュリティ関連の受託をしている人は、線引きの変更を正確に把握しておくべきです。

脆弱性の発見支援は使える。エクスポイト開発とペンテストは使えない。 この境界を知らずに「AI に手伝わせる前提」で見積もると、作業の途中でセーフガードに止められます。 逆に、発見・レビューの領域では実用性が明確に上がったため、コードレビュー系の案件では武器が増えたと考えてよい状況です。