--- title: "SharePointの容量確認と削減｜計算式・PowerShell・バージョン履歴の設定手順" url: "https://www.issoh.co.jp/tech/details/19240/" published: 2026-11-03 updated: 2026-11-03 categories: ["プラットフォーム"] publisher: "株式会社一創" --- # SharePointの容量確認と削減｜計算式・PowerShell・バージョン履歴の設定手順 SharePointの容量は、組織全体で「1TB＋購入ライセンス数×10GB」の1つの枠を全サイトで分け合う仕組みです。社員100名の会社なら約2TBで、どのサイトがどれだけ使っているかは管理センターのアクティブなサイト画面で確認できます。ただし、表に見えているファイルの合計と使用量が合わないことはよくあります。原因の多くは、保存のたびに溜まるバージョン履歴、ごみ箱、保持ポリシーで残る版です。この記事では、容量の計算式、管理センターとPowerShellとGraph APIでの容量確認の手順、バージョン履歴の制限設定と既存の版を削るトリミングジョブ、容量を買い足すか削るかの判断を、Microsoft Learnの記載とコード例で整理しました。 ## まとめ：SharePointの容量は内訳を見てから版の上限で削るのが先決 容量の上限は「1TB＋10GB×購入ライセンス数」で決まり、超えると組織全体が読み取り専用になる危険があります。使用量は管理センターの「アクティブなサイト」右上で確認でき、サイト別の一覧はPowerShellの `Get-SPOSite` かGraph APIで定期的に出力できます。管理センターの数値は直近24〜48時間の変更を含まない点に注意してください。 削る順番は、バージョン履歴が先です。組織の既定はメジャーバージョン500版で期限なしのため、頻繁に上書きされる大きなファイルが容量を食います。既定を「自動」に変えても既存のライブラリと既存の版には効かないので、使用状況レポートで影響を見積もってからトリミングジョブで削る手順が必要です。削減しても足りない場合に限り、追加容量を買う判断に進みます。 ## 組織の容量を計算式で出す：1TB＋10GB×ライセンスとOneDriveの扱い ### 購入ライセンス数から総容量を出す計算式と2の30乗バイトの単位 Microsoft Learnの[SharePoint の制限](https://learn.microsoft.com/ja-jp/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits)（2026年10月6日更新）によると、Microsoft 365 Business（Basic・Standard・Premium）、Microsoft 365 E3・E5、Office 365 E1・E3・E5の組織あたりの総容量は「1TB＋購入したライセンスあたり10GB」です。100名分のライセンスなら1TB＋1TBで2TB、30名なら1TB＋300GBで約1.3TBになります。 容量を換算するときは、単位にも注意が必要です。SharePointのストレージは1GB＝2の30乗バイトのバイナリGBで計算されます。Graph APIなどでバイト値を取得してGBに直すときは、1,000の3乗ではなく1,024の3乗で割らないと、管理センターの表示と数値がずれます。1つのサイトに割り当てられる上限は25TB、1ファイルのアップロード上限は250GBです。 ### F1・F3の数え方と個人のOneDriveが組織の枠に入らない理由 現場担当者向けのMicrosoft 365 F1・F3、Office 365 F3は、ライセンス数にかかわらず組織全体で1TBです。F系を数百名分買っても容量は増えないため、総容量の計算にはBusinessやE系のライセンス数だけを入れます。 ライセンスを持つユーザーごとに作られるOneDriveは、この計算に含まれません。個人のOneDriveは別枠で、SharePointのチームサイトとは容量の数え方が分かれています。どちらにファイルを置くべきかという運用ルールは[SharePointとOneDriveの保存先の決め方](https://www.issoh.co.jp/column/details/18754/)で整理しています。 ### 総容量を超えたとき組織全体が読み取り専用になる流れと猶予措置 総容量を超えた状態が続くと、テナントが読み取り専用モードになるおそれがあります。利用者はファイルの追加も変更もできなくなり、使用量を減らすか容量を追加するまで解除されません。公式の脚注では、追加容量やライセンスの購入後に「購入の確認」を選ぶと、新しい容量が反映されるまで最大14日間だけ読み取り専用を外せるとされています。この措置は365日に1回しか使えません。 つまり、超過してから慌てて買うと、猶予を1年に1回しか使えないうえに業務が止まる時間が出ます。使用率が80〜90%に達した時点で次の章の手順で内訳を見て、削るか買うかを決めておく運用が安全です。追加容量の単価とアーカイブの料金は[SharePointの料金と追加容量の費用](https://www.issoh.co.jp/column/details/18760/)にまとめています。 ## SharePoint管理センターで組織とサイトごとの使用量を確認する手順 ### アクティブなサイト画面の記憶域バーで総量と残量を確かめる手順 組織全体の容量確認は、[サイト ストレージの制限を管理する](https://learn.microsoft.com/ja-jp/sharepoint/manage-site-collection-storage-limits)の手順どおり、SharePoint管理者以上のアカウントで行います。 1. SharePoint管理センターを開き、左のメニューから「サイト」の「アクティブなサイト」を選ぶ 2. 画面右上の記憶域バーで、使用可能な容量とサブスクリプションの総容量を読む 3. 一覧の「使用済みストレージ」列で並べ替え、使用量の多いサイトから確認する 表示される使用量には、直近24〜48時間の変更が反映されていません。大量に削除した直後に数値が減らなくても、翌々日まで待ってから判断してください。ごみ箱にある削除済みのサイトは組織の使用量に数えられませんが、サイトの中のごみ箱に入ったファイルは数えられます。この違いは後の章で扱います。 ### サイト所有者が記憶域メトリックスでフォルダ単位の内訳を見る方法 管理センターに入れないサイト所有者でも、自分のサイトの内訳は「記憶域メトリックス」で確認できます。サイト右上の歯車から「サイト情報」を開き、「すべてのサイト設定の表示」を選んで、「サイト コレクションの管理」の下にある「記憶域メトリックス」を開きます。 この画面はライブラリ、フォルダー、ファイルの順に掘り下げられ、どの階層が容量を使っているかを上から順に追えます。ファイルの見た目のサイズに比べて合計が極端に大きいライブラリは、バージョン履歴の見直し対象です。サイトの容量が上限に達した場合、同じ画面右上の「追加のクォータを要求」から管理者へ要求メールを送れます。 ### サイトのストレージ制限を自動から手動へ切り替える判断と通知設定 既定では、すべてのサイトが中央のプールから必要な分だけ容量を使う「自動」です。管理センターの「設定」から「サイトのストレージ制限」を「手動」に変えると、サイトごとにGB単位で上限を設定し、上限に近づいたときにサイト所有者へメールを送れるようになります。 手動に切り替えるのは、特定の部署が容量を独占しそうな場合に限ります。部署が10を超えると上限値の管理そのものが手間になり、上限に達したサイトから毎週のように増枠依頼が来ます。手動から自動へ戻すと、サイトの上限はすべて25TB（25,600GB）に戻る点も覚えておいてください。 ## PowerShellとGraph APIでサイト別の使用量を一覧にして監視する ### Get-SPOSiteで全サイトの使用量をCSVに出すPowerShellスクリプト サイトが数十を超えると、画面での確認は続きません。SharePoint Online管理シェルの[Get-SPOSite](https://learn.microsoft.com/ja-jp/powershell/module/microsoft.online.sharepoint.powershell/get-sposite)で、全サイトの使用量を1本のCSVに出せます。`-Limit` の既定は200件なので、全件を取るには ALL を指定します。 ``` # SharePoint Online 管理シェルで実行（SharePoint管理者以上） Connect-SPOService -Url https://contoso-admin.sharepoint.com # StorageUsageCurrent と StorageQuota は MB 単位。1024 で割って GB に直す Get-SPOSite -Limit All | Select-Object Url, Title, @{ Name = 'UsedGB'; Expression = { [math]::Round($_.StorageUsageCurrent / 1024, 1) } }, @{ Name = 'QuotaGB'; Expression = { [math]::Round($_.StorageQuota / 1024, 1) } } | Sort-Object UsedGB -Descending | Export-Csv .\spo-storage.csv -NoTypeInformation -Encoding UTF8 ``` クォータの値がMB単位であることは、Set-SPOSiteの例（`-StorageQuota 1024` が1GB）で確かめられます。既定では個人のOneDriveは返らないため、出力されるのはチームサイトとコミュニケーションサイトの一覧です。月1回このCSVを残しておけば、前月比で急に増えたサイトをすぐ見つけられます。 ### Graph APIのquotaで残量の状態を取りnearingで通知する実装 監視を自動化するなら、Microsoft Graphのドライブに付いている[quota](https://learn.microsoft.com/en-us/graph/api/resources/quota?view=graph-rest-1.0)を読みます。サイトの既定のドキュメントライブラリに対して、次のように quota だけを選んで取得します。 ``` GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive?$select=quota Authorization: Bearer {token} // 応答例（値はバイト単位） { "quota": { "deleted": 1073741824, "remaining": 96636764160, "state": "nearing", "total": 1099511627776, "used": 1002874863616 } } ``` state は normal・nearing・critical・exceeded の4値で、残量が総量の10%を切ると nearing、1%を切ると critical になります。deleted はごみ箱のファイルが使っている量です。nearing を検知した時点でTeamsやメールへ通知する仕組みにすれば、読み取り専用になる前に手を打てます。アプリ登録とアクセス許可の付け方は[Microsoft Graph APIの権限設計と呼び出し手順](https://www.issoh.co.jp/tech/details/18719/)を参照してください。 ### 使用状況レポートAPIで全サイトの使用量を日次でCSVに取る方法 全サイトの数値をまとめて取るなら、[getSharePointSiteUsageDetail](https://learn.microsoft.com/en-us/graph/api/reportroot-getsharepointsiteusagedetail?view=graph-rest-1.0)が向いています。必要なアクセス許可は Reports.Read.All で、期間は D7・D30・D90・D180 から選びます。 ``` GET https://graph.microsoft.com/v1.0/reports/getSharePointSiteUsageDetail(period='D7') Authorization: Bearer {token} // 302 Found の Location にあるダウンロードURLからCSVを取得する // 主な列：Site URL, File Count, Storage Used (Byte), Storage Allocated (Byte), Last Activity Date ``` 応答は302で、事前認証付きのダウンロードURLへ転送されます。このURLは数分で失効するため、取得したらすぐCSVを保存する処理にしてください。Last Activity Date が古いのに Storage Used (Byte) が大きいサイトは、アーカイブか削除の候補として棚卸しに回せます。 ## バージョン履歴が容量を膨らませる仕組みと既定500版の見直し手順 ### 上書き保存のたびに版が残る仕組みと既定500メジャー版の影響 ドキュメントライブラリは、ファイルを保存するたびに以前の状態をバージョンとして残します。[組織の既定のバージョン制限](https://learn.microsoft.com/ja-jp/sharepoint/set-default-org-version-limits)は、メジャーバージョン数500・期限なしの手動設定です。50MBの図面ファイルを毎日上書きする運用なら、版だけで理論上は最大25GB近くまで増えます。 後で示す使用状況レポートでも、各版の Size がバイト単位で記録されています。表に見えるファイルの合計が数百GBなのに使用量が数TBというサイトでは、まず版の総量を疑ってください。共同編集で自動保存が細かく走る Office ファイルほど、版の数が増えやすくなります。 ### 組織既定を自動または件数と期限の手動設定に変える手順とコマンド 管理センターの「設定」から「バージョン履歴の制限」を開くと、「自動」と「手動」を選べます。手動ではメジャーバージョン数を100〜50,000の範囲で指定し、必要なら「この期間を過ぎるとバージョンを削除する」で期限も付けます。画面からは100版未満・30日未満を設定できません。PowerShellでは次のとおりです。 ``` # 自動（版の経過時間に応じて古い版を間引くMicrosoftのアルゴリズム）にする Set-SPOTenant -EnableAutoExpirationVersionTrim $true # 手動：メジャー100版まで、365日を過ぎた版は削除 Set-SPOTenant -EnableAutoExpirationVersionTrim $false -MajorVersionLimit 100 -ExpireVersionsAfterDays 365 # 現在の設定を確認する Get-SPOTenant | Select-Object EnableAutoExpirationVersionTrim, MajorVersionLimit, ExpireVersionsAfterDays ``` 設定に迷った場合の選択肢は「自動」です。[バージョン履歴の制限の概要](https://learn.microsoft.com/ja-jp/sharepoint/document-library-version-history-limits)でもストレージ用には自動が推奨されています。手動で件数を絞るのは、監査や契約上の理由で「何版まで、何日まで残す」を説明できる必要がある部署だけで足ります。 ### 既存ライブラリには効かない落とし穴とサイト単位で同期する方法 ここが一番の落とし穴です。組織レベルの変更は、変更後に作られた新しいライブラリにしか適用されません。既存のライブラリの制限も、既存の版の量も変わらず、新しいライブラリへの反映にも最大24時間かかります。組織の既定を自動にしたのに使用量が減らない、という相談の大半はこれが原因です。 既存のライブラリに新しい制限を入れるには、サイトかライブラリ単位での再設定が必要です。サイト内の全ライブラリの制限をサイトの設定にそろえ、同時に既存の版も削るには `New-SPOSiteManageVersionPolicyJob -Identity $siteUrl -SyncListPolicy -TrimUseListPolicy` をキューに入れます。版の削除は元に戻せないので、実行前に次の章の手順で影響を見積もります。 ## 既存の古い版を削る手順：使用状況レポートからトリミングジョブまで ### サイト内のファイル別に版の使用容量の内訳をCSVで出すジョブの手順 使うコマンドは `New-SPOSiteFileVersionExpirationReportJob` です。削る前に、どのファイルの版が何バイト使っているかをCSVで出します。[バージョン使用状況レポートのチュートリアル](https://learn.microsoft.com/ja-jp/sharepoint/tutorial-generate-version-usage-report)の手順では、レポートの保存先は同じテナントのドキュメントライブラリ内で、同名のファイルが無い場所を指定します。 ``` $siteUrl = "https://contoso.sharepoint.com/sites/sales" $reportUrl = "https://contoso.sharepoint.com/sites/sales/Shared Documents/VersionReport.csv" # レポート作成ジョブをキューに入れる（非同期） New-SPOSiteFileVersionExpirationReportJob -Identity $siteUrl -ReportUrl $reportUrl # 進捗を確認する。status が completed になれば集計できる Get-SPOSiteFileVersionExpirationReportJobProgress -Identity $siteUrl -ReportUrl $reportUrl ``` CSVは1行が1つの版で、FileUrl、MajorVersion、Size、SnapshotDate などの列を持ちます。FileUrl ごとに Size を合計すれば、版が容量を食っているファイルの上位がわかります。サイトの規模によっては完了まで数日かかるため、容量が逼迫する前に走らせておくのが前提です。このレポートには保持ライブラリに入った版も含まれます。 ### 自動・期限・件数の3つのトリムモードの違いと2023年以前の版の扱い [既存のバージョンをトリミングする](https://learn.microsoft.com/ja-jp/sharepoint/trim-versions)には、トリムモードを1つ選んでジョブをキューに入れます。 | モード | コマンドの指定 | 削られる版 | | ------ | ---------------------- | --------------------- | | 自動（推奨） | \-Automatic | 自動制限のアルゴリズムで期限切れになる版 | | 手動・期限 | \-DeleteBeforeDays 90 | 指定日数より古い版（30日未満は指定不可） | | 手動・件数 | \-MajorVersionLimit 50 | 指定した版数を超える古い版 | 期限モードには既知の制限があり、2023年1月1日より前に作られた版は指定日数にかかわらずすべて削除されます。古い契約書の版を残したいライブラリでは、期限モードを使うとその版が消えるため、このモードは選択すべきではありません。サイト単位なら `New-SPOSiteFileVersionBatchDeleteJob -Identity $siteUrl -Automatic`、ライブラリ単位なら `New-SPOListFileVersionBatchDeleteJob` で実行し、`Get-SPOSiteFileVersionBatchDeleteJobProgress` で進捗を追います。 ### トリミングは復元できない：保持ポリシー下の版とバックアップの確認 トリミングジョブで削除した版は、ごみ箱を経由せず完全に削除されます。Microsoft 365 Backupなどで事前にバックアップを取っていない限り復元できません。実行前に確認する項目は次の3つです。 - 使用状況レポートで、削除後に版が10未満になるファイルと影響を受ける利用者を確認したか - 対象サイトに保持ポリシーや電子情報開示の保留が掛かっていないか - 監査や契約で版を残す義務があるライブラリを対象から外したか 保持ポリシーの対象の版は、トリミングジョブでも削除されず有効期限だけが付けられます。ポリシーを外さない限り容量は減らないため、保持の設定を持つ部署とは事前に調整が必要です。 ## ごみ箱と保持ライブラリ：削除しても容量が減らない原因の切り分け ### 第1段階・第2段階のごみ箱の93日の保持期間と削除済みサイトの数え方 ファイルを削除しても、サイトのごみ箱にある間は容量を使い続けます。公式の制限ページも、サイトのごみ箱を監視して定期的に空にするよう勧めています。[SharePoint と OneDrive の保持の詳細](https://learn.microsoft.com/ja-jp/purview/retention-policies-sharepoint)のとおり、第1段階と第2段階を合わせた保持期間は93日です。利用者が第1段階を空にしても第2段階に残るため、即座に容量を空けるにはサイトコレクション管理者が第2段階のごみ箱も空にします。 一方、ごみ箱に入った削除済みのサイトは組織の使用量に数えられません。不要なサイトを丸ごと削除するのは、ファイルを1つずつ消すより効く手段です。Teamsのチームを作るたびにサイトが増える仕組みと、使われないサイトの片づけ方は[TeamsとSharePointの関係と乱立を防ぐ運用](https://www.issoh.co.jp/column/details/18756/)で扱っています。 ### 保持ポリシーで増える保存保持ライブラリと版の上限が無視される条件 Microsoft Purviewの保持ポリシーが掛かったサイトでは、ファイルを編集・削除すると元の内容が非表示の「保存保持ライブラリ」へコピーされます。利用者がファイルを消しても、保持期間が終わるまで中身はサイト内に残ります。さらに保持ポリシーや電子情報開示の保留の対象になっている間は、ライブラリのバージョン制限が無視され、古い版は自動で消えません。 削除しても容量が減らないときは、ごみ箱、保持ポリシー、版の3つを順に疑います。前の章のレポートで保持ライブラリの版が大きければ、原因は保持の設計です。保持期間を必要以上に長くしていないかを、法務や監査の担当と見直してください。 ## 容量を買い足すか削るかの判断基準と監視を仕組み化する運用設計 ### 現行ファイルの使用率で見る削減で足りる場合と追加容量を買うべき場合の境界 判断は、版とごみ箱を除いた「現行ファイルだけの量」で行います。現行ファイルの合計が総容量の70%未満なら、バージョン履歴の制限とトリミングで十分に戻せるため、追加容量は買いません。現行ファイルだけで総容量の90%を超えているなら、削減は時間稼ぎにしかならず、追加容量の購入かアーカイブを検討する段階です。 動画や設計図面のように1ファイルが数GBあり、毎月100GB単位で増えるデータを置いている場合も、SharePointの容量で抱え続けるのは見送ります。保存先をAzure Blob Storageなど別のストレージに分け、SharePointには参照用のリンクだけを置く構成のほうが安く済みます。費用の比較は[SharePointの追加容量とアーカイブの単価](https://www.issoh.co.jp/column/details/18760/)の数値で行ってください。 ### 容量監視を手作業で続けない月次レポートとサイト所有者への棚卸しの仕組み化 容量の問題は、一度削って終わりにはなりません。前の章までのGraph APIの quota と使用状況レポートを月次で取得し、使用率が80%を超えたら通知、最終利用日が180日以上前のサイトは所有者へ棚卸しの確認を送る、という流れをPower Automateかスクリプトで組んでおくと、担当者が替わっても運用が続きます。 当社では、SharePointの容量の棚卸し、バージョン履歴の制限設計、Graph APIを使った監視の作り込みまでを[Microsoft 365・Copilot導入支援](https://www.issoh.co.jp/service/erp%5Fcrm/microsoft365/)としてお受けしています。今のサイト一覧と使用量のCSVがあれば、どのサイトの何を削れば容量が戻るかを具体的にお示しできます。 ## よくある質問 SharePointの容量確認と削減について、管理者とサイト所有者からよく寄せられる質問をまとめました。 ### SharePointの容量はどこで確認できますか？ 組織全体の総容量と残量は、SharePoint管理センターの「アクティブなサイト」画面の右上に表示されます。サイトごとの使用量は同じ画面の一覧で並べ替えて確認できます。一覧を定期的に記録したいときは、PowerShellの Get-SPOSite -Limit All でCSVに出力する方法が手軽です。表示には直近24〜48時間の変更が反映されていません。 ### 一般の利用者でもサイトの容量を確認できますか？ サイトの容量を確認できるのは、サイトの設定を開ける所有者やサイトコレクション管理者です。所有者は「サイト情報」から「すべてのサイト設定の表示」を開き、「記憶域メトリックス」でライブラリやフォルダー単位の内訳を見られます。編集や閲覧の権限しか無いメンバーはこの画面を開けないため、容量の状況は所有者か管理者に確認を依頼してください。 ### ファイルを削除したのに容量が減らないのはなぜですか？ 理由は3つ考えられます。管理センターの数値に24〜48時間の遅れがあること、削除したファイルが第1段階・第2段階のごみ箱に最大93日残ること、保持ポリシーの対象サイトでは中身が保存保持ライブラリへコピーされることです。数日待っても減らない場合は、第2段階のごみ箱と保持ポリシーの設定を確認します。 ### バージョン履歴の上限を下げると既存の版も消えますか？ 組織レベルの設定を変えても、既存のライブラリと既存の版は変わりません。新しい設定が適用されるのは、変更後に作られたライブラリだけです。既存の版を減らすには、サイトかライブラリ単位でトリミングジョブを実行します。トリミングで削除した版はごみ箱に入らず復元できないため、事前に使用状況レポートで影響を確認してください。 ### OneDriveの容量はSharePointの容量に含まれますか？ ライセンスを持つユーザーごとのOneDriveは、SharePointの組織の容量「1TB＋10GB×ライセンス数」には含まれません。OneDriveは利用者ごとの別枠で管理されます。Teamsのチャネルで共有したファイルはチームのSharePointサイトに保存されるため、こちらは組織の容量を使います。 ## 関連記事 - [SharePointの料金｜単体プランの販売終了とMicrosoft 365の実額、追加容量・外注費まで](https://www.issoh.co.jp/column/details/18760/)：容量が足りないときの追加容量・アーカイブの単価。 - [SharePointとは？できること・OneDriveやTeamsとの違いと導入判断の基準](https://www.issoh.co.jp/column/details/18021/)：容量の前提になるSharePoint全体の役割。 - [SharePointとOneDriveの違い｜保存先の決め方と退職時に消えるファイル、Teamsの保存先](https://www.issoh.co.jp/column/details/18754/)：容量の枠が分かれる2つの保存先の使い分け。 - [TeamsとSharePointの関係｜チーム作成で増えるサイトの実体と乱立を防ぐ運用ルール](https://www.issoh.co.jp/column/details/18756/)：容量を食う使われないサイトを増やさない運用。 - [Microsoft Graph APIとは？できること・権限設計とPythonでの呼び出し手順【2026年10月】](https://www.issoh.co.jp/tech/details/18719/)：容量監視をAPIで組むときの認可と呼び出し方。 --- 出典: [SharePointの容量確認と削減｜計算式・PowerShell・バージョン履歴の設定手順]()（株式会社一創）