2025年10月19日 / 最終更新日 : 2025年10月19日 fujifuji コラム

DifyのPrivateモード設定ガイド｜限定メンバーで社内チャットボットを安全に運用する方法

Difyで社内チャットボットを構築したものの、「URLを知っている人なら誰でもアクセスできてしまう」という問題に直面していませんか？機密情報を扱う社内ツールとして運用する場合、適切なアクセス制限は必須です。

本記事では、Difyを限定されたメンバーだけで安全に利用するための具体的な方法を、クラウド版・セルフホスト版それぞれのケースで詳しく解説します。

1 1. Difyのアクセス制限における課題
- 1.1 Difyの標準設定における問題点
- 1.2 なぜアクセス制限が重要なのか
2 2. Privateモードの基本設定
3 3. クラウド版での限定メンバー運用方法
4 4. セルフホスト版での認証・アクセス制限
5 5. メンバー管理とロール設定
6 6. 会話ログのアクセス制限
7 7. エンタープライズ版の高度な権限管理
8 8. 運用時のベストプラクティス
9 9. よくある質問と解決策
10 10. まとめ
11 ■らくらくPython塾 – 読むだけでマスター

1. Difyのアクセス制限における課題

Difyの標準設定における問題点

Difyでアプリケーションを作成すると、デフォルトでは以下のような課題があります：

クラウド版の場合

公開されたアプリはURLを知る全員がアクセス可能
パスワードやユーザー認証機能が標準では不十分
URLが流出すると意図しない利用が発生するリスク

セルフホスト版の場合

追加の認証設定が必要
インフラレベルでの制御が求められる
設定の複雑さがハードルとなる

なぜアクセス制限が重要なのか

1. 機密情報の保護 社内文書を学習させたチャットボットは、会社の機密情報を含む可能性があります。

2. API利用料金の管理 DifyではOpenAIやClaudeなどのLLM APIを使用します。これらは従量課金のため、無制限なアクセスを許すと予期しない高額請求につながる可能性があります。

3. コンプライアンス要件 個人情報や機密データを扱う場合、適切なアクセス制御が法的に求められることがあります。

2. Privateモードの基本設定

Privateモードとは

DifyのPrivateモードは、招待されたメンバーだけがアクセスできる設定です。デフォルトでこのモードが有効になっています。

デフォルト設定の確認

アプリケーション作成時、デフォルトで「Private」に設定されており、以下の特徴があります：

招待されたメンバーのみアクセス可能：ワークスペースに招待されたユーザーだけが利用できます
Slack/Teamsでの共有も制限される：共有リンクも限定メンバーしか開けません
社外秘ボットとして安全に運用可能：機密情報を扱うアプリに適しています

アクセス制御の切り替え方法

アプリケーションの公開設定は、管理画面からワンクリックで切り替えられます：

アプリの「監視」画面を開く
公開設定で「Private」または「Public」を選択
設定を保存

推奨：社内評価が終わるまではPrivateに固定しておくことを推奨します。

3. クラウド版での限定メンバー運用方法

Dify 1.0.0以降の新機能：WebApp無効化

Dify 1.0.0から、より強力なアクセス制限が可能になりました。

設定方法

アプリの「監視」画面を開く
「WebApp」を無効にする

これだけで以下の効果が得られます：

ログインユーザーのみがアプリを利用可能
ログインせずに探索タブのURLからアクセスしようとすると、ログインが強制される
公開URLからのアクセスは404エラーが表示される

ワークスペースへのメンバー招待

招待手順

Difyのユーザーアイコンをクリック
「設定」→「メンバー」を選択
招待したいユーザーのメールアドレスを入力
ロールを選択（Owner/Admin/Editor/Normal）
招待を送信

自動アカウント作成 招待されたユーザーには自動的にDifyアカウントが作成され、メールで通知されます。

クラウド版の制限事項

クラウド版では以下の高度な認証機能は利用できません：

カスタム認証プロバイダーの統合
SSO（シングルサインオン）連携
IP制限
Basic認証

これらが必要な場合は、セルフホスト版の採用を検討してください。

