はじめに

Difyを触っていると、「これ、UIだけだとあと一歩届かないな」という場面がけっこうあります。
でも、その“あと一歩”はノードの組み合わせやDSLの扱い方を知っているだけで、かなり埋められます。

この記事では、実務で地味に効くDifyの小ネタをいくつかまとめます。
メインのネタは次の2つです。

Current Time とコード実行ノードを組み合わせた日付計算
フロー間でノードを直接コピーできないときのDSL活用

あわせて、運用時に役立つ小ネタも追加で紹介します。

この記事は、DifyのVersion1.13.2時点での内容です。
バージョン違いによっては内容が適していないこともありますのでご留意ください。

1. Current Time × Code で営業日計算を作る

Difyには現在時刻を取得する Current Time というツールがあり、コード実行ノードではPython / JavaScriptで任意の処理を書けます。コード実行ノードは前段ノードの値を入力変数として受け取り、辞書形式で後続ノードに返せるので、「今日を基準に○営業日後を出す」といった日付ロジックをきれいに実装できます。

こんなときに便利

たとえば、次のような要件です。

問い合わせ受付日から「3営業日後」の期限を出したい
申込日の「5営業日前」を締切日にしたい
土日を避けて次回営業日を返したい

LLMは数値計算や日付計算を苦手としているため、LLMに「営業日を計算して」と自然言語だけで任せると、ケースによってはブレます。
一方で、日付取得を Current Time、計算をコード実行ノードに分けると、ロジックを固定化できるので安心です。

フローのイメージ

Start
  ↓
Current Time
  ↓
Code
  ↓
Answer

実装イメージ

今回実装するのは「今日から○営業日後の日付」を返す、土日除外のシンプル版です。
祝日までは考慮しない、まずは一番手軽な形です。
※祝日を考慮する例は記事後半参照

コード実行ノードの入力例

current_time: Current Time の出力
business_days: 進めたい営業日数（例: 3）

Pythonコード例

def main(current_time: str, business_days: int) -> dict:
    from datetime import datetime, timedelta

    # 文字列から日時へ変換
    base = datetime.strptime(current_time, "%Y-%m-%d %H:%M:%S")

    days_added = 0
    current = base

    while days_added < business_days:
        current += timedelta(days=1)
        # 月〜金なら営業日としてカウント
        if current.weekday() < 5:
            days_added += 1

    return {
        "base_date": base.strftime("%Y-%m-%d"),
        "calculated_date": current.strftime("%Y-%m-%d"),
        "weekday": current.strftime("%A")
    }

このコードなら、土日を飛ばして営業日先の日付を算出できます。

この構成のよいところ

一番のメリットは、「時刻の取得」と「計算ロジック」を分離できることです。
日付計算をLLMの気分に任せず、コード実行ノードに閉じ込められるので、テストしやすく、あとで「営業日ではなく7日後に変えたい」「前営業日にしたい」といった修正も楽です。コード実行ノードは標準ライブラリの datetime も使えるため、こうした用途と相性がいいです。

祝日込みの“本気の営業日計算”にしたい場合

実務では「土日だけ除外」では足りず、日本の祝日も避けたくなることが多いです。
祝日や会社固有の休日を営業日計算で考慮させたい場合には、除外日の一覧（祝日リスト）を事前に作成しておくことで、コード実行ノードで細かな営業日計算が実現できます。

Pythonコード例

祝日リスト例
※環境変数やインプット等で祝日リストを設定する

HOLIDAYS = ["2026-01-01", "2026-01-02", "2026-01-03", "2026-01-12", "2026-02-11", "2026-02-23", "2026-03-21", "2026-04-29", "2026-05-03", "2026-05-04", "2026-05-05", "2026-05-06", "2026-07-20", "2026-08-11", "2026-09-21", "2026-09-22", "2026-09-23", "2026-10-09", "2026-11-03", "2026-11-23", "2026-12-29", "2026-12-30", "2026-12-31"]

from datetime import datetime, timedelta  
import ast

def main(current_time: str, business_days: int, HOLIDAYS: str):

    # 文字列から日時へ変換
    HOLIDAYS = [datetime.strptime(date, "%Y-%m-%d").date() for date in ast.literal_eval(HOLIDAYS)]

    base_date = datetime.strptime(current_time, "%Y-%m-%d %H:%M:%S").date()
    current = base_date
    days_added = 0

    while days_added < business_days:
        current += timedelta(days=1)
        # 土日・祝日でなければカウントを進める
        if current.weekday() < 5 and current not in HOLIDAYS:
            days_added += 1

    return {
        "base_date": base_date.strftime("%Y-%m-%d"),
        "calculated_date": current.strftime("%Y-%m-%d"),
        "weekday": current.strftime("%A")
    }

