Anthropicの蒸留攻撃対策を解説|攻撃者が集めるデータを約90〜99%削減

Anthropicは2026年10月12日、Claudeに対する蒸留攻撃への新しい防御策を発表しました。初期の証拠では、攻撃者が収集できたデータ量を約90〜99%減らしたと説明しています。

蒸留攻撃は、あるモデルの能力を別のモデルへ複製するため、大量の応答や推論データを集める手法です。API利用企業は、回答品質だけでなく会話履歴の再送方法やブロック時の扱いも点検します。

発表された対策は、推論ブロックの移動を制御する仕組み、2段階分類器、繰り返し試行への利用制限と課金の3系統です。90〜99%というデータ量の初期証拠と、推論トークンが10〜100倍以上少なくなったという自社推計を分けて読み、API連携で点検すべき箇所を整理します。

※本記事は2026年10月20日時点の情報です。

2026年10月12日の発表で、攻撃者が収集できたデータ量は初期の証拠で約90〜99%減。企業側は会話履歴・ブロック・監視を点検する
90〜99%は収集データ量の初期証拠で、顧客側の削減率ではない

Anthropicが蒸留攻撃対策を発表|攻撃者の収集データ量を初期の証拠で約90〜99%削減

蒸留は、能力の高いモデルの応答で別のモデルを学習させる方法です。モデルを小型化する正当な用途もありますが、Anthropicが今回説明したのは、元の開発者の許可なく能力を複製する大規模な抽出キャンペーンを指します。

攻撃者には最終回答以外に、Claudeが回答前に作る推論の全文記録も価値があります。モデルが結論へ到達する手順を含み、別のモデルの学習に使いやすいためです。Anthropicは初期対策として推論を要約して表示し、全文記録で学習した場合のSWE-bench Verified成績80.4%に対して、要約記録では71.8%だったと説明しています。

ただし、約90〜99%は攻撃者が収集できたデータ量についての初期の証拠です。すべての顧客の出力が同じ割合で減る意味でも、将来の攻撃を防ぐ保証でもありません。企業は数字だけで判断せず、データの再利用範囲を点検します。

ポイント

90〜99%は収集データ量の初期証拠です。顧客側の削減率や、すべての攻撃への防御率として読み替えないことが判断の出発点になります。

防御1|preserved thinkingで推論ブロックの移動を制御

最初の防御は、推論ブロックを別の会話やアカウントへ移して読み出す経路を狭めることです。Claude Fable 5.1とClaude Opus 5.5にpreserved thinkingを導入しました。2026年8月31日以降に作られた新しいAPIアカウントでは、過去のコンテキストを編集しにくくします。

会話途中のメッセージ差し替えは、保存された推論ブロックとの対応を崩します。新しいアカウントや対象モデルでは、履歴の再構成がエラーの要因です。Fable 5.1の特徴や長時間の会話設計は、Claude Fable 5.1の解説と合わせて判断材料にできます。

公式Docsは、同じ会話の履歴を途中で組み替えず、APIから返った内容を保ったまま末尾に追加するappend-onlyの連携を案内しています。会話を再構成する処理がある企業は、公式Platform Docs(preserved thinking)で現在のモデルと設定に合う扱いを確認してください。

Claude Sonnet 5.5では、推論トランスクリプトを、それを生成したリクエストの組織だけが利用できるようにしました。複数の顧客を1つの会話保存領域で扱うサービスでは、どの組織のリクエストで作られた推論かを追跡できるデータ設計が必要です。Claude Opus 5.5・Sonnet 5.5の比較も、対象モデルを選ぶときの補助材料です。

ポイント

APIクライアントは、会話履歴を「編集して再構成」する設計から「返却値を保持して末尾に追加」する設計へ移せるかを、対象アカウントとモデルごとに点検する必要があります。

防御2・3|分類器と利用制限で抽出の試行を止める

推論ブロックの移動を制御しても、攻撃者は隠された推論を引き出すリクエストを繰り返します。Anthropicは、こうした能動的な抽出の試行を2段階分類器で検知し、アカウント単位の利用制限を重ねる構造です。回答を受動的に集める通常利用の経路とは、検知対象を分けて考える必要があります。

2段階分類器は、攻撃者が推論を引き出そうとするリクエストを判定します。誤検知率は0.1%未満で、対象はClaude Sonnet 5.5、Claude Opus 5、Claude Opus 5.5、Claude Fable 5、Claude Fable 5.1です。翻訳やタグ付き出力を使った推論の抽出にも修正を加えました。

推論の抽出試行を2段階分類器(誤検知率0.1%未満)で判定し、利用制限、関連アカウントの停止へ進む。2026年9月24日から特定領域はブロック課金
抽出の試行は分類器で検知し、繰り返す利用者には制限と停止を重ねる

同じアカウントで推論の抽出を繰り返す利用者には、より厳しい利用制限を適用します。反復・継続的な試行と判断した場合は、関連アカウントを停止します。さらに2026年9月24日から、蒸留を含む、誤検知率0.1%未満の特定領域では、Claudeが応答する前に防御でブロックしたリクエストへの課金を再開しました。

誤検知率が0.1%未満でも、リクエスト量が大きいサービスでは正規利用への影響を無視できません。再試行の条件、ブロック時のログ、課金の扱い、問い合わせの責任者を決めておく必要があります。データ境界や安全策を設計するときは、AnthropicのEnterprise Frontier Safeguardsも関連する論点です。

効果は10〜100倍以上|数値とトレードオフを分けて読む

