Claude Fable 5.1のappend-only会話設計

複数モデルへのフォールバックや自前の要約ロジックで会話履歴を組み立てている基盤で、ある日から特定のリクエストだけ400エラーで落ちるようになった——原因が数ターン前に注入して削除したはずのリマインダーだった、というケースが増えている。Claude Fable 5.1から有効な「Preserved Thinking」は、会話履歴の書き換えをAPI側で検知する仕組みだ。

本記事はエージェントガバナンスの技術基盤として、コンテキスト圧縮の設計やMid-conversation Tool Changesと合わせて、自前のエージェントハーネスを運用するプラットフォームエンジニア向けに整理する。

Preserved Thinkingとは何か

Preserved Thinkingは蒸留対策の機構で、thinking blockの署名からモデル一致と会話履歴の不変性を検証し、違反時は400エラーまたはブロック破棄を返す。

Claude Fable 5.1以降、thinking・redacted_thinkingブロックのsignatureはAPI側で2点を検証される。1つはモデルの一致で、あるモデルは自分自身と自分より古いモデルが生成したthinking blockしか読めない。Claude Fable 5.1はClaude Opus 5のブロックを読めるが、逆方向は読めず、無言でドロップされる。もう1つはプレフィックスの不変性で、system・tools・それ以前のmessagesのいずれかが変わっていると、そのブロック以降のthinkingがすべて無効になる。

この検証は2026年8月31日以降に作成されたアカウントでデフォルト適用される。それ以前のアカウントでもthinking.block_binding.prefix_mismatch_behaviorを明示すれば同じ検証が働き、Anthropicは将来的に全アカウントへ拡大する方針を示している。今から会話履歴をappend-only（追記専用）に設計しておく必要がある理由はここにある。

なぜ既存の圧縮パターンが壊れるのか

会話履歴の途中を書き換える一般的な圧縮・注入パターンは、Preserved Thinkingの検証対象そのものであり無警告で壊れる。

多くの自前ハーネスが採用してきた次のパターンは、いずれもプレフィックス検証に抵触する。

Keep-tail圧縮: 古いターンを要約に置き換えつつ直近数ターンを生のまま残す方式。残したアシスタントターンのthinking blockは「要約前の履歴」を前提に生成されているため、要約と入れ替えた瞬間に無効化される
バックグラウンド圧縮: 要約生成をクリティカルパス外で行い、数リクエスト後に差し替える方式。差し替えが着地する直前までに生成されたthinkingがすべて無効になる
ターン途中への一時的な指示注入: 「次のメッセージだけ有効なリマインダー」を過去のターンに挿入して後で消す実装。挿入も削除もプレフィックス変更にあたる
tools配列の直接編集: セッション途中でツール構成を書き換える実装

Append-onlyな設計への置き換え方

過去ターンの編集はすべて専用APIで置き換えられ、messagesは新規ターンの追記のみで運用できる。

Anthropicは編集操作ごとに専用の代替APIを用意している。

ツールの追加・削除: tools配列は初回リクエストで全候補を宣言し固定する。途中の変更はrole: "system"メッセージにtool_addition/tool_removalブロックを追記して表現する（mid-conversation-tool-changes-2026-07-01）
エフォート変更: トップレベルのoutput_config.effort書き換えはキャッシュを再構築するだけでthinkingには影響しないが、Claude Fable 5.1では空のcontentを持つsystemメッセージにoutput_configを載せて追記する per-message effort（mid-conversation-output-config-2026-07-01）の方が意図が明確になる
新しい指示の追加: 過去ターンを書き換えず、Mid-conversation system messagesとして末尾に追記する。1ターン限りならclear_at: "next_user_message"を付与する
古いターンの圧縮: クライアント側で手を入れず、サーバー側のCompactionまたはContext Editing（clear_tool_uses_20250919等）に委ねる。これらはAPIが送信済みの内容と比較して検証するため、サーバー側での要約はプレフィックス違反にならない

例外処理と移行時の確認手順

thinking-binding-controls-2026-08-01ベータヘッダーでprefix_mismatch_behaviorをdrop_blockにすると、違反ブロックのみ課金なしで破棄されinput_transformationsに記録される。

移行を急がずまず現状を可視化したい場合は、prefix_mismatch_behaviorを"drop_block"に設定する。失敗したブロックとそれ以降のthinkingは無課金で破棄され、レスポンスのinput_transformationsにreason: "prefix_binding_mismatch"として記録される。本番導入前に数ターンの通常セッションを走らせ、system・tools・messagesが前リクエストと一致しているかを差分で確認する手順が推奨されている。モデルルーティングやフォールバック構成を持つ基盤では、フォールバック経路ごとにこの検証を行っておくべきだ。LLMゲートウェイでモデル切り替えを一元化している場合、切り替え時にthinkingブロックが破棄される前提でリトライ設計を組み込む必要がある。

参考

まとめ

Preserved Thinkingは会話履歴の途中書き換えを前提にした実装を今後段階的に締め出す。Keep-tail圧縮やターン途中への指示注入といった従来パターンは、tool_addition/tool_removal・per-message effort・mid-conversation system messages・サーバー側Compactionという専用APIに置き換えることでappend-onlyのまま運用できる。自前のエージェント基盤を持つ企業ほど影響範囲は大きく、モデルルーティングやフォールバック設計と合わせた技術統制が必要になる。設計・運用の相談はKuuの大規模実装支援（RDE）まで。