Access から Power Apps への移行完全ガイド ── Dataverse 7ステップ・規模別TCO・VBA→Power Fx 実コード片

執筆: Koki Soga（Aurant Technologies アーキテクト・コンサルタント） 最終更新: 2026-05-15

「Access を Power Apps に移行する」という決定をしたあと、最初に詰まるのが「結局どこから手を付けるか」です。Microsoft 公式の Dataverse 移行ツールは強力ですが、業務側との合意・ライセンス選定・ガバナンス設計・VBA の扱いまでをまとめて見渡せる日本語の実装ガイドは、まだ多くありません。

本記事は、Aurant Technologies が支援してきた Access → Power Apps 案件の知見をベースに、Dataverse 移行 7 ステップ・規模別 5 年 TCO・VBA → Power Fx 実コード片 6 種・ガバナンス 3 点セットを中心に整理します。Power Apps 単体ではなく、Power Platform 全体としての設計図を提示します。

1. Access から Power Apps への移行で押さえる3つの分岐

移行の成否は、最初の 3 つの分岐で 8 割が決まります。

分岐1：どの Power Apps を使うか（Canvas / Model-driven / Power Pages） 3 種類で開発思想がまったく違います。Access フォームの感覚に近いのは Canvas、Access リレーション設計の延長は Model-driven、社外公開は Power Pages です。詳細は第 2 節で扱います。

分岐2：どのデータバックエンドを選ぶか（Dataverse / SharePoint / Azure SQL） ここを誤ると、後でライセンス費用が倍以上になります。Dataverse はリッチだが Premium ライセンス必須、SharePoint は安価だが業務データ向きではない、Azure SQL は柔軟だが運用負荷が乗る。詳細は第 3 節で扱います。

分岐3：VBA をどうするか（変換／棚卸し／捨てる） 500 行未満なら捨てて Power Fx で書き直し、500〜3,000 行なら段階変換、3,000 行超なら .NET 内製や Salesforce など別選択肢を併せて比較。詳細は Access VBA をモダン言語へ変換する完全ガイド も参照してください。

この 3 分岐を Phase 1 で確定させると、それ以降の進行が劇的に楽になります。

2. Power Apps 3種類の使い分け：Canvas／Model-driven／Power Pages

使い分けの実務判断

Canvas を選ぶケース：現場の入力業務、モバイル必須、UI レイアウトが業務の鍵。Access の「入力フォーム＋簡単な参照」を置き換える典型用途です。

Model-driven を選ぶケース：データ件数が多く、複数テーブルの参照・更新が日常業務。Dataverse とセットでないと使えません。Access のリレーショナル DB 機能を素直に置き換えるなら第一候補です。

Power Pages を選ぶケース：取引先・顧客に Web フォームで申請してもらう、認証付きポータルを提供する、など社外公開用途。Access には根本的にできなかった領域です。

混在も可能です。「Model-driven で顧客マスタを管理、Canvas で営業のモバイル入力、Power Pages で顧客ポータル」という構成は実案件で頻出します。

3. データバックエンドの選択：Dataverse／SharePoint／Azure SQL

Power Apps の費用と機能は、データソースで決まります。

選び方の原則

Access から 業務データ（顧客マスタ、受注、在庫など）を移すなら Dataverse 一択です。SharePoint List は「お知らせ一覧」「申請履歴」のような軽量なリスト用途に留めます。

Azure SQL は 既存の SQL Server 資産がある場合や、Power BI からの大量集計クエリ前提など、特定の条件で選びます。一般用途の第一候補にはなりません。詳細は Access バックエンドを Azure SQL に切り出すハイブリッド構成 を参照してください。

4. Access の機能と Power Apps の対応マッピング

Access フォームのレイアウトを自動移行する公式ツールは存在しません。フォームは必ず Canvas / Model-driven で再設計が必要です。これを「自動でできる」と説明する記事もありますが、実装すると必ず破綻します。

5. VBA → Power Fx 変換：6パターンの実コード片

Power Fx は Excel 数式の延長で書ける宣言型言語です。VBA の手続き型から発想を切り替える必要があります。

主要変換パターン

パターン1：レコード検索（DLookup）

' VBA
Dim sName As String
sName = Nz(DLookup("CustomerName", "tblCustomers", "CustomerCode='" & Me.CustomerCode & "'"), "")

// Power Fx
Set(varCustomerName,
    LookUp(Customers, customerCode = CustomerCodeInput.Text, customerName)
);
If(IsBlank(varCustomerName), Notify("該当顧客なし", NotificationType.Warning))

