Power Automateのクラウドフローとデスクトップフローの違いとは？トリガー種別・実行基盤・ライセンス差で選び分ける

Power Automateで自動化を組むとき、最初に決めるのは機能でも画面でもなく、どちらのフローで作るかという一点です。クラウドフローとデスクトップフローは名前が似ていますが、処理が動く場所も、起動のきっかけも、必要な権利も別物です。ここを曖昧にしたまま作り始めると、動くには動くのに夜間の無人実行だけが通らない、という手戻りが起きます。この記事では、両者を分ける境界を実装目線で整理し、どちらで組むかを決める条件まで示します。製品そのものの概要はPower Automateとは？基本・できること・料金・導入判断まで解説を先にご覧ください。

まとめ：二つのフローの選び分けは実行基盤で決まる

結論から言えば、判断軸は三つだけです。第一に、自動化したい対象がAPIで触れるクラウド上のサービスなら、クラウドフローだけで組み切ります。第二に、画面を操作しないと触れないアプリやローカルのファイルが混じるなら、デスクトップフローの併用が妥当です。第三に、人がサインインしていない状態で動かす必要があるなら、非アテンド型の権利とマシンの用意が前提条件に加わります。

クラウドフローはMicrosoftのクラウド上で動き、コネクタを通じてサービスのAPIを呼びます。デスクトップフローは登録したWindowsマシンの上で動き、画面のUI要素や画像を頼りに操作を再現する仕組みです。前者は安定して速く、後者は対象を選ばない代わりに画面の変更に弱いという性質があります。したがって、両方が使えるならクラウドフローを優先し、届かない範囲だけをデスクトップフローに切り出す設計が最も壊れにくくなります。

クラウドフローとデスクトップフローを分ける実行基盤と処理対象

クラウドフローはコネクタ経由でクラウドサービスのAPIを直接呼び出す

クラウドフローの実体は、Microsoftのクラウド上で動くワークフローです。SharePointのリストに行が増えた、Outlookにメールが届いた、Teamsに投稿された、といったイベントをコネクタが受け取り、次のアクションへつなぐ仕組みです。処理はすべてAPI経由なので、ユーザーのPCが起動しているかどうかとは無関係に動きます。画面を持たないため、実行の速さも安定します。

反面、触れる相手はコネクタが用意されているサービスに限られます。コネクタがない社内システムでも、HTTPアクションでREST APIを叩けば届きますが、この経路はプレミアムコネクタの扱いになり権利の話が絡みます。APIを持たない古いクライアントアプリには、そもそも手が届きません。

デスクトップフローは登録済みWindowsマシン上で画面のUIを操作する

デスクトップフローは、Power Automate for desktopで作った手順をWindowsマシンの上で再生する仕組みです。Microsoft Learnのデスクトップフロー概要（2025年6月27日付・2026年8月時点で確認）は、ターミナルエミュレーターのようなレガシーアプリケーションから最新のWebアプリまでを対象にでき、UI要素・画像・座標のいずれかでコンピューターと対話すると説明しています。APIがない相手にも届くのが最大の強みです。

その代わり、画面の構造に依存します。対象アプリの更新でボタンの位置やIDが変わると、処理が止まる原因です。実行中はマシンの画面を占有するため、人が同じPCで別の作業をしていると干渉も起こります。PAD単体の操作手順や無償版の範囲はPower Automate Desktopとは？無償RPAでできること・使い方・導入判断を解説に整理しました。

現在のフロー種別は生成アクションを含む三つの実行方式に整理された

かつてPower Automateのフローは四種類と説明されていましたが、Microsoft Learnの「Power Automateとは」（2025年11月19日付・2026年8月時点で確認）では、クラウドフロー・デスクトップフロー・生成アクション（プレビュー）の三つに整理されています。ビジネスプロセスフローはこの一覧から外れました。古い記事の四分類を前提に設計すると、現在の管理画面と噛み合いません。

三つ目の生成アクションは、個々のアクションを並べる代わりに意図だけを指定し、入力と文脈からAIが手順を組み立てる方式です。プレビュー段階のため、本番の業務フローに組み込む判断はまだ早いと見ています。

