---
title: "SharePointリストとは？列設計・ビュー・5000件のしきい値とPower Apps連携を実装目線で解説"
url: "https://www.issoh.co.jp/tech/details/18724/"
published: 2026-10-22
updated: 2026-10-22
categories: ["業務システム"]
publisher: "株式会社一創"
---

# SharePointリストとは？列設計・ビュー・5000件のしきい値とPower Apps連携を実装目線で解説

SharePointリストは、行と列で構成された表形式のデータをチームで共有する機能で、Microsoft Listsアプリから開くリストと同じものです。備品台帳や問い合わせ管理なら、Excelの共有ファイルを置き換えるだけで同時編集の衝突がなくなります。ただし、件数が5,000件を超えたあたりからビューが開かなくなる、Power Appsの検索結果が途中で切れる、といった壁があり、作る前の列設計でほとんどが決まります。この記事では、リストの作成手順とGraph APIでの作り方、列の内部名とインデックスの設計、列の書式設定のJSON、Power Appsの委任、そして業務システムへ移す判断の線を、Microsoftの公式ドキュメントの数値に沿って整理しました。

## まとめ：SharePointリストで作れる範囲と業務システムへ移す判断の結論

SharePointリストは、Microsoft 365を契約していれば追加費用なしで使える「共有できる表」です。1つのリストに入る件数の上限は3,000万件と大きく、件数そのものより、1つのビューで扱える5,000件のしきい値と、その手前で設計するインデックスが実務の制約になります。列は作成した時点で内部名が固まるため、英数字の名前で作ってから表示名を日本語に変える手順を最初から決めておきます。

結論として、単一の表で完結し、絞り込み条件が決まっていて、ビューごとの表示が5,000件を超えない台帳ならリストで十分です。逆に、複数の表をまたぐ整合性（在庫の引当や金額の締め処理）が要る業務、項目単位の権限が数千件に及ぶ業務は、最初からDataverseや業務システムで作るほうが安く済みます。

## SharePointリストとMicrosoft Listsの共通基盤と表形式データの構造

### Microsoft ListsとSharePointリストの共通基盤と保存先の違い

