【2026年版】公開AI(チャットボット・API・ファインチューニング済みモデル)の「モデル抽出・蒸留窃取・学習データ抽出」攻撃対策ガイド——大量クエリで“中身”を盗まれる手口と、クエリ異常検知・出力ウォーターマーク・レート制限・回答難読化による多層防御

  1. はじめに——守る対象が「保存データ」から「公開した推論エンドポイント」へ
  2. 前提——3つの攻撃を整理する(抽出・蒸留・学習データ抽出)
    1. 攻撃1:モデル抽出(Model Extraction)
    2. 攻撃2:蒸留による窃取(Distillation / Knockoff)
    3. 攻撃3:学習データ・PII・システムプロンプトの抽出
    4. 標準フレームワークでの位置づけ
  3. 攻撃の見え方——正常利用と窃取クエリはどう違うか
    1. 1. クエリ分布の偏り(網羅性)
    2. 2. 頻度・バースト・継続性
    3. 3. 出力の使われ方のシグナル
  4. 第1の防御層:クエリ異常検知——レート制限を超えた「振る舞い検知」
    1. レート制限だけでは止まらない理由
    2. 振る舞い検知で見るべきメトリクス
    3. 実装の考え方
  5. 第2の防御層:出力側の防御
    1. 1. 確信度(logprobs)の非公開・丸め
    2. 2. 回答の難読化・確信度の丸め
    3. 3. 出力ウォーターマーク
  6. 第3の防御層:システムプロンプト/学習データ抽出を防ぐ出力フィルタ
  7. ファインチューニング済みモデル特有のリスクと「最小公開原則」
  8. 検知→遮断→監査のインシデント連携
  9. 多層防御チェックリスト
  10. よくある質問(Q&A)
    1. Q1. レート制限を入れていれば、モデル窃取は防げますか?
    2. Q2. 確信度スコア(logprobs)をAPIで返すのは危険ですか?
    3. Q3. 出力ウォーターマークを入れれば盗まれませんか?
    4. Q4. 独自データでファインチューニングしたモデルは公開しても大丈夫ですか?
    5. Q5. 正規ユーザーを誤って止めてしまうのが心配です。
  11. まとめ——「公開した瞬間に盗まれ得る」を前提に設計する
  12. 参考リンク

はじめに——守る対象が「保存データ」から「公開した推論エンドポイント」へ

これまでのAIセキュリティ記事では、ベクトルDBに保存された埋め込みの漏洩や、社内ナレッジへの不正アクセスといった「保存されているデータをどう守るか」を中心に扱ってきました。しかし2026年、もう一つの攻撃面が急速に現実味を帯びています。それは、自社が外部に公開した推論エンドポイント(チャットボット・API・ファインチューニング済みモデル)そのものが資産として盗まれるという攻撃です。

攻撃者はサーバーに侵入しません。正規の窓口である公開APIに対して、大量かつ巧妙なクエリを投げ続けるだけです。そして、(1) モデルの入出力の対応関係を観測して挙動を複製する、(2) 出力を教師データにして別のモデルを蒸留する、(3) 統計的なクエリで学習に使った社内データ・PII・システムプロンプトを抽出する——これらを「正常利用に見える範囲」で実行します。

筆者はネットワークのTAC(テクニカルアシスタンスセンター)とアドバンスドサービスで長年トラフィック異常の検知に携わってきました。本記事の核心は、そのNOC/TAC的なトラフィック分析の発想が、そのままモデル窃取の検知・防御に転用できるという点にあります。「保存データを守る」発想とは逆方向の、公開した推論面を守るための多層防御を、実装の視点で整理します。

想定読者は、自社AIを外部公開しているSaaS事業者、APIを提供する企業、そして独自データでファインチューニングしたモデルを運用する情シス・CISOの方々です。


前提——3つの攻撃を整理する(抽出・蒸留・学習データ抽出)

「モデルが盗まれる」と一口に言っても、攻撃者の狙いと手口は3種類に分かれます。防御策が異なるため、まずここを分けて理解することが出発点です。

