SharePoint / OneDriveの権限管理で迷いやすいのは、「SharePointグループで管理すべきなのか」「Microsoft 365グループやTeams側で管理すべきなのか」という点です。2026年5月8日前後に更新された公式情報の要点は、SharePointサイト権限の細かなカスタマイズは可能だが、多くの組織では標準のグループとMicrosoft 365グループを中心に管理するのが安全ということです。特に、チームサイト、コミュニケーションサイト、Teams連携サイト、OneDriveの外部共有設定では確認すべき場所が異なるため、権限変更前に影響範囲を切り分ける必要があります。Microsoft Learnでは、SharePointグループの作成、ユーザー追加・削除、サイトアクセス付与、グループ削除、権限レベル変更、サイト管理者の追加・削除が整理されています。(Microsoft Learn)
SharePointサイト権限のカスタマイズで押さえるべき結論
「Customize SharePoint site permissions」は、新しい共有機能の発表というより、SharePointサイト権限を細かく調整する場面で、どの操作をどこで行うかを整理した管理者向け情報です。
重要なのは、すべてのサイトで同じ方法を使わないことです。SharePoint in Microsoft 365では、サイトの種類によって推奨される権限管理の場所が変わります。
| サイト・利用形態 | 推奨される管理方法 | 注意点 |
|---|---|---|
| チームサイト | 関連付けられたMicrosoft 365グループで管理 | SharePoint側だけで追加したユーザーは、メールボックスやPlannerなど他のグループサービスにはアクセスできない |
| Teams連携のチームサイト | TeamsまたはMicrosoft 365グループで管理 | Teamsの所有者・メンバー管理とSharePoint権限が連動する |
| Teamsのプライベートチャネル・共有チャネルサイト | Teams側で管理 | SharePoint側では権限を個別管理できず、読み取り専用表示になる場合がある |
| コミュニケーションサイト | SharePointのOwners、Members、Visitorsグループで管理 | 社内ポータルやニュース配信など、閲覧者が多いサイトに向いている |
| Hubサイト | 元になるサイト種類に応じて管理 | サイトをHubに関連付ける権限は管理者側で制御する |
| OneDrive | SharePoint管理センターの共有設定とユーザー単位のOneDrive設定で管理 | OneDriveの外部共有はSharePoint全体の設定より緩くできない |
Microsoftは、コミュニケーションサイトでは組み込みのSharePointグループを使い、チームサイトでは関連付けられたMicrosoft 365グループを通じて権限を管理することを推奨しています。(Microsoft Learn)
何が変わるのか：権限モデルの変更ではなく、運用判断の明確化
今回の公式情報で読み取るべきポイントは、SharePointの権限モデルそのものが大きく変わったというより、細かな権限カスタマイズを行う前に、標準グループ管理を優先すべき場面が明確化されている点です。
Microsoft Learnでは、このページを「高度なシナリオ向け」と位置付けています。単にファイルやフォルダーを共有したい場合、またはサイトを共有したい場合は、別の共有手順を参照するよう案内されています。(Microsoft Learn)
つまり、管理者がまず判断すべきなのは「権限をカスタマイズするか」ではなく、次の順序です。
| 判断ポイント | 推奨される考え方 |
|---|---|
| ファイルやフォルダー単位で共有したい | サイト権限ではなく共有リンクや個別共有を検討する |
| サイト全体にアクセスさせたい | サイト共有、Microsoft 365グループ、SharePointグループのいずれかを使う |
| Teamsと連携している | Teams側の所有者・メンバー管理を優先する |
| コミュニケーションサイトを管理したい | SharePointのOwners、Members、Visitorsグループを使う |
| 特定業務だけに細かい権限を与えたい | カスタムSharePointグループや権限レベルを検討する |
| 既定グループを削除したい | 原則として削除しない |
特に注意したいのは、権限を細かく分けすぎると、後から「誰がどこにアクセスできるのか」を追いにくくなる点です。監査、退職者対応、外部ユーザーの棚卸し、情報漏えい調査の負荷が上がります。
影響範囲：管理者、サイト所有者、開発者が見るべき場所
SharePointサイト権限のカスタマイズは、単にユーザーを追加・削除するだけの作業ではありません。設定場所を誤ると、Teams、Microsoft 365グループ、OneDrive、外部共有、Power Automateなどの周辺運用にも影響します。
SharePoint管理者への影響
SharePoint管理者は、サイト単位の権限だけでなく、組織全体の共有ポリシーも確認する必要があります。
特に重要なのは次の設定です。
| 確認項目 | 確認する理由 |
|---|---|
| SharePoint管理センターの外部共有設定 | サイトやOneDriveの共有範囲の上限になる |
| サイト単位の共有設定 | 組織全体より緩い設定にはできない |
| Microsoft Entra B2B連携 | 外部ユーザーの招待、認証、ゲスト管理に関わる |
| 既定の共有リンク種類 | 「すべてのユーザー」「組織内のユーザー」「特定のユーザー」などの初期値に影響する |
| Anyoneリンクの有効期限 | 匿名リンクの放置リスクを抑える |
| ドメイン制限 | 取引先や競合など、共有可能な外部ドメインを制御する |
| サイト管理者 | 権限トラブル時に復旧できる管理者がいるか確認する |
SharePointとOneDriveの外部共有は組織レベルで制御でき、必要に応じて特定サイトではより厳しい設定にできます。一方で、OneDriveの共有設定はSharePointの設定より緩くできません。(Microsoft Learn)
サイト所有者への影響
サイト所有者は、日常的なメンバー追加や閲覧者追加を行う立場です。ただし、サイト所有者がすべての権限設定を自由に変更できるわけではありません。
たとえば、Microsoft Learnでは、サイトコレクション管理者のリンクを表示するには少なくともSharePoint管理者である必要があり、サイト所有者には表示されないと説明されています。(Microsoft Learn)
サイト所有者が特に注意すべきなのは、次の3点です。
- メンバー追加の場所を間違えない
- 既定のOwners、Members、Visitorsグループを安易に変更しない
- 個別共有を増やしすぎない
たとえば、チームサイトでSharePoint側に直接ユーザーを追加すると、そのユーザーはSharePointサイトにはアクセスできても、Microsoft 365グループに紐づくメールボックス、予定表、Plannerなどにはアクセスできない場合があります。チーム全体の作業スペースとして使っているなら、Microsoft 365グループまたはTeams側で追加する方が自然です。
開発者・Power Platform担当者への影響
開発者やPower Automate、Power Apps、SharePointリスト連携を担当する人は、権限変更によるアプリやフローへの影響を確認する必要があります。
実務で起きやすいトラブルは次のようなものです。
| よくあるトラブル | 原因 | 対策 |
|---|---|---|
| Power Automateのフローが失敗する | 実行ユーザーや接続アカウントがリストにアクセスできなくなった | 接続アカウントの権限と共有範囲を確認する |
| Power Appsでリストが表示されない | アプリ利用者にSharePointリストの閲覧権限がない | アプリ共有だけでなく、データソース側の権限も付与する |
| WebパーツやSPFx拡張が期待通り表示されない | ページ、ライブラリ、リストの権限が分断されている | サイト、ライブラリ、アイテム単位の継承状態を確認する |
| 外部ユーザーがファイルにアクセスできない | 外部共有設定、Entra B2B設定、サイト権限のいずれかで制限されている | 組織レベル、サイトレベル、共有リンクの順に確認する |
アプリや自動化の不具合は、コードの問題ではなく権限変更が原因で起きることがあります。変更前に、利用しているリスト、ライブラリ、接続アカウント、外部ユーザーの有無を棚卸ししておくと、切り戻しが容易になります。
SharePointグループを作成する前に決めること
SharePointグループは、同じ権限を持つユーザーをまとめるための仕組みです。ユーザーごとに直接権限を付けるより、グループ単位で管理した方が運用しやすくなります。公式情報でも、1人ずつ権限を割り当てるのではなく、グループを使って同じ権限レベルをまとめて付与できると説明されています。(Microsoft Learn)
ただし、グループ作成前に設計しないと、似た名前のグループが乱立します。
グループ作成前のチェック項目
| 項目 | 決める内容 | 例 |
|---|---|---|
| グループ名 | 目的が分かる名前にする | 営業ポータル_編集者、経理サイト_閲覧者 |
| 説明 | 何のためのグループか明記する | 「営業部ポータルのお知らせ編集担当」 |
| 所有者 | 管理責任者を1名以上明確にする | 部門管理者、サイトオーナー |
| メンバー変更権限 | 誰がメンバーを追加・削除できるか | グループ所有者のみ |
| 参加・脱退リクエスト | 申請を許可するか、通知先をどこにするか | サイト管理用メールアドレス |
| 権限レベル | 閲覧、編集、フルコントロールなど | VisitorsはRead、MembersはEditが基本 |
| 棚卸し周期 | 定期確認の頻度 | 四半期ごと、半年ごと |
グループ名は「部署名＋役割」だけでは不十分です。たとえば「営業部」だけでは閲覧者なのか編集者なのか分かりません。営業部_サイト閲覧、営業部_ニュース投稿のように、アクセス対象と操作範囲を含めると運用しやすくなります。
SharePointグループでできる主な操作
公式情報では、SharePointグループに関する主な操作として、作成、ユーザー追加、ユーザー削除、サイトアクセス付与、削除、権限レベルの割り当てが説明されています。(Microsoft Learn)
グループを作成する
SharePointグループを作成するには、サイトの設定から「サイトの権限」に進み、詳細なアクセス許可設定でグループを作成します。作成時には、グループ名、説明、所有者、メンバーシップ設定、参加・脱退リクエスト、サイトに対する権限レベルを指定します。(Microsoft Learn)
実務では、作成直後に次の確認をしておくと安全です。
- グループ所有者が退職予定者や一時担当者だけになっていないか
- フルコントロールを不要なユーザーに付与していないか
- 編集者にすべきユーザーを所有者にしていないか
- 外部ユーザーを含める必要が本当にあるか
- グループの用途が説明欄だけで分かるか
特にフルコントロールは、権限変更やサイト設定変更まで可能になる強い権限です。投稿やファイル編集だけを任せたい場合は、Members相当の編集権限で足りることが多いです。
グループにユーザーを追加する
ユーザー追加は、サイトの種類によって操作の考え方が変わります。
コミュニケーションサイトでは、サイトアクセス画面からユーザーやグループを追加し、権限レベルを選択します。チームサイトでは、メンバーシップ画面からメンバーを追加します。Microsoft Learnでも、コミュニケーションサイトとチームサイトで手順が分けて説明されています。(Microsoft Learn)
実務では、次のように判断すると失敗しにくくなります。
| 追加したい相手 | 推奨される追加先 |
|---|---|
| Teamsのチームメンバーとして共同作業する人 | TeamsまたはMicrosoft 365グループ |
| SharePointサイトだけ閲覧する人 | SharePoint Visitorsグループ |
| コミュニケーションサイトで記事を投稿する人 | SharePoint Membersグループ |
| サイト設定も管理する責任者 | Ownersまたはサイト管理者。ただし人数は絞る |
| 一時的な外部協力者 | 共有ポリシーと期限を確認したうえで、必要最小限の権限 |
「とりあえず所有者に入れる」は避けるべきです。トラブル対応のために権限を強くするほど、後から不要権限が残りやすくなります。
グループからユーザーを削除する
ユーザー削除は、People and Groupsから対象グループを選び、削除したいユーザーを選択してグループから外します。(Microsoft Learn)
削除時に注意すべきなのは、別の経路で権限が残っていないかです。
たとえば、あるユーザーをSharePointグループから削除しても、次の経路でアクセスが残ることがあります。
- Microsoft 365グループのメンバーである
- Teamsのメンバーである
- 別のSharePointグループに入っている
- 共有リンクで個別にアクセス権を持っている
- セキュリティグループ経由で権限を持っている
- サイトコレクション管理者に設定されている
退職者や異動者の対応では、SharePointグループだけでなく、Microsoft 365グループ、Teams、Entra ID、共有リンク、OneDrive共有も含めて確認する必要があります。
サイトアクセスをグループに付与する
グループにサイトアクセスを付与する場合は、詳細なアクセス許可設定から権限を付与します。共有ダイアログでは既定で編集権限が提示される場合がありますが、必要に応じてオプションを表示し、別の権限レベルやSharePointグループを選ぶことができます。(Microsoft Learn)
ここで失敗しやすいのは、閲覧だけでよい利用者に編集権限を付けてしまうことです。社内ポータル、規程集、申請手順ページなどは、多くの利用者にReadまたはView Onlyを付与し、編集できる人を限定するのが基本です。
既定のSharePointグループは削除しない
公式情報では、既定のSharePointグループを削除しないよう明確に注意されています。既定グループを削除するとシステムが不安定になる可能性があるため、削除するのは自分で作成し、不要になったグループに限定すべきです。(Microsoft Learn)
既定グループとは、一般的に次のようなグループです。
| グループ | 標準的な役割 |
|---|---|
| Owners | サイトの管理者。通常はフルコントロール |
| Members | コンテンツの作成・編集者 |
| Visitors | 閲覧者 |
これらを削除したり、用途を大きく変えたりすると、将来の引き継ぎやトラブル対応が難しくなります。標準グループでは表現できない権限が必要な場合は、既定グループを壊すのではなく、新しいSharePointグループを作成する方が安全です。
権限レベルを変更するときの注意点
SharePointでは、Read、Edit、Full Controlなどの権限レベルをグループやユーザーに割り当てます。既定の権限レベルで足りない場合は、カスタム権限レベルを作成して割り当てることもできます。
ただし、複数の権限レベルを同時に割り当てると、権限は足し算になります。公式情報では、複数の権限レベルを選ぶと、それぞれに含まれる権限の和集合が付与されると説明されています。(Microsoft Learn)
たとえば、ある権限レベルに「A、B、C」が含まれ、別の権限レベルに「C、D」が含まれる場合、結果として「A、B、C、D」が付与されます。これは「一部だけ制限したつもりが、別の権限で許可されていた」という事故につながります。
権限レベル変更前の確認表
| 確認項目 | 理由 |
|---|---|
| 既定のReadやEditで足りない理由が明確か | 不要なカスタム権限を増やさないため |
| 対象がユーザー単位ではなくグループ単位か | 個別付与は棚卸しが難しいため |
| 複数権限レベルを同時に付けていないか | 権限が和集合になり、想定より強くなるため |
| Full Controlが不要な人に付いていないか | サイト設定や権限変更まで可能になるため |
| 権限変更後のテストユーザーを用意したか | 管理者アカウントだけでは一般利用者の見え方を確認できないため |
| 切り戻し手順を記録したか | 業務影響が出たときに戻せるようにするため |
権限レベルを変更する場合は、本番サイトでいきなり行うのではなく、テスト用サイトや限定グループで確認してから展開するのが安全です。
チームサイトではMicrosoft 365グループとの関係を必ず確認する
チームサイトは、多くの場合Microsoft 365グループに関連付けられています。Microsoft Learnでは、Microsoft 365グループの所有者はサイト所有者に、グループメンバーはサイトメンバーになると説明されています。(Microsoft Learn)
ここで重要なのは、SharePoint側だけで権限を追加したユーザーと、Microsoft 365グループに追加したユーザーでは、利用できる範囲が異なることです。
| 追加方法 | SharePointサイト | Teams | グループメールボックス | Plannerなど |
|---|---|---|---|---|
| Microsoft 365グループに追加 | 利用できる | 構成により利用できる | 利用できる | 利用できる |
| Teamsに追加 | 利用できる | 利用できる | 構成により利用できる | 利用できる |
| SharePointサイトに直接追加 | 利用できる | 利用できない場合がある | 利用できない | 利用できない |
プロジェクトメンバーとして継続的に共同作業する人は、SharePointに直接追加するより、TeamsまたはMicrosoft 365グループに追加する方が管理しやすいです。一方、関連部署の閲覧者や監査担当者のように「SharePointだけ見られればよい」人は、SharePointのVisitorsグループに追加する方が適している場合があります。
コミュニケーションサイトではVisitorsグループを活用する
コミュニケーションサイトは、ニュース、社内ポータル、部門情報、規程集などを広く発信する用途に向いています。公式情報では、コミュニケーションサイトはMicrosoft 365グループに接続されず、Owners、Members、Visitorsの標準SharePointグループで管理すると説明されています。(Microsoft Learn)
実務では、次のように役割を分けると管理しやすくなります。
| 役割 | 付与先の例 | 権限の考え方 |
|---|---|---|
| サイト管理者 | 情報システム部、ポータル責任者 | Owners。ただし人数を絞る |
| コンテンツ作成者 | 広報、人事、総務、部門担当者 | Members。ページやニュースを編集できる |
| 一般社員 | 全社員セキュリティグループなど | Visitors。閲覧中心 |
| 外部委託先 | 必要な範囲のグループ | 原則として最小権限、期限付きで管理 |
閲覧者が多いサイトでは、個人を一人ずつ追加するより、セキュリティグループをVisitorsに追加する方が運用しやすいです。ただし、入れ子のセキュリティグループはパフォーマンス上の問題につながる可能性があるため推奨されないとされています。(Microsoft Learn)
OneDriveへの影響：サイト権限とは別に共有設定を確認する
今回のテーマはSharePointサイト権限ですが、対象サービスにOneDriveが含まれる場合は、OneDriveの共有設定も別途確認する必要があります。
OneDriveは個人用のファイル保管・共有に使われるため、SharePointサイト権限とは運用の見え方が異なります。ただし、SharePoint管理センターではSharePointとOneDriveの組織レベル共有設定を管理できます。
特に確認したいのは次の項目です。
| 設定 | 確認する理由 |
|---|---|
| OneDriveの外部共有レベル | ユーザーが外部にファイルを共有できる範囲を制御する |
| 既定の共有リンク | ユーザーが無意識に広い範囲へ共有しないようにする |
| Anyoneリンクの有効期限 | 匿名リンクが長期間残るリスクを抑える |
| リンク権限 | 閲覧のみか、編集可能かを制御する |
| ファイル閲覧者情報 | OneDrive所有者が閲覧者情報を見られるかに影響する |
| Microsoft Entra B2B連携 | 外部ユーザーをゲストとして管理するかに関わる |
SharePoint管理センターの外部共有設定では、SharePointとOneDriveの共有レベルを指定できます。OneDriveの設定はSharePointより厳しくすることはできますが、SharePointより緩くすることはできません。(Microsoft Learn)
移行・展開時に確認すべきポイント
オンプレミスSharePoint、ファイルサーバー、旧サイト、別テナントからMicrosoft 365のSharePoint / OneDriveへ移行する場合、権限設計は移行前に整理しておく必要があります。
移行前に確認すること
| 確認項目 | 具体的な作業 |
|---|---|
| 既存権限の棚卸し | 誰がどのフォルダー、ライブラリ、サイトにアクセスできるか確認する |
| 個別権限の有無 | ファイル単位、フォルダー単位で例外が多すぎないか確認する |
| 外部ユーザー | ゲスト、取引先、委託先のアクセスを洗い出す |
| 退職者・異動者 | 不要なアカウントや古いグループを削除する |
| セキュリティグループ | Entra ID側のグループ設計と整合させる |
| Teams連携 | 移行先がTeams連携サイトか、単独SharePointサイトかを決める |
| OneDrive共有 | 個人が外部共有している重要ファイルを確認する |
移行で失敗しやすいのは、ファイルサーバーのフォルダー権限をそのままSharePointに再現しようとするケースです。SharePointはサイト、ライブラリ、リスト、アイテム単位で権限を設定できますが、細かく分けすぎると管理が難しくなります。
展開時のおすすめ手順
| 手順 | 内容 |
|---|---|
| 権限方針を決める | チームサイトはMicrosoft 365グループ、コミュニケーションサイトはSharePointグループなど基本方針を決める |
| サイト分類を行う | 部門サイト、プロジェクトサイト、社内ポータル、外部共有サイトを分類する |
| 標準グループを設計する | Owners、Members、Visitorsを基本に、必要な場合だけカスタムグループを作る |
| 外部共有ポリシーを確認する | 組織レベル、サイトレベル、OneDrive設定を確認する |
| テストユーザーで検証する | 所有者、編集者、閲覧者、外部ユーザーの見え方を確認する |
| 管理者と所有者に説明する | どこでメンバーを追加するか、どの権限を使うかを共有する |
| 定期棚卸しを予定する | 四半期または半年ごとに権限を確認する |
移行時は、権限を完全再現するより「業務に必要なアクセス権だけを再設計する」という考え方が重要です。古い例外権限をそのまま移すと、新しい環境でも管理不能になります。
権限カスタマイズでよくある失敗
個人に直接権限を付けすぎる
一時対応のつもりで個人に直接権限を付けると、後から削除漏れが起きやすくなります。基本はグループに権限を付け、ユーザーはグループに追加します。
例外的に個人へ直接付与する場合は、理由、期限、承認者を記録しておきましょう。
編集権限と所有者権限を混同する
「投稿できる人」と「サイト全体を管理できる人」は分けるべきです。ニュース投稿やファイル編集だけならMembersで足りる場合が多く、Ownersに追加する必要はありません。
所有者が増えすぎると、意図しない権限変更、ページ構成変更、外部共有設定変更が起きるリスクがあります。
外部共有設定をサイト権限だけで判断する
外部ユーザーがアクセスできない場合、SharePointグループだけを見ても原因が分からないことがあります。組織レベルの外部共有、サイトレベルの共有設定、Microsoft Entra B2B、共有リンク種類、ドメイン制限を順に確認する必要があります。
既定グループを削除・改変する
Owners、Members、Visitorsを削除したり、用途を大きく変えたりすると、標準的な管理手順が通用しなくなります。不要なグループを整理したい場合でも、既定グループではなく、自分で作成したカスタムグループを対象にします。
Teams連携サイトをSharePoint側だけで管理する
TeamsのメンバーシップとSharePointサイト権限が連動している場合、SharePoint側だけで権限を調整すると、TeamsやMicrosoft 365グループの実態とズレが出ます。Teams連携サイトでは、まずTeams側で管理すべきかを確認しましょう。
管理者が今すぐ確認すべきチェックリスト
SharePoint / OneDrive環境を運用している管理者は、次の項目を確認しておくと、今回の公式情報を実務に落とし込みやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| サイト一覧の分類 | チームサイト、コミュニケーションサイト、Hubサイト、Teamsチャネルサイトを分類したか |
| 権限管理の場所 | Microsoft 365グループ、Teams、SharePointグループのどれで管理するか決めているか |
| 既定グループ | Owners、Members、Visitorsが残っており、用途が崩れていないか |
| カスタムグループ | 目的不明のグループ、所有者不在のグループがないか |
| 権限レベル | 不要なFull Controlや複数権限レベルの重複がないか |
| 外部共有 | 組織レベル、サイトレベル、OneDriveレベルの設定が方針に合っているか |
| ゲストユーザー | 退職者、契約終了者、不要な外部ユーザーが残っていないか |
| 共有リンク | Anyoneリンクや期限なしリンクが放置されていないか |
| サイト管理者 | 緊急時に対応できる管理者が設定されているか |
| 変更記録 | 権限変更の理由、実施者、日時を記録しているか |
このチェックリストは、すべてを一度に完璧にするためではなく、リスクの高い場所から順に直すために使うのが現実的です。まずは外部共有サイト、機密情報を扱うサイト、退職者や外部ユーザーが多いサイトから確認しましょう。
まとめ：SharePoint権限は「細かく設定できる」より「管理し続けられる」が重要
SharePointサイト権限は柔軟にカスタマイズできます。しかし、柔軟さをそのまま使いすぎると、個別権限、例外グループ、共有リンク、外部ユーザーが増え、管理者でも全体像を把握しにくくなります。
今回の「Customize SharePoint site permissions」で押さえるべき実務上のポイントは、次の通りです。
- チームサイトはMicrosoft 365グループまたはTeams側での管理を基本にする
- コミュニケーションサイトはSharePointのOwners、Members、Visitorsを中心に管理する
- 既定のSharePointグループは削除しない
- カスタムグループは目的、所有者、権限レベルを明確にして作る
- 権限レベルを複数付けると権限は足し算になる
- OneDriveはサイト権限とは別に、共有設定と外部共有ポリシーを確認する
- 移行時は既存権限の完全再現ではなく、必要最小限のアクセス権に整理する
次に行うべきことは、自社テナントのサイトを種類別に分類し、各サイトで「どこで権限を管理するのか」を明文化することです。そのうえで、外部共有、所有者、カスタムグループ、Full Control付与の有無を棚卸しすれば、SharePoint / OneDriveの権限管理を安全に標準化できます。
コメント