【実践ガイド】LLMセキュリティ対策｜OWASP Top10と具体的な防御策を解説

LLM（大規模言語モデル）の業務活用を検討する中で、

「どのようなセキュリティリスクがあるのか」

「具体的な対策方法がわからない」といった不安を抱えていませんか。LLMは適切に管理しなければ、情報漏洩やシステムの乗っ取りといった重大なインシデントにつながる可能性があります。安全なAI活用を実現するためには、LLM特有の脆弱性を理解し、適切な防御策を講じることが不可欠です。

この記事では、LLMセキュリティの基本的な考え方から、コミュニティが整理したリスク指針である

「OWASP Top 10 for LLM」で指摘されている主要な脆弱性、具体的な攻撃手法、そして企業が実践すべき防御策までを網羅的に解説します。自社のセキュリティ対策に不安がある方や、これからLLM導入を本格化させたいと考えている方は、ぜひ本記事を参考に、安全なAI活用への第一歩を踏み出してください。より具体的な導入支援や人材育成に興味がある方向けの情報もご案内しています。

LLMセキュリティとは？AI活用で考慮すべき新たな脅威

LLMセキュリティとは、大規模言語モデルを組み込んだシステムを、情報漏洩や意図しない動作などから保護する取り組みです。モデルだけでなく、参照データ、連携ツール、利用者の権限、運用環境までを対象に考えます。

LLMを業務で利用する際は、用途と取り扱う情報に応じたセキュリティ対策が必要です。次のセクションでは、従来の対策との関係と、具体的なビジネスへの影響を整理します。

従来のWebアプリケーションセキュリティとの違い

従来のWebアプリケーションでは、認証・認可、入力検証、脆弱性修正、ネットワークやWAFによる防御などを組み合わせます。LLMを使う場合も、これらの対策は引き続き必要です。さらに、自然言語の指示や参照資料がモデルの挙動を変えるリスクを扱います。

LLM特有の攻撃には、プロンプトや外部文書を通じた指示の混入があります。一方で、すべての攻撃が自然言語だけで行われるわけではありません。モデル・学習データ・依存ソフトウェアなどへの改ざんも対象です。モデルの出力を信頼し過ぎず、アプリ側でデータ参照やツール実行の許可を検証します。

LLM特有のリスクがもたらすビジネスへの影響

攻撃により、機密情報や個人情報が漏れる可能性があります。例えば、社内資料を参照するAIが不正な指示に従うと、取得した情報を回答に含めたり、外部送信を試みたりするおそれがあります。実際の被害範囲は、接続先の権限と送信経路に依存します。（出典：Microsoftの間接プロンプトインジェクション対策）

さらに、学習データを汚染される「データポイズニング」によって、LLMが誤った情報や差別的な内容を生成し、企業のブランドイメージを大きく損なうリスクもあります。その他にも、システムの不正利用によるサービス停止や、意図しないAPI連携による過剰な課金など、事業継続に直接的な打撃を与える経済的損失にもつながりかねません。これらのリスクを回避するためには、LLMの特性を理解した上で、適切なセキュリティ対策を講じることが不可欠です。

OWASP Top 10 for LLMの主要なリスクと版の違い

OWASP Top 10 for LLMは、LLMアプリのリスクと対策を整理したコミュニティによるガイドです。法令や認証規格そのものではありません。2026年10月17日時点で公式サイトには2026年版資料が掲載されていますが、一覧・個別解説には2025年版も残っています。以下では番号の混同を避け、2026年版の名称と2025年版の対応を示します。（出典：OWASP 2026年版資料、2025年版一覧）

このリストを理解することは、自社のLLMアプリケーションがどのような危険に晒されているかを把握し、優先順位をつけて対策を講じるための第一歩となります。ここでは特に重要ないくつかの脆弱性について、その内容を詳しく見ていきましょう。

LLM01:2026 プロンプトインジェクション

プロンプトインジェクションは、入力や参照内容によってモデルが開発者の意図しない動作をする問題です。2025年版もLLM01です。モデルへの指示だけで認可を代替せず、データ取得やツール実行をアプリ側で検証します。（出典：OWASPのプロンプトインジェクション解説）

利用者が直接入力する指示に加え、Webページや文書などに埋め込まれた指示を取り込む「間接」攻撃があります。参照内容を信頼できる命令として扱わない設計が必要です。（出典：Microsoftの間接攻撃対策）

LLM05:2026 データとモデルのポイズニング

