Microsoft 365 Copilotは、ユーザーがアクセス可能なすべてのSharePointサイト・OneDrive・Teams・メールを学習元として回答を生成します。そのため、過去に設定された「とりあえず全社共有」や「退職者が残したオープンフォルダ」がそのまま情報漏洩リスクになる可能性があります。前回はガイドラインの策定方法を扱いましたが、今回は導入前に実施すべき権限設計と過剰共有の洗い出し手順を解説します。

Copilot導入前に権限設計が必要な理由

Copilotは独自の権限体系を持たず、Microsoft 365の既存のアクセス許可をそのまま尊重します。つまり、あるユーザーがSharePointサイトAにアクセス権を持っていれば、Copilotはサイト内のファイルを参照して回答を生成します。この仕組みは「セキュリティが保たれている」と説明されますが、実態は「現在の権限設定が正しい」ことが前提です。組織によっては、過去のプロジェクト終了後も共有設定が残っている、全社員が閲覧可能なフォルダに機密文書が混在している、といった状態が放置されている場合があります。Copilotはこれらを区別せずに学習元として扱うため、導入前に権限の棚卸しと是正を検討する必要があります。

権限設計を怠ると、営業担当者がCopilotに「今期の戦略を教えて」と尋ねた際、本来アクセスすべきでない他部門の未公開計画書を引用して回答する事態が起こり得ます。これは技術的な不具合ではなく、過剰共有という運用の問題が顕在化した結果です。

過剰共有が生まれる典型的なパターン

  • プロジェクト終了後の放置: 期間限定のTeamsチームやSharePointサイトに、終了後もメンバー全員がアクセス可能なまま残る
  • 「全員」グループへの安易な付与: 「とりあえず見れるようにしておこう」という判断で、全社員を対象にしたセキュリティグループに閲覧権限を与える
  • 外部ユーザーの管理不足: 業務委託先や取引先に付与した共有リンクが期限なしで残り続ける
  • OneDriveの個人共有: 各社員が個別に設定した共有設定が可視化されず、組織として把握できていない

これらは意図的な情報漏洩ではなく、日常業務の中で積み重なった設定ミスです。Copilot導入はこれを見直す機会として位置づけることができます。

権限設計の全体像と実施タイミング

権限設計は、Copilotのライセンス購入前に着手し、パイロット展開の前までに完了させることが推奨されます。具体的には以下の手順で進めます。

手順1: 現状の権限構造を可視化する

最初に、組織内のすべてのSharePointサイト・Teamsチーム・OneDriveについて、誰がどのリソースにアクセスできるかを一覧化します。Microsoft 365管理センターやMicrosoft Graph APIを利用すれば、サイトごとのメンバーリスト・アクセス許可レベル・共有リンクの一覧を取得できます。この段階では、以下の項目を記録します。

  • サイト名・チーム名
  • 所有者・メンバー・閲覧者の人数
  • 外部ユーザーの有無
  • 最終更新日・作成日
  • 「全員」や「全社員」といった広範なグループが含まれているか

この作業は手動では現実的ではないため、PowerShellスクリプトやサードパーティの監査ツールを使います。Microsoft 365 Copilot 導入とオンボード ガイド(IT管理者向け)(Microsoft Learn(公式ドキュメント))でも、導入前の権限レビューが推奨されています。

手順2: 過剰共有を判定する基準を定める

可視化した権限リストを機械的に精査するため、過剰共有と判定する基準を事前に決めます。以下は一例です。

  • メンバー数が一定規模を超えるサイトは要確認
  • 最終更新日が一定期間以上前で、所有者が退職済みのサイトは整理対象
  • 外部ユーザーが含まれるサイトのうち、共有リンクに有効期限が設定されていないものは再設定
  • 「全員」グループに編集権限が付与されているサイトは見直しを検討

これらの基準は、組織の業務実態に合わせて調整します。例えば、全社ポータルや社内規程を格納するサイトは全員アクセスが正当ですが、特定部門のプロジェクトサイトに全員がメンバーとして登録されているのは異常です。判定基準を明文化することで、後の精査作業を複数人で分担できるようになります。

手順3: リスクの高いサイトを抽出し優先順位をつける

手順2で定めた基準に照らし、リスクの高いサイトを抽出します。全サイトを一度に是正するのは現実的ではないため、以下の優先順位で対応します。

  1. 機密情報を含むサイト: 人事評価・財務資料・未公開の戦略文書など、情報分類で「機密」に該当するファイルが格納されている場所
  2. 外部共有が有効なサイト: 取引先・委託先とのやり取りが発生するサイトは、共有範囲の妥当性を個別に確認
  3. 長期間更新されていないサイト: 所有者不在のまま放置されているサイトは、アーカイブまたは削除を検討

