Difyとは？料金・できること・使い方とLangChainとの違い｜2026年最新版

Dify（ディファイ）は、LangGenius, Inc. が開発するオープンソースのAIアプリ開発プラットフォームです。 ブラウザ上のビジュアルキャンバスでAIワークフロー・RAG（社内文書検索）・AIエージェントを組み立て、そのままWebアプリ／API／MCPサーバーとして公開できます。クラウド版は無料枠から試せ、ソースコードが公開されているためDockerで自社サーバーに構築することもできます。

2026年9月1日時点の最新安定版は v1.17.0（2026年8月25日リリース）。さらに8月27日には公式ブログで 新しいAgent が発表され、これまでワークフローに紐づいていたエージェントが「独立して再利用できるアプリ」へと構造ごと変わりました。Difyは「プロトタイプを作るツール」から「エージェントを本番運用する基盤」へ性格を変えつつある、というのが現在地です。

この記事でわかること

• Difyでできること（ワークフロー／ナレッジ／エージェント／公開手段）と2026年9月時点の最新機能
• Cloud・Community（セルフホスト）・Enterpriseの料金と、見落としやすい「二層構造」のコスト
• AIクレジット（Message Credits）が実際に何回分なのか、プラン上限に達すると何が止まるのか
• クラウド版を試す5ステップと、Docker Composeでのセルフホスト手順・v1.17.0のアップグレード注意点
• LangChain／n8n／Flowise・Langflowとの選び分け、商用ライセンス2条件、セキュリティ運用の実態

この記事はこんな方向けです。 社内AI基盤のツールを選定している情シス・DX担当、LangChainと比較検討しているエンジニア、セルフホストの要件と運用負荷を事前に把握したい方。生成AIそのものの基礎から確認したい方は生成AIとは？仕組みから活用事例まで解説もあわせてご覧ください。

Difyの基本情報：開発元・提供形態・規模

Difyは公式に「The Platform for Production-Ready Agentic Workflows（本番運用に耐えるエージェンティックワークフローのためのプラットフォーム）」と位置づけられているオープンソースプロダクトです。開発元は LangGenius, Inc.（日本国内向けには日本法人が窓口となり、日本語サイトとEnterprise版の提供・導入支援を行っています）。

出典: Dify 公式サイト

Difyが担う範囲

Difyは「LLMそのもの」ではなく「LLMを使ったアプリを作り、運用する土台」です。OpenAI・Anthropic・Googleなど各社のモデルをMarketplace経由で接続して使う構成で、モデルの提供やファインチューニングは行いません。裏を返せば、モデルを乗り換えてもアプリ側を作り直さずに済むのが構造上のメリットです。

Difyでできること：6つの機能ブロック

現在のDifyは、Workflow（ワークフロー）／Knowledge（RAG）／Agent（エージェント）／Marketplace（拡張）／Publishing（公開）／Monitoring（監視） の6ブロックで整理すると理解しやすい構成になっています。

出典: langgenius/dify GitHub

1. Workflow / Chatflow（ワークフロー構築）

LLM呼び出し・条件分岐・変数抽出・ツール実行などのノードをドラッグ&ドロップでつなぎ、多段処理を設計します。公式ドキュメントで確認できる主なノードは次のとおりです。

実務でよく組まれるのは「問い合わせメールを分類 → 該当マニュアルを検索 → 返信文を生成 → 担当者が承認してから送信」「議事録を要約 → 決定事項とタスクを抽出 → 表形式で出力」「見積書PDFから項目を抽出 → 社内基準と突合 → 逸脱をアラート」といった流れです。バージョン管理・スニペット（ノード群の再利用）・単一ノード実行・変数インスペクターなど、編集と検証を回す機能が標準で用意されています。

2. Knowledge（RAG／ナレッジ）

ファイルをアップロードし、チャンク設定とインデックス方法を決めるだけで検索可能なナレッジベースが作れます。インデックスは「高品質（ベクトル）」と「経済的（キーワード）」の2種類で、経済的モードはベクトルを作らないためストレージを消費しません。

• 親子モード（Parent-Child）チャンクに対応し、検索精度と文脈量のバランスを調整できる
• 取り込み元はローカルファイルのほか、Notion同期・Webサイトからのインポートに対応
• Knowledge Pipeline で、取り込み〜前処理〜ベクトル化を自分で設計できる
• External Knowledge API により、既に持っている自社RAGや外部検索基盤を接続できる
• ドキュメントメタデータ管理、検索テスト（Retrieval Test）、リクエストレート制限を用意

