こんにちは、mayaです！
2026年7月、以前に一度公開された Claude Fable 5 が再び使えるようになりました。触った感覚をチームで共有していると、必ず出てくる質問があります。
「で、Fableってどんな時に使えばいいの？」
単価はOpus 4.8の2倍ですが、体感の消費はもっと激しい。かといっていつもOpus/Sonnetでいいわけでもない。
この記事では、日本語圏・英語圏の実践報告を突き合わせて集約した「Fableを使うべき場面と、使うべきでない場面」を判断ガイドとしてまとめます。
TL;DR
Fableは「実行者」ではなく「設計図を描く役」として使う。 これに尽きます。
- ✅ 使う: 設計図作り（スキル・harness・Agent設計）、長時間自律タスク、アーキテクチャ判断、大規模移行の骨格作り
- ❌ 使わない: 日常のコード書き、単発の小修正、セキュリティ関連コード、高速レスポンスが必要な場面、Fableを "常用モデル" にする運用
Fableの性格を一言で
私の感触、そして多くの開発者の発信を見ていて、しっくり来ている捉え方があります。
Fableは、設計図を描くモデル。
タスクのほとんどの工程においてFableはオーバースペック。大抵はOpusやSonnet5で十分です。（これまでがそうだったように）
Fable自身に手を動かさせるより、Fableに「他のAIや人間が実装するための設計図」を描かせるところに真価があります。
英語圏の開発者たちも、独自の言葉で同じ地点に辿り着いています。
- Ethan Mollick: 「I am no longer sure I am the wizard. I am closer to a patron.（もう自分は魔法使いではない。パトロンに近い）」
- Every (Dan Shipper): 「Objectives, not tasks.（タスクではなく目的を渡せ）」
- Simon Willison: 「Big model smell（デカいモデル特有の匂い）」「Relentlessly proactive（容赦なく能動的）」
言葉は違うけど、行き先は同じ。「Fableに『何を作れ』と指示するのではなく、『何を達成したいか』を渡してそのための設計自体を描かせる」という使い方です。
✅ Fableを使うべき3つの場面
1. 設計図作り（Skill / Harness / Agent設計）
一番効くのはここです。Fableが使えなくなっても、Fableに作らせた設計図（スキル・ハーネス）は今後も働き続けます。
私が実際に活用したユースケースがこちら
- Claude Codeのカスタムスキル・エージェントを、要件から逆算して書かせる
- 複数スキル・エージェントの自律連携や自動化の仕組みを設計させる
- 既存の実装エージェント、ブログ執筆エージェント、調査エージェントの改良
- CLAUDE.md やガードレールの棚卸し・リライト
いずれも、人やAIが動くための「設計図」を作る作業です。
適切な設計図があれば、下位モデルでもきちんと期待水準の仕事を返してくれるようになります。
FableはOpushの2倍の料金ですが、その後の下位モデルのパフォーマンスが向上するならば特別高いとは思いません。
「設備投資/初期投資」という言葉がしっくりきます。
2. 長時間自律タスク
数時間〜数日走らせる系のタスクは、Fableの独壇場です。
明らかにOpusに任せるより性能が良いです。以下は私の活用事例です
- 依存関係のある十数タスクを順次処理：各タスクをサブエージェント（Opus）に委任し、Fableが指示・進捗管理役として振る舞い完遂
- 新旧環境の仕様の差分を網羅チェック：リプレイスプロジェクトにて、新旧環境の仕様の差分を網羅的に洗い出し、新環境の修正Issueを起票
他にも、ネットを見てると以下のような事例が多数確認できました
- Stripeの事例: Stripeは5,000万行のRubyコードベース移行を1日で完了（従来見積り2ヶ月）
- Ethan Mollickの事例: 15ページの spec を渡して9.5時間自律実行、Sonnet系サブエージェントを起動して並列調査
- Zvi Mowshowitzの事例: Victor TaelinがHVM5で1770%高速化＋気付いていないバグを発見「my personal singularity moment」
Cursor / Cognition / Cline のベンチマークでもリードは明確です。
| ベンチマーク | Fable 5 | Opus 4.8 | GPT-5.5 |
|---|---|---|---|
| SWE-Bench Pro | 80.3% | 69.2% | 58.6% |
| CursorBench | 72.9% | — | 64.3% |
| Every Senior Engineer Bench | 91/100 | 63 | 62 |
| Cline Terminal-Bench 2.1 | 88.0% | — | 83.4% |
（出典: Cursor / Cognition / Cline 各社公表のベンチマーク。詳細は末尾の参考リンク）
FableはOpusなどの下位モデルをサブエージェントとして使い回す、オーケストレーションするのが非常にうまいです。
メインセッション（Fable）のコンテキスト消費を最小限に、実作業をサブエージェントに委任させることで長時間タスクも難なくこなします。
3. アーキテクチャ判断・レビュー役
もう1つ、Fableが一段抜けて強いのがメタ認知系の作業です。
人間が何をやろうとしているのか、その「完成形を先に想像する力」を汲み取る力が強い。
- 実装済みAgent運用ルールの棚卸し・診断
- 曖昧な要件や設計の構造化・複数論点の横断整理
- 「何を作らないか」「何をやめるか」を含む設計判断
- 作りかけの成果物や画像から「これは何を作ろうとしているか」を推定して補完
このように、**「抽象度や難易度が上がるほど優位性が高まる」**のがFableの性格だと思います。
逆に低難度タスクではOpus 4.8とほぼ変わらない、というより「速度・単価を考えるとOpusのほうが良い」場面が多い。
❌ Fableを使うべきでない場面（アンチパターン）
同じくらい大事なのがこっちです。
常用モデルとして丸投げする
- トークン消費が桁違い。Claude Max 20xでも数時間でusage limitに到達
- 実効コストはOpus 4.8の2倍どころか3〜5倍になりがち。Simon WillisonはCSS 2行修正で$12、1日で$110消費。HN上には「1タスクで$2K溶かした」報告も
- Pro/Maxの週次50%無料枠は別枠ではなく内数
「難所だけFable、あとはSonnet/Opus」の分業運用がベストプラクティスとして浸透しつつあります。
日常のコード書き・単発の小修正
低難度タスクでは Opus 4.8 とスコアがほぼ変わらず、速度と単価を考えればむしろ Opus / Sonnet のほうが良い場面が多い。「CSS 2行直すだけ」のような単発の小修正に Fable を持ち出すのは、設計事務所にネジ1本の締め直しを頼むようなものです。日々のコード書きは Sonnet / Opus に任せ、Fableは難所の設計に温存しましょう。
セキュリティ関連コード生成
Fableはセキュリティ観点での悪用を防ぐため、ケースに応じて内部的にOpusにフォールバックすることがあります。
7月の再デプロイでセーフガードがさらに強化され、通常コーディングでも正当なリクエストが誤フラグされる報告が増えました。
認証周りやCVE解析、パッチ生成のように「セキュリティ隣接領域」に触れるコード生成は、素直にOpus 4.8を使ったほうが良い可能性が高いです。
高速レスポンスが必要な場面
effort=medium でもOpus 4.8 xhighの倍以上遅い体感、という報告が複数あります。チャットボット、リアルタイム補完、ユーザー待たせる系のインタラクションには不向きです。
過剰生成・過剰リファクタを許す運用
Fableは**「頼んでいない考察を勝手に整理して順位付けする」傾向、「指示していない他人のブランチをpullして調査する」**自律性の暴走が報告されています。よく言えば relentlessly proactive、悪く言えば余計なお世話。プロンプトには「何をしないか」「範囲」「停止条件」を明記しましょう。
Fableを使うときのコツ
Fable 5 を「アドバイザー」として使う
実行役のSonnet 5が、迷ったときだけFable 5にガイダンスを求めるパターン。
ほとんどのトークンがSonnet 5単価で消費されます。
- Fable5で動くアドバイザースキル/エージェントを用意しておく
- CLAUDE.mdに「困ったらアドバイザーエージェントに相談して」と書いておく
- Sonnet 5やOpusが困ったときだけFable5が起動する
Anthropic 公式（ClaudeDevs）が、紹介している手法にも似たようなものがあります。
公式の実測数値は以下の通り。
- SWE-bench Pro: Fable 5 単体スコアの約92% を、価格の約63% で達成
- Fable 5 の呼び出しはタスクあたり平均1回程度
Fable 5 を「オーケストレーター」として使う
Fable 5が計画を立て、下位モデルのワーカーサブエージェントに委任するパターン。
作業のほとんどをSonnet 5などの下位モデルに行わせることで、Fableのトークン消費を抑えます
- CLAUDE.mdに「設計はFable、実作業はOpusのサブエージェントに行わせる」と書いておく
- あるいはFableモデル用のオーケストレーションスキルを作る
こちらもAnthropic 公式（ClaudeDevs）が、同じような手法を紹介しています。
- BrowseComp: Fable 5 単体スコアの約96% を、価格の約46% で達成
プロンプト設計の要点（公式ガイドから）
Anthropic 公式の Claude Fable 5 のプロンプティングガイド から、押さえておくと事故が減る要点だけ抜粋します。
-
エフォートは低めから始める: Fable の
lowでも従来モデルのxhighを超えることが多い。足りなければ上げる - 「何をしないか」を明示する: 依頼されないメール下書きや過剰リファクタなど、勝手なアクションを封じる
- 動作をいちいち列挙しない: 細かい do/don't リストは逆効果。「Lead with the outcome.」のように方向性だけ渡す
- 長時間タスクは進捗を実証させる: 「ツール結果と照らして監査してから報告せよ」の一文で捏造報告がほぼ消える
-
「なぜ」を一緒に渡す:
[大きな目的] のために [誰] が [何を可能にする] 必要がある。だから [依頼]のテンプレで精度が上がる
Fable向けプロンプト生成スキルを作るのがおすすめ
ここまでの要点を毎回頭に入れて書き分けるのは現実的ではありません。実務でおすすめの運用は、上記の公式ドキュメントをベースにした「Fable向けプロンプトを書くスキル」を作り、日々のプロンプトはOpus / Sonnet などにそのスキル経由で生成させるという形です。
- Skill の instructions に公式ガイドの要点を落とし込む（エフォート指定・境界明示・進捗監査・独立検証・memory・send-to-user・why の同梱）
- 入力は「ゴール／範囲／完了条件／想定 effort レベル」
- 出力は上記要点を組み込んだ Fable 向けプロンプト
このスキル自体を一度 Fable に書かせて、日々の運用では Opus / Sonnet に食わせる。**「設計図（このスキル）を Fable に描かせて、実行は Sonnet に流す」**という、記事全体で述べてきた設計士パターンそのものです。
コストの物差しを変える
Fableのコストは per-call の費用対効果で評価しない。設計事務所を「引いた線の本数」で評価しないのと同じで、「設計図を描かせて、その設計図から生まれるアウトカムで回収する」という物差しに切り替えるほうが判断がぶれません。
まとめ：迷ったときの早見表
Fableは「実行者」ではなく「設計士」として使う。 これが日英コミュニティが辿り着いた結論です。「で、結局どう使うんだっけ？」とド忘れしたら、ここだけ見返せば思い出せるようにまとめておきます。
まず、この3択で振り分ける
| タスクの性質 | 使うモデル |
|---|---|
| 難しい・曖昧・長時間 | Fable |
| 実装・量産・日常業務 | Opus / Sonnet |
| 危険（セキュリティ隣接）・高速・小粒 | Fable以外 |
✅ Fableを使う場面
| 場面 | 具体例 |
|---|---|
| 設計図作り | Skill / Harness / Agent設計、CLAUDE.md・ガードレール整備、実装前の指示書づくり |
| 長時間自律タスク | 数時間〜数日の自律実行、大規模移行の骨格、サブエージェント（Opus/Sonnet）のオーケストレーション |
| アーキテクチャ判断・レビュー | 曖昧な論点の構造化、「何を作らないか」の設計判断、運用ルールの棚卸し |
❌ Fableを使わない場面（と、その理由）
| 避ける場面 | 理由 |
|---|---|
| 常用モデルとして丸投げ | コストが2倍どころか3〜5倍に膨らむ |
| 日常のコード書き・単発の小修正 | 低難度ではOpus/Sonnetのほうが速くて安い |
| セキュリティ関連コード | セーフガードで誤フラグ・Opusフォールバックが起きやすい |
| 隣接領域（生物・化学・医療・食品）を含む会話 | 途中でOpusに降格される可能性 |
| 同一会話でのモデル比較 | アンカリングで公平に比較できない |
| 高速レスポンス用途 |
effort=medium でもOpus xhighの倍以上遅い |
🛠 使うときにやること
① 分業パターンを仕込んでおく
- アドバイザー型: 実行はSonnet / Opus、迷ったときだけFableに相談。CLAUDE.mdに「困ったらアドバイザーに相談」と書く／アドバイザースキルを用意しておく
- オーケストレーター型: Fableが計画を立て、実作業は下位モデルのサブエージェントに委任。CLAUDE.mdやオーケストレーションスキルに仕込む
② プロンプトの要点を外さない
- エフォートは低めから始める（
lowでも従来のxhigh超えが多い） - 「何をしないか」「範囲」「停止条件」を明記する
- 長時間タスクは「ツール結果と照らして監査してから報告せよ」と指示する
- 「なぜ」を一緒に渡す
③ Fable向けプロンプト生成スキルを用意する
要点を毎回意識するのは大変。公式ガイドを落とし込んだ「Fable向けプロンプト生成スキル」を作り、日々はOpus / Sonnetにそれ経由でプロンプトを生成させる。
④ コストの物差しを変える
Fableが実際に生み出すコードではなく、「設計図から生まれるアウトカム」で回収する設備投資として評価する。
参考リンク（一部）
- Anthropic — Introducing Claude Fable 5 and Mythos 5
- Anthropic — Redeploying Fable 5
- Anthropic — Advisor tool（Fable 5 アドバイザー／オーケストレーター パターン公式ガイド）
- Anthropic — Claude Fable 5 のプロンプティングガイド
- ClaudeDevs (X) — Fable 5 アドバイザー／オーケストレーター パターン紹介ポスト
- Simon Willison — Initial impressions of Claude Fable 5
- Ethan Mollick — What it feels like to work with Mythos
- Every — Vibe Check: Fable 5 Is the Best Coding Model in the World
- Zvi Mowshowitz — Capabilities
- Nathan Lambert — Claude Fable 5 and new safety fables
- Latent Space — Anthropic Claude Fable 5, Mythos but Safe
- Zenn: ますみ / Galirage の徹底解説 / kmizu — 言語の庭 / shinya.hara — Fable 5が帰ってきた
- Qiita: yo_arai — 1日使ってみて / ochtum — プロンプト設計入門
Discussion