日本時間の明日2026年7月2日（米国時間の2026年7月1日）、Fable 5がグローバル再展開されます。
米商務省が輸出管理を解除したことを受け、AnthropicはFable 5を Claude Platform・Claude.ai・Claude Code・Claude Cowork でグローバルに再提供します。Pro / Max / Team / 一部Enterprise プランでは、7月7日まで週間利用上限の最大50%までFable 5が無料枠で含まれ、それ以降は usage credits 経由となります。つまり「試すなら今週」です。本記事は、再展開初日に合わせて公式ドキュメントとコミュニティ知見を統合した実践ガイドです。

この記事の狙い

Fable 5 は「賢くなったチャットボット」ではありません。数時間〜数日、自律的に走り続けるエージェント／チームメンバーとして設計されたモデルです。従来のOpus向けプロンプトをそのまま持ち込むと、むしろ性能が落ちたり、そもそもrefusalで弾かれてFableで動かなくなったりします。

本記事は2部構成です。

第1部:技術的一般論・理論 — Fableが何者で、なぜ従来と違う扱いが要るのか
第2部:すぐ使える実践術 — テンプレート・落とし穴・チェックリスト

⚠️ 注意①:　挙動・価格・アクセス可否は変わります。特にアクセス状況は流動的なので、本番導入前に必ず Anthropic公式ドキュメントと公式ニュースで最新を確認してください。
⚠️ 注意②:　バズったデモやシステムプロンプトリークの類は真偽・再現性が未確認のものが多く、本記事では仕様の根拠としては扱いません。

第1部:技術的一般論・理論 — Fable 5とは何者か

1-1. Mythosクラスという新ティア

Fable 5 は、AnthropicがOpusクラスの上に置いた Mythosクラス の一般公開モデルです。同じ土台のモデルに安全策（セーフガード）を付けたものが Fable 5、外したものが Mythos 5（Project Glasswing の限定提供）という関係です。名前の由来は、ラテン語 fabula（＝語られるもの）で、ギリシャ語の mythos と同根です。

主要スペックは以下の通り。

項目	内容
コンテキスト	1M トークン（デフォルト）
出力上限	128K トークン／リクエスト
価格	入力 $10 / 出力 $50（per 1M tokens、Opus 4.8の約2倍）
Thinkingモード	Adaptive thinking のみ（常時ON、`disabled`不可）
特性	長時間・複雑・曖昧なタスクほど強い
データ保持	30日保持が必須（zero data retention 不可、Covered Model指定）

価格が高いのは事実で、長時間ループは容易に高額になります。予算設計・キャッシュ活用・effort調整はコストと直結します（詳細は第2部）。

1-2. 「長ければ長いほど強い」— 設計思想

Fable 5 の核心は、タスクが長く複雑なほど他モデルとの差が開く点にあります。従来なら人間が数時間〜数週間かける仕事、たとえば大規模コード移行、複数段階の分析、複雑なエージェントフロー、文書横断リサーチ、高精度なビジョン理解 — こうした「重い一枚仕事」でこそ本領を発揮します。

逆に言うと、スネークゲームやToDoアプリのような簡単なタスクだけで試すと、その能力レンジを過小評価しがちです。「自分が旧モデルには振らなかった難問」から試すのが公式の推奨です。

1-3. 従来モデルと決定的に違う5つの挙動

移行時に理解すべき、Fable特有の挙動です。

