既にActive Directoryを運用している組織では、IDaaSを新たに導入しなくてもGoogle WorkspaceのID管理は成立します。ADをIDの正とし、GCDS（Google Cloud Directory Sync）で同期する構成なら、運用を一本化でき、追加のライセンス費用も発生しません。IDaaSが効くのは「連携先SaaSが多い」「条件付きアクセスの要件が細かい」「AD廃止方針がある」「ライフサイクル管理を自動化したい」のいずれかに該当する場合です。判断は要件の列挙から始めてください。
Google Workspace の導入提案を受けると、多くの場合セットでIDaaS（ID管理・認証基盤サービス）が組み込まれています。多要素認証、シングルサインオン、アクセス制御を一元化できる、という説明です。
機能としては正しい説明です。ただし、既にActive Directoryを運用している組織では、IDaaSを新たに導入しなくても要件を満たせるケースがあります。ライセンスは利用者数に比例するため、数千名規模なら年間コストの差は無視できません。
基本構成はAD＋GCDS
既存のADをIDの正とし、GCDS でGoogle Workspace 側へ同期する構成です。
- ユーザー、グループ、組織部門をADから同期する
- 入退職・異動はAD側の操作が起点になり、Google Workspace 側へ反映される
- 認証はGoogle側で行う、またはADと連携させる
この構成の利点は明快です。ID管理の運用を一本化できること、そして追加のライセンス費用が発生しないことです。
数千名規模のある組織では、この構成を採用し、IDaaSの新設を見送りました。既にADでの権限管理と人事異動対応の運用が確立しており、そこに新しい基盤を挟む合理性がなかったためです。既存の運用が回っているなら、それを壊さない選択にも十分な価値があります。
Microsoft 365・Google Workspace の設計から運用までを、情報システム部門の一機能として引き受けます。移行プロジェクトの計画策定と実行支援もご相談いただけます。
情シス365 を見る →ITアウトソーシングGCDS運用で押さえるべき5点
そのまま入れれば動く、というものでもありません。実務で注意すべき点を挙げます。
| 論点 | 押さえるべきこと |
|---|---|
| 組織部門（OU）の設計 | Google Workspace のOU構造はポリシー適用の単位。ADの組織構造をそのまま写すとポリシー設計と噛み合わないことがある。「人事上の組織」と「ポリシー適用上のグループ」は別物として設計する |
| 同期対象範囲の限定 | ADには退職者、システムアカウント、テスト用アカウントなどが混在する。フィルタで明示的に限定しないと不要なライセンスを消費する |
| 削除時の挙動 | AD側でユーザーを削除したときGoogle Workspace 側でどう扱うか（削除・停止・保留）は設定次第。詰めずに本番投入すると事故につながる |
| 同期エラーの検知 | GCDSは同期が失敗しても気づかなければそのまま。ログの出力先と失敗時の通知経路を運用設計に含める |
| 休職者・長期不在者の扱い | 専用のOUを作り、機能を制限した安価なライセンスを割り当てる設計が有効。数十名分でも複数年契約なら金額として効く |
最後の点は、実際の案件で論点になったものです。休業中の職員が一定数いる組織では、その分のライセンスをどう扱うかで費用が変わります。「在籍しているから全員フルライセンス」と決めてしまう前に、利用実態に応じた区分を検討してください。
特に3番目の削除挙動は、テスト環境で必ず確認すべき項目です。AD側の一括整理をきっかけに、Google Workspace 側のアカウントとデータが想定外に失われる事故は、実際に起きうる類型です。
IDaaSが必要になる4つの条件
一方で、以下に該当するならIDaaSの導入を検討する価値があります。
| 条件 | なぜ効くか |
|---|---|
| 連携先のSaaSが多い | Google Workspace 以外にも複数のSaaSを利用し、それぞれで認証を管理しているなら集約の効果が出る。Google Workspace 単体のためだけに入れるのは割高 |
| 条件付きアクセスの要件が細かい | 「社内ネットワークからは多要素認証を省略」「管理下の端末以外は特定機能のみ」といった条件を細かく設計したい場合、専用基盤があると実現しやすい |
| ADを持たない、または廃止方針 | オンプレADの維持そのものをやめたい方針なら、クラウド側にIDの正を移す設計になる |
| ライフサイクル管理を自動化したい | 人事システムを起点に入社・異動・退職の処理を自動化したい要件があるなら、専用製品のほうが実装は容易 |
2番目については注意が必要です。Google Workspace 側にも一定の条件付きアクセス機能があり、上位エディションではさらに細かい制御が可能です。要件を具体化してから比較しないと、既にある機能に対して重複投資することになります。Microsoft 側の同種機能との比較は条件付きアクセスの設定パターンが参考になります。
判断の順序を間違えない
提案を受ける側として、次の順で確認することをお勧めします。
- 実現したい認証・アクセス制御の要件を、具体的に列挙する
- その要件がGoogle Workspace 標準機能と既存ADの範囲で満たせるか確認する
- 満たせない要件だけを対象に、追加製品を検討する
「IDaaSを入れるか入れないか」から議論を始めると、機能の総論比較になって結論が出ません。製品同士を並べれば、どちらにも相手にない機能が必ず見つかります。それは自組織にとって必要かどうかとは別の話です。
要件を先に固め、埋まらない差分にだけ製品を当てる。費用対効果の判断はこの順序でしか行えません。そして要件を列挙する際は、「あったら便利」と「なければ業務が回らない」を分けて書いてください。この区別がないまま列挙すると、結局すべてが必須要件として扱われます。
よくある質問
Google Workspace導入にIDaaSは必須ですか？
必須ではありません。既にActive Directoryを運用している組織なら、ADをIDの正としてGCDSで同期する構成で要件を満たせるケースがあります。ID管理の運用を一本化でき、追加のライセンス費用も発生しません。数千名規模なら年間コストの差は無視できない金額になります。
GCDSで同期する際に特に注意すべき点は何ですか？
組織部門の設計、同期対象範囲の限定、削除時の挙動、同期エラーの検知経路、休職者の扱いの5点です。特に削除挙動は、AD側でユーザーを削除したときGoogle Workspace側でどう扱うか（削除・停止・保留）が設定次第のため、テスト環境で必ず確認してから本番投入してください。
ADの組織構造をそのままGoogle Workspaceの組織部門に写してよいですか？
推奨しません。Google Workspaceの組織部門はポリシー適用の単位であり、人事上の組織構造とは目的が異なります。そのまま写すとポリシー設計と噛み合わず、後から作り直すことになります。人事上の組織とポリシー適用上のグループは別物として設計してください。
IDaaSを導入したほうがよいのはどんな場合ですか？
連携先のSaaSが多い場合、条件付きアクセスの要件が細かい場合、ADを持たないか将来的に廃止する方針がある場合、人事システムを起点にライフサイクル管理を自動化したい場合の4つです。Google Workspace単体のためだけに導入するのは割高になります。
休職者や長期不在者のライセンスはどう扱えばよいですか？
専用の組織部門を作り、機能を制限した安価なライセンスを割り当てる設計が有効です。在籍しているから全員にフルライセンスを割り当てると決める前に、利用実態に応じた区分を検討してください。数十名分でも複数年契約なら金額として効いてきます。
まとめ
既存のActive Directory があるなら、GCDS連携でGoogle Workspace のID管理は成立します。IDaaSは提案にセットで入りがちですが、既存の運用が回っているなら、それを壊さない選択にも価値があります。
GCDS運用では、組織部門の設計、同期対象範囲、削除時の挙動、エラー検知の経路、休職者の扱いを事前に詰めてください。特に削除挙動はテスト環境での確認が必須です。
IDaaSが効くのは、連携SaaSが多い／条件付きアクセスの要件が細かい／AD廃止方針がある／ライフサイクル自動化をしたい、のいずれかです。判断は「要件の列挙 → 標準機能での充足確認 → 差分に製品を当てる」の順序で行ってください。