クラウドフローのトリガー三種類と起動条件から決める設計の分岐点

自動化されたクラウドフローは監視対象のイベント発生を契機に起動する

自動化されたクラウドフローは、監視対象のサービスで何かが起きた瞬間に動きます。ファイルが作成された、項目が更新された、承認が返ってきた、といったイベントが起点です。人手を挟まない定常処理はこの型に寄せます。

注意したいのは、更新をきっかけに同じリストの項目を書き換える設計です。書き換えが次のトリガーを呼び、無限ループになります。トリガー条件で自分の更新を除外するか、フラグ列で処理済みを判定してください。

インスタントフローは担当者の操作やPower Appsの画面から呼び出す

インスタントフローは、ボタンを押す、Power Appsから呼ぶ、といった人の操作で起動します。承認の依頼や、担当者が選んだ行だけを処理する用途に向く方式です。後述するデスクトップフローの呼び出しも、この型か自動化された型のどちらかから行います。

設計上の制約として、受信リクエストのタイムアウトは120秒（2分）です。画面へ結果を返すフローでは、この時間内に応答アクションまで到達させる必要があります。長い処理は子フローへ切り出し、応答だけ先に返す構成にしてください。

スケジュール済みフローは実行時刻と繰り返す間隔を指定して定期運転する

スケジュール済みフローは、指定した時刻や間隔で定期的に動きます。日次の集計、月初の帳票作成、深夜のバッチ連携が典型です。イベントを拾えない相手に対して、定期的に見に行く形で代替する使い方もできます。

ただし実行の継続時間には30日という上限があり、承認などの保留ステップを含む実行もこの時間で計算されます。実行履歴の保持も30日です。長期の監査記録が要るなら、外部のストレージへ書き出す仕掛けを別に用意しておきます。

デスクトップフローの実行モードとマシン登録で押さえる前提条件

アテンド型は担当者がサインイン中のマシン画面を使って処理を動かす

アテンド型は、人がサインインしているマシンの画面を使って処理を再生します。作った本人が手元で走らせる分にはこの形が手軽で、画面の動きを目視できるため検証もしやすい方式です。用途としては、担当者が処理の開始を判断する業務や、まだ手順が固まりきっていない自動化に向いています。

弱点は、実行中そのPCが塞がることです。マウスやキーボードの操作が割り込むと処理が崩れるため、走らせている間の作業は止まります。台数を増やして並列化する発想も、人の数だけしか増やせません。

非アテンド型は担当者がサインアウトした状態の登録済みマシンで走らせる

非アテンド型は、人が触っていないマシンで処理を走らせるモードです。夜間バッチや大量件数の処理はここに寄せます。実行のためには、対象を登録済みのマシンまたはマシングループとして用意し、デスクトップフロー接続を構成しておく必要があります。

Microsoft Learnのクラウドフローからデスクトップフローをトリガーする手順（2026年5月5日付・2026年8月時点で確認）は、前提条件として登録済みマシンまたはマシングループ、職場または学校アカウント、構成済みのデスクトップフロー接続の三つを挙げています。無人での実行にはアドオンが要るという点も、同じ前提条件の欄に明記されています。

マシン登録とマシングループが複数処理を並列実行する配分単位になる

マシンは自動化に使う物理または仮想のデバイスを指し、マシングループは複数台を一つの実体として束ねる仕組みです。処理が集中したときは、グループ内の空いているマシンへ実行が割り振られます。並列で何本流せるかは、このマシンの台数と権利の本数で決まります。

したがって、件数が読めない処理を非アテンド型で組む場合は、想定同時実行数から必要台数を先に逆算してください。台数の見積もりと費用の関係はPower Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説で扱っています。マシンの登録そのものはインストール直後の初期設定に含まれ、手順はPower Automate Desktopのインストールと初期設定｜MSI版とストア版の違いからマシン登録まで解説にまとめました。

クラウドからデスクトップを呼び出す場合に生じるライセンス上の境界線

