AIへの不正指示の防御策をOSS「Open-Prompt-Injection」はどう評価するのか

「プロンプトインジェクションの対策をうたう製品がいくつもあるが、どれが本当に効くのか比べようがない」「区切り記号で囲む、注意書きを足す、といった工夫を社内で入れたが、それで十分なのか分からない」——AIを組み込んだ業務の仕組みを預かる、情報システム部門やセキュリティの担当者からよく上がる声です。防御策の良し悪しは、製品の説明や評判で決めたくなります。けれども本当は、防御策は、攻撃をどれだけ止めたかと、本来の業務の精度をどれだけ落としたかを、同じ条件で並べて初めて比べられるものです。この記事では、AIへの不正指示の攻撃と防御を共通の物差しで評価する研究用のOSS「Open-Prompt-Injection」について、確かめられる事実、元になった論文の結果の読み方、そして企業が防御策を選ぶときの観点を整理します。攻撃文の例や作り方、ツールを動かす手順は扱いません。

Open-Prompt-Injectionとは何か。2026年10月時点で確かめられる事実

Open-Prompt-Injection は、GitHub上で公開されているプロンプトインジェクションの攻撃と防御のためのツールキット（道具の一式）です。READMEによると、攻撃、防御、そして言語モデルを組み込んだアプリやAIエージェントを、実装し、評価し、拡張できることを目的にしています。リポジトリの説明文では、言語モデルに対するプロンプトインジェクションの攻撃と防御のベンチマーク（同じ条件で性能を比べるための試験の一式）と位置づけられています。

公開の時期と規模を押さえておきます。リポジトリが作られたのは2023年10月19日で、最後の更新は2026年9月27日です。2026年10月22日時点のスターはおよそ510、複製（フォーク）は82です。正式な配布版（リリース）は出ていません。ライセンスはMITで、OSI（オープンソースの定義を管理する団体）が承認したライセンスにあたるため、この記事では「OSS」と呼びます。

作者のアカウントは2018年に作られた個人のもので、所属は登録されていませんが、READMEは自らの研究グループの論文三本の引用を求めています。READMEが参照する講演資料は米デューク大学の研究者のサイトに置かれており、大学の研究室が論文とあわせて公開してきた研究用のコードと読めます。製品として保守されているものではない点は、後の見出しで改めて扱います。

プロンプトインジェクションとは。なぜ同じ物差しが求められたのか

プロンプトインジェクションとは、AIへの入力に指示を紛れ込ませ、AIの振る舞いを意図しない方向へ変えてしまう攻撃の総称です。とくに、AIが読み込むメールや文書、ウェブの頁などに指示が仕込まれている場合を間接プロンプトインジェクションと呼びます。OWASP（ウェブの安全性に関する国際的な非営利の団体）は、言語モデルを使う仕組みの主要な危険の一覧で、これを筆頭の項目に挙げています。

問題は、この攻撃への備えがこれまで、個別の事例の報告や、提供元ごとの独自の試験で語られがちだったことです。論文は、2023年当時の研究が主に事例の検討にとどまり、攻撃と防御を体系的に理解する土台が欠けていた、と指摘しています。ある防御策が効いたという報告があっても、どの攻撃に対して、どの言語モデルで、どの業務の場面で測ったのかがそろっていなければ、別の報告と比べることはできません。

企業の担当者にとっても事情は同じです。対策の製品を比べようとしても、各社が示す数値は条件が違い、並べて読むことが難しい場面が少なくありません。Open-Prompt-Injection は、攻撃と防御を同じ条件で並べるための共通の土台を研究者が公開したものです。この記事で注目したいのは、個々の数値よりも、この土台が採った測り方の組み立てです。

土台になった論文：攻撃と防御を形式化して比べる

READMEが引用を求める論文の一つ目は、「プロンプトインジェクションの攻撃と防御の形式化とベンチマーク」と題したものです。2023年10月に論文の公開頁へ初版が出され、2024年の USENIX（米国の計算機の学会）が開く安全性の国際会議に採録されたと記載されています。最新の改訂は2025年11月です。

