Microsoft Power Automate

解決する課題

• メール受信やフォーム送信のたびに、人手で転記・通知・承認依頼を繰り返す作業が積み上がる
• 複数の SaaS や社内システムをまたぐ連携を、そのつどスクリプトを書いて保守するのが負担
• 画面操作しかできないレガシーアプリやデスクトップ業務を、API がないために自動化できない
• 自動化を IT 部門だけに頼ると、現場の小さな改善が後回しになり、属人化する

これらを、トリガーとアクションを並べるだけのローコードな「フロー」として組み立てられるようにすることで解決します。プログラミング知識が浅い現場担当者でも、定型業務の自動化を自分で構築・運用できます。

主要概念と用語

• フロー（Flow）: 自動化の単位。きっかけ（トリガー）と一連の処理（アクション）を上から順に並べたもの
• クラウドフロー: クラウド上で動く API ベースの自動化。さらに自動・即時・スケジュールの3タイプに分かれる
• デスクトップフロー（RPA）: 画面操作を記録・再現して、API のないアプリも自動化する。Power Automate for desktop で作成する
• トリガー: フローを開始するきっかけ。メール受信、ファイル作成、スケジュール、ボタン押下などがある
• アクション: トリガー後に実行する処理。データの取得・更新、通知、承認、分岐などをつなげる
• コネクタ: 各サービスへの接続部品。標準コネクタとプレミアムコネクタがあり、独自 API 用のカスタムコネクタも作れる
• コネクション: コネクタを使うための認証情報の保管庫。アカウントごとに保持される
• 承認（Approvals）: 承認依頼の送信・集約を行う組み込み機能。Teams やメールから応答できる
• 環境（Environment）: フローやデータを入れる入れ物。本番と検証を分離する境界になる
• Dataverse: Power Platform 共通のデータ基盤。フローの実行履歴や一部の機能が裏で利用する

仕様・制限・クォータ

代表的な考え方です（具体値は変動するため定性的に示します）。

• 作成方法: ブラウザのデザイナーで、トリガーとアクションを画面上に並べて構成する。コードは原則不要
• トリガーの種類: イベント起点（自動）、手動起動（即時）、時刻起点（スケジュール）の3系統がある
• コネクタの区分: 標準コネクタとプレミアムコネクタがあり、プレミアム利用には対応するライセンスが要る
• 実行回数・スループット: 1日あたりや一定時間あたりの**API 要求数に上限（スロットリング）**がある。大量処理は分割や間隔調整を検討する
• 同時実行: ループや並列処理には同時実行の上限があり、大量データの一括処理では設計上の配慮が要る
• 保持: 実行履歴の保持期間には上限がある。長期の記録は別途ログ出力やストレージへ退避する
• タイムアウト: 1つのフロー実行やアクション待機には最大時間の制約がある。長時間の承認待ちなどは設計で吸収する

内部の仕組み

クラウドフローは、トリガーが発火すると Power Automate のランタイムがアクションを上から順に評価し、各コネクタ経由で対象サービスの API を呼び出します。トリガーには、イベントを能動的に受け取るプッシュ型と、一定間隔で変化を確認するポーリング型があります。実行ごとに入出力と結果が実行履歴として残り、成否やエラー内容を後から追跡できます。

デスクトップフロー（RPA）は、画面上の UI 要素やマウス・キーボード操作を記録し、それを再生して人の操作を代行します。API が用意されていないアプリでも、画面操作のレベルで自動化できるのが特徴です。クラウドフローからデスクトップフローを呼び出し、API 連携と画面操作を組み合わせることも可能です。

• コネクタは各サービスへの認証と API 呼び出しをラップし、フロー側は中身を意識せずアクションとして使える
• エラー時の挙動は、再試行ポリシーや「実行コンフィグ（並列・スコープ・分岐）」で制御する
• 承認などの長時間待機は、応答が返るまで実行を保留する仕組みで実現される

設計パターン / ベストプラクティス

