LLMセキュリティとは

大規模言語モデル（LLM）セキュリティとは、基盤モデル、その基礎となるトレーニングデータと推論データ、およびそれらを利用するエンタープライズアプリケーションを保護するためのポリシー、制御、テクノロジーを指します。大規模言語モデルセキュリティは、モデルのトレーニングやファインチューニングから、本番環境での入力処理と出力生成まで、ライフサイクル全体を対象とします。

LLMセキュリティの理解

LLMは、構造化されていない自然言語の入力に応答し、同じプロンプトに対しても異なる出力を生成することがあります。この性質は「非決定性」と呼ばれます。こうした非決定性があるため、機密データを扱う組織、規制対象業界で事業を展開する組織、AIを活用した自動化に依存する組織にとって、LLMのセキュリティは極めて重要な課題です。適切な保護対策を講じなければ、LLMアプリケーションによって、データ漏えい、コンプライアンス違反、知的財産の喪失、プロンプトインジェクションなどの新たな攻撃手法に企業がさらされる可能性があります。

企業では、機密性の高い顧客データの直接処理や、社外向けブランドコミュニケーションの文案作成などにLLMをかつてない速さで導入しています。適切な制御がなければ、LLMが言語ベースの攻撃に悪用されたり、機密情報が漏えいしたり、運用上または評判上の損害につながる安全でない出力が生成されたりする可能性があります。企業は、基盤モデルをベースとする統合ツールを、その制御体制を整備するよりも速いペースで本番環境に導入しています。さらに、人間による明示的な指示なしにアクション、ツール呼び出し、コミュニケーションを実行するエージェント型AIの台頭により、従来よりも高い新たなリスク特性が生じています。

LLMセキュリティが重要な理由

LLMは意思決定に影響を与え、タスクを自動化し、ユーザーと直接やり取りするため、セキュリティが極めて重要です。LLMアプリケーションセキュリティでは、モデルを高リスクのコンポーネントとして扱います。モデルを保護するには、一度限りのテストではなく継続的な評価が必要です。利用状況が変化しても、モデルが安全かつ予測可能な形で動作することをチームで確認する必要があります。EU AI法などの新たな規制では、AIシステムに対するリスク管理、ログ記録、人による監督の実施が組織に義務付けられています。そのため、LLMセキュリティは単なる技術上のベストプラクティスではなく、コンプライアンス要件となっています。

LLMセキュリティは、監視、監査、人による監督といった追加のガバナンス対策に加え、主に次の4つの領域にわたります。

トレーニングデータと推論データの保護
モデルの完全性の維持
入力と出力の制御
デプロイ環境とAPIのセキュリティ確保

トレーニングデータと推論データの保護

トレーニングデータのポイズニングとセキュアなパイプライン

LLMは、膨大なデータセットとサードパーティ製コンポーネントから学習します。トレーニングデータやファインチューニングデータが悪意を持って改変されると、モデルが偏った動作、隠れたバックドア、安全でない応答を学習する可能性があります。トレーニングデータとファインチューニングデータは、モデルの動作を直接左右します。十分に検証されていないデータセットや、適切に管理されていないデータセットを使用すると、データポイズニング、バイアス、機密情報の意図しない記憶のリスクが高まります。

ベストプラクティスには、信頼できるリポジトリからのデータ取得、バージョン管理の維持、データリネージの文書化、変更履歴の監査が含まれます。強固なデータガバナンスは、LLMのセキュリティと規制遵守の両方を支えます。大規模言語モデルのセキュリティを確保するには、データソースを検証し、来歴を維持するとともに、モデルの依存関係を継続的に評価する必要があります。

機密情報の開示とデータ漏えい

LLMは、トレーニング中に学習した、またはプロンプトやコンテキストウィンドウを通じて提供された機密情報や専有情報を、意図せず開示する可能性があります。これには、個人を特定できる情報（PII）、認証情報、企業の機密データなどが含まれます。データ漏えいの防止はLLMの安全性における中核的な要素であり、特にコンプライアンス違反が重大な結果を招く規制環境では重要です。