優先順位をつけることで、限られたリソースで効率的にリスク低減を図ります。例えば、機密情報を含むサイトが少数であれば、まずそれらを集中的に精査し、残りは段階的に対応します。

手順4: 是正作業を実施する

抽出したサイトごとに、以下のいずれかの対応を実施します。

  • 権限の縮小: 不要なメンバーを削除し、必要最小限のユーザーのみにアクセスを限定
  • 共有リンクの再設定: 有効期限を設け、匿名リンクを廃止し、認証必須のリンクに変更
  • アーカイブまたは削除: 業務上不要になったサイトは、SharePointの保持ポリシーに従ってアーカイブし、アクティブな一覧から除外
  • 所有者の再任命: 退職者が所有しているサイトは、後任の担当者に所有権を移譲

是正作業は各部門の協力が不可欠です。IT部門が一方的に権限を削除すると業務が止まるリスクがあるため、事前に部門長へ是正対象のリストを共有し、確認期間を設けることが推奨されます。確認期間中に異議がなければ、スケジュールに沿って是正を実行します。

手順5: 是正後の状態を記録し継続監査の体制を作る

是正作業が完了したら、その時点での権限構造をベースラインとして記録します。以降は、定期的に同じ基準で監査を実施し、新たな過剰共有が発生していないかを確認します。この継続監査は、Copilot導入後も維持すべき運用プロセスです。

監査結果は、サイト数・是正件数・リスクレベルの推移をダッシュボードで可視化し、経営層へ定期報告します。これにより、権限管理が形骸化せず、組織の統制が保たれます。

権限設計で押さえるべき技術的ポイント

SharePointのアクセス許可レベルの理解

SharePointには「フルコントロール」「デザイン」「編集」「投稿」「読み取り」という標準のアクセス許可レベルがあります。過剰共有の多くは「編集」権限を安易に付与することで生じます。業務上、閲覧のみで十分なユーザーには「読み取り」を与え、編集が必要な場合も「投稿」で事足りるケースが多くあります。フルコントロールは管理者のみに限定することが推奨されます。

Microsoft EntraID(旧Azure AD)のグループ管理

SharePointやTeamsの権限は、多くの場合Microsoft EntraIDのセキュリティグループまたはMicrosoft 365グループを介して付与されます。グループのメンバーシップが正しく管理されていないと、退職者や異動者がアクセス権を保持し続ける可能性があります。グループの定期的な棚卸しと、動的グループ(属性ベースで自動メンバー管理)の活用により、手動更新の負担を減らすことができます。

条件付きアクセスと情報保護ラベルの併用

権限設計は「誰がアクセスできるか」だけでなく、「どの環境からアクセスできるか」も含めて設計します。Microsoft EntraIDの条件付きアクセスポリシーを用いれば、社内ネットワークからのみアクセス可能にする、多要素認証を必須にする、といった制御が可能です。また、Microsoft Purview情報保護ラベルを使い、ファイル単位で「社外共有禁止」「暗号化必須」といったポリシーを適用すれば、誤って広範に共有された場合でもリスクを抑制できます。

組織体制と責任分担

権限設計は技術作業だけでなく、組織横断のプロジェクトとして位置づけることが推奨されます。以下の役割分担を明確にします。

  • プロジェクトオーナー(経営層または情報システム部門長): 全体スケジュールと予算を承認し、各部門への協力要請を行う
  • IT部門: 権限の可視化・スクリプト実行・是正作業の技術実施を担当
  • 各部門の管理者: 自部門のサイト・チームについて、メンバーの妥当性を確認し、不要なアクセス権の削除を判断
  • 情報セキュリティ部門: 是正基準の策定・監査結果のレビュー・リスク評価を担当

各部門の管理者が「自分のチームは問題ない」と判断しがちなため、IT部門または情報セキュリティ部門が客観的な基準で精査を行い、必要に応じてエスカレーションする仕組みを作ります。

よくある失敗パターンと対処法

失敗例1: 一度の是正で終わらせる

Copilot導入前に大規模な是正を行っても、導入後に新たなサイトやチームが日々作られるため、時間経過とともに元の状態に戻る可能性があります。対処法は、サイト作成時に自動的に権限レビューのリマインダーを設定する、または作成から一定期間後に自動監査を実行する仕組みを導入することです。

失敗例2: 現場の反発を想定せずに進める

