SharePoint のストレージ使用量を見直すための第一歩 ～自動バージョン管理～

こんにちは。今回のブログ担当は新宅です。今回は SharePoint の管理についての Tips です。

SharePoint のストレージ容量上限 (2025 年 4 月現在)

SharePoint のストレージ容量上限は、一般組織と教育機関とで異なるため、注意が必要です。

Business/Enterprise ライセンスの一般組織の場合

Microsoft 365 Business Basic/Standard/Premium や、Microsoft 365 E3/E5 等をお使いの場合は、下記の容量がテナントの SharePoint ストレージ容量上限として与えられます。なお、Exchange Online や OneDrive for Business でのストレージ容量は、各ライセンス プランの上限に応じて各ユーザーに割り当てられるため、このSharePoint ストレージ容量上限のカウントには含まれません。

1 TB + (10 GB × ライセンス ユーザー数) =  テナントの SharePoint 容量上限
※ SharePoint においては、1 TB は 1024 GB として計算されます。
※ただし、F1/F3 等に含まれる SharePoint Online Kiosk プランは、ライセンス ユーザー数のカウント対象外です。

例として、Microsoft 365 E3 を 100 人、Microsoft 365 F3 を 30 人でお使いのテナントでは、このようになります。

1024 GB + (10 GB × 100 人) = 2024 GB → SharePoint の容量上限はほぼ 2 TB
※ F3 の 30 人は SharePoint Online Kiosk プランのため、ライセンス ユーザー数のカウント対象外です。

この例であれば、130 人の共有ストレージとして 2 TB に近い容量が与えられ、これを組織内で共有する形になります。

【参考】SharePoint の制限 – Microsoft Learn

Education ライセンスの教育機関の場合

テナントで使用できる Office 365 / Microsoft 365 系のライセンスの半数以上が Education ライセンスである場合、教育機関のテナントであると見なされてストレージ容量上限の計算方法が変更されるため、容量上限の計算式が異なるものになり、下記の計算式となります。なお、Business/Enterprise ライセンスの一般組織の場合は Exchange Online や OneDrive for Business の容量は別カウントですが、Education ライセンスの教育機関の場合はこれらも含めた容量で使用量がカウントされる点に注意が必要です。

100 TB + (50 GB × 有償 A3 ユーザー数) + (100 GB × 有償 A5 ユーザー数) = テナントの Exchange / OneDrive / SharePoint 合計の容量上限
※ Microsoft 365 においては、1 TB は 1024 GB として計算されます。

例として、教職員向け Microsoft 365 A3 を 50 人、教職員向け Microsoft 365 A5 を 10 人、学生使用特典 (無償) の Microsoft 365 A3 を 1,000 人 でお使いのテナントでは、このようになります。

102,400 GB + (50 GB × 50 人) + (100 GB × 10 人) = 105,900 GB → テナント全体の容量上限は約 103.4 TB
※学生使用特典は無償であるため、ユーザー数のカウント対象外です。

この例であれば、1,060 人の Exchange / OneDrive / SharePoint すべての容量の上限が 103.4 TB ほどになり、これを組織内で共有する形になります。教育機関の場合、1 人のユーザーが OneDrive に 1 TB のデータを置いてしまうと、テナントの 103.4 TB のうち 1 TB を消費することになるため、OneDrive の容量の管理にも注意が必要です。

【参考】Microsoft 365 Education のストレージの変更 – Microsoft

SharePoint の容量カウントの落とし穴

ユーザーが使用していると考える容量よりも、多くのストレージを消費する

通常のローカル PC や NAS などでは、例えば 100 GB の容量があると言われたら、実データで 100 GB 近くのものを置けるはずです。多少の管理領域で消費される分を引いて考えたとしても、空の状態であれば 1 GB のファイルを 98～99 個程度置けると考えるはずです。

しかし、SharePoint はそうではありません。SharePoint には「バージョン履歴」という機能があり、その履歴も容量を消費するからです。

