Difyとは｜企業導入の判断ガイド・料金・商用利用・n8nとの使い分け【2026年9月版】

本記事の情報について: 本記事の料金・ライセンス条件・システム要件は、2026年9月5日時点でDifyの公式サイト・公式ドキュメント・GitHubリポジトリのライセンス原文を直接確認した内容に基づいています。事例の数値はすべて当該企業またはDifyの公式発表を出典としています。Difyは更新の速いソフトウェアであり、料金体系もバージョンも変わります。意思決定に用いる際は各出典の最新版をご確認ください。ライセンスに関する記述は一般的な整理であり、個別案件の法的助言ではありません。

「Difyを使えば生成AIアプリが作れるらしい」と聞いて調べ始めると、どのサイトも似たような説明にたどり着きます。ノーコードで作れる、RAGが標準搭載されている、複数のLLMを切り替えられる——。それらはすべて正しいのですが、実際に社内で導入を検討する立場になると、その説明では一歩も前に進めません。

私たちがこの記事を書いたのは、検索データを見て、ある非対称に気づいたからです。後ほど「Difyの検索需要は縮小している」の章で実測データとともに詳しく述べますが、「Dify とは」の検索需要はこの12か月ほぼ横ばい（起点・終点とも月6,600）である一方で、「Dify 料金」「Dify 活用事例」「Dify 商用利用」といった判断材料を探すキーワードは6割以上（最大で−85%）減っています（いずれもGoogle広告の丸められた概数）。名前を聞いて調べる人の減り方は緩やかなのに、その先の判断材料を取りに行く人だけが激減している。これは「Difyとは何か」の説明が足りないのではなく、「Difyを採用すべきか」に答える情報が足りないということだと私たちは考えています。

そこで本記事は、Difyの機能紹介ではなく、導入判断のための記事として構成しました。料金は公式ページのHTMLから実際の値を取り出し、ライセンスはGitHubの原文を条項ごとに分解し、事例は企業自身の公式発表だけを使っています。二次情報の転記はしていません。

この記事の要点

• Difyとは、LLMを使ったアプリを画面上で組み立てるための開発プラットフォームである。ChatGPTのような完成した対話サービスではなく、ChatGPT等のモデルを呼び出して自社用のアプリを作る側の道具にあたる
• 料金でもっとも誤解されやすいのは、Difyの利用料とLLMの利用料が別物である点。有料プランに含まれる「message credits」は公式に「モデルを試すために提供されるもの」と説明されており、使い切ったあとは自分のAPIキーに切り替える設計になっている
• Dify Cloudの課金単位はユーザー数ではなくワークスペース単位である。Professionalは1ワークスペース・メンバー3名まで、Teamは1ワークスペース・メンバー50名まで（2026年9月5日時点）
• 商用利用はライセンス原文で明示的に認められている。ただし「マルチテナント環境での運用」と「フロントエンドのロゴ・著作権表示の削除や改変」の2つのいずれかに該当する場合は、別途商用ライセンスが必要になる（2026年9月5日時点の原文）
• 一方で公式の料金ページは、無償のCommunity版を「オープンソース愛好家・個人開発者・非商用プロジェクト向け」と位置づけている。ライセンス原文と料金ページの位置づけには温度差があり、業務利用の可否は自社の使い方に照らして要確認である
• 選定の分岐は3つで決まる。LLMが主役ならDify、システム連携が主役ならn8n、込み入った制御が要るならコード。この3点で切ると迷わない
• 公開事例では、リコーグループが国内グループ社員約3万人に展開して約10,200個のアプリが作られている（2026年7月27日時点）。ただしリコージャパンは同時に、Dify活用が拡大した企業に共通する課題として「IT管理者が利用状況を十分に把握できない」ことも公表しており、作れることと使われることは別である
• 検索需要は縮小局面にあるが、縮小の幅は語によって大きく違う。料金・事例・商用利用といった判断材料を探す語が6割以上減る一方、「Dify とは」は横ばいである。なおヘッドワード同士で比べるとn8nは−55%、Difyは−33%でn8nのほうが減り幅が大きく、「Difyがn8nに置き換えられた」という説明はデータでは裏づけられない
• Difyを続けるかコード開発へ切り替えるかは、要求がいくつ積み上がったかで判断できる。可用性・監査・基幹連携・込み入った制御を含む8項目のうち3つ以上が該当したら、切り替えを検討する段階である（本文にチェックリストを掲載）

Difyとは｜30秒でわかる要点