RAGの仕組みそのものを押さえたい場合はRAGとは？仕組みと最新動向を解説を先に読むと、チャンク設計や埋め込みモデル選定の判断がしやすくなります。

3. Agent（AIエージェント）

2026年のDifyで最も大きく変わったのがここです。新しいAgent（公式ブログ 2026年8月27日発表／ドキュメント上はベータ機能と明記）により、エージェントの扱いが次のように変わりました。

概念としては、ロール・プロンプト・モデル・スキル・ツール・ファイルをまとめた「能力（Capabilities）」を先に作り、実行のたびに「タスク」を渡す設計です。会話ごとに記憶は独立し、新しい会話は白紙から始まります。エージェントの基礎概念はAIエージェントとは？仕組み・活用事例・リスクを解説で整理しています。

なお従来型のAgentアプリ（モデルが自律的にツールを使うチャット型アプリ）も引き続き利用できます。新しいAgentはベータ扱いのため、社外公開より社内の限定利用から始めるのが妥当です。

4. Marketplace（プラグイン・拡張）

marketplace.dify.ai では Models / Tools / Data Sources / Triggers / Agent Strategies / Extensions / Bundles の7カテゴリでプラグインが配布されています。モデルプロバイダーもここから追加するため、初期構築時点で連携先をすべて決め切る必要はありません。加えて、ワークフローのテンプレートを公開できる Templates セクションと Creator Center も用意されています。

Skills やプラグインという考え方自体を掘り下げたい方はAgent Pluginsとは？MCPとAgent Skillsの標準を解説が参考になります。

5. Publishing（公開手段）

作ったアプリは次の形式で公開できます。ここが「フレームワークではなくプラットフォーム」と言える最大の理由です。

• 共有URL付きのWebアプリ（チャット型／ワークフロー型、ブランディングとアクセス制御の設定つき）
• サービスAPI（OpenAPI仕様を公開。自社システムやSlackボットから呼び出し）
• 既存サイトへのiframe／チャットウィジェット埋め込み
• MCPサーバーとしての公開 — Claude DesktopやCursorなどMCP対応クライアントからDifyアプリを呼び出せる
• Dify Marketplaceへのアプリ公開

MCPまわりの標準化動向はMCPの新ロードマップ（2026年後半）で扱っています。

6. Monitoring（モニタリング）

ダッシュボード（パフォーマンス・コスト・エンゲージメント）、会話ログ／実行ログ（Webアプリ・Webhook・スケジュールなど起動元を表示）、アノテーション（良い回答をキュレーションしてAI生成をバイパスする仕組み）が標準搭載です。外部連携として LangSmith / Langfuse / Opik / W&B Weave / Arize / Phoenix などにトレースを送れます。

2026年最新アップデート：v1.17.0で何が変わったか

2026年9月1日時点の最新安定版はv1.17.0（8月25日リリース）です。 直近のリリースは、機能追加よりも「エージェントを本番で回せるか」に重心が寄っています。

出典: langgenius/dify GitHub

v1.17.0の主な変更点

• E2Bサンドボックスバックエンド — エージェントのシェル／コード実行を、ローカルサンドボックスに加えてE2Bのクラウドサンドボックスでも実行可能に。DIFY_AGENT_RUNTIME_BACKEND で切り替え、docker-compose.e2b.yaml が新規提供
• Build-time Home Snapshots — エージェント公開時にサンドボックスのホームディレクトリ（インストール済みパッケージ・準備ファイル）をスナップショット化し、以降の実行がその状態から始まる。毎回の環境構築待ちがなくなる
• ワークスペース単位のSkill管理 — スキルを「コードとツール定義をまとめた再利用可能・バージョン管理されたケイパビリティ」として扱い、draft → publish → version のライフサイクルで管理
• コンテキスト対応の履歴圧縮 — 古いツール結果の削除 → 古い履歴の要約という段階的な圧縮で、長い会話でもコンテキスト予算内に収める
• LLM環境変数の再利用 — プロバイダー・モデル・パラメータの共有設定を一度定義し、任意のLLMノードから参照できる
• Loop／Iteration内でのHuman Input — 繰り返し処理の中にレビュー・承認ステップを置け、ページを更新しても一時停止と再開が維持される
• プロバイダー中立の統合トレーシング（既定はオフ）— LLMのTTFT、エージェントのReActステップ、ツール呼び出し、失敗ノードを可視化
• マルチモーダル強化 — LLMノードとエージェントが画像ファイルを直接マルチモーダルモデルへ渡せるように
• Go to Anything（⌘K／Ctrl+K） — アプリ・エージェント・スキル・ナレッジ・プラグインへ横断ジャンプ
• 既定値変更 — APP_MAX_EXECUTION_TIME と WORKFLOW_MAX_EXECUTION_TIME が1200秒 → 3600秒に引き上げ

