Google Workspace で独自ドメインを一元管理する方法と移行ポイント

グループ企業では、本社や関連会社がそれぞれ異なる独自ドメインやメール環境を利用していることがあります。各社が個別に管理してきた結果、アカウント管理やセキュリティ設定が統一されず、本社のIT部門がグループ全体の状況を把握しにくくなっているケースもあります。

こうした環境を整理する方法の一つが、Google Workspace を活用したメール・アカウント管理の一元化です。Google Workspace では、独自ドメインを使用したGmailを利用できるほか、複数のドメインを一つの環境で管理することもできます。

本記事では、Google Workspace で独自ドメインを一元管理するメリットから、複数ドメインの管理、DNS・MXレコードの設定、安全に移行を進めるためのポイントまで解説します。

1.Google Workspaceで独自ドメインを一元管理するメリット

独自ドメインメールの管理が分散することで起こる課題

本社と関連会社が異なるメール環境を個別に管理していると、メールアカウントの作成・削除やセキュリティ設定も各社任せとなり、本社側で全体像を把握しにくくなります。

特に退職者や異動者のアカウント管理には注意が必要です。会社ごとに対応方法が異なると、不要なアカウントが残ったり、必要以上の権限が付与された状態が続いたりする可能性があります。

また、管理方法が担当者個人の知識に依存している場合、担当者の異動や退職によって設定内容や対応手順が分からなくなることもあります。

グループ全体のメール環境を見直す際には、単にメールサービスを変更するだけではなく、ドメイン、ユーザー、権限、運用ルールまで含めて整理することが重要です。

Google Workspace でメール基盤を統合するメリット

Google Workspace では、企業が保有する独自ドメインを利用してGmail を運用できます。複数のドメインを一つの環境へ追加し、Google 管理コンソールからユーザーを管理することも可能です。

各社に分散していた管理を一元化することで、次のようなメリットが期待できます。

項目	各社で分散管理	Google Workspace で一元管理
アカウント管理	各社ごとに運用方法が異なる	共通ルールを整備しやすい
セキュリティ設定	会社ごとにばらつきが出やすい	グループ全体で方針を統一しやすい
退職・異動対応	対応漏れを把握しにくい	管理状況を確認しやすい
障害時の対応	各社で個別対応が必要	標準的な対応手順を整備しやすい
管理ノウハウ	担当者に属人化しやすい	手順や権限を標準化しやすい

さらに、Google Workspace ではGmail だけでなく、Google ドライブや Google Meet、Google カレンダーなども利用できます。メール基盤の統合をきっかけに、グループ全体の情報共有方法まで見直すこともできます。

管理負荷を抑えるためのアカウント・権限設計

一元管理といっても、すべての管理業務を本社IT部門が担当する必要はありません。

グループの規模が大きくなるほどユーザー追加や削除、問い合わせ対応などを本社だけで行うと負担が集中します。そのため、本社が管理する範囲と各社へ委任する範囲を明確にしておくことが重要です。

たとえば、グループ共通のセキュリティ方針や重要な管理者権限は本社で管理し、日常的なユーザー対応は各社の管理担当者へ任せる方法があります。

また、システム上の権限設定だけでなく、「誰が申請するか」「誰が承認するか」「誰が作業するか」といった運用フローも決めておきましょう。

2.複数の独自ドメイン名を Google Workspace で管理する方法

利用中のドメイン名を整理する際のポイント

複数の会社を Google Workspace へ統合する場合、まず現在利用しているドメインとメール環境を棚卸しします。主な確認項目は次のとおりです。

確認項目	確認内容
ドメイン名	現在利用している独自ドメイン
利用会社・部門	どの会社・部門が使用しているか
ユーザー数	利用中のメールアカウント数
メール環境	現在利用しているメールサービス・サーバ
DNS管理先	レジストラ、DNSサービス、外部ベンダーなど
DNS変更担当者	実際に設定変更できる担当者
関連システム	複合機、業務システム、通知システムなど

特に注意したいのが、「DNSの管理者」と「メールシステムの管理者」が異なるケースです。

DNSを外部ベンダーへ委託している場合、Google Workspace の担当者だけでは設定を変更できません。設定変更の申請方法や承認者、作業までに必要な日数なども事前に確認しておきましょう。

セカンダリドメインを活用した複数ドメイン追加の考え方

Google Workspace では、プライマリドメインに加えて、セカンダリドメインやユーザーエイリアスドメインを追加できます。複数の独自ドメインを管理する場合は、それぞれの用途に応じて使い分けることが重要です。

項目	セカンダリドメイン	ユーザーエイリアスドメイン
主な用途	別ドメインのユーザーを追加する	既存ユーザーに別ドメインのアドレスを追加する
アカウント	新しいユーザーを作成できる	新しいユーザーは作成しない
適したケース	本社・関連会社などで利用者を分ける	同じ利用者が複数ドメインのアドレスを使う

たとえば、本社と関連会社で異なるユーザーがそれぞれのドメインを利用する場合は、セカンダリドメインが選択肢となります。一方、既存ユーザーに別ドメインのメールアドレスを持たせたい場合は、ユーザーエイリアスドメインを利用できます。

