Difyのパラメータ設定完全ガイド！環境変数と最適化のポイント

Difyをセルフホスト（Docker）で運用する際、デフォルトの設定のままでは「大きなファイルがアップロードできない」「長いワークフローがタイムアウトする」といった問題に直面することがあります。

この記事では、Difyの挙動を制御する重要な環境変数（パラメータ）の意味と、安定稼働のための推奨設定値について、カテゴリ別に詳しく解説します。

1. 基本接続・URL設定

Difyの各サービス（フロントエンド、API、コンソール）が相互に通信するためのURL設定です。SSL化やドメイン設定を行う場合に必須となります。

変数名	説明	設定例
CONSOLE_API_URL	コンソールAPIのバックエンドURL。認証コールバック等に使用。	https://api.console.dify.ai
CONSOLE_WEB_URL	コンソールWebのフロントエンドURL。CORS設定等に使用。	https://console.dify.ai
SERVICE_API_URL	サービスAPIのURL。フロントエンドでの表示に使用。	https://api.dify.ai
APP_API_URL	Webアプリ（WebApp）APIのバックエンドURL。	https://app.dify.ai
APP_WEB_URL	WebアプリのURL。ファイルプレビュー等に使用。	https://udify.app/
FILES_URL	ファイルダウンロード用のURLプレフィックス。 ファイルプレビューやダウンロードURLをフロントエンドに表示したり、マルチモーダルモデルの入力として使用します。他人による偽造を防ぐため、画像プレビューURLは署名付きで、5分の有効期限があります。

2. サーバー・パフォーマンス設定

APIサーバーの動作モードやワーカー数、ログレベルを制御します。

変数名	説明
MODE	起動モード。Docker起動時のみ有効で、ソースコード起動では無効。 ・api: APIサーバーを起動します。 ・worker: 非同期キューのワーカーを起動します。
DEBUG	デバッグモード（デフォルト: false）。ローカル開発時は true 推奨。
LOG_LEVEL	ログ出力レベル（デフォルト: INFO）。本番環境では ERROR 推奨。
SECRET_KEY	セッションの暗号化キー。初回起動時に必ず設定してください。 openssl rand -base64 42を使用して強力なキーを生成できます。

変数名	説明
FLASK_DEBUG	Flaskのデバッグモード。オンにすると、インターフェースでトレース情報が出力され、デバッグが容易になります。
DEPLOY_ENV	デプロイ環境。 ・PRODUCTION（デフォルト）: プロダクション環境。 ・TESTING: テスト環境。フロントエンドページにはテスト環境を示す明確な色の識別が表示されます。
MIGRATION_ENABLED	trueに設定した場合、コンテナ起動時に自動的にデータベースのマイグレーションが実行されます。dockerによる起動時にのみ有効で、ソースコード起動では無効です。ソースコード起動の場合、apiディレクトリで手動でflask db upgradeを実行する必要があります。
CHECK_UPDATE_URL	バージョンチェックポリシーを有効にするかどうか。falseに設定した場合、https://updates.dify.aiを呼び出してバージョンチェックを行いません。現在、国内から直接CloudFlare Workerのバージョンインターフェースにアクセスできないため、この変数を空に設定すると、このインターフェースの呼び出しをブロックできます。
TEXT_GENERATION_TIMEOUT_MS	デフォルト値は60000 (milliseconds). 一部のプロセスが進行中にタイムアウトの原因で全部のサービスが利用できなくなるのを防ぐために、テキストの生成やワークフロー進行中にタイムアウトの時間を指定するために使用されます。
CSP_WHITELIST	コンテンツセキュリティポリシー (CSP) ホワイトリスト。デフォルトでは有効になっていません。この変数に許可されるドメイン名のリストを入力すると、この変数が自動的に有効になり、潜在的な XSS 攻撃を減らすのに役立ちます。オンにすると、ホワイトリストには次のドメイン名が自動的に含まれます。

コンテナ・ワーカー設定（重要）

パフォーマンスに直結する設定です。