長時間タスクの上限が3600秒になった点と、Home Snapshotsの追加は、「エージェントに調査や集計を任せる」使い方を現実的にする変更です。

Difyの料金プラン（2026年9月時点）

Dify Cloudは無料のSandboxを含む3プラン、セルフホストのCommunityは無料、Enterpriseは個別見積もりです。 公式の料金ページは既定が年払い表示（17%オフ）になっているため、月額と年額の混同に注意してください。

Dify Cloud

月額表示は公式ページの月／年トグルで切り替えて確認できます。既定表示は年額のため、申し込み前に必ず自分が契約する周期の金額を確認してください。

なお、過去に存在したセルフホスト向けの「Premium」プラン（AWS AMI提供）は、現在の公式料金ページには掲載がありません。掲載はCommunityとEnterpriseの2つのみです。古い解説記事で「Premium」を前提にした比較を見かけたら、そこは情報が更新されていないと判断して構いません。

セルフホスト・Enterprise

Enterpriseの金額は公式に非公開です。第三者サイトが具体的な年額を挙げていることがありますが、公式で確認できる情報ではないため、社内資料に転記しないほうが安全です。CommunityとEnterpriseは同一のDockerイメージで、ライセンスと環境変数によって機能が切り替わる構造になっています。

見落としやすい「二層構造」のコスト

Difyの利用料と、裏で動くLLMのAPI従量課金は別会計です。 ここを分けずに見積もると、稟議後に必ず差分が出ます。

プラン料金に含まれるのはAIクレジット（料金ページの表記はMessage Credits）で使える範囲です。ここで押さえるべき公式仕様が1つあります。

AIクレジットの消費単位は「AIレスポンス1回＝モデル呼び出し1回（入力1回＋出力1回）」。消費トークン数に関係なく1レスポンスとしてカウントされ、必要クレジット数はモデルごとに異なる（大きいモデルほど多く消費）。

つまり「5,000クレジット＝5,000往復」ではなく、使うモデルによって実際の往復回数は変わります。長文を投げてもクレジット消費は増えない一方、上位モデルを選ぶと1回あたりの消費が増える、という挙動です。

自分のOpenAI／Anthropic等のAPIキーを登録（BYOK）した分は、各プロバイダー側に直接課金されます。キーはワークスペース全体で有効になり、管理できるのはオーナーと管理者のみです。AIクレジットと自前キーは併用でき、プロバイダーごとに「使用優先度」を設定してクレジット枯渇時に自前キーへフォールバックさせることもできます。

「Communityは無料だからコストゼロ」という見積もりは成立しません。実コストはサーバー費用＋LLM API費用＋運用工数です。逆にCloudのProfessionalを選んでも、支払いは「$590/年＋LLM API利用料」になります。

教育プログラム（Dify for Education）

在学中の学生・現職の教員／学校職員は、認証すると年額Professionalプランを無償で利用できます。条件は細かいので、申請前に次を確認してください。

• 18歳以上で、教育機関に在学・在職していること
• 学校発行のメールアドレスでの登録が必須（個人アドレス・卒業生専用アドレスは対象外）
• 適用されるのは年額プランのみ。月額プランや既存の有料サブスクには適用できない
• AIクレジットはSandbox相当（一回限り200・毎月補充なし）。使い切った後は自分のAPIキーで継続利用
• 1回の認証につき1ワークスペース。自動更新はなく、毎年の再認証が必要。終了後はSandboxに戻る

ツール全体のコスト感を横並びで見たい場合は生成AIツールおすすめ比較も参考にしてください。

プラン上限は実際どう効くのか

料金表の数字より、上限に達したときに何が止まるかのほうが導入判断では重要です。公式ドキュメントで確認できる挙動を整理します。

さらに運用上見落とされやすい仕様として、会話やログを削除しても、その中でアップロードされたファイルは消去されません（公式ドキュメントに明示的な警告があります）。個人情報を含むファイルを扱う運用では、ファイル側の削除手順を別途決めておく必要があります。エディタ上でのプレビュー・テスト実行はログに残らない点も、検証記録を残したい場合は注意点です。

Difyの使い方①：クラウド版で始める5ステップ

最短で試すならクラウド版です。登録からアプリ公開まで、慣れれば30分程度で一巡できます。

ステップ1：アカウント登録
https://cloud.dify.ai にアクセスし、GitHub・Google・メールアドレスのいずれかでサインアップします。Sandboxプランは無料で即利用できます。

