⏳

1週間限定のClaude Fable 5で何をすべきか ― 7月7日→7月13日→7月19日まで

に公開
AI
Fable
Claude
Anthropic
Fable 5
tech

はじめに

2026年7月1日、Claude Fable 5が世界に再提供された。6月9日の発表から6月12日の米国輸出規制による提供停止を経て、6月30日に規制が解除され、7月1日の再提供に至っている。ただし今回は無条件の解禁ではない。Pro/Max/Team等のプランで追加課金なしにFable 5を使えるのは、週次利用上限の範囲内で2026年7月7日までの1週間限定だ。7月8日以降は利用クレジット（従量課金）が必要になる。※現在は、7月7日 → 7月13日 → 7月19日まで延長されている。

本稿は、この短い試用期間に「何をすべきか」を、公開情報と筆者の実務経験に基づいて整理する考察である。ベンチマーク数値や仕様の一次資料が確認できない箇所は、その都度ヘッジ表現を付す。断定できるのは輸出規制・提供期間・Anthropic公式発表の内容のみであり、それ以外は「〜という報告がある」「〜とされる」という扱いで読んでほしい。

5行まとめ（クリックで展開）

TL;DR（5行まとめ）

  1. Fable 5とMythos 5は同じ基盤モデルを用いるが、一般提供向けのFable 5には追加safeguardがある。6月版から性能が落ちたというより、safeguardとルーティングが体感差を生んでいるという分析がある
  2. Opus 4.8にできずFable 5にできることの本質は、個別の応答品質差ではなく「長時間タスクの一貫性」「大規模コンテキストでの横断処理」「計画・設計の全体最適化」の3点にある
  3. この1週間は、大規模移行・大量文書の横断分析・積年の技術的負債の棚卸しなど、広い文脈と長時間実行を要する作業に投げるのに適している
  4. Fable 5だけに全部投げると利用枠を早く消費しやすい。判断・統合・設計方針はFable 5、調査・実装はSonnet系など軽量なモデルに任せる分担がトークン効率上もっとも良い
  5. 7月8日以降はクレジット課金になるため、この1週間は「Fable 5が自分のワークフローに本当に必要かを見極める試用期間」と位置づけるのが妥当

1. Fable 5とは何か ― 中身はMythos 5なのか、6月より弱くなったのか

同一基盤モデル、主な違いは安全対策

Anthropicの公式発表によれば、Fable 5とMythos 5は同じ基盤モデルを用いている。主な違いは安全対策の設計にある。Fable 5は一般提供向けに、サイバー攻撃や生物化学兵器転用など「デュアルユース」の懸念がある能力に対して追加safeguardが組み込まれている。このsafeguardに関連して、一部リクエストがOpus 4.8へフォールバックする挙動も説明されている（Anthropicによれば、この挙動が影響するのはセッションの5%未満とされる）。

一方Mythos 5は、一部領域でsafeguardが緩和された版であり、「Project Glasswing」という取り組みに参加が承認された組織（サイバー防衛・重要インフラ運用者等）のみが利用できる。一般のPro/Max/Teamユーザーが日常的に触れるのはFable 5であり、Mythos 5に触れる機会はない。

つまり「Fable 5の中身はMythos 5なのか」という問いへの答えは、基盤モデルとしてはイエス、提供される挙動としてはノーということになる。

提供停止と再提供の経緯

Fable 5は2026年6月9日に発表されたが、6月12日に米国の輸出規制によって全ユーザー向けの提供が停止された。規制は6月30日に解除され、7月1日に世界規模で再提供された。

Pro/Max/Team、および一部Enterpriseユーザーは、7月1日から7月7日までの1週間、週次利用上限の最大50%までFable 5を追加課金なしに利用できる。7月8日以降は利用クレジット（従量課金）が必要になる。API料金は入力$10・出力$50（百万トークンあたり）で、Opus 4.8（$5・$25）のおよそ2倍にあたる。

「6月より性能が落ちた?」の真相

