個人Gmailで会社メールを運用していた事務所が、Google Workspaceに移行した全手順

会社ドメインのメールアドレスを現行のホスティングサービスで取得し、実際の送受信はGmailで行う。

小規模な事務所では広く使われている構成です。当社でも長らくこの方法で運用していました。

今回、Google Workspaceを導入し、メールもGoogle WorkspaceのGmailに統合しました。きっかけは、前回の記事でお伝えしたストレージの集約です。ファイル管理をGoogle Workspaceの共有ドライブに移す中で、メールだけ従来の構成に残しておく理由がなくなりました。加えて、ホスティングサービス側のストレージ容量の上限が見えてきたこと、Google Workspaceに組み込まれているGemini（GoogleのAI機能）をGmail上でも活用したかったことも、移行を後押ししました。

この記事では、当社が実際に行った切り替え作業の全手順と、途中でつまずいたポイントをまとめます。同じような環境で運用されている事務所の参考になれば幸いです。

なお、本記事は執筆時点の情報に基づいています。Google Workspaceや各種ホスティングサービスの管理画面・仕様は変更される場合があるため、作業時は最新の公式ヘルプもあわせてご確認ください。

個人Gmailで業務メールを受けていた会社がGoogle Workspaceに切り替えた全手順を解説するアイキャッチ画像

移行前の構成

当社のメール環境を整理します。

メールアドレスの取得先： 現行のホスティングサービス（会社ドメインで発行）
送受信の実行環境： 各スタッフの個人Gmail（ホスティングサービス側の転送設定＋GmailのSMTP設定で、会社ドメインとして送受信）
共有アドレス（info@など）： ホスティングサービスの転送機能で、該当スタッフの個人Gmailに配信

この構成自体に大きな不具合があったわけではありません。ただ、Google Workspaceを導入してDriveやカレンダーを会社アカウントに集約していく中で、メールだけが個人Gmailに残っている状態は管理上の一貫性を欠きます。Google Workspaceの管理コンソールで全員分のアカウントを一括管理できるようになるのに、メールだけは各自の個人アカウント側の設定に依存し続けることになるためです。

そこで、Drive・カレンダーの移行と合わせてメールもGoogle Workspaceに寄せることにしました。

全体の流れ

移行作業は大きく4つの工程に分かれます。

工程	作業者	所要時間の目安
1. Google Workspaceの初期設定・転送先の切り替え	管理者	半日〜1日
2. DNS設定（SPF・DKIM・受信ゲートウェイ）	管理者	1〜2時間
3. 過去メールの移行	管理者（1名ずつ）	1名あたり数時間〜1日
4. フィルター・署名・共有アドレスの再設定	各スタッフ	1名あたり5〜10分

以下、それぞれの手順を説明します。

工程1：受信先の切り替え（ホスティングサービス側の操作）

最初に行うのは、新着メールの届け先を個人GmailからGoogle Workspaceに変更する作業です。

Google Workspaceには「裏アドレス」と呼ばれる、Google指定の一時受信用アドレスが自動で用意されています。MXレコードの切り替えを行わない構成（後述）では、ホスティングサービス側の転送先をこの裏アドレスに書き換えることで、Google Workspace側の受信トレイにメールが届くようになります。

手順

Google管理コンソール（admin.google.com）で、自社に割り当てられた一時受信用アドレスの形式を確認する
ホスティングサービスの管理画面を開き、メールアカウント設定で対象ドメインを選択
各メンバーの転送先を、個人Gmailから裏アドレスに書き換える
info@などの共有アドレスも同様に書き換える

当社では9名分の転送先を変更しました。ホスティングサービスにはメールアカウント一覧のCSVエクスポート機能があるため、件数が多い場合はCSVで一括置換してからインポートすると効率的です。

工程2：送信メールの信頼性を確保する（DNS設定）

転送先を変えただけでは、Google Workspaceから送信したメールが相手先で迷惑メール扱いされる可能性があります。これを防ぐため、3つのDNS関連設定を行いました。

SPFレコードの追加

ホスティングサービスのDNSレコード設定で、既存のSPFレコード（v=spf1 で始まるTXTレコード）に include:_spf.google.com を追記します。末尾の ~all の手前に半角スペースを空けて追加するだけです。

DKIMの有効化

DKIMは、送信するメールに電子署名を付け、そのメールが自社ドメインから正当に送信されたことを受信側が確認できるようにする仕組みです。Google管理コンソールのGmail設定からDKIMの新しいレコードを生成し、表示されたTXTレコードの値をホスティングサービスのDNS設定に追加します。ホスト名は google._domainkey です。登録後、管理コンソールに戻って「認証を開始」をクリックします。

ただし、DNSの反映には時間がかかる場合があるため、「認証を停止」ボタンが表示された時点で完了と判断せず、実際に送信したメールのヘッダーを確認して、DKIM署名が正しく付与されているかをあわせて確認しました。なお、なりすまし対策としてはDKIMだけでなくSPFとDMARCもあわせて設定することが推奨されています。SPFレコードの追記は前項の手順で行っています。

受信ゲートウェイの設定

ホスティングサービスを経由してメールを転送する場合、Gmailからはホスティングサービスが直接の送信元として見えることがあります。このままでは本来の送信元を正しく判定できず、SPF認証や迷惑メール判定が意図した通りに働かないことがあります。当社の環境でも、転送されたメールをGoogleが「不審な送信元」と判定するケースがありました。

Google管理コンソールのGmail設定で「受信ゲートウェイ」を有効化し、ホスティングサービスのIPアドレスを登録しておくと、Gmailがメールヘッダーをたどって本来の送信元IPアドレスを特定できるようになり、SPF認証や迷惑メール判定を行いやすくなります。

