Difyで業務アプリを作る前に知っておきたい制限と対策

お疲れ様です。tkmiです。

最近はやりのノーコード・ローコードでAIアプリを作れる Dify について、前回はチュートリアルの補足を書きました。
ノーコード・ローコードでAIアプリを作れるDifyはとても魅力的なツールです。 ただし実際に使ってみると「思ったよりうまく動かない」と感じることもあります。

この記事では、実際にDify Cloud版でAIアプリを作成する中で遭遇した

・よくある制限
・実際に困ったポイント
・それに対して行った対策

をまとめました。
エンジニアだけでなく、ノーコードでAIアプリを作ろうとしている方の参考になれば幸いです。

① 長い処理は途中で止まる（ステップ数制限）

Difyのワークフローにはステップ数の上限があります。

•  ステップ数の上限：500step

さらに注意点として
・開始ノード
・終了ノード
・イテレーション内のノード
もすべてカウントされます。

例

データ一覧をループ処理するワークフローを作ったところ、途中で処理が停止する問題が発生しました。
原因を調べると、イテレーションの回数が多くステップ数が500に到達していたことが原因でした。

処理内容

HTTPリクエストで外部APIを利用し、処理データの一覧を取得しています。
次のコードノードで、整形を行い、イテレーションノードに要素数50の配列を渡しています。
※検証のため意図的にstep数を稼いでいます。

 1ループで10ノード使用 × 50件処理（500steps） + それ以外のノード（10steps）
= 510steps

対策

・一度に処理する件数を減らす（例：10〜20件）
上の例の場合は、50→40にするだけで、100steps減るので、410stepsとなり最後まで処理できるようになります。

・ワークフローを分割する
処理内容が複雑になる場合は、データを一旦外部に保存し、次の処理を別のワークフローで行う方が良い時もあります。

② 長文を渡すと失敗する（文字数制限）

コードノードにも制限があります。

•  文字列の上限：約400,000文字 

長文データ（ログ、議事録など）をそのまま扱うとエラーになります。

例

議事録データをまとめて処理しようとしたところ
コードノードでエラーが発生しました。
原因は出力変数の文字数制限の超過でした。

処理内容

50万文字のテキストファイルをアップロードし、ファイルからテキストを抽出して文字数を出力しています。
コードノードの出力変数（次のノードに渡すための変数）に抽出したテキストを渡しています。

対策

コードノードで出力変数に渡す前に、文字列を40万文字以下にカットします。
また、分割が可能であれば、複数ファイルに分けたりして処理を行うと良いと思います。
以下は30万文字のテキストファイル2つからテキストを抽出して出力するだけのワークフローです。

③ 配列データの扱いに制限がある

コードノードで扱える配列にも上限があります。

• 配列の最大要素数：500件

例えば、検索結果やデータ一覧をそのまま扱うと制限に引っかかることがあります。

例

メール配信用に宛先の一覧を外部APIから取得して、配信タイトル・本文を組み合わせて、配信リストを作成しようとしたところ、コードノードでエラーが発生しました。
原因は宛先の一覧が500件を超えていたからでした。

処理内容

コードノードで501個の配列を作成して出力変数に渡しています。

対策

出力変数に設定する配列の要素数は500以下になるようにします。

 ■上級者向けの注意点

④ イテレーションは2重にできない

イテレーション（ループ処理）の中にイテレーションを配置することはできません。

例

 5人のユーザーについて、3つの商品それぞれのレビューを分析するワークフローを作成しようとしました。

処理内容

ユーザーの一覧（5人）と商品レビューの一覧（3つ）を配列として、イテレーションに渡し、ユーザー→商品の2重ループをしようとしましたが、イテレーション内でイテレーションが選択できません。
※以下ワークフローはサンプルのため、処理を簡素にしています。

対策

この場合、「ユーザー × 商品」のすべての組み合わせを先に作っておき、その配列をイテレーションに渡すことで、組み合わせ全件の分析処理を行うことができます。

⑤ HTTPリクエストはデータサイズに注意

外部API連携では、データのサイズが大きいとエラーになります。

HTTPリクエスト・レスポンスの上限は1MBと定義されています。大きなJSONや長文データは失敗しやすいです。

例

外部API（データベースなど）から、議事録データをまとめて取得しようとして、HTTPリクエストノードでエラーが発生しました。
原因はレスポンスデータ容量の超過でした。 

処理内容

検証用に1MBを超えるテキストを取得する外部API （Google Apps Script/GAS）を作成しました。

対策

① レスポンスデータを分割する

まずは、取得するデータサイズを確認し、分割できる場合は分割します。

検証用のようなGASから1MBのテキストデータを返す場合（外部に作成した自前のAPIなど）は、データを1MB未満に分割することで正常に取得できるようになります。

② ファイルとして取得する

外部APIの仕様上データを分割できない場合は、一度ファイルとして外部に保存し、
Difyからファイルとして取得する方法もあります。

例）
・テキストデータを外部サーバーにファイルとして保存する
・DifyからHTTPリクエストノードにURLを指定して取得
・その後テキスト抽出ノードを利用する
※この場合も、後続処理の文字数制限には注意が必要です

③ データ取得を2段階に分ける（推奨）

Supabaseなどの外部データベースを利用している場合は、
取得処理を2段階に分けることで、1回あたりのデータ量を削減できます。

1回のレスポンスサイズを小さくできるため、安定して処理できます

⑥ 同時実行でデータが壊れる

Difyのワークフローは、スケジュールやWebhookなどによって自動実行する方法と、手動で実行する方法があります。

これらの実行は同時に発生する可能性があり、さらに処理が完了する前に同じワークフローが再度呼び出されることもあります。

しかし、Difyにはワークフローの同時実行を制御する仕組み（排他制御）がないため、同じワークフローが並行して実行される場合があります。

 例

商品在庫を管理するワークフローを作成しています。
ユーザーが商品を購入すると、ワークフローが起動し、在庫を1減らします。

在庫が1しかない状態で、AさんとBさんがほぼ同時に商品を購入しました。
本来はどちらか一方のみ購入できるはずですが、両方の処理が在庫「1」の状態を参照して実行されたため、どちらも購入できてしまい、結果として在庫が「-1」になりました。

これは、ワークフローが同時に実行され、同じデータを同時に更新したことによって発生した問題です。

処理内容

こちらは、Dify＋外部データベースサービスを使って制御を行う想定になります。
※ワークフローはサンプルのため、簡易にしています。

対策

• ロック方式：同時実行を防ぐ（シンプルな制御）
• キュー方式：順番に処理する（安定した運用が可能）

ロック方式で制御を行う場合は、以下のようなフローを作成すると良いと思います。
起動→ロック→処理→成功/失敗→ロック解除→完了 

⑦ データは自動保存されない

Difyはワークフロー内で作成したデータなどを、WF終了後も保存しておくことはできません。
ワークフロー内で作成したデータを永続的に保存し、Dify外でも活用する場合は、別のサービス等と連携してDifyから出力する必要があります。

対策

以下サービス等でデータを保存します。

• Supabase
• Googleスプレッドシート

各サービスの連携方法はこちらの記事も参考にしてください。

まとめ

Difyは「小さな処理を組み合わせる」ことで強力になります。 制限を理解して設計することが、安定した業務アプリ開発のポイントです。