Power PlatformではExcel、SharePointリスト、Dataverse、SQL Serverなどのデータソースを利用できます。どれが最も優れているかではなく、業務の規模、同時利用、データの構造、権限管理に合うものを選ぶことが重要です。
この記事では、DataverseとSharePointの違いを中心に、Excel・SQL Serverとの使い分けと、切り替えを検討すべきタイミングを解説します。

\ Excel管理、このままで大丈夫?/
脱Excelを検討すべき業務と移行の考え方をチェック
目次
Power Platformで使える主なデータソースの比較
主な違いを簡単に整理すると、以下のとおりです。
| データソース | 適した用途 | 検討すべき点 |
|---|---|---|
| Excel | 既存ファイルを使う小規模な管理 | 同時書き込み・ファイルロック |
| SharePointリスト | 部署の情報共有・文書に関わる業務 | ビューのしきい値・データ関連付け |
| Dataverse | 複数アプリによる共通データ利用・詳細な権限管理 | ライセンスと事前設計 |
| SQL Server | 既存DBとの連携・複雑なデータ処理 | 接続・運用設計 |
この比較表は、各データソースを選ぶ際の大まかな目安です。実際には、利用人数だけでなく、同時書き込みの有無、データ間の関連性、権限管理、運用期間を組み合わせて判断することが大切です。以下で、それぞれの制約と特徴を詳しく確認します。
ExcelやSharePointリストは、Power Platformを使い始める際に取り入れやすいデータソースです。しかし、利用者やデータ件数が増えると、ファイルロック、リストビューのしきい値、Power Appsの委任などが課題になる場合があります。まずは、どのような制約が起きるのかを把握することが、保存先を選び直す第一歩です。
Excel:ファイルのロックと同時編集の問題
Excel Online (Business) コネクタの公式ドキュメントには、ファイルが最後に使用された時点から最大6分間ロックされる場合があると記載されています。また、複数のクライアントから同じExcelファイルへ同時に書き込むことはサポートされておらず、競合やデータの不整合が発生する可能性があるとされています。さらに、呼び出し回数は60秒あたり100回までに制限されています。
つまり、Excelの同時編集の問題は「運が悪いと起きる現象」ではなく、コネクタの仕様として明記された制約なのです。
SharePoint:5,000件の壁
SharePointリストのビューには、5,000件という上限(リストビューのしきい値)があります。リスト自体には最大3,000万件まで保存できますが、1つのビューで5,000件を超えるデータを表示しようとするとエラーになります。この値はSharePoint Onlineでは変更できません。
Power Apps:委任の問題
Power Appsでは、データの取得・処理に「委任」の仕組みが関わります。

Power Appsは、クエリをデータソース側に渡して処理させる「委任」という仕組みを使っています。ところが、データソースがサポートしていない関数が1つでも含まれていると、クエリ全体が委任されなくなります。この場合、Power Appsはデータソースから先頭の一部のデータだけを取得し、アプリ側で処理します。取得件数は既定で500件、設定により最大2,000件まで増やせます。
公式ドキュメントでも、この状況の危険性がはっきりと説明されています。アプリの利用者には「一部の結果しか表示されていない」という通知が表示されないため、データは存在するのに検索で見つからないという問題に、利用者も開発者も気づきにくいのです。
最初は快適に動いていたアプリや自動化が、データが増えるにつれて遅くなり、やがて誤った結果を表示するようになります。その結果、開発よりもメンテナンスや障害対応に多くの時間を取られることになります。
Dataverseを使うと何が変わるのか
Dataverseは、はじめから多数のユーザーによる利用と、業務システムとしての運用を前提に設計されています。
- 委任できるクエリの範囲が広い:公式ドキュメントでも「DataverseはExcelより多くのクエリ機能をサポートする」と説明されており、その例として「in」演算子が挙げられています。SharePointでは委任されなかった数式が、Dataverseでは委任される場合があります。
- 集計関数をサーバー側で処理できる:たとえばCountRowsやCountIfはSharePointでは委任されないため、500~2,000件の範囲でしか計算されません。一方、Dataverseでは委任がサポートされているため、対応する集計処理をサーバー側で実行できます。ただし、関数や設定による制限があります。
- リレーションシップ、セキュリティ、入力検証をアプリではなくデータ側で管理できる:検証をアプリ画面だけに設定していると、Power Automateや外部連携から登録されたデータは検証されません。これが最も重要なポイントです。
※ 注意:500件・2,000件という上限はデータソースではなく、Power Appsアプリ側の設定です。Dataverseを使っていても、委任されない数式を使えば同じ制限を受けます。「Dataverseに切り替えれば委任を気にしなくてよい」というわけではありません。
参考:キャンバス アプリでの委任について – Power Apps | Microsoft Learn
関連記事:Dataverseとは?特徴・できること・Power Appsでの活用方法をわかりやすく解説

