Microsoft Defender for Office 365のプロンプトインジェクション対策｜影響と管理者対応

Microsoft Defender for Office 365に、受信メールへ埋め込まれたプロンプトインジェクションを配信前に検知し、隔離する保護機能が追加されました。対象となるDefender for Office 365 Plan 1／Plan 2ではPublic Previewとして提供され、原則として管理者による有効化や新しいポリシーの作成は不要です。

ただし、「自動で有効になるから対応不要」という意味ではありません。検出されたメールは既存の「高確度フィッシング」として扱われるため、検疫件数、監視クエリ、SIEM連携、誤検知時のリリース手順に影響します。特にMicrosoft 365 Copilotや、Exchange Onlineのメールを読み取るAIエージェントを利用している組織は、検出状況と運用手順を早めに確認すべきです。(TECHCOMMUNITY.MICROSOFT.COM)

日本時間2026年7月9日時点で確認できるMicrosoft公式情報では、Tech Communityの「Defending the Inbox Against Prompt Injection Attacks」とMicrosoft Learnの関連ページは、いずれも2026年7月8日付で公開・更新されています。本記事では、その公式情報を基に、保護対象、管理者設定、監査・検知への影響、優先すべき対応を整理します。(TECHCOMMUNITY.MICROSOFT.COM)

Microsoft Defender for Office 365のメール経由プロンプトインジェクション対策とは

今回追加されたのは、メールを読む人ではなく、メールを処理するAIを狙った悪意ある命令を検出する機能です。

攻撃者はメール本文などに、次のような命令を埋め込む可能性があります。

以前の指示を無視するようAIに要求する
メールを安全だと説明させる
会話やメールボックス内の情報を外部へ送信させる
接続されたツールを実行させる
後続の要約や判断に誤った情報を混入させる

ユーザーがMicrosoft 365 Copilotに未読メールの要約を依頼したり、AIエージェントが受信メールを自動分類したりすると、AIはメール内の文字列を入力データとして読み込みます。その中に攻撃者の命令が含まれていると、本来の利用者の指示よりも攻撃者の命令を優先してしまう可能性があります。

Defender for Office 365は、このようなメールをメールフローの段階で調べ、メールボックスやAIアシスタントへ届く前に検知します。(Microsoft Learn)

項目	公式情報の要点	管理者への影響
提供状態	Public Preview	表示名や挙動が変更される可能性を考慮する
適用対象	Defender for Office 365 Plan 1／Plan 2、Microsoft Defender XDR	対象メールボックスのライセンスを確認する
対象方向	受信メール	組織内メールや送信メールまで保護されるとは限らない
検出タイミング	メールフロー上の配信前	AIがメールを読む前に遮断できる
検出後の判定	高確度フィッシング	既存の検疫・フィッシング対応運用に入る
新しい識別値	Prompt injection protection	ExplorerやAdvanced Huntingで抽出できる
管理者による有効化	原則不要	設定作業より監視・運用確認を優先する

従来のフィッシングと何が違うのか

一般的なフィッシングは、人間にリンクをクリックさせたり、添付ファイルを開かせたりする攻撃です。一方、プロンプトインジェクションは、メールを読み取るAIモデルに命令を実行させようとします。

比較項目	従来のフィッシング	メール経由のプロンプトインジェクション
主な標的	メールを読む人	メールを処理するAI
成功条件	人がリンクを開く、返信する、認証情報を入力する	AIが埋め込まれた命令に従う
主なペイロード	URL、添付ファイル、偽のログイン画面	AIへの自然言語命令
隠し方	なりすまし、緊急性、偽サイト	不可視文字、HTML、引用文、エンコード
想定される被害	認証情報窃取、マルウェア感染	情報漏えい、誤分類、不正なツール実行、誤った要約

重要なのは、人がメールを怪しいと思うかどうかだけでは防げない点です。画面上では空白に見える文字や、通常は読まれないHTMLの要素も、AIが処理するデータには残っている場合があります。(Microsoft Learn)

どのようなメール内容が検査されるのか

Microsoftの説明では、Defender for Office 365は目に見える本文だけでなく、AIアシスタントが受け取るメッセージ全体を想定して分析します。