パターン2：レコード追加

db.Execute "INSERT INTO tblOrders (CustomerCode, Amount) VALUES ('A001', 50000)"

Patch(Orders, Defaults(Orders), { customerCode: "A001", amount: 50000 })

パターン3：条件分岐の一括更新

db.Execute "UPDATE tblOrders SET Status='Approved' WHERE Status='Pending'"

UpdateIf(Orders, status = "Pending", { status: "Approved", approvedDate: Now() })

パターン4：ループ処理

Dim rs As DAO.Recordset
Set rs = db.OpenRecordset("SELECT * FROM tblOrders WHERE Status='Pending'")
Do Until rs.EOF
    rs.Edit
    rs!Status = "Approved"
    rs.Update
    rs.MoveNext
Loop

ForAll(
    Filter(Orders, status = "Pending"),
    Patch(Orders, ThisRecord, { status: "Approved" })
)

パターン5：メッセージ表示

MsgBox "登録しました", vbInformation

Notify("登録しました", NotificationType.Success, 3000)

パターン6：エラーハンドリング

On Error GoTo ErrHandler
db.Execute "INSERT INTO ..."
Exit Sub
ErrHandler:
    MsgBox Err.Description

IfError(
    Patch(Orders, Defaults(Orders), { /* ... */ }),
    Notify("登録失敗: " & FirstError.Message, NotificationType.Error)
)

VBA から見たときの最大の発想転換は、ループを ForAll や UpdateIf に置き換えることです。Power Fx ではループは「データセット全体に対する宣言的な操作」として書きます。kintone JS / Apex / Python / C# も含めた 5 言語並列の変換表は、Access VBA をモダン言語へ変換する完全ガイド にまとめてあります。

6. Dataverse へのスキーマ移行 7ステップ

Access のスキーマを Dataverse に移行する標準手順です。Microsoft 公式の Dataverse 移行ツールが Access に同梱されており、テーブル・リレーション・データを一括で運べます。

ステップ1：Dataverse 環境の作成

Power Platform 管理センターで対象の環境を作ります。本番に直接ではなく、まず開発環境（Sandbox）から始めることが鉄則です。

ステップ2：データ型の事前確認

Access のすべてのデータ型が Dataverse でサポートされているわけではありません。事前に確認すべき非対応・要変換のデータ型は次のとおりです。

ステップ3：Access から移行ツール起動

Access のリボン「データベース ツール」→「Dataverse に移動」→ 接続情報入力。Microsoft アカウント認証後、対象テーブルを選択します。

ステップ4：依存関係の解決

リレーションが張られているテーブルは、参照側を先に移行する必要があります。移行ツールは自動で依存関係を解析しますが、循環参照がある場合は手動で順序を指定します。

ステップ5：データ検証

移行完了後、レコード件数・主要列の値の合計・最大最小を Access 側と突合します。文字エンコード・日付フォーマット・小数点処理の差で値がずれることがあるため、ここを省略すると本切替で詰まります。

ステップ6：Power Apps 接続テスト

Canvas または Model-driven アプリを 1 つ作り、移行した Dataverse テーブルへの読み書きを確認します。ユーザー権限（セキュリティロール）もこの段階で設計します。

ステップ7：本番反映と切替

Sandbox から本番環境へのデプロイは Power Platform の Solution パッケージで行います。データ自体はもう一度移行ツールを本番に対して実行します。並行稼働期間（旧 Access と新 Power Apps を 1 〜 3 ヶ月並走）を必ず設けます。

7. Power Automate との連携：Access マクロから移行する5パターン

Access マクロや一部の VBA 自動処理は、Power Automate に分離します。アプリ内ロジック（Power Fx）と業務フロー（Power Automate）を分けることが、保守性の鍵です。

設計のコツ

Power Automate のフローは「1 業務 1 フロー」ではなく、「再利用部品＋呼び出し元フロー」の構成で書くと、後で別業務に展開しやすくなります。たとえば「PDF を作って指定先にメール送信」は子フローにし、各業務フローから呼び出します。

8. Claude Code を使った半自動変換

3,000 行を超える VBA を全部手で書き直すのは現実的ではありません。Claude Code に変換のドラフトを生成させ、人間が検証・補正するワークフローが推奨です。

標準手順

