Dify v1.15.0徹底解説――CLI、推論表示、Human-in-the-Loopで「AIアプリ」から「業務基盤」へ

はじめに

Difyは、Web画面でAIワークフローを作成するだけのツールから、業務システムに組み込めるAI実行基盤へ進化しようとしています。

その方向性がはっきりと表れたのが、2026年6月25日に公開されたDify v1.15.0です。

今回のアップデートでは、次のような注目機能が追加されました。
記載日 2026/7/12

ターミナルからDifyを操作できるdifyctl
モデルの推論情報をリアルタイム表示
Human-in-the-Loopの入力フォーム強化
画像・動画生成など長時間処理への対応
Excel内の埋め込み画像をナレッジへ取り込み
Phoenixを使ったRAGトレースの強化
Plugin DaemonのPyPIミラー自動選択
セキュリティ修正とアップグレード手順の変更

特に重要なのは、Difyの利用範囲が次のように広がった点です。

これまで
Web画面でAIアプリを作成・実行する

        ↓

v1.15.0以降
CLI、バッチ、CI/CD、人の承認、長時間処理を含む
業務プロセス全体からDifyを利用する

本記事では、Dify v1.15.0の中でも特に注目したい機能を、実務での利用イメージとともに紹介します。

Dify v1.15.0の注目機能一覧

機能	注目度	主な用途
`difyctl` CLI	★★★★★	バッチ、スクリプト、CI/CD
推論情報のストリーミング表示	★★★★★	デバッグ、検証、説明性向上
Human-in-the-Loopフォーム強化	★★★★★	承認、確認、ファイル添付
長時間実行モデルへの対応	★★★★☆	画像・動画生成、非同期処理
Excel埋め込み画像の抽出	★★★★☆	製造業資料、点検表、品質報告書
Phoenixトレーシング強化	★★★★☆	RAGの調査、障害解析、可観測性
PyPIミラー自動選択	★★★☆☆	Pluginの安定インストール
UI・操作性の改善	★★★☆☆	ワークフロー編集、初回利用

1. `difyctl`――Difyをターミナルから実行可能に

v1.15.0で最も注目したい機能の一つが、Difyのコマンドラインクライアントである**difyctl**です。

これまでDifyのアプリやワークフローを実行する場合、Web画面を開くか、APIを直接呼び出す実装が必要でした。

difyctlを利用すると、ターミナルからDifyのアプリやワークフローを実行できます。

ターミナル
   ↓
difyctl
   ↓
Difyアプリ／ワークフロー
   ↓
LLM・RAG・外部ツール

`difyctl`で広がる利用方法

difyctlの登場により、次のような使い方がしやすくなります。

シェルスクリプトからDifyを実行する
定期バッチからワークフローを呼び出す
CI/CDパイプラインへAIチェックを組み込む
ローカル環境からAIエージェントを実行する
障害解析スクリプトからDifyへログを渡す
複数ファイルを順番に処理する

例えば、製造設備のログを毎日解析する場合、次のような構成が考えられます。

設備ログ出力
   ↓
定期実行スクリプト
   ↓
difyctlでワークフローを実行
   ↓
異常傾向を分析
   ↓
レポートを保存・通知

CI/CDとの連携

ソースコードの変更時にDifyのワークフローを呼び出し、次のようなチェックを行う構成も考えられます。

GitへのPush
   ↓
CIパイプライン開始
   ↓
difyctlを実行
   ↓
コードレビュー／仕様チェック
   ↓
結果に応じてビルドを継続または停止

Difyは従来からAPI経由で利用できましたが、CLIが追加されたことで、API呼び出し処理を一から実装しなくても、既存の運用スクリプトへ組み込みやすくなります。

対応環境

公式リリースノートでは、以下のプラットフォームへの対応が案内されています。

Windows
macOS
Linux

環境変数をスコープ付きで渡す機能や、レート制限を含むエラー表示の改善も行われています。

difyctlは、Difyを「ブラウザで使うツール」から「開発・運用プロセスから呼び出せる基盤」へ広げる重要な機能です。

2. モデルの推論情報をリアルタイム表示

v1.15.0では、モデルAPIから提供される推論情報を、最終回答とは分離して表示できるようになりました。

対応する画面・実行方法には、次のものがあります。

Chatflow
Workflow
ワークフロー実行プレビュー
difyctl

推論情報は専用の「Thinking」領域へストリーミング表示されます。