7月1日の再提供直後、SNS上で「Fable 5がnerfed（弱体化）された」という声が上がった。しかし、公開情報ベースでは、基盤モデル自体が6月版から差し替わったとは確認できない。再提供時に強化されたsafeguardやルーティングが、体感上の性能低下として受け止められた可能性がある。このsafeguardは、Amazonの研究者が報告したjailbreak技法への対策として組み込まれたものとされる。

問題は、このsafeguardが過剰検知気味だという点にある。"exploit"や"fix"といった、セキュリティ関連には見えるが実際には通常のデバッグ作業で頻出する語を含むタスクまでOpus 4.8へフォールバックされるケースが頻発し、これが「弱体化」論争の火種になった。

decrypt.coの分析記事は、12件のTypeScriptデバッグタスクを追跡した結果、実際にFable 5へ到達したのはそのうち3件のみだったと報告している。同記事は「体感の性能低下はルーティングが原因であり、モデル能力そのものの変化ではない」と結論づけている。BleepingComputerも同様に、再提供直後のパフォーマンス低下への不満を報じている。

この一連の経緯からの実用上の含意ははっきりしている。セキュリティ関連の語彙を含むタスクでは、意図せずOpus 4.8へフォールバックされるリスクがある。したがって、この期間限定ウィンドウでFable 5を活かすなら、分類器に引っかかりにくい大規模移行・設計・分析系のタスクに使うのが得策だ。次章以降はこの前提で組み立てる。

2. Opus 4.8にできなくて、Fable 5にできること

Fable 5とOpus 4.8の関係を「上位互換モデル」とだけ捉えると、この1週間の使い道を見誤る。両者の違いは個々の応答品質の差というより、扱えるタスクの時間軸とスケールの違いにある。

ベンチマークの扱い

Anthropicの発表では、Fable 5は複数のベンチマークで従来モデルを上回るモデルとして紹介されている。ただし、本稿執筆時点で本文から容易に検証できる形の詳細な数値表は確認できなかったため、ここでは個別スコアの列挙は避ける。

実務上は、スコアそのものよりも「長時間・大規模・全体最適化」のタスクに強いとされる点をどう使うかが重要だ。以下では、この観点に絞って使いどころを整理する。

本質的な違いは3点に整理できる

数値上の差より重要なのは、以下の3点だ。

(a) 数時間〜日単位の長期タスクで一貫性を保てること。Anthropicは、Fable 5が長時間タスクや大規模な作業で強みを発揮すると説明している。長時間にわたって目標を見失わず、文脈の一貫性を保ち続けられる点がOpus 4.8との大きな差と言える。

(b) 大規模コンテキストでコードベース／大量文書を扱えること。大きな文脈を扱えるモデルでは、単発の巨大入力だけでなく、関連ファイルや資料をまたいだ横断的な処理が現実的になる。

(c) 計画・設計の全体最適化能力。個別の実装力よりも、大きなタスクを見渡して構造を決める力に強みがある。これは次章で扱う「大規模移行」「棚卸し」的なタスクとの相性の良さに直結する。

まとめると、Fable 5の価値は「1回の受け答えの賢さ」よりも「長時間・大規模・全体最適化」という軸にある。この軸に沿ったタスクを選んで投げることが、1週間という短い試用期間を活かす鍵になる。

3. この1週間でやるべきこと① ― 大規模プロジェクトに投げる

Fable 5の強みが「長期タスクの一貫性」「大規模コンテキストでの横断処理」「全体最適化」にあるなら、この期間にまず試すべきは、普段は着手をためらっているような大規模な作業だ。

ライブラリのメジャーバージョンアップ移行

React 18→19、Next.js の Pages Router 世代から App Router への移行など、影響範囲が広くコードベース全体の整合性を見ながら進める必要がある移行作業は、長期一貫性が効くタスクの代表例だ。移行方針を最初に固め、それを最後まで崩さずに適用し続けられるかどうかが成否を分けるため、Fable 5の特性と相性が良い。

フレームワーク移行

Pages Router → App Router、あるいはVue → Reactのようなフレームワークをまたぐ移行も同様だ。単一ファイルの書き換えではなく、ルーティング・状態管理・ビルド設定といった複数のレイヤーにまたがる変更を一貫した設計方針の下で進める必要がある。

