社内の共有ファイルについて、「この権限はどうなっているのだろう」と思うことはないでしょうか。
以前のファイルサーバーであれば、部門ごとのフォルダにアクセス権を設定し、「どこに置くか」を決めれば「誰に見せるか」もおおむね決まりました。しかし現在は、Teams、SharePoint、OneDrive、メール添付、PCへのダウンロードと、ファイル共有の経路がかつてよりも増えています。共有の便利さとは裏腹に、権限管理はむしろ分かりにくくなっているのではないでしょうか。
またMicrosoft 365 Copilotの利用をきっかけに、「こんな社内情報まで検索や要約の対象になるのか」と気づくこともあります。ただし、これはAIの問題と言うよりは、ファイルの共有範囲やアクセス権が適切だったかどうか、以前から存在していた情報管理の課題が浮き彫りになったと考えることもできます。
今回は、権限管理を考えるうえで重要となるMicrosoft 365の「秘密度ラベル(Sensitivity labels)」について、ファイルサーバーからRMS、AIPへと続く変遷を振り返りつつ、「なぜこの仕組みが必要になったのか」を見ていきましょう。
01 ファイルサーバーでは「どこに置くか」で情報を管理していた
社内のファイルサーバーを長く使ってきた企業では、フォルダ(ディレクトリ)ごとにアクセス権を設定していることが多いと思います。たとえば次のような構成です。

人事部の社員だけが人事部フォルダにアクセスでき、その中の給与・人事情報フォルダはさらに限られた担当者だけが開ける。階層ごとにアクセス権を設定して管理するという考え方です。
ただし、フォルダのアクセス権が守っているのは、基本的に「ファイルが置かれている場所」であり、ファイルそのものではありません。フォルダから取り出したファイルをPCへコピーしたり、メールに添付したりすると、元のフォルダに設定されていたアクセス権は関係なくなります。「このフォルダに誰がアクセスできるのか」と「このファイルを誰が開けるか」は別の概念です。
02 保存場所から出たファイルをどう守るか―RMSの登場
そこで登場したのが、Rights Management Services(RMS)です。RMSはWindows Serverの機能として2003年に登場し、その後クラウドサービスのAzure Rights Management(Azure RMS)へと発展しました。
RMSでは、ファイルそのものを暗号化し、「誰が利用できるのか」「閲覧だけか、編集もできるのか」といった利用権限を情報と結び付けます。利用時にはユーザーを認証し、設定された利用権限に従ってファイルを開く仕組みです。
これにより、ファイルサーバーでの「この場所に誰がアクセスできるか」という管理に加えて、「このファイルを誰が利用できるか」を管理できるようになりました。ファイルが別の場所へ移動しても、権限のない人には中身を見せない。保存場所を中心に考えていたファイル管理からの大きな変化でした。

03 どのファイルを守るのか―RMSからAIPへ
ただし、ここで次の問題が出てきます。社内には、製品カタログ、会議資料、見積書、顧客リスト、給与情報、経営会議の資料など、様々なレベルのファイルがあります。Webサイトで公開している製品カタログと未発表の経営計画を、同じ強度で保護する必要はありません。
そこで必要になるのが、「この情報はどの程度重要なのか」という分類です。
Microsoftは2016年6月、Azure Information Protection(AIP)を発表しました。AIPは、Azure RMSによる保護と、2015年に買収したSecure Islands社のデータ分類・ラベル付け技術を組み合わせたサービスです。Microsoftは発表時、その中核機能を「分類し、ラベルを付け、保護する(classify, label and protect)」と説明しています。
単に「ファイルを保護する」のではなく、その前に「ファイルの情報分類を決める」という段階が加わったのです。たとえば「公開可能」「社内限定」「機密」と分類し、「機密」のラベルには暗号化などの保護を組み合わせる、といった運用ができます。
ファイルを保護する仕組みだけではなく、ファイルの重要度を決めて運用する。RMSからAIPへの変化は、そうした情報管理の考え方の変化を表しています。