モデルの応答
   ├─ 推論情報 → Thinkingパネル
   └─ 最終回答 → 回答欄

これにより、最終回答を読みやすい状態に保ちながら、モデルが出力した推論情報を別に確認できます。

何が便利になるのか

複雑なワークフローでは、期待した回答が得られなかった場合に、次のどこに原因があるのか判断しにくいことがあります。

プロンプトが悪い
入力データが不足している
RAGの検索結果が適切でない
モデルが質問を誤解している
出力形式の指示が弱い

推論情報を確認できれば、モデルがどのように問題を捉えたかを調べる手掛かりになります。

入力
 ↓
モデルが問題をどう解釈したか
 ↓
どの情報を重視したか
 ↓
最終回答

また、表示された推論情報は保存され、ページを再読み込みした後も確認できます。

注意点

ここで表示されるのは、利用しているモデルやモデルAPIが推論情報として返した内容です。

必ずしも、モデル内部で行われているすべての処理がそのまま表示されるわけではありません。

記事やシステム説明では、次のように表現するのが適切です。

モデルAPIから提供されたReasoning情報を、最終回答とは分離して表示できるようになった。

「AIの内部思考を完全に可視化できる」と説明すると、実際の仕様よりも強い表現になるため注意が必要です。

3. Human-in-the-Loopが実用的な承認フォームへ進化

Human-in-the-Loopとは、AIだけですべての処理を完了させず、途中で人の確認や判断を挟む仕組みです。

v1.15.0では、Human Inputノードのフォームで、次の入力形式を利用できるようになりました。

ドロップダウン選択
ファイルアップロード
複数ファイルアップロード
従来のテキスト入力

これまでの自由記述中心の入力から、業務で使いやすい構造化された入力フォームへ進化しています。

製造業での利用例

例えば、設備異常の一次解析をAIに行わせ、最終判断を保全担当者へ依頼するワークフローを考えます。

設備からアラーム発生
        ↓
Difyがマニュアルと過去事例を検索
        ↓
AIが原因候補と対応案を作成
        ↓
ワークフローを一時停止
        ↓
保全担当者が対応方法を選択
        ↓
現場写真やログを添付
        ↓
ワークフローを再開
        ↓
作業記録を作成

ドロップダウンには、例えば次の選択肢を設定できます。

対応方法
- 設備を停止する
- 継続運転して監視する
- 部品を交換する
- メーカーへ問い合わせる
- 上長判断を依頼する

さらに、現場写真、波形データ、ログファイルなどを添付して、後続処理へ渡せます。

完全自動化だけが正解ではない

生成AIを業務へ導入する際、すべてを完全自動化しようとすると、次のリスクがあります。

誤った判断がそのまま実行される
責任の所在が不明確になる
現場固有の状況を考慮できない
高リスクな操作をAIが決定してしまう

Human-in-the-Loopを使えば、AIを「判断者」ではなく、人の判断を支援するアシスタントとして運用できます。

AIが分析する
   ↓
人が確認する
   ↓
承認された処理だけを実行する

特に、設備停止、品質判定、顧客回答、契約確認、社外送信など、人の承認が必要な業務で有効です。

4. 画像・動画生成など長時間実行モデルに対応

画像生成や動画生成のモデルは、テキスト生成モデルと比べて、結果が返るまでに長い時間がかかる場合があります。

従来の同期処理では、生成が完了する前にタイムアウトする可能性がありました。

v1.15.0では、ポーリング方式を利用して、長時間実行される生成モデルの完了を待てるようになりました。

Difyから生成を要求
        ↓
モデル側でジョブを開始
        ↓
Difyが処理状況を定期確認
        ↓
生成完了
        ↓
最終結果を取得

対象となる処理の例

画像生成
動画生成
音声生成
大容量ファイルの解析
非同期ジョブ型API
長時間の推論処理

公式リリースノートでは、画像や動画生成のように応答に時間がかかるモデルが例として挙げられています。

Difyの利用範囲が広がる

これまでDifyは、テキスト生成やRAGを中心としたワークフローで利用されることが多いツールでした。

長時間処理への対応が進むことで、次のようなマルチモーダルワークフローも作りやすくなります。

商品情報を入力
   ↓
LLMで広告文を生成
   ↓
画像生成モデルで広告画像を生成
   ↓
人が内容を確認
   ↓
承認後に配信

今後、画像、動画、音声を組み合わせたAIワークフローが増える中で、重要な基盤機能になると考えられます。

