Part 1/4: AIエージェントのプロンプトインジェクション対策：OpenAIが明かす設計原則

 

はじめに：自律エージェントが直面する新たな脅威

大規模言語モデル（LLM）を基盤とするAIエージェントが、コード実行・ウェブ検索・メール送信・データベース操作といった現実世界のアクションを自律的にこなせるようになった今、セキュリティ上のリスクも急速に増大している。その中でも最も深刻な脅威の一つが「プロンプトインジェクション（Prompt Injection）」だ。

プロンプトインジェクションとは、攻撃者が悪意ある命令文をモデルへの入力に混入させ、開発者や利用者の意図を上書きする攻撃手法である。OWASP（Open Worldwide Application Security Project）は「OWASP Top 10 for LLM Applications」においてプロンプトインジェクションを第1位（LLM01）として掲げており、その危険性は業界全体で広く認識されている [Source: https://owasp.org/www-project-top-10-for-large-language-model-applications/]。

本シリーズ「Building Production-Grade AI Agents: Security, Architecture, and Runtime」の第1回では、OpenAIが公開した設計指針「Designing AI agents to resist prompt injection」を軸に、本番環境でAIエージェントを堅牢に構築するための基礎的な防御原則を解説する [Source: https://openai.com/index/designing-agents-to-resist-prompt-injection]。

直接インジェクションと間接インジェクション

プロンプトインジェクションには大きく2つの攻撃ベクターが存在する。直接インジェクションは、攻撃者がプロンプトに直接アクセスして命令を挿入するパターン（いわゆるジェイルブレイク）だ。一方、間接インジェクションは、エージェントが外部から取得したコンテンツ（ウェブページ・PDF・メール・ツール実行結果など）に埋め込まれた命令によって行動を乗っ取られるパターンであり、自律エージェントにとってより深刻な脅威となる。

2022年にPerez & Ribeiroが発表した論文「Ignore Previous Prompt: Attack Techniques For Language Models」はこの問題を体系的に論じた先駆的研究であり、LLMが外部コンテンツ中の命令を正規のシステム命令として実行してしまうメカニズムを実証した [Source: https://arxiv.org/abs/2211.09527]。エージェントが信頼できないデータソースを大量に処理するほど攻撃の表面積は拡大し、マルチステップのタスク実行においてはその危険性がさらに増す。

OpenAIが示す5つの設計原則

OpenAIの設計ガイドラインは、エージェントをプロンプトインジェクションから守るための実践的なフレームワークを提供している。

1. 信頼階層（Trust Hierarchy）の明示的な実装

エージェントが受け取る入力には、信頼度の異なる複数のソースが存在する。システムプロンプト（オペレーター） > ユーザーメッセージ > 環境から取得したコンテンツという優先順位を明示的に設計し、下位ソースが上位の命令を上書きしないよう徹底することが基本原則だ。このインストラクション階層はOpenAIのエージェント設計の核心をなしている。

2. 最小権限の原則（Minimal Footprint）

エージェントが保有するツールのスコープと権限は、現在のタスクに必要な最小限に抑えるべきだ。ウェブ検索タスクを実行するエージェントにメール送信やファイル削除の権限を与えるべきではない。攻撃者が悪意あるコンテンツを介してエージェントを操作した場合でも、権限が限定されていれば被害の「爆発半径（blast radius）」を最小化できる。

3. データとインストラクションの明確な分離

パイプラインのすべての段階において、モデルへの入力が「指示（instruction）」なのか「処理対象のデータ（data）」なのかを区別する設計が求められる。Microsoftのリサーチチームが提案した「スポットライティング（Spotlighting）」技術は、XMLタグや特殊デリミタを用いて信頼できる命令と取得データを構文的に区別させることで、モデルが環境コンテンツ内の命令を実行しにくくする手法として有望視されている [Source: https://arxiv.org/abs/2403.14720]。

4. 不可逆的アクションへの人間承認チェックポイント

ファイル削除・メール送信・外部APIへの書き込みなど、取り消しが困難なアクションを実行する前には、人間が内容を確認・承認するチェックポイントを設けることが推奨される。自律性と安全性のトレードオフを意識した設計判断であり、エージェントが意図せず重大な操作を実行するリスクを抑制する。

5. ログ・監査可能性の確保

エージェントが実行したすべてのツール呼び出しと判断プロセスは、詳細なログとして記録されるべきだ。インジェクション攻撃が成功した場合でも、事後的に根本原因を特定し迅速に対処するためには、監査トレイルが不可欠となる。

防御の現実的な限界

これらの原則を実装しても完全な防御は難しい。モデル自体がインストラクション階層を完全には学習しきれていないこと、自然言語の曖昧性がエッジケースを生み出すこと、マルチエージェント構成（エージェントが別のエージェントを呼び出す構成）ではトラスト境界がさらに複雑化することなど、未解決の問題が積み重なっている。OWASPは多層防御（Defense in Depth）を推奨しており、単一の対策に依存せず、モデルレベル・アーキテクチャレベル・インフラレベルの各層で防御を組み合わせることが重要だ。

次回予告

第2回では、プロダクショングレードAIエージェントのためのアーキテクチャパターン——オーケストレーター・エグゼキューターモデル、メモリ管理の設計、ツール境界の定義——を掘り下げる。今回解説したプロンプトインジェクション対策の設計原則は、適切なアーキテクチャ設計によって初めて実効性を持つ。その具体的な実装方針を次回で詳述する。