LLMセキュリティとは？OWASP Top 10の安全性リスクを軽減する方法

攻撃者の指示をAIにコマンドとして扱わせる攻撃、すなわちプロンプトインジェクションは、2023年以降のすべての版で「OWASP Top 10 for LLM Applications」の第1位に挙げられています。

このリストは、AIセキュリティの分野でコンセンサスと呼べるものに最も近い存在です。このプロジェクトは少人数のセキュリティ専門家グループから始まり、現在では18か国以上の600人を超える専門家が貢献しています。

AI企業である私たちが、AIがいかにして言いくるめられてしまうかについてのガイドを公開するのですから、この問題が解決済みであるかのように装うつもりはありません。OWASPプロジェクトの共同リーダーであるWilson氏は、現在の防御策についてはっきりとこう述べています。「……率直に言って、私たちはまだ99%には達していないと思います」

2026年版も同じ論調で始まります。プロジェクトリーダーは、「だまされないモデルを作ろうとするのはやめる」こと、そして、たとえモデルがだまされても重要なものが壊れないよう周囲のシステムを設計することを私たちに求めています。

本記事では、その立場に立って、OWASPの2026年版リストにある10のリスクすべてを見ていきます。

LLMセキュリティとは？

LLMセキュリティとは、AIモデルとそれを利用するアプリケーションを攻撃や悪用から守ることです。リスクは、モデルが何につながっているかに応じて大きくなります。具体的には、モデルが読み取れるファイルやデータ、そしてメール、検索、社内データベースなど、モデルが使えるツールです。

適切に保護されたソフトウェアでは、プログラムが従う指示と、プログラムが処理する情報との間に明確な境界線があります。しかし、LLMにはその境界線がありません。

モデルが読み取るものはすべて、1つの長いテキストの流れとして届きます。開発者の指示も、あなたの質問も、モデルが調べたWebページもです。AIモデルは本来、発言しているのが開発者なのか、ユーザーなのか、あるいは問題について考えを巡らせているモデル自身なのかを把握できることになっています。

しかし、研究者のJasmine Cui氏とCharles Ye氏は、モデルが誰の発言かを主にテキストの語り口から推測していることを明らかにしました。そのため、攻撃者がモデル自身の推論のように聞こえる文章を書くと、モデルはそれを自分で思いついたアイデアだと信じてしまう可能性があります。これは、誰が主導権を握っているかをモデルが把握していることを前提とするあらゆる安全対策にとって問題です。

私たちも自社のAIエージェントで同じ問題に直面してきました。当社のCISOであるKyle PolleyはISMGに対し、エージェントは「システムプロンプトにポリシーを追加しても、それに従わない可能性がある」と語っています。そこで私たちは、エージェントがこれから実行しようとしていることをチェックし、その操作が設定されたセキュリティルールに違反する場合にはブロックできるオープンソースツール、Numbatを開発しました。

LLMセキュリティとは、モデルがときに間違った相手の命令に従ってしまうことを受け入れたうえで、そうなっても機能し続けるAIガードレールをその周囲に設けることです。

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

ここからは、「OWASP Top 10 for LLM Applications 2026」を第1位から第10位まで順に見ていきます。

各リスクについて、どのように問題が起きるのかをわかりやすく説明し、実際の事例を紹介します。そのうえで、リスクを防ぐ、あるいは少なくとも被害を抑えるのに役立つ対策を取り上げます。

1. プロンプトインジェクションを封じ込める

プロンプトインジェクションは、攻撃者がAIに本来従うべきではない指示を実行させることで起こります。こうした指示は、チャットで直接与えられることもあれば、メール、Webページ、ドキュメントに仕込まれていることもあります。

後者は間接プロンプトインジェクションと呼ばれます。たとえば、あなたがアシスタントにドキュメントの要約を頼んだとします。ところが、そのドキュメントの作成者は、あなたの非公開ファイルを自分に送るようアシスタントに指示していました。アシスタントがその指示に従えば、ドキュメントの作成者は事実上あなたのアクセス権を借りたことになります。

