CHAPTER 02

Dify実務辞典 — アーキテクチャとコンポーネント構成

Difyを構成する8コンポーネント(フロント/APIサーバ/Worker/Plugin Daemon/SSRF Proxy/DB/Vector DB/Redis)の役割と、セルフホスト時に描くべきシステム図の一覧

ステータス: 🟢 現役 最終更新: 2026-07-13 作成者: にしむら(学習キュレーター)

このファイルでできること

Difyをセルフホストで動かすとき、内部でどんな部品(コンテナ)が動いていて、それぞれが何を担うかを把握できる。003事業でインフラ設計・顧客へのシステム説明・障害切り分けをするときの参照元。

使うタイミング:

  • セルフホスト構成を設計・見積もりする時
  • 顧客に「どんなサーバーが必要か」を説明する時
  • 障害時にどのコンポーネントを疑うか切り分ける時

入門を先に読みたい人へ: 概念だけ知りたいなら入門教科書 ../05-cloud-vs-selfhost.md を先に。このファイルは実装レベルの内訳です。


1. Difyとは(実務前提の再確認)

「Define Your AI」— LangGenius社が開発するOSSのLLMアプリ開発プラットフォーム。コードを書かずにRAGパイプライン・AIエージェント・ワークフローを構築・運用できる。セルフホストするとこれらの機能が複数のコンテナに分かれて動く。

2. コンポーネント構成(8つの部品)

| コンポーネント | 技術 | 役割 | |---|---|---| | Webフロントエンド | Next.js | ビジュアルエディタ・チャットUI・管理画面 | | APIサーバ | Python / Flask | RESTful API・ストリーミング処理 | | Celery Worker | Python / Celery + Redis | 非同期タスク(ドキュメントインデックス等) | | Plugin Daemon | 独立プロセス | モデル・ツールプラグインのアウトプロセス実行 | | SSRF Proxy | Squid | HTTPノードからの外部リクエスト中継・SSRF防止 | | DB | PostgreSQL | 会話履歴・ナレッジメタデータ・設定の永続化 | | Vector DB | Weaviate(既定) / Qdrant / Milvus 他14種以上 | ベクトル検索 | | キャッシュ / MQ | Redis | Celeryブローカー・セッション管理 |

公式構成のコンテナ数: Docker Composeでは11コンテナ(コア5 + 依存6)が動き、最小要件はCPU 2コア・RAM 4GiB(公式ドキュメント / 2026年7月時点)。Docker Composeのほか Kubernetes・Terraform・AWS CDK・Alibaba Cloud でのデプロイにも対応。

なぜコンポーネントが分かれているのか

  • ドキュメントのインデックス作成は重い処理 → APIサーバを止めないよう Celery Worker に逃がす(非同期化)
  • プラグインは別プロセス → プラグインがクラッシュしても本体が落ちない(Plugin Daemon の役割)
  • SSRF Proxy → ワークフローのHTTPノードが社内ネットワークを勝手に叩く攻撃(SSRF)を防ぐ関所。003のようにセキュリティが前提の事業では特に重要

3. セルフホスト vs クラウド(構成観点)

| 比較軸 | セルフホスト(Community Edition) | Dify Cloud | |---|---|---| | データ管理 | 自社インフラ上で完全管理 | Dify社のSaaS上に保存 | | コスト | インフラ費用のみ | 従量課金 | | カスタマイズ | フル(ソースコード変更可) | 制限あり | | マルチテナント | 自前で設計が必要 | プラン内で提供 | | 立ち上げ速度 | Docker Compose / Helm で数時間 | 即日 |

クラウド/セルフホストの選択基準(ビジネス観点)は license.md と入門 ../05-cloud-vs-selfhost.md を参照。

4. 描くべきシステム図(顧客説明・設計用)

003事業で顧客説明や自分の理解のために、draw.io 等で図に起こしておくべきもの。

優先度A — 必ず作る

| 図 | 内容 | 用途 | |---|---|---| | システムアーキテクチャ図 | Dify全コンポーネントと接続関係 | インフラ設計・顧客説明 | | RAGパイプライン図 | ドキュメント投入→チャンキング→Embedding→Retrieval→LLM回答のフロー | RAGの仕組みを顧客に説明 | | 顧客環境分離図 | 顧客ごとにインスタンスを分ける物理配置 | 「データは混じらないか?」への回答 |

優先度B — 推奨

| 図 | 内容 | 用途 | |---|---|---| | ワークフローノード構成図 | ユーザー入力→ナレッジ検索→LLM→出力のフロー例 | 導入後にできることのデモ説明 | | デプロイフロー図 | Docker Compose / Helm での展開フロー | 納品・引き渡し時のSOP | | 権限・ロール設計図 | オーナー・管理者・ユーザーの権限範囲 | 組織向け提案時 |

優先度C — 余裕があれば

| 図 | 内容 | |---|---| | 会話履歴データフロー図 | チャット→API→PostgreSQL→履歴取得のデータの流れ | | コスト試算モデル図 | インスタンス数×顧客数×トークン使用量のコスト構造 | | セキュリティ境界図 | SSRF Proxy・ネットワーク分離・認証フロー |


関連ドキュメント