· updated

【初心者OK】Dify 使い方｜30分でチャットボット5ステップ

Dify を触ってみたいけれど、Chatbot・Agent・Workflow・Chatflow の 4 アプリタイプが並んでいて、どこから手を付ければいいか分からないと感じていませんか。実際、ラッコキーワード実測（2026 年 5 月時点）でも「Dify 使い方」は月 1,900 件・SEO 難易度 40・+146% の急成長領域です。私自身、Dify を含むノーコード AI エージェント構築の道具立て（Dify / n8n / Make / Zapier 等）のいずれかを業務で常用しています。

結論から言うと、まずクラウド版（dify.ai）の Free プランで Chatbot を 5 ステップ（アカウント作成 → アプリ選択 → モデル設定 → プロンプト → 公開）で作るのが筋です。本記事では 4 アプリタイプ俯瞰・初心者 5 ステップ・ワークフロー／チャットフロー・RAG 構築・クラウド vs セルフホスト・料金・職種別 UC まで通貫整理します。

とりあえず最短で「Dify で何が作れるか」を知りたい方は、セクション 1「結論」と セクション 3「初心者 5 ステップ」、セクション 4「4 アプリタイプ俯瞰」から読み始めると、5 分で判断材料が揃います。

01 — 結論：Dify は「ノーコードで AI チャットボット／RAG／エージェントを作れる OSS 基盤」、まずは Free プランで Chatbot を 5 ステップ

📖 この章で使う用語

  • Dify（ディファイ）：オープンソースのノーコード LLM アプリ構築プラットフォーム。AI チャットボット／RAG／エージェントを GUI で組める。プラモデルの「組み立て済みパーツ集」のイメージ。
  • ノーコード：プログラミングを書かずに画面操作で組み立てる方式。Excel の関数を少し凝った GUI で組むイメージ。
  • OSS（オーエスエス：Open Source Software）：ソースコードが公開されていて、誰でも自由に使える・改変できるソフトウェア。Wikipedia のように「誰でも読めて改良できる」イメージ。
  • LLM（Large Language Model：大規模言語モデル）：ChatGPT / Claude / Gemini の正体にあたる「文章を予測する装置」。詳細は別記事 LLM とは で扱っています。

まず結論から書きます。Dify を触り始めるなら、クラウド版（dify.ai）の Free プランで「Chatbot」を 5 ステップで作る——これが、ノーコード AI エージェント基盤を業務で扱っている私のいちばん実用的な最初の一手です。

Dify の正体を 1 行で書くと、「ノーコードで AI チャットボット／RAG／エージェントを作れるオープンソース基盤」 です。GUI で「アプリの種類」を選び、「使う LLM」を選び、「プロンプト」を書くだけで、最短 30 分以内に動くチャットボットが手元に立ち上がります。コードを書く必要はありません。動くものができたあとは、Web 公開・自社サイトへの埋め込み・API 化、と段階的に育てられる構造です。

Dify には 4 つのアプリタイプが並んでいて、ここが最初のつまずきポイントです。Chatbot（質問応答型）／Agent（自律実行型）／Workflow（ノードベース自動化）／Chatflow（分岐型対話） の 4 つで、ぱっと見では違いが分かりにくい設計になっています。後ろの セクション 4 で 1 表に整理しますが、結論を先取りすると、入門は Chatbot 一択、慣れたら Workflow → Chatflow → Agent の順で広げるのが、未経験者にとって心理的な負担がいちばん軽い順路です。

ここで本記事の立ち位置と、既存記事との役割分担を明示しておきます。本記事は 「Dify 使い方の専門深掘り」 に絞ります。AI エージェントを作る別ルート（Python + LangChain / Microsoft Copilot Studio / Claude Projects・カスタム GPTs）の俯瞰は、親ハブの AIエージェント 作り方 で 4 ルート全体を扱っています。RAG の概念そのものは RAG とは、AI エージェントの概念は AIエージェント とは、AI コーディング全般は AI コーディング で、それぞれ別記事として整理済みです。本記事は「Dify をどう使い始めるか」「4 アプリタイプをどう選び分けるか」「Dify ナレッジ機能で RAG をどう組むか」「クラウドとセルフホストをどう選ぶか」に焦点を絞ります。

私自身の立ち位置もお伝えしておきます。私は、ノーコード AI エージェント構築の道具立て（Dify / n8n / Make / Zapier 等）のいずれかを業務で常用しています。Dify を含むこの道具立て群の業務利用は射程内ですが、本記事では「具体的にどれを日常的に業務で叩いているか」という個別ツール名の特定は伏せます（案件の都合）。Dify 単体の細かい本番運用ノウハウは、Dify 公式ドキュメント・公開情報からの整理と、ノーコード AI エージェント道具立て群に共通する業務感覚を組み合わせて書きます。

最後に重要なメタ宣言を 1 つ。本記事では「絶対 Dify が一番」「絶対 Chatbot から始めるべき」とは申し上げません。料金・機能・最適な選択肢は、組織要件・既存スタック・チーム規模で大きく振れます。本記事の判断軸は「2026 年 5 月時点・私のノーコード AI エージェント業務経験と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。

02 — Dify とは——OSS のノーコード LLM アプリ構築プラットフォーム、Make / n8n / Zapier との違い

📖 この章で使う用語

  • LangGenius：Dify を開発・運営する OSS プロジェクト企業（中国・北京拠点）。
  • Apache 2.0 ライセンス：OSS ライセンスの一種。商用利用可・改変可、ただし著作権表示の維持義務あり。
  • Agent（エージェント）：LLM が自律的に道具を選んで手順を組み立てて実行する仕組み。詳細は別記事 AIエージェント とは で扱っています。
  • Workflow（ワークフロー）：ノードを線で繋いで「入力 → 処理 → 出力」を組み立てる自動化フロー。
  • Chatflow（チャットフロー）：Workflow の対話型バージョン。ユーザー入力ごとに分岐する対話型エージェント設計。

ここからは、Dify の 「正体」「何ができるか」「Make / n8n / Zapier との違い」 を順に整理します。

02-1. Dify の正体——LangGenius が運営する OSS の LLM アプリ構築基盤

Dify は LangGenius 社が開発・運営する、オープンソースの LLM アプリ構築プラットフォーム です。GitHub 上で Apache 2.0 ライセンスで公開されていて、誰でも自由に使え、コードを読め、改変もできます。出典は本記事末尾の「出典」セクション、Dify 公式 GitHub リポジトリをご参照ください。

サービス提供形態は 2 系統 あります。

  • クラウド版（dify.ai）：LangGenius がホスティングしている SaaS 形態。アカウント作成すれば即時試用可能、Free / Pro / Team / Enterprise の料金体系
  • セルフホスト版（Community Edition）：自社サーバや社内 PC、クラウド VM 上に Docker Compose で自分で立ち上げる形態。OSS なので Dify 本体は無料、サーバコストは別計算

クラウド版とセルフホスト版の選び分けは、後ろの セクション 10 で詳しく扱います。先に結論だけ書くと、まず触ってみるならクラウド版、機密情報や社内ポリシーが厳しければセルフホスト版、という分け方が一般的です。

02-2. Dify で何ができるか——4 アプリタイプの 1 行サマリ

Dify でできることを 4 行で並べると、次のとおりです（詳しい比較は セクション 4 で扱います）。

  • Chatbot：質問応答型のチャットボット。FAQ ボット、社内ナレッジ問い合わせ Bot など
  • Agent：LLM が自律的に道具（ツール）を選んで実行するエージェント
  • Workflow：ノードベースの自動化フロー。線形パイプライン（入力 → 処理 → 出力）の組み立て
  • Chatflow：複数ノード連結型の会話設計。ユーザー入力ごとに分岐する対話型フロー

加えて、すべてのアプリは Web 公開、自社サイトへの埋め込み、API 化、の 3 形態で外部に公開できます。「動くチャットボットを 1 つ作ってから、社内向け Slack 連携を足し、公式 Web サイトに埋め込み、ついでに API としても外部から叩けるようにする」——という段階的な育て方が現実的です。

02-3. Make / n8n / Zapier との違い——汎用ワークフロー vs LLM アプリ構築特化

