Difyに仕様書を入れる前に伏せたい情報

はじめに：Difyにコードや仕様書を読ませたいが、どこまで渡してよいか迷う

Difyは、チャットボットやRAG（検索拡張生成）、ワークフロー、エージェントなどをノーコードで構築できるAIアプリ開発基盤です。社内のナレッジベースを読み込ませて問い合わせ対応を自動化したり、設計書を検索させて仕様確認を効率化したりと、さまざまな業務活用が期待されています。

ところが、実際にプロジェクトで使おうとすると「Gitリポジトリのソースコードをまるごと読ませたいが、顧客情報やAPIキーが含まれている」「社内の仕様書をアップロードしたいが、他部署のメンバーに見られないか心配」といった不安が浮かびます。とくに情報漏洩やプライバシーの観点から、どの情報をDifyに渡してよいのか、どの範囲なら安全なのか、判断に迷う方は少なくありません。

本記事では、Difyの公式ドキュメントや公開情報をもとに、社内コードや仕様書をAIに渡す際の線引きの考え方、除外すべき情報の具体例、チーム設定やアクセス制御のポイント、安全な運用例を整理します。導入形態によるリスクの違いや、実際に注意すべきファイルの種類にも触れ、読者の皆さんが自分のユースケースに合った判断を下せるよう、実用的な情報をお届けします。

なお、本記事の内容は公開情報に基づく一般的な指針であり、個別の法務・セキュリティ判断については、必要に応じて社内のセキュリティ担当者や専門家にご相談ください。

Difyの情報の流れを理解する：入力から外部LLM送信までの基本構成

Difyにコードや仕様書を渡す範囲を考える前に、まずはDifyの中で情報がどのように流れるのかを押さえておきましょう。Difyは、ユーザーが入力したテキストやアップロードしたファイルをナレッジベースに格納し、必要に応じて外部の大規模言語モデル（LLM）に送信して応答を生成します。

具体的には、以下のような流れになります。

1. ユーザーがチャット画面やAPI経由で質問を入力する

2. 質問内容に応じて、ナレッジベースから関連する文書やコードの一部が検索される

3. 検索結果とプロンプトが組み合わされ、外部LLM（OpenAIやGoogle Geminiなど）にAPI送信される

4. LLMが生成した回答がユーザーに返される

この流れの中で、情報漏洩のリスクが生じるポイントは主に三つあります。一つは、アップロードしたファイルや会話履歴がDifyのサーバーやクラウド環境に保存されること。二つ目は、ナレッジベースから検索された社内情報が外部LLMに送信されること。三つ目は、ログやメタデータに入力内容が残る可能性です。

したがって、「どこまで渡してよいか」を判断するには、単に「機密情報かどうか」だけでなく、「その情報がどの経路を通るのか」「誰がアクセスできるのか」をセットで考える必要があります。

Difyの導入形態とセキュリティ責任の分界点

Difyには主に三つの提供形態があります。クラウド版（Dify Cloud）、セルフホスト版（Community Edition）、エンタープライズ版（Enterprise）です。それぞれでデータの保存場所やセキュリティ対策の責任主体が異なり、コードや仕様書を渡す際のリスク評価も変わってきます。

クラウド版（SaaS）の特徴と注意点

クラウド版は、Dify社が管理するサーバー上で動作し、ユーザーはアカウントを作成するだけですぐに利用を開始できます。SOC 2やISO 27001といったセキュリティ認証の取得が進められており、一定の統制は期待できます。しかし、データの保存先や暗号化ポリシーの詳細が公開情報だけでは不透明な部分もあり、機密性の高いコードや個人情報を含むファイルをアップロードする際には慎重な判断が求められます。

クラウド版では、チャット内容やナレッジベースのデータがベンダーのクラウド環境に保存されます。また、外部LLMを利用する場合、API送信時にプロンプトや検索結果がモデル提供元のサーバーを経由します。このため、社外秘の仕様書や顧客データを扱う場合は、情報の流れを事前に確認し、必要に応じてデータの匿名化やマスキングを検討する必要があります。

セルフホスト版（Community Edition）の特徴と注意点