1. 1. VBA をエクスポート：.bas ファイル形式で書き出します。Access の Application.SaveAsText で自動化可能です。
2. 2. 意図のドキュメント化：Claude Code に各プロシージャの入力・出力・副作用・業務目的を vba_doc/{module}.md として要約させます。
3. 3. マッピング合意：本記事 5 節の表を mapping.md として渡し、変換ルールを統一します。
4. 4. Power Fx 変換：マッピングに従ってドラフトを生成。コメントは日本語のまま残します。
5. 5. 人間レビュー：業務責任者を交えて仕様乖離を確認し、TODO 箇所を順次潰します。

実プロジェクトでは、3,000 行規模で 2 週間（人手のみだと 2 〜 3 ヶ月）に収まります。具体的なプロンプト 5 本と詳細手順は Access VBA をモダン言語へ変換する完全ガイド の第 8 章にまとめています。

9. ライセンス・コスト構造と規模別5年TCO試算

Power Apps のライセンスは 2 種類です。実コストはデータソース選定で大きく変わります。

規模別5年TCO試算（万円）

Dataverse + Premium ライセンス前提で計算します。

同条件の kintone と比較すると、小規模では Power Apps が約 1.4 倍、中規模では約 1.4 倍、大規模では約 1.6 倍のコスト感です（kintone 側の数値は Access vs kintone 完全比較 第 2 節を参照）。

ただし、Power Apps は 既存の Microsoft 365 環境との統合・Power BI との直結・Azure AD ベースの権限管理を標準で持つため、Microsoft エコシステム前提の組織では総合的に Power Apps が有利になることが多くなります。

コストを抑える3つの工夫

• 全員 Premium ではなく、データ閲覧のみのユーザーは Per App プランを併用
• Dataverse ストレージは「ファイル列」を多用すると急増する。添付は SharePoint / OneDrive に分離
• Power Automate Premium が必要なフローは限定する（Standard コネクタで済むなら付帯ライセンスで足りる）

10. ガバナンス：Environment／DLP／ALM の3点セット

中規模以上で必ず詰まるのがガバナンスです。Power Apps は誰でも作れるため、3 〜 6 ヶ月で「野良アプリ問題」が顕在化します。

Environment（環境分離）

開発（Dev）／検証（Test）／本番（Prod）の 3 環境を最低限分けます。「個人サンドボックス」を全社員に配布し、本番にはガバナンスを通ったアプリだけが上がる構造を作ります。

DLP（データ損失防止ポリシー）

Power Apps のコネクタは標準で 1,000 種類超あり、SNS や個人クラウドへのデータ送信も技術的には可能です。DLP ポリシーで「業務利用可」「機密データ可」「禁止」の 3 グループに分け、本番環境では機密データを業務外コネクタに渡せないようにします。

ALM（アプリケーションライフサイクル管理）

Power Platform CLI と GitHub Actions / Azure DevOps を組み合わせ、アプリを Solution パッケージで Git 管理します。50 アプリを超える組織では必須です。Solution import / export の自動化、環境間プロモートの自動化、Dataverse スキーマのバージョン管理を整備します。

ガバナンス整備は移行プロジェクトの Phase 3 〜 4 で進めますが、Phase 1 の段階で構築方針だけは決めておかないと、後から組み直すコストが膨らみます。

11. 移行プロジェクトの進め方

Phase 1 の精度がプロジェクト全体の品質を決めます。本記事の第 1 〜 3 節を Phase 1 のチェックリストとして使い、「3 分岐すべて決まったか」「Dataverse 環境設計は完了したか」「VBA 戦略は合意できたか」を必ず確認してから Phase 2 に進んでください。

まとめ

Access から Power Apps への移行は、Power Apps 単体の選択ではなく Power Platform 全体の設計として進める必要があります。本記事で押さえてほしい 4 点を再掲します。

• 3 分岐を Phase 1 で確定する（Power Apps 種類 / データソース / VBA 戦略）
• Dataverse 移行は 7 ステップで、データ型確認を省略しない
• VBA は 6 パターンで Power Fx に変換、ループは宣言型に発想転換
• 5 年 TCO は規模ごとに事前試算、Dataverse ストレージとガバナンス工数も忘れない

Aurant Technologies では Access → Power Apps 移行を Phase 1 の棚卸しから Phase 4 のガバナンス整備まで一気通貫で支援しています。VBA 行数・利用者数・現状のデータソースを共有いただければ、本記事のフレームに沿った第一案を返信します。無料相談窓口 から問い合わせ可能です。

関連記事

• Access移行 完全マスターガイド 2026（ピラー）
• Access VBA をモダン言語へ変換する完全ガイド
• Access vs kintone 完全比較
• Access バックエンドを Azure SQL に切り出すハイブリッド構成
• Access のマクロを Power Automate に移行する
• Access レポートを Looker/Power BI に移行する