Excel台帳をSharePointリストへ置き換える ── 共有・履歴・フロー連携で「台帳が壊れる」を卒業する

「案件管理台帳.xlsxを開いたら読み取り専用だった。誰が開いているか分からないのでコピーを作って更新したら、どれが最新か分からなくなった」「並べ替えたら行がズレて、別の案件のメモが付いてしまった」。共有フォルダのExcelで案件管理・問い合わせ管理・備品管理などの台帳を回している会社から、こういう相談をよく受けます。

Excelは表計算ソフトとしては優秀ですが、「複数人が同時に追記・更新する台帳の置き場所」としては構造的に無理があります。Microsoft 365を導入済みなら、この用途にはSharePointリスト(Microsoft Lists)という専用の器がすでに手元にあります。行ごとの同時編集、変更履歴、型付きの入力、そしてPower Automateによる通知・承認への発展まで、台帳に必要なものが一通り揃っています。

この記事では、Excel台帳の限界がどこで来るのか、SharePointリストへの置き換え判断と移行手順、リストビューのしきい値5,000をはじめとする設計上の注意、そしてPower Automate連携で台帳を「動く台帳」にするところまでを整理します。

対象読者と前提環境: 共有フォルダーのExcel台帳を複数人で回している情シス・業務担当者を想定しています。前提はMicrosoft 365を導入済みで、SharePoint Onlineが使えるプランであること(SharePointリスト=Microsoft Listsはその範囲の機能です)。¹ この記事で扱うPower Automateの連携も、SharePointコネクタをはじめすべて標準コネクタなので、Microsoft 365のライセンスに含まれるPower Automateの利用権で組めます。²³ 追加ライセンスが要るのは、7章で触れるDataverseやSQLなどプレミアムコネクタに手を伸ばす場合だけです。⁴

1. まず結論

• Excel台帳の事故(上書き・行ズレ・最新版不明)の根本原因は、ファイル丸ごとが編集単位になっていることです。SharePointリストは行(アイテム)単位で編集・履歴管理されるため、この種の事故が構造的に起きにくくなります。
• SharePointリストは1リストあたり最大3,000万アイテムまで保存でき、リストアイテムへの添付ファイルは1ファイル250MBまでです。⁵
• よく話題になる5,000件の制限は「リストビューのしきい値」であり、保存できる件数の上限ではありません。インデックス列と絞り込んだビューの設計で、5,000件を超えても運用できます。⁶⁷
• SharePoint Onlineのリストは作成時からバージョン履歴が有効(既定で50バージョン)です。「誰がいつどの項目を変えたか」が最初から残ります。⁸
• Microsoft ListsにはExcelブックからリストを作成するインポート機能があります。ただし取り込みの前に、セル結合の解除・1行1件化・表記ゆれの掃除と列型の設計を済ませておくのが移行の実務です。¹
• SharePointコネクタは標準コネクタなので、Microsoft 365のライセンス範囲で「アイテムが作成または変更されたとき」を起点に通知・承認・督促のフローを組めます。²³
• 集計・分析が主目的のシート、1〜2人でしか触らない低頻度の台帳はExcelのままで問題ありません。逆に、リレーションが多い・件数が数十万件規模・トランザクション整合性が要る業務データは、リストではなくDataverse(Power Platformの業務アプリ向けデータ基盤。データをテーブルの集まりとして保持し、テーブル間の関連付けやロールベースのアクセス制御を前提に設計されたクラウドのデータベースです)⁹や業務システム(受託開発)の領域です。なお、Power AutomateからDataverseを使うコネクタはプレミアム層に分類されるため、ライセンスの追加が前提になります。⁴

この記事の知識マップ