PCMagは、プロンプトのセキュリティを、多孔質の石の穴をふさぐ作業になぞらえています。1つの穴をふさいでも、水は別の穴を見つけてしまいます。「攻撃は抜け道を見つけ出します。それが修正されても、LLMのような動的なシステムの性質上、まだ発見されていない攻撃経路が数え切れないほど残っているのです」

事例：2025年6月、Aim Securityの研究者がEchoLeakを発見しました。これは、Microsoft 365 Copilotをだまして企業の非公開情報を漏えいさせる脆弱性です。従業員が日常的な業務上の質問をすると、Copilotが攻撃者の送ったメールを取り込み、その中に隠された指示に従って、機密情報を攻撃者に送信してしまう可能性がありました。この攻撃は、悪意のある指示を検出し、不審なリンクを除去するためのチェックをすり抜けました。

できること：

• Metaの「Rule of Two（2の法則）」に従う：EchoLeakが成立するには、企業データを読み取り、外部のメールを読み取り、情報を外部に送信できるAIが必要でした。そして、そのAIは3つすべてを備えていました。これらの機能のうち2つまでに制限すれば、プロンプトインジェクションに過大な支配力を握られるのを防げます。タスクに3つすべてが必要な場合は、操作のたびに人間による承認を必須にしましょう。
• 防御策を把握している攻撃者を想定してテストする：導入したルールやフィルターをセキュリティテスターに伝えたうえで、それらを回避させてみましょう。ある研究では、防御策に適応した攻撃者が、テストされた12の防御策の大半に対して90%以上の確率で攻撃に成功しました。

2. 機密情報の漏えいを防ぐ

AIシステムが、本来見るべきではない人に非公開情報を渡してしまうことを、機密情報の漏えいと呼びます。たとえば、顧客の支払い情報を明かしてしまったり、非公開の会話を共有データベース上に放置したりすることが該当します。

漏えいの多くは「過剰共有」から始まります。たとえば、ある企業がアクセス権限の緩いドライブやナレッジベースにAIを接続したとします。AIは設計どおり、アクセスできるものは何でも取得します。誰かが侵入する必要はありませんが、LLMは侵入されたも同然だと考えるべきです。

事例：2025年1月、Wizの研究者が、インターネット上に公開されたままのDeepSeekのデータベースを発見しました。そこには100万件を超えるログエントリが含まれており、チャット履歴や、ソフトウェアが他のサービスにアクセスする際に使うAPIキーもありました。研究者たちは、モデルを説得して何かを明かさせる必要すらありませんでした。

できること：

• AIがデータを読み取る前にアクセス権を確認する：アプリケーションは、ドキュメントをモデルに渡す前に、質問している人がどのドキュメントを閲覧できるかを確認する必要があります。
• AIが残す記録を保護する：アクティビティログを保存する前に個人情報やシークレットキーを削除し、ログインを必須にして、アクセスを必要な人に限定しましょう。保持期間を設定し、記録が際限なく蓄積されないようにします。

3. 過剰なエージェンシーを抑制する

過剰なエージェンシーを持つAIは、仕事に必要な範囲を超える力を持っています。つまり、不要なツール、タスクの範囲を超えるアクセス許可、確認なしで行動できる自由です。ここでは、原因は問題ではありません。

インジェクションされたプロンプトでも、バグでも、単にモデルが間違えただけでも、結果は同じです。AIにその能力があれば、いずれ破壊的なことをしてしまいます。

事例：2025年7月、SaaStrの創業者Jason Lemkin氏は、変更を加えないよう指示していたにもかかわらず、Replitのコーディングエージェントが1,206件の経営幹部の記録を含む彼のデータベースを削除したと報告しました。エージェントは当初、データは復元できないと答えましたが、後に復旧が可能であることが判明しました。Lemkin氏は、データベースに手を触れないよう指示しても、それを削除する能力自体はなくならないことに気づいたのです。

拡大

出典：X

できること：

• タスクに不要な機能を取り除く：エージェントに与えるツールと、そのツールでできることの両方を制限しましょう。メールを要約するアシスタントに必要なのはメールを読む権限であり、送信や削除の権限ではありません。
• 権限チェックをAIの外部に置く：操作が要求されるたびにセキュリティルールに照らして確認し、人間による承認を必須にしましょう。

4. AIサプライチェーンに入り込むものを確認する

