次の分岐をエージェントが選ぶ。Dify 1.18でワークフローは持ち運びやすく、見通しやすくなる

エージェントのデモは、たった一度のリクエストに成功しただけでも説得力があるように見えます。難しい問いが現れるのは、別のチームが再利用したくなったときです。どの分岐を選ぶのか、どのファイルがアプリと一緒に移るのか、入れ子になったワークフローの中で起きたことをどこで確認できるのか。

2026年10月23日にリリースされた Dify 1.18.0 は、こうした問いを一つにつなげます。今回加わったのは、エージェントの Output Routes 、持ち運び可能な .ifpkgアプリパッケージ 、そして詳しいワークフローの実行表示です。エージェントの回答をさらに華々しくするというより、アプリの中で担う役割を、再利用できるほど分かりやすくする変更です。公式リリース。

Difyは、視覚的なワークフロー、モデル、ナレッジ、ツールを組み合わせてAIアプリケーションを作るプラットフォームです。同じプロンプトをチャットへ何度も貼り付ける代わりに、モデルの判断をアプリケーションの処理につなげられます。今回のリリースで興味深いのは、次の処理を決めること、アプリを移すこと、実行を調べることという三つの実務上の課題を結び付けている点です。

ワークフロー画面：LangGenius / Difyドキュメントの貢献者、CC BY 4.0。切り抜かずに縮小し、WebPへ変換しています。視覚的なビルダーを示す画面であり、今回追加されたすべての操作項目を示すものではありません。

分岐とは、行き先を持つ判断である

従来のワークフローでは、条件は既知の値を調べることが多くあります。ステータスが承認済みか、項目が空か、スコアがしきい値を超えたか、といった確認です。自然言語の依頼はそれほど整っていません。一つのメッセージに、質問、不満、例外対応の依頼が混在することもあります。

Difyの新しい Output Routes では、設定済みのルートの中からエージェントが選択し、対応する分岐へワークフローを進められます。エージェントの解釈がプロセス内の選択となり、次の処理が生成文だけに委ねられず、ワークフロー上に表れます。

これによって、アプリを設計し、調べやすくなる可能性があります。作成者は存在する行き先を定義し、エージェントは依頼に応じてその中から選び、ワークフローは接続された処理を実行します。エージェントの自然言語による説明自体が最終成果物でなくても、ルートには意味があります。

ただし、境界は重要です。「エスカレーション」のルートを選んだからといって、法的・財務的にエスカレーションが必要だと証明されたわけではありません。「返信下書き」のルートを選ぶことは、送信の許可でもありません。それぞれの選択の後にどの操作を許すか、例外を誰が担当するかは、引き続きワークフローに組み込む必要があります。

例1：顧客からの一通のメッセージ、三つの進み方

製品への質問と例外対応の依頼が混在して届く、カスタマーサポートチームを考えてみましょう。アプリに区別してほしいのは、大きく三つの進み方です。承認済みのヘルプ資料から回答する、人が確認するための下書きを作る、通常とは異なる案件を上位担当へ回す、というものです。

明示的なルートがあれば、こうした行き先をワークフロー上に表示できます。単純な設定の質問はナレッジに基づく回答へ、アカウント固有の不確実性を含む依頼は確認へ、取引条件の例外を求める依頼はその判断を担当するチームへ進められます。

これはアプリケーションの選択肢を説明する例であり、Difyが提供する既成のサポート方針ではありません。各ルートに何が該当するかをチームで定義し、適切な事例を与え、入力が曖昧な場合の対応も決める必要があります。説得力のある説明によって、権限の境界が消えてしまってはいけません。

利点は、すべてのメッセージを簡単に分類できることではありません。作成者が特定の判断を評価できることです。難しいメッセージを通常回答の分岐へ送ったなら、テストの失敗が明確になります。すべてを人へ送るなら、安全ではあっても役立つ自動化はわずかかもしれません。

判断に迷うメッセージと期待する行き先を、テスト用に残しておきましょう。複数の依頼が混ざったもの、情報が不足したもの、実際の顧客対応に近い言語の違いも含めます。きれいに整った事例でしか成功しないワークフローは、図が完成して見えても、まだデモです。

設定済みのルートは、言語に基づく判断を、目に見えるワークフローの行き先へ変えます。それぞれの行き先には、許可された操作と確認のルールが必要です。

持ち運ぶのはプロンプトだけではない

