AIに渡す文章に紛れた不正な指示を見分けるモデル「Wolf Defender」とは

AIに渡す文章に紛れた不正な指示を見分けるモデル「Wolf Defender」とは

「社内文書やメールをAIエージェントに読ませ始めたが、その中に命令が仕込まれていたら気づけるのか」「日本語の文章を検査できる判定役はないのか。英語専用ばかりでは使いにくい」——生成AIを業務の流れに組み込み始めた開発部門と、その守りを任された情報システム部門から、繰り返し寄せられる問いです。答えを一つのモデルに求めたくなりますが、本当の論点は検査役の性能の高さではありません。検査役が見る範囲と見ない範囲を知ったうえで、見逃しを受け止める仕組みと組み合わせられるかが問われています。この記事では、2026年に公開された判定モデル「Wolf Defender」を取り上げ、モデルカードで確かめられる事実、提供元をめぐる確認の結果、安全面の評価、企業が導入前に決めておくべきことを整理します。導入や設定の手順、攻撃文の例は扱いません。


カメ先生カメ先生

性能の数字が高い判定モデルを入れれば、不正な指示はほぼ止まると思われがちなんだ。でも本当は、どの言語で、どんな長さの文章で、誰が測った数字なのかで、意味がまったく変わるんだよ。


カメ子カメ子

数字が高くても、自社の文章で同じ結果になるとは限らないということですか。


カメ先生カメ先生

そう。Wolf Defenderは多言語に対応した土台の上に作られていて、長い文章も区切って読める。ただ、公開元がしっかり確かめたのは英語とドイツ語が中心で、日本語は確かめた範囲に入っていない。しかも判定役は文章しか見ないから、誰が送ったか、AIにどんな権限があるかは知らないんだ。


カメ子カメ子

では、モデルに任せる部分と、権限や承認の仕組みで受け止める部分を、人が先に分けておく必要があるということですか。


この記事のポイント
  • Wolf Defenderは、AIに渡す文章を「問題なし」と「注入の疑い」に分ける判定モデル。多言語の土台モデルをもとに作られ、ライセンスはApache 2.0。重みは安全な形式で、独自のプログラムも含まない
  • 公開元の測定では、紛らわしい正常な文章を誤って止める割合が前の版より大きく下がった。ただし数字は公開元自身の測定で、主に確かめた言語は英語とドイツ語。日本語での精度は公開情報からは分からない
  • 名義はPatronus Protectで、運営会社はドイツの企業と表示されている。同じ名前を含む米国のPatronus AI社との関係は確かめられなかった。使う範囲と止める判断は人が決める

AIの導入・活用、何から始めるべきかお悩みですか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

目次

Wolf Defenderとは何か。2026年10月時点で確かめられる事実

Wolf Defenderは、AIモデルの共有サイトHugging Faceで公開されている文章の判定モデルです。モデルカード(モデルの説明書)によると、大規模言語モデル(LLM)に届く前の文章から、プロンプトインジェクションや安全装置を外させる型の指示を見つけるための分類モデルと説明されています。検査の対象として、利用者の入力のほか、検索して取り込んだ文書、メール、ウェブページ、AIエージェントが使う道具の出力が挙げられています。

このラインの精査で確かめた事実を並べます。モデルの登録は2026年3月8日、最後の更新は2026年10月24日です。2026年10月27日時点で、ダウンロード数は5,687、いいねの数は26でした。ライセンスはApache 2.0で、利用の前に申請や同意を求める制限はかかっていません。大きさは約3億800万の値(パラメーター)を持つ規模で、生成AIの基盤モデルに比べると小さく、判定だけに特化したモデルです。同じ公開元からは、約1億4,000万の値を持つ小型版「Wolf Defender Small」も別の置き場所で公開されています。

現在の版は、モデルカードの変更履歴で「v2」とされています。初版は、同じ土台モデルの上に作った最初の公開版で、v2では判定の仕組みを学び直し、長い文章の学習と評価を加え、紛らわしい正常な文章での誤検知を減らしたと書かれています。重みのファイルのほか、動かす環境を選びにくくするためのONNXという共通形式に変換したものも、精度と大きさの異なる四種類が同じ場所に置かれています。なお、このラインではモデルを入手したり動かしたりはしておらず、以下はすべて公開情報を読んで確かめた範囲の話です。

提供元はどこか。Patronus AI社との関係は確かめられなかった

