Anthropicの蒸留攻撃対策レポートを読む：preserved thinkingでClaude APIの会話履歴の扱いがどう変わるか
どうも！オペ部の西村祐二です！
Anthropicが2026年10月12日に、Strengthening our defenses against distillation attacksという記事を公開しました。他社がClaudeの出力を大量に集めて自社モデルの学習に使う「蒸留攻撃」に対して、どんな防御を入れ、どれくらい効果が出たかをまとめたものです。
国家安全保障寄りの話に見えますが、防御策の一部はClaude APIの仕様として入っています。会話履歴の組み立て方によっては400エラーが返るようになり、遮断されたリクエストにも課金されます。この記事では原文の主張をまとめたうえで、API連携を自前で書いている人が何を確認すればよいかを、preserved thinkingのドキュメントと突き合わせて見ていきます。名指しされた企業の個別事案や、輸出規制などの政策論には踏み込みません。
Anthropicが報告した効果：集められるデータを約90〜99%削減
原文が挙げている結果は次のとおりです。いずれもAnthropic自身の発表で、第三者の検証を経た数字ではありません。
| 項目 | 原文の記述 |
|---|---|
| 全体の効果 | 蒸留者が集められるデータを約90〜99%削減（初期の推計） |
| 推論トークンの抽出量 | 分類器の導入後、プラットフォーム上で抽出された推論トークンが10〜100倍以上減少。測定できないほど少ない日もあった |
| アカウント停止 | 蒸留に関わる数万アカウントを停止。キャンペーン開始から2時間以内に止めた例が多い |
| 分類器の誤検知率 | 0.1%未満 |
| 失った売上 | 数兆トークン分の有償トラフィックを断った |
原文は、これらの成果が続くとは限らないとも書いています。蒸留は攻撃と防御の応酬が続くものであり、高度で粘り強い攻撃者がこの防御に挑んでくるケースはまだ見ていない、という但し書きです（"How well our new methods work"の節）。
なぜ推論の書き起こしが狙われるのか
原文によると、蒸留者が一番欲しいのは最終的な回答ではなく、Claudeが回答に至るまでの推論の書き起こし（reasoning transcripts）です。推論そのものの価値を示す例として、次の比較が挙げられています。Claude Opus 4.8の推論をそのまま使って学習したモデルはSWE-bench Verifiedで80.4%、要約した推論で学習したモデルは71.8%でした（"Simple defenses are not enough"の節）。
最初の対策は推論を要約してから見せることでした。すると攻撃側は、Claudeに過去の推論を「verbatim, exactly character for character」で出力させるような抽出に切り替えました。原文には、1つのラボが1万2,000件のリクエストで、それぞれ異なる抽出手法を試した例や、2万を超えるアカウントを同時に運用していたネットワークの例が出てきます。
（原文の記述をもとに筆者が作成した概念図です）
推論を守る3つの防御
原文は新しい防御を3つに分けています（"Our new methods"の節）。
1. 推論の行き先を制御する（preserved thinking）
Claude Fable 5.1とClaude Opus 5.5で導入された仕組みです。原文の説明は次の3点です。
- 2026年8月31日以降に作られた新しいAPIアカウントでは、Claudeの過去のコンテキストを書き換えられない
- 新しいモデルが出した推論を、防御の弱い古いモデルが読めないようにする
- Claude Sonnet 5.5の推論は、そのリクエストを送った組織からしか使えない
API利用者への影響は次の章で扱います。
2. 抽出の試みを検知して塞ぐ
constitutional classifiersの研究をもとにした2段階の分類器で、推論の抽出を狙うリクエストを検知して遮断します。原文によると、この分類器は社内外のレッドチームで検証されています。堅牢さは、生物兵器関連の支援を防ぐセーフガードとほぼ同程度とされています。対象はClaude Sonnet 5.5、Claude Opus 5と5.5、Claude Fable 5と5.1で、今後の同等モデルにも適用する予定です。推論を翻訳させる、タグで囲んで書かせる、といった回避策も個別に塞いだと書かれています。
3. 繰り返しの試行を割に合わなくする
抽出を繰り返すアカウントには厳しい利用制限をかけ、最終的には停止します。さらに2026年9月24日からは、Claudeが応答する前に遮断されたリクエストへの課金を再開しました。
API連携側で確認したいこと
ここからは、原文とpreserved thinkingのドキュメントを読んだうえでの筆者の整理です。
自前でリクエストを組み立てているかどうかで分かれる
ドキュメントの"Who needs to change anything"の節によると、Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDKがリクエストを組み立てている場合は、何も変える必要がありません。systemとtoolsを会話中に固定し、messagesに追記するだけの実装も、同様に変更は不要です。
確認が必要なのは、Messages APIを直接呼び、会話の途中で履歴を加工している実装です。
何が「書き換え」とみなされるか
API側は、返却されたthinkingブロックごとにsignatureを見て、次の2点を確認します。
- そのブロックより前にある
system、tools、messages（ドキュメントでいう「prefix」）が、ブロック生成時と同じか - 現在のモデルがそのブロックを読めるか
prefixが変わっていると、そのブロック以降のthinkingブロックが無効になります。prefixの判定の対象はClaude Fable 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 5.5へのリクエストで、Claude Mythos 5.1とFable 5.1より前のモデルでは判定されません。ドキュメントが書き換えの例として挙げているのは次のような処理です。
- 日付やモード、あとから接続したMCPサーバーに合わせて
systemプロンプトを組み直す - 古いツール結果を消したり短くしたりする
- クライアント側で古いターンを要約・削除し、新しいターンだけthinking付きで残す
toolsの項目を追加・削除・編集する- ユーザーターンに付けたリマインダーを、あとで消したり書き換えたりする
- 空の
thinkingブロックを省くシリアライザーを通す（Fable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5ではthinkingフィールドが既定で空になり、推論はsignature側に入っているため、省くと推論ごと失われます）
一方で、effort、max_tokens、tool_choice、metadataの変更や、cache_controlの付け外し（プロンプトキャッシュの位置変更）などは判定の対象外です。
自作のエージェントでは、コンテキスト節約のために古いツール結果を間引く処理を入れていることがよくあります。筆者が最初に確認したいのはこの部分です。
（ドキュメントの記述をもとに筆者が作成した概念図です。実際のリクエストの形式はドキュメントを参照してください）
アカウント作成日で既定の挙動が違う
prefixの判定は、2026年8月31日 00:00 UTC以降に作られたアカウントで既定で有効です。それより前のアカウントでは、thinking.block_binding.prefix_mismatch_behaviorを指定したリクエストにだけ適用されます。このフィールドを使うにはベータヘッダーthinking-binding-controls-2026-08-01が必要で、ヘッダーなしで指定すると400エラーになります。
古いアカウントで開発し、新しいアカウントで本番を動かすような構成だと、本番だけで400エラーが出ることになります。お客様ごとにアカウントを分けて運用している場合も、アカウントの作成日は確認しておきたいところです。
判定に失敗したら400で止めるか、ブロックを捨てて続けるか
判定に失敗したときの挙動はprefix_mismatch_behaviorで選べます。
"error"（判定が有効な場合の既定）: 最初に失敗したブロックを示す400invalid_request_errorを返す"drop_block": 失敗したブロックとそれ以降のthinkingブロックを捨てて処理を続ける
ただしMessage Batches APIでは、判定が既定で有効なアカウントでもフィールドを指定しなければエラーにならず、失敗したブロックが捨てられます。エラーにしたい場合は"error"を明示します。
"drop_block"にするとエラーは出ませんが、モデルが推論をやり直すぶん出力トークンが増えます。出力トークンの増加量は、ドキュメントに載っているAnthropicの測定（誤差の幅が大きい推計とされています）で次のとおりです。
- 1セッションに1回捨てた場合: 2.5%（low effort）〜20.1%（max effort）
- 2ターン目以降に毎回捨てた場合: 4.6%（low effort）〜67.1%（max effort）
ドキュメント自身も"drop_block"は一時しのぎで、根本対応ではないと位置づけています。
同じベータヘッダーを付けると、捨てられたブロックとその理由がレスポンスのinput_transformationsにthinking_droppedとして入ります。理由はprefix_binding_mismatch、model_binding_mismatch、organization_binding_mismatchのいずれかです。
古いアカウントでフィールドを指定せずにヘッダーだけ付けた場合、ブロックは捨てられずにモデルへ渡され、prefixの不一致がthinking_mismatch_allowedとして記録されます。本番トラフィックを止めずに、書き換えが起きている箇所を観察する手段として使えます。
モデル切り替えとアカウントをまたぐ利用
モデルごとに読めるthinkingブロックが決まっていて、読めないブロックはエラーにならずに黙って捨てられます。たとえばドキュメントによると、Claude Opus 5のような以前のモデルはClaude Fable 5.1のブロックを読めません。前章の「古いモデルが読めないようにする」仕組みの一例です。なお、Opus 5.5もFable 5.1のブロックは読めません。会話の途中でFable 5.1からOpusへ切り替えるルーティングを入れている場合、それまでの推論は引き継がれず、エラーも出ません。
ドキュメントでは、原文が挙げたSonnet 5.5に加えてClaude Haiku 5.5も対象で、thinkingブロックは生成したアカウントか、それに紐づくアカウントでしか使えません。会話履歴を別アカウントに持ち回す設計では、推論は引き継がれない前提で設計します。
遮断されても課金されるリクエストを避ける
前述のとおり遮断されたリクエストにも課金され、表のとおり誤検知率は0.1%未満ですがゼロではありません。筆者としては、正当な用途でも、モデル自身の推論を全文そのまま出させるようなプロンプトは避けておくのが無難だと考えます。なお、遮断時にどんなレスポンスが返るかは、原文にもドキュメントにも書かれていません。
限界と注意点
- 90〜99%、10〜100倍といった効果の数字について、測定方法の詳細は原文に書かれていません
- 原文は単独の論文ではなくブログ記事です。分類器の評価データやレッドチームの条件は公開されていません
- preserved thinkingの仕様はベータヘッダーや日付付きの機能名を含み、今後変わる可能性があります。実装前にドキュメントの最新版を確認してください
- 本記事は実機で400エラーや
input_transformationsを再現したものではなく、ドキュメントの記述に基づく整理です
まとめ
Anthropicの記事は、推論の書き起こしを蒸留の一番の標的と位置づけています。そのうえで、推論の行き先の制御、抽出の検知、繰り返し試行の抑止という3つの防御を入れ、流出を大きく減らしたと報告しています。
API連携側にとっての要点は、systemとtoolsを会話中に固定し、messagesは追記だけにすることです。古いツール結果の間引きやsystemの組み直しをしている自作エージェントでは、2026年8月31日以降に作ったアカウントで対象モデルを使うと、既定で400エラーが返ります。古いアカウントでも、ベータヘッダーを付けてinput_transformationsのthinking_mismatch_allowedを見ておくと移行しやすくなります。また、途中でモデルを切り替えたりアカウントをまたいだりすると、推論はエラーなしで捨てられます。Claude Code、Claude Agent SDK、Managed Agents経由で使っているなら、対応は不要です。
誰かの参考になれば幸いです。
参考リンク:
