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

Logic Apps と Flow は、通常のアプリケーションや API とは異なる性質があります。それは、長期間実行中の状態になることもよしとする、というものです。通常であれば、処理はできるだけ短時間で終了させるのが正しいとされていますが、Logic Apps や Flow ではその限りではありません。Logic Apps であれば最大 90 日、Flow の場合でも 30 日の間、実行中となってよい仕組みになっています。これは Flow でよく利用される承認機能（Approvalコネクタ）が良い例で、承認を依頼してから終了するまで数日かかることは普通の事です。この考え方を持っていると、今回のように処理がシンプルに行えることもあります。

全体の LogicFlow は以下の様に作成しました。

トリガには、要求(HTTP Request)トリガを利用します。そしてまずは対象となるサイトを HTTP コネクタで取得します。今回、検知しようとしたサイトは Microsoft Flow の Release Note サイト（ https://docs.microsoft.com/ja-jp/business-applications-release-notes/powerplatform/released-versions/flow）です。前日に取得した内容と、当日取得した内容を比較して、違いがあれば更新された、という判定を行っています。

ただし、今回のこのサイトは、内部に動的に生成された URL を持つ隠し項目が埋められており、アクセスするタイミングによっては毎回 URL が異なるものが存在していました。そのため、更新日を表していた meta タグの値に限定させて判定を行わせています。このようなものが埋め込まれていないのであれば、HTTP コネクタで取得した値をそのまま比較しても問題はありません。

meta タグに限定させている箇所は、次のように処理を行っています。

先に、HTTP コネクタで取得した HTML の内容を、uriComponent 関数を利用してエンコードを行っています。これは、内部で改行コードなど、Logic Apps や Flow でそのままでは扱えない文字があるためです。例えば \r\n は改行を表しますが、uriComponent 関数を利用すると %0D%0A という文字列になります。その変換結果に対し、行単位に配列へ分割します。この場合 split 関数に指定するのは、先ほど例に挙げた改行コードとなります。

split(uriComponent(body('FlowReleaseNoteを取得')),'%0D%0A')

変換した配列から、meta タグとなっている箇所を抽出します。

equals(startsWith(item(), uriComponent('<meta name=\"updated_at\"')), true)

startsWith 関数は「～で始まるか」を判定する関数です。これを利用して、meta タグを記載しているもののみに、配列を限定させます。今回は、更新日を表す meta データが、updated_at という名前で設定されているのが解析できましたので、その要素のみに限定を行い、フィルタリングした結果をそのまま配列な変数へと設定します。

初回起動時は、比較対象となる前回の結果がありませんので、IF コネクタで判定を行います。前回データは HTTP Request トリガに渡してもらう形になりますので、トリガに何もデータがわたってきていない＝前回データがない、という判定です。

前回データが存在した場合、今回取得したデータと比較するために、同じ形となるよう配列変数に設定します。そして配列変数をそれぞれ比較し、違いがあれば更新があった、なければ同一として判定しています。

そして最後に、1日処理を待機させ、その後に今回取得したデータを添付し自分自身を呼び出しています。こうすることで、今回取得したデータを次回処理に引き継ぐことが可能です。特に外部ストレージを経由しなくても、必要情報を受け渡すことができますので、色々とアレンジして利用してみるとよさそうです。

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

いつもの Kevin さんと John さんです。

今回のお題目は次のようになっていました。

ここまでのアップデートの中で一番大きいものは、やはりなんといっても ISE(Integration Service Environment)のパブリックプレビュー開始です。利用者が占有できる Logic Apps 実行環境を作成することで、他ユーザーが大量の処理を実施している際の影響を受けにくくするもので、VNet を利用してオンプレミス環境と接続することも可能です。まだ価格プランが発表されていませんが、ビジネスの場面で大量にデータを扱うのであればメリットがあると言われています。

ISE の開発は非常に苦労していたのがうかがえますｗ

Static Result は最近プレビューで利用できるようになった、テスト支援機能です。コネクタを実際に実行させずに、モックとして実行し特定の値を返却できるようにする機能で、これを利用することで今までは難しかった「エラー発生時の処理テスト」が簡単に行えるようになります。

Delete Run API は Logic Apps の実行中止 API です。実行履歴のブレード上から、利用可能になっているものかと思います。

Handling many parameter は、実行結果の表示で多くのパラメータを利用している場合、縦にすごく長い表示になっていたのですが、その表示方法を変更しある程度必要なものに絞った形で表示するようにしたものです。

Tracking for batch trigger は、今まで対応していなかった Batch トリガでの追跡プロパティ対応です。言われるまで対応していなかったことに気づいていませんでした・・・ｗ