変数名	説明
SERVER_WORKER_AMOUNT	APIサーバーのワーカー数。すなわちgevent workerの数。 計算式: CPUコア数 x 2 + 1 詳細はこちら：https://docs.gunicorn.org/en/stable/design.html#how-many-workers
CELERY_WORKER_AMOUNT	非同期処理を行うCeleryワーカーの数（デフォルト: 1）。負荷に応じて増やしてください。
GUNICORN_TIMEOUT	リクエスト処理のタイムアウト時間（デフォルト: 200）。 推奨設定: 長時間の生成処理を行う場合は 360 以上に設定推奨。

変数名	説明
DIFY_BIND_ADDRESS	APIサービスのバインドアドレス。デフォルト：0.0.0.0、すべてのアドレスからアクセス可能にします。
DIFY_PORT	APIサービスのバインドポート番号。デフォルト5001。
SERVER_WORKER_CLASS	デフォルトはgevent。Windowsの場合、syncまたはsoloに切り替えることができます。
CELERY_WORKER_CLASS	SERVER_WORKER_CLASSと同様に、デフォルトはgevent。Windowsの場合、syncまたはsoloに切り替えることができます。
HTTP_PROXY	HTTPプロキシのアドレス。国内からOpenAIやHuggingFaceにアクセスできない問題を解決するために使用されます。注意点：プロキシがホストマシンにデプロイされている場合（例：http://127.0.0.1:7890）、このプロキシアドレスはローカルモデルに接続する場合と同様に、dockerコンテナ内のホストマシンアドレスを使用する必要があります（例：http://192.168.1.100:7890またはhttp://172.17.0.1:7890）。
HTTPS_PROXY	HTTPSプロキシのアドレス。国内からOpenAIやHuggingFaceにアクセスできない問題を解決するために使用されます。HTTPプロキシと同様に設定します。 *.sentry.io http://localhost:* http://127.0.0.1:* https://analytics.google.com https://googletagmanager.com https://api.github.com

3. ワークフロー実行・制限の最適化

複雑なワークフローを運用する場合、最も調整が必要になる項目です。デフォルト値は低めに設定されているため、ユースケースに合わせて緩和してください。

変数名	説明	デフォルト	推奨・調整目安
WORKFLOW_MAX_EXECUTION_STEPS	ワークフローの最大ステップ数。無限ループ防止のため極端に大きくしないこと。	500	必要に応じて調整
WORKFLOW_MAX_EXECUTION_TIME	ワークフローの最大実行時間（秒）。	1200	大規模処理なら延長
WORKFLOW_CALL_MAX_DEPTH	ワークフローのネスト（再帰呼び出し）の最大深度。	5	複雑な構造なら10程度
APP_MAX_ACTIVE_REQUESTS	単一アプリの最大同時リクエスト数（0は無制限）。	0	過負荷防止なら20程度 10-20程度で制限すべき

4. ファイルアップロード制限の解除

「ファイルサイズが大きすぎてアップロードできない」というエラーが出る場合、以下の値を変更します。

変数名	説明
UPLOAD_FILE_SIZE_LIMIT	通常ファイルの最大サイズ（MB）。デフォルト 15。
UPLOAD_IMAGE_FILE_SIZE_LIMIT	画像ファイルの最大サイズ（MB）。デフォルト 10。
UPLOAD_VIDEO_FILE_SIZE_LIMIT	動画ファイルの最大サイズ（MB）。デフォルト 100。
UPLOAD_AUDIO_FILE_SIZE_LIMIT	音声ファイルの最大サイズ（MB）。デフォルト50。
WORKFLOW_FILE_UPLOAD_LIMIT	一度にアップロード可能なファイル数。デフォルト 10。

5. コード実行・HTTPリクエストの調整

PythonコードブロックやHTTPリクエストブロックで、大量のデータを扱う場合にエラーになる設定値です。

変数名	説明	デフォルト	推奨・調整目安
CODE_MAX_STRING_LENGTH	コードノードで処理可能な最大文字列長。	80,000	スクレイピング等は800,000へ拡張推奨
HTTP_REQUEST_NODE_MAX_TEXT_SIZE	HTTPリクエストのテキスト最大サイズ。	1MB	3MB以上へ拡張推奨
HTTP_REQUEST_MAX_READ_TIMEOUT	HTTPリクエストの読み取りタイムアウト（秒）。	600	外部APIが遅い場合は延長