\ Excel管理、このままで大丈夫?/
脱Excelを検討すべき業務と移行の考え方をチェック
Power Platformはさまざまなデータソースに接続できます。ここで大切なのは「どれが優れているか」ではなく、「いま何を作ろうとしているか」です。保存先を選ぶ際は、実務上、次の5つの観点で判断するのがおすすめです。
- 同時性:同じデータを複数のユーザーが同時に扱うか
- 規模:データが将来何件まで増える見込みか
- 構造:データ同士に関連があるか
- 権限:ユーザーごとに閲覧できる範囲を分ける必要があるか
- 寿命:構築するシステムを数か月使うのか、数年使うのか
Excel:1人で、一時的に、既存のExcelデータを扱う場合
Excelの活用例を確認しながら、得意な用途と注意点を整理します。

Excelは、既存のファイルや集計方法を活かし、手軽にデータ管理を始められる点が強みです。主なメリットは次のとおりです。
- すでにExcelで管理しているデータをそのまま活用できます。
- 数式、ピボットテーブル、グラフなどで集計作業ができます。
- 準備不要で、今日からすぐに始められます。
- 担当者1人が手作業で管理する小規模なデータに向いています。
ただし、前提条件が1つあります。Power AppsやPower AutomateからExcelを扱う場合、データは必ずテーブルとして書式設定されている必要があります。公式ドキュメントにも「データはExcelでテーブルとして書式設定されている必要があり、テーブルになっていないデータにはPower Appsからアクセスできない」と記載されています。Excelに初めて接続するときにつまずく原因の多くは、このテーブル書式の問題です。
一方で、Excelを業務アプリのデータソースとして継続利用する場合は、次のような制約に注意が必要です。
- 同時書き込み:ファイルが最大6分間ロックされることがあり、複数のクライアントからの同時書き込みはサポートされていません。
- データ型の強制:数値の列に文字列が入力されても防げません。
- 変更履歴と監査ログ:誰が・いつ・何を変更したかが記録されません。
- ユーザーごとの権限:権限はファイル単位のため、ファイルを開ける人はすべての行を閲覧できます。
そのため、Excelは次のような小規模・一時的な用途に適しています。
- 年に1~2回程度の集計作業
- 担当者1人が管理し、他のユーザーは閲覧のみのリスト
- Power Platformの学習用テストアプリ
- 元データがすでにExcelで、その形式を維持する必要がある場合
次のような状況が出てきたら、Excel以外の保存先を検討するタイミングです。
- 「誰がファイルを開いているの?」という会話が出てきた
- 同じファイルを2人以上で編集している
- 件数が増えて、ファイルを開くたびに遅くなってきた
SharePointリスト:部署単位で、文書に関わる業務を扱う場合
SharePointリストのデータ管理例をもとに、活用しやすい場面と制約を確認します。

