Dify 三昧：【速報】Dify v1.13.0リリース！Human-in-the-Loop機能でAIと人間の協働が進化 - アップグレード手順と注意点を解説

はじめに

ディーネットのよろず請負人、深見です。

Dify v1.13.0がリリースされました！今回のバージョンアップでは、AIと人間のコラボレーションを強化する「Human-in-the-Loop（HITL）」機能の導入と、ワークフロー実行エンジンの大幅な改善が目玉となっています。

🎯 エグゼクティブサマリー

このバージョンで何が変わる？

項目	影響度	概要
新機能	★★★★★	Human-in-the-Loop（HITL）により、ワークフロー内での人間の承認・判断が可能に
パフォーマンス	★★★★☆	キャッシュ最適化とメモリリーク対策により、体感速度と安定性が大幅に向上
データベース	★★★☆☆	マイグレーション実行が必要。`flask db upgrade` で自動対応可能。バックアップ必須
API 互換性	★☆☆☆☆	既存 API との後方互換性を維持。外部連携への影響なし
UI/UX	★★☆☆☆	操作方法の変更なし。バグ修正による品質向上が中心

誰に影響する？

すべてのユーザー: HITLによる新しいワークフロー構築の可能性
大規模デプロイメント管理者: 新しいCeleryキュー設定が必須
開発者: パフォーマンス改善とAPI機能拡張の恩恵

🚀 新機能：Human-in-the-Loop (HITL)

HITLとは？

これまでのDifyのワークフローは、完全に自動化されているか、完全に手動であるかのどちらかでした。このため、AIの速度が必要でありながらも人間の判断が不可欠な、リスクの高いシナリオでは「信頼のギャップ」が生じていました。

Human-in-the-Loop（HITL）の導入により、人間の監視がワークフローアーキテクチャのネイティブな部分となり、意思決定が必要なポイントで直接レビュー手順を組み込むことが可能になります。

主な機能

1. ネイティブなワークフロー一時停止

ワークフローの重要な決定ポイントで、「Human Input」ノードを挿入することで、ワークフローの実行を一時停止できます。

2. レビューと編集

このノードはUIを生成し、人間がAIの出力をレビューしたり、変数を修正したり（ドラフトの編集やデータの修正など）して、プロセスを続行する前に介入できます。

3. アクションベースのルーティング

「承認」「却下」「エスカレート」などのカスタムボタンを設定することで、ワークフローのその後のパスを決定できます。

4. 柔軟な配信方法

人間の入力フォームは、WebアプリまたはEメールで配信できます。クラウド環境では、Eメール配信の利用可能性はプランや機能設定に依存する場合があります。

実際の活用シーン

HITLを活用することで、以下のようなワークフローが実現可能になります。

シーン1：コンテンツ承認フロー

AIが記事の下書きを生成
    ↓
【Human Input】編集者がレビュー・修正
    ↓
承認ボタン押下で公開 / 却下で再生成

メリット: AIの執筆速度と人間の品質管理を両立

シーン2：顧客サポート対応

AIが問い合わせ内容を分析し回答案を作成
    ↓
【Human Input】サポート担当者が内容を確認
    ↓
承認で自動送信 / エスカレートで上級者に転送

メリット: 対応スピードの向上と品質保証の両立

シーン3：データ処理ワークフロー

AIが大量データから異常値を検知
    ↓
【Human Input】データサイエンティストが判断
    ↓
承認で処理続行 / 却下で別の処理へ分岐

メリット: 自動化による効率化と、重要判断における人間の専門性の活用

🛠 アーキテクチャのアップデート

実行エンジンのリファクタリング

HITLに必要なステートフルな一時停止/再開メカニズムをサポートし、イベント購読APIを提供するために、実行エンジンがリファクタリングされました。

主な変更点:

ワークフローベースのストリーミング実行と高度なチャット実行はCeleryワーカーで実行されるようになりました
非ストリーミングのワークフロー実行は引き続きAPIプロセスで実行されます
すべての一時停止/再開パス（HITLなど）はCeleryを介して再開されます
イベントはRedis Pub/Subを介してストリーミングされます

大規模デプロイメントおよびセルフホストユーザー向け

新しいCeleryキュー workflow_based_app_execution が導入されました。標準的なセットアップはすぐに機能しますが、高スループット環境では、安定性とパフォーマンスを確保するために以下の最適化を検討する必要があります。

推奨される最適化

1. ワーカーのスケーリング

特定のワークロードに基づいて、workflow_based_app_execution キューを消費するワーカーの数を調整します。

2. 専用Redis（オプション）

