Anthropic が 2026年6月30日に Redeploying Fable 5 を公開しました。
6月12日に Fable 5 と Mythos 5 へのアクセスが停止されていましたが、Anthropic は輸出管理上の制限が解除されたことを受け、Fable 5 を 7月1日から Claude Platform、Claude.ai、Claude Code、Claude Cowork でグローバルに提供すると説明しています。
ただし、今回の再解放は「以前と同じように、何でも無制限に使える」という話ではありません。
Pro、Max、Team、一部 Enterprise では、7月7日まで週次利用上限の最大50%まで Fable 5 が含まれ、その後は usage credits 経由になるとされています。日本時間で 7月1日になっていても、アカウントや利用面によって反映に時間差がある可能性はあります。記事執筆時点では、公式発表を前提にしつつ、実際の利用可否は Claude 側の表示で確認するのが安全です。
今回考えたいのは、Fable 5 が戻ってきたこと自体よりも、Fable 5 を何に使うべきかです。
結論から言うと、Fable 5 は日常のコード実装を全部置き換えるモデルではなく、深い洞察、仕様設計、タスク分解、仕組み化に使うのがよさそうです。実装そのものは Opus や Sonnet に渡す。Fable 5 は「何を作るか」「何を見落としているか」「どう進めると破綻しにくいか」を考えるために使う。
今のうちに準備しておくべきなのは、Fable 5 に投げるタスクの棚卸しです。
復活したが、制約付きの復活である
まず、今回の時系列を整理します。
Anthropic は 2026年6月9日に Claude Fable 5 and Claude Mythos 5 を発表しました。Fable 5 は Mythos-class の能力を一般利用向けの安全制限付きで提供するモデルとして説明されています。発表時点では、長く複雑なタスクほど既存モデルとの差が大きいとされ、ソフトウェアエンジニアリング、知識労働、視覚、科学研究などが主な対象領域として挙げられていました。
その後、6月12日に米国政府の輸出管理指令を受け、Fable 5 と Mythos 5 へのアクセスが停止されました。6月30日の発表では、その制限が解除され、Fable 5 は 7月1日から戻るとされています。
同時に、重要な条件も示されています。
- 7月7日までは、対象サブスクプランで週次利用上限の最大50%まで利用できる
- 7月7日以降は usage credits 経由になる
- AWS、Google Cloud、Microsoft Foundry では、できるだけ早く再有効化するとされている
- サイバーセキュリティ関連などの一部リクエストは、引き続き安全分類器により Opus 4.8 へ回されることがある
つまり、Fable 5 は戻ってきますが、使い方には設計が必要です。
短い検証期間に、なんとなく日常タスクを投げて「賢いね」で終わるのはもったいない。Fable 5 でなければ見えにくい論点を、先に用意しておくべきです。
Fable 5に任せたいのは、答えより問いの設計
Fable 5 に向いているのは、単に「難しい質問に答える」ことではないと思っています。
むしろ価値が出るのは、問いそのものがまだ整理されていない仕事です。
たとえば、次のような状態です。
- Issue はあるが、どこから着手すべきか曖昧
- 仕様、実装、運用、顧客影響が絡んでいる
- 複数リポジトリや複数チームにまたがる
- 一見コード修正に見えるが、実は業務プロセスの問題も含んでいる
- 実装前に、何を検証すべきかを決める必要がある
- 失敗した場合の手戻りが大きい
こういう仕事は、いきなりコードを書くと危険です。
Fable 5 には、まず「この仕事をどう分解すべきか」「何を前提にすると危ないか」「人間が決めるべき判断はどこか」を出してもらう。そこまで整理できれば、実装は Opus や Sonnet に渡せます。
モデルの使い分けは、能力の上下だけで考えない方がよいです。
Fable 5 は、仕事の地図を作るモデル。
Opus は、地図に沿って丁寧に実装するモデル。
Sonnet は、明確なタスクを速くこなすモデル。
このように役割を分けると、高いモデルを高いまま浪費せずに済みます。
Fableで分析し、Opusで書く
コードを書く場面でも、Fable 5 を直接実装係にするより、まず分析係にする方が価値が出る場面があります。
たとえば、次の流れです。
- Fable 5 に、既存Issue、関連PR、設計ドキュメント、ログ、過去の失敗を読ませる
- Fable 5 に、目的、非対象範囲、リスク、受け入れ条件、検証計画を整理させる
- 人間が、判断が必要な箇所だけ確認する
- Opus に、整理済みの仕様と受け入れ条件を渡して実装させる
- Opus または別モデルに、差分レビューとテスト観点を確認させる
この流れだと、Fable 5 は「長く考える必要があるところ」に集中できます。
実装そのものは、すでに仕様が整っていれば Opus で十分なことが多いはずです。むしろ、Fable 5 に実装もレビューも全部任せると、検証期間の利用枠を早く消費します。
大事なのは、Fable 5 に完成品を求めることではありません。
Fable 5 に、よい実装が生まれるための条件を作らせることです。
7月7日までに棚卸ししたいタスク
Fable 5 を使える期間や枠が限られるなら、先に候補タスクを棚卸ししておくべきです。
見るべきなのは、「いま実装したいもの」だけではありません。むしろ、ずっと気になっているが、考えるコストが高くて後回しになっているものです。
| タスク候補 | Fable 5 に任せること | 次に残す成果物 |
|---|---|---|
| 大きすぎるIssue | 論点分解、段階分け、依存関係の整理 | 子Issue案、実装順、完了条件 |
| 複数repoの技術負債 | 影響範囲、共通原因、優先度の整理 | 移行計画、検証リスト、リスク表 |
| 曖昧なプロダクト仕様 | 顧客価値、除外範囲、判断未決事項の抽出 | 仕様書、受け入れ基準、質問リスト |
| AI運用ルール | どこを人間が見るか、どこを機械検証に寄せるか | ワークフロー、レビュー境界、チェックリスト |
| コンテンツ/ナレッジ整理 | 記事、docs、playbook の重複と不足を見つける | 情報設計、統合案、更新計画 |
| 営業・顧客支援の業務 | 反復作業と判断作業を分ける | 自動化候補、テンプレート、例外処理 |
こうしたタスクは、短いチャットで一問一答するより、材料をまとめて渡した方がよいです。
Fable 5 の価値は、断片的な答えではなく、複数の文脈をつなげて「仕事の構造」を見つけるところにあります。
タスクを投げる前に、型を作っておく
Fable 5 を使うなら、プロンプトもその場で雑に書かない方がよいです。
毎回、次の型にそろえるだけで、成果物の再利用性が上がります。
目的:
このタスクで最終的に達成したい状態を書く。
材料:
Issue、PR、設計ドキュメント、ログ、顧客メモ、過去の判断などを列挙する。
制約:
触ってよい範囲、触らない範囲、公開期限、コスト、セキュリティ条件を書く。
出してほしいもの:
1. 主要論点
2. 未確認の前提
3. タスク分解
4. 実装前に決めるべき判断
5. Opus に渡せる実装指示
6. 検証計画
7. 人間が最後に確認すべきポイント
禁止:
この段階ではコードを書かない。まず構造化と判断材料の整理だけを行う。この型で出てきた成果物を、そのまま Issue、ADR、仕様書、ACE Playbook、プロジェクトの運用ルールに残していく。
そうすると、Fable 5 の利用は一回きりの「すごい回答」ではなく、組織のナレッジになります。
仕組み化の対象は、モデルではなく仕事の流れ
高性能モデルが使えるようになると、つい「どのモデルが一番強いか」に意識が向きます。
しかし実務では、モデル比較だけではあまり意味がありません。
重要なのは、仕事の流れのどこに高性能モデルを置くかです。
たとえば、次のように分けます。
- Fable 5: 論点整理、仕様化、タスク分解、リスク分析
- Opus: 実装、複雑な修正、レビュー対応
- Sonnet: 軽い調査、定型的な修正、文章整理
- 人間: 目的設定、公開判断、顧客影響、優先順位
この分解をしておかないと、Fable 5 を使っても、結局「高いチャット」になります。
逆に、Fable 5 が出したタスク分解を Issue に落とし、Opus が実装し、check / build / e2e が機械的に検証し、最後に人間が公開判断をするなら、モデルの能力はワークフロー全体に効きます。
AI仕様駆動開発で大事なのは、まさにここです。
AI に丸投げするのではなく、AI が迷わず動ける仕様、受け入れ条件、検証条件を先に作る。Fable 5 は、その前段を強くするために使うのが自然です。
使用クレジット前提なら、使う前に成果物を決める
7月7日以降は usage credits 経由になるとされています。usage credits は、通常のサブスク枠を超えた利用を従量課金で続けるための仕組みです。
従量課金で使い続ける選択肢はあります。
ただし、その場合は「何時間使ったか」ではなく、「何が残ったか」で評価すべきです。
Fable 5 を使う前に、期待する成果物を決めておく。
- 子Issueが作れる状態になったか
- 実装指示が Opus に渡せる粒度になったか
- リスクと未確認事項が明確になったか
- 人間が判断すべきポイントが減ったか
- 次回以降に再利用できるテンプレートや手順になったか
このどれも残らないなら、Fable 5 を使う意味は薄いです。
逆に、1回の Fable 5 セッションで、大きな仕事の見通し、実装順、検証計画、人間判断の境界が整理されるなら、従量課金でも十分に意味があります。
まとめ
Fable 5 の再解放は、単に「また使えるようになった」というニュースではありません。
限られた枠で、高性能モデルをどこに使うべきかを考えるよい機会です。
私は、Fable 5 は深い洞察、仕様設計、タスク棚卸し、仕組み化に使うのがよいと思っています。コードを書くこと自体は Opus や Sonnet に任せればよい場面が多い。Fable 5 には、その前にある「何を作るべきか」「何を見落としているか」「どう進めると失敗しにくいか」を考えさせる。
7月7日までにやるべきなのは、Fable 5 を触ることではありません。
Fable 5 に考えさせるべきタスクを洗い出すことです。
そして、その出力を Issue、仕様書、検証計画、運用ルールとして残すことです。
高性能モデルは、単発の回答で終わらせると消費になります。
仕事の流れに組み込むと、仕組みになります。