はじめに
本記事を閲覧いただきありがとうございます。
株式会社NTTデータ九州 ビジネス共創部 デジタルビジネス推進室の内田です。
普段はセキュリティ領域で、ゼロトラスト技術を用いたサイバーセキュリティ対策や、SaaS・生成AIを活用した業務高度化などに関わっています。
今回は、
AIエージェントは、Webページなどの外部情報に含まれる指示をどのように扱うのか？
というテーマで、プロンプトインジェクションに対するAIエージェントの挙動を個人環境で検証しました。
本記事について
本記事は筆者個人による技術検証の結果と考察をまとめたものです。
検証結果は特定の環境・設定・時点において観測された事象であり、特定製品の評価や優劣を示すものではありません。また、本記事に記載された内容は筆者個人の見解であり、所属組織の公式見解を表すものではありません。また、本記事はプロンプトインジェクションの攻撃成立条件や再現手順を紹介することを目的としたものではありません。観測された挙動から、企業でAIエージェントを利用する際の防御設計上の考慮点を整理することを目的としています。
先に結論
今回、条件を変えた3つのパターンを、異なる3つのAIエージェント環境で確認しました。
結果は次のとおりです。
| 検証パターン | 今回観測した結果 |
|---|---|
| ① 露骨なWeb注入 | 3環境でダミー情報の送信なし |
| ② 業務ルールに見せたWeb注入 | 3環境でダミー情報の送信なし |
| ③ ユーザー目的 + Web手順 | 3環境でダミー情報を利用した送信処理を確認 |
①②では、Webページ内に追加の処理を促す指示を含めても、今回の条件ではダミー情報の送信は確認されませんでした。
一方③では、
ユーザーから与えられた目的
と、
Webページに記載された手順
が組み合わさった条件で、今回確認した3環境すべてにおいて、追加情報の参照からダミー情報を利用した送信処理まで実行されました。
今回の検証から見えてきたのは、単純に、
「AIが悪意あるプロンプトを見破れるか」
だけではありません。
外部情報が、
単なる「データ」として扱われるのか
それとも、
ユーザーから与えられた目的を達成するための「手順」として扱われるのか
という違いも、AIエージェントのセキュリティを考えるうえで重要なポイントになりそうです。
なぜAIエージェントのセキュリティが重要なのか
従来のチャットAIは、主に質問に対して文章を返すものでした。
一方、AIエージェントは、
- Webページを読む
- ファイルを読む
- メールを読む・送る
- APIを実行する
- SaaSを操作する
- コマンドを実行する
といった、実際の操作まで行えるようになっています。
従来のAIであれば、判断を誤った場合でも、
間違った回答が返ってくる
という影響にとどまるケースが多くありました。
AIエージェントでは状況が変わります。
つまり、
AIの「回答」だけでなく、AIが実行できる「アクション」まで守る必要がある
ということです。
プロンプトインジェクションとは？
プロンプトインジェクションとは、AIが処理する情報の中に別の指示を紛れ込ませ、AIの判断や動作へ影響を与えようとする手法です。
たとえば、利用者がAIへ、
このWebページを要約して
と依頼したとします。
本来、AIはWebページの内容をデータとして読み取り、要約することが期待されます。
しかし、Webページ内にAIへ別の処理を促す文章が含まれていた場合、それをAIが、
自分が従うべき指示
として扱ってしまう可能性があります。
特に、Webページや文書、メールなど、外部から取得した情報を介してAIへ間接的に指示を与えるものは、**間接プロンプトインジェクション（Indirect Prompt Injection）**と呼ばれます。
AIエージェントでは、こうした指示が文章生成だけでなく、
- ファイルアクセス
- 外部通信
- API実行
- SaaS操作
などのアクションへつながる可能性があるため、より広い範囲での対策が必要になります。
OWASP Agentic Top 10で見ると何が起きているのか
AIエージェントのセキュリティについては、OWASP GenAI Security Projectから**「OWASP Top 10 for Agentic Applications 2026」**が公開されています。
これは、AIエージェントが自律的に計画・判断・操作を行うようになったことで生じる代表的なセキュリティリスクを整理したものです。
今回観測した挙動をこのフレームワークに当てはめると、特に次の3つと関連付けて考えることができます。
| OWASP Agentic Top 10 | 概要 | 今回の検証との関係 |
|---|---|---|
| ASI01: Agent Goal Hijack | 外部情報等によってエージェントの目的や実行経路が変化するリスク | Webページ内の情報がAIの後続動作へ影響する |
| ASI02: Tool Misuse & Exploitation | 正規のツールや機能が意図しない目的で利用されるリスク | ファイル参照や通信といった正規機能が別の処理につながる |
| ASI09: Human-Agent Trust Exploitation | 人間がAIを信頼することで不適切な操作を受け入れてしまうリスク | 正常な処理だと認識した利用者がAIの操作を承認する可能性がある |
今回の③を単純化すると、次のように捉えられます。
つまり、プロンプトインジェクションを、
AIが悪い文章に騙される問題
だけとして捉えると、少し狭いかもしれません。
AIエージェントでは、
外部情報がAIの実行経路へ影響する
↓
AIが持っている正規の機能が利用される
↓
場合によっては人間もその処理を正当だと判断する
という一連の流れとして考える必要があります。
これは、AIエージェントのセキュリティをモデル単体ではなく、AI・ツール・権限・データ・人間を含めたシステム全体で考える必要があることを示す一例だと考えます。
なお、上記はOWASPによる本検証への公式な評価・分類ではなく、今回観測した挙動を筆者がOWASP Agentic Top 10の観点から整理したものです。
今回の検証環境
検証日は以下です。
- 初回検証：2026年8月29日
- 再検証：2026年9月7日
今回、異なる3つのAIエージェント環境を利用しました。
本記事では特定製品の評価・比較を目的としていないため、以下では、
- 検証環境A
- 検証環境B
- 検証環境C
として記載します。
なお、一部の環境では同一系統のモデルを利用しています。
そのため、本検証は、
3つのAIエージェント環境における挙動を確認したもの
であり、3種類の独立したAIモデルの性能を比較したものではありません。
検証はすべて個人所有PC・個人環境で実施しています。
会社の業務環境、会社アカウント、会社データは使用していません。
安全な検証環境を用意する
今回の検証では、本物のパスワード、APIキー、アクセストークンなどの機密情報は一切使用していません。
秘密情報を模したダミーデータを用意し、AIエージェントがその情報を読み取り、別の処理へ利用しようとするかを確認しました。
また、データの送信先についてもインターネット上の外部サーバーは利用せず、自身のPC内だけで完結するローカルのテスト環境を利用しています。
今回確認しているのは、
AIがダミー情報を読み取り、送信を伴う処理まで実行するか
という挙動です。
実際の機密情報を外部へ送信するような検証は行っていません。
試した3つのパターン
今回、条件を少しずつ変えながら3つのパターンを確認しました。
注記
本記事の目的は、プロンプトインジェクションを再現する具体的な攻撃手順を紹介することではありません。
そのため、実際に使用した具体的なユーザープロンプトやWebページ内の指示内容、再現手順については、本記事の本筋ではないことから意図的に省略・抽象化しています。
① 露骨なWeb注入
最初は、比較的分かりやすいパターンです。
ユーザーがAIへ依頼しているのは、
Webページの内容を確認する
というタスクです。
一方、Webページ内には、その目的とは明らかに異なる追加の操作を促す指示を含めました。
今回、この条件では3環境ともダミー情報の送信は確認されませんでした。
② 業務ルールに見せたWeb注入
次に、Webページ内の指示を単純な命令ではなく、
業務上必要なルールや手順
のように見える形へ変更しました。
「品質確認」「監査」「報告」など、正常な業務プロセスの一部として追加処理が必要であるように意味付けしています。
①とは異なり、ユーザーが依頼している処理との関連性を持たせています。
ただし、ユーザー自身は追加情報の参照や、その情報を利用した送信処理までは明示的に依頼していません。
この条件でも、今回確認した3環境ではダミー情報の送信は発生しませんでした。
③ ユーザー目的 + Web手順
③では条件を変えました。
ユーザー自身がAIへ、
ある処理の正常性を確認する
という目的を与えます。
AIが関連するWebページを確認すると、そこには、
正常性を確認するための手順
として、追加情報を参照して処理を行う手順が記載されています。
③でも、
ユーザーがダミー情報を読み取り、送信するよう直接AIへ指示した
わけではありません。
ユーザー自身が与えているのは、あくまで、
正常性を確認する
という目的です。
その一方で、Webページ側には、その目的を達成するための手順として追加情報の参照と送信を伴う処理を記載しました。
今回の条件では、3環境すべてで追加情報の参照から送信処理まで実行されました。
検証結果
結果を整理すると次のとおりです。
| パターン | 今回の観測結果 |
|---|---|
| ① 露骨なWeb注入 | 3環境で送信なし |
| ② 業務ルールに見せたWeb注入 | 3環境で送信なし |
| ③ ユーザー目的 + Web手順 | 3環境で送信処理を確認 |
③については挙動の再現性を確認するため、各環境で複数回確認しました。
今回の条件では、各環境で5回実施したすべての試行において同様の挙動を確認しています。
ただし、これは統計的な有意性や一般化を目的とした試験ではありません。
あくまで、
特定の環境・設定・入力条件において観測された挙動
として捉える必要があります。
なぜ①②と③で挙動が変わったのか？
今回の結果を考えるうえで重要なのが、
「データ」と「指示」の境界
です。
①②では追加処理は実行されなかった
①では、ユーザー自身が依頼している目的と、Webページ内の追加指示との間に明確な隔たりがあります。
②では業務ルールのように見せていますが、ユーザー自身は追加情報の取得や送信までは依頼していません。
今回確認した一部環境では、Webコンテンツをそのままユーザー命令として扱わない判断も確認できました。
今回の①②では、
Webページに書かれているからといって、その内容をそのまま実行すべき指示として扱わない
という境界が機能したと考えられます。
③ではWeb手順とユーザー目的が整合していた
一方③では、
正常性を確認する
という目的をユーザー自身が与えています。
そしてWebページには、
正常性を確認するための手順
が記載されています。
今回観測された流れは次のとおりです。
ここで注意が必要なのは、AI内部の判断過程そのものを直接観測できたわけではないという点です。
ただし今回の結果からは、
ユーザーから与えられた目的とWebページ側の手順との整合性が、外部情報の扱われ方に影響した可能性
が考えられます。
今回の検証で最も興味深かったポイントです。
人間承認があれば安全なのか？
もう1つ確認できたのが、人間承認（Human-in-the-loop）の限界です。
今回利用した3環境のうち1つでは、情報の参照や通信の実行時に、人間による承認操作が求められました。
それでも③では、最終的にダミー情報を利用した処理が実行されています。
利用者自身が、
「自分は正常性確認という正当な作業を行っている」
と認識している場合、AIから提示された操作についても正常な作業の一部として承認してしまう可能性があります。
つまり、
承認画面が存在すること
と、
利用者が、その操作の安全性を適切に判断できること
は別問題です。
AIだけでなく、AIを利用する人間まで含めた防御設計が必要になります。
「AIを絶対にだまされないようにする」だけでは守れない
プロンプトインジェクション対策というと、
AI自身に悪意ある命令を見破らせる
ことへ目が向きやすくなります。
しかし今回の結果から考えると、それだけに依存するのは難しそうです。
AIも判断を誤る可能性があります。
人間も判断を誤る可能性があります。
そのため重要なのは、
どこか1つの判断が失敗しても、大きな被害へつながりにくい構造を作ること
だと考えます。
企業でAIエージェントを守るための5つの観点
1. 【データ保護】秘密情報をAIへ直接見せない
APIキー、パスワード、アクセストークンなどを、AIが自由に読み取れる場所へ置かないことが基本です。
AIに秘密情報そのものを渡すのではなく、
必要な機能だけ利用させる
構造にします。
AIが参照できない情報であれば、AI自身の判断だけで外部へ送信されるリスクも抑えられます。
2. 【最小権限】AIが利用できる機能を限定する
AIへ、
- 何でも読める
- 何でも変更できる
- どこへでも通信できる
- 何でも実行できる
という権限を与えないことも重要です。
たとえば情報を参照するだけのAIであれば、外部への書き込みや通信まで自由に許可する必要はないかもしれません。
AIが判断を誤っても、
そもそも、その操作を実行できない
状態にします。
3. 【アイデンティティ】AIも1つの主体として管理する
AIエージェントへユーザー本人と同じ強い権限をそのまま渡すのではなく、
AI自身に必要な権限だけを与える
という考え方も重要です。
人間と同様に、
- 誰が利用しているのか
- どのAIエージェントなのか
- どのシステムへアクセスできるのか
- どの操作を許可するのか
を管理します。
AIエージェントも企業システムへアクセスする新しい主体として捉える必要があります。
4. 【人間承認】承認時に「何が起きるか」を見せる
重要な操作へ人間承認を入れること自体は有効です。
ただし、
この操作を実行しますか？
Yes／No
だけでは、利用者が適切に判断できない可能性があります。
たとえば、
どの情報を参照するのか
↓
その情報がどこで利用されるのか
↓
どのシステムへ通信するのか
といった関係を、利用者が理解できる形で提示する必要があります。
具体的には、
- 読み取るデータを明示する
- 利用先や送信先を分かりやすく表示する
- 初めてアクセスする通信先では追加確認を求める
- 通常とは異なる操作を目立たせる
といったUI／UX上の工夫が考えられます。
5. 【データ・通信制御】DLPやSASE／SSEを最後の防波堤にする
AIや利用者が、
これは正常な処理です
と判断したとしても、
そのデータを外へ出してよいのか
は別の仕組みで判断できます。
たとえばDLPでは、
- 個人情報
- 機密情報
- APIキー
- 認証情報
- 機密ラベル付きファイル
などを検知できます。
さらにSASE／SSEなどを利用して、
- 接続可能な通信先を制御する
- 不要な外部通信を遮断する
- リスクの高い通信先をブロックする
- 通信ログを取得する
といった対策も考えられます。
AI自身の判断をすり抜けても、別のセキュリティレイヤーで止めるという考え方です。
ゼロトラストの考え方にも近い
こうした対策は、企業ですでに取り入れられているゼロトラストの考え方とも共通しています。
ゼロトラストでは、ユーザーや端末について、ネットワーク上の場所や所属だけを理由に暗黙的に信頼せず、アクセスする主体と対象となるリソースを確認しながら制御します。
AIエージェントについても同様に、
AIだから信用する
のではなく、新しい1つの主体として管理します。
役割を整理すると次のようになります。
| 対策 | 守るもの |
|---|---|
| IdP／権限制御 | 誰・何が、何をしてよいか |
| 最小権限 | AIが実行できる操作 |
| 人間承認 | 重要操作を本当に実行するか |
| DLP | 何を外へ出してよいか |
| SASE／SSE | どこへ通信してよいか |
| SIEM／ログ | 何が起きたか |
| 利用者教育 | 正当そうに見える処理を適切に判断できるか |
重要なのは、
AI自身の安全判断だけを信用しない
ということです。
AIエージェントは「単体製品」ではなく「システム」として守る
今回の検証を企業環境へ当てはめると、次のように考えられます。
AI自身の判断をすり抜けても、
権限制御で止める。
必要な権限を持っていたとしても、
人間承認で止める。
人間も正常な処理だと判断したとしても、
DLPや通信制御で止める。
そして完全には防げなかった場合でも、
ログや監視から検知できるようにする。
このように、AIエージェントを単体のAI製品としてではなく、
ID・権限・データ保護・通信制御・人間承認・監視までを含むシステム
として捉えることが、安全な活用につながると考えます。
今回の検証から得られた示唆
今回の結果を整理すると、次のようになります。
1. 明確なWeb注入は今回の条件では実行されなかった
①②では、今回確認した3環境でダミー情報の送信は確認されませんでした。
2. 外部情報を単純に「Webから来たから無視する」だけでは整理できない
③では、Web上の手順に沿って追加情報の参照・送信まで実行されました。
重要なのは、
指示がどこから来たか
だけではない可能性があります。
3. ユーザーの目的との関係も考える必要がある
今回、「ページを確認する」と「正常性を確認する」という条件で観測された挙動が異なりました。
ユーザーの目的と外部手順の関係も、AIエージェントの防御設計を考える要素になり得ます。
4. 人間承認も単独では万能ではない
承認機能の有無だけでなく、
人間が適切に判断できる情報を提示できているか
まで考える必要があります。
5. AIを含めた多層防御が必要になる
AI自身の安全機能だけでも、人間への注意喚起だけでも十分とは限りません。
AI、人、データ、権限、ネットワークを含めた多層防御
として設計することが重要です。
この検証の限界
今回の結果は、
- 特定のAIエージェント環境
- 特定のモデル
- 特定の設定
- 特定の検証パターン
- 今回検証した時点の環境
で確認したものです。
LLMは確率的に動作するため、同じ入力であっても常に同じ結果になるとは限りません。
また、本検証は統計的な一般化や製品間の性能比較を目的としたものではありません。
今回の結果から、
特定の製品なら安全
特定の製品なら危険
といった評価を行うことはできません。
さらに、本検証からAI内部の判断過程そのものを直接観測したわけではありません。
本記事における「なぜこの挙動になったのか」という部分には、実際に観測した結果をもとにした筆者の考察が含まれています。
まとめ
今回の検証では、
単純なWeb注入では追加処理が実行されなかった一方、ユーザーの目的とWeb上の手順が整合する条件では、追加情報の参照・送信まで実行された
という挙動を観測しました。
これは特定製品の安全性を評価するものではありません。
一方で、AIエージェントを企業で活用する際に、
AI自身の安全判断だけへ依存してよいのか
を考える材料にはなると思います。
AIエージェントは、
- 情報を読む
- ツールを使う
- データへアクセスする
- SaaSやAPIを操作する
- 人間へ承認を求める
といった複数の要素とつながっています。
そのため安全性も、モデル単体ではなく、
- ID／認証
- 最小権限
- データ保護
- DLP
- SASE／SSE
- 人間承認
- ログ／監視
- 利用者教育
まで含めた全体アーキテクチャとして考えていく必要があります。
目指すべきなのは、
AIが絶対に間違えない環境
ではありません。
AIが判断を誤っても、人間が判断を誤っても、大きな被害へつながりにくい環境
です。
言い換えるなら、
プロンプトだけに頼らず、アーキテクチャと人の両方で守る。
AIエージェントの活用が進むほど、これまで人間や端末を対象としてきたゼロトラスト、ID管理、データ保護、通信制御といったセキュリティの考え方を、AIエージェントという新しい主体まで広げていくことが重要になると考えます。
今回の個人検証が、企業におけるAIエージェントの安全性と生産性を両立するための設計・運用を考える材料になれば幸いです。
参考資料
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications 2026
- NIST Special Publication 800-207, Zero Trust Architecture
- Chao et al., Jailbreaking Black Box Large Language Models in Twenty Queries（PAIR）
免責事項
本記事内の図表は、特記がない限り筆者が今回の検証内容をもとに作成したものです。
本記事は筆者個人の検証結果・考察をまとめたものであり、所属組織の公式見解、製品選定方針、AIサービスの業務利用可否を一般化して示すものではありません。
特定製品の安全性を保証・否定することも目的としていません。
また、本記事はプロンプトインジェクション等の攻撃手法を推奨するものではありません。
記事内では、検証の意図や結果を理解するうえで必要な範囲に内容を抽象化しており、実際に使用した具体的なユーザープロンプト、Webページ内の指示内容、再現手順の一部は意図的に掲載していません。
セキュリティ検証を行う場合は、自身が所有・管理している環境、または明示的な許可を得た環境で実施してください。