MakeのRouterとIf-elseの違い｜複数へ配る処理と一つを選ぶ処理

Makeで条件ごとに処理を分けた後、最後の記録処理を何本もコピーしていませんか。分岐の見た目が似ていても、RouterとIf-elseでは、同じデータに対して通る道の考え方が違います。ここを選び間違えると、通知が二重に届いたり、更新漏れのあるコピーが残ったりします。

複数の仕事へ配りたいならRouter、一件につき一つの判断をしてから共通処理へ戻したいならIf-elseとMergeを検討します。既存のシナリオを丸ごと置き換える前に、小さな例で違いを確かめましょう。

分岐を選ぶときの判断表

一件を複数へ配るのか、一つへ振り分けるのか

例えば問い合わせが来たとき、担当者へ知らせることと受付台帳へ残すことを両方行いたいなら、複数の経路に進む構成に意味があります。一方、対応区分を「資料不足」「回答準備」「対象外」のどれか一つに決めたい場合は、同じ一件を複数の区分へ送ると困ります。

Routerでは各経路のフィルターを評価するため、条件が重なれば複数の経路を通る可能性があります。上の経路を通ったら下の経路が自動で止まるという前提では組まないでください。複数へ配る仕組みと、選択肢から一つを選ぶ仕組みを分けることが最初の設計です。

If-elseは条件に応じて一つの経路を選び、対応するMergeへ戻して後続を共通化できます。ただし、経路が一つに決まることと、業務上の分類が正しいことは別です。条件の順番や空欄の扱いが誤っていれば、誤った区分へ一件ずつ正確に流れるだけです。

同じ入力で二つの構成を比べる

説明用に、問い合わせへ「契約中」「添付資料あり」という二つの情報が付いているとします。契約中の相手には担当者通知、添付資料のある問い合わせには資料保管を行いたいなら、両方に当てはまる入力で二つの処理が動くことは意図どおりです。

同じ情報を受付区分の判定に使うなら、どちらを優先するか決める必要があります。「契約中なら担当者確認」「それ以外で資料不足なら追加依頼」という順番と、資料不足を最優先にする順番では、結果が変わります。これはMakeが決めることではなく、運営側が決める業務ルールです。

まず紙や表に、入力と期待結果を書きます。契約中で添付あり、契約中で添付なし、未契約で添付あり、未契約で添付なしの四通りを用意すれば、条件が重なる場合と外れる場合を比べられます。テスト件数を増やす前に、何が正解なのかを明文化してください。

Routerの順番とフォールバックを誤解しない

Routerの経路は順番に処理されます。同時並行で動くことを前提に設計する機能ではありません。経路の表示位置だけを見て「最初の一件だけ通る」と判断したり、処理時間が必ず短くなると期待したりしないようにしましょう。

フォールバック経路は、他の経路の条件に合わないデータの行き先として使えます。例えば分類できなかった問い合わせを確認用の一覧へ残す使い方です。通常の経路と同じ名前を付けるより、「分類できなかったもの」と意図が分かる名前にすると、後から履歴を読みやすくなります。

ただし、未分類のものを受け止めることと、処理エラーを直すことは違います。分類条件には合っていて、その先の外部サービスで失敗したケースまで、フォールバックで自動回復すると考えないでください。条件分岐とエラー時の処理は別に点検します。

Mergeでは後続へ渡す値をそろえる

If-elseの後に共通の台帳登録を置く場合、Mergeで後続へ渡す出力名と、各経路で返す値を設定します。分岐前の受付IDと、判定後の対応区分を分けて持たせると、一件の問い合わせを追いやすくなります。

片方の経路では「回答準備」、もう片方では空欄という状態でも、後続の登録自体が動くことはあります。Mergeにつながった見た目だけで完成にせず、どの経路から来ても必要な項目が出るかを見てください。値の形式も、片方が文字列で片方が複雑なデータになっていないか確認します。

既存のRouterへMergeを付ければ、そのままIf-elseと同じ動きになるわけではありません。公式の使い分けに沿って構成を選びます。また、ネストしたIf-elseを使う場合は、その判断段階ごとに対応するMergeが必要です。最初は一段の分岐を動かしてから増やす方が、間違いを見つけやすいでしょう。

本番の送信を外して境界を試す

試すときは、顧客へのメール送信などをそのまま動かさず、テスト用の記録先で経路と値を見ます。入力ごとに受付ID、通った経路、後続の記録件数を残せば、「成功」と表示された一回の中で何件作られたかを比べられます。

条件が金額や件数なら、境界の直前、境界そのもの、直後を試します。例えば架空の運用ルールを100件以上で別対応とするなら、99件、100件、101件を入れます。比較記号を一つ取り違えるだけで、境目の一件が想定外になります。

空欄、想定外の文字、取り込めなかった値も加えます。AIが付けた分類を使う場合は、その出力が毎回同じ表現になるとは限りません。見慣れない値を無理に通常処理へ流さず、確認用に分ける条件を決めておくと、後で修正する対象を拾えます。

テスト結果を比べる際は、通る道の数と登録先の件数を分けます。Routerの二経路が正しく動いても、両方が同じ台帳へ一行ずつ追加していたら、業務上は二重登録になるかもしれません。ノード単位の成功だけでなく、最後に残るデータまで確かめます。

既存シナリオはコピーで変更する

運用中の構成を直すなら、変更前のシナリオと設定を残し、複製した側で比較します。分岐後の同じ処理をまとめると保守しやすくなりますが、もともと経路ごとに少し違う条件があった場合は、その違いまで消してしまわないよう注意してください。

移行前後で同じ入力を使い、出力先、対応区分、記録件数を比較します。結果が違う場合は、それが改善による意図した変更なのか、設定漏れなのかを一件ずつ判断します。「シナリオが短くなった」という見た目だけで本番へ切り替えないでください。

引き継ぎには分岐条件と優先順位、未分類データの行き先、Mergeの出力項目を残します。後から問い合わせ区分を増やす人が、既存の条件と重なるかを判断できる書き方にしましょう。分岐は増やすより、何を一度だけ行いたいかを決めることが大切です。

確認日：2026年10月16日。仕様はMake公式 RouterとIf-else and Mergeを確認。問い合わせ分類とテスト値は説明用の仮定例です。