デスクトップ単体で動かす場合とクラウドから呼ぶ場合で必要な権利が変わる

デスクトップフローをPAD上で手動起動するだけなら、無償の範囲でも踏めます。境界が現れるのは、クラウドフローからデスクトップフローを呼んだ瞬間です。この連携を含む構成では、アテンド型の実行に相応のライセンス、非アテンド型の実行に非アテンド型アドオンが必要になります。

見落としやすいのは、権利を持つべき人が誰かという点です。公式手順は、適切なライセンスを持つ必要があるのは接続の作成者だと明記しています。検証時に作成者の権利で通っていたフローが、本番で別の担当者の接続に差し替えた途端に止まる事故は、この一行を読み飛ばしたときに起きます。

ライセンス権利の確認をフローの設計段階へ前倒しすると手戻りが減る

実務での順序としては、フロー種別を決めた直後に権利の要否を確認します。クラウドフローだけで完結するなら標準コネクタの範囲かどうか、デスクトップフローを混ぜるならアテンド型か非アテンド型か、この二問だけ先に答えを出しておけば足ります。金額の見積もりはその後で構いません。

逆に、作り終えてから権利の話に着手すると、設計をやり直す羽目になります。無人実行の要件が後から出てきたケースでは、マシンの用意と接続の作り直しまで戻ることも珍しくありません。

両フローを併用するハイブリッド設計と実測で影響する処理上限値

クラウドフローを親にしてデスクトップフローを子として呼ぶ組み立て方

併用の基本形は、クラウドフローを親、デスクトップフローを子とする構成です。親側で「デスクトップ用Power Automateで構築したフローを実行する」アクションを置き、実行モードにアテンド型か非アテンド型を指定します。呼び出しの起点になれるのは、インスタントフローか自動化されたクラウドフローです。

親子の間では、入力変数でクラウド側からデータを渡し、出力変数でデスクトップ側の結果を戻せます。この受け渡しを設計しておくと、画面操作の部分だけを子に閉じ込め、分岐や通知は親側で組む構成が可能です。保守の面でも、壊れやすい部分が一箇所に集まるので原因を追いやすくなります。

入力2MBと接続ごとに毎分70実行という上限を前提に処理を組み立てる

公式ドキュメントが示す実測上の制約は二つあります。デスクトップフローの入力サイズは2MB（中国リージョンでは1MB）が上限で、これを超えるデータは渡せません。大きなファイルはクラウド側のストレージに置き、パスや識別子だけを渡す形に切り替えます。

もう一つは、接続ごとに1分あたり最大70回というデスクトップフロー実行の上限です。数百件を1件ずつ子フローで処理する設計は、この壁に当たります。件数が多い処理では、まとめて一度に渡して子側でループさせるか、接続を分けて負荷を散らす形へ組み替えてください。

非同期パターンを無効にすると親のキャンセル操作が子フローへ伝わらない

実行アクションの設定で非同期パターンを無効にしている場合、親のクラウドフローをキャンセルしても子のデスクトップフローは止まりません。マシン上で処理だけが走り続け、次の実行と競合します。運用でフローを止める手順を作るなら、この挙動を前提に子側の停止手段も用意しておきます。

障害調査の面では、非アテンド型に限りビデオログを有効にできます。失敗の直前60秒の画面が記録され、既定の保存先は端末のローカルです。PADのバージョン2.66以降が条件で、UI要素の検出失敗やタイミング問題のように、テキストログだけでは原因の特定が難しい事象で効きます。

どちらのフローで組むかを決める条件と外部委託へ回す判断基準の整理

クラウドフローだけで処理を組み切るべき対象システムの条件を先に置く

対象がMicrosoft 365やクラウドサービスで完結し、標準コネクタで届くなら、迷わずクラウドフローだけで組みます。通知、承認、リストの更新、ファイルの移動といった処理はこの範囲です。マシンの用意も権利の追加も不要で、実行の安定度が段違いに高くなります。

APIを持つ社内システムが相手でも、HTTPアクションで届くならクラウド側に寄せる判断が優先します。画面操作へ逃げるのは、あくまで最後の手段だと決めておくと設計がぶれません。

