LLMノーコードツールを開発に導入して、LLMとシステム開発で責務分離しようぜ

はじめに

どうもやまぐちです。
みなさんはLLMのノーコードツールを使っていますでしょうか？
最近はDifyをはじめ、Azure PromptFlowやAWS BedrockPromptFlowsなども出てきています。
私はDifyをよく使っていますが、このようなLLMノーコードツールはかなり便利な反面、自由度はコードを書くよりは限られてきます。
そんなLLMのノーコードツールを使っているとどう開発に使うべきかがなんとなくわかってきたのでここにまとめておこうと思います。

LLMアプリ作る時のつらみ

LLMアプリを作る時の課題として、プロンプト作りとその結果が正しいかどうかを見極められるドメインエキスパートの人がいないと難しいことが挙げられます。LLMアプリは、LLMパートとそれ以外のシステム開発パートがあるのでドメインエキスパートだけではシステムは完成しません。開発者との協業が現場は必須になってきます。

システム開発を念頭に置いた時にまずはLangChainやLlamaIndexを使うことになります。つまりLLMパートもシステム開発内に組み込まれてしまいまうのです。

そうするとLLM部分はドメインエキスパートと開発者が密すぎるほど密に連携しないとなかなかいいものが作れないのと言うのが現状だと思います。
もちろん密に連携することは悪いことではありませんが、時にはそれが開発速度や改善速度を下げてしまうこともあります。
そこでPromptLayerなどを使用することでプロンプトだけ別で切り出して触れるようにしているところも出てきていると思います。例えば以下のブログが参考になります。

しかし、実際のフローを改善するとなる単に単一のプロンプトをいじるだけでなくて、LLMの数を増やすことや、条件分岐を増やすなどをする必要がでてくきます。
そうなってくると単にプロンプトのみの管理では物足りなくなってくると思います。

LLMローコードツールを使って、LLMとシステム開発で責務を分離しよう。

そんな時にはLLMのローコードツールが有効な解決策となります。
LLMのローコードツールを活用することで、システム開発からLLMパートを自然に分離することができるのです。
まあまあ強制的な分離です。
LLMアプリではドメイン知識が大事になります。ローコードツールを導入することでLLMとシステム開発の責務を分離することでドメインエキスパートがLLMパートを触るハードルがかなり下がり、より開発速度や改善速度が速くなるのではないでしょうか？

ドメインエキスパートがLLMパートを触れるようになると、改良や精度改善などを実施しやすくなりより良いLLMパーツを作れるはず！と思っています。もちろんその時はドメイン以外の知識ももちろん必要になるので、開発者は相談者になるべきだとも思っています。

イメージは、以下の画像のように責務を分けるということです。

言うなればドメインエキスパートと開発者の責務分離に当たると思います。(完全に分離し切るわけではないので、不正確な表現ですがキャッチーですね)

システム開発での利点

それだけじゃなくてシステム開発的にもいいと私は考えています。
それは単にLLMパートとシステム開発パートで責務が完全に別れるのでメンテもしやすいですし

ざっと考える中でも以下が考えられます。
LLMパートとシステム開発パートで責務が完全に別れるので

• コード修正or LLM修正の影響を与える範囲が明確になり、影響範囲がわかりやすく予期せぬバグが少なくなるはず！
• モジュール性が向上することで、そもそも依存度が下がりやすい
• LLM部分が触りやすくなるので、継続的な改善が進めやすい
  などなど。

責務の分離でよく言われることが大体当てはまります。

使用するLLMローコードツールは？

じゃあどのローコードツールを使用すればいいでしょうか？
正直責務の分離ができたらなんでもいいと思ってます。色々ツールある中で使いやすい状況とかもあるのでチームごとに判断いただくのが一番いいと思います。
それを踏まえて以下は読んでいただくのがいいと思います。

私は今はDifyがいいと思っています。Difyが良い理由は３つあります。

• Difyデフォルトのアプリ機能を使うことができること
• 使いやすさ
• 自由度の高さ

Difyデフォルトのアプリ機能を使うことができること。

Difyではデフォルトでアプリ機能を持っています。そこまで大した機能が盛り込まれているわけではありませんが、チャットアプリや簡単なワークフロー実行だけはできるのです。

• チャット画面
  

• ワークフロー実行画面
  

速くアプリ作って検証したい初期段階(MVP作成など)なら、Difyのデフォルトのアプリ機能だけ　or デフォルトのアプリ機能+若干のUIカスタマイズなどが有効なのではないでしょうか？UIカスタマイズは以下のようにできるのでそれもいいところです。

ただこれにもデメリットがあって、LLMをメインで売りに行ってしまうことになるからです。
本当にこれが顧客の課題の解決策かは常に考えておかないと手段売りになってしまいますので注意ですね。

自由度の高さ

Difyはできないこともありますが、現状は他(PromptFlowやAWS BedrockPromptFlows)に比べると私は自由度は高いと思っています。(さらっとしか他触っていないので間違っていたらすいません。)

そうでなくともOSSで作られているのでどんどん改善も走っていて、今後の自由度が上がるという期待感的にDifyがいいのではないかと思っています。

使いやすさ

クラウドに乗ってる系のやつをつかっても問題ないしそっちのが良いと思うところもあると思うけど、コード触ってない人にクラウド触らせるのってハードル高いと思っています。その分Difyに軍配が上がると思っています。

まとめ

色々とつらつら書きましたが、ざっとまとめです。

• LLMノーコードツールを使うことで、LLMパートとシステム開発パートの責務を自然と分離できる
• 責務分離により、ドメインエキスパートがLLMパートを直接触れるようになり、開発・改善速度が向上すると思う
• システム開発の観点からも、モジュール性向上や影響範囲の明確化などのメリットもある
• 責務分離できてドメインエキスパートが気軽に触ることができればなんでもいいが、私はDifyがいいと思っている

ただここまで書いてるのにひっくり返すようですが、ドメインエキスパートがいない状況や開発者しか絶対LLM触らないよ！ってところだとこの限りではないと思っています。

最後に

最近使っていてそう感じてきているのだけなのでもしかしたら今後この意見は変わるかもしれません。
しかし責務の分離という意味ではすごくLLMローコードツールいいなと最近は思うのです。

Xやってるので気になる方はフォローお願いします。