概要
| この記事の結論 AccessとPower Appsは、DataverseやSQL Serverなどの共通データを利用する構成で併用できます。社内の集計・帳票はAccess、現場の登録・照会はPower Appsといった役割分担が可能です。ただし、ACCDBファイルそのものを共同編集する構成ではありません。双方の入力チェック、更新権限、同時更新、削除、障害時の再処理を共通の業務ルールとして設計します。 AccessとPower Appsの併用とは、共通のデータ基盤をそれぞれの画面から利用し、業務や利用者ごとに担当範囲を分ける構成です。 |
この記事でわかること
- DataverseやSQL Serverを共通データ基盤にする
- 画面に隠れた業務ルールを棚卸しする
- 共有とデータ権限は別に設定する
- 双方からの更新と競合を検証する
この記事の主な内容
- AccessとPower Appsを併用できる条件
- 共通データに接続する3つの構成
- 画面の役割と業務ルールを分担する
- 同時更新と権限のトラブルを防ぐ
- 小さく始める併用導入の手順
- まとめ
- よくある質問
想定読了時間：約9分
AccessとPower Appsを併用できる条件
AccessとPower Appsは、共通のデータ基盤を利用する構成で併用できます。社内の集計・帳票をAccessに残し、現場の登録・照会をPower Appsへ分ける方法です。Dataverseへの移行後もAccessを継続できる構成は、Microsoftの公式資料でも案内されています。
［出典：AccessデータのDataverse移行］
ACCDBファイルを共有する構成ではない
基本になるのは、双方から同じDataverseやSQL Serverなどのデータを利用する考え方です。Power AppsからACCDBのフォームやVBAをそのまま呼び出すことを前提にはしません。また、OneDrive上のACCDBを複数端末で同期することとも異なります。
共通データを使う場合でも、画面ごとに更新条件が違うと整合性は崩れます。どちらから登録できるか、どの状態から変更禁止か、削除を認めるかを先に決めます。接続が成功することは、共存運用の出発点にすぎません。
併用が適する業務を選ぶ
設計例として、社内の受注管理と請求帳票をAccessで行い、外勤担当がPower Appsで訪問記録を登録する構成があります。画面の用途が分かれているため、既存帳票を残しながら新しい入力手段を追加できます。
反対に、同じ伝票の全項目を両方の画面で自由に更新させる場合は、競合や操作差の検証が増えます。最初は閲覧だけ、次に限定した登録だけという順で対象を広げると、影響を確認しやすくなります。
共通データに接続する3つの構成
主な候補はDataverse、SQL Server、SharePointリストです。どれでも同じ構成で置き換えられるわけではなく、既存データの関連、処理、権限、運用基盤に合わせて比較します。
| 共通データ基盤 | Access側 | Power Apps側 | 主な判断材料 |
|---|---|---|---|
| Dataverse | 対応環境でリンクテーブルを利用 | Dataverseに接続 | Power Platformとの統合、型と権限、利用権 |
| SQL Server等 | ODBC等でリンク | SQL Serverコネクタを利用 | 既存DB資産、SQL処理、接続・運用体制 |
| SharePointリスト | リストをリンク | SharePointコネクタを利用 | シンプルなリスト業務、関連や検索の制約 |
Dataverseを共通基盤にする
AccessのテーブルをDataverseへエクスポートし、リンクテーブルを作成する方法があります。そのデータをPower Appsでも利用する構成です。Accessのフォームや帳票を残せる可能性がありますが、移行後のデータ型と更新動作を確認します。
［出典：AccessからDataverseへ移行する手順］
Dataverseへ移しても、Access画面がPower Appsへ自動変換されるわけではありません。共有されるのはデータであり、それぞれの画面の操作や業務ロジックは別に管理します。詳しい移行手順は関連記事075で扱います。
SQL Serverを共通基盤にする
すでにSQL Serverにデータがあるなら、必ずDataverseへ移す必要はありません。Access側は既存のリンクを活用し、Power Apps側はSQL Serverコネクタから接続する案を比較できます。接続方式や操作ごとの対応条件はコネクタ資料で確認します。
［出典：SQL Serverコネクタ］
オンプレミスのSQL Serverへ接続する場合は、オンプレミスデータゲートウェイなどの構成を検討します。ゲートウェイとは、クラウド側のサービスと社内データを接続するための中継機能です。稼働するPC・サーバー、更新、障害時の担当も必要です。
SharePointリストを利用する
簡単な受付や一覧管理ならSharePointリストを検討できます。Accessからリストをリンクする方法も案内されています。 ただし、複雑な親子構造、複数テーブルを一括確定する処理、大量データの検索まで、既存Accessと同じ感覚で作れるとは限りません。
［出典：Accessデスクトップデータベースの共有方法］
小さな試作では、必要な絞り込みや関連の参照、更新方法を優先して検証します。既存のMicrosoft 365契約に含まれる範囲で実現できるかも、利用する機能と契約条件に照らして確認します。
［出典：Power Platformライセンスの概要］
画面の役割と業務ルールを分担する
併用では、画面ごとの担当を明確にし、共通の制約を抜け落ちなく適用することが重要です。機能一覧と一緒に、登録・更新・承認・削除の責任範囲を作ります。
AccessのVBAに隠れたルールを見つける
既存フォームの保存前処理には、必須入力、重複確認、締め済み判定、金額計算などが入っている場合があります。Power Appsからデータを登録しても、そのAccessのVBAは実行されません。画面に埋め込まれた業務ルールを棚卸しします。
例えば、「承認済みは編集不可」という制約がAccessにしかないと、新しい入力経路から承認済みデータを変更できる可能性があります。DataverseやSQL Serverなどのデータ基盤側で担保する制約と、画面で利用者を助けるチェックを分けます。
処理の確定単位を決める
受注ヘッダーと複数明細を登録する場合、途中で失敗しても片方だけ確定しない仕組みが必要です。複数の画面操作や複数回の更新が自動的に一つの取引になるとは考えません。下書きと確定を分けるか、サーバー側の一括処理を使うかを設計します。
Power Automateなどの非同期処理を追加する場合も、実行遅延や失敗、再試行を考えます。厳密に守るべき制約を後から動く通知処理だけへ任せず、どの時点で業務上の登録が完了したと見なすかを決めてください。
同時更新と権限のトラブルを防ぐ
同じレコードへ複数の更新経路ができるため、更新競合、削除、画面への再表示を検証します。「同じデータを使うから常に一致する」という説明だけでは、利用者の操作を守れません。
表示の更新と保存の更新を区別する
Accessで変更した値がデータ基盤へ保存されても、開いたままのPower Apps画面へ即座に表示されるとは限りません。再読込や再取得のタイミングを決め、古い表示を基に誤って上書きしないようにします。
同時更新テストでは、二つの端末で同じレコードを開き、別々に変更して保存します。後の更新を拒否するか、利用者へ再読込を促すかなど、実装した動作を確認します。レコードのバージョン情報や更新日時の扱いも検討対象です。
権限を操作別に定義する
Dataverseではセキュリティロール等を使って、テーブルやレコードの操作範囲を制御します。一般利用者、承認者、管理者で、閲覧・追加・変更・削除・関連付けの必要範囲を整理します。
［出典：Dataverseのセキュリティ概念］
SQL接続でも、接続資格情報と実際のデータ権限を確認します。アプリにログインした利用者と、DBへの接続で使う主体が同じとは限りません。画面上の担当者名だけで、サーバー側の制御が行われていると判断しないでください。
削除と履歴の扱いを統一する
片方の画面で物理削除し、もう片方が履歴を前提に集計していると、業務結果が変わります。削除を禁止して無効状態にするのか、関連データごと削除するのかを共通ルールにします。監査ログやバックアップの保存範囲も確認します。
方式と変更範囲を整理したい場合は
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
小さく始める併用導入の手順
最初の対象は、業務のまとまりが小さく、更新の責任を分けやすい機能にします。少数の利用者で試し、既存Accessの結果に影響がないことを確かめてから広げます。
1 対象機能とデータを整理する
テーブル、主キー、親子関係、利用画面、帳票、外部連携を対応付けます。未使用の列や一時テーブルまで機械的に共有せず、共通で扱うデータを選びます。Accessの原本と設定は保管してください。
2 接続と権限を用意して試作する
検証環境で共通データへの接続を作り、まず閲覧、次に登録・更新の順で確認します。主キーが欠ける、型が合わない、権限が不足するといった問題を、この段階で切り分けます。
3 両方の画面と帳票で照合する
Accessから登録してPower Appsで参照し、その逆も行います。必須値、重複、同時更新、削除、失敗後の再実行を試し、帳票や集計の結果も確認します。個別画面が動くことと、一連の業務が整合することを分けて検証します。
4 運用担当と変更方法を決める
アプリ所有者、接続の管理者、DB担当、問合せ窓口を決めます。列名や型を変更すると両方の画面に影響するため、変更を検証環境で試す手順が必要です。担当者が不在でも更新や復旧ができる状態を目指します。
まとめ
AccessとPower Appsは、共通データを使い、集計・帳票と現場入力などの役割を分けて併用できます。成功の条件は、データの正本、入力チェック、権限、更新競合を両方の画面にまたがって設計することです。
接続だけを追加する前に、既存VBAが守っている業務ルールを確認しましょう。SQL Serverなど既存の基盤がある場合は、その活用も含めて比較すると、データ移行を伴わない追加方法が見つかる場合があります。
Accessの現在の構成から相談できます
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
よくある質問（FAQ)
一般的な構成では、ACCDBへ直接接続することを前提にせず、Dataverse、SQL Server、SharePointリストなどの共通データ基盤を利用します。
動きません。Power Appsから登録してもAccessのフォームイベントやVBAは実行されません。共通で必要な入力チェックや制約は、適切な実行場所へ再構成します。
同じ保存先を使っても、表示の即時反映は別の問題です。再取得、画面の再読込、オフライン同期などのタイミングを設計し、古い値での上書きを防ぎます。
候補になります。Accessの既存接続を活用し、Power AppsからSQL Serverコネクタで利用する案を比較します。認証、権限、ゲートウェイ、コネクタ制約と利用権を確認します。
参考情報
AccessデータのDataverse移行
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/migrate-access-to-dataverse
AccessからDataverseへ移行する手順
https://support.microsoft.com/en-us/access/get-started-migrate-access-data-to-dataverse
Accessデスクトップデータベースの共有方法
https://support.microsoft.com/en-us/access/ways-to-share-an-access-desktop-database
SQL Serverコネクタ
https://learn.microsoft.com/en-us/connectors/sql
Dataverseのセキュリティ概念
https://learn.microsoft.com/en-us/power-platform/admin/wp-security-cds
Power Platformライセンスの概要
https://learn.microsoft.com/en-us/power-platform/admin/pricing-billing-skus