5. Excel内の埋め込み画像をナレッジへ取り込み

製造業や一般企業では、重要な資料がExcelで管理されていることが少なくありません。

しかし、Excel資料には文字情報だけでなく、次のような画像が含まれている場合があります。

設備写真
不具合写真
回路図
グラフ
スクリーンショット
操作手順図
製品画像

従来、Excelをナレッジへ登録しても、埋め込まれた画像が十分に取り込まれず、重要な情報が欠落することがありました。

v1.15.0では、Excelファイル内に埋め込まれた画像を、ナレッジインポート時に抽出できるようになりました。

Excelファイル
   ├─ セルの文字情報
   ├─ 表データ
   ├─ コメント
   └─ 埋め込み画像
          ↓
      ナレッジへ取り込み

製造業との相性が良い

例えば、次のようなExcel資料をRAGへ登録しやすくなります。

設備点検表

点検項目	判定	写真
ベルトの摩耗	要交換	摩耗部分の写真
センサー位置	正常	取付位置の写真
配線状態	要確認	端子台の写真

品質不具合報告書

項目	内容
不具合内容	表面に傷が発生
発生工程	組立工程
原因候補	搬送時の接触
添付画像	不具合部分の写真

これらの資料では、文章だけでなく画像そのものが重要な情報です。

画像抽出への対応により、Difyのナレッジ機能を、現場資料へ適用できる可能性が高まります。

注意点

画像を抽出できることと、画像の内容を常に正確に理解・検索できることは同じではありません。

実際の精度は、次の要素に左右されます。

使用するマルチモーダルモデル
文書解析方式
画像の解像度
図や写真の複雑さ
OCRの認識精度
ナレッジパイプラインの構成

実運用前には、代表的なExcelファイルを使った評価が必要です。

6. Phoenix連携を強化――RAGの処理を追跡しやすく

DifyでRAGを構築した場合、回答が間違っていたときに、原因を調査する必要があります。

しかし、RAGの回答生成には複数の処理が含まれます。

ユーザーの質問
   ↓
検索用クエリの生成
   ↓
ナレッジ検索
   ↓
関連文書の取得
   ↓
LLMへの入力
   ↓
最終回答

回答だけを見ても、どの段階に問題があったのか判断できない場合があります。

v1.15.0では、Phoenix連携が強化され、次のことが可能になりました。

独自のTrace Session IDを指定
アプリケーション側のセッションとトレースを関連付け
ドキュメント検索処理をトレース
RAG結果がどのように作られたかを追跡

Trace Session IDの利用イメージ

業務システムのセッションID
        ↓
Difyワークフロー
        ↓
PhoenixのTrace Session ID
        ↓
LLM・RAG・検索処理を関連付け

これにより、「この利用者の、この質問に対して、どの文書が検索され、どの処理を通って回答されたか」を調査しやすくなります。

本番運用では可観測性が重要

AIアプリは、作成して動けば終わりではありません。

本番運用では、次のような調査が必要になります。

なぜ誤回答したのか
どの文書を参照したのか
検索結果は適切だったか
モデルへの入力内容は正しかったか
どの処理で時間がかかったか
どのセッションで障害が発生したか

Phoenix連携の強化は、Difyを検証用ツールではなく、継続的に監視・改善するAI基盤として利用するための重要な変更です。

7. Plugin DaemonがPyPIミラーを自動選択

DifyのPlugin Daemonは、プラグインが利用するPythonパッケージをPyPIから取得します。

しかし、地域やネットワーク環境によっては、PyPIへの接続が遅い、または不安定になる場合があります。

v1.15.0では、Plugin Daemonが起動時に接続環境を判定し、必要に応じて近いPyPIミラーを自動選択できるようになりました。

関連する環境変数は次のとおりです。

PIP_MIRROR_AUTO_DETECT=true
PIP_MIRROR_URL=

環境変数の意味

`PIP_MIRROR_AUTO_DETECT`

PIP_MIRROR_AUTO_DETECT=true

地域やネットワーク状況に応じて、利用するPyPIミラーを自動判定します。

デフォルト値はtrueです。

`PIP_MIRROR_URL`

PIP_MIRROR_URL=https://example-mirror/simple

利用するPyPIミラーを手動で指定します。

PIP_MIRROR_URLを設定した場合は、自動判定よりも手動設定が優先されます。

社内プロキシ環境での注意点

この機能は、すべてのネットワーク問題を自動的に解決するものではありません。

