Difyは、チャットボットやAIエージェントなどのAIアプリを開発・運用できるプラットフォームです。
社内データを参照した回答生成や、外部サービスと連携した業務の自動化に活用できます。
まずは、セキュリティを検討する前提として、企業利用で押さえておきたいDifyの特徴をご紹介します。
Difyでは、画面上で処理のブロックをつなぎ、チャットボットやワークフローを組み立てられます。現場の担当者が、業務に合わせたAIアプリを開発しやすい点が特徴です。ただし、複雑な処理や外部連携では、技術的な知識が必要になる場合もあります。
Difyの基本的な使い方やAIアプリの作成手順は、以下の関連記事をご覧ください。
【関連記事】Difyの使い方を解説|何ができるか・特徴・AIアプリ開発の手順まで
Difyには、社内文書などを検索し、その内容をもとに回答を生成するRAGの機能があります。これは、AIモデル自体を学習させる仕組みとは異なります。
また、用途に応じたAIモデルの選択や、外部サービスとの連携も可能です。
Difyの導入形態は、提供元であるDify.aiが管理する環境を利用する「クラウド版」と、自社で用意したサーバーやクラウド環境に構築する「セルフホスト版」の大きく2つに分かれます。
企業のセキュリティポリシーや管理体制に合わせて、適切な環境を選択することが可能です。
Difyの基本機能や、具体的な活用例についてさらに知りたい方は、以下の関連記事もご覧ください。
【関連記事】Difyとは?GPTsとの違いやRAG構築、実務での活用メリットを解説
Difyは社内データや外部サービスと連携して利用するため、導入時にはデータの取り扱いや管理範囲を確認することが重要です。
次に、セキュリティを判断するための基本を確認しましょう。
Difyでは、データの暗号化やアクセス制限、第三者による認証・監査への対応など、企業利用を支えるセキュリティ対策に取り組んでいます。
導入する際は、こうした対策を踏まえ、利用環境や接続先、自社の運用がセキュリティ要件に合うかを判断することが重要です。
本章では、Difyが実施するセキュリティ対策と、入力データの取り扱いについて解説します。
Difyは、ISO 27001:2022の認証やSOC 2 Type IIの監査に関する情報を公表しています。
ISO 27001は組織の情報セキュリティ管理の仕組みに関する国際規格で、SOC 2 Type IIは管理策が一定期間にわたって適切に運用されているかを第三者が評価する監査報告です。
また、セキュリティへの取り組みを公開する「Trust Center(トラストセンター)」を設置しています。
情報を守り、サービスを安定して運用するために、次のような対策を行っています。
これらは、提供元のセキュリティ体制を判断する材料になります。
ただし、認証や監査報告には対象範囲があり、自社で構築した環境や独自のアプリ設定まで保証するものではありません。
セルフホスト環境の保護や利用者の権限設定などは、別途確認が必要です。
※出典:Dify公式ブログ「Dify Achieves SOC 2, ISO 27001 & GDPR Compliance for the Second Year Running」、Dify 公式Trust Center
Difyのセキュリティは、次の3つに分けると整理しやすくなります。
たとえば、自社のサーバーにDifyを構築しても、外部のAIモデルを利用して回答を生成する場合は、質問や回答に必要な文書の一部などが外部へ送信されます。
プラグインや外部APIとの連携でも、処理に必要な情報が連携先に渡る場合があります。
「Difyをどこに置くか」と「データをどこへ送るか」は別の確認事項です。
保存先と送信先の両方を把握することが、導入判断の出発点になります。
Difyの提供元であるLangGeniusは、AIとのやり取りのデータをモデルの学習に利用しない方針を公表しています。
ただし、自社で接続するAIモデルやAPIにおけるデータの取り扱いは、接続先の契約・設定条件によって異なります。
また、学習に使われなくても、データが保存される場合があります。接続先だけでなく、Dify側に残る文書やログについても、保存先・保持期間・削除条件を確認しましょう。
セキュリティの確認ポイントを押さえたら、導入形態によって管理範囲や運用負担がどう変わるかを確認しましょう。
Difyの利用環境は、大きくクラウド版とセルフホスト版に分かれます。セルフホストには、Community版や、企業向けの管理機能・サポートを備えるEnterprise版などがあります。
自社のセキュリティ要件に合う導入形態を選ぶには、機能だけでなく、誰が管理・保守を担うかにも注目することが重要です。
本章では、導入形態ごとの違いを比較表で整理したうえで、自社に合う環境の選び方を解説します。
| 比較項目 | Dify Cloud (クラウド版) |
セルフホストのCommunity版 |
セルフホストのEnterprise版 |
| 稼働環境・データの配置 | 提供元が管理するクラウド環境 | 利用企業が用意・管理する環境 | 利用企業が用意・管理する環境 |
| 提供元の主な対応 | サービス基盤の運用・保守 | ソフトウェアや修正情報の公開。導入先の運用管理は利用企業側 | ソフトウェアの提供と契約に基づくサポート |
| 利用企業側の主な対応 | 入力情報、アプリ、利用者、公開範囲、接続先の管理 | 左記に加え、インフラ・更新・障害対応などの体制確保 | Community版の対応に加え、契約上の役割分担に応じたインフラ・保守体制の確保 |
| 権限管理・監査機能 | 利用できる機能はプランによって異なる | 標準のメンバー・ナレッジ管理機能などを要件と照合 | SSO、ロールに応じた権限管理、監査ログなどを要件と照合 |
| 更新・バックアップ・復旧 | 提供条件と対応範囲を確認 | 利用企業側で実施体制を確保 | 提供元・委託先との契約に基づき役割を確認 |
| 自社に必要な体制 | アプリと利用者を管理する体制 | インフラを含めた構築・運用体制 | 管理機能を運用し、保守を調整する体制 |
| 適した要件・状況 | インフラ管理の負担を抑えて利用したい | 自社環境で柔軟に構築・運用したい | 自社環境と企業向けの管理機能・サポートを組み合わせたい |
| 主な確認事項 | データの取り扱いとプランごとの機能・制限 | 必要な機能を満たせるか、継続的に保守できるか | 必要な機能とサポート範囲、費用、責任分担 |
※機能やサポート範囲は、バージョン・プラン・契約によって異なります。導入時には最新の公式情報と契約条件を確認してください。
また、表のデータ配置は主にDify側の環境を示しており、外部AIモデルや連携サービスへの送信先は別途確認が必要です。
表中のSSOは、社内の認証基盤と連携してログインを管理する仕組みです。
監査ログは、誰がいつどのような操作をしたかを確認するための記録です。
自社のセキュリティ審査で求められる認証方式や記録の対象に対応しているかを確認しましょう。
クラウド版は、利用企業がDifyの稼働基盤を一から構築・保守する負担を抑えられます。
一方、入力する情報、アプリの公開範囲、利用者の権限、接続するAIモデルや外部サービスの選択は、利用企業側で管理する必要があります。インフラ管理を任せられることと、社内の情報管理が不要になることは異なります。
セルフホスト版には、Community版とEnterprise版があります。Community版は、ソースコードが公開されているOSS版(オープンソース版)とも呼ばれ、ライセンス条件の範囲内で、自社のサーバーやクラウド環境に導入・カスタマイズできます。
ソフトウェアは無料で利用できますが、サーバーなどのインフラ費用や構築・保守の負担は別途発生します。
Community版でも、ワークフローやRAGを利用したAIアプリを構築できます。
Enterprise版では、こうした開発機能に加えて、SSOによる認証連携、複数ワークスペースの管理、監査ログなど、組織で利用するための管理機能が用意されています。
たとえば、社内の認証基盤と連携してログインを管理したい場合や、部署ごとに作業環境を分けたい場合は、必要な機能への対応を確認するとよいでしょう。
また、機能だけでなく、技術サポートや障害時の対応条件も選定のポイントです。
Enterprise版であっても、自社環境の管理や更新作業をすべて任せられるとは限らないため、契約に含まれる支援と、自社で担う作業を確認しましょう。
自社管理環境へのデータ配置が必須であれば、セルフホストが有力な選択肢になります。
一方、必要な管理機能や契約条件を満たすクラウドサービスを利用できる場合は、運用負担を抑えられる可能性があります。
判断の際は、扱うデータの機密性に加え、必要な権限管理、許容できる送信先、更新・保守を継続できる体制を整理してください。
自社の要件を満たし、無理なく管理を続けられる環境を選ぶことが重要です。
企業利用では、アプリの設計や設定、運用ルールの不備によって問題が起こる可能性があります。
本章では、情報漏洩や意図しない操作につながる主なリスクを、想定例とともにご紹介します。
想定例:人事部門向けのアプリを全社員が利用できる状態にしており、個人の評価情報を含む回答が出力された。
アプリの公開範囲が広すぎると、本来情報を見せるべきではない利用者がアクセスできる場合があります。
また、一般社員向けの文書と経営層向けの機密文書を、参照範囲を分けずに登録すると、回答を通じて機密情報が伝わる可能性があります。
アプリへのアクセスと、回答に利用する情報の範囲の両方を確認する必要があります。
想定例:APIキーを記載した設定ファイルを社外へ共有し、第三者に不正利用された。
APIキーが漏洩すると、そのキーに与えられた権限の範囲で、不正なアクセスや想定外の利用料金が発生する可能性があります。
また、認証情報の漏洩とは別に、外部サービスへ何が送られるかを把握していないこともリスクになります。
便利なプラグインを追加した結果、顧客情報や社内文書が、社内で承認していないサービスへ送信されるケースなどが考えられます。
想定例:AIが参照したWebページに不正な指示が含まれており、本来の業務とは異なる回答や操作を行った。
プロンプトインジェクションとは、AIへの入力や参照データに不正な指示を含め、意図しない動作を引き起こそうとする攻撃です。利用者の入力だけでなく、社内文書や外部のWebページが入口になる場合もあります。
AIにメール送信やデータ更新などの権限を与えていると、影響が回答内容にとどまらない可能性があります。外部ツールにどのような操作を許可するかも、リスクに関わります。
リスクを低減するには、システムの設定と、利用企業側の運用ルールを組み合わせることが必要です。
本章では、入力情報や権限の管理から、重要な操作への人の承認、更新・教育の体制づくりまで、安全な運用のために取り組みたい対策を解説します。
まず、対象業務ごとに扱う情報と利用目的、データの送信先を整理します。
個人情報、顧客から預かった資料、社外秘文書などは、自社の情報管理規程や顧客との契約条件に基づいて取り扱いを判断してください。必要に応じて、入力対象を限定したり、不要な個人情報を除いたりする方法を検討します。
AIモデルやプラグインも、利用者が自由に追加するのではなく、確認・承認の手順を決めておくと管理しやすくなります。
アプリを作成・管理する人と、公開されたアプリを利用する人を区別し、それぞれに必要な権限だけを付与します。
ナレッジを管理できるメンバーの設定と、公開アプリの利用者が回答を通じて参照できる情報の範囲も、別々に確認してください。必要に応じて、アプリやナレッジを分け、認証・認可の仕組みを設計します。
APIキーは、プロンプトや共有資料に直接記載せず、適切な認証情報の保管機能などで管理します。閲覧できる人を限定し、漏洩が疑われる場合の失効・再発行や、不要になったキーの削除手順も定めましょう。
モデレーションやガードレールを使い、入力・参照データ・出力内容を確認することで、不適切な回答や不正な指示によるリスクの低減を図れます。ただし、これらの対策だけで、すべての攻撃を防げるわけではありません。
メール送信やデータ更新など、影響の大きい操作では、AIや連携先に与える権限を制限し、実行前に人が確認・承認する流れを設けます。
利用環境や連携先によって実装方法が変わるため、必要な機能と実現方法を情報システム部門や支援会社と確認してください。
ログは、問題発生時の調査に役立つ一方、機密情報の保存先にもなります。
誰が設定変更や操作を行ったかを記録するログと、質問・回答・処理内容を含む会話・実行ログでは、保存目的や閲覧すべき担当者が異なります。それぞれについて、取得できる内容、閲覧権限、保持期間を確認してください。
登録文書についても、情報が古くなった場合や利用目的がなくなった場合の更新・削除手順を決めておきます。利用プランや構成によって設定できる範囲が異なるため、自社のルールに則って実現できるか確認することが必要です。
セルフホストでは、Difyだけでなく、OSや関連ソフトウェアも管理対象になります。脆弱性情報を確認する人、更新の影響を判断する人、作業を実施する人を明確にしましょう。
バックアップは取得するだけでなく、必要なデータを復元できるかを確認します。クラウドサービスや外部委託を利用する場合も、バックアップ・復旧の対象と対応範囲を確認してください。
あわせて、異動・退職時の権限見直し、利用者へのルール周知、問題発生時の連絡先と対応手順を整えます。技術的な対策を継続して機能させるためには、運用と教育の両方が欠かせません。
ここまで解説したデータの取り扱いや運用上の対策を、自社の導入計画に照らして確認しましょう。
本章では、導入前の検討に役立つチェックリストをご紹介します。
Dify本体だけでなく、接続するAIモデルや外部サービス、自社の設定・運用も含めて、情報システム部門やサービス提供元と確認し、自社の要件と対応方針を整理してください。
| 確認欄 |
確認項目 |
確認する内容・資料 |
自社の対応方針 |
確認担当 |
| □ | 対象業務と利用目的 |
どの業務で、何を目的に利用するか | ||
| □ | データの種類と機密性 | 入力・登録する情報と、社内規程・顧客契約との整合性 | ||
| □ | データの流れ | Dify、AIモデル、外部サービスへの送信内容と送信先 | ||
| □ | 学習利用の有無 | 接続先の契約・設定条件と、学習利用に関する例外 | ||
| □ | 保存・削除の条件 | 文書・ログの保存先、保持期間、削除方法 | ||
| □ | データの保護 | 通信時・保存時の保護方法と自社要件への適合 | ||
| □ | 利用者の権限 | 管理者・作成者・利用者の操作範囲と情報の参照範囲 | ||
| □ | アプリの公開範囲 | 意図した対象者だけが利用できる仕組み | ||
| □ | APIキーと外部連携 | 認証情報の保管・失効と、連携先の承認ルール | ||
| □ | 更新・復旧の体制 | 更新、バックアップ、復旧を担う人・提供元・委託先 | ||
| □ | 利用ルールと教育 | ルールの策定・周知・見直しを行う担当 | ||
| □ | 問題発生時の対応 | 連絡先、初動対応、調査・復旧の役割分担と、契約上のサポート範囲・対応時間 |
※本リストは、導入時の検討項目を整理するための参考例であり、必要な確認事項をすべて網羅するものではありません。
導入にあたっては、自社のセキュリティ基準および最新の製品情報・契約条件と照らし合わせて判断してください。
未確認の項目と、自社だけでは対応が難しい項目を分けると、情報システム部門や外部の支援会社に相談すべき内容が明確になります。
チェックリストで必要な対応を整理すると、環境整備や保守など、自社だけでは継続的に担うことが難しい項目が見つかる場合があります。
本章では、自社と外部の役割分担を整理する考え方や、外部サービス・支援を選ぶ際のポイントをご紹介します。
環境構築、更新・保守、権限設定、アプリ管理、利用者教育などの作業を洗い出し、自社で対応できる範囲を確認します。
たとえば、インフラ保守を外部に任せ、対象業務や入力情報の判断は自社で行うといった役割分担が考えられます。
運用ルールの作成や教育も支援を受けられる場合がありますが、自社として何を認めるかという判断や承認は必要です。
委託先を含めて、作業と責任の所在を明確にすることが大切です。
外部サービスや導入支援を比較する際は、次の点を確認することをおすすめします。
セキュリティ機能の多さだけでなく、導入後に自社が担う作業まで確認することで、運用負担の見通しを立てやすくなります。
Difyを活用したいものの、環境整備や運用の負担に課題をお持ちの企業に向けて、ヒューマンリソシアでは「つなぎAI Powered by Dify」をご案内しています。
つなぎAIは、Difyを基盤に、社内データや外部アプリ、生成AIを連携させ、お客さまの業務に合わせたAIアプリを構築・活用するためのサービスです。
企業での利用を支える、次のような特徴を備えています。
導入にあたっては、お客さまのセキュリティ要件や利用予定のAIモデル・外部連携を伺い、データの取り扱いやログ保持などの条件、対応可能な範囲を確認しながら、導入方法をご案内します。
また、ヒューマンリソシアでは、つなぎAIの活用・定着を支える研修や技術支援もご用意しています。業務整理からアプリ開発、現場での活用促進まで、お客さまの課題に寄り添って支援します。サービス本体と各種支援の提供範囲・費用についても、お気軽にご相談ください。
Difyのセキュリティや社内運用にお悩みの担当者の方へ
自社の要件に合う環境を選びたい、インフラ管理の負担を抑えたい、導入後の活用まで伴走してほしいといったお悩みは、ヒューマンリソシアにご相談ください。お客さまの課題に寄り添い、セキュリティ要件や運用体制に合わせた導入方法と支援をご提案します。
運用負担を抑えてDifyを活用する選択肢として、当社で取り扱う「つなぎAI Powered by Dify」もご案内しています。
A:接続するAIモデルやAPIの契約・設定条件によって異なります。
Difyの提供元は、AIとのやり取りのデータをモデルの学習に利用しない方針を公表していますが、接続先でも同じ条件が適用されるとは限りません。また、学習に利用されない場合でもデータが保存されることがあるため、保存先や保持期間も確認が必要です。
A:Difyは、ISO 27001:2022の認証やSOC 2 Type IIの監査に関する情報を公表しています。
ただし、認証・監査には対象範囲があり、自社で構築した環境やAIアプリの安全性まで保証するものではありません。
導入時は公式情報で最新の状況と対象範囲を確認しましょう。
A:扱えるかどうかは、情報の種類、自社規程や顧客との契約、Dify Cloudと接続先の利用条件によって異なります。
保存先・送信先、保持期間、削除方法、アクセス制御などを確認し、情報システム部門と利用可否を判断する必要があります。
A:RAGで社内文書を参照する場合は、アプリの利用者と、回答に利用できる情報の範囲を適切に管理する必要があります。
一般社員向けの資料と機密文書を区別せずに登録すると、本来閲覧できない情報が回答に含まれる可能性があるため、参照範囲や権限設定を確認しましょう。
A:プラグインによっては、外部サービスとの通信やデータの送信が発生します。
利用前に、連携先の信頼性や送信する情報、必要な権限を確認することが重要です。
また、利用できるプラグインを社内で承認したものに限定するなど、管理ルールを設けるとよいでしょう。
Difyを企業で安全に利用するには、認証や機能だけでなく、データの取り扱いと自社の運用体制を合わせて確認することが重要です。
本記事で解説したポイントは以下の通りです。
セルフホスト版は、自社要件に合わせて管理しやすい一方、継続的な保守が必要になります。
クラウドサービスを利用する場合も、入力情報や公開範囲などの管理は欠かせません。
自社で担う範囲を整理し、環境整備や運用の負担に課題がある場合は、外部サービスや支援を活用する方法もあります。
ヒューマンリソシアでは、「デジタルツール×教育×活用支援」を強みに、お客さま一社一社の課題に寄り添った伴走支援を行っています。
「つなぎAI Powered by Dify」などのサービス選定から、導入・開発支援、社員研修、導入後の運用サポートまで、お客さまの状況に合わせて必要な支援をご提案します。
セキュリティ要件や社内の運用体制を踏まえ、管理の負担を抑えながらDifyを活用したい担当者の方は、お気軽にご相談ください。
本コラム内容について
各コラムの内容は、執筆時点での情報を元にしています。
製品バージョンアップなどにより、最新ではない場合がありますので、最新の情報は、各社の公式Webサイトなどを参考にすることをおすすめいたします。
各コラムの内容は、利用することによって生じたあらゆる不利益または損害に対して、
弊社では一切責任を負いかねます。
ひとつの参考としていただき、利用いただく際は、各社のルール・状況等に則りご活用いただけますと
幸いです。
※「つなぎAI」は、日本電子計算株式会社の登録商標です。
※「Dify」は、米国LangGenius社の登録商標です。
※その他、記載されている会社名、製品名は、各社の商標または登録商標です。