Difyの自社環境導入にチャレンジした話

はじめに

ChatGPTやClaudeなどの生成AIがすっかり身近になってきた今、
「社内でもこういうツールを使っていけたらな」と思う機会が増えてきました。

でも、社外サービスにそのまま社内データを流すのは少し抵抗があります。
セキュリティや情報管理の観点で、どうしても”社外クラウドには置けない”データってありますよね。

そこで最近よく耳にする「Dify（ディフィ）」というAIプラットフォームです。

Dockerで動かせますし、クラウドを経由せずに自社サーバー上でChatGPT的な仕組みを構築できるという点が魅力的でした。

Dify自体は使用したことはありますが、構築はしたことがなかったので貴重な挑戦でした。

この記事でやること

この記事では、実際に自社のテスト環境にDifyを導入してみた記録をまとめます。
目的は「PoC（概念実証）」、つまり本格導入の前に”ちゃんと動くのか確かめる”ことです。

具体的にはこんな流れで進めました↓

• Difyの概要をざっくり理解します
• テスト用VMにDocker構成を準備します
• 決定したドメインでDifyを起動します
• 実際に触ってみて感じたことをまとめます

Difyとは

公式解説はこちら

一言で言うと、 ChatGPTのような生成AIアプリを、ノーコードで作れるオープンソースのプラットフォームです。

Difyを使うと、ブラウザ上で

プロンプトを編集して、AIモデルを選んで、返答の流れを設計して、そのままアプリとして公開できます

という、まるで「ChatGPTを自分で作る」ような体験ができます。

なぜ「自社環境」で？

今回の記事の目的： 「自社環境でDifyを立ててみた記録」を残すことです。

ChatGPTを始めとする生成AIツールはクラウドで気軽に触れますが、
「社内データを扱う」となるとやっぱりオンプレ（社内環境）で動かしたいケースが多いです。

たとえば──

• 社内管理システムとのデータ連携
• 業務データを分析・整理するためのワークフロー構築
• 登録処理や分析時にAIによる自動処理を組み込むこと

こうした用途では、クラウドを通さず自社サーバーで完結するAI基盤が理想的です。
Difyはそのニーズにちょうどフィットする存在です。

実際にやってみました

1. 今回の構築環境について

• テスト用VM
• 環境構成：Docker + docker-compose
• ドメイン設定済みのサブドメインを利用

Docker Composeで構築することで、アプリ・DB・バックエンドをまとめて立ち上げられるのが便利でした。
初期設定も比較的シンプルで、慣れていれば1時間もあれば起動までいける印象です（私は時間かかりましたが）。

2. Docker構成ファイルの準備

公式リポジトリ（https://github.com/langgenius/dify）
から docker-compose.yaml を取得します。

git clone https://github.com/langgenius/dify.git
cd dify/docker

.env ファイルを準備して環境変数を設定します。

cp .env.example .env
nano .env

3. Nginx設定ファイル（dify.conf）

今回は リバースプロキシ構成 にしており、外部からのアクセスはNginxを経由させます。
以下が実際に使用したものを一部変更した設定です↓

