Askhub
資料請求 お問い合わせ
お問い合わせ

用語解説

プロンプトインジェクションとは？防げない前提の対策と確認8項目

「読ませなければ安全」ではない

「取引先から届く請求書のPDFやメールを、AIに読ませて大丈夫か」
経理やカスタマーサポートの業務をAIに任せようとすると、情シスからまず聞かれる問いです。

プロンプトインジェクションとは、AIが読む文章に紛れ込ませた指示で、AIの動きを乗っ取る攻撃です。
メール、PDF、Excel、Webページ、社内文書。AIが読むもののすべてが入り口になります。

そして、この攻撃は、いまのところ完全には防げません。
国際的なセキュリティ団体のOWASPも、英国の国家サイバーセキュリティセンター（NCSC）も、OpenAIやMicrosoftも、そう認めています。

だから「怪しいものは読ませない」と考えたくなります。
でも、私たちはそうは考えていません。
読ませること自体は、やめなくてかまいません。

危なさを左右するのは、「読むかどうか」より「読んだAIが何をできるか」だからです。
入り込まれても被害が限られるよう、AIが書き込む・実行する・外へ送る範囲を絞っておく。そうすれば、メールやPDFを扱う業務もAIに任せられます。

まずは、なぜ防ぎきれないのかから考えます。

AIには、文章と指示の区別がない

プロンプトインジェクションには、2つの型があります。
直接型は、利用者が入力欄に「これまでの指示を無視して」などと打ち込むもの。
間接型は、AIが読み込むメールや添付ファイルに仕込まれた指示に、AIが従ってしまうものです。

業務でAIを使う会社にとって本題になるのは、間接型です。
攻撃者は、社内のシステムに入る必要がありません。AIが読みそうな場所に、文章を置けば足ります。
取引先を装ったメール。請求書のPDFの白い文字。Excelの隠しシート。Webページの見えない段落。

言語モデルにとっては、システムの指示も、利用者の依頼も、読み込んだメールの本文も、同じ文字の並びです。
NCSCは2025年12月のブログ記事で、ここを指摘しています。SQLインジェクションなら、データと命令を分けて渡せば根本から防げます。プロンプトインジェクションには、その解決策がありません。
NCSCが目標に置くのは、「起きにくくし、起きたときの影響を小さくする」ことです。
OWASPのLLMアプリ向けリスク一覧（2026年8月公開）も、指示の工夫やフィルターだけではリスクを確実には消せないとしています。

社内で「この製品を入れれば防げますか」と聞かれたら、こう答えるのが正確です。
「防ぎきる製品はない。被害を限る設計と組み合わせる」。

これは、机上の話ではありません。

メール1通で、情報は持ち出されうる

間接型の攻撃が成り立つことは、大手のAI製品でも、研究者によって示されています。

一番分かりやすいのは、2025年6月に公表されたMicrosoft 365 Copilotの事例（EchoLeak）です。
入り口は、外部から届いたメール1通。利用者は普通の質問をしただけで、クリックもしていません。それでも、社内の情報が外部へ持ち出されうることが示されました。Microsoftが修正済みで、悪用は確認されていません。

2025年5月には、GitHubにつないだAIエージェントで、公開の場に書かれた課題1件をきっかけに、AIが非公開の内容を公開の場に書き出す例も示されました。2025年2月には、要約を頼んだ文書の隠し指示で、Geminiの長期記憶に偽の情報が保存される例も公表されています。

どれも、攻撃者はAIに直接話しかけていません。
AIが仕事として読むものに、指示を置いただけです。
そして被害の大きさを分けたのは、AIが何を読め、どこへ書き出せたかでした。

攻撃の量はどうでしょうか。
Googleは2026年4月、公開Webに仕込まれた指示を調べた結果を公表しました。大半はいたずらや検索対策でした。
ただ、悪意あるものは、2025年11月から2026年2月にかけて相対で32%増えていました。
Googleは、手口はまだ稚拙だが、規模も巧妙さも増すと見ています。
いまのうちに被害を限る設計を入れておけば、手口が巧妙になっても、任せた業務は続けられます。

