Dify完全ガイド2026｜オープンソースのLLMOps基盤でAIアプリを構築・自己ホストする

Dify（ディファイ）は、LLMを使ったAIアプリを「コードを書かずに」構築し、本番運用まで持っていけるオープンソースのプラットフォームだ。 ChatGPTのAPIを叩いて社内チャットボットを作ろうとした人なら、すぐに気づくはずだ——実際に必要なのはAPIコール一発ではなく、社内文書を検索するRAG、プロンプトの管理、モデルの切り替え、公開用API、そしてログ監視……という「LLMアプリの周辺装置」一式である。これらを全部自作すると、いつまで経ってもプロトタイプが本番にならない。

Difyは、そのすべてを1つのWeb UIに畳み込んだLLMOps（LLMの開発・運用）基盤だ。ビジュアルなWorkflowキャンバスでフローを組み、文書をアップロードすればRAGが立ち上がり、数クリックでAPIとして公開できる。非エンジニアでも1時間以内にチャットボットを動かせるところまで、開発のハードルを下げる。この記事では、Difyを「何ができるか → セルフホスト → アプリタイプ → RAG → プラグイン → 実運用 → ライセンスと比較」の順に、公式ドキュメントで裏取りしながら解説する。

ノーコードからコードまでのAI自動化ツール全体像は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。本記事はその中でも「Dify」というLLMアプリ開発基盤に絞った実践編です。

Difyとは何か——3つの疑問に先に答える

新しいOSSに対して読者が知りたいのはいつも同じ3つ、「何ができて、何を解決し、何を代替するのか」だ。Difyについて先に答えを置く。

① 何ができるのか。 Difyは、LLMアプリに必要な機能——ビジュアルWorkflow、RAG、エージェント、モデル管理、監視——を1つのプラットフォームに統合している。ドラッグ&ドロップのキャンバスで処理フローを設計し、文書をアップロードしてナレッジベースを作り、数十のLLMプロバイダから好きなモデルを選び、完成したアプリをAPIとして外部に公開する。プロトタイプから本番運用までを、コードをほとんど書かずに1つのツールで完結できる。

② 何を解決するのか。 LLMアプリを「ライブラリで一から組む」ときの膨大な作業を肩代わりする。RAGのドキュメント取り込みからチャンク分割・埋め込み・検索、プロンプトのバージョン管理、複数モデルの切り替え、公開API化、そしてログとパフォーマンスの監視——これらは自作すると数週間かかるが、Difyでは画面操作に置き換わる。結果として、非エンジニアでも1時間以内に実用的なチャットボットを立ち上げられるところまでハードルが下がる。

③ 何を代替するのか。 開発ライブラリのLangChainが担っていた「コードを書く」部分をGUIで代替する。ビジュアルビルダーのFlowiseより本番運用・ガバナンス寄りで、汎用自動化のn8nとは「ナレッジベース付きのAIアプリ」に特化する点で棲み分ける。ByteDanceのCozeのようなノーコードbot基盤とは正面から競合するが、Difyはオープンソースで自己ホストできることが決定的な差別化になる（機能面の細かい優劣評価は第三者比較に基づく整理で、推測を含む）。

Difyの内部構成を俯瞰すると、フロント（web）・バックエンド（api）・非同期処理（worker）・各種データストアが連携する、れっきとしたWebアプリケーションであることが分かる。

本体はオープンソースで、GitHubスターは約14.7万（GitHub API実測。公式サイトの旧表記より実数は大きい）。2026年6月25日公開のv1.15.0では、アプリやWorkflowをターミナルから直接実行できる difyctl CLIや、推論の思考過程（Chain-of-Thought）を専用パネルにストリーム表示する機能などが加わり、開発体験がさらに磨かれている。

Difyのセルフホスト（Docker Compose）

Difyを試す最短路は、公式が提供するDocker Composeでの自己ホストだ。GitHubからクローンし、docker ディレクトリで環境変数をコピーして起動するだけで、必要なコンテナ一式が立ち上がる。

# 1. リポジトリを取得（最新の安定タグを推奨）
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 2. 環境変数ファイルを用意（そのままでも起動可、本番は要編集）
cp .env.example .env

# 3. 起動（初回はイメージ取得に数分）
docker compose up -d

起動が終わったら、コンテナがすべて正常かを確認する。Difyは約11個のコンテナで構成される（api / worker / worker_beat / web / plugin_daemon と、依存する weaviate・db(PostgreSQL)・redis・nginx・ssrf_proxy・sandbox）。

# 全コンテナが Up / healthy かを確認
docker compose ps

