「メールセキュリティ グループ（Azure AD / Microsoft Entra ID）」を丸ごと SharePoint に紐づけて運用していると、特定ユーザーだけを“特定 1 フォルダー以外の全フォルダー”から除外したいという現場ニーズが必ず出てきます。本記事では、SharePoint 権限モデルの前提と回避不能な制約を明確化し、現実解となる 3 つのアプローチ（継承停止／分離／グループ見直し）を、手順・スクリプト・運用設計まで踏み込んで解説します。
目次
前提と課題の整理
状況は次のとおりです。
- 会社の メールセキュリティ グループ（Microsoft Entra ID 旧 Azure AD のセキュリティ グループ）が、SharePoint の 8 フォルダーすべてにアクセスできる。
- 新入社員 1 名だけを、「特定の 1 フォルダーだけ許可」し、それ以外の 7 フォルダーからは除外したい。
- しかし思いつく方法は、
（a）グループごと権限を外す／（b）すべてで継承を切って個別調整／（c）そのユーザーをグループから外し必要フォルダーだけ個別付与──のみ。
┌─ メールセキュリティ グループ │ ├─ Folder A（許可） │ ├─ Folder B（許可） │ ├─ Folder C（許可） │ ├─ ... │ └─ Folder H（許可） └─ 新入社員（1名）だけを「Folder X 以外」から除外したい
結論：現行モデルでは「否定（Deny）パーミッション」はありません
SharePoint の権限モデルは「許可ベース（Allow）」であり、特定ユーザーに対してグループの権限を打ち消す否定的（Deny）パーミッションは存在しません。したがって、「このユーザーだけはグループ権限を無効にする」という指定はできません。実現するには、次のいずれかの方針が必要になります。
- 問題のフォルダーで継承を停止し、専用グループに付け替える。
- 制限対象フォルダーを、別ライブラリ（または別サイト）へ分離する。
- ユーザーをメールセキュリティ グループから外し、SharePoint 用の代替グループで必要なフォルダーだけ許可する。
以下、それぞれの特徴と実装を整理します。
3 つの現実的アプローチの比較
| 方法 | 概要 | 長所 | 短所・注意点 |
|---|---|---|---|
| A. 継承停止＋専用グループ | 該当フォルダーだけ権限継承を停止し、ResourceCenter_ReadOnly などの専用 SharePoint グループを作って付与。除外したいユーザーはそのグループに入れない。 | 既存のメールセキュリティ グループを維持できる／影響範囲を最小化しやすい／管理画面からアクセス権の意図を可視化しやすい。 | 継承停止の箇所が増えるほど権限の複雑さと棚卸しコストが上がる。ユニーク権限の数が多すぎると運用負荷が増す。 |
| B. 別ライブラリ／サイトへ分離 | 機密フォルダーを新しいドキュメント ライブラリまたは専用サイトへ移し、そこでのみ専用グループを許可。 | 情報構造で「機密／一般」を切り分けられる。将来的に保持・ラベル・IRM・DLP などをコンテナー単位で適用しやすい。 | リンクやフローの見直しが必要になる可能性。移動時のボリュームや業務停止の調整が必要。 |
| C. メールセキュリティ グループから外し、代替グループで必要フォルダーのみ許可 | メール用途と SharePoint 用途を分離し、SharePoint 用はロール別のグループ（例：SP_All_Read、SP_RSC_ReadOnly）で制御。対象ユーザーは必要なロールのみに所属。 | 原理的にシンプルで拡張性が高い。フォルダー追加時もロール付与で対応可能。 | グループの再設計・移行コストが発生。メール配信・他アプリとの依存関係に注意。 |
おすすめの判断基準
- フォルダー数が少なく、機密フォルダーが明確：将来の監査・ガバナンスを見据え、B（分離）を推奨。ラベルや保持ポリシー、外部共有ポリシーも切り分けやすくなります。
- フォルダー構造を動かしにくい／影響範囲を最小にしたい：A（継承停止＋専用グループ）が現実解。
- この先も同様の例外が増えそう：運用の持続性重視でC（グループ見直し）を検討。ロールベース設計にして例外運用を減らします。
SharePoint 権限モデルの要点（誤解しやすいポイント）
- Allow ベース：否定（Deny）はありません。どこかで許可された権限は、別の場所から打ち消せません。
- 継承（Inheritance）：サイト → ライブラリ／リスト → フォルダー → アイテムの順に継承。継承を停止した瞬間にその場所はユニーク権限になり、以降は手動管理です。
- Limited Access（制限付きアクセス）：上位オブジェクトに入るためだけの補助権限が自動的に付くことがあります。アクセスを許可したわけではないので心配不要です。
- グループの種類：SharePoint グループとEntra ID（旧 Azure AD）グループは別物。ロール表現は SharePoint グループ、横断的な人の集合は Entra ID グループで表すと整理しやすくなります。
- ユニーク権限の上限：1 ライブラリ内でユニーク権限（ユニーク スコープ）を増やしすぎると管理コストが跳ね上がります。最小限にとどめるのがベストプラクティスです。
実装手順（A：継承停止＋専用グループ）
前提準備
- フォルダー名：
ResourceCenter（例） - 作成する SharePoint グループ：
SP_RSC_ReadOnly（閲覧）、必要に応じてSP_RSC_Edit（編集） - 除外対象ユーザー：新入社員 1 名（このグループには入れない）
UI 操作手順
- 問題のフォルダーを含むドキュメント ライブラリを開き、対象フォルダーを選択。
- 右側の「アクセスの管理」（または「共有」→「詳細」）を開き、「詳細設定」へ移動。
- 「このフォルダーのアクセス許可の継承を停止」を実行（「継承の停止」ボタン）。以降、このフォルダーはユニーク権限になります。
- 既に付与されているメールセキュリティ グループの権限を削除。
- 新規 SharePoint グループ（例：
SP_RSC_ReadOnly）を作成し、必要なメンバーのみ追加。除外ユーザーは入れない。 - フォルダーのアクセス許可画面で、新規グループに対して「閲覧（Read）」または所定の権限レベルを付与。
- 必要に応じて、上位から伝播してきた不要なリンク共有やアクセス権が残っていないか確認。
PnP.PowerShell による自動化例
同作業をスクリプト化して再現性と監査性を高めます（テスト環境で検証してから本番で実行してください）。
# 1) 接続
$siteUrl = "https://contoso.sharepoint.com/sites/DeptX"
Connect-PnPOnline -Url $siteUrl -Interactive
# 2) 対象ライブラリ／フォルダーを特定
$libraryTitle = "ドキュメント" # 英語テナントなら "Documents"
$folderServerRelativeUrl = "/sites/DeptX/Shared Documents/ResourceCenter"
# 3) フォルダーの ListItem を取得
$item = Get-PnPListItem -List $libraryTitle -FolderServerRelativeUrl $folderServerRelativeUrl `
| Where-Object { $_.FileSystemObjectType -eq "Folder" } | Select-Object -First 1
if (-not $item) { throw "フォルダーの特定に失敗しました。" }
# 4) 継承停止（上位権限はコピーせず、サブスコープもクリア）
Set-PnPListItem -List $libraryTitle -Identity $item.Id -BreakRoleInheritance `
-CopyRoleAssignments:$false -ClearSubscopes:$true
# 5) 既存のメールセキュリティ グループ権限を除去
$principalToRemove = "SG-MailSecurity-AllFolders" # 実名に置換
Remove-PnPListItemPermission -List $libraryTitle -Identity $item.Id -Principal $principalToRemove
# 6) 専用 SharePoint グループに閲覧権限を付与
$spGroup = "SP_RSC_ReadOnly"
Set-PnPListItemPermission -List $libraryTitle -Identity $item.Id -Group $spGroup -AddRole "Read" 注意：テナント言語やサイトの言語によりライブラリ名が異なります。必ず対象環境に合わせて変数を調整してください。
実装手順（B：制限対象フォルダーを別ライブラリ／サイトに分離）
推奨アーキテクチャ
- 「機密」フォルダーだけを新ライブラリ（例：
ResourceCenter）に移動し、ライブラリ単位で専用グループを付与。 - さらに要件が強い場合は専用サイト（例：
/sites/ResourceCenter）を用意し、外部共有、ラベル、保持、DLP、アクセス要求の設定をサイト単位で分離。
移行ステップ（例）
- 新ライブラリ（または新サイト）を作成し、既定の権限をクリアして専用グループのみを付与。
- 元のフォルダーからコンテンツを移動（またはコピー）。移動中は編集中断ルールと周知を行い、完了後にリンクの付け替えを実施。
- ワークフロー（Power Automate）やショートカット、ブックマーク、Teams タブなどの参照先を更新。
- 元フォルダー側の権限は整理し、重複や残骸を残さない。
メリットの再整理
- 機密度に応じたラベル、保持ポリシー、IRM、共有設定をコンテナーで完結。
- ユニーク権限の点在を避け、棚卸しと監査がしやすい。
実装手順（C：メールセキュリティ グループの見直し）
メール配信や他システム連携を担う「メールセキュリティ グループ」にファイル共有の意味合いを持たせると、例外対応が増えるほど運用が破綻します。用途ごと（ロールごと）にグループを分離し、SharePoint は SharePoint でロールベースに整理しましょう。
再設計の例
| グループ名（例） | 用途 | 所属 |
|---|---|---|
SG-MailSecurity-All | メール配信／全社通知 | 全社員（新入社員を含む） |
SP_AllFolders_Read | SharePoint 全体（一般文書）閲覧 | 必要な社員（新入社員を含む） |
SP_RSC_ReadOnly | ResourceCenter 専用閲覧 | 除外対象者を含めない |
このように、メール用途とファイル共有用途を分けることで、「あの 1 名だけ除外」といった要件にも副作用なく対応できます。
運用設計のベストプラクティス
命名規則
- 用途・スコープ・権限レベルを名前に含める：
SP_RSC_ReadOnly、SP_RSC_Edit、SP_General_Readなど。 - 接頭辞で資産種別を明示：
SP_（SharePoint）、SG_（Entra ID Security Group）。
定期レビュー
- 継承停止フォルダーと個別付与ユーザーは、半期〜年 1 回の棚卸しを実施。
- 実業務の変化（異動・兼務・委託）のたびに、該当ロールの見直しを運用ルール化。
監査とログ
- 権限変更やアクセスの監査ログを有効化し、だれが・いつ・何を変更したかを追跡できる状態に。
- 棚卸し時は、ユニーク権限の一覧・共有リンクの状況・外部共有の有無を確認。
共有リンクの既定値
- 「リンクを知っているすべてのユーザー」を既定にしない。組織内ユーザー限定を既定にする。
- 有効期限やダウンロード禁止設定（閲覧のみ）を適宜活用。
落とし穴と対策
- 「Limited Access」が付いた＝アクセス可能という誤解：入れ子構造を通過するための補助であり、実権限ではありません。
- ユニーク権限の氾濫：場当たりで継承停止を乱発すると、誰が何に入れるかが不明瞭になります。設計図（役割設計図）を作り、ルールに沿って付与・剥奪を行うこと。
- メールセキュリティ グループ多用途化の弊害：通知・配信と閲覧ロールを分離しないと、1 名除外のたびにスパゲッティ化。
- 「共有」経由の抜け道：フォルダー側で継承停止をしても、個別ユーザーに直接共有されると想定外の許可が生じます。共有の既定・ポリシーで抑止を。
ケーススタディ（ResourceCenter を 1 名だけ除外）
要件：新入社員 1 名は ResourceCenter のみ閲覧可。それ以外の 7 フォルダーは不可。
- A 方式：ResourceCenter のみ継承停止。
SP_RSC_ReadOnlyを作成し、既存のメールセキュリティ グループを外す。新入社員はSP_RSC_ReadOnlyに入れない。結果：ResourceCenter 以外は従来どおりメールセキュリティ グループで管理され、ResourceCenter は専用グループのみが許可。 - B 方式：ResourceCenter を独立ライブラリに移動し、同名の
SP_RSC_ReadOnlyのみ許可。将来は保持・共有・ラベルも専用に。 - C 方式：SharePoint 用のロールグループへ再設計。新入社員は
SP_AllFolders_Readから除外し、SP_RSC_ReadOnlyのみ参加。
変更前後の可視化（例）
| オブジェクト | 変更前 | 変更後（A 方式の例） |
|---|---|---|
| Folder A〜H（ResourceCenter 以外） | SG-MailSecurity-All（閲覧） | 変更なし |
| ResourceCenter | SG-MailSecurity-All（閲覧） | SP_RSC_ReadOnly（閲覧）／SG-MailSecurity-All は削除 |
| 新入社員 | SG-MailSecurity-All 経由で全フォルダー閲覧 | ResourceCenter のみ閲覧可（SP_RSC_ReadOnly には入れない） |
チェックリスト（運用・監査）
- 対象フォルダーの継承状態は「ユニーク」になっているか。
- メールセキュリティ グループの権限がフォルダーに残っていないか。
- 新規 SharePoint グループのメンバーに、除外対象が含まれていないか。
- 共有リンク（ユーザー単位の直接共有）が残っていないか。
- 棚卸し台帳に、ユニーク権限の場所・許可ロール・最終更新者・根拠チケットが記録されているか。
よくある質問（FAQ）
Q：フォルダーで「閲覧不可」に設定するチェックはありますか？
A：いいえ。SharePoint は否定（Deny）を持たず、許可しない＝アクセス不可という設計です。許可を付けないことが唯一の「拒否」です。
Q：上位に付けたグループの権限を、下位で“この人だけ無効化”できますか？
A：できません。下位で継承を止め、必要な許可だけを付け直す必要があります。
Q：継承停止はどれくらいまで増やして良いですか？
A：機能上の上限に達する前に、運用の複雑性が先に限界に達します。用途でコンテナー分離（B 方式）する方が長期的には健全です。
Q：他のユーザーが「共有」で直接許可したら？
A：想定外の許可が生じます。共有の既定値・外部共有・リンクの種類・有効期限をポリシー化し、管理者レビューを導入してください。
導入から定着までの実務ポイント
- 変更申請と記録：ITSM（チケット）に、対象・根拠・実施者・実施日を必ず残す。
- 関係者通知：いつ／誰が／どのフォルダーに／どのロールを付け替えたかを関係者へ周知。
- テスト用アカウント：メンバー／非メンバーの 2 種で動作確認し、想定外アクセスがないか検証。
- テンプレート化：継承停止フォルダーを作る際の命名・台帳・承認フローをテンプレ化。
まとめ
- SharePoint には「このユーザーだけグループ権限を打ち消す」否定（Deny）が無いため、回避策は存在しません。
- 実現するには、A：継承停止＋専用グループ、B：別ライブラリ／サイトに分離、C：グループ見直しのいずれかを選択。
- 将来の管理コストとガバナンスを考慮し、最もシンプルな構造を目指すのがベストです。機密と一般を分けられるなら B、最小影響で済ませるなら A、例外が増える見込みなら C を選びましょう。
実務メモ（すぐ使える運用ルール例）
| ルール | 内容 | 効果 |
|---|---|---|
| 設計図の維持 | サイト／ライブラリ／フォルダーごとに「許可すべきロール」を図式化し、最新版を保存。 | 誰が見ても意図が分かり、属人化を防止。 |
| 台帳の標準化 | ユニーク権限の場所・ロール・メンバー・根拠・期限を Excel/Lists で一元管理。 | 棚卸しと証跡の手戻りを削減。 |
| リンク既定値 | 「組織内ユーザー」「閲覧のみ」「有効期限あり」を既定。必要時のみ例外申請。 | 意図しない外部共有・再共有を抑止。 |
| 四半期レビュー | ユニーク権限と共有リンクの棚卸し、アクセスポリシー遵守状況をレビュー。 | ドリフト（ズレ）の早期検知。 |
技術補足
- 権限レベル：既定（閲覧／編集／フル コントロール）を使い、カスタム権限レベルは最小限に。複雑化すると監査・運用の難度が上がります。
- アクセス要求の設定：継承停止フォルダーではアクセス要求の宛先を明示。申請→承認→台帳反映を自動化できると理想的です。
- 自動化：PnP.PowerShell で「継承停止・付与・剥奪・台帳更新」をスクリプト化。Pull Request でレビュー可能に。
- サイト・ライブラリ設計：「同じライフサイクル・同じセキュリティ」のものを同じコンテナーにまとめるのが原則。
要点（Accept Answer）
- 結論：現行の権限モデルでは回避不可。SharePoint に否定（Deny）はないため、（1）グループを外す／（2）継承停止でフォルダー単位に再設定／（3）ユーザーをグループから外し必要フォルダーだけ個別付与のいずれかを選ぶしかない。
- おすすめ：フォルダー構造を動かせるなら B（分離）、動かしにくいなら A（継承停止＋専用グループ）。例外が増えそうなら C（ロール設計）で根治。
- 運用の肝：命名規則／台帳／共有既定／定期レビュー／監査ログの 5 点を習慣化。
コメント