モデルが置かれているのは、Hugging Face上の「patronus-studio」という組織の名前の下です。モデルカードの著者名と引用の書き方は「Patronus Protect」で、製品の案内はpatronus.studioというサイトにつながっています。そのサイトの下部には、運営会社としてCasdo Labs GmbHの名前と、ドイツのミュンヘン区裁判所での商業登記の番号が記されています。Wolf Defenderは、Patronus Protectという名前の製品群を出すドイツの企業のモデルと読むのが、一次情報に沿った理解です。

一方、AIの評価の分野には、名前がよく似た米国のPatronus AIという企業があります。Hugging Face上の同社の組織(PatronusAI)は、自社のサイトとしてpatronus.aiを掲げており、確認した時点ではWolf Defenderも、patronus.studioも出てきませんでした。反対に、patronus.studioのページとWolf Defenderのモデルカードにも、Patronus AIへの言及はありません。両者が同じ会社か、資本や提携の関係があるかは、確認した一次情報からは確かめられませんでした。運営会社の名前と所在地が異なることから別の組織である可能性が高いと考えられますが、これは推測です。

この点をあえて書くのは、調達や社内の説明で取り違えが起きやすいからです。「評価の分野で知られた会社のモデル」と思い込んで選ぶと、問い合わせ先や契約の相手を誤るおそれがあります。モデルを選ぶときは、名前の似た会社ではなく、置き場所の組織名と運営会社の表示で出どころを確かめることを勧めます。なお、patronus.studioには、Wolf Defenderのほかにも、道具の呼び出しや文書の機密性を判定する複数のモデルが並んでいます。

なぜ今、文章の検査役が求められるのか

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

AIエージェントが広がると、間接型の重みが増します。エージェントはメールを読み、ウェブを調べ、道具を呼び出してその結果を読み、次の行動を決めます。その途中で読む文章のどこかに命令が仕込まれていれば、利用者に悪意がなくても、エージェントが他人の命令に従って動くおそれがあります。Wolf Defenderのモデルカードが、メールや道具の出力を検査の対象に挙げているのは、この流れを踏まえたものです。

こうした文章を人がすべて読んで確かめるのは現実的ではありません。そこで、AIに渡す前の文章を小さなモデルで検査し、疑わしいものを止めたり記録したりする考え方が使われています。ただしOWASP自身が、プロンプトインジェクションを確実に防ぐ方法があるかは分かっていないと書いており、検査役は被害を減らす手段の一つという位置づけです。Wolf Defenderのモデルカードも、権限の制限や情報源の信頼度と組み合わせる一つの層として使うよう求めています。

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

モデルカードによると、Wolf Defenderの役割は単純です。受け取った文章を「問題なし」と「注入の疑い」のどちらかに分類し、注入の疑いの確からしさを数値で返します。文章を書き換えたり、AIの代わりに答えたりはしません。あくまで文章に点数を付けて、二つの箱のどちらに入るかを示す判定役です。モデルカードは、このモデルが文章を作らないこと、エージェントの権限も決めないことを明記しています。

判定の結果をどう扱うかは、組み込む側が決めます。モデルカードの説明図では、問題なしなら先へ進め、注入の疑いなら自社のセキュリティの方針を当てはめる流れが示され、止める、隔離する、人の確認に回すのいずれにするかは利用する側が決めると書かれています。公開元の評価は、確からしさが真ん中の値を超えたら疑いありとする線で行われていますが、モデルカードは線の位置は実際に流れる文章で調整するべきだとしています。線を低くすれば見逃しは減り誤検知が増え、高くすればその逆になります。

もう一つ大事なのは、このモデルが文章しか見ないことです。モデルカードの限界の節には、誰が送った文章か、道具にどんな権限があるか、文章の出どころや信頼の境目は、文章の中に書かれていない限り分からないとあります。同じ文章でも、社内の担当者が書いたのか、外部のウェブページから来たのかで危険の度合いは違います。その区別は、判定役の外側にある仕組みが担う必要があります。

長い文章の扱い:区切って読み、最も疑わしい部分を拾う

文章の判定モデルには、一度に読める長さの上限があります。Wolf Defenderは、文章を細かく区切った単位(トークン)で数えて、一度に2,048単位まで読めます。これより長い文書について、モデルカードは、2,048単位ずつの窓に区切り、隣り合う窓を64単位ずつ重ねて読み、それぞれの窓の結果を、最も疑わしい部分を重く見る方法でまとめる手順で評価したと説明しています。長い文書の途中に命令が埋め込まれても拾えるようにする工夫です。

