Anthropic は 2026年10月12日に、蒸留攻撃への防御を強めた結果、攻撃者が抜き取れるデータの量が約90〜99%減ったと公表しました。
蒸留攻撃は、他社の AI に大量の質問を投げて答えを集め、その答えで自社のモデルを鍛える手口です。
元になっている蒸留は正当な学習手法なので、どこからが「攻撃」なのかが分かりにくい言葉でもあります。
定義と手口、防ぎ方を押さえておくと、最近の API の仕様変更がなぜ入ったのかにも説明がつきます。
蒸留攻撃とは
蒸留攻撃は、モデルの開発元に無断で、そのモデルの能力を大量のやり取りから抜き取り、別のモデルに写し取る行為です。
元になっている蒸留は、大きな「教師」モデルの答えで小さな「生徒」モデルを学習させる、広く使われている手法です。
AI 企業が自社の大きなモデルを蒸留して、安くて速い小型版を作ることはごく普通に行われています。
蒸留の仕組みそのものは、別の記事で解説しました。
Anthropic は 2026年9月の脅威レポートで、不正な蒸留を「許可なく、隠れて、産業規模でモデルの能力を抜き取り、別のモデルに再現する活動」と定義しています。
同じレポートは、こうした活動の多くが、盗んだクレジットカードや API キーで作った偽アカウントの網に支えられていると書いています。
参考: Detecting and countering misuse of AI: September 2026（Anthropic）
Google も 2026年2月の報告で、同じものを「モデル抽出攻撃（model extraction attack）」と呼び、知的財産の窃取に当たるとしました。
参考: GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use（Google Cloud）
規約の面では、Anthropic の商用利用規約が、競合する AI モデルを学習させる目的でサービスを使うことを禁じています。
参考: Commercial Terms of Service（Anthropic）
正当な蒸留と蒸留攻撃を分けるのは、使う技術ではなく、開発元の許可があるかどうかです。
なぜ推論の過程が狙われるのか
蒸留攻撃でいちばん価値が高いのは、モデルが答える前に書く推論の過程の記録です。
最終的な答えだけでなく、どう考えてその答えに至ったかまで真似させられるので、生徒モデルの伸びが大きくなります。
Anthropic は、この差を自社の実験で示しました。
Claude Opus 4.8 の推論の全文で学習させたモデルは SWE-bench Verified で 80.4% を取り、要約した推論だけで学習させたモデルは 71.8% にとどまっています。
推論を要約してから見せるという初期の対策が効いたのは、この差があったからです。
答える前に考えるモデルの仕組みは、こちらにまとめています。
受け身の収集から聞き出す攻撃へ
最初の段階の攻撃は、普通の利用者と同じようにリクエストを送り、返ってきた答えで学習するだけでした。
推論が要約されるようになってからは、隠れた推論そのものを書き出させる方向に変わっています。
9月の脅威レポートには、「前の推論を一字一句そのまま出力して」と指示する単純なものから、推論を別の言語に「翻訳」させるものまで、実際の手口が載っています。
ある研究所は、それぞれ違うだまし方をした 12,000 件のリクエストで、どれが通るかを試していたそうです。
Google の報告にも、推論の言語を利用者の入力にそろえるよう指示して推論の全文を出させようとした、10万件を超えるプロンプトの事例があります。
偽アカウントの網で量を稼ぐ
量を稼ぐために、攻撃者は大量の偽アカウントをまとめて動かすプロキシの網を使います。
Anthropic は 2026年2月の報告で、3つの研究所が約2万4,000の不正アカウントから、Claude と1,600万回を超えるやり取りを生成したと公表しました。
同じ報告では、1つのプロキシの網が2万を超える不正アカウントを同時に管理していた例も挙げています。
参考: Detecting and preventing distillation attacks（Anthropic）
1件ずつ見れば普通の依頼でも、同じ型のプロンプトが何万回も、狭い能力に集中して届くと攻撃だと分かる、というのが Anthropic の説明です。
提供側はどう防いでいるのか
10月12日の発表によると、Anthropic の防御は3つの層でできています。
参考: Strengthening our defenses against distillation attacks（Anthropic）
推論の行き先を制限する
1つ目は、推論の記録がほかの会話・モデル・アカウントへ持ち出されないようにすることです。
Claude Fable 5.1 と Claude Opus 5.5 では preserved thinking という仕組みが入り、2026年8月31日以降に作られた API アカウントは過去の文脈を書き換えられなくなりました。
Claude Sonnet 5.5 の推論の記録は、そのリクエストを出した組織からしか読めません。
分類器で抜き取りを止める
2つ目は、推論を抜き取ろうとするリクエストを見分ける2段構えの分類器です。
Anthropic は、生物兵器への悪用を防ぐ安全策と同じくらいの頑健さにしたとし、誤検知の率は0.1%未満だと説明しています。
この分類器は、10月12日時点で Claude Sonnet 5.5、Opus 5 と 5.5、Fable 5 と 5.1 で動いているとのことです。
繰り返しを難しくする
3つ目は、同じアカウントから何度も試せないようにする仕組みです。
抜き取りを続けるアカウントには厳しい利用上限がかかり、しつこく続ければアカウントが停止されます。
9月24日からは、誤検知が0.1%未満の分野（蒸留を含む）に限って、安全策が応答前に止めたリクエストへの課金も再開しました。
効果の数字
Anthropic によると、分類器の導入後に攻撃者が抜き取れた推論のトークン数は、導入前の10分の1から100分の1以下に減りました。
蒸留に関わる数万のアカウントを停止し、その多くは攻撃を始めてから2時間以内だったそうです。
発表の冒頭に置かれた数字は、抜き取られるデータの量が約90〜99%減ったというものでした。
正規の開発者に出る影響
防御の副作用は、普通に API を使っている開発者にも出ています。
実装の手直しが要るのは preserved thinking で、送り返した推論のブロックより前の部分（system・tools・それまでの messages）が変わっていると、そのブロックは無効になります。
参考: Preserved thinking（Claude API Docs）
2026年8月31日（UTC）以降に作られたアカウントではこのチェックが既定で効き、既定の動作は 400 エラーです。
公式ドキュメントは、会話の途中で次のような操作をしている実装を確認の対象に挙げています。
- system プロンプトを作り直す（日付や、途中でつながった MCP サーバーの反映など）
- tools の一覧に足す、消す、書き換える
- 古いツールの結果を消したり縮めたりする
- 古いターンをクライアント側で要約し、新しいターンだけを推論ごと残す
- 推論のブロックを途中だけ抜いて、後ろを残す
対策の基本は、セッションの間は system と tools を固定し、messages を追記だけにすることです。
この規律はプロンプトキャッシュを効かせる条件と同じだと、公式ドキュメントにも書かれています。
Claude Code や claude.ai、Claude Agent SDK がリクエストを組み立てている場合は、何も変わりません。
すぐに直せないときのつなぎとして、ベータヘッダーを付けて食い違ったブロックを捨てる設定も用意されています。
// 公式ドキュメントのリクエスト例から thinking の部分だけを抜き出したもの
// ヘッダーに anthropic-beta: thinking-binding-controls-2026-08-01 が要る
"thinking": {
"type": "adaptive",
"block_binding": {
"prefix_mismatch_behavior": "drop_block"
}
}
// 省略ただし、捨てた推論はモデルが考え直すので、そのぶん出力のトークンが増えます。
Anthropic の計測では、毎ターン捨てた場合の出力トークンの増加は、effort が low で4.6%、max では67.1%でした。
ドキュメント自身も、drop_block は直すまでのつなぎで、長く使う設定ではないとしています。
蒸留攻撃の対策に残る課題
Anthropic 自身が、この成果がどれだけ続くかはまだ分からないと書いています。
攻撃と防御はいたちごっこで、高度で粘り強い回避の試みはまだ見ていない、という但し書きも付いていました。
効果の数字は、どれも Anthropic 自身による計測です。
攻撃者は Anthropic の API だけでなく、他社のクラウドや推論サービスにも通信を分散させています。
そのため Anthropic は、モデルの開発元だけでなく、プラットフォーム側も不正なアカウントの排除に加わる必要があると訴えました。
利用者の立場では、Google の報告が、蒸留攻撃そのものは一般の利用者のデータを直接脅かすものではなく、リスクは開発元とサービス提供者に集中するとしています。
一方で、正規でない転売の窓口を使うと話が変わります。
9月の脅威レポートは、こうしたプロキシのサービスが利用者に知らせずにやり取りを保存し、蒸留用に売っている例を報告しました。
最後に
蒸留攻撃は、正当な学習手法である蒸留を、許可なく産業規模で他社のモデルに向けたものです。
狙われるのは答えよりも推論の過程で、Anthropic は推論の行き先の制限、分類器、アカウント対策の3層で守っています。
その副作用として、API で会話の履歴を書き換える実装は、400 エラーや出力トークンの増加に当たるようになりました。
API を直接使うなら、system と tools を固定して履歴を追記だけにしておけば、履歴の書き換えのチェックで止められることはありません。
以上です。
コメントを残す