SharePointでは、サイトだけでなくドキュメントライブラリ、フォルダー、ファイルなどにも個別のアクセス許可を設定できます。
細かく設定できるため便利ですが、「設定できる」ことと「設定した方がよい」ことは別です。
権限を細かく分けすぎると、誰がどのファイルへアクセスできるのか分かりにくくなり、異動や退職時のメンテナンスも複雑になります。
先に結論をまとめると、SharePointの権限は、できるだけ上位の単位でグループに対して設定し、その権限を下位へ継承させることを基本にすると管理しやすくなります。
| 権限を分ける単位 | 当サイトでの推奨 | 主な用途 |
|---|---|---|
| サイト | ◎ | 利用者・業務・管理主体そのものを分ける |
| ライブラリ | ◎ | 同じサイト内で一部のファイル群だけアクセス範囲を分ける |
| フォルダー | △ | 少数の例外的なアクセス制御 |
| ファイル | △～× | 一時的・限定的な共有 |
下位の単位で権限を設定すること自体が悪いわけではありません。
問題になるのは、個別の権限設定が増え、管理者が全体を把握できなくなることです。
SharePointのサイト・ライブラリ・フォルダーの違いについては、以下の記事も参考にしてください。
SharePointのサイト・ライブラリ・フォルダーの違い｜どう使い分ける？
- SharePointの権限は基本的に親から子へ継承される
- 権限継承を停止するとどうなる？
- SharePointの権限は個人ではなくグループで管理する
- Owners・Members・Visitorsとは
- サイト単位で権限を分けるケース
- ライブラリ単位で権限を分けるケース
- フォルダー単位の個別権限は使ってはいけない？
- ファイル単位の権限は一時的・例外的な用途にする
- 権限を細かくしすぎると何が問題になる？
- SharePointの権限はどの単位で設定する？
- SharePointの権限設計で迷ったときの判断フロー
- SharePointの権限設計でおすすめする6つのルール
- SharePointの権限設計例
- 権限継承を切る前に確認すること
- SharePointの権限設計まとめ
SharePointの権限は基本的に親から子へ継承される
SharePointでは、アクセス許可を親から子へ引き継ぐ権限継承という仕組みがあります。
概念的には次のようになります。
サイト │ │ 権限を継承 ↓ ドキュメントライブラリ │ │ 権限を継承 ↓ フォルダー │ │ 権限を継承 ↓ ファイル
たとえば、営業部サイトを営業部のメンバーが利用できるように設定した場合、その配下のライブラリやファイルも、基本的には親からアクセス許可を引き継ぎます。
営業部サイト │ │ 営業部メンバー │ ├─ 共有ライブラリ │ │ │ ├─ 営業資料 │ └─ マニュアル │ └─ 案件ライブラリ
すべて同じメンバーが利用するのであれば、ライブラリやフォルダーごとに同じ権限を設定し直す必要はありません。
権限継承を利用することで、管理する権限設定の数を減らせます。
権限継承を停止するとどうなる？
SharePointでは、必要に応じて親からの権限継承を停止し、そのライブラリやフォルダーなどに固有のアクセス許可を設定できます。
たとえば、営業部サイト内の契約関連ライブラリだけ利用者を限定する場合です。
営業部サイト
│
│ 営業部メンバー
│
├─ 共有ライブラリ
│ └─ 営業部メンバー
│
└─ 契約関連ライブラリ
↑
権限継承を停止
↓
一部メンバーのみ
継承を停止すると、そのライブラリは親サイトとは異なる権限を持つようになります。
その配下のフォルダーやファイルは、さらに固有権限を設定しない限り、新しく設定したライブラリ側の権限を継承します。
ここで覚えておきたいのが、次の考え方です。
「権限継承を切る＝独立して管理する権限設定を1つ増やす」
継承を停止すること自体に問題はありません。
しかし、10か所、20か所、50か所と増えていけば、それぞれについて「誰がアクセスできるか」を管理する必要があります。
そのため、権限継承は必要な場所だけで停止する方が管理しやすくなります。
SharePointの権限は個人ではなくグループで管理する
SharePointの権限設計では、ユーザーを1人ずつ直接追加するよりも、グループを使って管理することを基本にします。
たとえば、次のように個人単位で設定するとします。
営業部サイト 山田さん：編集 佐藤さん：編集 鈴木さん：編集 田中さん：編集
この方法でも利用できますが、人数が増えるほど管理が大変になります。
代わりに、次のようにグループを利用します。
営業部メンバー
│
├─ 山田さん
├─ 佐藤さん
├─ 鈴木さん
└─ 田中さん
↓
営業部サイト
→ 営業部メンバー：編集
この構成であれば、担当者が変わったときはグループのメンバーを変更することで対応できます。
- 入社：グループへ追加
- 異動：所属グループを変更
- 退職：グループから削除
サイトやライブラリごとの権限設定を毎回変更する必要が減ります。
人が変わっても、権限設計そのものを変更しなくてよい構成にすることが重要です。
Owners・Members・Visitorsとは
SharePointでは、サイトのアクセス管理で次のような役割が使われます。
| グループ | 基本的な役割 |
|---|---|
| Owners | サイトを管理するユーザー |
| Members | サイト内のコンテンツを編集するユーザー |
| Visitors | 主に閲覧するユーザー |
ただし、Microsoft 365のSharePointでは、すべてのサイトを必ずこの3つだけで管理するわけではありません。
Microsoft 365グループに接続されたチームサイトでは、Microsoft 365グループの所有者やメンバーとSharePointサイトの権限が連携します。
そのため、実際の権限設計ではサイトの種類やMicrosoft 365グループとの関係も確認する必要があります。
この記事では具体的な追加・変更手順ではなく、権限をどの単位で管理するべきかを中心に解説します。
サイト単位で権限を分けるケース
利用するユーザーや業務そのものが大きく異なる場合は、サイト単位で分離する方法が最も分かりやすくなります。
たとえば次のような構成です。
営業部サイト → 営業部メンバー 人事部サイト → 人事部メンバー 経理部サイト → 経理部メンバー
サイトごとに利用者が明確に異なるため、各サイトの基本権限をそのまま配下へ継承できます。
特に次の条件が異なる場合は、サイト分割を検討します。
- 利用するユーザー
- 業務の目的
- 管理担当者
- 外部共有などのセキュリティ方針
部署ごとのサイト設計については、以下の記事で詳しく解説しています。
SharePointは部署ごとにサイトを分けるべき？設計の判断基準と具体例
ライブラリ単位で権限を分けるケース
サイトを利用するユーザーはほぼ同じでも、一部のファイル群だけアクセス範囲を変えたい場合は、ライブラリ単位の権限分離が有力です。
たとえば次のような構成です。
営業部サイト
│
├─ 共有ライブラリ
│ → 営業部メンバー全員
│
└─ 契約関連ライブラリ
→ 一部メンバーのみ
営業部サイトそのものを2つに分けるほどではありませんが、契約関連資料だけ利用者を限定したいケースです。
この場合、契約関連ライブラリで親サイトからの権限継承を停止し、必要なグループへアクセス許可を設定する方法があります。
サイトとライブラリのどちらで分けるべきかについては、以下の記事でも詳しく解説しています。
SharePointはサイトとライブラリのどちらで分ける？設計の判断基準
フォルダー単位の個別権限は使ってはいけない？
SharePointではフォルダー単位で固有のアクセス許可を設定できます。
そのため、フォルダー単位の権限設定を完全に禁止する必要はありません。
たとえば、通常は営業部全員が利用するライブラリの中に、一時的な特別案件のフォルダーがある場合です。
共有ライブラリ
│
├─ 営業資料
├─ マニュアル
│
└─ 特別案件
↑
一部メンバーのみ
このように例外が少数で、管理対象が明確であれば、フォルダー単位の固有権限を利用する選択肢があります。
しかし、次のような状態になった場合は注意が必要です。
共有ライブラリ │ ├─ 営業担当者のみ ├─ 管理者のみ ├─ プロジェクトAのみ ├─ プロジェクトBのみ ├─ 特定担当者のみ └─ 外部共有用
フォルダーごとに異なる権限が大量に設定されると、誰が何へアクセスできるのか把握しにくくなります。
このような状態になってきたら、フォルダー権限を追加し続けるのではなく、ライブラリやサイトの分け方を見直してください。
ファイル単位の権限は一時的・例外的な用途にする
SharePointでは個別のファイルを特定のユーザーへ共有することもできます。
たとえば、1つの資料だけ一時的に別の担当者へ共有するといった利用方法です。
一方、次のような運用を恒常的に続けるのはおすすめしません。
契約書A → Aさん 契約書B → Bさん 契約書C → Cさん 契約書D → Dさん
ファイル単位で権限が大量に異なると、サイトやライブラリを見ただけではアクセス範囲を把握できなくなります。
また、個別のファイルを共有すると、そのアイテムが親とは異なる固有権限を持つことがあります。
一時的な共有であればファイル単位、恒常的な業務ルールであればサイトまたはライブラリへ昇格させると考えると管理しやすくなります。
権限を細かくしすぎると何が問題になる？
SharePointの権限を細かく設定しすぎると、最初は便利でも、時間が経つほど管理が難しくなります。
主な問題は次のとおりです。
- 誰がどの情報へアクセスできるのか分かりにくくなる
- 異動時の権限変更が増える
- 退職者のアクセス整理漏れが発生しやすくなる
- 管理者しか権限構造を理解できなくなる
- アクセスできない原因を調査しにくくなる
- 意図しない共有に気付きにくくなる
- 定期的な権限レビューが難しくなる
特に危険なのは、特定の管理者だけが「なぜこの人だけアクセスできるのか」を理解している状態です。
その担当者が異動・退職すると、権限設計そのものがブラックボックス化します。
正常時に使えることだけでなく、数年後に別の管理者が見ても理解できるかまで考えて設計してください。
SharePointの権限はどの単位で設定する？
当サイトでは、次の順番で検討することをおすすめします。
第1候補：サイト
利用者や業務そのものが異なる場合です。
利用者・業務が大きく違う
↓
サイトを分ける
第2候補：ライブラリ
サイトの利用者はほぼ共通しているものの、一部のファイル群だけアクセス範囲が異なる場合です。
サイト利用者はほぼ同じ
一部のファイル群だけ違う
↓
ライブラリを分ける
第3候補：フォルダー
サイトやライブラリを分けるほどではない、少数の例外に使用します。
少数の例外だけ
↓
フォルダー固有権限を検討
第4候補：ファイル
一時的・限定的な共有で使用します。
一時的な例外
↓
ファイル共有を検討
下位になるほど例外的な用途として扱うことがポイントです。
SharePointの権限設計で迷ったときの判断フロー
権限をどこで分けるべきか迷った場合は、次の順番で考えます。
利用するユーザーが
大きく違う？
│
┌────┴────┐
YES NO
│ │
↓ ↓
サイトを 一部のファイル群だけ
分ける アクセス対象が違う？
│
┌────┴────┐
YES NO
│ │
↓ ↓
ライブラリ 少数の例外だけ？
を分ける │
┌────┴────┐
YES NO
│ │
↓ ↓
フォルダー等 サイト・ライブラリ
の固有権限 設計を再確認
を検討
このフローは絶対的なルールではありませんが、個別権限を必要以上に増やさないための判断基準として利用できます。
SharePointの権限設計でおすすめする6つのルール
SharePointを長期間管理するのであれば、次の6つを基本ルールとしておくと権限が複雑になりにくくなります。
1．個人ではなくグループへ権限を付ける
担当者変更のたびにサイトやライブラリの権限を変更するのではなく、グループのメンバー変更で対応できる構成にします。
2．可能な限り親から権限を継承する
同じ利用者が使用する場所では、同じ権限を個別設定せず、親の設定をそのまま継承します。
3．利用者が大きく違うならサイトを検討する
独立した業務や利用者を、1サイト内の細かな個別権限だけで無理に管理しないようにします。
4．一部のファイル群だけ違うならライブラリを検討する
サイトを分割するほどではないアクセス差は、ライブラリで整理できないか確認します。
5．フォルダー・ファイルの固有権限は例外扱いにする
使用禁止ではありませんが、基本設計として大量に作らないようにします。
6．必要以上に高い権限を与えない
閲覧だけでよいユーザーへ編集権限を付与するなど、業務上必要のないアクセス許可は与えないようにします。
権限は「念のため広く付ける」のではなく、業務に必要な範囲だけ付与することが基本です。
SharePointの権限設計例
たとえば、営業部でSharePointを利用する場合は次のような構成を検討できます。
営業部サイト
│
├─ 共有ライブラリ
│ → 営業部メンバー
│
├─ 契約関連ライブラリ
│ → 契約関連グループ
│
└─ マニュアルライブラリ
→ 営業部メンバー
別の業務で利用者そのものが異なる場合は、別サイトとして管理します。
人事部サイト → 人事部メンバー
この構成であれば、通常の営業資料は営業部サイトから権限を継承し、契約関連資料だけライブラリ単位でアクセス対象を分けられます。
個々のファイルやフォルダーへ大量の固有権限を設定する必要もありません。
権限継承を切る前に確認すること
ライブラリやフォルダーで権限継承を停止する前に、次の4点を確認してください。
- このアクセス差は一時的ではなく継続するのか
- グループ単位で管理できるか
- ライブラリを分けた方が分かりやすくならないか
- サイトそのものを分けるべき業務ではないか
この4点を確認して、それでも個別権限が必要であれば設定します。
逆に、例外対応を繰り返すうちに固有権限が増えてきた場合は、権限設定を追加するよりもSharePoint全体の構造を見直した方がよい可能性があります。
SharePointの権限設計まとめ
SharePointではサイト・ライブラリ・フォルダー・ファイルなど、さまざまな単位でアクセス許可を設定できます。
しかし、細かく設定できるからといって、細かく設定することが最適とは限りません。
基本的には次の順番で考えます。
- 利用者や業務が大きく異なる → サイト
- 一部のファイル群だけアクセス範囲が異なる → ライブラリ
- 少数の例外 → フォルダー
- 一時的な例外 → ファイル
そして、可能な限り個人ではなくグループへ権限を付与し、親から子へ権限を継承させます。
特に覚えておきたいのが、「権限継承を切る＝独立して管理する権限設定を1つ増やす」という考え方です。
固有権限を設定するたびに、その設定を将来も管理し続ける必要があります。
「この権限を設定できるか」ではなく、「担当者が変わっても管理できるか」まで考えて設計することが、SharePointの権限を複雑にしないポイントです。
SharePointのサイト・ライブラリ設計、同期、NAS、バックアップなども含めて確認したい場合は、SharePoint Onlineの使い方・設計まとめをご覧ください。
