プロンプトインジェクションを前提にしたAI実行環境の考え方

外部から与えられたテキストでAIの振る舞いを乗っ取る攻撃、プロンプトインジェクション。その仕組みについては、姉妹サイトのプロンプトインジェクションとは？が基礎から解説しています。ここではその続きとして、注入されることを前提に、AIエージェントの実行環境をどう設計するかを扱います。

なぜ「防ぎきる」を前提にできないのか

エージェント型のAIは、人の指示以外にも大量のテキストを読みます。Webページ、ドキュメント、コードのコメント、ツールの出力。そのどれもが、エージェントへの「指示」を紛れ込ませる経路になり得ます。

モデル側の防御（指示と情報の区別、不審な指示の拒否）は年々向上していますが、入力経路の多様さを考えると、すべての注入を入口で見抜く前提には立てません。だとすれば設計の問いはこう変わります。「注入を防げるか」ではなく、「注入が成功したとき、何が起きるか」です。

AIによる機密情報の漏えいは「到達範囲」で決まる

外部入力に誘導された（乗っ取られた）エージェントができることは、その前のエージェントにできたことと同じです。攻撃者は新しい能力を得るのではなく、既存の能力と到達範囲を悪用します。

• エージェントが機密ファイルを読める環境なら、攻撃者も読める
• エージェントが外部へ通信できる環境なら、攻撃者は読んだものを送り出せる
• エージェントの行動が記録されない環境なら、何が起きたか後からも分からない

つまりプロンプトインジェクションの被害規模は、注入の巧妙さよりも実行環境の設計で決まります。

実行環境側の3つの設計

1. 触れられる範囲を、仕事に必要な分だけに絞る

エージェントには、その仕事に必要なファイル・ツールだけを渡します。社員のPCでエージェントを動かす構成がこの点で不利なのは、隣のリポジトリ、顧客データ、認証情報といったPC上のすべてが地続きになりやすいからです（AIコーディングエージェントを社員PCで動かすリスクと代替策）。仕事単位で区切られたワークスペースを用意し、その中だけで動かす構成なら、乗っ取られても触れられる範囲はその部屋の中に限られます（AIエージェント用ワークスペース設計）。

2. 機密と外部経路を、同じ環境に同居させない

注入による情報持ち出しが成立するには、「機密に触れられる」と「外部へ送れる」の両方が同じ環境に揃っている必要があります。どちらか一方を環境から取り除けば、注入による自動的な持ち出しは成立しにくくなります。

• 機密を扱う環境からは、外部への経路をなくす（ローカルLLMで完結させる）
• 外部と通信できる環境には、機密を置かない

「不審な送信を見抜いて止める」よりも、「送る経路がそもそもない」方が、判定の誤りが入り込む余地がありません。

3. 何が起きたかを、環境の側で記録する

注入が疑われたとき、「エージェントが何を読み、何を実行し、何を送ろうとしたか」を再構成できる記録が必要です。記録は乗っ取られたエージェント自身ではなく、環境の側で取る必要があります（AIエージェント実行環境の監査ログ）。

レイヤーを重ねる — 環境設計は万能ではない

実行環境の設計にも限界はあります。許可された範囲内での悪用（公認の宛先へ機密を混ぜて送る等）は環境設計だけでは止まりません。だから対策はレイヤーで重ねます。

それぞれ守備範囲が違うため、どれか1つで済ませるものではありません。

まとめ

• プロンプトインジェクションは入力経路が多様で、入口で防ぎきる前提に立てない
• 被害規模は注入の巧妙さではなく実行環境の設計で決まる
• 設計は3つ（触れる範囲の最小化・機密と外部経路の分離・環境側での記録）
• 環境設計にも限界がある。モデル・環境・ネットワーク出口のレイヤーを重ねる

「被害を限定する実行環境」を製品にするとどうなるか。その答えがHoko（矛）というAIエージェント実行アプライアンスで、機密ルームには外部への経路そのものがなく、すべての部屋の記録が箱の側に残ります。構成は2つのルームに示しました。