ステップ2：モデルプロバイダーを設定
「設定」→「モデルプロバイダー」で、使用するLLMをMarketplaceから追加します。AIクレジットで動くモデルはそのまま使え、自前のAPIキーを登録すればその分は各社に直接課金されます。ローカルモデル（Ollama等）はエンドポイントURLを指定します。

ステップ3：アプリを作成
「アプリを作成」から、チャットボット／テキストジェネレーター／Agent／Chatflow／Workflowを選びます。最初の1本はチャットボットが最も理解しやすく、テンプレートを取り込んで中身を読み解く進め方も有効です。

ステップ4：プロンプト設計とナレッジ接続
システムプロンプトを書き、必要ならナレッジ（RAG用ドキュメント）を紐付けます。右側のプレビューで挙動を即確認でき、思考過程（CoT）も専用パネルで追えます。ここで検索テスト（Retrieval Test）を使い、狙ったチャンクが引けているかを先に確認しておくと後の手戻りが減ります。

ステップ5：公開する
「公開する」で共有URLが発行され、同時にAPIエンドポイントも生成されます。埋め込みコードやMCPサーバーとしての公開もここから設定します。公開前にアクセス制御の設定を確認し、社内限定にするか外部公開するかを明示的に決めてください。

Difyの使い方②：Docker Composeでセルフホストする手順

社内データを外部に出せない場合は、Community Edition（OSS版）をDocker Composeで自社環境に構築します。

事前に必要な環境（公式の最小要件）

構築の流れ

1. 最新リリースタグを指定してリポジトリをクローンする
2. dify/docker ディレクトリへ移動する
3. .env.example を .env にコピーして設定する
4. docker compose up -d で起動する
5. docker compose ps で全コンテナの起動を確認する
6. http://localhost/install（サーバー上なら http://<サーバーIP>/install）にアクセスして管理者アカウントを作成する

起動するのはコアサービス＋依存サービス＋初期化タスクで計16コンテナです。ベクトルDB・リバースプロキシ・サンドボックス実行環境などが含まれるため、単一のWebアプリより構成が重い点は最初に理解しておく必要があります。v1.15.0以降は公式CLI difyctl も提供されており、Web UIを開かずにターミナルやCIからアプリ・ワークフローを実行できます。

v1.17.0へアップグレードするときの注意点

既に運用している環境をv1.17.0に上げる場合、破壊的変更が含まれます。公式手順は「compose と .env をバックアップ → 最新コードを取得 → マイグレーション実行」です。

• 新規DBマイグレーションあり（flask db upgrade が必要）。add_conversation_cleanup_index は既存データにインデックスを張るため、conversations テーブルが大きいと時間がかかる
• 環境変数 EDITION が DEPLOYMENT_EDITION にリネーム。ENTERPRISE_ENABLED は削除
• AGENT_BACKEND_RUN_TIMEOUT_SECONDS → DIFY_AGENT_RUN_TIMEOUT_SECONDS に置換。DIFY_AGENT_SHELLCTL_AUTH_TOKEN / DIFY_AGENT_SHELLCTL_ENTRYPOINT は削除
• Docker Compose構成が変更され、docker-compose.e2b.yaml が追加。カスタマイズ済みのcomposeファイルは再適用が必要

本番運用で追加検討する項目

最小要件（2コア／4GiB）は検証用の下限です。実運用では以下を前提に設計してください。

• リソース：ドキュメント処理とベクトル検索がボトルネックになりやすい。公式は本番向け推奨スペックを数値で公開していないため、実データでの負荷試験が現実的
• バックアップ：PostgreSQL（アプリ設定・ログ）、ベクトルDB、アップロードファイルの3系統
• 公開範囲：社内利用ならVPN・社内ネットワークに閉じる。インターネット公開するならリバースプロキシでのTLS終端とアクセス制御が必須
• アップデート運用：セルフホストでは脆弱性対応のためのバージョン追従が事実上の義務

構築のハードルは「Dockerを扱える担当者が最低1名いること」です。ここが確保できないなら、無理にセルフホストせずCloudのProfessional／Teamから始めるほうが総コストは低くなります。

Difyの日本語対応はどこまで進んでいるか

UI・公式ドキュメントとも日本語が用意されており、日本語環境での利用ハードルは低い部類です。ただし公式日本語ドキュメントはAIによる自動翻訳です。

仕様の細部（環境変数名や上限値など）を確認するときは、日本語ページで当たりをつけて英語版で裏を取る運用が安全です。日本語RAGで精度を出すときの実務ポイントは次の2点になります。

