AccessのバックエンドをDataverseへ移行し、フロントはAccessのまま使いたい——このとき必ずぶつかるのが「Power Appsの最適ライセンスはどれ？」問題です。本記事では“アプリを作らない”前提で、per user／per appの考え方と、最安でコンプライアンスを守る現実解を整理します。
結論：AccessフロントでDataverseを使うだけなら、per userがいちばん安全
最初に結論をはっきりさせます。Accessをフロントエンドとして、Dataverse（フルDataverse）のテーブルへリンクして運用する場合、監査・契約解釈の観点で最も説明しやすいのは「Power Apps Premium（per user）」です。Power Apps Premiumはユーザー単位で、割り当てられたユーザーがPower Apps／Dataverseのフル機能を利用できる前提で設計されています。
一方のper appは「特定のPower App（またはPower Pagesサイト）を、特定の環境で実行する権利」をユーザーに付与する考え方で、“アプリに紐づけて割り当てる”運用が前提です。アプリを用意せずにAccessだけでDataverseへ接続する形は、この制度設計と噛み合いにくく、監査時の説明が難しくなります。
今回の前提を整理：何をしたいのか
- Accessのバックエンド（約50MB）をDataverseへ移行する
- フロントエンドはAccessを継続（既存フォーム・レポートを活かす）
- AccessからDataverseテーブルにリンクして利用する
- 利用者は10名
- Power Appsの業務アプリは基本的に作らない（できれば）
- 月額コストは最小化したいが、合法運用（ライセンス解釈で揉めない）を優先したい
なぜ「Access＋Dataverse」だとライセンスがややこしく見えるのか
DataverseはPower Platformの中核データ基盤で、一般にフルDataverseはプレミアム領域として扱われます。Power Appsの各プランは「どのユーザーが、どの範囲のPower Apps／Dataverse機能を使えるか」を決める仕組みで、特にper appは“アプリ（またはサイト）単位の権利付与”を軸に制度が組まれています。
ここで悩ましいのが、AccessはPower Appsの「Canvasアプリ」や「モデル駆動型アプリ」ではない点です。Dataverseのテーブルにアクセスしていても、それが「特定アプリの実行」と同一視できるのかは、購入したプランと運用実態の整合性として説明が必要になります。だからこそ、Access-only運用ならper userが“説明コスト”を最小化できます。
まず押さえる：Power Appsの代表的な選択肢（価格・権利・容量）
2025年時点で、選択肢は大きく次の4つに整理できます（価格は米国サイトの参考値。契約形態や通貨、購入チャネルで変動します）。
| 選択肢 | 課金単位 | 主な想定 | 参考価格 | Dataverse容量の目安（テナント加算） | Access＋Dataverse適合 |
|---|---|---|---|---|---|
| Power Apps Premium | per user | ユーザーに無制限のアプリ実行・作成権 | $20/ユーザー/月（年払い等） | DB 250MB＋ファイル2GB/ユーザー | 最も整合しやすい |
| Power Apps per app | per user / per app | 特定の1アプリ（または1サイト）だけ実行 | $5/ユーザー/アプリ/月 | DB 50MB＋ファイル400MB/ライセンス | 最小アプリを用意すれば現実的。ただし説明設計が必要 |
| Power Apps per app（従量課金メーター） | per active user / app | 月に実際に使ったユーザーだけ課金 | $10/アクティブユーザー/アプリ/月 | （環境に一時的な容量付与などの扱い） | “毎月必ず使う”なら固定のper appより割高になりやすい |
| Dataverse for Teams | 対象のM365/O365に含まれる範囲 | Teams内のローコード用途 | 追加費用なしのケースあり | 環境あたり2GB（DB＋ファイル合算） | 要件次第。Access専用バックエンドとしては制約が多い |
per appの本質：「アプリに対して割り当てる」ライセンス
per appプランは、管理ドキュメントでも「特定のビジネスシナリオのために、特定の環境で、1つのアプリ（または1つのPower Pagesサイト）を実行する」ことを前提に説明されています。さらに、per appはライセンスプールを購入した後、環境に割り当て、ユーザーに割り当ててからアプリを共有するという管理フローが示されています。
ここが重要で、per appを選ぶなら次の2点をセットで理解しておく必要があります。
- 「アプリが存在すること」が前提になりやすい（=何に対して権利を付与したか説明できる必要がある）
- 環境が増えるとライセンスが増える可能性がある（同じアプリが別環境にあると、環境ごとに必要になる、という管理上の考え方が示されています）
後者は見落としがちです。本番と検証（別環境）をきっちり分けたい組織ほど、per appの総数が増えやすくなります。
「アプリを作らずにper appでDataverseだけ使う」は成立する？
結論から言うと、“per appを買ったが、アプリは公開せず、ユーザーはAccessだけでDataverseにアクセスする”という運用は、少なくとも公式ドキュメント上で明確に推奨・保証されている形ではありません。per appの説明はあくまで「1アプリ（1サイト）を実行する権利」であり、管理フローも“アプリ共有”を前提にしています。
したがって、今回の要件（Accessが主役・アプリを作らない）で「最安・合法」を狙う場合の結論は次のどちらかに収束します。
- 揉めないことを最優先：per user（Power Apps Premium）
- コスト優先だが説明責任も負う：最小アプリを発行してper appを割り当てる
コストを抑えてper appに寄せる現実解：最小アプリを発行して割り当てる
やり方はシンプルです。“Dataverseに触れる権利の根拠（=アプリ）を作る”ことが目的なので、業務アプリとして凝ったものにする必要はありません。
- Dataverse環境（本番用）を用意し、Dataverseデータベースを作成する
- Accessから移行（テーブル作成・データ移送・リンクテーブル作成）を実施する
- 同じ環境で、最小構成のPower Apps（Canvasまたはモデル駆動型）を作成して発行する
- 例：特定テーブルの一覧を表示するだけの1画面アプリ／検索と参照だけのモデル駆動型アプリ
- 目的：per appの「1アプリを実行する権利」という前提に寄せる
- 購入したper appライセンスを環境に割り当て、そのアプリをユーザーに共有する
- そのうえでAccess側はDataverseリンクテーブルを利用し続ける
AccessとDataverseをリンクする手順自体はMicrosoftのサポート記事として公開されており、Access側はPower Apps環境と同じ資格情報でサインインすることが前提として書かれています。
注意点：この構成は「per appの割り当て要件（アプリ共有）を満たす」ための運用設計です。ただし、ユーザーがPower Appsを実行せずAccessだけで使っている状態が、契約解釈上いつでも問題ないと断言できる公式文言は見つけにくいのが実情です。監査に強い運用にしたいなら、後述の“証跡づくり”までセットで考えるのが安全です。
10名・50MBのケースで、費用感を比較する
条件を「利用者10名」「Dataverseは1環境」「Power Appsは最小アプリを1つだけ」と仮定すると、月額の目安は次のようになります（参考価格ベース）。
| 案 | 必要ライセンス | 月額目安 | 向いている状況 |
|---|---|---|---|
| 安全重視 | Power Apps Premium（per user）×10 | $200 | 監査・内部統制が厳しい／将来の拡張（自動化・追加アプリ）があり得る |
| コスト重視 | Power Apps per app（1アプリ想定）×10 | $50 | アプリは最小でよく、運用の説明資料を作れる／環境も増やさない |
| 利用が不定期 | per app従量課金（アクティブユーザー課金） | $10 ×（その月に使った人数） | 月によって利用者が大きく変動し、毎月フル稼働しない |
「最安」を数字だけで見るとper appが勝ちやすいのは事実です。一方で、Access＋Dataverseの世界では、ライセンスそのものより“運用の説明責任”がコストになることがあります。差額が大きいほど魅力的に見えますが、監査対応や契約見直しの手戻りが発生すると一気に逆転します。どこまでリスクを許容するかが最終判断ポイントです。
容量は十分？ 50MBなら“容量”より先に見るべきものがある
50MB規模で10名利用なら、純粋な容量だけで困るケースは多くありません。Power Apps Premiumは1ユーザーあたりDB 250MB、ファイル2GBのDataverse容量がテナントに加算されます。per appはDB 50MB、ファイル400MBが加算される目安です。
例えば10名分の加算だけ見ても、PremiumならDB 2.5GB、per appでもDB 500MB相当が“目安として”確保されます。実際の消費はシステム領域やログ等も絡むため単純ではありませんが、少なくとも50MBのデータ量そのものは「容量が足りないからPremiumにする」という話にはなりにくいでしょう。
むしろAccessリンク運用で現場が先に困りやすいのは、次の3点です。
- パフォーマンス：AccessからDataverseリンクは遅いと感じるケースがある（特に複雑な結合や大量レコードの一覧）。
- APIリクエスト上限：Power Platformはライセンス種別で1日あたりのリクエスト上限が変わります。たとえば、paidライセンス（Premium系）は高い枠（例：40,000/24時間）で、per app等は低い枠（例：6,000/24時間）に分類されます。Accessが小さな読み書きを大量に発生させる構成だと、体感速度や運用の安定性に影響する可能性があります。
- 権限設計：Dataverseのセキュリティロール、環境へのアクセス制限（セキュリティグループなど）を設計しないと、運用開始後のトラブルが増えます。
Dataverse for Teamsは“無料っぽい”が、今回の目的に合うかは別問題
Dataverse for Teamsは、対象のMicrosoft 365ライセンスで利用できる範囲として提供され、環境あたり2GBの合算ストレージなど、フルDataverseとは別の枠で管理されます。
一見「これで十分では？」となりがちですが、注意点があります。
- Dataverse for TeamsはTeams内のローコード用途を主軸にした位置づけで、フルDataverseの機能差・制約があります。
- Microsoft 365に含まれるDataverse機能は「Microsoft 365アプリが自分の機能を拡張するためにDataverseを使う」範囲に限定され、カスタムアプリやカスタム用途のDataverse利用を無制限に許すものではないと明記されています。
「Accessをフロントにして、Teamsとは独立して業務DBとして運用したい」という文脈では、Dataverse for Teamsを選ぶことで要件が満たせない、もしくは後からフルDataverseにアップグレードせざるを得ない、といった手戻りが起こりやすい点に注意してください。
“揉めない運用”に寄せるなら：per user（Premium）を選ぶべき条件
次の条件に1つでも強く当てはまるなら、per userが無難です。
- Power Appsを作らない／作りたくない（Accessが主役）
- ライセンス解釈で揉めたくない（監査や内部統制が厳しい）
- 将来的にPower Automate等の周辺拡張の可能性がある
- DataverseのAPIリクエスト上限を余裕のある枠にしたい
Premiumの価格・権利・Dataverse容量付与は公式の価格ページやFAQで整理されています。
それでもper userを避けたいとき：per appで“合法運用”に近づけるチェックリスト
どうしても月額を下げたい場合、per appを選ぶこと自体は珍しくありません。ただし、Access-only運用に寄せるほど説明が難しくなるため、以下のチェックリストを埋めて“説明可能な形”に寄せます。
| チェック項目 | やること | 目的 |
|---|---|---|
| アプリの用意 | 最小構成でもよいのでPower Appsアプリを発行し、環境内で共有できる状態にする | per appの前提（アプリ実行権）に寄せる |
| 割り当ての証跡 | 誰に、どの環境で、どのアプリを共有したかを管理画面の出力やスクリーンショットで保管 | 監査時の説明資料にする |
| 環境の統制 | 本番環境はセキュリティグループでアクセス対象者を絞り、不要なユーザーを入れない | “使っていない人が触れる”状態を避ける |
| セキュリティロール | Accessが必要とするCRUD権限だけを付与（テーブル単位・行レベルも検討） | 過剰権限を避け、事故を減らす |
| APIリクエストの監視 | 実運用でのリクエスト消費量を観測し、上限に近づくならUI・クエリ設計を見直す | “遅い／止まる”の原因を早期に潰す |
見落としがちな“ライセンス地雷”：制限付きテーブルと複雑なサーバー側ロジック
多くのAccess移行ではカスタムテーブル中心になりますが、DataverseにはDynamics 365アプリに紐づく制限付きテーブル（restricted tables）や、プラグイン・リアルタイムワークフローなどの複雑なサーバー側ロジックを追加した場合に、必要ライセンスが変わり得るという注意点があります。
「テーブルはカスタムだから大丈夫」と思っていても、後からDynamics 365アプリを入れたり、ソリューションを導入したりすると前提が変わることがあります。運用設計の段階で“将来の追加機能”も見越しておくと、あとで揉めにくくなります。
Accessリンク運用を成功させる小技：ライセンス以外で効く現場対策
最後に、ライセンス選定と同じくらい効く“現場のコツ”をまとめます。特にAccessフロントを継続する場合、ここが弱いと「Dataverseにしたのに遅い」「結局使われない」になりがちです。
- 一覧を作り込みすぎない：大量レコードを一気に表示するフォームは避け、検索→詳細の導線にする
- 集計は分離する：重い集計はPower BI等を検討し、Accessのクエリで全部やろうとしない
- 段階移行：まずは参照系だけDataverseリンクにし、更新系は段階的に移す
- テスト環境を用意：本番の前に同じ構成で10名同時利用を模擬し、体感速度とリクエスト消費を確認する
AccessからDataverseへの移行手順（移行ウィザード、リンクテーブル作成、主キー管理など）はMicrosoftの公式手順があるので、まずはその流れに沿ってPoCを作るのがおすすめです。
よくある質問
Power Appsを作らないなら、Power Appsライセンスは不要では？
Dataverse（フル）を業務データ基盤として使う場合、一般的にはPower Apps Premium（per user）やper appなど、Dataverseのフル機能を使えるライセンス体系で整理されます。Microsoft 365に含まれるDataverseの“限定機能”は、Microsoft 365アプリが自身の機能を拡張する目的に限定され、カスタム用途の自由な利用を許すものではない、とされています。
per appにした場合、ユーザーがPower Appsを実際に起動する必要はある？
公式に「AccessだけでOK」「起動しなくてもOK」と断言できる文言は見つけにくいため、実務では“アプリを共有し、利用権の根拠を作る”ところまでを運用要件に入れるのが安全です。加えて、監査対応のために「誰がどのアプリを使える状態か」を記録しておくと説明が通りやすくなります。
まずは試しにやりたい。無料で検証できる？
検証目的であればDeveloper Planや試用版を使って環境を作り、移行とリンクの検証を行うのは有効です。ただし試用・開発用の位置づけは本番利用と異なるため、運用開始時は必ず本番用の契約に切り替える前提で計画してください。
まとめ：最安を目指すほど“説明できる形”が重要になる
Accessフロントを残してDataverseに移行する場合、純粋な機能面だけでなく「ライセンスの前提と運用実態が一致しているか」が最重要です。
- アプリ無しでAccessだけで使うなら、per user（Power Apps Premium）が最も安全で説明しやすい
- 月額を下げたいなら、最小アプリを発行してper appを割り当てるのが現実解
- どちらを選んでも、権限設計・リクエスト上限・リンク性能を含む“運用設計”が成功要因になる
ライセンスは更新・改定されることがあるため、導入時点の公式ガイドと契約書（CSP/EA等）を必ず確認し、必要ならMicrosoftまたはリセラーに照会しておくと安心です。
コメント