スタートブロックは、SteelEngineで構築されたワークフローのデフォルトトリガーです。構造化された入力を収集し、エディターテスト、APIデプロイメント、チャット体験のためにグラフの残りの部分に分岐します。
スタートブロックは、ワークフローを作成するときに開始スロットに配置されます。エディター実行、APIへのデプロイリクエスト、チャットセッションに同じエントリーポイントを提供したい場合は、そのままにしておきます。イベント駆動の実行のみが必要な場合は、WebhookまたはScheduleトリガーと交換してください。
スタートによって公開されるフィールド
スタートブロックは、実行環境に応じて異なるデータを出力します：
- 入力フォーマットフィールド — 追加した各フィールドは
<start.fieldName>として利用可能になります。例えば、customerIdフィールドは、下流のブロックとテンプレートで<start.customerId>として表示されます。 - チャット専用フィールド — ワークフローがチャットサイドパネルまたはデプロイされたチャット体験から実行される場合、SteelEngineは
<start.input>（最新のユーザーメッセージ）、<start.conversationId>（アクティブなセッションID）、および<start.files>（チャットの添付ファイル）も提供します。
入力フォーマットフィールドは、後で参照する予定の名前に限定してください—これらの値は、エディター、API、およびチャット実行間で共有される唯一の構造化フィールドです。
入力フォーマットの設定
入力フォーマットのサブブロックを使用して、実行モード全体に適用されるスキーマを定義します：
- 収集したい各値のフィールドを追加します。
- タイプを選択します（
string、number、boolean、object、array、またはfiles）。ファイルフィールドは、チャットとAPIの呼び出し元からのアップロードを受け付けます。 - 手動実行モーダルにテストデータを自動的に入力させたい場合は、デフォルト値を提供します。これらのデフォルト値はデプロイされた実行では無視されます。
- フィールドを並べ替えて、エディターフォームでの表示方法を制御します。
接続するブロックに応じて、<start.customerId>のような式を使用して、下流の構造化された値を参照できます。
エントリーポイントごとの動作
エディタで実行をクリックすると、スタートブロックは入力フォーマットをフォームとしてレンダリングします。デフォルト値により、データを再入力せずに簡単に再テストできます。フォームを送信するとワークフローが即座にトリガーされ、値は<start.fieldName>（例えば<start.sampleField>）で利用可能になります。
フォーム内のファイルフィールドは対応する<start.fieldName>に直接アップロードされます。これらの値を使用して、下流のツールやストレージステップにデータを供給します。
下流でのStart（開始）データの参照
<start.fieldName>を構造化されたペイロードを期待するエージェント、ツール、または関数に直接接続します。- プロンプトフィールドで
<start.sampleField>や<start.files[0].url>（チャットのみ）などのテンプレート構文を使用します。 - 出力のグループ化、会話履歴の更新、またはチャットAPIへのコールバックが必要な場合は、
<start.conversationId>を手元に置いておきます。
ベストプラクティス
-
APIとチャットの両方の呼び出し元をサポートしたい場合は、Startブロックを単一のエントリーポイントとして扱います。
-
下流のノードで生のJSONを解析するよりも、名前付き入力フォーマットフィールドを優先します。型の強制変換は自動的に行われます。
-
ワークフローが成功するために特定のフィールドが必要な場合は、Startの直後に検証またはルーティングを追加します。
-
<start.fieldName>を構造化されたペイロードを期待するエージェント、ツール、または関数に直接接続します。 -
プロンプトフィールドで
<start.sampleField>や<start.files[0].url>（チャットのみ）などのテンプレート構文を使用します。 -
出力のグループ化、会話履歴の更新、またはチャットAPIへのコールバックが必要な場合は、
<start.conversationId>を手元に置いておきます。
ベストプラクティス
- APIとチャットの両方の呼び出し元をサポートしたい場合は、スタートブロックを単一のエントリーポイントとして扱います。
- 下流のノードで生のJSONを解析するよりも、名前付き入力フォーマットフィールドを優先します。型の強制変換は自動的に行われます。
- ワークフローの成功に特定のフィールドが必要な場合は、スタートの直後に検証またはルーティングを追加します。
ベストプラクティス
- APIと会話の両方の呼び出し元をサポートする場合は、Startブロックを単一のエントリーポイントとして扱います。
- 下流のノードで生のJSONを解析するよりも、名前付き入力フォーマットフィールドを優先します。型変換は自動的に行われます。
- ワークフローを成功させるために特定のフィールドが必要な場合は、Start直後に検証またはルーティングを追加します。