お試しでは知ることのできない真の実力

このエントリは Power Automate Advent Calendar 2023 の 12/06 分エントリになります。

 Office 365/Microsoft 365 では、Power Automate や Power Apps の利用権（シードプラン）が付属していることもあり、多くの人が Power Platform の恩恵を受けていることと思います。なんだかんだ言って、特に費用追加せずに利用できるというのは大きなメリットですので、勿体ないから自社で活用しようぜ！、と考えるところも多々あるでしょう。

 Power Automate で作業を自動化できたらステキですし、Power Apps で独自アプリを作れたりしたらまたステキすぎて、鼻息荒くなってしまう人もいるでしょう。また、思い描いていることができるかどうかを試すためにも、所有している利用権の活用や試用版を登録してお試し利用して考えようとしている人も多いと思います。

お試しできないもの

　Power Automate の能力は付随する利用権や試用版では確かめることができない部分があります。代表的なのは処理能力です。Microsoft 公式ドキュメントとして以下のページが用意されていますので、ここを参照するのが役立ちます。

自動化フロー、スケジュールされたフロー、インスタント フローの制限事項
https://learn.microsoft.com/ja-jp/power-automate/limits-and-config#performance-profiles

　パフォーマンスプロファイルとして、Power Automate の処理能力がまとめられています。ドキュメントには「安」と分類されたカテゴリに、

安 無料/Microsoft 365 プラン/Power Apps プラン 1、アプリごとのプラン/Power Automate プラン 1/すべての試用版ライセンス/Dynamics 365 Team Member/開発者向け Microsoft Power Apps 

と書かれており、このプロファイルで動作できる能力はドキュメントの最後の方に記されています。

　24時間ごとの Power Platform 要求で行える数がありますが、ざっくり言い換えるとこの数字が最大となるアクション実行限界です。各コネクタのアクションで1度の処理で何回呼び出しが行われるかはまちまちですが、最低１回は呼び出しが行われるとした場合、1日に実行できるアクション数は24時間での要求数となります。つまるところ、1日に10,000アクション以上は実行ができないことになります。

　実際にこれを超える処理を行った場合どうなるか、これはフローが一時停止状態のような形になり、処理が途中で実行中のまま止まります。履歴では実行中なのに、フローのどこかのアクションで処理がストップしている状態です。

　1日に10,000アクションと言われると結構なことができそうに思えますが、先に書いた通り「1アクションでどれくらい呼び出しが発生するかは公開されていない」ので、実際にはそれよりも少ない数でしか動作することができません。

　試用版やシードプランによる利用権での処理能力と、有償ライセンスである Power Automate Premium を購入した際の処理能力は、最大実行数で10倍になります。ここでも「騙されんぞ、どうせ最大数だけだろ！」と思われがちですが、実際の実行速度も体感で２～３倍は早く動作しているように感じられるほどです。世の中に広く伝わる赤くなったら3倍速くなる、というわけではありませんが有償ライセンスによりプロファイルをミディアムに切り替えるだけで、思っている以上の処理能力を手にすることが可能です。場合によっては1時間かかった処理が10分かからなくなった、といったことも実際に起きたことがあります。

結局のところどうするのがよいか

　少ない処理数をユーザー数でカバーさせるような処理の仕組みを作ることももちろん可能です。AというファイルだったらAさんに、BというファイルだったらBさんに、といった形で処理を振り分ける仕組みにすればよいので、そこだけ見れば実現も十分に可能ですが、そこまでのことをやろうとした場合、大体にしてライセンス購入して処理能力を向上させた方がスムーズに解決できてしまうことが多いです。1か月かけて処理を複数人に割り振りするような仕組みを作るか、2000円弱支払って数倍の処理能力を手にするか、どちらがよいかはその時々の事情もあるので一概には言い切れません。ただ、人ひとりが1か月考えて作り上げる時間にもコストが関わってくると考えると、最終的にどうすることがメリットあるのかは、一行の余地があると思われます。