4. セルフホスト版での認証・アクセス制限

セルフホスト版を選択すべきケース

以下の要件がある場合は、セルフホスト版を推奨します：

高度なセキュリティ要件がある
既存の認証システムと統合したい
データを完全に社内管理したい
カスタマイズした認証フローが必要

方法1：Basic認証の設定

最もシンプルなアクセス制限方法です。特定のURLにのみBasic認証をかけることができます。

実装手順（Nginx使用の場合）

# 1. パスワードファイルの作成
htpasswd -c /etc/nginx/.htpasswd username

# 2. Nginx設定ファイルの編集
vi /root/dify/docker/nginx/conf.d/default.conf.template

# 3. 以下を追記
location /chat/xxxxx {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
    proxy_pass http://web:3000;
    include proxy.conf;
}

# 4. Dockerコンテナの再起動
cd /root/dify/docker/
docker compose down
docker compose up -d

メリット

簡単な設定で実現可能
Difyアプリケーション本体に手を加える必要なし

デメリット

ブラウザに認証情報が記憶されるため共有環境では注意が必要
ユーザー管理の一元化ができない

方法2：ALB + Cognito認証（AWS環境）

AWS環境でDifyを運用している場合、より高度な認証が可能です。

構成例

ユーザー → ALB（Cognito認証） → Dify

特徴

認証されたユーザーのみアクセス可能
AWS Cognitoでユーザー管理
HTTPSリスナーによる安全な通信

実装

Dify on AWS CDKを利用し、以下のパラメータを設定：

new DifyOnAwsStack(app, 'DifyOnAwsStackAlbAuth', {
  domainName: 'your-domain.com',
  hostedZoneId: 'YOUR_HOSTED_ZONE_ID',
  requireAuth: true  // 認証を有効化
});

方法3：Google認証

社員限定アクセスとするため、ALBでGoogle認証を導入する方法です。

メリット

社員の既存Googleアカウントを利用
パスワード管理が不要
退職者は自動的にアクセス不可

実装のポイント

Application Load Balancerの設定
Google OAuth 2.0の設定
ドメインまたはGoogleグループでのアクセス制限

方法4：IP制限

最もシンプルだが制限の多い方法です。

設定例（セキュリティグループ）

# 特定IPアドレスからのみアクセス許可
許可ルール：
- ソース：123.456.789.0/24（会社のIPレンジ）
- ポート：80, 443
- プロトコル：TCP

メリット

設定が簡単
インフラレベルで制御

デメリット

在宅勤務など社外からのアクセスに対応困難
動的IPアドレスの管理が煩雑

方法5：Cloudflare Tunnel

NATの内側にサーバーがある場合でも、安全にインターネット公開できる方法です。

メリット

SSHポート以外を開放する必要がなく、セキュリティが向上
NATの内側でも外部からアクセス可能
Cloudflareのグローバルネットワークによる高速化

デメリット

Cloudflareアカウントが必要
追加の設定が必要

5. メンバー管理とロール設定

Difyの権限体系

Difyには4つの基本ロールがあります：

1. Owner（オーナー）

権限

ワークスペースの完全管理権限
チームメンバーの管理
メンバー権限の調整
モデルプロバイダーの設定
アプリケーションの作成・編集・削除
ナレッジベースの作成
ツールライブラリの設定
課金管理

適用対象：ワークスペースの責任者

2. Admin（管理者）

権限

チームメンバーの追加・削除
モデルプロバイダーの設定
アプリケーションの作成・編集・削除
ナレッジベースの作成
ツールライブラリの設定

制限

メンバー権限の調整はできない

適用対象：部門管理者、プロジェクトリーダー

3. Editor（編集者）

権限

アプリケーションの作成・編集・削除
ナレッジベースの作成・編集
ワークフローの構築

制限

メンバー管理不可
モデルプロバイダー設定不可
ツールライブラリ設定不可

適用対象：開発者、アプリ制作担当者

4. Normal / Viewer（閲覧者・一般ユーザー）

権限

チーム内で作成されたアプリの使用のみ

