MakeでAIの分類結果を分岐させたら、同じ問い合わせから複数の下書きや通知ができる。その場合は、分類モデルの出力だけでなく、分岐を「複数条件に合えば全部実行する」形にしたか、「一つだけ選ぶ」形にしたかを確認します。ルートを上から並べただけでは、一つを選ぶ処理になるとは限りません。
この記事は、MakeのScenarioで、AI分類後の条件分岐と後続処理を設計する手順です。公式資料と独自の架空入力を基に整理しており、実際のMake操作、AI呼び出し、下書き作成、送信は行っていません。掲載件数は条件を手元で計算したもので、製品の実行履歴や料金ではありません。
目次
Routerの順番と、排他的な選択を分ける
Makeの公式Router資料は、ルートを並列ではなく順番に処理すると説明しています。ただし、その順番は「最初に通ったルートで終了する」という意味ではありません。各ルートのFilter条件を確認し、同じ入力が複数の条件を満たすかを調べます。Make：Router（新しいタブで開く）
一方、公式のIf-elseは、最初にtrueとなった条件のルートだけを実行し、どれもtrueでなければElseへ進む機能です。複数箇所へ配るのか、一つの処理方針を選ぶのかで使い分けます。Make：If-else and Merge（新しいタブで開く）
例えば、同じ記録を台帳と検索索引の両方へ保存したいなら、複数ルートが必要な設計もあります。反対に、一件の問い合わせについて「確認待ち」か「下書き作成」のどちらかを選びたいなら、同時に二つへ流れない条件が必要です。
AI出力を検査してから、分岐へ渡す
最初に、AIへ何を判断させ、Make側で何を確定するかを決めます。以下は問い合わせを分類した後の入力例です。実AIの出力ではありません。
{
"record_id": "Q001",
"category": "billing",
"needs_review": true
}
categoryはbilling、support、otherのように許可値を決め、needs_reviewは真偽値として検査します。文字列の"true"、値なし、許可外の分類を、正常なfalseやotherと同一視しません。形式が合わない入力は、ここから先の通常分岐へ渡さず、入力確認の対象として分けます。
この例では、AIの分類がbillingでも、needs_reviewがtrueなら人の確認を優先する業務ルールとします。分類語から担当者や送信許可を自動的に補うものではありません。実際の優先順位は、チームの業務要件で決めてください。
四つの入力で、条件の重なりを見る
通常ルートAを「needs_reviewがtrue」、Bを「categoryがbilling」とし、どちらにも合わない場合のfallbackには追加の絞り込み条件を置かないとします。次は検算用の架空データです。
表は横にスクロールできます
| 入力ID | category | needs_review | Routerで通るルート |
|---|---|---|---|
| Q001 | billing | true | AとB |
| Q002 | billing | false | B |
| Q003 | support | true | A |
| Q004 | support | false | fallback |
Q001は二つの条件を同時に満たします。Aを上へ移しただけでは、Bの条件を満たす事実は変わりません。各ルートの後ろに同種の通知や下書き生成を置けば、重なりが後続の複数処理につながる設計になります。
この表では、入力は4件、ルートを通る回数は合計5回です。ルートごとに後続モジュールが何回動くか、さらにどのように課金されるかは別の計算です。「4件だから4回しかAIを呼ばない」「差分1回がそのまま1credit」という見積もりには使いません。
公式のfallbackは、ほかのルートの条件に合わないデータの経路です。Aで後続処理が失敗したときの復旧先、という意味ではありません。またfallback自体にもFilterを設定できるため、実Scenarioではその追加条件も確認してください。
一つだけ選ぶなら、優先順位を条件へ落とす
確認待ちを優先し、その後に請求関係を処理するなら、If-elseの条件を次の順に置く案があります。
- needs_reviewがtrueなら確認待ち。
- それ以外でcategoryがbillingなら請求用の下書き処理。
- どちらでもなければElseで別途確認。
この場合、Q001は最初の条件だけを選ぶため、請求用下書きへは進めません。四つの入力は次のように分かれます。
表は横にスクロールできます
| 入力ID | 選ぶ経路 | この時点で行わないこと |
|---|---|---|
| Q001 | 確認待ち | 請求用下書き処理 |
| Q002 | 請求用下書き処理 | 確認待ち経路の処理 |
| Q003 | 確認待ち | 請求用下書き処理 |
| Q004 | Else | 分類だけを根拠に送信 |
こちらの選択経路は合計4回です。これは分岐条件だけの検算で、AI判定が正しいことや、Scenario全体が一度しか実行されないことを証明しません。
Routerを維持したい場合も、Bを「needs_reviewがfalse、かつcategoryがbilling」のように、業務要件に応じて排他的な条件へ直す選択があります。どちらの設計でも、両条件に合う入力、片方だけ、どちらにも合わない入力を確認します。
共通処理へ戻すなら、Mergeの対象を確認する
分岐後に同じ保存処理へ戻したい場合、公式のMergeはIf-elseの条件ルートを再接続し、有効な経路のデータを後続へ渡す機能です。Routerの枝をそのままつなぎ直すためのモジュールではありません。
例えば、選んだ経路でroute_statusをREVIEW、DRAFT、OTHERへ整え、Mergeの出力へrecord_idとroute_statusをマッピングしてから、共通の記録処理へ進む案です。これは保存設計の例で、実際にMakeへ登録したものではありません。
Mergeを置くだけで、全経路の情報が必要な形になるとは考えず、どの経路のどの値を出すかを設定します。確認待ちの入力へ下書き本文が存在すると仮定したり、欠けた値を別の入力から補ったりしないようにします。
分岐の重なりと、再実行の重複は別に調べる
同じrecord_idが二重に保存された原因は、分岐の重なりだけとは限りません。トリガーの再受信、再試行、手動再実行など、Scenarioへ何回入ったかも確認します。
調査では、入力ID、実行を識別する情報、AI出力、Filterの値、通った経路、保存先の結果を結び付けます。一回の実行で二つへ流れたのか、同じ入力が二回実行されたのかを分けてください。
修正確認では、外部送信を含まない許可された検証構成で、正常値と形式不正、条件の重なりを確認します。既存のScenarioを一括で置き換えたり、通知を送ってから件数を数えたりすることを、診断の前提にしません。
一つの結果を選ぶ分岐ができても、下書きの内容確認や実際の送信判断は別です。AI分類の結果、処理経路、外部操作の完了をそれぞれ記録すると、二重処理を直したつもりで別の問題を隠すことを避けやすくなります。
参考資料
公式資料の確認日：2026年10月23日。モジュールの利用可否と表示は対象環境で確認してください。四つの入力と経路数は架空例の条件計算です。