IT部門が一方的に権限を削除すると、「業務に必要なファイルが見れなくなった」というクレームが発生する可能性があります。対処法は、是正の事前に対象サイトの所有者へ通知メールを送り、確認期間を設けることです。また、是正理由を「Copilot導入に伴うセキュリティ強化」と明示することで、組織全体の取り組みであることを理解してもらいます。

失敗例3: 外部共有を全面禁止にする

過剰共有を恐れるあまり、SharePointの外部共有機能そのものを無効にすると、取引先との資料共有ができなくなり、かえってメール添付やUSBメモリといった統制外の手段が増える可能性があります。対処法は、外部共有を禁止するのではなく、承認フローを設ける、有効期限を必須にする、共有先ドメインをホワイトリストで管理する、といった段階的な制御を行うことです。

権限設計完了後のチェックリスト

以下の項目が完了していることを確認してから、Copilotのパイロット展開へ進むことが推奨されます。

  • 全SharePointサイト・Teamsチームの権限が一覧化され、リスク判定が完了している
  • 機密情報を含むサイトへのアクセスが、必要最小限のユーザーに限定されている
  • 外部共有リンクに有効期限が設定され、匿名リンクが存在しない
  • 所有者不在のサイトが整理されている、またはアーカイブ済みである
  • 継続監査の体制とスケジュールが合意され、責任者が任命されている
  • 各部門の管理者が是正内容を承認し、運用ルールを理解している

権限設計とガバナンスの関係

権限設計は、Copilot導入におけるガバナンスの土台です。前回扱った利用ガイドラインが「何をしてよいか・悪いか」を定めるのに対し、権限設計は「誰が何にアクセスできるか」を物理的に制御します。両者は車の両輪であり、ガイドラインだけでは防げない技術的なリスクを、権限設計が補完します。

AI導入時の情報資産管理の重要性は、セキュリティ専門機関でも指摘されており、権限設計はその具体的な実践手段として位置づけられます。

まとめ

Microsoft 365 Copilotは既存の権限を前提に動作するため、過剰共有が放置されている環境では、導入直後から情報漏洩リスクが顕在化する可能性があります。導入前に現状の権限を可視化し、リスクの高いサイトを優先的に是正し、継続監査の体制を整えることで、Copilotを安全に活用できる基盤が整います。権限設計は一度で終わる作業ではなく、組織の成長とともに進化させるべきプロセスです。次回は、権限設計を実施した後も残る情報漏洩リスクと、それを防ぐための設定と体制について掘り下げます。

よくある質問

Copilot導入前の権限設計はどのくらいの期間が必要ですか?

組織の規模とSharePointサイト数に依存します。権限の可視化と基準策定、各部門との調整と是正作業、継続監査体制の構築を段階的に進める必要があります。サイト数が多い場合や、過去に大規模な組織再編があった場合は、さらに期間を要することがあります。

権限設計を外部委託することは可能ですか?

可視化と是正作業の技術的な部分は外部へ委託可能ですが、各サイトのメンバーが妥当かどうかの判断は、業務内容を理解している社内の管理者が行う必要があります。外部委託する場合は、委託先が権限リストを抽出し、社内で判定基準に照らして精査する分業体制が現実的です。委託先の選定では、Microsoft 365の管理経験とセキュリティ知識を持つベンダーを選びます。

過剰共有の是正後、業務に支障が出た場合の対処法は?

是正前に各部門へ通知し確認期間を設けることで、多くの問題は防げますが、それでも「必要なファイルが見れなくなった」という報告が発生する可能性があります。対処法として、是正実施後一定期間はヘルプデスクの体制を強化し、報告があったサイトについては個別に権限を再付与します。ただし再付与は、申請者の上長承認を必須とし、無条件には戻さないルールを設けます。

OneDriveの個人共有も権限設計の対象に含めるべきですか?

含めることが推奨されます。OneDriveは個人のファイル保管場所ですが、ユーザーが自由に共有リンクを発行できるため、組織として把握しづらい過剰共有が発生しやすい場所です。Microsoft 365管理センターやMicrosoft Graph APIを使い、全ユーザーのOneDrive共有リンクを一覧化し、外部共有や匿名リンクが存在する場合は是正対象とします。

Copilot導入後に新しいTeamsチームを作る際のルールはどうすべきですか?

Teamsチーム作成時に、所有者が自動的に権限レビューのリマインダーを受け取る仕組みを設定します。具体的には、チーム作成から一定期間後に所有者へメールを送り、メンバーの見直しを促します。また、チーム作成時にテンプレートを用意し、デフォルトで「全員」グループが含まれないようにすることで、過剰共有の発生を防ぎます。