共有フォルダのExcel台帳はファイル丸ごとが編集単位であるため同時編集の上書き事故を招きやすく、行(アイテム)単位で編集・履歴管理されるSharePointリストはその後継として事故を軽減する。移行はセル結合解除などの掃除と列型設計をインポートより先に済ませるのが実務の本体で、リストビューのしきい値5,000件は保存上限とは別物であり、インデックス付きの列と絞り込んだビューで対策できる。SharePointコネクタが提供するアイテム作成・変更トリガーはPower Automateのクラウドフローを起動して通知・承認・督促を自動化できるが、フロー自身の書き戻しが再度トリガーを満たすと無限ループになるため、トリガー条件による絞り込みが欠かせない。参照が数段に増えたり数十万件規模になったりする場合は、リストではなくプレミアムコネクタを要するDataverseが候補になる。

flowchart LR
    accTitle: Excel台帳からSharePointリストへの移行の知識マップ
    accDescr: 共有フォルダのExcel台帳が抱える同時編集事故をSharePointリストが行単位の編集とバージョン履歴で軽減すること、掃除・列型設計・インポートという移行手順、リストビューのしきい値とその対策、Power Automateのトリガー条件によるループ防止、Dataverseへの発展という関係を示す図
    excel_ledger["Excel台帳"]
    sharepoint_list["SharePointリスト"]
    simultaneous_editing_conflict["Excel台帳の同時編集事故"]
    excel_data_cleanup["Excel側の掃除"]
    excel_to_list_import["Excelからのリスト作成(インポート)"]
    list_column_type["リストの列型"]
    list_version_history["リストのバージョン履歴"]
    document_library["ドキュメントライブラリ"]
    list_view_threshold["リストビューのしきい値"]
    list_indexed_column["インデックス付きの列"]
    list_view["リストビュー"]
    list_item_trigger["アイテム作成/変更トリガー"]
    sharepoint_connector["SharePointコネクタ"]
    power_automate_cloud_flow["Power Automate クラウドフロー"]
    ledger_notification_workflow["台帳の通知・承認・督促のワークフロー"]
    trigger_condition["トリガー条件(Trigger Conditions)"]
    trigger_loop["トリガーの自己更新による無限ループ"]
    dataverse["Microsoft Dataverse"]
    large_scale_relational_ledger["大規模・多段参照の台帳要件"]
    premium_connector["プレミアムコネクタ(汎用HTTPアクション)"]
    power_bi_list_connection["Power BIからのSharePointリスト接続"]
    single_user_low_frequency_ledger["更新者が少数・低頻度の台帳"]
    multi_user_frequent_update_ledger["複数人が日常的に更新する台帳"]
    excel_ledger -.->|"原因になり得る"| simultaneous_editing_conflict
    sharepoint_list -->|"軽減する"| simultaneous_editing_conflict
    sharepoint_list -->|"の後継"| excel_ledger
    excel_data_cleanup -->|"より先に行うべき"| excel_to_list_import
    list_column_type -->|"より先に行うべき"| excel_to_list_import
    sharepoint_list -->|"前提とする"| list_column_type
    sharepoint_list -->|"利用する"| list_version_history
    document_library -->|"推奨される対応"| sharepoint_list
    sharepoint_list -.->|"原因になり得る"| list_view_threshold
    list_indexed_column -->|"軽減する"| list_view_threshold
    list_view -->|"軽減する"| list_view_threshold
    list_item_trigger -->|"前提とする"| sharepoint_list
    list_item_trigger -->|"前提とする"| sharepoint_connector
    power_automate_cloud_flow -.->|"利用する"| list_item_trigger
    power_automate_cloud_flow -->|"自動化する"| ledger_notification_workflow
    trigger_condition -.->|"防止する"| trigger_loop
    dataverse -->|"推奨される対応"| large_scale_relational_ledger
    dataverse -.->|"前提とする"| premium_connector
    sharepoint_list -->|"用いるのは非推奨"| large_scale_relational_ledger
    power_bi_list_connection -->|"利用する"| sharepoint_list
    excel_ledger -->|"推奨される対応"| single_user_low_frequency_ledger
    sharepoint_list -->|"推奨される対応"| multi_user_frequent_update_ledger
    power_automate_cloud_flow -.->|"原因になり得る"| trigger_loop
    list_item_trigger -->|"で構成できる"| trigger_condition

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. Excel台帳の限界はどこで来るか