ブラウザで http://localhost/install を開くと、最初の管理者アカウントを作成する初期セットアップ画面が出る。以降は http://localhost（ポート80）がDifyのコンソールになる。バックエンドAPIは5001番、プラグインデーモンは5003番で動く。

必要スペックは公式でCPU 2コア以上・RAM 4GB以上・Docker Compose 2.24.0以上とされるが、これは開発用の最小値だ。約11コンテナが常駐し、PostgreSQL・Redis・ベクトルDBを抱えるため、本番ではメモリに余裕を持たせ、これらデータストアの永続化とバックアップを自前で設計する前提になる。macOSのDocker Desktopなら8GB以上の割り当てが安心だ。

初回起動でつまずくとしたら、原因の多くはポート競合かメモリ不足だ。http://localhost が開けない場合、80番ポートを別のWebサーバ（既存のnginxやApache）が使っていないかを疑う。競合しているなら docker/.env の EXPOSE_NGINX_PORT を空いている番号に変えて起動し直す。また、コンテナが起動直後に落ちる（docker compose ps で Restarting を繰り返す）場合は、Dockerに割り当てたメモリが足りていないことが多い。Docker Desktopの設定でメモリ上限を上げてから docker compose up -d をやり直せば解消することがほとんどだ。ログは docker compose logs -f api で追える。ここさえ押さえれば、セルフホストで詰まる場面は大きく減る。

5つのアプリタイプとビジュアルWorkflow

Difyでアプリを新規作成すると、目的に応じて5つのアプリタイプから選ぶ。これがDifyの設計思想を最もよく表している。

このうち Workflow / Chatflow は、ノードをドラッグ&ドロップでつなぐビジュアルキャンバスで組み立てる。「ユーザー入力」ノードから始まり、「LLM」「知識取得（RAG）」「条件分岐」「コード実行」「HTTPリクエスト」などのノードを線でつないで、処理の流れを目で見ながら設計できる。プログラムのフローチャートをそのまま実行可能にしたようなもので、どこで何が起きているかが一目で分かる。

どのタイプを選ぶかは、「対話が主役か、処理が主役か」で分けると迷わない。ユーザーと会話し続けるものはChatbot/Chatflow、入力を受けて一括で処理して結果を返すバッチ的なものはWorkflow、モデル自身に「次に何をするか」を判断させたいならAgent、という具合だ。迷ったらまずChatflowで作り始め、複雑になってきたらWorkflowへ寄せる、という進め方が現実的である。

プロンプトの試行錯誤にはプロンプトIDEが使える。プロンプトを書きながら複数モデルの応答を並べて比較でき、text-to-speechの追加なども直感的に行える。「まず動かして、比べて、直す」というループを1画面で回せるのが、Difyがプロトタイピングに強い理由だ。v1.15.0では、エージェントやWorkflowの推論の思考過程（Chain-of-Thought）を専用パネルにストリーム表示する機能も加わり、「モデルがなぜその結論に至ったか」を開発中に追いやすくなった。最終的な回答画面はクリーンに保ちつつ、裏側の思考は開発者が覗ける——デバッグ体験の地味だが効く改善だ。

RAG（ナレッジベース）を最短で作る

Difyが最も得意とするのがRAG（Retrieval-Augmented Generation：社内文書などに基づく回答生成）だ。仕組みを自作すると重いこの機能を、Difyは「文書をアップロードするだけ」に単純化している。RAGの理論的な全体像は RAG完全ガイド2026 に譲り、ここではDifyでの作り方に絞る。

手順はシンプルだ。①「ナレッジ」メニューで新しいナレッジベースを作り、②PDFやPPT、テキストなどの文書をアップロードする。するとDifyがテキスト抽出 → チャンク分割 → 埋め込み（ベクトル化）→ インデックス作成までを自動で実行する。③あとはChatflow/WorkflowのLLMノードから、そのナレッジベースを参照するよう繋ぐだけ。これで、質問に対して文書の該当箇所を根拠付きで答えるRAGアプリが完成する。

検索の精度を上げるためのリランク（検索結果の並べ替え）も設定でき、ヒットした候補を再評価して最も関連性の高いものを回答に使わせられる。埋め込みや生成に使うモデルは自由に選べるため、埋め込みも生成もローカルのOllamaに向けて、文書を一切外部に出さないオフラインRAGを組むことも可能だ。ローカルLLMをDifyのモデルプロバイダに指定する具体像は Ollama入門2026 と併せて読むと理解が早い。