Difyとは、大規模言語モデル（LLM）を使ったアプリケーションを、画面上でブロックを組み立てるように開発・運用できるオープンソースのプラットフォームです。開発元はLangGenius, Inc.。日本では2025年2月に日本法人の株式会社LangGeniusが設立されており、同社は自社サイトで「Dify開発元｜日本法人」と位置づけ、Difyのセルフホスト版Enterpriseライセンスの販売などを事業内容として挙げています（出典: 株式会社LangGenius 会社概要、2026年9月5日確認）。

日本語の読み方は、公式筋でも表記が分かれています。開発元の日本法人である株式会社LangGeniusは自社サイトで「Dify（ディーフィー）」と表記し（出典: 株式会社LangGenius、2026年9月5日確認）、公式の販売・構築パートナーであるリコーは自社のニュースリリースで「Dify（ディフィ）」と表記しています（出典: リコー公式リリース（2026年6月8日））。どちらも公式筋の表記なので、社内で通じるほうを使って差し支えありません。

もう少し具体的に言うと、Difyは次の3つを1つの画面にまとめた道具です。

1. プロンプトの管理 — どのモデルに、どういう指示を与えるかを画面上で編集し、結果を見比べながら調整する
2. 社内データの接続（RAG） — PDFやマニュアルを読み込ませ、その内容に基づいて回答させる
3. 処理の連結（ワークフロー） — 「要約する → 翻訳する → 分類する」のような複数ステップを線でつないで自動化する

これらは個別のライブラリを使えばコードでも実装できます。Difyの価値は、それをコードを書かずに、かつ1つの管理画面の中で完結させられる点にあります。

ChatGPTとの違い

もっとも多い誤解が、DifyとChatGPTを同じ土俵で比べてしまうことです。この2つは競合しません。

DifyはOpenAIのモデルを呼び出す側です。つまり「ChatGPTかDifyか」ではなく、「ChatGPTをそのまま使うか、ChatGPTのモデルを使った自社用アプリをDifyで作るか」という問いになります。

提供形態

Difyには大きく2つの提供形態があります。

• Dify Cloud — 公式が運用するSaaS。ブラウザで登録すればすぐ使える。無料のSandboxと有料のProfessional・Teamがある
• Community Edition（セルフホスト） — ソースコードを自社のサーバーやクラウドに配置して動かす。ソフトウェア自体のライセンス費用は無償

このほか、大規模利用や高度なガバナンス要件に対応するDify Enterpriseが別途提供されています。本記事では「料金の全体像」と「商用利用とライセンス」の2章で、この3つの違いを料金とライセンスの両面から扱います。

まず結論｜Difyを選ぶべき場合／別の手段が良い場合

Difyを選ぶべきかは、LLMが主役か、システム連携が主役か、込み入った制御が要るか——この3点で決まります。機能の説明よりも先に、その分岐を示します。Difyは万能ではなく、向く場面と向かない場面がはっきり分かれる道具だからです。

Difyが向いている場合

別の手段が良い場合

判断の順序

私たちが実務で使っている順序は次のとおりです。

1. そもそも作る必要があるか — 既製のSaaSで足りるなら作らない
2. LLMが主役か、システム連携が主役か — システム連携が主役ならn8n等の自動化基盤を先に検討する
3. 誰が保守するか — 作った人が異動したあと誰も触れないアプリは、作らないほうがましである
4. 外部に提供するか — 提供するならライセンス条件を先に確認する（「商用利用とライセンス」の章）

Difyでできること6つと、できないこと

Difyの機能は多くの記事で紹介されていますが、「できること」だけを並べても導入判断には使えません。ここでは各機能に対して、その機能で行き詰まるポイントを対で示します。

RAGについての補足

RAG（検索拡張生成）は、社内文書を読み込ませて、その内容に基づいて回答させる仕組みです。Difyはこれを標準機能として持っているため、「PDFをアップロードして質問する」ところまでは短時間で到達できます。

ただし、実務で問題になるのはそこから先です。想定した文書が検索で拾われない、複数の文書にまたがる質問に答えられない、古い版と新しい版が混在して誤った回答が出る——といった精度の課題は、アップロードするだけでは解決しません。この領域の設計と改善についてはRAG構築の進め方で扱っています。

エージェント機能についての補足

Difyのエージェント機能は、LLMに複数のツールを与えて、目的に応じて自律的に使わせる仕組みです。デモとしては印象的に動きますが、業務に載せる段階では「毎回同じ結果になるとは限らない」という性質が重くのしかかります。

そのため実務では、自律的に判断させる範囲をできるだけ狭くし、決まった順序で動く部分はワークフローとして固定するのが定石です。この設計方針についてはAIエージェントのワークフロー設計とAIエージェントの構築手順で詳しく扱っています。

できないこと（明確な限界）

