プロンプトインジェクションから守る!Copilotセキュリティ実践術

はじめに

Microsoft 365 Copilotは業務効率を大きく高める一方で、導入時にセキュリティの備えが不十分だと、社内の機密データが意図せず外部へ漏れるリスクがあります。とりわけ、プロンプトインジェクションと呼ばれる攻撃手法や、ファイル権限の設定ミスによる「オーバーシェアリング」は、Copilotの利便性を逆手に取った深刻な脅威です。生成AIの導入支援をしていると、こうしたリスクへの認識が薄いまま展開を急ごうとする組織に頻繁に出会います。

こうしたリスクに対しては、テナント分離や権限モデルといったCopilotの基盤設計を正しく理解し、監査ログやDLPポリシーを組み合わせた多層防御を実装することが有効です。ここで重要なのは、プロンプトさえ制御すれば安全という思い込みを捨てることです。本記事では、Copilotのセキュリティ基盤から具体的な攻撃事例、導入前後の対策手順までを順を追って解説します。

Copilotのセキュリティ基盤

データ処理とテナント分離の仕組み

Copilotのセキュリティを支える最も基本的な仕組みが、データ処理をMicrosoft 365のサービス境界内にとどめる設計です。ユーザーが入力したプロンプト、そこから取得されるデータ、生成された応答はMicrosoft 365のサービス境界内で処理され、既存のプライバシー・セキュリティ・コンプライアンスの約束に従います（参照*1）。

さらに、テナント単位の厳格な分離が適用されています。データは保存時と転送時の両方で暗号化され、ある組織のデータに別の組織がアクセスすることはできません（参照*2）。こうした二重の防壁により、テナント間でのデータ混在が構造的に排除されています。

したがって、Copilotを利用する組織は、まず自社のテナント境界が正しく構成されているかを確認することが出発点になります。「Copilotを導入したからデータが外に出る」のではなく、「設定が間違っていたから出る」という順序を正確に理解しておかないと、対策の優先順位を誤ります。

権限モデルとMicrosoft Graph連携

Copilotは独自の特権を持たず、操作しているユーザーの権限の範囲内でのみデータにアクセスします。Security Copilotもユーザーとしてクエリを実行し、そのユーザーが持つ以上の特権を得ることはありません（参照*3）。

具体的には、CopilotはMicrosoft 365の既存の権限を引き継ぎ、感度ラベル、保持ポリシー、データアクセスルールをそのまま適用します（参照*2）。つまり、Microsoft Graphを通じて取得できる情報の範囲は、そのユーザーが普段のMicrosoft 365操作で閲覧できる情報と同じです。

この仕組みは、「Copilotを導入したから情報が見えるようになった」のではなく、「もともと見えていた情報をCopilotが素早く引き出す」という点を理解するうえで欠かせません。逆に言えば、権限設計が適切であれば、Copilot導入によって情報漏洩リスクが急増するわけではありません。問題は、導入前から放置されていた「過剰な権限」がCopilotによって一気に可視化・悪用されるという構造にあります。

基盤モデル非学習の保証

Copilotの利用データが外部のAIモデル改善に使われるのではないかという懸念は、導入検討時に頻繁に挙がります。この点について、プロンプト・応答・Microsoft Graph経由でアクセスされたデータは、基盤となる大規模言語モデルの学習データから明確に除外されています（参照*2）。

Security Copilotについても同様の方針が適用されており、顧客データはOpenAIと共有されず、販売目的にも使われず、第三者にも渡されず、Azure OpenAIの基盤モデル学習にも使用されません（参照*3）。組織のデータが自社のテナント外で二次利用される懸念は、現行の方針上は低減されています。

プロンプトインジェクションの脅威

攻撃の種類と仕組み

プロンプトインジェクションとは、AIの安全装置を迂回するために悪意ある指示を入力する攻撃手法です。Copilotに対する攻撃は大きく2つに分かれます。1つは、ユーザー自身が直接悪意あるプロンプトを入力するジェイルブレイク攻撃です。もう1つは、外部から送り込まれたコンテンツに命令を埋め込むクロスプロンプトインジェクション攻撃（XPIA）です（参照*1）。