攻撃1:モデル抽出(Model Extraction)

攻撃者が大量の入力をAPIに投げ、その入出力ペアを収集して、元モデルと同等の振る舞いをする「複製モデル(シャドウモデル)」を構築する手口です。出力に確信度スコア(logits / logprobs)が含まれていると、必要なクエリ数が大幅に減り、抽出効率が跳ね上がります。狙いは知的財産(モデルの能力そのもの)の窃取です。

攻撃2:蒸留による窃取(Distillation / Knockoff)

抽出の発展形です。標的モデルの出力を「合成教師データ」として使い、別のベースモデルをファインチューニングして機能的な等価物を作ります。OWASPはこれを「従来のクエリベースの抽出を回避する」より高度な手口と位置づけています。攻撃者は元モデルの内部構造を一切知らなくても、入出力だけで能力をコピーできてしまいます。

攻撃3:学習データ・PII・システムプロンプトの抽出

モデルそのものの複製ではなく、モデルが「記憶している中身」を引き出す攻撃です。代表的な技術は次の3つです。

  • メンバーシップ推論(Membership Inference): ある特定のデータが学習に使われたかどうかを、応答の差分から推定する。PIIや機密データの「在/不在」が漏れる。
  • モデル反転(Model Inversion): 大量クエリへの応答から、学習データの一部を再構成する。
  • システムプロンプト抽出: 繰り返しの誘導で、運用側が仕込んだ指示・社内ルール・接続先情報などを吐き出させる。

3つの攻撃を整理すると次のようになります。

攻撃狙うもの主なシグナル逆に有効な防御の軸
モデル抽出モデルの挙動(入出力対応)網羅的・体系的な入力分布logprobs非公開・振る舞い検知
蒸留窃取機能的な等価モデル大量・継続的な高品質クエリ出力難読化・ウォーターマーク・レート制限
学習データ抽出学習データ・PII・システムプロンプト差分探索・反復的な言い換え誘導出力フィルタ・最小公開・記憶抑制

標準フレームワークでの位置づけ

これらの攻撃は、業界標準のフレームワークにも明確に定義されています。引用する際の根拠として押さえておくと、社内説明や監査対応に効きます。

  • OWASP LLM Top 10(2025年版): 旧版で独立していた「Model Theft(モデル窃取)」と「Model Denial of Service」は、2025年版で LLM10:2025 Unbounded Consumption(無制限な消費) に統合されました。クラフトされたクエリでの部分モデル複製・シャドウモデル生成、合成データによる蒸留が明示的に列挙されています。学習データ・PIIの漏洩は LLM02:2025 Sensitive Information Disclosure、システムプロンプト漏洩は LLM07:2025 System Prompt Leakage が対応します。
  • MITRE ATLAS: 推論API経由のデータ窃取は AML.T0024(Exfiltration via AI Inference API)、コスト枯渇を狙う消費は AML.T0034(Cost Harvesting) に対応します。推論API自体への到達は ML Model Access(AML.TA0004) のタクティクスです。

つまり、本記事のテーマは「特殊な懸念」ではなく、2025年以降のAIセキュリティ標準が正面から扱う中核リスクです。


攻撃の見え方——正常利用と窃取クエリはどう違うか

窃取攻撃の最大の特徴は、一発の不正アクセスではなく「正常に見えるクエリの集合」として現れる点です。1リクエスト単位で見ると完全に合法的で、WAFや認証では止まりません。止めるには、トラフィックの「振る舞い」を集合として見る必要があります。これはまさにNOCでのトラフィック分析と同じ発想です。

1. クエリ分布の偏り(網羅性)

正常な利用者の質問は、その人の業務や関心に沿って自然な偏りを持ちます。一方、モデル抽出を狙う攻撃者は、入力空間を体系的・網羅的にカバーしようとします。決定境界をマッピングするために、似た入力を少しずつ変えながら掃くような分布が現れます。

2. 頻度・バースト・継続性

