Documentation Index
Fetch the complete documentation index at: https://dify-6c0370d8-docs-hitl-2.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
⚠️ このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
設定
ノードがどのように人間の入力を要求し処理するかを定義するために、以下を設定します。- 配信方法：リクエストフォームがどのように受信者に届くか。
- フォーム内容： 受信者に表示される情報と、操作できる内容。
- ユーザーアクション：受信者が行える決定と、それに応じたワークフローの進行方法。
- タイムアウト戦略：待機時間と、受信者が応答しなかった場合の処理。
配信方法
リクエストを配信するチャネルを選択します。現在利用可能な方法は次のとおりです。-
Webapp ：WebApp のエンドユーザーにリクエストフォームを表示します。トリガーで開始されたワークフローでは利用できません。
外部クライアントは Service API 経由で WebApp フォームのライフサイクルを駆動できます。詳細は API 連携フロー を参照してください。
- メール ：特定のワークスペースメンバー、外部のメールアドレス、またはワークスペース全員にリクエストリンクをメールで送信します。リンクを持っている人は誰でも応答でき、Dify アカウントは不要です。
配信方法に関わらず、最初の応答があった時点でリクエストはクローズされます。
フォーム内容
受信者が見て操作するフォームをカスタマイズします：- Markdown によるフォーマットと構造化 見出し、リスト、太字、リンクなどの Markdown 要素を使用して、情報を明確に提示します。
- 変数による動的データの表示 ワークフロー変数を参照して、レビュー用の AI 生成テキストや上流ノードの必要なコンテキスト情報などの動的コンテンツを表示します。 WebApp 配信方法では、フォーム自体がエンドユーザーに直接表示されます。参照した変数はフォーム内にそのまま値として描画されるため、 人間の入力ノードの前に回答や出力ノードを追加する必要はありません 。
-
フォームフィールドによる入力の収集
リクエストフォームにフィールドを追加して、受信者からのさまざまなタイプの入力を取得します。各フィールドは下流で使用できる変数になります。
たとえば、ブログレビューワークフローでは、受信者のフィードバックを下流の LLM ノードに渡してコンテンツの修正に使用できます。
フィールドタイプ 説明 段落 テキスト入力。空のまま開始することも、変数（例：修正対象の LLM 出力）や静的テキスト（例やデフォルト値）で事前入力することもできます。
最大長の制限はありませんが、非常に長い入力は下流の LLM のコンテキストウィンドウを超える可能性があります。選択 選択肢のリストから 1 つを選びます。選択肢を手動で定義するか、 array[string]変数を参照してその項目を選択肢として使用します。単一ファイル / ファイルリスト 単一または複数のファイルアップロード。 セルフホスト環境では、ファイルアップロードの上限を環境変数で調整できます。UPLOAD_FILE_SIZE_LIMIT、UPLOAD_IMAGE_FILE_SIZE_LIMIT、UPLOAD_VIDEO_FILE_SIZE_LIMIT、UPLOAD_AUDIO_FILE_SIZE_LIMITは拡張子ごとの 1 ファイルのサイズ上限を設定します。WORKFLOW_FILE_UPLOAD_LIMITはファイルリストフィールドで受け付けられる最大ファイル数の上限を設定します。デフォルト値については 環境変数 を参照してください。段落のみ任意で、選択、単一ファイル、ファイルリストは必須です。すべての必須フィールドが入力されるまで、フォームのアクションボタンは無効のままになります。
__rendered_content として利用できます。ファイル系フィールドの値はプレーンテキストのプレースホルダーとして表示されます。単一ファイルは [file]、ファイルリストは [N files] です。
ユーザーアクション
受信者がクリックできる決定ボタンを定義します。各ボタンはワークフローを異なる実行パスにルーティングします。 たとえば、Post ブランチはコンテンツの公開をトリガーするノードにつながり、Regenerate ブランチはコンテンツを修正するために LLM ノードへループバックします。
各ボタンには表示タイトルとアクション ID があります。ボタンがクリックされると、その ID が __action_id、タイトル（ボタンテキスト）が __action_value として下流に公開されます。
__action_id、タイトル（ボタンテキスト）は __action_value として利用できます。
タイムアウト戦略
リクエストが期限切れになるまでの時間を設定します。デフォルトは 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 ノードのプロンプト（参考）
LLM ノードのプロンプト（参考）
- Generate Draft
- Regenerate
- Check Revision
SystemUser