• 画面の表現力を超える制御はできない。 込み入った状態管理や独自アルゴリズムが必要になった時点で、コード開発へ切り替える判断が要ります
• アプリの品質は保証されない。 誰でも作れるということは、誰でも品質の低いものを作れるということでもあります。「企業導入事例」の章で触れるとおり、これは実際の導入企業で表面化している課題です
• LLMの出力の正しさは担保されない。 Difyはモデルを呼び出す枠組みであり、誤った回答が出ないことを保証する仕組みではありません

料金の全体像｜公式プラン表と「LLM料金は別」の構造

Difyの費用は、Difyの利用料とLLMの利用料の2階建てになります。以下はすべて、2026年9月5日時点でDify公式の料金ページを直接確認した内容です。

Dify Cloud のプランと上限

出典: Dify Pricing（2026年9月5日確認。価格は税別で、決済時に税が加算される場合がある旨が記載されています）

※「文書処理の優先度」と「ワークフロー実行速度」は、公式表記で別々の語列が使われています。同じ「優先」でも行によって段が異なるため、行をまたいで語を比べないでください。上位・下位は列の位置で判断してください。なお「ワークフロー実行速度」の Standard / Faster / Priority は公式に順位が明示されているわけではなく、プランの上下からの推定です。

料金でよくある3つの誤解

誤解①：課金単位は人数ではなくワークスペース

公式ページの価格表記は「per workspace / month」です。つまりProfessionalの59ドルは「1人あたり59ドル」ではなく「1ワークスペースあたり59ドル、そこにメンバーを3名まで置ける」という意味になります。50名で使いたい場合、Professionalを17契約するのではなく、Teamプラン（1契約でメンバー50名）を選ぶことになります。

誤解②：月額だけを見ると、年間予算を20%多く見積もる

公式ページには「Bill Annually Save 17%」と明記されており、月払い59ドルに対して年払いは590ドル（月あたり約49.2ドル相当）、月払い159ドルに対して年払いは1,590ドル（月あたり約132.5ドル相当）です。

数字の向きに注意してください。公式が言う「17%お得」は、月払いを12か月続けた場合（59ドル×12＝708ドル）に対する割引率です。 逆から見ると、年払いを見落として月払いのまま年間予算を組むと、590ドルで済むところを708ドル、つまり20%多く計上することになります。Teamプランでも同じ比率です（1,908ドル対1,590ドル）。私たちが確認した解説記事4本は、いずれも年払い価格に言及していませんでした。年間予算を組む際は必ず公式ページで年払い価格を確認してください。

誤解③：message credits はLLM利用料ではない

これがもっとも重要な誤解です。公式ページはmessage creditsについて、「OpenAI・Anthropic・Gemini・xAI・TongyiといったモデルをDify上で手軽に試せるようにするために提供されるもので、消費量はモデルの種類によって異なる。使い切ったあとは自分のAPIキーに切り替えられる」という趣旨の注記を置いています（原文: "Message credits are provided to help you easily try out different models from OpenAI, Anthropic, Gemini, xAI, Tongyi in Dify. Credits are consumed based on the model type. Once they're used up, you can switch to your own API key."）。

つまりmessage creditsは「お試し枠」であって、業務で使う分のLLM利用料ではありません。本格的に使う段階では、自社でOpenAIやAnthropicのAPIキーを取得し、その利用料を別途各モデル提供元に支払うことになります。

したがって、企業が実際に負担する総額は次の足し算になります。

総額 = Difyの利用料（プラン料金 or セルフホストのインフラ費）
     + LLMのAPI利用料（各モデル提供元へ）
     + 埋め込みモデル・ベクトル検索など周辺の利用料
     + 運用にかかる人件費

「Difyは月59ドルから」という表現だけを見て稟議を通すと、後から2番目以降の費目が乗ってきます。この構造は、生成AIツールの選定でも共通する落とし穴です。

なお、Sandboxの200 message creditsについては、公式ページの表記に注意が必要です。ProfessionalとTeamには「5,000 message credits / month」「10,000 message credits / month」と月次であることが明記されているのに対し、Sandboxは「200 message credits」とだけ記載され、月次を示す表記がありません。またDifyのGitHubリポジトリのREADMEも、Sandboxプランについて「200回分の無償のGPT-4呼び出しを含む（includes 200 free GPT-4 calls in the sandbox plan）」という説明にとどめています。

他社の解説記事には「200クレジット/月」と書いているものがありますが、公式表記からは月次更新であると読み取れません。無料枠の量を前提に検討する場合は、実際にアカウントを作成して残量表示を確認することをおすすめします。

Community版（セルフホスト）とEnterprise版

出典: Dify Pricing（2026年9月5日確認）

Community版は「ソフトウェアのライセンス費用が無償」であって、「タダで運用できる」という意味ではありません。サーバー費用・運用工数・アップデート対応は自社の負担になります。この構造は自社環境でLLMを動かす場合と共通しており、費用の全体像はローカルLLMの費用構造で整理した考え方がそのまま当てはまります。