　せっかく利用権があるのでその枠内でどうこうしたい気持ちは理解できますが、実現したいことがその枠を超えるときには、有償プランを購入することもぜひ検討してみてください。

Power Automate Managementコネクタの実力とは

気が付けば3年ほどブログを放置してしまいました。今回ご縁があって、Power Automate のアドベントカレンダーに参加しまして、このエントリはその投稿となります。 色々な人がいろいろな観点で書いてくれているので、さて自分は何を書こうかなと考えてみたところ、結構昔からある割にほとんど日の目を見ないコネクタあったなーと思い、今回は Power Automate Management コネクタについて書いてみようと思います。 

 どんなコネクタなのか 

 Power Automate Managementコネクタは、その名前の通り Power Automate の管理機能を扱っているコネクタです。公式ドキュメント（https://learn.microsoft.com/ja-jp/connectors/flowmanagement/）でもアクションの一覧などがまとめられていますが、それを読んでもなかなかイメージが付かない or 使いどころが思いつかないのではないでしょうか。

アクション数もこのように非常に多いですが、ここで提供されているアクションについて、簡単な解説と使いどころを書いていきます。

フローの実行管理機能

フローをオフにする：環境内で指定されたフローを停止します。

フローをオンにする：環境内で指定されたフローを開始します。

フローを再送信する：環境内で指定されたフロー実行を再送信します。

フロー実行を取り消す：フロー実行を取り消します。

実行管理機能といえるのは上記の４アクションです。ここはイメージつきやすいところで、対象となるクラウドフローを指定して、オフ（無効化）・オン（有効化）を行ったり、実行エラーが発生したクラウドフローを再実行させたり、実行中のクラウドフローを中止させることが可能です。

利用するシーンとしても、管理機能的なものを用意する場面で利用することが思いつくので比較的利用することも簡単です。雰囲気的には、再送信と実行取り消しが使いやすいのかもしれません。

所有者・ユーザー関係の機能

フロー所有者を一覧表示する：環境内で指定されたフローのすべての所有者を一覧表示します。

フローの所有者を変更する：環境内で指定されたフローの所有者を変更します。

フロー所有者を管理者として変更する：管理者アクセス権のある環境内で作成された特定のフローの所有者を変更します。

実行専用ユーザーを変更する：環境内で指定されたフローの実行専用ユーザーを変更します。

管理者としてフローを一覧表示する：管理者アクセス権のある指定された環境内ですべてのフローを一覧表示します。

フローの実行専用ユーザーを一覧表示する：環境内で指定されたフローのすべての実行専用ユーザーを一覧表示します。

クラウドフローの所有者を変更したり、関連するユーザーの一覧を取得したりする機能です。これも、管理機能的なものとして利用することが考えられますが、冷静になって考えると、これらの操作を行うときは大体 Power Automate のポータルから手動で作業する場面が多いと思います。また、それらの作業は比較的単発で終わることが多く、繰り返しこのあたりの作業を必要とする場面はあまりイメージできません。

そう考えると、「Power Automateの完全な管理を行えるツールを自作したい」といったことでもなければ、そうそう利用することはないのではないか、と考えていますので、もし「こういうシーンで使えるじゃないか阿呆が！」というものがあれば、ぜひぜひ教えてください！

環境まわりの機能

自分の環境を一覧表示する：アクセス可能な環境を一覧表示します。

自分のフローを一覧表示する：指定された境内で作成したすべてのフローを一覧表示します。

自分の接続を一覧表示する：指定された環境内で使用可能なすべての接続を一覧表示します。

コネクタを一覧表示する：指定された環境内で使用可能なすべてのコネクタを一覧表示します。 この一覧には、カスタム コネクタおよび組み込みコネクタが含まれます。

コネクタを取得する：環境内で指定されたコネクタを取得します。

コールバック URL の一覧：環境内で指定されたフローのコールバック URL の一覧です。

利用している環境の情報取得や、環境にぶらさがるクラウドフローの一覧、コネクタの一覧、コネクタ情報の取得、接続情報の取得、外部から呼び出される先となるコールバックURLの取得が可能です。