Microsoftは[Microsoft 365 のリストとは何ですか?](https://support.microsoft.com/ja-jp/sharepoint/lists/data-and-lists/what-is-a-list-in-microsoft-365)で、リストを「チームのメンバーやアクセス権を与えた人と共有できるデータの集まり」と定義しています。リストはMicrosoft Listsアプリ、SharePointサイト、Teamsのいずれからでも作れ、Power Appsの接続ドキュメントにも「SharePointでリストを作成・表示するとMicrosoft Listsへ自動で切り替わり、同じリストは両方から見える」と書かれています。名前が2つあるだけで、データの置き場所は同じSharePointのリスト基盤です。

違いが出るのは保存先です。SharePointサイトやTeamsのチームで作ったリストはそのサイトに属し、サイトの権限をそのまま引き継ぎます。Listsアプリから「マイリスト」に作ったリストは個人の領域に置かれ、作成者の退職時にデータの持ち主が曖昧になります。業務で使う台帳は、最初から部署のサイトに作るのが原則です。SharePoint全体の位置づけは[SharePointとは何か、OneDriveやTeamsとの違い](https://www.issoh.co.jp/column/details/18021/)で整理しています。

### ドキュメントライブラリやExcelの共有ファイルとの違いと置き換えの判断材料

ドキュメントライブラリはファイルを主役にした入れ物で、リストは行（アイテム）を主役にした入れ物です。公式の説明どおり、ライブラリと違ってリストはサイトを作っても自動では作成されません。必要な台帳ごとに作ります。

Excelの共有ファイルと比べたときの差は、次の3点が大きい部分です。

- 列ごとにデータ型と必須入力を固定でき、日付欄に文字が入る事故を防げる
- 項目単位で更新履歴が残り、誰がいつどの値を変えたかを1件ずつ追える
- 行ごとに閲覧権限を変えられ、Power AutomateやPower Appsの入力元にそのまま使える

逆に、セル同士の計算式を縦横に張り巡らせた集計表は、リストに移すと再現できません。リストの計算列は同じ行の値しか参照できないため、集計はビューの集計行かPower BIに任せる前提で移行範囲を決めます。Excel管理が崩れる条件そのものは[エクセル管理の限界と専用ツールへ移る判断基準](https://www.issoh.co.jp/column/details/11237/)で詳しく扱っています。

## SharePointリストの作成手順：画面の5つの起点とGraph APIでの自動作成

### 画面からの作成：空白・Excel・CSV・既存リスト・テンプレートの選び分け

サイトの「新規」から「リスト」を選ぶと、空白のリスト、Excelから、CSVから、既存のリストから、テンプレートからの5つの起点が出ます。選び方の基準は、列の型をどこで決めたいかです。

1. 新しい台帳を作るなら「空白のリスト」から始め、列を1本ずつ型を指定して足す
2. 既存のExcel台帳を移すなら「Excelから」を選び、取り込み画面で各列の型を確認して直す
3. 部署ごとに同じ構成の台帳を配るなら、雛形を1つ作って「既存のリストから」で複製する

Excelからの取り込みは便利ですが、列の型が推測で決まります。金額が1行テキストとして取り込まれると、あとで数値列に変えられても既存値の扱いで手戻りが出ます。取り込み画面の型の確認だけは飛ばさないでください。

### Graph APIでリストと列を一括作成するリクエスト例と必要な権限

同じ構成のリストを複数のサイトに作るなら、画面操作よりAPIのほうが確実です。[Microsoft Graphのリスト作成API](https://learn.microsoft.com/ja-jp/graph/api/list-create?view=graph-rest-1.0)は、サイトに対して列定義ごとPOSTするだけでリストを作れます。必要なアクセス許可は Sites.Manage.All で、テンプレートを省略すると Title 列を持つ genericList になります。

```
POST https://graph.microsoft.com/v1.0/sites/{site-id}/lists
Content-Type: application/json

{
  "displayName": "案件台帳",
  "columns": [
    { "name": "Status", "displayName": "状態", "indexed": true,
      "choice": { "choices": ["受付", "対応中", "完了"] } },
    { "name": "DueDate", "displayName": "期限", "indexed": true,
      "dateTime": { "format": "dateOnly" } },
    { "name": "Amount", "displayName": "金額", "number": { } }
  ],
  "list": { "template": "genericList" }
}
```

ポイントは name と displayName を分けている点です。name がAPIや数式から参照する名前になり、displayName が画面に出る名前になります。絞り込みに使う状態と期限には、作成時点で indexed を付けています。行の追加は[リストアイテムの作成API](https://learn.microsoft.com/ja-jp/graph/api/listitem-create?view=graph-rest-1.0)で fields に name 側の名前を入れてPOSTし、こちらは Sites.ReadWrite.All が必要です。アプリ登録とアクセス許可の付け方は[Microsoft Graph APIの権限設計と呼び出し手順](https://www.issoh.co.jp/tech/details/18719/)を参照してください。

## 列設計の実装：列の種類・内部名・ルックアップ上限から決める台帳の形

### 台帳の列の種類ごとの使い分けとインデックスを付けられない型の一覧

列の型は、入力の正しさとあとで絞り込めるかの2点で選びます。公式の[インデックスの追加手順](https://support.microsoft.com/ja-jp/sharepoint/data-and-lists/add-an-index-to-a-list-or-library-column)に、インデックスを付けられる型と付けられない型が分かれて載っています。

| 列の型      | 主な用途      | インデックス |
| -------- | --------- | ------ |
| 1行テキスト   | 件名・管理番号   | 可      |
| 選択肢（単一）  | 状態・区分     | 可      |
| 選択肢（複数）  | タグ        | 不可     |
| 数値・通貨    | 数量・金額     | 可      |
| 日付と時刻    | 期限・受付日    | 可      |
| ユーザー（単一） | 担当者       | 可      |
| ユーザー（複数） | 関係者       | 不可     |
| 複数行テキスト  | 経緯・メモ     | 不可     |
| 計算列      | 同じ行の値から算出 | 不可     |

件数が増えると絞り込みに使う列は、インデックスを付けられる型で作る必要があります。担当者を複数選べるようにした結果、担当者で絞るビューが5,000件の壁を越えられなくなる、という失敗はよく起きます。絞り込み軸になる列は単一値で持ち、複数値が必要な情報は別の列に分けてください。

### 作成時に固定される内部名：日本語列名のエンコードと英数字の命名規則

列には画面に出る表示名と、作成時に決まって変わらない内部名があります。表示名はあとから自由に変えられますが、内部名は変わりません。最初に「対応 状況」という名前で作ると、内部名は日本語とスペースがエンコードされた文字列になります。[列の書式設定のドキュメント](https://learn.microsoft.com/ja-jp/sharepoint/dev/declarative-customization/column-formatting)にも、スペースは `_x0020_` に置き換わり、「Due Date」は `$Due_x0020_Date` として参照すると書かれています。

日本語の列名は1文字ずつ `_x30ab_` のような形に化けるため、Power Automateの式やGraph APIのフィルターで読みにくい名前を書くことになります。運用ルールは、列を英数字の名前で作成し、作成後に表示名を日本語へ変える手順です。Graph APIで作るなら、前の章の例のように name と displayName を分けるだけで済みます。

### ルックアップ列は1ビュー12個まで：マスタ参照を増やしすぎない設計

別のリストの値を参照するルックアップ列は、顧客マスタや商品マスタを持つ台帳で便利です。ただし[リストビューのしきい値の解説](https://support.microsoft.com/ja-jp/sharepoint/lists/data-and-lists/list-view-threshold-for-large-lists-and-libraries)によると、1つのクエリで結合できるルックアップ系の列は既定で12個までで、超えた操作はブロックされます。数えられるのはルックアップ列だけでなく、ユーザーまたはグループの列やワークフローの状態列など、結合を伴う列全般です。

担当者・作成者・更新者・顧客・商品・拠点と足していくと、12個は意外と早く埋まります。ビューに出す参照列を用途ごとに絞るか、表示用の値を1行テキストに写しておく設計で回避します。参照先のマスタが3つを超えて互いに関係し合う構造なら、それはもうリレーショナルデータベースの仕事です。

## ビューと列の書式設定：JSONで状態や期限を色分けする表示の作り込み

### フィルター・グループ化・並べ替えで用途別ビューを分ける設計基準

ビューは、同じリストを用途別に切り出す保存済みの表示条件です。担当者向けには「自分の担当で未完了」、管理者向けには「期限が今週の案件を状態でグループ化」というように、誰が何を判断するかでビューを分けます。全件ビューを既定にしたまま運用すると、件数が増えた時点でしきい値に当たります。

既定ビューには、インデックス列での絞り込みを必ず入れておく設計が必要です。たとえば「状態が完了以外」で絞ると、完了済みが溜まっても表示件数は対応中の数で止まります。完了分を年度ごとに別リストへ移すアーカイブ運用も、最初に決めておきます。

### 列の書式設定JSONで期限切れの行の期限欄を赤く表示するコード例

列の書式設定は、列の表示だけをJSONで変える機能で、データそのものは書き換えません。ビューを作成・管理できる権限があれば誰でも設定でき、列の見出しのメニューから「この列の書式設定」を開いて貼り付けます。次の例は、期限が今日より前の行の期限欄を赤くします。

```
{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
  "elmType": "div",
  "txtContent": "@currentField",
  "style": {
    "color": "=if([$DueDate] <= @now, '#d13438', '')",
    "font-weight": "=if([$DueDate] <= @now, 'bold', '')"
  }
}
```

\[$DueDate\] の部分が内部名での参照です。列を日本語名で作っていると、ここにエンコード済みの文字列を書くことになります。状態の選択肢ごとに背景色を変える場合は、公式が用意している sp-field-severity 系のクラスを使えば配色を自作せずに済みます。なお、ファイル名列や拡張リッチテキストの複数行テキスト列は書式設定の対象外です。

## 5,000件のしきい値とインデックス：件数が増えたリストで止まらない設計

### リストビューのしきい値5,000件で起きることと変更できない制約

リストそのものには3,000万件まで入ります（[SharePoint の制限](https://learn.microsoft.com/ja-jp/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits)、2026年10月時点）。制約になるのは、1回の操作で扱える件数を約5,000件に抑えるリストビューのしきい値です。これを超える操作はブロックされ、ビューにはエラーが表示されます。SharePoint Online ではこの値を管理者が変更できず、オンプレミス版のように夜間だけ緩める設定もありません。

しきい値の影響はビューだけではありません。5,000件を超えるリストを含むサイトはサイトテンプレートとして保存できなくなり、10万件を超えたリストやフォルダーでは権限の継承を切ることも戻すこともできなくなります。件数が増える台帳は、権限の切り方まで最初に決めておく必要があります。

### インデックスは1リスト20列まで：絞り込み列を先に決める手順

インデックスを付けられる列は1つのリストにつき20列までです。5,000件を超えても止まらないビューは、インデックス列で絞り込んだ結果が5,000件未満に収まるビューだけ、と考えると設計を間違えません。

1. ビューで絞り込みに使う列（状態・期限・担当者など）を洗い出す
2. その列をインデックス可能な型で作り、件数が少ないうちにインデックスを付ける
3. 各ビューの最初の絞り込み条件にインデックス列を置き、結果件数の見込みを確認する

インデックスの作成は全項目に触れる処理なので、件数が増えてから付けようとするとしきい値でブロックされることがあると公式も注記しています。運用が始まってからの後付けは避け、リストを作った日に付けておきます。

### Graph APIで項目を絞り込むときのフィルター条件とページ分割

APIで読み出す場合も同じ考え方です。[リストアイテムの一覧API](https://learn.microsoft.com/ja-jp/graph/api/listitem-list?view=graph-rest-1.0)は fields に対する $filter に対応していますが、インデックス列で絞り込むときに使えるのは1回につき1列だけ、と明記されています。

```
GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?expand=fields(select=Title,Status,DueDate)&$filter=fields/Status eq '対応中'
Authorization: Bearer {token}
```

読み取りのアクセス許可は Sites.Read.All です。結果が多いとページに分かれて返るため、応答の次ページのリンクを最後までたどる処理を必ず入れます。1ページ目だけで「全件同期できた」と誤認するのは、夜間バッチの典型的な不具合です。

## Power AppsとPower Automateとの連携：委任の制約と通知の作り替え

### Power Appsの委任：既定500件の上限とSharePointで委任できない演算子

リストを入力元にしたPower Appsのアプリは、リストのメニューの「統合」から数クリックで作れます。詰まるのは件数が500件を超えたときです。Power Appsは、数式をSharePoint側で処理できる場合（委任）だけ全件を対象にし、委任できない数式では先頭から「データ行の制限」までしか見ません。[英語版の委任のドキュメント](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/delegation-overview)（2026年10月更新）では、この制限は既定500件で最大10,000件まで引き上げられると書かれています。日本語版はまだ2,000件のままなので、上限値は英語版で確かめてください。

SharePointで委任できる操作は[SharePointコネクタのドキュメント](https://learn.microsoft.com/ja-jp/power-apps/maker/canvas-apps/connections/connection-sharepoint-online)に表で載っています。テキスト列の大小比較、IsBlank、ID列の等号以外の比較は委任されません。

```
// 委任される：選択肢列の値で等号比較
Filter(案件台帳, Status.Value = "対応中")

// 委任されない：IsBlank はテキスト列で委任不可（先頭500件しか見ない）
Filter(案件台帳, IsBlank(CustomerCode))

// 置き換え：空値との等号比較なら委任される（空文字は空として扱わない点に注意）
Filter(案件台帳, CustomerCode = Blank())
```

開発中はデータ行の制限を1に下げておくと、委任されない数式が1件しか返さなくなり、テストの段階で気づけます。公式が勧めているやり方で、試作アプリを本番へ持っていくときの事故を防げます。

### アラート廃止後の通知はルールとPower Automateで組み替える

リストの変更をメールで知らせる従来の「アラート」は、[SharePoint アラートの廃止](https://support.microsoft.com/ja-jp/sharepoint/admin/sharepoint-alerts-retirement)の予定どおり2026年7月に機能が削除されました。2026年1月から全テナントで新規作成が段階的に止まり、既存のアラートも延長できなくなっています。代わりとして公式が案内しているのは、リストの「ルール」とPower Automateの2つです。

使い分けは単純で、「状態が完了に変わったら担当者に知らせる」程度ならルールで足ります。条件が複数の列にまたがる、通知先を別のリストから引く、通知と同時に別の処理も走らせる、という要件ならPower Automateで組む設計です。フローから同じリストへ書き戻すと更新が更新を呼ぶ無限ループになりやすく、その止め方は[Power AutomateとSharePointの連携設計](https://www.issoh.co.jp/tech/details/16760/)で手順を示しています。

## SharePointリストで作り続ける場面と業務システムへ移す判断の基準

### 台帳をリストのまま運用できる条件：件数・同時更新・権限の境界値の目安

リストで作り続けてよいのは、次の条件がそろう場合です。データが1つの表でほぼ完結し、マスタ参照はルックアップ数本で済む。主要なビューがインデックス列での絞り込みで5,000件未満に収まる。項目単位の個別権限は使わないか、数百件程度に留まる。公式の上限では、項目単位の固有権限は5万件まで動作するものの、推奨は5,000件以下とされています。

この範囲なら、Power AppsとPower Automateを組み合わせて申請管理や問い合わせ管理を作るのが、費用と立ち上がりの速さで最も有利です。Microsoft 365をすでに契約している組織なら、追加のライセンスなしで始められる点も効きます。権限を広げすぎたリストはCopilotの回答に混ざる経路にもなるため、公開範囲の点検は[Microsoft 365 Copilotの情報漏洩対策](https://www.issoh.co.jp/tech/details/17565/)の手順で行ってください。

### リストを見送って業務システムで作るべき場面と典型的な失敗パターン

次のどれか1つに当てはまるなら、リストで作るのは見送ります。在庫の引当や入金消込のように、複数の表を同時に更新して整合性を保つ処理がある場合。ルックアップが12個の上限に近づくほど表同士の関係が多い場合。取引先ごとに見える行を変えるなど、項目単位の権限が数千件規模になる場合です。リストにはトランザクションがなく、2つのリストを同時に更新して片方だけ失敗したときに元へ戻す仕組みがありません。

失敗の典型は、小さく始めた台帳に機能を足し続け、5,000件を超えた時点でビューが開かなくなり、計算をPower Automateの多段フローで補い、作った担当者しか直せない状態になる流れです。このとき、台帳の移行先の候補となるのは次の2つです。Power Platformの範囲で続けるならDataverseへ、基幹データとの連携や複雑な計算が中心なら業務システムとして作り直します。ノーコードの別製品と比べたい場合は[kintoneでできることと内製の判断](https://www.issoh.co.jp/column/details/15084/)も比較材料になります。

当社では、SharePointリストを台帳にしたPower Appsのアプリ作成から、Dataverseへの移行、業務システムとしての作り直しの判断までを[Power Platform（PowerApps）導入支援サービス](https://www.issoh.co.jp/service/erp%5Fcrm/power-platform/)としてお受けしています。今あるリストの件数とビューの構成を見れば、どこまでリストで続けられるかは具体的に線を引けます。

## よくある質問

SharePointリストについて、作成と運用の段階でよく寄せられる質問をまとめました。

### SharePointリストとMicrosoft Listsは何が違いますか？

実体は同じです。Microsoft Listsは、SharePoint上のリストを一覧・作成するためのアプリで、どちらで作ってもSharePointのリスト基盤に保存されます。違いが出るのは保存先の選び方だけで、業務の台帳は担当者が異動・退職しても残るよう、部署のサイトに作ってください。

### SharePointリストは無料で使えますか？

SharePointを含むMicrosoft 365のプラン（Business Basic以上やE3など）を契約していれば、リストは追加料金なしで使えます。SharePoint Plan 1・Plan 2の単体プランも、リストを利用できる契約の対象です。容量は組織全体で「1TB＋ライセンスあたり10GB」の枠を共有し、リストの添付ファイルもこの枠を使います。

### リストが5,000件を超えたらどうなりますか？

データが消えることはなく、3,000万件まで登録できます。開けなくなるのは、インデックスの無い列で絞り込むビューや全件を並べるビューです。SharePoint Onlineではしきい値を変更できないため、絞り込み用の列にインデックスを付け、各ビューの結果を5,000件未満に抑える設計で回避します。

### Excelの表からSharePointリストを作れますか？

Excelの表からのリスト作成は可能です。サイトの「新規」から「リスト」を選び、「Excelから」または「CSVから」を選ぶと表を取り込めます。Excel側の列名がそのまま内部名になるため、取り込む前に列名を英数字へ直しておくと、あとでフローやAPIから扱いやすくなります。

### リストのアイテムに添付できるファイルの上限はありますか？

Microsoft Learnの「SharePoint の制限」では、リストのアイテムに添付できるファイルは1つあたり250MBまでとされています。ドキュメントライブラリの1ファイル250GBとは、ファイル容量の上限が異なる仕様です。図面や動画のような大きなファイルを扱うなら、ファイルはライブラリに置き、リストにはそのリンクや管理番号を持たせる構成のほうが、検索と権限管理の両面で扱いやすくなります。

## 関連記事

- [SharePointとは？できること・OneDriveやTeamsとの違いと導入判断の基準](https://www.issoh.co.jp/column/details/18021/)：リストを含むSharePoint全体の役割と導入判断。
- [Power AutomateのSharePoint連携とは？トリガー選定・無限ループ回避・権限設計を実装目線で解説](https://www.issoh.co.jp/tech/details/16760/)：リストを起点にしたフローの作り方と無限ループの止め方。
- [SharePointで社内ポータルを作る実装手順｜サイト構成・Webパーツ・権限・ナビ設計を上限値から解説](https://www.issoh.co.jp/tech/details/16153/)：リストを置くサイト側の構成と権限設計。
- [Microsoft Graph APIとは？できること・権限設計とPythonでの呼び出し手順【2026年10月】](https://www.issoh.co.jp/tech/details/18719/)：リストをAPIで操作するときの認可と呼び出し方。
- [エクセル管理の限界はどこか｜プロジェクト・工程・案件管理で崩れる条件と専用ツールへ移る判断基準](https://www.issoh.co.jp/column/details/11237/)：Excel台帳からリストやシステムへ移る判断。

---

出典: [SharePointリストとは？列設計・ビュー・5000件のしきい値とPower Apps連携を実装目線で解説](<https://www.issoh.co.jp/tech/details/18724/>)（株式会社一創）