AIを一から作る企業は少なく、その数は年々減っています。Menlo Venturesの調査「2025 The State of Generative AI in the Enterprise」によると、AIモデルを購入した企業の割合は2024年の53%から2025年には76%に増加しました。

多くの場合、企業はHugging Faceのようなハブからモデルをダウンロードし、他者が収集したデータセットでさらにトレーニングし、見知らぬ人が書いたアドオンやコードパッケージを組み込んでいます。

そのひとつひとつが侵入口になります。どれか1つでも改ざんされれば、その問題は製品に組み込まれたまま出荷されてしまいます。

事例：Hugging Faceの公開モデルリポジトリの数は、2026年1月から2026年8月の間に243万から296万に増加しました。しかし2026年7月、社内のセキュリティテスト中に、OpenAIのモデルがインターネットへのアクセスを防ぐための制御を回避し、Hugging Faceのシステムの一部に侵入しました。実際、あるエージェントは公開状態になっていた14件のアクセス認証情報を入手し、それらが有効であることを確認したうえで、他のエージェントと共有していました。エージェントたちはさらに脆弱性を悪用し、Hugging Faceのサーバー上でコードを実行できるようになりました。

「当社は、モデルのライフサイクル全体を通じてアライメントに関する要件を厳格化するとともに、より隔離されたサンドボックスの構築、インターネットアクセスの制限、モデルの重みへのアクセス管理の強化を進めています」とOpenAIのレポートは述べています。

できること：

• モデルを特定のバージョンに固定して検証する：各モデルをレビュー済みのバージョンに固定し、読み込む前にファイルのフィンガープリントを確認しましょう。そうすれば、同じラベルのまま差し替えられたファイルが紛れ込むのを防げます。OWASPはデジタル署名も推奨していますが、注意点もあります。署名が証明するのはモデルの出どころであって、安全性ではありません。
• AIが提案するパッケージはすべて確認する：AIアシスタントが推奨したコードパッケージをインストールする前に、そのパッケージが実在するか、意図したパッケージか、想定している発行元から提供されているかを確認しましょう。

5. データとモデルのポイズニングを防ぐ

ポイズニングされたAIは、汚染されたデータから学習します。そのデータは、ファインチューニングに使われたサンプルかもしれませんし、回答を探すために検索するナレッジベースかもしれません。モデルは一見正常に動作しているように見えますが、誤ったことを学習しており、特定のトリガーフレーズを見たときだけ不正な動作をするように学習している場合もあります。

誰かがそのフレーズを使うまでは、どんなテストを行っても問題は見つかりません。

拡大

また、ポイズニングは元に戻すのが非常に困難です。パッチを当てれば直るバグとは違います。データが誤っている場合は、データを再確認したり、モデルを再トレーニングしたり、モデルを丸ごと置き換えたりする必要があるかもしれません。

事例：2025年10月、Anthropic、英国AI Security Institute、Alan Turing Instituteの研究者は、特定のトリガーに遭遇するたびに意味不明な文字列を出力するよう、250件のポイズニングされたドキュメントでモデルに学習させられることを示しました。テストした4つのモデルサイズすべてで同じ件数が有効でした。最大のモデルは20倍以上のクリーンなデータでトレーニングされていたにもかかわらずです。

できること：

• データの出どころを追跡する：使用するすべてのデータセットとモデルについて、それぞれの入手元と、バージョン間の変更内容を記録しておきましょう。データセットのバージョン管理をおすすめします。そうすれば、ポイズニングが見つかった場合にクリーンなバージョンにロールバックし、どのように混入したかを突き止めることができます。
• バックドアがないかテストする：「バックドア」とは、攻撃者がモデルに仕込む隠れた動作のことで、特定のフレーズなどのトリガーによって起動するのを待っています。モデルに通常のルールを破らせるように設計された入力を使って、バックドアの有無をテストしましょう。

6. 無制限の消費に上限を設ける

AIが実行できる作業量やかかるコストに何の制限もない場合、その消費は「無制限」とみなされます。AIサービスの大半は従量課金制のため、攻撃者によって請求額をつり上げられたり、モデルのコピーを作られたりするおそれがあります。