制限

アプリの作成・編集不可
設定変更不可

適用対象：エンドユーザー、利用者のみ

効果的なロール設計

小規模チーム（10人未満）

Owner: 1名（IT部門責任者）
Admin: 2名（プロジェクトリーダー）
Editor: 3-4名（開発メンバー）
Normal: その他全員

中規模チーム（10-50人）

Owner: 1名（CTO/IT部門長）
Admin: 部門ごとに1名（人事、経理、営業など）
Editor: 各部門で2-3名
Normal: 一般社員

大規模組織（50人以上）

エンタープライズ版の採用を推奨。マルチワークスペースで部門別に管理。

メンバー管理のベストプラクティス

1. 最小権限の原則 必要最小限の権限のみを付与します。

2. 定期的な権限レビュー 月次または四半期ごとに、メンバーの権限を見直します。

3. 退職者の即時削除 退職者のアカウントは即座に削除し、アクセス権を剥奪します。

4. ドキュメント化 各ロールの責任範囲を明確に文書化します。

6. 会話ログのアクセス制限

会話ログの閲覧権限問題

Difyの標準設定では、エディター権限があれば他の人が作成したアプリの会話ログも閲覧できてしまいます。機密性の高い会話を扱う場合、これは大きな問題です。

会話ログアクセス制限の実装

方法1：Difyソースを変更せずに制限

リバースプロキシレイヤーで会話ログへのアクセスを制御する方法があります。

実装の考え方

リクエストに含まれる認証情報をもとにDify DBに問い合わせ
閲覧権限を判断（オーナー・管理者・アプリ作成者のみ許可）
権限がない場合はアクセスをブロック

注意点

Dify本体のアップデートで動作しなくなる可能性がある
技術的な知識が必要

方法2：ナレッジへのアクセス制御

ナレッジ単位でのアクセス制御は可能です：

ナレッジ作成時にアクセス権限を設定
特定のメンバーのみが参照できるように制限
アプリごとに使用するナレッジを分離

部門別の会話データ分離

推奨アプローチ

人事部用アプリ → 人事部メンバーのみアクセス可能
経理部用アプリ → 経理部メンバーのみアクセス可能
全社共通アプリ → 全社員がアクセス可能

エンタープライズ版であれば、ワークスペースごとに完全に分離できます。

7. エンタープライズ版の高度な権限管理

エンタープライズ版の特徴

大規模組織や厳格なセキュリティ要件がある場合は、エンタープライズ版の採用を検討すべきです。

マルチワークスペース機能

利点

1. 完全なデータ分離 部門やプロジェクトごとにワークスペースを作成し、データを完全に分離できます。

ワークスペース例：
- 人事部ワークスペース
- 経理部ワークスペース
- 営業部ワークスペース
- 開発部ワークスペース

2. コスト管理 ワークスペースごとに異なるAPIキーを設定することで、部署別のAI利用コストを正確に把握できます。

3. 柔軟な権限設定 ワークスペースごとに独立した権限管理が可能です。

SSO（シングルサインオン）連携

対応IdP

Azure AD
Okta
Google Workspace
その他SAML 2.0対応IdP

メリット

1. ユーザー利便性の向上 従業員は会社の認証情報でDifyにログインでき、新たなパスワードを覚える必要がありません。

2. セキュリティ強化 退職者のIdPアカウントを無効化すれば、自動的にDifyへのアクセス権も失効します。

3. 一元管理 全社の認証を一箇所で管理できます。

Admin API

エンタープライズ版では、管理タスクをAPI経由で自動化できます：

ワークスペースの作成・削除
メンバーの一括招待
権限の一括変更
監査ログの取得

Kubernetes対応

高可用性とスケーラビリティを確保するため、Kubernetes環境へのデプロイが可能です。

8. 運用時のベストプラクティス

セキュリティ強化策

1. 定期的なアクセスログの監査

監査項目：
- 異常なログイン試行の検出
- 未承認のアクセス確認
- 大量のAPI呼び出しの監視

2. 二要素認証の導入

可能であれば、Difyアカウントに二要素認証を設定します。