論文の柱は二つあります。一つは、プロンプトインジェクションの攻撃を共通の枠組みで書き表すことです。論文は、それまでに知られていた攻撃がこの枠組みの特別な場合として説明できることを示し、既存の手口を組み合わせた新しい攻撃も設計しています。もう一つは、その枠組みのもとで、5種の攻撃と10種の防御を、10種の言語モデルと7種の業務の課題で体系的に評価したことです。

業務の課題には、文章の感情の分析、迷惑メッセージの判定、要約、文法の訂正、差別的な表現の判定、二つの文が同じ意味かの判定、文と文の論理関係の判定の7種が使われています。AIに本来やらせたい仕事（目的の課題）と、攻撃者がやらせたい別の仕事（注入された課題）を組み合わせて測る形です。攻撃の具体的な組み立ては防御の評価に不要なため、この記事では扱いません。

評価の物差し：攻撃の成功と業務の精度を分けて測る

Open-Prompt-Injection の物差しで企業がまず借りたいのは、攻撃が成功した度合いと、防御を入れたときの業務の精度を別々に測るという考え方です。論文は、いくつかの指標を0から1の値で定義しています。READMEの例でも、攻撃の成功の度合いを表す指標が評価の出力として示されています。

指標（論文の定義）	何を測るか	企業の評価での読み替え
攻撃がない時の精度（PNA）	攻撃のない入力で、本来の仕事をどれだけ正しくこなせるか	防御策を入れても普段の業務の品質が落ちないか
攻撃の成功の度合い（ASV）	攻撃を受けたとき、注入された別の仕事をAIがどれだけこなしてしまったか	紛れ込んだ指示にAIがどれだけ従ってしまうか
応答の一致率	攻撃を受けた応答が、注入された指示だけを与えた場合の応答とどれだけ一致したか	AIの出力が攻撃者の狙いどおりに染まった度合い
誤検知率	汚れていない入力を、誤って攻撃と判定した割合	普通の業務の文書を止めすぎないか
見逃し率	攻撃を含む入力を、見逃した割合	検知をすり抜けて処理に進む攻撃がどれだけあるか

この表が示すのは、防御策の評価は、少なくとも「止める力」と「業務への影響」の二本の軸で読む必要があるということです。止める力だけを見れば、何でも止める仕組みが最も優秀に見えます。業務への影響だけを見れば、何もしない仕組みが最も優秀に見えます。どちらか片方の数値だけを示す評価は、判断の材料として不十分だと考えてよいでしょう。

論文が示した結果：予防型の防御は十分ではなかった

論文は、10種の防御を、入力や指示の形を工夫して攻撃を効かなくする予防型5種と、汚れた入力を見つけて止める検知型5種に分けて評価しています。結果のまとめは、既存の予防型の防御はいずれも十分ではなかったというものです。それぞれが、攻撃をあまり止められないか、業務の精度を目立って落とすかのどちらかでした。

防御の種類（論文の分類）	論文の評価の要旨
予防型：入力を別の言い方に書き換える	一部の攻撃の成功を下げたが、本来の仕事の精度を平均で約0.14落とした
予防型：入力の区切り方を変える	攻撃を止める効果が乏しく、精度も平均で約0.06落とした
予防型：区切り記号で入力を囲む	精度を平均で約0.08落とした
予防型：入力の前後に指示を置き直す・注意書きを足す	平均の精度の低下は小さいが、要約など一部の課題では落ち込みがあった
検知型：文章の自然さで見分ける（全体・区間ごと）	攻撃を含んでも文章が自然なため、見逃しが多かった
検知型：言語モデルに汚れているかを尋ねる	見逃しはとても少ないが、誤検知がとても多かった
検知型：応答が期待した形かで見分ける	分類の課題では働くが、要約や同じ種類の課題では働かなかった
検知型：答えの分かっている確認で見分ける	既存の手法で最も効果的だったが、文法の訂正などで見逃しが多い場面があった

