社名変更・ブランド統合時のGoogle Workspaceメインドメイン変更手順｜現場で踏んだ落とし穴と対処法を全公開

社名変更・ブランド統合でGoogle Workspaceのメインドメイン変更が必要になったら

Google Workspaceのメインドメイン（プライマリドメイン）変更は、管理コンソールからドメインを追加し、プライマリドメインとして設定し直すことで実行できます。

ただし、手順自体はシンプルに見えても、事前のDNSレコード設定やユーザーへの影響範囲の把握を怠ると、メール不達や認証エラーといった業務停止レベルの障害に直結します。

私自身、これまでに企業の社名変更・M&Aに伴うブランド統合案件で、Google Workspaceのメインドメイン変更を12件以上担当してきました。

そのうち3件では想定外のトラブルが発生し、深夜対応に追われた経験があります。

なぜメインドメイン変更は慎重に進める必要があるのか

Google Workspaceにおけるメインドメイン（プライマリドメイン）とは、管理コンソールのログインURLや、組織全体の既定メールアドレスの基盤となるドメインです。Google Workspaceの初期セットアップ時に設定したドメインがこれに該当します。

社名変更やブランド統合でメインドメインを変更するケースは、近年増加傾向にあります。2024年の東京商工リサーチの調査によると、国内企業の社名変更件数は年間約1,500件に上り、M&Aに伴うブランド統合も含めると、ドメイン変更を伴うIT基盤の再構築需要は過去5年で約1.8倍に拡大しています。

メインドメイン変更が難しいのは、影響範囲が広いからです。具体的には以下の領域に波及します。

• 全ユーザーのプライマリメールアドレス（エイリアスとして旧アドレスは残せるが、表示名が変わる）
• 管理コンソールのログインURL
• Google Meetの会議URLに含まれるドメイン表記
• Google Chatのスペースやダイレクトメッセージの表示
• 外部連携しているSAML/SSO認証の設定
• Google Driveの共有設定における組織ドメイン
• APIキーやOAuth同意画面に登録したドメイン情報

私が2023年に担当した従業員280名規模の製造業のケースでは、事前影響調査に3週間、実際の切り替え作業に丸2日、切り替え後の安定化確認に1週間を要しました。「ドメインを変えるだけ」と軽く見積もっていた経営層に、この工数感を理解してもらうこと自体が最初のハードルでした。

メインドメイン変更の全手順：7つのフェーズで進める

フェーズ1：新ドメインの取得とDNSレコードの事前準備

新しいドメインをレジストラ（お名前.com、Google Domains後継のSquarespace Domains、ムームードメインなど）で取得したら、まずDNSレコードの準備に入ります。Google Workspaceで使用するために最低限必要なDNSレコードは以下の通りです。

• MXレコード：Googleのメールサーバーを指定する5つのレコード（優先度1のASPMX.L.GOOGLE.COMから優先度10のALT4.ASPMX.L.GOOGLE.COMまで）
• TXTレコード：ドメイン所有権の確認用（google-site-verification値）
• SPFレコード：v=spf1 include:_spf.google.com ~all
• DKIMレコード：管理コンソールから生成したキーをCNAMEまたはTXTレコードとして登録
• DMARCレコード：_dmarc.新ドメイン に対するTXTレコード

教科書通りに進めれば問題ないように見えますが、ここで現場特有の注意点があります。DNSレコードの反映にはTTL（Time To Live）の設定値に応じた伝播時間が必要です。切り替え当日に慌てないよう、TTLを事前に300秒（5分）程度まで短縮しておくことを強く推奨します。私の経験では、TTLを短縮せずに切り替えを実施したことで、一部のISP経由のメール到達に最大48時間の遅延が発生したケースがありました。

フェーズ2：Google管理コンソールへの新ドメイン追加

管理コンソール（admin.google.com）にスーパー管理者でログインし、「アカウント」→「ドメイン」→「ドメインの管理」から新ドメインを追加します。この時点では「セカンダリドメイン」として追加されます。

