Microsoft 365のセキュリティ更新として今回まず押さえるべき結論は、Copilotや生成AIを安全に使うには、AI機能そのものより先に「ID、データ分類、DLP、監視、SIEM/XDR連携、権限管理」を整える必要があるという点です。2026年5月23日時点で確認された公式情報では、St. Luke’sとManpowerGroupの事例を通じて、Microsoft Defender、Microsoft Purview、Microsoft Security Copilot、Microsoft Sentinelを組み合わせ、AI活用の土台をどう守るかが示されています。これは全テナントに即時適用される強制変更ではありませんが、Microsoft 365管理者にとっては、自社環境の設定・移行計画・運用ルールを見直す重要なタイミングです。(Microsoft)
今回のMicrosoft 365セキュリティ更新で示されたこと
今回の公式情報は、単一機能のリリース告知というより、AI時代にMicrosoft 365環境をどう守るべきかを示す実践事例です。Microsoft Security Blogでは、AIによって業務とリスクの両方が変化しており、保護は後付けではなく、AIシステムの開発・統制・利用プロセスに組み込む必要があると説明されています。対象として挙がっている製品は、Microsoft Defender、Microsoft Purview、Microsoft Security Copilot、Microsoft Sentinelです。(Microsoft)
St. Luke’s University Health Networkの事例では、複数のセキュリティツールにまたがる可視性不足が課題でした。同社はMicrosoft DefenderとMicrosoft Sentinelを接続し、エンドポイント、ID、メール、クラウドワークロードを横断して見えるAI活用型のセキュリティ運用を進めています。公式情報では、Security Copilotのエージェントにより、アラートのトリアージや脆弱性対応などの反復作業を自動化し、Security Triage Agentによって月最大200時間のアナリスト作業を削減した事例も紹介されています。ただし、この数値は同社の事例であり、すべての組織で同じ効果が出るわけではありません。(Microsoft)
ManpowerGroupの事例では、グローバルに分散した従業員を守るため、複数ツールの乱立を減らし、Microsoft 365 E5、Microsoft Defender、Microsoft Sentinelを軸に統合型のセキュリティ基盤へ移行しています。公式情報では、ID、エンドポイント、メール、クラウドの予防・検出・対応機能と、SentinelのSIEM/SOAR機能を組み合わせることで、AI活用に耐えられるセキュリティ基盤を整えたと説明されています。(Microsoft)
管理者が理解すべき実務上の変更点
今回のポイントは、「AIを導入するかどうか」ではなく、「AIが業務に入ってくる前提でMicrosoft 365の守り方を変える」ことです。特に、SharePoint、OneDrive、Teams、Exchange、Entra ID、Defender、Purview、Sentinelを個別に管理している組織では、運用の分断がそのままAI利用時のリスクになります。
| 領域 | これまで起こりがちな運用 | 今回の示唆 | 管理者が確認すべきこと |
|---|---|---|---|
| データ保護 | SharePointやOneDriveの権限だけで管理する | AIが参照できるデータを分類・保護する | 機密ラベル、DLP、外部共有、サイト権限 |
| 監視・検知 | Defender、Sentinel、メール、IDのアラートを別々に見る | XDRとSIEMを統合し、相関分析しやすくする | Defenderポータル、Sentinelワークスペース、分析ルール |
| ID管理 | 管理者権限を常時付与する | 最小権限と継続的な検証を前提にする | Conditional Access、PIM、多要素認証、管理者ロール |
| AI運用 | 現場主導で試験導入する | AIエージェントにも統制と監査を組み込む | Security Copilotのワークスペース、ロール、利用範囲 |
| 開発・連携 | アプリに広いGraph権限を付与する | API権限も最小化し、アクセス範囲を明示する | アプリ登録、Graph権限、Selected permissions |
影響範囲はMicrosoft 365管理者だけに限られない
今回の内容は、Microsoft 365管理者だけで完結しません。AI基盤を安全にするには、セキュリティ運用、ID管理、データ保護、開発、業務部門の責任範囲を整理する必要があります。
| 担当者 | 主な影響範囲 | 最初に確認すべき場所 |
|---|---|---|
| Microsoft 365管理者 | ライセンス、ユーザー、Teams、SharePoint、OneDrive | Microsoft 365管理センター、SharePoint管理センター |
| Purview管理者 | 機密ラベル、DLP、監査、データガバナンス | Microsoft Purviewポータル |
| SOC・セキュリティ管理者 | インシデント、アラート、脅威ハンティング | Microsoft Defenderポータル、Microsoft Sentinel |
| Entra ID管理者 | 条件付きアクセス、特権ロール、アプリ同意 | Microsoft Entra管理センター |
| 開発者・内製AI担当 | Graph API、社内アプリ、エージェント連携 | Entraアプリ登録、APIアクセス許可、シークレット管理 |
特に注意したいのは、AI利用時のリスクが「AIツールの設定」だけで決まらないことです。たとえば、SharePointに古い機密ファイルが広く共有されたまま残っていれば、Copilotや社内AIエージェントの導入によって、その情報が見つかりやすくなる可能性があります。AI導入前に、既存のアクセス権とデータ分類を棚卸しすることが重要です。
Microsoft Purviewで最初に確認すべきデータ保護設定
Microsoft 365でAIを安全に使うための第一歩は、重要データを分類し、保護ルールを適用することです。Microsoft Purviewの秘密度ラベルは、組織のデータを分類・保護しつつ、ユーザーの共同作業を妨げにくい形で運用するための機能です。Microsoft 365 Copilotも、Purviewの秘密度ラベルや暗号化と連携し、グラウンディングやコンテンツ生成時のアクセス制御・保護設定に関わります。(Microsoft Learn)
機密ラベルは少数から始める
最初から複雑なラベル体系を作ると、ユーザーが判断できず、ラベル未設定のファイルが増えます。実務では、まず次のような4段階程度から始めると運用しやすくなります。
| ラベル例 | 対象データ | 推奨される扱い |
|---|---|---|
| Public | 公開資料、Web掲載済み資料 | 制限は最小限 |
| Internal | 社内手順書、一般的な会議資料 | 社外共有を必要に応じて制限 |
| Confidential | 顧客情報、契約書、財務資料 | 外部共有、ダウンロード、印刷を制御 |
| Highly Confidential | 役員資料、人事、M&A、医療・法務関連 | Copilot処理、外部共有、持ち出しを厳格に制御 |
失敗しやすいのは、すべてのファイルを「Confidential」にしてしまう運用です。これでは本当に守るべき情報が埋もれます。業務部門ごとに「何を最重要データとするか」を決め、ラベルの判断例を明文化してください。
DLPでCopilot利用時の情報漏えいを抑える
Microsoft Purview Data Loss Preventionは、Microsoft 365 CopilotやCopilot Chatとのやり取りを保護するためにも利用できます。公式ドキュメントでは、機密情報を含むプロンプトで外部Web検索を制限する機能、機密プロンプトの処理を制限する機能、秘密度ラベルが付いたファイルやメールをCopilotの応答要約に使わせない制御が説明されています。(Microsoft Learn)
管理者が確認すべき設定は次のとおりです。
| 確認項目 | 実施内容 | 注意点 |
|---|---|---|
| DLPポリシーの場所 | カスタムポリシーで「Microsoft 365 Copilot and Copilot Chat」を選ぶ | 他の場所と同時指定できない場合があるため、既存DLPと分けて設計する |
| 機密情報タイプ | クレジットカード番号、個人番号、社員番号、顧客IDなどを定義 | 標準SITだけでなく、自社固有の識別子も検討する |
| 秘密度ラベル条件 | Highly ConfidentialなどをCopilot処理から除外 | ラベル未設定ファイルには効かない |
| テスト方法 | まずシミュレーションや通知中心で運用 | いきなりブロックすると業務影響が読みにくい |
| 反映時間 | ポリシー更新後の反映に時間がかかる場合がある | 公式情報では最大4時間かかる可能性が示されている |
DLPによるCopilot保護では、ファイルがSharePoint OnlineまたはOneDrive for Businessに保存されていること、メールは条件によって対象時期があること、予定表招待はサポート対象外であることなど、範囲の制約もあります。ルールを作っただけで全データが一律に守られるわけではないため、対象データの保存場所とラベル付け状況を必ず確認してください。(Microsoft Learn)
Defender XDRとMicrosoft Sentinelの統合で確認すべき移行ポイント
St. Luke’sの事例から分かるように、AI時代のセキュリティ運用では「個別アラートを追う」だけでは限界があります。Microsoft 365のID、エンドポイント、メール、クラウドアプリ、外部クラウドの情報をつなぎ、SOCが同じ画面と同じ文脈で調査できる状態が重要です。
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、Defender XDRと組み合わせる、またはSentinel単体でも利用できます。さらに、Microsoftは2027年3月31日以降、AzureポータルでのMicrosoft Sentinelサポートを終了し、Defenderポータルでの利用に移行すると説明しています。現在Azureポータル中心でSentinelを運用している組織は、早めに移行計画を作るべきです。(Microsoft Learn)
SentinelをDefenderポータルに接続する前のチェック
Microsoft SentinelをDefenderポータルに接続するには、Defenderポータルの「System > Settings > Microsoft Sentinel > Connect a workspace」からワークスペースを選択し、プライマリワークスペースを指定します。接続後は、Home、Incidents、Advanced HuntingなどでSentinelとDefender XDRのデータを統合して扱えるようになります。(Microsoft Learn)
接続前に、次の項目を棚卸ししてください。
| 項目 | 確認する理由 |
|---|---|
| Sentinelワークスペース一覧 | プライマリにするワークスペースを誤ると、SOCの主要ビューが変わる |
| データコネクタ | Defender XDR連携により一部コネクタの扱いが変わる可能性がある |
| 分析ルール | インシデント作成ロジックや重複検知に影響する |
| 自動化ルール・Playbook | インシデント名やステータスを条件にしている場合、動作確認が必要 |
| RBAC | 既存のAzure RBAC権限は引き続き考慮されるが、運用担当者の権限設計を再確認する |
| SOC手順書 | 画面遷移、調査手順、エスカレーション先をDefenderポータル前提に更新する |
特に注意したいのは、Microsoft SentinelとDefender XDRの統合方法によって、インシデントの同期、コネクタ、分析ルール、コストの扱いが変わる点です。DefenderポータルにオンボードしてDefender XDRライセンスがある場合、Microsoft SentinelはDefender XDRと自動的に接続されます。また、Defender XDR統合製品の一部データコネクタは自動的に切断されると説明されています。(Microsoft Learn)
自動化ルールは「インシデント名」依存を避ける
移行時に壊れやすいのが、インシデント名を条件にした自動化です。公式ドキュメントでは、Defender XDRコネクタ有効時にMicrosoft側のインシデント作成ルールが無効になり、インシデントタイトルを事前に決められなくなる可能性があると説明されています。自動化ルールは、インシデント名ではなく、タグ、重大度、エンティティ、製品名、MITRE ATT&CKの戦術・技法など、より安定した条件で設計し直すのが安全です。(Microsoft Learn)
Security Copilotを展開する前に確認すべき設定
Microsoft Security Copilotは、AIを使ってセキュリティ運用を効率化するサービスです。Microsoft Learnでは、Security Copilotエージェントがクラウド、データセキュリティ、プライバシー、ID、ネットワークセキュリティなどの反復作業を自動化し、セキュリティチームの作業負荷を下げると説明されています。(Microsoft Learn)
ただし、Security Copilotは「導入すれば自動的に安全になる」製品ではありません。効果を出すには、Defender、Sentinel、Purview、Entra ID、Intuneなどの信号が整っていること、ロール設計が適切であること、人間による確認プロセスが残っていることが前提です。
Microsoft 365 E5およびE7向けのSecurity Copilotでは、Defender、Entra、Intune、Purviewの業務フローにSecurity Copilotエージェントが組み込まれることが説明されています。また、対象テナントでは既定ワークスペースが自動作成され、Security Copilotの各エクスペリエンスがその既定ワークスペースを利用します。(Microsoft Learn)
展開前に、少なくとも次の点を確認してください。
| 確認項目 | 管理者の対応 |
|---|---|
| ライセンスと対象テナント | 自社のMicrosoft 365契約、Security Copilot利用条件、対象ユーザーを確認する |
| 既定ワークスペース | Security Copilotポータルでワークスペース、所有者設定、データ保存場所を確認する |
| データ所在地 | Microsoft 365 geo overrideやADRを利用している場合、Security Copilot側の保存場所も確認する |
| ロール | SOC、ID管理者、Purview管理者などに必要最小限の権限を割り当てる |
| 利用シナリオ | フィッシングトリアージ、インシデント要約、調査支援など、低リスク領域から始める |
| 人間の承認 | 脆弱性修復、アカウント無効化、外部共有停止などは自動実行せず、承認手順を置く |
| 効果測定 | 平均トリアージ時間、誤検知率、対応件数、再オープン率を導入前後で比較する |
Security Copilotの評価で重要なのは、「便利だったか」ではなく「判断の質と対応速度が改善したか」です。St. Luke’sのように削減時間を測る場合も、単純な作業時間だけでなく、誤検知の減少、重大インシデントへの集中度、レポート作成時間、エスカレーション品質をあわせて見ると、導入判断がしやすくなります。
Entra IDと特権管理はAI基盤の最重要ポイント
AI活用が進むほど、ID管理の重要性は高まります。MicrosoftのZero Trust原則では、すべてのアクセス要求を明示的に検証し、必要最小限の権限を短時間だけ付与し、侵害が起きる前提で検知と対応を組み込む考え方が示されています。(Microsoft Learn)
Microsoft Entra Conditional Accessは、ユーザー、グループ、エージェント、IP、デバイス、アプリ、リスクなどの信号を使ってアクセス判断を行うZero Trustのポリシーエンジンです。管理者ロールを持つユーザーに多要素認証を要求する、レガシー認証をブロックする、組織管理デバイスを要求する、といった運用に使えます。(Microsoft Learn)
特権管理では、Microsoft Entra Privileged Identity Managementの活用を検討してください。PIMは、Microsoft Entra ID、Azure、Microsoft 365、Intuneなどの重要リソースへのアクセスを管理・制御・監視するサービスで、Just-in-Timeアクセス、承認、MFA、アクセスレビュー、監査履歴などを提供します。(Microsoft Learn)
実務では、次の設定を優先します。
| 優先度 | 設定 | 理由 |
|---|---|---|
| 高 | グローバル管理者の常時割り当てを削減 | 侵害時の被害範囲を小さくする |
| 高 | 管理者ロールのPIM化 | 必要な時だけ昇格し、承認・監査を残す |
| 高 | 管理ポータルへのMFAまたは強力な認証要求 | 管理者アカウントの乗っ取りを防ぐ |
| 中 | 条件付きアクセスのレポート専用モードで影響確認 | 誤ブロックを避けながら段階展開する |
| 中 | 緊急アクセス用アカウントの監視 | ロックアウト対策と不正利用検知を両立する |
| 中 | アプリ同意フローの統制 | 不要なGraph権限や外部アプリ連携を防ぐ |
開発者が確認すべきMicrosoft Graphとアプリ権限
Microsoft 365上でAIエージェント、社内検索、文書要約、ワークフロー自動化を作る場合、Microsoft Graphの権限設計がそのまま情報漏えいリスクになります。Microsoft Graphの権限リファレンスでは、アプリが正しく動作するために必要な最小権限だけを要求することがベストプラクティスとされています。(Microsoft Learn)
SharePointやOneDriveのデータにアクセスするアプリでは、安易にテナント全体へ広いアクセス権を与えないことが重要です。Microsoft GraphのSelected permissionsでは、サイト、リスト、リストアイテム、ファイル単位でアプリのアクセスを管理できます。たとえば、Sites.Selectedは特定サイトコレクションへのアクセス、Files.SelectedOperations.Selectedはファイルまたはライブラリフォルダー単位のアクセスに使えます。(Microsoft Learn)
開発・展開前のチェックリストは次のとおりです。
| チェック項目 | 実務上の判断基準 |
|---|---|
| Delegated権限かApplication権限か | ユーザー操作の延長ならDelegated、バックグラウンド処理ならApplicationを検討 |
| Graph権限の範囲 | Read.AllやReadWrite.Allを使う前にSelected permissionsで代替できないか確認 |
| 管理者同意 | 本番テナントでの同意前に、開発・検証環境で権限とログを確認 |
| シークレット | 長期シークレットを避け、証明書やマネージドIDなどを検討 |
| ログ | プロンプト、応答、取得データに機密情報が残らない設計にする |
| 環境分離 | 開発・検証・本番でアプリ登録、権限、データソースを分ける |
| 定期レビュー | 使われていないアプリ、過剰権限、期限切れ資格情報を棚卸しする |
開発者にとっての落とし穴は、「APIが動くこと」を優先して広い権限を付けることです。AI連携では、検索・要約・分類のために大量のデータへアクセスしがちです。最初の設計段階でアクセス範囲を狭めておかないと、後から権限を絞る作業が難しくなります。
展開・移行で失敗しやすいポイント
Microsoft 365のAIセキュリティ基盤を整える際は、技術設定だけでなく、業務影響と運用変更もあわせて考える必要があります。
| 失敗しやすいポイント | 起こる問題 | 回避策 |
|---|---|---|
| ラベル設計を複雑にしすぎる | ユーザーが選べず、未分類ファイルが増える | 最初は3〜5段階に絞り、判断例を配布する |
| DLPをいきなりブロック運用にする | 通常業務まで止まる | 監査・通知・シミュレーションから始める |
| Sentinel移行を画面変更だけと考える | 自動化ルールやSOC手順が壊れる | コネクタ、ルール、Playbook、手順書を事前棚卸しする |
| Security Copilotに過剰な期待をする | AIの回答を無検証で実行してしまう | 高影響操作には人間の承認を残す |
| 管理者権限を整理しない | 侵害時に被害が拡大する | PIM、MFA、条件付きアクセス、アクセスレビューを優先する |
| 開発アプリに広いGraph権限を与える | AI連携経由で不要なデータまで取得できる | Selected permissionsや最小権限を検討する |
まず30日で実施したい対応計画
今回の公式情報を受けて、すべてを一度に変える必要はありません。最初は、AI活用の前提になる基盤を小さく点検し、優先度の高いところから直すのが現実的です。
| 期間 | 目標 | 実施内容 | 成果物 |
|---|---|---|---|
| 1〜30日 | 現状把握 | 機密データ、外部共有、管理者権限、Sentinel構成、Graph権限を棚卸し | リスク一覧、優先順位表 |
| 31〜60日 | ガードレール整備 | 機密ラベル、DLP、Conditional Access、PIM、Defender/Sentinel連携を検証 | テストポリシー、移行計画 |
| 61〜90日 | AI運用の試験展開 | Security CopilotやCopilot関連DLPを限定部門で試す | 効果測定、運用手順、教育資料 |
最初に着手するなら、Purviewの機密ラベルとDLP、Entra IDの管理者権限、SentinelのDefenderポータル移行計画の3つを優先してください。この3点は、AI導入の有無にかかわらずMicrosoft 365環境全体の安全性に直結します。
まとめ：AI導入前にMicrosoft 365の土台を点検する
今回のMicrosoft 365セキュリティ更新で重要なのは、AIを安全に使うための主役が、Copilot単体ではなく、ID、データ、監視、ガバナンス、運用自動化の組み合わせであることです。St. Luke’sとManpowerGroupの事例は、Security CopilotやMicrosoft 365 E5を導入するだけでなく、Defender、Sentinel、Purview、Entra IDをつなぎ、セキュリティをAI活用の制約ではなく推進力に変える考え方を示しています。
管理者が次に取るべき行動は明確です。まず、重要データがどこにあり、誰がアクセスでき、どのAI機能やアプリが参照できるのかを棚卸ししてください。そのうえで、PurviewのラベルとDLP、Defender XDRとSentinelの統合、Security Copilotのワークスペースと権限、Entra IDの条件付きアクセスとPIM、Graph APIの最小権限を順番に確認します。
AIの活用を止めるのではなく、安全に広げる。そのための最初の一手は、新しい機能を有効化することではなく、Microsoft 365の既存設定をAI前提で見直すことです。
コメント