数値はすべて論文に著者が記載したもので、この記事では再現していません。注目したいのは、組み合わせた攻撃に対しては、予防型の防御を入れても攻撃の成功の度合いが高いままだったという記載です。社内でよく使われる「区切り記号で囲む」「注意書きを足す」といった工夫は、それだけで守りになるとは言えない、というのが論文の示唆です。

検知型の防御の結果：見逃しと誤検知のつり合い

検知型の防御は、汚れた入力をAIに渡す前に見つけて止めようとするものです。論文の結論は、こちらも既存の検知型の防御で完全に十分なものはなかったというものでした。結果を並べると、見逃しを減らすと誤検知が増え、誤検知を減らすと見逃しが増える、というつり合いの難しさが見えてきます。

たとえば、言語モデルに入力が汚れているかを直接尋ねる単純な検知は、見逃しがとても少ない一方で、普通の入力まで攻撃と判定する割合がとても高くなりました。論文は、言語モデルが慎重になりすぎることを理由に挙げています。誤検知が多すぎる仕組みは、現場の業務を止めてしまい、やがて外されて何も守らなくなるおそれがあります。

最も効果的だったのは、答えの分かっている確認用の問いを入力と一緒にAIに渡し、正しく答えられるかで入力の汚れを見分ける方法でした。誤検知が少なく、見逃しも平均では少なかったと記載されています。ただし文法の訂正などの課題では見逃しが多い場面があり、これも万能ではありません。企業が読み取るべきなのは、検知の仕組みは課題の種類によって得手不得手が大きく変わるという点です。

検知器DataSentinelと、位置を特定するPromptLocate

Open-Prompt-Injection には、論文で評価した既存の防御のほかに、同じ研究グループが後に提案した防御の部品も含まれています。一つは検知器の DataSentinel です。論文は2025年のIEEE（電気・電子の国際学会）が開く安全性とプライバシーの国際会議に採録されたと記載されています。論文の要旨によると、言語モデルを追加で学習させて汚れた入力の検知器とし、検知をすり抜けるよう工夫された攻撃も想定して学習の手順を組み立てた、とされています。

もう一つは PromptLocate で、2026年の同じ国際会議に採録予定と記載された論文に基づきます。こちらは攻撃を見つけるだけでなく、汚れた入力のどこに注入された指示があるかを特定するための部品です。論文の要旨は、その用途として、攻撃を受けた後の調査（フォレンジック）と、汚れた入力から元のデータを取り戻すことを挙げています。

READMEは、まず DataSentinel で入力が汚れているかを判定し、汚れていれば PromptLocate で位置を特定してデータを取り戻す、という二段の流れを防御の流れとして示しています。どちらも学習済みの重みを外部の共有ストレージから取得して使う作りで、READMEには、ほかの検知器や学習用のコードは今後公開予定と書かれています。論文の性能は著者の評価であり、第三者による再現は、この記事の確認の範囲では見つかっていません。

想定される使い方：防御策の選定と社内評価の場面

企業がこのOSSを直接動かすかどうかにかかわらず、使いどころは大きく三つ考えられます。一つ目は、防御策の製品や部品を選ぶときの評価の観点として使うことです。提供元の資料を読むとき、止める力と業務への影響の両方が示されているか、どの攻撃と課題で測ったのかが書かれているかを確かめる物差しになります。

二つ目は、社内で作ったAIの仕組みの評価です。READMEによると、別の防御や攻撃、課題を試すときは設定を差し替えて同じ流れで測れる作りで、論文の実験の組み合わせを一覧で定義し、途中で止まっても続きから再開できる仕組みも備えています。研究や評価の部門が、同じ条件のまま防御策だけを入れ替えて比べるための土台として使うことが想定されます。

三つ目は、社内の説明の材料です。区切り記号や注意書きだけで十分と考えている関係者に、予防型の工夫の限界を研究の結果で示すことができます。ただしここで示した使い方は、READMEと論文から読み取れる範囲の推測を含みます。製品の比較の公的な基準として作られたものではないため、結果をそのまま調達の合否の基準にするのは避けるのが無難です。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Open-Prompt-Injection の判定は「注意付き」です。主な根拠は、防御だけでなく攻撃の手法の実装も含むことです。攻撃と防御を同じ土台で比べるという目的上、避けられない構成ですが、扱う側には相応の管理が求められます。