相談を受けていて、Excel台帳が壊れ始めるポイントはだいたい共通しています。

• 同時編集と上書き。共有フォルダのExcelは、誰かが開いていれば読み取り専用になります。待てない人がコピーを作り、「台帳_最新.xlsx」「台帳_0715_田中修正.xlsx」が増殖し、どれが正か分からなくなります。ブラウザ版Excelの共同編集で同時に開くこと自体は回避できますが、次に挙げる問題は残ります。
• 行ズレと破壊。フィルターをかけたまま貼り付ける、並べ替えの範囲選択を誤る、行の挿入で隣の列だけずれる。表計算の自由さは、台帳にとってはデータを壊す自由でもあります。しかも誰がいつ壊したのかは、ファイルの更新日時くらいしか手がかりがありません。
• 入力規則が守られない。「ステータスはこの5つから選ぶ」「日付はyyyy/mm/dd」と決めても、セルには何でも入ります。入力規則(データの入力規則)を設定しても、コピー&ペーストで簡単に上書きされます。表記ゆれは、後の集計・検索のコストとして跳ね返ってきます。
• マクロの属人化。転記や集計をVBAで自動化した台帳は、作った人が異動・退職した時点でブラックボックスになります。マクロ付きブックはファイル破損のダメージも大きくなりがちです。
• 「見る」と「編集する」を分けられない。閲覧してほしいだけの人にも編集できるファイルを渡すことになり、権限の分離ができません。

一方で、Excelのままでよい台帳もあります。更新者が1〜2人で頻度も低いもの、月次で作って配るだけの集計表、計算式・ピボット・グラフが主役の分析シート、印刷様式そのものに意味がある帳票。これらは「複数人で同時に更新する」問題が起きないか、起きてもExcelの強み(計算・レイアウト)が上回ります。置き換えの判断基準は7章の表にまとめます。

3. SharePointリストとは ── セルの表ではなく「行のデータベース」

SharePointリストは、Microsoft 365に含まれるSharePointの機能で、Microsoft Listsアプリからも同じものを作成・利用できます(SharePointでリストを開くとMicrosoft Listsに案内される関係で、実体は同じです)。¹⁰ Excelとの一番の違いは、編集の単位がセルではなく行(アイテム)であることです。

実務で効く機能を補足します。

• 列の型。選択肢列を使えばステータスは定義した値しか入りません。ユーザー列は組織のアカウントと紐づくので「担当者」の表記ゆれが消えます。日付列は日付としてしか入らないため、期限の判定や並べ替えが確実になります。参照(ルックアップ)列で別リストの値を参照する簡単なリレーションも組めます。¹¹¹²
• ビュー。「自分の担当分」「今月期限」「未完了のみ」のように、同じデータを目的別の見え方で共有できます。Excelでシートをコピーして人別に配る運用が不要になります。
• バージョン履歴。アイテムごとに、いつ・誰が・どの列をどう変えたかが記録され、以前の版に戻せます。SharePoint Onlineではリスト作成時から既定で有効です。⁸ 「誰かが消した」「前の値が知りたい」への答えが標準機能になります。
• アラート・ルール。値の変更時に通知を送る簡易ルールをリスト側だけでも設定できます。¹ 凝った通知や条件分岐はPower Automateの出番です(6章)。
• Teams・モバイル。ListsはTeamsのチャネルにタブとして追加でき、デスクトップ・Web・モバイルから同じリストを操作できます。¹ 現場からスマホで問い合わせ状況を更新する、といった運用が現実的になります。

4. 移行の実務 ── 掃除→列設計→インポート→ビュー→切り替え

Excel台帳からの移行は、次の順序で進めます。ツールの操作よりも、最初の2ステップ(掃除と列設計)が成否を分けます。