6. データベース・ストレージ設定

データベース (PostgreSQL)

データベースにはPostgreSQLを使用します。public schemaを使用してください。

変数名	説明
DB_USERNAME	ユーザー名。PostgreSQLの接続情報。
DB_PASSWORD	パスワード。PostgreSQLの接続情報。
DB_HOST	データベースホスト
DB_PORT	データベースポート番号。デフォルト5432
DB_DATABASE	データベース名
SQLALCHEMY_POOL_SIZE	データベース接続プールのサイズ。デフォルトは30接続。同時アクセスが多い場合は増やします。
SQLALCHEMY_POOL_RECYCLE	データベース接続プールのリサイクル時間。デフォルト3600秒。
SQLALCHEMY_ECHO	SQLを出力するかどうか。デフォルトはfalse。

Redis 設定

このRedis設定はキャッシュおよび対話時のpub/subに使用されます。

変数名	説明
REDIS_HOST	Redisホスト。Redisの接続情報。キャッシュやPub/Subに使用。
REDIS_PORT	Redisポート。デフォルト6379。Redisの接続情報。キャッシュやPub/Subに使用。
REDIS_DB	Redisデータベース。デフォルトは0。セッションRedisおよびCeleryブローカーとは異なるデータベースを使用してください。
REDIS_USERNAME	Redisユーザー名。デフォルトは空
REDIS_PASSWORD	Redisパスワード。デフォルトは空。パスワードを設定することを強く推奨します。
REDIS_USE_SSL	SSLプロトコルを使用して接続するかどうか。デフォルトはfalse
REDIS_USE_SENTINEL	Redis Sentinelを使用してRedisサーバーに接続
REDIS_SENTINELS	Sentinelノード、フォーマット：<sentinel1_ip>:<sentinel1_port>,<sentinel2_ip>:<sentinel2_port>,<sentinel3_ip>:<sentinel3_port>
REDIS_SENTINEL_SERVICE_NAME	Sentinelサービス名、Master Nameと同じ
REDIS_SENTINEL_USERNAME	Sentinelのユーザー名
REDIS_SENTINEL_PASSWORD	Sentinelのパスワード
REDIS_SENTINEL_SOCKET_TIMEOUT	Sentinelのタイムアウト、デフォルト値：0.1、単位：秒

Celery 設定

CELERY_BROKER_URL フォーマットは以下の通りです。

（直接接続モード） 
redis://<redis_username>:<redis_password>@<redis_host>:<redis_port>/<redis_database>
例：redis://:difyai123456@redis:6379/1 
(Sentinelモード)　sentinel://<sentinel_username>:<sentinel_password>@<sentinel_host>:<sentinel_port>/<redis_database>
 例：sentinel://localhost:26379/1;sentinel://localhost:26380/1;sentinel://localhost:26381/1

変数名	説明
ROKER_USE_SSL	trueに設定した場合、SSLプロトコルを使用して接続します。デフォルトはfalse。
CELERY_USE_SENTINEL:	trueに設定すると、Sentinelモードが有効になります。デフォルトはfalse
CELERY_SENTINEL_MASTER_NAME	Sentinelのサービス名、すなわちMaster Name
CELERY_SENTINEL_SOCKET_TIMEOUT	Sentinelへの接続タイムアウト、デフォルト値：0.1、単位：秒

CORS 設定

フロントエンドのクロスオリジンアクセスポリシーを設定するために使用します。

変数名	説明
CONSOLE_CORS_ALLOW_ORIGINS	コンソールのCORSクロスオリジンポリシー。デフォルトは*、すべてのドメインがアクセス可能です。
WEB_API_CORS_ALLOW_ORIGINS	WebアプリのCORSクロスオリジンポリシー。デフォルトは*、すべてのドメインがアクセス可能です。

詳細な設定については、次のガイドを参照してください：クロスオリジン/認証関連ガイド

ベクトルデータベース