セルフホスト版は、自社のサーバーやプライベートクラウド上にDifyをデプロイして運用する形態です。データは自社の管理下に置かれ、外部への送信も自社で制御できます。ローカルLLM（自社内で動作するモデル）と組み合わせれば、機密情報を社外に出さずにAI機能を利用することも可能です。

ただし、セルフホスト版ではセキュリティ設定やパッチ適用、ネットワーク分離などの運用責任を自社で負うことになります。設定ミスや権限管理の不備があると、かえって情報漏洩のリスクを高める可能性もあるため、インフラやセキュリティに詳しい担当者の関与が欠かせません。

エンタープライズ版の特徴と注意点

エンタープライズ版は、大企業向けにSSO（シングルサインオン）や包括的な監査ログ、きめ細かなアクセス制御などの追加機能が提供されます。セキュリティ要件の厳しい組織でも導入しやすいよう設計されていますが、詳細な機能や提供条件は公式に確認が必要です。

導入形態ごとの比較表

| 項目 | クラウド版 | セルフホスト版 | エンタープライズ版 |

|——|————|—————-|——————-|

| データ保存先 | ベンダーのクラウド環境 | 自社サーバー | 要確認（自社または専用環境） |

| セキュリティ責任 | ベンダー側に一部委託 | 自社で全責任 | ベンダーと自社の分担（要確認） |

| 外部LLMへの送信制御 | 利用するLLMに依存 | 自社で制御可能（ローカルLLMも選択可） | 要確認 |

| 認証・アクセス制御 | 標準機能（ロール管理あり） | 自社で設定可能 | エンタープライズ向け機能（SSOなど） |

| 監査ログ | 30日間のログ制限あり（プランによる） | 自社で管理可能 | 包括的な監査ログ（要確認） |

| 導入の容易さ | 高い（アカウント登録のみ） | 中程度（サーバー構築が必要） | 要確認 |

表の内容は公開情報に基づく概要であり、最新の仕様やプランによる差異は公式ドキュメントで必ず確認してください。

コードや仕様書をDifyに渡す前に分けたい情報の線引き

実際にリポジトリや仕様書をDifyに読み込ませる際、すべてのファイルを無造作にアップロードするのは避けるべきです。ここでは、公開しても問題ない情報と、伏せるべき情報を分けるための考え方を示します。

公開コードと社内コードの違いを意識する

オープンソースソフトウェアのコードや、一般公開されているAPIドキュメントなどは、比較的リスクが低いといえます。一方、自社の製品コード、独自アルゴリズム、未公開の設計書、顧客向けの提案資料などは、社外秘として扱うべき情報です。

Difyに渡す際には、まず「この情報が社外に出た場合、どの程度の事業影響があるか」を評価します。影響が大きいものは、そもそもクラウド版のナレッジベースにアップロードしない、あるいはセルフホスト版でローカルLLMのみを使うといった判断が必要です。

除外したいファイルや秘密情報の具体例

以下のような情報が含まれるファイルは、Difyに渡す前に除外するか、マスキング処理を施すことを推奨します。

• 認証情報：APIキー、パスワード、アクセストークン、秘密鍵

• 個人情報：顧客名、住所、電話番号、メールアドレス、購買履歴

• 構成管理の機密情報：サーバーのIPアドレス、内部ホスト名、ネットワーク構成図

• 財務情報：売上データ、コスト構造、予算計画

• 契約情報：取引先との契約書、見積書、ライセンス証書

• セキュリティ脆弱性につながる情報：未パッチのバージョン情報、内部監査の指摘事項

コードリポジトリでは、`.env` ファイルや `credentials.json` といった設定ファイルがうっかり含まれがちです。仕様書では、表紙やフッターに社外秘マークが付いているもの、特定の顧客名が記載された要件定義書などが該当します。

マスキングや匿名化の実践

どうしてもドキュメントの内容をナレッジベースに含めたい場合は、事前に個人情報や機密情報をマスキングする方法があります。具体的には、正規表現を用いてメールアドレスや電話番号を検出し、「[個人情報]」などのプレースホルダーに置換するスクリプトを用意する、あるいはDifyの外部でデータ加工パイプラインを組むといった工夫が考えられます。