企業内ネットワークやZscalerなどを利用している場合は、引き続き次の設定確認が必要です。

HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1,api,worker,db,redis

さらに、社内CA証明書の登録や、コンテナ内からの名前解決も確認する必要があります。

8. UI・操作性も改善

v1.15.0では、大型機能だけでなく、日常的な操作性も改善されています。

主なUI改善

初回オンボーディング画面の再設計
「Go to Anything」検索パレットの改善
検索入力欄への自動フォーカス
アプリ削除前の確認追加
ワークフロー編集パネルの折りたたみ
長いエラーメッセージの全文表示
キーボードフォーカスの改善
Startノードの表示改善
Outputノードの設定改善

特に、ワークフローが大きくなると、設定パネルが編集領域を圧迫します。

パネルを折りたためるようになったことで、大規模なワークフローを編集しやすくなります。

従来
設定パネルが常に表示され、編集領域が狭い

v1.15.0
不要なパネルを折りたたみ、編集領域を広く使える

また、エラー通知で長いメッセージを確認しやすくなった点も、トラブルシューティングでは実用的な改善です。

9. セキュリティアップデート

v1.15.0では、新機能だけでなく、セキュリティ修正も含まれています。

特に、Plugin Daemonの転送処理に存在したパストラバーサル問題が修正されています。

対象の脆弱性は次のとおりです。

CVE-2026-41948

また、次の外向きHTTP通信に対して、上限付きタイムアウトが設定されました。

Firecrawl
Jina
Watercrawl
Nacos
Marketplace

SSRF Proxyのデフォルト外向き通信設定も強化されています。

さらに、以下を含む依存ライブラリが、CVE対応のため更新されています。

Bleach
PyJWT
Starlette
ストレージ関連ライブラリ

Self-hosted版を外部公開している場合は、新機能の確認よりも先に、セキュリティアップデートの適用を検討する必要があります。

10. v1.15.0へのアップグレードで注意すること

v1.15.0は、単純にイメージを更新してdocker compose up -dを実行するだけでは不十分です。

以下の作業が必要です。

データベースマイグレーション
Plugin自動更新設定のバックフィル
環境変数の差分確認
Docker Composeファイルの差分確認

10.1 必須のバックフィル処理

v1.15.0では、Pluginの自動更新設定が、プラグインカテゴリー単位の管理へ変更されました。

そのため、既存環境ではデータベース更新後に、次のコマンドを実行する必要があります。

Docker Compose環境

docker compose exec api flask backfill-plugin-auto-upgrade

ソースコード構築環境

uv run flask backfill-plugin-auto-upgrade

公式リリースノートでは、この処理は必須とされています。

実行しなかった場合、既存ユーザーが設定していたPluginの自動更新設定が、期待どおりに動作しなくなる可能性があります。

10.2 データベースマイグレーション

ソースコードから構築している場合は、次のコマンドを実行します。

cd api
uv sync
uv run flask db upgrade
uv run flask backfill-plugin-auto-upgrade

Docker Compose構成では、起動時にマイグレーションが処理される構成もありますが、実際のログとデータベース状態を必ず確認してください。

10.3 環境変数の変更

公式リリースノートでは、次の変更が案内されています。

追加：19個
削除：2個
変更：1個

削除された環境変数

SSRF_REVERSE_PROXY_PORT
SSRF_SANDBOX_HOST

変更された環境変数

変更前
UV_CACHE_DIR=/tmp/.uv-cache

変更後
UV_CACHE_DIR=/tmp/uv_cache

主な追加環境変数

OPENAPI_ENABLED=
OPENAPI_CORS_ALLOW_ORIGINS=
OPENAPI_KNOWN_CLIENT_IDS=
OPENAPI_RATE_LIMIT_PER_TOKEN=

PIP_MIRROR_AUTO_DETECT=true
PIP_MIRROR_URL=

SSRF_PROXY_ALLOW_PRIVATE_DOMAINS=
SSRF_PROXY_ALLOW_PRIVATE_IPS=
SSRF_SANDBOX_PROXY_HOST=
SSRF_SANDBOX_PROXY_PORT=

既存の.envをそのまま使い続けるのではなく、v1.15.0の.env.exampleとの差分を確認してください。

10.4 Docker Composeファイルも変更

v1.15.0では、以下のDocker Compose関連ファイルが変更されています。

docker/docker-compose.yaml
docker/docker-compose.middleware.yaml