そして表の「位置づけ」の行に注目してください。公式の料金ページはCommunity版を「非商用プロジェクト向け」と説明していますが、ライセンス原文は商用利用を明示的に認めています。この温度差は企業の法務確認でつまずく箇所なので、「商用利用とライセンス」の章で正面から扱います。

商用利用とライセンス｜原典の条件を分解する

Difyの商用利用は、ライセンス原文で明示的に認められています。以下はGitHubリポジトリのLICENSEファイルの原文を確認した内容です（2026年9月5日確認）。

なお本章が扱うのは、GitHubで公開されているソースコードに適用されるライセンスです。Dify Cloudの利用には、これとは別の契約文書が関わります。公式の料金ページのフッターには、利用規約（Terms of Service）・エンドユーザーライセンス契約（End User License Agreement）・データ保護契約（Data Protection Agreement）などが掲示されています。どの文書がどこまで適用されるかは各文書の記載によるため、Cloud利用を前提に検討する場合は必ず原文をご確認ください。

ライセンスの基本構造

原文の冒頭は「Dify is licensed under a modified version of the Apache License 2.0, with the following additional conditions（Difyは追加条件を付したApache License 2.0の修正版のもとでライセンスされる）」と述べています。

そして商用利用については、原文が明確にこう定めています。

Dify may be utilized commercially, including as a backend service for other applications or as an application development platform for enterprises. （Difyは、他のアプリケーションのバックエンドサービスとして、また企業向けのアプリケーション開発プラットフォームとして利用することを含め、商用利用が可能である。）

つまり、企業が社内業務のためにDifyを使うことは、ライセンス上は問題ありません。 そのうえで、次の2条件のいずれかに該当する場合は、開発元から商用ライセンスを取得する必要があると定められています。

商用ライセンスが必要になる2条件

条件a：マルチテナント環境での運用

原文は「Unless explicitly authorized by Dify in writing, you may not use the Dify source code to operate a multi-tenant environment.（Difyから書面で明示的に許諾されない限り、Difyのソースコードをマルチテナント環境の運用に用いてはならない）」としています。

重要なのは、原文が「テナント」の定義まで書いていることです。

Within the context of Dify, one tenant corresponds to one workspace. The workspace provides a separated area for each tenant's data and configurations. （Difyの文脈において、1テナントは1ワークスペースに対応する。ワークスペースは、各テナントのデータと設定について分離された領域を提供する。）

つまり「ワークスペースを複数立てて、それぞれ別の主体に使わせる形」がマルチテナントに当たります。自社の1ワークスペースを社員が共同で使う通常の社内利用は、この条件には当たらない——というのが、原文のテナント定義に沿った読み方です。一方、顧客ごとにワークスペースを切って提供するようなサービス形態は該当します。

条件b：ロゴ・著作権表示の削除または改変

原文は「In the process of using Dify's frontend, you may not remove or modify the LOGO or copyright information in the Dify console or applications.（Difyのフロントエンドを使用する過程で、Difyのコンソールやアプリケーション内のロゴまたは著作権表示を削除・改変してはならない）」としています。

こちらも「フロントエンド」の定義が原文に書かれています。

For the purposes of this license, the "frontend" of Dify includes all components located in the web/ directory when running Dify from the raw source code, or the "web" image when running Dify with Docker. （本ライセンスにおいて、Difyの「フロントエンド」とは、ソースコードから実行する場合は web/ ディレクトリ配下の全コンポーネント、Dockerで実行する場合は "web" イメージを指す。）

そして原文は「This restriction is inapplicable to uses of Dify that do not involve its frontend.（この制限は、フロントエンドを伴わない使い方には適用されない）」とも述べています。つまりDifyの画面を使わず、APIだけを自社アプリケーションから呼び出す構成であれば、この条件は問題になりません。

判定の手順

自社の使い方がどちらに当たるかは、次の順に確認してください。

1. ワークスペースを複数立てて、別々の主体（顧客・グループ会社等）に使わせるか？ → はい なら条件aに該当。商用ライセンスの取得が必要
2. Difyの画面（コンソールや公開アプリのUI）を使うか？ → いいえ（APIのみ利用）なら条件bは不適用
3. 画面を使う場合、ロゴや著作権表示を消したり変えたりするか？ → はい なら条件bに該当。商用ライセンスの取得が必要
4. 1と3がいずれも「いいえ」であれば、ライセンス原文の追加条件には当たらず、それ以外はApache License 2.0の条件に従う

なお原文の末尾には「The interactive design of this product is protected by appearance patent.（本製品のインタラクティブデザインは意匠権によって保護される）」との記載もあります。UIの見た目そのものを模倣する場合は、ライセンスとは別の権利が関わる可能性があります。