大規模なデプロイメントでは、新しい環境変数 PUBSUB_REDIS_URL を専用のRedisインスタンスを指すように設定することを推奨します。水平スケーラビリティを確保するために、Sharded PubSubを備えたRedis Clusterモードの使用を強く推奨します。

📊 アップグレードガイド

アップデート前の確認事項

アップグレードを開始する前に、以下の項目を必ず確認してください。

[ ] 現在のバージョンを確認
[ ] バックアップ計画を策定（データベースとボリューム）
[ ] メンテナンス時間を確保（30分〜1時間を想定）
[ ] 関係者への事前通知

⚠️ 重要なアップグレードノート

必須の変更：新しいCeleryキュー

新しいCeleryキュー workflow_based_app_execution が必須となります。

確認事項:

デプロイメント構成（Docker Compose、Helm Chartなど）に、この新しいキューをリッスンするワーカーが含まれていることを確認してください
このキューは、ワークフローベースのストリーミング実行とすべての再開フロー（HITLなど）に必要です
含まれていない場合、ストリーミング実行と再開タスクは処理されません

運用上の注意：APIトークンキュー

追加のCeleryキュー api_token について。

ENABLE_API_TOKEN_LAST_USED_UPDATE_TASK=true の場合、デプロイメントにも api_token をリッスンするワーカーがあることを確認してください。このキューは、APIトークンの last_used_at タイムスタンプのバッチ更新タスクで使用されます。

⚙️ 新しい環境変数

アーキテクチャの変更をサポートするために、いくつかの新しい環境変数が導入されました。大規模なデプロイメントでは、スケーラビリティを確保するためにPubSub Redisの設定に特に注意を払う必要があります。

重要な設定（大規模環境で必須）

環境変数	デフォルト値	説明
`PUBSUB_REDIS_URL`	(標準の`REDIS_*`設定)	APIとCeleryワーカー間のPubSub通信に使用されるRedis URL。専用Redisの使用を推奨
`PUBSUB_REDIS_CHANNEL_TYPE`	`pubsub`	ストリーミングイベントのチャネルタイプ。高スループット環境では `sharded` を強く推奨
`PUBSUB_REDIS_USE_CLUSTERS`	`false`	PubSubにRedisクラスターモードを有効化。sharded PubSubと組み合わせて水平スケーリングに使用

その他の追加設定

環境変数	デフォルト値	説明
`WEB_FORM_SUBMIT_RATE_LIMIT_MAX_ATTEMPTS`	30	レート制限ウィンドウ内でIPアドレスごとに許可されるWebフォーム送信の最大回数
`WEB_FORM_SUBMIT_RATE_LIMIT_WINDOW_SECONDS`	60	Webフォーム送信のレート制限のタイムウィンドウ（秒単位）
`HUMAN_INPUT_GLOBAL_TIMEOUT_SECONDS`	604800（7日）	人間からの入力を待機しているワークフロー実行が一時停止できる最大秒数
`ENABLE_HUMAN_INPUT_TIMEOUT_TASK`	true	期限切れの人間入力リクエストをチェックするバックグラウンドタスクを有効化
`HUMAN_INPUT_TIMEOUT_TASK_INTERVAL`	1	タイムアウトチェックタスクの間隔（分単位）
`ENABLE_API_TOKEN_LAST_USED_UPDATE_TASK`	true	APIトークンの `last_used_at` タイムスタンプをバッチ更新する定期的なバックグラウンドタスクを有効化
`API_TOKEN_LAST_USED_UPDATE_INTERVAL`	30	APIトークンの `last_used_at` タイムスタンプをバッチ更新する間隔（分単位）
`SANDBOX_EXPIRED_RECORDS_CLEAN_BATCH_MAX_INTERVAL`	200	DBへの負荷スパイクを軽減するために、保持クリーンアップバッチ間の最大ランダム遅延（ミリ秒単位）

アップデート手順

Docker Compose デプロイメント

# 1. カスタマイズした docker-compose.yaml ファイルをバックアップ（任意）
cd docker
cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak

# 2. main ブランチから最新のコードを取得
git checkout main
git pull origin main

# 3. サービスを停止（docker ディレクトリで実行）
docker compose down

# 4. データをバックアップ（重要！）
tar -cvf volumes-$(date +%s).tgz volumes

# 5. サービスをアップグレード
docker compose up -d

注意: hostname resolving error のようなエラーが発生した場合は、以下のコマンドを使用してください。詳細はこちらを参照してください。

docker compose --profile postgresql up -d

ソースコードからのデプロイメント

# 1. APIサーバー、ワーカー、Webフロントエンドサーバーを停止

