Difyの商用利用とライセンス：公開・販売前の確認点

Difyは、商用利用が一律に禁止されている製品ではありません。

公式リポジトリのLICENSEは商用利用を認める一方、マルチテナント環境の運用や、Difyのフロントエンドにあるロゴ・著作権表示の扱いに追加条件を設けています。

「Apache 2.0だから何でも自由」「料金を払えば全て許可される」という理解では、確認を落とすおそれがあります。

まず、利用するものが公開ソースのDifyなのか、Dify Cloudなのか、個別の商用契約で提供される版なのかを特定します。

その上で、顧客への提供方法、画面、ワークスペース、配布物、接続先を整理しましょう。

出発点は公式LICENSEです。

この記事は、Dify Cloudとセルフホストの違いを学び、社内利用、顧客向け公開、有償提供を検討する初学者・業務担当者向けです。

読後の成果物は、利用形態ごとに原文・未確認事項・確認先を残した表です。

2026年10月27日（Asia/Tokyo）に公式資料を確認しました。

一般的な確認方法を説明するもので、個別案件の法的助言や許諾判定ではありません。

実契約の審査やDifyの実機操作は行っていません。

1. 最初に「何の条件を読むか」を分ける

ライセンスはソフトウェア等を利用する許諾の条件、利用規約はサービスの利用条件を定める文書です。

契約には注文書や追加合意が含まれる場合もあります。

同じDifyという名前があっても、全てが同じ対象に適用されるとは限りません。

利用するモデルの契約や、社内資料を外部へ送る権限は、Dify本体のライセンスだけでは確認できません。

機能が使えること、料金を支払ったこと、データを持っていることも、それぞれ異なる事実です。

とくに「Difyで作ったものを売る」という表現は、内容を分解してください。

自分のアプリの利用料を受け取るのか、Difyのソフトウェアを改変して配るのか、構築支援を提供するのか、DSLや教材を配布するのかで、確認する対象が変わります。

DSLはアプリの設定を表す形式であり、その中に自作でないプロンプトやコード、秘密情報が含まれていないかも別に点検します。

2. 公開ソースのLICENSEで読むポイント

2.1 商用利用の記載と追加条件

調査時点のmainブランチのLICENSEは、Apache License 2.0を修正したものとして、追加条件を示しています。

第1項では商用利用に言及し、他アプリのバックエンドや企業向けアプリ開発基盤としての利用も例示しています。

その後に続く条件を省略して、最初の一文だけで判断しないことが大切です。

ここでいうtenantは、原文で1つのworkspaceに対応すると定義されています。

顧客企業数、ログイン人数、アプリ数、APIキー数を、そのままtenant数へ読み替えないでください。

逆に「社内利用だから複数workspaceの条件を読まなくてよい」とも断定できません。

実際の構成を記録し、第1項aと照合します。

同項は、Difyから書面で明示的に許諾されていないマルチテナント環境の運用を制限しています。

該当する運用を予定する場合は、商用ライセンス等の適用範囲を提供元に確認します。

「誰かが使っていた」「技術的に動いた」は許諾の証拠になりません。

必要な権限管理のための設計を、ライセンス確認を避けるためだけに変更するのも適切ではありません。

2.2 フロントエンドと表示を確認する

frontendの定義には、ソースコードから動かす際のweb/内の部品、Dockerで動かす際のweb imageが含まれます。

原文はDifyのfrontendを使わない利用に、この表示に関する制限が適用されないことも記載しています。

ただし、その例外を他の条件まで消すものとして扱わないでください。

「自分のUIからAPIを呼ぶ」という構成と、「Difyの画面を埋め込み、色やロゴを変える」という構成は同じではありません。

UIは利用者が操作する画面、APIは別のプログラムから機能を呼ぶための窓口です。

DifyのAPI資料は独自バックエンドからの呼び出しを説明していますが、それ自体が個別案件の許諾を与える文書ではありません。

利用者向け画面だけでなく、管理console、埋め込み画面、複製した部品も棚卸しします。

独自UIを使っていても、管理者が利用するDify画面の表示は別に確認が必要です。

表示を残す義務と、宣伝のためにブランドを新しく使う許可も別です。

ロゴを消す方法を探す前に、どの画面のどの表示を変更したいのかを原文と照合してください。

2.3 改変・配布とApache License 2.0

Apache License 2.0の原文では、第4節が再配布の条件を扱います。