断定できない点（法務確認で必ず聞かれる）

「料金の全体像」の章の末尾で予告した温度差を、ここで正確に整理します。

• ライセンス原文は商用利用を明示的に認めており、上記2条件以外の制限は設けていません
• 公式の料金ページは、Community版を「オープンソース愛好家・個人開発者・非商用プロジェクト向け」と説明し、「商用ライセンス許諾」をEnterprise版の項目として挙げています

この2つは論理的には矛盾しません（料金ページは想定利用者を述べたマーケティング上の説明であり、法的な許諾範囲を定めているのはライセンス原文である、という読み方が可能です）。しかし企業の法務部門が両方を読めば、確実に質問が出ます。

そのため実務上は、次のいずれかをおすすめします。

• 社内利用にとどまる場合でも、判断の根拠としてライセンス原文の該当箇所を稟議書に添付しておく
• 外部提供・マルチテナント・ロゴ改変のいずれかに触れる可能性がある場合は、着手前に開発元へ書面で確認する（原文が「explicitly authorized by Dify in writing」と書面での許諾を求めているため）
• 判断に迷う場合は、自社の顧問弁護士に確認する

なお原文は、コントリビューター（コードの提供者）が同意すべき事項として「The producer can adjust the open-source agreement to be more strict or relaxed as deemed necessary.（開発元は必要と判断した場合、オープンソース契約をより厳格にも緩和にも調整できる）」と定めています。適用の主体はコントリビューターですが、いずれにせよライセンス条件は将来変わりうるという前提で、依存度が高くなる設計は避けたほうが安全です。

セルフホスト（Community版）の要点

社内データを外部に出せない場合、Community版を自社環境で動かす選択肢があります。ここでは公式ドキュメントに記載された内容と、実務で検討が必要になる論点を分けて示します。

公式が示す最低システム要件

Dify公式ドキュメントおよびGitHubリポジトリのREADMEは、次を最低要件として挙げています（2026年9月5日確認）。

この数値の読み方に注意してください。これは「Difyが起動する」ための最低ラインであり、業務で複数人が使う際の目安ではありません。 実際の必要スペックは、同時に使う人数・扱う文書量・ベクトル検索の負荷によって変わります。検証環境と本番環境で同じ構成を前提にしないでください。

公式ドキュメントに記載された導入手順

以下は公式ドキュメントに記載されている手順です。私たちが実行して動作確認したものではありません。実施する際は必ず公式ドキュメントの最新版を参照してください。

# 1. 最新リリースのタグを指定してリポジトリを取得
git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git

# 2. docker ディレクトリへ移動
cd dify/docker

# 3. 環境変数ファイルを用意
cp .env.example .env

# 4. コンテナを起動
docker compose up -d

# 5. 状態を確認
docker compose ps

起動後は http://localhost/install にアクセスして初期設定を行う、と公式ドキュメントおよびREADMEに記載されています。

手順書に書かれない、運用で効いてくる論点

導入手順そのものは短いのですが、社内で使い続けるとなると別の検討が必要になります。私たちが実務で必ず確認するのは次の点です。

とくに「モデルの接続先」は見落とされがちです。Difyをセルフホストしても、接続先がOpenAIのAPIであれば、プロンプトと社内文書の内容は外部に送信されます。「セルフホストにしたから社内データは外に出ない」は成り立ちません。データを本当に外に出したくない場合は、モデル自体も自社環境で動かす必要があり、その判断材料はローカルLLMの導入判断にまとめています。

企業導入事例｜業務種別×効果

Difyの企業導入で、企業自身またはDifyの公式発表として具体的な数値を確認できたのは、私たちが調べた範囲ではリコーグループとカカクコムの2社でした。以下ではこの2社と、国内の推進体制を扱います。出典が確認できない数値は掲載していません。

リコーグループ｜全社展開と、その先に出てきた課題

リコーグループはDifyの導入企業として、もっとも詳細に経過を公表しています。グループ各社の公式ニュースリリースから時系列を追うと、次のようになります。

注目すべきは、2026年7月31日のリリースに書かれた課題認識です。リコージャパンは、Dify活用が拡大した企業に共通する課題として次を挙げています。同サービスはリコーグループ自身の社内実践から生まれたものだと同リリースに明記されています。

企業におけるDify活用が拡大し、社員が業務に応じたアプリケーションを開発・活用することで業務効率化が進む一方、IT管理者にとっては増加するアプリケーションの利用状況や活用実態を十分に把握することが難しいため、利用促進やコスト最適化に向けた管理・運用が課題となっています。

出典: リコージャパン公式リリース（2026年7月31日）

