Claude Fable 5.1 — 3つの破壊的変更と5つの追加機能、Fable 5からの移行で押さえるべきこと

Fable 5.1は「同じ値段で速く・安く・長く動く」後継モデル

2026年9月1日、Anthropicは Claude Fable 5.1 と Claude Mythos 5.1 をリリースしました。 Fable 5.1は2026年6月に登場した Claude Fable 5 の後継で、Anthropicが一般提供するモデルとしては最上位に位置します。 モデルIDは claude-fable-5-1 です。

発表を一言でまとめると、「入出力の単価は据え置き、キャッシュ読み取りだけ4分の1に値下げ。その上でエージェント系ベンチマークが大きく伸びた」モデルです。 ただしAPI利用者にとって重要なのは性能の話だけではありません。Fable 5から移行すると3つの破壊的変更があり、特に「preserved thinking（保持された思考）」は自前でエージェントループを組んでいる人ほど影響を受けます。 この記事では、公式発表・What's new・移行ガイドの内容を「何が伸びたか」「何が壊れるか」「何を新しく使えるか」の3軸で整理します。

位置づけ：Opus 5との使い分けとMythos 5.1との関係

Anthropicの公式ドキュメントは、Fable 5.1を「デフォルトで選ぶモデル」とは位置づけていません。 推奨は「まずOpus 5で始め、高度な推論や長時間のエージェント処理が必要な場合、あるいはOpus 5をeffort高めで回しても評価が届かない場合にFable 5.1を使う」という順序です。 料金がOpus 5の2倍（入力$10 / 出力$50 per MTok）である以上、まずは安い方で試すのが合理的という考え方です。

もう一つ押さえておきたいのが Claude Mythos 5.1 との関係です。Fable 5.1とMythos 5.1は同一のモデルで、違いは安全対策の構成とアクセス経路だけです。 Mythos 5.1はサイバーセキュリティや生命科学の専門家向けに安全対策を緩めた版で、Project Glasswingという審査制プログラムの参加組織にしか提供されません。 逆にいえば、Fable 5.1には攻撃的セキュリティや研究生物学を対象とした安全分類器が組み込まれており、これらの分野の正当な作業でも稀に誤検知（false positive）が起きます。

ベンチマークで見る伸び

公式発表のベンチマークで最も目立つのはTerminal-Bench-Science（エージェントによる科学研究タスク）で、Fable 5の24.7%から52.6%へ倍増しています。 エージェントコーディングのTerminal-Bench 4.0も42.0%から55.8%へ、ビジネスワークフロー自動化のAutomationBenchも17.1%から31.4%へと、いずれも「長時間・多段階のエージェント処理」で差が開いています。

一方で、知識労働の総合指標であるGDPval-AA v2は1723から1853、ツールなしのHumanity's Last Examは57.8%から60.9%と、伸び幅は相対的に小さめです。 つまりFable 5.1の改善は「賢さ全般が一段上がった」というより、「何時間も自律的に動き続けるタスクで崩れにくくなった」方向に集中しています。 公式ドキュメントも、改善が集中する領域として次の6つを挙げています。

• 長時間セッションのエージェントコーディング：複数ファイルにまたがる機能追加、大規模リファクタ・移行、数時間に及ぶデバッグとコードレビュー
• ドキュメント・スプレッドシート・スライドの作成：最初の質問から、完成した文書・数式入りスプレッドシート・スライドまで白紙から仕上げる
• リサーチと検索：見つけた情報をもとに追跡調査を重ねる多段階Web調査
• ビジョン：PDF内の密なチャート・財務資料・入れ子のテーブル。クロップ・ズームのツールを与えると最も強い
• ロングコンテキスト：1Mトークンの奥深くにある情報の検索と接続
• コンピュータ操作：ブラウザやデスクトップアプリの操作と、失敗からの復帰

料金：単価は同じ、キャッシュ読み取りだけ4分の1に

Fable 5.1の料金表はFable 5とほぼ同じですが、キャッシュ読み取りが$1.00から$0.25 per MTokに値下げされました。 他のClaudeモデルではキャッシュ読み取りは基本入力単価の0.1倍ですが、Fable 5.1では0.025倍です。