一方で、精査の範囲では、公開済みのセキュリティ勧告はなく、取得や導入の際に自動で動く処理の記載も見つかりませんでした。ライセンスはMITで、2023年から論文とあわせて更新されてきた研究用のツールキットです。スターの伸びは1日あたり0.5前後で、不自然な急増は見られません。READMEは、国際会議に採録された論文三本を元にしたコードであることを示しています。

ただし、精査で問題が見つからなかったことは、安全の保証ではありません。研究用のコードは、製品のように安全性の確認や長期の保守を前提に作られているわけではありません。社内で動かす場合は、一般のソフトウェアと同じ取り込みの手順で確かめてください。

注意点の詳細：攻撃の実装と、外部への接続の前提

第一の注意点は、攻撃の実装を含むことです。社内で扱う場合は、誰が、どの目的で、どの環境で使うのかを決めてから取り込む必要があります。評価の部門の閉じた環境に置き、業務で動いているAIの仕組みや社外のサービスに向けて試さない、といった線引きが前提になります。

第二は、外部の言語モデルの利用が前提になっていることです。READMEの例は、提供元の言語モデルを鍵（認証の情報）を使って呼び出す作りで、鍵を設定の文書に書き込む形が示されています。社内で扱うなら、鍵を共有の場所に置かない、評価専用の鍵を発行して使い終えたら止める、といった管理が欠かせません。評価のために大量の問い合わせを流せば、利用料も発生します。

第三は、学習済みの重みの取得元です。DataSentinel と PromptLocate の重みは、READMEのリンクから外部の共有ストレージで配布されています。モデルの重みも、取り込む前に出どころと中身を確かめる対象と考えてください。また、正式な配布版が出ていないため、どの時点のコードで評価したかを社内で記録しておくことも大切です。

悪用されうるリスク

攻撃と防御を同じ土台に並べるツールには、二面性があります。守る側には、どの防御がどの条件で外れやすいかを知る手がかりになります。一方で、攻める側にとっても、どの防御を、どういう条件ですり抜けやすいかの参考になりうることは否定できません。ここで扱う攻撃は論文で公開済みのものですが、手口をまとめて試せる状態にあること自体が、悪用の手間を下げる可能性があります。

ただし、プロンプトインジェクションの手口そのものは、この論文の前から広く知られ、報告されてきました。Open-Prompt-Injection が新たな脅威を生んだというより、既存の手口と既存の防御を条件をそろえて比べた記録だと読むのが妥当と考えられます。研究の分野では、弱点を公開して比べることで、より強い防御の研究が進むという考え方が一般的です。

守る側が受け取るべき示唆は、広く使われている防御の工夫の弱点は、すでに外から調べられる状態にあるという前提に立つことです。区切り記号や注意書きだけに頼った守りは、手口を知る相手には通じにくいと考えておくべきでしょう。この記事では、すり抜けの具体的な方法には触れません。

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

Open-Prompt-Injection を社内で動かす場合も、その物差しを借りて製品を評価する場合も、確かめる順番を決めておくと抜けを防げます。次の順で進めるのが一つの目安です。

企業が取るべき対策

第一に、防御策を一つ入れて終わりにしないことです。論文の結果は、予防型も検知型も単独では十分でないことを示しています。区切り記号や注意書きは入れてもよいですが、それを理由に守りを完成とみなさないようにします。第二に、AIに渡す権限を最小にすることです。外部の文書を読ませる仕事と、社外へ送る・記録を書き換える仕事を、同じ権限でまとめて持たせないようにします。

第三に、取り返しのつかない操作の前に人の承認を挟むことです。OWASPも、プロンプトインジェクションへの備えとして権限の最小化と、危険の大きい操作での人の承認を挙げています。承認を求めるときは、AIに操作の根拠と、根拠になった情報の出どころを書かせると、紛れ込んだ指示に由来する操作かどうかを人が見分けやすくなります。

