【実務・中級編】 AIガバナンスにおける責任分界点の明確化 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

おい、そこの手を止めてこっちを向いてくれ。

いま、君たちが手塩にかけて開発しているその生成AI機能、本当に「安全」だと言い切れるか？ 「いや、うちはAWS（あるいはAzureやGCP）を使っているからインフラはプロバイダー任せだし、基盤モデルはOpenAIやAnthropicのAPIを叩いているだけだから、セキュリティは向こうが担保してくれているはずだ」――そんな甘い考えを持っているなら、今すぐその幻想を捨ててほしい。

数々のインシデント現場を踏んできた私から言わせれば、「誰かが守ってくれているはずの領域」こそが、サイバー攻撃者にとって最も狙い目となる最悪の死角（ブラインドスポット）なのだ。

今日は、クラウドプロバイダー、モデル開発者、そして我々アプリケーション開発者の間における「責任分界点」の曖昧さを突いた攻撃の現実と、それをガチガチに固めるためのRACIチャートの実務的適用、そしてそのまま現場で使えるセキュアな実装コードについて話をしよう。

—

1. 責任分界点を誤るエンジニアが踏む「地雷」

生成AI（LLM）をシステムに組み込む際、セキュリティの責任は以下のように多層構造に分かれている。

1. 基盤モデルレイヤー（OpenAI, Anthropic, Google等）: モデル自体の安全性、学習データのクレンジング、ハルシネーションの抑制。
2. インフラストラクチャレイヤー（AWS, GCP等）: API基盤の可用性、ストレージの暗号化、ネットワークの分離。
3. アプリケーションレイヤー（君たち開発チーム）: プロンプトインジェクション対策、コンテキスト汚染の防止、機密情報のマスキング、出力結果のサニタイジング。

ここで多くの開発者が犯す最大の勘違いが、「モデル開発者がガードレール（安全機能）を用意してくれているから、アプリ側でのバリデーションは適当でも弾いてくれるだろう」という甘えだ。

プロンプトインジェクションやジェイルブレイク（脱獄）の攻撃者は、モデルが持つ「安全フィルター」の隙間を縫うために、エンコーディング（Base64や16進数）を悪用したり、システムプロンプトのコンテキストを巧妙に書き換えたりする入力を送り込んでくる。
もし君たちが「APIから返ってきたレスポンスをそのまま画面にレンダリングする」ような実装をしていれば、AIの出力経由でStored XSS（クロスサイトスクリプティング）や、最悪の場合、バックエンドでのRCE（リモートコード実行）に直結する。

「AIの出力はコードとして実行されないから安全」？ いやいや、AIが生成したSQLクエリやシェルコマンドを、そのまま eval() やデータベースへの直接クエリとして流し込んでいる現場を、私は何度も目撃している。それはもう、自ら手動でバックドアを開けているようなものだ。

—

2. RACIチャートで明確化する「誰が何を守るのか」

曖昧な責任分界を排除するため、まずはインシデントが起きた際に「誰の首が飛ぶのか」を定義するRACIチャート（Responsible: 実行責任, Accountable: 説明責任, Consulted: 相談先, Informed: 報告先）をプロジェクトの共通認識として持とう。

| セキュリティタスク / リスク項目 | モデル開発者 | クラウドプロバイダー | アプリケーション開発者 (君たち) | セキュリティチーム |
| :— | :—: | :—: | :—: | :—: |
| 基盤モデルの脆弱性パッチ・アップデート | R / A | C | I | I |
| API通信の暗号化・DDoS対策 | C | R / A | C | I |
| プロンプトインジェクション対策（入力値検証） | I | I | R / A | C |
| LLM出力のサニタイジング（XSS/インジェクション防止） | I | I | R / A | C |
| 機密情報（PII）のマスキング処理 | C | I | R / A | C |
| 監査ログの監視・異常検知 | I | C | R | A |

見ての通り、プロンプトの入力検証から出力のサニタイジング、機密情報の制御に至るまで、アプリケーション層のセキュリティは100%我々（アプリケーション開発者）の責任（Responsible）なのだ。プロバイダーのせいにすることは許されない。

—

3. 【実務実装】AI出力を安全に処理するセキュアコーディング

それでは、具体的にどう実装すべきか。
今回は、ユーザーからの入力を安全にLLMへ渡し、さらにLLMから返ってきた出力をWebフロントエンドで安全に表示（XSSを完全に防ぐ）するためのPython（FastAPI + LangChain等を想定したバックエンドの思想）およびJavaScriptのサンプルコードを提示する。