この値下げが効くのは、長いプレフィックスを繰り返し読み直すエージェントセッションです。 ツール呼び出しを何十回も重ねるループでは、毎ターンの入力トークンの大半がキャッシュヒットになるため、Anthropicは典型的なワークロードで約25%、エージェント性の高いワークロードでは最大45%のコスト削減になると説明しています。

裏を返すと、キャッシュミスの相対コストが跳ね上がったということでもあります。ヒット時が0.025倍、ミス時が1倍なので、その差は40倍です。 後述するper-message effortやturn-scoped system messageは、まさに「キャッシュを壊さずにエージェントループを制御する」ための道具として用意されています。

3つの破壊的変更

Fable 5から移行する場合、APIの互換性が壊れるのは以下の3点です。 いずれもエージェントループを自前で組んでいる場合に影響が大きく、Claude Code・claude.ai・Managed Agents・Agent SDKを使っている場合はハーネス側が面倒を見てくれます。

① forced tool useが400エラーになる

tool_choice に {"type": "any"} または {"type": "tool", "name": "..."} を指定すると、Fable 5.1では400エラーになります。 Messages APIだけでなく、Message Batches APIとトークンカウントAPIでも同様です。

tool_choice: type "tool" and "any" are not supported for this model.

理由は「thinkingが常時ONだから」です。強制的にツールを呼ばせると思考ステップが飛ばされ、モデルが考察をツール引数に書き込んでしまい、引数の品質が落ちます。 Fable 5やOpus 5もthinkingはデフォルトONですが、forced tool useは受け付けているため、これはFable 5.1固有の制限です。

移行は「何のために強制していたか」で分かれます。

// Before: Fable 5.1では400エラー
const before = await client.messages.create({
  model: 'claude-fable-5',
  max_tokens: 4096,
  tools: [getWeatherTool],
  tool_choice: { type: 'tool', name: 'get_weather' },
  messages: [{ role: 'user', content: '東京の天気を確認して要約して' }],
});

// After: 思考させた上でツールを名指しし、スキーマ保証は strict で担保する
const after = await client.messages.create({
  model: 'claude-fable-5-1',
  max_tokens: 4096,
  tools: [{ ...getWeatherTool, strict: true }],
  tool_choice: { type: 'auto' },
  messages: [
    { role: 'user', content: 'get_weatherツールを使って東京の天気を確認し、要約して' },
  ],
});

② thinking blockは生成したモデル以外が読めない

すべてのthinking blockには「どのモデルが生成したか」が記録されるようになり、Fable 5.1が生成したthinking blockはFable 5.1とMythos 5.1しか読めません。 逆方向は通ります。Opus 5やFable 5で始めた会話をFable 5.1に切り替えた場合、過去の推論はそのまま引き継がれます。

読めないブロックを含むリクエストを送っても、エラーにはなりません。APIがモデルに渡す前にそのブロックを落とし、リクエストは成功します。 落とされたブロックは input_tokens に含まれず課金もされません。 ただし切り替え先のモデルは推論なしで再計画することになるため、切り替え直後のターンはコストとレイテンシが上がります。

実務でこれが起きるのは、ルーターによるモデル切り替え、別モデルへのクライアント側リトライ、そして安全分類器の拒否に対するフォールバックです。 フォールバック先のOpus 4.8 / Opus 5はFable 5.1のthinking blockを読めないため、拒否からのフォールバック時はこの「推論の消失」が必ず発生します。

③ 過去ターンを編集すると以降のthinking blockが無効になる

3つの中で最も影響が大きいのがこれです。公式ドキュメントは②とあわせて「preserved thinking（保持された思考）」と呼んでいます。

Fable 5.1のthinking blockの signature には、そのブロックを生成した時点の会話プレフィックスが記録されます。 具体的にはトップレベルの system プロンプト、tools の集合、そのブロックより前のすべてのメッセージです。 次のリクエストでこのプレフィックスが変わっていると、APIは「このブロックは別の会話に紐づいている」と判断し、400エラーを返します。

