SharePointリストが5,000件未満でも表示できないとき、しきい値を超えるフィルターを見直す

SharePointのLVTエラーは一覧件数だけでは判定できません。viewが処理する行やfilter・sort・group・lookupの条件を確認して、負荷を減らす方法を探します。

AIものさし編集部

SharePointの一覧でしきい値エラーが出ても、表示結果が5,000件未満だからといって、原因がリスト件数以外にあるとは限りません。List View Threshold(LVT)は、画面に最後に表示される件数だけを見る制限ではなく、ビューのqueryが処理する対象や操作にも関係します。まずリスト全体の件数と、ビューが最初に使うfilter、sort、group、lookup等を分けて確認します。

列をindex化したのにエラーが続く場合は、filterに含めたindex列の数だけで判断しないでください。Microsoftのview filtering資料では、queryはfilter式の最初のindexed columnを使って候補を絞り、残りの条件をその後に適用します。最初のindexが多くの行を返すなら、最終結果が少なくてもqueryがしきい値を超える可能性があります。SharePoint OnlineとSharePoint Serverでは変更できる管理設定が異なるため、Onlineで管理者設定を変えれば解決するという前提を置きません。

最初に確認する情報

エラーが出るviewを開き、以下を記録します。

  • Site URL、list/library名、view名、エラー全文。

  • リスト全体のアイテム数と、viewで返る想定件数。

  • filterの列、順序、operator(AND / OR)、条件値。

  • Sort、Group、Totals、表示列の設定。

  • Lookup、Person/Group、Managed Metadataなどの列が、filter・sort・表示列のどこに含まれるか。

  • SharePoint OnlineかSharePoint Serverか、利用者の権限。

5,000はList View Thresholdの代表的な値ですが、OnlineかServerか、viewの操作や列の種類によって失敗する条件は違います。リストの総数だけで「しきい値以下だからLVTではない」と判定せず、実際にエラーとなるviewの設定を調べます。

Filterの先頭条件を見直す

Filterに複数条件がある場合、最初に使われるindexed columnが、候補を十分に減らす列になっているか確認します。たとえば、全件のうち特定の状態が少数なら、Statusのようなindexed columnを最初の条件として候補を絞り、その後に詳細条件を加える構成を検討します。Filterの画面上の並びとSharePointが実際に評価するqueryは、すべての環境で単純な見た目どおりとは限らないため、変更後はviewを開いて結果を確認してください。

Microsoftの例では、indexed columnの候補を最初に絞るAND条件が、大きなlistで有効な形として説明されています。これに対し、OR条件は候補集合を広げやすく、別の列の値も含めるために全体をscanする可能性があります。ORが必要な検索条件を勝手に削除するのではなく、必要な結果を保ったまま、より選択的なindexed filterを前段に置けるか検討します。

Filter設計の比較例

  • 広い条件:Category = A OR Owner = B。どちらかに当てはまる項目を広く探すため、処理候補が多くなり得ます。

  • 絞り込み条件:Indexed Status = Active AND Category = A。先にActiveの候補へ絞った後、Categoryを適用する考え方です。

  • さらに条件が必要な場合:Indexed Status = Active AND (Category = A OR Category = B)。上位のindexed conditionで候補を減らし、残りの条件で必要な2分類を選びます。

これはqueryの考え方を示す例であり、任意の列で同じ結果になる保証ではありません。Statusの分布やindex作成状態、列型、実際のview queryを見て判断してください。先頭indexed filterだけでしきい値を超える件数を返していないかが重要です。

Indexだけでは解決しない列と操作

Lookup列はindexを作成できる場合がありますが、Microsoft Supportはindexed lookup columnをList View Thresholdの回避に使うことはできないと説明しています。People/GroupやManaged Metadataの列も、sortや多数表示する列の組み合わせで問題になる場合があります。どの列型が原因かを決めつけず、まず一時的に対象列をviewから外す、sort/group/totalsを外すなど、影響の小さい比較を行います。

