プロンプトインジェクション対策は、AIがだまされる前提で、AIの権限と外部から入る文章の扱いを先に決めることです。悪い入力を見つける仕組みも使いますが、それだけでは足りません。
今日やることは、動いている、または入れる予定のAIについて、次の4つを1枚に書き出すことです。
- 読めるデータ（社内文書、メール、顧客情報など）
- 受け取る外部の文章（Webページ、届いたメール、添付ファイルなど）
- 実行できる操作（メール送信、登録、削除など）
- 外へ情報を送れる経路（URLの読み込み、外部サービスとの連携など）
この記事は公開情報を整理したもので、私たちが各製品を検証したものではありません。AIの守り全体はAIセキュリティのカテゴリから見られます。
なぜ入力の検査だけでは足りない？
総務省のAIのセキュリティ確保のための技術的対策に係るガイドラインは、細工した入力で不正な出力を誘う攻撃を2つに分けています。利用者が直接入力する直接型と、AIに細工したデータを参照させる間接型です。間接型の例には、Web上のファイルと電子メールが挙がっています。
社員に悪意がなくても、AIが外の文章を読むだけで間接型の入口になります。ここが会社の導入で見落としやすいところです。
入力の検査が決め手にならない理由は、AIの仕組みにあります。英国NCSCの解説によると、大規模言語モデルの内部には「データ」と「指示」の区別がありません。NCSCはこの攻撃を残存リスクとし、製品や機器で完全には緩和できないので、設計と運用で管理するよう述べています。
OWASPのLLM01:2025も、確実に防ぐ方法があるかは不明としたうえで、影響を抑える策を挙げています。OpenAIも、ChatGPTのLockdown Modeについて、データの持ち出しのリスクを下げるが、すべての攻撃を防ぐものではないと説明しています。
製品の説明の読み方
NCSCは、プロンプトインジェクションを「止められる」とうたうものには注意し、どう減らすのかを理解している製品を見るよう書いています。「ignore previous instructions」のような語を弾く方法にも、言い換えが無数にあるとして注意を促しています。
自社のAIはどの形？
確認の深さは、AIのつなぎ方で変わります。
| 使い方 |
外部の文章 |
主に確かめること |
| 画面に打って答えを読むだけ |
貼り付けたものだけ |
回答を確かめる運用 |
| 社内文書を検索して答える |
文書に混ざる可能性 |
利用者ごとの閲覧権限 |
| メールやWebを読んで要約する |
日常的に入る |
読めるデータと送信の経路 |
| 送信や登録まで実行する |
日常的に入る |
操作の権限と人の承認 |
下の段ほど、だまされた時の影響が大きくなります。NCSCは、AIがツールやAPIを呼ぶ場合の影響を、攻撃者にそのツールを直接渡した場合の最悪の結果と同じだと考えるよう説明しています。
広く使われる製品でも、この種の欠陥は登録されています。2025年6月に公開されたCVE-2025-32711は、Microsoft 365 CopilotのAIコマンドインジェクションによる情報の開示として記録されています。使っているAI製品も、ほかのソフトと同じように更新情報を追う対象に入れます。
AIをつなぐ前に確かめる7項目
1. AIのIDと権限は分かれているか
OWASPは、アプリに専用のAPIトークンを持たせ、機能の実行はモデルに任せずプログラム側で扱い、権限を最小限にするよう挙げています。担当者のIDをそのまま使わせると、その人が触れるものすべてが影響の範囲になります。
2. 外部の文章を読むときに権限が下がるか
NCSCは、ある相手から来た情報を処理するときは、AIの権限をその相手と同じ水準まで下げるという考え方を紹介しています。誰からでも届くメールを読むAIには、強い権限を持つツールを使わせないという形です。読む役と実行する役を分ける設計も、ここで検討します。
3. 外へ情報が出る経路はどこか
OWASPは、要約を頼まれたAIが、隠れた指示に従って外部URLへ会話の内容を流す例を挙げています。回答の中のリンクや画像の自動読み込み、外部サービスへの送信を一覧にし、不要なものを切ります。
4. 取り消せない操作に人の承認があるか
権限の強い操作には人の確認を入れるよう、OWASPも挙げています。送金、外部へのメール送信、データの削除、権限の変更から始めます。承認の増やしすぎの問題はAIエージェントの権限を決める記事で扱います。
5. 判定をAIの外に置いているか
NCSCは、AI以外の決まった仕組みで動作を制限する守りに重点を置くよう述べています。AIへの「秘密を出さないで」という指示に頼らず、送信先の許可リストや、権限のチェックをプログラム側に置きます。
6. 何を読み、何を実行したか記録が残るか
変な動きに気づいても、AIが読んだ文章と実行した操作が残っていなければ原因を追えません。誰の依頼で動いたかも一緒に記録します。
7. AI機能を試験の対象にしているか
OWASPは、モデルを信頼できない利用者として扱い、侵入テストなどを定期的に行うよう挙げています。外部に頼むなら、脆弱性診断サービスの比較を見て、AI機能が診断の範囲に入るかを見積もりの前に確かめます。
製造業の場合はどこから見る？
たとえば、問い合わせフォームの文面をAIが読み、過去の見積もりデータを引いて、返信の案を作る仕組みを考えます。この形には、誰でも書ける外部の文章、取引先ごとの単価という機密、メールという送信経路の3つがそろっています。
確認の順番は次のようになります。
- フォームの文面を読むAIには、公開カタログの範囲だけを見せる
- 単価を引く処理は、担当者が案件を開いた後に、担当者の権限で動かす
- 返信は下書きで止め、送信は担当者が押す
- 送信先は問い合わせの差出人に限るよう、プログラム側で固定する
便利さは少し落ちますが、AIがだまされても、単価の一覧が外へ出る経路を減らせます。設備の制御や生産計画につなぐ話が出たら、同じ確認を、より強い権限を扱う案件として行います。
ベンダーには何を聞く？
AIの組み込みを外部に頼むなら、次の質問を見積もりの段階で渡します。
- AIはどのIDで動き、そのIDは何に触れますか
- 外部の文章を読むとき、権限はどう変わりますか
- 人の承認が入る操作はどれですか。設定で変えられますか
- 読んだ内容と実行した操作は、どこに何日残りますか
- AI機能を対象にした試験を行いましたか。残ったリスクは何ですか
総務省のガイドラインはAI開発者とAI提供者向けで、対策としてガードレールによる検証や、RAGなどの権限管理を挙げています。発注側の読み物ではありませんが、ベンダーの説明を聞くときの言葉合わせに使えます。AIエージェントはこのガイドラインの対象外なので、その部分は別に確かめます。
入出力を監視する製品を検討するなら、AIセキュリティ製品の比較で扱う範囲の違いを見ます。社員がブラウザから使うAIへの入力を抑えたい場合は、セキュアブラウザの比較も見ておきます。どちらも権限の設計の代わりにはなりません。
残ったリスクをどう判断する？
7項目を通しても、リスクはゼロになりません。NCSCは、残るリスクを許容できないシステムなら、そもそも大規模言語モデルの用途として向いていない可能性があると述べています。
判断するのは技術担当だけではありません。「だまされたら最悪こうなる。そのとき、誰がどう止めるか」を1行で書き、経営側が受け入れられるかを決めます。受け入れられないなら、AIの出番を下書きまでに戻します。
AIのリスクは入力だけの話ではありません。誤情報や権利まで含めた全体は生成AIのリスクを社長が確かめる7点に、社員が外部のAIへ入れる情報の話は図面や現場写真の判断基準にまとめています。