あとは Azure Gov Cloud Arizona ということで、政府用環境を新しく展開したとのことです。

新規コネクタは、流石に三か月だとスゴイ量になっています。その中でも非常に衝撃的だったのは IBM3270 コネクタで、これはメインフレームとの接続を可能にしジョブの実行を指示できるものです。さすがにこれは個人では試せないですねｗ

デモは先ほどの Static Result です。デザイナー上で、テスト用に返却する値を設定することで、続くエラー時の処理が行われるかが、非常に簡単に確認できています。

現在対応中のものです。ISE は GA に向けて色々作業中で、ISE 用コネクタとして SAP と FileSystem を開発中とのことです。

VSCode で Logic Apps を対象にした新しいプロジェクトを開発中です。話を聞いていると、現在 Visual Studio で行えているものにとどまらず、もっと色々と管理や開発を行えるようなものとのことです。

RosettaNet は B2B な環境で利用されているプロトコルで、これも対応を進めているようです。日本ではどれほど浸透しているか、私は EDI などの世界から離れて久しいのもあり把握していませんが、こういった統一可能なプロトコルには是非のっかってほしいですね。

開発中コネクタでは、Key Vault が近々リリースが行われるとの話が出ました。おそらく２～３週間以内とのことで、これは非常に楽しみですね！

そして Azure Scheduler の終了に伴うアナウンス、これはこれまでも同様に行っていますが、2019/09/30 なので、あと半年くらいの時間があります。できるだけ早くに Logic Apps へ移行することをお勧めしています。

今月末に行われる Global Integration Bootcamp のイベント紹介に・・・

Microsoft Ignite の紹介、

Integrate2019 のイベント紹介を行い、今回の Logic Apps Live は終了しました。

やはり海外では Integration 系のイベントは強いのがあって、非常にうらやましいですね。日本でも同様のイベントを行ってみたいと思いますが、人集まらないだろうしなぁ。

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

今回検証してみたのは、このような形の LogicFlow です。Inline Code コネクタでは、JavaScript による値のソートを行わせています。

Inline Code コネクタへ渡す値は、次のような JSON の配列値を用意しました。

value という名前で、名前と年齢をもった JSON 値の配列が設定してあります。今回はこの配列を、年齢の降順でソートしてみました。その際の JavaScript を以下の様に記述します。

LogicFlow から受け取る値は、workflowContext オブジェクトとして渡されてきます。このオブジェクトでは、実行している LogicFlow 名やそのトリガ情報、アクション情報が設定されており、ここを参照するだけでここまで処理されたデータなどを利用することが可能です。その際、ダイアログに表示されている値を選択して利用することも可能で、実際に選択するとサンプルコードのように workflowContext.actions.作成.outputs といった JavaSciprt での記述が自動で挿入できます。また、コードを記載するエディタ上ではインテリセンスが動きますので、VSCode や Visual Studio でコードを記載するのと同じように、入力補完が行われるのは非常に便利なところです。

例えば、今回は作成アクションを利用して value という名前の値に配列を設定しているので workflowContext.actions.作成.outputs.value という書き方をすることで、作成した JSON 値を参照することができます。

実際の実行結果は上記のようになります。JavaSciprt 側で処理した結果が、予定した通りソートされているのが確認できます。このような感じで、これまで Logic Apps だけでは対応が難しかった場面で、JavaScript での処理を利用することができます。Azure Functions を作成することなく対応ができるようになりますので、さらに気楽に活用できるのではないでしょうか。

なお、現時点の仕様として外部モジュールの読み込みは提供していません。例えばハッシュ値の算出や暗号化を行う際に利用する crypto モジュールなどは、現時点では利用することができません。ある程度設定できるようになるとありがたいのですが・・・。

このあたりはセキュリティを考慮すると、致し方ないと理解できるのですが少々残念なところです。今後 C# や PowerShell でのコード記述が対応された場合には、恐らくさらにできることが増えていると思いますので、対応待ちというのも一つかと思います。

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

対象が配列の場合は、フィルタ処理のアクションを利用して簡単に指定できるのですが、コレクションの場合はそのままではフィルタ処理が行えません。そのため素直に処理を作成すると、ForEach を利用したループで 1 件ごとに存在するかチェックし、存在していなかったら変数に追加していく方法をとることも多いと思います。この形で要件は満たせるのですが、対象となるデータ件数が増えると飛躍的にアクション数と実行時間が増えてしまうのがネックです。特に Logic Apps の場合では、アクション数が増える＝課金が増える ことに直結していますのでできる限りアクション数は押さえたい所です。

