0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@JaJaThree(JaJaThree)

Dify v1.14.0 の新機能まとめ：共同編集、HITL、MCP、Goto Anything を解説

0
Posted at

Dify v1.14.0 の新機能まとめ：共同編集、HITL、MCP、Goto Anything を解説

はじめに

Dify v1.14.0 がリリースされました。

今回のアップデートでは、ワークフロー開発をチームで進めやすくする ワークフロー共同編集、人間の確認や承認をワークフローに組み込む Human-in-the-loop（HITL）、MCP / Plugin 周りの改善、Goto Anything の強化などが含まれています。

この記事では、Dify v1.14.0 の主な機能を整理し、特に以下の点を詳しく解説します。

  • ワークフロー共同編集
  • Human-in-the-loop / Human Input ノード
  • HITL はワークフローでしか使えないのか
  • Service API での HITL 対応
  • MCP / Plugin 改善
  • Goto Anything の強化
  • セルフホスト環境での注意点

Dify v1.14.0 の主な変更点

Dify v1.14.0 の主な変更点は以下です。

分類 内容
Collaboration 複数人で同じワークフローを共同編集
HITL Service API から Human-in-the-loop フローを扱えるように改善
MCP / Plugin MCP ツールメタデータ、OAuth、スキーマ公開、プラグイン周りを改善
Goto Anything 最近使った項目、/go コマンド、より深いサブセクションへの移動を改善
Prompt Editor スラッシュ入力による変数フィルタリング、キーボード操作を改善
RAG / Knowledge Summary index、Weaviate、Vector projection、tenant check を改善
Infrastructure Docker Compose healthcheck、Celery、PostgreSQL、Redis 周りを改善
Security IDOR 対策、所有権チェック、メール変更フローなどを改善

1. ワークフロー共同編集

v1.14.0 の大きな追加機能のひとつが ワークフロー共同編集です。

これは、複数のワークスペースメンバーが同じワークフローを同時に編集できる機能です。

イメージとしては、Google Docs や Figma のように、同じ編集画面を複数人で開いて作業できます。

Aさん：LLM ノードのプロンプトを修正
Bさん：HTTP Request ノードを追加
Cさん：条件分岐を確認
Dさん：コメントでレビュー指摘

従来は、1人が編集して、他の人は画面共有や口頭確認をするケースが多かったと思います。

v1.14.0 では、同じキャンバス上で複数人が並行して作業できます。

共同編集でできること

リアルタイム編集

複数人が同じワークフローを開き、同時に編集できます。

ノードの追加、移動、設定変更などが他のメンバーの画面にも反映されます。

ただし、同じ要素を複数人が同時に変更した場合は、最後の編集が優先されます。

同じ LLM ノードを Aさんと Bさんが同時に編集
  ↓
後から反映された変更が残る

そのため、チームで編集する場合は担当範囲を分けると安全です。

オンライン状態の表示

現在そのワークフローを開いているメンバーが分かります。

誰が作業中なのかを確認できるため、作業の重複を避けやすくなります。

共同編集カーソル

他のメンバーがどのあたりを見ているか、どの部分を操作しているかが分かります。

複雑なワークフローをレビューするときに便利です。

キャンバスコメント

ワークフローのキャンバス上にコメントを残せます。

たとえば、以下のようなレビューコメントをワークフロー上に直接書けます。

この条件分岐は異常系も考慮した方がよいです。

この HTTP Request ノードのタイムアウト設定を確認してください。

この LLM ノードのプロンプトは少し長いので分割した方がよいかもしれません。

設計メモやレビュー内容を別ファイルに分けるのではなく、ワークフロー画面上に残せる点が便利です。

セルフホスト環境で共同編集を使う場合

セルフホスト環境では、共同編集はデフォルトで無効です。

有効にするには、環境変数の設定が必要です。

例：

ENABLE_COLLABORATION_MODE=true
SERVER_WORKER_CLASS=geventwebsocket.gunicorn.workers.GeventWebSocketWorker
NEXT_PUBLIC_SOCKET_URL=wss://dify.example.com

ポイントは、共同編集に WebSocket が必要になることです。

ローカル検証であれば、環境に応じて以下のように考えます。

環境 NEXT_PUBLIC_SOCKET_URL の例
ローカル ws://localhost
HTTP 公開 ws://192.168.x.x
HTTPS 公開 wss://dify.example.com