# 2. 1.13.0 リリースブランチから最新のコードを取得
git checkout 1.13.0

# 3. Pythonの依存関係を更新
cd api
uv sync

# 4. マイグレーションスクリプトを実行
uv run flask db upgrade

# 5. APIサーバー、ワーカー、Webフロントエンドサーバーを再度実行

📌 その他の主な変更点

セキュリティとデータ整合性

データベースの信頼性向上

重複防止の強化: テナントのデフォルトモデルにマイグレーション時の重複排除とユニーク制約を追加しました
ツール削除の修正: プロバイダーIDのタイプ不一致によって引き起こされるツール削除のエッジケースを修正しました

認証とセキュリティ

FastOpenAPI統合の修正: 認証されたユーザーがリモートファイルAPIで匿名として解決される問題を修正しました
動的コード実行の削除: ECharts解析からの動的な新しいFunction評価を削除し、サポートされていないチャートコードに対して明示的な解析エラーを返すようになりました

UI/UXの改善

ファイル関連の応答: メッセージイベントタイプの検出を修正しました
権限管理: マネージャー以外のユーザーに対するワークスペース招待アクションを非表示にしました

パフォーマンスとスケーラビリティ

バックエンドの最適化

キャッシュの改善: プラグインマニフェストのプリキャッシュにより、バックエンドの負荷を削減
クエリの最適化: AppListApiクエリの最適化により、コンソールレイテンシを削減

大規模データタスクの安定性向上

以下の改善により、大規模データタスクの安定性が向上しました：

DBセッションの分割
バッチ処理されたクリーンアップ実行
インデックスチューニング
保持クリーンアップジョブのバッチ間スロットリングの構成

メモリとCPU使用率の改善

CPUオーバーヘッドの削減: RedisClientWrapper による過剰なCPU使用率を修正
セッション管理: Celeryタスクセッションをより小さく、個別の実行に分割するようにリファクタリング

APIとプラットフォーム機能

新しいAPIエンドポイント

エンドユーザー検索: テナント/アプリのスコープを強制するエンドユーザー検索用のService APIエンドポイントを追加
ワークフロー実行履歴: 実行状態の遷移中のワークフロー実行履歴の更新動作を改善

統合の強化

MCP（Model Context Protocol）ツールの改善: MCP応答から使用状況メタデータ（トークン/コストフィールドなど）を抽出し、レポートすることでMCPツールの統合を強化

ローカリゼーション

オランダ語サポート追加: バックエンドの言語マッピングとWebローカリゼーションリソース全体で、オランダ語 (nl-NL) の言語サポートを追加しました

🔍 詳細な変更リスト

Dify v1.13.0では、多数の改善とバグ修正が行われています。主な変更点をカテゴリ別に整理しました。

コードベースの改善とリファクタリング

