Owner権限（Team/Site所有者）をどう統制するか

山崎行政書士事務所
4 日前
読了時間: 7分

〜棚卸し＋逸脱検知で「便利な共同作業」を“事故らない基盤”に変える運用〜

山崎行政書士事務所（クラウド法務）です。情シスの現場でよく起きるのが、「TeamsのOwner（所有者）を増やしすぎて、いつの間にか統制不能になる」問題です。しかもTeamsのOwnerは、単なる“プロジェクトリーダー”ではなく、実態として 設定変更・メンバー管理・ゲスト招待などができる強い権限 を持ちます。

そして怖いのは、Teamsだけでは終わらないこと。Teamsの背後にある Microsoft 365 グループのOwnerは、SharePointサイト側にも強く影響します。たとえば サイトをMicrosoft 365 グループに接続すると、グループ所有者がサイトコレクション管理者（≒強権限）になり、サイト所有者グループにも追加される ため、Owner統制＝SharePoint統制でもあります。

この記事では、事業会社の情シス担当者向けに、Owner権限を「提出物レベルの運用」に落とし込むための実務ルール（棚卸し＋逸脱検知）を整理します。

なぜOwner統制が“事故ポイント”になるのか

Ownerを放置すると、典型的に次が起きます。

Ownerが退職・異動で消え、Ownerless（所有者不在）になる

→ メンバー追加・設定変更など“運用が止まる”のに、現場は気づきにくい
Ownerが多すぎて責任主体が不明（“誰でも管理できる＝誰も管理しない”）
ゲスト（社外）がOwnerに混入（例外が例外でなくなる）
Ownerが勝手に設定変更（プライバシー、外部共有、アプリ追加、チーム運用方針…）
最悪、グループ自体の廃止（削除）までOwner主導で進む（復旧・監査対応が地獄）

Microsoftの公式説明でも、グループOwnerは「メンバーシップと設定の管理者」と明確に位置づけられています。つまりOwner統制は、内部統制（アクセス権限管理）そのものです。

まず押さえるべき“公式仕様”3点

1) Teams Ownerは「設定とメンバー管理」の責任者

Teamsの所有者は、メンバー（やゲスト）を追加・削除し、チームの設定を管理・変更できます。

2) Ownerの上限は高い（＝“増やせてしまう”）

Teams：チームあたりOwner上限 100
Microsoft 365 グループ：グループあたりOwner上限 100

上限が100ということは、「放っておくと増え続ける」設計です。情シス側で“上限より先にルール”を作らないと、必ずスプロールします。

3) グループOwnerはSharePointでも強い

既存サイトをMicrosoft 365グループに接続すると、グループOwnerがサイトコレクション管理者になり、サイト所有者グループにも追加されます。SharePoint管理センターでも、サイト管理者の追加削除に加えて、グループ接続サイトではグループOwnerの追加削除もできることが明記されています。

Owner統制の設計思想：情シスが決めるべき「3つの線引き」

Owner統制は、結局この3つです。

Ownerに“してよい人”を決める（資格）
Ownerが“勝手に増えない仕組み”を作る（入口統制）
Ownerが“勝手に変わったら即わかる仕組み”を持つ（出口・監視）

ここから先は「運用設計の提出物」として作ると、監査・引継ぎ・是正が一気に楽になります。

実務ルール：Ownerを“権限”として管理する最低ライン

ルールA：最小Owner数は2名（単一障害点を潰す）

SharePointの新機能「サイト所有権ポリシー」でも、最小所有者数として2を選ぶことでOwnerless化リスクを下げられると明示されています。Teams/Groupでも同様に、「必ずOwner2名」 を標準化してください。

事業Owner（業務責任者）…1名
技術Owner（情シスまたは情報セキュリティの窓口）…1名
- “現場だけOwner”にしない（ガバナンスが崩れたとき止められない）

ルールB：ゲストOwnerは禁止（例外は「期限付き」）

ゲストは本来「外部ユーザー」です。Ownerに入れると、設定変更やメンバー管理の責任範囲が壊れます。例外を認めるなら、台帳に「期限」「承認者」「根拠」「代替策」 をセットで残してください。

ルールC：Owner追加は“Change”として扱う（申請・承認）

Ownerの追加/削除は、実態として「アクセス権限の変更」です。情シスはこれを 通常変更（Standard Change） としてテンプレ化しておくと良いです（後述のテンプレ参照）。

ルールD：Owner数の“社内上限”を決める（推奨：2〜5）

仕様上は100でも、実運用で100Ownerは破綻します。運用上の上限を定め、超過は例外扱いに。

棚卸し設計：台帳で“見える化”しないと統制できない

1) 棚卸し対象の最小単位は「Team / Group / Site」を束ねて管理

Owner統制で一番多い失敗は「Teamsだけ見てSharePointを見てない」パターンです。先に触れたとおり、Microsoft 365グループOwnerがSharePointに強い影響を持つので、台帳はTeam単体ではなく、M365グループIDをキーに紐づけるのが現実的です。

2) 棚卸し頻度を“リスクで分ける”

高リスク（例：外部共有あり、機微情報ラベル）：月次
中リスク：四半期
低リスク：半期〜年次

3) SharePointは「サイト所有権ポリシー」で“棚卸しの自動化”が可能

2026年のMicrosoft Learnでは、SharePoint Advanced Management のサイトライフサイクル管理として サイト所有権ポリシー が提供されており、

サイト所有者/管理者を定義
最小所有者数/管理者数（最大2）を設定
非準拠サイトを特定し、レポート化し、アクティブポリシーなら毎月通知
シミュレーションモードで影響確認してから本番化

といった運用が可能です。

※ライセンス要件（基礎ライセンス＋CopilotライセンスorSharePoint Advanced Management等）も明示されています。

逸脱検知設計：「変わった瞬間」をログで掴む

棚卸しは“定期点検”。でも事故は「点検の合間」に起きます。だから 逸脱検知（アラート） をセットにします。

1) 逸脱検知に使うログの基本セット

Microsoft Entra 監査ログ

監査ログには、日時、サービス、カテゴリ/アクティビティ名、アクター/ターゲット、変更されたプロパティの旧値・新値などが含まれることが公式に説明されています。

→ 「誰が」「何を」「どう変えたか」を追える
Microsoft Purview 監査ログ（Teams関連イベント）

Teamsの監査ログイベントはPurview監査で検索できる（運用・調査の軸になる）ことがMicrosoft Learnで整理されています。

2) “Owner変更”の逸脱検知は、Entra監査ログを主軸に

Owner変更はグループ管理イベントとして残るケースが多く、Entra監査ログのアクティビティ参照が公開されています（カテゴリ/アクティビティは変化し得る点も明記）。

情シスが見るべき危険シグナル（Owner変更系）

Owner追加が「申請IDなし」で発生
Ownerがゲスト（外部）
Owner数が2未満（Ownerless含む）
Owner追加が深夜/休日に集中
Owner追加の実行者が“業務責任者でも情シスでもない”
Ownerが短期間に入れ替わる（乗っ取りや運用崩壊の兆候）

3) Ownerless（所有者不在）対策は“自動回復”も使う

Microsoft 365 管理センターでは OwnerlessなMicrosoft 365グループ/Teamsを検知し、アクティブメンバーにOwner就任を自動招待するポリシー が提供されています（要件・制限も整理）。またTeams管理センターで、管理者がOwnerlessチームにOwnerを割り当てる修復アクションを行う想定も明記されています。