結論: 要件表の判定は5分で終わる。決め手は「誰が運用するか」

Dify Community Editionのセルフホストを検討するとき、最初に調べるのはたいてい必要スペックです。ただ、そこはすぐ終わります。公式が示す最低ラインは4項目しかなく、いまどきのサーバーなら大半が通過します。

判断が割れるのは、その先です。要件を満たすことと、1年後もその環境を運用できていることは別の話で、後者を決めるのは費用ではなく、更新・監視・バックアップ・障害対応を誰が持つかという体制の問題です。

この記事は、①最低要件を機械的に片付ける → ②運用責任で3つの選択肢を分ける → ③残る5項目を確認する、の順で進みます。

Difyセルフホストの判断順序を示すフロー図。第1段階は公式の最低要件4項目の判定で、CPU2コア以上、RAM4GiB以上、Dockerインストール済み、Docker Compose v2.24.0以上を確認する。ここは数分で終わる一次診断であり、不通過の場合は増設または別環境を検討して再判定する。第2段階は運用責任による選択肢の切り分けで、Dify Cloudはセットアップ不要で公式管理の環境から試せる、Community Editionは自社環境で構成を管理できるがサーバー更新監視バックアップ障害対応の担当が必要、Enterprise self-hostingは組織向け要件を公式に相談し価格と提供条件は要問い合わせ。第3段階は本番前に残る5項目で、想定同時利用数とワークフロー実行量の定義、ナレッジ用ファイルとログの保存量の見積もり、バックアップと復旧手順の試行、外部公開範囲と認証と秘密情報の管理方法の決定、更新と監視と障害対応の担当者と判断基準の決定。最低要件の通過は動き始められる下限であって運用を続けられる水準ではないことを示す。2026年8月24日にDify公式GitHubのREADMEで確認。

公式の最低要件は4項目(2026年8月24日 確認)

Dify公式GitHubのREADMEにある Quick start では、インストール前に満たすべき最低システム要件として CPU 2コア以上・RAM 4GiB以上が挙げられ、実行にあたって Docker と Docker Compose v2.24.0 以降が導入済みであることが前提とされています。

確認項目 通過条件 不足していたときの扱い
CPU 2コア以上 導入候補から一旦外す
RAM 4GiB以上 増設、または別環境を検討
Docker インストール済み 導入手順と運用責任者を先に確認
Docker Compose v2.24.0 以上 更新してから再判定

ここでいう「通過」は、公式の最低要件に合うという意味だけです。アクセスが増えたときの性能、保存容量、バックアップ、監視、障害復旧、社内のセキュリティ要件は一切含まれていません。この区別を曖昧にしたまま「要件を満たしたので進めます」と稟議に書くと、あとで前提が崩れます。

3つの選択肢を「運用責任」で分ける

最低要件を満たしても、セルフホストが自動的に適切とは限りません。Dify公式は Cloud をセットアップ不要で試せる選択肢として、Community Edition を自分の環境へ無料で設置できる選択肢として案内しています。

費用だけで比べると Community Edition が有利に見えますが、ソフトウェア利用料が無料でも、インフラ費と運用工数が0になるわけではありません。比較すべきは金額ではなく、誰が何を持つかです。

選択肢 長所 導入前に確認すること 向く状況
Dify Cloud セットアップを省き、公式が管理する環境からすぐ試せる プラン上限、データの保管場所、社内規程との整合、支払条件 まず小さく検証したい
Community Edition 自社環境で構成を自分たちで管理できる サーバー、更新、監視、バックアップ、障害対応の担当者 運用体制と要件が明確
Enterprise self-hosting 組織向けの要件を公式に相談できる 価格と提供条件は要問い合わせ 個別要件を公式と詰めたい

判断の実務的な順序としては、先に担当者を決めてから環境を選ぶほうが手戻りが減ります。「サーバーは余っているからセルフホストで」と決めたあとに運用担当が決まらず、更新されないまま放置される、という形が最もよくある失敗です。

なお、Community Edition は無料で使えますが、ライセンスは Apache 2.0 をベースに追加条件が付いた形式です。商用利用や再配布の条件は、導入前に公式リポジトリのライセンス条項をご自身で確認してください。

最低要件を満たしても、本番前に5項目が残る

一次診断を通過したら、本番候補として次の5項目を別途確認します。この段階を飛ばすと、起動できる環境と継続運用できる環境を混同したまま進むことになります。

  1. 想定同時利用数と、ワークフローの実行量を定義する
  2. ナレッジ用ファイルとログの保存量を見積もる(増え続ける前提で)
  3. バックアップと復旧手順を、小規模な環境で一度試す
  4. 外部公開の範囲、認証方法、APIキーなど秘密情報の管理方法を決める
  5. 更新・監視・障害対応の担当者と、判断基準を決める

特に3番は後回しにされがちですが、復旧を試していないバックアップは、バックアップとして数えられません。小さい環境で一度戻してみるまでは、手順が正しいかどうかは分かりません。

外部にAI導入・実装支援を依頼する場合も、この5項目を先に共有しておくと、Cloudで検証するのか、Community Editionを試すのか、公式へ個別相談へ進むのかを切り分けやすくなります。