受領者へのライセンスのコピー、改変ファイルへの変更表示、配布する派生物のソース形式における該当する権利表示の保持、元の配布物にNOTICEが含まれる場合の帰属表示などを確認します。

NOTICEは帰属情報等を記す通知で、どの案件にも新規作成が必須だと決めつけるものではありません。

同じ原文の第6節は一般的な商標利用の許諾を与えておらず、第7・8節には保証・責任に関する条件があります。

第9節には自らの責任で有償サポート等を提供する場合の扱いがありますが、それをDify公式の保証や認定と表現してはいけません。

Dify固有の追加条件も引き続き照合します。

この説明から「改変したものは全てのソースを一般公開しなければならない」と結論することもできません。

何を配布し、どの条件が適用されるかを確認します。

Apacheの公式ページは英語原文を正本としています。

本記事の説明や各言語版は、ライセンス原文の正式な翻訳や代替契約ではありません。

mainブランチの内容は変わり得ます。

利用中の版、tagやcommit、配布元を記録し、その版に対応するLICENSEを保存・参照してください。

公式リリースは版を調べる入口になりますが、最新リリースが自分の環境の版であるとは限りません。

本記事では利用中の版を特定していません。

3. Cloud・商用契約と公開ページの違いを読む

Dify Cloudの英語Terms of Serviceは、調査時点で2026年6月30日更新と表示され、ServiceをCloudのSaaS等として定義しています。

受諾されたDify Order Formも含めて契約を構成する旨があり、利用範囲、アカウント、公開する内容、第三者サービス等の条件を確認する必要があります。

公開ソースのLICENSEだけでCloud契約の確認を終えないでください。

英語EULAは2026年1月23日更新と表示され、LangGenius, Inc.を契約主体として、Dify Enterprise Editionの商用版等を対象に定義しています。

第II節に内部ネットワーク内での利用、第III節に第三者への提供やhosting等について事前の書面承諾に関する記載があります。

この制限をそのままCloud ToSの条項として説明するのは誤りです。

日本語EULAは2026年7月14日更新と表示され、契約主体は株式会社LangGeniusです。

購入したライセンス区分・エディションの範囲を確認する構成で、開発・検証環境の追加ライセンスに関する条件もあります。

第3条には第三者提供や改変等の条件があり、第3条7項ではAI学習・モデル蒸留等への利用結果の使用も扱っています。

通常の利用・保守・障害調査等に関する例外も含め、該当する契約全体を読みます。

ただし、学習等や競合・代替・類似する製品等の開発を目的とする場合は、その例外に含まれない旨も確認します。

英語版と日本語版は、単に同じ本文を置き換えたものとして扱えません。

新しい日付だから全ての契約に適用される、日本語で読んでいるから日本法人の契約になる、とも判断できません。

契約相手、購入版、注文書、追加合意、適用言語や文書間の優先関係を確認してください。

ここで挙げたEULAの条件を、公開ソースのCommunity利用全般へ広げないことも大切です。

もう一つ注意したいのが、紹介文と許諾本文の違いです。

Enterprise料金ページのCommunity紹介には非商用プロジェクト向けという表現がありますが、リポジトリのLICENSEには条件付きの商用利用の記載があります。

紹介文の一行だけで「Communityは商用禁止」とまとめず、対象版の原文と実契約に戻ります。

不一致が案件に影響する場合は、その箇所を示して照会します。

Enterpriseの紹介に商用ライセンスの認可や複数workspaceが記載されていても、あらゆる再販売、第三者へのhosting、表示変更が自動的に含まれるとはいえません。

同様に、Cloudの有料プランで機能が増えることと、自分の提供方法への許諾は別です。

Cloud料金ページは機能・利用枠を確認する資料として使い、個別条件を価格だけから推測しないようにします。

4. 利用形態別に原文確認表を作る

次の6例は、原文を探すための架空の机上演習です。

「利用可能」「違反」と自動判定する表ではありません。

同じ構成に見えても、対象版、契約、配布物、書面許諾が異なれば確認結果は変わります。

USE-01で1 workspaceと書いたことは、他の条件を確認しなくてよいという意味ではありません。

USE-02でも「APIだから無条件に追加許諾不要」とはしません。

USE-03・04では原文が挙げる条件に正面から向き合い、機能が動くかを試す前に、必要な確認と許諾の取得を進めます。

USE-05では、Dify自体を配る部分と、自分の設定を渡す部分を分けます。

DSLの公式説明では、設定・プロンプト・Knowledgeへの接続等が対象で、Knowledge本文や利用ログは含まれません。