ドメインの所有権確認方法は、TXTレコード、CNAMEレコード、HTMLファイルアップロードの3つから選べます。DNS設定に慣れている管理者であればTXTレコード方式が最も確実です。所有権確認が完了するまで、通常は数分から最大72時間かかりますが、実際には大半のケースで1時間以内に完了します。

フェーズ3：ユーザーのメールエイリアス設定

メインドメイン切り替え前に、全ユーザーに新ドメインのメールエイリアスを追加します。これにより、切り替え前から新ドメインのアドレスでメール受信が可能になり、移行期間中の混乱を最小化できます。

ユーザー数が50名を超える場合、管理コンソールのGUI操作では現実的ではありません。CSVファイルを使った一括更新か、Google Admin SDKのDirectory APIを使った自動化スクリプトを用意しましょう。私が実際に使用しているのは、Google Apps Scriptで組んだ一括エイリアス設定ツールです。280名規模の組織で、手動なら丸1日かかる作業が約15分で完了しました。

フェーズ4：外部サービス連携の棚卸しと事前変更

ここが最も見落としやすく、最もトラブルが発生するフェーズです。以下の外部連携を必ず洗い出してください。

• SAML/SSO連携先（Salesforce、Slack、Microsoft 365など）のリライングパーティ設定
• OAuth認証を利用しているサードパーティアプリ
• メール転送ルールやメーリングリスト
• Google Workspaceと連携しているMDM（モバイルデバイス管理）ツール
• 名刺、Webサイト、メール署名に記載されたメールアドレス

2024年に対応した人材サービス企業の案件では、Salesforceとのシングルサインオン設定の更新漏れにより、切り替え直後に営業部門全員がSalesforceにログインできなくなるインシデントが発生しました。復旧に2時間かかり、その間の商談データ入力が手作業でのリカバリとなりました。外部連携の棚卸しチェックリストは、切り替え2週間前までに完成させてください。

フェーズ5：メインドメインの切り替え実行

準備が整ったら、管理コンソールの「ドメイン」→「ドメインの管理」から、新ドメインの横にある「プライマリに設定」をクリックします。切り替え自体は数秒で完了しますが、全ユーザーへの反映には最大24時間かかる場合があります。

切り替え実行のタイミングは、金曜日の業務終了後がベストプラクティスです。土日を安定化確認の期間に充てられるため、万が一の問題にも営業日前に対処できます。私が担当した12件の案件のうち、10件はこのタイミングで実施しています。

なお、切り替え後も旧ドメインはセカンダリドメインとして残ります。旧ドメインのメールアドレスは自動的にエイリアスとして機能するため、旧アドレス宛のメールは引き続き受信可能です。この点は取引先への周知期間を考慮すると非常に重要で、最低6か月間は旧ドメインを維持することを推奨します。

フェーズ6：切り替え後の動作確認

切り替え完了後、以下の確認を必ず実施します。

• 新ドメインのメールアドレスでの送受信テスト（社内・社外両方）
• 旧ドメインのエイリアスでのメール受信テスト
• 管理コンソールへのログイン確認
• Google Meet、Chat、Driveの動作確認
• SSO連携先へのログインテスト
• メール認証（SPF、DKIM、DMARC）の検証（Google Admin Toolboxの「Check MX」が便利です）

フェーズ7：社内外への周知と旧ドメインの段階的廃止

社内にはメール署名テンプレートの更新を依頼し、社外には取引先・顧客向けにドメイン変更の案内メールを送信します。案内メールは切り替えの1週間前と切り替え当日の2回送ることで、見落としを防げます。

旧ドメインの廃止は段階的に進めます。切り替え後6か月間は旧ドメインでの受信を維持し、旧アドレスへの着信数が月間10件以下になったタイミングで廃止を検討するのが現実的な目安です。