(1) 既存データの掃除が先

Excel台帳には、表計算だから許されていた構造が必ず紛れ込んでいます。リストは1行=1アイテムのフラットな構造なので、先にExcel側で整えます。

• セル結合を解除する(結合はリストに持ち込めません)
• 1行1件にする(1つのセルに複数案件、複数行にまたがる1件、を解消)
• ヘッダーを1行にする(2段組ヘッダーは列名を付け直す)
• 表記ゆれを統一する(「対応中/対応チュウ/仕掛」→選択肢の候補値に揃える)
• 途中の小計行・装飾用の空行を削除する
• 計算式のセルは「値として残す」か「移行後に集計側で再現する」かを決める

この掃除は移行作業であると同時に、台帳の設計の棚卸しでもあります。「この列、誰も入れていない」「この2列は同じ意味だった」が大量に見つかるのが普通です。

(2) 列型の設計

掃除したExcelの各列を、どの型のリスト列にするかを決めます。定石はこうです。

(3) インポート

Microsoft ListsにはExcelブックのデータを取り込んでリストを作成する機能があり、既存の台帳を出発点にできます。¹ 操作の入口は、Microsoft Listsアプリ(またはリストを置きたいSharePointサイト)で「新規」>「リスト」と進み、作成方法の一覧から「Excelから」を選ぶところです。掃除済みのブックを指定すると、取り込む列とその型を確認する画面になります。

ただ、実務ではインポートの自動判定に任せきりにせず、先に列型を決めてからインポート時に確認する(あるいは先に空のリストを設計して後からデータを流し込む)ことをお勧めします。特に選択肢列・ユーザー列は台帳の品質を決める列なので、テキスト列のまま運用を始めてしまうと、せっかく移行した意味が半減します。

また、数千行を超える台帳では、1回のインポートにすべてを任せる計画にしないでください。持ち込んだ直後から5章で扱う5,000件しきい値の設計が最初の課題になりますし、取り込みが大きいほど列型の確認や失敗時のやり直しも重くなります。列設計を確定した空のリストを先に作り、しきい値対策のインデックス列と絞り込みビューを用意したうえで、データは区切りのよい単位に分割して投入する(実データの一部で一度リハーサルする)進め方が安全です。

(4) ビューと権限

既定のビューには「未完了のみ・期限昇順」のような日常業務の形を設定し、全件ビューは別に用意します。これは後述する5,000件しきい値への備えでもあります。権限は「編集できる人」「閲覧のみの人」をリスト単位で分けるところから始め、アイテム単位の細かい権限は本当に必要な場合に限定します(件数が増えてからの権限変更には制約があります。5章)。

(5) 並行期間と切り替え

移行日を決めて一斉に切り替えるのが理想ですが、現実には「しばらくExcelにも書く人」が出ます。並行期間を作る場合は「正はリスト、Excelは参照用の写し」と宣言し、Excel側を読み取り専用にしてしまうのが安全です。二重運用を漫然と続けると、どちらも正でなくなります。

5. 制限と設計の注意 ── 5,000・添付・「Excelにあってリストにないもの」

リストビューのしきい値5,000を正しく理解する

SharePoint Onlineには、1つのビュー(表示・並べ替え・フィルター・グループ化などの操作)が一度に扱えるアイテム数に既定で5,000件のしきい値があります。超えると「このリストのアイテム数がリストビューのしきい値を超えています」というエラーや、列の並べ替え・フィルターの失敗が起きます。⁶⁷

ここで重要なのは、これは保存件数の上限ではないことです。リスト自体は最大3,000万アイテムまで保存できます。⁵ 制限されるのは「5,000件を超える範囲を一度に舐めるクエリ」であり、対策も公式に案内されています。

