Power Automateの条件分岐 条件とスイッチの使い分け・複数条件の設定方法を解説

申請金額が一定額を超えたら部長に承認を回す、ステータスによって送る文面を変える、該当データがあるときだけ処理を進める。業務を自動化していくと、必ず「場合によって処理を変えたい」という要件が出てきます。

Power Automateには条件分岐の仕組みが複数用意されていますが、どれを使うべきかの判断基準を知らないまま作ると、分岐が深くなって読めないフローができあがります。また、条件の書き方によっては、想定と違う側に流れてしまうこともあります。空かどうかの判定や日付の比較は、その代表例です。

本記事では、条件分岐の仕組みの全体像から、条件アクションの基本、複数条件の組み方、スイッチとの使い分け、つまずきやすい判定パターン、そしてデスクトップフローでの書き方までを順番に整理します。

確認したいポイント	結論	詳細
条件分岐はどう作る？	条件アクションが基本	コントロールの「条件」を追加し、はいの場合といいえの場合にそれぞれ処理を入れます。
3つ以上に分けたいときは？	スイッチを使う	1つの値を固定の選択肢で振り分けるなら、条件を入れ子にするよりスイッチが読みやすくなります。
複数条件はどう設定する？	行を追加してAndかOrを選ぶ	同じ階層でAndとOrは混在できません。混ぜたい場合はグループを追加して階層を作ります。
思った側に分岐しないのは？	型と空判定が原因のことが多い	空文字とnullの違い、数値と文字列の違い、日付の形式やタイムゾーンのずれが典型的な原因です。

この記事でわかること

• 条件アクション・スイッチ・式という3つの仕組みと、その使い分けの基準
• 条件アクションの構成と、ANDやORを使った複数条件の設定手順
• 3つ以上に分けたいときにスイッチを選ぶ理由と、既定のケースの重要性
• 空判定や日付比較など、想定どおりに分岐しない典型パターンと対処
• ループやフィルターと組み合わせるときの設計と、デスクトップ版での書き方

▼ 業務自動化をどこまで進められるか整理したい方へ Power Automateや生成AIを使った業務効率化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

Power Automateの条件分岐の全体像

設定方法に入る前に、選択肢を把握しておきます。同じ分岐でも、使う仕組みによって作りやすさと後からの読みやすさが変わります。まずは3つの手段と、選び方を整理します。

用意されている3つの仕組み

クラウドフローで分岐に使えるのは、主に次の3つです。はいといいえの2択に分ける「条件」アクション、1つの値を複数の選択肢に振り分ける「スイッチ」、そして値そのものを式で切り替える方法です。

条件とスイッチは処理の流れを分けるもので、デザイナー上でも分岐として表示されます。一方、式による切り替えは分岐を作らず、1つのアクションの入力値だけを条件によって変える使い方です。式による切り替えは、if関数を使って「条件が成立すればA、しなければB」という値を作る書き方です。承認者の宛先、メールの件名、書き込む区分名など、値だけが変わる場面で活躍します。

たとえば「金額が10万円以上なら承認者をAさん、未満ならBさん」という程度であれば、分岐を作らずに承認者の欄で切り替えるほうがフローは短く済みます。処理そのものが変わるのか、値だけが変わるのかで判断してください。

分岐を作るかどうかの判断は、後の保守にも影響します。分岐が増えるほどテストすべき経路が増え、修正時に見落とす箇所も増えます。分けずに済むならそのほうがよい、という前提を持っておいてください。

クラウドフローとデスクトップフローの違い

Power Automateには2種類のフローがあり、条件分岐の書き方もそれぞれ異なります。クラウドフローは条件アクションとスイッチ、デスクトップフローはIfとSwitchのアクションを使います。

考え方は似ていますが、操作画面も用語も違います。情報を探すときは、どちらのフローの話なのかを必ず確認してください。本記事では両方を扱います。

どれを使うかの判断基準

判断は単純です。真偽の2択なら条件、固定の選択肢から1つを選ぶ判定ならスイッチ。これが基本になります。ステータスが5種類あってそれぞれ処理が違うなら、条件を入れ子にするよりスイッチのほうが構造が一目で分かります。

