不正指示を見抜くモデル「deberta-v3-base-prompt-injection-v2」とは

「生成AIの問い合わせ窓口に、指示を書き換えるような文章を送り込まれたら防げるのか」「社内文書を読ませて答えさせる仕組みを作ったが、文書の中に紛れた命令までAIが従ってしまわないか」——生成AIを業務の仕組みに組み込み始めた開発部門と、それを見守るセキュリティ担当の間で、いま行き交っている声です。こうした不安に対して、入力を機械で検査する判定モデルを前段に置くという考え方があります。ただし本当に問うべきなのは判定モデルの有無ではなく、判定モデルが何を見分けられて、何を見分けられないのかを知ったうえで置けるかという点です。この記事では、Protect AIが公開した判定モデル「deberta-v3-base-prompt-injection-v2」を取り上げ、モデルカードに書かれた事実と限界、安全面の注意点、企業が導入前に決めておくべきことを整理します。導入や設定の手順、攻撃文の例は扱いません。

deberta-v3-base-prompt-injection-v2とは何か。2026年10月時点で確かめられる事実

deberta-v3-base-prompt-injection-v2は、AIモデルの共有サイトHugging Faceで公開されている文章の判定モデルです。モデルカード（モデルの説明書）によると、Microsoftが公開した言語モデル「DeBERTa-v3-base」をもとに、Protect AIが追加の学習を行ったもので、言語モデルを操って意図しない出力をさせる「プロンプトインジェクション」を見分けて分類するために作られたと説明されています。対象の言語は英語、ライセンスはApache 2.0です。

このラインの精査で確かめた事実を並べます。モデルの登録は2024年4月20日、最後の更新は2026年7月9日です。2026年10月20日時点で、直近1か月のダウンロード数は約67万、いいねの数は121でした。大きさは約2億の値（パラメーター）を持つ規模で、生成AIの基盤モデルに比べると小さく、判定だけに特化したモデルです。重みのファイルのほかに、動かす環境を選びにくくするためのONNXという共通形式に変換したものも同じ場所に置かれています。

このモデルの呼び名は、もとになったモデルの名前に「プロンプトインジェクション」と版の番号を足したものです。v2とあるとおり、同じ公開元による前の版も公開されており、前の版のモデルカードには新しい版としてこのモデルが案内されています。Hugging Face上では、このモデルを組み込んだ公開アプリが35件、さらに調整を加えた派生のモデルが13件表示されており、入力の検査役として広く使われてきたモデルであることがうかがえます。

プロンプトインジェクションとは。なぜ判定の仕組みが求められるのか

プロンプトインジェクションは、生成AIに渡す文章の中に、本来の指示を上書きするような命令を紛れ込ませ、AIの振る舞いを変えてしまう攻撃です。AIの安全に関する国際的な指針であるOWASPの生成AI向けの10大リスクでは、最初の項目に挙げられています。OWASPは、利用者の入力そのものが振る舞いを変える「直接型」と、AIが読み込んだ外部のページやファイルに含まれた指示が振る舞いを変える「間接型」を区別しています。

企業にとって厄介なのは間接型です。社内文書や受信したメール、外部のウェブページをAIに読ませて答えさせる仕組みでは、利用者に悪意がなくても、読ませた文書の側に命令が仕込まれているおそれがあります。LLM Guardの文書も、文書を検索して答える仕組み、ウェブを閲覧する対話の仕組み、メールを自動で処理する仕組みを、危険の高い場面として挙げています。

こうした入力を人がすべて読んで確かめるのは現実的ではありません。そこで、AIに渡す前の入力を別の小さなモデルで検査し、疑わしいものを止めたり記録したりする考え方が生まれました。deberta-v3-base-prompt-injection-v2は、その検査役を担うモデルの一つです。ただしOWASP自身が、プロンプトインジェクションを確実に防ぐ方法があるかは分かっていないと書いており、検査役は被害を減らす手段の一つという位置づけです。

仕組み：入力を「問題なし」と「注入の疑い」の二つに分ける

モデルカードによると、このモデルの役割は単純です。受け取った文章を、問題なしを表す「0」と、注入の疑いありを表す「1」のどちらかに分類します。文章を書き換えたり、AIの代わりに答えたりはしません。あくまで入力に点数を付けて、二つの箱のどちらに入るかを示す判定役です。その結果を受けて止めるか通すかは、組み込む側の仕組みが決めます。