server {
  listen 80;
  server_name dify.test; # ← 実際のドメインは社内向けに変更
  location /console/api {
    proxy_pass http://api:5001;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
  }
  location /api {
    proxy_pass http://api:5001;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
  }
  location /v1 {
    proxy_pass http://api:5001;
    proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
  }
  location / {
    proxy_pass http://web:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

この設定で、

• /api, /v1, /console/api → バックエンド（APIサーバー）
• / → フロントエンド（Web UI）

にルーティングされます。

4. コンテナ起動

docker-compose up -d

完了後、ブラウザでhttp://localhost

にアクセスして、ログイン画面が表示されれば成功です。

• ※.local や .test ドメインをローカルで使う場合は、アクセスするマシン側の hosts ファイルにドメインとIPアドレスを手動で登録する必要があります。

今回作成したものは以下のようになります。

Nginx → Web (Next.js)
        ↓
       API (FastAPI)
        ↓
  ┌───────────────┬───────────────┬───────────────┐
  │PostgreSQL(DB) │ Redis(Cache)  │ Weaviate(Vector DB)
  └───────────────┴───────────────┴───────────────┘
          │
     Worker / Beat / Plugin Daemon / Sandbox / SSRF Proxy

各コンテナの役割

コンテナ    イメージ    　　　　　　　　　役割
nginx    nginx:latest    リバースプロキシ（API/Webの振り分け）
web    langgenius/dify-web    フロントエンドUI（Next.js）
api    langgenius/dify-api    バックエンドAPI（FastAPI）
db    postgres:15-alpine    メインデータベース
redis    redis:6-alpine            キャッシュ・セッション管理
weaviate    semitechnologies/weaviate    ベクトルDB（RAG機能用）
sandbox    langgenius/dify-sandbox    コード実行環境
plugin_daemon    langgenius/dify-plugin-daemon    プラグイン管理
worker / beat    langgenius/dify-api    Celeryバックグラウンド処理
ssrf_proxy    ubuntu/squid    SSRF対策プロキシ

親ディレクトリ/
└── dify.test/　# ← 実際のドメインは社内向けに変更
    ├── docker-compose.yml
    ├── conf/
    │   └── dify.conf             # Nginx設定
    ├── ssrf_proxy/
    │   ├── squid.conf            # SSRF対策設定
    │   └── docker-entrypoint.sh  # 起動スクリプト
    ├── volumes/sandbox/
    │   ├── conf/
    │   └── dependencies/
    └── reverse-proxy/apache/
        └── site/
            └── dify.test.conf

今回の構築で感じたポイント

段階的構築（5コンテナ→11コンテナ）で安定性を確保できました。

ログ確認と環境変数の整合性が成功の鍵です。

今後は以下の発展も可能だと思います↓

• 社内AIワークフローの自動化
• RAGを使った社内ドキュメント検索
• 独自プラグイン開発

学んだこと

今回の構築を通して感じたのは、
「Difyは思ったよりも柔軟ですが、でも”Docker Compose理解力”が問われる」ということです。

1. コンテナ間の依存関係を明確にすることが大事

DifyはAPI・Web・Worker・Plugin・DBなどが密に連携して動くため、
depends_on や environment の整合性を取らないと、ほんの少しの設定ミスでも簡単に起動エラーになります。

実際、最初のトライでは plugin_daemon の認証キー不一致や Redis の接続ミスに何度もハマりました。
でも一度正しく構成を理解すると、ログを追えばほぼ確実に自己解決できるようになります。

2. SSRF Proxy（Squid）の有効性

SSRF（サーバーサイドリクエストフォージェリ）対策をDocker内に閉じて実装できたのは大きな学び。
DifyはAIコード実行環境を内包しているので、セキュリティを意識したこの構成は本番を意識したPoCとして優秀でした。
「AIは便利だけど、セキュリティ前提で設計する」——この意識が強まりました。

3. 永続化とデータ保護のバランス
今回使うデータは以下の通りです。

• PostgreSQLデータベース
• アップロードファイル・ナレッジベース
• ベクトルデータベース
• プラグインデータ

一つのディレクトリに、このデータをまとめて永続化したことで、
リビルドしても環境がすぐ再現できるようになりました。
ただ、データの権限やパーミッション設定はかなりシビア。
便利さと安全性のバランスをどう取るかが今後の課題です。

4. 概念実証の段階では「最小構成 → 段階拡張」が正解

最初からフル構成を立てようとすると確実に詰まります（笑）。
最小構成（5コンテナ）で起動確認 → 順にWorker・Plugin・Sandboxを追加していく流れが一番安定。
「小さく動かして、確実に育てる」のがDify導入のコツだと思いました。

まとめ

Difyは社内AI基盤のPoCに最適
→ Docker Composeで完結し、オンプレ環境でもChatGPT的体験が再現可能。

構築難易度は中級レベル
→ Docker・ネットワーク・環境変数管理の理解があればスムーズに進む。

拡張性が高く、セキュアに運用できる
→ RAGやプラグイン機能を使えば、社内データ連携AIがすぐ作れる。

「社内AIの自前運用」を実現する一歩に
→ セキュリティを保ちながら生成AIの恩恵を享受できるのは大きい。

Dify構築の過程は、単なるツール導入ではなく、
「自分の手でAI基盤を育てていく第一歩」 だったと感じています。

これをきっかけに、さらに社内開発環境を整えるための仕組みづくりに挑戦したいと感じました。