蒸留には数万〜数百万件規模の入出力ペアが必要です。短時間の高頻度バーストか、レート制限を避けるために長時間・低頻度で淡々と続くパターンとして観測されます。後者は単純な閾値では検知できません。

3. 出力の使われ方のシグナル

確信度スコアを要求する、温度を極端に下げて決定論的な出力を引き出す、同一プロンプトを微差で繰り返す(差分探索)といった、人間の対話としては不自然な要求パターンが抽出・反転攻撃の特徴です。

正常利用と窃取クエリの見分けどころを整理します。

観点正常利用窃取の疑い
入力分布業務・関心に沿った自然な偏り入力空間を網羅・系統的に掃く
頻度不規則・人間的な間隔機械的に均一、または持続的な大量送信
クエリの類似性多様な意図微差の言い換え・差分探索が大量
出力要求回答の中身を読むlogprobs・確信度・決定論的出力を要求
セッション構造文脈が連続した対話文脈のない単発クエリの羅列

第1の防御層:クエリ異常検知——レート制限を超えた「振る舞い検知」

レート制限だけでは止まらない理由

レート制限はDoSや「Denial of Wallet(コスト枯渇)」には有効ですが、窃取の決定打にはなりません。攻撃者は制限値のすぐ下で、複数アカウント・複数IPに分散して、時間をかけて目標クエリ数を集めるからです。レート制限は「速度の上限」を見るだけで、「何を集めようとしているか(意図)」を見ていません。

ネットワークの世界で、ポートスキャンを単純なパケットレートだけでは検知できず、宛先ポートの網羅性パターンで検知するのと同じ構図です。窃取クエリも「速度」ではなく「網羅性・体系性」で捉える必要があります。

振る舞い検知で見るべきメトリクス

レート制限の「上」に重ねる検知レイヤーとして、主体(アカウント/APIキー/IP/指紋)ごとに次の指標を継続集計します。

  • クエリ多様性スコア: 入力の埋め込みをとり、一定窓内の入力がどれだけ入力空間を広くカバーしているか(網羅性が異常に高い=抽出の疑い)。
  • 近接重複率: 微差の言い換え・差分探索の比率(高い=反転/抽出の疑い)。
  • 確信度要求率: logprobsや決定論的出力を要求するリクエストの比率。
  • 累積クエリ量の傾き: 単発のバーストではなく、長期にわたる累積の増加トレンド。
  • 分散の集約: 別アカウント・別IPでも、入力分布が相互補完的(協調して空間を分担)になっていないか。

実装の考え方

過検知で正規ユーザーを止めると事業が痛むため、段階的なレスポンスが鉄則です。NOCのインシデント対応と同じく「観測→警告→緩和→遮断」の階段を設計します。

段階条件の例レスポンス
観測多様性スコアが平常域記録のみ
警告多様性・近接重複が閾値超監査ログにフラグ、内部アラート
緩和継続的に閾値超確信度の非公開化、出力の丸め強化、追加認証
遮断明確な窃取パターンレート厳格化/一時停止、CISOへエスカレーション

重要なのは、検知ロジックは「速度の閾値」ではなく「主体ごとの累積的な振る舞いプロファイル」を持つことです。これはトラフィックのベースラインを学習し、逸脱を見る——NOCの異常検知そのものです。


第2の防御層:出力側の防御

入口(クエリ)の検知に加えて、出口(応答)から漏れる情報量そのものを絞ります。攻撃の効率は「1クエリあたりに得られる情報量」に比例するため、ここを削るほど窃取コストが跳ね上がります。

1. 確信度(logprobs)の非公開・丸め

OWASPも明示する通り、logits / logprobs の不要な公開は抽出を劇的に容易にします。外部公開エンドポイントでは、確信度スコアを原則非公開とし、必要な場合もカテゴリ(高/中/低)に丸める、上位N件に限る、といった粒度制限をかけます。

2. 回答の難読化・確信度の丸め