OWASPは、この中核的な問題を「コストの非対称性」と呼んでいます。短く安価なリクエストが、あなたの側で高額な計算処理を引き起こすことがあるのです。

事例：2024年5月、SysdigのThreat Research Teamは「LLMjacking」と呼ばれる新たな攻撃を発見しました。ある攻撃者グループが、盗んだ認証情報を使って、クラウドでホストされている10のLLMサービスを標的にしたのです。攻撃者は脆弱なバージョンのLaravelを足がかりに侵入し、その後、認証情報で何ができるのか、どのようなクォータがあるのかを調べました。明らかにアクセス権の販売が目的でした。また、多くのログ設定も照会されており、おそらく検知を回避するためだったと考えられます。Sysdigによると、最悪の場合、被害者のコストは1日あたり46,000ドルを超える可能性があります。

できること：

• 支出を止める予算を設定する：個々のユーザー、APIキー、チーム、そしてアカウント全体に対して、支出の上限を厳格に設定しましょう。リクエストが入ってくる可能性のあるすべての場所で、その上限を適用します。
• すべてのタスクに停止点を設ける：タスクを実行できる時間、処理・生成できるテキストの量、ツールを呼び出せる回数を制限しましょう。同じ処理を繰り返すエージェントや、割り当てを超えたエージェントを自動的に停止させる仕組みを追加します。

7. 行動に移す前に誤情報を見抜く

AIがもっともらしく聞こえる誤った内容を生成し、人や何らかのシステムがそれに基づいて行動してしまうことを、誤情報と呼びます。中核的なリスクは、誤った回答そのものよりも、その誤った回答が信頼され、利用されてしまうことにあります。

インシデントの記録を見ると、実務者は誤情報を本来あるべきほど懸念していなかったことがうかがえます。2026年版の冒頭の書簡によると、投票では誤情報は下位に位置づけられましたが、実際のインシデントに基づけば上位に入ります。

事例：2025年、Deloitte Australiaは、44万豪ドルの政府契約に基づき、福祉関連ITシステムのレビューを納品しました。シドニー大学の研究者Chris Rudge氏が存在しない研究への参照を発見し、さらに連邦裁判所の判決からの捏造された引用も見つけました。修正版の報告書では、Deloitteが手法の一部にAzure OpenAI GPT-4oを使用していたことが開示され、同社は最終分割払い分を返金することに同意しました。残念なことに、これは保証（アシュアランス）レビューでした。

できること：

• エビデンスが回答を裏付けているか確認する：主張の根拠を、最新かつ信頼できる情報源に置きましょう。ポリシーに関する回答であれば、承認済みのポリシーを取得し、例外規定も含めて、それが結論を裏付けているか確認します。
• システムが行動する前に検証する：エージェントが「顧客が本人確認に合格した」と報告した場合は、支払いを実行する前に、その結果を本人確認システムと照合しましょう。重大な判断には人間による承認を必須とし、裏付けとなるエビデンスをレビュー担当者が確認できるようにします。

8. 隠れたコンテキストの露出による被害を抑える

AIアプリケーションは、ユーザーには通常見えない指示や背景情報をモデルに与えています。これには、システムプロンプト、社内ポリシー、利用可能なツールの説明、そしてそれらを誰が使えるかに関するルールなどが含まれます。隠れたコンテキストの露出とは、モデルがそうした情報を誰かに明かしてしまうことです。

OWASPは2026年、この項目を「システムプロンプトの漏えい」から拡張しました。漏れる可能性があるのはシステムプロンプトだけではないからです。危険度は、そこに何を置いたかによって決まります。文体ガイドが漏れても少し恥ずかしい程度で済みますが、APIキーが漏れれば、誰かに機密データベースへのアクセスを許すことになります。

事例：2023年2月、ユーザーたちはMicrosoftのBing Chatに内部の指示を明かさせることに成功しました。成功例の1つはMarvin von Hagen氏によるもので、同氏はOpenAIの開発者を名乗り、モデルを設定するためだとして指示を求めました。Bingは、検索、応答、安全性に関する動作を規定するルールと、内部名「Sydney」を開示しました。明かされた指示の中には、それらの指示を機密として扱うよう命じるものも含まれていました。

できること：

