Copilotの活用が広がる中で、Microsoft 365の使い方は大きく変わろうとしています。 しかし、「どこまでAIに任せてよいのか分からない」「従来の運用で問題ないのか不安がある」と感じている方も多いのではないでしょうか。
実際には、課題の多くは機能不足ではなく、運用の前提そのものにあります。 AIが実行主体となる環境では、権限やデータの状態がそのまま結果に反映されるため、設計のあり方がこれまで以上に重要になります。
本記事では、Microsoft 365で起きている変化の本質と、その中で情シスが今取り組むべき「土台づくり」の考え方と進め方を解説します。
この記事でわかること／解決できること
- AI活用により従来の運用がなぜ機能しなくなるのか
- 権限設定やデータの状態がリスクにつながる理由
- 過剰共有や例外設定といった見えにくいリスクの捉え方
- AI時代に求められる運用モデル（ID・端末・データ）の考え方
- Microsoft 365で土台を整える具体的な進め方
- 少人数体制でも実行できる現実的なロードマップ
なぜ今、Microsoft365の前提が変わろうとしているのか
Microsoft 365を取り巻く環境は、ここ1年で大きく変化しています。CopilotによるAIの実用化が進み、日常業務の中でAIを活用することが現実的な選択肢となり始めました。
これまで、Microsoft 365は「人が操作するツール」として導入・運用されてきました。ユーザーが必要な情報を探し、判断し、手作業で業務を進めることを前提に、セキュリティやアクセス制御、運用ルールが設計されてきました。
しかし現在、この前提は大きく崩れつつあります。AIがユーザーに代わってデータを横断的に探索し、文書作成や分析を行うだけでなく、業務プロセスそのものに関わるようになってきています。この変化により、「AIをどこまで信頼してよいのか分からない」「従来のアクセス制御やデータ管理で対応できるのか不安が残る」「少人数体制の中で運用が回るのか見通しが立たない」といった課題が見え始めています。
これらの課題に共通しているのは、単なる機能の問題ではないという点です。では、何が本質的な問題なのでしょうか。
変化の本質は「運用モデル」にある
ここで重要になるのが、「運用モデル」という視点です。前述した課題は、特定の機能を追加すれば解決するものではありません。むしろ、根本にあるのは「Microsoft 365をどのように使うか」という前提そのものです。
従来の運用では、「一度設定すれば、一定期間はそのまま使える」「問題が起きたら後から対応する」といった考え方が前提になっていました。これは、人が主体となってシステムを利用する環境で成立していたモデルです。しかし、AIが前提となる環境では、この考え方だけでは十分に機能しなくなります。これまで許容されていた設定の曖昧さや例外が、そのままリスクとして顕在化しやすくなるのです。
これまで人だけが前提だった運用を、これからは人＋AI前提へと見直す必要があります。
今、Microsoft365で起きている４つの変化
では、この運用モデルの変化は、具体的にどのような形で現れているのでしょうか。代表的な例を４つ挙げます。
１．AIが「支援」から「実行主体」へ変わる
最も大きな変化は、Copilotの役割が「支援」から「実行主体」へと近づいている点です。
これまでは、人がアプリケーションを操作し、Copilotに都度指示を出す使い方が主流でした。日常の業務の中では、文書の下書き作成や要約といった、単発のタスクを効率化する“支援ツール”としての利用が中心でした。
しかし、Copilotの進化により、この前提が変わりつつあります。これからは、Copilot Coworkのようなエージェント型AIの進化により、AIが複数のステップをまたがる作業を自律的に実行し、一連の業務プロセスそのものを担う方向へと進んでいきます。
さらにCopilotには、従来のGPTに加えてClaudeなど複数のAIモデルを使い分ける設計が導入され、タスクに応じて最適なAIが選択される仕組みも整いつつあります。これにより、単発の作業ではなく、一連の業務プロセスをAIが主体的に実行できるようになるのです。
その結果、AIも単独の従業員として扱う前提で、運用を見直す必要があります。
AIが実行主体となる環境では、人だけが前提だった時に想定していた範囲を超えて、権限の範囲内でデータを横断的に探索し、ネットワーク内のさまざまなデータやシステムにまたがって、処理を行うようになります。
そのため、権限管理や変更管理、監査といった統制が十分に整備されていなければ、想定外のデータ参照や情報利用がそのままリスクとして顕在化してしまいます。 これからは「AIをどう使うか」ではなく、「AIをどう管理するか」まで含めた設計が求められるようになります。
２．データ管理が「制御」から「可視化と是正」へ変わる
2つ目の変化は、データガバナンスの考え方が変わる点です。
これまでのデータ管理は、「情報を外に出さない」ことに重点が置かれてきました。メール送信やファイル共有といった外部に出る瞬間を制御することで、情報漏洩を防ぐアプローチです。
しかし、AIがデータを横断的に活用するようになると、この考え方だけでは不十分になります。AIは権限の範囲内で情報を広く探索・利用するため、もともとの共有状態や権限設定の影響をそのまま受けます。人は必要な情報を選んで参照しますが、AIはその前提を持たず、アクセス可能な情報を横断的に処理するため、「少し広めにアクセス権限が設定されているだけ」の状態でも、意図しない情報活用につながるリスクが生じます。
こうした状況では、データの状態そのものを管理する考え方が重要になります。具体的には、機密データの所在と利用状況の把握、過剰共有や想定外アクセスの検出と評価、分類や権限の見直しによる是正などです。加えて、AIのデータアクセスを追跡し、利用状況を把握できる状態も必要になります。 これからのデータ管理は、「外に出さない制御」から「可視化し、継続的に是正する運用」へと変わっていきます。
３．認証が「一定時間信頼」から「常に見直す」へ変わる
3つ目の変化は、IDとセッション制御の前提が変わる点です。
従来の認証では、一度サインインすると、その際に発行されるトークンによって一定期間は認証状態が維持される仕組みが一般的でした。一度ログインすれば、特に問題が起きない限りしばらくサインインされた状態が維持されます。
しかし、この仕組みでは、不審なアクセスが検知された場合や、退職などでアカウントが無効化された場合でも、すでに発行済みのトークンが有効な間はアクセスが継続できてしまいます。
こうした前提を見直す動きとして、今後は「状態変化を前提にアクセスを制御する運用」へと変わっていきます。ログイン後も継続的に状態を評価し、リスクが検知されたタイミングでセッションを再評価・遮断することで、不審なアクセスや不要なアカウントをほぼリアルタイムに制御できるようになります。
認証は単にログインを管理する仕組みではなく、「状態の変化に応じてアクセスを制御し続ける運用」へ設計が変わります。
４．セキュリティ運用が「人手中心」から「自動化前提」へ変わる
4つ目の変化は、セキュリティ運用のあり方そのものが変わる点です。
従来の運用では、複数のツールから発生するアラートを人が確認し、優先度を判断しながら一つひとつ対応していく必要がありました。このような状態は「アラートの海」とも呼ばれ、対応の遅れや見落とし、運用負荷の増大といった課題を引き起こします。
しかし現在は、検知・分析・対応といった一連のプロセスが統合され、セキュリティ運用は大きく変わりつつあります。従来は複数のツールに分かれていた情報が一つの管理ポータル画面に集約され、横断的に状況を把握しながら対応できるようになっています。個別のアラートをそのまま処理するのではなく、複数のシグナルを相関させて分析し、優先度付けや初期対応を自動化することで、対応すべきインシデントが整理された形で可視化されるようになっています。
これにより、従来は人手に依存していた調査や一次対応の負荷が大きく軽減され、復旧までの時間短縮や、いわゆる“アラート疲れ”の解消につながります。
「アラートを人が個別に処理する運用」から、「システムが分析し、人は判断に集中する運用」へ変わった結果、少人数でも現実的に回せる運用モデルへと変わっていきます。
AI活用を実現するために必要な「土台」とは
これらの変化を踏まえたとき、AI活用を現実の業務に落とし込むためには、何を整える必要があるのでしょうか。
AI活用が進んだ環境では、仕事の進め方が大きく変わります。これまでは、人が情報を探し、作業を組み立てていましたが、今後は目的を伝えるだけで、AIが文書作成からタスク整理までも担うようになります。成果物も固定されたものではなく、AIによって差分反映や要点抽出、タスク更新が自動で行われ、常に最新の状態に保たれます。その中で人の役割は、作業そのものではなく、レビューや判断、意思決定へとシフトしていきます。
こうした環境では、AIのアウトプットの品質は、社内データの整備状況に大きく依存します。ファイルの分類や共有範囲、アクセス権の設定といったデータの整理状況が、生産性の源泉となっていきます。
しかし、こうした変化への対応が不十分なままAI導入だけ進めてしまうと、現場では以下のような問題が顕在化します。
- AIが権限の範囲内で広くデータにアクセスし、意図しない情報活用が発生する
- アカウントやアクセス制御が追いつかず、リスクが見えにくくなる
- 端末や利用環境のばらつきにより、統制が効かなくなる
- アラートや例外対応が増え続け、運用負荷が逼迫する
これらの問題を防ぐためには、
- データの状態を可視化し、過剰共有を是正できる状態
- アクセスを継続的に評価し、安全な状態を維持できる仕組み
- AIを一つの“アプリケーション”として管理し、権限や変更履歴を追跡できる状態
といった土台を整えることが不可欠です。この土台が整って初めて、AI活用は現実的なものになります。
「土台」を整える3つの具体的アクション
Copilotを活用する場合の土台は、Microsoft365の機能である「Entra ID」「Intune」「Purview」を中心に整備することが可能です。では、具体的に何から着手すべきでしょうか。具体的に解説します。
１．Entra ID：IDを境界にした“アクセス制御”を再設計する
1つ目のアクションは、Entra IDを中心にアクセス制御の前提を見直すことです。
まず着手すべきは、条件付きアクセス（Conditional Access）における例外設定の棚卸しです。多くの環境では、特定のユーザーや端末を例外として許可する設定（除外ポリシー）が残ったままになっています。これらは一時的な対応として設定されたものでも、そのまま放置されることで“恒久的な例外”となり、アクセス制御上の抜け穴になりやすいポイントです。
AI前提の環境では、こうした例外はより大きなリスクになります。Copilotやエージェントは、与えられた権限の範囲を前提に動くため、例外として許可されたアクセス範囲をそのまま広く利用してしまうからです。
そのため、まずは条件付きアクセスの除外設定を洗い出し、どのユーザー・グループが例外になっているのか、その例外が今も必要なのか等を確認することが重要です。
特に、期限が設定されていない例外については、「期限を設定する」「定期的に見直す」といった運用に切り替えていきます。そのようにして「恒久的な例外が存在しない」または「すべての例外が期限付きで管理されている」状態を目指します。この“既存の穴をふさぐ”対応ができて初めて、次の強化が意味を持ちます。
そのうえで、Entra IDの設計として押さえるべきポイントは次の3つです。
- FIDO2やpasskeysを活用し、フィッシング耐性のある認証を標準化する
- Continuous Access Evaluation（CAE）により、状態や場所の変化に応じてセッションを再評価・制御する
- IDを中心に、端末・アプリ・AIの利用を一貫して管理できる構成にする
認証 → セッション制御 → IDの一元化の順で、段階的にID基盤を強化していくことが重要です。こうした設計が整うことで、AIが前提となる環境においても、安全にアクセスを制御できる状態を実現できます。
２．Intune：端末の状態を揃え、アクセス制御を機能させる
2つ目のアクションは、Intuneを使って端末運用の前提を揃えることです。
AI活用が進む環境では、「誰がアクセスするか」だけでなく、「どの状態の端末からアクセスするか」が重要になります。しかし、端末ごとの設定やセキュリティ状態がバラバラなままでは、いくら条件付きアクセスで制御しても十分に機能しません。そのため、まず取り組むべきは、端末の“準拠基準”を明確にすることです。
具体的には、Intuneのコンプライアンスポリシーを用いて、「OSの最小バージョン」「BitLockerなどによるディスク暗号化が有効」「ウイルス対策ソフトが有効」といった最低限のセキュリティ条件を定義します。これらの条件を全社のWindows端末に適用します。重要なのは、単にポリシーを設定することではなく、非準拠端末の一覧が把握でき、その是正フローが運用として回っている状態です。
この基盤が整うと、次の段階に進むことができます。
たとえば、Endpoint Analyticsによる端末状態の可視化や、Autopilotによる端末設定の自動化など、運用の効率化と高度化が現実的になります。ここで重要なのは、Intuneを単なる配布や設定管理のツールとしてではなく、端末の状態を可視化し、継続的に改善するための運用基盤として捉えることです。
また、ライセンスによって目指す運用のレベルも異なります。 E3では、ログや分析機能を活用して端末の健全性を把握し、運用品質の底上げを図ります。一方E5では、特権権限の制御やアプリ管理の強化により、「必要なときだけ権限を与える」「不要なアプリやシャドーITを排除する」といったゼロトラスト型の端末運用へと進めていきます。どちらの場合でも、端末の状態が揃って初めて、アクセス制御が意味を持つという点です。そのため、端末の標準化と状態の可視化は、AI活用の土台として欠かせない要素となります。
３．Purview：データに意味を持たせ、AI活用の土台を作る
3つ目のアクションは、Purviewを使ってデータの「分類と保護」の土台を整えることです。
まず着手すべきは、秘密度ラベルのパイロット導入です。Copilotは既存の権限や保護設定を前提に動くため、ラベルがない状態では機密度に応じた制御や監査が十分に機能しません。そのため、まずはデータに意味づけを行うことが重要になります。
具体的には、「公開」「社内」「機密」「極秘」といった複数段階のラベルを定義し、パイロット部門に自動適用してモニタリングを行います。一定期間の運用を通じて、ラベルが適正に付与され、現場で利用されている状態をひとつの目安とします。一定期間の運用で利用が定着した状態を確認したうえで、段階的に全社展開へと進めていきます。
この取り組みにより、データの「分類と保護」の土台が整います。この土台ができることで、次の対応として、DLPによる誤った共有や持ち出しを防ぐルールの適用や、DSPMによるリスクのあるデータの所在把握、それらの機能を活用した監査や調査の整備といったデータ運用の高度化へと自然につながっていきます。
重要なのは、ラベルを付ければ万全になるわけではないという点です。ラベルは“入口”であり、付いていなければ何も始まりません。AI活用においては、データに意味を持たせることが出発点になります。
3ヶ月で進める現実的なロードマップ
「Entra ID」「Intune」「Purview」によるAI活用の土台づくりについて、少人数体制でも実行できる進め方として、3ヶ月のロードマップを紹介します。
進め方のポイントは、ID・端末・データを並行して扱いながら、段階的に整備していくことです。優先順位をつけて順番に進めても問題ありませんが、今回は全体を意識しながら3ヶ月で土台を整える進め方を想定しています。すべてを一度に完成させるのではなく、「見える化 → 最小構成の整備 → 運用定着」の順で進めます。
1ヶ月目：現状把握と棚卸し
まずは各領域の現状を可視化します。条件付きアクセスの設定状況、端末の準拠率、共有権限の状態などを洗い出し、どこに課題があるのかを明らかにします。
2ヶ月目：最小構成での設計と適用
次に、必要最低限のルールを設計し、実環境に適用します。条件付きアクセスの基本ポリシーや端末の準拠基準、データの秘密度ラベルなど、土台となる仕組みを小さく回し始めます。
3ヶ月目：運用開始と改善
最後に運用フェーズへ進みます。ログやリスク検知をもとに監視を開始し、例外の管理や是正フローを定型化していきます。あわせて、より高度な機能が必要かどうかを評価し、次の施策を検討します。
| 1ヶ月目 棚卸し・現状把握 | 2ヶ月目 最小限の設計・実装 | 3か月目 運用開始・モニタリング |
|---|---|---|
| ID棚卸し Entra IDの利用状況・条件付きアクセスの現状を可視化 | CA基本ポリシー 条件付きアクセスの最重要3ポリシーを設定 | 監視体制の確立 Entraサインインログ・リスク検知の週次レビューを開始 |
| 端末把握 Intuneの登録率・コンプライアンス準拠率を確認 | デバイス準拠・Autopilot 準拠基準を適用＋ゼロタッチ展開を試行 | 例外管理の仕組化 除外ユーザー・デバイスの棚卸しと期限管理を定型化 |
| データ権限 SPO/OneDriveの共有範囲・過剰権限を洗い出し | 機密ラベル導入 秘密度ラベル4段階を設計・パイロット展開 | 次フェーズ判断 E5機能の必要性を評価しStep2への移行計画を策定 |
このロードマップを一通り実行することで、自社環境における課題や強化ポイントが明確になります。その結果、「何に投資すべきか」「何を優先すべきか」の判断がしやすくなります。重要なのは、ID・端末・データの3つを分断せず、確実に前に進めていくことです。
AI活用は「導入」ではなく「土台づくり」から
ここまで見てきた通り、Microsoft 365の価値は機能そのものではなく、それを前提にした運用モデルによって決まります。AIが実行主体となる環境では、権限やデータの状態がそのまま結果に反映されるため、設計次第でリスクが顕在化しやすくなります。 そのため、AI活用は導入から始めるのではなく、ID・端末・データといった土台を整えることから始める必要があります。
最初の一歩として重要なのは、現状を整理し、「何を整えるべきか」を明確にすることです。AI活用は「一気に変える」ものではなく、「土台を整えながら広げていく」ものです。まずは小さく整え、確実に回る状態を作る。その積み重ねが、結果として最も安全で早い進め方になります。
とはいえ、最初の一歩にハードルがあることも事実です。「機能が多すぎて何から手を付ければよいかわからない」「既存の運用との兼ね合いで設計を見直す決断が難しい」こうした悩みは多くの現場で共通しています。
弊社では、この土台づくりの段階からご支援しています。
現状の棚卸しと前提整理や役割分担と運用設計、優先順位付けを含めた現実的なロードマップ策定など、単なるツール導入ではなく、運用モデルそのものを見直すことを前提に、現実的に回る形へと落とし込む伴走型で支援します。まずは現状の整理からでも構いません。ぜひお気軽にご相談ください。
AI時代のMicrosoft 365運用モデルの土台づくり実践ガイド
ダウンロードする