指示遵守が極端に強い
詳細なステップリストを並べると、それに文字通り従おうとして柔軟性を失います。「手順」より「目的と境界」を渡すべき理由がこれです。
より能動的（proactive）
頼んでいないのにメールを下書きしたり、バックアップブランチを作ったり、スコープを広げたりします。「評価だけしてほしいのか、実行までしてよいのか」を明示しないと勝手に動きます。
Evidenceベースだが、放置すると楽観的報告をしがち
長時間実行では、ツール結果の裏付けなしに「それらしい進捗報告」を出すことがあります。報告前にツール実行結果と照合（監査）させる指示が信頼性の要です。
TTFT（最初のトークンまでの時間）が長い
高難度タスクは高effort設定で数分〜、自律実行は数時間に及ぶことも。これが「対話的なターン連発に向かない／全仕様を前もって投入すべき」理由の根っこです。クライアントのタイムアウト・ストリーミング・進捗表示は移行前に見直しが必要です。
セーフガードが強い
サイバーセキュリティ・生物・化学系はrefusalが出て Opus 4.8 にフォールバックしやすい。これは能力の欠如ではなく、意図的に保守的にチューニングされた分類器の作用です（誤検知は5%未満のセッションで発生、とされます）。

1-4. 【最重要・見落とされがち】refusalは「使い方」ではなく「動くかどうか」を左右する

コミュニティ記事で「効率の話」として扱われがちだが、実はFableで動くか否かを分ける論点が2つあります。これは本記事で最も強調したいポイントです。

① 「思考過程を出力させる」指示が refusal を誘発する

「ステップバイステップで考えて」「思考過程をすべて見せて」がNGな本当の理由は、過剰計画を招くからだけではありません。 内部推論を応答テキストとしてecho・書き起こし・説明させるプロンプトは、reasoning_extraction という refusal カテゴリを発火させ、Opus 4.8へのフォールバックを増やします。

対策: 旧Opus向けのスキルやシステムプロンプトに残っている「reflection」「show your thinking」系の指示を移行時に監査・削除する。
推論を見たいなら: 応答に再現させるのではなく、Adaptive thinking の構造化thinkingブロック（thinking.display: "summarized"）を読む。長時間実行中の進捗はsend-to-userツールで surface する。

② `budget_tokens` は非対応（400エラー）

旧世代（Opus 4.6/Sonnet 4.6）向けのハーネスをそのまま移植すると詰まります。Fable 5 / Mythos 5 で budget_tokens を設定すると 400 エラーを返します。thinkingの深さは effort パラメータで制御してください。

第2部:すぐ使える実践術

2-1. マインドセット:プロンプトではなく「システム」を組む

launch週にバズった合言葉が "You're not supposed to prompt Claude. You're supposed to build a system that prompts itself." です。Fableは「チャット相手」ではなく「チームリード／コンサルタント」として扱う、というコンセンサスです。

具体的には、単発プロンプトより以下を組み合わせます。

CLAUDE.md / プロジェクトルール（.cursorrules相当をルートに常設）
Memoryファイル(.md で教訓を蓄積)
Sub-agents(並列委譲・独立検証)
Artifactsの永続ストレージ / キャッシュ

そして重要なのは:旧Opus向けに作り込んだ細かいプロンプトやスキルは、Fableでは逆効果になり得ます。 移行は「モデル名の差し替え」ではなく、タスク境界・検証方法・長時間インタラクションの再設計です。

2-2. すぐ使える基本テンプレート(5要素)

Fableには「手順」ではなく「条件とゴール」を渡します。まずはこの5要素から。

目的(Why): なぜこのタスクをするのか。誰のためで、成果物で何が可能になるのか。
成果物: 最終的に何を、どんなフォーマットで出してほしいか。
範囲: やること / やらないこと(スコープの境界)。
完了条件: どの状態になったら「完了」とみなすか(停止条件)。
検証方法: 正しさをどう確認するか(テスト・ツール結果など)。

ポイント: 目的を最初に、簡潔に。ルールを20個並べるより、目的・境界・出力形式・制約を短く渡すほうが効きます。難しいタスクでは "This is a hard / hardest-unsolved problem" と明示して、undersellしないこと。良い例を 10個の指示より1つのリファレンス で見せるのも効果的です。

2-3. 長時間エージェント向けの追加ブロック

長時間・自律実行タスクには、上記に加えて以下を初回メッセージに詰め込みます(TTFTが長いので「後から小出し」は非効率)。

