AIを業務に組み込むとき、まず検討されがちなのが、悪い命令には従わないようAIに言い聞かせる方法です。システムへの指示文に、怪しい命令は無視するよう書いておく。これ自体は無駄ではありません。しかし、それだけを頼りに安全を保とうとすると、いずれ破られる場合があります。攻撃者は言い回しを変えて繰り返し試してくるためです。

そこで発想を切り替えます。AIが決してだまされないようにするのではなく、だまされても被害が出ない状態にしておく。この記事は、そのための設計思想と、具体的な守りの重ね方をまとめる柱です。個別の対策記事を、一枚の設計図の上に並べ直します。モデルが賢くなるほど攻撃も巧妙になり、防ぎきることに賭ける構えは崩れやすくなります。破られる前提で、破られても重要なものに手が届かないようにしておく設計が、最も崩れにくい構えになります。

前提：プロンプトだけで守るのは不十分

最初にはっきりさせておきたいのが、指示文(プロンプト)だけの守りには限界がある、という点です。

AIは、渡された文章について、これは資料・これは命令という区別を確実にはつけられません。そのため、怪しい命令に従わないよう書いても、資料の中に巧妙に紛れた命令をうっかり実行してしまう場合があります。指示文の工夫はあくまで補助であり、本命は、AIのプログラムやインフラの側でシステムとして制御することです。

実際に、RAGに1件のレビューを仕込むだけで会員の個人情報が漏れた検証では、モデルの賢さは問題ではありませんでした。問題は、信頼できないデータ・不要な個人情報・強すぎる権限が、同じ処理の流れに乗っていたこと。設計の問題でした。

設計思想：多層防御という考え方

守り方の背骨になるのが、多層防御です。

一枚の壁だけに頼ると、そこが破られた瞬間にすべてが抜けます。そうではなく、性質の違う守りを何枚も重ねる。一枚目をすり抜けても二枚目で止まり、二枚目も抜けたら三枚目で止まる。どこか一つが完璧である必要はなく、すべてが同時に破られなければ、重要なものは守られる。この重ねる発想が、AIセキュリティでは特に効きます。

AIへの攻撃は防ぎきることが難しいからこそ、防ぐことに全体重を預けず、通り抜けられても被害が出ない構えを層で作ります。以下では、その層を具体的に見ていきます。

層その1：入力・出力・ツール実行にガードレールを置く

一つ目の層が、AIとのやり取りの要所に検問所を置くガードレールです。置く場所は3か所あります。

  • 入力の検問：AIに渡す前に、外部データや利用者の入力をチェックする。乗っ取りに使われやすい言い回しや、明らかに不自然なパターンを弾く。RAGなら、取り込むデータの段階で検査するのがここにあたります。
  • 出力の検問：AIが出した結果を、実行する前にチェックする。宛先が許可リストにない、個人情報が混じっている、見知らぬ外部URLが入っている、といった場合に止める。
  • ツール実行の検問：AIが機能を使おうとした瞬間に、その操作が許されているかを確かめる。外部送信や削除は、条件を満たさなければ実行させない。

検問は、自前でルールを書いて用意することも、判定用の別のAIやガードレール向けのツールを挟むこともできます。ただし、検問だけでは怪しいものをすべて捕まえきれるわけではありません。そのため、これは一枚目として置き、次の層と重ねます。

層その2：ツールごとにロールを分け、最小権限にする

二つ目の層が、AIに渡す権限そのものを絞ることです。

そのAIの業務に本当に必要な機能だけを渡し、余計な強い機能は持たせない。これが最小権限の考え方です。さらに、機能(ツール)ごとに役割を分け、検索する係・答えをまとめる係・送信する係を別々に扱う。送信する係には送信の権限しか与えず、しかも送信先を許可リストで限定します。

こうしておくと、検問(層その1)をすり抜けた命令が届いても、AIには実行できる権限がありません。全会員の情報を外部へ送れと命じられても、任意の宛先へ送る権限を持っていなければ送りようがない。検問が漏らしても権限が止める。ここが層の重なりです。片方だけでは、そこが破られたときに止められません。検問はすり抜けられることがあり、権限設計にも設定ミスが起こり得るため、両方を重ね、同時に破られないかぎり被害を止める構えにします。

層その3：渡す情報を最小化し、インフラで通信を絞る

三つ目の層は、守るべきものをその場に置かないことと、いちばん外側の壁です。

一つは、AIに見せる情報の最小化です。回答に必要のない個人情報や機密は、最初からAIの文脈に入れない。渡していない情報は、だまされても漏れようがありません。どのデータをどの信頼度で扱うかは、信頼できないデータを分けて扱う話とセットで考えます。

もう一つが、インフラ側の通信制限です。サーバーそのものを、許可した相手としか通信できない状態にしておく。外へ出る通信も、外から入る通信も、決めた範囲だけを許可し、それ以外は遮断する。加えて、何を検索し・どこへ送ったかを記録(ログ・監査)しておけば、万一のときに何が起きたかを後から追えます。アプリの層をすべてすり抜けても、この一番外の壁で通信そのものが止まる、最後の砦です。

層を重ねると、こう守られる

ここまでの層を、検証の事故に当てはめます。攻撃者がレビューに隠し命令を仕込んでも、次のように止まりやすくなります。

  • 層1(入力の検問)で、怪しい投稿を取り込み段階で保留できていれば、そこで止まる。
  • すり抜けても、渡す情報を最小化(層3)していれば、そもそもAIの手元に個人情報がない。
  • それでも情報があり命令が届いても、送信権限が絞られていれば(層2)、外へ送れない。
  • 送ろうとしても、インフラの通信制限(層3)で、許可外の宛先へは届かない。

どこか一つが完璧でなくても、すべてが同時に破られないかぎり、情報は外へ出にくくなります。これが、だまされても被害が出ない構えの実体です。AI開発でつまずきやすい点のまとめはAIで作ったアプリのセキュリティの落とし穴もあわせてご覧ください。

導入前の点検リスト

いま動かしている、あるいはこれから構築するAIについて、層ごとに確認してください。

  1. 入力：外部データや利用者入力を、AIに渡す前に検査する仕組みがあるか。
  2. 出力：AIの結果を実行する前に、宛先や中身をチェックしているか。
  3. ツール：機能ごとに役割を分け、それぞれ最小権限になっているか。
  4. 情報：回答に不要な個人情報や機密を、AIに渡していないか。
  5. インフラ：通信できる相手を絞り、何をしたかを記録できているか。
  6. 前提：プロンプトの指示文だけに、守りを頼っていないか。

1つの層だけに丸をつけて安心しないこと。複数の層に丸がつくほど、崩れにくくなります。

まとめ

  • プロンプトの指示文だけでAIを守るのは不十分。破られる前提で、システム側で制御する。
  • 設計思想は多層防御。性質の違う守りを重ね、すべてが同時に破られないかぎり被害を止める。
  • 層1はガードレール(入力・出力・ツール実行の検問)。層2はツールごとのロール分けと最小権限。層3は情報の最小化とインフラの通信制限・監査。
  • 各層は単独では穴があるが、重ねると、どこか一つは止める状態になる。
  • 目指すのは、だまされないではなく、だまされても重要なものに手が届かない構え。

AIを安全に業務へ入れる鍵は、モデルの賢さより、この設計を組めるかどうかにあります。だまされないことに賭けるのではなく、だまされても重要なものに手が届かない構えを、層で作っておくことが要になります。