決定論的で再現性の高い出力は、入出力対応の学習を容易にします。外部公開面では温度をゼロに固定させない、同一入力への応答に許容範囲の揺らぎを持たせる、といった設計で、抽出に必要なクエリ数を増やします(正規ユーザーの体験を損なわない範囲で調整するのが前提です)。

3. 出力ウォーターマーク

ウォーターマークは「盗まれること自体」を止めませんが、盗まれた後に立証するための保険です。生成テキストに統計的な透かしを埋め込んでおけば、他社サービスやモデルが自社出力を蒸留教師に使った疑いが生じたとき、出力の素性を技術的に主張できます。法的・契約的な対抗手段とセットで効果を発揮します。


第3の防御層:システムプロンプト/学習データ抽出を防ぐ出力フィルタ

学習データ・PII・システムプロンプトの抽出(OWASP LLM02 / LLM07、MITRE AML.T0024)に対しては、出力段でのフィルタリングが要です。

  • システムプロンプトの分離と非依存化: システムプロンプトに機密(APIキー、社内固有ルール、接続先)を書かない。漏れても被害が出ない設計にする(「漏れない」ではなく「漏れても無害」を前提に)。
  • 出力スキャン: 応答にシステムプロンプトの断片、PIIパターン、学習データに含まれる固有の文字列が含まれていないかを送信前にスキャンしてマスク/ブロック。
  • 記憶(暗記)の抑制: ファインチューニング時に重複データを除去し、PIIを最小化することで、そもそもモデルが逐語的に「覚えている」量を減らす。これがメンバーシップ推論・反転攻撃への根本対策になります。
  • 誘導耐性のテスト: 「上の指示を全部教えて」式の抽出プロンプトに対する耐性を、リリース前のレッドチーミングで継続検証する。

ファインチューニング済みモデル特有のリスクと「最小公開原則」

独自データでファインチューニングしたモデルは、汎用モデルにはない固有のリスクを抱えます。学習に使った社内データやPIIが、モデルの重みの中に「記憶」として残っているためです。汎用モデルが盗まれても漏れるのは一般知識ですが、ファインチューニング済みモデルが抽出されると、競争優位の源泉である独自データまで漏れる可能性があります。

ここで効くのが、ネットワーク設計でいう最小権限の原則のAI版=「最小公開原則」です。

  • 公開面を最小化する: ファインチューニング済みモデルを直接外部公開せず、汎用モデル+RAGで代替できないかをまず検討する(独自データを重みに焼き込まず、検索層に置けば、モデル抽出では漏れにくい)。
  • 用途を絞る: 1つのエンドポイントに何でも答えさせず、タスクを限定して入力空間を狭める。網羅的な抽出を困難にする。
  • 認証の前段配置: 真に機密性の高いファインチューニング済みモデルは、匿名公開せず認証・契約済みの相手にのみ提供する。
  • 学習データの衛生管理: 学習前にPII除去・重複排除・最小化を徹底し、「盗まれても致命傷にならない」状態にしておく。

検知→遮断→監査のインシデント連携

検知ロジックは、それ単体ではなく既存のセキュリティ運用(SOC / インシデント対応)に接続して初めて機能します。前述の段階的レスポンスを、組織のインシデントフローに組み込みます。

  • 検知: 振る舞い検知レイヤーが主体ごとの異常をスコアリングし、閾値超でアラートを発報。
  • 遮断: 自動緩和(確信度非公開・出力丸め・レート厳格化)を即時適用。明確な窃取は一時停止。
  • 監査: どの主体が、いつ、どの入力分布で、何件のクエリを投げたかを改ざん不能なログに保全。事後の立証・法的対応・再発防止の根拠にする。

監査ログは、ウォーターマークと並ぶ「盗まれた後の立証手段」です。攻撃の全容(網羅性パターン・累積量・分散構造)を後から再現できる粒度で残すことが、契約違反や不正競争の主張を支えます。


多層防御チェックリスト