04 AIPから現在の「秘密度ラベル」へ
その後Microsoftは、AIPで導入したラベルの仕組みを、当時のOffice 365の各サービスへ統合していきます。2018年9月には統合ラベル(unified labeling)のプラットフォームが発表され、2019年4月にはAIP統合ラベルクライアントが一般提供されました。AIPで使われていたラベルは「秘密度ラベル(Sensitivity labels)」として共通化され、現在はMicrosoft Purview Information Protectionの機能としてMicrosoft 365に組み込まれています。
変わったのは名称だけではありません。AIPでは主にファイルやメールを対象としていたラベルの考え方が、現在ではTeamsやMicrosoft 365グループ、SharePointサイト、会議などにも広がっています。たとえばSharePointサイトを機密性の高い場所として分類し、ゲストアクセスなどを制御するといった使い方もできます。
一方、「情報を分類し、必要に応じて保護する」という基本的な考え方はAIPから変わっていません。「機密」というラベルを付けて分類するだけの運用もできれば、暗号化を組み合わせて、閲覧や編集ができるユーザーを制御することもできます。
つまり現在の秘密度ラベルは、AIPで登場した分類と保護の考え方を引き継ぎ、その対象をMicrosoft 365全体へ広げたものと考えると分かりやすいでしょう。