「Dify と Make / n8n / Zapier、何が違うのか？」という質問をよく受けます。1 行で書くと、Make / n8n / Zapier は汎用ワークフロー自動化、Dify は LLM アプリ構築に特化、という整理になります。

ツール主な役割LLM 統合ノーコード度
DifyLLM アプリ構築（Chatbot / Agent / Workflow / Chatflow / RAG）中核機能（OpenAI / Anthropic / Google 等を統合済み）高（LLM 用の専用 UI）
n8n汎用ワークフロー自動化（SaaS 連携・ETL・スケジュール実行）プラグイン経由で対応高（自由度が広い）
Make（旧 Integromat）汎用ワークフロー自動化（SaaS 連携の老舗）プラグイン経由で対応高（マウスで組む）
Zapier汎用ワークフロー自動化（最も多くの SaaS と接続）プラグイン経由で対応高（Trigger / Action）

私の業務感覚としては、「LLM をアプリの中核に据えたい」なら Dify、「既存 SaaS の橋渡しが中心」なら n8n / Make / Zapier、という選び分けが現実的です。詳しい意思決定軸は、後ろの「よくある質問」と、親ハブ記事 AIエージェント 作り方 の「ルート B：ノーコードで作る」セクションで扱っています。

02-4. リリース時系列——2023 年〜、Chatflow / Agent 機能の追加

Dify は 2023 年に OSS として公開され、その後メジャーアップデートで Chatflow（複数ノード連結型の対話設計） と Agent（LLM の自律実行型） が追加された経緯があります。GitHub の Star 数も右肩上がりに伸びており、2026 年 5 月時点で OSS ノーコード LLM アプリ基盤としては最も活発なプロジェクトの 1 つです。最新のリリースノートは GitHub の releases ページ、公式機能一覧は dify.ai の公式サイトで必ず事前確認してください。

03 — 初心者向け 5 ステップ：アカウント作成 → アプリ選択 → モデル設定 → プロンプト → 公開

📖 この章で使う用語

  • API キー：API（プログラム同士の通信窓口）を利用するための「会員証」。AI モデルプロバイダー（Anthropic / OpenAI 等）ごとに発行される。
  • モデルプロバイダー：LLM を提供する事業者。Anthropic / OpenAI / Google などのこと。
  • システムプロンプト：AI に「あなたは○○です」と最初に役割を与える指示文。営業時代の「新人への業務指示」のイメージ。
  • Publish（パブリッシュ）：作成したアプリを Web 公開する操作。「印刷ボタン」のイメージ。

ここからは、Google サジェスト 1 位「Dify 使い方 初心者」に正面から応える、最初の 1 個を 30 分以内に立ち上げる 5 ステップ を書きます。本記事のいちばんの主軸セクションです。

最初に立ち位置を 1 つお伝えします。私自身は、ノーコード AI エージェント構築の道具立て群を業務で扱っており、各種プロバイダの API キー取得・モデル切替・チャットボット構築・社内へのデプロイ運用の感覚は手元にあります。Dify 単体の本番運用細部までの一次経験は本記事では伏せますが、5 ステップを「未経験者の最初の壁ごとに丁寧に分解する」観点はそこから書きます。

03-1. ステップ 1：dify.ai でアカウント作成（30 秒〜1 分）

最初の一手は クラウド版（dify.ai）のアカウント作成 です。ブラウザで https://dify.ai を開き、「Sign Up」または「Get Started Free」のボタンから登録します。サインアップ方法は次の 3 種類が一般的です（最新は公式で必ずご確認ください）。

  • メールアドレス + パスワード：いちばん素朴な方式。確認メールが届く
  • GitHub アカウント連携：GitHub をお持ちならワンクリックでサインアップ
  • Google アカウント連携：Google ログインでワンクリック

未経験者の方には、GitHub または Google 連携のワンクリックをおすすめします。理由はパスワード管理の負担が減るのと、後で API キーを管理することになるので「アカウント数を増やしすぎない」ことが効いてくるからです。所要時間は 30 秒〜1 分です。

03-2. ステップ 2：「Create from Blank」で Chatbot を選択（30 秒）

サインアップ後、ダッシュボードに入ったら、左上の 「Create App」または「Create from Blank」 をクリックします。すると 4 アプリタイプ（Chatbot / Agent / Workflow / Chatflow）の選択画面が出ます。

最初は迷わず「Chatbot」を選んでください。理由は 3 つあります。

  1. 最も入門しやすい：システムプロンプトだけで動く、ノード設計が不要
  2. 5 分で「動くもの」が手に入る：成功体験が早く来るので、心理的に挫折しにくい
  3. 後から Workflow / Chatflow / Agent に乗り換え可能：Chatbot で慣れたら横展開が利く

「Agent から始めたい」「Workflow を組みたい」というニーズは分かりますが、Dify の概念（モデル設定・プロンプト・公開）を Chatbot で先に掴むのが、結果的にいちばん早いというのが、ノーコード AI エージェント道具立て群を業務で扱ってきた私のこれまでの感覚です。

03-3. ステップ 3：モデルプロバイダー設定（5〜10 分）

Chatbot を選んだら、最初の壁が来ます。モデル設定 です。Dify 自体は LLM を内蔵していないので、外部の LLM プロバイダー（Anthropic / OpenAI / Google など）の API キー を Dify に渡してあげる必要があります。

API キーの取得手順は、各プロバイダーで異なります（2026 年 5 月時点）。

  • Anthropic（Claude）：console.anthropic.com でアカウント作成 → API Keys ページで新規発行 → クレカ登録
  • OpenAI（GPT）：platform.openai.com でアカウント作成 → API keys ページで新規発行 → クレカ登録
  • Google（Gemini）：aistudio.google.com または console.cloud.google.com でアカウント作成 → API キー発行

最初の心理的なつまずきポイントは、クレカ登録が必要な点です。各プロバイダーが Free 試用クレジット（数ドル〜数十ドル分）を付与してくれることが多いですが、本番運用には課金が前提になります。最初に必ず利用枠制限（usage limit）を設定して、「うっかり数万円課金される」事故を防いでください。OpenAI なら platform.openai.com/account/limits で月次上限を設定できます。

API キーが取得できたら、Dify の右上「Settings → Model Provider」を開き、プロバイダーごとに API キーを入力します。API キーは絶対に他人と共有しないでください。GitHub の公開リポジトリにコミットしてしまうと数分で第三者に発見・悪用されます。詳しくは ChatGPT 始め方 でも触れています。

ChatGPT / Claude / Gemini といったプロバイダーごとの選び分けは、後ろの セクション 9 で扱います。先に結論だけ書くと、初心者の方は最初は 1 つだけ契約（自分が普段使っているサービスのアカウントを流用すれば API も取りやすい）、慣れたら用途で使い分け、が現実的です。

03-4. ステップ 4：システムプロンプトの入力（5 分）

API キー設定が終わったら、Chatbot 画面の左側「Instructions」（システムプロンプト欄）に AI に与える役割と指示 を書きます。最小例はこれです。

あなたは社内 IT ヘルプデスクのアシスタントです。
以下の方針で回答してください。
- 専門用語が出てきたら、必ず初出時にカッコ書きで意味を添えてください。
- 個人情報・機密情報を含む質問が来たら、回答を控えて情シス担当者を案内してください。
- 分からないことは「分かりません」と正直に答えてください。

最初は 「あなたは○○です。〜してください。」型のシンプル指示 から始めるのが筋です。営業時代のたとえで書くと、新人に最初に渡す業務指示書と同じで、最初から完璧な分厚いマニュアルを渡しても読まれません。動かしながら「あ、ここが足りない」と気づくたびに 1 行ずつ追記していくのが現実的です。

03-5. ステップ 5：プレビューでテスト → Publish ボタンで公開（5 分）

プロンプトを書いたら、画面右側の 「Debug & Preview」 で実際にチャットしてテストします。期待通りの応答が来るか、何往復かやり取りして確認してください。

応答が満足できる品質になったら、右上の 「Publish」ボタン で公開します。Dify は公開方法を 3 種類用意しています（後ろの セクション 5 で詳述）。

  • Web App：dify.ai のサブドメイン URL で即時公開（社内共有なら共有 URL の発行で完結）
  • Web 埋め込み：HTML タグを自社サイトに貼り付け、ウィジェット形式で表示
  • API：cURL や Python から叩ける REST API として外部公開