モデルの完全性の維持

サプライチェーンセキュリティ、信頼できるコンポーネント、SBOM

LLMアプリケーションは、サードパーティ製モデル、オープンソースライブラリ、プラグイン、外部APIに依存することが少なくありません。依存関係が増えるたびに、潜在的なサプライチェーンリスクも高まります。侵害されたオープンソースモデルやプラグインも、サプライチェーンリスクをもたらします。使用する外部コンポーネントはすべて、悪意のある攻撃者に侵入経路を与える可能性があります。

ソフトウェア部品表（SBOM）を使用してコンポーネントのインベントリを維持し、定期的なセキュリティレビューと脆弱性の監視を実施することで、侵害された依存関係や古くなった依存関係に起因するリスクを軽減できます。

入出力の制御：直接および間接プロンプトインジェクション

直接プロンプトインジェクション攻撃では、攻撃者が、システム命令を上書きしたり、ユーザープロンプトを通じてモデルの動作を操作したりするよう設計された入力を明示的に作成します。

間接プロンプトインジェクションは、攻撃者が文書やWebページなどの外部コンテンツに悪意のある指示を埋め込むことで発生します。LLMは指示に従うよう設計されており、プロンプトインジェクションは、正規の指示と区別しにくい指示を入力システムに紛れ込ませることで、この特性を直接悪用します。LLMは言語の理解を優先するため、プロンプトインジェクションによってセーフガードが回避され、機密データが漏えいしたり、意図しないアクションが実行されたりする可能性があります。

これを軽減するには、ユーザープロンプト、取得したドキュメント、システムコンテキスト、メタデータなど、LLMへのすべての入力を慎重に制限し、サニタイズする必要があります。入力サーフェスを制御することで、プロンプトインジェクション、間接的なプロンプト攻撃、外部コンテンツに埋め込まれた悪意のある指示にさらされるリスクを低減できます。一般的に推奨される対策には、信頼できるデータソースの許可リストへの登録、非表示または印字不可能な指示の除去、プロンプトの長さと複雑さの制限、ユーザー入力とシステムプロンプトの分離などがあります。

安全でない出力処理と検証

安全でない出力処理とは、アプリケーションがモデルの出力を検証もサニタイズもせずに直接実行または表示することです。モデルが悪意のあるコード、不正なコマンド、誤解を招くコンテンツを生成し、アプリケーションがそれを無条件に実行すると、組織はXSS（クロスサイトスクリプティング）攻撃や未承認のシステムコマンドの実行、ユーザーが誤った情報に基づいて行動するといった事態に直面する可能性があります。

LLMの出力を無条件に信頼してはなりません。生成されたテキスト、コード、クエリ、コマンドは、実行、保存、またはユーザーへの表示の前に検証する必要があります。企業は、出力が安全性とポリシーの要件を満たしていることを確認するため、コンテンツフィルタリング、スキーマ検証、コンテキストに応じたチェックを適用する必要があります。

監督、出力チェック、依存の制限

AIが進歩しても、人間による判断は依然として不可欠です。LLMの出力に過度に依存すると、誤りや捏造、不適切な意思決定が増える可能性があります。企業は、機密性の高いユースケースに対して人間参加型のレビューを徹底し、LLMの適切な利用方法に関するトレーニングを提供するとともに、自動化された意思決定について人間による検証が必要な範囲を明確に定める必要があります。

デプロイ環境とAPIのセキュリティ確保

自律性、過度な依存、最小権限の使用

ワークフローを開始したり、監督なしで意思決定を行ったりする能力など、LLMに過度な自律性を与えると、エラーや悪用のリスクが高まります。人間が介在しないLLMの自律的な動作は、現実世界で意図しない結果を次々と引き起こす可能性があります。エージェント型AIでは、LLMの自律性とLLMへの過度な依存がともに増幅されます。このような場合、攻撃者がLLMをフィッシング、ソーシャルエンジニアリング、悪意のあるコードに悪用し、脅威を増大させる可能性があります。