HTTPS 環境では通常 wss:// を使います。

2. Human-in-the-loop（HITL）とは

Human-in-the-loop、略して HITL とは、AI や自動処理の途中に 人間の確認・判断・修正・承認 を入れる仕組みです。

AI にすべてを自動実行させるのではなく、重要な判断ポイントで人間が介入できるようにします。

たとえば、以下のような流れです。

ユーザー入力
  ↓
LLM が回答案を作成
  ↓
Human Input ノードで一時停止
  ↓
人間が確認・修正・承認
  ↓
承認された場合のみ後続処理を実行

Dify では Human Input ノードとして使う

Dify では、HITL は主に Human Input ノードとして提供されています。

Human Input ノードに到達すると、ワークフローの実行が一時停止します。

その後、人間がフォームに入力したり、ボタンで承認・却下を選択したりすると、ワークフローが再開します。

HITL はワークフローでしか使えないのか

実務上は、HITL はワークフロー系アプリで使う機能と考えてよいです。

Dify の Human Input は「ノード」として提供されるため、ノードを配置できるアプリで使います。

アプリ種別 HITL / Human Input の利用
Workflow アプリ 利用できる
Chatflow アプリ 利用できる
通常の Chatbot 基本的には利用しない
Agent アプリ単体 基本的には利用しない
Text Completion 基本的には利用しない

つまり、通常のチャットボット設定画面で簡単にオンにする機能ではありません。

Workflow / Chatflow の中に Human Input ノードを配置して使う、という理解が分かりやすいです。

Human Input ノードでできること

Human Input ノードでは、主に以下のことができます。

1. 人間に内容を見せる

LLM の回答案、検索結果、API の実行結果、エラー内容などを人間に表示できます。

例：

以下の回答案を確認してください。

回答案：
{{llm.text}}

この内容で顧客に送信してよいですか？

Markdown 形式で表示できるため、見出し、太字、箇条書きなどを含めた確認画面を作れます。

2. 人間に入力・修正させる

AI が作成した内容を、人間が修正して後続処理に渡すことができます。

例：

AI が作成したメール文面：
{{llm.output}}

修正版を入力してください：
[入力欄]

入力された内容は、後続ノードで変数として利用できます。

たとえば、修正済みの回答文をメール送信ノードや HTTP Request ノードに渡すことができます。

3. ボタンで処理を分岐させる

Human Input ノードでは、人間が選択するボタンを定義できます。

例：

[承認]
[修正して送信]
[再生成]
[却下]

それぞれのボタンに対して、別々の実行パスを接続できます。

例：

承認 → 回答送信
修正して送信 → 修正版を送信
再生成 → LLM ノードへ戻す
却下 → 終了

これにより、AI の出力結果に対して人間が判断し、処理の流れを制御できます。

4. タイムアウト時の処理を決める

人間の入力が一定時間ない場合の処理も設計できます。

たとえば、以下のような分岐が考えられます。

一定時間応答なし
  ↓
自動終了

または、

一定時間応答なし
  ↓
管理者へ通知

業務フローに組み込む場合は、タイムアウト設計が重要です。

v1.14.0 での HITL の改善点

Dify v1.14.0 では、HITL に対して Service API 対応が追加されました。

これにより、Dify の Web 画面だけでなく、外部システムや独自の Web アプリから Human Input の内容を取得・送信しやすくなりました。

v1.14.0 以前のイメージ

従来は、HITL は主に Dify の WebApp や画面上で人間が操作するイメージでした。

Dify WebApp
  ↓
Human Input フォームを表示
  ↓
人間が承認・入力
  ↓
ワークフロー再開

v1.14.0 以降のイメージ

v1.14.0 では、Service API を使って外部システムから HITL を扱いやすくなりました。

外部システム
  ↓
Dify ワークフローを API で実行
  ↓
Human Input ノードで一時停止
  ↓
human_input_required イベントを受け取る
  ↓
外部システム側で承認画面を表示
  ↓
API で承認・入力内容を Dify に送信
  ↓
ワークフロー再開

これにより、社内システム、業務アプリ、チャットツール、管理画面などと組み合わせやすくなります。

Service API を使った HITL の流れ

Service API を使う場合の流れは、おおむね以下です。

1. ワークフローを API で実行する

まず、Dify のワークフローを API 経由で実行します。

Human Input ノードに到達すると、ワークフローは一時停止します。

