Difyを本番運用しているなら、アップデート前に確認すべきなのは『新機能』よりも『戻せる状態か』です。公式Docker Compose ドキュメント（2026-07-28更新）ではDocker Compose 2.24.0以上を前提に自己ホスト手順が整理され、起動時にはapi・api_websocket・worker・worker_beat・web・plugin_daemon・agent_backendの7つのコアサービスに加え、PostgreSQL・Redis・Milvus・S3等の依存コンポーネントが連動します。つまり更新はアプリだけでなく周辺構成、特に.env優先度、docker compose ps の Up or healthy 状態確認まで含みます。
この記事では、Dify管理者がアップデート前日に確認したいバックアップ対象、権限分離の切り方、当日の実行手順、ロールバック判断の基準を実務向けにまとめます。PoC環境から本番へ移る情シスや業務改善担当が、そのまま社内手順に落とし込める構成です。公式リリースノート・.env差分・sandbox設定・plugin設定・主要ワークフロー疎通の確認点まで網羅します。
なぜDifyアップデートは事前確認が重要なのか
Dify公式のDocker Compose docs では、デプロイ後もdocker/.envを直接管理し、さらに docker/envs/*.env で追加設定を上書きできる設計になっています。ただし『docker/.env が docker/envs/*.env より優先される』という明示的な階層が存在します。つまり環境ごとに設定が散らばる構成になっており、アップデート時に『どの設定がどこに書いてあるか』を把握していないと、既存設定が飛ぶリスクがあります。
公式Premium on AWS upgrade docs では『更新前にGitHub release notesを確認し、.env / envs / volumes をバックアップすること』を明記しています。さらに GitHub release notes v1.13.3 では sandbox 設定の python_path/nodejs_path 更新に注意が必要で、v1.11.4 では Node.js 24.13.0 の AsyncLocalStorage/async_hooks DoS CVE（CVE-2024-27985等）対応が案内されています。つまり『更新ボタン感覚では危険』で、リリース差分と環境差分を先に確認する運用が前提です。
Environment Variables docs には WORKFLOW_MAX_EXECUTION_STEPS、MAX_PARALLEL_LIMIT、WORKFLOW_LOG_RETENTION_DAYS など、運用に直結する設定があります。これらが既存の .env に入っていて、新バージョンで推奨値が変わった場合、明示的に継続指定しないと既定値に戻ります。本番では大規模ワークフロー実行やバッチ処理があるため、これらの設定値変化は直接的な停止につながる可能性があります。
アップデート前に必ず取るべきバックアップ
最低でも4点を分けて退避します。第一はPostgreSQLなどの永続データです。『docker compose exec postgres pg_dump -U postgres dify > backup_$(date +%Y%m%d_%H%M%S).sql』で本体DBを、さらに『docker volume ls | grep dify』で全volumeを特定し、各volumeをtar化します。Difyはdb・redis・milvus・s3各領域でデータを保持しているため、単なるDBダンプだけでは不足です。
第二は docker/.env と docker/envs/*.env 全ファイルのコピーです。『cp -r docker docker.backup.20260801』で丸ごと退避し、その際に『md5sum docker/.env > env.md5』で整合性も記録しておきます。.envは機密情報（API Key、DB password）を含むため、アクセス権限を絞った退避先（admin-only ディレクトリなど）に置きましょう。
第三は『docker compose ps』と『docker images grep dify』の出力を記録します。現在動作中のイメージタグ・コンテナ ID・ステータスを記録することで、更新失敗時に『どのバージョンで問題が起きたか』を即座に判定できます。公式doc を参照し、アップデート前の状態を『docker compose ps > status_before.log』で残すのが運用習慣です。
第四は『主要ワークフローの設定と実行フロー』です。Dify本体に保存されたワークフロー定義は、理論上はDB復旧で戻りますが、『このワークフローは正常に実行されるはず』という期待値を記録しておくことは重要です。更新後のテストで『以前と同じ入力に対して同じ出力が得られるか』を検証するため、主要フロー（例：「顧客問い合わせ分類」「営業提案生成」）の正常実行ログと期待出力を記録しておきましょう。
実務では『バックアップ取得時刻と対象をチェックリスト化』してください。例：『14:00 DBダンプ完了（23.5MB）』『14:05 docker/ 全ファイル退避完了』『14:10 docker compose ps 記録』『14:15 主要ワークフロー5本の疎通確認記録』のように時系列で残すと、障害時に『どこまで戻せるか』『どのタイミングの状態が最後の正常状態か』を即判断できます。
権限分離はどこまで必要か
更新作業を一人のフル権限運用に寄せすぎると、『変更と承認と検証が同じ人に集中』する状態になり、障害時の責任追及も曖昧になります。おすすめは以下の3～4役に分けることです：（1）実行担当：サーバーアクセス、docker pull・up の実行、（2）確認担当：更新後テスト実施（ログイン・ワークフロー実行・プラグイン確認）、（3）業務オーナー：ロールバック判断の最終決定、（4）監視担当：更新中・更新後のシステムメトリクス監視（CPU・メモリ・DB接続数）。
少人数でも『実行する人』と『戻す判断を出す人』を分けるだけで事故率は下がります。Difyの運用はアプリ設定だけでなく、サーバー・Docker・接続先LLM モデル・プロキシ設定（proxy_tunnel_http等）にもまたがるため、責任分界を曖昧にしない方が安全です。特にロールバック時は『判断の遅延が被害を拡大する』ため、決定権者を事前に明記しておくことが重要です。
当日のアップデート手順
当日は、以下の順序で進めます。ステップ1：リリースノート確認（GitHub official releases）。変更対象に『認証機構の変更』『環境変数新規追加』『依存サービス更新』『sandbox設定変更』『プラグインAPI互換性変更』が含まれるかを見て、内部向けセキュリティアラートを確認します。
ステップ2：バックアップ取得。前述の『DBダンプ・env ファイル・現行タグ・主要ワークフロー確認』を順に実施し、チェックリストで確認完了をマーク。ステップ3：メンテナンス告知。『Dify 運用中のため、アップデートのため15時～15時30分の間サービス停止』など、エンドユーザーにも周知します。
ステップ4：更新実行。公式手順では『docker compose down → 新イメージpull → docker compose up -d』が基本です。まず『docker compose down』で全コンテナ停止、次に『docker compose pull』で新イメージ取得、最後に『docker compose up -d』で起動。Difyは複数コンテナで構成されるため、起動順序がDocker Compose自動制御の範囲内なら問題ありませんが、特に worker・worker_beat・api の起動順序が逆になると初期化エラーが出る可能性があります。起動後は『docker compose logs -f api』で初期化ログを監視します。
ステップ5：起動確認。『docker compose ps』で全コンテナが Up or healthy 状態か確認。一つでも Exited や Dead 状態があれば、ログ確認してから次に進みます。ステップ6：主要機能疎通確認。以下の4点を必ず通してください：（1）Web UIログイン、（2）新規ワークフロー作成・保存、（3）既存ワークフロー実行（複数モデル呼び出し含む）、（4）プラグイン機能確認（Webhook呼び出しなど）。
ステップ7：メトリクス確認。『docker stats』で CPU・メモリ・ネットワークI/O に異常がないか。特にdb・redis コンテナがメモリリークを起こしていないか、worker が高CPU で留まっていないかを確認します。これら全てが正常なら、更新成功と判定。アップデート直後は新機能や改善点の動作検証も進められますが、『基本動作』を優先してください。
ロールバック判断を遅らせないコツ
ロールバック条件は事前に『数値化』しておくと迷いません。例：『15分以内に管理画面へログインできない』『主要ワークフロー2本以上が failure 継続』『接続先LLMの呼び出しで『503 Service Unavailable』がタイムアウト回数超過』『メモリ使用率が更新前比で50%以上増加』ならロールバック実行、という形で決めておきます。Dify公式は『各リリースのアップグレード手順は異なる可能性がある』と案内しているため、『戻し方も現行バージョン単位でメモ』する必要があります。
ロールバック実行時は：（1）『docker compose down』で新バージョンを停止、（2）『rm -rf docker/volumes/*』で新バージョンが作ったvolume削除（必要に応じて）、（3）『docker pull <old_image_name:old_tag>』で旧イメージ再取得、（4）『docker compose up -d』で旧バージョン起動、（5）DBダンプから復元『docker exec postgres psql -U postgres -d dify < backup_YYYYMMDD_HHMMSS.sql』、（6）旧ワークフロー疎通確認、という流れです。障害時に考えるのではなく『更新前に戻すラインと戻し手順を決めておく』のが運用手順の核心です。
社内手順に落とし込むときのチェックリスト
チェック項目は『対象バージョン確認』『Release notes 差分確認』『.env / envs 差分確認』『DBバックアップ完了・md5確認』『環境変数新規項目の継続指定確認』『実行担当/確認担当/決定権者の割当記録』『更新後テスト4項目実施記録』『メトリクス確認』『ロールバック条件と手順の記録』の9つに絞ると回しやすいです。
実装例：
□ 更新日時：2026-08-15 15:00
□ 対象version：v1.13.3 → v1.14.0
□ Release notes URL：https://github.com/langgenius/dify/releases/tag/v1.14.0
□ 変更項目：LLMコネクタAPI、Sandbox sandbox_config.yaml
□ .env新規項目：WORKFLOW_LOG_RETENTION_DAYS（旧値継続：30日）、AGENT_TOOLS_TIMEOUT（新規：600秒）
□ DB backup：backup_20260815_1455.sql（45.2 MB）、md5: abc123def456
□ Docker image：dify-api:1.13.3 → 1.14.0、dify-web:1.13.3 → 1.14.0
□ 実行担当：田中（infoSys）、確認担当：山田（dev）、決定権：部長
□ ロールバック条件：15分ログイン失敗、或いは main workflow failure
□ ロールバック手順：doc.md#rollback_v1.14.0 参照
PoC段階でもこのテンプレートを先に作っておくと、本番移行時に属人化しにくくなります。また月1回は『更新手順ドリル（実際には実行しないで流れだけ確認）』を情シス内で走すことで、更新当日の混乱を減らせます。ニュース性のある新機能より『更新後に業務が止まらない設計』を優先してください。
よくある質問
Q. 毎回ステージング環境での更新テストが必要ですか？
A. 理想は『本番と同じ構成のステージングで事前検証』ですが、リソース制約で難しい場合も多いです。最低限『本番更新の2時間前にDocker Composeの構成確認とdocker compose pull』をして、pull 段階でのエラー（ネットワーク、イメージ署名、互換性）を事前に発見することをお勧めします。
Q. Sandbox 設定の python_path/nodejs_path 更新はどこで見ればよいですか？
A. GitHub release notes の『Breaking Changes』セクションを毎回確認してください。例えば v1.13.3 では『sandbox config.yaml の python_path が /usr/bin/python3.11 から /usr/bin/python3.12 に変更』といった記載があります。Release notes にない場合は、既存値を継続指定（.env で SANDBOX_PYTHON_PATH=/usr/bin/python3.11 など）すれば問題ありません。
Q. ワークフロー設定の互換性をどう確認すればよいですか？
A. 更新直後に、本番で実運用しているワークフロー（顧客問い合わせ分類、営業提案生成など）を『同じ入力で実行』し、『同じ出力が得られるか』『実行時間に大きな差がないか』を確認してください。もし互換性破壊があれば、ロールバック判定の『主要ワークフロー2本 failure 継続』の基準に該当します。
Q. Node.js 24.13.0 の AsyncLocalStorage CVE 対応は何をすればよいですか？
A. GitHub discussion v1.11.4 で案内されている CVE-2024-27985 など async_hooks DoS 脆弱性については、『Dify が該当するNode.js バージョンを使っているかを、docker inspect dify-web で確認』し、必要であれば Dockerfile で Node.js version を fixed tag に固定することで対応できます。ただし公式Difyイメージを使用している場合は、Dify側で対応待ちとなります。
Difyの運用設計や権限分離ルール、アップデート手順の整備、障害対応ドリルまで含めて見直したい場合は、 AI・Dify運用のご相談はこちら 。現場運用に合わせたチェックリスト化・権限設計・ドリル実施まで支援できます。
