Google Workspace セキュリティグループの使い分け

Google Workspace の管理コンソールでは、Google グループに「Security」ラベルを付与することで、メンバー構成を厳密に保つセキュリティグループを作成できます。CAA（Context-Aware Access）ポリシーの適用先や Vault ホールドの対象にグループを使う場合、通常グループとセキュリティグループのどちらを選ぶかが設計の堅牢性に直結します。

この記事を読んだほうが良い人

• Google グループを CAA ポリシーの適用先として使っている情シス担当者
• Google Vault のホールド対象にグループを指定している担当者
• 管理コンソールで「セキュリティグループ」の設定を見かけたが、通常グループとの違いが整理できていない方
• 機密データを含む共有ドライブのアクセス管理グループを設計中の方

Google Workspace セキュリティグループとは？

セキュリティグループは、通常の Google グループに「Security」ラベルを付与したものです。メール配信やカレンダー招待などのグループとしての基本機能は変わらず、メンバーシップ制御に関する追加の制約が加わります。

Security ラベルは、グループの新規作成時に付与する方法と、既存グループに対して後から付与する方法の両方が使えます。ただし、いったん付与したラベルは削除できない点が重要で、テスト運用には向かない仕様です。

Google のヘルプドキュメントには「ポリシーを適用するグループはすべてセキュリティグループにすることを推奨する」と明記されています。アクセス制御やポリシー適用の目的で使うグループは、メンバーの構成を厳密に保つ必要があるためです。

セキュリティグループの中心的な特性は次の 2 点です。

• 外部ユーザー（組織外アカウント、non-Google アカウントを含む）をメンバーに追加できない
• 同一組織内のセキュリティグループ以外のグループをネストできない

通常グループでも「外部ユーザーの追加を禁止する」という運用ルールは作れますが、それはあくまでも人的・組織的なコントロールです。一方、セキュリティグループはシステムが追加操作を拒否するため、担当者の判断や作業ミスに依存しません。

2026年2月に発表された内部・外部メンバー分類の強化（2026年5月より展開中）も、セキュリティグループが持つ「組織外ユーザーを含めない」という原則と同じ方向性です。GWS のガバナンス方針として、ポリシー適用先のグループはセキュリティグループを基本とする設計が今後さらに重要になります。

通常グループとセキュリティグループの違い

2 種類の違いを一覧で整理します。

比較項目	通常グループ	セキュリティグループ
外部ユーザーの追加	可能（設定次第）	不可
外部グループのネスト	可能	不可（同一組織のセキュリティグループのみ）
Security ラベルの解除	—	永続的（一度付与したら取り外し不可）
ネストするグループの条件	制限なし	同等以上のメンバーシップ制限が必要
組織全体への自動追加	有効にできる	無効化される
CAA ポリシー適用の推奨度	非推奨	推奨
Vault ホールド対象	使用可	推奨

最も大きな違いは「制約がシステムによって強制されるかどうか」です。通常グループで外部ユーザーの追加を防ぐには、グループ設定や管理ルールへの依存が避けられません。セキュリティグループでは追加操作自体がシステムに弾かれるため、ガバナンスの確実性が格段に上がります。

セキュリティグループが推奨される場面

CAA ポリシーの適用先グループ

CAA（Context-Aware Access）は、アクセスレベルをユーザー単位またはグループ単位で割り当てる機能です。通常グループを使った場合、外部ユーザーや非セキュリティグループがそのグループにネストされていると、管理者が意図しないユーザーにポリシーが適用される（またはポリシー対象から漏れる）リスクがあります。

具体的な事故シナリオを考えます。開発部門全員を対象に「管理対象デバイスからのみ Google Drive にアクセス可」という CAA ポリシーを設定していたとします。その適用先グループが通常グループだった場合、グループのオーナーや管理者権限を持つ人なら誰でもメンバーを追加できます。そこに外部コントラクターが誤ってメンバーとして追加されると、そのユーザーも CAA ポリシーの適用対象に含まれます。デバイスコンプライアンスを満たしていないコントラクターのアクセスが制限される、または意図しない権限が付与される状況が起きます。

問題はこの変更が CAA 設定画面には一切反映されない点です。ポリシーの設定は変わっていなくても、グループ構成が変われば効果範囲が変わります。セキュリティグループにしておけば、外部ユーザーの追加がシステムに弾かれるため、このリスク自体を排除できます。

グループ構成が変わらない限り、CAA ポリシーの効き方も変わらない。この前提を担保するのがセキュリティグループの役割です。

Google Vault ホールドの対象グループ

法的調査や訴訟対応でデータ保全が必要になるケースを想定します。ある部門のメンバー全員のメール・チャットを Vault でホールドする際、対象をグループで指定することが多くあります。このグループが通常グループのままだと、メンバーの出入りに応じてホールド範囲が変動します。誰かがグループを退出した時点でその人のデータがホールドから外れたり、新たに加わったメンバーに対してホールドが自動的に適用されなかったりという状況が起きます。

セキュリティグループに切り替えることで「意図せず外部ユーザーがホールド対象に含まれる」または「外部ユーザーがホールドから外れる」リスクを防げます。法的保全や調査対応の文脈でグループを使う場合は、セキュリティグループを前提に設計してください。

管理ロール委任の対象グループ

管理コンソールで特定の管理ロールをグループ単位で委任する場合も、セキュリティグループを使う方が安全です。通常グループを委任先に使うと、グループオーナーが外部ユーザーを追加した場合に、そのユーザーが組織の管理権限を得てしまう可能性があります。管理ロールの委任先グループは、セキュリティグループとして構成することを原則にしてください。

