Difyとスクリプトの両用化が便利

Difyでの製作のあれこれを書いてみたいと思います。

最近、他社のDifyロジックの開発や修正案件を受けることも、少し多くなりました。
一つのワークフローだけで、3分以上もかかるようなフローを作ることもあります。
すこし難しめな課題だと、AI(llm)が40-60秒くらい処理がかかるので、それが何個かあると、3分を超えてきます。

スクリプトとDifyの両用

最近、Pythonなり、PHPでスクリプトを書いている途中で、一定のロジックをDifyで作り、それをAPI化して、スクリプト中に使うことをよくするようになりました。

Difyの方のロジックをもしテキストでスクリプトとして書いたら3,000行くらいありそうな内容が、API一つの呼び出しで、書けるので、
スクリプト中の視認性がかなり高くなります。

Difyだけでは、作れないツールなのですが、
できるだけ大きくの部分をDifyで作るようにしてみました。
それでも、全体の半分くらいではありますが。

スクリプトだけだと、どうしても処理の流れを追うのに、頭のリソースを使ってしまいますが、Difyにすると、本当にすっきり流れが見えますね。

ブロックの配置

ただ、Difyでブロックをたくさん作り、つなげると、
ブロックの配置が重要になりますね。
ブロック間の線が、ブロックにあまり隠れてしまわないようにとか
一定のグループに見えるように配置したくなり、
配置で時間がかかることもあります。

コストとllmの選択

処理数がおおいものを作ると、llmのコストが気になります。
けっこう真面目に、トークン数を調べて、各llmのAPIの料金表を見て、
1回のフローの処理に対する料金を調べたりします。
私の場合、内容によりますが、一ヶ月に10万件くらいの処理を何個かすることもありますので、コストを軽視していると、とんでもないことになりますので。
ある程度の精度があり、コストが安いのはGemini Flash1.5だと思うので、
それでできるものは、それで使うようにしています。

ただ、jsonでの出力を固定化したい時がよくあるので、その場合は、
gpt-4o-miniにします。
こちらの方が、すこしコストが高いです。
しかし、さくっとjsonでデータが固定できるので、次の処理に問題なく繋げやすいです。

llmの回答に満足できない時だけ、少しずつ上位版にしていきます。
話題のDeepSeekなども使えるようにしていますが、先日APIの通信エラーが長くあったので、あまり使っていません。

「コード」ブロックの多用

以前は、ノーコードツールで、「コード」ブロックの中にコードを書くのは、とてもナンセンスな気がしていました。
しかし、最近は、けっこう複雑なコードを「コード」ブロックの中に書くことも多いです。
既存のブロック、例えばURLのスクレイピングも、コードで書いてしまうことが多くなりました。
処理の速さだと、やはりコード処理の方が、他のAPIにつなげるよりも速いです。あと、API接続エラーとかも影響しないですから。

オリジナル外部APIの利用

「コード」で使えないモジュール、ライブラリなどがある場合は、
自分の外部サーバーにその機能の仕組みを作り、API化して、
Difyから呼び出して使うこともあります。
自分専用ですので、リソースの心配もほぼないので。

Difyのワークフローを別のワークフロー内に入れることは

自作のワークフローを別のワークフロー内で、一つのブロックとして使えるDifyの機能は、とても魅力的だと思っていたのですが、これをすると時間がかかります。あまりおすすめしません。
やはり、途中で別のワークフローを呼び出すのは、内部的に大変なのかもしれません。APIとかわらないほどの時間がかかります。もっとかかっているかもしれません。
ひとつのワークフローを、別のワークフローで流用する場合は、仕方ないので、ブラウザのタブを２つあげて、手作業でコピー(再作成)していっています。

最近のDify製作でのあれこれでした。
皆様の参考になれば、幸いです。