明示されている分析対象は次のとおりです。

件名
メール本文
HTMLマークアップやスタイル
白地に白文字などの不可視テキスト
サイズゼロや画面外に配置された文字列
引用された返信
転送された会話履歴
エンコードされた文字列
難読化された文字列

検出では、MicrosoftのLLMによる分類と、送信者情報やメッセージ評価などDefenderが持つ既存のシグナルが組み合わされます。単純に「Ignore previous instructions」という文字列があるかどうかだけを調べるキーワードフィルターではありません。(Microsoft Learn)

添付ファイルの保護範囲は断定しすぎない

Microsoft Learnは、プロンプトインジェクションが埋め込まれる場所として、ドキュメント、PDF、画像、メタデータなどの添付・埋め込みコンテンツも挙げています。

一方、検出処理の分析対象として具体的に列挙されているのは、件名、本文、HTML、不可視テキスト、引用・転送部分、エンコード・難読化部分です。公開情報だけでは、すべての添付形式や画像内の命令まで同じ精度で検出されるとは断定できません。(Microsoft Learn)

そのため、今回の機能を導入済みでも、Safe Attachments、Safe Links、マルウェア対策、AI側の入力フィルタリングを省略すべきではありません。

保護される範囲と保護されない範囲

今回の機能は、メール経由のプロンプトインジェクションに対する「入口側」の防御です。

対象	今回の機能による保護
外部から届く受信メール	主な保護対象
メール本文の不可視命令	検出対象として明示
引用・転送された会話内の命令	検出対象として明示
難読化・エンコードされた命令	正規化して分析
Microsoft 365 Copilotが読むメール	メール到達前の防御として有効
サードパーティーのメールAIアドイン	同じメールを読む場合は入口側で保護
Exchange Onlineを参照する独自AI	同じメールを読む場合は入口側で保護
組織内から送信されたメール	明示された主対象ではない
SharePointやOneDrive上の文書	今回のメール保護とは別の経路
Teamsメッセージ	今回のメール保護とは別の経路
外部Webサイトやデータベース	今回のメール保護の対象外

Microsoftは、Defender for Office 365によるメールフロー上の検査、Microsoft 365 Copilot側の実行時保護、Microsoft Defender XDRによるインシデント相関を、別々の防御層として説明しています。メールで遮断できなかった攻撃をAI側で防ぎ、さらにIDやエンドポイントの異常と関連付ける多層防御が前提です。(Microsoft Learn)

管理者による有効化やポリシー変更は必要か

対象となる顧客では、プロンプトインジェクション保護は既定で有効になり、追加の構成や管理者によるオプトインは不要とされています。公式情報では、この機能専用の有効化スイッチや新規ポリシーを作成する手順も案内されていません。(TECHCOMMUNITY.MICROSOFT.COM)

ただし、管理者が確認すべき項目はあります。

確認項目	必要な対応
専用機能の有効化	原則不要
新しいアンチフィッシングポリシーの作成	不要
対象ライセンス	Plan 1／Plan 2の割り当てを確認
メールフロー	受信メールがDefenderの検査経路を通るか確認
検疫ポリシー	通知やリリース要求の運用を確認
調査担当者の権限	Explorer、検疫、メールエンティティの閲覧権限を確認
SIEM・レポート	新しいDetection Technology値を取り込めるか確認
誤検知対応	管理者申請を含む手順を整備

EOPのみの環境は対象として扱わない

公式ドキュメントの適用対象は、Microsoft Defender for Office 365 Plan 1／Plan 2とMicrosoft Defender XDRです。Exchange Online Protectionのみを使用している環境は、今回の機能が利用できる前提で判断しないほうが安全です。(Microsoft Learn)

契約名称だけでなく、対象ユーザーやメールボックスに実際のサービスプランが割り当てられているかを確認してください。

検出されたメールはどう処理されるのか

プロンプトインジェクションが検出されると、メールは既存の高確度フィッシング判定に分類されます。

同時に、検出技術を示す新しい値として、次の項目が記録されます。

Prompt injection protection

日本語表示では「プロンプトインジェクション保護」などと表示される可能性があります。