このとき、イベントとして human_input_required が返ります。

2. form_token を取得する

human_input_required イベントから form_token を取得します。

この form_token は、停止中の Human Input フォームを取得・送信するために使います。

3. Human Input フォームを取得する

form_token を使って、Human Input フォームの内容を取得します。

イメージ：

GET /form/human_input/{form_token}

外部システム側では、この情報をもとに承認画面や入力フォームを表示します。

4. 人間の入力内容を送信する

人間が選択したアクションや入力内容を Dify に送信します。

イメージ：

POST /form/human_input/{form_token}

送信データの例：

{
  "inputs": {
    "review_comment": "この内容で問題ありません。"
  },
  "action": "approve",
  "user": "user-001"
}

送信後、停止していたワークフローが再開されます。

5. 続きのイベントを取得する

SSE 接続が切れた場合や、一時停止後に続きを確認したい場合は、ワークフローイベントを再取得します。

イメージ：

GET /workflow/{task_id}/events

HITL の代表的なユースケース

例1：AI 回答案を人間が承認してから送信する

問い合わせ対応やメール作成で使いやすいパターンです。

Start
  ↓
ナレッジ検索
  ↓
LLM で回答案を作成
  ↓
Human Input：回答案を確認
  ├─ 承認 → 回答送信
  ├─ 修正 → 修正版を送信
  └─ 再生成 → LLM に戻す

向いている用途：

  • 顧客問い合わせ対応
  • 社外メール作成
  • FAQ 回答の確認
  • サポートデスクの一次回答作成

例2：異常検知後に保全担当者が判断する

工場や設備保全のワークフローにも向いています。

センサーデータ取得
  ↓
異常判定
  ↓
LLM で原因候補と対策案を作成
  ↓
Human Input：保全担当者が確認
  ├─ 対応開始 → 作業指示
  ├─ 様子見 → 記録のみ
  └─ 誤検知 → 終了

向いている用途：

  • 設備異常の一次判断
  • 保全作業の承認
  • 作業指示書の確認
  • 異常検知後の対応判断

例3：危険な操作だけ人間承認を挟む

DB 更新、外部 API 実行、メール送信など、影響の大きい処理だけ人間承認を入れる構成です。

ユーザー依頼
  ↓
操作内容を分類
  ↓
低リスク → 自動実行
高リスク → Human Input で承認待ち
  ↓
承認された場合のみ実行

向いている用途：

  • DB 更新
  • メール送信
  • チケット作成
  • 外部 API 実行
  • 社内申請の承認

3. MCP / Plugin 周りの改善

v1.14.0 では MCP と Plugin 周りにも多くの改善が入っています。

主な内容は以下です。

改善内容 説明
MCP tool metadata ツール情報更新後に UI と同期しやすくなった
MCP server URL /v1 が二重に付与される問題を修正
MCP OAuth discovery 不正な JSON を安全に扱うよう改善
MCP schema publishing checkbox や json_object 型のマッピングを改善
Plugin auto-upgrade 自動アップグレード戦略の保存を改善
Local installer ローカルインストーラー周りを改善
File input behavior ファイル入力の挙動を改善
Tenant scoping 内部 API の end-user lookup で tenant スコープを改善

MCP を利用している場合、特に OAuth 認証や MCP サーバ URL 周りでトラブルがあった環境では、v1.14.0 で改善される可能性があります。

4. Goto Anything の強化

Goto Anything は、Dify 内のリソースを横断的に検索して移動できる機能です。

Windows / Linux では Ctrl + K、macOS では ⌘ + K で開きます。

Ctrl + K

または

⌘ + K

検索対象を絞り込むコマンドも用意されています。

コマンド 内容
@app アプリケーションを検索
@plugin プラグインを検索
@kb ナレッジベースを検索
@knowledge ナレッジベースを検索
@node 現在のワークフロー内のノードを検索

例：

@app analytics

@plugin slack

@kb company handbook

@node summary

v1.14.0 では、最近使った項目、/go コマンド、アプリ内のより深いサブセクションへの移動などが改善されています。

ワークフローやプラグイン、ナレッジを多く使っている環境では、目的の場所へ移動しやすくなります。

5. Prompt Editor の改善

Prompt Editor では、以下の改善が入っています。

  • スラッシュ入力による変数フィルタリング
  • 変数リストでの上下キー操作
  • プロンプト編集時の操作性改善

