Microsoft 365 → Google Workspace 全面移行 — メール・DKIM/DMARC・OneDrive→Google Drive

🎯 はじめに：この記事のスコープ

本記事はシリーズ 「脱Microsoft・OSS移行」の第 6 回 です。第 5 回 Ubuntu データ共有セットアップ までで Ubuntu 側の業務環境は完成しましたが、メール・カレンダー・ファイル共有という 全社員の業務を支えるクラウド側のスタックがまだ Microsoft 365 に残っています。本記事ではここを Google Workspace へ全面移行する 1 日完結の実録を、メール認証三冠（SPF + DKIM + DMARC）の達成、Chrome / PWA を Linux で安定動作させる仕上げ、OneDrive → Google Drive のファイル移行までまとめて扱います。

💡 本記事の到達点: 1 日（実質作業 2 時間）で Microsoft 365 の全機能が Google Workspace に置き換わり、メール 5,540 件の取りこぼし 0、ダウンタイム 0 秒、違約金 0 円、SPF + DKIM + DMARC すべて PASS、Ubuntu 上の Chrome / PWA で Google Meet の背景設定が動作、Windows 側 G:\マイドライブ\ と Ubuntu 側 ~/GoogleDrive/ が完全等価に見え、OneDrive 側からの差分追従と外部共有リンクの棚卸しまで終わる。

🗺️ 全体フロー：9 フェーズで 1 日完結

移行は 9 フェーズ構成です。Phase 5 の DNS 切替は必ず Phase 3（メールデータ移行）の完了後に実施してください。順序を逆にすると、Workspace 側にメールボックスがない状態で MX を切ってしまい、受信メールがバウンスします。Phase 4・Phase 7〜9 は独立しているため、組織の事情で順序を入れ替えても問題ありません。

📋 前提条件と移行対象の整理

ユーザーを 4 種類に分類する（最初の判断）

メールデータ移行を始める前に、対象組織のユーザーを以下の 4 種類に分類してください。この分類を間違えると Phase 3 のデータインポートがエラーで全体停止するため、最重要の前提作業です。

⚠️ Cloud Identity Free 専用アカウントを移行対象に含めるとインポート全体が止まる — そのアカウントには Exchange Online のメールボックスが存在しないため、データインポートツールが「移行元にメールボックスがない」エラーで対象ユーザー全員分の処理を停止します。Phase 3 のユーザーマッピング画面で必ずチェックを外すこと。

前提環境

CTS の移行前構成（実例）

参考として、CTS 移行時点（2026-04-27）の構成を示します。

💡 Cloud Identity Free と Workspace の併用パターンが最安 — GCP 組織管理者役は無料の Cloud Identity Free 専用アカウントに集約し、有料 Workspace ライセンスは実際にメールを使うユーザーにだけ割り当てます。第 1 回 脱Microsoft 全体戦略 のコスト試算もこの設計が前提です。本記事では以降、この Cloud Identity Free 専用アカウントを <ci-only-admin>@<your-domain> という placeholder で表記します（読者の環境では実際の管理アカウントに置き換えてください）。

💳 Phase 1: Google Workspace 契約

Google Workspace の契約画面で Annual Plan (Monthly Payment) を選択します。「年契約・月払い」という名前ですが、実質は 12 ヶ月コミットメント。短期検証で月単位の柔軟性が欲しい場合は Flexible Plan を選びますが 20% 割高になります。

⚠️ Annual Plan はライセンス追加自由・削除不可 — 契約期間中いつでも追加できますが、削除は契約更新時まで待つ必要があります。社員退職等で実数より多くライセンスを持つと、その分も次回更新まで課金されます。最初は実利用ユーザー数きっかりで契約し、必要になったタイミングで追加するのが安全です。

CTS は Google Workspace Business Starter を 1 ライセンス（実ユーザー 1 名分）で契約、Cloud Identity Free 専用アカウントはそのまま維持しました。年額 ¥9,599、請求は既存 GCP 用のクレジットカードを流用。