Microsoftの発表では、対象メッセージは受信トレイへ配信される前に隔離され、検疫、Explorer、リアルタイム検出、メールエンティティページなどから確認できます。(TECHCOMMUNITY.MICROSOFT.COM)

契約プランによって調査画面が異なる

契約	主な調査画面
Defender for Office 365 Plan 1	Real-time detections
Defender for Office 365 Plan 2	Threat Explorer
Microsoft Defender XDRで高度なハンティングを利用可能	Advanced Hunting

Threat ExplorerはReal-time detectionsよりも、保存済みクエリ、追加フィルター、調査・修復操作などの機能が多く用意されています。(Microsoft Learn)

Defenderポータルで検出状況を確認する方法

検疫から確認する

Microsoft Defenderポータルで、次の場所を開きます。

メールとコラボレーション > 確認 > 検疫 > メール

対象メッセージの詳細で、少なくとも次の項目を確認します。

検疫理由
脅威の種類
フィッシングの信頼度
検出テクノロジ
送信元アドレスとドメイン
受信者
元の配信場所
適用されたポリシー
メッセージID
類似メールの有無

「高確度フィッシング」という理由だけで判断せず、検出テクノロジがPrompt injection protectionかどうかを確認するのがポイントです。

Threat ExplorerまたはReal-time detectionsから確認する

Threat ExplorerまたはReal-time detectionsでは、フィッシングの表示や全メールの表示を開き、Detection technologyで絞り込みます。

確認したい値は次のとおりです。

Prompt injection protection

表示名はPublic Preview中に変更される可能性があるため、完全一致する選択肢が見つからない場合は、「Prompt」「Injection」などを含む項目やメールエンティティの詳細を確認してください。

Advanced Huntingで検出メールを抽出する

Advanced Huntingを利用できる環境では、EmailEventsテーブルのDetectionMethods列を使って対象メールを調査できます。EmailEventsには、送信者、受信者、配信アクション、配信場所、脅威判定、検出手法などが記録されます。(Microsoft Learn)

Public Preview中の表記変更にも対応しやすいよう、最初は完全一致ではなく部分一致で検索する方法が実用的です。

EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where DetectionMethods contains "Prompt injection"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    ConfidenceLevel,
    DeliveryAction,
    DeliveryLocation,
    DetectionMethods,
    NetworkMessageId
| order by Timestamp desc

日別の件数と影響を受けた受信者数を確認する場合は、次のように集計できます。

EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where DetectionMethods contains "Prompt injection"
| summarize
    Detections = count(),
    Recipients = dcount(RecipientEmailAddress),
    Senders = dcount(SenderFromAddress)
    by bin(Timestamp, 1d)
| order by Timestamp asc

Advanced Huntingで参照できるDefenderデータは原則として過去30日までです。長期的な傾向分析が必要な場合は、Microsoft Sentinelや既存のSIEMへ継続的に保存する運用を検討します。(Microsoft Learn)

なお、クエリ結果が0件でも、機能が無効とは限りません。単に該当する攻撃メールを受信していない可能性があります。ライセンス、権限、ポータル上のDetection Technology表示と併せて判断してください。

監査・検知運用にはどのような影響があるか

高確度フィッシングの件数が増える可能性がある

今回の検出は新しい脅威タイプとして独立するのではなく、既存の高確度フィッシング判定へ分類されます。

そのため、次のようなレポートやルールには影響が出る可能性があります。

高確度フィッシングの総件数を監視するダッシュボード
ThreatTypesがPhishのメールを通知するSIEMルール
高確度フィッシングの急増を検知するアラート
検疫件数をKPIとして扱う月次レポート
検出方式を固定リストで分類しているデータ処理
フィッシング件数から誤検知率を計算するレポート

従来のフィッシングとAI向け攻撃を区別したい場合は、ThreatTypesだけでなくDetectionMethodsも集計軸へ追加します。

専用アラートが必ず生成されるとは限らない

公式情報で明示されているのは、新しいアラート種別ではなく、新しいDetection Technology値です。

したがって、すべてのプロンプトインジェクション検出が独立したアラートやインシデントとして通知される前提にはしないでください。検疫、Explorer、Advanced Huntingを使った定期確認が必要です。(Microsoft Learn)

