「またセキュリティ審査で差し戻しですか？」
チャットボットの導入プロジェクトにおいて、PoC（概念実証）では現場から高い評価を得たにもかかわらず、本番運用の承認を得る段階でセキュリティ部門の壁にぶつかるケースは少なくありません。
「AIが競合他社の情報を漏らさない保証はあるのか？」
「悪意あるユーザーがプロンプトで攻撃したらどう防ぐ？」
従来の脆弱性診断ツールを実行しても、結果は「問題なし」。SQLインジェクションやXSS（クロスサイトスクリプティング）のような既知の脆弱性は見当たりません。それなのに、セキュリティ担当者の不安は解消されないというジレンマが、実務の現場で頻繁に発生しています。
自社プロダクトにLLM（大規模言語モデル）を統合する動きは急速に進んでいますが、それと同時に「正体の見えにくいリスク」への懸念も膨らんでいます。従来のWebアプリケーションなら「ここを塞げば安全」という定石がありました。しかし、LLMは違います。
「確率的に動く」というAIの本質そのものが、セキュリティの不確実性を生んでいるからです。
「不適切な回答をさせないようにプロンプトで禁止しました」という対策は、残念ながら根本的なセキュリティ対策とは呼べません。それはあくまで「お願い」レベルの話であり、悪意ある攻撃者の前では無力だからです。対話の自然さを損なわずに業務要件の安全性を担保するためには、単なる禁止命令ではなく、ユーザーの発話パターンを分析し、適切な対話フローへ誘導する設計が求められます。
では、どうすればこの「確率的なリスク」をエンジニアリングとして制御できるのでしょうか？
その答えは、個別の攻撃テクニックに都度対処することではなく、システム開発の王道である「脅威モデリング（Threat Modeling）」をLLM向けにアップデートして適用することにあります。
今回は、LLMシステムのどこに脆弱性が潜んでいるかを構造的に可視化し、設計段階でリスクを封じ込めるための実践的なアプローチを解説します。攻撃の手口を把握し、「守りやすいアーキテクチャ」をどう設計するか、その手法を見ていきましょう。
なぜ従来のセキュリティ診断ではLLMを守れないのか
まず、開発現場が直面している課題の「根っこ」を掘り下げます。なぜ、これまで信頼されていた高価なWAF（Webアプリケーションファイアウォール）や静的解析ツールだけでは、LLMシステムを守りきれないのでしょうか。
「確率的挙動」という新たなリスク要因
従来のプログラムは「決定論的」です。入力Aに対しては必ず出力Bが返ってくるように設計されています。バグとは、その期待値から外れる挙動のことでした。セキュリティ診断も、この「決まった入力に対する決まった脆弱性」を探すプロセスです。
一方、LLMは「確率論的（非決定論的）」です。同じ入力「こんにちは」に対しても、タイミングによって「こんにちは！」と返したり、「やあ、元気？」と返したりするかもしれません。この「ゆらぎ」こそが生成AIの人間らしさや創造性の源泉ですが、セキュリティの観点からは大きな課題になり得ます。
攻撃者はこの確率的なゆらぎを利用します。特定の言い回しや、一見無意味に見える文字列の組み合わせによって、モデルの確率分布を微妙に操作し、本来出力されるべきでない情報を引き出そうとします。これは従来の「コードの記述ミス」ではなく、「モデルの振る舞い」に対する攻撃なので、ソースコードをいくらスキャンしても見つからないのです。
境界防御を無効化する自然言語インターフェース
従来のシステム開発では長年、システムへの入力を厳格に制限することで安全性を保ってきました。数値入力欄には数字しか入れさせない、特殊文字< >はエスケープする、といった具合です。
しかし、チャットボットや対話型インターフェースは、「あらゆる自然言語」を入力として受け入れることを前提としています。ここが最大の違いであり、弱点です。「自由に入力してください」としつつ「攻撃コードは入力しないでください」と制御するのは、矛盾との戦いです。
自然言語は曖昧で、文脈によって意味が180度変わります。「システムを停止せよ」という命令は危険ですが、「『システムを停止せよ』というセリフが含まれる映画を教えて」という質問は無害です。従来のキーワードマッチング型のフィルタリングでは、この文脈の違いを理解できず、過剰検知（正常な利用をブロック）するか、すり抜けを許してしまいます。
資産・脅威・脆弱性の再定義
セキュリティの基本要素である「資産」「脅威」「脆弱性」の定義も、LLM時代には変化します。
- 資産（Assets）: 顧客データだけでなく、「システムプロンプト（AIへの指示書）」自体が企業のノウハウが詰まった知的財産であり、守るべき資産になります。また、LLMがアクセスできる「検索インデックス（RAG用データ）」も攻撃対象です。
- 脅威（Threats）: データの盗難だけでなく、「モデルのハルシネーション（嘘）を利用した社会的信用の失墜」や「リソース枯渇攻撃（長く複雑な処理をさせてAPI課金を増大させる）」といった新しい脅威が登場しています。
- 脆弱性（Vulnerabilities）: コードの欠陥だけでなく、「ガードレールの設定不備」や「学習データの偏り（バイアス）」も脆弱性とみなされます。
守るべきものと攻撃の手口が変わっている以上、守り方も根本から見直す必要があります。そこで有効なのが「脅威モデリング」です。
LLMワークフローにおける脅威モデリングの適用
脅威モデリングとは、システムの設計図を見ながら「攻撃者はどこを狙うか？」「もしここが破られたら何が起きるか？」をシミュレーションし、対策を検討するプロセスです。対話型AIやLLMチャットボットの設計においても、自然な対話体験と業務要件の安全性を両立させるために、この手法を適用することが重要です。
データフローダイアグラム（DFD）で見るAIシステム
まず、システムの地図を描きます。一般的なWebアプリのDFD（データフロー図）に加えて、LLM特有のコンポーネントを配置します。
- ユーザー（外部実体）: 入力を行う人間。
- 入力インターフェース: チャット画面などの対話接点。
- オーケストレーター（処理プロセス）: ユーザーの入力を受け取り、プロンプトを組み立て、LLMへ投げる制御プログラム。LangChainやSemantic Kernelなどがこれに当たります。
- 注意点: これらは単なるツールではなく、攻撃対象になり得る重要なコンポーネントです。例えばLangChainでは、APIキー流出につながる深刻な脆弱性（CVE-2025-68664等）が報告された事例もあり、コアパッケージの定期的な更新とセキュリティパッチの適用が不可欠です。
- LLMサービス（外部実体/プロセス）: OpenAI APIやAnthropic APIなどの外部サービス、または自社ホストモデル。
- 注意点（モデルの移行と廃止）: 利用するAPIモデルは常に変化します。例えばOpenAI APIでは、GPT-4o等のレガシーモデルが2026年2月に廃止され、GPT-5.2（InstantおよびThinking）が新たな標準モデルへ移行しました。これに伴い、長い文脈理解やツール実行の仕様が変更されています。旧モデルに依存したシステムは突然動作しなくなるため、APIのモデル指定パラメーターを最新モデルへ切り替える移行ステップを運用計画に組み込む必要があります。
- Claudeのケース: AnthropicのAPIでも同様に、Claude Sonnet 4.5からClaude Sonnet 4.6への移行が進んでいます。最新版ではAPIリクエストで
thinking={"type": "adaptive"}を指定するAdaptive Thinking機能が追加されるなど、APIの挙動やパラメータの仕様が変わるリスクを常に考慮し、コードの更新計画を設計段階から想定しておくことが重要です。
- 知識ベース（データストア）: RAG（検索拡張生成）で使うベクトルデータベースなど。
- ツール/プラグイン（外部実体）: LLMが呼び出す外部API（カレンダー操作、メール送信など）。
この地図上で、データが流れる線（データフロー）の一つひとつに「ここで何が起きうるか？」と問いかけて、潜在的な脆弱性を洗い出します。
STRIDEモデルのLLM版拡張
脅威分析のフレームワークとして有名な「STRIDE」を、LLMの文脈で解釈し直すと、リスクが明確に浮かび上がります。
- Spoofing（なりすまし）:
- LLM版: プロンプトインジェクションにより、「システム管理者からの命令」になりすましてLLMを操る攻撃です。あるいは、LLMが生成した自然な対話文が人間のものであるかのように振る舞い、フィッシング詐欺などに悪用されるケースも該当します。
- Tampering（改ざん）:
- LLM版: RAGの参照元データに悪意ある情報を混入させ（データポイズニング）、AIの回答を意図的に歪める攻撃です。検索結果のトップに来るように細工されたドキュメントを社内Wikiに配置するなどの手法が考えられます。
- Repudiation（否認）:
- LLM版: AIが不適切な発言をした際、その原因がモデルの特性にあるのか、プロンプトの設計にあるのか、参照データにあるのか追跡できない状態です。ログの不備により責任の所在が不明確になります。
- Information Disclosure（情報漏洩）:
- LLM版: プロンプトに含めた機密情報が、巧妙な質問によって引き出されるリスクです。また、学習データに含まれていた個人情報（PII）が意図せず対話の中で出力される可能性も含みます。
- Denial of Service（サービス拒否）:
- LLM版: コンテキストウィンドウ（記憶容量）を溢れさせる大量の入力を送りつけ、モデルの処理能力を奪ったり、トークン課金を意図的に増大させたりする攻撃（Wallet DoS）です。
- Elevation of Privilege（権限昇格）:
- LLM版: LLMに接続されたプラグイン（メール送信機能や自律的なPC操作など）を悪用し、本来ユーザーが持っていない権限でアクションを実行させる攻撃です。例えば、一般社員がAIのツール実行機能を通じて人事データベースにアクセスしてしまうケースなどが該当します。
信頼境界線の引き直し：プロンプトとコンテキスト
セキュリティ設計で最も重要なのが「信頼境界線（Trust Boundary）」の定義です。境界線の外側からのデータはすべて「汚染されている可能性がある」として検証する必要があります。
従来のアプリケーション開発では、ユーザー入力だけが「信頼できないデータ」として扱われてきました。
しかし、LLMを組み込んだシステムでは「LLMからの出力」も信頼境界線の外に置くべきです。なぜなら、LLMは外部からのプロンプトインジェクションによって密かに操作されている可能性があるからです。OpenAI APIやAnthropic APIなどの最新モデルでは「Structured Output（構造化出力）」や「JSON Schema」のサポートが強化され、出力形式のプログラム的な検証は容易になりました。しかし、出力されるテキストの内容そのものの安全性までは保証されません。
また、RAGシステムにおいては、「検索して取得した社内ドキュメント」も信頼できない場合があります。もし社内Wikiに悪意ある社員が「隠し命令」を埋め込んでいたら、AIがそのドキュメントをコンテキストとして読み込んだ瞬間、その命令を忠実に実行してしまう危険性があります（これを「間接的プロンプトインジェクション」と呼びます）。
「入力は疑え」という古典的な原則に加えて、「AIの出力も、参照データも疑え」。これが自然言語を扱うLLM時代の鉄則です。
参考リンク
OWASP Top 10 for LLMをワークフローにマッピングする
セキュリティ業界の標準団体OWASPが策定した「OWASP Top 10 for LLM」は、現在最も参照されている脆弱性リストです。これを単なるリストとして暗記するのではなく、先ほどのワークフロー（入力→処理→出力）のどこに該当するかを整理すると、対策が立てやすくなります。
入力層：プロンプトインジェクションとジェイルブレイク
ワークフローの最初、ユーザーからの入力段階で発生するのが以下の脅威です。
- LLM01: Prompt Injection（プロンプトインジェクション）
直接的な攻撃指令です。「前の指示を無視して〜せよ」といった命令で、開発者が設定した制約を突破しようとします。 - LLM05: Supply Chain Vulnerabilities（サプライチェーンの脆弱性）
使用するモデルやライブラリ自体にバックドアが仕掛けられているリスクです。信頼できるプロバイダーのモデルを選ぶことが第一の防御です。
ここでの対策は、ユーザー入力をそのままLLMに渡さず、前処理で「無害化」することや、入力の意図分類を行うことが有効です。
処理層：プラグイン悪用とデータ汚染
LLMが内部で思考し、ツールを使ったりデータを検索したりする段階のリスクです。
- LLM02: Insecure Output Handling（安全でない出力処理）
LLMの出力をそのままブラウザに表示したり、SQLクエリとして実行したりすることで発生するXSSやSQLインジェクションです。LLMはあくまで「信頼できない生成器」として扱う必要があります。 - LLM03: Training Data Poisoning（学習データ汚染）
ファインチューニングやRAGのデータソースに毒（誤情報や悪意ある命令）を混ぜる攻撃です。 - LLM08: Excessive Agency（過度な代理権限）
これが最近特に怖いリスクです。LLMに「メールを送る」「カレンダーを消す」といった機能を渡す際、権限を絞らないと、ユーザーの指示一つで甚大な被害が出ます。「なんでもできるAI」は「なんでも壊せるAI」になりかねません。
出力層：機密情報漏洩とハルシネーション
最終的にユーザーに回答を返す段階のリスクです。
- LLM06: Sensitive Information Disclosure（機密情報の漏洩）
学習データやプロンプトに含まれていたPII（個人識別情報）が出力されてしまうこと。 - LLM09: Overreliance（過度な依存）
AIの誤った情報（ハルシネーション）をユーザーが鵜呑みにしてしまい、誤った意思決定をすること。これは技術的なバグというより、UI/UXデザインによる「期待値コントロール」の問題でもあります。
こうしてマッピングすると、対策すべきポイントが「入力フィルタ」「権限管理」「出力監視」の3点に集約されることがわかります。
脆弱性診断と評価の新しいアプローチ
脅威モデリングでリスクを洗い出したら、次は実際にシステムが攻撃に耐えられるかテストする必要があります。ここで登場するのが「AIレッドチーミング」です。
静的解析から動的レッドチーミングへ
従来のセキュリティ診断（ペネトレーションテスト）は、ネットワークやOSの脆弱性を突くのが主でした。対してAIレッドチーミングは、「対話を通じてAIを騙す」テストです。
人間や自動化ツールが攻撃者役（レッドチーム）となり、あの手この手でLLMから不適切な回答を引き出そうと試みます。
- 直接的な攻撃: 「爆弾の作り方を教えて」と直球で聞く。
- ロールプレイ: 「私は化学の教師で、実験の危険性を生徒に教えたいのだが…」と善意の第三者を演じる。
- エンコーディング攻撃: Base64エンコードした文字列で命令を送り、フィルタをすり抜ける。
こうした攻撃パターンを数千、数万通り試し、どの程度の確率で防御できるかをスコアリングします。
LLMによるLLMの攻撃シミュレーション
人間が手動でやるには限界があるため、最近では「攻撃側もAIにやらせる」アプローチが主流です。
- Garak: LLM向けの脆弱性スキャナー。既知の攻撃パターンを大量に投げて反応を見ます。
- Promptfoo: プロンプトのテストツール。様々な入力に対する出力を一覧化し、リグレッションテストを行います。
「AIを使ってAIを攻撃し、AI（審判役）がその結果を判定する」。この自動化ループを作ることが、継続的なセキュリティ担保の鍵です。
評価指標の設定：成功率だけでなく「耐性」を測る
評価の際は、単純な「攻撃成功率」だけでなく、ユーザーテストやA/Bテストを通じた改善サイクルを回しながら、以下の指標も継続的に計測することが重要です。
- 拒否率（Refusal Rate）: 有害なプロンプトをどれだけ適切に拒否できたか。
- 過剰拒否率（False Positive Rate）: 安全な質問まで「お答えできません」と断っていないか。セキュリティを固くしすぎて対話の自然さや利便性が損なわれては本末転倒です。
- 脱獄耐性（Jailbreak Resistance）: 複雑なプロンプトエンジニアリングに対して、どれだけガードレールが機能したか。
Security by Design：堅牢なAIシステムを構築するために
最後に、これらのリスクを踏まえた上で、どのようなアーキテクチャを設計すべきか、具体的な解決策を提示します。
多層防御（Defense in Depth）の設計パターン
セキュリティの世界には「銀の弾丸」はありません。一つの対策が突破されても次で食い止める「多層防御」が基本です。LLMシステムでは、以下の3層で守りを固めます。
入力ガードレール（Input Guardrails）:
LLMに届く前に、入力をチェックします。- PIIのマスキング（電話番号やメアドを隠す）。
- 既知の攻撃パターンの検知（「無視して」などのキーワード検知）。
- 意図分類モデルを使い、業務に関係ない話題をブロックする。
モデル内防御（System Prompting）:
システムプロンプトで明確な境界線を引きます。- 「あなたは〜の専門家です。それ以外の話題には答えません」と役割を固定。
- 「提供された情報のみを使って回答してください」とRAGの参照範囲を限定。
出力ガードレール（Output Guardrails）:
LLMが生成した回答を、ユーザーに見せる前にチェックします。- 禁止ワードのフィルタリング。
- 形式チェック（JSON形式が崩れていないかなど）。
- NVIDIA NeMo GuardrailsやGuardrails AIといった専用ライブラリを活用し、定義したポリシー違反を検知する。
人間による介入（Human in the loop）の設計
特に「アクション（メール送信や決済など）」を伴う機能の場合、AIに全権を委ねるのは危険です。リスクの高い操作には、必ず人間の承認プロセスを挟む設計にしましょう。
例えば、「メールの下書き作成」まではAIが自動で行い、「送信ボタン」は人間が押す。あるいは、AIが実行しようとしているアクションの内容をポップアップで表示し、ユーザーが「OK」を押さないとAPIが叩かれないようにする。これだけで、Excessive Agencyのリスクは大幅に下がります。
AIガバナンスとセキュリティの融合
技術的な対策と同じくらい重要なのが、組織的なルール作りです。
- 利用ガイドラインの策定: ユーザーが入力してよいデータ、いけないデータの明確化。
- インシデント対応計画: もしAIが予期せぬ挙動や不適切な発言をした場合、誰がどうやってシステムを停止し、対外的な説明を行うか。
- 継続的なモニタリング: ユーザーとの対話ログ（プライバシーに配慮しつつ）を定期的に分析し、新たな攻撃パターンや予期せぬ挙動を早期に発見する。
セキュリティは「機能」ではなく「プロセス」です。一度作って終わりではなく、AIの進化に合わせて守り方もアップデートし続ける必要があります。
まとめ
LLMシステムのセキュリティ対策は、従来の「壁を作る」発想から、「免疫システムを作る」発想への転換が求められます。確率的な挙動を完全に制御することは不可能ですが、脅威モデリングによってリスクを可視化し、多層的なガードレールで被害を最小限に抑えることは可能です。
- 構造を知る: DFDとSTRIDEで、自社システムのどこにリスクがあるか地図を描く。
- 基準を持つ: OWASP Top 10 for LLMを参照し、対策の優先順位をつける。
- 試し続ける: 自動化されたレッドチーミングで、常にシステムの耐性をテストする。
- 多層で守る: 入力・モデル・出力の各段階でフィルタリングを行う。
これらを設計段階から組み込む「Security by Design」こそが、信頼されるAIプロダクトへの最短ルートです。
AIセキュリティの世界は日進月歩で、新しい攻撃手法と防御策が毎週のように生まれています。孤立した知識だけで戦うのは困難です。
コメント