Microsoft 365 Copilotで見落としがちなデータ保護の盲点とは？

Microsoft 365 Copilotの活用が広がる中、企業には従来以上に適切なデータ管理が求められています。Microsoft 365（以下、M365）は、Exchange Onlineのメール、SharePoint OnlineやOneDrive for Businessのファイル、Microsoft Teams（以下、Teams）のチャットや会議など、日々の業務で生まれる情報が集まる基盤です。社内の資料を共有し、離れた場所にいる従業員や取引先と効率よく仕事を進めるうえで、欠かせない環境になっています。

本稿では、生成AI時代に見落とされやすいM365のデータ保護の課題を整理します。

閉じる

Microsoft 365が攻撃者に狙われる理由

情報が集約されれば、担当者は必要な資料や過去のやり取りを探しやすくなります。その一方で、攻撃者が一つのアカウントを侵害すると、従業員本人が日常的には意識していない共有ファイルや業務情報にまでアクセスされる可能性があります。例えば、攻撃者が従業員の認証情報を入手してM365にログインできれば、本人が閲覧できるメールや共有ファイルを調べられます。メールの内容から取引先との関係を把握し、SharePoint Onlineに保存された契約書や事業計画を探すことも可能になります。

権限の高いアカウントが侵害された場合や、社内で広く共有された場所に機密情報が置かれている場合には、影響範囲はさらに広がります。また、攻撃者は閲覧した情報を持ち出すだけでなく、ファイルを削除・改ざんしたり、侵害したアカウントから同僚や取引先に不審なメッセージを送ったりすることもあります。M365のデータ保護では、「情報を盗まれないこと」に加えて、「必要な情報を失わないこと」も考える必要があります。

こうした侵害の入口を得るために攻撃者が多用する手法がフィッシングであり、M365のアカウントも主要な標的の一つとなっています。Hornetsecurityが2025年に実施した調査でも、ランサムウェア攻撃の侵入経路の46%をフィッシングが占めていました。偽のログイン画面へ誘導して認証情報を盗む手口に加え、認証後のセッションを悪用しようとする手口も確認されています。攻撃経路もメールに限らず、SMSやTeams、Slackなどのビジネスチャット、コラボレーションツールへと広がっています。

攻撃者は、従業員が日常的に利用するサービスや業務上の連絡を装い、M365の認証情報を盗み出そうとします。一つのIDから複数の業務サービスを利用できるというM365の利便性を支える仕組みは、そのIDが侵害された際には、被害が広がる要因にもなります。

生成AIによって変わるデータ保護の前提

これらの課題は、Copilotの登場前から存在していました。では、生成AIの活用によって何が変わるのでしょうか。大きな違いは、蓄積された情報の見つかり方と使われ方にあります。

従来、従業員が過去の資料を仕事に使うには、その保存場所を知っているか、検索語を考えて探し、見つけたファイルを開いて読む必要がありました。たとえアクセス権があっても、ファイルの存在を知らなければ利用する機会は限られます。古いプロジェクトのフォルダーや、大勢が参加するチームの奥にある資料は、権限上は閲覧できても、日常業務ではほとんど目に触れませんでした。

しかしCopilotを使うと、この状況が変わります。Copilotは、利用者の質問や作業の内容に応じて、アクセス可能なメール、チャット、文書などから関連情報を探し、要約して提示できます。例えば、新しい担当者が「この取引先との契約条件は、これまでどのように決まったのか」と尋ねた場合、過去のやり取りや会議資料を参照できれば、それらを手がかりに経緯を把握しやすくなります。担当者が一つひとつの保存場所を知らなくても、必要な情報にたどり着けます。これはCopilotの大きな利点の一つです。

その結果、M365上のデータは、単に保存しておく記録から、AIを通じて日々の判断や資料作成に使う資産へと役割を広げます。作成した当時だけでなく、後から別の担当者が異なる仕事に活用する可能性も高まります。企業が長年蓄積してきた情報を生かせる一方で、その情報をどのような状態で残しているかが、AI活用の価値を左右するようになります。

例えば、同じ案件について複数の資料が残っていて、どれが最新版か分からない状況を考えてみます。利用者は、Copilotが示した内容を確認するために、資料の作成日や決定の経緯を調べる必要が生じます。古い方針が残っていること自体が問題なのではなく、更新の関係が分からず、現在も有効な情報として扱ってよいか判断しにくいことが問題となります。データの所在を把握し、必要な記録を残し、古い情報と現行の情報を区別できるようにすることが重要です。つまり、従来から求められてきたデータ管理が、AIを使ううえでも重要になります。