LLM ノードで多くの変数を扱う場合、変数の選択や挿入がしやすくなります。

複雑なワークフローでは、プロンプト内で以下のような変数を多用します。

{{user_input}}
{{knowledge_retrieval.result}}
{{http_request.body}}
{{llm.output}}

こうした変数を扱う場面で、編集効率が上がります。

6. RAG / Knowledge 周りの改善

RAG や Knowledge 周りでは、以下の改善が含まれています。

改善内容 説明
Summary index と Weaviate Summary index 使用時の Weaviate 互換性を改善
Vector projection is_summary と original_chunk_id を含める改善
External datasets 外部データセットの tenant check を強化
Bound datasets バインド済みデータセットの tenant check を強化

Knowledge Retrieval や Weaviate を使っている場合、v1.14.0 は安定性改善の面でも意味があります。

特に、Dify で PDF や CSV を登録して RAG を使っている環境では、Knowledge 関連の修正は確認しておきたいポイントです。

7. Infrastructure / Operations 改善

セルフホスト運用に関係する改善も入っています。

項目 内容
Docker Compose api、worker、worker_beat の healthcheck を追加
Celery デフォルト worker concurrency を 4 に変更
PostgreSQL デフォルト max connections を 200 に変更
Redis key prefix 設定と retry logic を改善
env example .env.example やテンプレートを更新

Docker Compose で Dify を運用している場合、v1.14.0 の .env.example と既存 .env の差分確認をした方が安全です。

8. セキュリティ改善

v1.14.0 では、セキュリティ面の修正も含まれています。

主な内容は以下です。

  • メールアドレス変更フローのトークン処理強化
  • IDOR 対策
  • データソースの所有権チェック強化
  • データセット API の tenant check 強化
  • 外部データセット・バインド済みデータセットのチェック強化

複数ユーザー、複数ワークスペース、複数 tenant で利用している環境では重要な改善です。

セルフホスト環境でアップデート前に確認したいこと

Dify OSS を Docker Compose で運用している場合、v1.14.0 に上げる前に以下を確認した方がよいです。

1. .env.example との差分確認

新しい環境変数が追加されている可能性があります。

diff -u .env.example .env

実際には、既存 .env を直接上書きせず、差分を見ながら必要な項目だけ反映する方が安全です。

2. 共同編集を使うかどうか

共同編集を使う場合は、以下を確認します。

ENABLE_COLLABORATION_MODE=true
SERVER_WORKER_CLASS=geventwebsocket.gunicorn.workers.GeventWebSocketWorker
NEXT_PUBLIC_SOCKET_URL=wss://dify.example.com

WebSocket が必要になるため、Nginx やリバースプロキシで WebSocket が通るか確認します。

3. Plugin / MCP を使っているか

Plugin や MCP を使っている場合は、以下を確認します。

  • プラグインが正常に起動するか
  • MCP サーバ URL が正しいか
  • OAuth 認証が必要な MCP が動作するか
  • Marketplace からプラグインをインストールできるか

4. Knowledge / Weaviate を使っているか

RAG や Knowledge を使っている場合は、以下を確認します。

  • 既存ナレッジで検索できるか
  • Summary index を使っている場合に検索できるか
  • Weaviate のログにエラーが出ていないか
  • 新規ドキュメント登録が正常に完了するか

まとめ

Dify v1.14.0 は、単なる不具合修正版ではなく、チーム開発や業務ワークフロー化を進めるための重要なアップデートです。

特に注目すべき点は以下です。

  • ワークフローを複数人で共同編集できるようになった
  • Human Input ノードによる HITL を Service API から扱いやすくなった
  • HITL は Workflow / Chatflow のようなノード型アプリで使う機能
  • MCP / Plugin 周りの安定性が改善された
  • Goto Anything が強化され、Dify 内の移動がしやすくなった
  • RAG / Knowledge / Weaviate 周りの改善が入った
  • セルフホスト運用向けに Docker Compose、Celery、PostgreSQL、Redis 周りが改善された

個人的には、v1.14.0 の一番大きなポイントは ワークフロー共同編集 と HITL の Service API 対応だと思います。

Dify を個人利用からチーム利用、さらに業務システム連携へ広げていく場合、この2つの機能はかなり重要です。

特に HITL は、AI の回答や処理を完全自動化するのではなく、人間が確認すべきところだけ承認を挟めるため、実業務に Dify を組み込みやすくなります。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?