合同会社小村ソフト
相談する
メニュー

Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計

· 更新日: · · Power Automate, RPA, 業務自動化, デスクトップフロー, クラウドフロー, PowerShell, VBA, Excel, Office, 既存資産活用, 技術相談

更新履歴(4件・最終更新 2026年08月02日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
5章が画面手順書ではなく概念設計であることを明示したうえで、変数表とサブフロー分割の構造を追加しました。アクション名に日本語UI名を併記し(図のラベルの誤りも実際のアクション名に修正)、ライセンスの章を無人実行に必要な範囲へ絞り、実行履歴の見方と標準の失敗通知の限界を追加しました。
本文中の関連記事へのリンクの文言が、リンク先の現在のタイトルと食い違っていたのを、実際のタイトルに揃えました。本文の内容は変えていません。
初版公開
この記事を引用する(DOI: 10.5281/zenodo.21589893)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村 豪(2026)「Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21589893 https://staging.comcomponent.com/blog/power-automate-business-automation-guide/

DOI(最新版)
10.5281/zenodo.21589893
DOI(この版)
10.5281/zenodo.21732888

「共有フォルダに溜まる CSV を毎朝 Excel にまとめて上長にメールする」「複数の業務システムから値を手作業でコピペして集計する」。こういう作業を Power Automate で自動化したい、という相談を最近よく受けます。

最初の小さなフローは、たいてい数十分で動くようになります。厄介なのはそこから先です。本番で動かし始めてしばらくすると、たまにエラーで止まるようになる。対象システムの画面レイアウトが少し変わっただけでフローが壊れる。パスワードの置き場所が決まらないまま、とりあえず入力変数に直書きしたままになっている。「動くフロー」はあるのに、いざというとき誰も直せない――こういう状態に陥っている案件を何度か見てきました。

Power Automate は学習コストが低く、ノーコード・ローコードで始められます。その手軽さゆえに、設計を後回しにしたまま本番運用に乗ってしまいやすいツールでもあります。この記事では、クラウドフローとデスクトップフローの違い、PowerShell や VBA との役割分担、エラー処理、UI 自動化を安定させる考え方、認証情報の扱い、ガバナンスと運用、そして Power Automate の範囲を超えるタイミングの見極め方まで、実務でつまずきやすい順に書いていきます。

1. まず結論

  • Power Automate には大きく クラウドフロー（コネクタ経由でクラウドサービスをつなぐ）と デスクトップフロー（Windows の画面操作やデスクトップアプリを自動化する RPA）の 2 系統があります。まずどちらが必要かを切り分けるのが最初の設計判断です。
  • 「PC 上の定型作業」を自動化したいだけなら、Power Automate Desktop より先に PowerShell が候補になる場面も多いです。画面のクリックや入力が必須でなければ、PowerShell のほうが保守しやすく、バージョン管理にも乗せやすいことがあります。
  • Power Automate を選ぶ価値が大きいのは、API 連携の少ない既存システムの画面を操作する必要がある場合、あるいは Microsoft 365 のコネクタ（Outlook、SharePoint、Teams など）で通知・承認フローを素早く作りたい場合です。
  • 本番運用に乗せるなら、エラー処理（On Block Error）、UI セレクターの安定化、認証情報の安全な管理、DLP ポリシーによるガバナンスの 4 点は最初から設計に組み込みます。後付けは事故のもとです。12
  • 無人実行（unattended）には、有人実行（attended）とは別のライセンス・前提条件が必要です。ライセンス設計を後回しにすると、検証環境では動いたのに本番で動かせない、という事態になります。34

この記事の知識マップ

Power Automateはコネクタでクラウドサービスをつなぐクラウドフローと、Windows画面を操作する有人・無人のデスクトップフローから成り、後者はクラウドフローから呼び出せる。無人実行にはPower Automate ProcessライセンスとPremiumユーザーによるマシン登録、フローをソリューションへ含めることが前提になり、Officeアプリの操作にはさらにMicrosoft 365 Apps for enterprise(unattended)ライセンスが要る。デスクトップフローはセレクターで画面要素を特定し、On Block Errorでエラー処理をまとめ、Get credentialアクションでAzure Key Vault等から認証情報を安全に取得する。DLPポリシーはクラウドフロー・デスクトップフロー双方のコネクタ利用を制限でき、オンプレミスの資源はオンプレミスデータゲートウェイで橋渡しする。PowerShellは.NET基盤で大量データ処理に向き、VBAが担ってきたExcel操作はOffice Scriptsへ置き換わりつつある。

Power Automateの業務自動化設計の知識マップPower Automateのクラウドフローとデスクトップフローがライセンス・エラー処理・セレクター・認証情報・DLPポリシーとどう関わり、PowerShellやVBA・Office Scriptsとどう役割分担するかを示す図。利用する利用する利用する利用する利用する前提とする前提とする前提とする前提とする利用する利用するで構成できるで構成できる利用する利用する利用する利用するの後継利用する用いるのは非推奨推奨される対応Power Automate クラウドフローPower Automate デスクトップフローセレクター(UI要素の特定方法)On Block Errorアクション有人実行(attended)無人実行(unattended)Power Automate ProcessライセンスPower Automate Premiumユーザーライセンスソリューション(Power Platform)Microsoft 365 Apps for enterprise(unattended)ライセンスGet credentialアクションAzure Key Vaultデータ損失防止(DLP)ポリシーオンプレミスデータゲートウェイクラウドフローの失敗通知VBA(Visual Basic for Applications)ExcelPowerShell.NET(Core以降)Officeスクリプト(Office Scripts)画面操作を伴わない定型のPC作業

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全21件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. Power Automateの全体像

Power Automate は単一の製品というより、複数の自動化手段をまとめたプラットフォームです。

Power Automateクラウドフローデスクトップフロー / RPAプロセスマイニングAI Builder自動化フローイベントトリガースケジュールフロー定期実行インスタントフロー手動・ボタン起動コネクタSharePoint / Outlook / Teams / SQL など有人実行ユーザーの目の前で実行無人実行サーバー/専用PCで実行UI自動化画面操作・既存アプリ連携
  • クラウドフローは、コネクタを介してクラウドサービス同士をつなぐ仕組みです。トリガーの種類によって、自動化フロー（イベント発生時）、スケジュールフロー（定期実行）、インスタントフロー（手動起動）に分かれます。
  • デスクトップフローは、Windows 上のアプリケーションや画面を直接操作する RPA（Robotic Process Automation）です。クラウドフローから呼び出すことも、単独で実行することもできます。5
  • デスクトップフローはさらに、人が画面の前にいる状態で実行する有人実行（attended）と、専用の PC やサーバー上で人の介在なしに実行する無人実行（unattended）に分かれます。4

無人実行の「専用マシン」とは、ロックされていなければよいという意味ではありません。Windows 10/11 では、接続に使うユーザーかどうかに関係なく、誰かのセッションがロック状態であっても残っていると無人実行は失敗します。Windows Server ではもう少し範囲が狭く、接続に使う同じユーザーのロックされたセッションが残っていると実行できません。保守作業や、別の管理者による RDP 接続のあとに「ロック」や「切断」で済ませてしまいがちですが、確実に全員「サインアウト」しておく必要があります。6

相談を受けるときは、まず「これはクラウドサービス同士をつなぐ話なのか、それとも画面を操作する話なのか」を切り分けるところから始めます。それだけでだいぶ見通しが良くなります。

3. クラウドフロー・デスクトップフロー・PowerShell・VBAの使い分け

同じ「自動化」でも、得意な領域はかなり違います。

観点 クラウドフロー デスクトップフロー PowerShell VBA
実行環境 Microsoft のクラウド Windows PC / サーバー Windows PC / サーバー Office アプリ内
得意な処理 SaaS 間連携、通知、承認 画面操作、レガシーアプリ連携 ファイル操作、バッチ処理、API 呼び出し Office アプリ内の操作・帳票作成
トリガー イベント、スケジュール、手動 クラウドフローから呼び出し、スケジュール タスクスケジューラ、手動 Office アプリのイベント、手動
ロジックの複雑さ 中（コネクタとコネクタを組み合わせる） 中〜低（UI操作が中心） 高（プログラミング言語として柔軟） 高（Office内に閉じる前提で柔軟）
エラー処理 フロー単位の実行履歴で確認 On Block Error、リトライ設定 try/catch、終了コード On Error Resume Next 等（弱め）
ソース管理 エクスポート（zip）で擬似的に可能 エクスポート（zip）で擬似的に可能 Git でテキスト管理しやすい ブック内蔵で管理しにくい
向くケース 承認フロー、通知、SaaS連携、Microsoft 365まわりの業務フロー API のない既存システムの画面操作、レガシーアプリ連携 大量データ処理、定期バッチ、サーバー実行、テストしやすい処理 Excel/Access内で完結する個人〜小規模チームの作業

実務でよくある誤解は、「自動化したい＝とりあえず Power Automate」と考えてしまうことです。すでに API が用意されているシステムを Power Automate Desktop で UI 操作するのは、本来であれば PowerShell や .NET から API を直接叩いたほうが安定する場面です。逆に、API のない古い業務システムや Win32 アプリの画面を操作する必要があるなら、デスクトップフローの UI 自動化が現実的な選択肢になります。

補足: Excel や VBA の制約、置き換えの考え方については、別記事「VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン」でも整理しています。Microsoft 365 上の業務フローを Office Scripts と Power Automate で組み合わせるパターンにも触れています。7

4. ライセンス ── 無人実行に必要なものだけ押さえる

ライセンス体系の全体像（Microsoft 365 に含まれるシードライセンスの範囲、標準コネクタとプレミアムコネクタの境界、Premium と Process のどちらで数えると安いか、AI Builder のクレジット）は、別記事「Power Automateのライセンス ── Microsoft 365でどこまで無料か、プレミアムが要るのはいつか」に判断表つきでまとめました。ここでは、この記事の主題である無人実行を運用に乗せるために欠かせない 3 点だけを押さえます。3

必要なもの 何に割り当てるか 落とし穴
Power Automate Process 無人実行するマシン（またはクラウドフロー1本） 有人実行だけのライセンスでは無人実行できません。以前の「無人実行アドオン（Unattended RPA add-on）」はレガシー扱いで、新規に割り当てるなら Process です384
Power Automate Premium を持つユーザー 人（マシンを登録する担当者、クラウドフローから呼び出すときの接続ユーザー） Process はユーザーライセンスの代わりになりません。マシンの登録は Premium ライセンスを持つユーザーが行う必要があり、クラウドフローからデスクトップフローを呼び出す接続のユーザーにも Premium（またはデスクトップフロー権利を含むライセンス）が必要です3
ソリューション クラウドフローに Process を割り当てる場合の前提 ソリューションとは、フロー・アプリ・接続参照などの構成要素をひとまとめにして管理し、環境間を移送するための Power Platform の入れ物です。検証段階でよく使う個人用の「マイ フロー」のままでは Process を割り当てられないため、無人実行が視野にあるなら早めにソリューションへ入れておきます39

物理マシンを自分で用意したくない場合は、Microsoft がホストするマシン・マシングループで無人実行する Power Automate Hosted Process という選択肢もあります。8

もう 1 つだけ、無人実行に限らない原則を挙げておきます。「誰のライセンスで動くか」は、誰が作ったかではなく、どう起動されるかで決まります（自動化フロー・スケジュールフローは所有者、ボタン起動のインスタントフローは実行した人、無人 RPA はマシン）。この対応関係は上記のライセンス記事に表でまとめています。いずれにせよ、ライセンス設計を後回しにすると「検証環境では動いたのに本番で動かせない」という止まり方をするので、PoC の時点で上の 3 点を確認してください。

5. 実践設計 ── 共有フォルダのCSVを集計してExcel報告書を作り、メールする

具体例として、よくある「日次レポート作成」を題材にします。

最初にこの章の性格を明示しておきます。ここで示すのは画面の手順書ではなく、アクションの構成・変数・サブフロー分割・エラー時の後始末をどう決めるかという概念設計です。Power Automate for desktop の画面の並びや操作手順は公式ドキュメントとバージョンに追随するのが確実なので、この記事では「どのアクションを、どういう粒度で、どんな変数の受け渡しで組むか」に絞ります。そのまま作れる状態に近づけるため、5.1 に変数の一覧（名前・型・値の例）、5.2 にサブフローの分割構造を載せました。

なお、この記事ではアクション名を英語 UI 名で書いています。日本語 UI で作業する場合に備えて、下のアクション表と 5.1 の変数表では日本語名 / 英語名の対応を併記します。

やりたいこと

  1. 共有フォルダにある当日分の CSV を集める
  2. 内容を集計して Excel の報告書テンプレートに書き込む
  3. 報告書を所定のフォルダへ保存する
  4. 関係者へメールで通知する
  5. 失敗したら担当者に通知し、原因をログに残す
なしありエラー発生スケジュール起動 06:30On Block Error: 集計処理Get files in folder当日分CSVを取得対象ファイルあり?対象なしを記録して終了Read from CSV file1ファイルずつループ値を集計・変数に加算Launch Excelテンプレートを開くWrite to Excel worksheet集計結果を書き込みExcelを保存して閉じるSend an email担当者へ報告書を送信実行結果をログファイルに追記正常終了エラーハンドラExcelが開いたままなら閉じるエラー内容をログに記録管理者へ失敗通知メール異常終了として記録

主なアクションと役割は次の通りです。日本語 UI での名称も併記します（公式ドキュメントの日本語版アクションリファレンスの表記です10）。

アクション（日本語名 / 英語名） 役割 設計のポイント
フォルダー内のファイルを取得 / Get files in folder 対象 CSV の一覧取得 ファイル名のパターン、当日分の絞り込み条件を明確にする
CSV を読み取ります / Read from CSV file、Excel ワークシートを読み取する / Read from Excel worksheet データの読み込み ヘッダー行の有無、文字コード（UTF-8 など）を確認する
変数の設定 / Set variable、変数を大きくする / Increase variable 集計値の保持 変数名にデータ型を意識した接頭辞をつけると読みやすい（例: txtPath、numTotal、dtToday、lstFiles。5.1 参照）
Excel の起動 / Launch Excel Excel テンプレートの操作 インスタンスの起動と終了を必ずペアで管理する（終了し忘れると EXCEL.EXE が残る）。このフローは無人実行が前提なので、RPA アカウントに Microsoft 365 Apps for enterprise（unattended）ライセンスがあるかも確認する。これがないと Office が機能制限モードで動き、対話実行時と挙動が変わることがある11
Excel ワークシートに書き込む / Write to Excel worksheet 集計結果の書き込み セル番地のハードコードを避け、名前付き範囲や見出し検索で位置を特定する
電子メールの送信 (V2) / Send an email (V2)（Office 365 Outlook） 結果の通知 添付ファイルはパスをそのまま渡せない。事前に ファイルをバイナリ データに変換 / Convert file to binary data アクションでバイナリ化し、Attachments の Name には報告書のファイル名を、ContentBytes にはそのバイナリ変数を設定する12。宛先や件名のテンプレート化も分離する
テキストをファイルに書き込む / Write text to file（追記モード） 実行ログの記録 実行日時、処理件数、結果（成功/失敗）を1行ずつ追記する

日本語名は完全な一対一対応ではなく、たとえば Office 365 Outlook の Send an email (V2) は公式の日本語ドキュメント内でも「電子メールの送信 (V2)」「メールを送信する (V2)」と訳語が揺れています。12 UI で見つからないときは英語名で検索するのが確実です。

5.1 変数の設計 ── 名前・型・値の例

変数は「後から読む人がフローだけを見て意味を追えるか」で決まります。この例なら、最低限これだけを最初に決めておきます。値は環境に合わせて読み替えてください。

変数名 型 値の例・作り方 用途
txtSourceFolder テキスト \\fileserver\daily\in 取り込み元の共有フォルダー。フロー入力にしておくと検証環境で差し替えられる
txtTemplatePath テキスト C:\ProgramData\KsReport\template.xlsx Excel 報告書テンプレートの場所
txtOutputFolder テキスト \\fileserver\daily\report 完成した報告書の保存先
txtLogPath テキスト C:\ProgramData\KsReport\logs\daily.log 実行ログの追記先
dtToday 日時 「現在の日時を取得します / Get current date and time」の出力 当日分かどうかの判定に使う
txtToday テキスト 20260630（dtToday を「datetime をテキストに変換 / Convert datetime to text」でカスタム形式 yyyyMMdd に変換） ファイル名の絞り込みと、出力ファイル名 report_20260630.xlsx の組み立てに使う
lstFiles リスト 「フォルダー内のファイルを取得」の出力 当日分 CSV の一覧。件数 0 の分岐に使う
numTotal 数値 0 で初期化し、ループ内で「変数を大きくする」で加算 集計値
numProcessed 数値 0 で初期化 処理できたファイル数。ログとメール本文に入れる

ポイントは 3 つです。パスをアクションの中に直書きせず変数に出す（検証環境と本番の差し替えが 1 か所で済みます）、日付は「日時型」と「表示用テキスト」を分けて持つ（比較は日時型、ファイル名はテキストで組み立てる）、そして件数系の変数を必ず持つ（ログに残す材料になり、「0 件で正常終了」と「取得に失敗して 0 件」の区別がつきます）。

5.2 サブフローへの分割

フロー全体を 1 つの巨大なアクション列にせず、処理の単位でサブフローへ分割しておくと、後からの修正も、失敗した部分だけの再実行も楽になります。この例なら次の構造です。

Main（メインフロー）
  ├─ 初期化: 5.1 の変数を設定する
  ├─ [On Block Error] ブロック開始
  │    ├─ 「CSVを集める」を実行          → 出力: lstFiles
  │    ├─ 対象0件なら「対象なし」を記録して終了
  │    ├─ 「集計する」を実行              → 入力: lstFiles / 出力: numTotal, numProcessed
  │    ├─ 「Excelへ書き込む」を実行        → 入力: numTotal, txtTemplatePath / 出力: txtReportPath
  │    ├─ 「通知する」を実行              → 入力: txtReportPath, numProcessed
  │    └─ 「ログを書く」を実行            → 入力: 実行結果（成功）
  └─ [エラーハンドラ]
       ├─ 「Excelを後片付けする」を実行（開いたままのインスタンスを閉じる）
       ├─ 「ログを書く」を実行            → 入力: 実行結果（失敗＋エラー内容）
       └─ 「通知する」を実行              → 入力: 管理者宛の失敗通知

分割の基準は「単体で再実行しても壊れないか」です。「ログを書く」「通知する」のように正常系とエラー系の両方から呼ばれるものは、最初からサブフローにしておくと処理が二重管理になりません。逆に、サブフロー間で暗黙のグローバル変数に頼り始めたら分割しすぎのサインで、入力・出力として明示的に受け渡せる粒度に戻します。

クラウドフロー側でスケジュール起動し、実際の処理は呼び出し先のデスクトップフローに任せる構成も、運用上は扱いやすい形です。5

6. エラー処理を設計する

Power Automate Desktop には、ブロック単位でエラー処理をまとめて設定できる On Block Error アクションがあります。個々のアクションごとに「エラー時の動作」を設定する代わりに、ブロックに含まれる全アクションへ共通のエラー処理を適用できます。1

[On Block Error] 集計処理ブロック
  ├─ List files in folder
  ├─ Read from CSV file（ループ）
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[エラーハンドラ]
  ├─ Get last error アクションでエラー内容(名前・発生場所・該当アクション・詳細メッセージ)を変数として取得
  ├─ Excel のインスタンスが開いたままなら閉じる(失敗時こそ後片付けを省略しない)
  ├─ Write text to file（Append）でログへ記録
  ├─ Send an email（V2）で管理者へ通知
  └─ 「ブロックの最後から再開」または「フロー実行を停止」を選択

ここで押さえておきたいことがいくつかあります。

  • 個別アクションのエラー処理は、ブロック単位のエラー処理より優先されるため、特定のアクションだけ挙動を変えたい場合は個別設定、それ以外は On Block Error にまとめる、という役割分担にします。1
  • 「Retry action if an error occurs」を使うと、一時的なエラー（ネットワーク遅延やファイルロックなど）に対して、指定回数・間隔で自動リトライできます。すべてのエラーをリトライ対象にすると無駄に時間がかかるため、リトライすべきエラーとリトライすべきでないエラー（データ不整合など）を分けて考えます。1
  • エラーハンドラの中で直前のエラー内容を参照したい場合は、Get last error アクションを明示的に置きます。これは、発生したエラーの名前・場所・該当アクション・所属サブフロー・詳細・メッセージという6つのプロパティを持つ変数を返すアクションで、暗黙の変数として自動的に用意されているわけではありません。同じエラー値を後で誤って再利用しないよう、取得後は「Clear error」オプションでクリアしておくと安全です。1
  • ログは「成功/失敗」だけでなく、処理件数、対象ファイル名、エラーメッセージまで残すようにします。後から「なぜ止まったか」を調べる手がかりはログにしかありません。
  • ブロックの後処理として、「ブロックの最後から再開する」か「フロー実行を停止する」かを明示的に選びます。Excel のインスタンスを開いたまま停止すると、次回実行時にプロセスが残ったままになる、といった事故につながるため、エラー時こそ後片付け（インスタンスのクローズ）を意識します。13

PowerShell の try/catch/finally に慣れている場合、On Block Error の「ブロック」は try、エラーハンドラは catch、後片付けの処理列は finally に近いイメージで捉えると設計しやすくなります。

7. UI自動化を安定させる

デスクトップフローが不安定になる最大の原因は、多くの場合「UI要素の特定方法（セレクター）」にあります。

  • 既定では、UI要素ピッカーが画面の要素を セレクター（属性の組み合わせ）として記録します。アプリのバージョンアップや表示内容の変化に弱い属性（連番のインデックスや動的なIDなど）が含まれていると、見た目が同じでもフローが壊れます。14
  • 値が変化する属性は Equals ではなく Contains や正規表現に変更し、前のアクションの結果に依存する値は変数化することで、より動的で壊れにくいセレクターになります。14
  • 複数のセレクターを設定しておくと、最初のセレクターが失敗した場合に次のセレクターへ自動的にフォールバックします。重要な操作には予備のセレクターを用意しておくと安定性が上がります。14
  • セレクターが壊れた場合は、Repair selector 機能で自動的に修復候補を生成できます。手動で1から作り直す前に、まず試す価値があります。14
  • 画面遷移やアプリの起動には時間差があります。固定の Wait だけに頼らず、「ウィンドウを待機する」「UI要素が見つかるまで待機する」といった条件待機のアクションを組み合わせ、UI要素が見つからない場合の自動リトライも合わせて設定します。15
  • どうしても安定しない自動化対象（仮想化された画面、頻繁にレイアウトが変わる画面など）については、UI操作に固執せず、API・ファイル連携・データベースアクセスなど、より安定した連携方法がないかを先に確認します。

UI 自動化を最初に動かすこと自体は難しくありません。半年後も壊れずに動いているかどうかは、ほぼセレクターの作り方だけで決まります。

8. 認証情報を安全に扱う

業務自動化でもっとも事故が起きやすいのが、認証情報（パスワード、APIキー、接続文字列など）の扱いです。

  • パスワードや接続情報を、フローの入力変数にそのまま値として書き込むのは避けます。Get credential アクションを使うと、Azure Key Vault や CyberArk を裏側のシークレットボキャブラリとした「Power Automate の資格情報」から認証情報を安全に取得でき、取得した値は機密情報としてマークされ、フローの実行ログにも残りません。1617
  • Azure Key Vault をシークレットの保管場所として使う場合、Power Automate 側で Key Vault への接続情報を1か所にまとめて管理できるため、認証情報をフローごとに分散させずに済みます。17
  • 無人実行用のアカウントは、利用範囲を必要最小限にした専用アカウントを用意し、人が日常使うアカウントと兼用しないようにします。アカウントが持つ権限が広いほど、フローの不具合や設定ミスが及ぼす影響範囲も広がります。
  • 「動かすために一時的に」と平文でパスワードを入力変数に書いたまま検証を進めると、そのまま本番に残ってしまいがちです。検証段階から Get credential アクションを使う癖をつけておくほうが安全です。

9. ガバナンスと運用

個人やチーム単位で作ったフローが増えてくると、次は組織としての統制が必要になります。

  • データ損失防止（DLP）ポリシーは、フローやアプリで使えるコネクタを「業務データ専用」「業務データ利用不可」「ブロック」などに分類し、業務データ用コネクタと業務データ利用不可のコネクタを同じフロー内で組み合わせられないようにする仕組みです。組織のデータが意図せず外部サービスへ流出することを防ぐ、最初に整備すべきガバナンスです。18
  • デスクトップフローのアクションも同じ DLP ポリシーの枠組みで分類・ブロックできますが、これは既定では有効になっていません。Power Platform 管理センターのテナント設定で「Show desktop flow actions in DLP policies」を一度オンにする必要があり、この設定は後から元に戻せません。有効化したあとも、ポリシーで明示的に分類したモジュール・アクションだけが制御対象になるため、「DLP ポリシーを作った＝デスクトップフロー全体が統制下にある」とは限らない点に注意します。2
  • 無人実行用のマシンは、マシングループとしてまとめて管理し、どのフローがどのマシンで実行されるかを明確にしておきます。
  • 実行履歴をどこで見るかを決めておきます。個々のクラウドフローなら、Power Automate にサインインして「マイ フロー」→ 対象フロー → 詳細ページの「実行履歴」で、失敗した実行を選ぶとどのアクションで落ちたかとエラー詳細が見られます。同じ詳細ページの上部メニューにある「Analytics」では、成功率・失敗率と直近 30 日の実行履歴が見られます。テナント全体・環境全体の失敗を漏れなく見たいときは、Power Platform 管理センターの Monitor（監視）が最も網羅的です。1920 なお、カスケード失敗（先に失敗したアクションに引きずられて後続も失敗扱いになるもの）が並ぶので、実行履歴では「最初に失敗したアクション」を見るのが原則です。19
  • 標準の失敗通知の限界を知ったうえで、自前の通知を足します。 Power Automate はクラウドフローの失敗に対して 2 種類のメールを送ります。1 つは実行単位の失敗アラートで、接続切れやスロットリングのように「既知の直し方がある原因」と判定できたときだけ、フローの所有者・共同所有者へ送られます。しかもこれはフローの設定で有効になっている必要があり、同じフローには一度送ると 28 日間のクールダウンが入ります。もう 1 つは週次のダイジェストで、アラートが出なかった一般的な失敗も含めてまとめて届きます。19 つまり「毎回・すぐに・担当者へ」を標準機能だけで満たすことはできません。第 6 章のエラーハンドラから管理者へメールや Teams で通知する処理を、フロー自身の一部として組み込んでおいてください。
  • 社内ネットワーク内のデータベースやファイル共有など、クラウドから直接アクセスできないオンプレミスのリソースをクラウドフローから扱いたい場合は、オンプレミスデータゲートウェイを使います。ゲートウェイはクラウド側からの受信ポート開放を必要とせず、送信方向の接続だけで安全にデータを橋渡しします。21
  • 検証用と本番用で環境を分け、デスクトップフローや接続情報を環境ごとに切り分けておくと、検証中の変更が本番フローに影響することを防げます。

10. Power Automateの限界とエスカレーション基準

Power Automate は強力ですが、万能ではありません。次のような状況では、PowerShell や .NET アプリへの切り替えを検討します。

状況 判断 理由
数十万行規模のデータ処理が必要 PowerShell やバッチ処理アプリへ デスクトップフローのループ処理は大量データには向かない
複雑な業務ロジックがあり、自動テストを書きたい .NET アプリへ フロー自体の単体テストは難しく、ロジックが複雑になるほど検証コストが上がる
高頻度・低レイテンシでの常駐処理が必要 Windows サービス / Generic Host + BackgroundService へ フローの起動・実行コストはリアルタイム処理には不向き
操作対象のシステムに API が用意されている API を直接呼ぶ実装へ UI 操作よりも API 連携のほうが安定し、保守コストも下がる
操作対象画面のレイアウトが頻繁に変わる UI 自動化を避け、代替手段を検討 セレクターの保守コストが運用コストを上回る
ソースコードでの厳密な変更履歴・レビューが必須 Git 管理できる PowerShell / .NET へ フローのエクスポート（zip）は擬似的なバックアップにはなるが、コードレビューには向かない

「Power Automate で作ったものが育って複雑になりすぎた」と感じたときは、無理にフローを拡張し続けるより、コア処理を .NET や PowerShell に切り出し、Power Automate はトリガーと通知に専念させる構成へ寄せたほうが、結果的に保守しやすくなることが多いです。PowerShell によるログ調査・アーカイブ自動化の実例は、別記事「PowerShellスクリプト応用 ── ログ調査・アーカイブ・レポート化を安全に自動化する」でも紹介しています。

11. まとめ

Power Automate は、最初の一歩までは驚くほど簡単です。ただ、その手軽さは裏を返すと「設計を端折ってもいったん動いてしまう」ということでもあります。本番に出したフローを長く保守できるかどうかは、最初にどれだけ地味な判断を済ませておけるかでほぼ決まります。

クラウドフローとデスクトップフローのどちらを使うか、PowerShell や .NET に任せたほうがよい処理はどれか。この切り分けを最初にやっておくと、後からの手戻りはかなり減ります。エラー処理、UI セレクター、認証情報、ライセンス、DLP ポリシーは、いずれも「動いてから直す」より「最初から組み込む」ほうが圧倒的に安く済みます。そして、フローが育って複雑になってきたときに、無理に拡張せず .NET や PowerShell へ処理を逃がす判断ができるかどうかも、長く使い続けられるかを左右します。

「とりあえず動くフロー」と「安心して任せられるフロー」の間には、これだけの設計の差があります。既存の業務システムや Excel / VBA 資産が絡む自動化ほど、最初の設計判断が後々の保守コストを大きく左右します。

関連記事

関連する相談領域

合同会社小村ソフトでは、既存の Excel / VBA / Windows 業務資産を残しながら段階的に自動化・モダナイズする相談や、Power Automate を含む自動化基盤の設計レビューを扱っています。

参考リンク

  1. Microsoft Learn, Handle errors in desktop flows. On Block Error によるブロック単位のエラー処理、個別アクションとの優先順位、リトライ設定について。 ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Data loss prevention (DLP) policies. デスクトップフローに対する DLP ポリシーの適用、業務/非業務分類とブロックの仕組みについて。 ↩ ↩2

  3. Microsoft Learn, Types of Power Automate licenses. ユーザー単位・フロー単位ライセンスの種類と、自動化フロー/インスタントフローでのライセンスコンテキストについて。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, Attended and unattended scenarios for process automation. 有人実行と無人実行の違い、それぞれに必要なライセンスや実行形態について。 ↩ ↩2 ↩3

  5. Microsoft Learn, Trigger desktop flows from cloud flows. クラウドフローからデスクトップフローを呼び出す構成について。 ↩ ↩2

  6. Microsoft Learn, Run unattended desktop flows. Windows 10/11 では誰かのセッションがロック状態でも残っていると無人実行が失敗すること、Windows Server では接続ユーザー本人のロックされたセッションが対象になること、ロック・切断ではなくサインアウトが必要なことについて。 ↩

  7. Microsoft Learn, Run Office Scripts with Power Automate. Office Scripts と Power Automate を組み合わせた自動化、および必要ライセンスについて。 ↩

  8. Microsoft Learn, Deep dive on specific licenses. Power Automate Premium、Process、Hosted Process ライセンスの詳細について。 ↩ ↩2

  9. Microsoft Learn, Solutions in Power Apps. ソリューションがアプリやコンポーネントを環境間で移送し、既存アプリへカスタマイズ一式を適用するための仕組みであること、フローを含む複数種類のコンポーネントを 1 つにまとめられること、Power Automate を含む Power Platform 製品で ALM（アプリケーションライフサイクル管理）を実現する仕組みであることについて。 ↩

  10. Microsoft Learn（日本語版アクションリファレンス）, フォルダー アクション、ファイル アクション、Excel アクション、変数 アクション、日時 アクション、テキスト アクション、フロー制御 アクション. 本文で併記した日本語のアクション名（フォルダー内のファイルを取得、CSV を読み取ります、テキストをファイルに書き込む、ファイルをバイナリ データに変換、Excel の起動、Excel ワークシートに書き込む、変数の設定、変数を大きくする、現在の日時を取得します、datetime をテキストに変換、ブロック エラー発生時、最後のエラーを取得、サブフローの実行）の出典。 ↩

  11. Microsoft Learn, Overview of the unattended robotic process automation with Microsoft 365 Apps for enterprise. Microsoft 365 Apps for enterprise（unattended）ライセンスがない場合、無人実行で使う Office アプリが機能制限モードで動作することについて。 ↩

  12. Microsoft Learn, Office 365 Outlook actions reference. Send an email (V2) で添付ファイルを送る際は Convert file to binary data でバイナリ化し、Name / ContentBytes として渡す必要があることについて。 ↩ ↩2

  13. Microsoft Learn, Employ robust error handling. エラー処理を設計する際のガイドライン。 ↩

  14. Microsoft Learn, Build a custom selector. セレクターを動的にする方法、複数セレクターによるフォールバック、Repair selector について。 ↩ ↩2 ↩3 ↩4

  15. Microsoft Learn, Automate using UI elements. UI要素の指定方法と、待機・リトライの考え方について。 ↩

  16. Microsoft Learn, Secure your data. Get credential アクションによる認証情報の安全な取得と、実行ログへの非出力について。 ↩

  17. Microsoft Learn, Create an Azure Key Vault credential. Azure Key Vault をシークレットの保管場所として使う設定について。 ↩ ↩2

  18. Microsoft Learn, Data policies. コネクタの分類（業務データ専用/業務データ利用不可/ブロック）によるガバナンスの考え方について。 ↩

  19. Microsoft Learn, Understand flow failure notifications in Power Automate. 実行単位の失敗アラートが「既知の直し方がある原因」と判定できた場合にのみ所有者・共同所有者へ送られること、同一フローには 28 日のクールダウンがあること、フロー設定で有効になっていないと送られないこと、週次の失敗ダイジェストではアラート対象外の一般的な失敗も含めて通知されること、全件を見るには Power Platform 管理センターの Monitor か、フロー詳細ページの実行履歴を使うこと、カスケード失敗ではなく最初に失敗したアクションを見るべきことについて。 ↩ ↩2 ↩3

  20. Microsoft Learn, Monitor your flows. フロー詳細ページの Analytics で成功率・失敗率や直近 30 日の実行履歴を確認できること、環境単位の分析が Power Platform 管理センターで参照でき直近 28 日分の実行履歴を含むこと、Automation Center・Application Insights・Dataverse の FlowRun テーブルによる監視の選択肢について。 ↩

  21. Microsoft Learn, On-premises data gateway. オンプレミスデータとクラウドサービスを安全に橋渡しする仕組みについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

クラウドフローとデスクトップフローはどう使い分けますか？
クラウドフローはコネクタを介してクラウドサービス同士をつなぐ仕組みで、承認フロー、通知、SaaS連携、Microsoft 365まわりの業務フローに向きます。デスクトップフローはWindows上のアプリや画面を直接操作するRPAで、APIのない古い業務システムやWin32アプリの画面操作が必要な場合の現実的な選択肢です。相談を受けるときは、まず「クラウドサービス同士をつなぐ話なのか、画面を操作する話なのか」を切り分けるところから始めると見通しが良くなります。
Power AutomateとPowerShellはどちらを使うべきですか？
PC上の定型作業を自動化したいだけなら、画面のクリックや入力が必須でなければPowerShellのほうが保守しやすく、Gitでのバージョン管理にも乗せやすいことが多いです。APIが用意されているシステムをUI操作するのは本来PowerShellや.NETからAPIを直接叩いたほうが安定します。数十万行規模のデータ処理、自動テストが必要な複雑なロジック、高頻度の常駐処理もPowerShellや.NETに向きます。フローが複雑になりすぎたら、コア処理を切り出してPower Automateはトリガーと通知に専念させる構成が保守しやすくなります。
Power Automateの無人実行に必要なライセンスは何ですか？
無人実行には有人実行とは別のライセンスが必要で、フローやマシンにライセンスを紐づけるPower Automate Processライセンスを使います。以前の無人実行アドオンはレガシー扱いでProcessライセンスに置き換えられています。またProcessライセンスだけではユーザーライセンスの代わりにならず、マシンの登録にはPower Automate Premiumライセンスを持つユーザーが必要です。さらにWindows 10/11では誰かのセッションがロック状態で残っていると無人実行が失敗するため、全員のサインアウトが必要です。
デスクトップフローのUI自動化が不安定になる原因は何ですか？
最大の原因は多くの場合UI要素の特定方法（セレクター）にあります。連番のインデックスや動的なIDなど変化に弱い属性が含まれていると、見た目が同じでもフローが壊れます。対策として、値が変化する属性はEqualsではなくContainsや正規表現にし、複数のセレクターを設定してフォールバックさせ、壊れた場合はRepair selector機能で修復候補を生成します。固定のWaitだけに頼らず条件待機のアクションを組み合わせることも重要です。半年後も壊れず動くかどうかは、ほぼセレクターの作り方で決まります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る