機密データを含む共有ドライブの管理グループ

共有ドライブのアクセス管理にグループを使う場合（特に財務・法務・人事などの機密データを含むドライブ）、セキュリティグループを使うことで外部ユーザーが誤ってアクセス権を得るリスクを防ぎます。すべての共有ドライブのグループをセキュリティグループにする必要はありませんが、機密性が高いドライブのアクセス管理グループは、セキュリティグループへの切り替えを優先的に検討してください。

セキュリティグループの制約事項

使い始める前に把握しておきたい制約を整理します。

① 外部ユーザーをメンバーに追加できない

組織外のアカウント（non-Google アカウントを含む）はメンバーに追加できません。外部パートナーやコントラクターをメンバーに含める必要がある場合は、通常グループを使う必要があります。対処策としては、外部向けグループと内部向けセキュリティグループを分けて管理する設計が一般的です。

② Security ラベルは永続的（取り外し不可）

一度付与した Security ラベルは削除できません。テスト目的で付けてみるという使い方はできないため、付与前にメンバー構成と用途を十分に確認してください。本番適用前に、別のグループで同様の構成を試すことを推奨します。

③ ネストできるのは同一組織内のセキュリティグループのみ

通常グループをセキュリティグループにネストすることはできません。既存のグループ構成をそのまま Security 化しようとすると、ネスト構造の見直しが必要になるケースがあります。複数のグループが入れ子になっている構成では、末端（子グループ）から順に Security 化する「ボトムアップ方式」で進める必要があります。

④ ネストするグループの制限条件

セキュリティグループにネストするグループは、同等以上の制限（メンバーシップ設定がより厳格）である必要があります。制限が緩いグループをネストしようとするとエラーになります。事前にネスト対象のグループの設定を確認してください。

⑤ 組織全体への自動追加が無効になる

「組織の全メンバーを自動的に追加する」設定がある場合、Security ラベルを付与するとその設定が無効化されます。全社メールグループへの Security ラベル付与は、影響範囲を確認したうえで慎重に判断してください。

既存グループの棚卸しアプローチ

すでに Google Workspace を運用している組織では、ポリシー適用目的と一般的なメール・Chat 目的のグループが混在していることが多くあります。以下の手順で棚卸しを進めてください。

まず、現在 CAA ポリシー・Vault ホールド・管理ロール委任の対象として使われているグループをリストアップします。これらが最初に確認すべき対象です。

次に、リストアップしたグループについて次の観点を確認します。

• セキュリティグループとして設定済みか
• 外部メンバーが含まれているか
• 通常グループがネストされていないか

セキュリティグループに切り替える順序は、機密性・影響範囲の大きいものから優先します。管理ロール委任グループ → CAA ポリシー適用グループ → Vault ホールドグループ → 共有ドライブ管理グループ、の順で進めるとリスクを抑えながら対応できます。

切り替え前の準備として、対象グループから外部メンバーを外し、ネストされている通常グループを先に Security 化（またはネストを解除）しておく必要があります。Security ラベルは一方通行なので、準備が整ってから付与するよう注意してください。

どちらを使うか：判断フロー

以下の観点で判断します。

セキュリティグループを選ぶ場合

• CAA ポリシーの適用先グループ
• Vault ホールドの対象グループ
• 管理ロールの委任先グループ
• 機密データを含む共有ドライブのアクセス管理グループ
• 外部ユーザーを含める必要がなく、メンバー構成の整合性が設計上重要なグループ

通常グループを選ぶ場合

• 外部パートナーやコントラクターを含めるメールグループ
• ゲストを招待する必要があるカレンダー・Chat グループ
• 組織横断プロジェクトで外部参加者を含む共同作業グループ

迷った場合の判断基準は「このグループにポリシーを適用するか」と「メンバーの誤追加が設計上の問題になるか」の 2 点です。どちらかに YES であれば、セキュリティグループが適切な選択肢です。

なお、Security ラベルは一方通行で付与できる点を利用して、「まず通常グループで運用し、ポリシー適用が必要になったタイミングでセキュリティグループに切り替える」という段階的なアプローチも取れます。ただし、切り替え時にネスト構造の整理が必要になる場合があるため、早めに設計方針を固めておく方が後の手戻りは少なくなります。

まとめ

セキュリティグループは「ポリシーを適用するグループの専用区画」として設計されています。CAA ポリシー・Vault ホールド・管理ロール委任など、アクセス制御に関わるグループをセキュリティグループに統一しておくことが、Google Workspace のガバナンス設計における基本方針です。

通常グループはメンバーの自由度が高い分、ポリシー適用先としてはメンバー構成の管理が難しくなります。用途をはっきり分けて設計することで、CAA の意図しない適用外れや Vault のホールド漏れを防ぐことができます。

次のアクションとして、まず「現在ポリシーに使われているグループの一覧を取得する」ところから始めてください。ポリシー適用先でありながら通常グループのままになっているものが見つかれば、それがセキュリティグループへの移行候補です。棚卸しの結果によっては、グループ設計全体の再整理が必要になることもあります。グループ設計・OU 設計・CAA ポリシー設計の整合性確認は、100 名規模でも意外と複雑な作業になります。DRASENAS では GWS のガバナンス設計支援を業務委託で承っています。DRASENAS 公式サイトからお気軽にご相談ください。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。