共有ドライブをSharePointへそのままの構造で移すことはできません。両者は権限の考え方が異なるため、移行は「コピー」ではなく設計のやり直しになります。1共有ドライブ＝1サイトと機械的に対応させず、権限を分けたい単位でサイトを分けるのが基準です。移行前にやるべきは、外部共有リンクの棚卸しと、長いパスの検出の2つです。
Google WorkspaceからMicrosoft 365への移行を、共有ドライブのSharePoint再設計を含めてワンストップでご支援しています。
Google Workspace → M365 移行支援 を見る →Microsoft 365 コンサルティングそのまま移すと必ず破綻する
Google Workspaceからの移行で、メールは比較的すんなり終わります。難所になるのは共有ドライブです。理由は、両者の設計思想が違うためです。
共有ドライブは「箱にメンバーを紐づける」モデルです。ドライブ単位でメンバーとロールを設定し、中のファイルは基本的にその設定を継承します。一方SharePointは、サイトという単位に、ドキュメントライブラリとグループが組み合わさった構造です。
この違いを無視して1対1でコピーすると、次のことが起きます。
- 使われていない共有ドライブまでサイトとして残り、管理対象が増える
- 権限が意図どおりに移らず、見えるべき人に見えない／見えてはいけない人に見える
- 外部共有していたリンクが切れ、取引先から問い合わせが来る
移行は設計をやり直す機会と捉えてください。全体の進め方はGoogle Workspace → Microsoft 365 移行の実務ガイドにまとめています。
構造がどう違うか
| 観点 | Google 共有ドライブ | SharePoint |
|---|---|---|
| 単位 | 共有ドライブ | サイト（＋ドキュメントライブラリ） |
| メンバー管理 | ドライブに直接メンバーとロールを設定 | サイトのグループ（所有者／メンバー／閲覧者）に割り当て |
| 権限の粒度 | ドライブ単位が基本。ファイル単位の追加共有も可 | サイト、ライブラリ、フォルダ、ファイルの各階層で設定可能 |
| 階層 | フォルダ階層で表現 | サイトを分けるか、ライブラリを分けるかの判断が入る |
| 外部共有 | リンク共有と個別招待 | テナント／サイト単位で外部共有の可否を制御 |
実務上いちばん影響するのは権限の粒度です。SharePointは細かく設定できますが、細かくするほど管理できなくなります。ファイル単位・フォルダ単位の個別権限は極力使わない設計にしてください。
サイト分割の設計
分割の基準はシンプルです。権限を分けたい単位でサイトを分ける。それ以外の理由で分けないでください。
| 分ける | 分けない |
|---|---|
| アクセスできる人が明確に違う（例：人事、経理） | 単に部署が違うだけで、見せてよい範囲は同じ |
| 外部共有の可否が違う | フォルダで整理すれば済む |
| 保存期間・保持ポリシーが違う | 「なんとなく分かれていたから」 |
| プロジェクト単位で開始・終了がある | ― |
移行前の共有ドライブが数十個ある場合、そのままサイトを数十個作ると管理しきれません。統廃合の判断を先に済ませてください。最終更新日を見て、1年以上使われていないドライブはアーカイブとして別扱いにするのが現実的です。
権限の作り直し
Googleのロールは、そのままの形ではSharePointへ移りません。移行ツールが対応付けを試みますが、意図どおりになるとは限らないため、移行後の確認が必須です。
作り直しの手順は次のとおりです。
- グループを先に作る：個人を直接権限に割り当てず、Entra ID のグループを介して付与します。異動時の付け替えが1か所で済みます
- 3段階に整理する：所有者（設定を変えられる）、メンバー（編集できる）、閲覧者（読める）。まずこの3つに寄せます
- 例外を数える：3段階に収まらないものだけを個別対応にします。例外が多いなら、サイトの分け方が間違っています
- 棚卸しの周期を決める：年1回、グループのメンバーを確認する運用を先に決めておきます
移行は、Googleで積み上がった例外的な共有をリセットできる数少ない機会です。そのまま持ち込むと、同じ状態が続きます。
外部共有リンクの棚卸し
移行によってURLが変わるため、既存の外部共有リンクはすべて無効になります。取引先へ渡しているリンクがあれば、事前の連絡が必要です。
同時に、棚卸しの機会にもなります。
- 「リンクを知っている全員」で共有されたままのファイルを洗い出す
- 退職者や終了した案件に紐づく共有を止める
- 移行後は、外部共有に有効期限を設定する運用に切り替える
棚卸しをせずに移行すると、過剰共有の状態がそのまま新環境へ引き継がれます。移行前に一度リストを出してください。
ファイル名とパス長の制約
移行時にエラーとなる典型が3つあります。
| 制約 | 内容 | 対処 |
|---|---|---|
| パス長 | URLとしてのパスが長すぎると移行できない（おおむね400文字） | 階層を浅くする、フォルダ名・ファイル名を短くする |
| 使えない文字 | ファイル名に使用できない記号が含まれている | 事前に検出して一括で置換する |
| ファイルサイズ | 極端に大きいファイル | 分割するか、別の保管先を検討する |
パス長はフォルダ階層が深い組織で多発します。「2026年度／第1四半期／営業部／◯◯株式会社／提案／初回／…」のような構造は、日本語ファイル名と組み合わさると容易に上限へ達します。
移行計画の初期に検出ツールで洗い出し、階層を浅くする作業を移行前に済ませてください。移行当日に発覚すると、その場で判断できず作業が止まります。同種の論点はファイルサーバー移行の進め方でも扱っています。
移行の順序
| 順序 | やること |
|---|---|
| 1 | 共有ドライブの一覧と最終更新日を出し、統廃合を判断する |
| 2 | 外部共有リンクを洗い出し、不要なものを止める |
| 3 | パス長・ファイル名の問題を検出し、事前に修正する |
| 4 | サイト構成と権限グループを設計する |
| 5 | 少数のドライブでパイロット移行し、権限が意図どおりか確認する |
| 6 | 本移行。移行後に権限の確認とリンクの案内を行う |
1〜3は移行ツールを触る前の作業です。ここを飛ばすと、5のパイロットで必ず戻ってきます。
よくある質問
共有ドライブとSharePointサイトは1対1で対応させるべきですか？
機械的に1対1にすると、使われていない共有ドライブまでサイトとして残り、管理対象が増えます。移行を機に統廃合を検討してください。ただし逆に大きくまとめすぎると、権限の粒度が粗くなって過剰共有につながります。権限を分けたい単位でサイトを分けるのが基準です。
Googleのアクセス権はそのまま移行できますか？
そのままの形では移りません。共有ドライブのロール（管理者、コンテンツ管理者、投稿者、閲覧者など）とSharePointの権限は考え方が異なります。移行ツールが対応付けを試みますが、意図どおりになるとは限らないため、移行後に必ず確認してください。
外部共有リンクはどうなりますか？
移行によってURLが変わるため、既存のリンクは無効になります。取引先へ渡しているリンクがある場合は、移行前に洗い出して連絡が必要です。あわせて「リンクを知っている全員」で共有されたままのファイルを棚卸しし、不要なものは移行前に整理してください。
移行できないファイルはありますか？
パスが長すぎるファイル、ファイル名に使えない文字を含むファイル、極端に大きいファイルは移行時にエラーになります。とくにパス長は、フォルダ階層が深い組織で多発します。移行前に長いパスを検出して、階層を浅くするか名前を短くしてください。
Googleドキュメントはどうなりますか？
移行時にWord、Excel、PowerPointの形式へ変換されます。複雑な数式やApps Scriptは引き継げないため、業務で使っているものは事前に洗い出して個別に対応してください。
まとめ
共有ドライブからSharePointへの移行は、コピー作業ではなく設計のやり直しです。1対1で対応させず、権限を分けたい単位でサイトを分けてください。それ以外の理由で分けると、管理対象だけが増えます。
移行ツールを触る前に、共有ドライブの統廃合判断、外部共有リンクの棚卸し、パス長とファイル名の事前修正の3つを済ませてください。この3つを飛ばすとパイロット移行で必ず手戻りが出ます。
権限はEntra IDのグループを介して所有者・メンバー・閲覧者の3段階に寄せ、例外は数えられる範囲に抑えます。例外が多いなら、サイトの分け方を見直すサインです。