これはDifyを大規模に展開した現場から出てきた課題であり、導入検討時にもっとも参考にすべき情報だと私たちは考えています。約3万人（2026年6月時点）が利用可能な環境で約10,200個（2026年7月27日時点）のアプリが作られたということは、単純計算で社員3人に1個の割合です。そのすべてが日常的に使われているとは考えにくく、実際に同社は「誰が・何を・どれだけ利用しているか」を可視化するダッシュボードを後から必要としています。

作れることと、使われることは別です。 この点は「PoCで止まる企業と本番に載る企業の差」の章で改めて扱います。

カカクコム｜Dify Enterprise版での全社展開

Difyの公式ブログが公開している事例です（2025年11月21日公開）。

出典: Dify公式ブログ（2025年11月21日公開。Dify提供元による事例紹介であるため、記載は同社の視点によるものである点にご留意ください）

業務種別ごとの適用パターン

上記2社の公表内容と、公式が挙げる用途を業務種別で整理すると次のようになります。効果の数値は出典のあるものだけを記載しています。

なお検索結果には「議事録作成で年間◯時間削減」といった具体的な数値も流通していますが、私たちが一次情報を確認できなかったため、本記事には掲載していません。

日本国内の推進体制

2025年9月1日、株式会社LangGenius・株式会社NTTデータ・日本電子計算株式会社の3社共同で一般社団法人Dify協会（英文名: Japan Association for Dify）が設立されています。代表理事は株式会社LangGeniusの亀茲マルダン氏（同社サイトでの表記は「キジ マルダン」、役職表記は代表取締役社長）。日本市場向けの品質基準・ガイドラインの策定、先進事例の収集と共有、産学官連携の促進などを活動内容として挙げています。

出典: 一般社団法人Dify協会 設立に関するプレスリリース（PR TIMES）（2026年9月5日確認）

導入検討にあたっては、こうした国内の推進体制が整っていることも判断材料になります。とくに「開発元が海外企業であること」を懸念する場合、日本法人と業界団体の存在は一定の材料になるでしょう。

Difyの検索需要は縮小している｜実測データと、その正しい読み方

Dify関連キーワードの検索需要は、直近12か月で縮小しています。ただし減り方は一様ではなく、「Dify 料金」「Dify 活用事例」「Dify 商用利用」「Dify デメリット」といった語が6割以上減る一方で、「Dify とは」はほぼ横ばいです。 以下は2026年9月5日に私たちが独自に取得したデータに基づく分析です。

実測データ

2026年9月5日にDataForSEO経由でGoogle広告のキーワードデータ（日本・日本語）を取得しました。Dify関連18語の直近12か月の推移は次のとおりです。

出典: DataForSEO Google Ads Search Volume API（location: Japan / language: ja、2026年9月5日取得。当社実測）

なお、Google広告のキーワードデータは丸められた概数で提供されます。個々の値の精度ではなく、語の間の相対的な動きを見るための材料としてお読みください。

素朴な解釈と、その誤り

これを見ると「Difyは終わったのか」と感じるかもしれません。「n8nやコーディングエージェントに移行したから」という説明も目にします。

しかし同じ日に取得した対照群のデータは、この説明を否定します。

出典: 同上（当社実測）

ヘッドワード同士で比べると、移行先とされるn8n（−55%）のほうがDify（−33%）よりも減少幅が大きいのです。 LangChainはDifyと同程度（−33%）に減っています。つまり「DifyがLLMアプリ構築の主役の座をn8nに明け渡した」という説明は、データでは裏づけられません。

データが実際に示していること

2つの非対称が読み取れます。

非対称①：カテゴリ全体が縮小し、別の形式が伸びている

Dify・n8n・LangChainという「LLMアプリを組み立てるための道具」を調べる需要が揃って減る一方、Claude Codeのようなコーディングエージェントは173%増、AIエージェントという概念そのものも22%増えています。「ツールを組み立てて作る」から「エージェントに作らせる／エージェントそのものを使う」へ、検索行動の重心が移っていると解釈するのが、データに素直な読み方です。

非対称②：認知段階の落ち込みは緩やかで、「判断材料そのもの」を探す語の落ち込みが際立って大きい

ヘッドワードの「dify」単体は60,500→40,500（−33%）と減ってはいます。しかし「dify とは」は12か月のうち11か月が6,600で、2025年10月のみ8,100。起点（2025年8月）と終点（2026年7月）はいずれも6,600で、実質的に横ばいです。一方、料金（−63%）・活用事例（−76%）・事例（−67%）・商用利用（−85%）・デメリット（−75%）といった、判断材料そのものを探す語は6割以上減っています。減り方の水準がまるで違うのです。

