執筆している2026年10月25日時点の情報です。Microsoft 365 Copilot のセキュリティ機能は更新されるため、最新情報は必ず公開情報（本記事末尾の参考リンク）もあわせてご確認ください。
本稿はMicrosoftの公式ブログ・セキュリティ情報・公開ドキュメントをもとに整理したものです。実機での攻撃再現や保護機能の検証は行っていません。場面と確認項目は説明用の仮想例・筆者の提案です。本稿の作成に際して、実際のテナント設定は変更していません。
1. 「このメールを読んで」と「このメールの指示に従って」は違う
Copilotに「今日届いたメールを要約して」と頼むとします。
この依頼でしてほしいのは、メールの内容を読み、重要な情報を整理することです。メールの差出人に、Copilotの仕事の進め方を自由に決めてもらうことではありません。
ところが、AIが読むメールや資料に、回答を別の方向へ誘導する文章が紛れ込んでいたらどうでしょう。
要約の対象だった文章が、AIへの命令として扱われる。 このような問題につながるのが、「間接的プロンプトインジェクション」です。
2026年10月13日のMicrosoft公式ブログは、このリスクを減らすため、取得した情報の出所や信頼の境界に応じて扱いを変える、Trust-Aware Controlsの考え方を紹介しています。
本稿では、「読んでよい情報」と「従ってよい指示」を分ける仕組みとして、やさしく整理します。
参考情報
2. この記事で分かること
- メールや資料を読むAIに、なぜ特有のリスクがあるのか
- アクセス権限と「信頼境界」は、何が違うのか
- Microsoftが紹介した、隔離・制約された処理の考え方
- Outlookの外部送信者識別について、管理者が確認すること
- 保護機能があっても、利用者・管理者に残る確認事項
主な読者は、Copilotでメールや資料の要約を行う方、Microsoft 365管理者、AIの業務利用を支援する方です。
攻撃方法を再現する記事ではありません。また、個人向けCopilotや、すべてのAIエージェントに同じ保護があると説明するものでもありません。中心となる公式解説の対象は、Microsoft 365 Copilotです。
3. 間接的プロンプトインジェクションとは
利用者が頼んだことと、外部の文章を混同する問題
プロンプトとは、AIに渡す依頼や指示です。通常、利用者は「このメールを要約して」「この資料から予定を整理して」と頼みます。
間接的プロンプトインジェクションでは、AIが参照するメール・文書・メッセージなどに、AIの動作へ干渉しようとする指示が含まれます。
| 種類 | 例の位置付け |
|---|---|
| 利用者の依頼 | 「メールの要点を整理してほしい」という本来の仕事 |
| 参照する内容 | 日時、問い合わせ、提案内容など、整理すべき情報 |
| 紛れ込んだ指示 | 本来の仕事から外れるよう、AIの応答や処理を誘導する文章 |
重要なのは、利用者自身が問題のある指示を頼んでいなくても、AIが仕事のために読みに行った情報を経由して、影響を受ける可能性があることです。
フィッシングメールと、まったく同じ話ではない
人間をだましてリンクを開かせるフィッシングと、関連する場面はあります。しかし、ここで注目しているのは、AIが入力を処理するときの問題です。
人が内容をよく読まなくても、AIが要約対象としてその文章を取得することがあります。そこで、整理すべき情報と、従うべき命令を取り違えない設計が必要になります。
ただし、外部のメールに指示文があるだけで、必ず攻撃が成功するという意味ではありません。 保護機能、利用する処理、入力内容などによって結果は異なります。
参考情報
4. なぜアクセス権限だけでは、説明しきれないのか
「読める」と「従う」は、別の判断
Microsoftの公開資料は、Copilotが利用者の閲覧権限に基づいて組織内の情報を提示すると説明しています。アクセス権限の管理は、引き続き重要です。
ただし、閲覧が許可されたメールの中身に、AIを誘導する文章が含まれていることはあり得ます。
つまり、次の二つは別の質問です。
- この利用者は、この情報を読んでよいか。
- この情報の中にある指示に、AIが従ってよいか。
一つ目を正しく判定できても、二つ目まで自動的に解決するわけではありません。
信頼境界を「受付と作業指示書」で考える
たとえば、社外から届いた問い合わせを、受付担当者が読む場面を考えます。
問い合わせを受け取ることと、問い合わせに書かれた内容で社内の作業規則を書き換えることは別です。外部の相手が書いた文章は、対応に必要な情報として読んでも、社内の指示と同じ権限を持たせるべきではありません。
この区切りが、本稿でいう信頼境界のイメージです。
なお、「社内の文章はすべて安全」「社外の文章はすべて悪意がある」という分類ではありません。公式ブログは、組織外からのメールなどを、出所やポリシーに基づいて信頼できない入力として扱う例を示しています。
権限管理やDLPが不要になるわけではない
DLPは、Data Loss Prevention、つまり情報漏えいを防ぐための管理です。
公式ブログは、認証・アクセス管理・DLPが設計どおり機能していても、AIが入力を解釈する段階のリスクが残り得ると説明しています。
これは従来の対策を否定する話ではなく、従来の対策に、AIの処理段階の保護を重ねるという考え方です。
参考情報
- Building Trust-Aware Controls for AI: Differentiated handling of untrusted content
- Data, Privacy, and Security for Microsoft Copilot
5. Trust-Aware Controlsは、何を変えるのか
怪しい文章を見つけるだけでなく、入力の通し方を変える
AIによる判定や入力のフィルタリングは、リスク低減のための手段です。公式ブログが紹介する新しい方向性は、それらに加え、取得した情報を主モデルへ渡す前に、出所に応じた処理の境界を設けることです。
ここでいう主モデルとは、最終的な回答の生成などを担う中心の大規模言語モデルを指します。
公式解説の流れを四段階で整理する
| 段階 | 公式ブログで説明されている考え方 |
|---|---|
| 1. 出所などのシグナルで分類する | 取得した情報を、信頼できる入力・信頼できない入力として扱い分ける |
| 2. 隔離・制約された経路で処理する | 信頼できない内容を、そのまま主モデルへ渡さず、機能を制約した経路へ送る |
| 3. 必要な情報を残した表現へ変換する | 利用者の依頼に必要な情報を保ちつつ、悪意ある内容を取り除くことを目指す |
| 4. 出所を考慮して回答を作る | 変換済みの表現や、出所を示す情報を使って、主モデルが処理する |
公式ブログは、情報の出所を示すマーカーを付け、後段の処理でも由来を考慮できるようにする仕組みも説明しています。
「この文章は怪しいか」を毎回当てることだけに頼るのではなく、どの入力が、どの処理経路を通るかを制御する点が重要です。
「決定的な制御」は、「必ず無害になる」という意味ではない
公式ブログにあるdeterministicな制御とは、定められたシグナルや処理ポイントに基づいて境界を設ける、という説明です。
それを、「AIがすべての悪意を正確に見抜く」「変換後の内容は必ず正しい」「攻撃成功率がゼロになる」と読み替えてはいけません。
Microsoftは、この仕組みを多層防御の一部として説明しています。初期の取り組みは外部通信などの高リスクな内容に重点を置き、追加の種類・情報源への拡張を検討しているとしています。
仮想例：会議案内の要約を頼む場合
外部から届いた架空の会議案内に、開催日時などの情報と、要約を別の方向へ誘導する文章が混在していたとします。
本来の仕事は、日時・議題・参加方法を整理することです。信頼境界を設ける考え方では、必要な情報を取り出しつつ、メール内の文章に本来の依頼を書き換える権限を持たせないことを目指します。
これは仕組みの理解を助けるための仮想例です。特定のメールを実際に処理し、安全な出力を確認したものではありません。
参考情報
6. 管理者が確認する、Outlookの外部送信者識別
公式ブログだけでなく、MSRCの案内を読む
公式ブログは、テナントで保護を構成するため、該当するOutlookの送信者設定を有効にし、CVE-2026-55145のガイダンスを確認するよう案内しています。
CVEとは、公開された脆弱性を識別するための番号です。この番号のMicrosoft Security Response Center（MSRC）での名称は、Outlook Copilot Tampering Vulnerabilityです。
日付は区別しておきましょう。
- Trust-Aware Controlsの公式ブログ公開日：2026年10月13日
- CVE-2026-55145のMSRCでの初回公開日：2026年7月14日
本稿は、この脆弱性が10月に初めて発表されたと説明するものではありません。
MSRCの案内では、顧客側の作業が必要とされています。対策として、Outlookの外部送信者タグ付けを有効にし、信頼できない入力の識別とMicrosoft提供の緩和策につなげることが説明されています。
「サービス側の対策だから、管理者は何も確認しなくてよい」とは扱いません。
最初に、既存の設定を確認する
以下は、Exchange Online PowerShellへ接続済みの、必要な権限を持つ管理者が使う確認用の例です。本稿では実行していません。
モジュールや接続が未準備の場合は、公式の接続ガイドに従って準備します。対象テナントと管理権限を確認し、認証情報をスクリプトへ直接書き込まないでください。
Get-ExternalInOutlook | Format-List Enabled, AllowList
| 項目 | 確認すること |
|---|---|
| Enabled | 外部送信者識別が有効か |
| AllowList | 外部送信者識別の対象から除外する送信者・ドメインが登録されているか |
AllowListは、外部表示の例外リストです。登録されていることを、内容が安全であることの保証や、AIへの指示を信頼してよい根拠にはしません。
有効化は、組織の変更手順に従って行う
Microsoft Learnに掲載されている、有効化のコマンドは次のとおりです。
Set-ExternalInOutlook -Enabled $true
これは組織の設定を変更する操作です。確認用コマンドではありません。 必要な権限、変更承認、利用者への影響を確認してから実行してください。
有効化後は、確認コマンドで設定を再確認できます。
Get-ExternalInOutlook | Format-List Enabled, AllowList
ただし、設定値がTrueになったことは、すべてのCopilot処理を検証できたこととは別です。
反映時間と、既存のメールフロールールに注意する
公式のコマンド資料では、対応するOutlookで外部アイコンが表示されるまで、24～48時間かかる場合があると説明されています。
これは外部アイコンの表示についての案内です。Copilot側のすべての保護が同じ時間で展開・検証される、という意味ではありません。
また、件名へ「外部」などの文字を追加する既存のメールフロールールがある場合、公式資料は重複を避けるための調整を案内しています。
ただし、既存の件名ラベルと、Outlook標準の外部送信者識別を、同じ設定だとは扱いません。 既存ルールを一律に削除・無効化せず、何を目的としたルールなのか、他の保護や運用へ影響しないかを確認して変更します。
参考情報
- Building Trust-Aware Controls for AI: Differentiated handling of untrusted content
- Outlook Copilot Tampering Vulnerability
- Get-ExternalInOutlook
- Set-ExternalInOutlook
- Connect to Exchange Online PowerShell
7. 利用者と管理者に残る確認事項
ここからは、公開資料の考え方を踏まえた筆者の運用上の提案です。製品が自動的にすべてを保証する、という説明ではありません。
利用者：重要な結論は、元の情報へ戻って確認する
- 要約が依頼と違う方向へ進んでいないか確認する。
- 契約条件・金額・期限など、重要な情報は元のメールや資料と照合する。
- AIの回答だけを根拠に、送信・共有・重要な判断を進めない。
- 不自然な回答や指示を見つけた場合は、組織の報告手順に従う。
報告する場合も、メール全文や個人情報を無関係なチャットへ転記せず、許可された窓口で必要な情報だけを扱います。
管理者：一つの設定を、対策全体の代わりにしない
- 外部送信者識別の状態と例外を確認する。
- Microsoft 365の閲覧・共有権限を見直す。
- DLPや既存のメール保護を継続する。
- 公式のセキュリティ情報と、対象環境の提供状況を確認する。
- 検証は承認された環境と手順で行い、設定確認と保護の実測を分けて記録する。
外部アイコンが表示されることだけで、「すべての間接的プロンプトインジェクションに対応済み」と判断しないことが重要です。
8. 制限事項と、確認できていないこと
全コンテンツ・全製品の共通保証ではない
公式ブログは、初期の重点対象を外部通信などとし、追加のコンテンツや情報源への拡張を検討していると説明しています。また、提供状況や動作はリリース状態・テナント環境によって異なるとしています。
そのため、次のようには断定しません。
- すべてのメール・文書・Webページで、同じ保護が有効になっている。
- すべてのCopilot製品や、独自に作成したエージェントにも自動的に適用される。
- 外部送信者識別を有効にすれば、攻撃も情報漏えいも完全になくなる。
本稿で未確認の事項
- 各テナント・クライアント・処理経路ごとの詳細な提供範囲と展開状況
- 信頼できない入力を判定するすべてのシグナル、変換処理の内部仕様
-
AllowListなどの例外設定が、Copilot側の保護の各段階へ与える具体的な影響 - 保護の有効性を利用者が直接確認できる表示・ログの網羅的な仕様
- 日本語のメールでの実際の処理結果、誤判定や要約品質への影響
- 自組織で必要となる契約・ライセンス・既存設定との組み合わせ
本稿では、実際の設定変更、攻撃再現、保護の有効性測定を行っていません。最新の対象範囲や必要な作業は、公式のブログ・MSRC・製品ドキュメントで確認してください。
参考情報
- Building Trust-Aware Controls for AI: Differentiated handling of untrusted content
- Outlook Copilot Tampering Vulnerability
9. まとめ：情報は読んでも、その指示をそのまま信頼しない
Copilotが仕事に使う情報には、利用者の依頼とは異なる指示が紛れ込む可能性があります。
Trust-Aware Controlsのポイントは、取得した情報の出所を考慮し、信頼できない入力を隔離・制約された経路で処理することで、AIへの影響を減らそうとすることです。
覚えておきたいのは、次の三点です。
- 読める情報と、従ってよい指示は別。 アクセス権限だけでは、AIの解釈段階の問題は解決しません。
- サービス側の保護と、管理者の作業を分けて確認する。 MSRCは外部送信者識別の有効化を案内しています。
- 多層防御を続ける。 権限管理、DLP、メール保護、利用者による確認を、一つの設定で置き換えません。
利用者は重要な要約を元の資料と照合し、管理者は公式ガイダンスと現在の設定を確認する。身近なメール要約の場面でも、この二つを組み合わせることが大切です。
参考リンク
公開情報の確認日は2026年10月25日です。Microsoft Learnは公開ページの更新情報（updated_at）を記載しています。ブログ公開日、脆弱性の初回公開日、機能の提供開始日は、それぞれ別のものです。
| 資料 | 提供元 | 公開日・更新日 | 主な使用箇所 |
|---|---|---|---|
| Building Trust-Aware Controls for AI: Differentiated handling of untrusted content | Microsoft Community Hub | 公開日：2026年10月13日 | 間接的プロンプトインジェクション、信頼境界、処理の仕組み、限界 |
| Outlook Copilot Tampering Vulnerability | Microsoft Security Response Center | 初回公開日：2026年7月14日 | CVE-2026-55145、顧客側の作業、外部送信者識別の案内 |
| Data, Privacy, and Security for Microsoft Copilot | Microsoft Learn | 更新情報：2026年10月8日 | 利用者の閲覧権限と組織情報の扱い |
| Get-ExternalInOutlook | Microsoft Learn | 更新情報：2026年2月27日 | 設定の確認、Enabled・AllowList |
| Set-ExternalInOutlook | Microsoft Learn | 更新情報：2026年2月27日 | 有効化、外部アイコンの反映時間、既存ルールとの調整 |
| Connect to Exchange Online PowerShell | Microsoft Learn | 更新情報：2026年6月18日 | 接続の前提条件、認証、管理権限 |
本記事について
本記事は、公開情報をもとに内容を整理し、できるだけ分かりやすく解説することを目的として作成しています。記載内容は個人の見解であり、所属組織の公式見解を示すものではありません。少しでもお役に立てればうれしいです。
ご質問・追記要望は本ページのコメント欄までお寄せください。