デスクトップフローを処理へ組み込む条件と採用を見送るべき場面

デスクトップフローを採るのは、APIのない業務パッケージやローカルのExcelマクロ、Web画面しか提供されていない外部サイトが処理の中に含まれる場合です。加えて、対象アプリの画面が頻繁には変わらないこと、処理の件数が毎分70実行の上限に収まること、この二つを満たすなら採用して問題ありません。

逆に見送るべきは三つの場面です。対象アプリが四半期ごとに画面刷新を受けるケース、処理が数千件規模で1件ずつの起動が必要なケース、そして障害時に人が即座に対応できない体制で無人実行だけを増やすケースです。いずれも、画面依存の壊れやすさが運用コストとして跳ね返ります。この条件に当たるなら、対象システム側のAPI提供を先に交渉するか、Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説で扱った連携基盤へ処理を移す方が結果的に安く済みます。

フローを内製で進める範囲と専門会社へ委託する範囲を難易度で切り分ける

クラウドフロー中心の自動化は、業務を知っている現場の担当者が内製で回せます。トリガーとアクションを並べる作業に開発の知識は要らず、修正も手元で完結する作りです。部門別にどの業務から着手するかはPower Automateの導入事例｜経理・人事・営業の自動化パターンと外注の線引きが参考になります。

一方、非アテンド型のマシン設計、権限とサービスアカウントの設計、既存システムとのAPI連携が絡む部分は、内製だけで抱えると運用が止まったときに復旧できません。この領域では、外部の手を借りる判断が妥当です。当社ではPower Automate導入支援・RPA移行として、フロー種別の設計から無人実行の基盤構築までをご一緒しています。設計段階からのご相談も承ります。

よくある質問

クラウドフローとデスクトップフローはどちらが速いですか？

同じ処理を実現できる場合、クラウドフローの方が速く安定します。API経由で直接データをやり取りするため、画面の描画待ちが発生しません。デスクトップフローは対象アプリの起動や画面遷移を待つ必要があり、処理時間が読みにくくなります。速度が要件に含まれるなら、まずクラウド側で届く経路を探してください。

デスクトップフローは無料で使えますか？

PAD上で手動起動する範囲なら無償で踏めます。ただしクラウドフローから呼び出す構成にすると、アテンド型には相応のライセンス、非アテンド型にはアドオンが要ります。権利が必要なのは接続の作成者です。金額の内訳は料金とライセンスの記事にまとめています。

夜間に人がいない状態で自動実行できますか？

非アテンド型を使えば実現できます。前提として、登録済みのマシンまたはマシングループ、職場または学校アカウント、構成済みのデスクトップフロー接続、そして非アテンド型アドオンの四つが揃っている必要があります。アテンド型のままスケジュール実行を組んでも、サインアウト状態では処理が進みません。

クラウドフローだけで社内システムを操作できますか？

その社内システムがREST APIを公開していれば、HTTPアクションで操作できます。この場合はプレミアムコネクタの扱いになるため権利の確認が必要です。APIがなく画面しか提供されていないなら、デスクトップフローに切り出す判断になります。

一つの処理で両方を組み合わせると保守しにくくなりませんか？

役割を分けて組めば、むしろ保守は楽になります。画面操作の部分だけをデスクトップフローに閉じ込め、分岐や通知やエラー処理はクラウドフロー側に置く形です。対象アプリの画面が変わったとき、直す範囲が子フローに限定されます。

関連記事

• Power Automateとは？基本・できること・料金・導入判断まで解説
• Power Automate Desktopとは？無償RPAでできること・使い方・導入判断を解説
• Power Automateの料金・ライセンスとは？Premium/Process/従量課金の区分と見積もり手順を解説
• Power Automate Desktopのインストールと初期設定｜MSI版とストア版の違いからマシン登録まで解説
• Power Automateの導入事例｜経理・人事・営業の自動化パターンと外注の線引き
• Azure Logic Appsとは？仕組み・ConsumptionとStandardの違い・料金と採用判断を実装者目線で解説