今回の全体的な処理の流れは次のようになります。

今回のサンプルデータとして、JSON 値を持つ配列を次のように作成しています。

A のコレクションには name という値に A, B, C, D, E と設定し、B のコレクションには A, B, C, E, F と設定し、差分が発生するように作成しています。A と B を比較して、A のみに存在する name = D となるものだけを取得してみます。

そのためにはフィルタ処理を利用するのが最善のため、比較対象となる項目だけを抽出して配列を作成します。一度ヘッダ情報のない CSV 作成を行うことで、配列に変換できるデータが作成できます。

このような形で比較項目だけに限定して抽出できたので、これを配列に変換します。

split 関数を利用して配列へ変換するのですが、その時は Logic Apps や Flow での悩みの種である改行コードが付いて回るので、uriComponent 関数を利用して変換した結果から、改行ごとに分割して配列を作成するように記述します。

split(uricomponent(body('AコレクションからCSVテーブルの作成')),'%0D%0A')

配列が作成できたので、ようやくフィルタ処理が行えます。対象となるのはコレクション B を指定し、フィルタ条件としては次のように設定します。

contains(outputs('Aコレクションから比較要素のみで配列化'), item().name)

上記の関数式の結果が False になれば、A コレクションには存在しない B コレクションだけのものと判断できます。このような形で処理を行うことで、コレクション間の差分をレコード数に関係なく 3 アクションで取得が可能です。contains 関数は対象が配列であれば、含む・含まないの判断が容易に行えますので、比較対象の値だけに絞った配列を作成することを活用してみてください。

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

Logic Apps や Flow のワークフロー定義は、CodeView や Flow Management コネクタ、または REST API による取得が可能です。その際の取得結果は、大体月のような構造になります。

ワークフロー上のアクションは、definition\actions の値として配列な形で記載されます。この時のキー名はデザイナー上で命名したものが利用されますので、どのようなキー名となるかは固定できません。そのためワークフロー上でこの JSON 値を利用しようとすると、非常に厄介です。今回はこのアクション情報を、1次元の配列に鳴らした形に変換します。

作成した変換用ワークフローの全体図は次のようなものです。

JSON 値のキー名を単純に列挙するのは、Logic Apps の場合 InlineCode コネクタで JavaScript による処理を行うのが、最も楽です。次のコードだけで対応できます。

Object.keys(workflowContext.trigger.outputs.body.actions)

このように Object クラスの Keys メソッドを利用すると、キー名の列挙が行えます。ただし、子要素については列挙されませんので、その部分をどうするかが一番の問題となります。そこで今回は、列挙できたキー名に対してそれぞれ actions という子要素があるかどうかチェック、ある場合は子要素の解析を行うという処理方法を採用しています。

列挙したキー情報を指定して、For Each にてループを作成します。これで各要素に子要素があるかを判断させるようにします。ただし、InlineCode コネクタの処理結果は文字列として連携されてきますので、結果に対して Array 関数で明示的に配列へと変換したうえでループを行う必要があります。

子要素の存在チェックですが、次のような聞き方をしています。

empty(triggerBody()?['actions']?[item()]?['actions'])

最初の HTTP Request トリガに渡されてきた値にある actions、その中に列挙できたキー名でアクセスしてさらに actions という子要素があるかどうか、という聞き方です。真ん中ほどの item() の部分が列挙されたキー名、その後に ? 演算子を付けた形で actions 子要素を参照しに行かせています。？ 演算子を利用することで、実際には要素が存在していない場合でも実行時エラーになることを防いでおり、参照できた場合はその値、できなかった場合は空文字列が返却されてきます。そのため empty 関数で「値があるかないか」を判別させ、値がある＝子要素がある、値がない＝子要素がない、という形で判定を行います。

子要素が存在した場合は、その子要素のキー名を列挙させる必要があります。サンプルのワークフロー定義でいうと、「ダミースコープ」というアクションの中には actions 要素があり、その中で実際に配置された子アクション「エラーとなる計算」が記載されているのがわかると思います。ここは簡単に処理する場合、IF アクションの中でさらに IF アクションで判定させる、とするのですが、Logic Apps や Flow の仕様上だと 8 階層まで深く作ることができてしまいます。そうすると IF を 8 階層組み上げることになるのですが、流石にそれはワークフローとして見づらいものとなります。

このような場合、プログラム開発を行ったことがある人であればお気づきでしょうが、再帰的処理、という方法を採用します。これは自分自身を呼び出す方法で、階層が深い場合には適した手法です。