1. チャンク分割の見直し — 日本語は既定のチャンクサイズだと文脈が切れることがあります。検索テストで実データを見ながら調整する前提で組むこと
2. 埋め込みモデルの選定 — 日本語に強い埋め込みモデルを選ぶだけで検索ヒット率が変わります。ただし次元数が大きいモデルはストレージ消費も増えるため、精度とプラン上限のバランスで決めます

Difyの強み

出典: langgenius/dify GitHub

1. モデルを固定せずに済む
複数のプロバイダーをMarketplace経由で接続でき、ローカルモデルにも対応します。価格改定や新モデル登場があっても、ワークフローの構造を変えずに差し替えられるのは長期運用で効きます。

2. 作る・試す・公開する・見るが1画面で完結
プロンプト設計、ワークフロー構築、ナレッジ管理、公開、ログ監視までが同じ画面に収まっています。ツールを繋ぎ合わせる手間がないため、非エンジニアが関わる社内プロジェクトで特に有利です。

3. セルフホストという選択肢がある
ソースコードが公開されているため、外部SaaSにデータを預けられない業務でも自社環境で完結できます。Cloudで検証してからセルフホストへ移す段階的な進め方も取れます。

4. 「作った後」の機能が厚い
ログ、アノテーション、トレース連携、Human-in-the-Loop、バージョン管理、CLI実行と、運用フェーズで必要になる機能が揃っています。2026年のリリースはこの領域への投資が中心です。

5. エージェントが再利用可能な資産になった
新しいAgentにより、一度作ったエージェントを単体アプリとしてもワークフローの1ステップとしても使えるようになりました。ワークフローごとに似たエージェントを作り直す無駄が消えます。

6. 公開監査を受けている
ISO 27001:2022、SOC 2 Type II、GDPR対応を2年連続で完了したと公式ブログが発表しており、Cloud版利用者は画面右上の「Compliance」からレポートをダウンロードできます。稟議で提示できる材料が公式経路で手に入るのは実務上の利点です。

Difyの弱み・できないこと

LangChain・n8n・Flowise／Langflowとの違い

LangChainとの比較が最も多く検索されますが、両者は競合というより層が違います。 LangChainはコードで書くフレームワーク、DifyはGUIで作って公開・運用まで担うプラットフォームです。

出典: langchain-ai/langchain GitHub

DifyとLangChainの選び分け

現在のLangChainは、エージェントを構成する本体（create_agent）、決定論的ワークフローと耐久実行を担う LangGraph、全部入り構成の Deep Agents、そして可観測性レイヤーの LangSmith という3〜4層の構成になっています。「LangChain＝チェーンをつなぐライブラリ」という2024年頃の理解のままだと、比較を誤ります。

判断の目安は次のとおりです。

• コードで細かく制御したい／既存のPythonアプリに深く組み込みたい → LangChain＋LangGraph
• 非エンジニアを含むチームで内製し、公開・運用まで一気に持っていきたい → Dify
• PoCはDifyで速く回し、要件が固まった部分だけコードで作り直す → 併用

重要なのは、両者が排他ではないことです。Difyのトレースを LangSmith に送る統合は公式に提供されています。 GUIで作りつつ、観測とデバッグはLangChain側のエコシステムに寄せる、といった構成も取れます。フレームワーク側の詳細な比較はAIエージェントフレームワーク比較で扱っています。

Difyとn8nの選び分け

n8nはSaaS間連携・業務自動化のツールで、課金単位も「ワークフロー実行回数」です。「複数SaaSをまたぐ定型業務の自動化」が主目的ならn8n、「LLMの精度とナレッジ設計が主目的」ならDifyという切り分けになります。実務では、n8nがトリガーと外部連携を担い、AI処理部分だけDifyのAPIを叩く構成も現実的です。中小企業での自動化の進め方は中小企業のAI自動化ガイドも参考になります。

DifyとFlowise／Langflowの選び分け

いずれもフロー型のLLMアプリビルダーで、個人の検証や学習には十分です。Flowiseは動作要件が軽く（Difyの最小4GiBに対して1GB程度でも動くとされます）、手元で試すには扱いやすい選択肢です。Difyとの差は、ナレッジ管理・アノテーション・ログ／トレース・チーム権限・複数の公開手段といった「組織で運用する側」の作り込みにあります。1人で試すならどれでも構いませんが、チーム運用に入ると差が出ます。

ライセンスと商用利用の条件

