Microsoft 365 から Google Workspace への乗り換え｜AD・SSO・共有リンクの落とし穴
目次 クリックで開く
ビジネスインフラの心臓部であるグループウェアの刷新は、単なるツールの入れ替えではありません。Microsoft 365からGoogle Workspaceへの乗り換えは、ファイル管理の哲学、認証基盤の設計、そしてセキュリティモデルの再定義を伴う大規模なプロジェクトです。
特に、長年Active Directory（AD）で管理してきた権限体系や、SharePoint上の膨大なドキュメントをどう「Google流」に変換するかは、多くのIT担当者が頭を抱えるポイントです。本記事では、実務者が直面する「AD・SSO・共有リンク」の3大落とし穴を中心に、検索上位の技術情報を網羅した完全版の移行ガイドをお届けします。
Microsoft 365からGoogle Workspaceへ乗り換えるべきか？
移行の検討段階で最も重要なのは、「なぜMicrosoft 365をやめるのか」という目的の明確化です。単なるライセンス費用の比較だけでなく、業務プロセスの変革（DX）という視点が欠かせません。
生産性とコストの観点からの比較
Microsoft 365は、デスクトップアプリ（Word, Excel, PowerPoint）の圧倒的な多機能性が強みです。一方、Google Workspaceは「ブラウザ完結」による徹底したリアルタイム同時編集と、検索性の高さに強みがあります。
| 項目 | Microsoft 365 | Google Workspace |
|---|---|---|
| 主な思想 | 個人の生産性・ローカル保存からの進化 | クラウドネイティブ・情報の民主化 |
| ファイル管理 | SharePoint / OneDrive | Google ドライブ / 共有ドライブ |
| 認証基盤 | Microsoft Entra ID (旧Azure AD) | Cloud Identity / Google ログイン |
| 同時編集 | 可能だが、デスクトップ版で競合が発生しやすい | 極めてスムーズ。100人単位の同時編集に耐える |
| 料金体系 | 複雑（Business, Enterprise, E3/E5等） | シンプル（Business Starter, Standard, Plus等） |
多くの企業がGoogle Workspaceへの移行を決める決定打は、「バージョン管理の撤廃」と「情報共有の摩擦ゼロ化」です。ファイルに「_最新版」「_20240414修正」といった名前をつけてメール添付する文化を、URL一つで常に最新版を共有する文化へ変えることができます。
ただし、SaaSのライセンスコスト削減だけを目的とする場合、既存のオンプレミス負債やレガシーな運用が足かせになることもあります。以下の記事では、こうしたインフラの「剥がし方」について詳しく解説しています。
SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）
ID管理と認証の落とし穴：AD・Entra ID連携の最適解
移行において最大の障壁となるのが、Active Directory（AD）やMicrosoft Entra ID（旧Azure AD）との連携です。Google Workspaceへ移行しても、PCのログイン認証や既存の社内システムのためにADを使い続けるケースは少なくありません。
オンプレミスAD継続か、Google Cloud Identityへの集約か
選択肢は主に3つあります。
- AD主権（ハイブリッド構成）：ADをソースオブトゥルースとし、Google Cloud Directory Sync (GCDS) でGoogleにユーザーを同期する。
- Entra ID主権：Entra IDをIdP（アイデンティティプロバイダー）として使い、SAML連携でGoogle Workspaceにログインする。
- Google主権（クラウドネイティブ）：ADを廃止し、Google Cloud IdentityをメインのID基盤とする。
Google Cloud Directory Sync (GCDS) 導入時の注意点
多くのエンタープライズ企業が採用するGCDSですが、運用上の「落とし穴」があります。それは「一方通行の同期」です。AD上のユーザー情報をGoogleへ流し込むことは得意ですが、Google側で設定したパスワードやプロフィール変更はADに書き戻されません。
公式ドキュメントの要点：
GCDSは読み取り専用のコネクタとして動作します。同期対象から外れたユーザーは、設定次第でGoogle側のアカウントが「停止」または「削除」されるため、除外ルールの設定には細心の注意が必要です。
退職者のアカウント削除漏れは、セキュリティ上の大きな脆弱性となります。ID管理の自動化については、以下のアーキテクチャ解説が参考になります。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ
データ移行の実務：Exchange・OneDrive・SharePointの処理
データの移行は「何を」「どこまで」運ぶかの選別が成功を左右します。すべての過去データを移行しようとすると、APIのレート制限に抵触し、終わりのない移行作業に陥ります。
移行ツールの選定
- Google Workspace Migrate：大規模（数百〜数千ユーザー）な移行に適したサーバー設置型の公式ツール。Exchange、SharePoint、ファイルサーバーに対応。
- GWMMO (Google Workspace Migration for Microsoft Outlook)：個々のユーザーが自分のOutlookデータ（PSTファイル等）を移行するクライアントツール。
- データ移行サービス（管理コンソール内）：設定が容易だが、移行速度やエラーハンドリングに制限がある。
SharePointから「共有ドライブ」へのマッピング設計
ここが実務上の最重要ポイントです。Microsoft 365のSharePointオンラインは「サイト」単位で管理されますが、Google Workspaceでは「共有ドライブ」単位になります。
- 落とし穴1：階層構造：Googleの共有ドライブは「ドライブの中にドライブ」を作ることはできません。SharePointで深い階層のライブラリを作っている場合、複数の共有ドライブに分割してフラット化する必要があります。
- 落とし穴2：権限の継承：SharePointでは特定のフォルダだけ個別に権限を外す（固有の権限）が可能ですが、Google共有ドライブは上位の権限を下位が必ず継承します。
権限管理と「共有リンク」のセキュリティリスク管理
Microsoft 365からGoogle Workspaceへ移行した直後、最も情報漏洩が起きやすいのが「共有リンク」の扱いです。
共有モデルの決定的な違い
Microsoft 365の場合、リンクにパスワードをかけたり、有効期限を設定したりすることが標準で容易です。一方、Google Workspaceの共有リンク（リンクを知っている全員）は、一度URLが流出すると、Googleアカウントを持っていない第三者でも閲覧可能になってしまう設定があります（管理設定で制限可能）。
移行時に注意すべき「リンクを知っている全員」
移行ツールを使用してOneDriveのファイルを移すと、元の「リンク共有設定」が意図せず引き継がれたり、逆にすべてリセットされて業務が回らなくなったりします。
推奨される運用：
管理コンソールで「ドメイン外への共有」をデフォルトで禁止、または警告表示にする。
「リンクを知っている全員」ではなく、特定のメールアドレスへの招待を徹底させる。
社外との頻繁なやり取りには「ビジター共有」機能（Googleアカウントがない相手に認証コードを送る機能）を活用する。
こうしたファイル管理のDX化と、AppSheetなどのノーコードツールを組み合わせることで、従来のExcel作業を劇的に効率化できます。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
移行後に発生する「業務停止」を防ぐためのチェックリスト
データ移行が終わっても、初日にユーザーから悲鳴が上がるようでは失敗です。以下の3点は必ず事前に検証してください。
1. Excel VBA / マクロの互換性
ExcelファイルをGoogleスプレッドシートとして開くことは可能ですが、VBA（マクロ）は一切動作しません。
対策：
業務影響の大きいマクロは、Google Apps Script (GAS) で書き直す。
どうしてもVBAが必要なファイルは、Googleドライブ上で「Officeファイルのまま」保存し、ローカルのExcelで編集する運用にする。
2. Outlookの「予定表」と「会議室」の同期
移行期間中に、一部の部署がOutlook、一部がGoogleカレンダーを使っていると、会議室の予約重複が発生します。
対策：
「Calendar Interop」を設定し、双方の空き時間を相互に参照できるようにする。
3. ブラウザのブックマークとショートカット
意外と忘れがちなのが、デスクトップに置いていたSharePointへのショートカットです。これらはすべて無効になるため、移行後の新URLをプッシュ通知やポータルサイトで周知する必要があります。
総括：失敗しないための段階的移行ロードマップ
Microsoft 365からGoogle Workspaceへの乗り換えを成功させるためには、技術的な整合性（AD連携・SSO）と、ユーザーの行動変容（ファイル共有文化の是正）を両輪で進める必要があります。
- フェーズ1：ID基盤の整備（Cloud Identityのセットアップ、SSO連携テスト）
- フェーズ2：パイロット移行（IT部門やDX推進チームでの実機検証）
- フェーズ3：データ移行の実施（週末を利用した一斉移行、または部署ごとの段階移行）
- フェーズ4：定着化支援（GASによる自動化、共有ドライブの運用ルール徹底）
Google Workspaceは、正しく導入すれば組織のスピードを劇的に加速させます。本記事で指摘した「落とし穴」を事前に埋め、安全でスムーズな移行を実現してください。
実務者が把握しておくべき技術的制約と運用上の誤解
移行プロジェクトを円滑に進めるためには、ツールの仕様に起因する「物理的な限界」を正しく理解しておく必要があります。特に大規模な組織では、以下の制限がボトルネックになるケースが散見されます。
公式ドキュメントに基づく主要な制限事項
Microsoft 365の柔軟な（悪く言えば複雑な）権限体系をそのまま持ち込もうとすると、Google Workspaceの仕様と衝突します。移行設計の前に必ず確認してください。
| 対象項目 | 主な制限・仕様 | 実務上の影響 |
|---|---|---|
| 共有ドライブのアイテム数 | 1ドライブあたり最大40万個（ファイル、フォルダ、ショートカット含む） | SharePointの巨大なライブラリを1つの共有ドライブに集約すると上限に達する恐れがある。 |
| 共有ドライブのフォルダ階層 | 最大20階層まで | 深いネスト構造を持つファイルサーバーからの移行時に、エラーや同期失敗の原因となる。 |
| APIの転送量制限 | 1ユーザーあたり1日750GBのアップロード上限（※エディションにより要確認） | テラバイト単位のデータ移行を行う際、単一のアカウントで行うと数日を要する。 |
公式リファレンス：
よくある誤解：「Google Apps Script (GAS) ですべて解決できる」
Excel VBAの代替としてGASが推奨されますが、GASには「1スクリプトの実行時間は最大6分（Google Workspace Business等）」「URLフェッチの回数制限」などのクォータが存在します。複雑な重い処理をGASだけで完結させようとせず、必要に応じてGoogle Cloud（BigQuery等）と連携する設計が、真の業務自動化には不可欠です。
例えば、より高度なデータ活用や自動化を目指す場合は、以下のアーキテクチャ設計が参考になります。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
認証統合の最終チェックリスト
Microsoft Entra IDをIdPとしてGoogle WorkspaceへSSO（シングルサインオン）を構成する場合、以下の3点を情シス担当者は再点検してください。
- 不変のID（Immutable ID）の整合性：Entra ID上の属性とGoogle上のメールアドレスが完全に一致しているか。
- モバイルアプリの挙動：SSO有効化後、スマートフォンのGmailアプリ等で再ログインが正しく要求され、Intune等のMDMポリシーと競合していないか。
- プロビジョニングのタイミング：Entra IDでユーザーを削除した際、Google側のアカウントが停止されるまでのタイムラグを許容できるか。
退職者管理の自動化など、ID基盤のライフサイクル管理を徹底したい場合は、以下の記事で詳細な構成を紹介しています。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。