なぜ Dify は On-Premise を選んだのか：データ主権・日本企業コンプライアンス・ハイブリッドクラウド戦略

はじめに

エンタープライズ AI プラットフォームの導入形態を検討するとき、「SaaS か On-Premise か」という二項対立で語られることが多い。しかし Dify の設計思想はそのどちらでもない。Dify は SaaS として利用できる利便性を維持しつつ、On-Premise / Self-Host を“第一級の導入パス“として公開している 点に最大の特徴がある。

本稿では、Dify がなぜ On-Premise デプロイを製品アーキテクチャの中核に据えたのかを、データ主権、日本固有の法規制、ネットワーク分離要件、そしてハイブリッドクラウド戦略の観点から掘り下げる。

1. Dify の On-Premise 提供形態：公開されている事実

1.1 Docker Compose による即時デプロイ

Dify の公式ドキュメントは、Self-Host の最初のステップとして Docker Compose を提供している。docker-compose.yml 一つで API サーバー、Worker、Web フロントエンド、PostgreSQL、Redis、Weaviate（Vector DB）が立ち上がる構成だ。

# Dify Self-Host の最小構成イメージ
services:
  api:
    image: langgenius/dify-api:latest
    environment:
      - DB_HOST=db
      - REDIS_HOST=redis
      - VECTOR_STORE=weaviate
  web:
    image: langgenius/dify-web:latest
  worker:
    image: langgenius/dify-api:latest
    command: celery worker
  db:
    image: postgres:15
  redis:
    image: redis:7
  weaviate:
    image: semitechnologies/weaviate:latest

この構成が示すのは、Dify が「クラウドベンダーのマネージドサービスに依存しない自己完結型アーキテクチャ」を意図的に設計しているということだ。

1.2 Enterprise Kubernetes / Helm デプロイ

Enterprise 版では Helm Chart が提供され、以下のインフラ制御が企業側に委ねられている：

この設計は「Dify はアプリケーション層を提供し、インフラの制御権は企業が保持する」という明確な分離思想を反映している。

1.3 Resources Checklist の意味

Enterprise Docs には Resources Checklist が公開されており、CPU・メモリ・ストレージの推奨スペックが Workspace 数・同時ユーザー数別に記載されている。これは SaaS ベンダーが通常公開しない情報であり、企業のインフラチームがキャパシティプランニングを自律的に行うことを前提とした設計であることを示す。

2. データ主権：なぜ「データがどこにあるか」が最重要課題なのか

2.1 エンタープライズ AI が扱うデータの性質

AI プラットフォームが扱うデータは、従来の SaaS とは本質的に異なる：

• Knowledge Base に投入される社内文書: 就業規則、契約書テンプレート、製品仕様書、顧客対応マニュアル
• Workflow で処理される業務データ: 顧客情報、取引履歴、財務データ
• LLM へのプロンプトとレスポンス: 機密情報を含む質問と、それに対する回答ログ
• Embedding ベクトル: 元文書を復元可能な数値表現

graph TB
    subgraph "データ主権の境界"
        A[社内文書] --> B[Embedding 処理]
        B --> C[ベクトルDB]
        A --> D[全文インデックス]
        E[ユーザークエリ] --> F[LLM API]
        F --> G[レスポンスログ]
    end
    
    subgraph "SaaS モデルの場合"
        H[外部クラウド上に全データ]
        style H fill:#f99,stroke:#333
    end
    
    subgraph "On-Premise モデルの場合"
        I[企業ネットワーク内に全データ]
        style I fill:#9f9,stroke:#333
    end

2.2 データ主権が問題になる典型的シナリオ

3. 日本企業コンプライアンスと On-Premise の必然性

3.1 個人情報保護法（APPI）への対応

2022年施行の改正個人情報保護法は、以下の点でエンタープライズ AI に直接的な影響を与える：

• 第27条（第三者提供の制限）: AI プラットフォーム事業者に個人データを提供する場合、原則として本人同意が必要
• 第28条（外国にある第三者への提供の制限）: 海外クラウドにデータを保管する場合の追加要件
• 安全管理措置義務（第23条）: データの物理的・技術的安全管理措置の実施義務

On-Premise 環境であれば、データは自社の管理下にとどまるため、第三者提供に該当しないケースが多く、コンプライアンス対応の複雑さが大幅に軽減される。

3.2 業界固有の規制

3.3 日本企業の意思決定プロセスとの整合

日本の大企業における IT 導入には、独自の組織的特性がある：

1. 稟議制度: 情報システム部門、法務部門、コンプライアンス部門の順次承認が必要
2. 部門間権限分離: 各部門がアクセスできるデータ範囲の明確な境界設定
3. ベンダー管理: 委託先の安全管理措置に対する監査義務
4. 長期安定性要求: 3-5年の運用計画に耐えるアーキテクチャであること

On-Premise は「データが自社の管理下にある」という一点で、稟議における最大のハードルを低くする。SaaS の場合に必要となる「データ処理委託契約」「安全管理措置の確認」「第三者提供該当性の法的整理」が大幅に簡素化されるためだ。

4. ネットワーク分離と閉域網対応

4.1 日本企業の典型的なネットワーク構成

graph LR
    subgraph "社内ネットワーク"
        A[業務端末] --> B[社内プロキシ]
        B --> C[Dify On-Premise]
        C --> D[社内DB / ファイルサーバー]
        C --> E[社内ベクトルDB]
    end
    
    subgraph "DMZ"
        F[リバースプロキシ]
    end
    
    subgraph "外部"
        G[LLM API<br/>OpenAI / Azure / Anthropic]
    end
    
    C -->|"制御されたAPI通信のみ"| F
    F --> G
    
    style C fill:#69b,stroke:#333,color:#fff

