Difyの商用利用とセキュリティ｜社内審査を通すための論点とAzureでの代替構成

Difyで作った試作が社内で評価された。ところが本番化の稟議で止まる——理由はたいてい機能ではなく、ライセンスの条文と、データの置き場所と、「これは誰が作っているものか」に答えられないことです。

本記事は、Difyを業務で使う前に押さえておく3つの論点（ライセンス／データの置き場所／社内審査への答え方）を公式の一次情報だけで整理し、Difyで進める場合と別の道を採る場合の分かれ目までをまとめた実務ノートです。

弊社は、Microsoft 365・Azure の閉じた環境の中でAIを業務活用する「AIプライベート」の設計・実装を手がけています。本記事では、Difyの公式ライセンス原文と公式ドキュメント、そして Microsoft Learn を根拠に、「使ってよいか」ではなく「どの条件なら使えるか」という形で整理します。特定の製品を否定することが目的ではありません。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

Difyでできること、そして稟議で止まる理由

Dify は、生成AIを使ったアプリやエージェントを、画面上でワークフローとして組み立てられる基盤です。社内文書を読ませる仕組み（RAG）やツール呼び出しも一つのワークスペースで扱えるため、試作の速さが大きな魅力になります。実際、「まず動くものを見せる」という用途では有力な選択肢です。

問題は、その先です。試作が評価されて本番化の話になった途端、情報システム部門やセキュリティ部門の確認が入り、そこで止まる。止まる原因は、機能の不足ではありません。ほぼ次の3つに集約されます。

1. ライセンス——どういう使い方までが許諾の範囲か
2. データの置き場所——業務データがどこで処理され、誰が運用するのか
3. 社内審査への答え方——運営元・更新・監査をどう説明するのか

いずれも「使ってはいけない」という話ではなく、条件を満たせるかどうかの話です。順に、公式の一次情報で確認していきます。

論点①ライセンス｜Apache 2.0 だが、2つだけ別扱いがある

Dify のライセンスは Apache License 2.0 を土台にしていますが、それに追加の条件が2つ乗っています。公式リポジトリの LICENSE 原文にある要点は次のとおりです。

• Dify から明示的な書面による許諾を得ない限り、Dify のソースコードを使ってマルチテナント環境を運用してはならない
• Dify のコンソールおよびアプリケーションにあるロゴや著作権表示を、除去・改変してはならない（この条件はフロントエンド部分に対するもの）

実務に翻訳すると、判断はかなりはっきりします。自社の業務で使う分にも、特定の1社向けに構築して納品する分にも、追加のライセンスは要りません。一方で、一つのDifyを複数の顧客で共有させるSaaSとして提供する形と、ロゴや著作権表示を外して自社製品として見せる形は、書面による許諾が必要になります。

やろうとしていること	追加の許諾	補足
自社の社内業務で使う（自己ホスト）	不要	Apache 2.0 の範囲で扱える
特定の1社のために構築して納品する	不要	そのお客様が自社環境で使う形
複数の顧客が一つのDifyを共有するSaaSとして提供する	要・書面による許諾	マルチテナント運用にあたる
ロゴ・著作権表示を外して自社ブランドの製品として見せる	要・書面による許諾	フロントエンドの表示に関する条件

ここで押さえておきたいのは、「OSSだから自由に使える」と「OSSだから自社サービスとして売れる」は別だということです。前者は概ね正しく、後者はこの条文で明確に区切られています。自社サービスの土台に据える構想があるなら、設計に入る前に確認しておくべき点です。判断に迷う提供形態については、公式に商用ライセンスの問い合わせ窓口（business@dify.ai）が用意されています。

論点②データの置き場所｜提供形態で答えが変わる

「Difyは安全ですか」という問いには、そのままでは答えられません。どの提供形態で使うかによって、データがどこで処理され、誰が運用するのかが変わるからです。まず形態を切り分けます。

提供形態	データが処理される場所	主な制約・特徴	運用を担うのは
クラウド版	提供事業者の環境	すぐ試せる。自社テナントの外で動く	提供事業者
コミュニティ版 （自己ホスト）	自社が用意した環境	無料で使える。単一ワークスペースのみで、複数ワークスペースの作成には対応しない	自社
エンタープライズ版	自社が用意した環境	ライセンスキーで有効化。複数ワークスペース・シングルサインオン・詳細な権限管理・モデルプロバイダーのロードバランシング	自社

