Claude Fable 5.1が思考ブロックを単一の会話にバインド — エージェントの推論を台無しにする4つの編集（2026年）

これについては3つの公式ドキュメントで説明されており、それぞれ異なる側面をカバーしています。リリースノートで発表され、「What's new in Claude Fable 5.1」ページで破壊的変更の概要が説明され、専用の「Preserved thinking」ページに完全なルールと移行チェックリストが掲載されています。同日に更新された、一般ユーザー向けのヘルプセンター記事（4つ目のドキュメント）では、APIをまったく触らない場合にこの同じメカニズムがどのように見えるかが示されています。

思考ブロックがモデルと署名を持つように

このルールには方向性があります。Anthropicの言葉を借りれば、「すべての思考ブロックは、どのモデルがそれを生成したかを記録しており、一方向にのみ保持されます。Claude Fable 5.1は以前のモデルの思考ブロックを読み取りますが、以前のモデルがClaude Fable 5.1の思考ブロックを読み取ることはありません。」

したがって、上位のモデルに移行する会話は推論を維持します。下位のモデルに移行する会話は、そこで実行されるターンの推論を失います。Fable 5.1は、Opus 5、Fable 5、Mythos 5、およびそれ以前のモデルからのブロックを受け入れます。しかし、それらのモデルはいずれもFable 5.1のブロックを読み取ることができません。

リクエストに対象モデルが読み取れないブロックが含まれている場合、「APIはモデルがそれを見る前にブロックをドロップ（破棄）します」。ドロップされたブロックには課金されません。そして、デバッグにおいて重要な点として、thinking-binding-controls-2026-08-01ベータヘッダーを使用すると、ドロップはトップレベルのinput_transformations配列に報告されます。ドキュメントによると、これがない場合、「ドロップはサイレントに行われます」。

モデルチェックに加えて、さらに2つのチェックが存在します。APIは「ブロックより前のものが何も変更されていないこと」（トップレベルのsystemプロンプト、tools内のツールセット、およびブロックより前のすべてのメッセージ）と、「以前の思考ブロックのチェーンが途切れていないこと」を検証します。これは「各思考ブロックがターンをまたいで前のブロックを記録している」ためです。

それ以降のすべてを無効化する4つの編集

リリースページには、そのパターンが明確にリストされています。以下は、それ以降のすべての思考ブロックを無効化します。

• 「以降のターンを維持したまま、以前のターンを編集、並べ替え、または削除する。」
• 「以前のターンにリクエストごとのテキスト（リマインダーやステータス行）を挿入し、次のリクエストでそれを削除する。」
• 「同じ会話内のリクエスト間で、トップレベルのsystemプロンプトまたはtools配列を再構築する。」
• 「以降のリクエストで異なるバイトを返す画像またはドキュメントのURL（チェックはURLではなくバイトを対象とするため、同じファイルに対するローテーションされる署名付きURLは問題ありません）。」

「4つ」というのはベンダーによる要約であり、すべてではありません。「Preserved thinking」ページでは、同じ内容がさらに多くの行を持つ表に拡張されています（ツールの編集、履歴の途中からの思考ブロックの削除、ターン範囲のメッセージの言い換えなど）。ご自身のハーネスが問題ないと結論付ける前に、この表に目を通してください。

チェックが適用されている場合、無効化されたブロックを再送するリクエストは、The block is bound to a different conversation（ブロックは別の会話にバインドされています）というメッセージとともに400エラーを返します。

これら4つのうち、どれが罠であるかに注目してください。2番目は決して特殊なコードではありません。以前のメッセージにターンごとのリマインダーを挿入し、次のリクエストでそれを削除するというのは、長いツールループを制御するための標準的なテクニックですが、これを行うとそれ以降のすべての思考ブロックが失われます。

何が有効なままで、現在誰に適用されているか