• 絞り込みに使う列にインデックスを付ける。並べ替え・フィルターの軸になる列(受付日、ステータス、担当者など)に列インデックスを作成します。ただしインデックスの追加・削除ができるのは2万アイテムまでという制限があるため、リストが大きくなる前に設計しておきます。⁷
• ビューを常に5,000件未満に絞る。「今年度分」「未完了のみ」「担当者=自分」のように、インデックス列でのフィルターを既定ビューに組み込みます。⁷

インデックスの作成場所は分かりにくいので、メニューのパスを書いておきます。リストを開いて右上の設定(歯車)>「リストの設定」(List settings)>「列」セクションの「インデックス付きの列」(Indexed columns)>「新しいインデックスの作成」(Create a new index)と進み、対象の列(主列)を選んで作成します。インデックスを作れるのは1つのリスト/ライブラリあたり最大20列までなので、よく使うフィルター列に絞ってください。¹³

中小企業の案件・問い合わせ台帳なら年間数百〜数千件が多く、当面は無縁に見えますが、数年分が蓄積すれば届く数字です。「年度で絞った既定ビュー+インデックス列」を最初から作っておけば、後から慌てずに済みます。なお、アイテム数が10万件を超えるとリスト・フォルダー単位での権限継承の切断ができなくなるなど、大規模化には別の制約もあります。⁵ 数十万件規模の運用が最初から見えているなら、リストではなくデータベース(Dataverse・SQL)を選ぶ判断です(7章)。

添付ファイルの扱い ── 添付列かドキュメントライブラリか

リストのアイテムにはファイルを添付でき、1ファイル250MBまで対応します。⁵ ただし実務では次の2点に注意が要ります。

• リストのバージョン履歴は列の変更を記録しますが、添付ファイルの変更は版管理されません。⁸
• Power Automateから添付を操作する場合、SharePointコネクタが扱える添付ファイルサイズは90MBまでです。²

見積書・報告書のように、それ自体の版管理や共同編集が必要なファイルは、リストの添付ではなくドキュメントライブラリに保存し、リストにはリンクや管理番号で紐づける構成が扱いやすいです。添付列は「FAXのスキャン1枚」のような、アイテムに従属する軽い証跡向きと割り切ります。

Excelにあってリストにないもの

移行相談で必ず確認するのが、「Excelだからできていたこと」への依存度です。

• 自由なレイアウト。セル結合、2段組ヘッダー、色分けだけで意味を持たせた表は再現できません。意味は列に、見せ方はビューに移します。
• セル間の複雑な計算式。リストにも集計列(計算値)はありますが、シート全体を参照する複雑な計算網やピボットの代替にはなりません。集計・分析は、リストのデータをExcelやPower BIに接続して行う役割分担にします。Power BI Desktopからリストに接続してレポートを作る手順や、Power BIサービスでリストから直接セマンティックモデルを作成して定期更新する方法が公式に用意されています。¹⁴¹⁵
• 印刷レイアウト。台帳をそのまま印刷様式にしていた場合、リストの画面は帳票にはなりません。印刷が要件なら、エクスポートしたデータをExcelテンプレートに流し込む、帳票側を別途作るなどの設計が必要です。

つまり「入力と共有はリスト、計算とレイアウトはExcel/Power BI」という分業に組み替えるのが、置き換えの正しい形です。

6. Power Automate連携で台帳が動き出す

SharePointリスト化の最大の配当は、Power Automateとの連携です。SharePointコネクタは標準コネクタなので、標準コネクタを使えるMicrosoft 365ライセンスの範囲でクラウドフローを組めます。² リストには「アイテムが作成されたとき」「アイテムが作成または変更されたとき」などのトリガーが用意されており、台帳への登録・更新をそのままフローの起点にできます。²³

flowchart TD
    Excel[既存のExcel台帳] -- 掃除・列設計して移行 --> List[SharePointリスト<br/>案件・問い合わせ台帳]
    Forms[Microsoft Forms<br/>申請・依頼の受け口] -- 応答を転記 --> List
    List -- アイテム作成/更新トリガー --> Flow[Power Automate<br/>クラウドフロー]
    Flow --> Notify[Teams/メールで担当者へ通知]
    Flow --> Approve[承認フローへ回す]
    Sched[スケジュール実行] --> Remind[期限切れアイテムの督促]
    List -.-> Sched
    List -- 接続/エクスポート --> BI[Excel集計・Power BIレポート]