【自律動作指示】
あなたは自律的に動作しています。ユーザーはリアルタイムで監視していません。
元の依頼から自然に導かれる「可逆的な行動」は、確認を求めず進めてください。
不可逆な行動(削除・設定変更など)、スコープ変更、ユーザーしか判断できない
情報が必要な場合は、そこで止めて確認を求めてください。

【進捗報告ルール】
進捗を報告する前に、必ずこのセッション内のツール実行結果と照合して監査すること。
検証できていない事項は「未検証」と明記し、失敗したテストは実際の出力とともに報告すること。

【境界設定】
分析を依頼された場合は、分析結果のみを報告し、修正は行わないこと。
修正はユーザーが明示的に依頼したときだけ行うこと。

【最終報告の形式】
Outcome first(TLDR)で。結論→根拠→リスク→次アクションの順。
作業中の略記・矢印チェーン・内部ラベルをそのままユーザーに出さないこと。

💡 最後の「最終報告の形式」は地味だが重要。長時間のツール実行後、モデルは大量の内部コンテキストを抱え、最終要約が「本人にしか分からない略記」になりがちです。Outcome first を明示して防ぎます。

2-4. Effortレベルの使い分け(と、名称の注意)

effort はFableのコストと品質を握るレバーです。最高effortでは、返す前にモデルが自分の作業を反省・検証します(launchパートナーのRakutenが「自律運用を現実にするのはこれ」と評価した挙動)。

基本方針: 普段は high、本気で難しいタスクだけ上位設定。デフォルトで最大化しない。難易度に合わせる。
注意: effortの段階名は情報源によって記述が割れています(high / xhigh / ultracode 系の記述と、low / medium / high 系の記述が混在)。暗記して他環境に流用せず、自分が実際に使う環境(API / claude.ai / Claude Code)で選べる値を確認してください。

用途	工夫ポイント
短時間タスク	目的＋成果物＋フォーマットを明確に。過剰に詳細を書かない
長時間エージェント	初回に全仕様を投入。Memoryファイル活用
コーディング	CLAUDE.mdにルール記載。テスト・レビューをサブエージェントに分担
調査・研究	「Lead with the outcome(結論を先に)」を必ず入れる
クリエイティブ	バリエーションが欲しければ「3パターン生成して」と明示

2-5. サブエージェント:委譲＋「独立検証」の2レイヤー

Fableは並列サブエージェントの起動・維持が旧モデルより格段に安定しています。使い方は2つ。

委譲(delegation): 独立した下位タスクを並列に投げ、メインスレッドは進め続け、脱線したら介入する。
独立検証(verifier): ここが公式の踏み込みどころ。自己批判だけに頼らず、独立した検証役のサブエージェントを立てる。これで「モデルが自分を正しいと思い込む」問題を減らせます。

「Evidence監査(2-3のブロック)」と「検証サブエージェント」は別レイヤーです。両方あると信頼性が大きく上がります。

2-6. Memory:履歴コピペではなく「再利用可能な教訓」

Fableはメモリ活用の投資対効果が特に大きいモデルです(公式の launch 結果では、ファイルベースの永続メモリタスクが Fable の性能を Opus 4.8 の約3倍 改善)。

鍵は「チャット履歴のコピー」ではなく「再利用可能な教訓の保存」。 1ファイル1教訓で蓄積します。

# lessons/001-login-ux.md
**教訓**: 初回ユーザー向けには「即時フィードバック」が最も効いた。
**背景**: ...
**適用条件**: ...

プロンプト内で「lessons/ フォルダを参照して判断せよ」と指示すると効果的。加えて、

完了した作業は短い要約に圧縮して context rot とコストを抑える。
Retrieve, don't recall — プロンプトに全部詰めず、そのステップに必要なスライスだけ引く。

2-7. send_to_user ツールの落とし穴