ドキュメントには、何が編集とみなされないかも同様に明記されており、そのリストは人々が想定するよりも寛大です。末尾にメッセージを追加することは問題ありません。履歴の最初から思考ブロックを削除すること、cache_controlマーカーを移動すること、max_tokens、output_config、またはtool_choiceを変更することも同様に問題ありません。サーバー側の圧縮（compaction）やコンテキスト編集は明示的に問題ないとされています。なぜなら「チェックはサーバーの編集されたコピーではなく、送信された内容を比較する」ためです。

適用は段階的に行われ、日付は正確に指定されています。「新規アカウントとは、2026年8月31日00:00 UTC以降に作成されたアカウントを指します。」これらのアカウントには、本日よりチェックが適用されます。それより古いアカウントでは、不一致は記録されますが、リクエストでprefix_mismatch_behaviorが設定されている場合にのみ対処されます。今後の計画を立てる上で重要なのは、次の将来を見据えた一文です。「今後のモデルでは、すべてのユーザーに対してチェックが強制されます。」

これにより、ドキュメント全体の中で最も有用な警告が導き出されます。これは、他人が実行するツールを開発・提供しているすべての人に向けられたものです。「他人が自身のAPIキーで実行するツールやフレームワークをメンテナンスしている場合、新規アカウントのユーザーはあなたよりも先にこのチェックに遭遇します。あなた自身のキーはおそらく古いアカウントにあるためです。」

コンシューマー側：メモリがモデルを動かす可能性

同日、Anthropicは、Fable 5およびFable 5.1においてClaudeが会話の途中でモデルを切り替える理由に関するヘルプセンターの記事を更新しました。これはmessages配列を見たことがない人向けに書かれていますが、結論は同じ場所にたどり着きます。

Fable 5.1はすべてのリクエストで安全分類器（safety classifier）を実行し、ブロックされたリクエストはフォールバックします。「リクエストがフォールバックすると、ClaudeはブロックされたClaude Fable 5またはFable 5.1のリクエストを、同じ会話内のOpusモデルで再実行します。」そして、「切り替え後、モデル選択は会話の残りの部分でOpusのままになります。」

これが、チャットウィンドウで展開される方向性ルールの実態です。あなたの会話は、Fable 5.1の推論を読み取ることができないモデルに移行したばかりなのです。

そのページから、さらに2つの文章をじっくり考える価値があります。ブロックされるカテゴリの1つは、「モデルの要約された思考を抽出しようとする試みを含む、Fable 5およびFable 5.1に対する蒸留攻撃（distillation attacks）」です。これは、なぜこのバインドが存在するのかを物語っています。そして、分類器は最新のメッセージだけを読み取るわけではありません。「チェックは、最新のメッセージだけでなく、モデルが読み取るすべてのもの（メモリ、コネクタからのコンテンツ、ウェブ検索結果、ファイルなど）もレビューするため、自分が入力していないコンテンツによってブロックがトリガーされる可能性があります。」

これを注意深く読んでください。メモリレイヤーにあるものがモデルの切り替えをトリガーする可能性があり、そのモデルの切り替えこそが推論をドロップさせる原因なのです。

これによって、Claude Fable 5.1の記憶力が低下するわけではありません。ここで説明されている内容は、機能としての永続メモリ（persistent memory）には一切触れていませんし、両モデルがデフォルトで提供している1Mトークンのコンテキストウィンドウを縮小するものでもありません。

また、これはポリシーを装った弱体化（ナーフ）でもありません。Anthropicはその理由を直接述べています。署名チェックが存在するのは、「ある指示セットの下で生成された推論が、別の（潜在的に敵対的な）指示セットの下で再実行されないようにするため」です。これをコンシューマー側のブロックされた蒸留カテゴリと組み合わせると、2つのレイヤーにおける1つの防御策となります。これをデグレード（退行）と呼ぶのは誤解です。

これが変えるのは、メッセージ配列のステータスです。これまでは、messagesは書き換え可能なワーキングメモリでした。古いターンをその場で要約したり、リマインダーをパッチ適用したり、新しいツールが追加されたときにシステムプロンプトを再構築したりできました。Fable 5.1では、その配列はチェックサム付きの追加専用ログに近くなっています。そうではないと想定していたシステムのコンポーネントは、今後別の場所に存在する必要があります。