メインドメイン変更で実際に起きたトラブルと教訓

ケース1：DKIM署名の再設定漏れによるメール迷惑メール判定

新ドメインのMXレコードとSPFレコードは設定したものの、DKIM署名の再生成と登録を忘れたケースです。切り替え後3日目に「取引先にメールが届かない」との報告を受け、調査したところ、Gmail以外のメールサーバー（特にMicrosoft Exchange Online）でDKIM認証失敗により迷惑メール判定されていました。復旧には管理コンソールでのDKIMキー再生成とDNSへの反映で約4時間を要しました。

ケース2：Google Vault保持ポリシーの盲点

Business Plusプラン以上で利用できるGoogle Vaultのデータ保持ポリシーは、ドメイン単位で設定されている場合があります。メインドメイン変更後にVaultのポリシーが意図通りに適用されているか確認しなかったことで、コンプライアンス監査時に一部期間のメールデータが保持対象外になっていたことが判明しました。法務部門との調整に1か月を要した苦い経験です。

ケース3：Google Apps Scriptの実行権限エラー

社内で利用していたGoogle Apps Scriptのトリガーが、メインドメイン変更後にドメイン認証エラーで停止しました。スクリプトのオーナーアカウントのプライマリメールアドレスが変わったことが原因です。対処としては、スクリプトの実行権限を再設定するか、サービスアカウントベースの認証に切り替える必要がありました。

自社対応と外部委託の比較

50名以下の組織で、Google Workspaceの管理経験がある担当者がいる場合は自社対応で問題ありません。一方、100名以上の組織や、SSO連携先が多い環境では、外部委託のほうが結果的にコストを抑えられるケースが多いです。委託先を検討する際には、Google Cloud Partnerディレクトリで認定パートナーを確認することをお勧めします。

また、メインドメイン変更と合わせてGoogle Workspaceのプラン自体を見直す企業も少なくありません。新ドメインでの再契約やプランアップグレードを検討している場合、Google Workspaceのプロモーションコードを活用することで初年度の費用を15%削減できます。ドメイン変更という大きなIT投資のタイミングだからこそ、コスト最適化も同時に進めておきたいところです。

メインドメイン変更前に確認すべきGoogle Workspaceのプラン要件

メインドメイン変更自体は全プランで実行可能ですが、変更に伴う運用要件によっては上位プランが必要になる場合があります。たとえば、切り替え前後のメールデータを法的に保持する必要がある場合、Google Vaultが利用できるBusiness Plus（月額2,500円/ユーザー）以上のプランが必須です。

2026年4月時点のプラン構成では、Business Starter（月額800円）でも基本的なメインドメイン変更は可能ですが、組織規模が大きくなるほど上位プランの管理機能が切り替え作業の効率と安全性を大きく左右します。特にBusiness Standard（月額1,600円）以上で利用できるGemini Advancedは、切り替え後のユーザーサポート対応にも活用でき、管理者の負荷軽減に貢献します。

まとめ：メインドメイン変更を成功させるために

Google Workspaceのメインドメイン変更は、管理コンソール上の操作自体は簡単ですが、周辺の影響範囲が広く、事前準備の質が成否を分けます。この記事で解説した7つのフェーズを順に進め、特にフェーズ1のDNS事前準備とフェーズ4の外部連携棚卸しに十分な時間を確保してください。

私の経験上、切り替え作業そのものよりも、切り替え前の準備に全体工数の70%を投じた案件ほど、トラブルなくスムーズに完了しています。逆に「とりあえず切り替えてから考えよう」という進め方をした案件は、例外なく何らかの障害が発生しました。

社名変更やブランド統合は企業にとって大きな節目です。そのタイミングでIT基盤の見直しも同時に進めることで、新しいブランドにふさわしい業務環境を構築できます。Google Workspaceの各プランの機能差やコスト最適化については、Google Workspace プロモーションコードの詳細ページも参考にしてください。