Power Automate の条件分岐まとめ｜equals と contains・if()・null 対策

📝 この記事は、Power Automate で条件を書くときの選び方を、実際に動かしながら整理したものです。
式や関数の仕様はMicrosoft 公式（ワークフロー式の関数リファレンス）で確認しています。

条件アクションを置いたのに、思ったように分かれない。
原因はたいてい、比較の方法か、型か、空欄のどれかです。
この記事では、条件の3つの欄・equalsとcontains・if()・null対策を1本にまとめます。

条件は「置けば動く」ので、間違っていても気づきにくいところです。
講座では、わざと誤判定するデータを流すようにしています。言葉で説明するより、1回動かしたほうが早いと思ったからです。

条件アクションは「質問を1つ作る」だけ

設定画面に欄が3つ並んでいて戸惑いますが、やっていることは単純です。

左＝いま持っている値。
中＝どう比べるか。
右＝比べる相手。

「タイトルは（左）、会議という言葉を（右）、含んでいますか（中）」という
1つの質問を組み立てているだけです。答えが「はい」か「いいえ」で処理が分かれます。

📌 equals と contains を取り違えない

この2つは、名前が似ているのに動きがまったく違います。

equals（等しい）｜完全に同じときだけ通ります。1文字違っても、余分なスペースがあっても通りません。

「承認済み」equals「承認済み」→ true　／　「承認済み」equals「承認」→ false

contains（含む）｜指定した文字が含まれていれば通ります。

「来月の会議について」contains「会議」→ true

これは実際に社内で起きたパターンです。
ステータスを contains で見ていて、似た名前の別ステータスまで承認扱いになっていました。エラーが出ないので、指摘されるまで気づきませんでした。

📌 比較が通らないときは「型」を疑う

見た目が同じなのに一致しない、という場合はたいてい型が違っています。

文字列の "100" と数値の 100 は別物です。
Excel や SharePoint から取った値は、思っている型と違うことがよくあります。

そろえてから比べます。数字として比べるなら int()、
文字として比べるなら string() を通します。

equals(int(変数A), 100)　／　equals(string(変数A), '100')

日付も同じです。表示が同じでも、書式が違えば一致しません。
formatDateTime() で形をそろえてから比べます。

アクションを増やさない書き方：if()

「値を切り替えたいだけ」のときに条件アクションを置くと、フローが縦に伸びていきます。
値だけなら if() で1行です。

if(条件式, 真のときの値, 偽のときの値)

if(equals(変数, ''), '未設定', 変数)

使い分けは単純です。処理の流れを分けたいなら条件アクション、値を選ぶだけなら if()。

📌 空欄（null）でフローを止めない

「特定の申請だけエラーになる」という現象の原因は、ほとんどが空欄です。

任意項目が未入力だったり、リストの列に値が入っていなかったりすると、
その値は null（何も入っていない状態）になります。
空文字とは別物で、そのまま後続に渡すとエラーになることがあります。

備えは coalesce() です。並べた中から最初の null でない値を返します。
全部 null なら null を返します。

coalesce(triggerBody()?['備考'], '（記載なし）')

候補は何個でも並べられるので、
「ニックネーム → 氏名 → 固定文字」のように段階的に落とすこともできます。

条件を式で書く（詳細モード）

条件アクションには、欄を埋める方法のほかに式で書くモードがあります。
条件が複雑になってきたら、こちらのほうが見通しが良くなります。

複数の条件を組み合わせるときは and() と or() を入れ子にします。

and(equals(変数A, '承認'), greater(変数B, 10000))

「どちらか片方」なら or()、「〜でない」なら not() です。

or(equals(状態, '差戻'), equals(状態, '却下'))

比較に使える関数

equals と contains のほかにも、よく使うものがあります。

前方一致・後方一致｜伝票番号の頭文字や、拡張子で判定するときに使います。

startsWith(ファイル名, 'INV')　／　endsWith(ファイル名, '.pdf')

空かどうか｜空文字も、空の配列も「空」と判定します。

empty(変数) → 空なら true

長さ｜文字数や件数で分岐したいときに使います。

length(配列) → 件数　／　length(文字列) → 文字数

承認の結果で分ける

承認アクションの結果を条件に使うとき、引っかかりやすい点があります。

返ってくる値は Approve / Reject の英語です。
画面の表示が日本語でも、フローに渡る値は英語のままです。

equals(outputs('承認')?['body/outcome'], 'Approve')

日本語の「承認」と比べても、永遠に一致しません。
画面に見えている表示と、中で持っている値は別物という考え方は、
選択肢の列やドロップダウンでも同じです。

失敗したときだけ動かす

条件アクションとは別に、前のアクションが失敗したときだけ動かす仕組みがあります。
アクションのメニューにある「実行条件の構成」です。

ここで「失敗した」「タイムアウトした」にチェックを入れると、
前が転んだときだけ、そのアクションが動きます。

フローが止まったことに気づけないのは、運用でいちばん困る状態です。
失敗時に自分へ通知を送るアクションを1つ置くだけで、対応が何日も早くなります。

実際に組んでみる：申請の自動振り分け

ここまでの話を、1本のフローにつなげます。
「申請が来たら、金額と種別で送り先を変える」という形です。

条件から書き始めると、あとで値を確かめに戻ることが多いです。
受け取った値をそのまま出して見るだけなら1分で終わります。順番を入れ替えただけで、作る時間が短くなりました。

補足：確認ポイント

スイッチと条件はどう使い分けるか
分岐が3つ以上あって、しかも1つの値の中身で分かれるだけなら、
スイッチのほうが読みやすくなります。
条件アクションを入れ子にすると、階層が深くなって追えなくなります。
逆に、複数の値を組み合わせて判断するなら条件アクションです。

選択肢の列は文字列として比べられないことがある
SharePoint の選択肢列や、参照している列は、
表示上は文字に見えても、中では別の形で持っていることがあります。
そのまま比べて一致しないときは、実行履歴で実際に入っている形を確認すると分かります。
?['Value'] のように、中の項目を指定する必要がある場合があります。

大文字と小文字は区別される
equals() は大文字と小文字を別のものとして扱います。
入力のゆれが想定されるなら、toLower() で片方にそろえてから比べます。

まとめ

※ 本記事は公開日時点の内容です。筆者が実際に試した手順をまとめたもので、Power Automate の仕様は今後変わる可能性があります。
※ 記事の構成・図解の一部は、AIを壁打ち相手にしながら作成しています。