Power Platformの開発者にとって、Dataverse for Teamsは魅力的な選択肢の一つです。しかし、通常のDataverse環境とは異なる特性を持つため、使い始める前にその違いを理解しておくことが重要です。この記事では、Dataverse for Teamsのメリットと制限事項について、実務で役立つポイントを詳しく解説します。
Dataverse for Teamsのメリット
Dataverse for Teamsの最大のメリットは、プレミアムライセンスなしでPower AppsやPower AutomateからDataverseが使えることです。
通常、Dataverseを利用するにはPower Apps Premium以上のライセンスが必要ですが、Dataverse for Teams環境であれば、Microsoft 365ライセンス(Teams含む)のみで利用できます。これにより、追加コストをかけずにリレーショナルデータベースを活用したアプリケーション開発が可能になります。
なぜDataverseが使えるといいのか
まず、Power AppsとSharePointリストを組み合わせて開発する際に必ずぶち当たる委任の問題を、Dataverseならほとんどの場面で回避できます。
これから説明する各特性や制限事項を考慮する必要はありますが、委任問題を解決できるというだけでも絶大なメリットがあると言っても過言ではありません。
また、それ以外にも開発環境から本番用のDataverse for Teams環境へソリューションとしてアプリ・テーブル・フローをまとめて移行することで、開発環境と本番環境のテーブルを容易に分けることができるのも大きなメリットです。
SharePointリストの場合、本番環境へ移行する前に接続を繋ぎ変えてからエクスポートしなくてはならないため手間がかかりますし、フィールド名が少し違うだけでフォームやギャラリーコントロールを大幅に修正しなくてはならない、のようなことが多発します。
委任の拡張とソリューションエクスポートで大幅に工数を削減できるのは、大きなメリットです。
容量に関する特性
Dataverse for Teamsの環境容量は1チームあたり2GBまたは100万行まで
Dataverse for Teams環境で利用できるストレージ容量は、1つのチーム(Microsoft Teamsのチーム)あたり2GBまでという制限があります。そのうち、800MB弱はシステム領域として消費されるため、実際に利用可能な領域は約1.2GBです。
また、通常のDataverse環境とは違って拡張することはできません。
1.2GBというとめちゃくちゃ少ないように感じますが、テーブルに添付ファイルを付けたり、Power Appsに画像ファイルをインポートしなければそうそう超えることはありません。ストレージ制限よりも先に100万行の制限の壁にぶち当たるかもしれません。
ストレージ容量または行数の制限に当たったときは、Power Platform管理センターから実稼働環境にアップグレードすることで、リソースを別の環境に移動させずとも容量の問題を解消することができます。
※実稼働環境にアップグレードすると、その時点からDataverseコネクタの利用にプレミアムライセンスが必要になります。
Dataverse for TeamsはテナントのDataverse容量を消費しない
Dataverse for Teams環境はテナント全体のDataverse容量を消費しません。
通常のDataverse環境では、テナントに割り当てられた容量プールから消費されるため、環境が増えるとライセンスの追加購入が必要になることがあります。しかし、Dataverse for Teamsは独立した容量体系を持つため、既存のDataverse容量に影響を与えることなく利用できます。
Dataverse for Teams環境は作成上限が決まっている
一方で、テナント内で作成できるDataverse for Teams環境の数には上限があります。計算式は以下のとおりです。
Dataverse for Teams環境の作成上限 = 5 + ( テナントのMicrosoft 365 ユーザーライセンス数 ÷ 20 )
開発機能の制限
Dataverse for Teams環境にあるキャンバスアプリはTeams外で開発・実行できない
Dataverse for Teams環境で作成したキャンバスアプリは、Teams内でのみ開発・実行が可能です。Power Appsのスタジオ(Webブラウザ版)やモバイルアプリから直接アクセスすることはできません。
Power Automateのクラウドフローは通常のWebサイト上でも編集・実行できます。
Dataverse for Teams上のテーブルで作成できる列の種類には制限がある
ほとんどの列の種類はDataverse for Teamsでも共通です。システムによって自動で作成される列も共通です。しかし、一部の列には制限が存在します。
| 列の種類 | 制限内容 |
|---|---|
| 計算列(Calculated Column) | 作成不可 ※計算式列(数式列、Formulas Column)は使用可能 |
| ロールアップ列 | 作成不可 |
| 選択肢列 | テーブル内専用の選択肢列のみ。 通常のDataverseのように環境内で共通の選択肢を持つことはできません。 |
| 通貨 | 通貨の種類はDataverse for Teams環境を作成したときの地域設定により自動決定され、これを変更することはできません。 |
計算列やロールアップ列は計算式列で代用可能なので、この制約は無視できる範囲でしょう。
一方で選択肢列の制限は注意が必要です。複数のテーブルで同じ選択肢を使いたい場合、各テーブルで個別に定義しなければならず、メンテナンス性が低下します。
Dynamics 365テーブルと一部の標準テーブルが存在しない
FAXや取引先企業などの、通常のDataverse環境には標準で追加されるテーブルが、一部Dataverse for Teams環境には存在しません。
これらのテーブルを使う予定がある場合は注意してください。
モデル駆動型アプリは作成・利用できない
通常のDataverse環境では利用できるモデル駆動型アプリは、Dataverse for Teams環境では対応していません。
他の環境でモデル駆動型アプリを開発してから、ソリューション等でインポートすることもできません。
Power Appsアプリはすべてキャンバスアプリで作成する必要がありますので注意しましょう。
テーブルのフォーム・ビジネスルールなどを作成・利用できない
通常のDataverse環境では、フォームでレコードの登録・修正を行ったり、ビジネスルールによる入力検証・自動化が可能です。しかし、Dataverse for Teams環境ではこれらの機能が利用できません。
UI設計や入力検証はすべてキャンバスアプリ内に自力で実装する必要があります。開発の柔軟性は高まりますが、一方で開発工数が増える可能性もあります。
ほとんどのシステム列の値をテーブルの詳細画面で確認できない
Dataverse for Teams環境では、下記の列を除いてシステム列の値をテーブルの詳細画面で確認することができません。
- 作成者
- 修正者
- 作成日
- 修正日
列と値自体は存在するので、キャンバスアプリのテーブル コントロールやギャラリー コントロールで確認しましょう。
セキュリティ・ガバナンス
環境へのアクセス権がチームメンバーに紐づいている
Dataverse for Teams環境へのアクセス権は、Teamsのチームメンバーシップに自動的に紐づけられます。つまり、Teamsのチームに参加しているユーザーは、自動的にDataverse for Teams環境にもアクセスできるようになります。
チームメンバー全員にデータベースへのアクセスを許可したくない場合は、別のアプローチを検討する必要があります。
テーブルへのアクセス権限の設定方法や粒度が異なる
通常のDataverse環境ではセキュリティロールを活用して、チームやユーザーが環境内で利用可能な機能・テーブルを細かく制御することができます。部署(Business Unit)を利用した階層構造のアクセス権を設定したり、各テーブルのCRUDに細かいアクセス範囲を規定することもできます。
チームはEntraセキュリティグループを活用して動的にすることも可能なので、たとえば部長以上の役職に就くユーザーを入れる動的グループを作成して、それで環境のチームを作成すれば、異動が発生するたびにアクセス権のメンテナンスを行う必要がなくなります。
それに対し、Dataverse for Teams環境にはセキュリティロールという概念が存在せず、テーブルへのアクセス権は以下の5種類からしか選択できません。
| ロール名 | 作成 | 読み取り | 更新 | 削除 |
|---|---|---|---|---|
| 完全なアクセス | ○ | ○ | ○ | ○ |
| 共同作業 | ○ | ○ | △ | △ |
| 参照 | × | ○ | × | × |
| 非公開 | ○ | △ | △ | △ |
| なし | × | × | × | × |
○…すべて可
△…自分が作成したレコードのみ
×…すべて不可
また、チームに所属するユーザーはチーム内のロール(所有者・メンバー・ゲスト)で自動的に振り分けられてしまいます。ゲストはテナント外のユーザーであるため、実質2種類のロールしかないことになります。
シンプルなアクセス制御には十分ですが、複雑な権限設計が必要な業務システムには向いていません。
チームの所有者は強制的に「完全なアクセス」が付与される
また、チームの所有者はすべてのテーブルに対して強制的に「完全なアクセス」が付与され、変更することができません。
これがかなり厄介で、アプリの管理者・開発者とチームの所有者は必ずしも同一メンバーではことが多いです。アプリ管理者ではないのに他人のレコードを更新・削除できてしまうのは危険ですよね。
チームの所有者を別の業務との兼ね合いでどうしても絞れない場合は、既存のチームとは別にアプリ用のチームを作って運用するなどの対策を取る必要が出てきます。
レコードを共有できない
Dataverseにおけるレコードの共有とは、本来アクセス権を持たないユーザーやチームに、レコード1件単位でアクセス権を付与することです。
このレコードの共有をDataverse for Teams環境では利用することができません。
前述のアクセス権設定の制限も相まって、細かいアクセス権を制御が困難になります。
Power Platformの監査を利用できない
通常のDataverse環境では、監査機能を有効にすることで、誰がいつどのデータを作成・更新・削除したかを追跡できます。しかし、Dataverse for Teams環境では監査機能が利用できません。
コンプライアンスや監査要件が厳しい業務では、この制限が致命的になる可能性があります。
データの変更履歴を残す必要がある場合は、Power Automateで変更ログを取るようにするなどの対策を検討しましょう。
環境作成の制御が難しい
Dataverse for Teams環境は、チームメンバーであれば誰でも作成できます。
誰でも作成できるという表現だけ見るとポジティブに感じますが、裏を返せば無秩序に作成できてしまうとも言えます。
Teams内のPower Appsアプリでキャンバスアプリ（またはCopilot Studioエージェント）の作成先となるチームを選択すると、明示的に「このチームに環境を作成します」のような確認が行われないまま勝手に環境の作成が始まってしまいます。
さらに、試用環境や開発者環境のように作成権を特定の管理者に絞る制御項目もPower Platform管理センターにありません。
これがPower Platform管理者の悩みのタネになりがちで、いつの間にか環境が増殖し、どれが実際に利用されている環境なのか判断しにくくなり、棚卸が面倒なことになります。
また、前述の通り環境の作成数に上限があるため、本当に使いたいチームが利用開始しようと思ったら上限に到達していて作成できないということにもなりかねません。
ここまで読んだPower Platform管理者の方の中には「Dataverse for Teamsは使わせたくないな」と思った方もいるでしょう。
他の環境種別のように「PPF管理者が必要な際に払い出す」のような制御はできませんが、テナント内で完全に利用をブロックすることはできます。
詳細な方法はギークフジワラさんの記事を参考にしてください。
まとめ
ここまでデメリットや制限事項を多く挙げてしまいましたが、Dataverse for Teamsは「プレミアムライセンスは買えないけど、SharePointリストからは脱却したい！」というときに、強力な選択肢になります。
とはいえ、特性を理解せずに選んでしまうと「結局、通常のDataverseを課金する羽目になった！」ということにもなりかねませんので、本稿の内容はよく理解してから利用を決定したほうがいいと思います。
環境選定の際の参考になれば幸いです。
コメント