ただし、Google Workspace の設定をすべてドメイン単位で分離できるわけではありません。誰がどのドメインを使用するのかを整理し、組織部門による管理や将来的な組織変更も考慮して設計しましょう。

ユーザー・メールアドレス・ドメイン名の管理ルール

複数の独自ドメインを一元管理する場合には、ユーザー名やメールアドレスのルールも整理しておく必要があります。

たとえば、同姓同名のユーザーが存在する場合の命名方法や、グループ会社間の 転籍時に使用するドメインやメールアドレスをどのように扱うかなどを決めます。

退職者についても、いつアカウントを停止するのか、必要なデータを誰へ引き継ぐのかを決めておきます。

各社で使用してきたルールをすべてそのまま Google Workspace へ持ち込むと、移行後も複雑な管理が残ります。Google Workspace への移行を機に、グループ共通にできる部分と各社固有で残す部分を整理することが、長期的な管理負荷の低減につながります。

3. Google Workspace 導入時に必要なDNS設定と管理方法

 

現在のDNS設定を事前に確認する方法

Google Workspace で独自ドメインのメールを利用する場合、DNS設定の変更が必要です。

まず、利用しているドメインのDNS管理サービスと管理担当者を特定し、管理画面へのログイン方法や設定変更に必要な権限があるかを確認します。DNSを外部ベンダーが管理している場合は、設定変更の依頼方法や担当者も確認しておきましょう。

次に、DNS管理画面で現在登録されているレコードと設定値を確認します。確認した内容は、変更前の状態へ戻せるよう一覧表や画面キャプチャなどで記録しておくと安心です。特にMXレコードのほか、SPFなどに使用されるTXTレコードやCNAMEレコードも記録しておくと、変更前後を比較しやすくなります。

移行当日に管理先や権限の問題で作業が止まらないよう、事前にDNS設定を変更できる状態まで確認しておくことが重要です。

DNS管理者と Google Workspace 管理者の役割分担

DNS管理者と Google Workspace 管理者が異なる場合には、作業範囲を明確にします。

作業	Google Workspace 管理者	DNS管理者
必要なDNSレコードの確認	〇	△
変更内容・日時の策定	〇	〇
DNSレコードの変更	△	〇
Google Workspace 側の確認	〇	△
メール送受信テスト	〇	△
問題発生時の切り戻し判断	〇	〇

※実際の役割分担は、自社の管理体制や外部ベンダーとの契約内容に応じて調整します。

「設定作業」「確認作業」「問題発生時の判断」を分けて整理しておくと、担当者間の認識のずれを防ぎやすくなります。

DNS設定変更を安全に進めるための事前準備

DNS設定変更を安全に進めるためには、変更前後の状態を比較できるようにしておきます。

事前に整理しておきたい項目は次のとおりです。

• 変更対象となるDNSレコード
• 変更前・変更後の設定値
• 作業担当者と確認担当者
• 作業予定日時
• 変更後の確認方法
• 問題発生時の連絡先
• 元の設定へ戻す手順

DNSの変更内容は環境によって反映までに時間がかかる場合があります。そのため、切り替え直後だけで作業を完了とせず、一定時間が経過した後にも状態を確認しましょう。

また、DNS設定を変更する際は、事前に対象レコードのTTLを短くしておくことで、古い設定がキャッシュに残る時間を短縮できます。TTLを変更した後は、変更前のTTL分の時間を空けてからDNSレコードを切り替えましょう。切り替え後の動作に問題がないことを確認したら、元の値へ戻します。

4.MXレコード変更によるメール移行を安全に進める方法

MXレコード切り替え前に確認すべき既存メール環境

MXレコードは、そのドメイン宛てのメールをどのメールサーバへ配送するかを指定するDNSレコードです。Google Workspace へ移行する際には、メールがGoogle 側へ配送されるよう設定を変更します。

ただし、切り替え前には現在のメール環境を十分に確認する必要があります。ユーザーのメールアドレスだけでなく、メーリングリスト、転送設定、代表アドレス、過去メールの移行方法なども確認しましょう。

特に見落としやすいのが、複合機や監視システム、業務アプリケーションなどから送信されるメールです。

これらを把握せずに移行すると、移行後にシステム通知が届かないといった問題が発生する可能性があります。

Google Workspace 用のMXレコードへ変更する手順

MXレコードを変更する前に、Google Workspace 側で対象ドメインの確認やユーザーアカウントの準備を済ませておきます。準備が整ったら、次の流れでMXレコードを切り替えます。

項番	手順	主に作業するサービス・場所	作業内容
1	現在のMXレコードを記録する	DNS管理サービス	現在登録されているMXレコードを確認・記録
2	Google Workspace 用のMXレコードへ変更する	DNS管理サービス	既存のMXレコードを Google 指定のMXレコードへ変更
3	Gmailを有効化する	Google 管理コンソール	対象ドメインの「Gmailを有効にする」を実行
4	社内外とのメール送受信を確認する	Gmail＋外部メール環境	社内・社外のアドレスとの送受信をテスト
5	関連システムの動作を確認する	各業務システム	複合機、監視システム、業務アプリなどのメール送信を確認