Secret型環境変数を含める選択肢がある点にも注意します。

エクスポートできた事実は、同梱内容を販売・再配布する権利の証明ではありません。

USE-06のように提供形態を変える場合は、以前の確認結果をそのままコピーしません。

Cloudから自己運用へ、Communityから商用契約へ、社内向けから顧客向けへ変わるたびに、どの文書のどの条件を確認し直すかを書き足します。

5. 本体以外の権利を別欄で確認する

5.1 ブランド、プラグイン、モデル、データ

Difyの画面に既にある表示を保持することと、自分の広告や有料教材へロゴを新しく使うことは別です。

Brand Usage Termsは、説明・報道等の参照と、事前の書面承認を必要とする商用の宣伝等を区別しています。

公式提携、認定、推奨を根拠なく示してはいけません。

Brand Guidelinesには、Powered by Difyバッジを商用マーケティング、有料研修、収益化した講座等で使う際の書面許可に関する記載もあります。

「公式だと名乗らなければどんなバッジ利用も自由」と単純化しないでください。

Brand Usage Termsには見出し側の2025年11月28日と本文側の2025年3月4日という日付表示が併存しているため、照会時はURLと確認日、問題になる条項を一緒に示します。

プラグインも本体と分けます。

Marketplace Agreementは開発者による提出・配布を扱い、プラグインの商用利用と、Marketplaceでの販売方式の条件を別に定めています。

調査時点では無料プラグインのみとする記載があり、外部の有料サービスを必要とする場合の開示も求めています。

これを「外部APIも無料」「依存ライブラリを無条件で再配布できる」という意味に広げないでください。

プラグイン開発ガイドラインやプライバシーガイドラインを参照し、配布元、版、含まれるコード・素材、送信先を整理します。

Marketplace掲載済みというだけで、自分の案件の権利やセキュリティ確認が完了するわけではありません。

manifestの仕様にある権限やプライバシー情報も、配布物のライセンス本文の代わりにはなりません。

モデルAPIでは、提供者、契約主体、入力の利用権、生成結果の利用条件、保存・学習利用の条件などを確認します。

Difyのモデル設定資料は、Cloudのクレジットと持ち込むAPIキーの経路を説明していますが、全モデルの生成結果に一律の権利を与えるものではありません。

今回はモデルを指定していないため、特定の提供者の規約を確認済みとはしていません。

社内資料や購入した教材を持っていても、それを外部サービスへ送信し、複製・公開・再配布できるとは限りません。

生成結果についても、契約上の利用条件と、著作権等の法的保護や第三者の権利は同じ問いではありません。

用途と素材を特定し、判断が必要な部分を担当者や必要に応じて専門家へ確認します。

6. 机上演習：原文から確認事項を取り出す

この演習ではDifyを起動せず、ロゴを変更せず、APIを呼びません。

架空の計画を読み、必要な資料と不足情報を書き出します。

実案件で許諾された事例として引用しないでください。

USE-02の条件を具体化すると、次のようになります。

検討ID: LEARN-009 / USE-02
運営者: ハーバー教材室（架空）
目的: 学習教材について答える顧客向けの有料FAQを計画
利用形態: Communityの自己運用を検討、対象版は未特定
workspace: 1つを計画。実環境では未確認
利用者画面: 独自に作成し、Dify APIをバックエンドから呼ぶ想定
Dify frontend: 公開画面へ部品を流用しない想定。管理consoleは利用し、表示を維持
配布: Difyソフトウェアの顧客への配布は予定しない
モデル・プラグイン・入力資料の権利: 未確認
書面許諾・契約確認: 未実施

まず、この例の事実と推測を分けます。

「1つを計画」は稼働中のworkspace数の実測ではありません。

「独自に作成」は、実際の部品にDify frontendを含まないと確認した証拠でもありません。

後から開発者に確認する項目として残します。

次に、対象版のLICENSE第1項a・bへ戻り、何が原文に書かれているか、何が計画書からは分からないかを記入します。

文章を読んだ状態と、許諾を取得した状態は分けてください。

完成の目安は、単に「商用利用OK」と書けたことではありません。

対象文書、節、条件、不明点、次の確認相手がつながっていることです。

配布用の原文確認シートには、6例の確認観点と、自分の案件を記入する空欄を用意しています。

確認状態にはnot_checked（未確認）、text_reviewed（本文を読んだ）、question_open（照会事項がある）、evidence_recorded（証拠を記録した）などを使えます。

これらは教材の管理用ラベルで、法律上の判定区分ではありません。