ここで注意したいのは、この区切り方はモデルの外側で行う処理で、組み込み方しだいで変わるという点です。たとえば、業務の連携基盤であるApache Camelの公式の部品では、2,048単位を超える文章は区切らずに受け付けない作りになっていると、Camelの文書に書かれています。長い文章をそのまま一回で判定させる作りでは、上限を超えた後ろの部分が検査されない可能性もあります。

長い社内文書や、検索して取り込んだ複数の文書をまとめて読ませる仕組みで使うなら、文章のどこからどこまでが検査されているのかを、組み込みを担当する開発者に確かめる必要があります。モデルカードも、長い文書では窓に区切る処理を使うよう案内しています。検査されていない部分が残る作りでは、モデルの精度の数字はそのまま当てはまりません。

多言語の土台と、日本語の扱い

Wolf Defenderの土台は、米国のジョンズ・ホプキンス大学の言語と音声の研究拠点が公開した多言語モデル「mmBERT-base」です。その説明によると、1,800を超える言語で学習され、ライセンスはMITです。Wolf Defenderはこの土台に追加の学習を行ったもので、モデルカードには土台のMITライセンスの表記も引き継いでいると書かれています。英語専用の判定モデルが多いなかで、多言語の土台を選んでいることが、このモデルの大きな特徴です。

ただし、土台が多言語であることと、判定が多言語で確かめられていることは別の話です。モデルカードによると、主に評価した言語は英語とドイツ語で、学習にはドイツ語、スペイン語、中国語、ロシア語の例や、その他の多言語の資料が含まれます。そのうえで、それ以外の言語は確かめた範囲が少ないと明記されています。日本語について、学習に使ったか、どれだけ確かめたかの記載は、確認した範囲ではありませんでした。

つまり、日本語の文章を入れても何らかの点数は出ますが、公開元の示した精度で当たっているという裏付けはありません。モデルカードには、利用者による少人数の試験として、スペイン語の正常な文章で誤検知がなかったという報告も載っていますが、試験の数が少ないと公開元自身が断っています。日本語の業務で使うかどうかは、自社の日本語の文章で見逃しと誤検知を測ってから判断するほかありません。

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

モデルカードには、複数のデータで測った数字が並んでいます。公開元が用意した約7万2,000件の検証用データでは、注入の疑いを拾う力と正しさをまとめたF1という指標が98.44パーセント、正常な文章を正常と判定できた割合が99.83パーセントでした。学習に使わずに取り分けた約1万4,700件の試験では、見逃しの割合が3.15パーセント、正常な文章を誤って止める割合が0.41パーセントです。

注目したいのは、紛らわしい正常な文章での数字です。セキュリティの解説文や、命令の形をした正常な文章など、誤検知を起こしやすい2,523件を集めたデータで、v2は96.23パーセントを正常と判定しました。前の版は81.57パーセントでした。実際の業務に近い正常な文章178件では、前の版の66.85パーセントから96.63パーセントへ上がっています。改良の主な狙いは、正常な文章を止めてしまう誤検知を減らすことだったと読み取れます。ただ、178件という数は小さく、自社の文章で同じ結果になるとは限りません。

もう一つ押さえるべきは、これらが公開元自身が、公開元の選んだデータで測った数字だということです。モデルカードには、他社の判定モデルと並べた比較表や、外部の研究者による比較の結果も引用されていますが、比較の条件は公開元が決めたもので、このラインでは比較先の数字を独自には確かめていません。モデルカード自身も、エージェントの環境を模した試験は決まった攻撃を使ったもので、すべての状況を代表するものではないと注意しています。エージェントの守りで気になる、道具の出力に混ぜ込まれた指示についても数字があります。小型版のWolf Defender Small v2を、研究用の環境AgentDojoの攻撃文27種類を長い道具の出力に埋め込んだ試験で測ったところ、攻撃の場面の83.31パーセントを拾い、正常な出力97件のうち誤って止めたのは1件でした。攻撃文を単独で判定すれば27種類中25種類を拾えたのに対し、長い出力に埋め込まれると周りの文章に薄められて見逃しが増えたと書かれています。公開元は、攻撃文の種類が少なく、複数回のやり取りを網羅した評価ではないと断っており、このモデルは会話の流れを覚えておく仕組みでもありません。

組み込み先の広がりと、その受け止め方