審査を意識するなら、自己ホストが選択肢になります。データを自社の管理下に置けるからです。ただし、ここで見落とされがちな点があります。自己ホストにした瞬間から、そのサーバーの運用・更新・監視は自社の仕事になるということです。脆弱性が公表されたときに誰がいつ更新を当てるのか、バックアップと復旧は誰が確認するのか、利用者の権限は誰が棚卸しするのか。審査は通っても、運用で詰まる——このパターンが実際にはいちばん多いところです。

もう一点、コミュニティ版が単一ワークスペースである事実は、組織での使い方に直結します。部門ごとにワークスペースを分けて権限を切りたい、という要件が出た時点で、エンタープライズ版のライセンスか、別の構成かの判断が必要になります。小さく始めるほど、この分岐は後から効いてきます。

論点③社内審査で問われること｜確認項目と、答えの作り方

オープンソースのソフトウェアを業務に入れるとき、審査の性質が変わることを理解しておくと、準備が楽になります。商用サービスの審査は「提供事業者の体制」を見るのに対し、OSSの自己ホストの審査は「自社の運用体制」を見ることになります。相手に出してもらう資料がない代わりに、自分たちで答えを用意する必要があります。

実際に問われるのは、おおむね次の項目です。Difyに限らず、OSS基盤を入れるときに共通します。

この一覧を見て「自社で答えられる」となれば、Difyの自己ホストは十分に現実的な選択です。逆に、ここで手が止まるなら、足りないのは製品ではなく運用体制です。無理に押し通すより、既存のID基盤や統制の仕組みに乗る構成へ切り替えたほうが、結果的に早く本番へ届きます。なお、承認されていないAIツールが現場で先に使われてしまう状況への向き合い方は「シャドーAIを止めずに統制する」で扱っています。

判断の分かれ目｜Difyで進める場合／別の道を採る場合

3つの論点を踏まえると、判断は次のように整理できます。どちらが優れているという話ではなく、組織の状況によって向き不向きが分かれるという話です。

Difyが向く状況	別の構成を検討したい状況
社内での試作・検証を速く回したい	複数の顧客へ共有型のサービスとして提供する計画がある
特定の1社向けに構築して納める	既存のID基盤に認証・権限を寄せて統制したい
サーバーの運用・更新を担う要員を置ける	運用要員を置けない、または運用を増やしたくない
扱うデータの機微度がそれほど高くない	審査で厳格なデータ所在・監査要件を求められる

Microsoftの純正部品で同じことをする場合

「別の道」を選ぶ場合、Microsoft 365 や Azure を既に使っている組織であれば、いま持っている統制の仕組みにそのまま乗せる構成が現実的です。審査で問われる項目の多くを、既存の答えで再利用できるからです。

エージェントやワークフローの実行基盤にあたるのが Microsoft Foundry Agent Service です。Microsoft Learn によれば、エンタープライズ向けに次の仕組みが用意されています。

• エージェントごとの専用の Microsoft Entra ID——資格情報を共有せずに、リソースやAPIへスコープを絞ったアクセスができる
• プライベートネットワーク——Azure 仮想ネットワーク内で実行し、ネットワーク分離とデータ所在地の要件に対応する
• 独自リソースの持ち込み——ストレージ、Azure AI Search、Azure Cosmos DB を自社のものにできる
• ロールベースのアクセス制御とコンテンツフィルター——作成・呼び出し・管理の権限を分け、プロンプトインジェクションのリスクを軽減する

もう一つ、業務部門が自分でエージェントを作る用途では Microsoft Copilot Studio が選択肢になります。費用の考え方だけ補足すると、Copilot Studio は無料のユーザーライセンス（テナントの Copilot クレジット購入が前提）のほか、従量課金や前払いプランで利用します。Microsoft 365 Copilot のライセンスをお持ちの場合、Microsoft 365 や Teams、SharePoint の中でエージェントを使う分は Copilot クレジットの消費対象になりません。つまり、すでに手元にある選択肢を先に確認する価値があります。