例えば、90 MB のまま容量が変わらない上書き保存を 2 回、その後に 95 MB に増加する上書き保存を 1 回、その後さらに 100 MB に容量が膨らむ編集を 1 回実行して、最新のファイルが 100 MB であるとき、ユーザーが見えているものだけを見て 100 MB 消費していると考えます。ローカル PC の場合、過去のバージョンは上書きされることで過去のバージョンはすべて失われますが、ストレージ消費量は最新分の 100 MB 分のみとなるため、ユーザーの考えと一致します。一方、SharePoint はすべて保持されますが、過去のバージョンのサイズも合計した 465 MB を消費してしまいます。

この例の場合、たったの 5 世代で、ユーザーが考える容量の 4.6 倍もストレージ容量を消費していることになってしまうのです。SharePoint は既定でファイルごとに過去 500 世代までを保持するようになっており、編集回数が多いファイルでは、この例よりもさらに状況が悪化することは想像に難くないと思います。
その結果として、SharePoint のストレージ容量が 100 GB あったとしても、ユーザーから見て 10 GB 程度しか置いていないのに、バージョン履歴で残りの 90 GB を食いつぶしたことが原因で、「ストレージ容量の上限に達したというエラーが出た」という事象が発生することもあります。

一方で SharePoint のバージョン履歴は、ユーザーにとっても有用

PC を使用して作業している人なら、「編集するべきファイルを間違えて元のデータが無い！」とか、「誤って必要な Excel シートをブックから削除したが Ctrl+Z (元に戻す) が効かない！」とか…そういった取返しのつかない、もしくは取り返すためにさらに時間のかかる戻し作業が必要になってしまうようなミスを、誰しもが経験したことがあるはずです。そのような時でも、SharePoint のバージョン履歴によって、「上書き保存」をするだけで過去のバージョンを取っておいてくれるため、3 分もあればいつでも編集を無かったことにできます。このように、うっかり間違えた作業もすぐにリカバリーができるという点で、非常に大きなメリットになります。

さらに SharePoint のバージョン履歴はオフにすることができない

上記の例で、「既定でファイルごとに過去 500 世代までを保持するようになっており」と記載していますが、この設定で過去 100 世代までに減らすことはできても、それよりも小さい数を指定することができません。つまり、上記のようなメリットを捨てることを受け入れて最大限に容量を使う目的で SharePoint のバージョン履歴をオフにすることも叶わないわけです。

社内でも膨らむ SharePoint のストレージ

社内でも古いファイルが増えてきて、それらのバージョン履歴が一生消えることもないので、基本的には右肩上がりの状態が続いていました。じわじわと増え続け、2024 年後半～ 2025 年はじめ頃に 950 GB 程度の使用量に達するような状態になっていました。それでも、過去の古いお客様のファイルなど一部のファイルは、作成されっぱなしではなく最終的に削除されるようなケースもあったので、微増と微減の繰り返しをしつつ、長期的には微増し続けているという状態でした。2025 年 1 月 8 日時点では 940 GB の消費という状況で、問題が発生するまでにはまだ時間がありましたが、いずれ問題が発生することは避けられない状況でした。

新しく登場した自動バージョン管理

最近の変更はしっかりと細かく保存、古い保存は粗めに保存

昨年の秋に新しく登場した自動バージョン管理機能によって、この困った事態を緩和することができるようになりました。
この自動バージョン管理を有効にすると、ユーザーが頻繁に復元する可能性が高い最近の履歴は多く、あまり参照されなくなる古い履歴ほど少なくして保持するようになります。言い換えると、新しい履歴はすべて保持しつつも、古い履歴を間引いていくということですね。

また、間引くのではなく、「○ 日経った履歴はすべて削除」というモードも増えました。

それぞれどのようにバージョン履歴を保持するのかについては、この図をご参照ください。なお、手動での指定はバージョン数は 100 以上の数値、有効期限は 30 日以上の数値でなければなりませんが、カスタマイズすることが可能です。

詳しくは、ドキュメント ライブラリのバージョン ストレージを計画する – Microsoft Learn に記載があります。