これを防ぐため、LLMエージェントとプラグインは最小権限の原則に従って動作させる必要があります。モデルがアクセスできるのは、本来の機能を実行するために必要なデータ、ツール、アクションのみに限定します。コードの実行、レコードの変更、トランザクションの開始などの高リスクな操作には、明示的な承認、またはインフラストラクチャで定義および適用される追加の検証を必須とする必要があります。

DoS攻撃、リソース枯渇、モデル窃取

LLMエンドポイントは、多くのリソースを消費する高コストな資産です。攻撃者は、大量のプロンプトを送信してトラフィックを集中させ、コストを増大させることで、これらを悪用できます。また、アクセス制御が脆弱な場合、モデルの窃取や不正な複製を許す可能性があります。体系的かつ堅牢なアクセス制御や制限がなければ、攻撃者はバックエンドに触れることなくモデルにクエリを送信し、その動作を複製できます。Denial-of-Wallet攻撃では、悪意のある攻撃者がトークンを大量に消費するクエリをエンドポイントに集中させ、AIサービスを停止させることなく、組織のクラウドまたはAPI予算を急速に消費させます。

監視、ログ記録、インシデント対応

プロンプト、出力、利用パターン、パフォーマンスを継続的に監視することで、不正利用、異常、新たな脅威を早期に検知できます。ログ記録は、フォレンジック分析とコンプライアンス要件への対応に役立ちます。EU AI Actなどの規制では、特定のAIシステムに対してトレーサビリティとインシデント発生後の分析が義務付けられているため、ログ記録と監視はコンプライアンスとセキュリティの両面で不可欠です。また、組織はLLM関連の事象に特化したインシデント対応手順を策定し、問題発生時に迅速な封じ込めと修復を行えるようにする必要があります。

LLMにおける主なセキュリティリスクと脆弱性リスク

大規模言語モデル（LLM）とそのアプリケーションは、従来のアプリケーションとはリスク特性が大きく異なります。「OWASP Top 10 for LLM Applications」は、プロンプトインジェクション、安全でない出力処理、トレーニングデータのポイズニング、機密情報の漏えい、過剰な権限付与、モデルのサービス拒否など、AI固有のリスクに焦点を当てています。アクセス制御の不備やインジェクションの欠陥といったWebアプリケーションの脆弱性に焦点を当てる従来の「OWASP Top 10」とは異なり、LLM版では、自然言語入力、モデルの動作、外部ツール、AIの自律性によって生じるリスクを扱います。こうした脅威には、プロンプトインジェクション、安全でない出力処理、トレーニングデータのポイズニング、機密情報の漏えい、モデルの過剰な自律性、リソース枯渇によるサービス拒否などがあります。このフレームワークでは、LLMを影響の大きいコンポーネントと位置付け、専用のガバナンス、継続的な監視、最新のアプリケーションおよびAPI標準に準拠した多層的な保護が必要であることを強調しています。

これらのカテゴリーを把握することで、企業は最新のアプリケーションおよびAPIセキュリティの実践に沿って、LLMセキュリティ固有の範囲に対応する、的を絞った緩和策を設計しやすくなります。

LLMセキュリティのベストプラクティス

LLMは自然言語を介してやり取りし、動的な出力を生成するほか、機密性の高いシステムと連携することも多いため、従来のセキュリティ制御だけでは不十分です。

効果的なLLMセキュリティのベストプラクティスでは、技術的な保護策、ガバナンスプロセス、人による監督を組み合わせます。組織は、プロンプトが操作される可能性、出力が悪用される可能性、依存関係が侵害される可能性を前提とする必要があります。

目標はリスクを排除することではなく、安全なイノベーションを大規模に実現しながら、障害が発生する可能性とその影響を低減することです。

企業は、採用するすべてのAIモデルについて、リスクの構成を継続的に可視化する必要があります。そのためには、導入済みのモデルを最新のAI脆弱性ライブラリと継続的に照合し、各モデルが環境にどのような脅威をもたらすかを把握することが重要です。F5のComprehensive AI Security Index（CASI）は、利用可能なAI脆弱性ライブラリの中でも最大規模で、特に定期的に更新されているものの1つです。これにより、組織はモデルレベルのリスクを一貫して最新の状態で把握できます。

