Dify セキュリティ要件と検証を徹底解説｜AWSで監査対応を最短14日で進めたい担当者へ

Difyは安全か。危険の正体は置き場所と送るデータ

Difyはアプリの組み立てを担うツールで、回答を作るのは接続した大規模言語モデル（LLM）です。したがって危険が生まれる場所は、Difyの画面の中というより、その外側にあります。プロンプトや会話ログがどこに保存されるか、ナレッジ（RAG用の文書）に機密が混ざらないか、外部のモデルへ何が送られるか。この3点を固定すれば、残りのリスクは一般的なWebシステムと同じ管理で足ります。

クラウド版とセルフホスト、どちらを選ぶか

Difyには提供元が運用するクラウド版と、自社環境に構築するセルフホスト版があります。判断軸は運用体制です。セルフホストはデータの保管先と通信経路を自社で決められる代わりに、バージョン更新、脆弱性対応、バックアップの責任がすべて自社に移ります。クラウド版は運用負荷が軽い一方、保管地域や保持期間、監査報告書の提供可否を契約で確認する必要があります。機密区分が高い業務を扱い、AWSにすでに統制基盤がある企業は、VPC内へのセルフホストが説明しやすい構成です。

入力したデータはAIの学習に使われるのか

ここを決めるのは製品側の設定ではありません。接続するモデルの契約です。主要なLLMベンダーはAPI経由で受け取ったデータを既定では学習に使わない方針を示していますが、プランや地域、オプトイン設定で変わります。社内規程に書くなら「使わない」と断定する前に、利用するモデルの利用規約とデータ処理条項を版ごとに確認し、その版数と確認日をセットで記録してください。SOC 2やISO/IEC 27001などの認証取得状況も、公式のセキュリティ情報ページで最新を確認し、監査で提示するなら報告書の入手可否まで押さえます。

セルフホストで抜けやすい3点

1つ目はバージョン更新です。OSSの修正は更新でしか届かないため、追随の担当と頻度を運用要件に書きます。2つ目はコード実行のサンドボックスです。ワークフローでコードを動かす構成では、実行環境をネットワーク的に隔離し、外向き通信を絞ります。3つ目は管理画面の公開範囲です。検証中にインターネットへ開いたまま本番へ移る事故が起きやすいので、社内網やVPN、SSOの背後に置く前提で設計します。

Difyのセキュリティリスクを6つに分けて押さえる

リスクを漠然と「情報漏えい」とまとめると対策が決まりません。発生源で分けると、止める場所と担当がはっきりします。次の6つに整理すると、そのまま検証項目の見出しになります。

プロンプトインジェクションは入力経路をふさぐ

プロンプトインジェクションは、利用者が打つ文章だけで起きるとは限りません。RAGで読み込んだ文書やWebページに指示文が仕込まれ、それを読んだモデルが従う経路もあります。対策の中心は、そもそも取られて困る情報をモデルに渡さない設計へ寄せることです。そのうえで、参照した文書の根拠表示、外部から取り込む文書の登録審査、出力に含めてはいけない語の検知を検証項目に入れます。

ナレッジの権限とログの残り方

ナレッジは部門をまたいで共有されやすく、権限設計が最も崩れる場所です。人事と法務が同じナレッジを参照できる状態を放置すると、権限の話ではなく規程違反になります。ナレッジ単位で参照権を分け、誰がどの文書を登録したかを残します。会話ログも同じで、保存するか、するなら何日で消すかを決め、削除が実際に効いているかまで確認します。

監査で問われる要件は5領域に収まる

セキュリティ要件は数を増やすほど形骸化します。監査で実際に説明を求められるのは、データ、権限、ログ、外部送信、変更管理の5領域です。ここを先に文章化しておくと、社内審査の往復が減ります。

データ分類と保持期間を先に決める

入力データと参照データを、公開情報、社外秘、個人情報、機微情報に分類します。Difyではプロンプトと会話ログもデータとして残り得るため、保存しない、一定期間で消す、暗号化して保管するのどれを取るかを区分ごとに決めます。AWSならS3の暗号化とライフサイクルで削除まで実装でき、設定そのものが証跡になります。

権限分離は役割の数だけ作らない

管理者、開発者、利用者、監査担当の4役割から始めます。増やすほど棚卸しが回らなくなるためです。DifyのワークスペースとAWSのIAMで、同じ役割名を使って対応表を作ります。APIキーと暗号鍵に触れる人は最小にし、SSOとMFAを前提にすると、監査で説明する材料がそのまま揃います。

ログは誰がいつ何をしたかまで残す