検疫メールをユーザー自身で解放できない

高確度フィッシングとして検疫されたメールは、検疫ポリシーの設定にかかわらず、受信者自身で直接リリースできません。

検疫ポリシーで許可されている場合、ユーザーは管理者へリリースを要求できます。実際の解放判断は管理者が行います。(Microsoft Learn)

この仕様により、AI関連の技術資料やセキュリティレポートが誤検知された場合、ヘルプデスクへの問い合わせやリリース要求が増える可能性があります。

メール本文を閲覧した管理者操作は監査対象になる

Threat Explorerなどで管理者がメールをプレビューまたはダウンロードした操作は、既存のAdminMailAccessアクティビティとして監査ログに記録されます。

一方、今回の機能専用の新しい監査操作が追加されたとの案内はありません。検出結果の確認にはDefenderのメール調査画面を使用し、担当者による本文閲覧などの操作監査には監査ログを使用する、という役割分担になります。(Microsoft Learn)

管理者が優先すべき対応

最優先：対象ライセンスと保護経路を確認する

次の条件を満たしているか確認します。

対象ユーザーにDefender for Office 365 Plan 1またはPlan 2が割り当てられている
外部からの受信メールがMicrosoft 365の検査パイプラインを通る
外部メールゲートウェイやコネクタによって、想定外のフィルターバイパスが発生していない
SOC担当者が検疫やExplorerを閲覧できる
Advanced Huntingを使う担当者に必要な読み取り権限がある

特に、サードパーティーのセキュアメールゲートウェイを併用している環境では、「Microsoft 365へ届いているからDefenderでも同じように検査されている」と決めつけず、実際のメールフローを確認します。

最優先：AIがメールを読む範囲を把握する

Microsoft 365 Copilotのライセンス数だけを確認しても不十分です。次のような仕組みも調査対象に含めます。

Copilotによるメール要約
未読メールの自動トリアージ
メール内容を基に返信案を生成する機能
Power Automateなどから呼び出す生成AI
Exchange Onlineを参照する独自AIエージェント
Outlookへ追加されたサードパーティーAIアドイン
共有メールボックスを監視する自動化
問い合わせメールを分類するAIシステム

AIがメールを読む頻度が高く、接続されたツールの操作権限が広いほど、優先度は高くなります。

早期対応：既存の監視ルールを更新する

次のいずれかに該当する場合は、監視設定を見直します。

高確度フィッシングを一括して重大アラートにしている
DetectionMethodsの値を固定リストで処理している
未知の検出方式を「その他」として破棄している
Phish件数だけを集計し、検出技術を記録していない
SIEMへの取り込み項目にDetection Methodsが含まれていない

少なくとも初期段階では、Prompt injection protectionの件数、受信者、送信元、誤検知、リリース結果を別集計にすると状況を把握しやすくなります。

早期対応：誤検知対応の手順を決める

誤検知が疑われる場合は、単に検疫から解放して終了しないことが重要です。

Microsoftは、検出技術に関する誤検知を解決する場合、管理者申請から始めるよう案内しています。管理者申請を行うと、必要に応じてテナント許可／ブロックリストへの一時的な許可エントリを追加し、Microsoft側のフィルター改善につなげられます。(Microsoft Learn)

推奨する流れは次のとおりです。

送信者、ドメイン、認証結果、メール経路を確認する
HTMLソースや不可視テキストを調査する
業務上正当な内容か確認する
AIに読み込ませても安全な内容か別途判断する
誤検知であれば管理者申請を行う
緊急性がある場合のみ、確認後に管理者が解放する
同じ送信元・件名・本文による類似メールを調査する
調査結果をチケットやインシデント記録へ残す

「正当なメール」と「AIに安全なメール」は分けて判断する

プロンプトインジェクションの対応では、従来の誤検知対応とは異なる判断が必要です。

たとえば、セキュリティベンダーから送られたレッドチーム報告書に、攻撃検証用のプロンプトがそのまま記載されているケースを考えます。

