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

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

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

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

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

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

なぜなら、「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'))』

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

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

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

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

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

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

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

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

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

おわりに（＋おまけ）

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

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

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

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

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

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

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