アプリの公開、コネクタ設定、鍵の更新は監査対象になりやすい操作です。取得しているだけでは足りず、改ざんできない場所へ集約し、保持期間を決めます。AWSではCloudTrailとCloudWatch Logsで集中管理し、S3 Object Lockで改ざん耐性を足す構成が取れます。検証では、監査担当が過去の操作を再現できるかで合否を判定します。

外部送信は範囲を固定する

送信する項目、マスキングの方針、保存期間、学習利用の可否を明文化します。RAGでは全文を渡さず、必要な抜粋だけを送る設計にすると、範囲が自然に狭まります。AWS側ではVPCエンドポイントや送信先の制限で通信経路を絞れます。範囲が固定できると、検証項目は「その範囲を超えていないか」の1点に集約されます。

要件を検証に変える。合否で判定できる文章にする

要件は理想の状態を示し、検証はその状態に到達した証拠を作ります。「安全に運用する」と書いた要件は、誰も合否を判定できません。「会話ログは30日で削除する」「氏名と住所はマスキングしてから送信する」のように、Yes/Noで答えられる文へ言い換えます。この書き換えができた時点で、検証項目は自動的に決まります。

テストと検証は目的が違う

テストは仕様どおり動くかを確かめる作業、検証は要件を満たすかを確かめる作業です。権限分離や監査証跡、保持期間は画面操作の確認では判定できません。AWSのIAM設定とCloudTrailのイベントまで見て、初めて検証が成立します。最初から100項目を作らず、機密性・完全性・可用性の3軸に外部送信と権限を掛け合わせ、必須20項目に絞ると推進できます。

証跡は第三者が再現できる形で残す

画面キャプチャだけの証跡は改ざん疑義が残ります。AWSのログ、設定のJSONエクスポート、実行時刻を混ぜて保存してください。検証手順書には前提条件、手順、期待結果、証跡の保存先、例外時の判断基準まで書きます。ここまで書けていれば、担当が変わっても同じ判定を再現でき、監査対応の資料をあらためて作る手間も消えます。

AWSで埋まる範囲と、Dify側に残る範囲

AWSは暗号化、ログ、ネットワーク境界、バックアップが得意です。一方、プロンプトの中身、ナレッジの登録審査、出力の妥当性はDify側と運用ルールの担当で、基盤では埋まりません。責任の線を先に引いておくと、事故時に「誰がどの証跡で説明するか」で揉めません。

部門別に見る、要件と検証の置きどころ

扱うデータの区分が変わると、締めるべき要件も変わります。文章中心の業務ほどDifyと相性がよく、先に要件を固めた案件ほど展開が速い傾向があります。

情報システム部門：社内FAQの一次回答

社内規程と手順書をナレッジ化し、チャットで一次回答を返す構成です。会話ログの保持を30日に固定し、参照権を部門単位で分けました。検証では誤回答時のエスカレーション経路とログ追跡を手順化し、設定変更の履歴をCloudTrailで証跡化しています。一次対応の工数は月60時間削減しました。

人事部門：個人情報を含む面接メモの要約

氏名と住所を自動マスキングし、外部送信の範囲を固定したうえで要約と整形を任せます。検証の中心はマスキング漏れで、テストケースを作って確認し、証跡は暗号化ストレージへ保管しました。要約作業は1件あたり25分短縮しています。

法務部門：契約レビューの一次確認

条文を抽出してリスク条項の指摘案を出す使い方です。原本の保管場所とアクセス権を厳格化し、モデルへ渡すのは必要な抜粋だけに限定しました。検証では差分抽出の精度と、送信データが範囲内に収まっているかをログと設定で裏取りします。一次レビューは30%短縮しました。

監査対応を14日で終える進め方

要件定義から証跡の整理までは、対象を1業務に絞れば2週間で回せます。日程を切ることで、要件を増やし続ける議論に区切りがつきます。

体制の組み方や社内合意の取り付けでつまずきやすい場合は、導入の進め方をまとめた資料に、関係部門の巻き込み順とスケジュールの型を載せています。

費用の目安と、上振れする条件

費用は運用体制、検証の深さ、基盤の統制レベルで変わります。次の表は一般的な相場感で、弊社の見積もりではありません。実際の金額は要件を確認したうえで個別見積もりになります。

上振れするのは、後から外部送信の禁止が決まってアーキテクチャを組み替える場合と、証跡が足りず検証をやり直す場合です。IT導入補助金や自治体のDX支援が使える場合もありますが、業種と規模で適用可否が変わるため、早めに確認してください。どの業務から着手すると回収が早いかは、効果の出やすい業務から選ぶ資料で判断材料を整理しています。

つまずく4つの原因と、先に決めること

失敗の多くは、技術の難しさより「決めていない項目」から起きます。次の4つを着手前に潰しておくと、審査で止まりません。

よくある質問