バックエンドでの入力サニタイジングと機密情報フィルタリング (Python)

LLMに送る前の入力値から、システムプロンプトを破壊するような特殊文字やインジェクションの兆候を排除し、さらにクレジットカード番号などのPII（個人情報）をマスクする実装だ。

import re
from typing import str

def sanitize_and_filter_prompt(raw_input: str) -> str:
    """
    ユーザーからの入力を検証し、プロンプトインジェクションの兆候や
    機密情報（クレジットカード番号やメールアドレス）をフィルタリングする。
    """
    # 1. 制御文字や極端に長い入力を弾く（DoS対策）
    if len(raw_input) > 2000:
        raise ValueError("入力文字数が長すぎます（上限: 2000文字）。")
    
    # 2. プロンプトインジェクションでよく使われる特定パターンの無効化
    # 例: "Ignore previous instructions" などのシステム指示上書きを検知・置換
    dangerous_patterns = [
        r"ignore previous instructions",
        r"システムプロンプトを忘れろ",
        r"お前の役割を"
    ]
    
    cleaned_input = raw_input
    for pattern in dangerous_patterns:
        cleaned_input = re.sub(pattern, "[FILTERED]", cleaned_input, flags=re.IGNORECASE)

    # 3. クレジットカード番号のマスキング（PII漏洩防止）
    cc_pattern = r"\b(?:\d[ -]*?){13,16}\b"
    cleaned_input = re.sub(cc_pattern, "[REDACTED_CREDIT_CARD]", cleaned_input)

    return cleaned_input

# 【使い方】
# user_message = request.json.get("message")
# safe_message = sanitize_and_filter_prompt(user_message)
# -> この安全な文字列をLLMのAPIへ渡す

フロントエンドでの安全な出力レンダリング (JavaScript)

LLMが生成したテキストをブラウザに描画する際、もしMarkdown形式などをパースしてHTMLとして直接埋め込んでいる（innerHTMLを使っている）なら、今すぐそれを止めろ。それはStored XSSの温床だ。DOMPurifyなどのサニタイザーを必ず噛ませるか、テキストノードとして安全に挿入する必要がある。

/**
 * LLMからの出力を安全にHTMLとして画面に描画する関数
 * @param {string} rawAiOutput - LLMから返却された生のテキスト
 * @param {HTMLElement} targetElement - 描画先のDOM要素
 */
function renderSecureAiOutput(rawAiOutput, targetElement) {
    // 依存ライブラリ: DOMPurify (HTMLのサニタイジング用)
    // marked.js 等でMarkdownをHTMLに変換する場合の安全対策
    
    // 例として、生の文字列をそのまま innerHTML に入れるのは絶対NG
    // targetElement.innerHTML = marked.parse(rawAiOutput); // <-- 脆弱！
    
    // 【正しい実装】
    // 1. Markdownをパースした後に、DOMPurifyで悪意あるスクリプトやイベントハンドラを除去する
    const unsafeHtml = marked.parse(rawAiOutput);
    
    // DOMPurifyがグローバルに読み込まれている前提
    const cleanHtml = DOMPurify.sanitize(unsafeHtml, {
        ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li', 'code', 'pre'],
        ALLOWED_ATTR: ['href', 'target']
    });

    // 2. サニタイズ済みのHTMLのみをDOMに反映
    targetElement.innerHTML = cleanHtml;
}

—

4. チーフエンジニアからの最後の忠告

生成AIという「ブラックボックス」をシステムに組み込むとき、私たちは得てして思考停止に陥りがちだ。「AIが賢いから勝手にやってくれる」「クラウドが守ってくれる」。そんな他力本願な設計は、必ずセキュリティ監査やインシデントの現場で鋭い牙を向いて跳ね返ってくる。

もう一度言う。インフラの安全はクラウドプロバイダーの仕事だが、その上で動くアプリケーションの境界線を守るのは、画面の前に座っている君たちの仕事だ。

RACIチャートで自分の役割を正確に認識し、入力のバリデーションと出力のサニタイジングという「基本中の基本」を泥臭く徹底すること。それこそが、真の意味でセキュアなAIシステムを構築する唯一にして最大の近道なのだ。

さあ、エディターに戻って、自分のコードの入力値検証を見直すとしようか。

スポンサーリンク

コメント

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