代表的なパターンは3つです。

• 通知。新しい問い合わせが登録されたら担当チャネルにTeams通知を送る、担当者列が設定されたら本人にメールする。台帳を「見に行く」運用から「知らせてくれる」運用に変わります。
• 承認。ステータスが「承認依頼」に変わったら承認フローを開始し、結果と承認者・日時をリストの列に書き戻す。承認の証跡が台帳の同じ行に揃うこの構成は、別記事「Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する」で詳しく扱っています。¹⁶
• 督促・棚卸し。毎朝スケジュール起動で「期限切れかつ未完了」のアイテムを抽出し、担当者へまとめて通知する。SharePointを使ったリマインダーフローは定番のシナリオとして公式にも案内されています。³ 営業日判定や月次処理を含む定期実行の設計は「Power Automateの定期実行フローと営業日設計」にまとめています。

1点だけ設計上の注意があります。「アイテムが作成または変更されたとき」トリガーのフローが自分でリストを更新すると、その更新でまた自分が起動する無限ループになり得ます。後段の条件分岐で捨てるのではなく、トリガー条件(trigger conditions)で「ステータスが特定の値のときだけ起動する」とトリガー側に書くのが定石です。条件を満たさない更新では実行自体が発生せず、実行履歴にも残りません。¹⁷

設定場所と式の形はこうです。デザイナーでトリガーを選び、「設定」(Settings)の「トリガー条件」(Trigger conditions)に「+ 追加」で式を1行ずつ書く(クラシックデザイナーではトリガー右上の「…」>「設定」>「トリガー条件」)。式は必ず@で始めます。複数書いた場合はすべてを満たしたときだけ起動するので、「どれかを満たせばよい」場合は@or(条件1, 条件2)と1本にまとめます。¹⁷

@equals(triggerBody()?['Status']?['Value'], '承認依頼')

これは「ステータス列(内部名Status)が『承認依頼』になったときだけ起動する」という条件です。選択肢列の値は['Value']まで下りて取り出す点と、列名は画面の表示名ではなく内部名である点に注意してください(1行テキスト列なら@equals(triggerBody()?['Status'], '承認依頼')のように['Value']は不要です)。式を手書きするのが不安な場合は、公式ドキュメントが案内している手順 ── フローに一時的に「アレイのフィルター処理」(Filter array)アクションを置き、画面で条件を組んでから「詳細モードで編集」で生成された式をコピーし、トリガー条件に貼ってアクションを削除する ── が確実です。¹⁷

ただしトリガー条件は、フロー自身の書き戻しで条件が偽になることと対になって初めてループを止めます。「ステータスが『承認依頼』のとき起動」するフローなら、処理の最後で必ずステータスを『処理中』や『承認済み』など別の値へ更新して終えることまでが設計です。書き戻し後もステータスが『承認依頼』のままだと、その更新で再び条件が真になり、承認要求や通知が繰り返し飛びます。条件に使う列を変えない書き戻しがどうしても必要な場合は、処理済みフラグ列を足してトリガー条件に加えてください。

入力の入り口をさらに広げたい場合は、Microsoft Formsで受け付けてフローでリストに転記する構成が有効です(「Microsoft FormsとPower Automateで申請・依頼の受け口を作る」)。また、この記事の範囲はすべて標準コネクタで組めますが、DataverseやSQLに手を伸ばすとプレミアムライセンスの領域に入ります。⁴ 境界線は「Power Automateのライセンスと標準/プレミアムコネクタの境界」で整理しています。

7. 判断表 ── Excelのまま/リスト化/業務アプリ・データベース開発

