1つのノードで、あらゆる分岐へ——Switchノード登場

CloudFlowで、フィールドの値に応じて各結果を適切なアクションへ振り分け。多方向の分岐のためにBranchノードを積み重ねる必要はもうありません。

実際のクラウド運用が、単純なイエス・ノーの一問で片付くことはほとんどありません。タグには5種類の値が入ることもあれば、リクエストで指定されるプロバイダーもさまざまです。検出結果には十数種類のカテゴリーのいずれかが付くこともあります。

これまで、CloudFlowで「値ごとに異なる処理を行う」ロジックを組むには、Branchノードを連鎖させる——if/elseを次々に重ねる——しかありませんでした。動作はするものの、フローは深く冗長になり、新しい値を追加するたびにチェーンをつなぎ直す必要があり、分岐が増えるほどロジック全体を一目で把握するのが難しくなっていました。

新機能

Switchノードは、その連鎖を1つの判断ポイントに集約します。対象のフィールドを指定し、必要な値ごとにケースを定義するだけで、CloudFlowが各結果を一致するパスへ振り分けます。

名前付きケースによる厳密マッチング - 文字列・数値・ブール値を厳密な型判定で照合。"1"と1が混同されることはありません。

大文字・小文字の区別を無視 — チェックボックス1つで、Production、PRODUCTION、productionが同じパスに集まります。上流でタグ値を正規化する必要はもうありません。

デフォルトパス — どのケースにも一致しない結果をまとめて受け止められます。設定しなければ、一致しない結果はそこで終了するだけ。失敗することも、意図せず取りこぼすこともありません。

結果ごとのルーティング — 私たちが特に気に入っているポイントです。Switchノードはバッチ内の各アイテムを個別に評価するため、1回の実行で複数のパスを同時に動かすことができ、すべてのアイテムが本来あるべき場所へ正確に届きます。

活用例:営業時間外のインスタンス整理

平日19:00に実行され、すべてのEC2インスタンスを一覧化し、そのバッチを1つのSwitchノードに渡して各インスタンスのEnvironmentタグを読み取るフローを想像してみてください。

• production → スキップされ、手つかずのまま。ガードレールが最初から組み込まれています。
• dev → 夜間は停止。アイドル状態の支出を自動的にカットできます。
• Everything else → デフォルトパスがリソースの所有者を特定してタグ付けを依頼。タグなしのインベントリは蓄積するどころか、時間とともに減っていきます。

スケジュールトリガー1つ、一覧取得1回、ルーティング判断1つ。同じ処理をBranchノードで組めば条件の連鎖が延々と続きますが、Switchならホワイトボードに書き出したポリシーそのままの読みやすさです。しかもルーティングは結果ごとに行われるため、1回の夜間実行でdevインスタンスの停止、本番環境の保護、タグなしインスタンスの所有者への通知まで、すべてを一度に処理できます。

使い始めるには

Switchノードは、すべてのCloudFlowユーザーが今すぐ利用できます。フローエディタで結果を振り分けたい場所の**[+]**を選択し、Switchを選んで、評価するフィールドとケースを追加するだけです。マッチングルールやその他の例については、Switchノードのドキュメントをご覧ください。

クラウド上のフィールドが3つ以上の値を取りうるなら——そのためのノードがここにあります。