IF が満たされた場合の処理、すなわち子要素が存在していた場合の処理として、自分自身を呼び出すように HTTP アクションを利用します。こうすることで、別インスタンスとして同じ処理を起動させ、子要素のものからキー名を列挙させることができます。

ここでの戻り値をどう処理するかですが、このワークフローでは最終的に配列な値をそのまま返却するように HTTP Response アクションを設定しています。

そのため再帰的に呼び出した時の結果はそのまま配列変数に追加したいのですが、まとめての追加は Union 関数を利用する必要があるのと、変数の設定アクションでは自分自身を指定することができない（変数 A の設定アクションでは、A の値を利用できない）ため、素直に For Each で処理結果をループさせて追加しています。

試しに Postman でワークフローを呼び出し、結果を確認してみると、ワークフロー定義の情報からアクションを列挙できているのがわかるかと思います。

このようなワークフローをくみ上げると、ワークフロー定義の JSON 情報を渡すことで、アクション情報を列挙することが可能です。これは特定の値だけを抽出して1次元配列に変換する、というパターンですので、色々と応用が利く場面があると思います。

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

まず UI Flow ですが、利用するための条件が色々あります。公式ドキュメントはプレビューな内容ですが、参考になります。なお、私が試している環境は、Azure 上に構築した Windows 10 Insider な VM を利用しています。

必ず必要なもの

• 組織アカウント
  （Azure Active Directory に登録してあるアカウント）
• Chrome ブラウザか Chromium 版 Edge ブラウザ
• CDS 利用可能な環境とライセンス
  （CDS 必須なためプレビュー環境では利用できません）
• UI Flow Apps
  (UI Flow を作成しようとしたときに、ローカルへインストールを求められます)
• Common Data Service ソリューション環境
  (現時点ではソリューション上でないと UI Flow を呼び出せない)

Web用 Ui Flow 作成時で必要なもの

