PowerAppsでアプリを作るとき、「SharePointで足りるのか」「Dataverseにした方がいいのか」で迷いますよね。画面はすぐ作れても、データが増えたあとに権限や関係性で詰まると、作り直しがつらいです。
PowerApps Dataverseは、業務アプリを長く使うためのデータ基盤です。ただし、最初にテーブル、ライセンス、委任、セキュリティを見ておくと、あとから慌てずに済みます。
PowerApps Dataverseでできること
Dataverseは、Power Appsで使うデータをただ保存する場所ではありません。業務で使うデータをテーブルとして整理し、リレーションや権限を持たせて、アプリ全体の土台にするサービスです。
Dataverseは業務アプリ用のデータ基盤
Microsoft Learnでは、Dataverseをビジネスアプリで使うデータを安全に保存・管理するものとして説明しています。
Dataverse lets you securely store and manage data that’s used by business applications.
What is Microsoft Dataverse?
PowerApps Dataverseを一言でいうと、業務データの置き場所です。Excelのように表で見えるだけでなく、テーブル、列、リレーション、権限をまとめて扱えます。
たとえば顧客管理なら、顧客テーブル、案件テーブル、活動履歴テーブルを分けて作れます。それぞれを関連付けることで、「この顧客にひも付く案件だけを見る」という画面を自然に作れます。
Dataverseは保存先というより、業務データのルールを持った基盤です。アプリ画面より先に、何をテーブルとして持つかを決めると使いやすくなります。
逆に、単にメモを数十件保存したいだけなら、重すぎることもあります。Dataverseは便利ですが、保存先だけの感覚で選ぶと、ライセンスや設計の手間が後から気になります。
キャンバスアプリとモデル駆動型アプリで使える
Dataverseは、Power AppsのCanvasアプリでも、モデル駆動型アプリでも使えます。Canvasアプリでは、ギャラリーやフォームにDataverseテーブルを接続して、自由な画面を作ります。
モデル駆動型アプリでは、Dataverseのテーブル、フォーム、ビュー、リレーションをもとにアプリを組み立てます。データ構造がしっかりしている業務なら、画面をゼロから作り込まなくても、一覧、詳細、編集画面を整えやすいです。
| アプリの種類 | 向いている使い方 | Dataverseとの関係 |
|---|---|---|
| Canvasアプリ | 現場向けの自由な画面 | テーブルをデータソースとして接続 |
| モデル駆動型アプリ | 顧客管理や案件管理 | Dataverseの構造を中心に画面を作る |
| Power Automate | 承認や通知の自動化 | Dataverseの追加や更新をトリガーにする |
見た目を自由に作りたいならCanvasアプリ、データ構造を中心に業務アプリを整えたいならモデル駆動型アプリが合います。どちらでも、中心にあるのはDataverseのテーブルです。
テーブルとリレーションで業務を表現する
Dataverseの強みは、単体の表ではなく、複数のテーブルを関係づけられるところです。顧客、案件、担当者、問い合わせ、契約のように、業務で使う名詞を別テーブルとして持てます。
たとえば、案件テーブルに顧客への参照列を持たせると、1つの顧客に複数の案件をひも付けられます。SharePointリストでも近いことはできますが、Dataverseの方が関係性を前提に作りやすいです。
- 顧客と案件をつなぐ
- 案件と活動履歴をつなぐ
- 担当者とチームをつなぐ
- ステータスや分類を選択肢で管理する
ここを最初に整えると、画面側の式が短くなります。反対に、テーブル設計を曖昧にしたまま進むと、あとから式が複雑になりやすいです。
SharePointやExcelとの違いを先に押さえる
Dataverseを使うべきかは、機能の多さだけで決めない方がいいです。Excel、SharePoint、Dataverseはそれぞれ得意な場面が違うので、データ量、関係性、権限、ライセンスを並べて見ると判断しやすくなります。
Excelは試作に強く本番運用では弱い
Excelは試作に強いです。列を増やすのも早く、手元で編集できるので、業務の流れを整理する段階ではとても便利ですよね。
ただし、複数人で同時に使う業務アプリのデータソースとしては、限界が出やすいです。権限、履歴、入力チェック、データの整合性を考えると、Excelだけで本番運用するのは苦しくなります。
Excelは下書きや初期整理には向いていますが、Power Appsの本番データ基盤として長く使うなら、早めにSharePointやDataverseへ移す判断が必要です。
「今月だけ使う一覧」ならExcelで十分です。でも、利用者が増える、データを関連付ける、権限を分ける、履歴を残すなら、Dataverseを候補に入れた方が安心です。
SharePointは始めやすくDataverseは構造化に強い
SharePointリストは手軽さが魅力です。Microsoft 365の範囲で始めやすく、部署内の台帳や申請一覧なら、Power Appsとの相性も良いです。
Dataverseは、SharePointよりも構造化とセキュリティに強いです。複数テーブルの関係、セキュリティロール、ソリューション管理、モデル駆動型アプリまで見据えるなら、Dataverseが合います。
| 比較軸 | Excel | SharePoint | Dataverse |
|---|---|---|---|
| 始めやすさ | 高い | 高い | 中くらい |
| 複数テーブル | 苦手 | 工夫が必要 | 得意 |
| 権限管理 | 弱い | サイトやリスト中心 | ロールや行単位で設計しやすい |
| 本番運用 | 小規模向き | 部署内向き | 業務アプリ向き |
| ライセンス確認 | 少なめ | 少なめ | 必要 |
ここで大事なのは、どれが上という話にしないことです。小さく始めるならSharePoint、長く育てる業務アプリならDataverse、という分け方が実務では使いやすいです。
ライセンスと容量は早めに確認する
Dataverseを使うときは、ライセンスと容量を早めに確認します。Power Apps PremiumにはDataverse容量が含まれますが、組織の契約状況によって使える範囲が変わります。
あとから「作ったけど使う人のライセンスがない」となると、公開前停止になりかねません。特に、全社員向けや複数部署向けのアプリでは、開発前に利用者数を見積もるのが大事です。
確認したい項目は、次のとおりです。
- 利用者がPower Apps Premiumを使えるか
- Dataverseのデータ容量に余裕があるか
- 添付ファイルや画像をどこに置くか
- 開発環境と本番環境を分けるか
- Dataverse for Teamsで足りるか
ライセンスは面倒に見えますが、最初に確認しておくと後戻りが減ります。費用、人数、容量の3点だけでも押さえておくと、判断がかなり楽になります。
Dataverseテーブル設計の基本
Dataverseで一番大事なのは、画面を作る前のテーブル設計です。業務の名詞をテーブルにし、入力項目を列にし、関係性をリレーションにすると、Power Apps側の画面と式が自然に整理されます。
テーブルは業務の名詞で考える
テーブルは、業務の中に出てくる名詞で考えると作りやすいです。顧客、案件、商品、問い合わせ、申請、契約、作業履歴のように、独立して管理したいものをテーブルにします。
初心者がやりがちなのは、1つの巨大なテーブルに全部入れる作り方です。最初は楽ですが、顧客名、案件名、担当者、活動履歴、契約情報が混ざると、あとから重複が増えます。
テーブルは「一覧にしたいもの」ではなく、「業務として独立して管理したいもの」で分けると失敗しにくいです。
たとえば顧客管理なら、顧客テーブルと案件テーブルを分けます。問い合わせ履歴まで必要なら、問い合わせテーブルも分けます。このように分けることで、再利用しやすいデータになります。
列は入力と検索の両方から決める
列は、フォームで入力する項目だけでなく、あとで検索や絞り込みに使うかも考えて決めます。表示だけに使う列と、条件に使う列では、設計の重みが違います。
| 決めること | 例 | 考え方 |
|---|---|---|
| 主列 | 顧客名、案件名 | 一覧で見て意味がわかる名前にする |
| 選択肢 | 状態、分類、優先度 | 表記ゆれを防ぐ |
| 日付 | 期限、契約日、対応日 | 並び替えや期限管理に使う |
| 参照列 | 顧客、担当者 | 他テーブルとの関係を作る |
| 必須 | 件名、ステータス | 空欄だと困る項目に絞る |
選択肢をテキストで持つと、表記ゆれが出ます。「対応中」「対応しています」「作業中」が混ざると集計しづらいので、選択肢にしておく方が安全です。
ただし、なんでも必須にすると入力が重くなります。利用者が毎回迷うようなフォームは使われないので、本当に必要な列から始めましょう。
リレーションはあとから画面を楽にする
リレーションは、Dataverseらしさが出る部分です。顧客と案件、案件と活動履歴、商品と見積明細のように、テーブル同士の関係を表します。
リレーションを作ると、画面で関連データを見せやすくなります。たとえば、顧客の詳細画面に、その顧客の案件一覧を出す、といった作り方がしやすいです。
テーブル設計の順番は、次のように考えると進めやすいです。
- 業務で管理したい名詞を出す
- 名詞ごとにテーブルを作る
- 入力と検索に使う列を決める
- テーブル同士の関係を決める
- 権限と利用者を確認する
最初から完璧に作る必要はありません。ただ、テーブル、列、関係、権限の順で考えるだけで、画面を作り始めた後の迷いが減ります。
Power AppsからDataverseを使う手順
Dataverseのテーブルを作ったら、Power Apps側ではデータソースとして接続します。基本は、テーブルを追加し、ギャラリーで一覧を表示し、フォームやPatchで作成と更新を行う流れです。
テーブルを作ってデータソースに追加する
まずPower AppsでDataverseのテーブルを作り、必要な列を追加します。既存の標準テーブルを使うこともできますが、初めてなら業務に合わせたカスタムテーブルで試すと理解しやすいです。
Canvasアプリでは、データソースからDataverseテーブルを追加します。追加すると、ギャラリーの Items やフォームの DataSource に指定できるようになります。
- 顧客テーブルを作る
- 名前、区分、担当者、ステータスなどの列を作る
- CanvasアプリでDataverseテーブルを追加する
- ギャラリーに一覧表示する
- フォームで詳細と編集を作る
ここで大事なのは、表示確認だけで終わらせないことです。新規作成、編集、検索、削除まで小さく試すと、列の型や権限の問題に早く気づけます。
ギャラリーとフォームで一覧と編集を作る
一覧画面ではギャラリー、編集画面ではフォームを使うと、最初のアプリは作りやすいです。フォームはDataverseの列情報をもとにDataCardを作ってくれるので、入力画面のたたき台になります。
たとえば、顧客テーブルを一覧表示するなら、ギャラリーの Items にテーブルを指定します。
Customers検索ボックスを付けるなら、最初は前方一致のようなシンプルな条件に寄せます。
Filter(
Customers,
StartsWith(Name, txtSearch.Text)
)このように書くと、FilterとStartsWithで考えられます。複雑な文字列加工を入れる前に、まず委任しやすい形で画面を作るのがおすすめです。
最初の1画面は、一覧、詳細、編集の3つを小さく作るだけで十分です。いきなり全部の業務を再現しようとすると、設計迷子になりやすいです。
PatchやFilterは委任を意識して書く
保存はEdit formなら SubmitForm、ボタンから直接保存するなら Patch を使います。初心者は、まずフォームと SubmitForm で作り、細かい制御が必要になったらPatchを考える流れが楽です。
Patch(
Customers,
Defaults(Customers),
{
Name: txtCustomerName.Text,
Status: drpStatus.Selected
}
)Patchは自由度が高い一方で、列の型に合わせて値を渡す必要があります。選択肢、参照列、ユーザー列が絡むと、式が長くなりやすいです。
Dataverseでは、検索や絞り込みも重要です。アプリが小さいうちは気づきにくいですが、データが増えると委任の影響が出ます。Filter、LookUp、Sort、StartsWith など、よく使う式の委任可否を早めに見ておきましょう。
権限と委任でつまずかない設計にする
Dataverseは本番運用に強い反面、権限と委任を後回しにすると調査が難しくなります。「作成者は見えるのに利用者は見えない」「検索結果が一部だけ」という問題を避けるため、最初に確認しておきたいです。
セキュリティロールは最初に役割で分ける
Dataverseの権限は、セキュリティロールを中心に考えます。誰が作成できるのか、誰が編集できるのか、誰が閲覧だけなのかを、業務の役割ごとに分けます。
SharePointのようにリスト単位で考えるだけでなく、Dataverseではテーブルや行へのアクセスを設計します。この考え方に慣れるまでは少し難しいですが、運用が大きくなるほどロール管理が効いてきます。
たとえば、問い合わせ管理なら次のように分けられます。
| 役割 | できること | 注意点 |
|---|---|---|
| 受付担当 | 問い合わせを作成、更新 | 他部署のデータを見せるか決める |
| 管理者 | 全件閲覧、割り当て変更 | 権限を強くしすぎない |
| 閲覧者 | 一覧と詳細を見る | 編集不可にする |
| 外部連携 | 自動処理だけ実行 | 接続ユーザーを管理する |
権限を後から付け足すと、画面やPower Automateの動作確認が増えます。最初に閲覧、作成、編集、削除の4つだけでも分けておくと、運用に入りやすいです。
委任できる式に寄せて検索を作る
Power Appsの委任は、Dataverseでも避けて通れません。公式の委任概要では、委任できない場合に一部のデータだけを取得して処理する考え方が説明されています。
委任警告を無視すると、アプリが動いているように見えても、検索対象が一部だけになることがあります。
特に、検索画面では次の観点を確認します。
Filterで条件をシンプルに書けるかStartsWithで前方一致にできるかSortやSortByColumnsが委任できるか- 変換関数や複雑な計算を条件に入れていないか
- テストデータではなく本番想定件数で試しているか
DataverseはSharePointより大きな業務データに向きますが、何でも無制限に検索できるわけではありません。委任と件数は、画面を作る前から設計項目として見ておくのが安全です。
Dataverse for Teamsは用途を絞って使う
Dataverse for Teamsは、Teams内で小さくアプリを作るときに便利です。ただし、全社展開や本格的な運用を前提にするなら、通常のDataverse環境との違いを確認する必要があります。
「Teams内の部門アプリ」なら、Dataverse for Teamsで十分なことがあります。一方で、環境分離、容量、複雑なセキュリティ、ソリューション管理まで必要なら、通常のDataverseを検討した方がいいです。
判断に迷ったら、利用範囲、権限、容量、移行の4つを見ます。ここで不安が残るなら、最初から通常のDataverse環境で設計した方が後戻りしにくいです。
Dataverseを選ぶときは、技術だけでなく運用も一緒に決めます。誰が環境を管理するか、誰がテーブルを変更できるか、誰が本番へ反映するかを決めないと、あとから属人化しやすいです。
PowerApps Dataverseに関するよくある質問
まとめ
PowerApps Dataverseは、テーブル、リレーション、権限を持った業務データ基盤です。SharePointより設計は必要ですが、本番運用を見据えるなら心強い選択肢になります。
まずは小さなテーブルを1つ作り、Canvasアプリで一覧、編集、検索を試してください。そのうえで、ライセンス、権限、委任を確認しながら、壊れにくいアプリに育てていきましょう。