危なさは「読んだ後に何ができるか」で決まる

社内のデータに触れず、外へ何も送れないAIが、要約して人に見せるだけ。それなら、被害は要約がゆがむ程度にとどまります。
社内データも読め、外へ送る手段も持つAIなら、持ち出しの経路になりえます。

この組み合わせを分かりやすく整理したのが、開発者のSimon Willison氏が2025年6月に示した「致命的な三要素」です。
私的なデータに触れられる。信頼できない内容を読む。外へ送れる。
3つが1つの仕事にそろうと、仕込まれた指示で私的データを外へ持ち出されうる、という見方です。

そろう仕事では、どれか1つを外します。
外せないなら、書き込みと送信を定めた操作と宛先に限り、その外側に人の確認を挟みます。

業務に当てはめてみます。
カスタマーサポートで、問い合わせメールを読んで種類を分け、担当窓口に振り分ける。外へは送らず、社内の振り分けだけにすれば、すぐ任せやすい仕事です。
経理で、請求書PDFを読み取り、入金と照合して消し込む。これは、業務操作で縛れば任せられます。業務操作とは、あらかじめ定めた業務の単位の操作のことです。書き込みは「入金を消し込む」だけにし、前提条件（入金と請求書の取引先が一致する、など）で確かめます。
問い合わせへの回答メールを送る。取引先台帳の振込先を変える。外への送信や重要な項目の変更には、人の承認を残します。

読ませること自体は続けてかまいません。
そのかわり、読む仕事と書く・送る仕事の組み合わせを、仕事ごとに決めておきます。

ただ、読む経路は、外から届くものだけではありません。

共有データも、次の入り口になる

AIが後から参照するものも、入り口になります。社内検索の文書。会話の記憶。複数のAIが読み書きする共有の台帳。

たとえば、取引先からのメールを読んだAIが、取引先台帳の「振込先」欄に偽の口座を書き込んだとします（説明のための想定です）。
支払いを準備する別のAIや担当者は、それを正しいものとして使います。
共有データへの書き込みが、そのまま次の読む経路になるわけです。

OWASPも、このリスクを挙げています。会話の要約、長期記憶、検索用の索引に入った偽の情報が、後の判断や操作をゆがめる。協力する別のAIにも広がる。
仕込みから被害までに時間が空くので、原因も辿りにくくなります。

だから、振込先のような重要な項目は、AIが自由に書き換えられないようにしておきます。
変更には承認と履歴を残す。AI自身の出力を、確かめずに信頼できるデータへ戻さない。

入り口は多く、防ぎきれない。
では、どう備えればよいでしょうか。

入りにくくし、入られても被害を限る

Microsoft（2025年7月）やGoogle（2025年6月）は、いくつもの対策を重ねる多層防御を公表しています。外部の文章に印を付けて指示と区別する。仕込みらしさを別のAIで検知する。危険な操作の前に利用者に確かめる。

ただ、検知役のAIにも、すり抜けはあります。
Anthropicは2025年11月、ブラウザを操作するAIへの攻撃の成功率を約1%まで下げたとしています。それでも、解決済みではないとしています。OpenAIも2025年12月、完全な解決はなさそうだと述べています。

だから効いてくるのが、利用する会社の側の備えです。
NCSCも、信頼できない内容を処理するAIに強い権限のツールを持たせないこと、操作の制限にはAIの判断を挟まない決まった仕組みを使うことを勧めています。

私たちは、利用する会社が打てる手を6つの層で考えています。
入りにくくする側に2つ。信頼できない入力の扱いと、記憶と共有データの管理です。
入られても被害を限る側に4つ。権限の最小化。書き込みの制限。実行の隔離と通信先の制限。人の確認と監視。

読む経路と、書く・実行する・送る経路 · 6つの層の置き場所
層1・2はモデルに入る前、層3〜5はモデルが何かをする前に置きます。層6はすべての経路にかかります。どの層にも限界があるので、他の層のすり抜けを拾うように重ねます。

推進者が業務の設計に組み込んでおきたいのは、後ろの4つです。
乗っ取りを見抜けなかった場合でも効くからです。統制を置く場所の選び方はAIエージェントの権限設計で整理しています。