これで 30 分以内に「動くチャットボット」が手元に立ち上がるはずです。最初は Web App の URL を社内 Slack で共有して、同僚に触ってもらうのが、フィードバックを集めるいちばん早い方法です。

04 — 4 つのアプリタイプ俯瞰：Chatbot / Agent / Workflow / Chatflow の違いと選び方

📖 この章で使う用語

  • Chatbot（チャットボット）：質問応答型のアプリ。FAQ ボット、カスタマーサポート Bot など。
  • ツール（道具）：エージェントが外の世界とやり取りする「道具」。電卓・地図アプリ・Slack 送信・外部 API 呼び出しなど。
  • 分岐ロジック：「もし A なら B、そうでなければ C」の条件分岐。Excel の IF 関数のイメージ。
  • 線形パイプライン：「入力 → 処理 → 出力」のように、分岐なしで一直線に流れる処理の連なり。工場のベルトコンベアのイメージ。

ここからは、Dify の 4 アプリタイプ（Chatbot / Agent / Workflow / Chatflow） を 1 表で俯瞰します。SERP 上位の記事には少ない、本記事の主たる差別化軸です。

04-1. 4 アプリタイプの 1 表俯瞰

アプリタイプ性格適した用途複雑度
Chatbot単純な質問応答型社内 FAQ / カスタマーサポート / シンプルな対話★（最も入門しやすい）
AgentLLM が自律的に道具を選んで実行業務自動化 / 道具呼び出し型 / 検索 + 推論★★★★（最も難しい）
Workflow線形ノードベースの自動化フロー業務処理パイプライン / ETL / 一括処理★★（GUI で組める）
Chatflow分岐型対話のフロー設計段階的ヒアリング / 分岐型カスタマーサポート★★★（分岐設計が必要）

私の業務感覚としては、「動くものを作る早さ」では Chatbot がダントツ、「業務に組み込む実用度」では Workflow / Chatflow、「概念学習として 1 回触っておきたい」のが Agent、という位置づけです。

04-2. 選び方の意思決定表——3 つの問いに答えるだけ

「自分は 4 つのうちどれを作るべきか」を考える際、次の 3 問に Yes / No で答えると、おおむね候補が絞り込めます。

Q1: ユーザーとの会話 UI が必要ですか？

  • Yes → Chatbot / Chatflow / Agent から選ぶ（次の Q2 へ）
  • No → Workflow（バックエンド処理）

Q2: 道具（Slack 送信 / 外部 API 呼び出し等）を AI が自律的に選んで実行する必要がありますか？

  • Yes → Agent（最も難しいが、自律性が要件なら一択）
  • No → 次の Q3 へ

Q3: 会話の途中で「分岐ロジック」が必要ですか？

  • Yes → Chatflow（分岐型対話の設計）
  • No → Chatbot（シンプルな質問応答）

この 3 問で 「最初に作るべきアプリタイプ」がだいたい決まるはずです。迷ったら、3 問とも No が出る確率が高い「Chatbot」から始めるのがいちばん心理的負担が軽い順路です。

04-3. 後から乗り換えできるか——アプリタイプの切り替えと知識の移植

「最初に Chatbot を作ったら、あとで Workflow に変えたいときどうすればいいか？」という質問もよく受けます。結論を先に書くと、アプリタイプ自体は乗り換え不可、ただし「中身（プロンプト・モデル設定・ナレッジ）」は別アプリにコピーして再利用可能、というのが Dify の設計です（2026 年 5 月時点）。

私の業務感覚としては、「最初の Chatbot で得たノウハウ（プロンプト設計・モデル選定・ナレッジ整理）は、Workflow / Chatflow / Agent に作り直すときの 8 割の資産になる」——と捉えるのが現実的です。最初の 1 個を「捨てるつもりで作る」のではなく、「次の 3 個の原型として育てる」つもりで作ると、後悔が少ない印象です。

05 — チャットボット作成：Dify で最も入門しやすい用途、社内 FAQ ボットの実例

📖 この章で使う用語

  • ナレッジ（Knowledge）：Dify が提供する文書管理機能。PDF / Word / Markdown 等をアップロードして RAG として検索可能にする箱。「社内 Wikipedia」のイメージ。
  • Web 埋め込み：作成したアプリを自社サイトの HTML タグとして貼り付ける方式。
  • iframe：Web ページの中に別の Web ページを埋め込む HTML タグ。

ここからは、Google サジェスト 4 位「Dify 使い方 チャットボット」に応える、社内 FAQ ボット作成の型 を扱います。

05-1. なぜチャットボットが Dify 入門に最適か

Dify でチャットボットが入門に最適な理由は 3 つあります。

  1. 最小ステップで動くものが見える：セクション 3 の 5 ステップで完結
  2. ノード設計が不要：Workflow / Chatflow のような「線で繋ぐ作業」を学ぶ前に動く
  3. ナレッジ機能を後付けできる：チャットボットを土台にして、後から RAG（社内ドキュメント検索）を足せる

私のこれまでの業務感覚としては、チャットボット系の構築は最初の 1 〜 2 個で「概念」を掴むのが早い——たとえば「システムプロンプトの書き方」「モデルごとの応答の違い」「ナレッジを足したときの精度変化」などが、頭よりも先に手で分かるようになります。

05-2. 社内 FAQ ボット作成の 3 ステップ

社内 FAQ ボットを作る最小手順は次の 3 ステップです。

  1. システムプロンプト設計：Bot の役割・回答方針・NG 行動を 5〜10 行で記述
  2. ナレッジ接続：社内 FAQ の PDF / Word / Markdown を Dify のナレッジ機能にアップロード（詳しくは セクション 8 で扱います）
  3. 公開：Web App URL を社内 Slack で共有、または iframe で社内ポータルに埋め込み

シンプルな型としてのシステムプロンプト例を 1 つ置きます。実際の運用では、組織ごとの固有要件で調整してください。

あなたは [会社名] 社内向け IT ヘルプデスクのアシスタントです。

【回答方針】
- 接続されたナレッジから根拠を引き、出典の文書名を併記してください。
- ナレッジに該当情報がない場合は「分かりません、情シス担当者へ」と案内してください。
- 個人情報・機密情報を含む質問は回答せず、人間担当者にエスカレーションしてください。

【トーン】
- 丁寧で簡潔（敬語ベース、3 文以内）。
- 専門用語は初出時にカッコ書きで意味を添えてください。

このプロンプトを土台に、最初の 1 週間は「実際の問い合わせを観察 → プロンプトを 1 行ずつ追記」の改善サイクルを回すのが、ノーコード AI エージェント道具立て群を業務で扱ってきた私のこれまでの感覚から見ても、いちばん早い育て方です。

05-3. 公開方法 3 種——Web App / Web 埋め込み / API

Dify Chatbot の公開方法は 3 種類です（2026 年 5 月時点）。

  • Web App：dify.ai のサブドメイン URL で即時公開。社内向けなら URL を Slack や Confluence に貼って完結
  • Web 埋め込み：HTML タグまたは iframe を社内ポータル・公式 Web サイトに貼って、ウィジェット表示
  • API：cURL や Python / Ruby / Node.js などから叩ける REST API として外部公開

最も多いのは Web App 公開 です。「いったん Web App で社内に出して、フィードバックを 1〜2 週間集めてから埋め込み or API 化を判断する」のが、結果的にいちばん手戻りが少ない順路です。

機密情報の扱いについては後ろの セクション 13（失敗パターン）で詳しく書きますが、公開先のスコープ（公開／社内限定／IP 制限）は必ず設定してください。Web App のデフォルトは「URL を知っている人なら誰でもアクセス可能」な設計のため、社内ナレッジを載せたチャットボットを意図せず外部に公開してしまう事故が起こり得ます。

06 — ワークフロー機能：ノードベース自動化、業務効率化用途

📖 この章で使う用語

  • ノード：Workflow の構成単位。「処理 1 つ分」のブロック。
  • HTTP Request ノード：外部 Web API を呼び出すノード。Slack / Notion / 社内 API などへ繋ぐ。
  • Code ノード：Python / JavaScript の任意コードを実行できるノード。GUI で組めないロジックを書く逃げ道。
  • If-Else ノード：条件分岐ノード。「もし入力が A なら B 経路、そうでなければ C 経路」。

