このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
人間の入力ノードは、ワークフローを重要なポイントで一時停止し、カスタマイズ可能なリクエストフォームを配信します。受信者はフォームを使って情報を確認し、入力を提供し、ワークフローの進行方法を決定する事前定義された選択肢から選ぶことができます。
重要な場面に人間の判断を直接組み込むことで、 自動化による効率と人間による監視のバランス をとることができます。
ワークフロー設計の完全な例については、例：コンテンツレビューワークフロー を参照してください。
設定#
ノードがどのように人間の入力を要求し処理するかを定義するために、以下を設定します。
-
配信方法：リクエストフォームがどのように受信者に届くか。
-
フォーム内容： 受信者に表示される情報と、操作できる内容。
-
ユーザーアクション：受信者が行える決定と、それに応じたワークフローの進行方法。
-
タイムアウト戦略：待機時間と、受信者が応答しなかった場合の処理。
配信方法#
リクエストを配信するチャネルを選択します。現在利用可能な方法は次のとおりです。
-
Web app ：Web アプリのエンドユーザーにリクエストフォームを表示します。トリガーで開始されたワークフローでは利用できません。
Info外部クライアントは Service API 経由で Web アプリフォームのライフサイクルを駆動できます。詳細は API 連携フロー を参照してください。
-
メール ：特定のワークスペースメンバー、外部のメールアドレス、またはワークスペース全員にリクエストリンクをメールで送信します。リンクを持っている人は誰でも応答でき、Dify アカウントは不要です。
配信方法に関わらず、最初の応答があった時点でリクエストはクローズされます。
フォーム内容#
受信者が見て操作するフォームをカスタマイズします：
-
Markdown によるフォーマットと構造化
見出し、リスト、太字、リンクなどの Markdown 要素を使用して、情報を明確に提示します。
-
変数による動的データの表示
ワークフロー変数を参照して、レビュー用の AI 生成テキストや、誰かが上流の人間の入力ノードでアップロードした承認用のファイルなどの動的コンテンツを表示します。
Web アプリ配信方法では、フォーム自体がエンドユーザーに直接表示されます。参照した変数はフォーム内にそのまま値として描画されるため、 人間の入力ノードの前に回答や出力ノードを追加する必要はありません。
Tip推論モデルは最終回答とともに思考プロセスも出力します。
text出力変数を参照するとデフォルトで両方が表示されます。回答のみを表示するには、対応する LLM ノードで 推論タグの分離を有効にする をオンにします。
-
フォームフィールドによる入力の収集
リクエストフォームにフィールドを追加して、受信者からのさまざまなタイプの入力を取得します。各フィールドは下流で使用できる変数になります。
たとえば、ブログレビューワークフローでは、受信者のフィードバックを下流の LLM ノードに渡してコンテンツの修正に使用できます。
フィールドタイプ 説明 段落 テキスト入力。空のまま開始することも、変数（例：修正対象の LLM 出力）や静的テキスト（例やデフォルト値）で事前入力することもできます。
最大長の制限はありませんが、非常に長い入力は下流の LLM のコンテキストウィンドウを超える可能性があります。選択 選択肢のリストから 1 つを選びます。選択肢を手動で定義するか、 array[string]変数を参照してその項目を選択肢として使用します。単一ファイル / ファイルリスト 単一または複数のファイルアップロード。 Infoファイルアップロードの上限を環境変数で調整できます。UPLOAD_FILE_SIZE_LIMIT、UPLOAD_IMAGE_FILE_SIZE_LIMIT、UPLOAD_VIDEO_FILE_SIZE_LIMIT、UPLOAD_AUDIO_FILE_SIZE_LIMITは拡張子ごとの 1 ファイルのサイズ上限を設定します。WORKFLOW_FILE_UPLOAD_LIMITはファイルリストフィールドで受け付けられる最大ファイル数の上限を設定します。デフォルト値については 環境変数 を参照してください。Note段落のみ任意で、選択、単一ファイル、ファイルリストは必須です。すべての必須フィールドが入力されるまで、フォームのアクションボタンは無効のままになります。
受信者が応答すると、すべての値が入力されたフォーム内容は下流変数 __rendered_content として利用できます。ファイル系フィールドの値はプレーンテキストのプレースホルダーとして表示されます。単一ファイルは [file]、ファイルリストは [N files] です。
ユーザーアクション#
受信者がクリックできる決定ボタンを定義します。各ボタンはワークフローを異なる実行パスにルーティングします。
たとえば、Post ブランチはコンテンツの公開をトリガーするノードにつながり、Regenerate ブランチはコンテンツを修正するために LLM ノードへループバックします。
各ボタンには表示タイトルとアクション ID があります。ボタンがクリックされると、その ID が __action_id、タイトル（ボタンテキスト）が __action_value として下流に公開されます。
プリセットのボタンスタイルを使用して、アクションを視覚的に区別します。
たとえば、Approve のような重要なアクションには目立つスタイルを、二次的なオプションには控えめなスタイルを使用します。
タイムアウト戦略#
リクエストが期限切れになるまでの時間を設定します。デフォルトは 3 日です。
タイムアウトまでに受信者が応答しなかった場合、ワークフローはノードのタイムアウトブランチに進みます。このブランチをフォールバックパス（通知の送信やリトライループなど）に接続してください。
タイムアウトブランチが接続されていない場合、ワークフローは終了します。
例：コンテンツレビューワークフロー#
このワークフローでは、ワークフローの起動者が入力した topic と language からブログ記事の草稿を作成します。その草稿をメールでレビュアーに送信し、レビュアーの選択に応じて最終出力を確定します。
このノードでレビュアーが行えるようにすべき次の 3 つを軸に設計されています。
-
AI が生成した草稿を確認する：フォームで上流の LLM ノードの
text変数を参照し、レンダリングされたフォームに草稿の本文をそのまま表示させます。 -
必要に応じて草稿を直接編集する：フォームに
editsという段落フィールドを追加し、同じtext変数で事前入力します。これによりレビュアーは草稿を出発点として、その場で編集できます。ブログ記事は通常長いため、フォームの Markdown 表示（第 1 点）の方が、単独の段落フィールドよりも読みやすくなります。コンテンツが短い場合は、事前入力した段落フィールド 1 つで閲覧と編集の両方を兼ねられます。
-
AI による修正のためにフィードバックを提供する：
- レビュアーのフィードバックを集めるため、フォームに
feedbackという段落フィールドを追加します。 - 下流の LLM ノードを 2 つ順に接続します。
- Regenerate ノード：元の草稿
textとレビュアーのfeedbackを受け取って修正された草稿を生成します。 - Check Revision ノード：
feedbackと修正された草稿を受け取り、修正がフィードバックに沿っているかを確認します。検証された結果が最終出力として下流に流れます。
- Regenerate ノード：元の草稿
- レビュアーのフィードバックを集めるため、フォームに
レビュアーは受け取ったリクエストフォームで、判断に基づいて該当する段落フィールドを入力（または空のまま）し、対応するアクションボタンをクリックします。各アクションは異なる出力に接続されます。
- Approve：上流の LLM からの元の草稿
- Apply Edit：
editsフィールドでレビュアーが編集した内容 - Regenerate：下流の LLM パイプラインからの修正草稿
LLM ノードのプロンプト（参考）
System
User
System
User
System
User