以前私が行っていた、新規コネクタの追加やアクション/トリガの新規追加を検知する仕組みでは、このアクションの機能を利用しています（Logic Apps側でやってることもありますが）。なお、現在はかかるコストが思っている以上に発生してしまっているので止めていますが、なんとか近いうちには復活させたいとも思っています……。

コネクタは環境によってというか、環境が存在する地域（リージョン）によってどこまで提供されているかは異なります。自分が利用している環境でどこまでのコネクタや機能が提供されているかの確認には、このあたりのアクションを利用すると便利です。

接続情報の作成機能

接続の作成：環境内の特定のコネクタの接続を作成します。

環境周りの機能の一つなんですが、ちょっと特殊なアクションなのでここは個別に記載します。接続の作成アクションは、その名前の通りコネクタから利用する接続情報を新規に作成するためのアクションです。それを聞くと、じゃあクラウドフローを展開するときに接続情報を自動で作成することができるんじゃないか、なんて思われるかもしれません。

しかしここでも冷静に考えてみてもらいたいのですが、クラウドフローを展開するときはそのほとんどがパッケージなどの形でエクスポート・インポートで展開し、その際に接続情報を指定することが多いです。また接続情報を作成する際には当然相手先サービスに接続するためのアカウントやパスワードといったセキュアな情報が必要です。セキュアな情報自体はKeyVaultなどに保存すればよいのでしょうが、そのようなセキュアな情報をクラウドフローに扱わせる場面は、なかなか思いつかないのが実情です。

そしてもう一つ、これはおま環（お前の環境の問題）の可能性が高いのですが、作成先の環境ですでに別の接続情報が存在している場合、デザイナー上でアカウント情報の設定が求められない状況になります、

上記のキャプチャは、Twitterの接続情報作成とSharepointの接続情報作成時になります。Twitterは私もよく利用しているので、対象の環境にはすでに接続が存在しています。この場合はアカウント情報を入力できませんでした。対して接続情報を作成していなかったSharePointの場合はデザイナー上でアカウント情報を入力できました。この動きの違いが、予想しているようなすでに接続情報があるかどうかに由来しているかまでは確認ができていません。ですがこういう動きがあり得る以上、利用する場合は注意が必要です。

クラウドフローの管理機能

フローを取得する：環境内で指定されたフローを取得します。

フローを管理者として取得する：管理者アクセス権のある環境から指定されたフローを取得します。

フローの作成：フローの作成

フローを更新する：環境内で指定されたフローを更新します。

フローを削除する：環境内で指定されたフローを削除します

削除されたフローを管理者として復元する：管理者のアクセス権を持つ環境で、論理的に削除された指定のフローを復元します。

クラウドフローの取得や新規作成、更新削除といったことを行う機能です。クラウドフローをJSON形式で取得し、部分的に書き換えて新規に作成するといったことが可能です。削除しても復元が用意されているので一安心といったところだと思います。

この機能もなかなか使いどころが思いつかないところですが、定期的に処理内容を調整する必要のある場合、クラウドフロー上でその処理をIFとか利用して定義しておくことも可能ですが、こちらの機能を用いてクラウドフローの定義自体を定期的に書き換える、という使い方はアリかもしれません。

私が実際に利用していたのは、先の例にあったコネクタ一覧の作成においてです。コネクタは環境によって提供されるものが異なると書きましたが、付け加えると最新のコネクタはプレビュー環境（アメリカの環境の一つ）にまず提供が行われます。この環境は試用版として作成するのですが、試用版環境は30日が経過すると削除される仕様があります（一時的に延長することは可能です）。削除されるとなるとどうするかですが、既存の試用版環境を削除して新しく試用版環境を作成し、その環境からコネクタ一覧を取得するということをやっていました。

環境を作る部分はやればできそうだったのですが手間が多そうだったので、コネクタ一覧を取得する際に「現在存在している環境一覧を取得し試用版環境を見つける」という処理を頭にかませていました。そうすることで、定期的にコネクタ一覧を取得するアクションを再設定する必要がなくなったのでちょっとは楽にできたものです。

