SharePoint のリスト／ドキュメント ライブラリで「5,000 件」の制限に当たると、上限を引き上げたいと考えがちです。しかし多くの環境では“上限変更”よりも、インデックスとビュー設計で「5,000 件を超えても快適に扱える構成」に寄せる方が、安定して再現性の高い解決になります。
SharePoint の「リスト ビューしきい値（List View Threshold）」とは
リスト ビューしきい値（List View Threshold / LVT）は、SharePoint が大量データに対する“重い検索・並び替え・集計”を実行したときに、サーバー側の負荷が急増して全体が遅くなるのを防ぐための仕組みです。多くの場面で「5,000 件」が意識され、条件次第ではエラー表示や操作の制限として現れます。
ここで重要なのは、問題になるのが「リストの総件数」そのものではなく、1 回の操作（クエリ）が参照・処理しようとする件数だという点です。例えば 10 万件のリストでも、インデックス列で適切に絞り込めば、日常操作は問題なく行えます。一方で、絞り込みや並び替えの条件が不適切だと、実際の表示は 30 件でも、裏側では 5,000 件を超える範囲を走査してしまい、しきい値に当たります。
| よくある誤解 | 実際のところ | 対処の方向性 |
|---|---|---|
| リストが 5,000 件を超えたら使えない | 総件数が多くても、クエリが適切なら運用可能 | インデックス列＋ビューの絞り込みを設計する |
| 表示件数を 100 件にすれば大丈夫 | 表示件数より“走査件数”が問題になる | 最初から 5,000 件未満に絞れる条件を作る |
| フィルターすれば何でも回避できる | インデックスが効く条件でないと回避できないことがある | フィルター対象列をインデックス化し、条件を見直す |
しきい値は引き上げられる？SharePoint Online と SharePoint Server の違い
結論から言うと、SharePoint Online（Microsoft 365）では、運用上「5,000 件のしきい値を引き上げる」前提の構成は基本的にできません。SharePoint Online は、共有基盤で全テナントの性能を守るための制御（リソース調整）が強く働き、しきい値を自由に変更できない設計になっています。
一方、オンプレミスの SharePoint Server では、管理者が中央管理（Central Administration）から Web アプリケーション単位でしきい値設定を変更できます。ただし、Microsoft 自身も「性能劣化のリスクがあるため推奨しない」旨を明確にしており、恒常運用での引き上げは慎重に判断すべき領域です。必要がある場合でも、恒常的に上げるより、オフピーク時に一時的に制限を緩める「Daily Time Window（デイリー タイム ウィンドウ）」を検討するのが現実的です。
| 環境 | しきい値の変更 | できること | 推奨スタンス |
|---|---|---|---|
| SharePoint Online（Microsoft 365） | 不可（運用として引き上げ前提にできない） | インデックス／フィルター／フォルダー／検索導線などで回避 | 設計で回避（“5,000 を超えても扱える形”） |
| SharePoint Server（オンプレ） | 可（管理者が中央管理から変更可能） | しきい値変更、監査/管理者向け高い上限、Daily Time Window など | 基本は回避設計。変更は最終手段で小さく・短く |
なぜ「上限を上げる」が危険なのか
しきい値は、単なる意地悪な制限ではなく、SharePoint が裏側で利用するデータベース処理の負荷を抑えるための“安全装置”です。上限を上げれば、その瞬間は「見える／動く」ように見えても、次のような副作用が出やすくなります。
- 同時アクセス時に全体が遅くなる（他のユーザーの操作まで巻き込む）
- 重いビューが常態化して改善が進まない（“上げれば良い”運用が定着する）
- 大規模データほどトラブル時の復旧が難しくなる（削除・移動・権限変更なども重くなる）
特に SharePoint Online は共有基盤であるため、特定サイトだけ都合よく上限を上げる、といった運用が成立しづらい設計です。結果として、“しきい値を引き上げたい”という要求は、ほぼ必ず「情報設計と導線の改善」に置き換える必要があると考えた方がスムーズです。
現実的な解決策の基本は「インデックス列＋フィルター（ビュー設計）」
5,000 件問題の王道は、次の 2 点をセットでやり切ることです。
- よく使う列にインデックス（索引）を付ける
- インデックス列を使って、常に 1 ビューあたりの対象件数が 5,000 件未満になるように絞る
インデックス列を付けるべき列の選び方
インデックスは何でも付ければ良いわけではありません。インデックスは検索を速くする一方で、追加・更新時に“索引の更新コスト”がかかるため、付けすぎると逆に運用が重くなります。Microsoft も「最大 20 列まで作れるが、必要な列に絞るべき」と明確に述べています。
実務で失敗しにくい選び方は次の通りです。
- 利用者が日常的に絞り込みに使う列（状態、年度、部署、カテゴリ、担当者、作成日など）
- 分布が偏りすぎない列（全部が「未着手」などだと絞れない）
- “運用上の導線”に組み込みやすい列（年度別ビュー、部門別ビューなど）
| 用途 | おすすめのインデックス候補 | ビュー設計例 |
|---|---|---|
| 申請・稟議 | 年度、部署、ステータス、申請日 | 年度×ステータス別、部署別、直近 30 日 |
| 問い合わせ管理 | ステータス、受付日、カテゴリ、担当者 | 未完了のみ、担当者別、月別 |
| ドキュメント | 作成日、更新日、部門、分類（メタデータ） | 年度フォルダー＋部門メタデータ、更新日順 |
注意点：ルックアップ列（Lookup）をインデックスにしても、しきい値回避としては期待通りに効かないケースがあります。まずはテキスト・数値・日付などの“基本型”の列を主軸にし、ルックアップは補助的に使う設計が安全です。
インデックスの作り方（サイト所有者・リスト管理者ができる範囲）
操作の流れはシンプルです。リスト／ライブラリの設定から「Indexed columns（インデックス列）」を開き、対象列のインデックスを作成します。環境によって UI 名称は多少異なりますが、基本は共通です。
- 対象のリスト／ライブラリを開く
- 設定（歯車）から「リストの設定／ライブラリの設定」を開く
- 「列」セクションの「インデックス列（Indexed columns）」を開く
- 「新しいインデックスを作成」から、よく使う列をインデックス化する
- 必要に応じて、複合インデックス（主列＋副列）も検討する
“複合インデックス”は、例えば「年度で絞って、同時に作成日で並び替える」といったビューで効果が出やすい考え方です。ただし、複合化すれば何でも解決するわけではないので、まずは最初の絞り込み条件を強くする（＝年度・部署などで件数を大きく減らす）方が再現性は高いです。
ビューのフィルターを「インデックス列」中心に組むコツ
インデックスを付けても、ビューの条件が噛み合っていなければ効果が出ません。実務で効きやすい“設計のコツ”を、具体的な判断軸に落とします。
| やりたいこと | 効きやすい設計 | つまずきやすい設計 |
|---|---|---|
| 年度別に一覧したい | 年度（インデックス）でフィルターし、各年度ビューを用意 | 全年度を 1 ビューで並び替えだけで探す |
| 担当者ごとに見たい | 担当者（インデックス）＋ステータス（絞り込み） | 担当者を列表示だけして、検索は手動 |
| 最新を追いたい | 作成日/更新日（インデックス）で「直近 30 日」など期間を固定 | 全件を更新日でソートし、延々スクロール |
| カテゴリで探したい | カテゴリ（インデックス）＋サブカテゴリは二段階フィルター | 複数カテゴリ OR 条件でまとめて絞る |
“全部を一覧表示”の代わりに、「入口となるビューを複数用意する」のが現実解です。例えば「年度別」「部署別」「未完了のみ」「自分の担当」など、利用者の行動パターンに合わせてビューを分けると、迷わず・しきい値にも当たりにくくなります。
モダン体験の「自動インデックス」を理解しておく
モダン SharePoint では、保存済みビューでの並び替え・フィルターや、モダン画面での並び替え操作を契機に、インデックスが自動作成されるケースがあります。ただし、自動化には条件があり、特にモダン画面での並び替えに伴う自動インデックス作成は、アイテム数が 20,000 未満のリスト／ライブラリに制限されます。20,000 を超える場合は、インデックスがバックグラウンドで作成され、その間「Indexing in progress（作成中）」の表示が出ることがあります。
ここでのポイントは、自動化を“保険”として理解し、運用で重要な列は最初から手動でインデックス設計しておくことです。自動インデックスは「利用者が頻繁に使う列」とズレることもありますし、作成タイミングをコントロールしにくいからです。
さらに安定させる設計案：分割・アーカイブ・検索導線
インデックス＋ビュー設計で多くは解決しますが、業務要件によってはそれだけでは足りないこともあります。次の施策は、長期運用の“詰まり”を避けるうえで効果的です。
リスト／ライブラリの分割（年度別・部門別・プロジェクト別）
「どう頑張っても 1 年で数万件増える」「部署ごとに完全に別運用」などの場合、リストを 1 つに集約し続けること自体が、将来の運用コストを押し上げます。分割は一見面倒ですが、次のようなメリットがあります。
- 各リストの“現役データ”が小さくなり、ビューが安定する
- 権限管理（部署別閲覧など）が整理しやすくなる
- バックアップ／移行／棚卸しの単位が分かりやすくなる
分割の単位は「利用者が自然に理解できる切り口（年度・組織・案件）」が鉄則です。逆に「A〜M と N〜Z」のような人工的な分割は、教育コストと誤登録が増えやすいので注意が必要です。
古いデータをアーカイブして“現役”を軽くする
「全件を常に見たい」のではなく、「現役（直近 1〜2 年）を快適に扱いたい」ケースは多いはずです。その場合は、次のように“置き場所”を分けると運用が安定します。
- 現役リスト：直近年度のみ（例：今年度＋前年度）
- アーカイブ：年度ごとに別リスト／別ライブラリ／別サイトに保管
検索導線（サイト検索）を整えておけば、過去データも「見つけられる」状態を維持しつつ、日常操作は軽くできます。
フォルダー運用（特にドキュメント ライブラリ）を“使いどころ限定”で採用する
フォルダーは必須ではありませんが、うまく使うとデータアクセスが効率化します。SharePoint ではフォルダー自体が内部的なインデックスとして機能し、フォルダー単位の表示は、インデックス列で絞り込むのと同程度に高速になり得ます。ただし、フォルダー内の件数が 5,000 を超えると結局しきい値に当たり得るため、「年度フォルダー」「部門フォルダー」など、自然に分散する単位で使うのがコツです。
また、ビューで「フォルダーなしですべて表示（Show all items without folders）」を選ぶ場合は、フォルダーの恩恵を捨てることになるため、インデックスに基づくフィルターが必須になります。
“検索前提”の導線を用意する（一覧で全部見ない）
大量データを「一覧でスクロールして探す」体験は、しきい値以前にユーザー体験としても厳しくなります。SharePoint には、リスト／ライブラリ内検索やサイト検索があり、検索範囲を段階的に広げて探すこともできます。設計としては次を用意すると効果的です。
- まずは現役ビュー（年度・未完了など）に誘導する
- 見つからない時は“ライブラリ内検索”を使う
- 最後は“サイト全体検索”で横断する
Excel / Access など“オフライン分析”に逃がす
「月次で全件を集計したい」「横断の分析が必要」など、そもそも SharePoint のビューではなく分析ツールが向いている要件もあります。Microsoft の案内でも、Excel や Access などにデータを持ち出して分析することで、SharePoint 側の負荷を下げつつ作業効率を上げる選択肢が示されています。日常運用は SharePoint、分析は Excel/Access と割り切ると、5,000 件問題に振り回されにくくなります。
「エラーが出た」時の即効性がある応急処置
すでにビューでエラーが出ている場合、まずは“ビューを軽くする”のが最短です。Microsoft も、しきい値エラーを避けるためのビュー編集として、並び替え・グループ化・集計（Totals）などを外すことを案内しています。
| 症状 | ありがちな引き金 | まずやる応急処置 | 根本対策 |
|---|---|---|---|
| 「5,000 件を超えたため禁止」系の表示 | 非インデックス列でのソート／集計／グループ化 | ソート/グループ/合計を外す、表示列を減らす | インデックス列の追加、ビューの条件再設計 |
| フィルターしても改善しない | フィルター列がインデックスでない／条件が効きにくい | 絞り込み条件を「年度」など強い列に変更 | インデックス設計を見直し、入口ビューを増やす |
| 特定の列でソートするとエラー | 人/グループ、ルックアップ、メタデータ系でのソート | ソート対象をテキスト/数値/日付系に変更 | 設計上“並び替えたい列”をインデックス＋代替列で用意 |
また、列の種類によっては、ソートや表示列数が増えるほどしきい値エラーのきっかけになることがあります。特に人/グループ列、ルックアップ列、管理メタデータ列などは、ビューを“盛りすぎない”ことが安定運用につながります。
実例：5 万件の「申請一覧」を“5,000 件の壁”なしで運用するビュー構成
例として、申請データが年間 2 万件以上増え、数年で 5 万件を超える「申請一覧」リストを想定します。列は次のような構成です。
| 列名 | 型 | 役割 | インデックス推奨 |
|---|---|---|---|
| 年度 | 数値/テキスト | データ分割の軸（最重要） | ◎ |
| 部署 | 選択肢/テキスト | 閲覧単位・担当分け | ◎ |
| ステータス | 選択肢 | 未処理の抽出 | ○ |
| 申請日 | 日付 | 期間抽出・直近表示 | ○ |
| 申請者 | 人/グループ | 本人確認 | △（補助） |
このリストで“全部一覧”を維持しようとすると高確率で詰まります。そこで、デフォルトビューを「現役に自然に収束する」よう設計します。
| ビュー名（例） | フィルター（例） | 狙い |
|---|---|---|
| 今年度：未完了 | 年度＝今年度 AND ステータス≠完了 | 日常の処理対象だけを出す（最優先導線） |
| 今年度：部署別 | 年度＝今年度 AND 部署＝（各部署） | 部署単位での確認を高速化 |
| 直近 30 日 | 申請日＝直近 30 日 | “最近のものだけ見たい”需要を吸収 |
| 自分の申請 | 申請者＝自分 AND 年度＝今年度 | 利用者のセルフサービス導線 |
| 過年度（アーカイブ入口） | 年度＝前年度（など） | 必要時だけ過去に入る（常用しない） |
ポイントは、「年度」など“強く絞れるインデックス列”を全ビューの先頭条件として使うことです。これにより、リスト総件数が増えても、日常的にアクセスするビューは常に小さく保てます。さらに、過年度のデータを別リスト／別サイトへ段階的に退避すれば、現役リストはほぼ固定サイズで運用できます。
SharePoint の 5,000 件問題を“設計で解く”ためのチェックリスト
最後に、実務で抜け漏れが出やすいポイントをチェックリストにまとめます。
- 利用者が「どう探すか」を言語化した（年度／部署／ステータス／担当者など）
- よく使う絞り込み列にインデックスを付けた（付けすぎていない）
- 入口ビューを複数用意し、1 ビューの対象件数が自然に小さくなるようにした
- ソート／グループ化／集計／表示列数を“盛りすぎ”ていない
- 過年度の扱い（アーカイブ、分割、検索導線）が決まっている
- モダンの自動インデックスは“保険”として扱い、過信していない
「しきい値を上げたい」という相談の多くは、実は「情報設計（どう絞るか）」「導線設計（どのビューから入るか）」「データの寿命（アーカイブするか）」の 3 点を固めることで解消できます。まずはインデックスとビューを整え、必要に応じて分割・アーカイブを組み合わせるのが、SharePoint を長く安定して使うための最短ルートです。
コメント