データやモデルを改ざんし、出力の偏りや不正な挙動を生じさせるリスクです。2026年版はLLM05、2025年版はLLM04「Data and Model Poisoning」に相当します。学習・追加学習に使うデータや配布モデルの由来、変更履歴を確認します。（出典：OWASPのデータ・モデル汚染解説）

外部データを利用する場合は、取得元や更新経路を管理し、改ざんがないかを確認します。ただし、通常の利用で入力した内容が、その場で基盤モデルの学習に使われるとは限りません。学習、検索用データの更新、回答時の参照を分け、製品設定と契約を確認しましょう。

LLM03:2026 過剰な自律性・権限（Excessive Agency）

モデルに過剰な機能・権限・自律性を与えると、誤った出力や攻撃が、削除・送信などの実操作につながります。2025年版ではLLM06です。参照だけの用途に書き込みや削除の権限を与えないことが基本です。（出典：OWASPのExcessive Agency解説）

ツールと操作対象を必要最小限に絞り、利用者自身の権限で認可します。送金・削除・外部送信など影響の大きい処理には、人による承認や実行上限を設けましょう。

LLMを標的とした代表的な攻撃手法と被害シナリオ

LLMを使ったシステムでは、外部文書の指示を誤って採用するなどの攻撃が検証されています。ここでは実在企業の被害事例ではなく、想定される仕組みと攻撃シナリオを説明します。自社で検証する際は、許可を得た隔離環境とテスト用データを使います。

ここでは、実際の攻撃手口や想定される被害シナリオを詳しく解説し、LLMセキュリティの脅威をより身近な問題として捉えていきましょう。

間接プロンプトインジェクションによる情報窃取の手口

間接プロンプトインジェクションは、攻撃者が外部の文書やWebページなどに命令を混入させ、AIの処理を誘導する手口です。例えば、問い合わせ対応AIが外部ページを参照する場面が考えられます。（出典：Microsoftの間接プロンプトインジェクション解説）

外部ページに情報送信を促す指示があっても、必ず実行されるとは限りません。AIが機密情報を取得でき、外部送信や表示経路も利用できる場合に漏洩へつながるおそれがあります。参照元の分離、権限制限、送信先制御を組み合わせ、失敗時にも被害を抑える設計にします。

ジェイルブレイクによる倫理的制約の回避と悪用

ジェイルブレイクは、モデルの安全上の制約を回避して、制限対象の応答を得ようとする試みです。安全対策の内容や有効性は製品・モデルによって異なり、すべてのLLMが同じ制約を備えるわけではありません。

ロールプレイなどで制約の回避を試みる攻撃が知られていますが、特定の前置きで常に成功するものではありません。不適切な回答の生成だけでなく、連携ツールがその回答を実行してしまう経路も含めて検証することが大切です。

企業が取り組むべきLLMセキュリティの防御策

LLMを安全に活用するためには、これまで見てきたような脅威に対抗するための多層的な防御策が不可欠です。単一の対策で万全を期すことは難しく、「入力の検証」「権限の管理」「出力と対話の監視」という3つの軸で、総合的なセキュリティ体制を構築する必要があります。これらの対策は、攻撃の侵入を防ぐだけでなく、万が一侵入された際の被害を最小限に抑えるためにも機能します。

ここでは、企業が具体的に取り組むべき防御策を、それぞれの軸に沿って解説します。自社のセキュリティ対策と照らし合わせながら、どこに弱点があるかを確認してみましょう。

入力の検証と出力のフィルタリング（サニタイズ）

入力の長さや形式を検証し、不審な指示を検知する仕組みを設けます。ただし、禁止語やパターン照合だけでプロンプトインジェクションを防ぎ切ることはできません。外部データの扱いを区別し、認可・操作制限などを別の層で強制します。

出力では、機密情報の検出に加え、表示先に応じたエスケープや形式検証を行います。SQLやコマンドを生成した場合も、検証なしに実行しません。フィルターには見逃しと誤検知があるため、情報の取得範囲や送信先の制御と併用しましょう。

ユーザー権限の厳格な管理と監視

最小権限の原則に基づき、ユーザーとAI連携先の権限を管理します。顧客DBでは必要な項目だけでなく、その利用者に閲覧が許される行・文書の範囲も検証します。検索やツールの呼び出し時点で認可し、不要な書き込み権限を付けません。

万が一、アカウントが乗っ取られたり、プロンプトインジェクション攻撃を受けたりした場合でも、被害の範囲を限定できます。権限設定を定期的に見直し、不要になった権限を速やかに削除する運用も重要です。