ここからは、Google サジェスト 2 位「Dify 使い方 ワークフロー」に応える、Workflow 機能の使い方 を扱います。

06-1. Workflow とは——ノードを線で繋いで処理を組み立てる

Workflow は ノードを線で繋いで「入力 → 処理 → 出力」を組み立てる線形パイプライン です。GUI 上で「Start ノード」から始まり、LLM ノード・Knowledge Retrieval ノード・HTTP Request ノード・Code ノード・If-Else ノードなどを線で繋ぎ、最後に「End ノード」で終わる構造です。

たとえて言うと、Workflow は 工場のベルトコンベア に近い設計です。最初に荷物（入力）が乗って、途中のステーションで加工（LLM 呼び出し）や検査（条件分岐）が行われ、最後に出荷（出力）される。各ステーションの並びと内容を GUI で組み立てるイメージです。

06-2. 主要ノード種別の 1 行サマリ

Dify の Workflow で頻繁に使う主要ノードを、1 行ずつ整理します。

  • Start ノード：Workflow の入口。引数（input 変数）を受け取る
  • LLM ノード：プロンプトを書いて LLM を呼び出す中核ノード
  • Knowledge Retrieval ノード：Dify ナレッジ機能から関連文書を検索（RAG の中核、後ろの セクション 8 で扱います）
  • HTTP Request ノード：外部 Web API を呼び出す（Slack 送信 / Notion 投稿 / 社内 API 等）
  • Code ノード：Python / JavaScript の任意コードを実行（GUI で組めないロジックの逃げ道）
  • If-Else ノード：条件分岐（「もし A なら B、そうでなければ C」）
  • Iteration ノード：配列に対する繰り返し処理（リストの各要素に同じ処理を適用）
  • End ノード：Workflow の出口。最終的な出力を返す

最初は Start → LLM → End の 3 ノードだけ で動かしてみるのがおすすめです。慣れてきたら HTTP Request ノードで Slack 送信、Code ノードで前処理、If-Else ノードで分岐、と段階的に増やしていく順路が現実的です。

06-3. シンプルな Workflow 例：日報要約 → Slack 通知

未経験者にも腑に落ちる Workflow の型を 1 つ置きます。「営業日報のテキストを受け取って、LLM で 3 行に要約して、Slack に投稿する」フローです。

[Start: 日報テキスト入力]
   ↓
[LLM: Claude Sonnet で3行要約]
   ↓
[HTTP Request: Slack Incoming Webhook に POST]
   ↓
[End: 完了通知]

この型を組むだけで、毎日 15 分かかっていた「日報の要約 → チームへの共有」が 30 秒で済むようになります。営業時代に「日報を書いた」とチーム Slack に毎日投げていた私の経験からすると、こういう小さい自動化の積み重ねが、結局のところ一番効きます。

Workflow と Slack 連携を組み合わせると、AI を「黙って動くアシスタント」として業務に組み込みやすくなります。詳しい組み合わせは AI 業務効率化 事例 でも別記事として扱っています。

06-4. Workflow の失敗パターン 3 個

Workflow を組むときに、ノーコード AI エージェント道具立て群を扱う中で観察される失敗パターンを 3 つ並べます。

  1. ノード過多：1 つの Workflow に 30〜50 ノードを詰め込んで、保守不能になる
  2. エラー処理の未設計：LLM タイムアウト・API エラー・JSON パース失敗時の分岐がなく、本番で止まる
  3. LLM 呼び出しコストの計算漏れ：Workflow が 1 日 1,000 回叩かれて、月末に数万円課金される

回避策はいずれも「小さく作って観察してから足す」に尽きます。最初の 1 個は 5〜10 ノード以内に抑え、エラー処理を 1 ノードずつ足し、利用枠制限と監視を必ず先に設定する——これがノーコード AI エージェント道具立て群に共通する業務感覚です。

07 — チャットフロー機能：複数ノード連結型の会話設計

📖 この章で使う用語

  • Question Classifier（質問分類器）：ユーザー入力を「カテゴリ A / B / C」に分類するノード。「営業の問い合わせフォームの選択肢」のイメージ。
  • Answer ノード：Chatflow でユーザーへの応答を返すノード。
  • エスカレーション：AI で対応しきれない問い合わせを人間担当者に引き継ぐ流れ。

ここからは、Google サジェスト 5 位「Dify 使い方 チャットフロー」に応える、Chatflow 機能 を扱います。

07-1. Chatflow とは——Workflow の対話型バージョン

Chatflow は Workflow に「対話 + 分岐」要素を足したバージョン です。Workflow が「入力を 1 回受け取って出力を 1 回返す」線形パイプラインだとすると、Chatflow は「ユーザーと何往復もしながら、入力ごとに分岐する」対話型フロー、と整理できます。

たとえて言うと、Workflow は 書類審査（1 回提出して 1 回回答）、Chatflow は 面接（往復しながら深掘る） に近い設計です。

07-2. Workflow と Chatflow の使い分け

「Workflow と Chatflow、どちらを使うべきか？」の判断軸は 1 つです。ユーザーとの会話が必要か、それとも 1 回入れて 1 回出すだけか。

  • Workflow ＝ 入力を 1 回受け取って結果を返すだけ（ETL、一括処理、バックエンド処理）
  • Chatflow ＝ ユーザーと何往復もしながら、文脈を保持して分岐する（カスタマーサポート、段階的ヒアリング）

私の業務感覚としては、「ユーザーが画面を見ながら会話する」UI なら Chatflow、「裏側で黙々と動く」処理なら Workflow、という分け方が現実的です。

07-3. Chatflow の典型用途——問診型 FAQ / 段階的ヒアリング

Chatflow が向く典型用途を 3 つ並べます。

  • 問診型 FAQ ボット：「お困りなのは A / B / C のどれですか？」→ カテゴリに応じて深掘り
  • 段階的ヒアリング型エージェント：要件定義の前段で、ユーザーから情報を引き出すヒアリング
  • カスタマーサポートの分岐応答：AI で完結する問い合わせ／人間にエスカレーションする問い合わせの仕分け

07-4. Chatflow の型例——問い合わせ分類 → FAQ 検索 → エスカレーション

シンプルな Chatflow の型を 1 つ置きます。「ユーザーの問い合わせを分類 → 該当 FAQ を検索 → 回答 or 人間担当者へエスカレーション」フローです。

[Start: ユーザー入力受付]
   ↓
[Question Classifier: 「IT 質問」「総務質問」「人事質問」に分類]
   ↓
[If-Else: 分類結果で分岐]
   ├─ IT → [Knowledge Retrieval: IT FAQ] → [LLM: 回答生成] → [Answer]
   ├─ 総務 → [Knowledge Retrieval: 総務 FAQ] → [LLM: 回答生成] → [Answer]
   └─ 人事 → [HTTP Request: 人事担当 Slack に通知] → [Answer: 担当者からご連絡します]

この型を組むことで、「全部 AI で回答する」のでも「全部人間で回答する」のでもなく、AI で完結する問い合わせと、人間にエスカレーションすべき問い合わせを自動で仕分ける運用に近づきます。

07-5. Chatbot と Chatflow の使い分け（再整理）

セクション 5 で扱った Chatbot との使い分けも、ここで再整理しておきます。

  • Chatbot ＝ 単発の質問応答が中心、シンプルな FAQ ボット
  • Chatflow ＝ 分岐ロジックや段階的なヒアリングが必要な複雑な対話

迷ったら、まず Chatbot を作って動かしてから、「分岐が必要だ」と感じた時点で Chatflow に作り直す順路が、心理的に挫折しにくい流れです。

08 — RAG 構築：Dify ナレッジ機能 + ベクトル DB 統合

📖 この章で使う用語

  • 検索拡張生成（RAG：Retrieval-Augmented Generation）：外部の文書を検索して、その結果を踏まえて答えを生成する仕組み。詳細は別記事 RAG とは で扱っています。
  • チャンク：長い文書を、検索しやすいサイズ（500〜1,000 字程度）に切り分けた断片。
  • 埋め込み（embedding）：テキストを「意味を表す数値の並び」に変える操作。
  • ベクトル DB：意味が近いものを素早く取れるデータベース。本屋の「ジャンル別の棚」のイメージ。
  • Top-K：「上位 K 件を取り出す」の K。検索結果の上位何件を LLM に渡すかの設定。

