💭

Power Automate が得意なこと、苦手なこと

2023/05/15に公開

ソフトウェアエンジニアの abechanta です。

十数年前に内製した社内向けサービスをどうにかしたい(ロクにメンテされてないが、維持はしたい)

というのはよくある話ですね。
そこで調査を始めてみて、機能の大半は今どきオープンソースのものを使えば開発不要で代替できるけど、検証してみると一部機能だけが不足していたというのもよくある話です。

ここでどうするかは悩ましい問題で、「プラグインを内製する」という選択も十数年後の引き継ぎを想像すると腰が重かったり。

ということで、ここ暫くはもう 1 つの選択肢を確立すべく Power Automate と格闘していました。
システムが置き換わったことで感じる不足や機能を、クラウドフローに肩代わりさせようという目論見でした。

当初は Power Automate といえばややオモチャっぽい印象がありましたが、まじめに向き合ってみてそれなりに使えることが分かり、今回は 2 か月足らずでシステムリプレースのプロトタイプが完成しました。

この記事は Power Automate についてちょっと詳しくなった筆者が、Power Automate の習得を始めようかと悩んでいるあなたに向けて、Power Automate の得意なことや苦手なことについて簡単にまとめてみたものです。
いま「自動化したい」と感じているプロセスを、そもそも Power Automate でカバーできるかを判断する材料にしてもらえればと思います。

その前に少し宣伝です。
今回のノウハウを生かして入門書を書きました。
よろしければチェックしてみてください。

https://techbookfest.org/product/vuD0wJ7DuzeSV4Y1NdXJxQ

得意なこと

Microsoft365 サービスと連携して動くというところが、とても良くできています。
大抵は Microsoft365 を導入している組織が Power Automate の契約を付加するケースが多いのかなと思いますが、その組織の業務やデータが Microsoft365 中心であればあるほど、Power Automate 活用の下地ができているということになります[1]
典型的には「メールは Outlook、チャットは Teams、ストレージは OneDrive、ナレッジは SharePoint」みたいなパターンですね。

例えば Outlook と Gmail を比較してみると、Gmail のトリガーは「新しいメールが届いたとき」だけなのに対して、Outlook のトリガーには以下の豊富なトリガーが使えるのです。

  • 新しいメールが届いたとき
  • 自分をメンションした新しいメールが届いたとき
  • メールにフラグが設定されたとき
  • 新しいイベントが作成されたとき
  • イベントが変更されたとき
  • イベントが追加、更新、または削除されたとき
  • 予定しているイベントがすぐに開始されるとき

同じことは Teams コネクタSlack コネクタの比較や、その他の競合サービスにも当てはまります。

SharePoint アイテムリストのうちの 1 つを右クリックして、自動化メニューからフローを呼び出せたりするのも便利です。


SharePoint のアイテムに自動化プロセスを適用する

誰かに OK をもらうというステップを含むビジネスプロセスも得意です。
Approvals(承認)コネクタを使うと、ボタンクリックだけで応答可能なフォームが Teams と Outlook の両方に届くので、忙しい同僚や上司を煩わせずに済みます。


Teams で届いた Approval


Outlook で届いた Approval

Microsoft Forms に必要事項を入力し「提出」ボタンをクリックしたら Approval が上長に届き、上長から「承認」をもらったら申請メールを特定窓口へ送信する、というようなフローは定番中の定番です。

苦手なこと

社内サービスと連携して動くというところは、やや苦手です。
特に社内サービスがイントラネットにある場合、社内サービスに対してアクションをするには大抵プレミアム HTTP コネクタを使う必要がありますし、イントラネットにゲートウェイホストが必要になるためです。
これらをセットアップするには追加の契約が必要になります[2]

Power Automate Desktop と連携して動くというところも、(苦手ということではないですが)追加契約が必要です。

時間をトリガーにするのもやや苦手です。
例えば、何かが始まる 30 分前にアクションをしたい場合には、作成したフローを 30 分ごとに定期実行させて、予定表などをポーリングする必要があります。
このとき最大 29 分のズレは許容することになります。
かと言って、このポーリングを 1 分ごとにしてしまうと、リミット超過に至り、フロー起動が抑制されてしまったりします。

これと似た理由で、何かが発生していないことを条件とするような自動化も少し苦手です。
組織の全員が書類を提出すべきところ、誰が未提出かを判定するとか、作成したタスク(チケット)が一定期間放置されてないかを判定する、とかいうケースです。

ある程度の規模を超えた複雑なフローを実現するのには向いていません。
フローの編集は現時点ではグラフィカルなフローデザイナーを使うしかないので、複数名で並行して作業ができませんし、本番環境を直接編集しなければならずメンテナンスが困難になります[3]

次に取り組むこと

これまでに Power Automate を使ってシステムを 1 つリプレースして、入門書も 1 冊書き上げたので、スタンダードコネクタで実現できる範囲についてはかなりしゃぶり尽くせたと実感しています。

しかし周囲に目を向けてみると、もっと広い世界が待っていました。

まだプレミアムコネクタを使い倒せてませんし、Power Apps と連携させてませんし、Visual Studio で Teams Toolkit を叩いたりもしていません。
同じくローコード開発を担う Azure Logic Apps も気になってます。

私自身、Power Platform にはポテンシャルを感じているので、もうしばらくこの世界を探索してみようと思っています。
そしてまた、この記事の続きを報告できるようにがんばります。

脚注
  1. Power Automate 単体で契約するケースは少ないでしょうし、単体で契約してもうまく活用するのは難しいと感じています。 ↩︎

  2. 社内サービスをトリガーにするだけであれば、ゲートウェイを準備しなくても、メール着信トリガーを絡めて実現できる場合があります。 ↩︎

  3. このあたりを緩和するためのノウハウについては、紹介した書籍を参考にしてほしいです。:-P ↩︎

Discussion