F5はLLMセキュリティをどのように実現するのか

LLMを活用したアプリケーションは、独立したシステムとして扱うのではなく、セキュアな開発プラクティスに組み込む必要があります。APIやマイクロサービスと同様に、変更の追跡、監査、ロールバックを可能にするため、モデルのバージョン管理とアクセス制御、テストを行い、ガバナンスの適用された継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインを通じてデプロイする必要があります。F5はLLMワークロードのアプリケーションデリバリとセキュリティ制御を強化し、ハイブリッド環境とマルチクラウド環境全体で一貫した適用を実現します。

The F5 AI Security Platformは、継続的なリスク評価と緩和のサイクルを通じて、お客さまが管理を維持できるようにしながら、AIモデル、アプリ、エージェント、およびそれらを接続するAPIのセキュリティとガバナンスを確保します。AIガバナンスからAIランタイム保護まで、AI Security Platformは、取り込みパイプラインから出力に至るAIオブザーバビリティを、F5 AI Guardrails、F5 AI Red Teamなどを通じて支援します。

F5 BIG-IPとF5 Distributed Cloud Servicesは、トラフィック管理、アクセス制御、検査による組織のLLM API保護を支援します。API検出、認証、レート制限、ボット対策などの機能により、悪用、DoS攻撃、自動化された攻撃からLLMエンドポイントを保護します。これらの対策により、リソースの枯渇を防ぎ、コストの高い推論サービスへの不正アクセスをブロックします。

F5 Distributed Cloud Web App and API Protection (WAAP)は、インジェクション攻撃、悪意のあるプロンプト、通常とは異なるリクエストパターンを検出することで、LLMのセキュリティを強化します。トラフィックを監視して異常なアクティビティを見つけ、プロンプトインジェクション、データ流出、LLMを活用したシステム機能の不正利用を特定します。

F5 BIG-IP SSL Orchestrator は、機密データや外部システムを扱う環境で暗号化トラフィックの復号と検査を可能にし、セキュリティツールによる潜在的な脅威の検出を支援します。この可視性は、パフォーマンスに影響を与えることなく、本番環境でLLMの入力と出力を監視するうえで不可欠です。

Distributed Cloud Servicesは、ハイブリッドおよびマルチクラウド環境全体で、ポリシー管理、オブザーバビリティ、適用を一元化します。セキュリティチームは、LLMトラフィック、異常、メトリクスを一貫して可視化できるため、脅威の検知と対応を迅速化できます。LLMを既存のアーキテクチャに組み込むことで、孤立したAIサイロを防止します。F5は、AIワークロードに多層防御の原則を適用し、変化するビジネスニーズや脅威に適応できる、スケーラブルでレジリエントなAIセキュリティを実現します。

LLMセキュリティ：よくある質問

LLMセキュリティに関連する主なリスクは何ですか？

プロンプトインジェクション、データ漏えい、安全でない出力処理、学習データのポイズニング、過度な自律性は、一般的なリスクです。

企業がLLMのセキュリティを強化するには？

企業は、入力フィルタリング、出力検証、最小権限アクセス、監視などの多層的な制御を適用することで、LLMのセキュリティを強化できます。

OWASP Top 10 for LLM Applicationsは、従来のOWASP Top 10のWebリスクとどのように異なりますか？

従来のOWASP Top 10はWebアプリケーションセキュリティを対象として策定されており、インジェクション、認証の不備、設定ミスなどのリスクを扱います。OWASP Top 10 for LLM Applicationsは、自然言語、非決定性、従来とは異なるWebリスク（プロンプトインジェクション、安全でない出力処理、トレーニングデータのポイズニングなど）に対応しています。

LLMはサイバー防御に活用できますか？

はい。LLMは、脅威分析の自動化、セキュリティログの分析、トリアージと対応の迅速化に広く活用されています。