目安としては、「台帳」と呼べるうちはリストで十分、「業務システムの代わり」をリストにさせ始めたら赤信号、と考えています。参照列が増え、フローが何本も絡み合い、しきい値対策のビューが乱立し始めたら、それはデータベースと業務アプリで解くべき問題になっています。リストの良さは、そこに至るまでの数年間を、追加費用の少ない標準機能で安全に運用できることです。

8. まとめ

共有フォルダのExcel台帳の問題は、担当者の注意力ではなく構造の問題です。ファイル丸ごとが編集単位である限り、上書き・行ズレ・最新版不明は繰り返されます。SharePointリストに移すと、編集は行単位になり、入力には型が付き、変更はバージョン履歴に残り、権限は役割で分けられます。

移行の実務は、インポート操作そのものよりも「データの掃除」と「列型の設計」が本体です。そして5,000件のしきい値はビューの制限であることを理解し、インデックス列と絞り込んだビューを最初から用意しておけば、長く安心して使えます。添付ファイルはドキュメントライブラリとの役割分担を決め、計算とレイアウトはExcel/Power BIに任せる。この分業ができた台帳は、Power Automateのトリガーを起点に、通知・承認・督促まで自動で動く「動く台帳」に育っていきます。

そしてリストで苦しくなってきたら、それはDataverseや業務システムへ進むサインです。どこまでを標準機能でやり、どこからを開発で解くか。その線引きの相談から、弊社で承っています。

関連記事

• Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計
• Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する
• Microsoft FormsとPower Automateで申請・依頼の受け口を作る
• Power Automateの定期実行フローと営業日設計
• Power Automateのライセンスと標準/プレミアムコネクタの境界

関連する相談領域

合同会社小村ソフトでは、Excel台帳のSharePointリスト化・Power Automate連携の設計相談から、リストでは収まらない業務データベース・業務アプリの受託開発までを扱っています。

• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

SharePointリストには5,000件までしか入れられないのですか？

いいえ。5,000件というのはリストビューのしきい値で、1つのビュー(表示・並べ替え・フィルター)が一度に扱えるアイテム数の既定の制限です。リスト自体には最大3,000万アイテムまで保存できます。5,000件を超えて使う場合は、絞り込みに使う列にインデックスを付け、常に5,000件未満に絞られたビュー(今年度分・担当者別など)を既定にする設計にすれば運用を続けられます。インデックスの追加は2万アイテムを超えると制限があるため、大きくなる前に設計しておくことが重要です。

ExcelファイルからそのままSharePointリストを作れますか？

作れます。Microsoft ListsにはExcelブックのデータを読み込んでリストを作成する機能があり、既存の台帳を出発点にできます。ただしその前に、セル結合の解除、1行1件への整理、ヘッダー行の統一、表記ゆれの掃除を済ませておく必要があります。また、選択肢列・ユーザー列・日付列といった列の型はリストの価値の中心なので、インポート任せにせず先に列設計を決めてから取り込むことをお勧めします。

Excel台帳のままでよいのはどんな場合ですか？

更新するのが1〜2人で更新頻度も低い場合、台帳というより集計・分析のワークシートである場合、複雑な計算式やピボット、印刷レイアウトが主目的の場合は、Excelのままで問題ないことが多いです。逆に、複数人が日常的に追記・更新する、状態(対応中・完了など)を管理する、変更の履歴や担当者を追いたい、通知や承認につなげたい、という台帳はSharePointリストに向いています。

SharePointリストにするとPower Automateで何ができますか？

SharePointコネクタは標準コネクタなので、Microsoft 365のライセンス範囲で「アイテムが作成されたとき」「作成または変更されたとき」といったトリガーからクラウドフローを起動できます。新規登録のTeams通知、状態変更をきっかけにした承認フロー、期限切れアイテムの定期的な督促などが代表例です。蓄積したデータはExcelやPower BIから参照して集計・レポート化もできるため、台帳が通知・承認・集計のハブになります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。