概要
| この記事の結論 AccessからPower Appsへの移行では、データの移行と、画面・VBA・クエリ・帳票などの再設計を分けて進めます。テーブルを移しただけでは既存業務を置き換えられません。最初に利用中の機能と業務ルールを棚卸しし、データ基盤とアプリ方式を選定します。小さな業務で試作し、権限・検索結果・帳票・例外処理を照合してから段階的に本番へ切り替えます。 AccessからPower Appsへの移行とは、既存の業務要件とデータを引き継ぎ、Power Appsを中心とした画面・処理・運用へ再構成することです。 |
この記事でわかること
- データと画面・業務処理を別々に移行する
- VBAを用途別に分類し実装先を決める
- 少量データの試作だけで完了にしない
- 本番切替と差分保全を計画する
この記事の主な内容
- Power Apps移行で引き継げるものと作り直すもの
- 既存Accessの機能を棚卸しする
- データ基盤とアプリ方式を選ぶ
- 画面と業務ロジックと帳票を再構成する
- 受入テストから本番切替まで進める
- まとめと移行計画の相談先
- よくある質問
想定読了時間：約9分
Power Apps移行で引き継げるものと作り直すもの
AccessからPower Appsへ移行するときは、データ移行とアプリ再構築を別の作業として計画します。テーブルをDataverseへ移せても、既存のフォーム、VBA、クエリ、レポートが同じ動作のPower Appsへ自動変換されるわけではありません。
［出典：AccessデータのDataverse移行］
業務要件を引き継ぐという考え方
引き継ぐ中心は、顧客や受注などのデータと、仕事を成立させる業務ルールです。現在の画面を一枚ずつ再現する前に、実際に使う機能、不要な機能、手作業で補っている機能を整理します。現行システムの不便までそのまま移さないことが重要です。
| Accessの資産 | 移行時の扱い | 確認する内容 |
|---|---|---|
| テーブルとデータ | データ基盤へ移行または既存DBを継続 | 型、キー、関連、件数、精度 |
| フォーム | Power Apps側で再構成 | 端末、入力順、操作権限 |
| クエリ | 目的と実行場所を再設計 | 検索、集計、結合、更新範囲 |
| VBAとマクロ | 業務ルールを抽出して再実装 | 条件分岐、エラー、外部連携 |
| レポート | 別方式で再作成またはAccessを併用 | 印刷、PDF、改ページ、再発行 |
最初から全機能を移さなくてもよい
現場入力や申請など、独立した業務から切り替える方法があります。Accessは既存帳票を担当し、新しいアプリは登録を担当するなど、移行途中の役割を決めます。併用期間中も、どのデータをどちらで更新するかを固定してください。
既存Accessの機能を棚卸しする
移行前に必要なのは、オブジェクトの数だけでなく、実際の業務との対応です。画面数だけから工数を見積もると、少数の画面に集中した複雑なVBAや、月末にだけ使う帳票を見落とします。
利用者と頻度を対応付ける
画面、帳票、クエリ、VBA、外部ファイルの一覧を作り、誰が、いつ、何のために使うかを記録します。日次業務だけでなく、月次締め、年度切替、過去データ訂正など、頻度の低い処理も確認します。
設計例として受注業務を調べるなら、登録画面だけでなく、在庫引当、値引き計算、承認、納品書、CSV連携まで追います。一つのボタンが複数テーブルを更新する場合は、成功・失敗の条件と処理の確定単位も記録します。
VBAを用途別に分類する
- 入力を補助する処理：初期値、表示切替、候補の絞り込み。
- 業務の整合性を守る処理：必須条件、重複禁止、締め後の変更禁止。
- データ処理：検索、集計、更新、一括取込。
- 外部連携：Excel、PDF、メール、他システムへの送受信。
分類すると、画面側に置く処理と、共通データ基盤やサーバー側で実行する処理を検討しやすくなります。元のVBAを行単位で置き換える前に、その処理が必要な理由を明らかにします。
移行対象から外す機能も決める
使われていない画面を残すと、開発と検証の範囲が広がります。ただし、最近使っていないことだけで廃止せず、年次処理や監査対応に必要かを業務担当者へ確認します。廃止する場合は、過去のデータや帳票を参照する方法を残します。
データ基盤とアプリ方式を選ぶ
Power Appsへ移行するからといって、保存先を必ず新しくする必要はありません。すでにSQL Serverを使っているなら、その活用も比較します。DataverseはPower Platformとの統合やデータ権限を含めて検討する候補です。
［出典：Power Appsの概要］［出典：SQL Serverコネクタ］
保存先を選ぶ観点
| データ基盤 | 検討しやすい状況 | 主な確認事項 |
|---|---|---|
| Dataverse | 関連データとPower Platformを一体で管理したい | 型、容量、セキュリティロール、利用権 |
| SQL Server等 | 既存DB・SQL処理を活用したい | コネクタ、認証、接続、DB運用 |
| SharePointリスト | シンプルな受付やリスト管理 | 関連、検索、更新処理、権限の適合性 |
単純にライセンス費用だけで選ぶと、必要な処理を後から複雑な連携で補うことがあります。データの関連、同時更新、検索、外部連携を代表業務で確認してから決めます。
キャンバスかモデル駆動か
画面の配置や現場の操作を細かく設計したいならキャンバスアプリ、Dataverseの関連データを統一した画面で管理したいならモデル駆動型アプリを比較します。どちらも要件に合わせた設計と検証が必要です。
［出典：Power Appsの概要］
開発・検証・本番の環境も用意します。ソリューションとは、アプリやテーブルなどの構成要素をまとめて管理する仕組みです。変更をいきなり本番へ反映せず、依存関係と接続設定を確認して移送する手順を考えます。
画面と業務ロジックと帳票を再構成する
画面の作成では、必要な業務を完了できる流れを優先します。現行フォームと同じ項目が並んでいても、検索結果や保存動作が違えば、業務の移行は完了していません。
検索結果の欠落を防ぐ
キャンバスアプリでは、データソースへ委任できない式があると、既定500件、設定最大2,000件を対象にローカル処理します。データ全体の保存上限ではありませんが、大量の顧客や履歴を検索する場合には結果の欠落につながります。
［出典：キャンバスアプリの委任とクエリ制限］
試作では数十件だけを登録して確認するのではなく、本番相当の件数と検索条件を使います。先頭付近にないデータや、該当なし、同名データ、空欄などを含めて検証します。警告表示だけでなく、返る結果が業務上正しいかを確認してください。
複数更新を一つの業務として扱う
伝票と明細を別々に保存している途中で失敗すると、不完全なデータが残る可能性があります。下書き状態と確定状態を分ける、一括処理をサーバー側へ集約するなど、失敗時に整合性を保つ設計が必要です。
Power Automateを使った通知や連携は、実行の遅延や失敗、再試行も想定します。保存ボタンを押した時点と、外部システムへ反映が終わる時点を分け、利用者にどの状態まで知らせるかを決めます。
帳票の出力要件を分解する
請求書のような帳票では、金額と改ページ、再発行時の内容、保存期間などを確認します。Accessに残す、テンプレートからPDFを生成する、別の帳票機能を使うなどの選択肢を比較します。画面が完成したあとで帳票の再現性が問題にならないよう、先に試します。
Power BIは分析・可視化の候補ですが、すべての既存帳票を同じ条件で置き換えられるとは限りません。必要な出力方式、配布先、ライセンスを個別に確認します。
方式と変更範囲を整理したい場合は
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
受入テストから本番切替まで進める
受入テストでは、利用者が仕事を最後まで完了できるかと、誤った処理が防がれるかを確認します。通常の登録だけでなく、取消し、訂正、権限不足、通信断、連携失敗も対象にします。
| テスト対象 | 照合する内容 |
|---|---|
| データ | 件数、主キー、関連、金額、日付、空欄 |
| 検索 | 本番相当件数、絞り込み、並び順、集計の対象範囲 |
| 業務処理 | 登録、更新、承認、締め、取消し、途中失敗 |
| 権限 | 閲覧できる範囲、更新・削除できない条件 |
| 帳票と連携 | PDF、改ページ、送受信、再実行、重複 |
利用者と同じ権限で確認する
開発者や管理者の権限だけでは、実際の利用者が操作できるか分かりません。一般利用者、承認者、閲覧専用などのアカウントで確認します。Dataverseのロールなど、保存先の制御も検証します。
［出典：Dataverseのセキュリティ概念］
本番切替の順序を固定する
現行側の更新停止、最終バックアップ、差分移行、照合、新アプリ公開、利用者への案内を順に実行します。照合が合わない場合に、誰が開始を見送るか、いつまでに旧側へ戻すかも決めておきます。
切戻し前に新側の更新を保全する
新アプリへ切り替えた後に登録されたデータは、旧システムのバックアップにはありません。旧側へ戻す場合は、新側の更新を取り出して保全し、反映または再入力する手順が必要です。単純なバックアップ復元を切戻し計画のすべてにしないでください。
稼働後はアプリ所有者、接続の管理者、ライセンス管理者、問合せ窓口を明確にします。無償の開発環境を本番代わりにせず、利用者と機能に合う利用権を確認してください。
［出典：Power Platformライセンスの概要］
まとめと移行計画の相談先
AccessからPower Appsへの移行は、データと業務要件を引き継ぎ、画面・処理・帳票・運用を再構成する作業です。棚卸し、方式選定、試作、受入テスト、本番切替の順に進めると、移行範囲と検証条件を具体化できます。
データだけの移行手順は関連記事075、Accessを残す共存運用は073で扱います。機能が多い場合は、対象を一つに絞った調査と試作から進め、全体の見積もりへつなげましょう。
Accessの現在の構成から相談できます
Accessの改修、データ基盤の見直し、Web・モバイル連携の検討をご相談いただけます。
利用中の画面・帳票、データ件数、利用端末、外部連携、停止可能時間を整理すると、必要な調査と対応範囲を具体化できます。
よくある質問（FAQ）
業務全体をそのまま自動変換できる前提では進めません。テーブル移行と、画面・VBA・クエリ・帳票の再構成を分けます。生成機能で作った画面も業務に合わせて検証が必要です。
必要ありません。独立した入力業務から始め、帳票などをAccessに残す段階移行ができます。ただし新旧の更新先と切替条件を明確にします。
印刷位置、改ページ、PDF保存、再発行などの要件を整理し、別の出力方式で再構成するかAccessを継続します。画面の移行だけで帳票が完成するわけではありません。
機能数に加え、VBAの複雑さ、帳票、外部連携、データ整備、権限、停止可能時間、受入条件で変わります。棚卸しと代表業務の試作で範囲を具体化して見積もります。
参考情報
Power Appsの概要
https://learn.microsoft.com/en-us/power-apps/powerapps-overview
AccessデータのDataverse移行
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/migrate-access-to-dataverse
キャンバスアプリの委任とクエリ制限
https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/delegation-overview
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
SQL Serverコネクタ
https://learn.microsoft.com/en-us/connectors/sql