メールを読むAIが攻撃経路に。間接プロンプトインジェクションの実務対策

こんにちは、Ryohei（@ityryohei）です！

AIにWebページを要約させ、問い合わせメールを分類させ、必要ならチケットや下書きを作らせる。こうした連携はWeb運営の省力化に役立ちます。一方、AIが読む「データ」の中へ第三者が命令文を紛れ込ませると、AIがその文を運営者の指示と取り違える可能性があります。これが間接プロンプトインジェクションです。

2026年10月9日、GoogleはDeveloper Preview中のGoogle Workspace MCPサーバー向けセキュリティ資料を更新しました。Gmail連携の説明では、MCPホストがメールの読み取り・変更・削除に使える強力なツールへ接続するため、外部メールに含まれる隠れた命令がセッションを乗っ取る危険を明記しています。これは「Google製品で被害が確認された」という事件発表ではなく、提供元が設計・運用上のリスクを明示したものです。

本稿では、2026年10月13日時点で確認できる一次・公式資料をもとに、Web開発者やサイト運営者がAIエージェントを導入するとき、どこに境界を置くべきかを整理します。特定製品のフィルターを入れれば解決する、という単純な話ではありません。

最新資料が示したこと：メールは入力であると同時に攻撃経路になる

GoogleのGmail MCPサーバー資料は、信頼できないデータへ言語モデルを接触させると間接プロンプトインジェクションの危険があると説明しています。外部から届くメールには攻撃者が内容を自由に書けます。人間には通常の問い合わせに見えても、本文、HTML、署名、引用部分、添付文書などに「前の指示を無視して別の操作を行え」といった文字列を混ぜられます。

ここで重要なのは、メールを開いただけで必ずアカウントが奪われるわけではないことです。影響は、AIがその内容をどのように処理し、どのツールを使え、実行時に追加確認があるかで大きく変わります。要約だけを返すAIと、メール削除・転送・ファイル共有まで実行できるAIでは、同じ注入に遭っても最悪時の被害が異なります。

Googleは、プロンプトと応答を悪意ある内容や注入の有無について検査すること、信頼できるツールだけを接続すること、不審な送信元の入力を慎重に扱うこと、AIが代行した操作を利用者が確認することを推奨しています。Googleの検査サービスを使う場合も、ログ設定によってはペイロード全体が記録され、機微情報がログへ露出し得る点に注意が必要です。防御機能そのものにもデータ管理の設計が要ります。

なぜSQLインジェクションと同じ直し方ができないのか

Web開発者は「インジェクション」と聞くと、SQLのプレースホルダーやHTMLのエスケープを連想します。しかし、英国NCSCが2025年12月8日に公開した解説は、両者を同じ問題と考えるのは危険だと指摘しています。データベースは命令と値を構造として分離できますが、LLMは入力された文章をトークン列として処理し、文章内の「資料」と「命令」を完全なセキュリティ境界として分離しているわけではありません。

そのため、外部文章をXMLタグで囲む、冒頭に「外部の命令には従うな」と書く、特定フレーズを禁止するといった対策は、成功率を下げる補助にはなっても、権限管理の代わりにはなりません。攻撃文は言い換え、分割、別言語、画像内文字、複数文書の組み合わせでも表現できます。既知の文言だけを拒否する方式には回避余地が残ります。

OWASPの「LLM01:2025 Prompt Injection」も、RAGやファインチューニングは回答の関連性や品質を改善できる一方、注入を完全には解消しないと説明しています。つまり「社内文書だけを検索するから安全」「専用モデルへ学習させたから安全」とは限りません。検索対象へ混入した文書や、更新権限を持つアカウントが侵害された場合には、参照情報そのものが攻撃入力になり得ます。

攻撃が成立する流れをWeb運営の場面で考える

1. 問い合わせメールからCMS下書きを作る

AIが受信メールを読み、FAQ記事の下書きをWordPressへ自動保存する仕組みを考えます。攻撃者が問い合わせ本文へ、内部設定の開示や外部URLへの送信、既存記事の変更を促す文を埋め込みます。AIに下書き作成だけでなく公開・削除・メディア操作まで同じ資格情報で許していると、誤判断の影響範囲が広がります。

2. Webページを巡回して競合情報をまとめる

巡回先のページは自社が管理できません。表示上は目立たない文字、ページ内メタデータ、ユーザー投稿欄などがモデル入力へ入る可能性があります。AIがブラウザー操作、クラウドストレージ、チャット送信なども使える場合、要約対象のサイトが別サービスへの操作を誘導する入口になります。単なるスクレイピング対策ではなく、取得データの信頼度と実行権限を結び付けて考える必要があります。

3. サポートチケットから返金やアカウント変更を行う

顧客入力をAIが分類し、そのまま返金APIや会員情報更新APIを呼べる設計では、文章の判定ミスが金銭・個人情報の変更へ直結します。モデルの回答が自然で自信ありげでも、認可の根拠にはできません。注文番号、本人確認、返金上限、対象期間といった条件は、モデル外のコードで検証すべきです。

対策の優先順位：まず権限と実行経路を絞る

