条件
条件ブロックを使用すると、ブール式に基づいてワークフローの実行パスを分岐させることができ、異なる実行パスを持つ動的で応答性の高いワークフローを作成できます。条件を評価してワークフローを適切に振り分け、LLMを必要とせずにデータやロジックに基づいて実行フローを制御できます。

条件ブロックはLLMを必要とせず決定論的な意思決定を可能にし、単純な分岐ロジックに最適です。
概要
条件ブロックでは以下のことが可能です:
分岐ロジックの作成:ブール式に基づいてワークフローをルーティング
データ駆動型の意思決定:前のブロックの出力を使用して条件を評価
複数のシナリオの処理:異なるパスを持つ複数の条件を定義
決定論的なルーティングの提供:LLMを必要とせずに決定を行う
動作の仕組み
条件ブロックは順次評価プロセスを通じて動作します:
- 式の評価 - 現在のワークフローデータを使用してJavaScript/TypeScriptのブール式を処理
- 結果の決定 - 式の評価に基づいて真または偽を返す
- ワークフローのルーティング - 結果に基づいて適切な宛先ブロックに実行を振り分ける
- コンテキストの提供 - デバッグとモニタリングのための決定に関するメタデータを生成
設定オプション
条件
評価される1つ以上の条件を定義します。各条件には以下が含まれます:
- 式:真または偽に評価されるJavaScript/TypeScript式
- パス:条件が真の場合にルーティングする宛先ブロック
- 説明:条件が何をチェックするかの任意の説明
複数の条件を作成でき、それらは順番に評価されます。最初にマッチした条件が実行パスを決定します。
条件式のフォーマット
条件はJavaScript構文を使用し、前のブロックからの入力値を参照できます。
// Check if a score is above a threshold
<agent.score> > 75
// Check if a text contains specific keywords
<agent.text>.includes('urgent') || <agent.text>.includes('emergency')
// Check multiple conditions
<agent.age> >= 18 && <agent.country> === 'US'
結果へのアクセス
条件が評価された後、以下の出力にアクセスできます:
<condition.result>
: 条件評価の真偽結果<condition.matched_condition>
: マッチした条件のID<condition.content>
: 評価結果の説明<condition.path>
: 選択されたルーティング先の詳細
高度な機能
複雑な式
条件内でJavaScriptの演算子や関数を使用できます:
// String operations
<user.email>.endsWith('@company.com')
// Array operations
<api.tags>.includes('urgent')
// Mathematical operations
<agent.confidence> * 100 > 85
// Date comparisons
new Date(<api.created_at>) > new Date('2024-01-01')
複数条件の評価
条件は一致するものが見つかるまで順番に評価されます:
// Condition 1: Check for high priority
<ticket.priority> === 'high'
// Condition 2: Check for urgent keywords
<ticket.subject>.toLowerCase().includes('urgent')
// Condition 3: Default fallback
true
エラー処理
条件は自動的に以下を処理します:
- 未定義またはnull値の安全な評価
- 型の不一致に対する適切なフォールバック
- 無効な式のエラーログ記録
- 欠落した変数のデフォルト値
入力と出力
条件: 評価する真偽式の配列
式: ブロック出力を使用するJavaScript/TypeScript条件
ルーティングパス: 各条件結果の宛先ブロック
condition.result: 条件評価の真偽結果
condition.matched_condition: マッチした条件のID
condition.content: 評価結果の説明
condition.path: 選択されたルーティング先の詳細
真偽結果: 主要な条件評価の結果
ルーティング情報: パス選択と条件の詳細
アクセス: 条件の後のブロックで利用可能
使用例
カスタマーサポートの振り分け
シナリオ:優先度に基づいてサポートチケットを振り分ける
- APIブロックがサポートチケットデータを取得
- 条件が
<api.priority>
が 'high' と等しいかチェック - 高優先度チケット → エスカレーションツールを持つエージェントへ
- 通常優先度チケット → 標準サポートエージェントへ
コンテンツモデレーション
シナリオ:分析結果に基づいてコンテンツをフィルタリング
- エージェントがユーザー生成コンテンツを分析
- 条件が
<agent.toxicity_score>
> 0.7 かチェック - 有害コンテンツ → モデレーションワークフロー
- クリーンコンテンツ → 公開ワークフロー
ユーザーオンボーディングフロー
シナリオ:ユーザータイプに基づいてオンボーディングをパーソナライズ
- ファンクションブロックがユーザー登録データを処理
- 条件が
<user.account_type>
=== 'enterprise' かチェック - エンタープライズユーザー → 高度なセットアップワークフロー
- 個人ユーザー → シンプルなオンボーディングワークフロー
ベストプラクティス
- 条件を正しく順序付ける:より具体的な条件を一般的な条件の前に配置し、特定のロジックがフォールバックよりも優先されるようにする
- デフォルト条件を含める:最後の条件として包括的な条件(
true
)を追加し、一致しないケースを処理してワークフローの実行が停止しないようにする - 式をシンプルに保つ:読みやすさとデバッグを容易にするために、明確で簡潔なブール式を使用する
- 条件を文書化する:チームのコラボレーションとメンテナンスを向上させるために、各条件の目的を説明する説明を追加する
- エッジケースをテストする:条件範囲の境界値でテストすることで、条件が境界値を正しく処理することを確認する