「外部IPを自動検出する」はON、「ゲートウェイのIPから届いたものではないメールはすべて拒否する」はOFFにしています。後者をONにすると、Google内部からの通知メールや社内メールまでブロックされてしまうため注意が必要です。いずれもGoogle公式では任意設定とされており、自社の構成に合わせて判断してください。

工程3：過去メールの移行

Google Workspaceの管理コンソールには、別のGoogleアカウントからメールをインポートする機能があります。管理者が1名ずつ順番に作業を行います。

手順

管理コンソールで「データ」→「データのインポートとエクスポート」→「データインポート」を開く
「別のGoogleアカウント/Gmail」のインポートを選択
移行元（個人Gmail）のアドレスを入力し、接続をリクエスト
本人にOAuth認証を完了してもらう（届いたメールで「許可」を押すだけ）
移行先（Google Workspaceアカウント）を指定し、インポートを開始

処理はバックグラウンドで実行されるため、画面を閉じても問題ありません。1名あたりの所要時間はメール量によりますが、数時間から1日程度です。「スキップ済み」と表示されるメールは既に移行済みのものなので、正常な動作です。

なお、当社が調べた限り、個人GmailからGoogle Workspaceへのメール一括移行にはこの方法が最も確実でした。POPでの移行ではラベルやフィルタが引き継がれず、Google Workspaceアカウント側のインポートボタンも当社のプランでは見当たりませんでした。

工程4：各スタッフが行う設定

ここからは、スタッフ各自に対応してもらう作業です。いずれも数分で完了します。

フィルター（振り分けルール）の移行

旧個人Gmailの設定画面で「フィルタとブロック中のアドレス」を開く
「すべて選択」→「エクスポート」で mailFilters.xml をダウンロード
新しいGoogle Workspaceアカウントの同じ設定画面で「フィルタをインポート」→ファイルを選択→「フィルタを作成」

過去メールに付いていたラベル自体は移行時に自動作成されるため、この手順で振り分けルールだけを移せば、これまでと同じ運用がそのまま再現されます。

署名の移行

旧Gmailの設定→全般タブで署名をコピーし、新しいGoogle Workspaceの同じ画面に貼り付けて保存するだけです。

info@等での送信設定（該当者のみ）

info@など共有アドレスで送信する必要があるスタッフは、Google WorkspaceのGmail設定→アカウントタブで「他のメールアドレスを追加」を行います。ホスティングサービスのSMTP情報を入力し、確認コードで認証すれば、送信元をプルダウンで切り替えられるようになります。

MXレコードの切り替えは見送った

Google Workspaceの正規構成では、MXレコードをGoogleに向けてメールを直接受信するのが推奨されています。当社でも検討しましたが、今回は見送りました。

理由は、Workspaceアカウントを持たない関係者への影響が大きすぎたためです。当社のドメインには、Google Workspaceユーザー以外にも多数のメールアドレスが存在しており、MXを切り替えた場合、それらすべてにGoogle側でルーティング設定やグループの作成が必要になります。対象が数百件に及ぶため、現時点では作業量に見合わないと判断しました。

現在の「ホスティングサービス経由で裏アドレスに転送」という構成はGoogleが移行期間用として提供しているものであり、業務上の支障は発生していません。将来的に全員がGoogle Workspaceアカウントを持つ段階で、MX切り替えを再検討する予定です。

移行時に注意した点

切り替え順序を間違えない。 ホスティングサービス側の転送先変更（工程1）は、Google Workspace側のアカウント準備が完了してから行います。順序を逆にすると、メールの行き先がなくなる時間帯が発生します。

テスト送信で受信確認を行う。 転送先の切り替え後、外部から各アドレス宛にテストメールを送り、Google Workspaceの受信トレイに届くことを確認しました。SPF・DKIMの設定反映にはDNSの浸透時間が必要なため、送信テストは数時間〜半日空けて行うと安全です。

スタッフへの周知はシンプルに。 管理者側の作業が大半を占めるため、スタッフに依頼する内容は「フィルターの移行」「署名のコピー」「info@の送信設定（該当者のみ）」の3点に絞り、それぞれ手順書を用意しました。

まとめ

工程	内容	ポイント
受信切り替え	ホスティングサービスの転送先を裏アドレスに変更	CSVで一括置換が効率的
DNS設定	SPF追記・DKIM有効化・受信ゲートウェイ	迷惑メール判定を防ぐために必須
メール移行	管理コンソールからOAuthで1名ずつ	数時間〜1日、バックグラウンド実行
個別設定	フィルター・署名・共有アドレス	各自5〜10分で完了

今回のメール移行は、Google Workspace導入によるストレージ統合の延長線上で行ったものです。メール単体で深刻な問題を抱えていたわけではありませんが、Drive・カレンダーを会社アカウントに集約した以上、メールだけ個人Gmail側に残しておく合理性はありませんでした。結果として、管理コンソールでの一元管理、ホスティングサービスのストレージ制約からの解放、GeminiをはじめとするGoogle Workspaceの機能をメールでも活用できる環境が整いました。

移行作業そのものは、管理者1名が集中して対応すれば1〜2週間で完了できる規模です。仕組みとしては難しくないものの、DNS設定や受信ゲートウェイなど、事前に調べておかないとハマる箇所がいくつかあります。手順を整理してから着手することをおすすめします。

私たちアクセルパートナーズは、クラウド移行の実行支援を軸に、中小・中規模企業の「外部経営企画室」として集客から採用・財務までご支援しています。「Google Workspaceを導入したいが、メールやファイルの移行まで手が回らない」「個人アカウントでの運用を整理して、管理を一本化したい」とお考えの方は、お気軽にご相談ください。