05 なぜ今、秘密度ラベルを考える必要があるのか
ファイルサーバーが中心だった頃は、「ファイルサーバー → 部門フォルダ → ファイル」という比較的シンプルな構造で情報を管理できました。
現在のMicrosoft 365では、その構造が大きく変わっています。ファイルはSharePointやOneDriveに保存され、Teamsから共有されることもあれば、共有リンクを使って社内外の人とやり取りすることもあります。さらに、TeamsやSharePointサイト、Microsoft 365グループといった、情報を共有する「場所」そのものにも、それぞれ公開範囲やアクセス条件があります。
つまり、管理する対象は「どのフォルダにファイルを置くか」だけではなくなりました。ファイルやメールはどのような情報なのか、どのチームやサイトで扱うのか、誰と共有してよいのか。こうした複数の視点で情報を管理する必要があります。
さらにCopilotを使い始めると、「こんな資料も検索できたのか」と気づくことがあります。Copilotによって、利用者に新たなアクセス権が与えられるわけではありません。もともと閲覧できる状態だった情報が、検索や要約によって見つけやすくなったのです。だからこそ、誰がアクセスできるかだけでなく、その情報をどう扱うべきかを整理しておく必要があります。
こうした環境で、情報の重要度を示し、その扱い方につなげるための共通の目印となるのが秘密度ラベルです。
06 「場所」と「情報」、2つの管理を組み合わせる
では、秘密度ラベルを導入すれば、フォルダやSharePointのアクセス権管理は不要になるのでしょうか。もちろんそうではありません。むしろ実務では、「場所」と「情報」の2つをどう組み合わせるかが重要です。
人事部を例に考えてみましょう。人事部のSharePointサイトは、人事部のメンバーだけがアクセスできるようにする。これが「場所」の管理です。しかし、人事部で扱う情報がすべて同じ重要度とは限りません。そこで、情報そのものにも分類を持たせます。
| 情報の例 | 秘密度ラベル | アクセスを制御する方法 |
|---|---|---|
| 全社向け人事制度資料 | 社内限定 | 全社向けサイトのアクセス権 |
| 人事部内の業務資料 | 社内限定 | 人事部サイトのアクセス権 |
| 個人情報・給与情報 | 機密 | サイトのアクセス権+必要に応じて暗号化 |
ここでのポイントは、同じ「社内限定」でも、置き場所によって実際に扱える人は変わることです。一方、特に重要な情報には、保存場所だけに頼らず、必要に応じてファイル自体にも暗号化などの保護を持たせる。こうして「誰がその場所に入れるのか」と「その情報を誰が扱えるのか」を分けて設計します。
Microsoft 365では、TeamsやSharePointサイトといった「場所」側にも秘密度ラベルを設定できます。こちらは、ゲストアクセスや外部共有など、サイトやチームの利用条件を設定するためにも利用できます。
ただし、サイトに付けたラベルが、そのまま中のファイルへ同じラベルとして適用されるわけではありません。「場所の管理」と「ファイルの分類・保護」は別の仕組みとして考えることが重要です。
07 秘密度ラベルは細かく作ればよいわけではない
実際に導入するとしたら、何種類のラベルを作ればよいのでしょうか。厳密に管理しようとすると、「社外秘」「部外秘」「機密」「重要機密」「個人情報」「顧客情報」など、細かく分類したくなるかもしれません。
利用者がラベルを選ぶ運用では、分類が多すぎると「この資料は社外秘なのか、部外秘なのか」と迷いやすくなります。Microsoftも、まず組織の分類体系(taxonomy)を定め、それぞれのラベルの意味や、どのような情報が該当するのかを利用者が理解できるようにすることを推奨しています。大切なのは、最初から細かな分類を作り込むことではなく、自社で実際に判断できる分類にすることです。
たとえば考え方を整理するために、次のような3段階から検討してみることもできます。
| ラベル | 対象となる情報 |
|---|---|
| 公開可能 | 社外へ公開しても問題のない情報 |
| 社内限定 | 社員は利用できるが、原則として社外へ公開しない情報 |
| 機密 | 利用できる社員や部門を限定すべき情報 |
重要なのはラベルの数ではなく、社員が「この情報はどう扱えばいいのか」を判断できることです。そのうえで「機密」に相当する情報は暗号化するのか、外部共有をどこまで認めるのか、誰まで閲覧できるのか、といった具体的なルールを決めていきます。秘密度ラベルは、設定して終わりの機能ではありません。会社としての情報管理ルールを、実際のMicrosoft 365の運用に結び付けるための仕組みとして考える必要があります。
08 まとめ
ファイルサーバーの時代には、フォルダを分けてアクセス権を設定する方法が分かりやすく合理的でした。ファイルが保存場所の外へ移動するようになると、RMSがファイルそのものを保護する考え方を加え、AIPは「分類し、ラベルを付け、保護する」という流れを明確にしました。現在の秘密度ラベルは、その延長線上にあります。
秘密度ラベルは、まったく新しい発想から生まれたセキュリティ機能ではなく、情報の使われ方が変わるたびに「どうすれば適切に管理できるのか」を考えてきた結果なのです。
Teams、SharePoint、OneDriveによってファイルの保存・共有の方法がさらに増えた今、次の2つを組み合わせて考えることが求められます。
- 「どこに置くか」を管理する(サイト・チーム・フォルダのアクセス権)
- 「その情報は何なのか」を管理する(秘密度ラベルによる分類と保護)
こうした考え方は、ゼロトラストセキュリティにもつながります。ゼロトラストでは「社内ネットワークの中にあるから安全」とは考えず、利用者や端末、アクセスする情報などをもとにアクセスを判断します。同じように、「このフォルダに入っているから安全」と考えるのではなく、情報そのものに分類と保護を持たせる秘密度ラベルは、ゼロトラストにおける「データの保護」を支える仕組みの一つです。
秘密度ラベルの導入そのものを目的にするのではなく、まずは自社にどんな情報があり、誰が扱うべきなのかを整理してみる。そこから始めることが、複雑になったMicrosoft 365の情報管理を見直す第一歩になるでしょう。
ドコモソリューションズのMicrosoft 365運用支援
Microsoft 365の情報管理を見直す際には、製品の設定だけでなく、現在の共有方法や権限設定、情報の分類ルールを整理することが重要です。ゼロトラストセキュリティの考え方とあわせて、ファイルの権限管理についてもドコモソリューションズへお気軽にご相談ください。
参考資料
- Microsoft「Announcing Azure Information Protection」(2016年6月)
- Microsoft「The Azure Information Protection unified labeling client is now generally available」(2019年4月)
- Microsoft Learn「秘密度ラベルの詳細」
- Microsoft Learn「秘密度ラベルを使用してコラボレーション ワークスペース (グループとサイト) を保護する」
- Microsoft Learn「Microsoft 365 Copilotやその他のジェネレーティブ AI アプリに対する Microsoft Purview データセキュリティとコンプライアンス保護」
- Microsoft Learn「Azure Information Protection (AIP) の統合ラベル付けクライアントについて学ぶ」
- Microsoft Learn「Microsoft Purviewを使用したデータ ガバナンスとセキュリティ ベースライン」
- Microsoft Learn「Zero Trustを使用してデータをセキュリティで保護する」
商標について
※Microsoft、Microsoft 365、Microsoft Teams、SharePoint、OneDrive、Outlook、Word、Excel、PowerPoint、Microsoft 365 Copilot、Microsoft Purview、Azure、Windows Serverは、Microsoft Corporationの米国およびその他の国における商標または登録商標です。