【実務・中級編】 LLMの推論APIに対するモデル反転攻撃(Model Inversion) – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

LLMの「記憶」を暴く：モデル反転攻撃（Model Inversion）と現場で使える鉄壁の防御術

現場のエンジニア諸君、お疲れ様。最近はLLMをAPI経由で組み込むのが当たり前になったが、その裏で「学習データがうっかり漏洩している」という事実に気づいている者はどれくらいいるだろうか。

今日は、API越しのモデル反転攻撃（Model Inversion Attack）について話そう。教科書的な「モデルの重みを入手して…」という話ではない。APIのレスポンスを執拗に叩き続け、学習データに混入した機密情報をパズルのように再構築する、実戦的な攻撃の話だ。

なぜLLMのAPIからデータが漏れるのか

モデル反転攻撃の本質は、「出力の偏り」を統計的に逆算することにある。例えば、特定のユーザーの個人情報や、機密コードが学習データに含まれていた場合、その情報を想起させるような巧妙なプロンプト（プロンプト・インジェクションの変種）を投げ続けると、モデルは「もっともらしい続き」として学習データに過剰適合（Overfitting）した断片を吐き出してしまう。

特に、Fine-tuningしたモデルや、RAGを利用していない生に近いLLMほど、このリスクが高い。「うちは機密情報を学習させていない」と言い切れるか？ログの紛れ込み、API経由の入力を自動的に再学習する設定…盲点はそこら中にあるんだ。

攻撃のロジック：何が起きているのか

攻撃者は通常、以下のような手順を踏む。

1. プロービング（探索）: ターゲットとなる情報（例：社内エンジニアのメールアドレスやAPIキー）の断片を投げ、モデルの反応を見る。
2. 確率分布の利用: logprobs（対数確率）が返ってくるAPIであれば、出力の確信度を解析し、最も確率の高いトークンを繋ぎ合わせることで、機密データの復元精度を飛躍的に高める。
3. 推論の繰り返し: レート制限を回避しつつ、数万回単位で似たような入力を投げ、モデルが「記憶」を吐き出す境界線を探り当てる。

実務で組むべき「鉄壁」の防御策

「APIを止める」のが最も安全だが、ビジネスはそうもいかない。我々が実装すべきは、「攻撃者の試行コストを、割に合わないレベルまで引き上げる」ことだ。

1. レート制限とバースト制御（Nginxでの実装）

まずは基本的なレート制限だ。攻撃者が短時間に数千回ものリクエストを投げられないようにする。Nginxの limit_req モジュールを適切に設定しよう。

# Nginx設定: 1秒間に許容するリクエスト数を制限
limit_req_zone $binary_remote_addr zone=llm_api_limit:10m rate=1r/s;

server {
    location /v1/chat/completions {
        # 1秒間に1回のみ許可、バーストを3回まで許容
        limit_req zone=llm_api_limit burst=3 nodelay;
        
        # 制限を超えたら429エラーを明示的に返す
        limit_req_status 429;
        
        proxy_pass http://backend_llm_service;
    }
}

2. 出力のランダム化とセマンティック・フィルター（Python）

推論APIの温度（temperature）を意図的に高く保つだけでは不十分だ。出力されたテキストに対し、正規表現や軽量なBERTモデルを用いた「機密情報フィルタリング」をラッパーとして実装する。

import re

def filter_sensitive_info(text):
    """
    出力からメールアドレスやAPIキー等のパターンを検出し、マスク処理を行う
    """
    # 例: シンプルなメールアドレスのパターンマッチ
    email_pattern = r'[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+'
    masked_text = re.sub(email_pattern, "[MASKED_EMAIL]", text)
    
    # 実際にはここに、機密情報のエンティティ抽出を行う判定ロジックを入れる
    return masked_text

# API呼び出し後の処理例
def secure_llm_response(raw_response):
    filtered_content = filter_sensitive_info(raw_response["choices"][0]["message"]["content"])
    return filtered_content

3. セマンティック・トラップ（ハニーポット）

さらに一歩進んだ対策として、「わざと偽の機密情報を含めた入力」を監視する手法がある。APIへの入力や出力に「カナリアトークン」を紛れ込ませ、それがモデルを通じて出力された瞬間、攻撃を検知してIPを即座にブロックする仕組みだ。

最後に：エンジニアが持つべき視点

セキュリティは「設定して終わり」のツールではない。攻撃者は常に「APIのレスポンスの揺らぎ」の中に答えを探している。

ログを監視せよ: 短時間に同じようなリクエストが連続しているなら、それはモデル反転攻撃の兆候だ。
出力を信じるな: LLMの出力はユーザーに渡す前に、必ずアプリケーション層で洗浄（Sanitization）する。
データのライフサイクルを把握せよ: どのデータが学習に使われ、どのデータが推論に使われているか。この境界線が曖昧な場所こそが、君たちの最大の脆弱性になる。

現場のコードが強固であれば、攻撃者は疲弊して去っていく。さあ、今すぐサーバーのログを確認し、レート制限の設定を見直すんだ。それが、我々エンジニアの責務だ。