また、次のファイルが追加されています。

docker/docker-compose.pytest.ports.yaml

独自にdocker-compose.yamlを編集している場合、公式ファイルで単純に上書きすると、ローカルのカスタマイズが失われます。

アップグレード前にバックアップしてください。

cd docker

cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak
cp .env .env.$(date +%s).bak

11. Docker Compose版のアップグレード例

以下は、公式手順を基にしたアップグレードの流れです。

# Difyのdockerディレクトリへ移動
cd docker

# 設定ファイルをバックアップ
cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak
cp .env .env.$(date +%s).bak

# サービスを停止
docker compose down

# ボリュームをバックアップ
tar -cvf volumes-$(date +%s).tgz volumes

# リポジトリのルートへ戻る
cd ..

# タグを取得
git fetch --tags

# v1.15.0へ切り替え
git checkout 1.15.0

# dockerディレクトリへ移動
cd docker

# .envとComposeファイルの差分を確認
git diff HEAD^ -- docker-compose.yaml
git diff HEAD^ -- .env.example

# サービスを起動
docker compose up -d

# Plugin自動更新設定を移行
docker compose exec api flask backfill-plugin-auto-upgrade

起動後は、次のコマンドで状態を確認します。

docker compose ps

ログも確認します。

docker compose logs -f api

docker compose logs -f worker

docker compose logs -f plugin_daemon

12. アップグレード後に確認したい項目

v1.15.0へ更新した後は、最低限、次の項目を確認することを推奨します。

基本動作

Difyへログインできる
既存アプリを開ける
Chatflowを実行できる
Workflowを実行できる
ナレッジ検索が動作する
Pluginを実行できる

新機能

difyctlをインストール・実行できる
推論情報がThinking領域へ表示される
Human Inputでドロップダウンを利用できる
Human Inputでファイルを添付できる
長時間実行モデルがタイムアウトしない
Excel内の画像が抽出される

運用

APIコンテナにエラーがない
Workerコンテナにエラーがない
Plugin Daemonにエラーがない
データベースマイグレーションが完了している
Plugin自動更新設定が引き継がれている
プロキシ設定が維持されている
独自のCompose設定が維持されている

13. Dify v1.15.0で何が変わったのか

Dify v1.15.0の変更を一言で表すと、次のようになります。

Difyが、Web画面中心のAIアプリ作成ツールから、CLI・人の承認・長時間処理・可観測性を備えた業務ワークフロー基盤へ近づいた。

特に大きな変化は、次の4点です。

1. Web画面以外から呼び出せる

difyctlにより、シェルスクリプト、バッチ、CI/CDなどからDifyを利用しやすくなりました。

2. AIの処理を確認しやすい

推論情報の表示やPhoenixトレースの強化により、モデルやRAGの挙動を調査しやすくなりました。

3. 人を含む業務フローを作りやすい

Human-in-the-Loopのフォームが強化され、人の承認やファイル添付を含む業務プロセスを構築しやすくなりました。

4. テキスト以外の生成AIへ広がった

長時間実行モデルへの対応により、画像や動画生成を含むワークフローへ適用範囲が広がりました。

まとめ

Dify v1.15.0は、一見するとUI改善や機能追加をまとめたアップデートに見えます。

しかし、個々の機能を整理すると、Difyが目指している方向が見えてきます。

ノーコードでAIアプリを作る
        ↓
業務システムからAIを呼び出す
        ↓
人とAIが協調して処理する
        ↓
実行状況を監視・改善する

特に注目したいのは、次の機能です。

difyctlによるCLI実行
Reasoning情報のストリーミング表示
Human-in-the-Loopフォームの強化
画像・動画生成など長時間処理への対応
Excel埋め込み画像のナレッジ取り込み
PhoenixによるRAGトレースの強化

v1.15.0は、派手なAIエージェント機能を追加するアップデートというよりも、AIを実際の業務で安全に動かし、監視し、他システムと接続するための土台を強化したバージョンだと感じます。

一方で、アップグレード時には、次の点に注意が必要です。

データベースマイグレーション
backfill-plugin-auto-upgradeの実行
環境変数の追加・削除
Docker Composeファイルの変更
プロキシや独自設定の引き継ぎ

Self-hosted版を運用している場合は、いきなり本番環境を更新するのではなく、検証環境で既存ワークフロー、ナレッジ、Pluginの動作を確認してから更新することを推奨します。

参考資料

更新履歴

2026年7月：初版作成