ここからは、Google サジェスト 3 位「Dify 使い方 RAG」に応える、Dify のナレッジ機能で RAG を組む方法 を扱います。本記事の差別化軸の 1 つです。

08-1. Dify ナレッジ機能の正体——4 ステップで RAG を組める「箱」

Dify のナレッジ機能は、「文書をアップロードするだけで、自動チャンク化＋埋め込み生成＋ベクトル DB 保存まで一括で済ませてくれる箱」 です。RAG の中核要素を全部内蔵してくれているので、「Python で LangChain を書いて、ベクトル DB を立てて、埋め込みモデルを呼んで……」という従来の自前構築と比べると、立ち上がりが圧倒的に早いです。

内部で行われている処理を 4 ステップに分解すると、こうなります。

  1. ドキュメント取込：PDF / Word / Markdown / Notion / Web ページなどをアップロード
  2. チャンク化：長い文書を 500〜1,000 字程度の断片に切り分ける
  3. 埋め込み生成：各チャンクを「意味を表す数値の並び（ベクトル）」に変換
  4. ベクトル DB 保存：意味が近いチャンクを素早く取り出せるデータベースに格納

利用者が画面で操作するのは「ドキュメントをアップロードする」だけ。残りの 3 ステップは Dify が裏側で自動実行してくれます。これがノーコード RAG 構築の最大の価値です。

08-2. Dify が内部で使うベクトル DB の選択肢

Dify は内部で複数のベクトル DB をサポートしています（2026 年 5 月時点、最新は公式 docs で必ずご確認ください）。

  • Weaviate：OSS、ベクトル検索 + GraphQL クエリが特徴
  • Qdrant：OSS、軽量で立ち上がりが早い
  • pgvector：PostgreSQL の拡張、既存 RDB と統合しやすい
  • Chroma：OSS、Python ファーストで扱いやすい
  • Milvus：OSS、大規模スケール向け

クラウド版 Dify では Dify 側がベクトル DB を選定・運用してくれます。セルフホスト版（Community Edition）では、自分で「どのベクトル DB を裏側に置くか」を環境変数で指定する流れになります（後ろの セクション 10 で扱います）。

私の業務での RAG 構築経験では、FAISS / Chroma / Weaviate の 3 銘柄を選定理由ごとに使い分けてきました。Dify ナレッジ機能経由で RAG を組む際は、「Dify がデフォルトで選んでくれるベクトル DB」をいったん受け入れて、ボリュームや性能要件が現実に出てから乗り換えを検討する流れが現実的です。詳しい背景は RAG とは で扱っています。

08-3. 検索設定——Top-K / スコア閾値 / 再ランキング

Dify ナレッジ機能には、検索精度を調整するパラメータが 3 つあります。

  • Top-K：「上位何件を LLM に渡すか」（典型値 3〜5）
  • スコア閾値：「類似度がこの値以上の結果のみ採用」（典型値 0.5〜0.7）
  • 再ランキング（rerank）：取得した複数チャンクを LLM 側でもう 1 回並べ替える機能（精度向上、コスト増）

最初は Top-K = 3、スコア閾値 = 0.5、再ランキング OFF で動かしてみて、回答品質が物足りなければ Top-K を 5 に上げ、それでもダメなら再ランキングを ON にする——というステップアップが現実的です。

08-4. Chatbot / Workflow / Chatflow から Knowledge Retrieval ノードで呼び出す

ナレッジは作って終わりではなく、Chatbot / Workflow / Chatflow の中から「Knowledge Retrieval ノード」で呼び出す ことで実際に動きます。具体的には、Workflow / Chatflow の編集画面でノードを追加 → 「Knowledge Retrieval」を選択 → 検索対象のナレッジを指定、という流れです。

Chatbot の場合は、画面右側の「Context」セクションでナレッジを紐付けるだけで、ユーザー入力に応じて自動で関連チャンクを検索 → LLM に渡してくれます。

08-5. 自前 RAG（Python + LangChain）との対比

「Dify ナレッジを使う」と「Python + LangChain で自前 RAG を組む」の対比を表で並べます。

項目Dify ナレッジ機能自前 RAG（Python + LangChain）
立ち上がり速度即日（30 分でアップロード完了）数日〜数週間（環境構築・ベクトル DB 立て・コード書き）
細部のチューニングUI 提供範囲内（Top-K / 閾値 / 再ランキング）フル制御可能（チャンク分割アルゴリズム・埋め込みモデル・検索ロジック）
ベクトル DB 選択Dify が用意した範囲から選ぶFAISS / Chroma / Weaviate / Pinecone 等を自由選定
コストDify サブスク + LLM API + ベクトル DB ホスティングサーバ + ベクトル DB + LLM API（細かい最適化が利く）
保守性Dify 側のアップデートに追従自前コードの保守責任

私の業務感覚としては、「PoC や 1〜2 ヶ月の検証なら Dify ナレッジ、本番運用で精度・コスト・カスタマイズが要件になるなら Python + LangChain で自前構築」、という選び分けが現実的です。Dify ナレッジで立ち上げて、要件が見えてきた段階で自前 RAG に移植する、という段階移行のパスもありえます。

08-6. Dify ナレッジ機能の失敗パターン 3 個

Dify ナレッジで RAG を組むときの代表的な失敗を 3 つ並べます。

  1. チャンクサイズ不適切：デフォルトの 500 字でも、「契約書のように 1 条が長い文書」や「FAQ のように 1 行が短い文書」では精度が崩れる。文書特性に応じて 300〜2,000 字で調整
  2. 埋め込みモデル選定ミス：日本語コンテンツに英語特化の埋め込みモデルを当てると、類似度計算が崩れる。多言語対応のモデル（OpenAI text-embedding-3 系列、Cohere multilingual 等）を選ぶ
  3. 閾値設定ミス：閾値を高く設定しすぎる（0.8〜0.9）と、関連文書がまったく取れずに「分かりません」を連発する Bot になる。最初は 0.5 前後で試すのが現実的

09 — モデルプロバイダー設定：Anthropic / OpenAI / Google / Bedrock / ローカル LLM

📖 この章で使う用語

  • Azure OpenAI：Microsoft Azure 上で OpenAI モデルを利用する企業向けサービス。
  • AWS Bedrock：Amazon Web Services が提供する LLM 統合サービス。Claude / Llama 等を AWS の契約・課金体系で利用できる。詳細は AWS Bedrock で扱っています。
  • ローカル LLM：自分のパソコンや社内サーバで動かす LLM。Ollama / LM Studio などのツール経由で実行。

ここからは、Dify から呼び出せる モデルプロバイダーの選び分け を整理します。

09-1. Dify がサポートする主なモデルプロバイダー

Dify は Settings → Model Provider から複数のモデルプロバイダーを登録できます。2026 年 5 月時点の主要プロバイダーを並べます（最新は公式 docs で必ずご確認ください）。

  • Anthropic：Claude Opus / Sonnet / Haiku（直 API、API キー 1 本で開始）
  • OpenAI：GPT-4o / GPT-4o mini / GPT-3.5（直 API）
  • Google：Gemini Pro / Gemini Flash（Google AI Studio または Vertex AI）
  • Azure OpenAI：Microsoft Azure 経由の OpenAI モデル（企業向け契約）
  • AWS Bedrock：AWS 経由の Claude / Llama / Mistral / Titan 等
  • ローカル LLM：Ollama / LM Studio などのツール経由

Anthropic / OpenAI / Google の直 API は私自身が業務で常用しています。Bedrock 経由 Claude は PoC・検証で部分的に触っており、概念と選定の整理レベルまでは語れます。詳しくは AWS Bedrock と Claude 使い方 で別記事として扱っています。

09-2. モデルごとの用途・コスト感の整理

「結局どのモデルを使えばいいか」の判断軸を、私の業務感覚で 3 つに整理します。

  • コスト重視（量産系タスク） ＝ Claude Haiku / GPT-4o mini / Gemini Flash
  • 性能重視（複雑要件・長文整理） ＝ Claude Opus / GPT-4o / Gemini Pro
  • 社内データ厳格運用 ＝ Bedrock 経由 Claude / Azure OpenAI / セルフホスト + ローカル LLM

