AccessとPower Automateの連携方法と自動化できる業務

概要

この記事でわかること

• 端末内の処理を自動化
• 通知と承認を連携
• 実行環境を確認
• 重複処理を防ぐ

この記事の主な内容

1. AccessとPower Automateで自動化できる範囲
2. 連携方式を業務と保存先から選ぶ
3. 読み取りから始める導入手順
4. 通知や更新を止めない運用設計
5. 費用と実行環境を確認する
6. 小さく導入して効果を確かめる
7. よくある質問

想定読了時間：約9分

AccessとPower Automateで自動化できる範囲

AccessとPower Automateの連携では、既存の入力画面を使い続けながら、集計、ファイルの受け渡し、通知などの定型作業を自動化できます。最初に決めるのは「どのボタンを自動で押すか」ではなく、業務の開始条件と完了条件です。

例えば、毎朝の受注一覧作成なら、対象日の確定、データ抽出、出力結果の確認、関係者への案内を一つの業務として整理します。抽出だけ成功し、案内が失敗することもあるため、処理の途中状態を残す設計が必要です。

専用アクションとSQL接続を区別する

Power Automate for desktopには、Accessの起動、テーブルの読み取り、保存済みクエリやマクロの実行、終了を行う専用アクションがあります。Microsoftの資料ではAccess 2013以降が対応対象です。ただし、対応対象に含まれることと、その製品が現在サポート期間内であることは別に確認します。
［Microsoft公式資料］

一方、データベースアクションでは、接続文字列を使ってデータベースへ接続し、SQLを実行します。保存済みの業務画面を操作する方法とは異なるため、既存処理を呼ぶのか、データだけを扱うのかで選びます。
［Microsoft公式資料］

この表は設計例です。承認や通知をAccess専用アクションだけで完結させるという意味ではありません。各処理を担当するフローと接続先を分けて検討します。

連携方式を業務と保存先から選ぶ

既存Accessのマクロを活用したい場合は専用アクション、表の読み書きが中心ならSQL接続、複数のクラウドサービスから同じデータを扱いたい場合は共通データ基盤が候補になります。画面操作の自動化は、直接呼び出せる機能がない部分に絞ると保守範囲を整理できます。

クラウドフローと端末処理を分ける

クラウドフローから端末内のACCDBを扱う構成では、どの端末がどの権限でファイルを開くかを明示します。「クラウド上で動くから、担当者のPCが停止していても端末内の処理を実行できる」とは限りません。

また、SQL Server用のコネクタやゲートウェイを用意しただけで、ACCDBがSQL Serverと同じ接続対象になるわけではありません。接続対象がAccessファイルなのか、移行済みのSQL Serverなのかを設計書に書き分けます。

共通データ基盤を導入する場合は、Access側とフロー側で同じ項目を更新してよいかを決めます。例えば承認状態を双方から変更できると、遅れて届いた処理が最新の状態を上書きする可能性があります。更新元を決めるか、状態の変化を検査してから更新します。

読み取りから始める導入手順

最初の試行は、本番ファイルのコピーを使った読み取り処理にします。更新を伴わない処理で、接続、対象抽出、件数照合、終了処理までを確かめると、業務データを変更せずに問題を切り分けられます。

読み取り専用の試行を作る

1. 毎回同じ判断基準で処理できる業務を一つ選びます。対象、頻度、成果物、担当者を記録します。
2. バックアップを取得し、検証用コピーと出力先を用意します。通知先も検証用に分けます。
3. Access専用アクションまたはデータベースアクションで接続し、少量のデータを抽出します。
4. 手作業の結果と件数、対象日、金額などを照合します。0件の場合も正常終了かを決めます。
5. 異常時の終了処理とログを用意し、担当者が停止・復旧できる状態で運用へ移します。

データベースアクションで実行する読み取りSQLの例です。
Orders、OrderID、OrderDate、Statusは説明用の名称であり、実際のテーブル定義に合わせて変更します。本制作ではAccess実機での実行検証は行っていません。

