Microsoft Dataverse

解決する課題

• 業務アプリのためにデータベースやバックエンド API を自前で構築・運用するのが重い
• 部門ごとに Excel やバラバラの DB にデータが散らばり、整合性やアクセス制御が統一できない
• ローコードで作ったアプリに、行レベルの権限管理・監査・リレーションを伴う本格的なデータ層が欲しい
• Dynamics 365 や Power Platform と、同じデータを共有して二重持ちを避けたい

これらを、ビジネスアプリ向けに管理されたデータプラットフォームとして提供することで解決します。作り手はテーブルとリレーションを定義するだけで、認可・監査・API・統合の仕組みが標準で付いてきます。

主要概念と用語

• 環境（Environment）: Dataverse データベースとアプリ・フローを束ねる境界。開発・テスト・本番を環境で分離する
• テーブル（Table）: 旧称エンティティ。行と列でデータを保持する単位。標準テーブルとカスタムテーブルがある
• 列（Column）: 旧称フィールド。テキスト・数値・日付・参照などのデータ型を持つ
• リレーションシップ: テーブル間の 1 対多・多対多のつながり。参照整合性を保ったまま関連データをたどれる
• 行（Row）/ レコード: テーブル内の 1 件のデータ
• ソリューション（Solution）: テーブルやアプリ・フローなどのカスタマイズをまとめて配布・移送する単位。ALM の基盤
• ビジネスルール / 計算列・ロールアップ列: コードを書かずに検証・自動計算を定義する仕組み
• セキュリティロール: 操作（作成・読み取り・更新・削除）と範囲を組み合わせて権限を定義する単位
• Dataflow / コネクタ: 外部ソースからデータを取り込んだり、他システムと連携したりする仕組み
• Common Data Model（CDM）: 顧客・取引先などの共通スキーマ定義。標準テーブルはこれに沿う

仕様・制限・クォータ

代表的な考え方です（具体値は変動するため定性的に示します）。

• アクセス手段: Power Apps・Power Automate からのネイティブ参照のほか、**Web API（OData ベースの REST）**でプログラムからも操作できる
• データ型: テキスト・数値・日時・選択肢（オプションセット）・参照・ファイル・画像など、業務で使う型を一通り備える
• 容量: データベース・ファイル・ログの容量はテナントに割り当てられた範囲で消費し、追加容量はライセンスで拡張する
• API 呼び出し: ユーザー/アプリ単位の **API リクエスト数に上限（スロットリング）**があり、大量処理はバッチや一括 API で平準化する
• 環境の種類: 試用・サンドボックス・本番・開発者など用途別の環境があり、本番と非本番を分けて ALM を回す
• データ所在: 環境作成時に**リージョン（データ保管地）**が決まる。コンプライアンス要件に合わせて選ぶ

内部の仕組み

Dataverse は、テーブル定義（メタデータ）と実データを管理されたデータストア上に保持し、その上に認可・監査・API・イベントの層を被せたプラットフォームです。利用者はストレージエンジンを意識せず、テーブルとリレーションのモデルだけを扱います。

アクセスは Microsoft Entra ID による認証を前提とし、すべての要求がセキュリティロールで認可されてからデータに到達します。行レベル（レコード共有・所有者・ビジネスユニット）まで踏み込んだ細かい制御が標準で効くのが特徴です。

• Web API は OData ベースで、検索・絞り込み・関連データの展開（expand）を URL で表現できる
• プラグイン / リアルタイムワークフローで、作成・更新時にサーバー側ロジックを差し込める
• 変更追跡（Change Tracking）や Synapse Link で、変更分の同期や分析基盤への連携ができる
• 監査ログにより、いつ誰がどの列を変更したかを追跡できる

設計パターン / ベストプラクティス

• 環境を用途で分離し、開発・テスト・本番をソリューションで移送して ALM を回す
• 標準テーブル（CDM）を優先し、共通の顧客・取引先などは独自テーブルを乱立させず標準に寄せる
• セキュリティロールは最小権限で設計し、ビジネスユニットと所有者で範囲を絞る
• 検証や自動計算はビジネスルール/計算列で宣言的に書き、できる範囲はコードを避ける
• 大量データはバッチ/一括 APIで扱い、API スロットリングを避ける
• 分析はトランザクション環境で重い集計をせず、Synapse Link などで分析基盤に逃がす
• カスタマイズはソリューションに含めて管理し、環境間の差分を手作業で持ち込まない

運用・監視

• Power Platform 管理センターで、環境・容量・ユーザー・データポリシーを一元管理する
• 容量レポートでデータベース/ファイル/ログの使用量を監視し、上限到達前に拡張や整理を計画する
• 監査ログを有効化し、機微なテーブルの変更履歴を追跡できるようにする
• API リクエストの使用状況を確認し、スロットリングの兆候を早期に把握する
• データ損失防止（DLP）ポリシーでコネクタの組み合わせを制御し、業務データの外部流出を防ぐ
• バックアップや復元は環境単位で行え、復元ポイントを運用要件に合わせて把握しておく

コスト

• 課金は主にライセンス（ユーザー/アプリ単位）と容量で構成される
  • Power Apps や Dynamics 365 のライセンスに一定の Dataverse 容量が含まれることが多い
  • データベース・ファイル・ログの容量超過分は追加購入で拡張する
• 大量の行や添付ファイルを持つ設計は容量コストに直結するため、保持期間や不要データの整理を設計に織り込む
• 具体的な単価・含まれる容量・無料枠は変動するため、公式の料金/ライセンスページで最新値を確認する

セキュリティ

• 認証は Microsoft Entra ID を前提とし、すべての操作がセキュリティロールで認可される
• 行レベルの細かな制御（所有者・ビジネスユニット・チーム共有）で、誰がどのレコードを見られるかを絞れる
• 列レベルセキュリティで、機微な列だけを特定ロールに限定できる
• 通信は TLS で暗号化され、保存データも暗号化される
• 監査ログで変更を追跡し、DLP ポリシーでコネクタ経由の外部連携を制御する
• **データ所在（リージョン）**を環境作成時に選び、コンプライアンス対象データの保管地を管理する

関連サービス・比較

Dataverse は「ビジネスアプリ向けに管理されたデータ層」であり、汎用のリレーショナル DB とは立ち位置が異なります。Azure SQL Database と守備範囲を整理します。

Azure 内では、汎用 DB の Azure SQL Database、分析連携の Azure Synapse Analytics、自動化の Power Automate が隣接します。Dataverse は Power Platform と Dynamics 365 の共有データ基盤という性格が強く、AWS に厳密な相当サービスはありません（強いて言えばマネージド DB と業務アプリ基盤を組み合わせた領域に近い）。

ハンズオン / CLI例

Dataverse 環境は Power Platform CLI（pac）で扱うのが一般的ですが、ここでは環境の土台にあたる Azure 側の確認と、Power Platform 管理ツールの導入例を示します。

# サインインと購読の確認（環境はテナント配下に作成される）
az login
az account show -o table

# Power Platform 管理用 CLI（pac）を .NET ツールとして導入する例
dotnet tool install --global Microsoft.PowerApps.CLI.Tool

# pac で認証し、テナント内の環境一覧を確認
pac auth create --name demo
pac admin list

# ソリューションをエクスポートして ALM の移送に使う
pac solution export \
  --path ./MySolution.zip \
  --name MySolution \
  --managed true