多くの日本企業では「社内システムはインターネットに直接接続しない」が前提であり、外部 API 呼び出しはプロキシ経由の限定的な通信のみ許可される。Dify の On-Premise は、以下の構成を可能にする：

• Knowledge Base / Vector DB は完全に社内閉域網内に配置
• LLM API 呼び出しのみがプロキシ経由で外部通信（Azure OpenAI Service の Private Endpoint 利用も可能）
• ユーザーのアクセスログ、クエリログは社内の SIEM に統合可能

4.2 完全閉域網（エアギャップ）への対応

製造業の設計部門や防衛関連企業では、インターネット接続が一切ない環境での運用が求められる場合がある。Dify の On-Premise + ローカル LLM（Ollama / vLLM 等）の組み合わせは、この要件にも対応できる：

graph TB
    subgraph "完全閉域網"
        A[Dify On-Premise] --> B[Ollama / vLLM<br/>ローカル LLM]
        A --> C[Weaviate / pgvector<br/>ローカル Vector DB]
        A --> D[PostgreSQL<br/>ローカル DB]
        E[ユーザー端末] --> A
    end
    
    F[インターネット]
    F -.->|"接続なし"| A
    
    style F fill:#f99,stroke:#333

5. ハイブリッドクラウド戦略：SaaS と On-Premise の共存

5.1 段階的導入モデル

日本企業における現実的な Dify 導入は、以下のような段階を踏むことが多い：

5.2 Dify のアーキテクチャがハイブリッドを可能にする理由

Dify の設計には、ハイブリッド構成を自然に実現できるいくつかの特徴がある：

1. 環境変数ベースの構成管理: データベース接続先、ストレージバックエンド、LLM Provider の切り替えが環境変数で完結
2. ステートレスな API / Worker: 水平スケールが可能で、クラウド・オンプレミス間での負荷分散が設計可能
3. Provider 抽象層: 同一アプリケーションが、環境に応じて Azure OpenAI（閉域網）と OpenAI API（パブリック）を切り替えられる
4. Knowledge Base の独立性: ベクトルDB の接続先を変えるだけで、ナレッジの配置場所を制御できる

6. On-Premise 運用における設計上の考慮事項

6.1 運用負荷とトレードオフ

On-Premise は「自由」を手に入れる代わりに「責任」も引き受ける：

6.2 推奨されるアーキテクチャパターン

graph TB
    subgraph "本番環境 (Kubernetes)"
        direction TB
        LB[Ingress Controller / ALB]
        
        subgraph "Application Layer"
            API1[Dify API Pod x3]
            WEB1[Dify Web Pod x2]
            WK1[Dify Worker Pod x3]
        end
        
        subgraph "Data Layer"
            PG[(PostgreSQL<br/>Primary + Replica)]
            RD[(Redis Sentinel)]
            VDB[(Vector DB<br/>Weaviate Cluster)]
            S3[(Object Storage<br/>MinIO / S3)]
        end
    end
    
    LB --> API1
    LB --> WEB1
    API1 --> PG
    API1 --> RD
    API1 --> VDB
    WK1 --> PG
    WK1 --> RD
    WK1 --> S3

6.3 監視・可観測性

On-Premise 環境では、以下の監視項目を自社で設計する必要がある：

• アプリケーションメトリクス: API レイテンシ、Worker キュー長、エラーレート
• インフラメトリクス: CPU / メモリ使用率、ディスク I/O、ネットワーク帯域
• ビジネスメトリクス: アクティブユーザー数、クエリ数、Knowledge Base ヒット率
• セキュリティ監視: 認証失敗、異常なアクセスパターン、データエクスポート操作

7. 競合製品との比較：On-Premise 対応の深さ

Dify の差別化は「OSS でありながら Enterprise Helm を提供し、かつ GUI ベースの管理画面を含む」点にある。フレームワーク型（LangChain）は柔軟だが GUI がなく、クラウドネイティブ型（Bedrock / Azure）は On-Premise に対応しない。

8. 日本市場における On-Premise の将来展望

8.1 AI ガバナンスの制度化

2024年以降、日本政府は AI ガバナンスに関する議論を加速させている。今後、以下のような規制が具体化する可能性がある：

• AI 利用におけるデータ所在地要件の明確化
• AI 出力の説明責任（Explainability）要件
• AI システムの監査証跡（Audit Trail）保存義務

これらの規制強化は、On-Premise またはプライベートクラウド上での AI プラットフォーム運用を後押しする方向に作用する。

8.2 ローカル LLM の成熟

日本語対応のローカル LLM（Llama 系、Qwen 系、国産 LLM）の性能が向上するにつれ、完全閉域網での Dify 運用が実用的な選択肢になりつつある。Dify の Provider 抽象層は、こうしたモデルの切り替えを低コストで実現する設計になっている。

まとめ

Dify が On-Premise を「付加機能」ではなく「第一級のデプロイパス」として設計している理由は、以下の3点に集約される：

1. データ主権の確保: エンタープライズ AI が扱うデータは機密性が高く、企業の管理境界内に留める必要がある
2. 日本企業のコンプライアンス要件への適合: 個人情報保護法、業界規制、稟議制度との整合性
3. ハイブリッドクラウド戦略への柔軟性: PoC から本番まで、段階的な導入パスを提供

On-Premise は「重い」選択ではない。むしろ、エンタープライズ AI を正式な業務プロセスに組み込むための必要条件である。Dify はその前提を製品アーキテクチャに織り込んだプラットフォームだと言える。

参考資料

• Deploy Dify with Docker Compose
• Kubernetes - Dify Enterprise Docs
• Resources Checklist - Dify Enterprise Docs
• 個人情報保護委員会 - 改正個人情報保護法
• FISC 安全対策基準