オンプレのファイルサーバー（約1.5TB／70万ファイル規模）を OneDrive for Business／SharePoint Online に移行する際は、権限の例外運用と同期の限界がつまずきポイントです。見え方・容量計算・サイト分割・同期しない運用まで、実務で破綻しない設計を具体例でまとめます。
結論：置き換えは可能。ただし「階層そのまま」「全員フル同期」は避ける
70万ファイル級の移行で一番やってはいけないのは、ファイルサーバーの階層と運用をそのままクラウドにコピーして、全員がPCに同期して使う設計です。SharePoint Online は強力ですが、得意領域は「共同作業」「検索」「権限統制」「監査」です。逆に、ファイルサーバー型の例外権限が大量にある“巨大な階層フォルダー”を、全員が同期してオフライン前提で使うやり方は破綻しやすいです。
- 権限：フォルダー単位で設定は可能だが、例外（継承解除）を増やすほど運用が壊れる
- 見え方：基本は権限でトリミングされ「見えない」。ただし共有リンク運用次第で“存在が推測できる”場面は残る
- 容量：SharePoint は組織プールのため、ライセンス数に対して移行量が上回るとすぐ詰まる
- 同期：同期は“便利機能”ではなく“設計課題”。同期対象を最小にし、ブラウザー中心へ寄せる
- 設計：サイト／ライブラリ分割＋浅い階層＋メタデータ（列とビュー）で再設計する
まず整理：OneDrive と SharePoint（Teams）の役割を混ぜない
移行で揉める原因の多くが「何を OneDrive に置き、何を SharePoint に置くか」を曖昧にしたことにあります。判断を早くするための実務目安を表でまとめます。
| 用途 | 推奨の置き場所 | 共有の単位 | 権限の考え方 | 同期の考え方 |
|---|---|---|---|---|
| 個人作業（下書き／一時保存） | OneDrive for Business | 必要時だけ共有 | 原則は本人。共有は都度コントロール | 同期OK（ただし巨大化させない） |
| 部署の共有（部内で共同編集） | SharePoint サイト（＝Teamsのファイルも実体はSharePoint） | サイト／ライブラリ | Microsoft 365 グループ／SharePoint グループで統制 | 同期は“必要な一部だけ” |
| 全社共有（規程・テンプレ） | SharePoint（閲覧中心サイト） | サイト | 閲覧権限を広く、編集は限定 | 原則ブラウザー（同期しない） |
| 機密（人事・給与・契約など） | SharePoint（機密専用サイト） | サイト／ライブラリ | 最小権限＋監査前提。例外は極小化 | 原則同期しない（必要時のみ限定） |
| 保管目的のアーカイブ | SharePoint も可（ただし設計必須） | サイト／ライブラリ | 閲覧者を明確に。例外権限は作らない | 同期しない。検索と閲覧中心 |
Microsoft 365 Business Basic では「1ユーザーあたり 1TB のクラウドストレージ」がうたわれますが、これは“個人用領域”の文脈で語られることが多い点に注意してください。 共有の大容量置き場を OneDrive に寄せると、所有者退職や共有の氾濫で管理が難しくなります。共有は SharePoint を“正面”に置き、OneDrive は個人作業の標準置き場として整理するのが安全です。
権限：サブフォルダーだけアクセスさせることは可能。ただし例外運用は最小限に
「UserA は Main 配下すべて」「UserB は Accounting\Banking のみ」のような要望は、SharePoint でも技術的には実現できます。フォルダー単位で権限を付与し、継承を解除すればよいからです（サイト／ライブラリ／フォルダー／ファイルで個別に権限を設定できます）。
ただし、実務では“フォルダーごとの継承解除（例外）”を大量に作るほど、管理が破綻します。理由はシンプルで、以下が一気に増えるからです。
- 「誰がどこまで見えるか」を説明できなくなる（ヘルプデスクが詰む）
- 異動・退職・組織改編のたびに権限棚卸しが地獄になる
- “親を直したつもりが子に効かない”など、事故が起きやすい
さらに、SharePoint には「ユニーク権限（継承解除した権限設定）」の上限があり、リスト／ライブラリ単位で最大 50,000、一般的な推奨は 5,000 とされています。 70万ファイル級でフォルダー例外を増やす設計は、上限や運用品質の両面でリスクが高いです。
実務で強い：権限は「サイト」「ライブラリ」単位に寄せる
ファイルサーバーの置き換えで安定しやすいのは、権限設計の単位を下げすぎないことです。おすすめは以下の優先順位です。
| 権限を切る単位 | 向いている場面 | メリット | 注意点 |
|---|---|---|---|
| サイト | 部署・機密区分・プロジェクトごと | 管理が最も簡単。権限説明もしやすい | サイト数が増えるので命名・運用ルールが必須 |
| ドキュメント ライブラリ | 同一サイト内で用途が分かれる（例：部内共有/機密） | サイトほど増えず、権限境界を作れる | ライブラリ乱立は検索・導線設計が必要 |
| フォルダー | 例外をどうしても避けられない場合のみ | 従来階層に近い感覚で制御できる | 継承解除が増えると運用が壊れる（上限もある） |
| ファイル | 個別共有（例：外部共有、特例） | 最小範囲で共有できる | “共有リンクの放置”が事故要因になりやすい |
「UserB を Banking のみに」問題の現実解
ファイルサーバーと同じ階層で「Accounting\Banking だけ別権限」にしたくなるのは自然ですが、SharePoint での“安全運用”に寄せるなら、次のいずれかが現場で強いです。
- 案A：Accounting をサイトとして分け、Banking をライブラリ（またはサブサイトではなくサイト）にする
→ 権限境界が明確で、例外が増えにくい - 案B：同一サイト内で「Accounting（一般）」と「Banking（機密）」をライブラリで分ける
→ サイトは増やしたくないが権限境界は欲しい場合に有効 - 案C：どうしてもフォルダーで切る（最終手段）
→ 例外フォルダー数を“上限付き”にして、増やさないルールを作る
オリジナルの現場ルールとしておすすめなのは、「例外は“申請制”にして、例外フォルダーは棚卸し対象にする」ことです。例外を“作れる状態”にしておくと、現場の善意で増えていきます。増えた瞬間に、SharePoint はファイルサーバーの悪い部分（例外だらけの権限）をそのまま引き継いでしまいます。
見え方：基本は権限で「見えない」。ただし“共有リンク”と“限定アクセス”を理解する
SharePoint はアクセス制御リスト（ACL）に基づき、権限がないアイテムが検索結果から除外される（セキュリティトリミング）動きをします。
そのため、一般的な操作（ライブラリの一覧表示、検索、最近使ったファイル等）では、権限のないフォルダー／ファイルは基本的に見えません。ただし、実務では次の2点が“落とし穴”になります。
- 共有リンク運用：権限がない人に「リンク共有」してしまうと、リンク経由で開けてしまう（＝見え方の前提が崩れる）
- 限定アクセス（Limited Access）：子フォルダーやファイルだけに権限を付けると、内部的に親側に“通過用の最低限権限”が付くことがある（挙動を理解しておかないと混乱する）
「フォルダーが見える／見えない」で揉める場合は、次の表で整理すると話が早いです。
| 状況 | ユーザーの体感（一覧・検索） | ユーザーの体感（直リンク） | 運用上の対策 |
|---|---|---|---|
| フォルダー／ファイルに権限なし | 基本的に表示されない | 開けない | 原則この状態を保つ |
| 子フォルダーだけに権限あり（親は権限なし） | 親を辿って閲覧はできないことが多い | 直リンクなら開けるケースがある（限定アクセスの挙動） | 例外を増やさない。可能ならライブラリ／サイトで分離 |
| 共有リンクを発行してしまった | 一覧には出ないのに“開ける”など、説明が難しくなる | リンクから開ける | 外部共有ポリシー／期限付きリンク／棚卸しを徹底 |
「見えない設計」を守るには、権限設計だけでなく共有のガバナンス（誰が共有リンクを作れるか、期限、外部共有の範囲、監査）をセットで決める必要があります。特に機密領域は、サイトを分けて外部共有を抑制するだけでも事故率が大きく下がります。
容量：Business Basic 20ライセンスでの計算と、足りないときの現実的な選択肢
SharePoint の組織全体のストレージは、基本的に「1TB +（購入ライセンス数 × 10GB）」で計算されます。 さらに、追加ストレージ（Office 365 Extra File Storage など）を購入して増やす形になります。
例として、Business Basic を 20 ライセンス保有している場合は次の試算になります（概算）。
| 項目 | 計算 | 目安 | ポイント |
|---|---|---|---|
| SharePoint（組織プール） | 1TB +（20 × 10GB） | 約 1.2TB | 共有サイト（Teams含む）の合計で消費 |
| OneDrive（個人領域） | 1ユーザーあたり標準 1TB（必要に応じて増枠可） | ユーザーごと | SharePoint の組織プールとは別枠として扱われる旨が明記されている |
オンプレが約 1.5TB の場合、SharePoint の共有プール（約 1.2TB）だけでは単純移行で不足する可能性が高いです。さらに、SharePoint ではサイトのごみ箱も組織全体の容量に含まれます。
容量が足りないときの“現実解”は次の3つです。どれが正しいかは、データの性質（共同編集が必要か、監査が必要か、どれだけ参照されるか）で決めます。
| 選択肢 | 向いているデータ | メリット | 注意点 |
|---|---|---|---|
| 追加ストレージを購入して SharePoint に集約 | 共同編集・検索・監査が必要な“現役データ” | 運用統一。Teams/SharePoint中心で回せる | コストが増える。容量増分の管理が必要 |
| 移行前に棚卸し（削除・整理・重複排除） | 古い・放置・重複が多いデータ | コストも運用負荷も減る | 現場合意が必要。ルールなしだと進まない |
| アーカイブの置き場を分ける（SharePoint以外も含めて） | ほぼ参照しない“保管データ” | SharePointを現役用途に最適化できる | 検索・権限・バックアップの仕組みを別途設計 |
なお、SharePoint のサイト単体は最大 25TB まで設定できますが、組織全体の上限（プール）に縛られます。 つまり「サイトは 25TB まで行けるから大丈夫」という読みは危険です。
同期性能：70万ファイルは「同期しない前提」で設計する
OneDrive 同期クライアントは便利ですが、巨大ライブラリの同期はトラブルの温床です。Microsoft 公式の制限・推奨として、同期については「合計 300,000 アイテムを超えないことを推奨」「同期していなくても、300,000 を超えると性能問題が起き得る」と明記されています。
70万ファイル級は、設計として「全部同期」は選択肢から外すのが現実的です。ここで重要なのは、同期を“禁止”するのではなく、同期を“例外”にすることです。
おすすめのアクセス設計：ブラウザー中心＋同期は最小限
現場で安定する運用パターンは次の通りです。
| シーン | 推奨 | 理由 | 運用メモ |
|---|---|---|---|
| 日常の閲覧・検索 | ブラウザー（SharePoint） | 同期負荷ゼロ。検索・フィルタが強い | “どこに何があるか”はナビと検索で教育する |
| 共同編集（Office文書） | Teams/SharePoint で直接開く | 同時編集・版管理が活きる | ローカル保存癖を減らすのがコツ |
| どうしてもローカル作業が必要な少量フォルダー | 同期（対象を絞る） | 現場の作業効率を落とさない | 同期OK範囲を“固定”し、増やさない |
| 機密領域 | 原則ブラウザー、必要時のみ限定同期 | 端末流出・誤共有リスクを下げる | 同期するなら端末の暗号化・条件付きアクセスも検討 |
「Files On-Demandでも重い」への答え
Files On-Demand は“中身をダウンロードしない”だけで、同期関係の管理や変更検知は発生します。つまり、アイテム数が巨大だと、オンデマンドでも重くなり得ます。そこで実務では、次の順で対策します。
- 同期する前提を捨てる：Webアクセスを標準にする
- サイトを分割する：巨大な1サイトに全部突っ込まない
- ライブラリを分割する：部署や業務単位で“同期可能サイズ”にする
- 同期対象を固定する：勝手に「全部同期」が増えない仕組み（ルール）を作る
「同期対象を選べばOK」と思われがちですが、Microsoft は“同期していなくても、アイテム数が多いと性能問題が起こり得る”旨を明記しています。 したがって、根本はアイテム数を分散し、同期そのものを主戦場にしないことです。
構造設計：「ファイルサーバーと同じ階層」で置けるか？に対する現実的な答え
技術的には、SharePoint のライブラリは最大 30,000,000 アイテムまで格納できます。 よって「置けるか？」だけなら“置けます”。
しかし、運用上は次の制約が効いてきます。
- リスト表示のしきい値：ビューで 5,000 を超えるとエラーになるケースがある（特にクラシック体験）
- ユニーク権限上限：継承解除が増えると上限に近づく
- パス長：URL（デコード後）のフルパスが 400 文字を超えられない
- 禁止文字・予約名：移行時に弾かれるファイル名が出る
パス長とファイル名の制限は、深い階層ほど刺さる
深いフォルダー階層をそのまま持ち込むと、最終的に“移行できないファイル”が出ます。実務で特に効くのはこの2つです。
| 制約 | 内容（要点） | 影響 | 対策 |
|---|---|---|---|
| パス長 | デコード後のフルパス（フォルダー＋ファイル名）で 400 文字以内 | 深い階層・長いファイル名ほど移行エラー | 階層を浅く、フォルダー名を短く、メタデータ活用 |
| 禁止文字 | ” * : < > ? / \ | は使用不可。先頭末尾のスペースも不可 | 移行時に弾かれる／勝手にリネームされる | 移行前スキャンで洗い出し、命名規約を作る |
「階層は残したい」という要望は多いので、現実解としては、“大分類だけフォルダー”＋“検索しやすい列（年度／顧客／案件／機密区分など）”を付けてビューで見せるという折衷が強いです。フォルダーで全てを表現しようとすると、深さ・例外権限・同期・パス長の4点セットで詰みやすいです。
おすすめのサイト分割テンプレ：部署別＋機密別で「例外権限」を減らす
70万ファイル級を“ひとつの巨大共有”として移行すると、権限と同期が必ず限界を迎えます。分割の基準はシンプルで、「人の境界（誰が使うか）」と「データの性質（機密・外部共有・更新頻度）」です。
| サイト例 | 主なライブラリ例 | 権限の基本 | 同期方針 | 一言メモ |
|---|---|---|---|---|
| 全社ポータル | 規程、申請書テンプレ | 閲覧＝全社員、編集＝限定 | 同期しない | “探す場所”をここに寄せる |
| 経理 | 請求、支払、Banking（機密） | 経理メンバーのみ | 原則しない（必要時だけ） | Banking はライブラリ分割が効く |
| 人事（機密） | 人事情報、評価、労務 | 最小権限 | 同期しない | 例外権限を作らない運用が重要 |
| 営業 | 提案、見積、顧客別資料 | 営業メンバー＋必要部署 | 限定的に同期OK | 顧客別はメタデータ＋ビューが強い |
| プロジェクト | 案件別 | 案件メンバーのみ | 案件ごとに最小同期 | 終わったらアーカイブサイトへ移す |
| アーカイブ | 年度別、部門別（閲覧中心） | 閲覧者を明確化 | 同期しない | “保管”と“活用”を分ける |
この形に寄せると、フォルダーの継承解除を増やさずに済み、結果として「権限の説明」「異動時の追加・削除」「監査」の負担が激減します。
アーカイブ用途：SharePointに“置く”前に、アーカイブの種類を分ける
アーカイブには2種類あります。
- 活用アーカイブ：ときどき探して参照する（検索が大事）
- 保管アーカイブ：ほぼ触らない（コストと保全が大事）
SharePoint は前者（活用アーカイブ）と相性が良いです。検索・権限統制・共有が得意だからです。一方で後者（保管アーカイブ）まで全て SharePoint に入れると、容量コストや運用負荷が増えます。オンプレの 1.5TB を丸ごと“捨てずに移す”より、「現役は SharePoint」「保管は別」の二層にした方が、長期で見て失敗しにくいです。
移行の進め方：70万ファイル規模で失敗しないチェックリスト
ツール選定より先に、やるべきことは「減らす」「分ける」「ルール化する」です。実務で効く順にまとめます。
| フェーズ | やること | 成果物 | 失敗パターン |
|---|---|---|---|
| 棚卸し | 重複・不要・古いデータの削除方針を決める | 削除ルール／保管ルール | 「全部必要」で止まる |
| 制約スキャン | 禁止文字・予約名・パス長を洗い出す | リネーム一覧 | 移行中にエラーが出て泥沼化 |
| 情報設計 | サイト分割、ライブラリ分割、命名規約を決める | サイト設計書 | ファイルサーバー階層をそのままコピー |
| 権限設計 | グループで付与し、例外権限を上限付きにする | 権限表 | フォルダー例外が増殖 |
| パイロット | 一部署で実運用を回して課題を出す | 運用ルール（改訂版） | 本番一発勝負で炎上 |
移行前スキャンで必ず出てくる“弾かれる名前”の代表例は、禁止文字（” * : < > ? / \ |）や予約名（CON, PRN, AUX, NUL など）です。 また、URLのパス長（デコード後 400 文字）も深い階層で頻発します。 ここを先に潰すだけで、移行作業の難易度が段違いに下がります。
SharePointに「ファイルサーバーの感覚」を残すなら、守るべき運用ルール
現場の受け入れを考えると、最初から100%メタデータ運用は難しいこともあります。その場合でも、次の“最低限のルール”を決めると、巨大化しても破綻しにくいです。
- 同期は申請制：原則はブラウザー。同期が必要な理由と範囲を明確化
- 例外権限は上限付き：フォルダー継承解除は「月に増やしてよい件数」を決める
- フォルダー階層は浅く：3階層程度を目安に、深掘りは列と検索に寄せる
- 命名規約：長いフォルダー名を禁止し、禁止文字も明文化
- “共有リンク”の棚卸し：誰が、いつまで、どの範囲を共有しているかを定期点検
Dropboxを選ぶ理由はある？比較の軸を表で整理
Dropbox を選ぶべきかは「Dropboxが良い／悪い」ではなく、あなたの組織が何を最優先するかで決まります。判断を速くするための比較軸を並べます。
| 判断軸 | SharePoint＋OneDrive | Dropbox | 現場の判断ポイント |
|---|---|---|---|
| Microsoft 365（Teams/Outlook/Office）との統合 | 強い（標準導線） | 統合は可能だが別サービス感が残りやすい | Teams中心で働くならSharePointが自然 |
| 権限設計の“考え方” | サイト／ライブラリ単位が得意 | フォルダー共有の体験が分かりやすい | 例外権限を増やす文化なら再設計が必要 |
| 同期の運用 | 同期は“絞って使う”前提が安全 | 同期中心の運用を選びやすい | 大量同期が前提なら、設計と運用コストを比較 |
| 容量の考え方 | 共有はテナントプール（1TB+10GB×ライセンス）で詰まりやすい | プラン次第（ここは見積で比較） | 1.5TBを“共有”で置くならコスト差が出やすい |
| ガバナンス（監査・保持・統制） | Microsoft 365の枠で統制しやすい | Dropbox側の管理機能で統制 | 既存のM365運用体制を活かすなら前者 |
実務的な結論としては、すでに Microsoft 365 を中核にしているなら、SharePoint＋OneDrive で統一するメリットは大きいです。ただし、「容量（共有プール）」「同期（全員フル同期しない）」「権限（例外を増やさない）」の3点を守らないと、移行したのに不満が増える状態になりがちです。逆に、この3点を設計で押さえられるなら、70万ファイル級でも十分に現実的な置き換えになります。
最後に：この規模は“設計が9割”
70万ファイルは、ツール操作の問題ではなく、情報設計と運用ルールの問題です。ポイントは「サイト分割で権限境界を作る」「同期を標準にしない」「容量を事前に試算して現役と保管を分ける」。この3点を押さえたうえで移行すれば、ファイルサーバーよりも“探しやすく、共有しやすく、統制しやすい”状態を作れます。
コメント