trial.py 内の reqparse をPydanticモデルに置き換えるリファクタリング (#31789)
プラグイン詳細パネルコンポーネントの保守性とコード構成を改善するためのリファクタリング (#31870)
UpdateDSLModal および Metadata コンポーネントからサブコンポーネントとカスタムフックを抽出するようにリファクタリング (#32045)
Celeryタスクセッションをより小さく、個別の実行に分割するようにリファクタリング (#32085)
document_indexing_update_task をデータベースセッション分割するようにリファクタリング (#32105)
知識取得ノードからデータベース操作を分離するようにリファクタリング (#31981)
document_indexing_sync_task をDBセッション分割するようにリファクタリング (#32129)

バグ修正

コア機能の修正

APIリファレンスドキュメントリンクの en プレフィックスを削除する修正 (#31910)
console_ns のインポートが欠落している問題を修正 (#31916)
MCPサーバーのステータスが正しくない問題を修正 (#31826)
MCP出力スキーマがユニオン型でフロントエンドがクラッシュする問題を修正 (#31779)
自動サマリー環境を修正 (#31930)
delete_draft_variables_batch が無限ループになる問題を修正 (#31934)
db.session の誤用を修正 (#31971)
uuid_generate_v4 がPostgreSQLでのみ使用される問題を修正 (#31304)
エージェントノードのツールタイプが正しくない問題を修正 (#32008)
flask upgrade-db がエラー時に失敗するように修正 (#32024)
ドキュメントDBセッションブロックのバッチ削除を修正 (#32062)
trigger 出力スキーマが欠落している問題を修正 (#32116)
知識パイプラインサービスAPIルートを登録する修正 (#32097)
パイプラインファイルアップロードの created_at をシリアル化する修正 (#32098)
サンドボックス以外のユーザーで有料残高がある場合の処理を修正 (#32173)
dify ホームディレクトリがないことによるパーミッションエラーを修正 (#32169)
すべてのツールが削除される問題を修正 (#32207)
get_message_event_type が誤ったメッセージタイプを返す問題を修正 (#32019)
fastopenapi がユーザーを匿名として認識する問題を修正 (#32236)
RedisClientWrapper による過剰なCPU使用率を修正 (#32212)

UI/UXの修正

ロケールを useExploreAppList の appList クエリキーに含めることで、ローカリゼーションサポートを修正 (#31921)
trigger クエリフックから staleTime/gcTime のオーバーライドを削除し、orpc 契約を使用する修正 (#31863)
探索ページでアプリリストヘッダーを固定する調整 (#31967)
Serwistのプリキャッシュ404エラーを修正するための書き換えルールを web に追加 (#31770)
KB Retrieval設定で不要なスクロールバーを削除 (#32082)
モデルプロバイダーリストを検索する修正 (#32106)
ユーザーのタイムゾーンをアプリコンテキストから日付ピッカーコンポーネントに渡す修正 (#31831)
ベースノードの状態アイコンの表示を修正 (#32208)
現在のユーザーがワークスペースマネージャーでない場合、招待ボタンを非表示にする修正 (#31744)

新機能と機能拡張

下書きを同期するために最新のハッシュを使用する機能を追加 (#31924)
アカウント削除時のクリーンアップ機能を追加 (#31519)
更新をチェックする前にすべてのプラグインマニフェストをプリキャッシュする機能を追加 (#31942)
APIトークンにRedisを使用する修正 (#31861)
MCPツールの使用状況を抽出する機能を追加 (#31802)
Service APIにエンドユーザー検索エンドポイントを追加 (#32015)
Human Input Node 機能を追加 (#32060)
メンバー削除時に孤立した保留中のアカウントをクリーンアップする修正 (#32151)
ワークフローツールファイル出力にファイルマーカーを含める修正 (#32114)
スキーマからワークフローツール出力の説明を埋める修正 (#32117)
Celery設定を強化する機能を追加 (#32145)
ワークフロー実行履歴管理とUI更新を強化する機能を追加 (#32230)
nl-NL言語をサポートする機能を追加 (#32216)

パフォーマンス改善

AppListApi エンドポイントの応答時間を最適化してパフォーマンスを向上 (#31999)
単一削除ではなくバッチ削除メソッドを使用してパフォーマンスを向上 (#32036)
メッセージクリーンアップのパフォーマンスを最適化するためにインデックスを更新 (#32238)

その他の調整

DELETE エンドポイントで適切なHTTP 204ステータスコードを返す修正 (#32012)
ページを閉じるときの自動保存のために sendBeacon を fetch keepalive に置き換える修正 (#32088)
新しい workflow_based_app_execution を含めるように launch.json.example を更新 (#32184)
既読マーク時も会話の updated_at を変更しないように修正 (#32133)
他のノードに接続せずに単一ノードで下書きを実行できるようにする調整 (#31977)
start-worker スクリプトで workflow_based_app_execution キューのタスクを消費するように調整 (#32214)
重複を防ぐため tenant_default_models にユニーク制約を追加 (#31221)
SetupApi を設計上認証不要としてマーク (#32224)
useInvalidateWorkflowRunHistory のモックをパイプライン実行テストに追加 (#32234)
バージョンを1.13.0に更新 (#32147)

おわりに

Dify v1.13.0は、Human-in-the-Loop（HITL）機能の導入により、AIの自動化と人間の判断力を適切にバランスさせた、より実用的なワークフロー構築が可能になりました。完全自動化と完全手動の二択ではなく、重要な意思決定ポイントで人間が介入できる仕組みは、特に高リスクなビジネスシーンでの活用を大きく前進させるでしょう。

また、実行エンジンのリファクタリングやパフォーマンス最適化により、より安定した運用環境が実現されています。大規模デプロイメントを行う場合は、新しいCeleryキューやPubSub Redis設定に注意が必要ですが、適切に構成することで、スケーラビリティの高いシステムを構築できます。

アップデート時は必ずバックアップを取得し、段階的に移行作業を進めることをお勧めします。特に本番環境では、検証環境での動作確認を十分に行ってからのアップグレードを心がけましょう。

Difyの進化は止まりません。次のバージョンでどのような機能が追加されるか、今から楽しみです。

参考リンク

本記事は Dify v1.13.0 のリリースノートを基に作成されています。最新情報は公式サイトおよび GitHub リポジトリをご確認ください。

深見和正