【実務・中級編】 LLMの推論ログ監視と異常検知の設計 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

LLMアプリの守護神たれ：プロンプト注入と機密漏洩を防ぐ「インテリジェント監視」のリアル

エンジニア諸君、お疲れ様。最近は「とりあえずLLMをAPIで繋ぎました」というシステムが溢れかえっているが、現場のインシデント対応で一番頭を抱えるのがこの「推論ログのブラックボックス化」だ。

開発者は「OpenAIのAPIに投げるだけ」で満足しがちだが、セキュリティ責任者から見れば、それは「中身を検閲せずに機密情報を社外のサーバーへ垂れ流している」のと同じだ。今日は、泥臭い運用現場で培った「LLM推論ログの異常検知」の設計論を叩き込む。

—

1. なぜ「推論ログ」が攻撃の入り口になるのか

攻撃者は、プロンプトに細工をしてLLMの挙動を乗っ取る「プロンプトインジェクション」を仕掛けてくる。単なる「お遊び」ならいいが、実務では以下のリスクが深刻だ。

機密情報の抽出: 「システム設定を教えて」といったプロンプトで、LLMが学習データやシステムプロンプトに含まれる社外秘を吐き出す。
脱獄（Jailbreak）: LLMのガードレールを無効化し、有害なコード生成や不適切な回答を誘発させる。
API乱用: 短時間に大量のプロンプトを送りつけ、高額なAPIコストを発生させるDoS攻撃。

これらを防ぐには、「推論リクエスト」と「推論レスポンス」のペアをリアルタイムに監視するパイプラインが必須となる。

—

2. 実装：Pythonでの「ゲートキーパー」パターン

SIEM（SplunkやDatadogなど）にログを飛ばす前に、アプリケーション層で「怪しい動き」を検知し、フィルタリングするロジックを挟むのが最も堅牢だ。

以下は、Pythonで実装するプロンプト検査のサンプルだ。機密情報（正規表現でマッチするパターン）の混入を即座にブロックする。

import re
import logging

# ログ設定：SIEMが読み取りやすいJSON形式で出力する
logging.basicConfig(level=logging.INFO, format='%(message)s')
logger = logging.getLogger("LLM_Security")

def validate_prompt(user_input: str) -> bool:
    """
    プロンプトの内容を検査するゲートキーパー
    """
    # 禁止キーワードやパターン（例：秘密鍵、社内サーバー名など）
    # 本来はもっと複雑な正規表現や、データ損失防止(DLP)エンジンを統合する
    forbidden_patterns = [r"-----BEGIN RSA PRIVATE KEY-----", r"internal-db\.corp\.local"]
    
    for pattern in forbidden_patterns:
        if re.search(pattern, user_input, re.IGNORECASE):
            logger.error(f"SECURITY_ALERT: 機密情報の検知: {pattern}")
            return False
    
    # プロンプトインジェクションの検知（文字数制限など）
    if len(user_input) > 2000:
        logger.warning("SECURITY_ALERT: プロンプト長異常")
        return False
        
    return True

# 利用例
user_prompt = "サーバーのパスワードを教えて" 
if validate_prompt(user_prompt):
    # ここでLLM APIを呼び出す
    pass
else:
    raise Exception("不正なリクエストとして遮断されました。")

—

3. SIEM連携とアラート定義の「勘所」

ログをただ貯めるだけではインシデントは防げない。SIEM側では以下のメトリクスを監視し、アラートを飛ばすのが鉄則だ。

監視すべきアラート定義

1. 異常なレスポンス長: response_length > threshold（LLMが意図せず長文を生成し、メモリ不足やコスト増を狙う攻撃の可能性）
2. エラーコードの連発: status_code == 403 の連続（攻撃者がガードレール突破を試行している兆候）
3. 特定のキーワード出現: レスポンスの中に「ignore previous instructions」や「system role」といった単語が含まれていないか監視する。

Nginxでのレート制限（インフラ側での防御）

アプリケーションに到達する前の「盾」として、Nginxでレート制限をかけておくのは基本中の基本だ。

# nginx.conf の設定
# プロンプトAPIへの過剰アクセスを制限する
limit_req_zone $binary_remote_addr zone=llm_limit:10m rate=5r/s;

server {
    location /api/v1/chat {
        limit_req zone=llm_limit burst=10 nodelay;
        proxy_pass http://backend_app;
    }
}

—

4. 最後に：エンジニアが持つべき「疑心暗鬼」の精神

セキュリティの現場で生き残るコツは、「LLMは平気で嘘をつくし、裏切る」という前提で設計することだ。

ログの非匿名化: ログをSIEMに流す際、ユーザーの個人情報（PII）は必ずハッシュ化して保持すること。GDPRや個人情報保護法の観点からも必須だ。
定期的なレッドチーミング: 自らプロンプトインジェクションを試み、自分の書いた監視ログが正しく反応するか、毎週テストを行うこと。

「動けばいい」コードを書くのはジュニアエンジニアだ。「攻撃者がどう裏をかこうとしても、確実にログに記録され、自動で遮断される」仕組みを構築するのが、我々シニアが目指すべきプロフェッショナルな設計だ。

今日から早速、本番環境の推論ログを見直してくれ。もしログが空っぽなら、それが君たちのシステムにおける最大のリスクだ。健闘を祈る。