Claude Fable 5 vs Mythos 5: APIルーティング比較
APIアクセス、セーフガード、フォールバック動作、本番モデルルーティングの観点からClaude Fable 5とMythos 5を比較します。
ステータス更新（2026年6月13日）：この更新時点で、AnthropicはClaude Fable 5とClaude Mythos 5の両方へのアクセスを停止しており、GitHubのCopilotもFable 5をすべてのサーフェスから削除しました（他のClaudeモデルは影響を受けていません）。以下で「今日Fable 5を呼び出せる」と記載されている内容は、6月9日の発売日時点の状態を反映しており、現在は正確ではありません。アクセスが回復するまで、この記事は現時点でどちらをルーティングすべきかのガイドとしてではなく、2つのモデルが設計上どのように異なるかの参考資料としてご覧ください。停止の理由は現時点では主にプレス報道によるものであり、公式の完全な説明はまだありません。本番環境での判断はAnthropicの復旧通知を待ってから行ってください。
同じ頭脳を持ちながらルールブックは異なる2つのモデルについての作業メモ——そして、どちらかをパイプラインに組み込む前に何を意味するか。
こんにちは、皆さん。Doraです。私はこの2つのうちどちらを中心にルーティングを設計すべきか解明しようと、1週間近くを費やしました。Claude Fable 5 vs Mythos 5の短い答えはこうです：同じ基盤モデル、2つの異なる安全性とアクセスの取り決め。この一つの違いが下流のほぼすべてを決定します——誰が呼び出せるか、リクエストがブロックされたときに何が返ってくるか、そしてフォールバックロジックがどのように機能しなければならないか。この記事は私が整理したこと、まだ不明瞭なこと、そして私を信頼するのではなく自分で仕様を読むべき箇所をまとめたものです。
最初に一点。私はMythos 5を本番環境で実行していません——Project Glasswing以外ではほとんど誰もそうしていません。そのため、この内容の多くは私が個人的にストレステストしたものではなく、ドキュメント化されていることを比較したものです。その線引きが必要な箇所は明示します。そして、後から追加した2点目：両モデルを取り巻くアクセス状況は発売後数日で急速に変化しました（上部のステータス注記を参照）。そのため、以下の「今日呼び出せる」という記述は発売日時点の状況を説明しており、必ずしも今朝の状況ではないことをご承知おきください。
Fable 5 vs Mythos 5を一文で
同じ能力クラス。異なる安全モデル、異なるアクセスモデル。これが比較のすべてであり、以下はすべてその結果に過ぎません。
同じ能力クラス、異なる安全性/アクセスモデル
両モデルは同じベースから生まれています。Anthropic自身のドキュメントによれば、Claude Mythos 5はClaude Fable 5の能力を共有しています——分割は生の知性に関するものではありません。Fable 5にはリクエストを拒否できる安全分類器が搭載されています。Mythos 5にはこれらの分類器がなく、審査済みプログラムを通じてのみ提供されます。
ベンチマークチャートでMythos 5がFable 5をわずかに上回る場合、それはより賢いモデルではありません。ガードレールが時折クエリを別の場所にルーティングしない、同じモデルです。デコーダーは、アスタリスク付きのベンチマークギャップは能力の違いではなく、Opus 4.8へのセーフガードフォールバックによるものだと指摘しています。Mythos 5が「プロ」ティアのように聞こえるマーケティング的な表現があるため、この点を明確にしておく価値があります。そうではありません。ガードレールなしのティアです。
この違いがAPIビルダーにとって重要な理由
構築する立場にある場合、アクセスの分割が最初に問題になります。Fable 5は今日呼び出せます。Mythos 5はおそらくまったく呼び出せません。そのため、設計作業のほとんどは実際には「Fable 5の拒否動作をどのように構築するか」であり、重要インフラにいない限りMythos 5は脚注に過ぎません。
詳細の前に簡単な方向付けテーブルを示します：
| 項目 | Claude Fable 5 | Claude Mythos 5 |
|---|---|---|
| 能力クラス | Mythosクラス（同じベース） | Mythosクラス（同じベース） |
| 安全分類器 | あり——リクエストを拒否できる | 分類器なし |
| アクセス | 一般提供 | 限定的、Project Glasswingのみ |
| APIモデルID | claude-fable-5 | claude-mythos-5（未確認） |
| 価格 | $10 / $50（入力/出力、100万トークンあたり） | $10 / $50（入力/出力、100万トークンあたり） |
| コンテキスト/出力 | 1Mコンテキスト、128k出力 | 1Mコンテキスト、128k出力 |
| データ保持 | 30日間（ZDRなし） | 30日間（ZDRなし） |
| 対象ユーザー | 一般的な本番環境での使用 | 審査済みのサイバーセキュリティ/生物学研究 |
APIモデルIDについての注記：
claude-fable-5はAnthropicのドキュメントと複数のソースで確認されています。claude-mythos-5は命名パターンからの合理的な推測です——Mythos 5は公開販売されていないため、その正確な文字列を裏付ける公開ドキュメントはありません。実際に呼び出す必要がある場合は、ここに記載したものではなく、アカウントチームから提供されたものを使用してください。
アクセスと可用性
ここで2つのモデルは互換性がなくなります。
Fable 5の一般提供
Fable 5は実際に入手できるモデルです。AnthropicのFable 5製品ページによれば、Claude Platformでネイティブに、マーケットプレイスを通じて、そしてAWS、Google Cloud、Microsoft Foundryで利用できます。開発者はモデル文字列claude-fable-5で呼び出せます。申請もアカウントチームによるゲーティングも不要です。登録してすぐに使えます。
VentureBeatはロールアウトの形を確認しました：Fable 5は今日、ウェブサイト、アプリ、APIを通じて一般公開されています。これがビルダーの99%がルーティングの中心に置くモデルです。今追加しなければならない注意点：その「今日利用可能」は6月9日時点では正確でした。6月12日の時点で、AnthropicはFable 5とMythos 5の両方へのアクセスを停止し、GitHubも同日すべてのCopilotサーフェスからFable 5を削除しました——他のすべてのClaudeモデルは稼働中のままでした。別途、発売から2日後にMicrosoftは自社社員向けにGitHub CopilotのFable 5をブロックしていました。内部コンプライアンスルールに対する30日間の保持要件を理由としており（このブロックは内部のみ；外部顧客はより広範な停止まではアクセスを維持していました）。つまり、「セルフサービスで常時稼働」はこのモデルについて今は安全な前提ではありません。
Mythos 5の制限付きアクセス
Mythos 5は別の話です。一般提供されていません：Project Glasswingの承認済み顧客に限定提供されています。必要であれば、ドキュメントによるとAnthropicのAWS、またはGoogle Cloudのアカウントチームに連絡するよう求められています——つまり、すでにアカウントチームがいない場合、それが答えです。デコーダーは率直に述べています：Mythos 5は少数のパートナーグループに予約されており、サイバーセキュリティなどの領域での制限を削除します。
正直に言うと——私は「制限付き」が本当に制限付きを意味することを受け入れる前に3つの記事を読みました。購入できる高価格ティアではありません。セキュリティプログラムに結びついた承認プロセスです。それが該当しない場合は、Fable 5を中心に計画を立てて先に進んでください。
プラットフォームの可用性とアカウントチームの要件
実際のフィルター：Fable 5は主要クラウド全体でセルフサービスです。Mythos 5はアカウントチームを通じてAnthropicの制限付きサイバーセキュリティイニシアティブであるProject Glasswingへの承認を得る必要があります。2つのモデルが同じAPIIDのパターン（claude-fable-5 / claude-mythos-5）を持つため、ドロップダウンの切り替えのように見えます。そうではありません。一方はパブリックエンドポイント、もう一方は権限です。
セーフガードとフォールバック動作
次はコードを実際に変える部分です。
機密ドメインの分類器
Fable 5のヘッドライン統合変更点は、ノーと言えることです。APIドキュメントから：Claude Fable 5にはリクエストを拒否できる安全分類器が含まれています。Claude Mythos 5にはこれらの分類器は含まれていません。ブロックされるドメインは重要なもので——TechCrunchはサイバーセキュリティ、生物学、化学、蒸留をモデルが応答をブロックする領域として挙げました。
拒否が発生した場合、エラーは発生しません。stop_reason: "refusal"を含む通常のHTTP 200が返され、応答によってどの分類器が発動したかが通知されます。これは意図的なデザインの選択であり、処理方法に影響します——拒否は有用な出力を含まない成功した応答です。
ルーティングコンセプトとしてのOpus 4.8へのフォールバック
ここに洗練された点があります。Fable 5が拒否した場合、ブロックされたクエリはそのまま消えるわけではありません——多くはOpus 4.8によって処理されます。Anthropicのドキュメントにはこう記されています：機密トピックに関する多くのクエリは、代わりに次に最も有能な一般提供モデルであるClaude Opus 4.8から応答を受け取ります。
概念的には2層システムとして考えてください：最前線の作業にはFable 5、Fable 5が扱わないものはOpus 4.8で安全にキャッチ。前述のベンチマークのアスタリスクは？数値に表れているのがまさにこのメカニズムです。
フォールバックガイドのための実装詳細
方法については意図的に深く掘り下げません。専用のガイドがあり、SDKミドルウェアとfallbacksパラメーターを比較記事に詰め込むことは両方のトピックを中途半端に扱うことになるからです。コンセプトレベルで言えば：サーバーに再試行させることも、クライアントから再試行することも、手動で構築することもできます。正確なstop_reason処理、ベータ版fallbacksパラメーター、SDKミドルウェアのセットアップ——これらはすべてAnthropicの拒否とフォールバックドキュメントにあり、私の言い換えではなくそこで読むべきです。
本番ルーティング設計
実際のパイプラインを設計している場合、3つの点を考慮すべきです。
ポリシーを意識したモデル選択
ベンチマークリーダーボードではなく、ワークロードが実際に何をするかに基づいてモデルを選択してください。一般的な本番トラフィック→Fable 5。適切な承認を得たサイバーセキュリティまたは生物学研究→アクセスがあればMythos 5。低コストまたはフォールバックパス→Opus 4.8。判断はポリシーとアクセスについてであり、「SWE-Benchでどちらが高得点か」ではありません。
高レベルのフォールバックAPI設計
拒否を例外ではなく通常のブランチとして設計してください。拒否は200を返すため、エラーハンドリングではキャッチできません——stop_reasonを明示的にチェックし、それに応じてルーティングする必要があります。サーバーサイドの再試行（コードが少ない、現在ベータ版）とクライアントサイドの制御（柔軟性が高い、どこでも動作）のどちらが望ましいかを事前に決定してください。私が行き着いた判断：監査のためにどのモデルが応答したかを重視する場合、クライアントサイドの方がより明確な制御ができます。単に回答が欲しい場合は、サーバーサイドの方が動く部品が少ないです。
監査ログとデータ保持
これには驚きました。Fable 5とMythos 5の両方は30日間のデータ保持を持ち、ゼロデータ保持では利用できません——指定カバーモデルです。GitHubのchangelogは（現在は停止された）Copilotロールアウト中にその理由を明記しました：Anthropicは有害または悪用的な使用を検出する安全分類器を運用するためにプロンプトと出力を最大30日間保持し、その後削除します。保持されたデータはトレーニングには使用されません。これは仮想のコンプライアンス上の懸念ではありません：まさにMicrosoftが自社社員のモデルをブロックした条項です。コンプライアンス体制がすべてのモデルにわたってZDRを前提としている場合、この前提が崩れます。出荷前に確認してください。Anthropicのデータ保持ドキュメントがここでの信頼できる情報源であり、私の要約ではなくそれに対して確認すべきです——保持ルールはひっそりと更新される類のものです。
ビルダーはどのモデルを中心に計画すべきか？
短い答え：ほぼ全員にとってFable 5——ただし「中心に計画する」というのはアクセスが戻ることを前提としているという大きな注意付きで。現時点では誰もどちらのモデルにもライブトラフィックをルーティングしていません。
一般的な本番環境での使用にはFable 5をデフォルトに
一般提供されており、Anthropicが公開した最も有能なモデルであり、セーフガードは一般的な製品がほとんど触れないドメインに影響するだけです。ソフトウェアエンジニアリングと知識作業——Fable 5の強みに関するAnthropicの独自の枠組み——については、分類器がほとんど邪魔になりません。パフォーマンスも本物です：Stripeは5000万行のRubyコードベースで、Fable 5が2か月以上チーム全体が費やすような大規模移行を1日でこなしたと報告しています。通常ならこの種の数字に懐疑的になりますが、名前が挙げられた顧客とともにAnthropicの発売資料を通じて伝えられているため、ベンダー報告のデータポイントとして受け取ってください。
Mythos 5を制限付きアクセスの特殊容量として扱う
Project Glasswingにすでに所属していない限り、Mythos 5を中心にアーキテクチャを構築しないでください。これは「アップグレードする」モデルではありません。審査済みのサイバーセキュリティと生物学研究のための特殊な、ガードレールなしの容量であり、アクセスパスはアカウントチームと承認プロセスを通じます。ほとんどのビルダーにとっては見えないものであるべきです。
Opus 4.8をフォールバックまたは低コストルートとして維持する
Opus 4.8はこの世界で2つの役割を持ちます：Fable 5が拒否したときの安全なキャッチ、そしてフロンティアが不要なときの安価でまだ非常に有能なオプションです。Anthropicのモデル概要によれば、現在の本番モデルであり続けています。ルーティングに維持することはダウングレードではありません——フォールバック設計全体が依拠するバックストップです。そして現在のFable/Mythosの停止中は、単なるバックストップではなく——3つのうち唯一まだ応答しているものであり、Fable 5とだけ通信する方法しか知らないパイプラインを構築しないことへの独自の論拠です。
FAQ
Claude Fable 5とMythos 5の違いは何ですか？
同じベースモデルと能力を共有しています。Fable 5にはリスクの高いドメインでリクエストを拒否できる安全分類器が含まれており、一般提供されています。Mythos 5はこれらの分類器が削除されており、承認されたProject Glasswingパートナーに制限されています。アクセスとセーフガードが異なります；生の能力は異なりません。正式で最新の定義については、Anthropicの公式モデルドキュメントを確認してください——これは急速に変化する領域です。（2026年6月中旬時点で、両モデルは一時停止中です——どちらかに依存する前に現在の可用性を確認してください。）
Fable 5は自動的にOpus 4.8にフォールバックしますか？
できますが、「自動的に」はどのように構築するかによります。Fable 5が拒否した場合、リクエストはOpus 4.8によって処理でき、Anthropicはその再試行を処理するサーバーサイド、クライアントサイド、手動の方法を提供しています。サーバーサイドのfallbacksパラメーターはベータ版です。実装の詳細は公式フォールバックガイドにあり、記憶から組み込むのではなくそれに従ってください——最新の公式ドキュメントに対して確認してください。
開発者はFable 5のセーフガードを無効にできますか？
いいえ。セーフガードはオン/オフできるトグルではありません。Mythos 5——分類器なしのバージョン——は、Fable 5内の設定ではなく、Project Glasswingを通じて審査済みパートナーのみが利用できる別途ゲートされたモデルです。Fable 5の分類器を削除またはバイパスするサポートされた方法はなく、試みるべきではありません。現在のポリシーについては、Anthropicの公式ドキュメントを参照してください。
APIビルダーはデフォルトでどのモデルを使用すべきですか？
Claude Fable 5です。一般提供されており、最も広くリリースされた有能なClaudeモデルであり、セーフガードが一般的なソフトウェアと知識作業に干渉することはほとんどありません。フォールバックと低コストパスとしてOpus 4.8をルーティングに維持してください。Project Glasswingに承認されていない限り、Mythos 5はスコープ外として扱ってください。常に、コミットする前に公式ドキュメントで可用性と価格を確認してください。そして現在、「デフォルトで」というのは名目上のことです：Fable 5が停止している間、実際にトラフィックを処理しているのはOpus 4.8です。
まとめ
Claude Fable 5 vs Mythos 5の問い全体は一つの事実に収束します：同じモデル、異なるルールブック。Fable 5は実際に構築の基盤となるもの——パブリックで、有能で、重要な箇所にガードレールがあります。Mythos 5は私たちのほとんどが決して触れない特定の種類の承認された作業のための制限付き容量です。そしてOpus 4.8がフォールバックとして全体を静かに支えています。
ですから、あなたが私の立場であれば次にすることはこうです：公式のモデルと拒否ドキュメントを確認し、サーバーサイドとクライアントサイドのどちらのフォールバックがスタックに合うかを決定し、30日間の保持がコンプライアンスの状況で何かを変えるかどうかを確認してください。最後の点がほとんどの人が見逃すトラップです。そしてそれよりも前に：Fable 5がオンラインに戻っているかどうかを確認してください。執筆時点ではまだそうではないからです。この比較で最も速く変化した変数は、最も予想していなかったものでした——セーフガードでもフォールバックロジックでもなく、そもそもモデルに到達できるかどうかです。
私のメモはここで終わります。まだ実際の負荷でフォールバックパスを実行していません——それは来週の問題です。要検証。
以前の記事：