ただし、検討段階の語がすべて急落しているわけではありません。「dify 導入」は−29%、「dify 構築」は−36%、「dify オンプレミス」は−43%と、6割以上の急落には至らず、ヘッドワード（−33%）に近い水準にとどまる語もあります（いずれも元の数値が月70前後の小さい語で、丸め幅の影響を受けやすい点にご留意ください）。

逆の例もあります。「dify docker」は−64%と急落層に入っており、手順系がすべて緩やかというわけではありません。 セルフホストの構築手順を新しく調べる動きは、はっきり弱まっていると読めます。したがって急落しているのは「判断材料そのもの」を探す語が中心であって、検討段階の語全般でもなければ、手順系がすべて無傷というわけでもありません。

つまり突出して減っているのは、Difyの名前を調べる行動ではなく、料金・事例・商用利用という「採否を決めるための材料」を調べる行動です。入口の数（「Dify とは」は横ばい）も、使い方や導入を調べる数（−16%・−29%）も大きくは変わらないまま、判断材料を取りに行く回数だけが6割以上落ちています。

この事実をどう使うか

2つの実務的な含意があります。

1. 「まだ話題の分野だから、情報は自然に新しくなる」という前提は捨ててください。 料金・事例・商用利用・デメリットといった語が6割以上減ったということは、料金・商用利用・事例を調べ直して書く人がそれだけ減ったということです。実際に「料金の全体像」「商用利用とライセンス」の章で見たとおり、日本語の解説には公式表記と食い違うものが混ざっています。判断は必ず公式の一次情報で行ってください
2. 一方で「もう終わったツール」でもありません。 検索需要の縮小と、導入企業での利用拡大は別です。リコーグループのアプリ数は2026年5月の約9,300から7月の約10,200へ伸びており、マーケットプレイスとダッシュボードという追加の仕組みまで整備しています。既に入れた企業の中では拡大しているのです

n8n / Claude Code / Agent SDK との使い分け

「Difyの検索需要は縮小している」の章のデータを踏まえると、「Difyか他か」ではなく「どの局面でどれを使うか」の整理が必要になります。

実務での使い分けの原則

LLMが主役ならDify、システム連携が主役ならn8n。 社内文書に基づいて答えるチャットボットを作るならDifyが速い。一方、「基幹システムからデータを取得して、加工して、Slackに通知する」という処理が主で、そこにLLMを一部使うだけならn8nが向いています。詳しい自動化の設計はn8nの連携ノードと自動化レシピで扱っています。

両方を使う構成もあります。 n8nで業務システムとの連携を組み、LLMを使う処理はDifyのAPIを呼び出す——という分担は現実的です。この構成でもアプリの作成・編集にはDifyのコンソールを使いますが、ロゴや著作権表示を改変しない限り、「商用利用とライセンス」の章で見た条件bには当たりません。

コーディングエージェントは競合ではありません。 Claude Codeのようなツールは「開発者がコードを書く作業を速くする」道具であり、Difyの「非エンジニアがアプリを作る」目的とは層が異なります。ただし、開発者がいる組織では「Difyで画面上で組むより、コードで書いたほうが速い」という場面が実際に増えています。その場合はClaude Agent SDKによる実装のようなコードベースの選択肢を検討してください。

切り替えの道筋を最初から想定しておく。 私たちが実務で推奨しているのは、要件が固まらないうちはDifyで素早く検証し、制御の要求が上がった段階でコード開発へ切り替える二段構えです。最初からコードで作り込むと仕様変更のたびに手戻りが大きく、逆に最後までDifyで押し切ろうとすると表現力の限界にぶつかります。この設計判断はAIエージェントの段階的な設計でより詳しく扱っています。

PoCで止まる企業と本番に載る企業の差

Difyの導入検討でもっとも多い失敗は、技術的な失敗ではありません。動くものはできたのに、業務に定着しないという失敗です。

「作れる」が「使われる」にならない構造

「作りっぱなし」は抽象的な懸念ではありません。「企業導入事例」の章で見たリコーグループの経過——アプリが増えたあとに管理の問題が来て、可視化ダッシュボードを後から整備した——が、その最も具体的な記録です。

ただしリコーグループは、大規模展開に成功したからこそ課題が表面化した側です。多くの企業はその手前——作った本人しか使っていない状態——で止まります。

現場で実際に起きるのは、おおむね次のパターンです。

コード開発に切り替えるべき判断基準

「Difyで作り続けるか、コード開発（自社実装または受託開発）に切り替えるか」を判断する基準を、私たちは次のように整理しています。3つ以上に当てはまれば、コード開発への切り替えを検討する段階です。