情報の見え方も変わります。例えば、以前のプロジェクトで作成した機密資料が、組織内の広い範囲から閲覧できる設定のまま残っていたとします。これまでは、その保存場所を知る人しか開かなかったかもしれません。しかし、閲覧権のある利用者が関連する質問をCopilotに投げかければ、資料の内容に触れる可能性があります。普段は誰も閲覧していないからといって、その情報が適切に保護されているとは限りません。。

ここで誤解してはならないのは、Copilotが利用者の権限を越えて、自由に社内情報を読むわけではないという点です。CopilotはM365の既存のアクセス制御に従います。問題になるのは、共有範囲を広く設定したまま忘れていた資料や、担当者の異動後も権限を見直していないファイルなど、従来から存在する過剰共有です。人が偶然見つける機会は少なかった情報でも、AIの支援によって業務の文脈に現れやすくなります。

Copilotを危険なものとして遠ざけるのではなく、データがどこにあり、どれが正しく、誰がアクセスできるのかを把握することが、安全で有効なAI活用の前提になります。

「クラウドだから安心」で終わらせない

M365はMicrosoftが提供・運用するクラウドサービスであるため、データの保護もすべてMicrosoftに任せられると考えてしまいがちです。しかしクラウドでは、提供事業者と利用企業が、それぞれ異なる役割を担います。これが責任共有モデルの基本的な考え方です。

Microsoftは、サービスを構成するインフラやアプリケーションの運用、サービス基盤の可用性やセキュリティの確保を担います。また、M365にはデータの保持・復元やアクセス制御のための機能も用意されています。一方で、どの情報を誰と共有するか、どのデータをどの期間守るか、事故が起きたときに何をどの時点へ戻すかは、企業の業務や規則に応じて企業側が決める必要があります。監査のためにどの記録が必要か、退職者の情報をどう引き継ぐかといった判断も、企業側の運用に関わります。

例えば、誤って削除したファイルに気づくのが数日後なのか、数カ月後なのかによって、必要な復旧手段は異なります。あるファイルだけを戻せればよい場合もあれば、広範囲に改ざんされたデータを、影響を受ける前の状態へ戻したい場合もあります。標準機能があることと、自社に必要な範囲・期間・方法で復旧できることは同じではありません。まず「何が起きたら、何を、いつまでに戻す必要があるか」を定め、その要件に照らして機能を確認することが重要です。

Copilotの活用が進めば、この確認はさらに重要になります。業務データが失われれば、従業員が参照できなくなるだけでなく、AIが利用できる情報も欠けてしまいます。反対に、データが残っていても共有範囲が適切でなければ、共有を想定していなかった利用者が、AIを通じて内容に触れる可能性もあります。企業には、データを残すことと、適切な人に使わせることの両方が求められます。

M365のデータを守る2つの視点

そこで本連載では、M365のデータ保護を以下の2つの視点から考え、次回以降で詳しく解説します。

バックアップ

誤削除や改ざん、ランサムウェアなどに備え、必要なデータを取り戻せるようにする視点です。M365の標準的な復元・保持機能で対応できる範囲を確認したうえで、自社が必要とするデータや時点まで復旧できるかを検討します。生成AI時代のバックアップには、業務を再開するためだけでなく、AIが活用する情報の基盤を守るという意味も加わります。

権限管理

過剰共有や、不要になったアクセス権を見直す視点です。Copilotが既存の権限に従うからこそ、その権限が現在の業務に合っているかを確かめる必要があります。必要な人が資料を見つけて使える利便性を保ちながら、見せる必要のない情報は適切に制限することが求められます。

まとめ

M365には業務情報が集約されるため、攻撃者にとって価値の高い標的となり、一つのアカウントの侵害が広い範囲に影響します。Copilotの登場は、攻撃者に狙われやすい構図や過剰共有などの課題を新たに作り出したわけではありません。しかし、これまで見つかりにくかった情報が業務の文脈に現れやすくなり、データの状態や権限設定が、そのままAI活用の質とリスクに反映されるようになりました。クラウドサービスである以上、データをどう残し、誰に使わせるかを決めるのは企業側の役割です。次回は、一つ目の視点であるバックアップを取り上げます。M365の標準機能とバックアップはどう違い、生成AIの活用を支えるためには何を守り、どこまで復旧できるようにすべきなのかを解説します。