付録: 環境の棚卸しを機械化するスクリプト(実行検証済み)

候補サーバーが数台あるときに、4項目を目視で突き合わせると見落とします。以下は、棚卸し済みの環境情報を渡すと通過可否と不足理由を返すスクリプトです。Python標準ライブラリのみで動き、環境情報を自動収集せず、外部通信も行いません。

入力するJSONの形式は次のとおりです。

[
  {
    "name": "candidate-server-a",
    "cpu_cores": 2,
    "ram_gib": 4.0,
    "docker_installed": true,
    "compose_version": "2.24.0"
  }
]

スクリプト本体です。

"""Check machine profiles against Dify's documented minimums.

This checker does not install or start Dify. It provides a deterministic
preflight for procurement and environment-screening examples.
"""

from __future__ import annotations

import argparse
import json
from pathlib import Path
from typing import Any

MIN_CPU_CORES = 2
MIN_RAM_GIB = 4.0
MIN_COMPOSE_VERSION = (2, 24, 0)


def parse_version(value: str | None) -> tuple[int, int, int] | None:
    if value is None:
        return None
    parts = value.split(".")
    if not 1 <= len(parts) <= 3 or any(not part.isdigit() for part in parts):
        return None
    numbers = [int(part) for part in parts]
    return tuple((numbers + [0, 0])[:3])


def evaluate(profile: dict[str, Any]) -> dict[str, Any]:
    reasons: list[str] = []
    if profile["cpu_cores"] < MIN_CPU_CORES:
        reasons.append("cpu_below_2_cores")
    if profile["ram_gib"] < MIN_RAM_GIB:
        reasons.append("ram_below_4_gib")
    if not profile["docker_installed"]:
        reasons.append("docker_missing")

    compose = parse_version(profile.get("compose_version"))
    if compose is None:
        reasons.append("compose_version_missing_or_invalid")
    elif compose < MIN_COMPOSE_VERSION:
        reasons.append("compose_below_2_24_0")

    return {
        "name": profile["name"],
        "eligible": not reasons,
        "reasons": reasons,
    }


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("input", type=Path)
    args = parser.parse_args()
    profiles = json.loads(args.input.read_text(encoding="utf-8"))
    results = [evaluate(profile) for profile in profiles]
    print(json.dumps(results, ensure_ascii=False, indent=2))
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

実行は次の1行です。

python check_dify_requirements.py input.json

境界値を含む架空7環境で、期待した判定と実際の出力が一致するかを確認しました。実データ・顧客情報・認証情報・Difyの実アカウントは使っていません。

架空環境 条件 期待 実出力
minimum_exact 2コア・4GiB・Dockerあり・Compose 2.24.0 通過 通過
cpu_shortage CPU 1コア 不通過 不通過
ram_shortage RAM 3.9GiB 不通過 不通過
docker_missing Dockerなし 不通過 不通過
compose_missing Compose版が不明 不通過 不通過
compose_too_old Compose 2.23.3 不通過 不通過
above_minimum 8コア・16GiB・Dockerあり・Compose 2.30.1 通過 通過

結果は7/7一致でした。不通過時は cpu_below_2_cores や compose_below_2_24_0 のように理由が配列で返るため、どこを直せば候補に戻るかがそのまま分かります。

このスクリプトが確認しているのは、公式に書かれた4つの数値との比較だけです。Difyのインストール、起動、負荷、ディスク、可用性、バックアップ、セキュリティはいずれも検証していません。台数が少なければ、手で確認しても同じ結果になります。

なお公式の要件は更新されることがあります。当メディアでは7日後・14日後・30日後に公式READMEと料金ページを再確認し、CPU・RAM・Compose版・Cloudの案内に差分があれば、スクリプトと本文を同時に更新します。

VERIFIED
動作確認日: 2026.08.24 / 環境: Windows / Python 3.11.1(標準ライブラリのみ) / ステータス: passed

よくある質問

CPU 2コア・RAM 4GiBを満たせば本番運用できますか?
いいえ。これは公式が示す最低システム要件を通過したという意味に限られます。想定アクセス量に対する性能、保存容量、バックアップ、可用性、セキュリティはいずれも別に評価が必要です。最低要件は「動き始められる下限」であって「運用を続けられる水準」ではありません。
Docker Composeの版が分からない場合はどうしますか?
判定上は不通過として扱ってください。`docker compose version` で確認してから再判定し、v2.24.0未満であれば更新計画を先に決めます。版が不明なまま進めると、起動時ではなく設定ファイルの解釈で問題が出るため、原因の切り分けが難しくなります。
このスクリプトはDifyをインストールしますか?
いいえ。JSONで渡した値を静的に判定して結果を出力するだけで、Difyのインストール、外部通信、環境の変更は一切行いません。環境情報を自動収集することもないため、棚卸し済みの値を手で入力する必要があります。
AI導入・活用支援

AI導入・実装のどこから着手するかを、30分で整理します

支援内容・進め方・料金の考え方を、30分のオンラインで整理します。フォームは3項目、送信は30秒です。

無料で相談する(30秒で送信)

先にサービス内容と料金を見る →

無料で相談してみる →