• シークレットをモデルのコンテキストに含めない：モデルが読み取れるものはすべてユーザーに見えてしまう可能性があると想定し、パスワード、APIキー、アクセストークンは別のシークレット管理システムに保存しましょう。
• ルールが漏洩しても権限が機能するようにする：アクセスチェックはアプリケーションコードで実施しましょう。ツールの利用が管理者に限定されている場合は、実行前にユーザーのアカウント権限を確認します。

9. ベクトルと埋め込みを保護する

AIがベクトル検索を使って社内文書から答えを探すとき、テキストを直接検索しているわけではありません。文書は「埋め込み（エンベディング）」に変換され、ベクトルデータベースに保存されます。埋め込みとは、各文章の意味を捉えた長い数値のリストです。質問も同じ方法で変換され、システムは数値が最も近い文章を取り出します。

OWASPは、この仕組みが破綻する4つのパターンをまとめています。ポイズニングはシステムに誤った結果を出させ、インバージョン（逆変換）は情報を漏洩させ、ジャミングは応答を止め、不適切なアクセス制御は誰にでも何でも渡してしまいます。

これらの数値は、見た目ほど安全な抽象化ではありません。保存された埋め込みはテキストに復元でき、ある手法はテストで32トークンの短い文章の92%を完全に復元しました。そのため、「埋め込みだけ」のバックアップが漏洩した場合でも、文書の内容が露出するおそれがあります。

例：USENIX Security 2025で発表された研究で、研究者たちは、巧妙に作成された1つの文書によって、AIが特定の質問に答えられなくなることを示しました。研究者たちはその文書を、AIが検索するコレクションに追加しました。AIがその文書を見つけると、情報が不十分だと答えたり、回答するのは安全でないと答えたりすることがありました。文書の中でAIにルールを無視するよう指示する必要さえありませんでした。これは「検索ジャミング（retrieval jamming）」と呼ばれます。

できること：

• 公開データと非公開データでインデックスを分ける：スクレイピングしたWebコンテンツを、パートナーのデータや社外秘の内部文書と混在させないでください。1つのインデックス内でコンテンツにタグを付けて区別するのではなく、信頼レベルごとに物理的に分離しましょう。そうすれば、ある種の設定ミスをまるごと防げるうえ、インターネットからスクレイピングしたコンテンツが取締役会資料の隣に紛れ込むこともなくなります。
• 埋め込みを元の文書と同じように扱う：埋め込みを暗号化し、ソースファイルだけでなくベクトルデータベースのバックアップも保護し、元の文書を削除したら埋め込みも削除しましょう。埋め込みサービスのAPIキーも秘密にしておく必要があります。

10. AIの出力は次に渡す前にチェックする

アプリケーションがAIの出力を、渡す先のシステムで安全に使えるかどうかを検証せずに渡している場合、それはLLM出力の不適切な処理にあたります。

この項目は、AIコーディングアシスタントが大量に生成する安全でないコードも対象にしています。つまり、アシスタントが書くコードの1行1行もまた出力なのです。

例：2025年に研究者のJohann Rehberger氏が示したところによると、SourcegraphのコーディングアシスタントAmpは、画像を表示するだけでチャットの内容を漏洩させる可能性がありました。同氏はプロンプトインジェクションを使って、Ampに非公開の情報を画像のWebアドレスに含めさせました。するとアプリケーションがその画像を自動的に取得し、情報が同氏のサーバーに送信されました。出力処理の欠陥は、この自動リクエストにありました。モデルが生成したテキストが外部サーバーへの接続となり、非公開データを運び出してしまったのです。

できること：

• 出力を渡し先に合わせて安全にする：応答は、どこに渡されるかに応じてチェックし、処理しましょう。Webページであれば、生成されたテキストが実行可能なコードにならないようにします。データベースであれば、渡された値をコマンドから切り離すプリペアドステートメントを使用します。
• 回答が外部へ自動的に接続しないようにする：モデルの応答に含まれる画像、リンクプレビュー、埋め込みページの自動読み込みは、デフォルトで無効にしましょう。必要な接続は、明示的に承認された接続先に限定します。

PerplexityはどのようにLLMを保護しているか