第四に、防御策の製品を調達するときは、止める力と業務への影響の両方の数値と、測った条件の開示を求めることです。第五に、攻撃を受けた後に備え、AIへの入力と出力の記録を残すことです。PromptLocate の論文が攻撃後の調査を用途に挙げているように、どの入力のどこに指示が紛れていたかを後から確かめられる記録は、被害の範囲を見極めるうえで欠かせません。

AIに判断させない範囲と、人が決める範囲

検知器も、守られる側のAIも、文章を見て判断する仕組みです。論文の結果が示すとおり、どちらも外れることがある以上、最終的な判断をAIに任せてはいけません。AIに任せてよいのは、怪しい入力を拾い上げる、操作の根拠を書き出す、評価の結果を集計する、といった人の判断を助ける部分までです。

人が決めるのは、どの操作をAIに許すか、どの操作の前に承認を挟むか、どの防御策をどの数値の条件で採用するか、どの頻度で評価し直すかです。人が確認する範囲を、導入の前に先に決めておくことで、運用が始まってから線を引き直す手間を減らせます。避けたい使い方を挙げます。

• 論文の表で成績のよかった防御策を、自社の課題で測らずにそのまま採用する
• 区切り記号や注意書きを入れたことを理由に、AIに社外への送信や支払いの権限まで渡す
• 攻撃の成功の度合いだけを見て、業務の精度や誤検知の割合を確かめない
• 攻撃の実装を含むツールを、目的や使う人を決めずに共有の環境へ置く
• 検知器が通した入力を、人が確かめずに重要な操作へそのまま流す

とくに二つ目は起きやすい失敗です。防御の工夫はすり抜けを前提にした守りの一枚であり、権限を広げてよい理由にはなりません。防御策の導入と権限の設計は、別々に決めるものだと考えてください。

よくある質問：論文の数値は今の製品にも当てはまるのか

そのまま当てはまるとは限りません。論文の評価で使われた言語モデルは2023年から2024年ごろの世代で、今の企業が使う言語モデルとは性能も振る舞いも違う可能性があります。防御策の製品も改良が続いています。数値は当時の条件での一つの測定として読み、今の自社の環境での結論は自社で確かめるのが現実的です。

では、論文を読む価値はどこにあるのか。それは、止める力と業務への影響を分けて測る、攻撃の種類と業務の課題を組み合わせて測る、検知は課題ごとに得手不得手があると見る、という評価の組み立てにあります。この組み立ては、言語モデルの世代が変わっても、自社の評価にそのまま持ち込めます。

もう一つ、「このツールを社内で動かすべきか」という問いもありそうです。評価の部門があり、閉じた環境と鍵の管理を用意できるなら選択肢になります。そうでなければ、物差しだけを借りて提供元の資料を読み解くだけでも十分に役立ちます。このラインでは実行しておらず、動作や結果の再現は確かめていません。

• Open-Prompt-Injection の内容は、GitHubのリポジトリ（README・ライセンス文書）を2026年10月22日に確かめた範囲に基づきます。版の更新で内容は変わる可能性があります
• 評価の指標・防御の分類・結果は、論文の公開頁と本文を同日に確かめた範囲です。数値は著者の記載で、この記事では再現していません
• DataSentinel と PromptLocate の性能、第三者による再現、作者の現在の所属は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。攻撃文の例や作り方、ツールの実行の手順は扱いません

まとめ

Open-Prompt-Injection は、プロンプトインジェクションの攻撃と防御を同じ条件で実装・評価するための、MITライセンスの研究用のOSSです。元になった論文は、10種の防御を10種の言語モデルと7種の課題で評価し、予防型も検知型も単独では十分でないことを示しました。後に加わった DataSentinel と PromptLocate は、検知と位置の特定という防御の部品を提供しています。攻撃の実装も含むため、扱いには管理が要ります。

企業にとっての教訓は、特定の防御策の優劣ではありません。防御策は止める力と業務への影響の両方で評価し、権限の最小化と取り返しのつかない操作の前の人の承認を先に整えること。そのうえで、防御の工夫を重ね、最終の判断は人が持つことが、この研究の結果との現実的な付き合い方です。

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