Claude Fable 5.1の保持指示でcompactionの要約を書く方法

Claude Fable 5.1のcompactionで情報が落ちる場面

Compaction(会話が長くなったときに古いやり取りを要約へ差し替える圧縮)を自分のコードで実装している場合、Claude Fable 5.1は制約や決定事項、細かい数値を要約から落としやすいと公式ドキュメントが明記しています。「次に何をすべきか」だけが残り、「何を条件として合意したか」が消える典型的な症状です。

原因は要約プロンプト側にあります。多くの実装は「役に立ちそうなことを何でも書いて」程度の汎用的な指示しか渡していません。Claude Fable 5.1はこの手の緩い指示に対して、Claude Fable 5より要約が粗くなる傾向があります。公式はこれを見越して、クライアント側で圧縮するときに使う保持指示のテンプレートを用意しました。

症状に心当たりがあるかどうかは、圧縮をまたいだ直後のやり取りを見れば分かります。ユーザーが以前に断った選択肢をClaudeが再提案してきたり、「無料プランでは使えない」といった制約を忘れて回答したりする場合、要約プロンプトが汎用的すぎる可能性が高いです。

保持指示の全文 — 公式が示すテンプレート

クライアント側で要約プロンプトを自前で書くなら、公式は次の文面をそのまま使うことを勧めています。

Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.

この文面を要約リクエストのユーザーメッセージかシステムプロンプトに渡し、圧縮対象の会話をその前後に添えて送ります。<summary></summary>タグで囲む指定まで含めて、独自の書き換えを加えずに使うのが安全です。

6項目の保持対象と、ユーザーとClaude自身の重み付け

指示文が番号付きで要求する6項目は、①発生した問題とその対処、②検討・試行・棄却した選択肢とその理由、③要求・合意・却下・制約として確立した事項(表現を変えずに)、④現在の到達点、⑤未解決の事項、⑥再現しにくい固有の詳細(名前・数値・日付・正確な文言・リンク)です。

重要なのは末尾の重み付けです。ユーザーが言ったこと・求めたこと・共有したことは、できる限り原文に近い言葉で残します。Claude自身の説明や推論過程は、結論だけに圧縮してよいとしています。長時間タスクを継続する上で価値を持つのはユーザー側の情報であり、Claudeの思考の言い回しではないという判断です。

具体例で見ると分かりやすくなります。③なら「無料プランでは対応しない」とユーザーが明言した制約、②なら「キャッシュを使う案も検討したが、整合性の要件で見送った」という経緯、⑥なら顧客IDやチケット番号のように書き換えると意味が変わってしまう値です。これらはどれも、Claude自身の言葉で言い換えた瞬間に価値が薄れる情報という共通点を持ちます。

単純圧縮を選ぶ理由 — thinkingブロックとの整合

保持指示は「要約の中身」を決めるだけで、「どう圧縮するか」は別の問題です。公式が推奨する形は、会話全体を1通の要約メッセージに置き換え、直近の発話だけを新しく送る単純圧縮です。直近ターンを原文のまま残す方式は避けます。

理由はClaude Fable 5.1のthinking(拡張思考)ブロックの束縛にあります。2026年8月31日以降に作成された新規アカウントでは、thinkingブロックはそれが生成された会話の前提(systemプロンプト・toolsの配列・それ以前のメッセージ)が変わっていない場合にのみ有効です。要約で古いターンを消しながら直近ターンのthinkingブロックだけ生で残すと、この前提が崩れて無効化され、The block is bound to a different conversationという400エラーになります。

会話全体を1通の要約に置き換える単純圧縮なら、thinkingブロックを一切送り返さないためこの検証に引っかかりません。直近ターンを原文のまま残したい場合は、サーバー側のon-demand compactionに要約を作らせ、prefix_mismatch_behavior: "drop_block"を指定して無効なブロックを落とす実装が必要です。Claude Fable 5.1の仕様変更でも、このthinkingブロックの束縛は移行時に壊れやすい箇所として扱われています。

