Sim

条件

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

条件ブロック

条件ブロックはLLMを必要とせず決定論的な意思決定を可能にし、単純な分岐ロジックに最適です。

概要

条件ブロックでは以下のことが可能です:

分岐ロジックの作成:ブール式に基づいてワークフローをルーティング

データ駆動型の意思決定:前のブロックの出力を使用して条件を評価

複数のシナリオの処理:異なるパスを持つ複数の条件を定義

決定論的なルーティングの提供:LLMを必要とせずに決定を行う

動作の仕組み

条件ブロックは順次評価プロセスを通じて動作します:

  1. 式の評価 - 現在のワークフローデータを使用してJavaScript/TypeScriptのブール式を処理
  2. 結果の決定 - 式の評価に基づいて真または偽を返す
  3. ワークフローのルーティング - 結果に基づいて適切な宛先ブロックに実行を振り分ける
  4. コンテキストの提供 - デバッグとモニタリングのための決定に関するメタデータを生成

設定オプション

条件

評価される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: 選択されたルーティング先の詳細

  • 真偽結果: 主要な条件評価の結果

  • ルーティング情報: パス選択と条件の詳細

  • アクセス: 条件の後のブロックで利用可能

使用例

カスタマーサポートの振り分け

シナリオ:優先度に基づいてサポートチケットを振り分ける

  1. APIブロックがサポートチケットデータを取得
  2. 条件が <api.priority> が 'high' と等しいかチェック
  3. 高優先度チケット → エスカレーションツールを持つエージェントへ
  4. 通常優先度チケット → 標準サポートエージェントへ

コンテンツモデレーション

シナリオ:分析結果に基づいてコンテンツをフィルタリング

  1. エージェントがユーザー生成コンテンツを分析
  2. 条件が <agent.toxicity_score> > 0.7 かチェック
  3. 有害コンテンツ → モデレーションワークフロー
  4. クリーンコンテンツ → 公開ワークフロー

ユーザーオンボーディングフロー

シナリオ:ユーザータイプに基づいてオンボーディングをパーソナライズ

  1. ファンクションブロックがユーザー登録データを処理
  2. 条件が <user.account_type> === 'enterprise' かチェック
  3. エンタープライズユーザー → 高度なセットアップワークフロー
  4. 個人ユーザー → シンプルなオンボーディングワークフロー

ベストプラクティス

  • 条件を正しく順序付ける:より具体的な条件を一般的な条件の前に配置し、特定のロジックがフォールバックよりも優先されるようにする
  • デフォルト条件を含める:最後の条件として包括的な条件(true)を追加し、一致しないケースを処理してワークフローの実行が停止しないようにする
  • 式をシンプルに保つ:読みやすさとデバッグを容易にするために、明確で簡潔なブール式を使用する
  • 条件を文書化する:チームのコラボレーションとメンテナンスを向上させるために、各条件の目的を説明する説明を追加する
  • エッジケースをテストする:条件範囲の境界値でテストすることで、条件が境界値を正しく処理することを確認する
条件