XPIAの特徴は、ユーザーが意図的に操作しなくても攻撃が成立する点にあります。たとえば、組織外から送られたメールに埋め込まれた攻撃者の指示が、AIに特権のある内部データへのアクセスと処理を行わせることがあります。この手法はLLMスコープ違反と呼ばれ、ユーザーの明示的な意図や操作なしに機密情報が流出する可能性を持ちます（参照*4）。

いずれの手法も、Copilotが持つ「ユーザーの代わりに情報を取得し要約する」という機能を悪用するものです。防御を考える際は、入力側と参照データ側の両方に対策が必要になります。生成AIのセキュリティリスクは、情報漏洩だけではなく、プロンプトインジェクションのように従来のITセキュリティの発想とは異なる論点が混在しています。従来のWebアプリ管理の延長で考えていると、防御の設計が根本的にずれます。

EchoLeak（CVE-2025-32711）の手口

プロンプトインジェクションの実際の脅威を示す事例として、EchoLeakと名づけられた脆弱性が報告されています。この脆弱性はCVE-2025-32711として追跡され、CVSSスコアは9.3と極めて高い深刻度が割り当てられました（参照*5）。

EchoLeakは「LLMスコープ違反」という新たな脆弱性の分類に属します。大規模言語モデルが、ユーザーの意図や操作なしに、特権のある内部データを漏洩させてしまうことが特徴です。攻撃チェーンにより、Copilotの画面は組織の従業員だけに開かれているにもかかわらず、攻撃者はユーザーが気づかないうちに機密情報や社外秘の情報をCopilotのコンテキストから自動的に抜き取ることが可能でした（参照*4）。

Microsoftは5月にサーバー側の修正を適用しており、実際の悪用が確認された証拠はなく、利用者側で個別に対応を取る必要はないとされています（参照*5）。しかし、この事例はゼロクリックで機密データが漏洩し得るという攻撃パターンが現実に存在することを示しています。「便利な機能」と「攻撃の入り口」は同じ場所にある、という認識をCopilot導入の前提として持っておく必要があります。

Microsoftの検知・防御技術

こうしたプロンプトインジェクションに対して、Copilotは複数の防御機構を備えています。Microsoft 365 Copilotは独自技術としてジェイルブレイク分類器およびXPIA分類器を使い、攻撃的なプロンプトを検知して緩和します（参照*1）。

加えて、Copilotにはプロンプトインジェクション、有害コンテンツ、データ漏洩に対する保護機能が組み込まれています。Web検索を利用する際にはクエリが匿名化され、ユーザーやテナントの識別情報が除去されるほか、広告主への共有も行われません（参照*2）。

これらの対策はMicrosoft側で継続的に更新されるサーバー側の防御であり、利用者が個別に設定する必要はありません。ただし、前述のEchoLeakのように新たな攻撃手法は継続的に発見されます。生成AI導入の難しさは、モデル選定よりも、組織の意思決定・ルール整備・出力品質の検証・現場への定着にあります。Microsoft側の対策を信頼しつつも、組織側の権限管理とDLPポリシーによる多層防御を組み合わせることが、実効性を高めます。

過剰権限とデータ漏洩リスク

オーバーシェアリングの実態と統計

プロンプトインジェクションと並んでCopilotのセキュリティ上の大きな課題となるのが、ファイル権限の設定ミスに起因するオーバーシェアリングです。オーバーシェアリングとは、本来アクセスすべきでない人にデータが共有されてしまう状態を指します。ファイルの権限が意図したよりも広く設定されている場合に発生し、Copilot Chatではファイルをアップロードした本人のOneDriveにのみ保存されるものの、そのファイルやクエリ結果を他者と共有すれば同様の問題が起こり得ます（参照*6）。

