Human Inputで未回答のまま期限を過ぎたら、承認側へ進めず、期限切れ専用の経路で止めます。 フォームへ届く前の失敗、回答がない状態、差し戻しは、それぞれ確認先が異なります。通知や公開を接続する前に、どの状態が返るかを別々に試します。

対象は、Difyで社内ワークフローを作り始め、人が確認してから下流へ進めたい人です。以下は架空の社内FAQを題材にした設計例です。コードは分岐を理解するための独立したモデルで、Dify本体やメールサービスを呼び出しません。

フォームの到達と、人が選んだ操作を分けて確認する

まずは公開しない検証用の経路を用意する

例では「FAQ-017、原稿版3、会議室の予約変更」という架空の依頼を用意します。原稿本文は「予約変更は総務へ確認してください」という短い文です。公開先の接続を置かずに、request_id、revision、statusを返す構成にします。

開始ノードで依頼番号と版を持たせ、Human Inputで原稿と確認してほしい点を表示します。確認者が見る情報は、表示に必要な最小限にします。承認と差し戻しの下流では、テスト用の出力へ状態を渡します。タイムアウトは別の出口へつなぎ、期限切れとして返します。

Webアプリとメールでは、フォームの届け先が違う

DifyのHuman Input公式資料（2026年11月9日確認）では、Webアプリ配信とメール配信が案内されています。Webアプリ配信は、利用者がWebアプリでフォームを見る方式です。トリガーで開始したワークフローでは、この方式を使えないと説明されています。

メール配信では、届いたリンクを使って回答します。公式資料では、リンクを受け取った人はDifyアカウントがなくても回答でき、どちらの配信方法でも最初の1件で受付が閉じます。社内の確認に使う場合は、確認者の範囲を事前に決め、リンクや原稿の転送を前提にしない設計にします。回答者を限定する必要がある場合は、リンクを持つだけで回答できる経路が要件に合うかを確かめます。

確認したいことWebアプリ配信メール配信
誰がフォームを見るかアプリ利用者依頼リンクの受け手
トリガーで始めた実行公式資料では利用不可受け手と配信条件を確認
何人の回答を受け付けるか最初の1件最初の1件
最初の検証で見るもの表示された原稿の版と操作届いたリンクと対象依頼の対応

ボタンの表示名と、分岐を識別するIDを区別する

確認者向けの表示は「承認する」「修正に戻す」とします。実行結果を調べるためのIDはapproveとreviseです。公式資料では、選択したボタンのIDを__action_id、表示名を__action_valueとして後続で参照できます。

表示名を分かりやすく変更することはできますが、後続ノードが表示名の文字列に依存していると、説明文の変更だけで条件がずれます。分岐はノードの接続とIDで確認し、表示名は利用者が判断しやすい文言にします。

差し戻し理由を入力する欄には、本文のどこを直すかのヒントを添えます。Paragraph欄は公式資料上で任意入力です。理由の記入が業務上必要なら、差し戻し経路の後続でも空欄を確認し、理由のない依頼を修正済みとして進めないようにします。反対にフォーム全体へ必須の選択欄を増やすと、どのアクションも押せない原因になるため、実際の業務に必要かを見直します。

期限切れの出口を用意し、再実行を別の依頼として扱う

未回答の期限と、エラーで止まる時間を混同しない

Human Inputの期限は、人が回答するためにフォームを開いておく期間です。公式資料には既定3日とあり、期限までに回答がない場合は接続されたタイムアウト分岐へ進みます。分岐を接続していなければ実行は終了します。期限は設定画面と対象環境の仕様を確認し、記事の例の期間をそのまま適用しないでください。

一方、フォームが表示される前に実行が失敗した場合は、未回答と同じ処理とは限りません。実行履歴を見て、開始ノードの入力、Human Inputへの到達、フォームを開けるか、回答を受け付けたかの順に調べます。ブラウザーの画面を閉じたことだけで、ワークフローが期限切れになったとも判断できません。

何が起きたか 期待する状態 次に確認するもの
版3を確認して承認 approved 承認経路と原稿版
版3に修正を依頼 needs_revision 理由と対象段落
期限まで未回答、分岐あり expired 期限切れ経路と依頼番号
期限まで未回答、分岐なし 実行終了 タイムアウトの接続
途中でフォームへ到達しない 未判定 実行履歴と上流ノード

架空の5パターンで接続先を検算する

下のPythonは、各経路で公開候補にしてよいかを検算するものです。expiredはDifyの組み込み出力変数という意味ではなく、この例でタイムアウト側へ付ける状態名です。タイムアウト時に回答のIDが返ることを前提にせず、専用の経路から固定値を渡します。

