トリガー条件を使いこなそう!
【Power Automate】
返信メールの無限ループ化を回避する

公開日:

はじめに :返信アクションで起きうるトラブル

Power Automateで起こしがちな失敗に、無限ループがあります。
なかでも、メール受信をトリガーにして、返信を送るフローによって、大量メール返信の発生を引き起こしてしまうという恐怖体験があります(実体験)。

危うきに近寄らず・・・のスタンスで返信アクション自体の利用を避けるのもありですが、
今回はTrigger Conditions(トリガー条件)を使って無限ループを回避する方法を紹介します。
願わくば、自動返信フローの作成にトライしている方が、しくじりを起こす前にこの記事が読まれますように!

無限ループが起きるパターン

まず、どんなフローが無限ループを引き起してまうのか確認しておきましょう。
こちら↓のサンプルは、Outlookコネクターを使って、「XXの件について」という件名を含むメールをトリガーにして、何かしたうえで、同じ件名で返信する、というフローです。

Sample Flow
メールを受け取ったら返信するというシンプルな自動化フロー

一見良さそうなのですが、これを有効化すると、無限ループの完成です😅

なぜなら、「XXの件について」というメール件名をトリガーにしているので、フローが同じ件名で返信することで、その返信メール自体によって延々と新たなトリガーを引くことになってしまうからです。(実際には、一定回数ループしたら止まります。ですがやはり、テストは十分行ったうえで本番利用した方が良いでしょう)

これを避けるためには、返信メールの件名を変えてしまうのが一番手っ取り早いです。が、もし件名をキープしたい場合は、

送信者が自分の場合は、トリガーしないようにする。(=送信者が自分でないときのみトリガーする)もしくは、
件名が「RE: XXの件について」の場合は、トリガーしないようにする(=件名が「RE: XXの件について」でないときだけトリガーする)

といったように、トリガー発生に対する追加条件を加えれば良さそうです。
これが、Trigger Condition(トリガーの条件)と呼ばれるものです。

Trigger Conditionsはどこから設定する?

トリガー条件は、

トリガーの右上 三点ボタン > 設定 > 「トリガーの条件」 にある +追加 をクリック > 条件を入力し、完了

で設定できます。今回加えたいトリガー条件が「送信者が自分でないときのみ」だとすると、以下のように入力してください。

@not(equals(triggerBody()?['From'], 'youremail@domain.com'))

(youremail@domain.comはご自分のアドレスに置き換えてください)

この条件を分解すると、

・トリガー内の本文の情報のうち、『triggerBody()』
・ Fromという項目が、『?['From']』
・ youremail@domain.comとイコールでない『not(equals(省略, 'youremail@domain.com'))』

ということを示しています。トリガー条件は@アットマークで始めるのが決まりです。

Trigger Conditions
トリガー条件の指定は三点ボタンから!


インテリセンスによる補助が効かないのが辛いところですが、Excelの式と似たようなものなので、雰囲気は大体わかると思います。
@に続く演算子としては、and(かつ)、contains(~を含む)、startsWith (~で始まる)などもありますし、
カッコをネストすることで複雑な条件も表現できます。
例:and(contains(), startsWith())
条件に合わせて変えてみましょう。
なお、+追加 で複数の条件を追加した場合は、「または」の意味になります。

triggerBody()で、条件に指定する項目名を把握する

さて、上の条件に挙げたうちの triggerBody()?['From'] は、トリガーの本文内に示されたメールの差出人を示しているのですが、?以降の項目名はどこから調べれば良いのでしょうか?

トリガーの中身を調べるには、組み込み > データ操作 の 「作成」アクションを使いましょう。
これに、triggerBody()という式を入れて、保存してください。その後テスト実行し、メールを送ってみましょう。

TriggerBody
終了以降のアクションは実行されなくなるので、デバッグ時に便利!

ちなみに、組み込み > コントロールの 「終了」アクションを次に配置しておくのがおススメです。
終了を使うと、以降のアクションは実行されなくなります。ですので、VBA等におけるブレークポイントと同じような使い方が可能です。

テスト成功後、実行結果の画面で、作成アクションを開きましょう。未加工出力の表示をクリックすると、トリガー本文部分のJSONが表示されています。
ここから、差出人メールアドレスは from という項目名であるということがわかります。

この場合、未加工入力の表示をクリックしても結果は同じです。

このようにして、トリガー条件として使う項目の名前を把握することが出来ます。確認出来たら、作成および終了アクションは削除します。

※追記ですが、トリガーのヘッダーも含めた情報を知りたいときは、代わりにtriggerOutput()を使ってください。

おわりに(+おまけ)

以上、今回はトリガー条件の使い方と、トリガー本文内の項目名の調べ方を紹介しました。

トリガー条件を使うと、トリガーの発生を細かく限定することが出来るため、「無駄打ち」が少なくなります。

ですから、トリガー時点では広めに掬っておいて、その後の条件分岐で合致する場合だけ実行する、というようなフローの作り方よりも、トリガー条件を使う方が、APIコールの回数も抑えられる分、効率の良いやり方と言えるでしょう。

SharePointやDataverseトリガーでも役立つので、使ってみてください。

最後に、トリガー条件の書き方がややこしいというか、すぐ忘れそうだな、と思われるかもしれません。そういうときは、ChatGPTに頼ってみると良いでしょう。
試したみたところ、GPT3.5だとおかしな回答でしたが、GPT4ではバッチリ正答してくれました。

ChatGPTによる回答。kotlinってなってますけど…でも合ってます。

Trigger Conditionsが出始めたころ、Power AutomateがMicrosoft Flowと呼ばれていた数年前は、こんなこと出来るんだ!と感動しつつも、ずいぶん苦労して、ああでもないこうでもないとやっておりました。おかげで身に付いたので、良かったのですが、今ではこんな便利なモノがあります。

さらには今後Power PlatformでCo-Pilot機能が順次強化されていくようですから、
ChatGPTを使わずともPower Automateの中で、AIが助けてくれるようになるのでしょう。

(参考リンク)Power Platform is leading a new era of AI-generated low-code app development

いつになるかわかりませんが、そう遠くない将来でしょうし、今から楽しみです。
うまく活用しながら、省エネでやっていきたいですね。