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

圧縮の直後に制約や決定事項が消える症状

Compaction(会話が長くなったときに古いやり取りを要約へ差し替える圧縮)を自分のコードで実装していると、要約から制約や決定事項、細かい数値が落ちることがあります。Claude Fable 5.1のプロンプトガイドも、この症状を「クライアント側の要約が制約・決定・正確な詳細を落とす」と挙げています。

典型は、「次に何をするか」だけが残り、「何を条件として合意したか」が消える形です。圧縮をまたいだ直後のやり取りを見れば気づけます。

• ユーザーが以前に断った選択肢を、Claudeがもう一度提案してくる
• 「無料プランでは使えない」といった制約を忘れて回答する
• 顧客IDやチケット番号が、近い別の値に置き換わっている

どれかに当たるなら、まず要約を書かせるプロンプトを疑います。ガイドはクライアント側で圧縮するとき用に、何を残すかを番号付きで指定する保持指示を用意しています。

保持指示の日本語訳例 — テンプレートをそのまま使う

要約プロンプトを自前で書くなら、プロンプトガイドの英文テンプレートが土台になります。日本語の会話を要約させる場合は、意味を保った日本語の指示文を使うこともできますが、その効果は自分の環境で確かめます。英文を日本語に直すと、次のようになります。

会話の記録を <summary></summary> タグの中に要約せよ。新しいコンテキストウィンドウでこの会話を引き継いでも、作業のやり直しや、関連する制約・背景の再説明が要らないよう、必要な情報をすべて含めること。次の点は必ず残すこと。(1) 発生した困難や問題と、その対処や解決の内容。(2) 挙がった可能性・選択肢・方法のうち、試したもの、見送ったものと、その理由。(3) 依頼されたこと、決定・合意・除外されたこと、好み・制約・境界として確立したこと。これらは表現を変えずに書く。(4) 現在の正確な到達点。ここまでに扱った内容、決着した内容、完了した内容。(5) 未解決のこと、約束したこと、次に行う予定のこと。(6) 後から再現しにくい具体的な詳細。名前、数値、日付、正確な文言、リンクや参照先は、そのまま残す。以上の点は、長くなってもよいので漏れなく書く。それ以外は簡潔にまとめる。発言者ごとに重みを変えること。ユーザーが述べたこと、求めたこと、共有したこと、確立したことは、ユーザー自身の言葉になるべく近い形で丁寧に残す。自分(Claude)の説明や推論は、結論や成果物まで大きく圧縮してよい。ただし上の6項目は一つも欠かさないこと。

この文面は要約リクエストのユーザーメッセージかシステムプロンプトに入れ、圧縮対象の会話を前後に添えて送ります。<summary></summary>タグで囲む指定は、訳文でも残してください。

6項目の中身と、ユーザーとClaudeの重み付け

重要なのは末尾の重み付けです。ユーザーが言ったこと、求めたこと、共有したことは、できる限り原文に近い言葉で残します。Claude自身の説明や推論は、結論と成果物まで圧縮してかまいません。

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

保持指示を渡す場所は圧縮方式で変わる

保持指示は要約の中身を決めるだけで、どの方式で圧縮するかとは別の問題です。圧縮の方式は3つに分かれ、指示の渡し先が違います。

on-demand compactionは、会話をそのまま送り、compactionパラメータで要約だけを返させる方式です。instructionsに空白だけではない文字列(上限16,384文字)を渡すと、既定の要約プロンプトが丸ごと置き換わります。日本語訳の保持指示は、この上限に十分収まります。

{
  "compaction": {
    "type": "summarize",
    "instructions": "(上の日本語訳の全文)ツールは呼ばず、要約の本文だけを返すこと。"
  }
}

末尾の「ツールを呼ばない」は省かないでください。要約の呼び出しがツールを呼んで終わると、要約ブロックは作られず、中身が空の応答が200で返ります。このときのstop_reasonは"tool_use"で、対処は「ツールを呼ばない」と書いたinstructionsで送り直すことです。

トークン閾値のcompactionでは、context_management.editsに置くcompact_20260112が同じinstructionsを持ちます。triggerの既定は入力15万トークンで、指定できる下限は5万トークンです。

{
  "context_management": {
    "edits": [
      { "type": "compact_20260112", "instructions": "(上の日本語訳の全文)" }
    ]
  }
}

on-demandのcompactionは、Amazon Bedrockでは使えません。Claude API、Claude Platform on AWS、Google Cloud、Microsoft Foundryではベータとして提供されています。

直近ターンを残すか — thinkingブロックとの整合

圧縮後の履歴の作り方は3通りあります。違いは、直近ターンのthinking(拡張思考)ブロックが検証に通るかどうかです。

Claude Fable 5.1のthinkingブロックは、それを生成した会話の中でだけ有効です。2026年8月31日以降に作成されたアカウントでは、system、tools、それ以前のメッセージのどれかが変わった履歴でthinkingを送り返すと、APIが次の400エラーを返します。

messages.1.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".