診断時は一度に多くの設定を変えません。以下の順に、一つずつ差を見ます。

  1. 元のview設定を記録または複製して戻せる状態にする。

  2. Filterの先頭indexed columnと、その候補件数を確認する。

  3. 不要なsortを外して再表示する。

  4. GroupとTotalsを一時的に外す。

  5. Lookup / Person / Managed Metadata列を表示列から減らし、結果を比べる。

  6. Filterを選択的なAND条件に組み替え、必要なデータが残るか確認する。

  7. 利用者が必要とする列と件数を保ったまま、最終viewをテストする。

Microsoftの大規模list向け資料は、sortを外す、groupを外す、Totalsを外す、必要な列だけ表示する方法を案内しています。すべてのviewで4項目を無条件に削除するのではなく、どの操作が原因かを比較し、必要な情報を保った形で修正します。

変更前後の検証

Filterを変えてエラーが消えても、必要な行まで除外してしまえば解決ではありません。viewを使う人の権限で、次の点を確認します。

表は横にスクロールできます

確認変更前変更後
表示できるかエラー全文と発生時刻同じ利用者・同じlistで正常に開くか
対象範囲必要なstatus/category/期間必要な項目が欠けていないか
sort/group元の並びと集計必要な並び・集計が維持されるか
列利用者が必要とする列lookup等を減らしても作業できるか
再現性対象件数・filter条件再読み込みや別利用者でも安定するか

一つずつ設定を変更して結果を記録します。Filterを緩めた結果、必要な行が見つからなくなっていないか、また逆に範囲を広げて負荷を増やしていないか確認してください。個人viewだけで成功した場合は、他の利用者や共有viewでも同じとは限りません。

SharePoint OnlineとServerの違い

SharePoint Onlineでは、LVTの値をサイト所有者が自由に変更して回避する手順を前提にしません。Microsoftの資料は、Onlineの大きなlistではindex、filter、folder、検索などを用いて処理対象を管理する方法を案内しています。SharePoint Serverには、Farm administratorが設定できるresource throttlingやoff-peakのDaily Time Windowなど、Onlineと異なる管理機能があります。記事や管理者の説明に「thresholdを上げればよい」と書かれていても、対象環境がServerかOnlineか確認してから扱います。

Listの中に5,000件より少ない行しかない場合でも、利用している列型、query、view操作、リサイクルビン内の項目、権限や一時的なservice状態を確認します。公式資料の説明範囲外の条件は、環境固有要因として管理者へ照会してください。Community投稿や第三者の回避策だけを根拠に、内部APIや権限設定を変更しません。

Site owner / 管理者へ渡す情報

viewの所有者だけではindex作成や列変更ができない場合、次をまとめます。

  • Site URL、list/library名、view名、SharePoint Online/Serverの区別。

  • エラー全文、発生時刻、利用者の権限。

  • リスト総件数とviewの想定結果件数。

  • Filter列と順序、AND/OR、sort/group/totals、表示列。

  • 対象列の種類とindex状態。

  • 変更した設定と、各変更後に再現したか。

  • 欠落してはいけない項目、業務上必要な並び・列。

アクセスtoken、個人情報を含むデータ行、機密のsite内容は、必要な権限と保管先を確認せずに添付しないでください。管理者が確認すべきなのは、特定列のindex状態、Online/Serverの違い、listの運用状態です。

次にすること

  1. エラーが出るviewとSharePoint Online/Serverを特定する。

  2. Filterの先頭indexed columnと候補件数を確認する。

  3. AND/OR、lookup列、sort、group、totals、表示列を一つずつ切り分ける。

  4. 必要な行を保持した最小のview変更を試す。

  5. 同じ利用者・viewで読み戻し、必要情報が欠けていないことを確認する。

5,000未満という表示結果だけでは、queryが問題ないと証明できません。列をindex化しただけでも解決とは限らないため、viewがどの順で候補を絞るかを実際の設定で確認してください。

公式Sources

Checked: 2026-10-15

Editorial Note: Microsoft公式資料に基づく一般的なview診断ガイド。特定listのindex状態、権限、query実行結果は未確認。