• Selenium IDE
  (UI Flow を作成しようとしたときに、ブラウザ拡張としてインストールを求められます）

デスクトップ用 UI Flow 作成時では、上記の UI Flow Apps がインストールされていれば大丈夫です。

UI Flow 実行時で必要なもの

• オンプレミスデータゲートウェイ

作成時では不要ですが、実行時にはオンプレミスデータゲートウェイが必要です。これは Power Automate
環境とのやりとりが必要と考えると理解できます。セキュリティ設定的にも、オンプレミスデータゲートウェイを利用している場合は、受信ルールを変更する必要がないのもあり非常に楽です。

UI Flow は先にワークフローを作成する必要があります。

作成するときは、マイフローのメニューから UI フローを選択します。

初期状態ではこのようになります。ここで UI フローの作成をクリックすると、Web 用 フローかデスクトップ用フローか、どちらを作成するのかを聞かれます。

ここで選択したものにより、以降の操作などが変化します。

デスクトップ用 UI Flow の作成

デスクトップアプリを選択し、次へをクリックするとワークフローの名前を求められますので、適当に入力し、次へをクリックします。

ワークフローの名前はこれまで通り、後で変更も可能です。次へをクリックすると、次は「入力フィールド」の設定です。入力フィールドとは、Power Automate の通常なワークフローから、UI Flow を呼び出す際に連携する値のことで、呼び出し元から渡した値で入力させるといった使い方になります。

新規追加をクリックすると、求めるフィールドの設定を求められます。

ここで入力するものは「入力ラベル」「サンプルデータ」「説明」の3点で、Power Automate で UI Flow を呼び出す際、デザイナー上に表示されるものとなります。値を渡す必要がなければ未設定で構いません。

フィールドの次は UI Flow
のワークフロー設定です。初期状態では上記のようなワークフローとなっていて、トリガとアクションが一つずつ用意されています。アクションのところが、実際の操作を記録させ最終的にワークフローに変換したものとなります。

Recording となっているアクションを開くと、レコーダーの起動がありますので、それをクリックします。そうすることで操作を記録させるツールが起動します。

起動するとこのような感じになります。画面上部に捜査記録用のツールが起動しているのが見えるかと思います。ここで起動しない場合、UI Flow Apps が起動していないことが考えられますので、タスクトレイにアイコンが潜んでいるかをチェックしてみてください。またプレビュー状態ということもあり、他の理由も考えられますがそのうち情報が公開されたり、修正が行われるものと思っています。

ツール上の Record をクリックすると、そこからの操作が記録開始となります。一通り操作を行い、Done をクリックすると操作内容がワークフローに展開されます。

例えば、Windows10 の検索で電卓を検索して起動、その後ポチポチとしていたような場合は、このようなワークフローに展開されます。恐らくは利用するアプリが切り替わる単位でスコープが区切られるのではないか、と思います。なおこのように展開されたワークフローは、直接編集が可能です。

アプリの起動であれば、このような項目が設定可能です。また、マウスの操作では実際に操作している時のスクリーンキャプチャが表示され、何を行うのかが視認可能です。不要な操作を削除するのは、アクションの削除と同じで各アクションの右上メニューから削除が行えます。

操作の記録が終わり、ワークフローの調整が終わったら、下に表示されている次へをクリックします。

次に設定するのは出力フィールドです。これは入力フィールドの反対で、UI Flow からワークフローへ値を戻す際の設定です。この項目の設定は、操作の記録中に行う必要があります。

記録中に、Get Output をクリックすると、出力フィールドの設定が行えます。フィールドの名前を入力し、実際に返却したい値を画面の対象項目をクリックして選択します。

その後ワークフローへ戻ると、このように設定した出力フィールドの内容が反映されます。出力フィールドの設定が終わったら、次へをクリックして作成した UI Flow のテストを行います。

入力フィールドを利用している場合は、値の入力を求められます。必要な入力を行ったら今すぐテストをクリックすると、作成した UI Flow のテスト実行が行えます。

テスト実行して問題があれば、各アクションの調整や再度操作記録を作成する必要があります。問題がなければ保存して終了します。

これでデスクトップアプリ用の UI Flow は作成完了です。通常のワークフローから呼び出すことで、操作を開始することができるようになります。

Web 用 UI Flow の作成

Web 用では Selenium IDE を利用して、RPA を行います。

Web 用の場合は、ワークフローの名前と開始時に開く Web サイトの URL が必要です。入力してレコーダーの起動をクリックします。

レコーダーの起動をクリックすると、Selenium IDE が起動します。ここから先は、Web 開発を行っている方であれば利用されてる方も多いであろう、Selenium そのものです。

Selenium IDE 右上部にある REC をクリックすると、操作の記録が開始され、先に入力したベースの URL がブラウザで開かれます。

ブラウザ上で各種操作を行った後で、再度右上部の STOP REC をクリックします。そうすると Selenium IDE 上にここまでの操作が展開されます。

デスクトップ版 UI Flow であった、入力/出力フィールドですが、Selenium IDE 上で直接設定を行う櫃よぐあります。例えば Store 系のコマンドを利用したものが入力/出力フィールドに対応していますので、IDE 上で直接記載を行います。このあたりは公式ドキュメントでも触れられていますので参考にしてください。

Selenium IDE 上での入力が終わったら、右上の保存ボタンをクリックします。

デスクトップ用 UI Flow と違い、Web 用 UI Flow では、Selenium IDE 上での設定がすべてで、Power Automate 側で調整などは行えません。フローの詳細画面もありませんので、直接 Selenium IDE でやりくりすることになります。

作成した UI Flow の実行

作成した Ui Flow を実行するには、ソリューション環境上で Power Automate のワークフローを作成します。

ソリューション一覧から、Common Data Service Default Solution をクリックします。

何も作成していなかった場合はこのような表示です。とりあえず新しいワークフローを作成します。

ソリューション上のワークフローでは、UI Flow を呼び出すためのコネクタが用意されていて、デスクトップ用/Web用 UI Flow の呼び出しを行うアクションが用意されています。

デスクトップ用 Web 用 どちらの UI Flow でも、呼び出す際にはオンプレミスデータゲートウェイ経由での接続が必要です。データゲートウェイの接続設定を求められますので、必要事項を入力します。

Web 用 UI Flow 呼び出しでは、呼び出す UI Flow 名と実行するブラウザの種類を選択します。

デスクトップ用 UI Flow 呼び出しでは、呼び出す Ui Flow 名を選択します。

また、デスクトップ/Web 双方で入力フィールドを設定している場合は、上記のようにデザイナー上で値の設定欄が追加表示されます。

出力フィールド設定を行っている場合は、後続の処理でダイアログに表示されますので、いつも通りの方法で結果の利用が可能です。

このような形で UI Flow は利用が可能です。デスクトップ用と Web 用で、設定する方法が全然違うので慣れが必要ですが、何かしらの自動操作を行うイメージはついたのではないでしょうか。実際の場面では、入出力フィールドを絡めて操作する内容を調整することも行えますので、汎用的な対応が可能です。是非色々触ってみてください。

 どんなコネクタなのか 

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

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

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

環境まわりの機能

接続情報の作成機能

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

最後に

このエントリは 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

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

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

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

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

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

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

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

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