DifyはApache License 2.0の改変版で公開されており、商用利用そのものは可能です。 社内の業務プラットフォームとして使う、受託開発でバックエンドに使う、自社サービスの基盤として使うといった用途は、追加ライセンスなしで行えます。

別途Difyから商用ライセンスを取得する必要があるのは、次の2ケースだけです。

1. マルチテナントサービスとしての運用 — 書面による明示的な許可なく、Difyのソースコードを使ってマルチテナント環境を運用してはならない、と規定されています。ここでのテナントは1テナント＝1ワークスペースと定義されています。要は「Difyをそのまま顧客ごとに切って他社向けSaaSとして提供する」形が該当します
2. ロゴ・著作権表示の削除／改変 — Difyのフロントエンド（ソースの web/ ディレクトリ、Dockerの web イメージ）を使う場合、コンソールやアプリ上のロゴ・著作権情報を削除・改変できません。フロントエンドを使わずAPIのみを利用する構成には、この制限は適用されません

これ以外はApache License 2.0に従います。加えてライセンス文には「本製品のインタラクティブデザインは意匠権で保護されている」との記載もあります。グループ会社への横展開のようなグレーゾーンは、自己判断せず開発元へ確認するのが安全です。

セキュリティ：セルフホストなら「バージョン追従」が必須条件

Difyを自社サーバーで運用するなら、脆弱性情報の追跡とアップデートを運用作業として組み込む必要があります。 これはDify固有の欠陥というより、活発に開発されているOSSを本番で使う際の一般的な前提ですが、実際に高深刻度の指摘が継続して公開されているため、精神論では済みません。

公開されている主なセキュリティアドバイザリ

半年の間にHigh判定が複数公開されている、というのが事実です。「無料だが運用は無料ではない」というのが、Community Editionを選ぶときの正確な理解になります。

v1.16.1〜v1.17.0で入ったセキュリティ強化

一方で、直近のリリースではハードニングも進んでいます。

• Cloudflare Turnstile（CAPTCHA） をサインイン／メールコードログインに任意適用できる
• メールコード認証の試行回数制限とトークン有効期限、エージェント用の短命認可トークン
• アクセス制御のスコープ厳格化 — dataset／document／RAG／conversation／ワークスペース資格情報／OAuthクライアントを所有者とアプリスコープに一貫して束縛し、複数の未認可アクセス経路を封鎖
• SSRF・アウトバウンド強化 — 外部HTTP接続フェーズを5秒に制限、エージェントのダウンロード／実行タイムアウトを設定可能に
• Azure Key Vault／プラガブルKMS — 鍵の払い出し・暗号化・復号とローテーション設定に対応
• v1.16.1では Squidプロキシによるエージェントサンドボックスのネットワーク隔離

エージェント機能を業務で使うなら、v1.16.1以上、できればv1.17.0を選ぶのが妥当です。

セルフホスト運用のチェックリスト

• GitHubのReleasesとSecurity Advisoriesを購読し、更新を検知できる体制にする
• 少なくとも月1回、バージョン差分を確認して適用可否を判断する
• アップデート前にDB・ファイルのバックアップを取る（v1.17.0はDBマイグレーションを含む）
• 管理コンソールをインターネットに直接公開しない（VPN・IP制限・リバースプロキシ）
• LLMのAPIキーは環境変数・シークレット管理で扱い、権限とレート上限を絞る
• アップロード可能なファイル形式を業務上必要な範囲に限定する
• エージェントのサンドボックス実行を使う場合は、利用者を社内の信頼できる範囲に限定する

公式ドキュメントは「ログには完全なユーザー会話が含まれ、機密情報が含まれる場合がある」と明記し、現地のデータプライバシー規制への準拠、プライバシーポリシーの公開、必要に応じた利用者同意の取得を求めています。Cloud版を選べばパッチ適用はDify側で行われるため、「セルフホストのほうが安全」ではなく「安全にする責任を自社が引き受ける」という理解が正確です。生成AI全般のリスク整理は生成AIのセキュリティリスクと対策、エージェント特有の権限設計はAIエージェントのセキュリティガイドで扱っています。

日本国内での導入の広がり

国内では、金融・通信のような大規模組織と、自治体・大学のような「現場に作らせたい」組織の双方で採用が公表されています。各組織や開発元の公表資料で確認できる代表例は次のとおりです（内容は各社の発表時点のもの）。

共通しているのは、情シスが基盤を用意し、各部門が自分でアプリを作る「現場内製型」の運用です。ここがコードベースのフレームワークとの分岐点になります。国内では解説記事や活用事例が豊富で、SIerによる導入支援も存在するため、日本語での情報収集がしやすい点も選定理由になりやすいところです。