そして、フォールバックのコストが変わります。価格や可用性のためにモデルをシャッフルするルーターは、以前は少しの品質低下と引き換えにしていました。しかし今や、推論チェーンをドロップさせている可能性があり、input_transformationsを有効にしていない限り、通知なしに静かにドロップされます。

「Fable 5.1は物事を忘れるようになった」 そうではありません。このバインドは、推論ブロックをリクエストに再適用できるかどうかを制御するものです。Claudeが会話間であなたについて記憶している内容とは無関係であり、それは別の制御を持つ独立したシステムです。

「では、思考ブロックを送り返すのをやめるべきか」 これも間違いであり、代償が大きいです。Fable 5.1は以前のモデルのブロックと自身のブロックを読み取ります。長いエージェントのターンにわたってそれらを再送することが、推論チェーンを維持する鍵となります。解決策は、履歴の送信をやめることではなく、履歴の編集をやめることです。

「これは生のAPI呼び出しを書く人にしか影響しない」 例外を除けば、ほぼその通りです。ドキュメントには、Claude Code、claude.ai、Claude Managed Agents、およびClaude Agent SDKがプレフィックスを自動的に維持することが記載されています。ラッパー、プロキシ、または評価（eval）ハーネスの内部を含め、ご自身でmessages配列を構築している場合は、あなたがチェックを行う必要があります。

「400エラーが最悪のケースである」 400エラーは、問題に気づくことができるため良いケースです。サイレントなケースの方が悪質です。ベータヘッダーなしでモデルがダウングレードされたときにブロックがドロップされるケースや、ローテーションされるドキュメントURLが静かに異なるバイトを返すケースなどです。

「チェックをオフにすればいい」 不一致が発生したときの挙動を選択することはできます（デフォルトの"error"の代わりに"drop_block"を指定するなど）。しかし、ドロップすることは維持することではありません。APIは「そのブロックと、会話内のそれ以降のすべての思考ブロックを削除」します。これは本番環境における合理的なデフォルト設定にすぎず、修復ではありません。

追加専用ルールは、単一の会話のリクエストボディという特定の要素に対する制約です。プロジェクトの永続的な知識がどこに存在するべきかについては何も規定していません。この区別こそが解決策のすべてであり、ルール、決定事項、好みを対話履歴の外側のメモリレイヤーにすでに保持しているチームが、今回のリリースによる影響をほとんど受けなかった理由です。

メモリレイヤーは、チェックが求める通りの方法で機能します。事実が最初から以前のターンに含まれていないため、以前のターン内で書き換えが発生することはありません。また、ストアが外部にあるため、推論チェーンをドロップさせたOpusへのフォールバックが発生しても、同じ知識が生き残り、その後のモデルでも維持されます。MemoryLakeは3つのステップを実行します。

ステップ1：APIキーの作成

サインインし、ダッシュボードからAPIキーを生成します。これは、エージェント、ハーネス、またはバックエンドがメモリを読み書きするために使用する資格情報であり、会話が現在どのClaudeモデルで実行されているかとは無関係です。この独立性こそが重要です。Fable 5.1からOpusへのフォールバックは、思考ブロックを読み取れるモデルを変更しますが、メモリを読み取れるものには一切影響を与えません。

ステップ2：最初のメモリのアップロード

以前のターンに挿入したくなっていた要素を、代わりにここに配置します。社内ルール、すでに下された決定とその背後にある理由、名前、定義、およびエージェントが何度も再学習していたルールなどです。プロジェクトの詳細が変更されるたびに再構築していた長いシステムプロンプトを維持してきた場合、その再構築は無効化を招く4つの編集の1つになります。その揮発性の高い半分をメモリに移動し、安定している半分をsystemに残してください。

ステップ3：AIとエージェントの接続

