Collaboration: ワークフローのリアルタイム共同編集（v1.14.0）

状態: draft / 重要度: ★★★★★

TL;DR

• v1.14.0 で ワークスペースメンバーが同じワークフローを同時に編集 できるようになった
• グラフ更新が即時同期、誰がどこを触っているかのプレゼンス表示、共有可視化
• セルフホストでは デフォルト無効 — 環境変数 + WebSocket 対応の Gunicorn worker 設定で有効化
• Dify Cloud では既に有効化済み

想定読者

• 複数人で Dify ワークフローを構築している組織
• セルフホスト運用していて Cloud と同等の体験にしたい運用者
• WebSocket / Gunicorn 周りの構成変更に詳しくない開発者

なぜ重要か

これまでの Dify ではワークフローを 1 人が「編集中」にすると他のメンバーは閲覧のみ、または編集を取り合う運用だった。実務でワークフローが複雑化するほど、設計者・SME（ドメインエキスパート）・QA が同時に手を入れたい場面が増える。Collaboration はこの最大の摩擦を解消する。

アウトライン（執筆予定）

1. 機能概要

• 同時編集の挙動（誰がどのノードを選択中か）
• 同期される項目（ノード追加・削除、エッジ、変数、設定）
• 競合解決の方針（Last-Write-Wins か CRDT か — 要調査）

2. セルフホストでの有効化

• 環境変数:
  ENABLE_COLLABORATION_MODE = true SERVER_WORKER_CLASS = geventwebsocket.gunicorn.workers.GeventWebSocketWorker NEXT_PUBLIC_SOCKET_URL = wss://dify.example.com
• なぜ WebSocket worker が必要か（通常の sync worker では持続接続が維持できない）
• リバースプロキシ側の設定（nginx / Caddy で WebSocket upgrade を許可）

3. アーキテクチャの推測

• Server: gevent + WebSocket ベース
• Client: おそらく Socket.IO or 類似プロトコル
• 状態の真実は DB か、メモリ上のセッションか

4. トレードオフと運用上の注意

• スケーリング: WebSocket セッションを複数サーバーで分散させるなら Sticky session or Redis pub/sub が必要
• 帯域: 大型ワークフローでの差分配信コスト
• セキュリティ: ワークスペース内全員が編集権限を持つので RBAC は事前整理が必須

5. 使ってみる

• 試し方の手順（2 タブで同じワークフローを開いて挙動確認）
• スクリーンショット候補

6. 関連リンク

• Workflow Collaboration Docs
• v1.14.0 リリースノート

検証が必要な事項（執筆前に裏取り）

• [ ] 競合解決アルゴリズム（CRDT/OT/LWW）
• [ ] 同時編集の上限人数
• [ ] WebSocket 切断時の挙動
• [ ] プレゼンス表示の更新頻度
• [ ] Cloud と Self-host で機能差があるか

ソース:
- GitHub Release v1.14.0 — Collaboration セクション
- Workflow Collaboration Documentation

本記事は非公式まとめです。正式仕様は Dify 公式ドキュメントをご確認ください。