Cloud・Community・Enterpriseの選び方

導入形態は、次の3問を順に判断すると迷いません。

Q1. 扱うデータを外部SaaSに置けますか？

• 置ける → Q2へ
• 置けない（機微情報・規程上不可） → Community（セルフホスト） または Enterprise。ただしDockerを扱える担当者が必要

Q2. 利用は何名規模で、SSOや複数ワークスペースが必要ですか？

• 1名・検証だけ → Sandbox（無料）
• 3名程度・単一プロジェクト → Professional（$590/年）
• 最大50名・複数プロジェクト → Team（$1,590/年）
• 全社展開でSSO・監査ログ・複数ワークスペースが要る → Enterprise（個別見積もり）

Q3. インフラを運用できる担当者がいますか？

• いない → Cloud一択。セルフホストは初期構築より継続運用（アップデート・バックアップ）が負担になります
• いる → Communityで自社構築。全社展開の段階でEnterpriseへ切り替える経路も取れます

コストの目安は次のとおりです。

こんな方におすすめ / おすすめしない方

おすすめできるケース

• 社内の生成AI活用をノーコードで立ち上げたい情シス・DX担当 — Pythonを書かずにRAGや承認フロー付きの業務アプリを作れる
• 各部門に自分でアプリを作らせたい大企業・自治体 — 基盤を情シスが用意し、現場が内製する運用に合う
• 社内文書検索（RAG）を短期間で形にしたい企業 — ナレッジ機能が標準搭載で、取り込みから公開まで一気通貫
• 複数のLLMを比較しながら選定したいチーム — モデルを差し替えても構成を作り直さずに済む
• エージェントを社内の複数業務で使い回したいチーム — 新しいAgentにより、一度作った能力を単体アプリにもワークフローの一部にも使える
• DifyのアプリをClaude DesktopやCursorから呼び出したい開発者 — MCPサーバーとしての公開に対応
• 機密データを社内に閉じたい企業でDocker運用者がいる場合 — Community版で自社完結の構成が組める

おすすめしないケース

• 独自アルゴリズムをコードで細かく制御したいエンジニア — LangChain＋LangGraphのほうが素直で、保守もしやすい
• 主目的がSaaS間連携・定型業務の自動化 — n8nやZapierの領域
• Difyをそのままマルチテナントの自社SaaSとして販売したい事業者 — 商用ライセンス契約が前提
• インフラを運用できる人材がおらず、かつクラウド保存にも懸念がある組織 — どちらの選択肢にも無理が出るため、社内ルールの整理が先
• LLM費用込みの固定料金パッケージを求めている組織 — 費用はプラットフォーム料金とAPI従量課金の組み合わせになる
• 不特定多数の外部ユーザーにコマンド実行型エージェントを提供したい場合 — 新しいAgentはベータであり、サンドボックスとはいえ実行環境を伴う

よくある質問（FAQ）

Q1. 最新バージョンは？アップデートは必要ですか？
2026年9月1日時点の最新安定版はv1.17.0（2026年8月25日リリース）です。Cloud版は自動で更新されますが、セルフホストは自分で更新します。2026年に入ってからHigh判定のアドバイザリが複数公開されており、古いバージョンで止めている環境は優先的に更新すべきです。なおv1.17.0は環境変数のリネーム（EDITION → DEPLOYMENT_EDITION）とDBマイグレーションを含むため、バックアップを取ってから作業してください。

Q2. AIクレジット5,000は「5,000回の会話」という意味ですか？
厳密には違います。公式仕様ではAIレスポンス1回（入力1回＋出力1回）で1回分としてカウントし、消費トークン数には依存しません。ただし必要なクレジット数はモデルごとに異なり、大きいモデルほど多く消費します。上位モデルを常用するなら、クレジット枠の消費は想定より速く進みます。

Q3. Sandboxの200クレジットを使い切ったらどうなりますか？
Sandboxのクレジットは一回限りで、毎月の補充はありません。使い切った後は自分のAPIキーを登録して利用を継続します。Difyの機能自体が止まるわけではなく、LLM呼び出しの費用負担先が変わるという理解が正確です。AIクレジットと自前キーは併用でき、優先度を設定してフォールバックさせることもできます。

Q4. セルフホスト版に必要なスペックは？
公式の最小要件はCPU 2コア以上・メモリ4GiB以上、Docker Compose v2.24.0以降です。ただしこれは検証用の下限で、起動するコンテナは16個あります。ナレッジのドキュメント量が増えるほど処理負荷が上がるため、本番では実データで負荷を測って決めるのが確実です。