ただし、マスキングしたとしても、文脈から個人や企業が特定されるリスクは残るため、完全な匿名化は難しいことを理解しておく必要があります。

チーム設定とアクセス制御で見るべき項目

Difyには、ユーザーを招待して共同作業するためのチーム機能やロール管理が備わっています。コードや仕様書を共有する範囲を絞りたい場合、これらの設定が重要な役割を果たします。

ロール管理の基本と権限の考え方

Difyでは、通常ロール（アプリケーションの使用のみ許可）とエディターロール（アプリケーションの作成・編集も許可）が用意されています。ユーザーを招待する際に適切なロールを選択することで、ナレッジベースへのアクセスやアプリ設定の変更を制限できます。

たとえば、仕様書を格納したナレッジベースを特定のプロジェクトメンバーだけが検索できるようにしたい場合、そのメンバーにはエディターロールを付与し、他のメンバーは通常ロールにとどめる、あるいは別のワークスペースに分離するといった運用が考えられます。

WebAppの公開設定とアクセス制限

Difyで作成したアプリは、WebAppとして公開することができますが、デフォルトではURLを知っていれば誰でもアクセスできてしまう場合があります。社内情報を扱うアプリでは、WebAppを無効化するか、NginxなどによるBasic認証やIP制限を追加で実装することが推奨されます。

セルフホスト版であれば、環境変数を利用した認証付きチャットボットの構築も可能です。クラウド版の場合は、提供されているアクセス制御の範囲を確認し、不足があれば追加の対策を講じる必要があります。

ナレッジベースの分割と共有範囲

一つのナレッジベースにすべての情報を詰め込むのではなく、「公開可能な一般情報」「プロジェクト限りの内部仕様」「機密性の高い設計書」といった具合に分割し、アプリごとに参照するナレッジベースを変える方法も有効です。これにより、誤って機密情報が公開されるリスクを低減できます。

安全に使うための運用例と確認ポイント

ここでは、実際の業務シーンを想定し、どのようにDifyを安全に運用できるか、いくつかのパターンを紹介します。

ケース1：公開APIドキュメントのQ&Aボット

公開されているAPIリファレンスやオープンソースのドキュメントをナレッジベースに読み込ませ、開発者向けのQ&Aボットを構築するケースです。情報はすでに公開されているため、クラウド版でもリスクは低く、外部LLMを利用しても問題になりにくいでしょう。

ケース2：社内の設計書検索アシスタント

自社の基本設計書や画面仕様書をナレッジベースに登録し、社内のエンジニアが必要な情報を素早く引き出せるようにするケースです。この場合、クラウド版を利用する際は、設計書に個人情報や取引先名が含まれていないかを事前にチェックし、必要に応じてマスキングします。また、アプリのアクセス制限をかけ、社内ネットワークからのみ利用可能にすることが望ましいです。

セルフホスト版であれば、ローカルLLMと組み合わせることで、設計書の内容を社外に一切出さずにAI検索を実現できます。ただし、ローカルLLMの精度や応答速度はモデルに依存するため、事前に検証が必要です。

ケース3：ソースコードのバグ分析アシスタント

Gitリポジトリのソースコードをナレッジベースに登録し、バグの原因調査やコードレビューの補助に使うケースです。ソースコードには、コメントにTODOやFIXMEが書かれているだけでなく、ハードコードされたテスト用の認証情報や、内部システムのURLが含まれていることがあります。

利用前には、`git-secrets` や `truffleHog` といったツールでリポジトリをスキャンし、機密情報が含まれていないかを確認する工程を組み込みましょう。また、コード全体を渡すのではなく、解析対象のモジュールやファイルを限定することも有効です。

共通の確認事項

• 利用規約とプライバシーポリシーの確認：クラウド版を利用する場合は、Difyの利用規約やプライバシーポリシーを必ず読み、データの取り扱いや第三者提供の有無を把握します。