中でも、台帳や基幹に書き込む業務で一番効くのは、書き込みの制限だと考えています。

書き込みは、業務操作で縛る

AIの権限を、「請求書を更新できる」のようなツールの単位では許しません。
「入金を消し込む」のような業務操作の単位で許します。
許すかどうかは、AIの外側のシステムが、実行のたびに判定します（詳しくはAIエージェントの権限設計）。

プロンプトインジェクションの側から見ると、こうなります。
「振込先を書き換えて」という仕込みがあっても、その業務操作が定義されていなければ実行できません。
定義された操作でも、前提条件を満たさなければ効果は確定しません。
差額が大きいときなどは、人の承認を通らなければ確定しません。
実行は記録に残り、間違えたときは取り消しの操作で戻せます。

乗っ取られたときに届く範囲 · 汎用のツール権限と業務操作の比較
図の右側のAIも、仕込みを見抜けるとは限りません。それでも、書き込みの届く範囲は、定義された業務操作の内側に縮みます。だから、残るリスクを操作ごとに洗い出して手当てできます。

AIへの指示に「この操作はしないで」と書くだけでは、乗っ取られたときに破られます。
OWASPも、許すかどうかをAIに判断させず、AIの外の仕組みで決めるよう勧めています。
なお、書き込みの制限は、読んだ情報の持ち出しまでは止めません。三要素をそろえないことと、通信先の制限を組み合わせます。

ただ、業務操作で縛っても、まだ余地は残ります。
定義された操作を、偏った入力で「正しく」実行させられることです。
偽の支払案内に「この入金は請求書B分です」と書かれていて、本来は請求書Aに充てるべき入金をBに消し込んでしまう。そんな場合です。

これは、3つで拾います。
前提条件で、金額・取引先・状態が矛盾しないかを、文書の主張ではなく台帳や基幹の値で確かめる。
照合で、振込名義や銀行の明細など、外部の文書とは別の出所と突き合わせる。
承認で、差額や金額が一定を超えるものを人が確かめる。そのとき、AIの説明と並べて、根拠の元データも見られるようにしておきます。

承認を形だけにしない工夫は、AIエージェントの承認はどの粒度で？承認疲れと自動承認ルールで扱います。

書き込みの次に考えたいのは、実行です。

AIが書いたプログラムは、切り離して動かす

AIに表計算やデータの加工を任せると、AIが書いたプログラムを動かす場面が出てきます。
仕込まれた指示は、ここで「実行される命令」に変わります。

OWASPも、AIの出力を確かめずに実行するリスクを挙げています。勧めているのは、管理者権限を持たない隔離環境と、作業ごとの分離です。

だから、AIが書いたプログラムは、社内ネットワークや業務サーバーから切り離した使い捨ての環境で動かします。外への通信先を絞り、鍵（認証情報）はAIの見える場所に置きません。
これは主に基盤の側の仕事です。推進者は「そうなっているか」を確かめれば十分です。
鍵の扱いはAIエージェントは誰の権限で動くのかで扱います。

最後に、任せる範囲を広げたときの抜け道を見ておきます。

自動承認ルールを、抜け道にしない

AIに任せる範囲を広げると、自動承認ルールが要るようになります。「この条件なら人の承認なしで確定してよい」という決まりです。
攻撃者から見ると、これは「人の目を通らない通り道」でもあります。
条件に収まるよう操作を小分けにする。少しずつ緩い承認へ寄せる。そんな突かれ方が考えられます。

基本は、ルールを決めることも、判定することも、AIに任せないことです。
条件は、金額や取引先などに対する決まった式で書き、システムが判定する。
AIは候補を出すだけで、確定するのは人。確定した人と時期を記録する。
件数や合計金額に上限を置き、過去の傾向から外れた実行は強調して人に見せる。
いつでも止められ、止めれば以後は人の承認に戻る。

ここまでを、自社の現状に当てはめてみます。

まず確かめる8つのこと