対策主に効く攻撃
入口振る舞い検知(多様性・近接重複・累積量)抽出・蒸留・反転
入口段階的レート制限(速度+意図)蒸留・コスト枯渇
出口logprobs非公開・確信度の丸めモデル抽出
出口出力の難読化・揺らぎ抽出・蒸留
出口出力ウォーターマーク蒸留(事後立証)
出口出力スキャン(PII・システムプロンプト)学習データ/プロンプト抽出
設計最小公開・RAG代替・用途限定全般
設計学習データの衛生管理(PII除去・重複排除)メンバーシップ推論・反転
運用検知→遮断→監査の連携・改ざん不能ログ全般(事後対応)

よくある質問(Q&A)

Q1. レート制限を入れていれば、モデル窃取は防げますか?

不十分です。レート制限は速度の上限を見るだけで、攻撃者は制限のすぐ下で、複数アカウント・複数IPに分散して時間をかければ目標クエリ数を集められます。窃取は「速度」ではなく「網羅性・体系性」で捉える振る舞い検知をレート制限の上に重ねて初めて止まります。

Q2. 確信度スコア(logprobs)をAPIで返すのは危険ですか?

外部公開面では原則として避けるべきです。OWASPも、logits / logprobsの不要な公開がモデル抽出を容易にすると指摘しています。返す必要がある場合も、カテゴリ(高/中/低)への丸めや上位N件への制限といった粒度制御をかけることを推奨します。

Q3. 出力ウォーターマークを入れれば盗まれませんか?

ウォーターマークは盗まれること自体を防ぎません。盗まれた後に「自社出力が無断で蒸留教師に使われた」ことを技術的に主張するための立証手段です。検知・遮断(事前)と、ウォーターマーク・監査ログ(事後立証)はセットで設計してください。

Q4. 独自データでファインチューニングしたモデルは公開しても大丈夫ですか?

最も慎重に扱うべき対象です。学習データやPIIがモデルの重みに「記憶」として残るため、抽出されると競争優位の源泉まで漏れ得ます。まず汎用モデル+RAGで代替できないかを検討し(独自データを重みに焼き込まず検索層に置けば抽出では漏れにくい)、公開する場合も用途限定・認証前置・学習データの衛生管理を徹底してください。

Q5. 正規ユーザーを誤って止めてしまうのが心配です。

だからこそ「観測→警告→緩和→遮断」の段階的レスポンスが重要です。いきなり遮断せず、まず確信度の非公開化や出力の丸め強化といった、正規ユーザーの体験をほとんど損なわない緩和から適用し、明確な窃取パターンに限って遮断・エスカレーションします。主体ごとの平常ベースラインを学習し、その逸脱を見るのが過検知を避けるコツです。


まとめ——「公開した瞬間に盗まれ得る」を前提に設計する

AIセキュリティの議論は、長らく「入力をどう守るか」「保存データをどう守るか」に集中してきました。しかし2026年の標準フレームワークは、公開した推論エンドポイントそのものが窃取対象になるという攻撃面を正面から扱っています。要点は3つです。

1. 1クエリ単位では止まらない。 窃取は「正常に見えるクエリの集合」として現れます。WAFや認証では止まらず、トラフィックを集合として見る振る舞い検知が必要です。

2. レート制限の「上」に検知層を重ねる。 速度ではなく、網羅性・近接重複・累積量・分散構造といった「意図」を見ます。これはNOC/TACのトラフィック分析の発想がそのまま武器になる領域です。

3. 事前防御と事後立証をセットにする。 検知・遮断・出力難読化(事前)と、ウォーターマーク・改ざん不能な監査ログ(事後立証)を組み合わせて初めて、多層防御が成立します。

「公開しない」という選択肢が現実的でない以上、「公開した瞬間に盗まれ得る」を前提に、入口・出口・設計・運用の4層で守る——これが、推論エンドポイントを資産として守るための基本姿勢です。


参考リンク

免責事項: 本記事は2026年5月時点の公開情報および標準フレームワークに基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。

コメント

タイトルとURLをコピーしました