ステータス: 🟢 現役 最終更新: 2026-07-13 作成者: にしむら(学習キュレーター)
このファイルでできること
Difyを顧客に納品・運用するとき、商用ライセンスが必要になるかどうかを判定できる。あわせて、ライセンス不要かつデータが混ざらない「顧客ごとにインスタンスを分ける」構成を設計できる。003事業で最も事故を起こしやすい論点なので、着手前に必ず引くこと。
使うタイミング:
- 顧客にDifyベースのサービスを提供する構成を決める前
- 「1つのDifyに複数顧客を乗せていいか?」と迷った時
- 契約書・提案書で「データは分離されている」と書く根拠が要る時
免責: ライセンス条項は変わり得る。本ファイルは2026年7月時点の理解の整理であり、可否を最終断定するものではない。再販・マルチテナント提供を検討する時は必ずライセンス原文と最新の利用規約を確認し、必要に応じて専門家に相談すること。
1. ライセンスの基本構成
Apache 2.0 + 独自追加条項(Dify Open Source License)。ベースはApache 2.0だが、商用の再販やマルチテナント提供に制限をかける追加条件が乗っている。
2. 商用ライセンスが不要なケース(Apache 2.0の範囲)
- 自社業務効率化ツールとして社内で使う
- 顧客ごとに独立したインスタンスを立てて納品・運用する
- 商用サービスのバックエンドとしてDifyを使う
3. 商用ライセンスが必要なケース(要注意)
| ケース | 判定 | |---|---| | 1インスタンスを複数テナントに提供(マルチテナント) | 要ライセンス | | DifyのロゴやCopyright表記を削除・変更する | 要ライセンス | | ホワイトラベルで再販する | 要ライセンス |
判定の勘所: 「1つのDifyを複数の顧客で共有する」瞬間に要ライセンス側へ倒れる。逆に「顧客ごとに1つずつ立てる」ならApache 2.0の範囲に収まる。
4. 003事業での安全な構成
顧客ごとに独立したインスタンスを立てる = ライセンス不要 かつ データが物理的に混ざらない
` 顧客A: Difyインスタンス(Docker) + PostgreSQL + Vector DB ← 独立 顧客B: Difyインスタンス(Docker) + PostgreSQL + Vector DB ← 独立 `
1インスタンスに複数顧客のワークスペースを乗せると、マルチテナント=要ライセンスになり、かつデータ分離もアプリ層頼みになって事故りやすい。この二重の理由から003では採らない。
5. 顧客環境の分離方式(比較)
| 方式 | 分離レベル | 商用ライセンス | 003向け | |---|---|---|---| | インスタンス完全分離 | 最強(DB・VectorDB・ストレージが完全独立) | 不要 | 推奨 | | DBスキーマ分離 | 中(アプリ層は共有) | 要ライセンス相当 | NG | | Workspaceで論理分離(Enterprise) | 弱(インフラ共有) | 要Enterpriseライセンス | 顧客増加後に検討 |
003のセキュリティ確定方針でも「顧客間データ分離は物理(1顧客=1プロジェクト)」が絶対線。スキーマ分離・論理分離は人為ミスで貫通するため、ライセンスの観点とセキュリティの観点の両方から「インスタンス完全分離」を選ぶ。
関連ドキュメント
- Dify公式Docs
- GitHub: langgenius/dify
architecture.md— インスタンスを構成するコンポーネント内訳admin-and-logs.md— 顧客に管理画面をどこまで見せるかREADME.md— 辞典の索引に戻る