LLMとの対話ログのモニタリングと異常検知

ログは目的を決め、利用者・操作・対象・結果など調査に必要な情報を記録します。全対話を無条件に保存すると、ログ自体に機密情報が蓄積します。本文の記録範囲やマスキング、閲覧権限、保存期間、削除方法を定め、異常な利用や実行を監視しましょう。

これらの異常なアクティビティを自動的に検知し、セキュリティ担当者にアラートを通知する仕組みを導入することが望ましいです。記録されたログは、万が一インシデントが発生した際に、原因究明や影響範囲の特定を行うための重要な証拠となります。

LLMセキュリティ対策を強化する実践的アプローチ

基本的な防御策を講じるだけでなく、より能動的かつ体系的なアプローチを取り入れることで、LLMセキュリティのレベルをさらに高めることができます。具体的には、攻撃者の視点でシステムの弱点を探す「AIレッドチーム」、開発の初期段階からセキュリティを組み込む「セキュアAI開発ライフサイクル」、そして信頼できる技術基盤を選定することが重要です。これらの実践的なアプローチは、未知の脅威に対する耐性を高め、持続的に安全なLLM活用環境を維持するために役立ちます。

ここでは、一歩進んだセキュリティ対策を実現するための3つのアプローチと、実際にAIスキルを習得した企業の事例を紹介します。

AIレッドチームによる疑似攻撃テストの実施

AIレッドチームは、許可された範囲で攻撃者の視点からAIの弱点を検証する活動です。実データの漏洩や本番の破壊を避けるため、対象・期間・禁止操作・連絡手順を定めます。プロンプト攻撃だけでなく、権限境界や連携処理も検証しましょう。

テストで見つけた問題は、修正して同じ条件で再検証します。モデルや参照データ、ツールを変更した際にも必要な範囲を確認します。レッドチームの実施だけで、すべての脆弱性を発見したとは判断できません。

AIの開発・運用ライフサイクルにセキュリティを組み込む

NCSCのガイドは、安全な設計・開発・導入・運用と保守の4段階でAIの対策を整理しています。設計段階の脅威分析から、供給網の確認、導入時の保護、運用中の監視・更新までを継続して扱います。（出典：NCSC「Guidelines for secure AI system development」）

早い段階で要件や権限を確認すると、後から設計をやり直すリスクを減らせる可能性があります。ただし、コストや期間の削減を保証するものではありません。対策の担当者、検証条件、更新・廃止時の処理まで決めておきましょう。

信頼できるLLM基盤モデルとAPIの選定

基盤モデルやAPIは、知名度だけで安全と判断せず、データの扱い、制御機能、契約条件を確認して選びます。提供元の対策と、自社アプリの認可・データ管理は別に評価しましょう。

公開モデルを使う場合も、配布元、ライセンス、モデルファイルや依存ソフトウェアの安全性、更新体制を確認します。重みが公開されていても、利用条件が自由なオープンソースとは限りません。APIを選ぶ場合は、次の点を確認しましょう。

• データ保持・再利用ポリシー：入力したデータがどのように扱われるか。
• 第三者評価：SOC 2の保証報告書やISO/IEC 27001認証について、対象サービス・範囲・期間を確認する。SOC 2は認証と同一ではありません。（出典：AICPAのSOC解説）
• APIキー管理機能：不正利用を防ぐための管理機能が充実しているか。
• 監査ログ：利用状況を追跡できるログが提供されるか。

これらの基準を基に、自社のセキュリティポリシーに合致した信頼できる基盤を選びましょう。

AX CAMP受講企業のAI活用事例と適用上の注意

グラシズ社は、2025年公開の取材で、LPライティングの外注費が約10万円から0円、制作時間が3営業日から2時間になったと報告しています。「月額10万円」や、社内人件費を含む総費用0円という意味ではありません。これは業務効率化の個別事例であり、セキュリティ対策の検証結果ではありません。（出典：グラシズ社インタビュー）

Route66株式会社は、2025年8月の取材で、原稿執筆に最大24時間・最短3時間かかっていた業務について、AI出力が10秒になったと報告しています。画像準備・挿入・装飾を含む記事完成までの全作業が10秒という意味ではなく、セキュリティを実証した数値でもありません。（出典：Route66社インタビュー）