Q5. 個人情報や機密文書を扱っても大丈夫ですか？
社内ルール次第です。Cloud版はISO 27001:2022・SOC 2 Type II・GDPR対応の監査を受けており、Cloud利用者は画面右上の「Compliance」からレポートを取得できます。外部保存自体が規程で認められない場合は、セルフホストかEnterpriseのVPC構成を選ぶことになります。加えて、会話やログを削除してもアップロードされたファイルは消えない仕様があるため、ファイル削除の手順は別途決めておいてください。

Q6. 無料で使い続けることはできますか？
Community Edition（OSS版）を自社サーバーで動かせば、Dify自体のライセンス費用はかかりません。ただしサーバー費用、LLM API費用、アップデート対応の工数は発生します。Cloud版のSandboxも無料ですが、1メンバー・5アプリ・ナレッジ50文書・ログ30日という枠内での利用です。Sandboxのログは30日で完全削除され、後からアップグレードしても復元できません。

Q7. DifyとLangChain、どちらを選ぶべきですか？
チームで素早く形にして公開・運用したいならDify、コードで細かく制御したいならLangChain（＋LangGraph）です。排他ではなく、Difyで仮説検証してから要件が固まった部分をコードで作り直す進め方も一般的です。DifyのトレースをそのままLangSmithへ送る統合も公式に用意されています。

Q8. 新しいAgentは従来のAgentノードと何が違いますか？
最大の違いは再利用性です。従来はエージェントがワークフローに紐づいており、別の場所で使うには作り直しが必要でした。新しいAgentはエージェント自体が独立したアプリになり、単体のチャットアプリとしてもワークフローの1ステップとしても呼び出せます。専用サンドボックス内でコマンド実行やファイル操作もできます。ただしベータ機能である点は前提にしてください。

Q9. 自社サービスに組み込んで販売できますか？
自社サービスのバックエンドとしてAPIを組み込む用途は、追加ライセンスなしで可能です。一方、Difyそのものをマルチテナント型のSaaSとして他社に提供する場合や、コンソール上のロゴ・著作権表示を削除・改変する場合は商用ライセンスが必要になります。

Q10. 学生・教職員は無料で使えますか？
Dify for Educationにより、年額のProfessionalプランを無償で利用できます。学校発行のメールアドレスでの登録が必須で、月額プランや既存の有料サブスクには適用されません。AIクレジットはSandbox相当（200・補充なし）にとどまるため、実質的には自前のAPIキー前提の運用になります。毎年の再認証が必要です。

まとめ

Difyは、AIアプリの構築から公開・運用までをGUIで一気通貫に扱えるオープンソースプラットフォームです。2026年9月時点の最新版はv1.17.0で、8月末に発表された新しいAgentにより、エージェントが「ワークフローの部品」から「独立して再利用できる資産」へ変わりました。

導入判断の要点は次のとおりです。

• 試すだけならCloudのSandboxが最短。アカウント登録とモデル設定だけで動く
• チーム利用ならProfessional（$590/年）かTeam（$1,590/年）。既定表示は年額のため、月額契約なら申込画面で単価を確認する
• 費用はDify料金＋LLM API従量課金の二層構造。AIクレジットは「1レスポンス＝1回」でカウントされ、モデルによって消費量が変わる
• データを外に出せないならCommunity（セルフホスト）。ただしDocker運用者とアップデート体制が前提で、実コストはサーバー費用＋API費用＋工数
• 全社展開・SSO・複数ワークスペースが必要ならEnterprise（個別見積もり）
• 商用利用は原則OK。ライセンス取得が必要なのは「マルチテナントSaaS化」と「ロゴ・著作権表示の削除」の2ケースのみ
• セルフホストではバージョン追従が必須。2026年もHigh判定のアドバイザリが継続して公開されている

コードで細かく制御したい要件が主ならLangChain＋LangGraphのほうが適しています。逆に、非エンジニアを含むチームで内製し、公開と運用まで自分たちで回したいなら、現時点でDifyは有力な選択肢です。

あわせて読みたい

• AIエージェントとは？仕組み・活用事例・リスクを解説 — Difyで作れるエージェントの基礎概念
• RAGとは？仕組みと最新動向を解説 — ナレッジ機能の土台になる技術
• AIエージェントフレームワーク比較 — LangChain・LangGraphなどの選び分け
• MCPの新ロードマップ（2026年後半） — DifyアプリをMCPサーバーとして公開する前提知識
• 生成AIのセキュリティリスクと対策 — 業務利用時のリスク整理
• 生成AIツールおすすめ比較 — 主要ツールの全体像