【実務・中級編】 AIガバナンスにおけるモデルカードとシステムカードの策定 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

AIガバナンスの「建前」を捨てろ：モデルカードとシステムカードで防ぐ現場の急所

エンジニア諸君、お疲れ様。今日もどこかでAI APIを叩き、LLMをプロダクトに組み込んでいることだろう。

最近、経営陣から「AIガバナンスを策定しろ」「モデルカードを作れ」という指示が飛んできて、頭を抱えているのではないか？多くの現場で、モデルカードは単なる「社内コンプライアンス用の形式的なドキュメント」として埃を被っている。だが、現場を知る我々にとって、それは攻撃者の侵入経路を塞ぐための「防御の地図」でなければならない。

今日は、教科書的な「透明性の確保」といった綺麗事は抜きにして、モデルカードとシステムカードを「攻撃者が悪用する隙間を埋めるための実戦的防具」としてどう活用すべきか、泥臭い話をしよう。

—

1. なぜモデルカードが「攻撃者のヒント」になるのか

攻撃者は、君たちが公開・内部共有しているモデルカードを詳細に分析している。特に「性能の限界」や「想定されるユースケース」の項目は、攻撃者にとっての「攻撃の脆弱性マップ」だ。

例えば、モデルカードに「このモデルは特定の業界用語に強く、推論時に特定のデータフォーマットを優先する」と書けば、攻撃者は「プロンプト・インジェクションでそのフォーマットを強制的に出力させ、後続のプログラムを誤動作させよう」と考える。

防御の鉄則：
モデルカードやシステムカードは、AIモデルの「スペック表」ではなく、「制約条件の宣言書」として書くべきだ。

—

2. 実戦的防衛策：プロンプト・インジェクションを「システム側」で封殺する

モデルカードで「このモデルは悪意ある入力を拒否するように調整済み」と書くだけでは不十分だ。現場では、AIの出力が直接アプリケーションのロジックに影響を与えるポイント（例：SQL生成やファイルパスの決定）で、必ず「ガードレール」を噛ませる必要がある。

以下に、Pythonで実装する、AIの出力をバリデーションするための「セキュア・ラッパー」のサンプルを示す。

import re

def sanitize_ai_output(raw_output):
    """
    AIの出力がSQLやコマンドに直接使われる場合、必ず正規表現で厳格にフィルタリングする。
    「モデルが安全」と信じるのではなく、出力値を「信頼できない外部入力」として扱うこと。
    """
    # 許可する文字パターン（例：英数字とアンダースコアのみに限定）
    # AIが余計なコードやエスケープシーケンスを混ぜるのを防ぐ
    pattern = r"^[a-zA-Z0-9_]+$"
    
    if not re.match(pattern, raw_output):
        # 異常なパターンを検知したらログに記録し、例外を投げる
        raise ValueError("セキュリティアラート: 不正なAI出力パターンを検知しました")
        
    return raw_output

# 実装例: AIが生成したテーブル名をそのまま使わず、検証を通す
ai_generated_table = "users; DROP TABLE users; --" # 攻撃者がAIを操って生成させたクエリ
try:
    safe_table = sanitize_ai_output(ai_generated_table)
except ValueError as e:
    print(f"安全な運用のためブロック: {e}")

—

3. インフラ側でAIの「暴走」を止める

モデルカードに記載した「限界値」をシステム側で強制するために、NginxやクラウドのWAF設定を活用する。AIモデルのAPI呼び出しに対するレート制限（Rate Limiting）は、単なる負荷対策ではない。「プロンプト・インジェクションによるモデルの大量消費（DoS攻撃）」を防ぐためのセキュリティ防壁だ。

以下は、特定のAPIエンドポイントに対して、短時間の過剰なリクエストをブロックするNginx設定例だ。

# Nginx設定ファイルの一部
# AIモデルを呼び出すエンドポイントに対し、IP単位でのレート制限をかける
limit_req_zone $binary_remote_addr zone=ai_limit:10m rate=5r/s;

server {
    location /api/v1/generate-content {
        # 1秒間に5回を超えたリクエストは即座に503を返す
        limit_req zone=ai_limit burst=10 nodelay;
        
        # 内部AI推論サーバーへの転送
        proxy_pass http://internal_ai_model_service;
    }
}

—

4. エンジニアが守るべき「カード」の真髄

モデルカードやシステムカードを策定する際は、次の3点を必ず盛り込んでくれ。

1. 入力のバリデーションルール: AIに入力されるデータには、どのような正規表現や型チェックを施しているか。
2. 出力のデコード処理: AIの出力をプログラムの引数として使う際、どの関数を通してエスケープしているか（htmlspecialchars や escapeshellarg の使用など）。
3. 異常検知時のフォールバック: AIがハルシネーション（嘘）を起こしたり、攻撃的な応答をしたりした場合、どのデフォルト値に切り替えるか。

最後に：セキュリティは「仕様」である

「AIだから予測不能」などという言い訳は、現場では通用しない。モデルカードに書くべきは「このモデルは素晴らしい」という自画自賛ではなく、「どういう入力をすれば、どこで爆発するか」という防衛上の境界線だ。

インシデントは、常に「仕様の隙間」から忍び込んでくる。君たちが作るカードが、チーム全員にとっての「安全な立ち回り方」の指針になるよう、今日からドキュメントの書き方を変えてみてほしい。

もし、実装で迷うことがあればいつでも相談に来い。コードの海で溺れる前に、防壁を固めておこう。