Google Workspaceの組織部門（OU）設計｜ポリシーの使い分け

Google Workspaceの管理コンソールで設定するポリシー（アプリの有効/無効、外部共有の制限、モバイル管理等）は、組織部門（OU：Organizational Unit）単位で適用されます。OU設計が雑だと「全員に同じポリシー」しか適用できず、部署ごとの要件に対応できません。

OUとは

OUは、GWSのユーザーをグループ化する階層構造です。Active Directoryの「組織単位（OU）」と同じ概念で、OU単位でポリシーを継承・上書きできます。

最上位には「ルート組織」があり、その配下にOUを作成します。子OUは親OUのポリシーを継承しますが、個別に上書きすることも可能です。

OU設計のパターン

パターン1：部署ベース（最も一般的）

ルート組織
├── 経営管理部
├── 営業部
├── 開発部
├── 管理者（IT担当）
└── 外部委託・パートナー

部署ごとに異なるアプリ設定やDrive共有ポリシーを適用できます。

パターン2：グループ会社ベース（M&A後の統合環境）

ルート組織
├── 親会社
│   ├── 営業部
│   └── 管理部
├── 子会社A
│   ├── 営業部
│   └── 製造部
└── 子会社B

グループ会社ごとに異なるセキュリティポリシーを適用する場合に有効です。

パターン3：役職ベース（セキュリティ重視）

ルート組織
├── 経営層（厳格なポリシー）
├── 管理職
├── 一般社員
├── アルバイト・パート（制限付き）
└── IT管理者

OUで制御できる主な設定

Gmailの設定： 外部送信の制限、免責事項の自動追加、メールルーティング

Driveの設定： 外部共有の許可/禁止、ダウンロード制限、共有ドライブの作成権限

アプリの有効/無効： 特定のOUでのみYouTubeやGeminiを無効化

モバイル管理： OUごとに異なるモバイルポリシー（画面ロック要件、アプリ制限）

2段階認証： OUごとに強制の有無や許可する認証方法を設定

OUとグループの使い分け

OUは組織構造、グループは横断的な例外と考えると整理できます。

	OU	グループ（設定グループ）
所属	1ユーザー1つだけ	複数に所属できる
向いている用途	部署・拠点・雇用形態など、恒久的な区分	兼務者、プロジェクト、一時的な例外
適用の優先	基本のポリシー	OUの設定を上書きする

設計の起点はOUにしてください。 グループでの例外を先に積み上げると、「なぜこの人だけこの設定なのか」が追えなくなります。

例外を作るときは、期限と理由を記録に残してください。 「一時的に許可」がそのまま残り、数年後に誰も理由を説明できない設定になっているのは、よくある状態です。

実運用でつまずく点

人事異動時のOU移動が漏れる

OUを部署ベースで作ると、異動のたびに移動作業が発生します。 移動が漏れると、旧部署のポリシーが適用され続けます。

• 人事異動の情報がIT担当に届く経路を作る（退職者対応と同じ課題です）
• 難しければ、四半期に1回、在籍者一覧とOU配置を突き合わせる
• 人数が多い場合は、人事システムからの自動同期を検討する

退職者・休職者用のOUを1つ作っておく

退職手続きの途中や、長期休職中のアカウントを置く先を決めておくと管理しやすくなります。このOUには、アプリの利用を制限したポリシーを割り当てておきます。

外部委託・パートナー用のOUを分ける

社外の担当者に自社アカウントを発行する場合、共有の制限や利用できるアプリを絞ったOUに入れます。ルート直下の既定OUに入れてしまうと、正社員と同じ権限になります。

テスト用のOUを用意する

新しいポリシーをいきなり全社に適用すると、影響範囲が読めません。IT担当者だけが所属するOUで先に試す運用にしてください。

設計時の注意点

1ユーザーは1OUにのみ所属： GWSのOUは「1ユーザーが複数OUに所属」はできません。兼務者のポリシー適用はGoogleグループ（設定グループ）で補完します。

OU変更の即時反映： ユーザーのOU移動は即座にポリシーに反映されます。人事異動時のOU移動は慎重に。

OUの階層は浅く： 3階層以上のネストは管理が複雑になります。2階層（ルート→部署）で十分なケースが大半です。

最初からすべてを作らない： まずルート直下に「IT管理者」OUだけ作り、管理者に厳格なポリシーを適用するところから始めるのが現実的です。

ルート組織の設定は全員に影響する： ルートを変更すると、上書きしていないすべてのOUに反映されます。「一部の部署のために」ルートを緩めると、全社が緩みます。 制限はルートで厳しく設定し、必要なOUだけ緩める方向で設計してください。逆にすると、新しく作ったOUが既定で緩い状態になります。

部署名をそのままOU名にしない： 組織変更のたびにOU名の変更が発生します。頻繁に名前が変わる組織では、「営業」「開発」といった大きな括りに留めるほうが維持しやすくなります。

変更内容は記録に残す： 管理コンソールの設定は、いつ誰がなぜ変えたかが後から追いにくいものです。簡単な変更履歴（日付・変更内容・理由）をスプレッドシートで管理しておくと、トラブル時の切り分けが早くなります。

まとめ

• OUは組織構造、グループは横断的な例外。設計の起点はOUにする
• グループでの例外には期限と理由を記録する。「一時的に許可」が数年残るのを防ぐ
• 部署ベースのOUは異動のたびに移動作業が発生する。四半期の突合で漏れを拾う
• 退職者・休職者用OU、外部委託用OU、テスト用OUを先に作っておく
• 外部委託者をルート直下の既定OUに入れると、正社員と同じ権限になる
• 新ポリシーはIT管理者OUで先に試す
• ルートを緩めると全社が緩む。制限はルートで厳しく、必要なOUだけ緩める
• 組織変更が多いなら、OU名は大きな括りに留める
• 管理コンソールの変更は追いにくい。変更履歴を別途記録しておく
• 1ユーザーは1OUのみ、階層は2階層が基本、管理者OUから段階的に拡張する

情シス365では、Google Workspaceの組織設計を支援しています。お気軽にご相談ください。