セルフホスト版Dify：自分のLLMでAIアプリを作成 ローカル

#チャットインターフェースではなくDifyを選ぶ理由

Open WebUI または LM Studio でモデルと対話できます。Difyはさらに一歩進んで、再利用可能なアプリケーションの構築を目指しています。システムプロンプトを定義し、知識ベースを接続し、APIまたは統合可能なチャットウィジェットで公開し、バージョン管理を行います。これはOpenAIのAssistantsまたはCozeのローカルかつオープンソース版に相当します。

DifyとOllamaの組み合わせの利点は二重です。まず、機密性です。GPT-4やClaudeに接続したDifyとは異なり、ここではインデックス化されたドキュメントと会話履歴が、あなたのインフラストラクチャ内に保持されます。次に、コストです。課金されるトークンはなく、API請求額を気にせずに数百のプロンプトで反復作業を行うことができます。

Chatbot

システムプロンプト、入力変数、会話メモリを備えた対話型アシスタント。

エージェント

ツール（ウェブ検索、計算、APIなど）を繰り返し呼び出してタスクを解決できるアシスタントです

Workflow

決定論的な処理のために、ノード（LLM、条件判断、抽出、HTTP）を視覚的に連結した構成。

ナレッジ / RAG

ドキュメントのインデックス化により、アプリがその内容に基づいて回答し、ソースを引用するようにします。

#前提条件

Difyは、複数のコンテナで構成されるアプリケーションです（API、ワーカー、フロントエンド、PostgreSQLデータベース、Redis、ベクトルデータベース）。Docker Composeでデプロイします。モデル側については、Ollamaがすでに稼働し、デフォルトのポートで待ち受けていることを前提とします。

Docker + Docker Compose

Composeプラグインを備えた比較的新しいDocker Engine（コマンドはdocker compose）。Windows/macOSではDocker Desktopで十分です。

Ollamaは正常に動作しています

Ollamaデーモンがインストールされ、http://localhost:11434でアクセスできること。始める前にollama listを実行して確認してください。

チャットモデル

たとえばqwen3.5:9b（256kのコンテキスト、マルチモーダル、Apache 2.0）は、2026年に8 GB環境で選ぶ際の定番です。Q4では約6.6 GBのVRAMに収まり、RTX 3060 12 GBなら十分な余裕があります。

埋め込みモデル

RAGに不可欠です。nomic-embed-textは標準的な選択肢で、軽量かつ効率的です。

リソース

Ollamaのモデルが消費するVRAM/RAMに加えて、Difyの構成全体そのものに約8GBのRAMを確保してください。

# Vérifier qu'Ollama répond
ollama list

# Modèle de chat (choisissez selon votre VRAM)
ollama pull qwen3.5:9b

# Modèle d'embeddings pour le RAG
ollama pull nomic-embed-text

#DifyをDocker Composeでインストール

Difyは、そのまま使えるdockerフォルダを含む公式リポジトリを提供しています。リポジトリをクローンし、環境設定ファイルのサンプルをコピーして、スタックを起動します。

1. 01
   リポジトリをクローンする

   GitHubからプロジェクトの最新安定版を取得し、docker-compose.yamlファイルが入っているdockerフォルダに移動してください。
2. 02
   .envファイルを作成する

   .env.exampleを.envにコピーしてください。ローカル利用にはデフォルト値で十分です。後でポートやシークレットを調整する場合も、このファイルで行います。
3. 03
   スタックを起動する

   docker compose up -d を実行してください。初回起動時にはイメージがダウンロードされ、PostgreSQLデータベースが初期化されます。数分かかると見込んでください。
4. 04
   管理者アカウントを作成する

   ブラウザでhttp://localhost/installを開き、最初の管理者のメールアドレスとパスワードを入力してください。このアカウントでワークスペースを管理します。

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

cp .env.example .env

docker compose up -d

# Vérifier que les conteneurs tournent
docker compose ps

#Ollama をモデルプロバイダーとして接続する

Difyは、Ollamaをプロバイダーとして登録した場合にのみ、ローカルモデルを認識します。登録は設定ファイルではなく、モデルの設定画面で行います。最も注意すべき点はURLです。Dockerコンテナ内では、localhostはコンテナ自体を指し、Ollamaが動作しているホストマシンを指しません。

1. 01
   ベンダー設定を開く

   右上隅のアバターをクリック → 設定 → モデル提供者。リスト内で Ollama を検索して選択してください。
2. 02
   サーバーのURLを入力してください

   Base URL フィールドに、コンテナからアクセスできるアドレスを入力してください（下の補足説明をご参照ください）。モデル名は ollama list が返すものと完全に一致する必要があります。たとえば qwen3.5:9b です。
3. 03
   チャットモデルを追加

   モデルの種類：LLM。コンテキストサイズ（モデルに応じて、例えば8192以上）を入力し、確定してください。Difyは保存時に接続をテストします。
4. 04
   埋め込みモデルの追加

   nomic-embed-textでも、タイプとして「Text Embedding」を選んで同じ操作を繰り返してください。このモデルがないと、ナレッジベースを構築できません。
5. 05
   デフォルトのモデルを定義する

   引き続き設定画面で、デフォルトのシステムモデルをqwen3.5:9bに、デフォルトの埋め込みモデルをnomic-embed-textに設定してください。

# Rendre Ollama joignable au-delà de localhost
# (à ajouter dans le service systemd ou l'environnement)
OLLAMA_HOST=0.0.0.0 ollama serve