Stripe事例

Anthropicの公式発表には、Stripeの事例が次のように明記されている。

"Stripe reported that Fable 5 compressed months of engineering into days. In a 50-million-line Ruby codebase, the model performed a codebase-wide migration in a day that would otherwise have taken a whole team over two months by hand."

Stripeは5,000万行のRubyコードベース全体の移行を、通常ならチームで2ヶ月以上かかるところ、Fable 5で1日で完了したと報告している（Anthropic公式発表より）。個人開発の規模でこれと同じスピード感を再現できるとは限らないが、大規模コードベースの一括移行というタスクの方向性自体は、この1週間で試す価値がある。

大量文書の横断分析

仕様書・議事録・ログといった大量の文書を横断して整合性を確認したり、矛盾点を洗い出したりする作業も、大規模コンテキストと相性が良い。個別の文書を都度読み込ませるのではなく、関連文書をまとめて渡し、全体を俯瞰した分析をさせることで、断片的な把握では見えてこない矛盾や抜け漏れを拾いやすくなる。

積年の技術的負債の棚卸し

これまで手を付けられずにいた個人開発リポジトリのリファクタリング・レビューにも、この期間は向いている。「積年の技術的負債の棚卸しを広いコンテキストにまとめて載せる」という切り口で、リポジトリ全体をまとめて読ませ、優先順位付けと設計方針の見直しを一度にやらせてみる。普段は着手コストが高くて後回しにしていたタスクほど、この試用期間にまとめて投げる価値がある。

4. この1週間でやるべきこと② ― 数時間単位のエージェント実行

Fable 5の長期一貫性を活かすもう一つの使い方は、設計→実装→テスト→再設計という一連の反復を数時間単位でまとめて任せることだ。

この使い方で重要なのは、完了条件を明文化して渡すことである。「いい感じに直しておいて」のような曖昧な指示では、長時間タスクの途中でゴールがぶれる、あるいは逆に必要以上に作業を広げてしまうリスクがある。「このテストスイートが全て通ること」「この仕様書に記載された振る舞いを満たすこと」といった、検証可能な完了条件を最初に渡しておけば、Fable 5は数時間の実行の中でその条件に向かって一貫して作業を進めやすくなる。

途中経過を逐一確認する必要がないタスク、たとえば夜間に走らせて朝結果を確認するような使い方も、この特性を活かした運用と言える。ただし後述するように、5時間の利用制限との兼ね合いは意識しておく必要がある。

5. この1週間でやるべきこと③ ― 業務自動化のプロトタイピング

長時間にわたって複数のツール（MCP、CLI、API）をオーケストレーションするワークフローの試作も、この期間に向いている用途だ。

普段の業務で「これを自動化できたら楽になるのに」と思いつつ、実装コストの見合いから手を付けていない自動化フローがあれば、それをこの1週間でプロトタイプとして組んでみる。MCPサーバー経由での外部サービス連携、CLIツールの組み合わせ、複数APIをまたいだ処理など、単一の関数呼び出しでは完結しない複雑なオーケストレーションを、Fable 5に長時間かけて組み上げさせる。

このプロトタイピングの目的は、完成品を作ることそのものよりも、「このワークフローがFable 5でしか成立しないかどうかを見極める」 ことにある。もし同じ自動化がOpus 4.8やSonnet系のモデルでも十分に機能するなら、7月8日以降にわざわざクレジット課金でFable 5を使い続ける理由は薄い。逆に、長時間の一貫性や大規模なコンテキスト保持が不可欠だと分かれば、それは継続利用を検討する根拠になる。

6. トークン効率 ― 利用枠を溶かさない使い方

ここがこの記事で最も重要なセクションだ。Fable 5の強みを活かそうとして、すべての作業をそのままFable 5に投げてしまうと、利用枠を想定以上に早く消費しやすい。

問題提起

Fable 5はOpus 4.8よりAPI単価が高く、Claudeのアプリ内利用でも上位モデルほど利用枠を早く消費しやすい。加えて、サブエージェントを多用したり思考トークンが膨らんだりすると、想定以上に早く枠を使い切ることがある。

