プロンプトインジェクションとは？社内のAI活用で起きる被害と具体例

プロンプトインジェクションとは、AIへの入力やAIが読む文書によって、AIの動きや出力を提供者の意図しない形に変えてしまう攻撃や脆弱性のことです。社内で起きる被害は、情報の流出、誤った要約や判断、AIにつないだ道具の不正な操作の3つ⁠に分かれます。

今日は、社内で使っているAIごとに「読めるもの」「読ませる社外の文書」「実行できる操作」⁠の3つ⁠を書き出してください。この3列⁠が埋まると、自社でどの被害が起こり得るかが見えてきます。

直接型と間接型の違い

国際的なセキュリティコミュニティOWASPのLLM01:2025は、この問題を入力がLLM（大規模言語モデル）⁠の動作や出力を意図しない形で変える脆弱性と説明しています。人の目に見えなくても、モデルが読み取る内容なら影響し得るとしています。

総務省の会議に提出された資料は、これを2つ⁠に分けています。

中小企業が見落としやすいのは間接型です。AIに話しかける人に悪意がなくても起きるからです。社員は普通に「このメールを要約して」⁠と頼んだだけで、不正な内容はAIが読んだ文書のほうに入っています。

OWASPは、意図せず起きる場合もあると書いています。わざと攻撃された場合だけの話ではありません。

この記事では悪用の手順には触れません。社内で確かめるために必要なのは、指示の書き方ではなく、被害の形だからです。

社内のAIで起きる被害は3つ⁠の形に分かれる

情報の流出：読めるものが多いほど広がる

AIが読める情報は、AIから出ていく可能性がある情報でもあります。総務省の会議資料は、本来は開示しない参照データの内容を回答に含ませる攻撃や、AIに設定された非公開の指示を引き出す攻撃を挙げています。

たとえば、全社の共有フォルダをそのまま読み込ませた社内チャットボットを作った場合を考えます。給与表や取引先別の単価が混ざっていれば、攻撃がなくても権限のない社員が質問で引き出せる形になりかねません。プロンプトインジェクションの対策以前に、読ませる範囲の問題として先に片付きます。

公開サイトのチャットボットでは、入力する側が社外の人になります。OWASPの例には、問い合わせ用チャットボットで指示を無視させ、非公開データの検索やメール送信に至る筋書きがあります。製品情報の案内だけなら、AIから社内の顧客データや受注データへの道を作らないのが基本の守りです。

誤った要約と判断：気づきにくい

被害が目に見えにくいのがこの形です。OWASPは、知識ベースの文書を書き換えられると、AIが誤解を招く結果を返す例や、応募書類に細工をしてAIの評価を変える例を挙げています。

総務省の会議資料には、2025年⁠に判明した実例として、論文速報サイトの論文に査読用AI向けの隠れた命令文が仕込まれていた件が載っています。読み手のAIだけに向けて好意的な評価を求めるものでした。

製造業なら、たとえば仕入先の見積書や仕様書のPDFをAIに読ませ、比較表を作る場面が当てはまります。AIが読む文書に、人が気づかない形で内容を偏らせる記述が入っていれば、比較結果が変わる可能性があります。実際にどれだけ起きているかを示す統計は確かめられませんでしたが、発注先の選定のように結果の影響が大きい作業では、元の文書と照合する手順を残しておきます。

つないだ道具の操作：影響が最も大きくなる

AIがメールを送れる、ファイルを更新できる、社内システムを呼び出せる。こうなると話が変わります。英国の国家サイバーセキュリティセンターNCSCの解説は、AIの出力をもとに道具やAPIを呼び出すシステムでは、影響がその道具を攻撃者が直接使えた場合の最悪の事態にまで広がると説明しています。

実際に公表された例が、Microsoft 365 Copilotの脆弱性CVE-2025-32711、通称EchoLeakです。総務省の会議資料によると、細工したメールを送るだけで、利用者の操作なしに機密情報を流出させられる脆弱性でした。Microsoftの更新ガイド⁠は影響を情報漏えい、最大深刻度を緊急としたうえで、利用者が取る対応はないとしています。

広く使われる製品の、すでに対応された例です。製品を避ける理由というより、メールと社内ファイルの両方を読むAIで何が起こり得るかを示す例として見るとよいと思います。

自社にどの形が当てはまるかは、次の表で見当をつけられます。

なぜ、完全に防げないのか

一般的なソフトウェアの脆弱性のように、修正すれば終わりとはいかない部分があります。NCSCは、LLMの内部にはデータと指示の区別がないと説明し、この攻撃は完全には軽減できないかもしれないと書いています。OWASPも確実な予防法があるかは不明としています。IPAの情報セキュリティ10大脅威 2026 解説書も、間接型について技術的対策で完璧なものは知られていないとしています。

ここから導かれる現実的な考え方は、「入らせない」⁠だ⁠け⁠に頼らず、「入っても被害が小さい」⁠形⁠を作ることです。NCSCは、製品や機器だけでは完全に軽減できない残存リスクとして、設計と運用で管理するよう求めています。特定の言い回しを禁止語として止める方法は、言い換えが無数にあるため頼りすぎないよう注意を促しています。

被害を小さくするために決めること

OWASPとNCSCが示す対策のうち、専門家がいない会社でも導入時に決められるものは5つです。

3つ目の考え方は、NCSCの説明が分かりやすいと思います。誰か外部の人から来たメールをAIが処理するときは、AIの権限もその相手の水準まで下げて考える、というものです。知らない相手に基幹システムの操作権限を渡さないのと同じ理屈です。

AIチャットボットを業者に頼むなら、見積の前に次のことを聞いてください。

• AIが読めるデータの範囲はどこまでか。利用者ごとの権限は反映されるか
• メール送信やデータ更新の機能はあるか。人の承認を挟めるか
• 外部から届いた文書やWebページを読むときの扱いはどうなるか
• 入力と操作のログを会社側で確認できるか
• 問題が見つかったときの連絡と停止の手順はどうなるか

答えが「対策済みです」だけなら、残るリスクと、起きたときに何が見えるかを聞き直します。NCSCの説明どおりなら、リスクがゼロになるとは言えないからです。

製品で補う場合は、守る場所で種類が変わります。AIの入出力を検査するものはAIセキュリティ製品の比較、機密情報の外部送信を見張るものはDLPの製品比較、ブラウザ上の操作を管理するものはセキュアブラウザの比較で見られます。どれも、権限を絞る設計の代わりにはなりません。

社員に伝えることは短くてよい

現場へ専門用語を説明する必要はありません。次の3つ⁠で足ります。

• AIの要約は、社外から届いた文書の内容に影響されることがある
• 発注、支払い、採用、取引先への回答に使う内容は、元の文書で確かめる
• AIが普段と違う案内をしたり、身に覚えのない送信をしたりしたら、すぐ担当者へ連絡する

この話を、社内のAI利用全体のなかで位置づけたい場合は、AIセキュリティの3つ⁠の対象の整理⁠が先に読めます。そもそも会社が把握していないAIには権限の確認ができないので、シャドーAIの進め方⁠も同時に進めると効率的です。関連する記事はAIのセキュリティのカテゴリ⁠にまとめています。