# Vérifier depuis l'hôte que l'API répond
curl http://localhost:11434/api/tags

#コードを書かずに最初のRAGアシスタントを構築

RAG（Retrieval-Augmented Generation、検索拡張生成）を使うと、モデルは訓練で得た知識だけに頼るのではなく、ユーザーのドキュメントに基づいて回答できます。Difyでは、ナレッジベース（Knowledge）を使い、それをアプリケーションに紐づけることで実現します。

1. 01
   知識ベースの作成

   「Knowledge」タブ → 作成。ファイル（PDF、Markdown、TXT、DOCX）をインポートしてください。Difyがそれらを自動的にチャンクに分割します。
2. 02
   チャンク分割とインデックス作成を設定する

   「高品質」インデックスモードを選択し、nomic-embed-textの埋め込みモデルを使用してください。ドキュメントが非常に構造化されている場合（テーブル、コードなど）は、チャンクのサイズを調整してください。
3. 03
   チャットアプリケーションを作成する

   Studioタブ → アプリを作成 → チャットボット。名前と説明を設定してください。
4. 04
   システムプロンプトを記述

   エディターで、アシスタントの役割を次のように記述してください。「提供された文書だけをもとに回答してください。情報が文書に含まれていない場合は、その旨を伝えてください。」これがハルシネーションを抑えるための指示です。
5. 05
   知識ベースの関連付け

   アプリの「Contexte」パネルで、ステップ1で作成したナレッジベースを追加してください。回答に使用した抜粋が表示されるよう、出典の引用を有効にしてください。
6. 06
   テスト後、公開

   右側のデバッグパネルを使って質問を投げてください。動作に満足したら、公開をクリックし、チャットのURLとAPIキーを取得してください。

#ワークフローとエージェント：ノーコードでどこまでできるか

Difyは、単なるチャットボットに加えて、より高度な二つのモードを提供しています。Workflowモードでは、ユーザー入力、LLM呼び出し、条件分岐（if/else）、パラメータ抽出、HTTPリクエスト、リストの反復処理といったノードをつなぐビジュアルキャンバスを使えます。こうして決定論的なパイプラインを構築できます。例えば、メールを受信し、分類し、エンティティを抽出してから、定型の返信を作成するといった流れです。

一方、Agentモードでは、どのツールをどの順序で呼び出すかをモデル自身が決め、結果に到達するまで繰り返します。より強力ですが、その分、不安定になりやすい方式です。品質は、モデルの推論能力と、ツール呼び出し形式を守る能力に大きく左右されます。非常に小さなローカルモデル（2～4B）は、この処理が苦手です。VRAMに余裕があれば、GLM 4.7 Flash（MoE 30B-A3B、MIT、約19GB）やQwen 3.8 27B（約18GB）のような、ツール利用に適したモデルを選んでください。

ノーコードが得意なこと

RAGチャットボットの試作を素早く作る、LLMの処理をいくつか順につなぐ、バックエンドのコードを書かずにAPIを公開する、チームでプロンプトを繰り返し改善する。

ローカル環境での難点

高度な処理を求められるマルチツールエージェントには、ツールを確実に使いこなせるモデルが必要で、そのためVRAMも必要になります。Qwen 3.5 9BはRAGには十分ですが、複雑なエージェントには十分であることがまれです。

コードへの移行タイミング

細かな業務ロジック、独自の連携、検索パイプラインの完全な制御が必要な場合、ビジュアルキャンバスの限界を補うのがLangChainのようなライブラリです。

#トラブルシューティング

モデル追加時に「Connection refused」と表示される

DifyからOllamaに接続できません。原因はほぼ常にURLです。localhostをhost.docker.internal（Docker Desktopの場合）またはDockerゲートウェイのIPアドレス（Linuxの場合）に置き換え、Ollamaが0.0.0.0で接続を待ち受けていることを確認してください。

モデルが表示されません

入力した名前がollama listの表示と一致していません。タグを含めた正確な名前をコピーしてください（qwen3.5ではなくqwen3.5:9b）。

ドキュメントのインデックス作成中にエラーが発生しました

埋め込みモデルが設定されていないか、ダウンロードされていません。ollama pull nomic-embed-textを実行し、デフォルトの埋め込みモデルとして選択してください。

応答が非常に遅い

チャットモデルの一部の処理がCPUに回っている可能性があります。より軽い量子化（Q4_K_M）か、より小さいモデルに切り替え、Ollama側でGPUが実際に使われていることを確認してください。

ポート80は既に使用されています

別のサービスがそのポートを使用しています。.env 内の EXPOSE_NGINX_PORT を変更し（例：8080）、docker compose up -d を再実行してください。

RAGを活用しても関連性のない回答

ナレッジベースがアプリに正しく関連付けられていることと、システムプロンプトがモデルにコンテキストに基づいて回答するよう求めていることを確認してください。また、チャンクのサイズも調整してください。

#さらに詳しく

Dify の実力は、それを支えるモデルとインフラの堅牢性に左右されます。これらのガイドは、Dify が依拠する基盤を強化します。

Ollama のインストール

チャットモデルおよび埋め込みをポート11434で提供するデーモンです — Difyのローカルスタックの基礎です。

ChromaDB と Ollama を使ったローカル RAG

Difyが内部で何を自動化しているのかを理解し、ノーコードの限界にぶつかったときにPythonで自分で制御できるようにするために。

n8n + Ollama：ローカルでの自動化

タスクの自動化を重視した別のノーコードアプローチで、Difyのワークフローを補完します。