ハーネスをストアに向けます。これにより、履歴の過去を書き換えるのではなく、ターンの開始時に取得が行われます。実質的に、これはターンごとのコンテキストが外部ソースから組み立てられて追加されることを意味し、6ターン前のメッセージにパッチ適用されることはありません。これこそが署名チェックが求めている形であり、プロンプトキャッシュを温かく保つ（warm）形でもあります。

長いエージェントの実行において、即座に生じる変化は、制御（steering）を会話の末尾に移動しなければならない点です。リマインダーは、追加されるターンまたはターン範囲のシステムメッセージになります。ツールの変更は、再構築されたtools配列ではなく、会話途中のツール変更パスを経由します。トリミングは、設計上チェックが無視するサーバー側の圧縮またはコンテキスト編集に移行します。

前段にルーターがあるシステムの場合、変化は可視性が必要になる点です。thinking-binding-controls-2026-08-01ベータヘッダーを送信し、input_transformationsをログに記録することで、サイレントなドロップをカウント可能なログ行に変換できます。Anthropic独自の検出レシピは、prefix_mismatch_behaviorを"drop_block"に設定して通常のマルチターンセッションを実行し、返ってくる内容を読み取ることです。

それ以外の人々（ブラウザでClaudeを使用している人々）にとって、実用的な変化はより小さく、そして奇妙なものです。安全性のフォールバックによって会話がOpusに移行した場合、以前のメッセージを編集することがドキュメントに記載された解決策です。「再試行する前に前のメッセージを編集すると、多くの場合役立ちます。」これはAPI側の推奨とは逆ですが、異なるレイヤーに関するものであるため、どちらも正しいのです。「履歴を編集しない」というのはリクエストボディに関するルールであり、チャットウィンドウの使い方に関するルールではありません。

コストに関する1つの注意点も同じ方向を示しています。思考ブロックを無効化するパターンは、プロンプトキャッシュを無効化するパターンとほぼ同じです。一方を修正すれば、もう一方も修正されます。

• アシスタントのターンを返された通りにそのまま追加する。 空の思考ブロックとその署名を含め、バイト単位で完全に一致させます。
• 以前のターンにパッチを適用しない。 ターンごとのリマインダーは、clear_at: "next_user_message"を設定したターン範囲のシステムメッセージに配置します。これにより、トークンコストをかけずにmessages内に維持され、以降のブロックが有効に保たれます。
• 会話の途中でsystemとtoolsを変更しない。 いずれの配列も再構築するのではなく、会話途中のシステムメッセージやツールの追加・削除パスを使用します。
• サーバー側でトリミングを行う。 圧縮やコンテキスト編集は編集とみなされません。クライアント側で以前のターンを要約することは編集とみなされます。
• ファイルをIDで参照する。 チェックはURLではなくバイトを対象とします。
• 必要になる前に可視性を有効にする。 ベータヘッダーを送信し、input_transformationsをログに記録することで、ドロップされたブロックを謎ではなく測定可能なメトリクスにします。
• 新規アカウントと同じようにテストする。 あなた自身のキーはおそらく古いアカウントにあるため、prefix_mismatch_behaviorを明示的に設定してください。
• 永続的な知識はmessagesの外に保持する。 履歴に挿入していたであろうものはすべてメモリレイヤーに属します。その際、コーディングエージェントが実際に何を読み取っているかを監査する価値があります。

Claude Fable 5.1における最大の変更点は、キャッシュ読み取りの価格ではありません。送信する会話が、署名され、モデルにバインドされた、追加専用のオブジェクトになったことです。そして、4つの一般的な編集習慣によって、モデルの推論が失われる（そのうち1つは静かに失われる）ようになったことです。

この制約は限定的であり、回避策はすべてAnthropicが同時にリリースした公式機能です。さらに良い知らせは、人々がメッセージ配列に密かに詰め込んでいたもののほとんどは、最初からそこに属すべきではなかったということです。推論が意図的に1つの会話にバインドされているのに対し、プロジェクトの知識は何にもバインドされる必要はありません。