VECTOR_STORE 変数で使用するDBを指定し、対応する接続情報を設定します。

• weaviate: WEAVIATE_ENDPOINT, WEAVIATE_API_KEY
• qdrant: QDRANT_URL, QDRANT_API_KEY
• milvus: MILVUS_URI, MILVUS_TOKEN

ファイルストレージ

データセットのアップロードファイル、チーム/テナントの暗号化キーなどのファイルを保存するために使用します。

デフォルトはローカルですが、S3互換ストレージへの変更が推奨されます。

• STORAGE_TYPE: local, s3, azure-blob 等から選択。
• S3設定: S3_ENDPOINT, S3_BUCKET_NAME, S3_ACCESS_KEY, S3_SECRET_KEY を設定。

ナレッジベース設定

変数名	説明
UPLOAD_FILE_SIZE_LIMIT	アップロードファイルのサイズ制限。デフォルトは15M。
UPLOAD_FILE_BATCH_LIMIT	一度にアップロードできるファイル数の上限。デフォルトは5個。
ETL_TYPE	使用可能な列挙型は以下を含みます： dify: Dify独自のファイル抽出ソリューション Unstructured: Unstructured.ioのファイル抽出ソリューション
UNSTRUCTURED_API_URL	ETL_TYPEがUnstructuredの場合、Unstructured APIパスの設定が必要です。 例：http://unstructured:8000/general/v0/general
TOP_K_MAX_VALUE	RAG の最大の上位 k 値。デフォルトは 10。

マルチモーダルモデル設定

変数名	説明
MULTIMODAL_SEND_IMAGE_FORMAT	マルチモーダルモデルの入力時に画像を送信する形式。デフォルトはbase64、オプションでurl。urlモードでは呼び出しの遅延がbase64モードよりも少なく、一般的には互換性が高いbase64モードを推奨します。urlに設定する場合、FILES_URLを外部からアクセス可能なアドレスに設定する必要があります。これにより、マルチモーダルモデルが画像にアクセスできるようになります。
UPLOAD_IMAGE_FILE_SIZE_LIMIT	アップロード画像ファイルのサイズ制限。デフォルトは10M。

Sentry 設定

アプリの監視およびエラーログトラッキングに使用されます。

変数名	説明
SENTRY_DSN	Sentry DSNアドレス。デフォルトは空。空の場合、すべての監視情報はSentryに報告されません。
SENTRY_TRACES_SAMPLE_RATE	Sentryイベントの報告割合。例えば、0.01に設定すると1%となります。
SENTRY_PROFILES_SAMPLE_RATE	Sentryプロファイルの報告割合。例えば、0.01に設定すると1%となります。

Notion 統合設定

Notion統合設定。変数はNotion integrationを申請することで取得できます：https://www.notion.so/my-integrations

変数名	説明
NOTION_CLIENT_ID
NOTION_CLIENT_SECRET

メール関連の設定

変数名	説明
MAIL_DEFAULT_SEND_FROM	送信者のメール名,（例：no-reply no-reply@dify.ai）、必須ではありません。
RESEND_API_KEY	ResendメールプロバイダーのAPIキー。APIキーから取得できます。
SMTP_SERVER	SMTPサーバーアドレス
SMTP_PORT	SMTPサーバポートnumber
SMTP_USERNAME	SMTP ユーザー名
SMTP_PASSWORD	SMTP パスワード
SMTP_USE_TLS	TLSを使用するかどうか, デフォルトは false
MAIL_DEFAULT_SEND_FROM	送り人のメールアドレス,（例：no-reply no-reply@dify.ai）、必須ではありません。

7. コンフィグパラメータ最適化

Difyコミュニティ版の構築・運用において、最も頻繁に問題となるのがアプリケーションコンフィグの設定で、デフォルト設定のままでの複雑なワークフロー実行は、上限値超過によるエラーが発生しやすいです。

ここでは、コミュニティ版Difyをクラウド環境にデプロイし大規模に使い始める際に、まずは調整・最適化した方が良いとコンフィグパラメータをピックアップして解説します。

Frontendリソースの上限値最適化