LLM Guardの文書では、このモデルの出す確からしさの数値に境目を設け、それを超えたら注入の疑いとして扱う使い方が説明されています。文書の例では境目を真ん中の値に置いていますが、既定の値として決まっているとは書かれていません。つまり、どこで線を引くかは使う側が決めるということです。線を低くすれば見逃しは減りますが誤検知が増え、高くすればその逆になります。

もう一つ押さえておきたいのが、一度に読める長さです。モデルカードの利用例は、一度に読む長さをおよそ512の単位（トークン）で区切る前提で書かれています。長い文章をそのまま渡すと、後ろの部分が読まれない可能性があります。LLM Guardの文書も、長い入力では判定のしかたを切り替えると精度が上がる場合があると触れています。長い社内文書を読ませる仕組みで使うなら、文章のどの部分まで検査されているのかを確かめる必要があります。

公開元が示す精度の数字をどう読むか

モデルカードには二種類の数字が載っています。一つは学習の途中で使った評価用データでの結果で、正解率は99.93パーセントです。もう一つは、学習に使っていないデータセットから集めた2万件の入力での結果で、正解率は95.25パーセント、適合率は91.59パーセント、再現率は99.74パーセント、両者をまとめたF1という指標は95.49パーセントでした。実際の運用に近いのは、学習に使っていないデータでの数字のほうです。

再現率99.74パーセントは、注入の疑いがある入力のほとんどを拾えたという意味です。一方で適合率91.59パーセントは、疑いありと判定したもののうち1割弱が、実は問題のない入力だったことを示します。見逃しを減らす方向に寄せた結果、正常な入力を止めてしまう誤検知が一定の割合で起きると読むのが妥当です。顧客からの問い合わせを受ける窓口で使えば、普通の質問が止められる場面が出てくると考えられます。

また、これらの数字は公開元自身が、公開元の選んだデータで測ったものです。日本語の入力、自社の業務の文章、最近の新しい攻撃の型で測った数字ではありません。前の版との比較では、正解率が94.8パーセントから95.25パーセントへ、適合率が90.9パーセントから91.59パーセントへと上がっており、誤検知を減らすことが改良の主な狙いだったと読み取れます。それでも誤検知がなくなったわけではありません。

学習に使ったデータと、前の版からの変化

モデルカードによると、学習用のデータは公開されている複数のデータセットを集めて作られました。さらに、学術論文や記事、セキュリティの競技会、LLM Guardの利用者から寄せられた意見をもとに、注入の例を作って加えたとされています。開発の過程では、学習の条件やデータの組み合わせを変えて20を超える構成を試したと書かれています。

データの権利についても一覧があります。MITライセンスのものが8件、権利表記のないものが6件、Apache 2.0のものが5件、ほかに権利表記を求める種類のものなどが含まれます。前の版のモデルカードには、学習データの中にはモデル本体より厳しい条件、たとえば非商用に限る条件のものがありうるので確かめてほしい、という注意書きがありました。モデル本体はApache 2.0でも、学習データの条件まで含めて社内の法務が確認することを勧めます。

前の版からの変化について、モデルカードは、新しいデータセットを使い、英語のプロンプトインジェクションだけに焦点を絞ったと説明しています。精度の改善と、利用者の意見への対応を行ったとも書かれています。前の版のモデルカードには、学習で扱っていない文体や話題ではうまく働かない可能性があるという限界も書かれていました。対象を英語に絞ったことは、精度を上げる一方で、英語以外の言語を対象外にする選択でもあったと考えられます。

使われ方：入力の見張り役としての位置づけ

このモデルは、Protect AIが公開していた生成AI向けの検査の道具集「LLM Guard」の中で、入力を検査する部品の一つとして使われてきました。LLM GuardはGitHubで公開され、スターは約3,200、ライセンスはMITです。LLM Guardの文書は、この部品が利用者からの入力を検査するためのものだと説明しています。モデルカードには、生成AIのアプリを組み立てる部品集LangChainの文書への案内もあります。

置き場所としては、利用者の入力や外部から読み込んだ文書を生成AIに渡す直前です。疑わしい入力を止める、記録を残して後から人が確かめる、利用者に確認を求めるといった扱いが考えられます。どの扱いにするかは、モデルではなく組み込む側が決めることです。モデルが答えるのは疑わしいかどうかの見立てであって、止めるかどうかの判断ではないという点を、仕組みを作る段階で共有しておく必要があります。

一方で、モデルカードとLLM Guardの文書は、どちらもAIの振る舞いを決める指示文（システムへの指示）をこのモデルで検査することを勧めていません。誤検知が起きるためです。システムへの指示には命令の形の文章が多く含まれるため、注入の疑いと見なされやすいと考えられます。検査の対象は利用者の入力と外部から取り込む文章に絞り、自社で書いた指示文は検査の対象から外すのが、公開元の想定に沿った使い方です。