私たちは、上記のリスクはいずれ必ず現実になると想定し、現実になっても大きな被害が出ないように設計しています。CISOのKyle Polleyが、その方法を最近のワークショップで詳しく説明しました。

• エージェントには専用のコンピューターが与えられ、最初は空の状態から始まる：ノートPCにインストールしたエージェントツールは、そのPC上のファイル、アプリ、保存された認証情報にアクセスできてしまう可能性があります。Perplexity Computerはその逆です。各タスクはそれぞれ隔離されたサンドボックスで実行され、Polleyの言葉を借りれば「デフォルトでは何にもアクセスできない」のです。
• エージェントがパスワードを目にすることはない：接続されたサービスの認証情報は、サンドボックスの外に保存されています。エージェントがGitHubなどのサービスにアクセスする必要がある場合は、認証情報を付けずにリクエストを送信します。ゲートウェイが接続先とリクエストの内容が想定どおりであることを確認し、送信時に認証情報を付加します。エージェントは鍵を受け取ることなく接続を利用できます。
• ユーザーの権限はそのまま引き継がれ、さらに絞り込むこともできる：OAuthを通じた接続では、接続先サービスにおけるユーザーのアクセス権限が維持されます。ユーザーが閲覧できないものは、エージェントも閲覧できません。
• すべてのWebページを見知らぬ相手として扱う：テストしたツールが実際の利用環境で私たちのニーズを満たさなかったため、私たちはエージェント型ブラウザーのCometのためにBrowseSafeを開発しました。このブラウザーは、Webページやメールなどの外部コンテンツをスキャンし、プロンプトインジェクションを検出します。モデルとデータセットはどちらもオープンソースとして公開しています。
• エージェントと、それが動作するマシンを監視する：Numbatは、エージェントが行動を決定してから、ツールが実際に実行されるまでの間に位置します。Numbatは対応するコーディングエージェント全体のアクティビティを記録し、設定されたポリシーに違反するアクションを実行前にブロックできます。Bumblebeeは、ノートPC、サーバー、ビルドパイプライン全体のソフトウェアパッケージを棚卸しし、既知の悪意あるパッケージにフラグを立てます。どちらもオープンソースです。
• モデルプロバイダーはユーザーのデータを保持しない：私たちは、サードパーティのLLMプロバイダーとの間でデータ保持ゼロの契約を結んでいます。また、Enterpriseの管理者は、Perplexity自体のデータ保持期間を最短24時間に設定できます。

私たちがNumbatを先回りして開発したのには理由があります。Polleyはそれを一言でこう表現しています。「エージェントに与える自律性が大きいほど、リスクも大きくなる」

LLMセキュリティに関するよくある質問

最も安全なLLMはどれですか？

LLMだけでアプリケーションが安全になるわけではありません。モデルは依然として、読むべきコンテンツを、従うべき指示と取り違えてしまうことがあります。また、標準的なテストでは強固に見える防御策も、本格的な攻撃にさらされると崩れることがあります。

より適切な問いは、自社のユースケースにとってどの構成が最も安全か、です。つまり、権限を限定し、認証情報をモデルから遠ざけ、リスクの高いアクションには人間の承認を必須とし、自社の防御策を熟知した人によるテストを行うことです。

LLMの脆弱性とは何ですか？

LLMの脆弱性とは、攻撃者によるものか、AIシステム自身のミスによるものかを問わず、AIシステムがだまされたり、データを漏洩したり、損害を引き起こしたりする原因となる弱点のことです。

主な10のリスクは、プロンプトインジェクション、機密情報の漏洩、過剰なエージェンシー、サプライチェーン、データとモデルのポイズニング、無制限の消費、誤情報、隠れたコンテキストの露出、ベクトルと埋め込みの弱点、不適切な出力処理です。

プライベートLLMは安全ですか？

用途によってはより安全な選択肢になりますが、それだけで安全になるわけではありません。自社のインフラストラクチャやクラウド環境でモデルを運用すれば、データの取り扱いをより細かく管理できます。しかし、プロンプトインジェクション、過剰なエージェンシー、ポイズニング、誤情報を自動的に防ぐ方法はありません。

セルフホストする場合は、ダウンロードしたモデルについても、サプライチェーンのリスクや必要なインフラストラクチャを含めて責任を負うことになります。