Claude のモデル別（Opus / Sonnet / Haiku）の使い分け詳細は、Claude Opus と Sonnet の違い と Claude Opus で別記事として整理済みです。

09-3. ローカル LLM 統合の位置づけ

Dify はセルフホスト版を中心に、Ollama や LM Studio で動かしているローカル LLM とも接続できます。社内 PC 上で Llama / Mistral / Qwen 等を動かして、外部にデータを出さない構成を組みたい場合の選択肢です。

私自身は、ローカル LLM は個人検証レベルでの利用にとどまっており、業務本番運用での Dify + ローカル LLM 統合の経験はありません。本記事では「セルフホスト版 + ローカル LLM」という構成が可能、という公開情報レベルの紹介にとどめます。詳細な手順は Dify 公式ドキュメントの「Local LLM Integration」セクションをご参照ください。

09-4. LLM 切替の意思決定軸——用途・コスト・既存スタックで使い分ける

「絶対これ」とは申し上げません。私のこれまでの業務感覚として、LLM 切替の意思決定は次の 3 軸で考えています。

  1. 用途：応答品質が最優先か、コストが最優先か、速度が最優先か
  2. コスト：1 日の呼び出し回数 × 平均トークン数 × プロバイダー料金の概算
  3. 既存スタック：すでに使っている AWS / Azure / GCP 等のクラウドベンダーとの統合度

最初は 1 つのモデルから始めて、運用しながら「ここはコスト重視に切り替えたい」「ここは性能重視にしたい」と気づいたタイミングで増やすのが現実的です。最初から 5 つのモデルを並列でセットしても、運用が散漫になるだけで意思決定が遅くなります。

10 — クラウド版 vs セルフホスト版：Docker 構築の判断軸

📖 この章で使う用語

  • Docker（ドッカー）：アプリを「箱（コンテナ）」に詰めて、どの環境でも同じように動かす仕組み。「お弁当箱」のイメージ。
  • Docker Compose：複数の Docker コンテナをまとめて起動・管理するツール。「複数のお弁当箱を 1 つの献立で運用する」イメージ。
  • VM（仮想マシン）：物理サーバの上に立てる「仮想のコンピュータ」。AWS EC2 / GCP Compute Engine などで利用する。

ここからは、Google サジェスト 6 位「Dify 使い方 ローカル」に応える、クラウド版とセルフホスト版の選び分け を扱います。企業利用層を意識した本記事の差別化軸です。

10-1. クラウド版（dify.ai）の特徴

クラウド版（dify.ai）は LangGenius がホスティングしている SaaS 形態 です。

  • Free プラン即時試用可：アカウント作成すれば 30 秒で開始
  • 料金体系：月 $59〜の Pro / Team / Enterprise（詳細は セクション 11 で扱います）
  • 運用負担ゼロ：サーバ管理・アップデート・バックアップは LangGenius 側で対応
  • データ送信先：LangGenius のサーバ + 各モデルプロバイダーのサーバ

個人試用・小規模 PoC・スタートアップでの本番運用なら、クラウド版で十分なケースが多い——というのが私の業務感覚です。

10-2. セルフホスト版（Community Edition）の特徴

セルフホスト版（Dify Community Edition）は OSS の Dify を自社サーバや社内 PC、クラウド VM 上に自分で立ち上げる形態 です。

  • Dify 本体は無料（OSS）
  • インフラコストは別計算：サーバ・ベクトル DB・ストレージ・運用人件費
  • データ送信先：自社サーバ内で完結（モデルプロバイダー API の呼び出しは別途）
  • カスタマイズ性：コードを読んで改変可能（Apache 2.0 ライセンス）

セルフホスト版が選ばれる典型シーンは、「機密情報・個人情報を社外サーバに置けない」金融・医療・公共系の企業利用 です。クラウド版だと「LangGenius のサーバを経由する」ことが許容できない組織でも、セルフホスト版なら社内ネットワーク内で完結できます。

10-3. 判断軸の整理——5 軸で並べる

クラウド版とセルフホスト版の選び分けを、5 軸で並べます。

軸クラウド版（dify.ai）セルフホスト版（Community Edition）
立ち上がり速度30 秒（アカウント作成のみ）30 分〜数時間（Docker Compose 起動）
機密情報の社外送出LangGenius サーバを経由社内ネットワーク内で完結
コスト月 $59 〜（Pro）サーバ + 運用人件費（規模で振れる）
運用負担LangGenius 側で対応自社で対応（アップデート・バックアップ・監視）
カスタマイズ性提供機能の範囲内コード改変可能（Apache 2.0）

10-4. セルフホスト最小手順（Docker Compose 5 ステップ）

Dify セルフホスト版の最小立ち上げ手順を、5 ステップに分解します（2026 年 5 月時点、最新は GitHub の README で必ずご確認ください）。

# 1. GitHub から Dify をクローン
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 2. 環境変数ファイルをコピー
cp .env.example .env

# 3. .env を編集（DB パスワード・Redis 設定・モデルプロバイダー API キー等）
vim .env

# 4. Docker Compose で起動
docker compose up -d

# 5. ブラウザで http://localhost/install を開いて管理者アカウントを作成

Docker / Docker Compose の基本が分かれば、立ち上げ自体は 30 分〜 1 時間程度です。難しいのはむしろ運用フェーズ（バックアップ・アップデート・ベクトル DB のスケール対応・監視）で、社内 IT 部門のサポートがあると安心です。

私自身の立ち位置を 1 つお伝えしておきます。Docker / Docker Compose の概念・運用感覚は業務経験の射程内ですが、Dify セルフホスト版を業務本番で日常運用しているわけではありません。本記事では公開情報・公式 README からの整理＋ Docker 系の業務経験を組み合わせて書いています。

10-5. セルフホスト版の失敗パターン 3 個

セルフホスト版で起こりやすい失敗パターンを 3 つ並べます。

  1. DB バックアップ忘れ：PostgreSQL のデータが飛んで、過去の会話履歴・ナレッジが全消失
  2. アップデートの手間：Dify 本体が頻繁にアップデートされる、追従コストが想定より大きい
  3. モデル API キーの管理ミス：環境変数に書いた API キーが、誤って Git にコミットされて第三者に漏れる

回避策は「バックアップを Cron で自動化、アップデートを定例化、API キーは Secrets 管理サービス（AWS Secrets Manager / HashiCorp Vault 等）に分離」——いずれも一般的なシステム運用の作法と同じです。

11 — 料金感：クラウド版の Free / Pro / Team / Enterprise

📖 この章で使う用語

  • SLA（サービスレベル契約：Service Level Agreement）：「稼働率 99.9% 保証」のような可用性・性能の合意。エンタープライズ向け契約で重要。
  • SSO（シングルサインオン：Single Sign-On）：1 つの ID/パスワードで複数の業務システムにログインできる仕組み。
  • シート（席数）：チームプランで管理される「同時に利用できるメンバー数」。

ここからは、Dify クラウド版の料金体系 を整理します。最初に強くお断りしておきます。料金は頻繁に改定されますので、本記事の数字も 2026 年 5 月時点の目安で、最終確認は dify.ai/pricing で必ず事前に行ってください。

11-1. クラウド版 4 プラン概観（2026 年 5 月時点）

プラン月額想定対象主な特徴
Free$0個人試用月メッセージ数・ナレッジ件数に上限あり、概念学習用
Pro月 $59 前後個人プロ・小規模チーム月メッセージ数増、ナレッジ拡張、本格運用の入口
Team月 $159 前後複数メンバーのチームチーム共有、複数アプリ、ナレッジ大量保持
Enterprise商談ベース大企業・組織導入SLA / SSO / 高度な権限管理、商用契約

※プラン名・価格・上限は変動します。最新は dify.ai/pricing（取得：2026-05-19）で必ず事前確認してください。

11-2. 別途必要なコスト——LLM API 料金は独立

Dify サブスク料金とは別に、LLM API 料金（Anthropic / OpenAI / Google など）は独立して発生 します。たとえば Dify Pro（月 $59）+ Claude Sonnet API 料金（実利用ベースで月 $10〜数百）、という二重課金構造になります。

私の業務感覚としては、「Dify サブスク + LLM API 料金の合計を月次でモニタリング」——これがいちばん予算管理を外しにくい運用です。LLM API 側は利用枠制限を必ず設定し、Dify サブスクのほうもチームの実利用に応じて Pro / Team / Enterprise のサイズ感を見直すのが現実的です。