messages.5.content.0: Invalid `signature` in `thinking` block. The block is
bound to a different conversation. Remove the block, or set
`thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That
setting requires the `thinking-binding-controls-2026-08-01` value in the
`anthropic-beta` header.

このチェックは2026年8月31日以降に作成された新規アカウントに対して強制されます。それより前のアカウントではAPIが不一致を記録するだけで、リクエスト側が prefix_mismatch_behavior を明示するまで動作は変わりません。 ただしAnthropicは将来のモデルで全アカウントに強制する方針を明言しているので、今のうちに対応しておく必要があります。

flowchart TD
    subgraph OK["有効なまま（append-only）"]
        A1["新しいターンを末尾に追加"]
        A2["role: system メッセージを追加"]
        A3["先頭のthinking blockを古い順に削除"]
        A4["サーバー側compaction / context editing"]
        A5["max_tokens・effort・cache_controlの変更"]
    end
    subgraph NG["以降のthinking blockが無効化"]
        B1["過去ターンの編集・並べ替え・削除"]
        B2["リマインダーを注入して次回削除"]
        B3["systemプロンプトやtoolsの再構築"]
        B4["途中のthinking blockだけ削除"]
        B5["古いtool_resultのクライアント側削除"]
    end
    OK --> R1["200 OK"]
    NG --> R2["400 error<br/>（drop_block指定時はブロックを落として続行）"]

逆に、次の操作は編集とみなされません。

• 履歴の末尾にターンを追加する（role: "system" メッセージの追加を含む）
• 先頭のthinking blockを古い順に削除する（途中のブロックだけ抜くのはNG）
• サーバー側のcompactionやcontext editing（チェックは「送信した会話」に対して行われるため、サーバー側の編集は対象外）
• system / tools / messages 以外のパラメータ変更（max_tokens、output_config.effort、cache_control の位置など）
• 同じバイト列を返す署名付きURLのローテーション（URL文字列ではなくバイト列が束縛される）

エラーではなく「落として続行」させたい場合は、ベータヘッダーとあわせて prefix_mismatch_behavior を明示します。

const response = await client.beta.messages.create({
  model: 'claude-fable-5-1',
  max_tokens: 4096,
  betas: ['thinking-binding-controls-2026-08-01'],
  thinking: {
    type: 'adaptive',
    block_binding: { prefix_mismatch_behavior: 'drop_block' }, // または 'error'
  },
  messages: history, // thinking blockをそのまま含む全履歴
});

// 落とされたブロックは input_transformations に報告される
for (const t of response.input_transformations ?? []) {
  console.log(t.type, t.path, t.reason);
  // 例: thinking_dropped messages.1.content.0 prefix_binding_mismatch
}

5つの追加機能

破壊的変更と対になる形で、5つの機能が追加されました。 うち3つはベータヘッダーが必要で、いずれも「履歴を編集せずにエージェントループを制御する」という同じ目的を持っています。

① per-message effort：キャッシュを壊さずeffortを変える

content が空の role: "system" メッセージに output_config.effort を付けて履歴に追加すると、その位置以降のeffortを変更できます。 トップレベルの output_config.effort をリクエストごとに変えるとプロンプトキャッシュが作り直されますが、この方式なら履歴への追記なのでキャッシュが維持されます。 ベータヘッダー mid-conversation-output-config-2026-07-01 が必要で、Fable 5.1・Mythos 5.1・Opus 5で使えます。

const response = await client.beta.messages.create({
  model: 'claude-fable-5-1',
  max_tokens: 4096,
  output_config: { effort: 'high' },
  betas: ['mid-conversation-output-config-2026-07-01'],
  messages: [
    { role: 'user', content: 'SQLiteからPostgreSQLへの移行計画を3ステップで立てて' },
    { role: 'assistant', content: '1. SQLiteのデータをエクスポート 2. PostgreSQLのスキーマ作成 3. インポートして行数を検証' },
    // effort専用のsystemメッセージ。次のuserターンから効く
    { role: 'system', content: [], output_config: { effort: 'low' } },
    { role: 'user', content: '計画を1文で要約して' },
  ],
});

effort専用メッセージはテキストを持たないため、通常のmid-conversation system messageの配置ルール（userメッセージの後に置く等）が適用されず、履歴のどこにでも置けます。 下げる方向は確実に効きますが、上げる方向は low から xhigh のような大きなジャンプでないと効きにくいとされています。

② turn-scoped system message：1ターンだけ効くリマインダー

エージェントループでは「実行前に受信箱を確認して」「ユーザーにはそのツール出力は見えていない」のように、そのターンだけ伝えたい指示がよくあります。 従来は履歴にテキストを注入して次のリクエストで削除する方法が使われていましたが、これは履歴編集なのでFable 5.1ではthinking blockを無効化してしまいます。

代わりに用意されたのが clear_at: "next_user_message" です。この属性を付けた role: "system" メッセージは、そのターンではシステムプロンプト相当の権限で効き、次のuserメッセージが現れた時点でレンダリングされなくなります。メッセージ自体は履歴に残したまま毎回そのまま送り返すので、履歴は変わらず、キャッシュも維持され、クリア後は入力トークンも消費しません。 ベータヘッダーは mid-conversation-system-clear-at-2026-08-21 です。

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "Results have landed in your inbox. Check it before running more code."
}

主な用途はツールループでの毎ターンのリマインダーです。各 tool_result のuserメッセージの後に新しいコピーを追記し、以前のコピーは削除せずそのまま残すのがルールです。tool_result だけのuserメッセージも「次のuserメッセージ」として数えられるため、古いコピーは自動的にクリア済み扱いになり、モデルは最新のものだけを読みます。

③ display: "updates"：ツール呼び出し間の進捗を受け取る

Fable 5系はツール呼び出しの間に「今何を見つけて、次に何をするか」という短い進捗メモを書きます。 これは推論とは別の独立したthinking blockとして、直後のツール呼び出しの前に返されますが、デフォルトの display: "omitted" では推論と同じく空文字になります。 そのため長いエージェントターンはユーザーから見ると何分も無言に見えていました。

thinking.display に新しく "updates" が追加され、ベータヘッダー thinking-display-updates-2026-08-18 とあわせて指定すると、推論は隠したまま進捗メモだけをテキストで受け取れます。 この設定下では「テキストが空でないthinking block = 進捗メモ」なので、そのままステータス行として画面に出せます。

const stream = client.beta.messages.stream({
  model: 'claude-fable-5-1',
  max_tokens: 16000,
  betas: ['thinking-display-updates-2026-08-18'],
  thinking: { type: 'adaptive', display: 'updates' },
  tools,
  messages: [{ role: 'user', content: '課金サービスに対して開いているPRをレビューして' }],
});

for await (const event of stream) {
  if (event.type === 'content_block_delta' && event.delta.type === 'thinking_delta') {
    // 空でないテキストが来たら進捗メモ。ステータス行として表示する
    if (event.delta.thinking) showStatus(event.delta.thinking);
  }
}

注意点として、進捗メモはゼロ個の場合もあり、モデルはどのタイミングでも省略できるので「0個以上」を前提に組む必要があります。 また max_tokens 等で途中終了した場合、最後のブロックが「This part of the response was interrupted before it finished.」というテキストの進捗ブロックになることがあります。 この場合はそのassistantターンをそのまま返し、新しいuserメッセージを追加すれば続行できます。

④ キャッシュ読み取りの値下げ

前述の通り、キャッシュ読み取りが$0.25 per MTokになりました。リクエスト側の変更は不要です。 ただしミスとヒットの差が40倍になったため、キャッシュを温め続ける工夫の価値が上がった点は意識しておく必要があります。 5〜60分のアイドル間隔なら、1時間TTLを使うより max_tokens: 0 のキープアライブ送信を5分TTLで回す方が安いケースが多いとされています。

⑤ コンテンツ来歴（content provenance）

Fable 5.1とMythos 5.1が生成するテキストには、すべてのプラットフォームでAnthropicの統計的テキストウォーターマークが付きます。 トークンや隠し文字を追加するものではなく、出力の意味・品質・可読性は変わりません。組織や利用者に関する情報も含まれません。 これはEU AI法への対応で、検出APIは規制当局・報道機関・ファクトチェッカー・研究者などの適格組織にプライベートプレビューで提供されます。

また、コード実行サンドボックスで生成した画像・音声・動画をFiles API経由でダウンロードすると、署名付きのC2PA Content Credentialsが付与されます。 マニフェスト分だけファイルサイズとチェックサムがコンテナ内のファイルと異なるため、整合性チェックをしている場合は調整が必要です。テキスト・PDF・Officeファイルは署名対象外です。

Fable 5から変わった挙動とプロンプト対処

APIは壊れないものの、コード変更なしで現れる挙動の差もあります。 公式の「Prompting Claude Fable 5.1」ドキュメントが挙げているものを、対処法とあわせて整理します。

安全分類器についても改善があります。サイバーセキュリティ分類器の誤検知はFable 5比で約60%減、初歩的な生物学・医療の無害な質問に対する誤検知は約85%減とされ、ソースコードの脆弱性発見は許可されるようになりました。 ただし「このプログラムはコンパイルエラーなく通るか？」のようなコンパイルチェック的な言い回し、マイナーなプログラミング言語、base64エンコードされたデータをコンテキストに返すツールの3つは誤検知を起こしやすいので、拒否ハンドリングとフォールバックは引き続き必要です。

移行チェックリスト

Fable 5から移行する場合に確認すべき項目をまとめます。Opus 5やそれ以前から移行する場合は、これに加えて「thinkingのdisabledが全effortで400になる」「ツール間のナレーションがtextブロックからthinkingブロックに移る」「ZDRが使えなくなる」「料金が2倍になる」といった差分が乗ります。

1. モデルIDを claude-fable-5-1 に更新する。
2. tool_choice の any / tool を削除する。 auto ＋プロンプトでの明示、strict: true、structured outputsのいずれかに置き換える。ツールが呼ばれなかった時のリトライループも不要になるので削除する。
3. データ保持設定を確認する。 30日保持が有効でないと400が返る。
4. thinking blockを毎ターンそのまま返す。 空のブロックも redacted_thinking も含めて改変しない。
5. 履歴をappend-onlyにする。 systemプロンプトはセッション開始時に固定し、途中の指示変更は role: "system" メッセージで追記する。毎ターンのリマインダーはturn-scoped system messageに移す。古いtool_resultの削除やcompactionはサーバー側に任せる。
6. 3ステップ確認を実行する。 drop_block で回して input_transformations を記録し、prefix_binding_mismatch をすべて潰す。本番では error か drop_block を明示的に選ぶ。
7. effortを再チューニングする。 レベル名はモデル間で同じ量の思考を意味しない。high から始め、medium で品質が保てるなら下げる。
8. UIに display: "updates" を組み込む。 長いツール呼び出しをユーザーが見守る製品なら必須。
9. Priority Tierとレート制限を確認する。 Fable 5.1はPriority Tier非対応。レート制限はFable 5と「Fable 5.x」プールを共有するため、移行期間中に両方を動かすなら余裕を再計算する。

まとめ

• ① 性能の伸びは「長時間の自律実行」に集中している。 Terminal-Bench-Scienceの倍増やAutomationBenchの大幅改善が示す通り、何時間も動き続けるタスクで崩れにくくなった。一方でHLEやGDPvalの伸びは小幅で、「賢さ全般」より「持久力」の進化と捉えるのが正確。
• ② 破壊的変更の本質は「履歴を編集するな」に集約される。 forced tool useの廃止は個別の話だが、thinking blockのモデル束縛と会話束縛は「会話履歴はappend-onlyで扱う」という一つの原則に帰着する。自前ハーネスを持つ人は3ステップ確認を今のうちに回すべき。
• ③ 追加機能は破壊的変更の「代替手段」として設計されている。 per-message effort・turn-scoped system message・display: updatesは、いずれも履歴を壊さずにループを制御するための道具。キャッシュ読み取りが4分の1になったことで、この「壊さない」設計の経済的価値も同時に上がった。