はじめに
Difyは、ノーコードやローコードでAIアプリケーションを構築できる強力なプラットフォームです。チャットボットやワークフロー、RAG（検索拡張生成）などを手軽に実装できるため、多くの企業や開発者に注目されています。しかし、その手軽さゆえに「社内の仕様書やリポジトリをどこまでAIに渡してよいのか」という不安を抱える方も少なくありません。
とくに、機密情報や顧客データを含むコードやドキュメントを扱う場合、情報漏洩のリスクは無視できません。Difyはクラウド版とセルフホスト版でデータの保管場所や送信先が異なり、利用するLLM（大規模言語モデル）によってもリスクの度合いが変わります。
この記事では、Difyに仕様書やリポジトリをアップロードする前に確認すべきポイントを、公式ドキュメントや公開情報をもとに整理します。導入形態ごとの違いや、安全に使うための運用例、よくある疑問にもお答えしますので、自社のポリシーに合った使い方を見極める材料にしてください。
結論：Difyに渡す情報は「公開可能か」「外部LLMに送られるか」で線引きする
Difyに仕様書やコードを渡す際の判断基準は、大きく次の2点に集約されます。
1. その情報は社外に公開できるものか
2. その情報は外部LLM（OpenAIやGoogle Geminiなど）に送信されるか
クラウド版の場合、アップロードしたナレッジや会話ログはDifyのサーバーに保存されます。さらに、RAGで検索されたテキストやプロンプトは、設定したLLMのAPIに送信されます。つまり、社外秘の仕様書をクラウド版にそのままアップロードし、外部LLMを利用すると、情報が社外に出る可能性があるのです。
一方、セルフホスト版（自社サーバーでの運用）では、データは自社環境に留まります。ただし、外部LLMを使う場合は依然としてAPI経由でデータが送信されるため、LLMの選定や契約内容の確認が欠かせません。
したがって、まずは「この情報は社外に出しても問題ないか」を基準に仕分けし、次に「どのLLMを使うか」「データがどこに保存されるか」を踏まえて、渡す情報の範囲を決めることが現実的なアプローチです。
Difyの基本構成と情報の流れを理解する
Difyに情報を渡す前に、Difyがどのようにデータを処理するのか、基本的な構成を把握しておきましょう。
Difyは、主に以下のコンポーネントで構成されます。
- 入力画面（WebApp）：ユーザーが質問を入力するインターフェース
- アプリ設定：プロンプトやワークフロー、ナレッジベースの紐付けなどを定義
- ナレッジベース：アップロードしたドキュメントやデータを格納し、検索可能にする
- LLM接続設定：OpenAI、Google Gemini、ローカルLLMなど、使用するモデルを指定
ユーザーが質問を入力すると、Difyは必要に応じてナレッジベースを検索し、関連するテキストを抽出します。そのテキストとプロンプトを組み合わせてLLMに送信し、生成された回答をユーザーに返します。
この流れの中で、情報が「保存される場所」と「送信される先」を意識することが重要です。
- 保存先：クラウド版ではDifyのサーバー、セルフホスト版では自社サーバー
- 送信先：外部LLMを利用する場合、そのLLMのAPIエンドポイント（OpenAI、Googleなど）
とくに、RAGで検索された社内ナレッジの一部が、そのまま外部LLMに送信される点は見落としがちです。仕様書の一部がプロンプトに埋め込まれて外部に送られる可能性を、常に想定しておく必要があります。
Difyの導入形態とセキュリティの違い
Difyのセキュリティは、導入形態によって大きく変わります。ここでは、代表的な3つの形態を比較します。
| 導入形態 | データの保存先 | 責任の所在 | 主なリスク |
| — | — | — | — |
| クラウド版（Dify Cloud） | Dify社のサーバー（Alibaba Cloud等） | Dify社（ベンダー） | データ保管場所の不透明さ、中国のデータ法制への懸念、外部LLMへの送信 |
| セルフホスト版（コミュニティ版） | 自社サーバー | 自社 | 外部LLMへの送信、セキュリティアップデートの自己管理、コード改変リスク（理論上） |
| エンタープライズ版 | 自社サーバーまたはAzure Marketplace | 自社（Dify社のサポートあり） | 外部LLMへの送信、契約内容による |
クラウド版の注意点
クラウド版は手軽に始められる反面、データがDify社の管理するサーバーに保存されます。Dify社はSOC 2やISO 27001の認証を取得していますが、データの保管場所や暗号化の詳細は公開情報だけでは不透明な部分もあります。また、開発拠点が中国にもあることから、中国のサイバーセキュリティ法やデータセキュリティ法に基づき、政府のデータアクセス要求に応じる可能性が指摘されています。
機密性の高い仕様書や個人情報を扱う場合、クラウド版の利用は慎重に判断すべきです。どうしても利用する必要がある場合は、後述する「安全に使う運用例」を参考に、情報を最小限に留める工夫が求められます。
セルフホスト版の注意点
セルフホスト版は、データを自社環境で管理できるため、クラウド版に比べてデータの直接的な漏洩リスクは低減します。しかし、外部LLMを利用する場合は依然としてデータがAPI経由で送信されるため、LLMプロバイダとの契約で「学習に利用されない」ことを確認する必要があります。
また、セルフホスト版はオープンソースであり、第三者による正式なセキュリティ監査の証拠が限られています。セキュリティアップデートの適用はユーザー自身の責任となるため、定期的なメンテナンスが欠かせません。
Difyに渡す前に伏せたい情報の具体例
実際に仕様書やリポジトリをアップロードする前に、以下のような情報は除外するか、マスキングすることを推奨します。
公開コードと社内コードの違いを明確にする
リポジトリ全体をそのままアップロードするのではなく、公開可能なコードと社内限定のコードを分けましょう。オープンソースのライブラリや一般的なアルゴリズムは比較的安全ですが、自社のビジネスロジックや独自アルゴリズム、顧客情報を含むコードは慎重に扱う必要があります。
除外したいファイルや秘密情報
以下のような情報は、Difyに渡す前に必ず除去してください。
- APIキー、パスワード、トークン：.envファイルや設定ファイルに含まれる認証情報
- 顧客情報、個人情報：氏名、住所、メールアドレス、購買履歴など
- 社外秘の仕様書：未公開の製品仕様、ロードマップ、契約書
- データベース接続情報：ホスト名、ポート番号、クレデンシャル
- 内部システムの構成情報：サーバー構成、ネットワーク図、セキュリティホールになりうる情報
これらの情報は、たとえセルフホスト版であっても、外部LLMに送信される可能性があるため、ナレッジベースには含めないのが原則です。
チーム設定で見るべき項目
Difyには、ユーザーロールや権限管理の機能があります。チームで利用する場合は、以下の設定を確認しましょう。
- ロール管理：通常ロール（アプリの使用のみ）とエディターロール（アプリの作成・編集）を適切に割り当てる
- WebAppの無効化：不要なWebAppを無効にし、公開範囲を制限する
- APIのアクセス制御：APIキーの発行を最小限にし、不要なキーは削除する
- ログの確認：会話ログや操作ログに機密情報が含まれていないか定期的にチェックする
これらの設定は、情報漏洩のリスクを低減するための基本的な対策です。とくに、ログに入力文やメタデータが残る場合があるため、ログの保存期間やアクセス権限も確認しておくと安心です。
安全に使うための運用例
実際にDifyを業務で使う場合の、具体的な運用例をいくつか紹介します。
ケース1：公開情報のみを扱うFAQボット
社外向けのFAQや、公開済みのマニュアルをナレッジベースに登録し、カスタマーサポート用のチャットボットを構築するケースです。この場合、扱う情報はすべて公開可能なものなので、クラウド版・外部LLMの利用も比較的安全です。
ケース2：社内用の仕様書検索ボット（セルフホスト＋ローカルLLM）
社内の仕様書をナレッジベースに登録し、開発者が仕様を検索できるボットを構築するケースです。機密情報を含むため、セルフホスト版で運用し、LLMもローカルで動作するオープンソースモデル（Llamaなど）を使用します。これにより、データが社外に出るリスクを最小限に抑えられます。
ケース3：コードレビュー支援（サニタイズ済みコードのみ）
リポジトリのコードをDifyに読ませて、レビューコメントを生成するケースです。この場合、事前にAPIキーやパスワードを除去したサニタイズ済みのコードのみをアップロードします。また、外部LLMを使う場合は、コードの断片が学習に使われないことを契約で確認するか、ローカルLLMを利用します。
ケース4：個人情報を含むデータの扱い
顧客情報を含むデータを扱う場合は、匿名化や仮名化を施した上で、限定的な分析に利用します。どうしても生データを扱う必要がある場合は、セルフホスト版＋ローカルLLMの構成をとり、アクセス権限を厳格に管理します。
よくある疑問（FAQ）
Q. Difyのクラウド版は安全ですか？
A. Dify社はSOC 2やISO 27001の認証を取得しており、一定のセキュリティ基準を満たしています。しかし、データの保管場所が不透明であることや、中国のデータ法制の影響を受ける可能性があるため、機密情報を扱う場合は注意が必要です。公開情報のみを扱う用途であれば、比較的安全に利用できます。
Q. セルフホスト版なら完全に安全ですか？
A. セルフホスト版はデータを自社で管理できるため、クラウド版に比べてリスクは低減します。しかし、外部LLMを使う場合はデータがAPI経由で送信される点に変わりはありません。また、セキュリティアップデートの適用や脆弱性管理は自己責任となるため、運用体制が重要です。
Q. 外部LLMにデータが学習されることはありますか？
A. OpenAIやGoogleなどのLLMプロバイダは、API経由で送信されたデータを学習に使用しないと明記している場合が多いです。ただし、契約プランや利用規約によって異なるため、必ず最新の公式情報を確認してください。不安な場合は、ローカルLLMの利用も検討しましょう。
Q. リポジトリをアップロードする際、除外すべきファイルの自動チェック方法はありますか？
A. .gitignoreファイルを活用し、機密情報を含むファイルをあらかじめ除外リストに追加しておく方法があります。また、git-secretsやtruffleHogなどのツールを使って、コミット前にAPIキーやパスワードが含まれていないかスキャンすることも有効です。
Q. Difyのログに機密情報が残らないようにするには？
A. Difyの設定でログレベルを調整したり、ログの保存期間を短く設定することが可能です。ただし、ログに機密情報が含まれないようにする根本的な対策としては、入力段階でマスキングするか、そもそも機密情報を入力しない運用を徹底することが重要です。
まとめ：自社のポリシーに合わせた線引きを
Difyに仕様書やリポジトリを渡す際は、「公開可能か」「外部LLMに送られるか」の2軸で判断することが基本です。導入形態によってリスクの度合いが変わるため、クラウド版の手軽さを取るか、セルフホスト版の管理責任を取るかは、扱う情報の機密性と自社のセキュリティポリシーに照らして決めましょう。
また、どんなに安全な構成でも、人的ミスや設定不備による漏洩の可能性はゼロではありません。定期的な監査やログチェック、チーム内でのルール共有を怠らず、安全な運用を心がけてください。
公式ドキュメントや利用規約は随時更新されるため、導入前やアップデート時には必ず最新情報を確認することをおすすめします。
コメント