つまり、Fable 5に「何でも」投げるのは、この1週間の試用期間においてもっとも非効率な使い方だ。

原則:「Fableは判断、Sonnetは実装」

トークン効率を最大化する原則はシンプルだ。全体把握・統合・判断・検証・設計方針はFable 5、調査・解析・コーディングはSonnet系の軽量なモデルに委譲する。

Fable 5は前述の通り、長期一貫性と全体最適化に強みがある。逆に言えば、個別のファイル調査や定型的なコーディング作業に、単価の高いFable 5のトークンを使うのは費用対効果が悪い。こうした調査・実装作業はSonnet系の軽量なモデルに任せ、Fable 5は「考える仕事」だけに専念させる。

実際に使える指示文の例を以下に示す。

全体把握/統合/判断/検証/設計方針はFable5、
調査/解析/コーディングは、Sonnet5 で次の内容を実行してください。

〈タスク内容〉

この指示文を、サブエージェントやモデル選択に対応した利用環境で使うことで、Fable 5が全体を俯瞰しながら、実際の手を動かす部分を軽量なモデルに振り分ける構造を作れる。コンテキストを絞る、要約を活用する、軽量なモデルへ委譲するという3点は、いずれもトークン効率を上げる方向で作用する。

途中で要約させる（最も重要）

もっとも効果が大きいのは、Fable 5の稼働そのものを最小限に絞り、要所だけに介在させる3フェーズ運用だ。

フェーズ 担当 所要時間の目安 内容
1. 計画 Fable 5 10〜15分 ゴール設定、設計、タスク分割、各タスクの完了条件を作成する
2. 実行 Sonnet系の軽量モデル 長時間 各タスクを実装・テストする
3. レビュー Fable 5 5〜10分 成果物全体をレビューし、設計との整合性だけを確認する

最初にFable 5へ計画立案だけをやらせ、ゴールとタスク分割、そして各タスクの完了条件を明文化させる。ここでFable 5の稼働時間は10〜15分程度に抑える。次に、その計画に基づいた実装とテストは軽量なモデルに任せる。ここは時間がかかってもよい。最後に、出来上がった成果物をFable 5に戻し、設計との整合性だけを5〜10分程度でチェックさせる。

この運用であれば、Fable 5が実際に稼働する時間はトータルで20〜25分程度に収まる。重い判断だけをFable 5に寄せ、実装作業を軽量なモデルに振り向けられるため、同じ作業量でも消費される利用枠は大きく圧縮できる。

結論

Fable 5は長期計画と全体最適化が得意なモデルであり、逆に言えば「考える仕事だけ」を担当させるのがもっともトークン効率が良い使い方になる。この1週間、Fable 5にすべてを任せたくなる場面は多いはずだが、そこをぐっとこらえて軽量なモデルとの分業を意識するだけで、同じ利用枠でこなせる作業量は大きく変わってくる。

まとめ

7月1日から7月7日までの1週間、Fable 5は追加課金なしで使える。しかし週次利用上限の50%という制約と、上位モデルゆえの利用枠消費を踏まえると、この期間にできることは思ったより限られている。優先順位をつけて臨むべきだ。

筆者が勧める優先順位は次の通りだ。まず、これまで着手をためらっていた個人開発リポジトリの棚卸しに広いコンテキストを使ってみる。次に、ライブラリやフレームワークのメジャー移行を1本、実際にFable 5へ任せてみる。最後に、業務自動化のプロトタイプを組んで、それがFable 5でしか成立しないワークフローなのかを見極める。

7月8日以降はクレジット課金に切り替わるため、この1週間は「Fable 5が自分のワークフローに本当に必要かどうかを見極める試用期間」と位置づけるのが妥当だ。長時間タスクの一貫性や大規模コンテキストが日常の作業に効いてくると実感できれば、課金してでも使い続ける価値がある。逆に、Opus 4.8やSonnet系モデルとの分業で十分だと分かれば、それもまた有益な結論と言える。

参考

Discussion