11-3. セルフホスト版のコスト構造（再掲）

セルフホスト版（Community Edition）は OSS なので Dify 本体は無料 ですが、別途次のコストが発生します。

  • サーバコスト：AWS EC2 / GCP Compute Engine / オンプレ等のホスティング費
  • ベクトル DB コスト：Weaviate Cloud / Pinecone / Qdrant Cloud 等を使う場合
  • 運用人件費：アップデート・バックアップ・監視の社内工数
  • LLM API 料金：クラウド版と同じく独立して発生

小規模なら月数千円〜数万円、大規模になれば数十万円〜数百万円のレンジになります。「OSS だから無料」と思い込まずに、人件費を含めた TCO（総所有コスト）で考えるのが筋です。

11-4. チーム導入時の意思決定軸——Pro 数席 vs Team vs Enterprise

「組織で導入するとき、Pro を数席契約するか、Team プランか、Enterprise か」の意思決定軸は次の 3 つで考えるのが現実的です。

  1. 同時利用メンバー数：5 名以下なら Pro 数席で回るが、10 名超なら Team が経済的
  2. 権限管理の細かさ：ユーザー権限・アプリ別アクセス制御が必要なら Team 以上
  3. コンプラ要件：SSO / SLA / 監査ログが必要なら Enterprise 商談へ

私の業務感覚としては、「Pro 数席で 1〜2 ヶ月運用してから、チーム拡大のタイミングで Team / Enterprise に乗り換える」——段階移行が、結果的にいちばん予算と意思決定の両方を外しにくい流れです。

「絶対 Enterprise プランを最初から契約すべき」とは申し上げません。組織規模・要件・予算の振れ幅が大きい領域です。最終判断は社内の情シス・調達・コンプライアンス部門と相談して、自社にとっての落としどころを決めてください。

12 — 非エンジニアのユースケース 5 本：営業／事務／個人事業主／副業ライター／エンジニア志望

📖 この章で使う用語

  • Slack Incoming Webhook：Slack 外部から特定チャンネルに投稿するための URL 窓口。「専用の郵便受け」のイメージ。
  • ヒアリング型ボット：ユーザーから段階的に情報を聞き出していく対話設計のチャットボット。

ここからは、Dify を エンジニアではない職種の方がどう使えるか、5 つの職種別ユースケースで整理します。本記事の主要ペルソナ（営業／事務／個人事業主／副業ライター／エンジニア志望）に整合する、機能系記事の必須セクションです。

各 UC は Before / After / 所要時間 / 最初の壁 の 4 要素で構成しています。具体的な企業名・業界は伏せていますが、いずれも私自身の業務観察と、ノーコード AI エージェント道具立て群を扱う中で観察された実態の範囲です。

12-1. UC ①：営業職——商談 FAQ ボットの社内共有

Before：顧客からの Q&A をエクセルで管理。商談中に「この製品の在庫は？」「導入事例は？」と聞かれると、エクセルを開いて検索 → 該当箇所まで読みに行く、というタイムラグが発生していた。

After：Dify Chatbot ＋ナレッジ機能で、商談中に Slack か Web App に質問を入れれば 5 秒で回答が返ってくる。議事録 PDF や提案書のテンプレを継続的にナレッジに追加していくと、Bot がチームの「集合知の窓口」に育っていく。

所要時間：初期セットアップ 30 分（5 ステップ）/ 月次運用 30 分（ナレッジ追加と動作確認）

最初の壁：API キー取得の心理的抵抗。クレカ登録と利用枠制限の設定が必要で、「うっかり数万円課金される」事故への警戒感がブロックになりがち。最初は Free 試用クレジットで動かしてみるのが現実的。

12-2. UC ②：事務職——社内ルール／規程の問い合わせ自動応答

Before：就業規則 PDF や経理規程を全文検索 → 該当箇所まで読みに行く負担。問い合わせが集中する月末・年度末は対応で 1 日が溶ける。

After：Dify Chatbot ＋ナレッジ機能で、社員からの「経費精算の上限は？」「在宅勤務の申請は？」といった問い合わせが、規程 PDF を根拠に出典付きで自動回答される。事務職の方は「Bot が答えられない例外ケース」だけ対応すればよくなる。

所要時間：初期セットアップ 1 時間（規程 PDF のアップロード＋プロンプト調整）/ 月次運用 15 分

最初の壁：機密規程の社外送出制約。クラウド版 Dify を経由することで、LangGenius のサーバとモデルプロバイダーのサーバを通過する。コンプラ要件が厳しい組織では、セルフホスト版＋ Bedrock 経由 Claude の構成（セクション 10 参照）を選ぶか、規程の機密度を社内法務・コンプライアンス部門と事前確認するのが筋。

12-3. UC ③：個人事業主——顧客対応 FAQ ボットの自分用構築

Before：問い合わせメールの 1 次対応に毎日 1 時間。「料金は？」「納期は？」「対応エリアは？」といった定型質問が大半を占める。

After：Dify Chatbot を Web サイトに埋め込み、よくある質問は自動応答。個人事業主の方は「具体的な見積もり依頼」「複雑な要件相談」だけメールで対応すればよくなる。

所要時間：初期セットアップ 1 時間（FAQ コンテンツの整理＋プロンプト設計）/ 月次運用 10 分

最初の壁：プロンプト設計。「自分のビジネスの文脈（料金体系・対応範囲・断り方）」を AI にどう伝えるかの書き方が、最初のうちは試行錯誤になる。最初の 1〜2 週間は「実際の問い合わせを観察 → プロンプトを 1 行ずつ追記」のサイクルを回すと精度が安定する。

12-4. UC ④：副業ライター——記事案件の取材メモ整理ボット

Before：取材音声を文字起こし → 構成案を組み立て → ライティングへ進む、という流れに 1 案件あたり 2 時間。文字起こしと構成案を行き来する時間が一番の負担。

After：Dify Workflow で「文字起こしテキスト入力 → LLM で要約 → 見出し候補 5 本生成 → Slack に通知」までを自動化。副業ライターの方は AI が出した構成案を叩き台に、人間にしかできない「視点の付け方」「読者への寄り添い」に時間を回せる。

所要時間：初期セットアップ 1 時間（Workflow ノードの構成）/ 案件あたり 10 分削減

最初の壁：Workflow ノード構成の設計。最初は型として既存テンプレ（Dify の公開テンプレートライブラリにいくつかサンプルあり）を写経し、慣れてきたら自分の業務フローに合わせて改変していく順路が現実的。

12-5. UC ⑤：エンジニア志望——AI エージェント学習の最初の一歩

Before：LangChain や LlamaIndex のチュートリアルを開く → Python の環境構築でつまずく → 「エージェントの概念」が掴めないまま挫折。

After：Dify Agent でツール選択＋自律実行の挙動を GUI で確認 → 「ああ、エージェントってこういう動きなのか」が手で分かる。そのあとに Python に進むと、概念は既に頭に入っているので、コード書きに集中できる。

所要時間：初期セットアップ 30 分（Free プラン＋無料試用クレジット）/ 週次学習 1 時間

最初の壁：API キー取得＋無料試用クレジット切れの心理的負担。最初は概念学習に絞り、深掘り学習に進むタイミングでクレカ登録＋有料プランへ、という段階移行が無理のない順路。AI エージェントの概念そのものは AIエージェント とは、Python での自前構築ルートは AIエージェント 作り方、AI コーディング全般は AI コーディング で別記事として扱っています。

12-6. 5 UC に共通する 3 つの観察

5 つのユースケースに共通する観察を 3 つだけ書き残します。

  1. 「動くもの」が最短 30 分で手に入る効果は大きい：心理的な挫折ポイントが減る
  2. 最初の壁は技術ではなく API キー取得＋利用枠制限の設定：未経験者の最大の躓きはここ
  3. 継続運用には「観察 → プロンプト改善」のサイクルが必須：作りっぱなしでは精度が育たない

詳しい職種別の業務効率化マトリクスは AI 業務効率化 事例 と AI 業務効率化 ツール で別記事として扱っています。

13 — 失敗パターン 5 個と回避策（YMYL 警戒章）