🚀 Phase 2: ライセンス割当と Gmail 初期設定

ライセンス割当

管理コンソール → ディレクトリ → ユーザー → 移行対象の実ユーザー → 「ライセンス」セクションで Google Workspace Business Starter を「割り当て済み」に変更。ここで Cloud Identity Free 専用アカウント（<ci-only-admin>@<your-domain>）は Cloud Identity Free のまま維持するのがポイントです。特権管理者権限を持つため、ライセンス変更は管理権限の取り扱いに直結します。

Gmail 初期設定ウィザード（3 ステップのスマート機能）

💡 ステップ 3 を切る理由は「Workspace データを Workspace 外へ流さない」 — Maps / Wallet / Assistant 連携は便利ですが、業務メール・カレンダー情報が他の Google プロダクトに渡る経路を作ります。BtoB 業務利用ではプライバシー境界を Workspace 内に閉じるのが定石です。

📥 Phase 3: メールデータ移行（Exchange Online → Gmail）

2026-04-22 に Google が公開した 新「データインポート」ツールで、Exchange Online のメール・カレンダー・連絡先をネイティブに取り込めます。CTS の場合、5,540 件のメールを取りこぼし 0 で移行できました。

アクセスパスとユーザーマッピング

管理コンソール → データ → データのインポートとエクスポート → データインポート → Exchange Online

⚠️ メールボックスを持たない Cloud Identity Free ユーザーは除外する — <ci-only-admin>@<your-domain> のような Cloud Identity Free 専用アカウントには Exchange Online のメールボックスが存在しません。ユーザーマッピングでチェックを外さないと「移行元にメールボックスがない」エラーで全体が止まります。これらのアカウント宛に届く GCP 請求通知などは Phase 7 の受信者アドレスマップで別途吸収します。

移行結果

Gmail ストレージ使用量は 644 MB（30 GB 上限の 2.1%）。10 年分のメールでもこの程度です。

Outlook フォルダ → Gmail ラベルマッピング

Outlook のフォルダ構造は Gmail のラベルとして自動再現されます。Gmail のシステム予約ラベル（受信トレイ / 送信済み / 迷惑メール）と区別するため、インポートツールが自動的にアンダースコアを付与します。

Outlook                     Gmail
─────────────────────────  ──────────────────────────
受信トレイ              →  受信トレイ_   ← アンダースコア付与（システムラベル衝突回避）
送信済みアイテム        →  送信済みアイテム_
削除済みアイテム        →  削除済みアイテム_
迷惑メール              →  迷惑メール_
1 ProjectA              →  1 ProjectA       ← ユーザー独自フォルダはそのまま
2 ProjectB              →  2 ProjectB

💡 件数表示が「5,540 件移行 → Gmail 検索 4,083 行」になっても焦らない — Gmail はデフォルトで 会話（スレッド）単位に集約表示するため、件数より少なく見えます。CTS 実機では 5,540 個別メールが 4,083 スレッドに集約され、1,457 件が返信・引用としてマージされていました。ストレージ使用量（644 MB）と Phase 6 の送受信テストで実体は確実に確認できます。

🛑 Phase 4: Microsoft 365 自動更新オフ（NCE 7 日ルール回避）

Microsoft の NCE（New Commerce Experience） 制度では、契約開始から 7 日を超えると即時キャンセル不可になり、残期間費用一括精算か契約満了まで継続のどちらかしか選べません。CTS は移行時点で 3 ヶ月以上経過しており、即時解約は不可能でした。

採用戦略: 自動更新オフ（違約金ゼロ）

各サブスクリプションを 「有効期限切れ時にキャンセル」 に設定します。契約満了時に自動解約されるため、違約金は発生せず、残期間は Workspace と並行稼働します。

操作手順

1. M365 管理センター → 課金情報 → サブスクリプション
2. 各製品の「定期請求」を 「有効期限切れ時にキャンセル」 に変更
3. 確認画面で同意