C社の2025年8月の取材では、SNS運用の稼働を1日3〜4時間から1時間に減らし、月間1,000万インプレッションを得たと紹介されています。これらは取材時の個別申告で、元ログや安全性を検証した結果ではありません。自社では業務効果とセキュリティの検証を分けて行います。（出典：C社インタビュー）

LLM セキュリティに関するFAQ

ここでは「セキュリティ診断」「社内ガイドライン」「公開モデルと商用APIの選び方」の3点を整理します。取り扱う情報、外部公開の有無、連携操作の影響に応じて、自社に必要な対策を検討しましょう。

LLMのセキュリティ診断はなぜ必要なのですか？

通常のWeb診断に加え、AIの参照データやプロンプト、ツール連携を含めて検証するためです。診断範囲は、扱う情報と操作の影響から決めます。社内で評価できない領域や重要な業務では専門家による診断も検討しますが、すべての用途で第三者診断が一律に必須という意味ではありません。

社内でLLMを利用する際のガイドラインはどのように作成すればよいですか？

社内向けLLM利用ガイドラインを作成する際は、まず利用目的と許容範囲を明確に定義することが重要です。その上で、以下の項目を盛り込むと良いでしょう。

• 入力禁止情報の定義：個人情報、顧客情報、社外秘の技術情報など、入力してはならないデータの具体例を明記する。
• 生成物の取り扱い：LLMが生成した情報の著作権や事実確認の責任の所在を明確にする。
• インシデント報告：不審な挙動や情報漏洩が疑われる場合の報告手順と連絡先を定める。
• ツールの利用範囲：会社が許可したLLMサービスのみを利用するよう徹底する。

これらのルールを全従業員に周知し、定期的な教育を行うことがガイドラインの実効性を高めます。

オープンソースのLLMと商用APIではどちらが安全ですか？

公開モデルと商用APIは、運用体制やデータの扱いが異なり、一律に安全性を順位付けできません。例えばOpenAIは、法人向け製品やAPIの入力・出力を標準では学習に利用しないと説明しています。ただし、学習利用、ログ保存、データ所在地は別の条件であり、対象製品と契約を確認します。（出典：OpenAIの法人データ方針）

自社運用では外部送信を制限する構成を選べますが、モデルを置いただけで閉域化するわけではありません。依存ソフトウェア、更新経路、テレメトリー、外部APIの接続を確認します。運用・脆弱性対応の責任分担も整理して、自社で維持できる方式を選びましょう。

LLM活用の人材育成や業務適用を相談するならAX CAMPへ

技術的な対策と併せて、利用者が入力ルールや確認手順を理解することも必要です。専門知識が不足する場合は、研修で学ぶ範囲と、セキュリティ専門家へ依頼する範囲を整理しておきましょう。

AX CAMPは、法人向けのAI研修・業務活用支援を提供しています。対象業務や担当者の経験に合う内容かを確認し、社内でAIを使うための基礎知識や運用の進め方を相談できます。（出典：AX CAMP公式サービス案内）

セキュリティ診断、レッドチーム、規程の専門監修などが必要な場合は、研修と同じ範囲に含まれると決めつけず、対応可否や担当者、成果物を確認してください。AI活用の研修や伴走支援については、AX CAMPの相談窓口をご利用いただけます。

まとめ：LLMセキュリティを強化し安全なAI活用を実現しよう

LLMは業務効率化に役立つ可能性がある一方、意図しない回答や連携処理によるリスクもあります。情報の参照範囲、実行権限、監視と対応手順を整理し、用途に応じて検証を続けることが大切です。

以下に、本記事の重要なポイントをまとめます。

• LLM特有のリスク：従来のWeb対策に加え、プロンプト攻撃やデータ・モデルの汚染を考慮する。
• OWASP Top 10：コミュニティの指針を活用し、参照する版とリスク番号を揃える。
• 多層的な防御策：入力の検証、権限管理、対話ログの監視を組み合わせた総合的なアプローチが不可欠。
• 実践的アプローチ：AIレッドチームやセキュアな開発ライフサイクルの導入により、さらにセキュリティレベルを高めることができる。

自社の権限設定や運用体制を点検し、対応できない部分は専門家へ相談しましょう。診断を依頼する際は、対象システム、許可するテスト、合格条件、修正後の再検証までを明確にします。

AIの業務活用や人材育成について相談したい場合は、AX CAMPのサービス案内をご覧ください。研修の対象範囲・支援内容を確認した上で、資料請求や個別相談をご活用いただけます。（出典：AX CAMP公式）