📖 この章で使う用語

  • Secrets（シークレッツ）：API キーやパスワードなどの機密設定値。「金庫の中身」のイメージ。
  • 無限ループ：プログラムの処理が終わらずに繰り返し続ける状態。Workflow ノードの設計ミスで起こりがち。
  • エスカレーション：AI で対応しきれない問い合わせを人間担当者に引き継ぐ流れ。

ここからは、Dify を業務利用する際に押さえておきたい 失敗パターン 5 個 を、回避策とセットで整理します。本記事の YMYL 警戒章です。

最初にメタ宣言を 1 つ。「絶対安全な Dify 構成」とは申し上げません。組織要件・データの機密度・契約形態によって最適解は大きく振れます。本記事の整理は「2026 年 5 月時点・私のノーコード AI エージェント業務経験と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。

13-1. 失敗 ①：API キーをクライアント側に露出 → セキュリティ事故

最も起こりやすい事故が、Anthropic / OpenAI / Google などの API キーを、ブラウザ側の JavaScript やフロントエンドのコードに直接書いてしまう パターンです。1 度公開されると数分で第三者にスクレイピングされて、数十万円〜数百万円の不正利用に繋がります。

回避策：API キーは必ずサーバサイド経由で扱い、フロントエンドには露出させない。Dify の場合は Settings → Model Provider 側で管理されるので、利用者が Dify の外で扱う必要は基本的にないが、Dify セルフホスト版の .env ファイルを Git にコミットしてしまう事故には警戒。AWS Secrets Manager / HashiCorp Vault などの Secrets 管理サービスとの統合を最初から組み込むのが筋。

13-2. 失敗 ②：機密情報・個人情報をナレッジにアップロードする前の確認漏れ

業務で Dify ナレッジに 就業規則・契約書・顧客リスト・社内データ をアップロードしようとするとき、その文書が「モデルプロバイダーのサーバを経由する」事実への配慮が抜けるケースがあります。

回避策：アップロード前に必ず次の 4 点を確認してください。

  1. モデルプロバイダーのデータ取り扱いポリシー（Anthropic / OpenAI / Google の利用規約）
  2. 社内の機密情報取り扱いルールとの整合
  3. 個人情報保護法・業界ガイドライン（金融庁・医療情報ガイドライン等）への適合
  4. 情シス・法務・コンプライアンス部門への事前相談

機密度が高い文書を扱う場合は、セルフホスト版＋ AWS Bedrock（社内 VPC 経由）＋ローカル LLM のような構成も選択肢です。最終判断は社内法務、必要に応じて弁護士の方へご相談ください。

13-3. 失敗 ③：LLM API コストの暴騰

Workflow を組んだら 無限ループや大量メッセージで LLM API が暴走 し、月末に予算を桁違いに超えていた、というのも代表的な失敗です。

回避策：

  • 利用枠制限を必ず設定：OpenAI / Anthropic の管理画面で月次の使用上限を入れる
  • Workflow に最大反復回数を設定：Iteration ノードや Agent の自律実行に最大回数の制約を必ず入れる
  • コスト監視ダッシュボードを置く：プロバイダーの利用状況を週次でチェック

私の業務感覚としては、「最初から利用枠制限を入れることで、初回事故の被害金額が桁違いに減る」——これは個人試用でも法人運用でも同じ作法です。

13-4. 失敗 ④：本番運用での監視・エラー処理未設計

「動いた」と「本番に乗せられる」は別物です。Dify で作ったアプリを社内に出した後、LLM タイムアウト・API レート制限・ベクトル DB のダウン などのエラーが起きた時、ユーザーに「分かりません」とだけ返してしまう設計は、社内信頼を一気に失います。

回避策：

  • エラー時のフォールバック応答を Workflow / Chatflow の各ノードに用意
  • 人間担当者へのエスカレーション経路を Chatflow に組み込む（HTTP Request ノードで Slack 通知 等）
  • 監視ダッシュボード（Dify の利用統計 + LLM プロバイダーの API 状況）を週次でレビュー

13-5. 失敗 ⑤：商用利用条件・ライセンスの確認漏れ

Dify そのものは Apache 2.0 ライセンスで商用利用可能ですが、(1) クラウド版 dify.ai の利用規約、(2) 各モデルプロバイダーの商用利用条件、(3) ナレッジに入れる文書の著作権 の 3 点は別途確認が必要です。

回避策：

  • クラウド版の利用規約を契約前に確認（dify.ai/terms）
  • モデルプロバイダーの商用利用条件を確認（特に Llama のような OSS LLM は商用条件の確認が重要）
  • ナレッジに入れる文書の著作権を確認（社外の論文・記事は引用条件の確認、画像は AI 画像生成の場合 AI 画像生成 無料 で扱う観点と同じ）

最終判断は社内法務、必要に応じて弁護士の方へご相談ください。「絶対安全な構成」とは申し上げません。本記事の整理は出発点であって、判断軸の一つにすぎません。

14 — よくある質問（FAQ）

📖 この章で使う用語

  • Free 試用クレジット：モデルプロバイダーが初回利用者に付与する無料利用枠（数ドル〜数十ドル分）。
  • PoC（Proof of Concept：概念実証）：本格導入の前に「動かせるか」「ROI が見合うか」を確認する小規模実証。

Q1: Dify は無料で使えますか？

A1: クラウド版（dify.ai）には Free プラン があり、個人試用なら無料です。月のメッセージ数や保存できるナレッジ件数に上限がありますが、まずは概念を理解するには十分です。本格運用には Pro 月 $59〜の有料プランか、セルフホスト版（Dify Community Edition、OSS）に踏み出す形が一般的です。なお、LLM API 料金（Anthropic / OpenAI など）は Dify サブスクとは別途必要 です。最新の料金は dify.ai/pricing で必ず事前確認してください。

Q2: プログラミング未経験でも Dify でチャットボットを作れますか？

A2: はい、Dify は GUI ベースで設計されているため、プログラミング未経験でも Chatbot を 30 分程度 で作れます。最初の壁は API キーの取得（Anthropic / OpenAI のアカウント作成 → API キー発行）の心理的抵抗です。クレカ登録が必要ですが、利用枠制限を必ず設定すれば「うっかり数万円課金」を防げます。完全コード未経験の方は、まず Free プラン＋ Free 試用クレジットで「動かす感覚」を手に入れるところから始めてみてください。

Q3: Dify でセルフホスト（Docker）するのは難しいですか？

A3: Docker / Docker Compose の基本が分かれば、Dify Community Edition のセルフホスト立ち上げは Docker Compose ファイルを使って 30 分〜 1 時間程度で可能 です。難しいのはむしろ運用フェーズ（バックアップ・アップデート・監視）で、社内 IT 部門のサポートがあると安心です。機密情報を社外に出せない企業利用層には現実的な選択肢ですが、運用負担は組織の体力で判断してください。

Q4: Dify と n8n / Make / Zapier、どれを選ぶべきですか？

A4: 「絶対これ」とは申し上げません。私の業務感覚としては、LLM アプリ構築特化 なら Dify、社内ワークフローをセルフホストで持ちたいなら n8n、既存 SaaS スタックが大量にあるなら Zapier または Make、という使い分けが現実的です。目的（PoC を早く回す／業務フローに組み込む／既存 SaaS と繋ぐ）で選ぶのが結局いちばん早い、というのが私の業務感覚です。詳細は親ハブ記事 AIエージェント 作り方 のルート B 章を参照してください。

Q5: 業務で Dify を使うとき、機密情報の扱いはどうすればいいですか？

A5: 「絶対大丈夫」とは申し上げません（私は弁護士ではありません）。一般論として、(1) Dify と契約する LLM プロバイダー（Anthropic / OpenAI など）のデータ取り扱いポリシーを事前確認、(2) 機密情報・個人情報をナレッジにアップロードしない運用ルールを社内で合意、(3) 厳格な要件があればセルフホスト版＋ AWS Bedrock / Azure OpenAI 等の組織契約モデル、(4) 最終判断は社内法務・コンプライアンス部門へ——の 4 点が出発点になります。必要に応じて弁護士の方へご相談ください。

訂正連絡先

本記事の数字・出典・記述に誤りや古い情報があれば、お手数ですが send@bon-bon-tools.com までお知らせください。確認の上、本文末尾の「訂正履歴」セクションに反映いたします。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）