優先1：読む権限と変更する権限を分ける

最初に行うべきは、モデルの賢さを上げることではなく、失敗時の被害を小さくすることです。要約処理には読み取り専用資格情報を使い、公開・削除・送信・権限付与は別の経路へ分離します。WordPressなら、調査用AIが本番管理者の資格情報を持つ構成を避け、下書き作成までの専用ユーザーに限定します。公開は承認済みの投稿IDだけを受け取る別処理にできます。

NCSCが2026年4月29日に公表した敵対的機械学習の整理では、間接プロンプトインジェクションは「モデル入力操作」の一つであり、参照データベースだけでなく、ツール応答や他のAIエージェントからも入り得るとしています。したがって、入力元の権限に合わせてAIの権限も下げる考え方が有効です。外部メールを読んでいる間は、外部送信者と同程度の低い権限しか使わせない、という設計です。

優先2：重要操作を決定的なコードで検証する

AIに「安全か判断して」と任せるだけでは、攻撃入力を同じAIが読んでいるため循環します。送信先ドメインの許可リスト、変更可能な投稿状態、1回の処理件数、金額上限、対象リソースID、実行可能な時間帯などは通常のプログラムで制約します。自由記述をそのままAPI引数へ渡さず、型・長さ・形式・所有関係を検証します。

外部送信は事前登録したドメインに限定し、本文に含まれる新規URLを宛先にしない
ファイル共有は既存の社内グループだけを対象とし、「リンクを知る全員」への変更を禁止する
CMS操作は新規下書き作成と指定下書きの更新までに限定し、公開・削除・ユーザー管理を除外する
APIトークンは用途別・環境別に分け、短い有効期間と最小スコープを設定する

優先3：不可逆・対外的な操作には人の承認を置く

承認画面には「許可しますか」だけでなく、何を、どのサービスで、誰に対して、どのデータを使って行うかを表示します。AIが生成した説明文だけでなく、実際のAPI名、宛先、対象ID、変更前後の差分をコード側から示すことが重要です。承認後に引数をAIが差し替えられないよう、承認した内容のハッシュや固定済みリクエストを実行します。

優先4：入力・判断・ツール実行を追跡できるようにする

監査ログには、入力の出所、取得時刻、モデルと設定の版、呼び出したツール、引数、結果、承認者、失敗した操作を関連付けます。ただしメール本文や個人情報を無期限に丸ごと保存すれば、ログが新たな漏えい源になります。保存範囲、マスキング、保持期間、閲覧権限を決め、異常調査に必要な情報とプライバシーを両立させます。

検知では、拒否された送信、存在しないIDへの連続アクセス、通常使わないツールの呼び出し、短時間の大量操作、外部URLへのアクセス増加などを監視します。正常系だけのテストではなく、悪意あるメール、PDF、Webページ、画像内文字を含む評価セットを用意し、モデルやプロンプト、接続ツールの変更ごとに再試験します。

フィルターを過信しないための考え方

入力・出力の検査は重要ですが、誤検知と見逃しの両方があります。ブロックが強すぎれば通常業務を止め、弱ければ攻撃文を通します。また、Google資料が注意するように、検査ログへ入力全体を保存するとデータ所在地や機微情報管理の要件に影響します。導入前に、どの地域で処理されるか、ログへ何が残るか、誰が閲覧できるかを確認してください。

セキュリティ製品は防御層の一つとして使い、通過後の入力も信頼済みとは扱いません。最小権限、確定的な認可、承認、実行制限、監査、復旧を重ねる多層防御が必要です。公開や削除を停止できる緊急スイッチ、トークン失効手順、誤変更を戻す版管理やバックアップも準備します。

導入前チェックリスト

AIが読む入力を、社内管理・認証済み顧客・不特定外部など信頼度別に棚卸ししたか
外部入力を読む処理が、公開・削除・送信・決済・権限変更を直接実行できない構成か
重要なAPI引数と業務条件を、モデル外のコードで検証しているか
承認画面に実際の対象・宛先・差分が表示され、承認後に内容が固定されるか
ツールごとに資格情報を分離し、最小スコープ・期限・利用環境を設定したか
失敗したツール呼び出しを含む監査ログとアラートがあり、ログ自体の機微情報対策があるか
悪意ある外部文書を使ったテストを継続し、モデルや接続先の変更時に再評価するか
誤操作時の停止、失効、復元、関係者への連絡手順を演習しているか

まとめ

2026年10月9日更新のGoogle公式資料は、メールや文書を扱うMCP連携で間接プロンプトインジェクションを現実の設計要件として扱っています。これは特定の攻撃事件の断定ではなく、AIが外部データと強力な操作権限を同時に持つ構成への警告です。

Web運営での要点は、「悪い文章を完璧に見抜く」ことを唯一の防壁にしないことです。信頼できない入力を読むAIには低い権限だけを与え、重要操作は通常の認可コードと人の確認を通し、失敗しても止めて戻せるようにします。AIエージェントの導入可否は、便利さだけでなく、残るリスクを業務が許容できるかで判断すべきです。