この問題の規模は決して小さくありません。5億5,000万件以上のデータレコードを分析した調査によると、組織の業務上重要なデータの16%がオーバーシェアリング状態にあり、平均して1組織あたり80万2,000件のファイルが過剰共有によるリスクにさらされています（参照*7）。

Copilotはユーザーの権限の範囲でデータを取得するため、権限が過剰に設定されている環境ではCopilotが本来見せるべきでない情報を要約・提示してしまう恐れがあります。私が企業の導入支援をしていて実感するのは、多くの組織がCopilot導入前の権限棚卸しを「後でやればいい」と後回しにしていることです。この数字は、それが致命的な判断ミスになり得ることを示しています。

感度ラベル未継承の問題

オーバーシェアリングに加えて、Copilotの出力に対するラベル管理にも注意が必要です。Copilotの生成結果は、参照元ファイルのセキュリティラベルが一貫して自動で引き継がれるとは限りません。元のファイルに機密データが含まれていても、生成された応答にラベルが付与されない場合があるため、機密情報が無分類のまま流通するリスクがあります（参照*7）。

この場合、AIの出力を受け取った従業員がデータの分類とリスク評価を手動で確認する必要があります。しかし実務では、すべての出力を逐一確認することは現実的ではありません。「AIの出力をそのまま社外に出すのは、文章作成ではなくリスク管理の問題」という発想が、ここでも必要になります。誰が確認したのか、どのデータを参照したのか、間違っていた場合の責任はどこかを、運用ルールとして決めておかないと、見落としが構造的に発生します。

したがって、感度ラベルの適用状況を組織全体で監視し、Copilotの出力物にも適切なラベルが付くよう運用ルールを定めておくことが、セキュリティ水準の維持に直結します。

部門別リスクシナリオ

オーバーシェアリングと感度ラベル未継承の問題は、部門ごとに異なるリスクとして顕在化します。たとえば、財務部門では次のようなシナリオが想定されます。財務アナリストがCopilotを使って四半期決算レポートを作成する際、入力データに公開済みの財務数値と未公開の収益データが混在しているケースです。入力段階で機密データが正しく分類されていないと、Copilotは未公開の収益データを含む包括的なレポートを生成しますが、そこに「機密」という分類を付けない場合があります（参照*7）。

このレポートがそのまま社内外に共有されれば、インサイダー情報の漏洩につながりかねません。財務に限らず、人事部門の従業員評価データや法務部門の契約情報など、各部門が扱う機密データの性質に応じてリスクの形は変わります。

Copilot導入にあたっては、部門ごとにどのデータが機密に該当するかを洗い出し、入力段階でのラベル付けと権限の見直しを事前に実施することが欠かせません。

導入前に整えるべき対策手順

高リスクサイトの特定と暫定保護

Copilotを安全に展開するためには、まず組織内の高リスクなデータ保管場所を特定し、暫定的な保護措置を講じる必要があります。具体的には、Microsoft Purview Data Security Posture Management（DSPM）のデータリスク評価を使い、機密データを含むオーバーシェアリング状態のサイト、リスクのある共有リンク、頻繁にアクセスされるコンテンツを洗い出します。加えて、SharePoint Advanced Management（SAM）のコンテンツ管理アセスメントを実行し、対象者が過大なサイトや不適切な共有が行われているサイト、所有者不在のサイトなどを特定します（参照*8）。

特定が済んだら、暫定措置として対象のサイトをCopilotの検索対象から除外します。SAMの制限付きコンテンツ検出（RCD）を有効にして機密サイトをCopilotの探索から除外し、Microsoft Purview DLP for Copilotを設定して機密コンテンツがCopilotの応答生成に使われないようにします。その後、Microsoft Purview監査とレポートを通じて、Copilotが制限対象のコンテンツを表示しなくなったことを検証します（参照*8）。

この「特定、除外、検証」の流れを導入前に完了させることで、Copilotが意図しないデータを参照してしまうリスクを大幅に低減できます。AI活用プロジェクトで成果を出すには、最初から全社展開を目指すより、小さな業務で入力・出力・確認・修正・効果測定を回してノウハウを貯めるほうが現実的です。このステップも、その考え方と同じです。

