日々の業務でMicrosoft Listを使って情報を整理していると、「特定のグループだけが見られるようにしたい」という要望が自然と出てくるものです。しかしSharePoint Onlineの仕組みは少々複雑で、アイテム単位や列単位での閲覧制御を思い通りに行うにはいくつかの注意点があります。この記事では、標準機能での権限設定の限界や実現策、さらに運用のコツや自動化のポイントについて詳しく解説します。
SharePointでアイテムをグループごとに制御する際の基本
SharePointには大まかに「サイト全体で設定する権限」「ドキュメントライブラリやリストなどのコンテナ単位で設定する権限」「個々のアイテム(またはファイル)ごとの権限」という三段階が存在します。標準ではサイトからリスト、そしてアイテムへと権限が継承される仕組みになっています。しかし個別のアイテムだけに固有の権限を付与する場合は、継承を解除（ブレーク）して、必要なグループあるいはユーザーだけに付与する方法が必須となります。
標準機能で列ごとの権限は設定できない
Microsoft List（SharePointリスト）の列に「Division/Group」という情報を加えて、列値に基づいて自動的に権限を切り替えることは、標準機能ではサポートされていません。たとえば、列の値が「PU Group」であれば、そのグループのメンバーのみが閲覧できるようにする、といった使い方をしたくても実現が難しいのが現状です。
なぜ列ベースがサポートされないのか
SharePointは基本的に「リスト（またはライブラリ）そのものの権限」もしくは「個々のアイテム（またはファイル）の権限」を管理対象とする思想で設計されています。列は単なるメタデータとして扱われるため、列単位での閲覧制御や編集制御といった仕組みは提供されていません。列を基準にしてアクセスを振り分ける場合は、プログラム的なアプローチやPower Automateの利用など、応用的なテクニックが求められます。
アイテム単位で権限を設定する基本手順
どうしてもグループごとにアイテムを見せたい・見せたくないを実現したい場合は、アイテムごとの権限設定が避けられません。ここからは具体的な手順を解説します。
手動での設定フロー
以下の手順でアイテム単位のアクセス制御が可能です。
- 該当のリストアイテム右上の「…」からManage Access(アクセスの管理)を選択
- 画面右上に表示される「…」メニューの中からAdvanced(詳細設定)をクリック
- 上部メニューにあるStop Inheriting Permissions(権限の継承を停止)を実行
- 不要なSharePointグループ（Members、Visitorsなど）を削除して、Ownersなど最低限必要なものを残す
- Grant Permissions(権限の付与)を実行し、閲覧・編集を許可したいグループあるいはユーザーを個別に追加する
一度権限継承を停止すると、そのアイテム固有のセキュリティ設定が始動します。意図しないメンバーが入り込まないように、不要なグループを確実に削除することがポイントです。
権限の種類に注意
SharePointでは「フル コントロール」「編集」「共同作成(Contribute)」「閲覧(Read)」など、いくつもの権限レベルが用意されています。グループごとに必要な権限レベルを見極めて設定しましょう。たとえば、「PU Group」には編集できる権限を与え、「GR&A Group」には閲覧のみ付与する、といった使い分けが可能です。
Power Automateでの自動化アプローチ
アイテムが多かったり、更新頻度が高かったりすると、いちいち手動で継承を解除して権限を付与するのは手間がかかります。そこでPower Automateを使った自動化が検討されます。
Power Automateによる権限設定フローのイメージ
たとえば以下のようなフローを作成します。
- トリガー：「アイテムが作成されたとき」「アイテムが更新されたとき」などを指定
- 条件分岐：「Division/Group」列の値によって分岐
- 権限継承の停止：「HTTPリクエスト」アクションや「SharePoint > Break inheritance action」を使用
- 権限付与と削除：Power Automateのアクション（Add Role Assignment/Remove Role Assignment）を活用
- 完了：更新内容が反映されるのを確認
実際にはHTTPリクエストを使ったSharePoint REST API操作も選択肢になります。具体的には以下のような構文を利用することが多いです。
POST /_api/web/lists/GetByTitle('対象リスト名')/items(ItemID)/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)続けて、権限を付与する場合は、また別のREST APIまたは標準アクションを使い、
POST /_api/web/lists/GetByTitle('対象リスト名')/items(ItemID)/roleassignments/addroleassignment(principalid=グループID, roledefid=権限レベルID)のように操作します。これらをフロー上で組み合わせれば、列の値に応じた動的な権限付与・削除が自動的に行われるようになります。
Power Automateテンプレート例
実際のコードはフローとして視覚的に構成することが多いですが、ここではイメージを示すため、一部JSON形式の例をシンプルに示します。
{
"name": "ItemPermissionAutomation",
"triggers": [
{
"type": "When an item is created or modified",
"siteAddress": "https://contoso.sharepoint.com/sites/Example",
"listName": "DemoList"
}
],
"actions": [
{
"type": "HTTP",
"method": "POST",
"uri": "/_api/web/lists/GetByTitle('DemoList')/items(@{triggerOutputs()?['body/ID']})/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)"
},
{
"type": "Condition",
"expression": "@equals(triggerOutputs()?['body/Division_x002f_Group'], 'PU Group')",
"trueActions": [
{
"type": "HTTP",
"method": "POST",
"uri": "/_api/web/lists/GetByTitle('DemoList')/items(@{triggerOutputs()?['body/ID']})/roleassignments/addroleassignment(principalid=XX, roledefid=YY)"
}
],
"falseActions": [
{
"type": "HTTP",
"method": "POST",
"uri": "/_api/web/lists/GetByTitle('DemoList')/items(@{triggerOutputs()?['body/ID']})/roleassignments/addroleassignment(principalid=ZZ, roledefid=YY)"
}
]
}
]
}上記のコードはあくまで概念的なサンプルですが、実際には「ユーザーやグループIDをどこから取得するか」「Role Definition ID(権限レベル)をどう指定するか」など、細部を詰める必要があります。
運用面での注意事項
アイテム単位の権限を多用すると、管理が煩雑になる恐れがあります。以下に運用面でのヒントをまとめます。
アイテム数の多さに注意
大量のアイテムに対して個別に権限を付与・削除を繰り返すと、フローの処理量が膨大になり、SharePoint側のパフォーマンスにも影響が出る可能性があります。たとえば数万件単位のアイテムを運用する場合は、フォルダごとに権限を付与する、またはサイトを分割して管理するなど別の構成を検討することも重要です。
権限レベルの設計
標準の「閲覧(Read)」「編集(Edit)」「フルコントロール(Full Control)」だけでなく、カスタム権限レベルを作成することもできます。ドキュメントライブラリほどではないにせよ、機密性の高い情報を扱うリストであれば、独自の権限レベルを用意しておくと混乱が減ります。
リスト内のビュー制御では隠しきれない
SharePointのビュー設定だけで表示を絞り込んでも、権限が存在する限りURLアクセスや検索から該当アイテムに到達できてしまうことがあります。セキュリティの観点からは、ビューだけの制御ではなくアイテム単位の権限設定が必須となる点を再度強調します。
どうしても列ベースが必要ならば？ 代替案と拡張アプローチ
標準機能ではサポートされていない列ベースの閲覧制御ですが、要件によっては以下のような代替策・拡張策が考えられます。
1. アプリカスタマイズやSPFx(SharePoint Framework)の利用
SharePoint Frameworkや自社開発のアプリによって、閲覧インターフェースを独自に作り込む方法があります。アプリ側で列の値を読み取り、許可されたユーザー以外には非表示にしてしまう仕組みを組み込むのです。ただし、これはあくまでUIレベルでの隠蔽であり、本質的にアイテムそのものの権限をロックダウンするわけではありません。セキュリティ要件が厳しい場合は限界があります。
2. 別リストを利用し関連付ける
列による制御を疑似的に行う方法として、「グループごとに異なるリストを用意し、Lookup列などで関連付ける」という運用もあります。各リストにアクセス権を設定しておき、Lookupで表示される内容もユーザーが属するグループごとのリストに依存させるイメージです。ただし、複数リストを行き来する導線の設計が難しくなるため、ユーザー体験と管理コストのバランスを考慮する必要があります。
3. Power Appsで画面を作り分ける
Power Appsを使ってカスタムフォームやアプリを構築し、ユーザーのグループ情報に応じて動的に表示を切り替えるアプローチもあります。SharePointのリストはバックエンド、Power Appsはフロントエンドという役割分担で、アクセス制御のロジックをPower Apps側に埋め込むのです。ただしこちらもSPFx同様に、表面上での制御にとどまりやすく、リスト自体にアクセスされる可能性は依然として残ります。
表で見るSharePointアイテム権限設定の比較
以下は、目的別に想定される権限設定アプローチの比較を示す簡易表です。
| アプローチ | メリット | デメリット | 適用シーン |
|---|---|---|---|
| リスト全体の権限 | シンプルに運用できる | 部署やチームごとの細かい制限が難しい | 全社向けの情報共有リストなど |
| フォルダーごとの権限 | 大量のアイテムをまとめて制御しやすい | フォルダ構成が複雑になると管理が煩雑 | 大量のアイテムを数グループで利用 |
| アイテム単位の手動設定 | 最もきめ細かく制御できる | 手動だと管理コストが非常に高い | 小規模・限定的なリスト |
| アイテム単位の自動化(Power Automate) | 列の値に応じた権限設定が半自動で行える | フローの作成や保守が必要。アイテムが多すぎるとパフォーマンスに注意 | 中～大規模だが柔軟性が必要 |
| Power AppsやSPFxなどのUI制御 | 柔軟な表示切り替えでユーザーに優しいインターフェース | 権限ではなくUIで隠すだけなので、根本的なセキュリティとしては限界がある | 利用者数が多くUIを重視する場合 |
このように、一言で「アイテム権限を設定したい」といっても、運用規模や要件に応じて最適な方法を検討する必要があります。
結論：アイテム単位の権限設定＋自動化が現実的
SharePointの標準機能だけでは、列ベースで自動的にアクセスを振り分ける機能はサポートされていません。そのため、もし「Division/Group」列の値で閲覧可能なグループを切り替えたいのであれば、アイテム単位での権限継承解除＋グループ追加・削除といった仕組みを整えるほかありません。
しかしながら、この手順を手動で行うのは手間がかかり、管理ミスが生じやすいのも事実です。そこでPower Automateなどを活用した自動化を検討することで、運用上の負担を軽減できます。最終的にはリスト構造の見直しやフォルダ分け、サイト分割、Power AppsによるUI制御などを組み合わせて、要件に最適化していくことが理想と言えるでしょう。
運用のポイントまとめ
- 小規模・限定的な運用であれば、アイテムごとの手動設定でも対応可能。
- 中～大規模の要件がある場合は、Power Automate等での自動化を検討。
- フォルダーやサイト分割も視野に入れて、構造的に管理する方法が結果として最も安全かつシンプルな場合も多い。
- UIレベルでの制御だけに頼らず、本質的な権限設定を意識する。
上記を踏まえ、SharePointリストのアイテムをグループごとに閲覧制御する場合には「アイテムごとの権限をブレークしてグループを再設定する」アプローチを基本とし、必要に応じて自動化フローを導入すると良いでしょう。
コメント