速さの目安と動かす環境

判定役を前段に置くと、その分だけ応答が遅くなります。LLM Guardの文書には、クラウドの仮想サーバーで測った速さの目安が載っています。384単位の長さの入力で、一般的な処理装置（CPU）だけの環境では1件あたり約210ミリ秒、ONNX形式に変換したものでは約100ミリ秒でした。画像処理用の装置（GPU）とONNX形式を組み合わせた環境では、1件あたり約8ミリ秒まで短くなっています。

これらは公開元が特定の条件で測った数字で、自社の環境で同じ速さが出るとは限りません。それでも、小さな判定モデルなら、生成AIの応答時間に比べて検査の待ち時間は小さく抑えられるという目安にはなります。大きな生成AIそのものに検査をさせる方法と比べると、費用と速さの面で有利な場面があると考えられます。

動かす場所の選択も、守りの設計に関わります。このモデルは自社の環境の中で動かせる大きさなので、検査のために入力を外部のサービスに送らずに済みます。顧客の問い合わせや社内文書を検査する場合、検査そのもので情報が外に出ないことは利点です。ただし、自社で動かすということは、更新や障害への対応も自社が担うということでもあります。この点は、後で触れる開発終了の話と結びつきます。

似た手段と何が違うのか

プロンプトインジェクションへの備えには、いくつかの手段があります。下の表は、判定モデルを置く方法を、ほかの代表的な手段と並べたものです。他の手段の欄は、OWASPが挙げる対策の分類をもとにした一般的な整理で、特定の製品の評価ではありません。

見る点	判定モデル（このモデル）	決まった言葉で止める規則	生成AI自身に判断させる	権限を絞る・人が承認する
守る場所	生成AIに渡す前の入力	生成AIに渡す前の入力	入力または出力	AIが実行できる操作
得意なこと	言い回しを変えた英語の注入にも反応しやすい	既知の言葉を確実に止める	文脈を踏まえた判断	見逃したときの被害を小さくする
苦手なこと	英語以外、安全装置を外させる型、誤検知	言い換えに弱い	費用と遅さ、判断自体が操られうる	見つけることはしない
日本語の業務への当てはまり	対象外と明記	規則しだい	モデルしだい	言語に左右されない

表から分かるとおり、どの手段にも苦手な範囲があります。判定モデルは見つける役、権限の絞り込みと人の承認は見逃したときの被害を小さくする役で、役割が違うので、どちらか一方で済ませるものではないと考えるべきです。OWASPも、入力と出力の検査に加えて、権限の最小化、危険な操作での人の承認、外部の文章の区別、攻撃を想定した試験を並べて挙げています。

安全性の評価：注意付きとした根拠

このラインでは、紹介するモデルを公開されている事実だけで精査しています。モデルを入手したり動かしたりはしていません。deberta-v3-base-prompt-injection-v2の判定は「注意付き」です。解説記事として取り上げますが、使うなら先に知っておくべき点があるという判定です。

まず、問題が見つからなかった点です。公開元はAIの安全を扱うProtect AIの組織アカウントで、同社は2025年7月にPalo Alto Networksによる買収が完了したと発表されています。ライセンスはApache 2.0で、利用に同意を求める制限もかかっていません。重みの本体はsafetensorsという、読み込んだだけでプログラムが動くことのない形式で置かれています。独自のプログラムを読み込ませる仕組みも含まれていません。Hugging Faceの自動検査では、重みを含むほとんどのファイルが安全と表示されています。

それでも注意付きとした根拠は二つあります。一つ目は、学習時の設定を記録したと見られる小さなファイルが、pickleという形式で置かれていることです。Hugging Faceの文書は、この形式は読み込むときに任意のプログラムが実行されうると注意しています。このファイルの自動検査の表示には、読み込み時に呼び出される部品が九つ検出されたとあり、安全か危険かの判定は示されていません。二つ目は、モデルカードの冒頭で、プロジェクトがすでに開発終了となったと告知されていることです。

なお、問題が見つからないことは安全の保証ではありません。精査は公開情報の範囲に限られ、モデルの中身や振る舞いを検証したものではないからです。判定モデルは守りの入口に置くものなので、自社の入力でどう振る舞うかは、導入する側で確かめる必要があります。

モデルカードに書かれた限界：英語以外・安全装置を外させる攻撃・システムへの指示