• 業務が止まると事業に影響が出る（可用性の要求がある）
• 監査・法令対応でログや処理内容の説明責任が求められる
• 既存の基幹システムとのデータ連携が必要になっている
• 画面上のノードが数十個規模になり、全体像を把握できる人がいない
• 「この条件のときだけ処理を変えたい」という要求が繰り返し出ている
• 同時利用者が増え、応答速度やレート制限が問題になり始めた
• 作成者以外が保守できない状態が3か月以上続いている
• 外部の顧客に提供する計画がある（ライセンス条件にも関わる）

逆に言えば、これらに当てはまらないうちはDifyのままで十分です。早すぎる作り込みは、要件が固まる前に手戻りを生みます。

PoCから本番運用へ進めるときの具体的な設計についてはPoCから本番運用への移行で、体制づくりを含めた支援の進め方は生成AIのPoC支援で扱っています。

検証の進め方

私たちはPoCを次の順で回します。

1. 業務を1つに絞る。 「社内問い合わせ全般」ではなく「経費精算に関する問い合わせ」まで絞る
2. 合格ラインを数値で決める。 「回答が正しい割合が◯割以上」「◯秒以内に返る」を先に書く
3. Cloudの無料枠か、手元のDockerで動かすCommunity版で組む。 この段階では有料契約もサーバー調達もしない
4. 実際の利用者に2週間使ってもらう。 作った本人以外が使えるかを見る
5. 合格ラインに届いたかで判断する。 届かなければ撤退するか、原因を特定して1つだけ直す
6. 届いたら初めて、本番の構成と費用と体制を設計する

この順序で進めると、Difyに投資すべきかどうかが、有料契約の前に分かります。

Dify導入前チェックリスト

稟議や社内検討にそのまま使える形で整理しました。

目的と要件

• 対象業務を1つに絞って特定した
• 現状その業務に何時間かかっているかを測った
• 成功の合格ラインを数値で定義した
• 既製のSaaSで代替できないことを確認した
• LLMが主役か、システム連携が主役かを判別した

費用

• Dify本体の費用（プラン料金 or インフラ費）を見積もった
• LLMのAPI利用料を別枠で見積もった
• 埋め込み・ベクトル検索など周辺の費用を確認した
• 運用にかかる人件費を工数で見積もった
• 課金単位がワークスペース単位であることを踏まえ、必要なプランを判定した
• 年払い（17%割引）と月払いのどちらにするか決めた

ライセンス・法務

• ライセンス原文を読み、マルチテナントに該当しないことを確認した
• ロゴ・著作権表示を改変する予定がないことを確認した
• 外部提供の計画がある場合、開発元への書面確認を計画に入れた
• Community版の公式の位置づけ（非商用プロジェクト向け）について社内で見解を整理した

データとセキュリティ

• AIに入力するデータの機密区分を業務単位で棚卸しした
• セルフホストでも外部LLMを使えばデータは外部に出ることを理解した
• ログの保持期間が監査要件を満たすか確認した（Sandboxは30日）
• 誰がログインできるかを設計した

体制

• 作成者が異動した場合に誰が引き継ぐかを決めた
• バージョンアップを誰がいつ行うかを決めた
• 障害時の復旧担当を決めた
• 部門別の利用量を測る仕組みを検討した
• コード開発への切り替え判断基準を事前に合意した

よくある質問

まとめ

Difyとは、LLMを使ったアプリを画面上で組み立てるためのプラットフォームです。社内文書を使ったチャットボットや、現場主導の業務アプリを短時間で形にできる点に価値があります。

一方で、導入判断に必要な情報は「何ができるか」ではありません。本記事で一次情報から確認したのは、次の4点です。

1. 料金はDifyの利用料とLLMの利用料の足し算である。message creditsはお試し枠であり、業務利用の分ではない。課金単位はワークスペース単位で、年払いは17%割引
2. 商用利用はライセンス原文で認められているが、マルチテナント運用とロゴ改変の2条件は別途許諾が必要。原文はテナントとフロントエンドの定義まで明記している
3. 公開事例では大規模展開が成立している（リコーグループ: 約10,200個）が、同時に「利用実態を把握できない」という管理課題も企業自身が公表している
4. 検索需要は縮小局面にあるが、ヘッドワードの減少幅はn8n（−55%）のほうがDify（−33%）より大きい。カテゴリ全体が縮小しており、特定ツールへの移行という説明はデータで裏づけられない

そのうえでの結論はシンプルです。Difyは「試すコストが極めて低い」道具であり、そこに最大の価値があります。 有料契約もサーバー調達もせずに、業務を1つ絞って2週間試せば、投資すべきかどうかが分かります。逆に、可用性・監査・基幹連携や制御といった要求が3つ以上重なったら、コード開発への切り替えを検討してください。その判断基準を最初に決めておくことが、PoCで止まらないための最大のコツです。