範囲の判定、空かどうかの判定、ANDとORが混ざる複雑な条件は、条件アクションの領域です。スイッチは値の完全一致でしか振り分けられないため、こうした判定には使えません。

そして、処理は同じで値だけが変わるなら、分岐を作らずに式で切り替えます。この3つの見極めができるだけで、フローの見通しは大きく改善します。

条件アクションの基本的な使い方

まずは基本となる条件アクションです。構成はシンプルで、判定部分と2つの分岐先という3つのパーツでできています。

条件アクションの構成

条件アクションは、「条件」「はいの場合」「いいえの場合」の3パーツで構成されます。条件に判定内容を書き、結果に応じてどちらかのブロックに入っているアクションが実行されます。

追加は、新しいステップから組み込みのコントロールを選び、その中の「条件」を選択します。コネクタ名は環境によってコントロールと表示される場合があります。

判定部分は、左に判定したい値、中央に演算子、右に比較対象という並びです。左側には、トリガーや前のアクションから受け取った動的なコンテンツを差し込みます。

なお、条件アクションには名前を付けられます。既定の「条件」のままにせず、「金額が10万円以上か」のように判定内容が分かる名前へ変えておくと、フローを開いたときに中身を展開しなくても流れを追えます。

これは分岐が複数あるフローで特に効いてきます。デザイナー上に「条件」「条件2」「条件3」と並んでいる状態では、どれが何を判定しているのか分かりません。

使える演算子

中央の演算子には、等しい、等しくない、次の値以上、次の値以下、次の値より大きい、次の値より小さい、を含む、で始まる、で終わるといった選択肢が並びます。文字列、数値、日付のいずれを扱うかで、選ぶべきものが変わります。

「を含む」は部分一致の判定に使えて便利ですが、意図しない一致を拾うことがあります。たとえば「A社」で判定すると「AA社」も該当してしまいます。完全一致で足りる場面では、等しいを選んでおくほうが安全です。

判定に使う動的なコンテンツが一覧に出てこない場合は、前のアクションで一度「作成」などに値を出しておくと選べるようになることがあります。入れ子の階層が深いデータでは、この方法が有効です。

「いいえの場合」を空にしてよいか

条件に該当しなかったときに何もしないのであれば、「いいえの場合」は空のままで問題ありません。フローはそのまま次のステップへ進みます。

ただし、意図して空にしているのか書き忘れているのかが、後から見た人には分かりません。何もしないことが仕様なら、コメント機能で「該当なしの場合は処理不要」と残しておくと親切です。

なお、条件の後ろにアクションを置いた場合、そのアクションはどちらの分岐を通ったかにかかわらず実行されます。両方に共通する処理は、分岐の中ではなく後ろに置くとフローが短くなります。

▼ 自社に合う自動化の進め方を相談したい方へ どの業務から着手すべきか、どこまでフローで作り込むべきかは、業務の実態によって変わります。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

複数条件の設定とANDとORの使い分け

実務では、判定が1つで済むことはあまりありません。条件アクションの中で行やグループを追加することで、複数の条件を組み合わせられます。

行を追加してANDとORを切り替える

条件の下にある追加メニューから「行の追加」を選ぶと、判定を1行増やせます。Andを選べば並んだ条件がすべて成立したときに、Orを選べばいずれか1つが成立したときに、はいの場合へ流れます。

複数の列の値をまとめて確認したい場面は頻繁にあります。公式のチュートリアルでも、スプレッドシートの複数列に対してor条件を使う例が紹介されています（出典：Microsoft Learn「Power Automate で条件式を使用する」）。

注意したいのは、同じ階層ではAndとOrを混在させられない点です。1つのグループ内はすべてAnd、あるいはすべてOrになります。混ぜたい場合は次のグループ機能を使います。

また、Orで条件を並べるときは、どれか1つでも成立すれば通過する点を忘れないでください。安全側に倒したいつもりでOrにした結果、想定より多くのデータが処理されてしまう、という取り違えはよく起こります。

