全部の案件に同じ対応をすると、何が起きるか
問い合わせメールに AI が一律で同じ丁寧な長文を返したとします。簡単な質問をした人には長すぎ、クレームを送った人には他人事に見え、法人の大口顧客には担当者から直接返事が欲しかった、となります。顧客の性質に合わない成果物が届くと、信頼を損ないます。だからワークフローには「状況に応じて処理を変える」仕組みが要ります。それが条件分岐で、その判断材料を持っているのが変数です。
変数：名前の付いた箱
変数は、ワークフローの中でデータを一時的に入れておく「名前付きの箱」です。中に入れるデータの出どころは3つあります。
- トリガーで受け取った情報: フォームの入力値、メールの送信者。
- 外部システムから取得した情報: CRM の顧客属性、在庫数。
- 前のアクションの出力結果: AI が分類したカテゴリ、計算した合計金額。
条件分岐は、この箱の中身を見て「次にどこへ進むか」を決めます。
条件分岐の3種類：見分け方は「何方向か」と「通すか遮るか」
| 種類 | 何をするか | 使う場面 |
|---|---|---|
| If/Else | 二択の分岐 | 金額が10万円以上か未満か。最も基本で、2択ならまずこれ |
| ルーティング | 3方向以上への振り分け | 問い合わせを「請求」「技術」「解約」「その他」の4種類のテンプレートに振り分ける |
| フィルタリング | 通過か遮断かの選別 | 条件を満たすデータだけを後続に通し、それ以外を除外する |
ルーティングは If/Else を入れ子にしても表現できますが、方向が増えるほど複雑になるので、多方向を一箇所でまとめて管理できるルーティングの方が見通しがよくなります。フィルタリングは、処理すべきでないデータを早い段階で除外して、後続の負荷を抑える役割です。
まとめると、2択なら If/Else、3方向以上ならルーティング、通過・遮断ならフィルタリング。試験では「4種類のテンプレートへの振り分け／金額基準での2択／条件を満たすデータのみ通過」の3つを振り分ける問題が出ます。
エラーハンドリングとフォールバック：止まらない設計
外部の API が応答しない、想定外の値が入ってくる、AI の出力が期待と違う形式で返ってくる。ワークフローを本番で動かすと、必ず起きます。エラーハンドリングはこれへの備えで、仕組みとしては If/Else の応用です。「正常に処理できたか」の二択で分岐し、異常ならフォールバック（代替手段）を実行します。
フォールバックの基本は、ワークフロー全体を止めず、業務が完全には止まらない状態を維持することです。たとえば CRM への登録 API が失敗したら、担当者に通知して、手で入力できるフォームを提供する。これなら案件は失われず、担当者が1件だけ手作業すれば済みます。
試験では「API コール失敗時の処理として最も効果的なもの」として、担当者への通知と手動入力フォームの提供、というフォールバックが正解になります。「失敗したら全体を停止する」「失敗を無視して次に進む」は誤りです。
エラーハンドリングは Human-in-the-Loop の設計と直結しています。人に戻すパスを明示的に設計することは、ガバナンスの観点からも欠かせません。完全自動化を目指しながらも、異常時に人が介入できる経路を残しておくことが、安全な運用の条件です。
設計判断：どの変数で、どの粒度で分けるか
分岐で最も重要な判断は 「どの変数で、どの粒度で分岐させるか」 です。
- 細かく分岐させすぎると、ルールが増えてメンテナンスが大変になり、誰も全体を把握できなくなる。
- 一切分岐しないと、冒頭の例のように不適切な出力が届く。
品質と保守性のバランスが取れるのは、成否に最も影響する変数に絞って設計することです。問い合わせ対応なら「顧客区分（法人・個人）」と「内容カテゴリ」の2つで分ければ十分で、「送信時刻」や「メールの長さ」まで分岐に使う必要はありません。
試験で問われる観点
- 3つの処理（4種類のテンプレートへの振り分け／金額基準での2択／条件を満たすデータのみ通過）を If/Else・ルーティング・フィルタリングに振り分ける。
- API コール失敗時の処理として最も効果的なもの（担当者への通知と手動入力フォームの提供というフォールバック）。
- 条件分岐の設計思想（成否に最も影響する変数に絞り、過度に細かい分岐は避ける）。
- 変数の3つの出どころ（トリガー、外部システム、前のアクションの出力）。
- エラーハンドリングは Human-in-the-Loop と直結し、人に戻す経路を明示的に設計する。