モデルカードの冒頭には、Wolf Defenderを組み込んでいる取り組みとして、業務連携の基盤Apache Camel、AIの信頼性を扱う取り組みTrustyAIの安全装置の設定、ほか複数の公開ソフトウェアが挙げられています。Apache Camelの文書では、版4.23から、Wolf Defenderの小型版を使って文章を検査する公式の部品が用意され、外部のモデルのサービスに頼らずに手元の処理装置(CPU)で判定すると説明されています。

Camelの文書によると、この部品は判定の結果と注入の疑いの確からしさを返し、続けるか、拒否するか、人の確認に回すかは、業務の流れの側で決める作りです。境目の値の初期値は真ん中で、判断のつきにくい範囲の扱いは既定ではエラーとして止める設定になっています。モデルの重みはCamelには同梱されず、利用者が自分の環境に用意する前提です。判定役と、止めるかどうかの判断を分けて設計している点は、守りの考え方として参考になります。

また、Red Hatの組織の下にも同じモデルの複製が置かれています。ただし、その置き場所は公開元からの複製と表示されているだけで、Red Hatが性能を検証した、あるいは保守を約束したという記述は確認できませんでした。大手の名前が並んでいることは、組み込みやすさの目安にはなりますが、品質の保証とは別に受け止めるべきです。モデルカード自身も、組み込み先の記載は推奨を意味しないと書いています。

似た手段と何が違うのか

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

見る点判定モデル(Wolf Defender)決まった言葉で止める規則生成AI自身に判断させる権限を絞る・人が承認する
守る場所AIに渡す前の文章AIに渡す前の文章入力または出力AIが実行できる操作
得意なこと言い回しを変えた注入、長い文書の途中の注入既知の言葉を確実に止める文脈を踏まえた判断見逃したときの被害を小さくする
苦手なこと未知の手口、短くあいまいな文章、送り手や権限の区別言い換えに弱い費用と遅さ、判断自体が操られうる見つけることはしない
日本語の業務への当てはまり土台は多言語だが日本語の精度は未確認規則しだいモデルしだい言語に左右されない

表から分かるとおり、どの手段にも苦手な範囲があります。判定モデルは見つける役、権限の絞り込みと人の承認は見逃したときの被害を小さくする役で、役割が違うので、どちらか一方で済ませるものではないと考えるべきです。Wolf Defenderのモデルカードも、隔離して動かす仕組みや最小限の権限に代わるものではないと、対象外の使い方として明記しています。

判定モデル同士を比べるときにも、見るべき点は同じです。精度の数字だけでなく、対象の言語、一度に読める長さ、長い文書の扱い、公開元の保守の状態を並べて確かめます。Wolf Defenderは一度に読める長さが長く、多言語の土台を持つ点で、英語専用で短い文章を前提にした判定モデルとは性格が異なります。

安全性の評価:紹介可とした根拠

このラインでは、紹介するモデルを公開されている事実だけで精査しています。モデルを入手したり動かしたりはしていません。Wolf Defenderの判定は「紹介可」です。

根拠にした事実を並べます。ライセンスはApache 2.0で、利用に申請や同意を求める制限はかかっていません。重みの本体はsafetensorsという、読み込んだだけでプログラムが動くことのない形式で置かれています。読み込み時に独自のプログラムを動かす仕組みも含まれていません。土台のモデルは大学の研究拠点がMITライセンスで公開したもので、出どころが明らかです。Hugging Faceの自動検査でも、重みや設定のファイルは安全と表示されていました。

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

配布物と提供元について知っておきたいこと

紹介可とした上で、知っておきたい点が三つあります。一つ目は、重みとは別に、学習時の設定を記録したと見られる小さなファイルが、pickleという形式で置かれていることです。Hugging Faceの文書は、この形式は読み込むときに任意のプログラムが実行されうると注意しています。このファイルの自動検査の表示には、読み込み時に呼び出される部品が検出されたとあり、安全という表示は付いていませんでした。判定に使うのは重みと設定のファイルで、このファイルは判定には不要と考えられます。

二つ目は、軽量化した変換版の扱いです。モデルカードは、精度を落として小さくした変換版では、元の重みと計算結果が少しずれることがあると書いています。四種類の変換版で記録した入力の判定が一致したとありますが、公開元はこれを変換の確認であって本格的な評価ではないと断っています。軽量化した版を使うなら、精度の数字は元の重みで測ったものだと理解しておく必要があります。