Frontendで気をつけるべきポイントは2つだけ: APIのURLおよびアプリ実行画面タイムアウト、になります。
対象となるファイルはgithubのdifyソースコードの/web/.env.exampleです。

APIリソースのURL設定
以下2点の設定が必要ですが、FrontendリソースとAPIリソースが同一サーバに配置されているならこのままで問題ありません。もしFrontend、API、sandboxなどそれぞれ別サーバに分散してデプロイしている場合は、localhostを適切な宛先で置き換えます。例えばAWSの場合、内部ロードバランサのDNSやECSのサービスコネクタで定義されたホスト名を設定します。

# The base URL of console application, refers to the Console base URL of WEB service if console domain is
# different from api or web app domain.
# example: http://cloud.dify.ai/console/api
NEXT_PUBLIC_API_PREFIX=http://localhost:5001/console/api
# The URL for Web APP, refers to the Web App base URL of WEB service if web app domain is different from
# console or api domain.
# example: http://udify.app/api
NEXT_PUBLIC_PUBLIC_API_PREFIX=http://localhost:5001/api

アプリケーション個別実行画面の表示タイムアウト

# テキスト生成のタイムアウト（ミリ秒）
NEXT_PUBLIC_TEXT_GENERATION_TIMEOUT_MS=60000

• デフォルト値（10分）では大規模ワークフロー実行時に不十分
• 弊社設定: 60分
• 注意: SaaS版では調整不可

なお、Chatflowや、ストリーム的にレスポンスが返却される作りのワークフローの場合、このパラメータが調整不可能でも困ることはありませんので、デフォルト値でも問題ありません。

8. コード実行環境設定

ワークフローのコードノードまたはテンプレートノードの設定値のうち、特に重要なものを取り上げます。

設定項目	説明	デフォルト値
CODE_MAX_STRING_LENGTH	処理可能な最大文字列長。大幅に調整すべきパラメータです。ファイルを読み込みテキスト変換し処理している場合などで、ここにヒットするケースがあります。大きいファイルを扱うケースは10倍の800,000でも小さいためユースケースに応じてさらに大きくすることも検討します。弊社では800,000をデフォルト、一部ユースケース専用デプロイでさらに巨大な値に設定しています。	80,000
TEMPLATE_TRANSFORM_MAX_LENGTH	テンプレート変換時の最大文字列長。jinja2を使うテンプレードノードを用いて巨大な出力をする際にエラーになるケースがあります。弊社では800,000に設定しています。	80,000
CODE_MAX_OBJECT_ARRAY_LENGTH	処理可能なオブジェクト配列の最大長。コードノードの出力がオブジェクト配列の場合に、その配列長の最大値のこと。また、ネストされている場合はネスト先のオブジェクト配列にも適用されます。30は小さすぎるため、長くすることをオススメしますが、長すぎるとメモリを大きく消費されるため、運用しつつ調整必要になります。弊社では30に設定していますが、巨大なワークフローを実行する少人数チーム専用のDifyでは100まで拡張しています。	30
CODE_MAX_DEPTH	CODEノードにおけるObjectのネストの最大の深さ。複雑なワークフローを書いていると時々”Depth limit $5 reached, object too deep.”というエラーに遭遇します。5でもほぼ問題はないですが弊社では10で設定しています。	5

9. APIツール設定

ワークフローのAPIツールノードの設定値のうち、特に重要なものを取り上げます。

設定項目	説明	デフォルト値
API_TOOL_DEFAULT_READ_TIMEOUT	APIリクエストの読み取りタイムアウト（秒）。ツール呼び出しでどのような拡張ツールを導入しているか、に依存しますが、60秒は短すぎます。弊社の場合、今後、データ操作系のツール連携が増えていく見込みですので、現在は600、チームによっては将来的に1800まで拡張する予定です。	60

HTTPリクエスト設定

ワークフローのHTTPノードの設定値のうち特に重要なものを取り上げます。

