概要
| この記事の結論 AccessはWindowsでの入力・集計・帳票を一体で作りやすいツールです。Power Appsはブラウザやモバイル向けの業務アプリを作るサービスで、Dataverseなどのデータ基盤と組み合わせて利用します。選定では端末だけでなく、既存帳票、業務ロジック、検索処理、権限、ライセンスと運用体制を比較します。Accessの画面を残し、現場入力だけPower Appsにする併用も選択肢です。 Power Appsとは、データソースに接続してブラウザやモバイル向けの業務アプリを作成・実行するMicrosoftのサービスです。 |
この記事でわかること
- 画面の開発環境とデータ保存先を分けて比較
- VBAや帳票は自動で引き継がれない
- 委任とデータ権限が設計上の重要点
- ライセンスと保守を含めて継続・併用・移行を判断
この記事の主な内容
- AccessとPower Appsは何が違うのか
- 端末と画面開発と帳票を比較する
- データ処理と権限の違いを押さえる
- ライセンスと運用費を比較する
- 継続と併用と移行をどう選ぶか
- まとめとツール選定の相談先
- よくある質問
想定読了時間：約9分
AccessとPower Appsは何が違うのか
AccessとPower Appsの大きな違いは、主な実行環境と、アプリ・データを組み立てる仕組みです。AccessはWindowsで入力・集計・帳票を作る用途に使われます。Power Appsはブラウザやモバイル向けの業務アプリを作り、データソースへ接続して利用するサービスです。
［出典：Power Appsの概要］
データを保存する場所も含めて比較する
AccessはACCDB内へテーブルを持つ構成だけでなく、SQL Serverなどの外部データにリンクする構成も取れます。そのため、「Accessは必ずローカル保存、Power Appsは必ずクラウド保存」という比較では、既存システムの実態を捉えられません。
［出典：Accessデスクトップデータベースの共有方法］
Power Appsの画面で使うデータは、Dataverse、SharePoint、SQL Serverなどに保存します。DataverseはPower Platformで使う業務データの基盤であり、Accessと同じような画面作成ツールそのものではありません。画面、業務処理、データ基盤を分けて検討します。
一方がすべてを置き換える関係ではない
社内PCで大量の伝票を入力し、複雑な帳票を出す業務と、現場で写真付きの点検を登録する業務では、必要な操作が異なります。製品単位で一つに決める前に、業務ごとに使いやすさと運用条件を比べることが重要です。
端末と画面開発と帳票を比較する
既存のWindows業務を活用したい場合はAccessが候補になります。ブラウザやスマートフォンを中心に入力を増やしたい場合はPower Appsを検討できます。ただし、画面の作りやすさだけでなく、帳票や周辺処理まで含めて判断します。
| 比較軸 | Access | Power Apps |
|---|---|---|
| 主な利用端末 | Windows PC | 対応ブラウザ、Power Apps Mobileなど |
| 画面 | フォームとイベントで構築 | キャンバスまたはモデル駆動で構築 |
| 業務処理 | クエリ、VBA、マクロなど | Power Fx、Dataverse側の処理、連携など |
| 帳票 | レポート機能で構築 | 出力要件に合わせ別途設計する場合がある |
| 既存資産 | 既存フォーム・帳票を活用可能 | Access資産は用途ごとに再設計 |
キャンバスアプリとモデル駆動型アプリ
Power Appsには、画面配置や操作を設計しやすいキャンバスアプリと、Dataverseのデータ構造を基に画面を構成するモデル駆動型アプリがあります。自由な現場入力を重視するか、関連データを一貫した管理画面で扱いたいかによって比較します。
［出典：Power Appsの概要］
「モデル駆動型なら要件定義がいらない」という意味ではありません。テーブルの関連、状態、権限、どの情報を見せるかは設計が必要です。また、キャンバスアプリでも、端末サイズに合うレイアウトを自分たちの業務に合わせて用意します。
VBAと帳票は自動で引き継がれない
AccessのVBAをPower Appsへ貼り付けても、そのまま動くわけではありません。入力チェック、計算、メール送信、ファイル出力、外部連携に分け、どの機能で実装するかを決めます。Power FxはPower Appsの数式言語であり、VBAの実行環境ではありません。
帳票も、印刷位置、改ページ、明細の増減、承認印、PDF保存、再発行などを確認します。Power Apps側へすべて作り直すほか、当面はAccessの帳票を残す案もあります。データ移行と帳票廃止を同時に行う必要はありません。
データ処理と権限の違いを押さえる
データ量が多い業務では、保存できる件数だけでなく、検索や集計が正しい範囲を対象に実行されるかを確認します。小さな試作で動いても、実データでは結果が欠ける可能性があります。
Power Appsの委任とは
委任とは、検索や絞り込みなどの処理をデータソース側へ任せることです。キャンバスアプリで委任できない式を使う場合、ローカル処理対象は既定500件、設定で最大2,000件です。これはPower Apps全体の保存件数の上限ではありません。
［出典：キャンバスアプリの委任とクエリ制限］
例えば、多数の顧客から対象を検索する場合、最初の一部だけを取得してから絞り込むと、存在する顧客を見つけられないことがあります。データソース、関数、演算子、列の型によって委任可否が変わるため、業務で使う式を実際の条件で検証します。
Accessでも処理場所は重要
Accessが外部DBに接続している場合も、クエリがどこで実行されるかが性能に関係します。必要な行をサーバー側で絞り込める構成と、クライアントへ大量に読み込む構成では通信量が異なります。「外部DBだから速い」とは断定できません。
アプリの共有とデータ権限を分ける
Power Appsを他の利用者へ共有しただけで、すべての権限設計が終わるわけではありません。Dataverseではロールなどにより、データを閲覧・変更できる範囲を制御します。Accessも外部DBを使う場合は、そのデータ基盤の認証や権限を含めて設計します。
［出典：Dataverseのセキュリティ概念］
重要なのは、画面のボタンを非表示にすることと、データの更新を禁止することを区別することです。複数の画面から同じデータを使う場合、共通の制約が抜け道なく適用されるかを確認します。
ライセンスと運用費を比較する
費用は、開発費だけでなく、利用権、データ基盤、保守、環境管理を含めて比較します。Microsoft 365を契約していても、Power Appsのすべての機能をその範囲で利用できるとは限りません。
Microsoft 365の権利とPremiumを区別する
一部のMicrosoft 365ライセンスには、標準コネクタなどに関する限定的な利用権が含まれます。Dataverseを使う独立したカスタムアプリやPremium機能では、別の利用権が必要になる場合があります。契約と実際の接続先を対応させて確認します。
［出典：Power Platformライセンスの概要］
無料のDeveloper Planは開発・テスト用であり、本番利用を無料にする仕組みではありません。また、Power AutomateやPower BIを追加する場合は、それぞれの利用条件を確認します。価格表の一つの金額だけで構成全体を見積もらないでください。
比較時にそろえる前提
| 確認項目 | 比較で明確にすること |
|---|---|
| 利用者 | 開発者、一般利用者、外部利用者の範囲 |
| データ | 保存先、接続先、容量、増加量 |
| 周辺機能 | 自動化、帳票、分析、メール・ファイル連携 |
| 環境 | 開発・検証・本番の分離と運用方法 |
| 保守 | 問合せ対応、障害復旧、変更管理、引継ぎ |
月額単価を固定して説明するより、利用する機能と対象者を整理して公式の契約条件と照合する方が、導入後の追加費用を見落としにくくなります。
方式と変更範囲を整理したい場合は
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
継続と併用と移行をどう選ぶか
今の業務が安定しているなら、Accessの継続や改修も合理的です。端末や利用場所が変わる業務だけをPower Appsに分ける併用、広い範囲を置き換える移行を、業務単位で比較します。
Accessの継続を検討するケース
Windows PCでの入力が中心で、既存帳票を多く使い、保守可能な状態が保たれている場合です。性能だけが問題なら、クエリやデータ基盤、フロントエンドの配布を先に見直す余地があります。
併用を検討するケース
現場の入力をスマホへ広げつつ、社内の集計や帳票を残したい場合です。Dataverseへ移したデータをAccessとPower Appsの両方から利用する構成があります。更新ルールと権限、同時更新を設計し、二重管理にしないことが条件です。
［出典：AccessデータのDataverse移行］
移行を検討するケース
多くの業務でブラウザ・モバイル利用が必要となり、既存画面や帳票の整理も進めたい場合です。VBAと外部連携の再実装範囲を調べ、運用担当者を決めたうえで進めます。ローコードでも、仕様の管理や検証は必要です。
選定前には、一つの代表業務で検索・登録・権限・帳票を試します。見た目だけの試作では判断しづらいので、実データに近い件数や例外処理まで確認してください。併用構成は073、移行手順は074が次の検討に役立ちます。
まとめとツール選定の相談先
AccessとPower Appsの比較では、利用端末、既存資産、データ処理、権限、継続費用をそろえます。既存のWindows業務を残すか、モバイル入力を追加するか、広く業務を変えるかによって、継続・併用・移行の適切な選択が変わります。
比較に迷う場合は、画面・帳票・VBA・連携の一覧と、将来の利用者・端末を整理しましょう。どちらか一方へ決める前に、共通データを使った役割分担を検討することもできます。
Accessの現在の構成から相談できます
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
よくある質問（FAQ）
単純な後継として一括置換する関係ではありません。Access継続、Power Appsへの移行、共通データを使った併用を、業務と運用条件で比較します。
そのまま動きません。VBAが担う入力補助、整合性確認、集計、外部連携を分けて実装先を決めます。既存Accessを残す場合は、そのAccess側でVBAを利用します。
利用範囲によります。一部のMicrosoft 365には限定的な利用権がありますが、Premium機能やDataverseの独立したアプリなどは別の利用権を確認します。
総保存件数の上限ではありません。キャンバスアプリで委任できないクエリのローカル処理件数に関する設定です。データソースと式の委任可否を確認することになります。
参考情報
Power Appsの概要
https://learn.microsoft.com/en-us/power-apps/powerapps-overview
Accessデスクトップデータベースの共有方法
https://support.microsoft.com/en-us/access/ways-to-share-an-access-desktop-database
キャンバスアプリの委任とクエリ制限
https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/delegation-overview
Power Platformライセンスの概要
https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus
Dataverseのセキュリティ概念
https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds
AccessデータのDataverse移行
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/migrate-access-to-dataverse