概要
| この記事の結論 AccessとPower Platformは、業務全体を一方へ置き換える前に、入力、帳票、自動化、分析の役割で使い分けます。既存のAccessを残し、共通のデータ基盤にPower AppsやPower Automateを追加する構成も選べます。端末、データ量、権限、ライセンス、保守担当を合わせて比較しましょう。 |
この記事でわかること
- 業務の役割で選ぶ
- 既存Accessも活用
- 共通データで併用
- 権限と費用を確認
この記事の主な内容
- AccessとPower Platformの役割を整理する
- 業務条件から向き不向きを比較する
- Accessを残して併用する構成
- データ基盤と権限を設計する
- 費用と保守体制を比較する
- 試作から導入判断へ進む
- よくある質問
想定読了時間：約8分
AccessとPower Platformの役割を整理する
AccessとPower Platformは、業務を構成する役割で比較すると選びやすくなります。既存Accessに入力、検索、帳票、データ保存がまとまっている場合、その機能をすべて一つの製品へ移す必要があるとは限りません。
入力と自動化と分析を分けて考える
Power Platformのうち、Power Appsは業務アプリの画面、Power Automateは処理の連携や自動化、Power BIは分析に使う製品です。Dataverseはデータを保存・管理する基盤です。これらをAccessのフォーム、VBA、レポートと機械的に一対一で対応させると、操作や出力の違いを見落とします。［Microsoft公式資料］
例えば、事務担当者が毎日使う受注入力と請求書印刷はAccessに残し、営業担当者の外出先入力をPower Appsに追加する構成が考えられます。確定後の通知はPower Automate、月次傾向の分析はPower BIが担当する、という分担です。
この例は構成の考え方を示すもので、実際の導入事例や標準機能だけで完成することを示しているわけではありません。各画面の必要機能、権限、接続方法を個別に確認します。
業務条件から向き不向きを比較する
製品の選定では、利用者数だけでなく、入力の速さ、端末、帳票、共有範囲、例外処理を比較します。社内で少人数が使うシステムでも、機密性や停止時の影響が大きければ、厳密な権限管理や復旧手順が必要です。
| 比較する条件 | Accessを生かしやすい場面 | Power Platformを検討する場面 |
|---|---|---|
| 操作 | 既存の入力手順や帳票を維持したい | 端末や場所に応じた入力画面が必要 |
| 業務改善 | 既存VBAやクエリを段階的に改修 | 通知や承認をサービス間で連携 |
| データ | 既存DBと帳票の依存が大きい | 共有するデータ基盤を整えたい |
| 分析 | 個別の抽出や定型出力を行う | 共通指標を継続的に可視化 |
| 保守 | Accessの保守体制がある | 環境管理とアプリ管理を整備できる |
どちらの列も製品の絶対的な制限を表すものではありません。例えばAccessでもSQL Serverの共通データを利用でき、Power Appsにも画面設計やデータ処理の工夫が必要です。比較表は候補を絞る入口として使います。［Microsoft公式資料］
入力と帳票は実際の操作で比較する
大量入力では、キーボード操作、行の追加、コピー、エラー時の修正手順を確認します。画面が似ていても、確定のタイミングが変わると、利用者の作業時間や入力漏れに影響します。
帳票については、A4かどうかだけでなく、改ページ、罫線、合計、プリンターごとの差、PDFの保存と再発行を確認します。Power BIの分析画面を用意しただけで、既存の請求書や納品書をすべて置き換えられるとは考えません。
Accessを残して併用する構成
既存業務を動かしながら改善するなら、共通データ基盤を用いた併用が候補になります。二つのアプリに同じ情報を別々に保存する構成では、どちらが最新か、いつ同期するかという問題が増えるためです。
DataverseとSQL Serverを候補として比較する
MicrosoftはAccessのデータをDataverseへ移行し、既存のAccessデスクトップクライアントを継続して使う方法を案内しています。ただし、データ型やサイズなどの対応条件を確認する必要があり、Accessの画面やVBAがPower Appsへそのまま変換される機能ではありません。［Microsoft公式資料］
SQL ServerやAzure SQL Databaseを共通基盤とし、Accessと追加アプリがそれぞれ接続する方法も考えられます。その場合は接続方式、ネットワーク、認証、ライセンスの条件を確認します。既存のSQL資産があるか、誰がDBを管理するかも選定材料です。
共有する項目には、一意な識別子、必須項目、更新者、更新日時、状態の遷移を定義します。例えば見積番号をアプリごとに採番すると重複する可能性があります。採番の責任を共通基盤または共通処理に集約すると、併用時の判断が明確になります。
データ基盤と権限を設計する
共有できることと、誰でも同じ操作ができることは別です。閲覧、登録、修正、承認、削除、出力を分け、部門や担当者に応じて許可する範囲を決めます。画面のボタンを隠すだけでデータを保護したと判断しないことが重要です。
委任と共有範囲を確認する
Power Appsの委任とは、絞り込みなどの処理をデータソース側で実行する仕組みです。委任できない処理は既定で先頭500件、設定により最大2000件を取得して処理するため、条件に合うデータが取得範囲外にあると結果が欠ける場合があります。［Microsoft公式資料］
これは「Power Appsは2000件までしか保存できない」という意味ではありません。データソースと式の組み合わせを確認し、実際の件数で最後の方のデータも検索できるかを試します。小さいサンプルだけの試作では見つからない問題です。［Microsoft公式資料］
| 確認する対象 | 試す内容 | 判断のポイント |
|---|---|---|
| 検索 | 対象データを先頭と末尾に用意 | 取りこぼしがないか |
| 権限 | 一般利用者と管理者で操作 | 不要な閲覧や更新ができないか |
| 同時更新 | 同じ明細を別の人が編集 | 意図しない上書きがないか |
| 自動処理 | 同じ通知条件を再実行 | 重複や無限の呼び出しがないか |
AccessとPower Platformの使い分けの進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。現在の構成と困っている業務がありましたらお気軽にご相談ください。
費用と保守体制を比較する
費用は初期構築と継続運用に分けて比較します。Accessを残す案でも配布、Office更新、接続先の保守は必要です。Power Platformを導入する案では、ライセンスに加え、環境、接続、権限、アプリ更新を管理する担当者を決めます。
利用者と運用の費用を積み上げる
Power Apps、Power Automate、Power BIでは、必要となる利用権が異なります。Microsoft 365やPower BIを導入済みでも、他製品のすべての機能を使えるとは限りません。対象のコネクタ、実行形態、共有方法、利用者範囲を現行の契約条件と照合します。［Microsoft公式資料］
比較見積もりには、対象人数と役割、必要環境、データ容量、外部接続、障害対応、改修頻度を記載します。月額単価だけを並べると、管理作業や利用者増加後の費用が抜け落ちます。単価や人数が変わった際に再計算できる形で整理します。
また、コネクタの利用や組み合わせには組織のデータポリシーが関わります。開発者が個人で作った接続に本番処理が依存すると、異動や退職時に処理が止まることがあります。所有者、接続の管理者、代替担当を台帳に残します。［Microsoft公式資料］
試作から導入判断へ進む
最初の試作では、使いやすい画面を一つ作るだけでなく、移行判断を左右する機能を選びます。複雑な検索、大量入力、権限制御、重要な帳票など、失敗すると本番採用が難しくなる機能を先に確認します。
代表業務で判定する
1. 業務を入力、処理、帳票、分析、運用へ分け、残す機能と改善する機能を決めます。
2. 代表機能を試作し、接続先と更新責任を確かめます。
3. 本番相当の件数、権限、端末、通信条件で業務を試します。
4. 初期費用、継続費用、保守担当、復旧方法まで含めて採用を判断します。
導入後は、操作時間、入力の差し戻し、処理失敗、問い合わせを記録します。製品を入れたことを成果にせず、利用者の仕事が完了するまでの負担が減ったかを確認しましょう。自動化フローを具体化する段階では、関連記事手順を利用できます。
関連記事：Access＋PowerAutomateでできること
よくある質問（FAQ）
必要ありません。既存の入力や帳票をAccessに残し、モバイル入力や通知などを追加する構成もあります。変更の目的と保守体制から移行範囲を決めます。
AccessのデータをDataverseへ移す機能と、画面やVBAをPower Appsへ変換することは別です。画面、操作、計算、帳票は個別に設計・検証します。
2000件は、委任できない処理で端末側に取得する行数の設定上限です。保存件数そのものの上限ではありません。データソースと式の委任可否を確認します。
ファイルをSharePointへ保存することと、データを共通利用することは異なります。ACCDBの同時利用を同期フォルダーで実現しようとせず、SharePointリストやDataverseなど適切なデータ接続を検討します。
Power BIの導入だけでは、Power AppsやPower Automateの必要な利用権まで確認できません。使う機能、コネクタ、利用者、共有範囲ごとに契約を確認します。
AccessとPower Platformの使い分けの進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。現在の構成と困っている業務がありましたらお気軽にご相談ください。
参考情報
Microsoft：Migrate Microsoft Access data to Microsoft Dataverse
Microsoft：Query limitations Delegation and query limits
Microsoft：Power Platform licensing FAQs
Microsoft：Data policies
Microsoft：Ways to share an Access desktop database