現実の場面でこのようなケースがあるかは何とも言えないところですが、似たように定期的にクラウドフローを変更しないといけない場面があるのであれば、このアクションの利用を検討してもよいと思います。

最後に

提供されているアクションについて、いろいろと思うところを書いてみました。機能としては確かに管理を行う場面では必要に思えるでしょう。ですが冷静になって、「その管理機能はクラウドフローで実行するほどのものか」、と一度よく考えてみてそのうえで必要になったらこのコネクタを利用してみるのがよいと思います。

個人的にはすべてを自動化することは必ずしもよいことだとは思っていません。どちらかといえば、そもそもその作業って必要なんだっけ、というラインから考えていくのがよいと思っていますので、深く考えずに自動化を進めることは対処療法を行っているようなもの、と頭の片隅にでも置いておくとよいのではないでしょうか。

Power Automate の UI Flow 現時点でのとりまとめ

Microsoft Ignite で発表された Microsoft Flow から Power Automate への変更。名称変更によるインパクトもありましたが、何といっても多くの人が気になっているのが RPA
を可能にする新機能　UI Flow だと思います。ある程度触ってみて、わかったことをまとめておきます。

Logic Apps でワークフローのアクション名を列挙する

Logic Apps や Flow を利用していると、時々 JSON 値のキー名がわからない場面に遭遇します。例えば Flow のテンプレート情報や、Logic Apps / Flow のワークフロー定義を参照してあれこれやろうとすると遭遇する問題です。今回、ワークフロー定義をもとにアクション名の列挙を行おうとして、JSON 値のキー名を列挙してみたのでそのやり方をメモしておきます。

LogicApps/Flow でコレクション間の差分を抽出する

Logic Apps や Flow では、配列やコレクションを扱う機会が非常に多く何かしらの操作をすることが多々あります。その中でもうまいやり方が見つかっていなかったコレクション間の差分（A と B の間で B のみに存在するデータ）を取得する方法で、フィルタ処理を利用したシンプルな方法が作成できましたので、メモ書きとして残します。

Logic Apps の InlineCode コネクタで JavaScript を利用する

今年の Build でアナウンスがありましたが、Logic Apps の新規コネクタとして Inline Code が発表されました。これは Logic Apps 環境上でちょっとした処理を動かすことのできるコネクタで、処理の記述には JavaScript が現在利用できます（将来的に C# と PowerShell が利用できるとの発表もありました）。そこで、実際に利用してみて感じた点をまとめてみました。

Logic Apps Live Mar 21 2019

今回も３か月ぶりとなった Logic Apps Live、タイミング的にはちょうど MVP Global Summit の時に放送がされました。

特定の Web サイトが更新されたかを Logic Apps/Flow でチェックする

Logic Apps や Flow を使って、特定の Web サイトが更新されたかを検知したいことがあります。RSS が提供されていれば、それをもとに判断できるのですが、Web サイトしか情報がない場合には簡単に行えません。思いつく方法の一つとしては、どこか別のストレージに保存しておき、それと比較する方法がありますが、今回はストレージを利用せずに比較する方法を作成してみました。

Logic Apps での API 接続情報エラーをチェックしてメール通知する

以前に、Microsoft Flow での接続状態チェックを行う LogicFlow を作成したことがあります。この際、Logic Apps では提供されていない管理コネクタを利用しての処理であったため、Logic Apps でのエラーチェックはできていませんでした。今回 ARM コネクタを利用してのチェックが行えたので、その方法をまとめておきます。

Logic Apps Live Dec 13 2018

前回が 9 月だったので、およそ 3 か月ぶりとなる Logic Apps Live が行われました。今回は恒例のクリスマス仕様で行われ、Logic Apps Live 初となる「スライド無しで喋りっぱなし」な回となりました・・・が、後ほどスライド部分が別動画としてアップされていましたので、なんとかなりましたｗ

二つの動画を見てのまとめとなります。