Google Workspace 管理者コンソール 初期設定チェックリスト

開始前の準備と導入前チェックリスト（Google Workspace 管理者コンソール 初期設定）

導入前に必要な情報と担当分担を決めます。管理者アカウント作成やブレークグラス運用の準備も必須です。ここでは、初回ログイン後に行う具体手順と事前に揃えるべき資料を示します。

管理者アカウント作成とブレークグラス運用

管理者アカウントは専用にし、日常用とブレークグラスを分けます。ブレークグラスは緊急時のみ使用する運用ルールを文書化してください。

• 管理コンソール（admin.google.com）へアクセスし、ディレクトリ > ユーザー > ユーザーを追加 で管理者用アカウントを作成します。
• 作成時の必須項目：primaryEmail、firstName、lastName、初期パスワード。次回ログイン時のパスワード変更を有効にします。
• 管理者アカウントに対しては必ず回復情報（別メール・電話番号）を登録させます。個人の Google アカウント設定（myaccount.google.com）から行えます。
• 2段階認証（2SV）とセキュリティキー（FIDO2/YubiKey 等）を管理者に登録します。セキュリティキーは組織的に管理し、少なくとも2つのブレークグラスアカウントへ割当てます。
• ブレークグラスの運用手順書は以下を含めます：アカウント名、担当者、保管場所、利用条件、事後監査手順。

導入前に揃える情報とスケジュール決定

導入前に必要な情報と関係者を確定させます。DNS担当や移行担当と実施スケジュールを共有してください。

• 管理対象ドメイン名とDNSログイン情報（権限/TTL変更権限）。
• 既存メール環境の構成情報（Exchange/IMAPホスト、ポート、認証方式）。
• 移行対象ユーザー・グループ一覧（CSVで取得）。
• SSO/IdP のメタデータ（SAML/OIDC）、テストユーザー情報。
• ライセンス数・希望エディション（Vault/DLP等はエディション依存）。
• DNS担当者の連絡窓口と本番切替の可用時間帯（メンテナンスウィンドウ）。
• 推奨：本番切替の48時間前にMX用TTLを短縮（例：300秒）にしておきます。

ドメイン確認とメール認証（MX／SPF／DKIM／DMARC）の設定（Google Workspace 管理者コンソール 初期設定）

ドメイン確認とメール認証は配信信頼性となりすまし対策に直結します。各設定は段階的に導入し、必ず検証とロールバック手順を用意してください。

ドメイン所有権確認（DNS TXT方式の手順）

DNS TXT による検証が最も一般的です。DNSにトークンを追加してから管理コンソールで検証します。

1. 管理コンソールでドメイン追加を行い、検証トークンを取得します。
2. DNSプロバイダの管理画面で、ホストを「@」または空欄にし、TXT 値にトークンを貼り付けます。TTLは一時的に短め（3600秒以下）を推奨します。
3. 反映確認は CLI の dig で行います。例:

1. 管理コンソールで「確認」ボタンを押して完了します。詳しくは公式手順をご参照ください。
   公式: https://support.google.com/a/answer/60216?hl=ja

MX レコード追加と切替の具体手順

MX 切替は段階的に行い、並行運用で確認してから旧MXを削除します。事前にTTL短縮を行っておくとロールバックが早くなります。

• 事前作業：本番切替48時間前に既存MXのTTLを300秒に変更します。

• Google の一般的な受信MX（ホスト名は小文字で指定します）:

• 1 ASPMX.L.GOOGLE.COM.

• 5 ALT1.ASPMX.L.GOOGLE.COM.
• 5 ALT2.ASPMX.L.GOOGLE.COM.
• 10 ALT3.ASPMX.L.GOOGLE.COM.

• 10 ALT4.ASPMX.L.GOOGLE.COM.

• DNS に新MXを追加して数分〜数時間待ちます。確認コマンド例:

• 検証が取れたら旧MXを削除します。ロールバックは旧MXを再追加してTTL待ちです。切替に伴う受信遅延はTTLに依存します。

公式: https://support.google.com/a/answer/174125?hl=ja

SPF（TXT）設定と運用上の注意

SPF は送信元偽装対策の基本です。必ず1つの TXT レコードに統合してください。

• 推奨の初期レコード例（Google のみ送信）:

• 外部サービスを追加する場合は include/ip4 を使います。例:

• 注意点:
• SPF レコードは一つだけにすること。複数あると無効になります。
• DNS ルックアップ（include、a、mx、ptr、exists）数は最大10回までです。多い場合はフラット化や第三者のSPF中継を検討します。
• 初期は ~all（ソフトフェイル）で様子を見てから -all に移行してください。
• 検証はメールヘッダの Received-SPF や Authentication-Results を確認します。

DKIM の有効化と鍵ローテーション（具体例と手順）

DKIM は公開鍵を DNS に置き、送信メールに署名を付与します。鍵は 2048 ビットを推奨します。

• 管理コンソールで鍵を生成する手順（例）:
• 管理コンソール > アプリ > Google Workspace > Gmail > メールの認証 で新しい DKIM 鍵を作成します。

• セレクタ例: s2026 または google。セレクタ名は英数字とハイフン推奨。

• DNS に追加する TXT レコード名と値の例（セレクタが s2026、ドメイン example.com の場合）:

• 注意点:
• DNS コンソールにより長い TXT は分割して登録する必要があります。各分割部分は自動で結合されますが、登録画面の注意を確認してください。

• 署名確認は受信メールのヘッダ「DKIM-Signature」や Gmail の「メールの詳細を表示」で確認します。

• 鍵ローテーション手順（実務フロー）:

• 管理コンソールで新しいセレクタを生成し、DNS に公開鍵を追加します。
• DNS が反映されたことを dig で確認します。dig TXT snewsel._domainkey.example.com +short
• 新セレクタで署名が開始されることを確認します（数時間〜数日監視）。
• 問題なければ旧セレクタのDNSレコードを削除し、管理コンソールの旧キーを無効化します。
• 鍵漏洩が疑われる場合は直ちに旧鍵を削除し、影響範囲を調査してください。

公式: https://support.google.com/a/answer/174124?hl=ja

DMARC ポリシーとレポート運用の注意点

DMARC はポリシー指示とレポート受信の両方を提供します。段階的に強化します。

• 最初は監視モードから開始する例:

• 移行例: p=none → p=quarantine → p=reject に段階的に変更します。
• RUA は集計レポート（XML）、RUF はフォレンジック（詳細）です。RUF にはメッセージ断片やヘッダが含まれる可能性があり、プライバシーや法規制の観点から受信先の取り扱いに注意してください。
• レポート解析は専用サービスや集計ツールの利用を推奨します。

公式: DMARC の一般説明や解析ツールの利用を参照してください。

DNS／メールの検証コマンド例と期待出力

各種検証の代表コマンドと期待例を示します。

メールヘッダの確認は Gmail の「メールの詳細を表示（Show original）」で Authentication-Results を確認します。そこに dkim=pass, spf=pass, dmarc=pass 等が表示されます。

ユーザー・OU・グループ設計とCSV/Directory Sync（Google Workspace 管理者コンソール 初期設定）

OU 設計とユーザー登録は日常運用に直結します。設計方針を先に決め、CSV や Directory Sync で段階的に導入してください。ここでは実務的なテンプレとインポート手順、注意点を示します。

OU 設計の基本方針

OU は「設定適用単位」として設計します。階層を深くしすぎると管理が煩雑になります。

• 基本は「地域／部門／役割」の順で浅い階層を推奨します。例: /JP/Sales、/JP/IT/Admin
• OU はポリシー（2SV適用、端末制限等）適用の単位です。設定粒度と合致するよう設計してください。
• 命名は英数字で統一し、特殊文字は避けます。

個別ユーザー作成の手順

個別作成は管理コンソールから行います。初期パスワードとパスワード変更要求を設定します。

• 管理コンソール > ディレクトリ > ユーザー > ユーザーを追加。
• 必須項目を入力し、適切な OU を割当てます。
• 管理者権限は必要最小限を付与します。

CSV 一括登録テンプレートとインポート手順

CSV で大量ユーザーを登録する場合のテンプレートと注意点を示します。必須フィールドの指定と文字コードに注意してください。

• 推奨のファイル形式と保存方法: UTF-8（BOMなし）、LF 改行。Windows の Excel を使う場合は「CSV UTF-8（コンマ区切り）」で保存します。
• ヘッダ例とサンプル行:

• 注意点:
• primaryEmail は実際のメールアドレスに置換してください。中括弧やテンプレート記号は使わないでください。
• orgUnitPath はルートからのパス（例: /JP/Sales）で指定します。
• CSV の文字列内にカンマを含む場合はダブルクォートで囲みます。