並行稼働コストは Business Basic + Premium で約 ¥36,000（残 7.5〜9 ヶ月分）。途中解約料を払うより圧倒的に安く、しかも並行期間中は Microsoft 365 にいつでも戻せる安全網になります。

🌐 Phase 5: DNS 切替（MX + SPF）

DNS 変更は メール移行が完了してから実施します。順序を逆にすると、Workspace 側にメールボックスがない状態で MX を切ってしまい、受信メールがバウンスします。

切替前の DNS 状態（AWS Route 53）

MX レコードの変更

- cts-g.jp  MX  3600  0 <tenant>.mail.protection.outlook.com.
+ cts-g.jp  MX  3600  1 SMTP.GOOGLE.COM

Google 側が指定するのは 優先度 1 / 値 SMTP.GOOGLE.COM の 1 レコードのみ。Outlook 時代と違ってバックアップ MX は不要です。AWS Route 53 では MX レコードの値は 「優先度 + スペース + ホスト名」 の 1 行入力です。

SPF レコード（TXT）の変更

TXT 値（cts-g.jp）:
  "MS=ms########"
- "v=spf1 include:spf.protection.outlook.com -all"
+ "v=spf1 include:_spf.google.com ~all"
  "google-site-verification=xxxxxxxxxxxxxxxxxxxx..."

💡 ~all（ソフトフェイル）で開始し、運用安定後に -all（ハードフェイル）へ昇格 — 切替直後は旧 Outlook 経由の自動送信や転送が残っている可能性があり、-all だとそれらが弾かれます。1〜2 週間運用して DMARC レポート（Phase 9）で異常がないことを確認してから -all に変更します。

⚠️ 検証用 TXT（MS=... / google-site-verification=...）はそのまま残す — 解約までの並行稼働期間中、Microsoft 365 と Google Workspace の両方がドメイン所有権を検証し続けます。どちらかを早期に削除すると検証エラーで管理コンソール側の操作が止まります。完全削除は M365 解約完了後（解約日 + 1 日以降）に行います。

DNS 反映確認

dig +short MX cts-g.jp
# → 1 smtp.google.com.

または mxtoolbox.com/MXLookup.aspx で Google IP（IPv4 + IPv6）に解決していれば完了。TTL 3600 で設定しているので、最大 1 時間で全世界に反映されます。

✅ Phase 6: 動作確認（受信・送信テスト）

受信テスト（外部 → cts-g.jp）

個人 Gmail（または別ドメイン）から h-honda@cts-g.jp 宛にテストメール送信。Workspace 側で 「External」ラベル自動付与で受信できれば成功です。CTS 実機では数分以内に受信できました。

送信テスト（cts-g.jp → 外部）

返信メールを外部 Gmail に送り、受信側でメールヘッダー（「メッセージのソース」）を解析します。

重要な発見: DKIM は自動有効

Workspace 契約時点で DKIM は自動有効化されています。ただし共有ドメイン（gappssmtp.com）での署名なので、Phase 8 で自社専用キー（cts-g.jp）に切替えて信頼性を上げます。

📨 Phase 7: Cloud Identity 専用アカウント宛の受信者アドレスマップ

このフェーズは Cloud Identity Free 専用アカウントが存在する組織のみ必要です。組織がない場合（Workspace のみで運用）はスキップ可。

課題: Cloud Identity Free にメールボックスがない

Cloud Identity Free 専用アカウント（本記事では <ci-only-admin>@<your-domain>）にはメールボックスがなく、MX 切替後は GCP 請求通知などが宛先不明でバウンスします。Workspace 有料ライセンスを追加すれば解決しますが、その分の費用が増えます。

解決策: 受信者アドレスマップ（メールエイリアスは不可）

Google Workspace の 「受信者アドレスマップ」 で <ci-only-admin>@<your-domain> 宛のメールを Workspace 有料ライセンスを持つ実ユーザー（本記事では <user>@<your-domain>）の Gmail にリダイレクトします。