補足：外部APIやDify Marketplaceの DateTime Tool のように日本の祝日対応・営業日モードを持つプラグインを使う方法もあります。

2. フロー間コピーは DSL 編集で“擬似的に”やる

Difyには同一キャンバス上でのコピー / ペースト / 複製ショートカットがあります。
ただし、「あるワークフローの一部ノードを、別のワークフローへそのまま持っていく」という機能は現時点ではなく、フローをまたいだ再利用はまだ少し工夫が必要、というのが実態です。

そこで使うのがDSL

DifyのアプリはDSLとしてエクスポート / インポートできます。
エクスポートしたDSLには、アプリ設定、ワークフロー構成、ノード設定、モデルパラメータ、プロンプトなどが含まれます。逆に、APIキーやナレッジそのもののデータは含まれません。

やり方の考え方

発想としてはシンプルです。

コピー元フローをDSLでエクスポート
コピー先フローもバックアップとしてDSLをエクスポート
DSLを見比べて、必要なノード定義と接続定義を移植
インポートして新しいアプリとして読み込む
変数参照や接続が崩れていないか確認する

UI上の「ノード単体コピー」ではなく、DSLレベルでワークフローの断片を移植するイメージです。

コピー実践例

フローAをフローBにコピーする

【フローA】

【フローB】

2つのフローのDSLをエクスポートする
フローA DSL内の「edges」の下の階層のコードをコピーする
※「edges」の下の階層の「data」が、ノードとノードをつなぐ「線」の情報
フローB DSL内の「edges」の下の階層に、上記でコピーしたedge情報をペーストする
※「edges」～「nodes」の間に挿入する
フローA DSL内の「nodes」の下の階層のコードをコピーする
※「nodes」の下の階層の「data」が、各ノードの情報
フローB DSL内の「nodes」の下の階層に、上記でコピーしたnode情報をペーストする
※「nodes」～「viewport」の間に挿入する
フローBのDSLをDifyにインポートする
※位置座標ごとコピーしているため、ノードが重なっている可能性が高い
「ノード整理」ボタンで、重なっているフローを自動整理する。
入力ノードが複数ある場合は、一つになるよう削除する
※本来入力ノードは1つしか配置できないので、入力ノードごとコピーした場合は1つになるよう削除が必要

この方法が向いているケース

定番の前処理ノード群を別フローでも再利用したい
毎回ゼロから組み直すのがしんどい
類似フローを量産したい
チーム内で“お決まり構成”を横展開したい

地味ですが、かなり時短になります。

注意点

この方法は便利ですが、雑にやると壊れます。
特に気をつけたいのは次の4点です。

必ず事前にバックアップを取ること
ノードIDや参照関係の整合性を崩さないこと
モデル設定や外部ツール認証は、インポート後に再確認すること
IDが重複してしまう場合、ノードやエッジ情報が正しくコピーされていない可能性がある

また、DSLエクスポートにはナレッジベースの“接続情報”は含まれても、“中身そのもの”は含まれません。
そのため、環境をまたぐ移植では「読み込んだのに動かない」ということが起きやすいです。

実務目線のひとこと

「ノードを跨いでコピペしたい」というニーズ自体は自然です。
ただ、フローが大きくなるほど、単純コピーよりも“再利用単位をどう切るか”のほうが重要になってきます。
後で紹介する「WorkflowをToolとして再利用する」方法も、長期的にはかなり有力です。

3. 再利用前提なら、Tools として“部品化”するのもアリ

DSL編集はたしかに便利ですが、頻繁に使う処理であれば、そもそも「再利用しやすい形」にしておくほうがきれいです。
Difyでは、複雑なワークフローを公開して、別のワークフローから Tool として使うことができます。

たとえばこんな部品化ができる

営業日計算フロー
テキスト前処理フロー
社内フォーマット変換フロー
定型チェックフロー

こうしておくと、別フローでは「また同じノード群を組む」のではなく、1つのToolとして呼び出せます。
完成している機能を別フローで利用したい場合には、DSL編集によるコピーではなくToolとして連携するという方法も検討してみてください。

まとめ

今回の小ネタをまとめると、こんな感じです。

日付計算は Current Time × Code の組み合わせが堅い
UIだけで足りないフロー間コピーは、DSL編集でかなり補える
再利用頻度が高い処理は、WorkflowをTool化すると運用しやすい

Difyはノーコードでのアプリ作成がとても便利ですが、少し踏み込んで DSL・Code・Tool化 あたりを活用していくことで、より柔軟なアプリ作成を楽しむことができます。