マルチテナント権限設計 – Workspace 分離・ロール階層・API キースコーピングの実践ガイド

エンタープライズにおけるマルチテナント設計とは、単に「部署ごとにアカウントを分ける」ことではない。データをどう隔離するか、モデルをどう共有するか、権限をどう継承するか – この 3 つの問いに答えることが本質である。

Dify では Workspace（ワークスペース）、Team Members（チームメンバー）、Model Providers（モデルプロバイダー）が異なる管理レイヤーとして設計されている。Enterprise 版ではこれらに加え、組織管理・SSO 連携・監査ログといったガバナンス機能が追加される。本記事では、日本企業が Dify Enterprise を社内展開する際の権限設計パターンを実務レベルで解説する。

1. Dify の権限モデル概要

1.1 基本概念の整理

graph TB
    subgraph "プラットフォームレベル"
        A[System Admin]
        B[Model Providers]
        C[License 管理]
    end
    subgraph "Workspace レベル"
        D[Workspace A<br/>営業部]
        E[Workspace B<br/>カスタマーサポート部]
        F[Workspace C<br/>法務部]
    end
    subgraph "Workspace 内"
        G[Apps]
        H[Knowledge Base]
        I[Tools]
        J[Members & Roles]
    end
    A --> D
    A --> E
    A --> F
    B -.->|共有可能| D
    B -.->|共有可能| E
    B -.->|共有可能| F
    D --> G
    D --> H
    D --> I
    D --> J

1.2 ロール階層

Dify には以下のロール階層が存在する。

1.3 隔離の境界

2. テナント設計パターン

2.1 パターン A: 強隔離モデル（部署完全分離）

graph LR
    subgraph "法務部 Workspace"
        A1[契約書レビューApp]
        A2[法務ナレッジベース]
        A3[専用 Model Provider]
    end
    subgraph "人事部 Workspace"
        B1[採用FAQ App]
        B2[人事ナレッジベース]
        B3[専用 Model Provider]
    end
    A1 -.- A2
    B1 -.- B2

適用場面: 法務、人事、財務、経営企画など、機密性の高いデータを扱う部署。

特徴:

• ナレッジベースは完全に分離
• Model Provider も部署ごとに個別設定（API キーを分離し、利用量を個別管理）
• メンバーの兼任は原則禁止または最小限
• 監査ログの定期レビューを実施

values.yaml との関連設定:

# Workspace 間のデータ分離は Dify のアプリケーション層で実現
# インフラレベルでは以下を確認
enterprise:
  enabled: true
  # 監査ログの有効化
  auditLog:
    enabled: true
    retention: "365d"

2.2 パターン B: 共有基盤 + データ分離モデル

graph TB
    subgraph "プラットフォーム共有層"
        M[共有 Model Provider<br/>GPT-4o / Claude]
        P[共有プラグイン]
    end
    subgraph "営業部 Workspace"
        C1[商談支援 App]
        C2[営業ナレッジベース]
    end
    subgraph "CS部 Workspace"
        D1[問合せ対応 App]
        D2[CS ナレッジベース]
    end
    M -->|利用| C1
    M -->|利用| D1
    C1 -.- C2
    D1 -.- D2

適用場面: 営業、マーケティング、カスタマーサポートなど、基盤モデルの共有が効率的な部署。

特徴:

• Model Provider はプラットフォームレベルで一元管理（コスト最適化）
• ナレッジベースとアプリケーションは Workspace で分離
• メンバーの複数 Workspace 所属を許可
• ツール（Web 検索、計算機等）は共有利用

2.3 パターン C: プロジェクト横断モデル

graph TB
    subgraph "DX推進PJ Workspace"
        E1[業務分析 App]
        E2[PJナレッジベース]
    end
    subgraph "営業部 Workspace"
        F1[営業 App]
        F2[営業ナレッジベース]
    end
    U1[ユーザーA<br/>DX推進 + 営業] --> E1
    U1 --> F1
    U2[ユーザーB<br/>DX推進のみ] --> E1

適用場面: 部署横断プロジェクトがある企業。同一ユーザーが複数の Workspace にそれぞれ異なるロールで所属する。

3. 権限設計のベストプラクティス

3.1 最小権限の原則