AIアプリケーションは、指示、エージェント定義、Skills、ファイル、ワークスペース内のリソースへの参照に依存することがあります。最も目立つプロンプトだけをコピーしても、アプリの多くの部分は置き去りになります。

Dify 1.18では、インラインのAgents、Skills、それらのファイルを含められる .ifpkgパッケージ が導入されました。リリースでは、インポート時にリソースを再作成し、参照を再マッピングすると説明されています。ファイルとURLからのインポートはYAMLとパッケージ形式に対応し、YAMLを明示的に選ぶエクスポートも引き続き利用できます。パッケージとインポートの変更。

再利用にとって意味のある変更です。手作業の説明書を渡して同僚に再構築してもらう代わりに、エージェントの仕組みを説明する関連部品をまとめて移せる可能性が高まります。

ただし、すべての外部依存関係まで自動的に移る証拠ではありません。モデルへのアクセス、認証情報、プラグインの有無、ネットワーク権限、ナレッジリソースは、移行先の環境によって異なります。構造が完全にインポートされても、正しく動かすまでに設定が必要な場合があります。

パッケージは、確認の工程を伴う、有用なアプリケーション成果物として扱いましょう。ファイルには、受け取り側のチームが書いていない指示や補助コンテンツが含まれ得ます。重要なアクセス権を持つワークスペースへ読み込む前に、出所と、エージェントやツールに期待される動作を理解する必要があります。

例2：提案書のワークフローを別のチームへ渡す

あるサービス企業が、提案書の最初の下書きを作るワークフローを構築したとします。依頼を集め、文章作成のSkillを適用し、必須の節がそろっているかを確認し、不確かな取引条件は人へ回します。

別のチームが、異なるサービス一覧で同じ方法を使いたいと考えています。プロンプトだけの引き継ぎでは不十分です。再利用する文章作成の指示、添付テンプレート、エージェントへの参照も動作の一部だからです。パッケージ形式は、そうした関連部品をより多くまとめて移すためのものです。

受け取るチームにも作業は残ります。サービス情報を差し替えるか確認し、許可するモデルとツールを設定し、誰が提案書を承認できるかを検証します。読み込んだワークフローが新しいワークスペースに適さないリソースを参照しているなら、インポートに成功したことを理由に、その参照を無条件で残すべきではありません。

移行の前後で、同じ少数のサンプル依頼を実行しましょう。ルートの選択、必須の節、ツールへのアクセス、確認の動作を比較します。持ち運べるアプリケーションには、意図したプロセスを保ちながら、移行先固有の情報を意識して変更できることが求められます。

ここで、パッケージ化は運用上の機能になります。再構築の手間を減らせますが、有用な成果は、別のチームが理解してテストできる、再現可能な引き継ぎです。インポート時に何回のクリックを省けるかは、その一部にすぎません。

ワークフローの内部が見えると、問題の調べ方が変わる

今回のリリースは、入れ子になった実行を含む 詳しいワークフローの実行表示 も重視しています。ユーザーが問題に気付く場所から、いくつも手前の処理でアプリが失敗していることがあるためです。

最終的な下書きの質が悪い原因は、ルーティングの誤り、ナレッジソースの不足、不完全なツールの結果、入れ子のワークフロー内の指示かもしれません。最終回答しか調べられなければ、失敗の原因ではないプロンプトを、いつまでも書き直してしまうおそれがあります。

実行が見える範囲が広がれば、問いを絞り込めます。この処理にどの入力が届き、何を出力し、次にどの処理がそれを使ったのか。その答えが分かれば、アプリの複数箇所を一度に変更するより、的確に修正できます。

可視性は、モデル内部の推論を完全に説明することとは異なります。実行情報でアプリケーションのイベントやデータの流れが見えても、すべてのトークンやルートが選ばれた理由までは確定できません。また、トレースのどの内容を誰に見せてよいかを自動で決めるものでもありません。

利用できる実行表示を、観測可能なワークフローの動作を理解するために使いましょう。トレースの保存期間、含まれる可能性がある機密情報、アクセスできる人は別途決めます。機密の依頼を扱うアプリで、デバッグの便利さが、内容への無制限なアクセスにつながってはいけません。

リリースされたことと、アップグレードできることは別の問い

GitHubの公式リリースは、日付のあるソフトウェアのリリースです。それだけで、すべてのホスト型Difyワークスペースで同じ機能が同時に有効になった証拠にはなりません。マネージドサービスを使う読者は、特定の操作項目を前提に計画する前に、実際のワークスペースと製品ドキュメントを確認してください。