RAGの品質を左右するのは、実はチャンク（文書の分割単位）の設計だ。Difyではチャンクの区切り方や長さ、隣接チャンクの重複（オーバーラップ）を調整でき、文書の性質に合わせて「短く切って精度重視」か「長めに切って文脈重視」かを選べる。検索方式もベクトル検索だけでなく、キーワード検索と組み合わせたハイブリッド検索を選べるため、固有名詞や型番のように「意味の近さ」だけでは拾いにくいクエリにも強くなる。回答には根拠となった文書チャンクが引用として付くので、「なぜその答えになったか」を追跡できる——これは、ハルシネーション（もっともらしい嘘）を疑わしいと見抜くうえで実務上とても重要な性質だ。

Difyのファイル取り込みでつまずく典型例（大量アップロードが「キューイング中」で止まる等）とその対処は、Dify ファイルアップロードが「キューイング中」で止まる原因3つと解決策 に実例をまとめている。

モデルとプラグイン・Marketplace・MCP

Difyは特定のモデルに縛られない。数百の商用/OSSモデル——OpenAI（GPT系）、Anthropic（Claude系）、Google（Gemini系）、Mistral、Llama3、そしてOpenAI互換APIやローカルのOllama——をプロバイダとして登録し、アプリごとに使い分けられる。用途に応じて「安いモデルで下書き、重要な回答だけ高精度モデル」といった振り分けもできる。

拡張性の中心がプラグインシステムだ。以下の6種類を追加でき、Difyを自分の環境に合わせて育てられる。

・Models — 新しいモデルプロバイダを追加
・Tools — エージェントが呼び出す外部ツール（検索・画像生成・計算など）
・Agent Strategies — エージェントの思考戦略（Function Calling / ReAct 等）
・Extensions — HTTP Webhookによる外部連携
・Datasources — 外部データソースからの取り込み
・Triggers — サードパーティのイベントでWorkflowを起動

エージェント用には、Google検索・DALL·E・Stable Diffusion・WolframAlphaなど50以上のビルトインツールが用意されている。これらは公式のMarketplaceで発見・インストール・共有でき、CLIによるscaffoldやリモートデバッグ、publishにも対応する。さらにNative MCP連携を備え、Model Context Protocol経由で他システムのツールやデータと繋がる。ビジュアルなAIワークフロー構築という点では Langflow が近い立ち位置のツールで、両者を比較すると設計思想の違いが見えてくる。

アプリをAPIとして外部システムに組み込む

Difyで作ったアプリは、画面の中で完結させる必要はない。各アプリはBackend-as-a-Service APIを発行し、外部のWebアプリやSlackボットからHTTPで呼び出せる。アプリごとに専用のAPIキーが発行されるので、それを使ってリクエストするだけだ。

# Difyアプリを外部システムから呼ぶ（アプリ発行のAPIキーを使用）
curl -X POST 'http://localhost/v1/chat-messages' \
  -H 'Authorization: Bearer app-xxxxxxxxxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {},
    "query": "退職金はいつ支給されますか？",
    "response_mode": "streaming",
    "user": "user-123"
  }'

この設計により、「Difyでロジックを組み、既存プロダクトはAPIで呼ぶだけ」という分業が成り立つ。フロントエンドやチャネル（Web・Slack・LINE）は自由に作りつつ、AIの頭脳部分だけをDifyに集約できる。プロンプトやフローを変えたいときはDifyの画面を直すだけでよく、呼び出し側のコードには手を入れずに済む——ここが、AIロジックを散らかさずに保守する上で効いてくる。

なお最新のv1.15.0では difyctl というCLIツールが加わり、Web UIを開かずにターミナルからアプリやWorkflowを直接実行できるようになった。CI/CDやバッチ処理にDifyのフローを組み込みたい場面で役立つ。

実運用ユースケースと本番運用の勘所

Difyは「試して終わり」ではなく実務に載る。代表的な使い方を4つ挙げる。

① 社内ナレッジチャットボット。 設計書・マニュアル・規程をナレッジベース化し、社員の質問に根拠付きで答える。Difyが最も得意とする王道用途で、RAGとチャットUIを最短で立てられる。

② カスタマーサポート自動化。 FAQや製品マニュアルをRAG化し、問い合わせに一次応答するbotを作る。Chatflowの条件分岐で「解決できないものは人間へエスカレーション」も組める。

③ ワークフロー自動化（NLPパイプライン）。 「要約 → 分類 → 生成」のような複数ステップの処理をビジュアルWorkflowで構築し、Backend-as-a-Service APIで既存システムに組み込む。定型的な文書処理を自動化できる。