グループの追加で入れ子にする

「グループの追加」を選ぶと、条件の中に一段下の階層を作れます。「AかつB」または「C」といった、AndとOrが混ざる判定はこれで表現します。

グループ単位でAndとOrを切り替えられるため、括弧を使った論理式と同じ構造を画面上で組み立てられます。作成後は折りたたんで表示できるので、見通しもある程度は保てます。

グループを多用しない

とはいえ、グループを重ねるほど読みにくくなります。階層が3つを超えるようなら、条件の書き方そのものを見直したほうがよい兆候です。

代替案としては、判定結果をあらかじめ変数に入れておき、条件ではその変数だけを見る方法があります。判定の意味に名前が付くため、後から読んだときに何を判定しているのかが分かりやすくなります。

あるいは、条件を分割して段階的に判定する構成も有効です。1つの条件ですべてを判定しようとせず、大きく分けてから細かく絞るほうが、修正時の影響範囲も小さく収まります。

詳細モードで式を書く

画面上の入力では表現しきれない判定は、詳細モードに切り替えて式を直接書くことで対応できます。andやor、equals、greater、less、emptyといった関数を組み合わせて記述します。

柔軟性は高い一方、式は画面から内容を読み取りにくくなります。担当が変わったときに解読できない状態になりやすいため、なぜその式なのかをコメントで残しておくことをおすすめします。一度詳細モードに切り替えると、画面上の入力欄には戻せない場合があります。切り替える前に、現在の条件を控えておくと安心です。

▼ 複雑になったフローの整理もご相談いただけます 「分岐が増えて手に負えない」「作った本人しか分からない」といった状態の見直しも含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

スイッチで3つ以上に分ける

分岐先が3つ以上になる場合は、条件を入れ子にするよりスイッチが適しています。1つの値を固定の選択肢で振り分ける用途に特化した仕組みです。

スイッチの構成

スイッチでは、まず判定に使う値を1つ指定します。その下にケースを必要な数だけ並べ、それぞれに一致したときの処理を入れます。どのケースにも一致しなかった場合は、既定のブロックが実行されます。

ケースは横並びで表示されるため、選択肢の数がそのまま構造として見えます。ステータスが5種類あるなら5つのケースを並べるだけで済み、条件を4回入れ子にするより圧倒的に読みやすくなります。

ケースの中身が空のままでも動作しますが、その値のときに何もしないことが意図なのかどうかは、後から見た人には判断できません。空のケースにもコメントを残しておくと、仕様として読み取れるようになります。

条件との使い分け

判断の目安はシンプルです。選択肢が決まっていて、値の完全一致で振り分けられるならスイッチ。範囲の判定、空かどうか、複数条件の組み合わせが必要なら条件アクションです。

選択肢列やステータス列のように、取りうる値があらかじめ決まっているデータとは特に相性がよくなります。逆に、金額の範囲で分けるような判定はスイッチでは表現できません。

既定のケースを必ず用意する

見落とされやすいのが既定のブロックです。どのケースにも当てはまらない値が来たときに、何もせず通過してしまうと、後から見て問題に気づけません。

想定外の値が来たことを通知する、ログに記録する、といった処理を既定に入れておいてください。マスタに新しい区分が追加されたときなど、実運用では必ず起こります。

ケースの数が10を超えるようであれば、分岐で書き分けるのではなく、対応表をリストやExcelに持たせて参照する設計も検討してください。値が増えるたびにフローを直す必要がなくなります。

完全一致と型に注意する

スイッチのケースは完全一致での判定です。前後の空白、全角と半角の違い、大文字と小文字の違いで一致しなくなります。

判定する値が自由入力の項目から来ている場合は、事前にトリムするなどして整えておくほうが安全です。選択肢から選ばれた値であれば、この心配はほぼありません。

想定どおりに分岐しない典型パターン

条件を正しく書いたつもりでも、思ったほうに流れないことがあります。原因はデータの型や表現の違いに集中しているため、パターンを知っておけば早く解決できます。

空かどうかの判定