セルフホストの環境では、別の責任が生じます。Dify 1.18のリリースノートでは、エージェントのランタイムプロトコルの変更を含め、API、ワーカー、Agent Backend、ランタイムイメージを連携させた変更が説明されています。複数コンポーネントの通信を変えるリリースを取り入れる際に、目に付きやすい一つだけを更新する方法は確実ではありません。

ノートには、ローカルのエージェントサンドボックスとツールの設定・移行に関する注意もあります。こうした内容は、実際の構成に基づくアップグレード計画に組み込むものです。製品紹介からコピーした、どの環境にも通用する一つのコマンドに単純化すべきではありません。

アップグレードの前に、現在の設定とアプリケーション成果物を保存し、対応するコンポーネントのバージョンを確認し、適切な環境で移行をテストしましょう。設定例に新しく見える値があるだけで、永続的な認証や暗号化に関係する設定を置き換えてはいけません。リリースの正確な移行手順に従ってください。

当面の目的がルートやパッケージの評価なら、別のテスト用アプリから始めるのも合理的です。最初の実験を、最も重要なワークフローの移行にしてしまわずに、新しい動作を学べます。

有用な評価は一枚にまとめられる

機能の効果を知るために、何十ものエージェントは必要ありません。実際の判断を含む一つのアプリと、インポートを試す二つ目の環境があれば、いくつもの重要な性質が見えてきます。

1. 範囲を絞った作業を選ぶ。 確認を経てサポート返信を作るなど、入力と結果が分かりやすいプロセスを選びます。例外を担当する人も決めます。
2. 少数のルートを定義する。 各ルートに業務上の意味を持たせ、その後の操作を指定します。安全に当てはまらない依頼の行き先も用意します。
3. 代表的な事例を集める。 通常の依頼、複数の意図が混ざったメッセージ、情報不足の事例を使います。実行前に期待するルートを書き出します。
4. 最終回答だけでなく、実行を調べる。 関係する入れ子の処理をたどり、予想外の値や選択が最初に現れる場所を特定します。
5. アプリケーションをエクスポートしてインポートする。 パッケージ内のリソースを確認し、移行先の参照、ツール、モデル、シークレットを点検します。足りないアクセス権を自動で与えるべきだと思い込まないようにします。
6. 移行後に同じ事例を繰り返す。 ルートと出力を比較し、受け取るチームの設定に意図して加えた違いを記録します。

有用な測定項目は具体的です。意図した行き先へ届く頻度、引き継ぎに必要な設定作業の量、実行全体を再構築せずにレビュー担当者が失敗箇所を見つけられるか。いずれも、生成された文章を、それ自体の正しさの証拠として扱う必要はありません。

パッケージはアプリケーションの構造を移せます。移行先ではアクセス権を確認し、成功する動作を定義した事例を再実行する必要があります。

期待が広がる点と、慎重に扱いたい点

期待できる方向は、アプリケーションをより再利用しやすい単位にすることです。ワークフローに明示的な行き先を含め、関連するエージェントのリソースをより多く持ち運び、問題が起きたときには実行を詳しく見られます。単独のプロンプトを卒業した一方で、すべてのアプリを個別の連携開発にしたくないチームにとって、この組み合わせは有用です。

その裏側には、持ち運びやすさが、良いパターンと同じ効率で誤りも広げるという懸念があります。曖昧なルートの定義や、強すぎる権限を持つツールは、整ったパッケージで届いたからといって適切にはなりません。ファイルを開けるかだけでなく、取り込む動作そのものを確認してください。

Difyにとって次の意味ある試験は、モデルの変更、新しいSkill、業務方針の改定、別のワークスペースへの移行を通じて、チームがアプリを維持できるかです。最初のインポートに成功すれば期待が持てます。意図した動作を保ちながら更新を管理できれば、成熟を示すさらに強い材料になります。

Dify 1.18は、エージェントの判断を目に見えるワークフローの構造につなげ、その実験をより興味深くしています。小さなプロセスから始め、ルートを分かりやすく保ち、引き継ぎを再現可能にする。それが、魅力的なデモを、別のチームも責任を持って使えるものへ育てる方法です。

出典

• Dify 1.18.0リリースノート、2026年10月23日06:33 UTC公開。
• Dify公式ドキュメント、製品の背景情報。リリースの利用可否は実際のワークスペースで確認してください。

ワークフローのメモ、依頼の事例、改訂の判断理由を検索できる場所に残しませんか。参考資料をTelli.shに集め、分かりやすい引き継ぎにつなげましょう。