なお、社内文書を読ませる仕組みを作るときに最も注意が要るのは、「誰がその文書を見てよいか」という権限が検索結果にも効いているかという点です。ここは構成によって扱いが変わるため、「AIエージェントで社内文書を活かす」で詳しく整理しています。エージェントに権限を持たせる考え方は「Entra Agent ID」を、これから始める段階の全体像は「企業におけるAIエージェント活用の始め方」をご覧ください。

まとめ｜判断の順序と、弊社の関わり

試作の段階では、速く作れることが正義です。しかし本番の判断は、作れるかどうかではなく、運用し続けられるかどうかで決まります。弊社は、お客様専用のセキュアなAI基盤の設計・実装を得意領域としています。いま試されている構成をそのまま活かせるのか、既存の Microsoft 365・Azure の統制に寄せたほうが早いのかを、審査で問われる項目から逆算してご提案します。

よくあるご質問

こちらをクリックして「よくある質問」を表示

Dify は商用利用できますか？

できます。ライセンスは Apache License 2.0 を土台としており、自社の業務で使う場合も、特定の1社向けに構築して納品する場合も、追加の許諾なしで扱えます。ただし追加条件が2つあり、一つは「明示的な書面による許諾がなければマルチテナント環境の運用に使ってはならない」こと、もう一つは「コンソールやアプリケーションのロゴ・著作権表示を除去・改変してはならない」ことです。複数の顧客が一つの環境を共有するサービスとして提供したい場合や、表示を差し替えて自社製品として見せたい場合は、公式の問い合わせ窓口で許諾を確認してください。

自己ホストにすれば、データは社外に出ませんか？

Dify 自体は自社が用意した環境で動きますので、その範囲ではデータを自社の管理下に置けます。ただし、実際にどこへデータが渡るかは「どのAIモデルを呼び出すか」で決まります。外部の生成AIサービスをモデルとして接続すれば、そのプロンプトは当然そちらへ送られます。審査ではこの点を必ず問われますので、Dify の設置場所だけでなく、モデルの提供事業者と処理の場所まで含めてデータの流れを図にしておくことをおすすめします。

コミュニティ版とエンタープライズ版は何が違いますか？

コミュニティ版は無料で自己ホストでき、ライセンスキーは要りません。ただし単一のワークスペースで使う前提で、複数ワークスペースの作成には対応していません。エンタープライズ版はライセンスキーで有効化する有償の形態で、複数ワークスペースの管理、シングルサインオン、より細かい権限管理、モデルプロバイダーのロードバランシングといった機能が使えます。部門ごとに環境と権限を分けたい、既存のID基盤と連携したい、という要件が出てきた時点が、検討の分かれ目になります。

Dify ではなく Microsoft の純正部品にすべきでしょうか？

どちらが優れているという問題ではなく、運用体制と要件で決まります。試作を速く回したい、特定の1社向けに構築する、運用を担う要員がいる——という状況なら Dify の自己ホストは十分に現実的です。一方、既存のID基盤に認証と権限を寄せたい、運用を増やしたくない、審査でデータ所在や監査の要件が厳しい——という状況では、Microsoft Foundry Agent Service や Copilot Studio のように、いま使っている統制の仕組みにそのまま乗る構成のほうが早く本番に届きます。すでに Microsoft 365 Copilot をお持ちなら、追加費用なしで試せる範囲があるかを先に確認することをおすすめします。

「試作は動いたが、本番化の判断がつかない」という段階のご相談を、弊社は数多くお受けしています。現在の構成を活かす形と、既存の Microsoft 365・Azure に寄せる形の両方を比べたうえでご提案しますので、お問い合わせよりお気軽にご連絡ください。実際に動くものでご確認いただける無料トライアルもご用意しています。

関連サービス・関連コラム

• 関連コラム：企業におけるAIエージェント活用の始め方
• 関連コラム：AIエージェントで社内文書を活かす
• 関連コラム：Microsoft Foundry Agent Service とは
• 関連コラム：Entra Agent ID
• 関連コラム：シャドーAIを止めずに統制する
• 関連サービス：AIエージェント導入支援
• Azure導入支援
• Microsoft 365導入支援

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）・電話対応（AI-Voice）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。