最も多いのがこれです。値が入っていない状態には、空の文字列とnullという別々の状態があり、単純に空文字と比較しても一致しないことがあります。

確実に判定したい場合は、empty関数を使う方法が有効です。判定したい値をempty関数に渡し、結果がtrueかどうかで分岐させます。詳細モードに切り替えて記述する形になります。

また、項目そのものが存在しない場合は、比較する以前にエラーになることがあります。取得元のデータに必ずその項目が含まれるかどうかも、あわせて確認してください。

判定に使う値が前のアクションから来ている場合は、そのアクションが失敗したりスキップされたりしたときの挙動も確認してください。値が取得できていない状態で比較すると、意図しない側へ流れることがあります。

日付の比較

日付の比較も定番のつまずきどころです。日付は文字列として扱われることがあり、表記の形式が違うと正しく比較できません。

比較する前に、両辺を同じ形式に変換しておくのが確実です。また、タイムゾーンの扱いにも注意が必要です。協定世界時で保持されている値をそのまま日本時間と比べると、9時間分のずれが判定に影響します。

「今日より前かどうか」といった判定では、時刻部分の扱いも決めておきます。日付だけで比べたいなら、時刻を落としてから比較する処理を入れてください。

数値と文字列の型違い

見た目は同じでも、数値として扱われているか文字列として扱われているかで比較結果が変わります。「10」という文字列と10という数値は、同じ値とは判定されません。

大小比較でも影響が出ます。文字列として比較されると、辞書順での判定になり、9より10が小さいという結果になることがあります。数値として比較したい場合は、int関数などで明示的に変換してから比べてください。

真偽値の扱いにも注意が必要です。チェックボックス列などから返る値が、trueという文字列なのか論理値なのかで比較の書き方が変わります。ここも実際の出力を見て判断するのが確実です。

選択肢列やユーザー列の比較

SharePointリストなどの選択肢列やユーザー列は、単純な文字列ではなくオブジェクトとして返ってくることがあります。そのまま文字列と比較しても一致しません。

この場合は、動的なコンテンツの一覧から表示名やValueといった下位の項目を選びます。どの項目を比較すべきかは、テスト実行の出力を確認すれば分かります。

判定がうまくいかないときは、まずテスト実行して実際の値を確認するのが最短の解決策です。想像で式を直すより、出力を見てから組み立てるほうが確実です。

▼ つまずいたところだけでも相談できます 「条件が思ったとおりに動かない」「式の書き方が分からない」といった個別の課題も含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

ループやフィルターとの組み合わせ

複数件のデータを扱うとき、どこで絞り込むかによってフローの速度と分かりやすさが変わります。条件分岐だけに頼らない選択肢も知っておいてください。

Apply to eachの中で判定する

取得した複数件それぞれに対して判定したい場合は、Apply to eachの中に条件アクションを置きます。1件ずつ評価され、該当するものだけに処理が走ります。

分かりやすい構成ですが、件数が多いと実行時間が伸びます。該当しない件についても、ループを1周する時間はかかっているためです。

なお、Apply to eachには同時実行の設定もあります。件数が多く順序を問わない処理では有効ですが、同じデータを更新する処理では競合が起きるため、内容を確認したうえで使ってください。

アレイのフィルター処理で先に絞る

より効率的なのが、ループに入る前に「アレイのフィルター処理」で対象を絞り込む方法です。条件に合う要素だけが残るため、ループの回数そのものが減ります。

フローの見通しもよくなります。「この条件のデータだけを処理する」という意図が、ループの外側に明示されるためです。件数が多いフローでは、この構成を基本にすることをおすすめします。

なお、フィルターの条件はフローの中に埋もれやすい部分です。どういう基準で絞っているのかをアクション名やコメントに残しておくと、後から仕様を確認する手間が減ります。

トリガー条件で起動自体を絞る

さらに手前で絞る方法もあります。トリガーの設定にあるトリガー条件を使えば、条件に合わないときはフローが起動しません。

「ステータスが承認済みになったときだけ動かしたい」といった要件では、フローの冒頭で条件分岐させるより、トリガー条件で弾くほうが無駄な実行が減ります。実行回数の上限を消費しない点も利点です。