最初の2つ、読ませるものの棚卸しと三要素から始めると、自社の弱いところが早く見えます。

  1. AIに何を読ませているかを棚卸しする：業務ごとに、社外から来るもの（メール、添付、Web、共有文書）を一覧にする
  2. 致命的な三要素がそろっていないか：私的データ・信頼できない内容・外への送信を、同じ仕事で同時に持っていないか
  3. 書き込みは定めた業務操作を通るか：汎用の更新権限をAIに渡していないか。許可の判定がAIの外にあるか
  4. 重要な項目をAIが自由に書き換えられないか：振込先、金額、取引先などの変更に承認と履歴があるか
  5. AIが書いたプログラムは切り離した環境で動くか：外への通信先をどう決めているか
  6. 鍵をAIが読める場所に置いていないか：指示文、プログラム、設定ファイルに鍵がないか
  7. 人の確認はどこに入り、何を見て判断するか：承認画面に根拠の元データが出るか。自動承認ルールを誰が確定し、止められるか
  8. 記録と定期的な試験：読んだもの、呼んだ操作、拒否された操作が記録されるか。仕込み入りの文書で試したか

拒否された操作は、攻撃の兆候になりえます。記録して監視します（AIエージェントの監視と停止）。

運用に残る判断もあります。
業務操作と前提条件の定義。定義が甘ければ、その範囲が乗っ取られたときの被害範囲になります。
どの仕事で三要素をどう外し、通信をどこまで許すか。業務の価値とリスクを比べて、人が決めます。
公表される新しい手口も、定期的に見直します。
どこまでをシステムが持ち、何が運用に残るかは、AIエージェントの責任は誰が負う？システムと運用の責任分界で整理しています。

導入がスムーズに進みやすいAIの選び方

次の基準を満たすAIの作りなら、情シスへの説明が短く済み、導入がスムーズに進みやすくなります。

  • 書き込みが業務操作の単位で決まり、許可の判定がAIの外にある
  • 仕事ごとに、読めるデータ・使えるツール・送れる先を絞れる
  • AIが書いたプログラムは切り離した環境で動き、鍵がAIに見えない
  • 重要な変更や外への送信に人の承認を挟め、記録が残る

情シスに説明するときの要点

  • プロンプトインジェクションは完全には防げない前提で、乗っ取られても被害が限られる設計にしています
  • 同じ仕事で「社内データ・社外の内容・外への送信」の3つをそろえません
  • AIの書き込みは定義した業務操作だけで、許すかどうかはAIの外のシステムが判定します
  • 振込先の変更や外部への送信など重要な操作は、人が根拠の元データを見て承認します
  • 読んだもの・実行した操作・拒否された操作は記録に残り、異常に気づけます

被害を限れば、任せる範囲は広げられる

AIが読むものに紛れた指示は、完全には防げません。
それでも、読ませることをやめる必要はありません。

危なさを決めるのは、読んだAIが何をできるかです。
社内データ・社外の内容・外への送信を、同じ仕事でそろえない。書き込みは業務操作で縛り、範囲内の悪用は前提条件・照合・承認で拾う。自動承認ルールは決まった式で判定し、人が確定し、いつでも止められるようにする。

始めるのは、問い合わせの振り分けのような、外へ送らない仕事からで十分です。
次に、請求書の消し込みのような、業務操作で縛れる仕事へ。
被害の届く範囲さえ設計しておけば、AIに任せる範囲は、段階的に広げていけます。
私たちは、そう確信しています。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

本文の「隔離」と「鍵の置き場所」を、Askhubは作りの前提にしています。AIが乗っ取られても、届く範囲と持ち出せるものを小さくするためです。AIが書いたプログラムは、Askhub本体と切り離した使い捨ての実行環境で動くので、本体の権限や他のお客様のデータには届きません。外部サービスの鍵はAIの環境に置かず、AIには代わりの文字列だけを渡します。Claude Codeのような外部のAIエージェントも隔離の中で動かし、社内データには必ずAskhubの権限と承認を通して触れさせます。国内リージョン限定やPマーク準拠などの構成を選べば、AIのプログラムから外への通信も遮断でき、利便性とセキュリティの兼ね合いを構成で選べます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：AIエージェント、外部ツール連携

用語解説の記事をもっと見る