def decide(event, revision, latest_revision, feedback=""):
    if event == "timeout":
        return "expired", False
    if revision != latest_revision:
        return "stale_revision", False
    if event == "approve":
        return "approved", True
    if event == "revise":
        return ("needs_revision" if feedback.strip() else "missing_reason"), False
    return "unresolved", False

assert decide("approve", 3, 3) == ("approved", True)
assert decide("revise", 3, 3, "変更窓口を確認") == ("needs_revision", False)
assert decide("revise", 3, 3, " ") == ("missing_reason", False)
assert decide("timeout", 3, 3) == ("expired", False)
assert decide("approve", 3, 4) == ("stale_revision", False)

Trueは、例で次の確認へ進めるという意味です。これだけで外部公開したり、書き込み先の権限を変更したりする設計ではありません。本番へつなぐなら、最後の書き込み前にも承認された版を照合し、既に処理済みの依頼では二重に書き込まないようにします。

未回答を再依頼するときは、版と依頼番号を取り違えない

期限が切れた後に同じ原稿を依頼し直す場合は、新しい依頼番号と対象の版を残します。版4をレビューしている途中で版3への判断を受け取った場合、版4を承認済みとして処理してはいけません。原稿版と確認者が見た版を対応させ、古い回答は確認用に分けます。

フォームが最初の回答で閉じても、別の実行から同じ原稿を依頼すれば、下流処理が二重になる可能性があります。実行単位のIDとは別に、公開対象と版を識別できるキーで照合する設計を考えます。自動再依頼を作る場合は回数に上限を設け、担当者が止める条件を決めます。

架空の時刻 出来事 記録したい結果
09:00 FAQ-017の版3を依頼 依頼A、版3、待機中
10:00 依頼Aが未回答のまま期限切れ 依頼A、版3、期限切れ
10:15 文面を直して版4を依頼 依頼B、版4、待機中
10:20 依頼Bを承認 依頼B、版4、次の確認へ
10:25 同じ版4の処理が再実行される 既に処理済みなら記録を追加しない

ここでの1時間は設計を理解するための架空の期限です。実際の設定可能範囲は利用環境で確認してください。2件を見比べるときは時刻の新しさだけで判断せず、対象IDと版と依頼IDの組を確認します。依頼Aのログに版3が残っていても、依頼Bの判断を取り消す理由にはなりません。

画面で確認する順番を1枚に残す

検収用の記録には、実行識別子、依頼番号、原稿版、開始時刻、フォーム到達時刻、期限、回答の種類、終了状態を残します。メールや外部サービスを試す前に、架空の値で承認・差し戻し・未回答・古い版への回答の結果を別々に記録します。通知を受け取ったことと、下流の処理が実行されたことは同じ欄にまとめません。

担当者が複数人の承認を必須にする場合は、ひとつのフォームの配信先を増やすだけでは要件を満たしません。誰の承認が必要かを分けて記録し、何人分がそろったときに進めるかを別に設計します。Difyでの分岐を学ぶ段階では、最初にこの小さな検収表が埋まるかを確かめると、画面上の設定と業務ルールを整理できます。

Difyのワークフローを講座で学ぶとき

条件分岐や外部サービスとの接続から練習したい人は、バイテックAIスクールのDifyマスターコースを比較候補にできます。公式案内では全21チャプター・82レッスンで、申請フローやレポート自動化などを題材にしています（2026年11月9日確認）。Human Inputの期限切れや再実行まで教材で扱うかは、必要に応じて説明会で確認してください。

広告：バイテックAIスクールの講座内容を確認

よくある質問

Q. 未回答のタイムアウトを、却下として処理してよいですか？
A.

この記事では期限切れと差し戻しを別に記録します。業務で未回答を却下と同じ終了扱いにする場合でも、原因が分かる状態名を残すと確認できます。

Q. タイムアウト経路を接続しなかった場合はどうなりますか？
A.

Cloud向け公式資料では、未回答のまま期限に達し、分岐が未接続なら実行が終了すると説明されています。終了後に必要な通知や記録があれば、明示的に接続して確認してください。

Q. 複数人にメールを送ると全員分の承認が取れますか？
A.

一つの依頼は最初の回答で閉じます。複数人の判断を必須にするには、各人の回答を別に集める仕組みが必要です。

Q. フォームを開くだけで承認になりますか？
A.

表示と回答は別です。検収では、確認した版と実際に選んだアクションを確認します。

Q. ボタンが押せないときは何を見ればよいですか？
A.

まず必須欄が埋まっているか、対象フォームが期限内で未回答かを確認します。画面の表示と実行履歴を照らし合わせます。

Q. タイムアウトをPythonで発生させた例ですか？
A.

掲載コードは状態を検算する独立したモデルです。実際のフォーム配信や時間経過は、使っているDify環境で検収してください。