最小権限とセキュアデフォルトの設定

暫定保護と並行して、恒久的な権限設計も整えておく必要があります。業務上重要なサイトに対しては、作成時点から制限付きアクセス制御（RAC）を既定として適用します。テナントレベルでは全社向け共有グループと「すべてのユーザー」リンクの使用を無効化または制限し、不要な公開経路を遮断します。さらに、Microsoft Purview Information Protectionを使い、サイト作成時に感度ラベルの付与を必須とすることで、サイトのプライバシー設定と共有制御が正しく適用される状態を初期設定として確保します（参照*8）。

こうした「セキュアデフォルト」の考え方は、個々のユーザーの判断に依存せず、仕組みとして安全を担保する点に強みがあります。Copilotが参照するデータの権限を最小限に保つことで、万が一の攻撃や設定ミスによる影響範囲を限定できます。生成AI導入時に詰まるのは、プロンプトでもモデル選定でもなく、「どのデータに誰がアクセスできるか」という業務側の定義です。セキュリティ設計は、技術より先に、業務設計の問題として考えるべきです。

監査・DLP・コンプライアンス運用

Purview監査ログとDSPMの活用

Copilot導入後の運用段階では、利用状況を継続的に可視化する仕組みが不可欠です。Security Copilotは、Microsoft Purview統合監査ログ（UAL）、Microsoft Purview DSPM for AI、およびOffice Management APIを通じて監査ログへのアクセスを提供し、コンプライアンスおよび規制要件への対応を支援します。UALは管理者イベントやアクティビティのメタデータを可視化し、DSPM for AIはプロンプトと応答のペアに関する洞察を提供します（参照*9）。

この2種類の情報を組み合わせると、「誰がどのようなプロンプトを送り、Copilotがどのデータを参照して何を返したか」を事後的に追跡できます。セキュリティインシデントの調査だけでなく、日常的な利用傾向の把握にも役立つため、定期的なレビュー体制を構築しておくことが望ましいです。生成AI導入時は、入力データ・出力形式・確認者・修正基準・ログ保存・例外処理を決める必要があります。ログを取れる状態にしておかないと、何か起きたときに追跡も改善もできません。

DLPポリシーとInsider Risk Management

監査ログによる可視化に加えて、能動的にリスクを遮断する手段としてDLPポリシーがあります。Copilotの応答生成に使わせたくないファイルやメールがある場合は、Microsoft Purview DLP for Copilotポリシーを設定し、特定の感度ラベルが付いたファイルやメールの処理を制限できます。また、Copilotに処理させたくないキーワードや機密データの種類がある場合は、プロンプト向けのDLPポリシーを有効にして、指定した機密情報を含むプロンプトへの応答を制限できます（参照*8）。

さらに、内部不正の検知にはMicrosoft Purview Insider Risk Management（IRM）が有効です。IRMポリシーを有効にすると、不適切またはコンプライアンス違反にあたるCopilot利用のパターンを検出し、リスクの高いユーザーを自動的により厳格なセキュリティポリシーの適用対象に追加します（参照*8）。DLPで出入口を制限し、IRMで内部の異常行動を検知するという二段構えが、Copilotのセキュリティ運用では効果的です。

ISO 42001・GDPR・EU Data Boundary対応

Copilotを組織のコンプライアンス体制に組み込むうえでは、国際認証や地域規制への適合状況の確認も欠かせません。MicrosoftはAzure AI Foundry ModelsおよびMicrosoft Security Copilotについて、AI管理システムの国際規格であるISO/IEC 42001:2023認証を取得しました。この認証は、AIシステムを責任ある方法で安全かつ透明性をもって構築・運用する姿勢を裏づけるものです（参照*10）。

EU域内のユーザーに対しては、追加の保護措置も用意されています。Copilot ChatはEU Data Boundaryに準拠するための追加対策を備えており、EUからのトラフィックはEU Data Boundary内にとどまります。一方、EU域外からのトラフィックは、大規模言語モデルの処理のためにEUおよびその他の国・地域へ送信される場合があります（参照*11）。