• インポート後はエラーCSVがダウンロードできます。失敗行はその内容に従って修正してください。

• インポート手順（概略）:

• 管理コンソール > ディレクトリ > ユーザー > その他の操作 > CSV を使って複数ユーザーを追加。
• ファイルをアップロードし、プレビューでマッピングを確認。
• 実行後、成功と失敗のサマリを確認し、エラー行を修正します。

Directory Sync（GCDS）設定とパイロット同期

Google Cloud Directory Sync は AD/LDAP と同期する一方向ツールです。同期設定は慎重に行ってください。

• 事前に属性マッピングとフィルター条件を定義し、限定 OU でパイロットを実施します。
• 初期は少数ユーザーで dry-run（テスト同期）を実行し、ログで差分を確認します。
• 同期は基本的に AD→Google の一方向であることを忘れないでください。誤設定は大量削除を招くため、設定変更前にバックアップとスナップショットを取得してください。
• ロールバックは同期設定を無効化し、必要であれば手動でユーザーを復旧します。

グループと管理者ロールの委譲

グループは用途に応じて命名規則を決め、外部投稿制御を設定します。管理者ロールは最小権限で委譲します。

• グループ命名例: team-営業, project-alpha。用途（メーリングリスト／共有受信箱）により設定を分けます。
• 管理ロールは最初に標準ロールを活用し、必要に応じてカスタムロールを作成します。例: ヘルプデスク用は「ユーザー管理」「パスワードリセット」のみ付与。
• 定期的にロール付与状況をレビューし、不必要な権限は剥奪します。

セキュリティ基本設定と端末管理（2SV、セキュリティキー、API 鍵運用）（Google Workspace 管理者コンソール 初期設定）

初期段階で有効化すべきセキュリティ設定と端末管理方針を示します。特に管理者と高リスクユーザーの保護を優先してください。

2段階認証（2SV）とセキュリティキーの展開

2SV は段階的に全ユーザーへ展開します。管理者は先行して必須化してください。

• 運用手順:
• 管理者アカウント群へ 2SV とセキュリティキーを必須化。
• テストグループで動作確認後、全社へ段階的に展開します。
• バックアップ手段（代替電話、バックアップコード）をユーザーに周知します。
• セキュリティキーは物理保管ポリシーを定め、発行・回収ログを残します。
• 高リスク管理者向けに Advanced Protection Program の導入を検討してください。公式情報を参照の上、適用対象と運用手順を決めます。
  公式（Advanced Protection の説明）: https://support.google.com/accounts/answer/7280203?hl=ja

端末管理の実務（登録・ポリシー・ワイプ）

端末管理は登録 → ポリシー適用 → モニタリングの順で実施します。BYOD と会社支給端末で扱いを分けます。

• 登録方法：管理コンソールの端末管理から登録を促します。
• ポリシー例：OS 最小バージョン、画面ロック、暗号化、不要アプリ制限。
• ワイプの区別：選択的ワイプ（企業データのみ削除）と全消去（端末初期化）を明確にし、実行手順と承認フローを文書化します。
• 実行前必須事項：紛失届・承認者・影響範囲の確認。ワイプ実行後の復旧手順も用意します。

API・サービスアカウント鍵の保管とローテーション

API 鍵とサービスアカウント鍵は厳格に管理し、長期鍵の使用を避けます。Workload Identity 等の代替を検討してください。

• サービスアカウント鍵の作成（gcloud 例）:

• 鍵の削除:

• 運用ポリシー例:
• 鍵は Secret Manager や専用のシークレットストアで保管する。メールや共有ドライブでの保管は不可。
• ローテーション頻度はリスクに応じて決定（例：90日〜1年）。ローテーション手順は必ず手順化し、更新後にアプリの動作確認を行ってから旧鍵を削除する。
• 可能なら Workload Identity Federation や短期トークンに置き換える。
• 監査: 鍵発行・削除の操作はログに残し、定期レビューを行います。

エディション依存の主な機能と確認

Vault、DLP、監査ログの長期保持やAdvanced Protection といった機能はエディション・ライセンスに依存します。契約前に必ず公式の機能比較を確認してください。

• 確認：公式のプラン比較ページや管理コンソールの購買情報で対象プランを事前に確認してください。公式: https://workspace.google.com/intl/ja/pricing.html