直近ターンを原文のまま残す実装(keep-tail)を選ぶ場合、保持指示を渡すのは古いターンをまとめる要約リクエスト側だけです。

{
  "compaction": { "type": "summarize" },
  "messages": [
    "...保持指示を添えて要約したい古いターンだけを送る..."
  ]
}

このリクエストが返すcompactionブロックを、直近ターンの前に置いて次のリクエストへ送ります。thinkingブロック付きの直近ターンをそのまま使う場合はthinking.block_binding.prefix_mismatch_behavior: "drop_block"を明示し、systemプロンプトとtools配列が要約リクエスト時と一致していることを確認します。ずれがあると、直近ターンのthinkingブロックまで無効化の対象になります。

サーバーサイドCompactionのinstructionsパラメータとの違い

Claude APIには要約プロンプトを差し替えられるinstructionsパラメータ付きのCompaction機能もあります。書き方も発火の仕組みも別物で、両方を同時に実装すると要約の主導権がどちらにあるか分からなくなります。

instructionsパラメータの書き方はCompactionのカスタム要約プロンプトを書く実装ガイド、圧縮ブロックの積み戻し実装はCompaction blocksを会話に戻す実装パターンにまとめています。ここで扱う保持指示は、この2つのサーバーサイド機能を使わずに要約を自前実装するときの代替手段です。

圧縮タイミングは早めに固定しない

Claude Fable 5.1はキャッシュ読み取りの単価が下がっているため、早いタイミングで圧縮してコストを抑えるという従来の判断が最適とは限りません。読み取りが安くなった分だけ、長く会話を維持してキャッシュを効かせ続けるほうが有利になる場面が増えています。プロンプトキャッシュと圧縮の関係はCompactionとプロンプトキャッシュを両立させる実装も参考になります。

圧縮を早めるか遅らせるかは、保持指示の6項目がどれだけ実際の要約に残っているかを見ながら調整するのが実用的です。要約が薄いなら、圧縮の頻度を上げるより先に指示文を疑うほうが効果的です。

compactionと一緒に見直すべき隣接プロンプト

保持指示だけを直しても、圧縮前後で会話全体の挙動が変わらなければ効果は限定的です。公式のプロンプトガイドは、Claude Fable 5.1でCompactionと同時に見直すべき項目をあと2つ挙げています。

会話履歴を追記専用に保つルールがまず前提になります。過去のターンを編集・並べ替えせず、システムメッセージの追加だけで指示や利用可能なツールを変える設計にしないと、圧縮とは無関係な操作でもthinkingブロックの束縛が崩れます。単純圧縮そのものは無効化を起こしませんが、圧縮以外の場所で履歴を書き換えていると、保持指示を正しく実装しても別の400エラーに当たります。

長時間タスクでは、圧縮をまたいでも「作業を最後までやり切る」指示を保つことも重要です。Claude Fable 5.1は次の一手を説明するだけで実行を止めたり、既に依頼された作業について確認を求めたりすることがあります。圧縮直後の要約メッセージにタスクの状態を正確に残しても、その先で止まってしまえば保持指示の効果が薄れます。ユーザーが見ていないことと、依頼済みの作業には確認なしで進めることをシステムプロンプト側に明記しておくと、圧縮後も長時間タスクを最後まで進めやすくなります。

実装時に踏みやすい落とし穴

まとめ

Claude Fable 5.1でクライアント側のcompactionを自前実装するなら、公式が示す6項目の保持指示をそのまま使い、会話全体を1通の要約に置き換える単純圧縮を選びます。直近ターンを原文で残したくなった場合だけ、サーバー側のon-demand compactionとdrop_block指定に切り替えるのが安全な設計です。指示を渡して終わりにせず、実際の圧縮後にどの項目が抜け落ちているかを一度は確認してから運用に載せます。