ISO 42001認証とEU Data Boundaryへの対応は、Copilotの導入稟議や社内セキュリティ審査の際に、根拠資料として活用できるポイントです。生成AIを社内に展開する場合、情報システム・法務・コンプライアンス・現場・教育・監査・データ管理が関係します。これらの部門を横断する根拠として、こうした認証情報を整理しておくと、社内調整のコストが下がります。

運用時の注意点と失敗例

Purviewだけでは防げない盲点

Purviewの各機能は強力ですが、ラベル付けの前提が崩れると保護の網から漏れる可能性があります。Purviewが保護できるのは「すでに正しくラベル付けされたデータ」に限られます。正しく分類済みのデータに対してポリシーを適用する仕組みであり、分類漏れのデータを自動的に見つけ出す機能は持ちません。実態として、業務上重要なデータの16%がオーバーシェアリング状態にあり、1組織あたり80万件を超えるファイルがリスクにさらされています。こうしたファイルの多くは感度ラベルが不正確であるか、そもそもラベルが付いていないことが原因でリスクを抱えています（参照*7）。

つまり、Purviewのポリシーを整備しただけでは、ラベルなしの機密ファイルは保護の対象外となり、Copilotの応答に含まれてしまう可能性が残ります。Copilotのセキュリティを実効性あるものにするには、ラベル付与の網羅性を高める取り組みをPurviewの運用と並行して進める必要があります。生成AIは「候補を生成する道具」であって「100%正確に動作する道具」ではありません。同様に、セキュリティツールも「正しく設定されたデータを守る道具」です。前提となるデータ整備を怠ると、どれだけ高機能なツールを入れても意味がありません。

データ共有設定の見落とし

もう1つの典型的な失敗が、データ共有に関するオプション設定の見落としです。Security Copilotでは、データ共有を有効にすると、プロンプトや応答などの顧客データが製品性能の向上、精度の改善、応答遅延の改善のためにMicrosoftと共有されます。この場合、アップロードファイルを除く顧客データがテナントに設定されたワークスペースの地理的リージョン外に保存される場合があります（参照*3）。

また、監査ログの取得についても設定が必要です。Microsoft Purviewによる顧客データのアクセス・処理・コピー・保存を許可するかどうかは管理者が構成する項目であり、この機能を有効にした後、多くの場合ログが利用可能になるまで24時間程度かかります（参照*12）。

データ共有と監査ログの設定は、導入直後に確認しておかないと、意図しないデータ流出や証跡の欠落につながりかねません。特にデータの地理的保管場所に関する要件がある組織は、共有オプションの有効・無効を慎重に判断してください。「便利だが現場導入は難しい」という構図が生成AIにはよくありますが、Copilotでも同様です。設定の見落としは、技術的な問題というより、運用ルールと責任範囲を誰も決めていないという組織的な問題から来ることが多いです。

おわりに

Copilotのセキュリティは、テナント分離や権限モデルといった基盤設計に加え、プロンプトインジェクション対策、DLPポリシー、監査ログ、ラベル管理といった複数のレイヤーを組み合わせることで初めて実効性を持ちます。どれか1つの仕組みに頼るのではなく、導入前の権限棚卸しから運用後の継続監視まで一貫した対策を講じることが、データ漏洩リスクを最小化する鍵です。ここで重要なのは、セキュリティの問題を「技術部門が解決すべき設定の問題」として切り離さないことです。誰がどのデータに触れるか、誰が出力を確認するか、何かあったときの責任はどこかという問いは、経営と現場が一緒に答えを出す必要があります。

本記事で取り上げた対策手順や注意点を自組織の環境に照らし合わせ、Copilotの利便性とセキュリティの両立を図る判断材料としてご活用ください。生成AIの価値は、単に作業時間を短くすることだけではありません。ただし、その価値を享受するには、業務設計とセキュリティ設計を先に整えることが前提です。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））