このメールは送信元も内容も正当かもしれません。しかし、メール内の攻撃用プロンプトをAIエージェントが命令として処理する可能性があるなら、「正当なメールだから安全」とは言い切れません。

管理者は、次の2つを分けて判断してください。

業務上正当なメールか
AIが自動処理しても安全なメールか

後者を確認できない場合は、通常の受信トレイへ解放せず、AIの自動処理対象から外した検証用経路で扱うほうが安全です。

送信者やドメインの一括許可は避ける

信頼できる取引先や社内システムから送られたメールでも、メール本文が第三者によって変更されたり、正規アカウントが侵害されたりする可能性があります。

また、Microsoft 365のSecure by defaultでは、高確度フィッシングに対して一部の許可リストやメールフロールールによる例外が適用されない場合があります。広範囲な許可設定ではなく、管理者申請と限定的な一時対応を優先してください。(Microsoft Learn)

対応要否を判断する基準

組織の状況	対応優先度	推奨対応
Copilotがメールを要約・検索する	高	ライセンス、検出状況、誤検知手順を直ちに確認
AIが受信メールを自動分類する	最優先	エージェント権限とツール実行範囲も含めて点検
サードパーティーAIアドインを使用	高	Exchangeデータへのアクセス範囲を確認
独自AIが共有メールボックスを監視	最優先	自動実行可能な操作とデータ参照範囲を制限
Defender for Office 365を利用中だがAI未導入	中	自動保護の確認と監視ルール更新を実施
EOPのみでAIがメールを処理する	高	今回の機能の対象外と考え、追加対策を検討
AIも自動化もメールを読まない	低～中	将来のAI導入に備え、検出と検疫運用を確認

AIがメールを読むだけでなく、外部送信、ファイル操作、チケット更新、ワークフロー実行などのツールを呼び出せる場合は、優先度を一段階上げて判断します。

よくある誤解と注意点

Microsoft 365 Copilotだけを保護する機能ではない

メールフロー上で悪意ある命令を遮断するため、Microsoft 365 Copilotに限らず、Exchange Onlineのメールを読むサードパーティーアドインや独自自動化にも入口側の防御として機能します。(Microsoft Learn)

新しいポリシーを作らなければ保護されないわけではない

対象顧客では自動的に動作し、追加構成は不要です。管理者が優先すべきなのは、有効化作業ではなく、ライセンス、可視化、検疫、誤検知対応の確認です。(TECHCOMMUNITY.MICROSOFT.COM)

すべてのプロンプトインジェクションを防げるわけではない

今回の機能は、受信メールという1つの経路を保護するものです。SharePoint、OneDrive、Teams、Webサイト、外部データベースなどからAIへ入る悪意ある命令には、別の保護が必要です。

信頼できる送信者なら安全とは限らない

正規アカウントが侵害される可能性があるほか、セキュリティ資料や開発資料に攻撃用プロンプトが正当な目的で含まれる場合もあります。送信元の信頼性と、AIが処理した場合の安全性を分けて確認します。

検疫から解放すれば対応完了ではない

誤検知であれば管理者申請を行い、Microsoft側の判定改善につなげる必要があります。また、解放後にAIがそのメールを処理する可能性も考慮してください。

管理者が最初に行うべき3つの確認

今回の変更に対して、まず実施すべきことは次の3点です。

対象ユーザーにDefender for Office 365 Plan 1／Plan 2が割り当てられているか確認する
検疫、ExplorerまたはAdvanced HuntingでPrompt injection protectionを確認できる体制を整える
高確度フィッシングとして隔離されたメールの誤検知調査、管理者申請、解放判断の手順を決める

AIがメールを処理する組織では、メールは単なる連絡手段ではなく、AIシステムへの入力経路です。今回の機能は追加設定なしで入口を保護しますが、検知後の運用まで自動的に整備されるわけではありません。

ライセンスとメールフローを確認したうえで、Detection Technologyを使った可視化、誤検知対応、AIエージェントの権限確認まで実施することが、実務上の優先対応となります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Defender for Office 365のプロンプトインジェクション対策｜影響と管理者対応

Microsoft Defender for Office 365のメール経由プロンプトインジェクション対策とは

従来のフィッシングと何が違うのか