System Admin は最小人数（2-3 名）に限定する
  └── 通常業務では Workspace Admin 以下のロールを使用
      └── アプリ利用のみのユーザーは Member ロールで十分

具体的な推奨:

3.2 Model Provider の管理方針

Model Provider の設定はコスト管理とセキュリティの両面で重要である。

推奨アプローチ:
1. System Admin がプラットフォームレベルで利用可能なモデルを設定
2. Workspace ごとに利用可能なモデルを制限（必要に応じて）
3. 各モデルの API キーは Secret Manager で一元管理
4. 月次でモデル利用量をレビュー

Model Provider 設定例（プラットフォームレベル）:

3.3 ナレッジベースのアクセス制御

4. API キーのスコーピング

4.1 API キーの発行単位

Dify の API キーはアプリケーション単位で発行される。外部システムと連携する際は、以下の原則を守る。

1 つの API キー = 1 つのアプリケーション = 1 つのユースケース

アンチパターン: 1 つの API キーを複数のシステムで使い回す。

4.2 API キー管理のベストプラクティス

# 外部システムからの Dify API 呼び出し例
# 各システムごとに個別の API キーを発行する

# CRM システム → 商談要約 App
# API Key: app-xxxx1111 (CRM 専用)

# チャットボット → FAQ 回答 App
# API Key: app-xxxx2222 (チャットボット専用)

# 社内ポータル → ドキュメント検索 App
# API Key: app-xxxx3333 (ポータル専用)

4.3 API キーのライフサイクル管理

5. SSO 連携による認証統合

5.1 推奨構成

Enterprise 版では SAML 2.0 / OIDC による SSO が利用可能である。

sequenceDiagram
    participant User as ユーザー
    participant Dify as Dify Enterprise
    participant IdP as IdP (Azure AD / Okta)
    
    User->>Dify: ログイン要求
    Dify->>IdP: SAML AuthnRequest
    IdP->>User: 認証画面
    User->>IdP: 認証情報入力
    IdP->>Dify: SAML Response (属性付き)
    Dify->>Dify: Workspace / ロール自動割り当て
    Dify->>User: ダッシュボード表示

5.2 IdP 属性マッピング

5.3 SSO 導入時の注意点

• 初回ログイン時に Workspace への自動割り当てルールを事前に定義しておく
• IdP 側のグループ変更が Dify のロールに反映されるタイミングを確認する
• 緊急時用のローカル管理者アカウントを 1 つ維持する（IdP 障害時の対応）
• SSO セッションタイムアウトと Dify セッションタイムアウトを整合させる

6. 監査とコンプライアンス

6.1 監査ログで記録すべきイベント

6.2 定期レビューの実施

月次レビュー:
  - 各 Workspace のメンバー一覧と最終ログイン日を確認
  - 90 日以上ログインのないアカウントを無効化
  - API キーの棚卸し（不要なキーの失効）
  - Model 利用量のコスト確認

四半期レビュー:
  - ロール割り当ての妥当性確認
  - Workspace 構成の見直し
  - 監査ログの異常パターン確認
  - アクセス権限のレビュー（J-SOX 対応）

7. 典型的な組織構成例

7.1 中規模企業（500 名、5 部署）の設計例

System Admin は情報システム部の 2 名に限定し、各 Workspace の Owner は部署長またはAI推進担当が担う構成とする。

8. まとめ

マルチテナント権限設計の核心は「共有効率」と「データ境界」のバランスである。以下の 5 つの原則を指針とする。

1. Workspace = テナント境界: 部署またはプロジェクト単位で Workspace を作成し、ナレッジベースとアプリを隔離する
2. Model Provider は共有可能: コスト効率のため、基盤モデルはプラットフォームレベルで管理し、必要に応じて Workspace 単位で制限する
3. 最小権限の原則: System Admin は最小人数に限定し、一般ユーザーには必要最低限のロールを付与する
4. API キーはユースケース単位: 1 キー = 1 アプリ = 1 連携先の原則を徹底する
5. 監査と定期レビュー: 監査ログを有効化し、月次でメンバー・キー・コストの棚卸しを実施する

権限設計は一度決めたら終わりではなく、組織の変化に応じて継続的に見直す運用プロセスが不可欠である。