三つ目は、速さの数字です。モデルカードには、公開元の独自の実行の仕組み(Patronus Runtime Engine)を使うと、一般的な実行環境より数倍速く、使う記憶領域も少ないという測定が載っています。しかしこの仕組みはモデルとは別の条件で提供され、利用には公開元への問い合わせが必要とされています。無償で使える範囲の速さを見積もるときは、一般的な実行環境の数字を見るべきです。モデル自体はApache 2.0ですが、周辺の製品には別の条件があることを押さえておきます。

悪用されうるリスク

このモデルは守りのための判定役で、攻撃のための道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、「判定モデルを入れたから、不正な指示は止まる」という安心が独り歩きすることです。モデルカード自身が、どの分類モデルもすべての攻撃は拾えず、新しい言い回しや、短くあいまいな文章、学習時と性質の違う文章では見逃しが起こりうると書いています。

次に挙げるのは推測ですが、検討の材料になります。判定モデルは公開されているため、攻撃する側も同じモデルを手元で試し、判定をすり抜ける言い回しを探せると考えられます。公開された検査役は、守る側だけでなく、攻める側にとっても試験台になりうるという性質を持ちます。公開元が学習をくり返し、新しい手口を取り込み続けるかどうかが、時間がたったときの守りの厚みを左右します。

もう一つは、配布物そのものの扱いです。このモデルについて悪意のある中身が報告されているわけではありませんが、複製や派生のモデルが増えるほど、別の置き場所にあるものまで同じ中身とは限らないという問題が出てきます。名前の似た別の会社との取り違えも、出どころの確認を難しくします。なお、このモデルが攻撃に悪用された事例は、2026年10月27日時点で確認した一次情報からは見つけられませんでした。

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

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

STEP1
検査したい文章の種類と言語を書き出す

利用者の問い合わせ、読み込ませる社内文書、受信メール、外部のウェブページ、道具の出力など、AIに渡る文章を種類ごとに一覧にし、日本語か英語かを確かめます。日本語が中心なら、自社の文章での試験を前提にします。

STEP2
文章の長さと、検査される範囲を確かめる

一度に読める長さを超える文書がどれくらいあるかを把握し、区切って検査するのか、受け付けないのかを、組み込みを担当する開発者と決めます。

STEP3
疑いありと出たときの扱いを決める

止める、隔離する、記録だけ残す、人が確かめるのどれにするかを、業務の担当者と一緒に決めます。誤検知で止まった場合の連絡先も決めておきます。

STEP4
出どころと配布物を確かめる

置き場所の組織名と運営会社の表示を記録し、名前の似た別の会社と取り違えないようにします。学習時の設定を記録したファイルは読み込まないことを社内の手順に書きます。

STEP5
評価と見直しの担当を決める

自社の文章で見逃しと誤検知を定期的に測る担当と、精度が下がったときに設定や検査役を見直す判断の担い手を決めておきます。

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

企業が取るべき対策

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

二つ目は、見逃しを前提にした権限の設計です。AIエージェントが社内の仕組みを操作したり、外部に情報を送ったりできる場合、検査をすり抜けた命令はそのまま実行に移ります。AIができる操作を必要最小限に絞り、送金や削除、外部への送信といった操作は人の承認を通す作りにします。三つ目は、記録と見直しです。疑いありとされた文章と、後から問題が分かった文章を記録し、判定役の見逃しと誤検知を定期的に確かめます。モデルカードも、線の位置は実際の文章で調整するよう求めています。

四つ目は、モデルの調達の決まりです。Hugging Faceなどから入手するモデルについて、公開元と運営会社、ライセンス、ファイルの形式、更新の頻度を確かめる項目を、社内の調達の手続きに入れます。モデルカードには多数の公開データセットを選んで使ったとあり、それぞれの条件までは示されていないため、学習データの条件は法務に確認してもらうのが安全です。五つ目は、日本語の業務への備えです。日本語で自社の文章を使った試験を、どの判定役を選ぶ場合でも条件にします。

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

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

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

  • 判定モデルを入れたことを理由に、AIエージェントに与える権限の見直しや人の承認をやめる
  • 日本語の精度を確かめないまま、日本語の問い合わせ窓口や社内文書の守りの柱として使う
  • 名前の似た別の会社のモデルと思い込んだまま、調達や社内説明の資料を作る
  • 疑いありの判定を、人が確かめずにそのまま利用者への処罰や記録の削除につなげる
  • 長い文書のどこまでが検査されているかを確かめずに、文書全体が安全と見なす
  • 公開元の精度の数字を、自社の文章で測った数字の代わりに稟議の根拠にする

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

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