MXレコードの具体的な設定値や手順については、作業時点でGoogle公式の最新情報を確認してください。利用しているDNSサービスによって設定画面や入力方法も異なります。

また、グループ企業ではすべての会社を同時に切り替える必要はありません。対象を限定して移行し、問題がないことを確認してから次の会社へ展開することで、トラブル時の影響範囲を抑えられます。

メール停止に備えた切り替え・ロールバック対策

メール移行では「正常に切り替わること」だけを前提に計画を立てないことが重要です。一部ユーザーだけが受信できない場合はアカウント設定を確認し、多数のユーザーが送受信できない場合はMXやDNS設定を確認したうえで、ロールバックを検討します。

ロールバック手順には、元のDNS設定だけでなく、切り戻しを判断する担当者や判断期限も記載しておきましょう。

「重大な問題が起きたら戻す」という曖昧な基準ではなく、「一定時間以内に主要なメール送受信が正常化しない場合は切り戻しを検討する」といった判断基準を決めておくと、トラブル時にも対応しやすくなります。

5. Google Workspace の独自ドメイン移行を段階的に進めるポイント

PoCを実施して移行手順を標準化する方法

複数の関連会社のメール環境を Google Workspace へ移行する場合、最初からグループ全体を一斉に切り替えるのではなく、PoCを実施して手順を検証する方法があります。

まず、本社の一部ユーザーなど影響範囲を限定できる対象で、アカウント作成、既存メール移行、メール送受信などを検証します。既存のメール環境を併用して一部ユーザーのみ Gmailを試験運用する場合は、メールルーティングなどを利用して検証環境を構成します。

PoCでは、作業時間、発生したエラー、手順書との差異、利用者からの問い合わせなどを記録し、手順書やチェックリストへ反映します。単なる技術検証ではなくグループ展開に向けた標準手順を作る工程と位置付けることで、 次の関連会社では同じトラブルを防ぎやすくなります。

SPF・DKIM・DMARCを含むメールセキュリティ設定

Google Workspace の独自ドメインメール設定では、メールの送受信だけでなくなりすまし対策を含む送信ドメイン認証についても確認します。

代表的な仕組みがSPF、DKIM、DMARCです。

設定	主な役割
SPF	メールを送信できるサーバを示す
DKIM	電子署名により送信元や改ざんの有無を確認する
DMARC	SPF・DKIMの結果をもとに認証失敗メールの扱いなどを指定する

一方、Google Workspace 以外にも自社ドメインを使用してメールを送信するシステムが存在する場合があります。

その状態を把握せずに設定を変更すると、正規の業務メールまで認証に失敗する可能性があります。そのため、移行前にメールの送信元を棚卸しし、段階的に設定・確認することが重要です。

移行チェックリストと担当者の役割分担を整える方法

グループ全体への展開では、技術的な手順と同じくらい重要なのがチェックリストと役割分担です。

たとえば、次のような形で工程ごとに担当者を決めておくと、進捗管理がしやすくなります。

フェーズ	主な作業	主な担当
事前調査	ドメイン・既存環境の棚卸し	本社IT＋各社管理者
移行準備	アカウント・Google Workspace 設定	Google Workspace 管理者
DNS準備	現行設定・変更手順の確認	DNS管理者
切り替え	MXレコード変更	DNS管理者
動作確認	メール・関連システム確認	本社IT＋各社担当者
移行後	問い合わせ・不具合対応	本社IT＋各社管理者
安定運用	権限・アカウント管理	本社IT＋各社管理者

会社ごとに担当者や承認フローが異なる場合でも、チェックリストのフォーマット自体を共通化しておけば、進捗やリスクを本社側で把握しやすくなり、移行ごとにゼロから手順を考える必要もありません。

Google Workspace への移行を一度きりのシステム変更として終わらせず、移行後のアカウント管理や問い合わせ対応まで標準化することが、長期的な運用負荷の低減につながります。

6.まとめ

Google Workspace を活用することで、会社ごとに分散していた独自ドメインのメールやアカウントを整理し、グループ全体で一元管理しやすくなります。複数の独自ドメインを利用している場合には、セカンダリドメインなどを活用し、各社のメールアドレスを維持したまま管理する方法も検討できます。

移行時には、DNSやMXレコード、SPF・DKIM・DMARC、既存のメール環境や関連システムを事前に確認することが重要です。複数の関連会社を対象とする場合は、PoCで手順を検証し、役割分担やロールバック方法を明確にしたうえで段階的に展開することで移行時のリスクと運用負荷を抑えやすくなります。

株式会社フライトソリューションズでは、Google Workspace の導入やメール環境の移行をはじめ、企業のクラウド環境整備を支援しています。複数の独自ドメインや既存メール環境を含めた Google Workspace への移行をご検討の際は、お気軽にご相談ください。