evidence_recordedも、全条件の充足や許諾の取得を自動的に意味しません。

証拠が示す対象・期間・条件を別に読みます。

不足があれば、次のような照会案へまとめます。

これは架空例の下書きで、送信していません。

件名: LEARN-009の提供形態に適用される条件の確認

ハーバー教材室という架空事例の計画を整理しています。
Communityを1 workspaceで自己運用し、独自UIとバックエンドAPIで、顧客向けの有料FAQを提供する想定です。
公開画面にはDify frontendの部品を流用しない想定ですが、管理consoleは利用し、ロゴ・著作権表示を維持します。
Difyソフトウェア自体の配布は予定していません。対象版と接続モデル等は未確定です。

対象版と実構成を確定した上で、LICENSE第1項a・bに関して必要となる確認や、追加の許諾の範囲を教えてください。
別契約が必要な場合は、対象法人、エディション、外部提供、表示、期間、追加条件が分かる書面をご案内ください。
回答がどの構成と版に適用されるかも確認したいと考えています。

この文面は学習用で、実案件の申込みや許諾取得を示すものではありません。

実際に照会する際は、実情に合う情報へ置き換え、対象文書のURL・節・確認日と、必要なら秘密情報を除いた構成図を添えます。

契約窓口や公式ページに掲載された連絡経路を確認し、APIキー、認証情報、顧客データを送らないようにしてください。

返答は対象案件と結び付けて保存し、他の顧客・版・構成へ無条件に転用しません。

7. 公開・販売前に残す記録

原文確認は、アプリが動くかどうかのテストとは別です。

Difyの公開機能でWebアプリやAPIを公開できても、契約・権利・データ保護・アクセス制御まで確認済みになるわけではありません。

取得日、文書の更新日、契約の締結日・効力発生日は別の欄にします。

Webページを今日読んだことは、その契約が今日から自分へ適用されたことを意味しません。

動くmainへのリンクだけでは後から同じ内容を追えないため、適切な保存先と対象版を記録します。

未回答の照会がある、必要な書面の対象範囲が分からない、実際の配布物を把握していない場合は、その状態を残して判断担当へ引き継ぎます。

全ての欄に機械的なチェックを付けることより、何を根拠に確認したかが追えることを優先してください。

8. よくある誤解と疑問

社内利用なら確認は不要ですか。

不要とはいえません。

workspace構成、画面表示、素材、モデルや外部サービスの契約は社内利用でも確認します。

公開ソースと商用契約の条件も分けてください。

自分で作った画面にDifyロゴは必要ですか。

第1項bのfrontendの定義と例外を読み、使った部品と画面を特定します。

独自UI、Difyの管理console、埋め込みを一括で判断しないでください。

本記事では個別の画面構成について許諾を判定していません。

有償の構築支援を始めると、必ずEnterprise契約が必要ですか。

有償かどうかだけでは決まりません。

提供する作業、運用する環境、配布物、表示、適用契約を特定します。

Dify公式の支援や認定であるかのような表示には、別の根拠が必要です。

生成した回答は自由に販売・再利用できますか。

Dify本体だけでは判断できません。

モデル提供者の条件、入力資料や第三者の権利、適用契約、利用目的を確認します。

契約によっては学習・モデル蒸留等への利用結果の使用にも条件があるため、通常の回答表示と同じ扱いにしないでください。

この記事の各言語版を契約書の代わりにできますか。

できません。

各言語版は同じ確認方法を説明する学習記事です。

正式な文書、実契約、必要な書面許諾を確認するために使ってください。

9. 次の一歩と更新のしかた

まず自分の利用形態を1つ選び、原文確認シートへ対象版、workspace、画面、外部提供、配布物を書き込んでください。

その上で、どの原文を読み、何が未確認で、誰へ照会するかを結び付けます。

商用利用という言葉を、具体的な構成と契約の確認へ置き換えることが、この教材の到達点です。

次の学習では、Workflow、Chatflow、Agentなど、目的に合うDifyのアプリ種類を選びます。

アプリの種類を決める技術的な判断と、公開・販売の権利確認は別に記録すると、後から構成を変えたときにも追跡しやすくなります。

公式文書の変更、版や契約の更新、利用者や提供先の変更、frontendの改変、配布物の追加、モデルやプラグインの変更があれば、該当する欄を再確認します。

本文のリンクは調査した公式資料への入口です。

確認日を更新するだけでなく、変わった条件と自分の案件への影響を記録してください。