⚠️ メールエイリアス方式は使えない — Cloud Identity Free 専用アカウントは Workspace 組織内のユーザーとして既に存在し、特権管理者権限を持つため、別ユーザーのエイリアスとして追加しようとすると「既に使用中」エラーになります。ルーティング層（受信者アドレスマップ）の機能を使う必要があります。

設定手順

管理コンソール → アプリ → Google Workspace → Gmail → ルーティング → 受信者アドレスマップ

💡 X-Gm-Original-To ヘッダー追加は必ずオン — Gmail のフィルタで「Cloud Identity 専用アカウント宛だけ別ラベル」のような振り分けをするには、元の宛先がヘッダーに残っている必要があります。これがないと To: が転送先（実ユーザー）になっていて、転送されてきたメールと自分宛のメールの区別が付きません。

動作確認: 外部 Gmail から <ci-only-admin>@<your-domain> 宛に送信し、<user>@<your-domain> の Gmail に届けば成功。CTS 実機では 14 秒で到達しました。

🔐 Phase 8: DKIM 自社専用キー設定

Phase 6 で確認したとおり Workspace 契約時に DKIM は自動有効ですが、署名ドメインが共有の gappssmtp.com です。**自社専用キー（cts-g.jp ドメインで署名）**に切替えると、なりすまし対策・配信信頼性が業界最高水準まで上がります。

Step 1: Google Workspace で DKIM 鍵生成

管理コンソール → アプリ → Google Workspace → Gmail → メールの認証
→ ドメイン: cts-g.jp を選択 → 「新しいレコードを生成」
→ キー長: 2048 bit / プレフィックス: google

生成された TXT レコード値（例 — 鍵本体はダミー）:

ホスト名: google._domainkey.<your-domain>
値: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...{Base64 約 400 文字}...IDAQAB

Step 2: AWS Route 53 で 255 文字制限の罠を回避

DNS の TXT レコードは 1 文字列あたり 255 文字以内という仕様で、2048 bit DKIM 公開鍵（470 文字以上）をそのまま貼ると Route 53 で以下のエラーが出ます。

CharacterStringTooLong (Value is too long)

解決策: ダブルクォートで 2 つに分割。DNS リゾルバが自動的に 1 つの値として連結する仕様を使います。Base64 文字列のどこで切っても構いません（DNS リゾルバが連結時にスペースを除去するため）。

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA{Base64 前半 約 200 文字}" "{Base64 後半 約 240 文字}IDAQAB"

💡 分割位置はどこで切っても良い — DNS リゾルバが連結時に区切りスペースを除去するので、Base64 文字列の途中で切っても問題ありません。唯一気をつけるのは各文字列が 255 文字以下であること。

Step 3: Route 53 への登録と反映確認

nslookup -type=TXT google._domainkey.<your-domain>
# → "v=DKIM1; k=rsa; p=MIIBIjANB...{Base64 前半}" "{Base64 後半}...IDAQAB"

Step 4: Google Workspace で「認証を開始」

DNS 反映後、管理コンソールに戻って 「認証を開始」 ボタンをクリック。ステータスが 「DKIM でメールを認証しています」 に変われば完了です。これ以降、送信メールの DKIM-Signature ヘッダーは以下のように変わります。

- d=<domain-slug>.YYYYMMDD.gappssmtp.com; s=YYYYMMDD;
+ d=cts-g.jp; s=google;

🛡️ Phase 9: DMARC 設定

DMARC レコード設定値

ポリシー段階的強化計画

⚠️ 最初から p=reject にしない — DMARC ポリシーは「失敗時にどう扱うか」を受信側に宣言するもので、reject を最初から指定すると 正当な送信なのに SPF / DKIM 設定漏れで弾かれるケースが見えなくなります。p=none でレポートを 1〜2 週間溜め、想定外の SaaS（メルマガ配信・問い合わせ自動返信等）が cts-g.jp ドメインで送信していないかを棚卸ししてから昇格します。