設定項目	説明	デフォルト値
HTTP_REQUEST_MAX_READ_TIMEOUT	HTTPリクエストの最大読み取り待機時間（秒）。長くする必要性はないと思いますが、もしDifyからn8nやDifyからDifyのワークフローをコールするようなケースでは、600秒ですと不足するケースはあります。弊社では一部のユースケース向けのDifyで今後拡張する予定です。	600
HTTP_REQUEST_NODE_MAX_TEXT_SIZE	HTTPリクエストのテキストデータ最大サイズ（バイト）。スクレイピングで利用しているケースでは1MBは小さすぎますので数倍に拡張する必要があります。弊社の場合、SaaS版Difyで最もエラーを引き起こした要因の一つで、3MBまで拡張しています。	1,048,576（1MB）
HTTP_REQUEST_NODE_MAX_BINARY_SIZE	HTTPリクエストのバイナリデータ最大サイズ（バイト）。上記のバイナリデータ版ですが、こちらもスクレイピングでファイルダウンロードがあるケースではやや小さいと思いますのでユースケースによっては調整必須となります。弊社では20MBまで拡張しています。	10,485,760（10MB）

セキュリティ設定

Dify全般のセキュリティ関連設定のうち、特に重要なものを取り上げます。

設定項目	説明	デフォルト値
LOGIN_LOCKOUT_DURATION	ログイン失敗時のロック解除までの時間(秒)。デフォルト24時間、かつ、それが画面上に表示されないため、Difyコミュニティ版の試験運用を開始して1時間以内で苦情が複数出ました。調整必須となります。ただし、Difyの公開範囲と利用企業のセキュリティ方針に準拠に依存します。弊社では閉域網での利用に閉じている関係で、15minで設定しています。なお、v.0.14.1以降のバージョンに含まれます。	86400(24hours)

App Configuration

Difyアプリケーショn実行全般の制御について解説します。

設定項目	説明	デフォルト値
APP_MAX_EXECUTION_TIME	アプリケーション実行の最大時間（秒単位）。WORKFLOW_MAX_EXECUTION_TIMEと整合している必要があります。弊社ではWORKFLOW_MAX_EXECUTION_TIMEと同値に設定しています。	1200
APP_MAX_ACTIVE_REQUESTS	単一のアプリケーションが処理できる最大同時リクエスト数（0の場合は無制限）。無制限にするとリスクがあるため、弊社では20に制限しています。	0

その他設定

設定項目	説明	デフォルト値
MAX_SUBMIT_COUNT	イテレーションノードの並列実行に使用されるスレッドプール内の最大スレッド数。実質、イテレーションノードの入力配列の最大長です。100は不十分なため弊社では150に設定しています。	100

Sandboxリソースの上限値最適化

対象となるファイルは、githubのdify-sandboxというgithubリポジトリの/conf/config.yamlです。

設定項目	説明	デフォルト値
WORKER_TIMEOUT	sandbox上で実行されるコードの実行タイムアウト(秒)。デフォルト5秒で短すぎるため変更必須です。	5
max_requests	sandboxへの同時リクエスト数(秒)。一般的には50で問題になることはほとんどありません。	50

タイムアウトなどを待つ以外に正攻法で止める方法がないため要注意

特に注意すべきは、再帰呼び出しを行うワークフローを起動してしまい、ロジックミスがあり無限ループした場合です。途中で停止不可能なため、アプリケーションコンフィグのWORKFLOW_MAX_EXECUTION_STEPSやAPP_MAX_EXECUTION_TIMEが重要になりますので、これらの上限値を極端に大きくすることがないようにしましょう。最悪のケースにおける対応策として、他のユーザに影響が出る形でもOKな場合は、sandboxやAPIリソースのサーバを落とす、利用しているLLMのAPIキー(Bedrockの場合は不可)をdeactivateする、、、、、などケースバイケースで対応方法はあります。

まとめ

Difyのデフォルト設定は、比較的小規模な利用を想定しています。業務で本格的に利用する場合や、大量のドキュメントを処理する場合は、特に「タイムアウト時間」「ファイルサイズ制限」「コード実行のメモリ/文字数制限」の緩和が必須となります。

まずは docker-compose.yaml または .env ファイルを確認し、現状の運用に合わせてパラメータを最適化してみてください。