モデルカードの「限界」の節には、三つのことが書かれています。一つ目は、英語のプロンプトインジェクションの判定では精度が高い一方で、英語以外の入力は扱わないことです。日本語の問い合わせや社内文書を検査しても、公開元が想定した働きは期待できません。日本の企業にとって、これは最も重い制約です。

二つ目は、安全装置を外させるための攻撃、いわゆるジェイルブレイクを見分けないことです。OWASPは、ジェイルブレイクをプロンプトインジェクションの一種で、モデルに安全上の決まりを無視させることを狙うものと説明しています。つまり広い意味での不正な指示の一部は、このモデルの守備範囲の外にあります。モデルカードは、高度な攻撃の手口に対しても使える範囲が限られる可能性があると認めています。

三つ目は、すでに触れたとおり、システムへの指示の検査には勧めないということです。誤検知が起きるためです。このほか、前の版のモデルカードには、学習で扱っていない文体や話題ではうまく働かない可能性があると書かれていました。v2のモデルカードには同じ記述はありませんが、自社の業務の文章で誤検知と見逃しがどの程度出るかは、公開情報からは分からないというのが、現時点で言えることです。

開発の終了と、提供元の買収をどう受け止めるか

モデルカードの冒頭には、このプロジェクトと、関連するGitHubのコードはすでに開発も保守も行われていない、という告知があります。LLM GuardのGitHubのリポジトリも、2026年7月9日に所有者によって読み取り専用の状態にされました。つまり、新しい攻撃の手口が出てきても、このモデルが学び直されることは期待できないということです。

プロンプトインジェクションの手口は、言い回しや形式を変えながら増え続けています。判定モデルは、学習したときに知っていた型には強くても、知らない型には弱くなりがちです。時間がたつほど、公開元が示した精度と実際の精度の差が開いていく可能性があります。Palo Alto Networksは、Protect AIの技術と人員を自社のAIの安全を守る製品群に組み込むと発表していますが、このモデルの後継が無料で公開されるかどうかは、確認した一次情報には書かれていない状況です。

開発終了は、すぐに使えなくなるという意味ではありません。公開された重みは残り、ライセンスも変わりません。ただ、問題が見つかっても公開元が直すことはないため、使い続けるなら自社が評価と更新の責任を持つ前提に立つ必要があります。商用の製品や別の公開モデルに移る場合に備えて、検査役を差し替えやすい作りにしておくことも考えられます。

悪用されうるリスク

このモデルは守りのための判定役で、攻撃のための道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、「判定モデルを入れたから、不正な指示は止まる」という安心が独り歩きすることです。日本語の入力、安全装置を外させる型の攻撃、学習していない新しい手口は、この判定役をそのまま通り抜ける可能性があります。

次に挙げるのは推測ですが、検討の材料になります。判定モデルは公開されているため、攻撃する側も同じモデルを手元で試し、判定をすり抜ける言い回しを探せると考えられます。公開された検査役は、守る側だけでなく、攻める側にとっても試験台になりうるという性質を持ちます。開発が止まっている以上、すり抜けの手口が広まっても、公開元による修正は見込めません。

もう一つは、配布物そのものの扱いです。pickle形式のファイルは、読み込むときにプログラムが動きうる形式です。このモデルのファイルについて悪意のある中身が報告されているわけではありませんが、派生のモデルや、別の場所に複製されたものまで同じとは限らない点に注意が必要です。なお、このモデルが実際に攻撃に悪用された事例は、2026年10月20日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、モデルを動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、モデルを入手する前の段階で終えられるものに絞っています。

この手順の要は、モデルを入れることと、モデルが見落とす範囲を決めることを同時に進めることです。判定モデルは守りの一枚であって、生成AIに与える権限の設計や、社内の利用規程に代わるものではありません。

企業が取るべき対策

一つ目は、生成AIに渡る入力の経路を把握することです。利用者の入力だけでなく、検索して取り込む文書、受信したメール、外部のページなど、AIが読むものはすべて命令の運び手になりえます。どの経路に検査役を置き、どの経路が無防備なのかを図にしておくことが、判定モデルを意味のあるものにする前提です。

二つ目は、見逃しを前提にした権限の設計です。生成AIが社内の仕組みを操作したり、外部に情報を送ったりできる場合、検査をすり抜けた命令はそのまま実行に移ります。AIができる操作を必要最小限に絞り、送金や削除、外部への送信といった操作は人の承認を通す作りにします。三つ目は、記録と見直しです。疑いありとされた入力と、後から問題が分かった入力を記録し、判定役の見逃しと誤検知を定期的に確かめます。