最終動作確認テスト

h-honda@cts-g.jp → 外部 Gmail にテスト送信。受信側でメールヘッダーを開くと：

🎉 SPF + DKIM + DMARC 三冠達成。 ここまでが Phase 9 完了で、メール認証構成は業界最高水準です。

🖥️ 仕上げ 1: Chrome + Chrome PWA の X11 + ANGLE 化（Meet 真っ白問題）

Ubuntu 26.04 + KDE Plasma の Wayland セッションで Chrome を素のまま使うと、Google Meet の背景設定（背景ぼかし）でカメラ映像が真っ白になります。NVIDIA ドライバ 580 LTS（第 3 回）を入れた前提で、Chrome の起動オプションを調整して恒久的に解消します。

症状: Meet の背景設定でカメラが真っ白

KDE Plasma 6 系のデフォルト Wayland セッション + NVIDIA + Chrome + WebGL の組み合わせで、Google Meet の背景設定（背景ぼかし・背景画像）を有効にすると カメラ映像が真っ白になります。

chrome://gpu で確認できる GL_RENDERER の末尾が、問題発生時と解決後で以下のように変わります。

解決策: 3 つの起動オプション（1 つでも欠けると再発）

google-chrome --ozone-platform=x11 --use-gl=angle --use-angle=gl

⚠️ 3 つすべて必須・1 つでも欠けると真っ白問題が再発 — 「--ozone-platform=x11 だけで十分」「--use-gl=angle だけで治る」という解説が散見されますが、CTS 実機での再現テスト結果としては 3 セットでないと安定しません。

恒久化 1: Chrome 本体のデスクトップエントリー

毎回コマンドラインから起動するのは現実的でないため、デスクトップエントリーに書き込みます。ユーザーローカルにコピーしてから編集することで、Chrome アップデートで /usr/share/applications/ 配下が上書きされても設定が消えません。

mkdir -p ~/.local/share/applications
cp /usr/share/applications/google-chrome.desktop ~/.local/share/applications/

# Exec= 行が 3 つあるので 3 行すべて書き換える
nano ~/.local/share/applications/google-chrome.desktop

修正後:

Exec=/usr/bin/google-chrome-stable --ozone-platform=x11 --use-gl=angle --use-angle=gl %U
Exec=/usr/bin/google-chrome-stable --ozone-platform=x11 --use-gl=angle --use-angle=gl
Exec=/usr/bin/google-chrome-stable --ozone-platform=x11 --use-gl=angle --use-angle=gl --incognito

update-desktop-database ~/.local/share/applications/

# 確認: 3 行すべてに 3 オプションが含まれていれば成功
grep "^Exec=" ~/.local/share/applications/google-chrome.desktop

恒久化 2: Chrome PWA の一括書き換え（落とし穴）

Chrome の「ページをアプリとしてインストール」機能（PWA）で Gmail / Meet / Calendar / Drive 等を独立アプリとして使うと、それぞれが別の .desktop ファイルから起動するため、Chrome 本体に追加したオプションが適用されません。Meet を PWA で開くと真っ白問題が再発します。

PWA の .desktop ファイルは Exec=/opt/google/chrome/google-chrome ...（google-chrome-stable ではなく google-chrome）から始まります。一括書き換えスクリプト:

# バックアップ（タイムスタンプ付き）
cp -r ~/.local/share/applications \
   ~/.local/share/applications.backup-$(date +%Y%m%d-%H%M%S)

# 一括置換
for f in ~/.local/share/applications/chrome-*.desktop; do
  sed -i 's|Exec=/opt/google/chrome/google-chrome |Exec=/opt/google/chrome/google-chrome --ozone-platform=x11 --use-gl=angle --use-angle=gl |g' "$f"
done

update-desktop-database ~/.local/share/applications/

