見出し画像

【Dify v1解説 後編】 エージェントがもたらすDifyの新たな価値

注意事項

この記事はbeta版の内容を含みます。以後情報が古くなる可能性があります。
また、既存のDifyと大きく内容が変わっておりますので、お試しの際は既存環境と分けて試されることを強く推奨します。

はじめに

この記事はDify v1 のアップデートを前編・後編に分けて紹介する記事となっております。
まだ前編を読んでいない方はこちらからご覧ください。

エージェントノードとは


エージェントノードは、Difyのチャットやワークフロー内で使われる機能です。これを使うと、必要なツールを自動で呼び出すことができ、AIがその場で最適なツールを選んで実行し、複数のステップを踏んで問題を解決します。

エージェントノードの使い方

v1からエージェントノードが追加されている。

ツールリストとインストラクション、クエリを指定することでエージェントを設定することができます。

  • ツールリスト
    エージェントが呼び出すことができるツールを追加および構成します。

  • インストラクション
    エージェントのタスク目標とコンテキストを定義します。

  • クエリ
    ユーザー入力を受け取ります。

ToolとInstruction、Queryを指定

実行した結果は以下のようになります。
・ユーザーの入力

パリに行きたいのですが、有名な観光地をいくつか挙げて、それぞれの特徴を教えてください。
・1回目のLLM呼び出し
「パリ 有名な観光地 概要」で検索 → 検索結果を出力
(この検索キーワードをLLMが考えているのがポイント)
・2回目のLLM呼び出し
検索結果を元に要約→最終出力

LLMが検索キーワードを考えて、検索した内容に基づいて回答している

エージェントノードの強み

これまでのワークフローは固定化された流れを記述することが一般的でした。それに対して、エージェントノードは入力内容に応じて、実行内容が動的に変化することが特徴です。したがって、ツールをどう使うかをLLMが柔軟に考えられることが、エージェントノードの強みです。これにより、従来のRPAのような固定化されたワークフローとは異なり、入力内容に応じて柔軟性をもったワークフローを構築することができます。

Agentic Strategyの違い

エージェントノードには、Agentic Strategyと呼ばれる、エージェントの実行戦略を設定する項目があります。現在のところ、Agentic Strategyには「ReAct (Reason+Act)」と「関数呼び出し (Function Calling)」という2つがあります。
どちらもLLM が外部システムと連携し、より実用的なタスクをこなせるようにするための仕組みです。しかし、何を目指しているかどう動くかが異なるります。違いをザックリまとめると、以下のようになります。

Agentic Strategyと呼ばれるエージェントが実行する戦略を設定できる

どんな場面で使うか

  • 関数呼び出し (Function Calling)

    • はっきりと定義された外部機能やAPIを呼び出して、一度もしくは少ない回数で結果を得るタスクに適している。

    • 「特定のAPIを叩いて現在の株価を取得する」「データベースに問い合わせて合計金額を出す」など、やりたいことや必要な引数が決まっている場面に向いている。

    • 例: 「天気予報APIに場所と日付を投げて、一発で回答を得る」というシンプルなやり取り。

関数に与えるパラメータのみ作成する
  • ReACT

    • 複数ステップの推論段階的な検索・計画が必要なタスクに強い。

    • 「ある情報を元に、次に何をすべきか考えて行動し、得られた結果からさらに推論を進める」ような流れが想定される場面に向いている。

    • 例: 「Web検索→記事要約→もう一度検索→新たに得た情報を組み合わせて判断」など、多段階のやり取り。

自分の状況の説明とアクションをLLMが考える

動き方のイメージ

  • ReACT の場合

    1. LLM がまず考える (Reason)

      • 「いま必要な情報は何か? どんなツールを使えばいいか?」などを、LLMが文章内で思考プロセスとして踏む。

    2. 必要に応じて行動する (Act)

      • ツールやAPIを呼び出し、結果を観察。

    3. 新たに得た情報を元に再び考える

      • さらに推論を深める。

    4. 最終的な回答やアクションを決定する

  • 関数呼び出しの場合

    1. LLM が「どの関数をどう呼び出すか」を一気に決定する

      • 例: 「get_weather(場所=パリ, 日付=来週)」のように、最適な関数名と引数のJSONを返す。

    2. アプリケーション側がその関数を実行し、結果を LLM に返す

    3. LLM が結果を用いて最終的な応答をユーザーに返す

簡単にまとめ

ReACT
→ LLMが自分で考えながら何度も行動できるようにするアプローチ
・メリット
→ 高度な推論や、柔軟なアクションの組み合わせができる
・デメリット
→ 手順が増えるので消費トークン量が増える。また、プロンプト設計の難易度が上がる。

関数呼び出し
→ LLMが必要な関数引数を特定して、アプリがサクッと呼び出すアプローチ
・メリット
→ シンプルでわかりやすく、デバッグがしやすい。
・デメリット
→ 1回や少ない呼び出しで完結するため、複雑なステップには向きにくい。

個人的な見解

今回、プラグインシステムやAgentic Strategyの本質は、Difyのコアレイヤーと外部連携レイヤーを分離しているということになります。コアのレイヤーは継続開発し、外部との連携やカスタマイズの部分は後から注入できる設計になり、拡張性が飛躍的に向上しています。したがって、LLMアプリケーションのデファクトスタンダードのノウハウはDify側で実装するが、それを社会に適応していくところはコミュニティに任せますというメッセージなのだと理解しています。
このように考えると、今後もDifyの使い勝手はますます上がっていくものと期待しています。

おわりに

今回は前編と後編でDifyのプラグインシステムおよびエージェントノードについて解説しました。
プラグインシステムで外部サービスとの連携が楽になった、というのはまだわかりやすいですが、エージェント特有の考え方などは慣れない方も多いのではないでしょうか。

このあたりは私たちのコミュニティである「Dify Studio」の方でも発信していくので、以下のリンクから参加をおすすめします。

株式会社Omlucでは法人向けのDify導入支援パッケージをご提供しております。
自社の業務をDifyで効率化したい、Difyを自社で使えるようになりたいなど、Difyに関するお問い合わせはお気軽にご相談ください


いいなと思ったら応援しよう!