SharePointリストは、Microsoft 365と連携したチームや部署単位の情報管理に向いています。主な強みは次のとおりです。
- 標準コネクタのため、追加ライセンスなしでPower AppsやPower Automateから接続できます。
- レコードごとにファイルを添付でき、バージョン管理も可能です。
- Microsoft 365のアカウントやグループの権限をそのまま利用できます。
- Teamsやドキュメントライブラリと連携できます。
- 同時書き込みがExcelより安定しています。
部署単位の業務システムでSharePointが長く使われてきたのは、性能が優れているからではなく、すでに手元にあり、文書と近い場所で使え、追加費用がかからないからです。これこそがSharePointの強みです。
一方で、複雑なデータ構造や権限管理を伴う業務では、SharePointリストの次のような制約を理解しておく必要があります。
SharePointリストでも参照列(ルックアップ列)を使ってリスト同士を関連付けることはできますが、Dataverseのテーブルリレーションシップとは機能も制約も異なります。公式ドキュメントにも「SharePointリストはリレーショナルテーブルをサポートしていないため、リレーションシップが必要な場合はキー列を自分で作成する必要がある」という趣旨の記載があります。参照列はあっても、データベースのリレーションシップとは別物と考えるべきです。そのほかの主な制約は次のとおりです。
- 1つのビューで5,000件を超えるとエラーが発生し、この上限は変更できません。
- 参照列・ユーザー列・管理メタデータ列が合計12個を超えると、ビューでエラーが発生する場合があります。
- 列レベルのセキュリティを設定できません。
- アイテムが100,000件を超えるリストでは、権限の継承を解除できません。
- 委任できない関数が多くあります。
2つ目の制約は、実務で特によく遭遇する問題です。この12個には「参照」列だけでなく、ユーザー列や管理メタデータ列、さらにシステムが自動作成する「作成者」「更新者」列も含まれるため、想定より早く上限に達してしまいます。公式ドキュメントが推奨するSharePointの設計指針にも注目しておきましょう。
具体的には、「テキスト・数値・はい/いいえ・日付などのシンプルな列の種類を使う」「SharePoint側の必須列は避け、入力チェックはPower Apps側で行う」「列名に空白や特殊文字を含めない」といった内容です。つまり、SharePointをデータベースのように使おうとすると、構造が複雑になるほど問題が起きやすいということです。
SharePointリストは、例えば次のような業務に適しています。
- 申請・承認が1~2段階で完結する業務(例:備品申請、休暇申請、入館申請など)
- レコードごとにファイル添付が必要な業務(例:稟議書、報告書の回収)
- 10~50名規模の部署で、年間数百~数千件程度のデータを扱う場合
- プレミアムライセンスを利用できない環境
- 数週間以内に構築しなければならないシステム
次のような状況が続く場合は、SharePoint以外の保存先を検討することをおすすめします。
- 委任の警告を無視し、コレクションで回避し始めた:データをすべてアプリ内に取り込めば当面は動きますが、件数が増えると破綻します。
- 同じ値を2つのリストに重複して入力している:リレーションシップを持つ構造が必要になっている、最もわかりやすいサインです。
- 「この列は部長だけに見せたい」という要望が出てきた:SharePointでは列レベルのセキュリティを設定できません。Power Apps上で非表示にするのは一時しのぎにすぎません。
- 運用中のリストの列を変更するのが怖くなった:開発環境と本番環境が分離されていない証拠です。ソリューションによる管理が必要な段階です。
- 同じデータを使うアプリが3つを超えた:検証ルールをアプリごとに個別管理していると、いずれどこかで食い違いが生じます。ルールをデータ側に移すべきタイミングです。
参考:Power Apps データ ソース – Training | Microsoft Learn
すべてのバージョンの SharePoint のリスト ビューのしきい値制限の操作 | Microsoft Support