# 確認: すべての行に 3 オプションが含まれていれば完了
grep "^Exec=" ~/.local/share/applications/chrome-*.desktop

恒久化 3: 新規 PWA 追加時の再修正

新たに PWA をインストールすると その PWA だけ起動オプションがない状態で .desktop ファイルが作られます。週次 cron や手元のシェルエイリアスで以下を流しておくと、二重適用を防ぎつつ取りこぼし 0 で運用できます。

for f in ~/.local/share/applications/chrome-*.desktop; do
  if ! grep -q -- "--use-gl=angle" "$f"; then
    sed -i 's|Exec=/opt/google/chrome/google-chrome |Exec=/opt/google/chrome/google-chrome --ozone-platform=x11 --use-gl=angle --use-angle=gl |g' "$f"
  fi
done
update-desktop-database ~/.local/share/applications/

if ! grep -q で既に修正済みのファイルをスキップするのがポイントです。

動作確認

chrome://version

「コマンドライン」項目に --ozone-platform=x11 --use-gl=angle --use-angle=gl が含まれていれば適用済み。Google Meet で背景設定（背景ぼかし）を有効にして、自分の映像と背景が正しく見えれば完了です。PWA 版 Meet でも同じテストを通します。

⚠️ Vulkan フラグを併用しない — chrome://flags で Vulkan を有効化すると '--ozone-platform=wayland' is not compatible with Vulkan エラーで Chrome が起動できなくなります。X11 モード前提なのでフラグはリセットしておきます。

📦 仕上げ 2: OneDrive → Google Drive ファイル移行

メール側が安定したら、OneDrive のファイルを Google Drive に移行します。rclone マウントの安定運用（独自 OAuth Client ID + PUBLISH APP / systemd / FUSE）は 第 5 回 Ubuntu データ共有セットアップ で構築済みの前提で、本フェーズではバルク移行・差分追従・共有リンク棚卸しを扱います。

前提チェック（第 5 回完了済み）

以下が第 5 回で完了している前提です。未完了の場合は先にそちらを参照してください。

なぜ rclone か（移行ツール比較）

💡 OneDrive 公式 ZIP ダウンロードは罠 — 大容量フォルダを Web UI で ZIP 化すると、ファイル名の文字化け（Shift_JIS 罠） と 4 GB 超で分割破損が起きます。rclone 直結のほうが圧倒的に安全です（ZIP 文字化け対策は Ubuntu 開発環境セットアップ § Windows との ZIP ファイル交換 も参照）。

OneDrive リモートを rclone に登録

OneDrive は Microsoft 側のレート制限が rclone 共有 Client ID でも余裕があるため、Google Drive と違って独自 Client ID は不要です。

rclone config
# n) New remote
# name> onedrive
# Storage> onedrive
# client_id>            ← 空 Enter
# client_secret>        ← 空 Enter
# region> 1             ← Microsoft Cloud Global

ブラウザで Microsoft アカウントの OAuth フローを完了させると type の選択を求められます:

1. OneDrive Personal or Business
2. Root Sharepoint site
3. Sharepoint site name
...
type> 1            ← Business（M365）でも 1 で OK

次に Drive ID の選択:

Found drives. Select one:
1: OneDrive (business) - <your-org>.sharepoint.com
> 1

最後の確認に y。動作確認:

rclone lsd onedrive: --max-depth 1 | head
# → OneDrive 直下のフォルダが見えれば成功

差分同期: dry-run → 本番 → 増分追従

初回コピーは必ず --dry-run で挙動確認してから本番実行します。

# ドライラン（実際には転送しない）
rclone copy onedrive: gdrive: --dry-run --progress

# 本番（初回フル転送 / 数時間〜数日）
rclone copy onedrive: gdrive: \
    --progress \
    --log-file=migration.log \
    --log-level INFO \
    --transfers 8 \
    --checkers 16 \
    --tpslimit 10