• 外部LLMのデータ利用ポリシー：OpenAIやGoogle Geminiなど、利用する外部LLMのAPIが、送信データをモデルの学習に利用しないかどうかを確認します。多くのAPIでは、業務用プランで学習利用をオプトアウトできる場合があります。

• ログの取り扱い：Difyのログには、ユーザーの入力内容やナレッジベースの検索結果が含まれる可能性があります。ログの保存期間やアクセス権限を確認し、必要に応じてログ出力を制限する設定を検討します。

情報漏洩リスクを最小化するための具体的な手順

ここでは、コードや仕様書をDifyに渡す前後に実践すべき手順を、チェックリスト形式で整理します。

事前チェックリスト

1. 渡す情報の分類：公開情報、社内限定情報、極秘情報に分類する

2. 機密情報のスキャン：ファイル内にAPIキーやパスワード、個人情報が含まれていないか自動ツールで検査する

3. マスキング処理：必要な情報だけを残し、機密部分をプレースホルダーに置換する

4. 導入形態の選択：情報の機密レベルに応じて、クラウド版かセルフホスト版かを決定する

5. アクセス制御の設計：誰がナレッジベースやアプリにアクセスできるか、ロールと権限を定義する

運用中のチェックリスト

1. 定期的なログ監視：不正アクセスや異常な操作が行われていないか、定期的にログを確認する

2. ナレッジベースの更新管理：新しいファイルを追加する際も、同様の機密情報チェックを実施する

3. ユーザー権限の棚卸し：プロジェクトメンバーの異動や退職に合わせて、アクセス権限を見直す

4. LLMの利用ポリシー変更の追跡：外部LLMのAPIがポリシーを変更していないか、定期的に確認する

掲示板や導入事例で見かける悩みとその対処

DifyのコミュニティやSNS上では、実際に導入を検討するユーザーからさまざまな不安の声が上がっています。ここでは代表的な悩みと、それに対する考え方を紹介します。

「中国のTencentや政府との関係が心配」

Difyの提供元であるLangGenius社は、米国企業であり、中国のTencentや中国政府との関係を否定する声明を出しています。また、データセキュリティは米国の法律とデータポリシーに準拠しており、SOC2やISO27001の認証取得も進められています。

とはいえ、オープンソースプロジェクトの性質上、コントリビューターやフォークの管理までは完全に把握できないため、自社のセキュリティポリシーに照らして許容できるかどうかを判断する必要があります。不安が拭えない場合は、セルフホスト版で自社管理下に置くという選択肢もあります。

「セルフホスト版の運用が難しそう」

セルフホスト版は自由度が高い反面、DockerやKubernetesなどのコンテナ技術、ネットワーク設定、SSL証明書の管理など、相応のインフラ知識が求められます。社内に専任のエンジニアがいない場合は、導入支援サービスを利用する、あるいはまずはクラウド版で小規模に試しながら知見を貯めるという段階的なアプローチも有効です。

「ログに機密情報が残るのが怖い」

Difyのログ機能は、アプリの改善や分析に役立つ一方で、入力内容がそのまま記録される可能性があります。クラウド版ではログの保存期間が30日間に制限されるプランもありますが、それ以前にログ出力自体を制限する設定や、ログを外部に送信しない構成を検討する必要があります。セルフホスト版であれば、ログの出力先や保存ポリシーを自社で細かく制御できます。

向いている使い方・向いていない使い方

Difyにコードや仕様書を渡すのが向いているケース

• 公開情報や社内でも広く共有されているドキュメントの検索性を高めたい

• セルフホスト版とローカルLLMを組み合わせ、完全にクローズドな環境でAIを活用したい

• 機密情報を含まない、あるいはマスキング済みのデータで社内ナレッジベースを構築したい

• アクセス制御を厳格に設定し、限られたメンバーだけで利用するアプリを作りたい

Difyにコードや仕様書を渡すのが向いていないケース

• 個人情報や取引先の機密情報が大量に含まれ、マスキングが現実的でない

• クラウド版しか利用できず、かつ情報漏洩が事業継続に深刻な影響を与える

• 社内にセキュリティレビューや運用を担当できる人材がおらず、設定ミスのリスクが高い