3. セッションタイムアウトの設定

一定時間操作がない場合、自動的にログアウトさせる設定を検討します。

コスト管理

1. APIキーの適切な管理

推奨事項：
- ワークスペースごとに異なるAPIキーを使用
- 定期的にキーをローテーション
- 使用量の監視とアラート設定

2. 利用状況の可視化

監視項目：
- ユーザーごとの利用回数
- アプリごとのAPI呼び出し数
- 月次コストの推移

3. 予算アラートの設定

OpenAIやAnthropicのAPI使用量に基づいて、予算超過アラートを設定します。

ユーザー教育

1. セキュリティガイドラインの作成

含めるべき内容：
- パスワード管理のルール
- アクセスURLの取り扱い
- 機密情報の入力に関する注意事項
- 不審なアクセスの報告方法

2. 利用トレーニングの実施

新規ユーザーには、Difyの適切な使い方をトレーニングします。

3. 定期的なリマインダー

セキュリティに関する注意事項を定期的に周知します。

データバックアップ

1. アプリのエクスポート

定期的にアプリケーションのDSLファイルをエクスポートし、バックアップします。

2. ナレッジベースのバックアップ

重要なナレッジデータは別途バックアップを取得します。

3. 設定のドキュメント化

認証設定、ネットワーク設定などをドキュメント化しておきます。

9. よくある質問と解決策

Q1: URLが漏洩した場合の対処法は？

A: 以下の手順で対応します：

即座にアプリを非公開に設定
新しいアプリとして再作成（新しいURLが発行される）
メンバーに新しいURLを通知
漏洩経路を特定し、再発防止策を講じる

Q2: 退職者のアクセスを確実に遮断するには？

即日対応

Difyからメンバーを削除
SSO利用の場合はIdPでアカウント無効化
APIキーを変更（退職者が知っている可能性がある場合）

定期確認

月次でメンバーリストと在籍者リストを照合

Q3: 複数部署で使いたいが、データは分離したい

コミュニティ版の場合

ナレッジを部署別に作成し、アクセス権限を設定
アプリを部署別に作成し、使用するナレッジを分離

エンタープライズ版の場合

部署ごとにワークスペースを作成
完全なデータ分離を実現

Q4: Basic認証とWebApp無効化、どちらを使うべき？

WebApp無効化を推奨するケース

クラウド版を使用
Difyのログイン機能で十分
シンプルな運用を求める

Basic認証を推奨するケース

セルフホスト版を使用
Difyのログインとは別の認証レイヤーが必要
特定のURLのみ保護したい

Q5: 社外の協力会社メンバーにも限定公開したい

方法1：Difyアカウントの発行

協力会社メンバーにもDifyアカウントを発行
Normalロールで権限を最小化
契約終了時に即座にアカウント削除

方法2：API経由での提供

DifyのAPI機能を使用
自社システムから認証を経てAPIを呼び出す
より細かい制御が可能

10. まとめ

DifyのPrivateモードと限定メンバーでの運用は、適切な設定により安全に実現できます。

本記事の重要ポイント

クラウド版利用の場合

デフォルトPrivate設定を活用
- 招待されたメンバーのみがアクセス可能
- ワンクリックで切り替え可能
WebApp無効化（Dify 1.0.0以降）
- ログインユーザーのみに制限
- 最も簡単で効果的な方法
適切なロール設定
- Owner/Admin/Editor/Normalを使い分け
- 最小権限の原則を遵守

セルフホスト版利用の場合

多様な認証方法から選択
- Basic認証：シンプルだが効果的
- ALB + Cognito：AWS環境での高度な認証
- Google認証：社員アカウントを活用
- IP制限：インフラレベルでの制御
会話ログのアクセス制限
- 機密性の高い会話を扱う場合は追加対策が必要
- リバースプロキシレイヤーでの制御
インフラレベルのセキュリティ
- ファイアウォール設定
- VPN接続
- 暗号化通信

エンタープライズ版の検討

以下の要件がある場合はエンタープライズ版を推奨：