移行・テスト・運用開始とその後の定期チェック（Google Workspace 管理者コンソール 初期設定）

移行は計画と段階的検証が成功の鍵です。リハーサルと増分移行でリスクを下げます。ここでは実務的な移行手順、テスト項目、運用開始後のチェックをまとめます。

移行計画と段階的ロールアウトの実務チェックリスト

移行はインベントリ、設計、パイロット、本番カットオーバーの順で行います。各段階で成功条件を定義してください。

• インベントリ作成：メール、カレンダー、共有ドライブ、権限を一覧化します。
• マッピング設計：所有権、共有設定、グループのマッピングを定義します。
• パイロット移行：代表的な業務ユーザー群で実施し、送受信、カレンダー、ファイルアクセスを確認します。
• カットオーバー：差分移行と並行運用で本番化。所有権と共有権限を最終確認します。
• 移行ツール例：Admin コンソールの Data Migration、GWMME（Exchange 用）、サードパーティツールを要比較検討します。

テスト手順と検証チェックリスト

移行後は各機能の正常性を検証します。チェック項目を明確にして担当を割当てます。

• メール送受信（外部含む）とヘッダの SPF/DKIM/DMARC 判定。
• カレンダー招待の送受信と更新反映。
• 共有ドライブの権限とファイルアクセス。
• グループ受信箱の配信と閲覧権限。
• SSO ログインの成功、フェールオーバー動作。
• モバイル同期（Exchange ActiveSync 等を使用する場合）の動作確認。

具体的な検証例：Gmail で送信したメールの「元のメッセージを表示」で Authentication-Results を確認し、dkim=pass、spf=pass、dmarc=pass を期待する。

運用開始後の定期チェック項目と監査ログ

運用開始後も定期的なレビューを行ってください。監査ログのエクスポートとアラート設定を整備します。

• 四半期ごとのユーザー権限レビューとロール見直し。
• ライセンス最適化レビュー。
• DKIM 鍵ローテーション（年1回目安）と DMARC レポートの定期確認（週次〜月次）。
• 監査ログの BigQuery エクスポートや SIEM 連携を設定し、重要イベントでのアラートを構築します。
• 定期的な復旧テスト（バックアップからの復元リハーサル）を実施します。

よくある初期設定エラーと切り分けフロー（集約）

代表的な初期設定の障害と基本的な切り分け手順を集約します。まずは「DNS/ネットワーク」「管理コンソール設定」「IdP設定」のいずれかを切り分けてから詳細対応します。

• DNS反映遅延：TTL を確認し、dig/nslookup で実値を確認します。
• MX 未設定/誤設定：dig MX example.com +short でホスト名と優先度を確認します。
• SPF 複数定義：DNS に TXT が複数存在する場合は 1 つに統合します。
• DKIM セレクタ不一致：DNS のセレクタ名と管理コンソールのセレクタが一致しているか照合します。
• SSO ログイン失敗：IdP の ACS URL、Entity ID、証明書、有効期限、時刻同期を確認します。
• ロールバック基本方針：DNS 系（MX/SPF/DKIM）は旧設定を再投入し TTL 待ち。SSO は事前作成したブレークグラスアカウントでアクセス復旧。

まとめ（Google Workspace 管理者コンソール 初期設定 手順）

導入前準備、ドメイン認証、ユーザー登録、セキュリティ、移行・運用の一連手順を実務寄りに整理しました。重要操作は必ず検証とロールバック手順を用意し、エディション差は公式で確認してください。

• 管理者アカウントは専用化し、ブレークグラスとセキュリティキーを準備する。
• ドメイン確認はDNS TXTで行い、MX/SPF/DKIM/DMARCは段階的に導入する。
• CSV は UTF-8（BOMなし）で保存し、インポート前に必須フィールドを確認する。
• DKIM はセレクタとDNS公開鍵の整合を確認してから有効化し、鍵ローテーション手順を定義する。
• API 鍵は安全に保管し、ローテーションと最小権限で運用する。
• 移行はパイロット→段階的ロールアウト→監査ログの整備の順で行う。

公式ドキュメントを必ず参照し、管理コンソールの UI 変更やエディション差に注意して作業してください。主要公式リンク（参考）: 管理コンソール ヘルプ https://support.google.com/a?hl=ja 、Admin SDK https://developers.google.com/admin-sdk 。