⚠️ sync ではなく copy を使う — sync は宛先側で消えたファイルを削除する破壊的操作です。移行期間中に Drive 側で誤って何かを消した状態で sync を再実行すると、OneDrive 側からも消えてしまう事故が起きます。初回・増分とも copy、最終クリーンアップ時のみ sync を慎重に検討します。

移行中の増分追従

OneDrive を使い続けながら段階的に Drive へ移行する場合、定期的に増分コピーします:

rclone copy onedrive: gdrive: \
    --progress \
    --log-file=migration-incremental.log \
    --update

--update は タイムスタンプが新しい場合のみ上書きする安全モード。誤って古いコピーで新しいファイルを潰す事故を防ぎます。

大容量ファイルでのリトライ戦略

ネットワーク瞬断や API レート制限で失敗するファイルは必ず出ます。--retries と --low-level-retries を組み合わせて自動リカバリ:

rclone copy onedrive: gdrive: \
    --progress \
    --log-file=migration.log \
    --retries 5 \
    --low-level-retries 10 \
    --retries-sleep 30s

完了後、grep -iE "error|fail" migration.log で取りこぼしを確認し、該当パスのみ再実行します。

OneDrive 共有リンクの棚卸し

ファイル本体は rclone で移行できますが、外部に共有していた OneDrive リンクは Microsoft 365 解約と同時に URL が死にます。代替手順:

1. 棚卸し — OneDrive 管理画面 →「共有」→「自分が共有したファイル」で外部共有リンク一覧を CSV エクスポート
2. Drive 側で新リンク発行 — 該当ファイル / フォルダを Google Drive Web UI で右クリック →「リンクを取得」→ アクセス権限を旧 OneDrive リンクと同等に設定（CTS では原則「リンクを知っている全員（閲覧者）」）
3. 置換通知 — 棚卸しで見える「誰に共有していたか」を元に、対象者に「Microsoft 365 解約に伴い共有リンクを Drive 側に切り替えます」と新リンクを通知
4. 旧リンク取り消し — Microsoft 365 解約 1〜2 週間前に旧 OneDrive リンクを明示的に取り消し、移行猶予を取る

💡 共有リンク移行マッピング表を作る — CTS では OneDrive URL → Google Drive URL → 共有先（社外含む） の対応を Google スプレッドシートで管理し、解約日まで両方有効にしておくことで移行漏れを防ぎました。

📊 完成した構成と数値

メール認証フロー（最終形）

DNS レコード一覧（最終形）

CTS 実績数値（移行直後）

コスト効果（CTS 実績ベースの年額換算）

第 1 回の試算（年 $4,200+）はチーム拡張時の見込みでしたが、移行直後の単年でも 約 ¥320,000 の純減が確定しました。

🚨 リスクと対策表（M365 → Workspace 移行 編）

✅ 第 6 回まとめ

Microsoft 365 → Google Workspace 全面移行フェーズで押さえるべき項目チェックリスト:

• DNS 切替はメール移行（データインポート完了）の後。順序を逆にすると受信メールがバウンス
• NCE 7 日ルール超過後は「有効期限切れ時にキャンセル」で違約金 0 円。並行稼働コストは途中解約料より圧倒的に安い
• データインポートでメールボックスを持たない Cloud Identity Free 専用アカウントは除外。Phase 7 の受信者アドレスマップで別の Workspace ユーザーへ集約
• AWS Route 53 の DKIM 255 文字制限は「ダブルクォートで 2 分割」で回避。DNS リゾルバが自動連結
• DMARC は p=none で開始し、1〜2 週間レポート監視 → quarantine → reject に段階強化
• SPF + DKIM + DMARC 三冠が達成できれば、なりすまし対策・配信信頼性は業界最高水準
• Chrome / PWA の Meet 真っ白問題は 3 オプション必須（--ozone-platform=x11 --use-gl=angle --use-angle=gl）。PWA は別 .desktop ファイルなので一括書き換え必要
• OneDrive → Google Drive は rclone copy（sync は破壊的）。第 5 回で構築した独自 OAuth Client ID + systemd マウントが前提
• OneDrive 共有リンク棚卸し → Drive 側で新リンク発行 → 置換通知 → 旧リンク取り消し の順。マッピング表で管理

