1.1 ユーザーライフサイクルの管理
プロビジョニングから削除まで — アカウント管理の全プロセスを完全解説
ユーザーアカウント作成方法の比較 試験頻出
組織の規模・技術スタックに応じて最適な手法を選択する。
| 作成手法 | 適したシナリオ | スケール | 特徴 |
|---|---|---|---|
| 管理コンソール（手動） | 少人数・テストアカウント | ≈10名 | GUI操作、即時反映 |
| CSV 一括アップロード | 定期採用・初期移行 | ≈数千名 | フォーマット正確性が必須 |
| Directory API | 人事システムとの連携 | 無制限 | リアルタイム自動プロビジョニング |
| GCDS | AD/LDAP環境との同期 | 大規模 | 一方向同期(AD→Google)、定期実行 |
| サードパーティ IdP (SAML) | Okta/Azure ADとの統合 | 大規模 | SSO + SCIMプロビジョニング |
手動作成 — ステップバイステップ
1
管理コンソールを開く管理コンソール →ディレクトリ→ユーザー→「新しいユーザーを追加」をクリック
2
基本情報を入力姓・名・プライマリメールアドレス（ユーザー名@ドメイン）を入力。メールアドレスは後から変更可能だが、変更時に旧アドレスはエイリアスに変換される。
3
組織部門（OU）を選択所属させる OU を指定する。この選択でポリシーが決まるため慎重に。
4
パスワード設定自動生成、または手動設定。「次回ログイン時にパスワード変更を要求」にチェックを入れる（セキュリティのベストプラクティス）。
5
ライセンス割り当て作成完了後、または自動割り当て設定済みなら不要。
CSV一括作成 — フォーマット例
# CSV テンプレートの必須列
First Name,Last Name,Email Address,Password,Org Unit Path
山田,太郎,taro.yamada@example.com,TempPass123!,/営業部
鈴木,花子,hanako.suzuki@example.com,TempPass456!,/開発部
First Name,Last Name,Email Address,Password,Org Unit Path
山田,太郎,taro.yamada@example.com,TempPass123!,/営業部
鈴木,花子,hanako.suzuki@example.com,TempPass456!,/開発部
GCDS（Google Cloud Directory Sync）詳解 重要
オンプレミスAD/LDAPとGoogle Workspaceを継続的に同期させるツール。
GCDS の同期方向は「一方向のみ」
AD/LDAP → Google Workspace の方向のみ。Google側で変更した内容はADに反映されない。
AD/LDAP → Google Workspace の方向のみ。Google側で変更した内容はADに反映されない。
Active Directory
真実のソース
真実のソース
→
GCDS
差分検出・同期
差分検出・同期
→
Google Workspace
自動反映
自動反映
GCDS でできること
✅ 同期対象
- ユーザーの作成・更新・削除/停止
- グループ・配信リストの同期
- カスタム属性のマッピング
- 組織部門（OU）の割り当て
❌ 同期対象外
- メールデータ（メール移行は別ツール）
- カレンダーデータ
- ドライブファイル
- Workspace固有の設定変更
設定手順
1
ツールをインストールGCDSをオンプレミスサーバーにインストール（Windows/Linux対応）
2
AD/LDAP接続設定サーバーアドレス、ポート、認証情報（サービスアカウント）を設定
3
同期ルールを定義LDAPクエリで同期対象ユーザー・グループを絞り込む
4
Google Workspaceと接続管理者アカウントのOAuth認証を設定
5
⚠️ シミュレーションを実行必ず本番同期前にドライランを実施し、意図しないユーザー削除がないことを確認！
6
スケジュール実行を設定例: 毎時自動同期でリアルタイムな状態維持
GCDS ≠ メール移行ツール
試験頻出の誤解！GCDSはユーザー/グループ情報の同期専用。メールデータの移行には別途「データ移行サービス」「GWMME」「Google Workspace Migrate」を使用する。
試験頻出の誤解！GCDSはユーザー/グループ情報の同期専用。メールデータの移行には別途「データ移行サービス」「GWMME」「Google Workspace Migrate」を使用する。
移行ツール完全比較 試験頻出
| ツール名 | 移行元 | 移行対象データ | 規模 |
|---|---|---|---|
| データ移行サービス Admin コンソール内 | Exchange, M365, Gmail(他組織), IMAP | メール・カレンダー・連絡先 | 小〜中 |
| GWMME Google Workspace Migration for Microsoft Exchange | Microsoft Exchange オンプレミス | メール・カレンダー・連絡先 | 中〜大 |
| Google Workspace Migrate | Exchange, SharePoint, Box, ファイルサーバー | メール・ファイル・カレンダー | 大規模・複雑 |
| Gmailのインポート機能 | IMAPサーバー（個人向け） | メールのみ | 個人 |
| GCDS | Active Directory / LDAP | ユーザー・グループ情報のみ | 中〜大 |
SAML SSO — サードパーティ IdP との認証連携 重要
SP-Initiated SSO
- ユーザーがGoogle(SP)にアクセス
- 未認証の場合 IdP にリダイレクト
- IdP で認証 → SAML アサーション発行
- Google がアサーションを検証してログイン
- ブックマーク・URL直接アクセス向け
IdP-Initiated SSO
- ユーザーが IdP ダッシュボードにログイン
- アプリアイコンをクリック
- SAML アサーション付きでGoogleへ遷移
- Google がアサーションを検証してログイン
- 社内ポータルからのアクセス向け
設定手順（Admin コンソール）
1
設定画面を開く管理コンソール →セキュリティ→認証→サードパーティ IdP での SSO
2
SSO プロファイルを有効化「SSO プロファイルを使用する」をオンにする
3
URL を入力IdPが提供する「ログインページURL」「ログアウトページURL」「パスワード変更URL」を入力
4
証明書をアップロードIdPの署名証明書（X.509形式）をアップロードしてアサーション検証を可能にする
5
ネットワークマスクを設定必要に応じて、社内IPアドレスからはSSO不要でアクセス可能にする
スーパー管理者は SSO 対象から除外する
IdP が障害を起こした際の緊急アクセスを確保するため、スーパー管理者アカウントはSSO対象から除外し、直接ログインを維持する。
IdP が障害を起こした際の緊急アクセスを確保するため、スーパー管理者アカウントはSSO対象から除外し、直接ログインを維持する。
アカウント状態管理 — 停止・削除・アーカイブ試験最頻出
退職者処理において正しい状態を選択することがコスト最適化とデータ保護の鍵。
✅ アクティブ
- ✓ 通常稼働状態
- ✓ ログイン可能
- ✓ データアクセス可能
- ✓ ライセンス消費あり
⏸ 停止（Suspend）
- ✗ ログイン不可
- ✓ データは保持
- ⚠ ライセンス消費継続
- ✓ いつでも復元可能
- 用途: 休職・調査・一時停止
📦 アーカイブ
- ✗ ログイン不可
- ✓ データは無期限保持
- 💰 低コストライセンスに変更
- ✓ Vaultでデータ保持
- 用途: 退職者のデータ長期保持
🗑 削除（Delete）
- ✗ ログイン不可
- ⚠ データは20日間のみ
- 💰 ライセンス解放
- ✅ 20日以内なら復元可
- 用途: データ不要の退職者
削除後 20 日でデータは完全消滅
削除後 20 日を過ぎると復元不可。法的要件やデータ保持義務がある場合は必ず「アーカイブ」を使用すること。
削除後 20 日を過ぎると復元不可。法的要件やデータ保持義務がある場合は必ず「アーカイブ」を使用すること。
退職者処理のゴールデンフロー ✦ ベストプラクティス
🔒 Step 1
即時アクション
即時アクション
パスワードリセット・ログインセッション無効化・モバイルデバイスワイプ
↓
⏸ Step 2
暫定対応
暫定対応
アカウントを「停止」、メール転送・受信トレイ委任で業務引き継ぎ確認
↓
📂 Step 3
データ移転
データ移転
Driveデータの所有権を後任者・管理アカウントに移転（マイドライブのみ対象）
↓
📦 Step 4
最終処理
最終処理
データ保持必要 → アーカイブ / 不要 → 削除（ライセンス回収）
ユーザー属性の変更と管理
| 属性 | 変更後の挙動 | 注意点 |
|---|---|---|
| プライマリメールアドレス | 旧アドレスは自動的にエイリアスとして保持 | 外部サービスへの影響を事前確認 |
| メールエイリアス | 受信のみ可能（最大30個） | 送信は常にプライマリアドレス |
| 表示名（姓・名） | メールアドレスは変わらない | 変更はすぐに反映される |
| 組織部門（OU） | 移動後はその OU のポリシーが即時適用 | ポリシー変更のユーザーへの影響を考慮 |
| パスワード | 管理者はいつでもリセット可能 | 「次回変更強制」フラグを活用 |
パスワードポリシーの推奨設定
| 設定項目 | 推奨値 | 根拠 |
|---|---|---|
| 最低文字数 | 12文字以上 | ブルートフォース攻撃への耐性向上 |
| 最大文字数 | 100文字 | パスフレーズを許可 |
| 強度の強制 | 有効 | 推測されやすいパスワードを拒否 |
| 定期的な変更強制 | 設定しない方向で検討 | NIST SP 800-63B に準拠。強制変更は弱いパスワードを誘発する可能性 |
| 再利用禁止 | 有効 | 古いパスワードへの回帰を防ぐ |
✦ セクション 1.1 ベストプラクティス総まとめ
- GCDS は「ユーザー/グループ同期ツール」であり「メール移行ツール」ではないことを明確に区別する
- スーパー管理者アカウントは日常業務用アカウントと完全に分離し、専用アカウントを使用する
- 本番同期の前に GCDS の「シミュレーション実行（ドライラン）」で意図しない削除がないことを確認する
- 退職者は即時「停止」し、データ所有権移転後にアーカイブまたは削除する（削除の20日ルールに注意）
- パスワードリセット時は必ず「次回ログイン時に変更を要求」フラグを有効にする
- 新規採用者の自動プロビジョニングに GCDS または SCIM を活用し、手動作業を排除する
- 管理者アカウントには物理セキュリティキー（FIDO2/Titan Key）による 2SV を必須化する
1.2 組織部門（OU）の設計と作成
ポリシー適用の基盤となるOU階層設計の原則と実践
OU の概念とポリシー継承メカニズム
OUはツリー状の階層構造で、上位OUのポリシーは下位OUに自動的に継承される。
| 継承の種類 | 動作 | 使用場面 |
|---|---|---|
| 継承（Inherit） | 親OUの設定が子OUに自動適用 | デフォルト状態。変更しない限り自動継承 |
| オーバーライド（Override） | 子OUで異なる設定を保存し上書き | 特定部門だけ例外ポリシーが必要な場合 |
| リセット（Reset to inherit） | カスタム設定を削除して親の設定を再適用 | オーバーライドを元に戻す場合 |
重要な制約：ユーザーは常に1つのOUにのみ属することができる。複数のポリシーセットを適用したい場合は、OUの継承に加えて「アクセスグループ（設定グループ）」を併用する。
OU 設計の戦略的アプローチ 設計の要
ベストプラクティス：OUは「物理的な組織図」ではなく、「適用すべきポリシーの差異」に基づいて設計する。同じポリシーが適用されるユーザーは同じOUにまとめる。
パターン1: 役割ベース
- フルタイム社員（標準ポリシー）
- 契約社員（外部共有制限あり）
- 外部ベンダー（厳格な制限）
- パートタイマー（限定アクセス）
パターン2: ポリシー差異ベース（推奨）
- 制限なし（経営層・一部管理職）
- 標準設定（一般社員）
- 厳格設定（財務・法務・人事）
- 例外アカウント（SA・テスト）
パターン3: デバイスベース
- ユーザー用OU（ユーザーポリシー）
- ChromeOSデバイスOU（デバイスポリシー）
- 会議室専用端末OU（キオスクモード）
- モバイルデバイスOU（MDMポリシー）
OU 作成手順 — ステップバイステップ
1
OU 作成画面を開く管理コンソール →ディレクトリ→組織部門→ 「＋」アイコン
2
名前と説明を入力命名規則を標準化する（例：
/Japan/Tokyo/Engineering）3
親OUを選択どの階層に作成するかを選択
4
ポリシーを設定作成したOUを選択 →アプリ→Google Workspace→ 各サービスの設定を変更・保存
5
ユーザーを移動ユーザー管理画面から対象ユーザーを選択 → 「組織部門の変更」を実行
✦ セクション 1.2 ベストプラクティス総まとめ
- OUはポリシーの差異で設計する。同じポリシーのユーザーは同じOUにまとめて管理コストを削減
- OU 階層は最大5階層以内に収める。深すぎると継承関係が複雑になり管理困難になる
- サービスアカウント・会議室・テストアカウントは専用の例外OUに配置し、ポリシーの独立管理を容易にする
- 新しいポリシーを本番適用する前に、テスト用OUで少数ユーザーに試験的に適用して影響を確認する
- OU の命名規則を文書化して組織全体で標準化する（後からの変更は影響が大きい）
- OU 移動時はユーザーへ事前通知する（ポリシー変更で利用不可になる機能が生じる可能性）
1.3 グループの管理
コミュニケーションとアクセス制御の両面で機能するグループの完全解説
4種類のグループタイプ完全比較 試験頻出
| グループタイプ | 主な用途 | 特徴的な機能 | 必要エディション |
|---|---|---|---|
| 配信リスト （Distribution List） | メール一斉送信 | グループアドレス宛のメールを全メンバーに転送 | 全エディション |
| Collaborative Inbox （共有メールボックス） | チームでのメール対応 （support@, info@） | メールの担当者割り当て・未解決/解決済み管理 | 全エディション |
| セキュリティグループ | IAM・アクセス制御 | Cloud IAMロール付与、設定グループとして使用可能 | 要ラベル設定 |
| 動的グループ （Dynamic Group） | 属性ベースの自動メンバー管理 | クエリ条件でメンバーを自動追加・削除 | Enterprise / CI Premium |
Collaborative Inbox — 詳細解説
通常の配信リスト
- 受信メールを全員に転送するだけ
- 誰が対応中か不明
- 重複対応が発生しやすい
- ステータス管理機能なし
Collaborative Inbox
- メールをキューとして管理
- 担当者に割り当て（Assign）可能
- 「未解決/解決済み」ステータス管理
- チームで協力して対応できる
設定手順
1
グループを作成または選択管理コンソール →ディレクトリ→グループ→ 対象グループ
2
Collaborative Inbox を有効化グループの設定 → 「会話をメンバーに割り当て可能にする」をオン
3
メンバー権限を設定メンバー全員に「割り当て・ステータス変更」権限を付与することを推奨
📎 公式ドキュメント
↗ Collaborative Inbox動的グループ（Dynamic Groups）— 詳細解説
動的グループの本質：メンバーを手動管理する代わりに、ユーザー属性に基づくクエリ条件を定義し、条件に合致するユーザーが自動的にメンバーとして管理される。
利用可能なクエリ条件例
# 動的グループのクエリ条件例
# 部署ベース
user.department =="Engineering"
# OU ベース
user.orgUnitPath =="/Japan/Tokyo"
# 役職ベース
user.title == "Manager"
# カスタム属性ベース
user.customAttributes.employeeType =="FTE"
# 複合条件（AND）
user.department =="Sales"&&user.location.name =="Tokyo HQ"
# 部署ベース
user.department =="Engineering"
# OU ベース
user.orgUnitPath =="/Japan/Tokyo"
# 役職ベース
user.title == "Manager"
# カスタム属性ベース
user.customAttributes.employeeType =="FTE"
# 複合条件（AND）
user.department =="Sales"&&user.location.name =="Tokyo HQ"
必要エディション：動的グループはEnterprise エディション またはCloud Identity Premium が必要。
セキュリティグループとアクセスグループ（設定グループ）
OU 設定の限界を補完する「設定グループ（アクセスグループ）」
ユースケース：開発部門のOU全体でYouTubeがオフに設定されているが、その中の特定2名だけが業務でYouTubeを使う必要がある場合。
解決策：その2名を「YouTube利用許可グループ」に追加し、グループに対してYouTubeを「オン」に設定。グループ設定はOU設定より優先される。
解決策：その2名を「YouTube利用許可グループ」に追加し、グループに対してYouTubeを「オン」に設定。グループ設定はOU設定より優先される。
セキュリティグループは一度設定すると通常グループに戻せない
セキュリティグループのラベル設定は不可逆。有効化前に本当に必要かを確認すること。
セキュリティグループのラベル設定は不可逆。有効化前に本当に必要かを確認すること。
✦ セクション 1.3 ベストプラクティス総まとめ
- グループの命名規則を統一する（例：grp-sales-global@、sec-admin-access@ のようにプレフィックスで用途を明示）
- チームでのメール対応には Collaborative Inbox を活用し、対応の重複と見落としを防ぐ
- 大規模なグループ（全社員グループなど）への外部からのメール送信を制限し、スパム・誤送信リスクを軽減する
- 動的グループを活用してメンバー管理を自動化し、人事異動時の設定漏れを根本から防ぐ
- 各グループに必ずオーナーを設定し、定期的なメンバーレビューを実施してもらう体制を作る
- セキュリティグループは一度設定すると戻せないため、有効化前に十分に検討する
1.4 ドメインの管理
プライマリ・セカンダリ・エイリアス — 3種類のドメインを正確に理解する
3種類のドメイン完全比較 試験最頻出
| ドメイン種別 | 定義と役割 | ライセンスコスト | 独立した受信箱 | 主な用途 |
|---|---|---|---|---|
| プライマリドメイン | 契約時に登録したメインドメイン。全設定の基準。 | 基本コスト | ✅ あり | 組織の標準ID |
| セカンダリドメイン | 別ブランド・子会社用に追加する独立したドメイン | ユーザーごとに追加発生 | ✅ あり（独立） | 別ブランド・別地域展開 |
| ドメインエイリアス | 既存ドメインの別名（.com と .co.jp など） | 無料 | ❌ 既存ユーザーと共有 | 同一ユーザーの複数アドレス受信 |
試験でよく出る問題パターン：
「example.com に加えて example.co.jp も使いたい。既存ユーザーが両方のアドレスでメールを受信できるようにしたい。追加のライセンスコストは発生させたくない。」
→ドメインエイリアスとして example.co.jp を追加。既存ユーザーに自動的に @example.co.jp アドレスが付与され、追加ライセンス不要。
「example.com に加えて example.co.jp も使いたい。既存ユーザーが両方のアドレスでメールを受信できるようにしたい。追加のライセンスコストは発生させたくない。」
→ドメインエイリアスとして example.co.jp を追加。既存ユーザーに自動的に @example.co.jp アドレスが付与され、追加ライセンス不要。
ドメイン追加手順 — DNS 設定を含む完全ステップ
1
管理コンソールでドメインを追加管理コンソール →アカウント→ドメイン→ドメインの管理→ 「ドメインを追加」
2
ドメイン名を入力して続行「続行してドメインの所有権を証明」をクリック
3
DNS に TXT レコードを追加（推奨）Google が提示する TXT レコードを、ドメインレジストラの DNS 設定に追加する
4
DNS 伝播を待機変更が全世界に伝播するまで数分∼最大48時間かかる場合がある
5
管理コンソールで確認をクリックGoogleがレコードを検出したことを確認する
6
MX レコードを設定メール配送先をGoogleのサーバーに向けるMXレコードを登録する（メールを使う場合）
7
SPF/DKIM/DMARC を設定メールのなりすまし防止のための認証レコードを追加する
DNS レコード確認コマンド
# TXT レコードの確認（Linux / Mac）
nslookup -type=TXT example.com
dig TXT example.com
# Windows PowerShell
Resolve-DnsName -Name example.com -Type TXT
# MX レコードの確認
dig MX example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
dig TXT example.com
# Windows PowerShell
Resolve-DnsName -Name example.com -Type TXT
# MX レコードの確認
dig MX example.com
nslookup -type=MX example.com
確認後に TXT レコードを削除しない
ドメイン確認後にDNSのTXTレコードを削除すると、確認が取り消される場合がある。レコードは残したままにすること。
ドメイン確認後にDNSのTXTレコードを削除すると、確認が取り消される場合がある。レコードは残したままにすること。
✦ セクション 1.4 ベストプラクティス総まとめ
- ドメイン確認には CNAME より影響範囲が小さいTXT レコードを使用する
- 既存ユーザーが別アドレスでも受信したいだけなら「ドメインエイリアス」を選択し、追加ライセンスコストを回避する
- プライマリドメインの変更は全ユーザーのメインアドレスに影響するため、計画的なメンテナンスとして慎重に実施する
- 不要になったドメインはAdminコンソールから削除してセキュリティリスクを最小化する
- ドメイン追加前にMXレコードを確認し、メール配信への影響を把握する
- SPF・DKIM・DMARCを必ず設定し、メールのなりすまし・フィッシング対策を徹底する
1.5 建物とリソースの管理
会議室・備品のカレンダー予約システム構築 — 物理リソースのデジタル管理
リソース管理の階層構造
| リソース種類 | 例 | 管理のポイント |
|---|---|---|
| 会議室 | 会議室A-10F（定員12名） | 定員・フロア・設備を正確に登録 |
| 共有デスク | フリーアドレス席-3F | 予約時間の上限設定が重要 |
| 備品 | プロジェクター01, 社用車A | 貸出・返却管理として活用 |
| 専用端末 | Meet Hardware-会議室B | フィーチャーに「ビデオ会議システム」を追加 |
一括作成 — CSV インポート手順 大規模環境必須
1
テンプレートをダウンロード管理コンソール →ディレクトリ→建物とリソース→リソース→ 「ダウンロード」でCSVテンプレートを取得
2
CSV を編集Google スプレッドシートや Excel で開き、必須列（Resource ID, Resource Name, Building ID, Capacity）を記入。フィーチャーは
#フィーチャー名 の列を追加。3
CSV をアップロード管理コンソールに戻り、編集済みCSVをアップロードして整合性チェックを実行
CSV フォーマット例
# リソース一括登録CSVの例
Resource ID,Building ID,Floor Name,Resource Name,Capacity,#ビデオ会議,#ホワイトボード
room-1f-101,tokyo-hq,1F,会議室101（定員10名）,10,YES,YES
room-2f-201,tokyo-hq,2F,会議室201（定員6名）,6,NO,YES
training-3f,tokyo-hq,3F,トレーニングルーム（定員30名）,30,YES,YES
Resource ID,Building ID,Floor Name,Resource Name,Capacity,#ビデオ会議,#ホワイトボード
room-1f-101,tokyo-hq,1F,会議室101（定員10名）,10,YES,YES
room-2f-201,tokyo-hq,2F,会議室201（定員6名）,6,NO,YES
training-3f,tokyo-hq,3F,トレーニングルーム（定員30名）,30,YES,YES
リソース予約権限の設定
| 権限レベル | 説明 | 推奨ユースケース |
|---|---|---|
| 無制限の予約 | 誰でも（外部除く）自由に予約可能 | 一般的な会議室 |
| 自動承認 | 予約申請が自動で承認される（空き確認のみ） | 共有デスク・一般備品 |
| 手動承認 | オーナーが予約申請を手動で承認/却下 | 役員会議室・高価な備品 |
| オーナーのみ | リソースカレンダーのオーナーだけが予約可能 | 特権的なリソース |
詳細予約オプション
| 設定項目 | 内容 | 推奨値 |
|---|---|---|
| 事前予約できる最大日数 | 何日前から予約できるか制限 | 60〜90日 |
| 最低使用時間 | 最短予約時間 | 30分 |
| 最大使用時間 | 1回の予約の最長時間 | 4〜8時間 |
| 定期的な予約 | 定期会議での予約を許可するか | 許可（期間上限を設定） |
✦ セクション 1.5 ベストプラクティス総まとめ
- リソース名は検索しやすいフォーマットで統一する（例：
会議室A-10F（定員12名）） - フィーチャーを標準化して全リソースに統一されたタグを付けることで、カレンダーの絞り込み検索を最大化する
- 予約できる最大日数を設定し、遠い将来の「場所取り」による占有を防ぐ
- 50以上のリソースを作成する場合は必ずCSV一括インポートを活用する（手動は非現実的）
- 建物の住所情報・緯度経度を正確に設定し、カレンダーのインテリジェントな提案機能（近い空き部屋の自動提案）を最大限活用する
- 役員会議室など特殊なリソースには「手動承認」権限を設定し、不適切な使用を防ぐ
試験対策まとめ — 頻出パターンと最重要ポイント
試験本番で確実に得点するための重要事項の総整理
🎯 試験頻出パターン 5選
パターン① — 移行ツールの選定
「Microsoft Exchange（オンプレミス、社員500名）からメール・カレンダー・連絡先を移行したい。最適なツールは？」
正解大規模・複雑な要件 →Google Workspace Migrate/ 標準的な移行 →GWMME/ シンプル →データ移行サービス
注意GCDSはメール移行ではなくユーザー/グループ情報の同期ツール！
注意GCDSはメール移行ではなくユーザー/グループ情報の同期ツール！
パターン② — アカウント状態の選択
「退職者のアカウントを、法的要件で2年間データ保持が必要。コスト最小化したい。」
正解即時停止 → Drive所有権移転 →Archived Userライセンスに変更 + Vaultで保持ルール設定
誤答削除する → 20日後にデータが消滅 / 通常ライセンスのまま停止 → コストが高い
誤答削除する → 20日後にデータが消滅 / 通常ライセンスのまま停止 → コストが高い
パターン③ — OU 設計
「財務部門はDriveの外部共有を禁止、他は許可したい。最適なOU設計は？」
正解ルート組織: 外部共有【許可】(デフォルト) → 財務部OU: 外部共有【禁止】(上書き)
パターン④ — グループタイプの選択
「support@example.com宛のメールをチームで管理。担当者割り当てと解決済み管理が必要。」
正解Collaborative Inbox→ メールの割り当て・ステータス管理ができる
誤答配信リスト → 全員に転送するだけで割り当て機能なし
誤答配信リスト → 全員に転送するだけで割り当て機能なし
パターン⑤ — ドメイン種別の選択
「example.com に加えて example.co.jp も使いたい。既存ユーザーが両方で受信できるようにしたい。追加ライセンスコストは不要にしたい。」
正解ドメインエイリアスとして example.co.jp を追加 → 追加ライセンス不要、既存ユーザーに自動付与
誤答セカンダリドメイン → 独立したユーザーが必要でライセンスコストが発生
誤答セカンダリドメイン → 独立したユーザーが必要でライセンスコストが発生
📋 最終確認チェックリスト
1.1 ユーザーライフサイクル
✓
GCDSの役割と同期方向（AD/LDAP→Google）
✓
GWMMEとデータ移行サービスの使い分け
✓
停止・削除・アーカイブの違いを説明できる
✓
削除後の復元可能期間は20日
✓
Drive所有権移転の制限（共有ドライブは対象外）
✓
SAML SSOの SP-Initiated / IdP-Initiated の違い
✓
アーカイブライセンスでコスト削減しつつデータ保持
1.2 組織部門（OU）
✓
ポリシーは上位OUから下位OUへ自動継承される
✓
OUは「物理的な組織図」ではなくポリシーの差異で設計する
✓
OU階層は最大5階層以内を推奨（深すぎると管理困難）
✓
ユーザーは常に1つのOUにのみ属せる（複数不可）
1.3 グループ管理
✓
4タイプの使い分け（配信リスト / Collaborative Inbox / セキュリティ / 動的）
✓
Collaborative Inbox = 担当者割り当て + 未解決/解決済みステータス管理
✓
動的グループは Enterprise エディションまたは Cloud Identity Premium が必要
✓
セキュリティグループは一度設定すると通常グループに戻せない（不可逆）
✓
設定グループ（アクセスグループ）の設定はOU設定より優先される
1.4 ドメイン管理
✓
ドメインエイリアス = 無料・既存ユーザーに自動付与（受信箱は共有）
✓
セカンダリドメイン = 独立ユーザー作成可・ライセンス追加必要
✓
ドメイン確認はTXT レコードの追加が推奨（CNAME より影響が小さい）
1.5 建物・リソース
✓
建物 → フロア → リソース → フィーチャーの4階層構造
✓
50件以上のリソース作成はCSV 一括インポートを活用
✓
予約権限は4レベル（無制限・自動承認・手動承認・オーナーのみ）
✓
フィーチャーを標準化してカレンダーの絞り込み検索を最適化