オンプレファイルサーバ から SharePoint / Googleドライブ への乗り換え｜権限の棚卸し

長年運用してきたオンプレミスのファイルサーバ（Windows Server 等）は、企業にとって重要な資産であると同時に、メンテナンスコストやセキュリティリスクを抱えた「技術負債」となりつつあります。ハードウェアの保守期限（EOS）やリモートワークの普及を背景に、SharePoint Online や Google ドライブへの移行は避けて通れない課題です。

しかし、単にデータを「コピー」するだけでは、移行後に権限設定の不備による情報漏洩や、必要なファイルにアクセスできないといった業務支障を招きます。本記事では、オンプレミスからのクラウドストレージ移行において最も重要となる「権限の棚卸し」と、具体的な移行プロセスについて実務者視点で詳しく解説します。

関連記事：SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方

1. SharePoint Online と Google ドライブの権限体系を比較

移行先を検討する際、まず理解すべきは Microsoft 365 (SharePoint) と Google Workspace (Google ドライブ) の権限ロジックの違いです。オンプレミスの NTFS 権限（読み取り、書き込み、変更、フルコントロール等）に慣れた管理者にとって、クラウド側の仕様は「似て非なるもの」です。

NTFS 権限とクラウド権限の決定的な違い

オンプレミスでは Active Directory (AD) のセキュリティグループに対して、フォルダ単位で詳細なアクセス許可（ACL）を設定していました。これに対し、クラウドストレージは「グループ・チーム単位の管理」が基本となります。

SharePoint は、従来の Windows ファイルサーバに近い階層構造を持ちつつ、サイトという「枠組み」で管理します。一方、Google ドライブの「共有ドライブ」は、ファイル単体での所有権という概念を排し、チームでデータを共有するモデルに特化しています。どちらを選択すべきかは、組織の既存ワークスタイルと、Microsoft 365 か Google Workspace かというプラットフォーム戦略に依存します。

2. 移行前に絶対必要な「権限の棚卸し」3ステップ

オンプレミスからクラウドへデータを移す際、最大の失敗要因は「現状の権限設定をそのまま引き継ごうとすること」です。長年の運用で「誰がアクセスできるか不明なフォルダ」や「退職者の権限」が残ったまま移行すると、クラウド上でセキュリティホールとなります。

ステップ1：現状のアクセス権限（ACL）の可視化

まずは、現在のファイルサーバ内の全フォルダ・ファイルのアクセス権限を抽出します。Windows 標準の icacls コマンドや PowerShell の Get-Acl を活用、あるいはサードパーティの可視化ツールを用いて、CSV 形式でエクスポートします。

注意点： 抽出したリストから「Everyone」や「Domain Users」にフルコントロールが与えられている箇所、明示的に拒否設定がされている箇所を特定してください。

ステップ2：不要データの削除と「負債」の切り離し

全てのデータを移行する必要はありません。過去数年間アクセスがないアーカイブデータは、移行対象から外して安価なオブジェクトストレージ（Azure Blob Storage や Google Cloud Storage）へ退避させるか、削除を検討します。移行データ量を減らすことで、移行時間の短縮とコスト削減に直結します。

関連記事：SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

ステップ3：権限マッピングシートの作成

オンプレのセキュリティグループを、クラウド上のどのグループ（Entra ID グループや Google グループ）に対応させるかを定義します。この際、権限を「最小権限の原則」に基づいて見直します。例えば、編集不要なメンバーには「閲覧」のみを割り当てるように再設計します。

3. SharePoint Online への移行実務と注意点

Microsoft はオンプレミスからの移行を支援するために、強力な無料ツールを提供しています。

SharePoint 移行ツール (SPMT) と Migration Manager

• SharePoint 移行ツール (SPMT): 個別の PC や小規模なサーバからの移行に適しています。
• Migration Manager: Microsoft 365 管理センターから一元管理でき、複数台の「エージェント」を立てて並列で大規模な移行を行う場合に最適です。

公式の仕様によれば、移行時にはファイルのメタデータ（作成日時、更新日時、作成者）を維持するオプションがあります。しかし、オンプレミスの AD ユーザーと Entra ID のユーザーが正しく紐付いていない場合、作成者が「システム」に置き換わってしまうため、事前のディレクトリ同期（Microsoft Entra Connect 等）が必須です。

「5,000個問題」への対策

SharePoint には、一つのライブラリ（またはフォルダ）内のアイテムが 5,000 個を超えると、インデックスが効かなくなり、表示や権限変更に制限がかかるという仕様があります。オンプレミスで一つのフォルダに数万個のファイルを置いていた場合は、移行時にフォルダを分割して設計し直す必要があります。

4. Google ドライブ（共有ドライブ）への移行実務と注意点

Google Workspace への移行では、個人の「マイドライブ」ではなく、組織管理の「共有ドライブ」を中心に設計します。

共有ドライブの権限設計

共有ドライブでは、最上位（ドライブレベル）で付与した権限が、配下の全てのフォルダ・ファイルに継承されます。下層のフォルダで「権限を剥がす」ことはできません（追加することのみ可能）。そのため、権限の異なるデータ群は、別の共有ドライブとして切り出すのが正しい設計です。

移行ツールの選択

• Google Workspace 移行ツール (GWMME): サーバーサイドで動作し、大規模なデータ移行をスケジュール実行できます。
• Google Cloud Directory Sync (GCDS): 移行そのものではなく、AD のユーザー・グループ情報を Google Workspace に自動反映するために使用します。

5. 移行後のセキュリティ運用：アカウント管理と自動化

データの移行が完了しても、運用が始まれば新たな課題が生じます。特に「退職者のアカウント削除」や「プロジェクト異動に伴う権限変更」の漏れは、重大なセキュリティリスクです。

これを防ぐためには、人事システムと連動した ID ライフサイクル管理（LCM）の構築が推奨されます。例えば、人事情報の変更をトリガーに、Entra ID や Google グループのメンバーシップを自動更新するアーキテクチャを導入することで、手作業によるミスを排除できます。業務のデジタル化をさらに進める場合は、単純なストレージとしての利用にとどまらず、ローコードツールとの連携も有効です。

関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

6. まとめ：オンプレ負債を断ち切り、真のDXへ

オンプレミスファイルサーバからクラウドへの移行は、単なるストレージの場所変更ではありません。複雑化した「権限の密林」を切り開き、ガバナンスの効いたデータ管理体制を再構築する絶好の機会です。

移行の成功には、以下の 3 点が欠かせません。

1. 徹底した現状分析：どのデータに誰がアクセスしているかを可視化する。
2. クラウドに最適化した設計：NTFS 権限を無理に模倣せず、クラウドの特性に合わせた階層構造を再考する。
3. 自動化された ID 管理：プロビジョニングツールを活用し、属人的な運用を廃する。

自社のデータ構造や利用規模に合わせて、SharePoint Online または Google ドライブの特性を見極め、計画的な移行を進めてください。不明な点がある場合は、各サービスの公式ドキュメント（Microsoft 移行ガイド / Google Workspace 管理者ヘルプ）を参照することをお勧めします。