50名以上の大規模組織
部門別の完全なデータ分離が必要
SSO連携が必須
高可用性・スケーラビリティが求められる

運用のベストプラクティス

定期的な監査
- メンバーリストの確認（月次）
- アクセスログの監視（週次）
- 権限レビュー（四半期）
コスト管理
- API使用量の監視
- 予算アラートの設定
- 部門別コスト把握
ユーザー教育
- セキュリティガイドラインの作成
- 新規ユーザートレーニング
- 定期的なリマインダー

次のステップ

まずは以下から始めることをおすすめします：

現状の確認：現在のDify設定を確認
要件の整理：必要なセキュリティレベルを明確化
段階的な実装：小規模から始めて徐々に拡大
継続的な改善：運用しながら最適化

DifyのPrivateモードを適切に設定することで、安全かつ効率的に社内AIツールを運用できます。本記事の内容を参考に、あなたの組織に最適なアクセス制限を実装してください。

関連キーワード Dify、Privateモード、アクセス制限、メンバー管理、セキュリティ、認証、ワークスペース、ロール設定、社内限定、Basic認証、SSO、会話ログ、エンタープライズ版

■らくらくPython塾 – 読むだけでマスター

■初心者歓迎「AI駆動開発/生成AIエンジニアコース」はじめました！

テックジム東京本校で先行開始。

AI駆動開発/生成AIエンジニアコース（初心者向け）

■テックジム東京本校

格安のプログラミングスクールといえば「テックジム」。
講義動画なし、教科書なし。「進捗管理とコーチング」で効率学習。
対面型でより早くスキル獲得、月額2万円のプログラミングスクールです。

テックジム東京本校

＜短期講習＞5日で5万円の「Pythonミニキャンプ」開催中。

【最速・確実】プログラミング攻略「永田町Pythonミニキャンプ」【5日間で5万円】

＜オンライン無料＞ゼロから始めるPython爆速講座

【無料・オンライン】ゼロからはじめるPython爆速講座

カテゴリー: コラム

1. Difyのアクセス制限における課題

Difyの標準設定における問題点

なぜアクセス制限が重要なのか

2. Privateモードの基本設定

Privateモードとは

デフォルト設定の確認

アクセス制御の切り替え方法

3. クラウド版での限定メンバー運用方法

Dify 1.0.0以降の新機能：WebApp無効化

ワークスペースへのメンバー招待

クラウド版の制限事項

4. セルフホスト版での認証・アクセス制限

セルフホスト版を選択すべきケース

方法1：Basic認証の設定

方法2：ALB + Cognito認証（AWS環境）

方法3：Google認証

方法4：IP制限

方法5：Cloudflare Tunnel

5. メンバー管理とロール設定

Difyの権限体系

1. Owner（オーナー）

2. Admin（管理者）

3. Editor（編集者）

4. Normal / Viewer（閲覧者・一般ユーザー）

効果的なロール設計

メンバー管理のベストプラクティス

6. 会話ログのアクセス制限

会話ログの閲覧権限問題

会話ログアクセス制限の実装

部門別の会話データ分離

7. エンタープライズ版の高度な権限管理

エンタープライズ版の特徴

マルチワークスペース機能

SSO（シングルサインオン）連携

Admin API

Kubernetes対応

8. 運用時のベストプラクティス

セキュリティ強化策

コスト管理

ユーザー教育

データバックアップ

9. よくある質問と解決策

Q1: URLが漏洩した場合の対処法は？

Q2: 退職者のアクセスを確実に遮断するには？

Q3: 複数部署で使いたいが、データは分離したい

Q4: Basic認証とWebApp無効化、どちらを使うべき？

Q5: 社外の協力会社メンバーにも限定公開したい

10. まとめ

クラウド版利用の場合

セルフホスト版利用の場合

エンタープライズ版の検討

運用のベストプラクティス

■らくらくPython塾 – 読むだけでマスター

Difyで社内チャットボットを構築する完全ガイド｜ノーコードで業務効率化New!!

お問い合わせ自動回答をDifyで実現！導入手順から料金まで徹底解説New!!