分類器導入後、Anthropicは抽出された推論トークンを自社基盤で推計し、導入前の10〜100分の1以下で推移したと説明しています。防御の完全実装後は10〜100倍以上減り、一部の日は測定できないほど少なかったとしています。

蒸留に関連するアカウントは数万件を停止し、キャンペーン開始から2時間未満で停止したケースも多くありました。効果の持続は不明で、いたちごっこが続くと説明しています。導入時は自社のリクエスト構造と監視体制に合わせて評価します。

防御主な仕組み企業側の負担・確認
preserved thinking。過去コンテキストの編集や推論ブロックの移動を制御。履歴をappend-onlyで扱い、対象モデルとアカウント時期を点検。
2段階分類器。推論の抽出試行を判定し、手法の変化に合わせて修正。誤検知、ブロック、再試行のログと運用を整える。
利用制限・停止・課金。反復試行を制限し、関連アカウントを停止。特定領域はブロック課金。課金条件と問い合わせ、サービス継続手順を決める。

ここで、90〜99%と10〜100倍以上を同じ割合として扱わないことが大切です。前者は攻撃者が収集できたデータ量の初期の証拠で、後者は抽出された推論トークン数の自社推計です。どちらも、顧客の出力や将来の攻撃に対する削減率を約束する数字ではありません。

ポイント

効果の数字は、対象、分母、測定方法が異なります。導入判断では、同じ指標にそろえようとせず、自社の抽出リスクと運用コストを別々に見積もります。

API利用企業が点検する4項目|履歴・課金・誤検知・監視

今回の変更は、Claudeを使うすべての企業が同じ修正を強制されるという話ではありません。対象モデル、2026年8月31日以降に作成されたアカウントか、会話履歴を加工して再送しているか、Message Batches APIを使っているかで影響の範囲が変わる仕組みです。アプリ・ゲートウェイ・運用の担当者に、次の4項目を確認してください。

API利用企業が点検する4項目: 対象モデルとアカウント、会話履歴の加工、APIの経路、運用監視
最初に、履歴のどこをアプリやゲートウェイが編集しているかを棚卸しする
  • 対象モデルとアカウント:preserved thinkingの対象モデルを使っているか、2026年8月31日00:00 UTC以降に作成されたアカウントかを、API管理者が確認します。
  • 会話履歴の加工:アプリやゲートウェイが履歴を要約・差し替え・再構成してから再送していないかを、連携担当者が洗い出します。途中の変更があるなら、公式Docsに沿った移行方法の検討が必要です。
  • APIの経路:通常のMessages APIだけでなく、Message Batches APIを使っている処理があるかを、バッチ担当者に確認します。経路によって確認すべき挙動が異なるため、実装条件は公式Docsで照合してください。
  • 運用監視:ブロック、再試行、課金、アカウント停止、連携変更をログとアラートで追い、正規利用への影響を業務側へ伝える窓口を、運用責任者と合意します。

特に、複数の顧客やモデルを1つのゲートウェイで扱う企業は、会話履歴をどこで保存・加工・再送しているかの追跡を可能にすることが重要です。アプリ担当だけでなく、ゲートウェイ担当とデータ基盤担当にも対象範囲を確認させ、顧客間の履歴が混ざらない境界を点検します。

実装の条件はモデルや設定ごとに細かく異なります。API担当者は、対象モデルと利用経路を整理したうえで、公式Platform Docs(preserved thinking)を確認してください。業務側はブロック時の再試行・課金・問い合わせの判断を決め、運用側は影響をログで追います。封じ込めと監視は、Claudeのサンドボックス脱出事例にも通じる論点です。

ポイント

最初に行うのはモデルの切り替えではなく、履歴のどの部分をアプリやゲートウェイが編集しているかの棚卸しです。そのうえで、ブロック・課金・再試行を含む運用を小さなトラフィックで評価します。

よくある質問

Q. 蒸留攻撃とは何ですか?

あるモデルの能力を別のモデルへ、元の開発者の許可なく複製する大規模な抽出キャンペーンです。

Q. 90〜99%削減は何が減った数字ですか?

攻撃者が収集できたデータ量の初期の証拠です。すべての出力や攻撃に対する保証ではありません。

Q. API利用企業は何を変更する必要がありますか?

対象モデルとアカウント時期、会話履歴を加工して再送する処理、Message Batches APIの利用有無を点検します。API担当者は実装条件を公式Platform Docs(preserved thinking)で確認し、アプリ・ゲートウェイ・運用の担当者と、履歴の扱い、再試行、課金、監視の分担を決めてください。

Q. 防御でブロックされたリクエストにも課金されますか?

蒸留を含む、誤検知率0.1%未満の特定領域では、2026年9月24日からClaudeが応答する前にブロックされたリクエストへの課金を再開しました。

まとめ

Anthropicの新しい蒸留攻撃対策は、推論ブロックの移動制御、2段階分類器、利用制限・停止・課金を組み合わせています。攻撃者が収集できたデータ量の初期の証拠は約90〜99%、抽出された推論トークンは導入前の10〜100分の1以下でした。

API利用企業は、対象モデルとアカウント時期、履歴編集、ゲートウェイ、ブロック時の課金と再試行を点検します。履歴をappend-onlyで扱い、誤検知や利用制限をログで追えば、連携障害の波及を抑えられます。

ポイント

蒸留対策はモデル提供者だけの機能ではなく、企業の履歴管理、ゲートウェイ、課金監視まで含む運用課題です。まずAPIリクエストの編集箇所を洗い出し、対象モデルの条件と照合してください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。