これで OS 土台 + 業務 PC 化 + 開発スタック + データ層 + メール / ファイル移行までが揃いました。Microsoft 365 残期間（〜2027/1）は並行稼働しつつ、いつでも戻れる安全網付きで Workspace 運用を本番化できます。

次回「Ubuntu リモート開発セットアップ — Tailscale + SSH + VS Code Remote で Wayland ホストに繋ぐ」では、データ層と認証基盤が揃った Linux 開発機に 外（自宅・出先・iPhone）から触れるようにする実録を扱います。Wayland では xrdp / Chrome Remote Desktop が詰むため、「画面ピクセルを送る」のではなく **「セッションを送る」**戦略に切り替えるのがポイントです。

📚 シリーズ記事

🔗 関連リソース

CTS-KB 内の関連記事

• 脱Microsoft 全体戦略・総論 — シリーズ第 1 回（コスト戦略・ロードマップ）
• Ubuntu PC セットアップ — シリーズ第 3 回（NVIDIA ドライバ事後導入・Meet 真っ白問題の前振り）
• Ubuntu データ共有セットアップ — シリーズ第 5 回（rclone 安定運用の正典・本記事の OneDrive → Google Drive パートの前提）
• Ubuntu 開発環境セットアップ — シリーズ第 4 回（Windows との ZIP 交換は 7-Zip 公式版で）

関連用語

• Microsoft 365 — 移行元のグループウェアスイート
• Google Workspace — 移行先のグループウェアスイート
• Cloud Identity — Free 版で GCP 組織管理者を維持する設計
• NCE — Microsoft 商用ライセンスの販売モデル（7 日ルール・自動更新オフ戦略の前提）
• MX レコード — メール配信経路を指定する DNS 標準レコード
• SPF — 送信元 IP ベースのメール認証
• DKIM — 署名ベースのメール認証
• DMARC — SPF / DKIM の結果を統合するポリシー
• OAuth 2.0 — Workspace データインポート・Drive API の認可プロトコル
• rclone — OneDrive ↔ Google Drive の差分同期に使う OSS ツール
• FUSE — rclone マウントの仕組み（第 5 回で詳述）
• PWA — Web アプリをネイティブ風に扱う仕組み（Chrome PWA で Gmail / Meet / Drive を独立アプリ化）
• KDE Plasma — Wayland セッションがデフォルトの Linux デスクトップ環境
• X11 — Chrome を Wayland から退避させる Ozone プラットフォーム
• Wayland — KDE Plasma 6 系のデフォルトセッション（Chrome WebGL 真っ白の原因側）

外部リソース

• Google Workspace 管理コンソール — データインポート・ルーティング・DKIM 設定
• データインポート（Exchange Online） — 2026-04-22 公開の新ツール
• Gmail メール認証（DKIM） — DKIM 鍵生成
• Gmail ルーティング（受信者アドレスマップ） — Phase 7 の設定画面
• mxtoolbox MX Lookup — DNS 反映確認
• mxtoolbox DKIM Lookup — DKIM 検証
• mxtoolbox DMARC Lookup — DMARC 検証
• Microsoft 365 サブスクリプション管理 — 自動更新オフ設定
• rclone Google Drive 公式 — 独自 Client ID と PUBLISH APP の手順
• rclone OneDrive 公式 — OneDrive リモート設定
• Chromium Ozone Platform — Wayland support — --ozone-platform フラグ公式リファレンス
• Chromium ANGLE Implementation Notes — --use-gl=angle / --use-angle=gl の背景
• KDE Bugzilla #502885 — Wayland + CSD で Chrome のウィンドウ管理が破綻する既知 Issue