注意点

Microsoft Purview (コンプライアンス) の設定で、SharePoint サイトや Microsoft  365 グループにアイテム保持ポリシーにて保持ポリシーを構成している場合、アイテム保持ポリシーが優先されます。そのため、アイテム保持ポリシーを構成しているテナントでは、この設定を行っても古いバージョンが削除されないことがあります。
【参考】データ ライフサイクル管理の詳細 – Microsoft Learn

自動バージョン管理の設定方法 (既定の設定)

新しく Microsoft 365 を使用し始める環境の場合は簡単です。各種 SharePoint サイトや Teams チームを作るよりも前に、SharePoint 管理センターで、下記の通り [バージョン履歴の制限を設定] で [自動] にするだけです。
既存で Microsoft 365 を使用中の環境の場合でも、この設定を適用するのであれば、同様に変える必要があります。なお、この時点では、本設定を変えてから作られた SharePoint サイトや Teams チームにのみ適用されます。

自動バージョン管理の設定方法 (既存の SharePoint サイトに対する構成)

既存の SharePoint サイトや Teams チームには適用されないため、個別に [自動] に切り替える処理が必要です。
すべての既存の SharePoint サイトに適用する場合は、SharePoint PowerShell の導入と接続を完了させた後、下記の PowerShell コマンドを実行することで対応可能です。
※本記事はあくまでも情報提供を目的としています。本記事に記載されている内容を閲覧者がご自身で実行された結果については、自己責任でお願いいたします。

Get-SPOSite | Set-SPOSite -InheritVersionPolicyFromTenant

【参考】サイトのバージョン履歴の制限を変更する – Microsoft Learn

この設定を行うと、それ以降に編集されたファイルについて、上書き保存されたときに、古く不要なバージョンが徐々に削除されていくはずです。上書き保存されないファイルについては、過去に保持されたバージョン履歴はそのまま保持され続けます。

既存のファイルのバージョン履歴をすべて自動バージョン管理に準拠させる方法

上書き保存されない古いファイルについても、すべて自動バージョン管理に準拠させることでバージョン履歴のデータを減らしたい (= トリミングしたい) 場合は、下記の PowerShell コマンドを実行することで対応可能です。
※複数回実行はしないでください。
※本記事はあくまでも情報提供を目的としています。本記事に記載されている内容を閲覧者がご自身で実行された結果については、自己責任でお願いいたします。

Get-SPOSite | New-SPOSiteFileVersionBatchDeleteJob -Automatic

コマンドの実行に成功すると、SharePoint Online サービス側にバックグラウンド ジョブが作成されます。言い換えると、コマンドが終了したように見えても、実際に古いバージョンのトリミングが終了したわけではありません。大きな SharePoint サイトがあったり、多数の SharePoint サイトがあるようなケースでは、全体の完了までには数日掛かることがあります。進行状況を確認する場合は、下記の PowerShell コマンドを実行することで確認可能です。

Get-SPOSite | Get-SPOSiteFileVersionBatchDeleteJobProgress

これによりストレージの削減が可能に

これによって、環境によっては最大で 7 割程度、使用量を削減できるのではないかと思います。

実例として、前述の 940 GB 程あった社内の SharePoint ストレージ使用量も、適用後はぐっと下がり 472 GB 程度になりました。つまり、弊社の場合、約半分が不要な古いバージョン履歴に占められていたということです。

まとめ

現状 SharePoint のストレージ使用量にお困りであっても、そうでなくとも、組織のコンプライアンス要件で回避できない事情があるのでない限りは、この自動バージョン管理の設定をすることをお勧めしています。実際の効果としては、使用状況にも多少左右されるところではあると思いますが、私個人の意見としては、あまり潤沢ではない SharePoint サイトの容量を少しでも有効に活用する上でほぼ必須と言える設定だと考えているところです。

本記事を最後まで御覧いただき、ありがとうございました。
ちなみに、次回のブログ記事の内容は未定ですが、当分先になるかと思いますので、それまでには何か考えておきます。