• 環境を分離する。検証用と本番用の環境を分け、フローをテストしてから本番へ展開する
• 接続は専用アカウントに寄せる。個人アカウント依存だと退職・異動でフローが止まる。サービス用アカウントで持つ
• エラー処理を組み込む。失敗時の通知やリトライ、代替処理（スコープと「実行条件の構成」）を最初から入れる
• 冪等性を意識する。再実行で二重登録・二重通知が起きないよう、キーで重複チェックする
• 大量データは分割する。一括ループはスロットリングに当たるため、ページング・間隔調整・バッチ化で平準化する
• 命名と説明を統一する。フロー名・アクション名を分かりやすくし、引き継ぎや監査を容易にする
• API があるなら API を優先。RPA は画面変更に弱いので、コネクタや API で済む処理は RPA にしない

運用・監視

• 実行履歴で各フローの成否・所要時間・エラー箇所を確認し、失敗の傾向を把握する
• 失敗時の通知を組み込み、フロー停止やエラー多発を担当者へ自動連絡する
• **所有者を複数にする（共同所有）**ことで、属人化を避け、不在時もメンテナンスできるようにする
• 接続の有効期限を定期確認し、認証切れによる停止を未然に防ぐ
• 集中管理が必要な組織では、管理センターでフローの一覧・利用状況・データ損失防止（DLP）ポリシーを統制する
• スロットリングに当たった場合は、実行頻度の見直しや処理の分割で要求数を平準化する

コスト

• ライセンスは主に利用者やフロー単位の課金が基本で、含まれる機能の範囲が区分で異なる
  • Microsoft 365 の一部プランには、標準コネクタを使う基本的な自動化が含まれることがある
  • プレミアムコネクタや Dataverse の本格利用には、上位のプレミアム系ライセンスが要る
  • **RPA（有人・無人）**は別建てのライセンスや、無人実行用のアドオンが必要になる
• 従量制ではなくシート/プラン課金が中心のため、利用者数や自動化の規模で見積もる
• 具体的な単価や含まれる枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• 管理アクセスは Microsoft Entra ID のアカウントで認証し、所有者・共同所有者の範囲を最小限にする
• コネクションの認証情報はサービス側で保管され、フロー定義に資格情報を直書きしない
• 機密データの外部流出を防ぐため、データ損失防止（DLP）ポリシーでコネクタの組み合わせを制限する
• 環境を分け、本番環境への変更を統制して、検証中のフローが本番データに触れないようにする
• 無人 RPA を使う場合は、実行アカウントの権限を絞り、操作対象を必要なアプリに限定する

関連サービス・比較

業務自動化を担う Azure / Power Platform のサービスと、ワークフロー基盤の Azure Logic Apps の守備範囲を整理します。

Power Automate と Azure Logic Apps はワークフローエンジンを共有しており、コネクタの考え方も共通です。違いは利用者層と運用方法で、現場主導のローコード自動化なら Power Automate、開発者がコードや IaC で統合基盤として管理するなら Logic Apps が向きます。AWS では、サーバーレスのワークフロー制御に AWS Step Functions、イベント連携に Amazon EventBridge が近い位置づけです。

ハンズオン / CLI例

Power Automate のフローはブラウザのデザイナーで作るのが基本で、専用の az CLI コマンドはありません。フローやコネクタの土台となる Power Platform 環境は、az CLI から Microsoft.PowerPlatform リソースとして用意できます。

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Power Platform リソースプロバイダーを登録（初回のみ）
az provider register --namespace Microsoft.PowerPlatform

# プロバイダーの登録状態を確認
az provider show --namespace Microsoft.PowerPlatform \
  --query "registrationState" -o tsv

# Power Platform 関連の利用可能なリソース種別を確認
az provider show --namespace Microsoft.PowerPlatform \
  --query "resourceTypes[].resourceType" -o table

# （環境やフローの実体は Power Platform 管理センターや
#  Power Automate のデザイナーで作成・公開する）