\ Excel管理、このままで大丈夫?/
脱Excelを検討すべき業務と移行の考え方をチェック
Dataverse:全社規模で、リレーションシップと権限管理が必要な業務を扱う場合
Dataverseは、複数のアプリや部署で共通のデータを扱う業務システムに向いています。主な強みは次のとおりです。
- テーブル間のリレーションシップを正式に定義できます。
- 行単位だけでなく、列レベルのセキュリティも設定できます。
- 検証がサーバー側で行われるため、アプリを経由せずにインポートされたデータにも同じルールが適用されます。
- 開発・テスト・本番環境を分離し、ソリューションを使って変更内容を展開できます。また、モデル駆動型アプリやビジネスプロセスフローも利用できます。
- Dynamics 365やCopilot Studioと同じデータ上で連携できます。
ただし、Dataverseを利用するには、ライセンスや設計・運用体制など、次の点を検討する必要があります。
- アプリを利用するユーザー全員分のプレミアムライセンス
- テーブル構造やセキュリティロールの事前設計
- 管理者・開発者としての知識
具体的には、Dataverseは次のような業務に適しています。
- マスタとトランザクションを分けて管理する業務(例:品目マスタと入出庫履歴、社員マスタと申請履歴のように、「基本情報」と「発生した記録」を分ける構造)
- 部署やロールによって閲覧できるデータが異なる業務
- 単価や個人情報など、特定の列を非表示にする必要がある業務
- 承認が複数段階あり、順序に応じてステータスが変わる業務
- 複数のアプリやフローが同じデータを共有する業務
- 運用しながら機能を追加し続ける、長期利用前提のシステム
一方で、次のような用途なら、現時点ではExcelやSharePointリストで十分な場合もあります。
- お知らせや社内名簿など、リスト1つで完結する業務
- 数人程度の小規模なチーム
- 使い捨ての一時的なシステム
関連記事:Dataverseの使い方と基本機能|テーブル・権限管理・Power Appsでの活用方法を解説
関連記事:Dataverseの料金・ライセンスを解説|無料で使える?費用・容量・導入コストを比較
SQL Serverはどのような場合に適しているか
SQL Serverは、社内にすでにSQL Serverベースのシステムがあり、そのデータをPower Platformから活用したい場合に適しています。大規模なデータや複雑なクエリにも強い、信頼性の高いデータベースです。
ただし、Power Platformと組み合わせて使う場合は、API・接続構成、ユーザー権限の管理、セキュリティポリシー、ビジネスロジック、さらにオンプレミス環境であればゲートウェイやネットワーク構成まで、個別に設計が必要になる場合があります。また、SQL ServerコネクタはDataverseと同じくプレミアムコネクタのため、「SQL Serverを使えばライセンス費用を抑えられる」というわけでもありません。
SQL Serverが汎用的なデータベースだとすれば、DataverseはPower Platformでの業務システム構築に最適化されたプラットフォームだといえます。
Dataverse for TeamsとDataverseの違い
【2026年10月時点】Dataverse for Teams環境は非推奨です。Microsoftは、2026年11月15日に新規環境作成を終了し、Dataverseにアップグレードされていない既存環境を2027年9月15日に停止、2027年10月30日に廃止すると発表しています。既存利用者は移行・アップグレードの検討が必要です。
- 容量:Teams用の環境は1チームあたり2GB(最大約100万行)です。作成できる環境数は5チーム分に加え、ライセンスを持つユーザー20人ごとに1チーム分が追加されます。容量の80%に達すると警告が表示されます。100%に達すると、既存のアプリは引き続き動作しますが、新しいアプリ、エージェント、フロー、テーブルは作成できなくなります。
- セキュリティ:Teams用の環境は、チームの所有者・メンバー・ゲストという区分をもとに動作します。通常のDataverseが提供する列レベルのセキュリティ、階層セキュリティ、部署単位のセキュリティは含まれていません。
- 機能:公式の比較表によると、Teams用の環境には高度なデータ型、非リレーショナルストレージ(ログ)、マネージドデータレイク、高度な検索およびDataverse検索、モバイルオフラインが含まれていません。プラグインなどのサーバー側の拡張も、通常のDataverseでのみ利用できます。
- Teams外での利用:Dataverse for Teamsで作成したアプリは、Teams内であればMicrosoft 365のライセンスで実行できますが、Teamsの外で実行するには別途ライセンスが必要です。
参考:Microsoft Dataverse for Teams の概要 – Power Apps | Microsoft Learn
ここまでの内容を表にまとめると、次のようになります。



比較表を見ると、Excel・SharePointリストは手軽さ、Dataverseはデータの関連付けや権限管理、SQL Serverは既存データベースの活用にそれぞれ強みがあることがわかります。Dataverse for Teamsは通常のDataverseと機能・運用条件が異なり、非推奨への変更も踏まえて選定する必要があります。
参考:Microsoft Learn:Power Platformで予定されている重要な変更
Dataverseへの切り替えを検討すべきタイミング
ここまで、データソースごとの特徴と選び方の基準を見てきました。では、ExcelやSharePointで運用しているアプリのデータ保存先はどのような場合にDataverseへの切り替えを検討すべきなのでしょうか。
判断のポイントは、単にデータ量が増えたかどうかだけではありません。より重要なのは、データの関連性・入力ルール・アクセス権限を、アプリごとに個別管理するやり方のままで運用し続けられるかどうかです。
最初はリスト1つと入力画面1つで十分だったアプリも、利用する部署や業務が増えるにつれて要件が変わっていきます。顧客情報と契約情報を結び付けたり、複数のアプリで同じステータス値を使ったり、担当者によって閲覧・編集できる範囲を分けたりする必要が出てきます。
こうした機能は、アプリの数式や自動化フローに1つずつ追加していくことも可能です。しかし、同じルールがあちこちに分散すると修正箇所が増え、一部にだけ変更が反映されるといった事態も起こりやすくなります。
Dataverseなら、こうした共通の仕組みをデータプラットフォーム側でまとめて管理できます。テーブル間のリレーションシップを定義し、サーバー側で入力を検証し、データへのアクセス権限を設定するという考え方です。
つまり、切り替えの価値は保存先を変えることそのものにあるのではありません。複数のアプリが同じデータを、同じ構造とルールで扱えるように整理できることにあります。
まとめ
Dataverseへの切り替えは、単純に件数が増えたという理由だけで決めるものではありません。データの関連性、入力ルール、アクセス権限、長期的な保守負担を整理して判断しましょう。

\ Excel管理、このままで大丈夫?/
脱Excelを検討すべき業務と移行の考え方をチェック


コメントを残す