SELECT TOP 20 OrderID, OrderDate, Status
FROM Orders
WHERE Status = ‘Pending’
ORDER BY OrderID;

SQLの実行後は、取得結果を検証用の出力へ渡し、接続を閉じます。エラー時にも接続の後処理が行われるようにします。検索条件へ外部入力を加える場合は、文字列をそのまま連結せず、使用する方式で安全に値を渡せるか確認してください。
［Microsoft公式資料］

専用アクションを使う場合は、対象データベースの起動後にテーブル名や保存済みクエリ名を指定します。添付ファイル型やバイナリ型のセルは読み取りアクションの制限対象なので、通常の文字・数値と同じ扱いを前提にしません。
［Microsoft公式資料］

通知や更新を止めない運用設計

業務で使う自動化には、成功時の流れと同じくらい、途中で止まった際の扱いが必要です。特に「更新は成功したが、完了応答を受け取れなかった」という状態で再実行すると、重複登録や二重通知につながります。

処理IDと再実行条件を決める

処理IDは、一回の業務処理を識別する値です。実行日時だけに頼らず、対象データのIDと業務日などを組み合わせて、同じ業務を再実行したことを判断できるようにします。処理ID、対象件数、開始時刻、終了状態をログに残します。

なお、フローの成功表示だけで業務の完了を判定しない設計も必要です。更新予定10件のうち対象が0件になった場合、技術的にはエラーにならなくても業務上は異常かもしれません。予定件数と実績、対象日、出力ファイルの存在などを合わせて確認します。

Access＋Power Automateでできることの進め方に迷ったら

既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。お気軽に現在の構成と困っている業務をご相談ください。

費用と実行環境を確認する

導入費用は、フローの作成費だけでは決まりません。実行する人、利用するコネクタ、有人・無人の実行方式、端末の準備と管理を合わせて確認します。Microsoft 365の契約があるという理由だけで、必要な機能がすべて追加費用なしとは判断できません。
［Microsoft公式資料］

有人実行と無人実行を区別する

有人実行は担当者が操作できる状況で利用する方式です。無人実行は人の操作を前提とせずに処理を進める方式で、ライセンスのほか、実行セッション、端末、認証、停止時の連絡を別途設計します。実際の契約と対象環境で必要条件を確認してください。

データベースアクションでは、Power Automate for desktopが64bitアプリケーションであり、選択可能なドライバーも64bitである点が公式資料に記載されています。Windowsのbit数だけで判断せず、Office、Access、接続プロバイダー、使用するアクションを整理します。
［Microsoft公式資料］

さらに、組織のデータポリシーでコネクタの組み合わせが制約される場合があります。試作時に使えた個人の接続を、そのまま業務の共通接続として引き継がないようにします。
［Microsoft公式資料］

小さく導入して効果を確かめる

導入判断では、手作業の時間だけでなく、監視、例外対応、更新時の修正にかかる時間も比較します。処理時間が短くても、毎日の確認や復旧が増えるなら、業務全体の負担は減らない場合があります。

効果測定と拡張の順序

例えば、日次一覧の作成を対象にするなら、実行回数、成功回数、照合不一致、担当者の作業時間を記録します。この例は評価方法の提案であり、特定の削減率を保証するものではありません。

安定後に更新や承認連携を追加し、その都度、重複実行と途中停止を試します。処理対象や利用部門が増えた場合は、端末内のファイル処理を増やし続ける前に、SQL ServerやDataverseなどへのデータ集約を検討します。製品全体の使い分けは関連記事で整理しています。必要に応じてご参照ください。

よくある質問（FAQ）

Access＋Power Automateでできることの進め方に迷ったら

既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。現在の構成と困っている業務をご相談ください。

参考情報

Microsoft：Access actions

Microsoft：Database actions

Microsoft：Run SQL queries to Microsoft Access

Microsoft：Power Platform licensing FAQs

Microsoft：Data policies

Microsoft：Run unattended desktop flows