④ 自律エージェント。 ReActやFunction Callingで外部ツール（検索・画像生成・計算）を呼ぶエージェントを構築する。単純な質問応答を超えて、「調べて・計算して・答える」相談役を作れる。たとえば「最新の為替を検索し、指定額を円換算して、結果をSlackに投げる」といった多段の仕事を、モデル自身が手順を判断しながら実行する。

⑤ コンテンツ生成アプリ。 Text GeneratorやWorkflowで、メール文面・記事下書き・商品説明などを定型フォーマットに沿って量産する。入力欄（フォーム）に商品名やトーンを指定させ、あとはボタン一つで一貫した品質の文章を出す社内ツールを、非エンジニアが数十分で作れる。

これらに共通するのは、「LLMを使った小さな業務アプリを、専任エンジニアを待たずに現場が自分で立てられる」という価値だ。IT部門がすべてを抱える必要がなくなり、現場が自分の課題に合わせてAIアプリを内製できる——ここにDifyを社内基盤として置く意味がある。

本番運用では、約11コンテナ構成をどう安定運用するかが勘所になる。PostgreSQL・Redis・ベクトルDBの永続化ボリュームを確保し、定期バックアップを設計する。バージョンアップはDBスキーマのマイグレーションを伴うことがあるため、.env とデータの互換性を確認してから上げる。監視・アノテーション機能でアプリのログとパフォーマンスを追い、問題の芽を早めに摘む。「作るのは1時間、運用は継続」——ここを見誤らないことが、Difyを本番で使いこなす条件だ。

ライセンスの注意点と他ツール比較

Difyを商用で使うなら、Dify Open Source License（Apache 2.0に追加条項を付けたライセンス）の理解が必須だ。GitHub上の表記も純Apacheではなく “Other” になっている。要点は2つ。

・マルチテナント制限 — 書面による許可なく、DifyをマルチテナントのSaaSとして再提供してはならない。複数の顧客に貸し出すクラウドサービスとして売るには、公式の商用ライセンスが必要
・ロゴ/著作権制限 — コンソールやアプリのDifyロゴ・著作権情報を削除・改変してはならない（対象はフロントエンド部分）

逆に言えば、この2条件に触れなければ、自社アプリのバックエンドサービスとしての利用や、企業向けアプリの開発基盤としての商用利用は許可されている。「社内で使う」「自社プロダクトの一機能として組み込む」分には問題なく、「Difyそのものを他社に貸すSaaSにする」場合だけ契約が要る、と理解すればよい。

判断に迷ったら、「あなたの顧客が、Difyの管理画面そのものを触るか？」を基準にするとよい。顧客が触るのは自社アプリのUIだけで、Difyは裏方に徹しているなら、多くの場合セーフだ。逆に、顧客ごとにDifyのワークスペースを切って管理画面ごと提供する（＝マルチテナントSaaS）なら、商用ライセンスの検討対象になる。ロゴについても同様で、フロントエンド部分のDify表記を消して自社ブランドとして再配布するのは制限に触れる。曖昧なケースや大規模な商用展開では、自己判断せず公式に問い合わせるのが安全だ。ライセンスは「使えるか/使えないか」ではなく「どう使うか」で線が引かれている、と捉えておきたい。

最後に、類似ツールの中でのDifyの立ち位置を整理する。

まとめると、独自ロジックを細かく詰めるならLangChain、AIアプリを速く立てて本番運用・監視まで持っていくならDify。そしてDifyの真価は、プロトタイプと本番の間にありがちな「作ったはいいが運用に載らない」という谷を、統合された1つのプラットフォームで埋めてくれるところにある。RAGもエージェントもモデル切替も監視も、別々のツールを繋ぎ合わせるのではなく、最初から1つの画面の中にある——この「統合されていること」自体が、チームで運用を続けるうえで効いてくる。

まずは docker compose up -d で自分の環境に立ててみて、文書を1つアップロードしてチャットさせるところから始めてほしい。ナレッジベースに社内文書を放り込み、質問を投げて、根拠付きの回答が返ってくる——その瞬間に、「LLMアプリを作る」という作業がぐっと身近になるはずだ。そこから先は、Workflowで分岐を足し、ツールを繋ぎ、APIで既存システムに組み込んでいけばいい。小さく立てて、育てる。それがDifyとの付き合い方だ。

参照ソース

・langgenius/dify — GitHub 公式リポジトリ
・Dify 公式サイト
・Dify 公式ドキュメント（docs.dify.ai）
・Docker Compose によるセルフホスト（公式docs）
・プラグイン Introduction（公式docs）
・Dify Open Source License（GitHub LICENSE）
・Dify Cloud（マネージド版）