Dataverseは、Power Appsなどから共通の業務データを利用するためのデータプラットフォームです。テーブル間の関連付け、入力検証、権限管理、採番・集計などをデータ側で構成できることが特徴です。
この記事では、Dataverseの基本機能とPower Appsでの活用方法、運用時の注意点を、元の解説に沿って順番に紹介します。具体的な操作画面は掲載画像を参考にしてください。
＼ Excel管理、このままで大丈夫？／
脱Excelを検討すべき業務と移行の考え方をチェック
目次
データの整合性を守るDataverseの基本機能
業務データは、個々の項目が正しいだけでは十分ではありません。関連する情報同士が正しく結び付き、どの経路から入力されても必要な検証が行われ、権限を持つ人だけがアクセスできる状態を保つ必要があります。
テーブルリレーションシップと検索列：関連データを正確に結び付ける
Dataverseでは、関連する業務データを別々のテーブルで管理しながら、検索列を使って結び付けられます。顧客と契約を例に、仕組みと設計時の注意点を見ていきましょう。
顧客と契約、品目と出庫履歴、社員と申請内容のように、業務データには互いに関連する情報が数多くあります。
これらの情報を毎回手入力したり、複数のリストにコピーして管理したりすると、同じ顧客の名前に表記ゆれが生じたり、一部のリストに変更が反映されなかったりするおそれがあります。
Dataverseでは、情報を役割ごとのテーブルに分け、検索列（ルックアップ列）で関連する行を結び付けられます。たとえば契約を登録する際に、顧客名を改めて入力するのではなく、顧客テーブルに登録済みの顧客を選択するといった使い方です。
これにより、同じ情報を繰り返し入力する手間が減り、各レコードがどの顧客や品目に紐づいているかを明確に管理できます。
ただし、リレーションシップを設定するだけで、重複や誤った紐づけがすべて自動的に防げるわけではありません。必須入力、一意の識別方法、関連データを削除したときの動作まで、業務に合わせて設計する必要があります。
外部システムとデータを連携する場合は、代替キーも活用できます。社内の品番や外部システムの顧客コードなどを識別キーとして定義しておけば、既存のデータを特定して更新する連携の仕組みを作れます。
参考：Microsoft Dataverse で行を参照するために代替キーを定義する – Power Apps | Microsoft Learn
ビジネスルール：複数の入力経路に共通の検証を適用する
入力画面だけに検証を設けると、フローや外部システム経由の登録では同じルールが適用されない場合があります。ビジネスルールで検証を共通化する方法を解説します。
Power Appsでは、不正な数量が入力されたら「保存」ボタンを無効にする、といった実装が一般的です。ユーザーがその場で誤りに気づけるため便利な方法です。
しかし、Power Automateや外部システム経由でデータが登録される場合、Power Appsの画面での検証だけでは不十分です。画面を経由しない入力にも、必要な検証が適用されなければなりません。
Dataverseのビジネスルールは、条件に応じた値の設定や入力検証を構成できる機能です。適用範囲を「エンティティ」に設定するとサーバー側でも実行されるため、Power Appsの画面以外の経路から保存されるデータにも共通の検証を適用できます。
たとえば、「申請数量が0以下ならエラーを表示する」というルールをテーブルに設定しておけば、アプリごとに同じ検証を個別に実装・保守する手間が減ります。
ただし、ビジネスルールですべての業務ロジックを処理できるわけではありません。別テーブルの在庫数と比較する処理や、複数のレコードをまとめて更新する処理など、複雑なロジックには、Power Automateのフローやプラグインなど、別のサーバー側の仕組みを検討するのがよいでしょう。
また、ビジネスルールによる列の表示・非表示や有効・無効の切り替えは、キャンバスアプリではサポートされていません。キャンバスアプリと組み合わせる場合は、テーブル側で担うルールと、画面側で担う表示制御を切り分けて考える必要があります。
参考：Microsoft Dataverse でビジネス ルールを作成する – Power Apps | Microsoft Learn
セキュリティロールと列レベルのセキュリティ：アクセス権限を一貫して管理する
業務システムでは、ユーザーの役割に応じてデータへのアクセス範囲を分ける必要があります。Dataverseの権限管理の仕組みを確認しましょう。
業務システムでは、ユーザーによってアクセスできるデータが異なります。たとえば一般社員は自分の申請内容のみ、部署の担当者は自部署の申請内容、管理者はすべての申請内容を確認できる、といった具合です。
このとき、アプリ画面でフィルターをかけたり項目を非表示にしたりするだけでは、アクセス権限を制御できているとはいえません。画面に表示されないことと、元データにアクセスできないことは別物だからです。
SharePointでも、サイト・リスト・アイテム単位で権限を設定できます。Dataverseではさらに、ユーザー・チーム・部署（ビジネスユニット）・セキュリティロールを組み合わせた権限モデルにより、組織や業務に合わせたアクセス範囲を柔軟に構成できます。
セキュリティロールでは、テーブルに対する読み取り・作成・書き込み・削除などの権限と、アクセスできる行の範囲を設定します。さらに、列レベルのセキュリティに対応した列ではセキュリティを有効にすると、列セキュリティプロファイルを通じて読み取り・作成・更新の権限を管理できます。
関連記事：Dataverseとは？特徴・できること・Power Appsでの活用方法をわかりやすく解説
繰り返し作業を減らすDataverseの機能
リレーションシップとセキュリティがデータ管理の土台だとすれば、列の機能はアプリ開発時の繰り返し作業を減らしてくれる存在です。
文書番号の採番、関連データの合計計算、共通の選択肢の管理などをプラットフォームの機能で構成すれば、アプリの数式や自動化フローに分散していた処理を減らせます。
オートナンバー：文書番号の採番をシンプルに
申請書や契約書の管理番号は、複数の処理が同時に動く場合も考慮して設計する必要があります。オートナンバー列でできることと制約を紹介します。
申請書や契約書に「REQ-2026-0001」のような管理番号を付けたい場面があります。
このとき、自動化フローで最後の番号を取得して1を足す方法では、同時に処理が走るケースを考慮しなければなりません。複数の処理が同じ「最後の番号」を読み取ると、番号が重複してしまうからです。
Dataverseのオートナンバー列を使えば、接頭辞と連番などを組み合わせた番号を自動で付与できます。シード値（開始番号）や最小桁数も指定できるため、独自の採番処理を作り込む手間が減ります。
ただし、オートナンバーは欠番のない連続した番号を保証するものではありません。レコードの作成がキャンセルされた場合などには番号が飛ぶことがあるため、欠番が許されない業務では、別の採番方法を設計する必要があります。
参考：Microsoft Dataverse におけるオートナンバー列 – Power Apps | Microsoft Learn
ロールアップ列と計算列：集計や計算をデータ側で処理する
複数の画面で同じ集計値や計算結果を使う場合、テーブル側で処理を定義できると便利です。ロールアップ列と計算列の違いを整理します。
顧客ごとの契約金額の合計や申請件数など、関連データをまとめて計算したい場合は、ロールアップ列を活用できます。
アプリごとに集計用の数式を作る代わりに、テーブル側に集計条件を定義しておけば、複数の画面で同じ基準の値を使いやすくなります。
ただし、ロールアップ列の自動計算は非同期で行われます。元データを変更しても即座に集計値へ反映されるわけではないため、常に最新の値が必要な業務では、計算のタイミングや更新方法を確認しておきましょう。
計算列は、数量×単価で金額を求めるように、列の値を使った計算に利用します。同じレコード内の値に加え、検索列（ルックアップ列）で関連付けられた親レコードの列を参照できる場合もあります。ただし、関連する複数のレコードを集計するロールアップ列とは用途が異なり、計算列に置き換えるだけでリアルタイム集計が実現するわけではありません。
特に、現在の在庫数を確認してから出庫を確定するような業務では、集計値を表示するだけでなく、同時にリクエストが発生しても正しく処理できるよう、別途ロジックを設計する必要があります。
参考：Power Apps でロールアップ列を定義する – Power Apps | Microsoft Learn
グローバル選択肢：複数のテーブルで同じ選択肢を使う
業務で共通のステータスや分類を使う場合は、選択肢の管理方法を統一することが重要です。グローバル選択肢の特徴と活用時の注意点を説明します。
「申請中・承認・差戻し」などのステータス値をテーブルごとに個別に定義すると、表記や選択肢の構成にばらつきが生じることがあります。
グローバル選択肢（Global Choices）は、複数の列で共有できる選択肢のセットを定義する機能です。これを参照するよう設定した列では、同じ基準の選択肢を使えます。
複数のアプリやテーブルで使う分類・ステータス値を一元管理したいときに便利です。ただし、名前が同じでも業務上の意味や変更のタイミングが異なる場合は、無理に1つにまとめず、別々に管理したほうが適切なこともあります。
Dataverseで変わるアプリ開発のスタイル
Dataverseはデータの保存先にとどまらず、複数のアプリが共通のデータや権限設定を利用する土台になります。ここでは、キャンバスアプリとモデル駆動型アプリの違いを紹介します。
Dataverseの強みは、データ管理機能だけではありません。同じテーブルをもとに用途に合ったアプリを構成し、複数の画面で共通のデータや権限設定を活用できる点も重要です。
代表的なアプリの作り方には、キャンバスアプリとモデル駆動型アプリがあります。両者は画面の作り方が異なり、ユーザーの作業内容に応じて使い分けることも、組み合わせて使うこともできます。
Dataverse＋キャンバスアプリ：業務に合わせて画面を自由に設計
キャンバスアプリは、画面レイアウトや操作の流れを自由に設計したい場合に適しています。モバイルからの申請、QRコードの読み取り、現場での点検など、特定の作業を手軽にこなしたい場面で力を発揮します。
Dataverseと組み合わせれば、画面は業務に合わせて自由に作りつつ、データの関連性やアクセス権限、サーバー側の検証はDataverse側で管理できます。
たとえば、現場の社員には必要な項目だけを入力するシンプルな画面を提供し、登録された情報は別の管理用アプリでも活用する、といった構成が可能です。
ただし、Dataverseに接続するだけで、保存や更新の処理を設計しなくてよくなるわけではありません。複数のテーブルをまとめて更新する処理や、エラー発生時に処理全体を取り消す必要がある業務では、別途処理の設計が必要です。
Dataverse＋モデル駆動型アプリ：データ管理を中心に画面を構成
モデル駆動型アプリは、Dataverseのテーブルやリレーションシップをもとに、フォーム・ビュー・ナビゲーションなどを構成するアプリです。
画面をゼロから自由にレイアウトするのではなく、データ構造や業務の流れに沿った標準化された画面を構成するため、顧客・契約管理や申請内容の確認など、多数のレコードを参照・編集する業務に適しています。
ビジネスプロセスフロー（BPF）を使えば、業務のステージを画面上に表示し、各ステージで必要な情報を入力・確認するよう案内することもできます。ただし、ステージを表示するだけで承認処理やステータス制御がすべて自動化されるわけではありません。
現場の社員はキャンバスアプリで入力し、管理者はモデル駆動型アプリで内容を確認する、という構成も可能です。この場合、2つのアプリが同じDataverseのデータを使うため、画面ごとにデータをコピーして管理する手間もかかりません。
参考：Power Apps を使用したモデル駆動型アプリの構築の概要 – Power Apps | Microsoft Learn
関連記事：DataverseとSharePointの違いとは？Excel・SQL Serverとの比較や選び方を解説
ソリューションによる展開：運用中の変更を計画的に管理する
業務アプリの公開後も安全に機能を追加・変更するには、環境を分けて構成要素を管理することが重要です。ソリューションによる展開の考え方を解説します。
業務アプリは、公開後も変化し続けます。入力項目が追加され、承認フローが変わり、新しい部署が使い始めます。
こうした変更を本番環境に直接反映すると、利用中の機能に不具合が生じるおそれがあります。業務の重要度に応じて開発・テスト・本番環境を分け、検証済みの変更を本番環境へ展開する流れが必要です。
Power Platformのソリューションは、アプリ、フロー、Dataverseのテーブル定義、セキュリティロールなどの構成要素をまとめて、環境間で移行・管理するための仕組みです。
Dataverseを使えば、データ構造と関連するアプリの構成要素をソリューションに含めて一括管理できます。これが、変更内容を別環境で検証してから本番に反映する、アプリケーションライフサイクル管理（ALM）の基盤となります。
なお、ソリューションはDataverseをデータソースとするアプリに限定された機能ではありません。ただ、SharePointリストのような外部データソースの構造は別途管理する必要があるのに対し、Dataverseならデータ構造まで含めてまとめて展開できるという利点があります。
また、ソリューションを使っても、無停止で展開できるとは限りません。業務データの移行、接続設定、変更による影響の確認などは、リリース計画に別途組み込んでおく必要があります。
参考：Power Platform におけるソリューションの概念 – Power Platform | Microsoft Learn
導入時に押さえておきたい設計のポイント
Dataverseの機能を活かすには、導入時のデータ構造・権限設計と、運用時のパフォーマンス対策が欠かせません。事前に確認すべきポイントを整理します。
まずはテーブル設計と権限設計から
Dataverseは多くの管理機能を備えていますが、どのような構造やルールを適用するかは自分たちで決める必要があります。どの情報を別テーブルに分けるか、データ同士をどう関連付けるか、誰がどの情報を閲覧・編集できるかといった設計から始めましょう。
既存のExcelやSharePointの列をそのまま移行すると、重複データや曖昧な管理基準まで一緒に持ち込んでしまうおそれがあります。切り替えは単なるデータのコピーではなく、既存の構造を見直す機会でもあります。
委任とパフォーマンスへの配慮は引き続き必要
Dataverseを使っていても、キャンバスアプリでは引き続き委任を考慮する必要があります。
委任されない数式では、データソースよりデータの取得・処理ができる件数が既定で500件（設定により最大2,000件）に制限されます。
そのため、データソースを切り替えた後も、検索・フィルター・集計の数式を見直す必要があります。データ量の増加が見込まれる場合は、実際の利用条件に近いデータで、結果の正確さと応答速度を確認しておくことが重要です。
参考：キャンバス アプリでの委任について – Power Apps | Microsoft Learn
関連記事：Dataverseの料金・ライセンスを解説｜無料で使える？費用・容量・導入コストを比較
まとめ
テーブルリレーションシップは関連するデータを結び付け、ビジネスルールは共通の入力検証を担い、セキュリティロールと列レベルのセキュリティはデータへのアクセスを制御します。こうした仕組みをデータ側に整えることで、複数のアプリで共通のルールを使いながら、それぞれの業務に合った画面を構成できます。
さらに、オートナンバーやロールアップ列、グローバル選択肢を活用すれば、個別に実装する処理を減らせます。キャンバスアプリとモデル駆動型アプリを用途に応じて組み合わせ、ソリューションで変更を管理することで、開発後の運用や改修も見据えた構成を作れます。
ただし、Dataverseを導入するだけですべての要件が自動的に満たされるわけではありません。テーブルと権限の設計に加え、集計の更新タイミング、同時更新への対応、委任、ライセンスなどを確認し、標準機能で対応する範囲と追加の実装が必要な範囲を整理することが大切です。
導入を進める際は、まず対象業務を1つ選び、必要なテーブル、入力ルール、アクセス権限を整理してみてください。そのうえで小さなアプリを作り、実際の操作や運用を確かめながら適用範囲を広げていくと、Dataverseの機能を自社の業務にどう活かせるかが見えてくるはずです。
＼ Excel管理、このままで大丈夫？／
脱Excelを検討すべき業務と移行の考え方をチェック
コメントを残す