答えは「試してみる価値はあるが、確かめるまでは守りの柱にしない」です。土台のモデルは多言語で学習されており、英語専用の判定モデルよりは日本語の文章に向く可能性があります。しかし、モデルカードで主に評価されたのは英語とドイツ語で、日本語での見逃しと誤検知の割合は公開情報からは分からないのが現状です。

では、日本の企業に関係がないのかというと、そうではありません。海外の顧客向けの窓口や、英語の資料やウェブページを読ませる仕組みでは、検査役として使える場面があります。また、業務連携の基盤など、すでに公開されているソフトウェアに部品として組み込まれているため、取引先や委託先の開発会社が自社の仕組みに組み込む可能性もあります。その場合は、どの文章を検査し、疑いありのときにどうしているのかを確かめる材料になります。

もう一つ、「提供元が小さな会社でも大丈夫か」という問いもありそうです。重みとライセンスは公開されており、提供元の事情で今ある重みが使えなくなることは考えにくいと言えます。問題は、新しい手口に合わせた学び直しが続くかどうかです。自社の文章で定期的に精度を測り、下がったら差し替えるという約束を社内で持てるなら選択肢になり、持てないなら保守の体制がはっきりした手段を検討するのが筋です。

  • Wolf Defenderの機能・精度・限界・ファイルの構成は、Hugging Faceのモデルカードとファイルの一覧、patronus.studioの製品のページ、土台モデルのモデルカード、Red Hatの組織の下の複製、Apache Camelの文書、Hugging Faceのpickle形式に関する文書、OWASPの文書を2026年10月27日に確かめた範囲に基づきます
  • 精度と速さの数値は公開元自身の測定、または公開元がモデルカードに引用したものです。日本語の文章や自社の業務の文章での精度は、確認した一次情報の範囲では確かめられませんでした
  • 提供元と米国のPatronus AI社との関係は、双方の一次情報に記載がなく確かめられませんでした
  • この記事は守りと評価の目線で書いています。導入・設定・実行の手順や攻撃文の例は扱いません

まとめ

Wolf Defenderは、AIに渡す文章を「問題なし」と「注入の疑い」に分ける判定モデルです。多言語の土台をもとに作られ、一度に長い文章を読め、Apache 2.0で公開されています。v2では、紛らわしい正常な文章を誤って止める割合を大きく下げたと公開元は示しており、業務連携の基盤の公式の部品にも使われています。提供元はPatronus Protectの名前で製品を出すドイツの企業と表示されており、名前の似た米国のPatronus AI社との関係は確かめられませんでした。

一方で、精度の数字は公開元の測定で、主に確かめた言語は英語とドイツ語です。文章しか見ないため、送り手や権限の区別はできず、長い文書の扱いは組み込み方で変わります。判定モデルが見落とす範囲を先に認め、権限の設計と人の承認で受け止めることが、AIエージェントを業務に組み込む企業にとってのこのモデルとの付き合い方です。

出典(一次情報)
  • Wolf Defenderのモデルカード(目的・仕組み・精度・言語・限界・変更履歴):https://huggingface.co/patronus-studio/wolf-defender-prompt-injection
  • ファイルの一覧(重みの形式と、学習時の設定のファイルの自動検査の表示):https://huggingface.co/patronus-studio/wolf-defender-prompt-injection/tree/main
  • patronus.studioの製品のページ(運営会社の表示・関連モデル・組み込み先):https://patronus.studio/product/ai-models
  • Hugging Face上のPatronus AIの組織のページ(照合のために確認):https://huggingface.co/PatronusAI
  • 土台モデル mmBERT-base のモデルカード:https://huggingface.co/jhu-clsp/mmBERT-base
  • Red Hatの組織の下の複製:https://huggingface.co/RedHatAI/wolf-defender-prompt-injection
  • Apache Camelの文書(Wolf Defenderを使う公式の部品):https://camel.apache.org/components/next/others/semantic-wolf-defender.html
  • Hugging Faceのpickle形式に関する文書:https://huggingface.co/docs/hub/security-pickle
  • OWASP 生成AIの10大リスク・プロンプトインジェクション:https://genai.owasp.org/llmrisk/llm01-prompt-injection/

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

AIの導入・活用、何から始めるべきかお悩みですか?

デボノはアカウント開設・初期設定など「そもそものAI導入」から社内定着まで伴走支援。マーケティング活用など一歩進んだご相談にも対応します。

運営会社:株式会社デボノ

目次