AIに社内文書やWebページを読ませて働かせる使い方が、すっかり日常になりました。
そこで避けて通れないのが、プロンプトインジェクションと呼ばれるリスクです。
名前だけならSQLインジェクションの親戚に思えますが、厄介さの質が少し違っています。
核心は AIにとって「命令」と「データ」の区別が構造的につかない という一点にあるのです。
プロンプトインジェクションとは何か
攻撃者が入力を通じて、開発者の与えた本来の指示を上書きしたり迂回させたりする攻撃を指します。
OWASP がまとめている大規模言語モデル向けのリスク一覧でも、LLM01 として先頭に置かれ続けています（LLM01:2025 Prompt Injection – OWASP Gen AI Security Project）。
厄介なのは、プレースホルダのように構文で無害化する決定打が今のところ無いという点でしょう。
直接型と間接型がある
直接型は、利用者が自分でチャット欄に「これまでの指示は無視して」と打ち込むタイプです。
一方の間接型は、AIが読み込んだWebページや文書、メール、チケットの側に指示が仕込まれている形になります。
業務利用で本当に怖いのは後者で、操作している本人に悪意がなくても成立してしまうのが厄介な点です。
たとえば要約させたページの中に、会話の内容を外部へ持ち出させるような文章が紛れ込んでいる、というのが典型例として挙げられています。
なぜ完全には防げないのか
モデルへ渡される入力は、最終的に1本の長いテキストへ連結されるのです。
システムプロンプトも、利用者の質問も、読み込ませた資料の中身も、同じ文字の並びとして届くわけです。
人間なら「これは資料の記述であって自分への命令ではない」と切り分けられます。
けれどモデルはその境界をデータ構造として持っていないため、命令のように見える文字列があれば拾ってしまう余地が残るのです。
現実的な守り方
前提として、入力側で止めきる発想から 被害の範囲を権限と出力で抑える発想 へ寄せるのが現実解になります。
- AIエージェントに渡すトークンやツールを、その作業に必要な最小限まで絞る
- 送信・削除・購入といった副作用のある操作は、実行前に人間の承認を挟む
- 外部から取り込んだ内容はあくまでデータとして扱い、そこに書かれた指示には従わせない
- モデルの出力を他システムへ流す前に、想定した形式かどうかを検証する
外部ツールとの接続を標準化する MCP のような仕組みを使う場合も、考え方は変わりません。
最後に
プロンプトインジェクションは、モデルが賢くなれば消える種類の問題ではありません。
命令とデータが同じ入り口から入ってくる以上、設計側で権限を絞り、危険な操作に人を挟むしかないのでしょう。
以上です。
コメントを残す