それ以前に作ったアカウントでは、prefix_mismatch_behaviorを指定したリクエストだけが検査されます。指定しない限りエラーにならないので、自分のキーで動いても、新しいアカウントの利用者は先に400に当たる点に注意してください。

keep-tailを自前の要約で作ったときの回避策が、thinking.block_binding.prefix_mismatch_behavior: "drop_block"(ベータヘッダーthinking-binding-controls-2026-08-01)です。APIが失敗したブロックと、それ以降のthinkingブロックを落とし、リクエストは成功します。落としたブロックはinput_transformationsに記録されます。

ただし、drop_blockはエラーを隠すだけで、履歴を書き換えている原因は直しません。落ちたthinkingを作り直すためにClaudeが長く考えることがあり、セッションのトークン使用量が増える場合があります。

APIが書いた要約なら、drop_blockなしで直近ターンのthinkingを残せます。条件は次の3つです。

• 要約リクエストを、preserved thinkingに対応したモデルに送る
• 残すターンを、要約した最後のメッセージの直後に、手を加えずに置く
• systemと、defer_loading: trueでないtoolsを、要約リクエストの前後で変えない

どれかが崩れても、圧縮した時点では何も失敗しません。残したthinkingが検証される最初の後続リクエストで、400かdrop_blockによる除去が起こります。

keep-tailで直近ターンを残す場合に、要約させる古いターンだけを送るリクエストは次の形です。

{
  "compaction": { "type": "summarize", "instructions": "(保持指示)" },
  "messages": [
    "...要約したい古いターンだけを入れる..."
  ]
}

返ってくるcompactionブロックを、残したターンの前に置いて次のリクエストに送ります。要約は送ったメッセージ全部を一度に対象にするので、残したいターンは要約リクエストのmessagesに入れません。最後のターンがツール呼び出しで終わり結果が無い場合は、400で拒否されます。

残したthinkingが有効だったかを確かめる手順

圧縮のレスポンスは、残したthinkingが有効かどうかを教えてくれません。後続の最初のリクエストで分かります。

エラーに当たったとき、同じ本文を再送しても毎回同じ400になります。1度だけdrop_blockを付けて送り直し、その選択をセッションに保存しておく流れです。保存を忘れると、再起動後のリクエストがまた400に戻ります。

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

プロンプトガイドは、Claude Fable 5.1ではキャッシュの読み取りが安くなったため、コスト削減のために早めに圧縮する判断が最適とは限らないと述べています。圧縮点を後ろにずらす実験をするよう勧めています。プロンプトキャッシュと圧縮の関係はCompactionとプロンプトキャッシュを両立させる実装が詳しいです。

圧縮の頻度を調整するときの目安は、保持指示の6項目が要約にどれだけ残っているかです。要約が薄いなら、頻度を上げる前に指示文を見直す方が先になります。

圧縮と一緒に見直す隣接プロンプト

保持指示だけ直しても、履歴の扱いが崩れていれば別の400に当たります。プロンプトガイドは、Claude Fable 5.1で圧縮と同時に見直す項目を、あと2つ挙げています。

1つ目は、会話履歴を追記専用に保つルールです。assistantのターンはAPIが返した形のまま、thinkingブロックごと履歴に積み、過去のターンを編集しません。検査に引っかかる編集は、プロンプトキャッシュを作り直させる編集と同じです。

• ターンごとのリマインダーを挿入したり、後から取り除いたりする
• 古いターンをその場で要約に差し替える
• セッションの途中でsystemプロンプトを書き換える

リマインダーはターン単位のsystemメッセージで送り、指示やツールの変更は会話の途中に挟むsystemメッセージで行います。履歴を縮める作業は、APIが行うcompactionやcontext editingに任せる、という案内です。Claude Fable 5.1の仕様変更でも、thinkingブロックの束縛は移行時に壊れやすい箇所として扱っています。

2つ目は、長時間のタスクを最後まで進めさせる指示です。Claude Fable 5.1は非同期の長い作業で、次の一手を説明して止まったり、依頼済みの作業に「進めますか」と確認したりすることがあります。ガイドが示すシステムプロンプト例の冒頭は、次の趣旨です。

あなたは自律的に動いている。ユーザーはリアルタイムで見ておらず、作業の途中で質問に答えられない。

例の後半には「コンテキストやセッションが長いことを理由に止まらない」という一文もあり、圧縮をまたぐ長時間タスクにそのまま関わります。この指示は曖昧な依頼への確認も減らすため、確認を残したい場面があるなら、その場面を冒頭の後ろに書き足します。

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

まとめ

直近ターンまで丸ごと要約してよい作りなら、単純圧縮で足ります。thinkingの検証を気にせず、保持指示の質だけを見ればよいからです。直近の数ターンを原文で残す必要があるときに限り、keep-tailを選びます。そのときの要約はAPIに任せ、3つの条件を守ります。圧縮が起きたら、要約の中身とinput_transformationsを運用前に一度確かめます。Fable 5.1の出力が詰まって読みにくいときの指示の足し方は、mannered proseを避けさせる指示にまとめています。