• 一度渡した情報を確実に削除できるかどうかが不透明で、社内ポリシー上許容できない

買う前・導入前に確認すべきこと（Difyの料金プランや機能の比較）

Difyの導入を検討する際は、セキュリティ面だけでなく、料金プランや機能の違いも比較しておく必要があります。以下に、確認すべき主なポイントを挙げます。

• 無料枠の範囲：クラウド版には無料枠があり、小規模な検証には十分ですが、ナレッジベースの容量やAPIコール数に制限があります。

• 有料プランの機能差：チーム機能、SSO、監査ログの保存期間、サポートレベルなどがプランによって異なります。

• セルフホスト版のライセンス：Community Editionはオープンソースで無料ですが、エンタープライズ向けの機能が必要な場合は有料ライセンスが必要になることがあります。

• 外部LLMの利用料：Dify自体の料金とは別に、OpenAIやGoogle GeminiなどのAPI利用料が発生します。ローカルLLMを使えばこのコストは抑えられますが、モデルのホスティング費用がかかります。

最新の料金体系やプラン内容は、Difyの公式サイトやドキュメントで必ず確認してください。

FAQ：コードや仕様書をDifyに渡す際によくある質問

Q. クラウド版のDifyにソースコードをアップロードしても大丈夫ですか？

A. ソースコードの内容によります。公開リポジトリのコードや、機密情報を含まないモジュールであればリスクは低いですが、APIキーや顧客情報が含まれる場合は、事前にマスキングするか、セルフホスト版の利用を検討してください。

Q. セルフホスト版なら完全に安全ですか？

A. セルフホスト版はデータを自社で管理できるため、外部への情報漏洩リスクは低減できますが、設定ミスや脆弱性対応の遅れによって内部からの漏洩や不正アクセスのリスクは残ります。適切な運用体制が前提となります。

Q. Difyに渡したデータはAIの学習に使われますか？

A. Dify自体はAIモデルを学習させる機能を持っていませんが、外部LLMを利用する場合、そのLLMの提供元がAPI経由で送信されたデータを学習に利用する可能性があります。利用するLLMのデータ利用ポリシーを確認し、必要に応じて学習利用をオプトアウトできるプランを選択してください。

Q. アップロードしたファイルを後から削除できますか？

A. Difyのナレッジベースからドキュメントを削除することは可能ですが、バックアップやログに残っている可能性は否定できません。完全な削除を保証する必要がある場合は、公式のデータ保持ポリシーを確認し、必要に応じてセルフホスト版で自社管理することを推奨します。

Q. チームメンバーにナレッジベースの一部だけを見せたいのですが可能ですか？

A. Difyの標準機能では、ナレッジベース単位でのアクセス制御が可能です。したがって、見せたい情報ごとにナレッジベースを分割し、メンバーに付与するロールや招待設定を調整することで、部分的なアクセス制限を実現できます。

まとめ：Difyに仕様書やコードを安全に渡すための判断基準

Difyにコードや仕様書を渡す範囲で迷ったときは、次の3つのステップで判断することをおすすめします。

1. 情報の分類：渡そうとしている情報が公開可能か、社内限定か、極秘かを明確にする

2. 経路の確認：その情報がDifyのクラウド環境に保存されるのか、外部LLMに送信されるのか、誰がアクセスできるのかを把握する

3. 導入形態の選択：情報の機密レベルと自社のセキュリティポリシーに照らして、クラウド版、セルフホスト版、エンタープライズ版のいずれが適切かを判断する

どんなに便利なツールでも、情報の取り扱いを誤れば大きな損失につながりかねません。しかし、必要以上に怖がって活用の機会を逃すのももったいない話です。Difyの仕組みを正しく理解し、適切な線引きと運用ルールを設けることで、安全かつ効果的にAIの力を業務に取り入れることができるでしょう。

本記事で紹介したチェックリストやケーススタディを参考に、まずは小さな範囲から試し、フィードバックを得ながら徐々に適用範囲を広げていくことをお勧めします。最終的な判断にあたっては、必ず公式ドキュメントや利用規約を確認し、必要に応じて社内のセキュリティ専門家や法務担当者に相談してください。