四つ目は、モデルの調達の決まりです。Hugging Faceなどから入手するモデルについて、公開元、ライセンス、学習データの条件、ファイルの形式、保守の状態を確かめる項目を、社内の調達の手続きに入れます。五つ目は、日本語の業務への備えです。日本語の入力を検査する手段は、このモデルとは別に用意する必要があり、商用の製品や他の公開モデルを比べる際も、日本語で自社の文章を使って試すことを条件にします。

AIに任せる範囲と、人が決める範囲

判定モデルは、それ自体がAIです。入力を読んで点数を付けることはできますが、その点数を見て業務を止めるかどうかを決める責任までは負えません。AIに判断させない部分を先に決める必要があるのは、守りのためのAIでも同じです。

具体的には、どの入力を検査するか、どこで線を引くか、疑いありとされたときにどうするか、誤検知で止まった顧客にどう対応するか。この四つはモデルに委ねず、人が決めて記録に残します。検査の結果を記録に残すときは、疑いありとした入力のどの部分が根拠になったのかを担当者が書き添え、人が確認する範囲を先に決めておきます。やってはいけない向き合い方を挙げます。

• 判定モデルを入れたことを理由に、生成AIに与える権限の見直しや人の承認をやめる
• 英語だけが対象と知らないまま、日本語の問い合わせ窓口の守りとして使う
• 疑いありの判定を、人が確かめずにそのまま利用者への処罰や記録の削除につなげる
• 自社で書いたシステムへの指示まで検査にかけ、誤検知で仕組み全体を止める
• 開発終了を知らないまま、何年も評価せずに使い続ける
• 出どころの分からない複製や派生のモデルを、正規のものと同じと見なして使う

裏を返せば、人が決める範囲ははっきりしています。何を検査し、どこで線を引き、見逃したときに何で受け止め、いつ見直すか。この四つが決まっていないまま判定モデルを置いても、守りの厚みは増えません。

よくある質問：日本語の業務で使えるのか

答えは「主な守りとしては使えない」です。モデルカードは、英語以外の入力を扱わないと明記しています。日本語の文章を入れても何らかの点数は出ますが、それが公開元の示した精度で当たっているという裏付けはありません。日本語の業務の守りに使うなら、別の手段を主にするのが妥当です。

では、日本の企業に関係がないのかというと、そうではありません。海外の顧客向けの英語の窓口や、英語のウェブページや資料を読ませる仕組みでは、検査役として使える場面があります。また、ダウンロードの多さから見て、取引先や委託先の開発会社が、生成AIの仕組みにすでに組み込んでいる可能性もあります。その場合は、どの入力を検査しているのか、開発終了をどう扱うのかを確かめる材料になります。

もう一つ、「開発が終わったモデルを使い続けてよいのか」という問いもありそうです。重みとライセンスは残るため、すぐに使えなくなるわけではありません。問題は、新しい手口に追いつかなくなることです。自社の入力で定期的に精度を測り、下がったら差し替えるという約束を社内で持てるなら使い続ける選択もあり、持てないなら別の手段を検討するのが筋です。

• deberta-v3-base-prompt-injection-v2の機能・精度・限界・ファイルの構成は、Hugging Faceのモデルカードとファイルの一覧、前の版のモデルカード、LLM GuardのGitHubのリポジトリと文書、Hugging Faceのpickle形式に関する文書、OWASPの文書、Palo Alto Networksの発表を2026年10月20日に確かめた範囲に基づきます
• 精度と速さの数値は公開元自身の測定です。日本語の入力や自社の業務の文章での精度は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や攻撃文の例は扱いません

まとめ

deberta-v3-base-prompt-injection-v2は、Protect AIがMicrosoftの言語モデルをもとに作った、生成AIへの入力を「問題なし」と「注入の疑い」に分ける判定モデルです。公開元の測定では、学習に使っていないデータでも見逃しはごく少なく、小さなモデルなので自社の環境で速く動かせます。Apache 2.0で公開され、入力の検査役として広く使われてきました。

一方で、英語以外の入力と安全装置を外させる型の攻撃は対象外で、正常な入力の1割弱を疑いありとする誤検知もあると、公開元自身の資料から読み取れます。2026年7月には開発終了となり、学び直しは見込めません。配布物には、読み込み時にプログラムが動きうる形式のファイルも含まれます。判定モデルが見落とす範囲を先に認め、権限の設計と人の承認で受け止めることが、生成AIを業務に組み込む企業にとってのこのモデルとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。