長時間タスクの途中で成果物をユーザーに見せたいなら send-to-user ツールが有効です。ただし定義するだけでは、Fableはめったに呼びません。 システムプロンプトに明示的な呼び出し指示が必要です。

ツール呼び出しの合間に、ユーザーが逐語で読むべき内容(部分成果物や質問への直接回答)が
できたら、その内容で send_to_user ツールを呼ぶこと。
send_to_user はユーザー向けコンテンツ専用。ナレーションや内部推論には使わないこと。

2-8. 避けるべきNGパターン

「ステップバイステップで考えて」 → 過剰計画を招くうえ、reasoning_extraction refusal を誘発しうる(第1部1-4参照)。
ルールを20個並べる → 文字通り守ろうとして柔軟性が死ぬ。
「残りトークンが少ないのでまとめて」 → 早めに切り上げてしまう。
リアルタイム確認前提の指示(「次どうする?」の連発) → 自律性を阻害し、TTFTの長さと最悪の相性。
旧Opus向けの reflection / show-your-thinking 指示を残したまま移行 → フォールバック増加。
budget_tokens の設定 → 400エラー。

2-9. refusal が出たときの備え

Fableがrefusalを返すと、API上は エラーではなく stop_reason: "refusal"(HTTP 200) で返り、どの分類器が弾いたかも示されます。本番では最初からフォールバックを組んでおきます。

サーバーサイド: fallbacks パラメータでAPI側に自動リトライさせる(beta)。
クライアントサイド: 各SDKのミドルウェアでリトライ。
課金: 出力生成前に拒否されたリクエストは課金されない。別モデルへリトライする際、fallback creditがプロンプトキャッシュ切替コストを還付するので二重払いを避けられる。

2-10. コスト最適化の実務

$10/$50 の価格では、プロンプト構造がそのままコストに響きます。

安いモデルで骨子を固める: プロンプトのたたき台は Sonnet / Opus で作り込んでから Fable に上げる。
キャッシュを積極活用: 安定した接頭辞(cached prefix)には割引が効く。
少数リッチターン: TTFTが高いので、多数の小ターンより、前もって全部投入して一発で終わらせる。
完了ワークストリームは要約に圧縮して context を軽く保つ。

まとめ:Fable 5 を強く使う5原則

Why を強く — 何を達成したいか、誰のためかを最初に。
境界と検証方法を必ず入れる — やらないこと、正しさの確認方法。
手順より条件とゴールを渡す — 過剰指示を削るのが一番効く。
Memory とサブエージェント — 教訓の蓄積と、委譲＋独立検証。
「動かすための前提」を先に潰す — reasoning抽出指示の削除、send_to_userの明示指示、budget_tokens非対応、フォールバック設計。

Fable 5 は「賢いアシスタント」ではなく「優秀な自律エージェント」です。人間が細かく指示するより、ゴールと制約を渡して任せるスタイルが最も相性が良い。そして本日から週間上限の最大50%が無料で使える枠は 7月7日まで。試すなら、いつもの簡単タスクではなく、**あなたの「一番難しい未解決の問題」**をぶつけてみてください。

参考(一次情報を優先)

Anthropic「Redeploying Claude Fable 5」(7/1再展開・無料枠の条件)
Anthropic「Claude Fable 5 and Claude Mythos 5」(モデル概要・セーフガード)
Claude Platform Docs「Prompting Claude Fable 5」(effort・指示遵守・memory・reasoning_extraction)
Claude Platform Docs「Introducing Claude Fable 5 and Claude Mythos 5」(スペック・refusal・fallback・課金)
Claude Platform Docs「Prompting best practices」(adaptive thinking・budget_tokens非対応)

※本記事の技術記述は上記公式ドキュメントに基づきます。バズったデモや非公式のシステムプロンプトリークは、再現性・真偽が未確認のため仕様の根拠としては扱っていません。導入前に必ず公式で最新の挙動・価格・アクセス可否をご確認ください。