Google Workspaceでグループを権限管理のハブにする方法
「新しく入った人に共有ドライブの権限を個別に付けて、カレンダーも共有して、Chatのスペースにも招待して……」――Google Workspaceの権限管理を個人単位で行っていると、異動や入退社のたびにこの作業が発生します。
Google Groupsはメーリングリストとしてしか使っていない組織が多いですが、実はDrive、カレンダー、Chat、管理コンソールの権限付与先として機能する「権限ハブ」になれます。グループ単位で権限を設計しておくと、人の出入りがあってもグループメンバーの編集だけで権限が連動します。2026年6月にはGoogle Groupsの内部/外部分類の厳格化に加え、モバイルデバイス管理者権限をOU単位で委任できる更新も一般提供されました。2026年7月にはGoogle Calendarで、代理編集者に編集を任せながら非公開予定の詳細を隠せる共有権限が追加され、Google Workspace inbound SCIMも一般提供されています。権限ハブを設計するときは、共有ドライブやChatだけでなく、管理者ロール、端末管理、カレンダー代理編集、IdPから同期されるユーザー・グループの範囲まで同じ棚卸しで確認する必要があります。
本記事のポイント
- Google Groupsは権限付与の「ハブ」として使うことで、Drive・カレンダー・Chatの権限管理を個人単位からグループ単位に移行できる
- 命名規則と入れ子構造を整備しておくと、組織変更や異動のたびに権限を個別に付け替える作業がグループメンバーの編集だけで済む
- Groups分類、MDM管理者権限、Calendar代理編集権限、inbound SCIMの更新を踏まえ、外部メンバー、端末管理ロール、非公開予定、IdP同期グループを同じ棚卸しで確認する必要があります。
なぜグループを権限ハブにするのか
Google Workspaceの権限管理は、個人のメールアドレスに直接権限を付与する方式と、グループのメールアドレスに権限を付与する方式の2通りがあります。ほとんどの組織は、意識せず個人アドレスへの直接付与を使っています。
個人単位の権限管理が破綻する理由
個人単位での権限付与は、小規模なうちは問題になりません。しかし、組織が20人を超えたあたりから次の問題が出始めます。
まず、異動のたびに「前の部署の共有ドライブから外して、新しい部署の共有ドライブに追加する」作業が発生します。Drive、カレンダー、Chat、それぞれで個別に操作が必要です。次に、退職者の権限剥奪で漏れが出ます。Driveからは外したがCalendarの共有カレンダーに残っていた、という状態は頻繁に起きます。さらに、「この人はなぜこのドライブにアクセスできるのか」という権限の根拠が、時間とともに不透明になります。
グループ単位にすると何が変わるか
グループを権限の単位にすると、権限管理のほとんどがグループメンバーの追加・削除に集約されます。たとえば「sales-team@example.com」というグループに営業用の共有ドライブ、営業カレンダー、営業用Chatスペースの権限を付与しておけば、新しい営業メンバーをこのグループに追加するだけで、必要なリソースすべてへのアクセスが一括で付与されます。退職時も、グループから外すだけで完了です。
グループ設計の3原則
グループを権限ハブとして機能させるためには、場当たり的にグループを作るのではなく、設計原則に基づいて整備する必要があります。
原則1：命名規則を統一する
グループが増えてくると、名前だけでは用途がわからなくなります。次のような命名規則を決めておくと、管理画面で一覧したときに用途が即座に判別できます。
部門グループ：dept-sales@、dept-engineering@、dept-hr@ のように「dept-」接頭辞をつける。
プロジェクトグループ：proj-migration-2026@、proj-new-product@ のように「proj-」接頭辞をつける。
権限グループ：acl-drive-sales@、acl-calendar-company@ のように「acl-」接頭辞をつけ、対象リソースを明示する。
外部共有用グループ：ext-partner-corp@、ext-vendor-a@ のように「ext-」接頭辞をつける。
接頭辞のルールは組織によって変えてよいですが、ルールがないよりある方が運用は確実に安定します。
原則2：入れ子構造（ネスト）を活用する
Google Groupsは、グループの中にグループを入れる「ネスト」が可能です。これを使うと、権限の階層構造を組めます。
たとえば、「all-staff@」グループの中に「dept-sales@」「dept-engineering@」「dept-hr@」を入れておけば、全社向けのカレンダーやDriveフォルダの権限を「all-staff@」に付与するだけで全員に行き渡ります。部門グループに人を追加すれば、自動的に全社グループの権限も付きます。
ただし、ネストの深さは3階層程度に留めることを推奨します。深くなりすぎると、権限の伝播経路が追いにくくなり、意図しないアクセス許可が発生するリスクがあります。
原則3：「配信用」と「権限用」を分離する
メーリングリストとして全員にメールを送る用途と、権限付与のためだけに使うグループは、目的が異なります。両者を同じグループで兼ねると、「メールは受け取りたくないが権限は必要」という人が出てきたときに対応できません。
推奨は、配信用グループ（dept-sales@）と権限用グループ（acl-drive-sales@）を分け、権限用グループのメンバーに配信用グループを入れ子にする構成です。こうすると、権限の付与単位とメール配信の単位を独立して管理できます。
グループが権限ハブになるGoogle Workspaceサービス
Google Drive・共有ドライブ
共有ドライブのメンバー追加画面で、グループアドレスを入力するだけで、グループ全員に権限が付与されます。「管理者」「コンテンツ管理者」「投稿者」「閲覧者」の権限レベルもグループ単位で指定できます。共有ドライブの外部共有制御とグループ設計を組み合わせると、「この共有ドライブにアクセスできるのはこのグループだけ」という制御が明確になります。
Google Calendar
カレンダーの共有設定でグループアドレスを指定すれば、グループ全員にカレンダーの閲覧・編集権限が付きます。会議室カレンダーや部門カレンダーの共有にも使えます。
2026年7月7日の Google Workspace Updates では、Google Calendarに新しい共有権限「Make changes (see private events as free/busy)」が追加されると案内されました。これは、代理編集者に通常予定の作成・編集・削除を任せながら、非公開予定の件名、参加者、本文などの詳細は見せず、空き時間情報としてだけ表示する権限です。
役員、営業責任者、採用責任者のカレンダーを秘書・アシスタント・営業企画が管理する組織では、「編集できる人」と「非公開予定の詳細まで読める人」を分けられます。グループを権限ハブにする場合も、代理編集用グループを作るだけでなく、そのグループに非公開予定の詳細閲覧まで必要かを分けて判断します。
| カレンダー権限の論点 | 確認すること | 実務での扱い |
|---|---|---|
| 代理編集 | 通常予定の作成・変更・削除を任せるか | 秘書、営業企画、採用アシスタントなど役割単位で付与する |
| 非公開予定 | 詳細を読ませる必要があるか | 原則は空き時間表示に留め、詳細閲覧は最小限にする |
| 定期予定の公開範囲 | 一部だけ非公開にする運用が残っていないか | 定期予定全体の公開範囲として見直し、例外を別予定へ分ける |
同じ更新では、定期予定の公開範囲にも変更があります。定期予定の中の1回だけ公開範囲を変えることはできなくなり、既存の定期予定はシリーズ内で最も厳しい公開範囲に合わせて更新されます。たとえば定期の1回だけを非公開にしていた場合、シリーズ全体が非公開扱いになる可能性があります。部門定例、役員会、顧客定例などをグループで共有している場合は、公開範囲の例外が残っていないかを棚卸し対象に入れてください。
Google Chat
Chatのスペースにグループをメンバーとして追加できます。グループに新しいメンバーが入ると、そのスペースにもアクセスできるようになります。
管理コンソール
管理者ロールをグループに付与することも可能です。たとえば「admin-helpdesk@」グループにヘルプデスク管理者ロールを付与しておけば、ヘルプデスク担当者の追加・削除がグループメンバーの編集だけで完結します。
モバイルデバイス管理者はOU単位で委任する
2026年6月29日の Google Workspace Updates では、モバイルデバイス管理者権限を特定の組織部門（OU）に絞って委任できる機能が一般提供されたと案内されました。以前からベータ提供されていた管理粒度が正式化され、管理者は必要なOUの端末だけを表示・管理できるようになります。
この更新は、端末管理を現場に任せたいが、全社の端末管理権限までは渡したくない組織に向いています。たとえば、関西拠点のヘルプデスクには関西OUの端末だけ、人事部門の担当者には人事OUの端末だけを管理させる、といった分け方ができます。エンドユーザー側の操作は変わりませんが、管理者ロールの切り方は見直し対象になります。
| 委任対象 | 向いている使い方 | 確認すること |
|---|---|---|
| 拠点別ヘルプデスク | 担当拠点の端末登録、紛失対応、状態確認を任せる | 対象OUと例外端末の扱い |
| 部門別管理者 | 営業、CS、人事など端末リスクが高い部門を分ける | 部門異動時に端末OUも更新されるか |
| 外部委託先 | 限定範囲の一次対応だけを委託する | 契約範囲、操作ログ、ロール解除手順 |
権限ハブ設計では、グループに管理者ロールを付けるかどうかだけでなく、そのロールが全社に効くのか、OU単位に閉じるのかを分けて確認します。共有ドライブ権限と同じく、管理者権限も「必要な範囲だけ」に寄せる方が、退職、異動、委託終了時のリスクを下げやすくなります。
2026年6月のGroups内部/外部分類厳格化への対応
2026年6月24日にGoogleは、Google Groupsの内部グループ・外部グループの分類をより厳格に扱う更新を案内しました。Rapid ReleaseとScheduled Releaseの両方でロールアウトが始まり、2026年7月1日までに完了する予定とされています。
分類の基本はシンプルです。組織内メンバーだけで構成されるグループは内部グループとして扱われ、外部メンバーを含むグループは外部グループとして扱われます。権限管理のハブとしてGoogle Groupsを使っている場合、この分類は共有ドライブ、Calendar、Chat、管理ロール、信頼ルールの設計に影響します。
既存グループについては、現在のメンバー構成にもとづいて自動分類されるため、すぐにアクセスが変わるわけではありません。ただし、管理者はAdmin consoleまたはGroups Settings APIで分類を確認し、自社のセキュリティ要件に合うよう調整できます。
今回の更新では、グループ一覧や詳細画面で外部メンバーを含むかどうかが以前より分かりやすく表示されるようになりました。権限ハブとして使っているグループでは、名前だけで判断せず、この表示も棚卸しの入口に使う方が安全です。
| 確認項目 | 見る理由 | 実務での対応 |
|---|---|---|
| 既存グループの分類 | 外部メンバー入りのグループが権限ハブに使われていないかを見る | Admin consoleで内部/外部分類を棚卸しする |
| 外部メンバー追加設定 | 誰が外部ユーザーを追加できるかでリスクが変わる | 管理者のみか、管理者とエンドユーザーのどちらまで許可するか決める |
| 外部メンバーの視覚表示 | 権限ハブなのに外部メンバー入りのグループを見落としにくくする | 棚卸し一覧で外部表示のあるグループを優先確認する |
| API同期 | Directory APIやIdP同期で外部メンバーが入る場合がある | 同期元のグループ属性とWorkspace側の分類を突合する |
| 共有ドライブやCalendarの権限 | 外部グループ化で共有ポリシーと矛盾する可能性がある | 外部共有ルール、信頼ルール、対象リソースを同時に確認する |
特に注意したいのは、Directory APIや外部IDプロバイダとの同期です。Googleの案内では、API経由で外部メンバーを追加したり、第三者IDプロバイダからAPIでデータ同期したりする場合、管理者が外部メンバーを追加できるようグループ設定が自動更新されると説明されています。人手で作ったグループだけでなく、自動同期されるグループも棚卸し対象に入れる必要があります。
inbound SCIMでは同期グループを手動変更しない前提にする
2026年7月9日の Google Workspace Updates では、Google Workspace inbound SCIM APIの一般提供が案内されました。SCIMはIdP、HRIS、独自アプリケーションなどの外部ID基盤から、ユーザーやグループの作成、更新、無効化をリアルタイムに同期するための標準プロトコルです。
権限ハブ設計では、この更新を「ユーザー作成を自動化できる機能」とだけ見ない方が安全です。Googleの案内では、WorkspaceがSCIM Service Providerとして動き、外部ソースから同期されるグループをWorkspace側でロックして、IdPと衝突する手動変更を防ぐ管理機能も示されています。つまり、権限グループの正本がGoogle Groupsなのか、IdP/HRISなのかを先に決めておく必要があります。
| SCIM同期の論点 | 確認すること | 実務での扱い |
|---|---|---|
| 正本 | ユーザー・グループの作成元がIdP/HRISかWorkspaceか | 同期対象は外部ID基盤を正本にし、Workspace側の手動変更を避ける |
| 退職・異動 | 退職、休職、部門変更がどの速さでWorkspaceへ反映されるか | 共有ドライブ、Calendar、Chat、Gemini Enterpriseなど連携先アプリまで同じ解除条件で見る |
| 同期グループ | ロック対象のグループと手動運用グループが混在していないか | 命名規則で sync- / acl- などを分け、管理者が変更先を誤らないようにする |
| 外部メンバー | 外部メンバーを含むグループがSCIMで同期されるか | 内部/外部分類、信頼ルール、共有ポリシーと突合する |
入退社や異動の反映が速くなるほど、設定ミスも速く広がります。inbound SCIMを使う場合は、同期対象のOU、グループ、外部メンバー、ロック対象、例外的に手動管理するグループを一覧化し、共有ドライブやCalendarの権限棚卸しと同じタイミングで点検します。
加えて、外部メンバー追加権限を「管理者のみ」にするか、「管理者とエンドユーザー」に広げるかも今回の判断ポイントです。共同トレイや配信用グループならエンドユーザー追加を許可しても、共有ドライブや管理ロールの権限ハブに使うグループでは、原則として管理者のみへ寄せた方が事故を減らしやすくなります。
権限ハブとしてグループを使っている場合、パートナー企業のメンバーを含むグループ（ext-系）が外部分類になることで、信頼ルールや共有設定との整合性を確認する必要があります。内部グループにのみ共有を許可していた共有ドライブや、内部グループにのみ閲覧権限を付与していたカレンダーでは、外部メンバーを含むグループをそのまま使ってよいかを事前に確認します。
グループ種別をテンプレート化すると迷いにくい
権限ハブとしてグループを使う場合、毎回ゼロから命名や用途を考えると、同じ役割のグループが乱立しやすくなります。あらかじめ「権限用」「配信用」「案件用」の3種類をテンプレート化しておくと、管理者交代時も崩れにくくなります。
| グループ種別 | 主な用途 | 命名例 |
|---|---|---|
| 権限用 | 共有ドライブ、カレンダー、Chatスペースのアクセス制御 | perm-sales-west / perm-cs-managers |
| 配信用 | 全社告知、部門連絡、メーリングリスト | announce-all / notice-hr |
| 案件用 | 特定プロジェクトや一時的な横断チームの共有 | proj-renewal-2026 / taskforce-security |
このテンプレートを先に決めると、「権限グループなのに配信にも使う」といった混線を避けやすくなります。特に権限ハブ運用では、配信用グループと権限用グループを混ぜないことが事故防止に効きます。
よくある質問
グループの管理は誰が行うべきですか？
部門グループの日常的なメンバー管理は、各部門のマネージャーに委任するのが実務的です。管理コンソールで「グループオーナー」権限を部門マネージャーに付与すれば、情シスがすべてのメンバー追加・削除を担当する必要がなくなります。命名規則やグループ構造の設計自体は情シスが管理し、日常運用を現場に委任するという分担が効果的です。
グループを使うとメールが大量に届きませんか？
権限用グループ（acl-系）はメール配信をオフにできます。グループの設定で「ウェブのみ」にすれば、メール配信なしで権限付与だけに使えます。配信用と権限用を分離する設計であれば、権限用グループへのメール配信は不要です。
既存の個人権限をグループに移行するにはどうすればよいですか？
一括移行は手作業になります。まず対象リソース（共有ドライブ、カレンダーなど）ごとに現在の権限付与状況を棚卸しし、対応するグループを作成し、グループに権限を付与してから個人の権限を削除する手順です。Google Workspace Admin SDKを使えばスクリプトで自動化も可能ですが、影響確認を含めると段階的に移行するのが安全です。
グループが多すぎて管理しきれなくなりませんか？
命名規則がなければ確実にそうなります。命名規則を整備し、用途ごとの接頭辞で分類し、定期的に使われていないグループを棚卸しするサイクルを作ることが前提です。監査ログを確認して、メンバーが0人のグループや、長期間活動がないグループを特定する運用も有効です。
MDM管理者権限は全社一括で渡すべきですか？
原則として、必要なOUに限定して委任する方が安全です。Google Workspaceではモバイルデバイス管理者権限をOU単位で委任できるため、拠点や部門の一次対応者に全社端末を管理できる権限を渡さずに済みます。委任先、対象OU、操作ログ、解除手順をセットで管理します。
内部/外部分類の変更で既存アクセスはすぐ変わりますか？
Googleの案内では、既存グループは現在のメンバー構成にもとづいて自動分類され、すぐにアクセス変更が起きないよう扱われます。ただし、外部メンバーを含むグループを共有ドライブ、Calendar、Chat、管理ロールに使っている場合は、分類と共有ポリシーの整合を確認する必要があります。
外部メンバーの表示が増えたら何を見直すべきですか？
まず、そのグループが配信用なのか権限ハブなのかを分けて確認します。権限ハブなら、共有ドライブ、Calendar、Chatスペース、管理ロールの付与先になっていないかを見直し、必要なら外部協業用グループと内部権限用グループを分離します。
APIやIdP同期で作られるグループも確認すべきですか？
確認すべきです。Directory APIや第三者IDプロバイダ経由で外部メンバーが同期される場合、Workspace側のグループ設定が自動更新されることがあります。inbound SCIMを使う場合は、IdPやHRISから同期されるユーザー・グループ、ロック対象、外部メンバーの有無、権限付与先をセットで棚卸しします。
inbound SCIMで同期されるグループは手動変更してよいですか？
原則として、同期元のIdPやHRISを正本にします。Workspace側で手動変更すると、次回同期で上書きされたり、権限の根拠が追えなくなったりします。同期グループと手動管理グループを命名規則で分け、例外変更は申請とログを残して扱う方が安全です。
Google Calendarの新しい共有権限は何を変えますか？
通常予定の編集を代理者へ任せながら、非公開予定の詳細を隠せるようになります。役員や営業責任者のカレンダーを複数人で管理する場合は、編集権限を持つグループと、非公開予定の詳細まで見られる人を分けて設計できます。定期予定では、シリーズ内の一部だけ公開範囲を変える運用ができなくなるため、例外予定は別予定として分ける方が安全です。
