「Dify で作れないか」と言われたら
社内の問い合わせ対応や、文書の要約、毎朝の情報収集を AI に任せたい。そんな相談を受けて調べると、まず名前が挙がるのが Dify です。画面上でブロックをつなぐだけで AI アプリが作れ、作ったものは URL を配れば社内の人がすぐに使えます。
試作が簡単なぶん、決めごとが後回しになりがちです。無料プランで作ったアプリが部署に広まってから、ログが 30 日で消えること、モデルの API キーが誰の契約に付いているか、作った本人しか直せないことに気づくケースがあります。セルフホストに切り替えるなら、ライセンスの条件とサーバーの運用も確かめる必要があります。
本記事では、Dify の公式ドキュメント・料金ページ・GitHub の LICENSE で 2026 年 10 月 5 日時点の情報を確かめました。そのうえで、できること、料金とライセンス、n8n や自作との使い分け、Dify を選ぶかの判断基準、本番に載せる前に決めることを、AI アプリを作る担当の目線で整理します。画面の細かな操作は公式のチュートリアルに任せます。そもそも AI エージェントにするべき業務かどうかの判断は、AI エージェントとは？生成 AI・RPA との違いと、業務に入れるかの判断基準 で扱っています。
Dify とは｜AI アプリとワークフローを組み立てて公開する基盤
Dify は、生成 AI を使ったアプリやワークフローを、ノード (処理の部品) をつなぐキャンバス上で組み立て、そのまま公開・運用できる基盤です。公式サイト は自らを「本番対応のエージェンティックワークフロー構築プラットフォーム」と説明し、クラウド・VPC・セルフホストのいずれにも置けるとしています。
| 項目 | 内容 |
|---|---|
| 開発元 | LangGenius, Inc. (米国) |
| ライセンス | Apache License 2.0 の修正版 (商用利用は可。マルチテナントとロゴの扱いに条件) |
| 最新版 | 1.17.1 |
| 提供形態 | Dify Cloud (提供元が運用) / Dify Enterprise (自社の環境に置く) / コミュニティ版 (無料) |
| 使えるモデル | OpenAI・Anthropic・Gemini などのクラウドのモデルと、Ollama などで動かす手元のモデル |
ソースコードは GitHub の langgenius/dify で公開されています。最新版は 2026 年 10 月 5 日時点の GitHub Releases で確認しました。日本では「ディファイ」「ディフィ」の両方の読み方が使われていますが、公式サイトとドキュメントに読み方の記載は見当たりませんでした。
個人が対話画面で AI とやり取りする使い方との違いは、作ったものを「アプリとして配れる」点です。プロンプト、参照させる社内文書、呼び出す外部サービス、処理の順番をアプリの中に固定し、使う人は入力欄に書くだけで同じ処理を受けられます。
Dify でできること
公式の主要な概念のページ は、新しく作るアプリの種類として Workflow と Chatflow の 2 つを勧めています。そのほかに、公式がレガシーと位置づける、より簡単な設定画面の 3 種類 (チャットボット・エージェント・テキストジェネレーター) があり、この 3 種類も Workflow と同じ仕組みの上で動作します。2026 年 10 月時点では、簡易版のエージェントとは別に、新しい Agent がベータ機能として加わっています。
| アプリの種類 | 動き方 | 向く用途 |
|---|---|---|
| Workflow | 入力を受け取り、決めた手順で 1 回処理して結果を返す | 文書の要約・分類、定期レポート、一括処理 |
| Chatflow | 会話のメッセージごとに手順を実行し、回答を返す | 社内 FAQ、手順を案内するアシスタント |
| Agent (ベータ) | 専用のサンドボックスで、ツールを使いながら進め方を自分で決める | 調べ物や資料の取りまとめなど、手順が決まらない作業 |
| チャットボットなど | プロンプトとモデルを設定するだけの簡易な画面 | 既存のアプリの保守 (新規は Workflow・Chatflow を推奨) |
部品として使える主な機能は次のとおりです。
- ナレッジは、社内文書を取り込み、質問に関係する箇所を検索してモデルに渡す仕組み (RAG) です。ファイルのアップロード、Notion や Web サイトからの取り込み、外部のナレッジベースとの API 連携に対応します
- 統合 (プラグイン) では、モデルの提供元、外部サービスのツール、データソースを Marketplace から追加します。MCP (外部ツールを AI につなぐ共通の規格) のサーバーも呼べます
- ノードは、LLM、条件分岐、繰り返し、Python・JavaScript のコード、HTTP リクエスト、パラメータ抽出などを組み合わせて使います
- 人間の入力は、ワークフローを止めて、Web アプリの画面かメールで担当者に確認のフォームを届け、選ばれた答えに沿って処理を続ける部品です
作ったアプリの配り方 は 4 通りあり、どの方法でも同じアプリの設定がそのまま使われます。
| 公開方法 | 使い方 |
|---|---|
| Web アプリ | 自動で作られる URL を共有する。社内の人にすぐ使ってもらうとき |
| API | 既存の社内システムや自社サービスから呼び出す |
| Web サイトへの埋め込み | チャットウィジェットを既存のサイトに置く |
| MCP サーバー | Claude Desktop や Cursor などの AI ツールから道具として呼ぶ |
Dify のワークフロー｜Workflow と Chatflow の違い
公式ドキュメント は、モデル・ツール・条件分岐を手順として組み、AI を決めた範囲の中で動かす形を「Agentic ワークフロー」と呼んでいます。この形は、モデル 1 つにすべてを任せるより、ハルシネーションや手順の抜けを抑えやすいという考え方に立っています。Workflow と Chatflow は同じキャンバスで作り、違いは使う人とのやり取りの仕方です。
| 項目 | Workflow | Chatflow |
|---|---|---|
| 実行の単位 | 1 回の入力につき 1 回 | 会話のメッセージごと |
| 開始のしかた | ユーザーの入力、またはトリガー | ユーザーの入力だけ |
| 終わり方 | 出力ノード (任意) | 回答ノード (必須) |
| 自動実行 | スケジュール・Webhook・外部サービスのイベント | 無い |
| 向く仕事 | レポート生成、データ処理、一括処理 | 対話型のアシスタント、案内付きの Q&A |
毎朝 9 時にニュースを集めて要約し、チームに送るような処理は、トリガーを使える Workflow で組みます。社員が質問を打ち込む社内 FAQ は Chatflow です。どちらを選んでも、送信や登録の前に人の確認を挟みたいときは、人間の入力ノードを途中に置きます。
活用事例の型
公式ドキュメントは、ナレッジ の代表的な使い道として、製品ドキュメントや FAQ から答えるサポートボット、社内の規程や手順を引ける社内ナレッジポータル、資料をもとにレポートやメールを作るツール、論文や市場レポートを検索・要約するリサーチ支援を挙げています。
公開されている企業の事例では、Dify のライセンス販売と構築支援も手がけるリコーが、自社のコラム で社内での活用を紹介しています。27 のサイトから 3C (顧客・競合・自社) の情報を集めて月 1 回のレポートを作るのに 17 時間かかっていた業務を、Dify で検索・分類・配信まで自動化し、約 1,000 人への日次配信と、業務工数の約 90% 削減に至ったとしています。数字はリコーの発表によるものです。
FIXIT種類が多くて迷う。結局どれを選べばいいの？
Hayate新しく作るなら 2 つから選びます。使い分けの目安は、1 回で終わる処理なら Workflow、会話なら Chatflow です。
FIXIT新しい Agent は使わなくていいの？
HayateAgent はまだベータなので、手順を書けない部分だけで十分です。書ける手順は Workflow のほうが挙動を読めます。
提供形態と料金【2026 年 10 月時点】
Dify は、提供元が運用する Dify Cloud、自社の環境に置く Enterprise、無料のコミュニティ版の 3 つの形で使えます。Cloud の料金は 料金ページ で次のとおりです (2026 年 10 月 5 日確認)。
| プラン | 月払い (USD) | 年払い (USD) | メンバー | アプリ | ナレッジの文書数・容量 | 付属のクレジット | ログの保持 |
|---|---|---|---|---|---|---|---|
| Sandbox | 0 | 0 | 1 人 | 5 | 50 件・50MB | 200 (1 回限り) | 30 日 |
| Professional | 59 / ワークスペース | 590 | 3 人 | 50 | 500 件・5GB | 5,000 / 月 | 無制限 |
| Team | 159 / ワークスペース | 1,590 | 50 人 | 200 | 1,000 件・20GB | 10,000 / 月 | 無制限 |
上表は公式ページの表示額です。日本語の料金ページ には「表示価格は税抜」と書かれ、税は請求先情報に基づいて計算され、チェックアウト時か請求書に別途表示されると説明されています。同じページの FAQ によると、法人向けの銀行振込 (請求書払い) は現在まだ提供されておらず、Team の年払いを対象に検討中で、その場合の請求書は LangGenius, Inc. が発行し海外送金になると説明されています。日本の消費税の加算や適格請求書についての告知は、公式サイトとドキュメントで見つかりませんでした。経理に回す前に、契約時の請求書で確認してください。
料金表を読むときの注意点は 4 つです。
- 付属のクレジットは、Dify Cloud が用意したモデルを試すための枠で、1 回の応答ごとにモデルに応じた量を消費します。使い切った後や、クレジットの枠を超えて使いたいときは、OpenAI などと自分で結んだ契約の API キーを登録し、利用料はその契約に請求されます。クレジットに対応していないプロバイダーやモデルは、最初から自分の API キーで使います
- ログの保持 は Sandbox では 30 日で、期間を過ぎたログは後からアップグレードしても戻りません。有料プランでも、Workflow の実行ログは約 3 ヶ月で画面から月別のアーカイブ (CSV でダウンロード) に移ります。社内で使い始めるなら、記録を残したい時点で有料プランにします
- ナレッジへの操作 (検索・文書の追加や更新) には 1 分あたりの上限があり、Sandbox は 10 回、Professional は 100 回、Team は 1,000 回です。社内 FAQ を多くの人が同時に使う想定なら、利用者数と照らして確かめます
- 請求はワークスペース単位です。部署ごとにワークスペースを分けると、その数だけ契約が要ります
Enterprise は個別見積もりで、SSO、複数のワークスペースの管理、商用ライセンスの許諾、公式によるアップデートと保守、技術サポートが含まれます。公式サイトでは、SAML による SSO、ロールによる権限管理、監査ログ、Kubernetes でのデプロイ、SOC 2 Type II と ISO 27001 の認証を挙げています。コミュニティ版は無料で、公開リポジトリの機能を 1 つのワークスペースで使えます。料金ページはコミュニティ版を個人開発者や非商用 (non-commercial) のプロジェクト向けと紹介していますが、商用で使えるかどうかの根拠は次の節の LICENSE です。
セルフホストの条件とライセンス
Docker Compose で動かす
セルフホストの公式手順 では、最小要件は CPU 2 コア以上・メモリ 4GiB 以上で、Docker Compose 2.24.0 以上が必要です。macOS の Docker Desktop では、2 vCPU 以上・8GiB 以上のメモリを割り当てるよう指定されています。Docker が動作する環境なら、ノート PC・社内サーバー・クラウドの仮想マシンのどこにでも置けます。
git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d起動すると、API・ワーカー・Web 画面などのコアサービス 7 つと、PostgreSQL・Redis・ベクトルデータベース (Weaviate)・サンドボックスなどの依存コンポーネント 8 つのコンテナが立ち上がります。ブラウザーで /install を開いて管理者アカウントを作れば使い始められます。
始めるのは簡単ですが、アップデートの手間は自社で負います。たとえば 1.17.1 では同梱の Weaviate が 1.27.0 から 1.39.2 へ上がるため、リリースノートは、同梱の Weaviate を使う既存のセルフホスト環境に、段階的な手動アップグレードを先に済ませるよう警告しています。手順を飛ばすとベクトル検索が壊れるおそれがあるとしています。アップデートのたびにリリースノートを読み、バックアップを取ってから上げる担当を決めておきます。
LICENSE の 2 つの条件
Dify の LICENSE は、Apache License 2.0 に条件を加えたものです。他のアプリのバックエンドや、企業のアプリ開発基盤として商用で使えると明記したうえで、次の 2 つに当たる場合は提供元から商用ライセンスを得る必要があるとしています。
| 条件 | LICENSE の内容 | 当たりやすい使い方 |
|---|---|---|
| マルチテナント | 書面の許可なく、ソースコードでマルチテナント環境を運営できない。1 テナントは 1 ワークスペースを指す | 顧客ごとにワークスペースを分けて SaaS として提供する |
| ロゴと著作権表示 | フロントエンド (web/ や web イメージ) を使う場合、コンソールやアプリのロゴ・著作権表示を削除・変更できない | 自社ブランドに作り替えて社外に配る |
ロゴの条件は、Dify のフロントエンドを使わない利用 (API だけを呼ぶ場合など) には適用されないと書かれています。また、コントリビューターとしてコードを提供した場合、提供元がライセンスを厳しくも緩くも変更できること、提供したコードが提供元の商用利用に使われうることに同意する条項もあります。社内の 1 つのワークスペースで、ロゴと著作権表示を変えずに使う範囲なら、2 つの条件には当たりません。顧客に提供する予定があるなら、設計の前に条件を確かめます。
データをどこに置けるか
Cloud を使う場合、プライバシーポリシー には、Web サイトのサーバーは米国にあり、関係会社や委託先は米国・欧州経済領域・中国などで運営され、個人情報はこれらの国・地域で処理されうると書かれています。社外に置けない文書を扱うなら、セルフホストか Enterprise を候補にします。
セルフホストにしても、クラウドのモデルの API を呼べば、質問と検索で見つかった文書の一部はモデルの提供元に送られます。外に出さずに済ませるには手元のモデルを使います。Dify の Marketplace には、Dify が確認済みとした Ollama 用のプラグインがあり、手元で動かしたモデルを登録できます。必要な機材とモデルの選び方は ローカル LLM とは｜仕組み・必要スペック・おすすめモデルと始め方 で解説しています。
Dify・n8n・自作の使い分け
Dify と並んで比べられるのが n8n です。n8n の README は、AI エージェントとワークフローを作って動かす基盤として 1,500 以上の連携先をうたっています。どちらもキャンバスで組めますが、出発点が違います。
| 観点 | Dify | n8n | 自作 (フレームワークで開発) |
|---|---|---|---|
| 中心にある機能 | AI アプリを作って配る。ナレッジ (RAG) と会話型を持つ | 業務の自動化。1,500 以上の連携先 | 何でも作れるが、部品から自分で用意する |
| 作ったものの形 | Web アプリ・API・埋め込み・MCP サーバー | ワークフローと AI エージェント | 自由 (画面・権限・データの持ち方を決められる) |
| 提供形態 | Cloud・Enterprise・コミュニティ版 | クラウドとセルフホスト | 自社で用意する |
| ライセンス | 修正版 Apache 2.0。マルチテナントとロゴに条件 | Sustainable Use License。社内業務目的などに限る | 使うライブラリのライセンスによる |
n8n の LICENSE は、利用と改変を「自社の社内業務目的、または非商用・個人での利用」に限っており、Dify とは制限のかかり方が違います。顧客向けのサービスに組み込む予定があるなら、n8n は提供元の商用ライセンスを、Dify はマルチテナントとロゴの 2 条件に当たらないかを確認します。
使い分けの目安は次のとおりです。
- 社内の人が使う AI アプリ (FAQ・要約・下書き) を早く配りたいなら Dify
- AI は処理の一部で、主役が SaaS 間のデータ連携 (問い合わせを CRM に登録して Slack に通知するなど) なら n8n
- 基幹システムの権限やデータに合わせた画面、評価の仕組み、細かな障害対応が要るなら自作
Dify で試作して効果を確かめ、要件が固まった部分だけを自作に移す進め方もあります。DSL (YAML) でアプリを書き出せるため、試作の手順を設計書の材料として残せます。ワークフローとエージェントの設計の型は AI エージェント設計パターン入門 にまとめています。
Dify を選ぶかの判断基準
Dify は試作が速い一方、社内の標準にすると、運用・権限・データの扱いまで Dify の仕組みに合わせることになります。検討中の業務 1 つについて、次の 5 つの問いに答えてみてください。
| 判断基準 | 問い | Dify が向く答え | 別の手段を考える答え |
|---|---|---|---|
| 作る人と直す人 | 作った後、誰が中身を直し続けるか | 業務担当とエンジニアが画面を見ながら直す | エンジニアがコードとテストで管理したい |
| データの置き場所 | 読ませる文書とログを、社外のクラウドに置けるか | 置ける (Cloud)、または自社サーバーで運用できる | 置けず、サーバーを運用する人もいない |
| 社外への提供 | 使うのは社内の人だけか | 社内だけ、または 1 つのワークスペースで足りる | 顧客ごとに分けて提供したい (商用ライセンスの確認) |
| 既存システムとの連携 | 連携は API を数本呼ぶ程度か | HTTP リクエストやツールで足りる | 基幹システムの権限・トランザクションに深く入る |
| 運用の担当 | アップデート・障害・利用料の監視を誰が見るか | 担当が決まっている (Cloud なら提供元が基盤を運用) | 担当がおらず、作った人が異動すると保守が止まる |
すべて「Dify が向く答え」に当てはまるなら、Dify で始める条件はそろっています。「別の手段を考える答え」が 1 つでもあるなら、その項目を先に片付けるか、別の手段を比べてから決めます。AI に任せる範囲そのものは、冒頭で紹介した AI エージェントの記事の「入れるかを決める 5 つの判断基準」で決められます。
FIXIT無料で試せるなら、とりあえず全社に配っちゃえばよくない？
Hayate試すなら少人数で十分です。全社に配るなら、Sandbox のログが 30 日で消える点が問題です。
FIXITえっ、消えたら何が困るの？
Hayate誤回答の原因を後から追えなくなります。配る前に有料プランと、ログを見る担当を決めておけば、原因を追えます。
Dify の始め方 (公式の手順)
公式のクイックスタート と各機能のページをもとに、Cloud で最初の Workflow を動かすまでの流れをまとめると次のとおりです。
- cloud.dify.ai で無料登録します。新しいアカウントは Sandbox プランで始まります
- 「統合」→「モデルプロバイダー」で使うモデルの提供元を追加します。クレジットの対象のモデルなら API キーは不要で、自分の API キーも登録できます
- 「スタジオ」→「空白から作成」→「ワークフロー」で新しいアプリを作ります
- ユーザー入力ノードで入力欄を定義し、LLM ノードなどをつないで処理を組みます。ノードは 1 つずつ試し実行 できます
- 社内文書を使う場合は「ナレッジ」で 文書を取り込み、知識検索ノードからつなぎます
- 「公開する」を押し、アクセスポイントの Web アプリの URL を共有します
自社のサーバーで試すなら、前述の Docker Compose の手順で起動し、同じ流れで作れます。ナレッジの回答の精度が足りないときは、文書の分け方や検索の方式を調整します。調整の考え方は RAG 構築の実践ガイド で解説しています。
社内で本番に載せる前に決めること
試作がうまくいったら、社内に配る前に次を決めます。いずれも公式ドキュメントに書かれた仕様から、決めておかないと後で困るものを選んでいます。
| 決めること | 公式ドキュメントの仕様 | 決めておく内容 |
|---|---|---|
| 役割と権限 | ロールはオーナー・管理者・エディター・メンバーの 4 つ。メンバーは公開済みのアプリだけを使える | 誰が作り、誰が使うだけか。オーナーの異動時に所有権を移す手順 |
| モデルの API キー | 登録したキーはワークスペース全体で共有され、そのキーの契約に請求される。管理できるのはオーナーと管理者だけ | 会社名義の契約のキーを使い、モデル提供元 (OpenAI など) の管理画面で利用料の上限を設定する |
| 公開の範囲 | Web アプリは既定でアクセス制限が無く、URL を知っている人なら誰でも開ける。MCP サーバーの URL は認証情報を含むため API キーと同様に扱う | URL を誰に配るか。利用者を認証で絞れるかは提供形態で可否を確認し、難しければ認証付きの社内システムから API で呼ぶ |
| ログと記録 | Sandbox は 30 日で削除。有料プランの会話ログは契約期間中保持し、Workflow の実行ログは約 3 ヶ月で月別のアーカイブに移る | 何を何日残すか。個人情報を入力させない運用 |
| 人の確認 | 人間の入力ノードで、処理を止めて担当者に確認を求められる | 送信・登録・削除の前に誰が確認するか |
| アップデートと障害 | 公開するとライブのアプリが即座に置き換わる。セルフホストはアップデートの手順を自分で踏む | 試す環境と本番の分け方、更新とバックアップの担当 |
AI に外部の操作を任せる場合のリスクと対策 (意図しない操作、外部連携からの情報漏えい) は、AI エージェントとは の「導入前に決めておくリスク対策」と同じ考え方で整理できます。
FIXIT の運用 — Dify の次の選択肢として
AI 駆動開発のクリエイティブスタジオである FIXIT は、Dify の導入代行を掲げたサービスは提供しておらず、自社の Dify の運用を事例として示す段階でもありません。そのため本記事は、公式ドキュメントの記載をもとに書いています。
FIXIT の AI エージェント開発 は、単発のチャットボットではなく、業務に組み込むエージェントを作るサービスです。過去の業務ログをもとに、自動化できる業務・半分だけ自動化する業務・人が担う業務に切り分けるところから始め、構成は LangGraph や Mastra、独自のフレームワークなど業務の要件に合わせて提案します。Dify で試作した結果、社内システムとの連携や品質の測り方が業務の要件に届かなかった場合の次の選択肢として検討いただけます。評価の仕組み (評価ハーネス) をセットで納品し、特定のモデルに依存しない構成にしています。
ナレッジに入れたい情報が、個人のメールや PC、個人の LINE に散らばっていて集められない会社もあります。その場合は AI アプリより先に、情報の置き場所を会社のものにする工程が要ります。業務 DX 伴走支援 では、連絡を Slack へ、メールとファイルを Google Workspace へ集約し、生成 AI を日常業務で使えるようにするところまで支援しています。
まとめ
Dify は、AI アプリとワークフローをキャンバス上で組み立て、Web アプリや API として社内に配れるオープンソースの基盤です。新しく作るなら、1 回で終わる処理は Workflow、会話は Chatflow を選びます。Cloud は無料の Sandbox から試せますが、ログの保持やメンバー数を考えると、社内で使い始める時点で有料プランを検討することになります。セルフホストは商用利用できる一方、マルチテナントとロゴの扱いに条件があり、アップデートの運用も自社で担います。
Dify を選ぶかは、作る人と直す人、データの置き場所、社外への提供、既存システムとの連携、運用の担当の 5 つで決められます。
次の一歩は、Sandbox で業務を 1 つ Workflow にしてみて、本記事の判断基準の表を埋めることです。Dify では業務の要件に届かない連携や評価が見えてきたら、AI エージェント開発 のページをご覧いただくか、お問い合わせ からご相談ください。