ただし、トリガー条件は式で記述する必要があり、デザイナー上では中身が見えにくくなります。設定したことと、その内容をドキュメントに残しておいてください。

取得の段階で絞る

最も効率がよいのは、データを取得するアクションの側でフィルターをかけることです。多くのコネクタには、取得時に条件を指定できるオプションが用意されています。

全件を取得してから分岐で捨てるのは、通信量と処理時間の両方を無駄にします。絞り込みはできるだけ手前で行うというのが、パフォーマンス設計の基本になります。

デスクトップフローでの条件分岐

Power Automate for desktopでも、考え方は同じです。Ifとその仲間、そしてSwitchを使い分けます。書き方の違いを整理しておきます。

If・Else if・Else

基本はIfアクションです。条件が成立したときだけ、Ifブロックの中に置いたアクションが実行されます。成立しなかった場合の処理はElseブロックに記述します。

段階的に判定したい場合は、Else ifを追加します。上から順に評価され、最初に成立したブロックだけが実行される仕組みです。条件の順序が結果を左右するため、並べ方には注意してください。

論理式で複数条件を書く

複数の条件を組み合わせたい場合は、論理式を使います。最初のオペランドにANDやORを含む式を書き、演算子を「と等しい」、2番目のオペランドをTrueとすることで判定できます。

ANDとORを混ぜる場合は、括弧で評価の順序を明示してください。括弧がないと、意図した優先順位で評価されないことがあります。式が長くなる場合は、いったん変数に入れてから判定するほうが読みやすくなります。

条件分岐の中でさらに分岐させる構成も可能ですが、入れ子が深くなるほど画面上で追いにくくなります。3階層を超えるようなら、サブフローへの切り出しを検討する目安と考えてください。

SwitchとCase

デスクトップフローにもSwitchが用意されています。Switchブロックの中に置いたCaseが、それぞれの条件に一致したときに実行されるアクションの範囲を示します。

すべての条件に当てはまらなかった場合は、既定のケースがあればそれが実行されます。クラウドフローと同様、想定外の値に備えて既定のケースを用意しておいてください。詳細はMicrosoft Learn「条件を使用する」にまとまっています。

デスクトップフローでは、条件の中で使う変数の型にも注意が必要です。テキストとして扱われている数値をそのまま大小比較すると、期待した結果にならないことがあります。必要に応じて型を変換してから判定してください。

分岐が増えたときの整理

条件が増えてフローが縦に長くなったら、サブフローに切り出すことを検討してください。処理のまとまりに名前が付き、メインのフローが読みやすくなります。

判定のルールが業務側で変わりやすい場合は、条件そのものを外部のExcelやリストに持たせる設計もあります。ルール変更のたびにフローを直す必要がなくなり、保守の負担が下がります。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

あわせて、社内で作れる人を増やす取り組みも並行して進めてください。フローが複雑になるほど、触れる人が限られていくことがリスクになります。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

Power Automateの条件分岐は、真偽の2択なら条件アクション、固定の選択肢から選ぶならスイッチ、値だけが変わるなら式という3つの使い分けが基本になります。処理そのものが変わるのか、値だけが変わるのかで判断してください。

複数条件は、条件アクション内で行を追加してAndとOrを切り替えます。同じ階層では混在できないため、混ぜたい場合はグループを追加します。ただし階層が深くなるほど読みにくくなるため、判定を変数に切り出すなどの工夫も検討してください。

思ったとおりに分岐しない原因は、空判定、日付の形式とタイムゾーン、数値と文字列の型違い、選択肢列やユーザー列の構造にほぼ集約されます。まずテスト実行して実際の値を確認するのが、最短の解決策です。

そして、絞り込みはできるだけ手前で行うこと。取得時のフィルター、トリガー条件、アレイのフィルター処理を使えば、分岐そのものを減らせます。シンプルなフローは、速いだけでなく後から直しやすいという利点もあります。

▼ 業務自動化を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからフローの設計、社内への定着支援までを一貫してご支援しています。 何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら