Dify使い方ガイド2026｜構築手順・料金・セルフホスト

いまDifyの画面を開くと、半年前の解説記事と用語が噛み合いません。ノード一覧に「Trigger」「Human Input」「Loop」が並び、Agentのタブが「Classic Agent」と「New Agent」に分かれ、ナレッジ作成では「General / Parent-child」を先に選ばされる。この記事の初版（2026年5月）も Agent Node と Tool Node と IF/ELSE の3つだけで説明していましたが、その後 v1.15.0（6月25日）・v1.16.0（7月17日）・v1.17.0（8月25日）で画面構造そのものが変わりました（Dify Releases、参照日: 2026-09-03）。

そこで全面的に書き直しました。以下は2026年9月3日時点の公式ドキュメントと公式リリースノートに当たって確認した内容で、設定項目・既定値・制約は原文の呼び名のまま記載しています。

Difyとは — 2026年9月時点の現在地

何をするツールか

Difyは、LLM・ツール・ロジックをビジュアルキャンバス上でつなぎ、AIアプリとして公開・監視までできる開発プラットフォームです。開発元は LangGenius, Inc.。公式ドキュメントは「モデルは単体では予測不能なので、構造化された反復可能なプロセスの中にAIを埋め込む」という考え方を Agentic Workflows と呼んでいます（Workflow & Chatflow、参照日: 2026-09-03）。画面の入口は Studio（組む）・Knowledge（文書）・Integrations（接続）・Access Point（公開）・Logs（見る）の5つです。

ライセンスは「オープンソース」ではない

GitHubリポジトリ langgenius/dify は2026年9月3日時点で star 154,283・fork 24,394。見落としやすいのが、公式サイトが Community Edition を「Open source」ではなく 「Source-available. Apache-2.0-derivative license」 と表記していることです。リポジトリの LICENSE には「Apache License 2.0 の改変版で追加条件が付く」と明記され、商用ライセンスが必要になる条件が2つ挙げられています。

• マルチテナントサービス：Difyの書面による明示的な許可がない限り、Difyのソースコードを使ってマルチテナント環境を運用してはならない。ここでの「テナント」は1ワークスペースを指す
• ロゴと著作権表示：フロントエンド（ソース実行時は web/ ディレクトリ、Docker実行時は web イメージ）のコンソール・アプリからロゴや著作権表示を削除・改変してはならない

この2条件以外はApache 2.0に従います。自社サービスの基盤としてDifyを組み込むなら、社内展開なのか顧客ごとにワークスペースを切る運用なのかで扱いが変わるため、評価の初期段階で法務に共有しておくのが安全です（Dify LICENSE、参照日: 2026-09-03）。

直近3リリースの差分

バージョン	公開日	主な内容
v1.15.0	2026-06-25	CLI difyctl 追加。Workflow / Chatflow / CLI で推論過程を専用パネルに表示。Human-in-the-Loopフォームにセレクトとファイルアップロードを追加
v1.16.0	2026-07-17	新しい Dify Agent（オープンベータ）。UIでAgentを組み、Skillとファイルを持たせ、Workflowノードから呼べる。OpenAIプラグインの既定APIが Chat Completions から Responses へ変更
v1.17.0	2026-08-25	AgentのサンドボックスにE2Bバックエンド、ビルド時ホームスナップショット、ワークスペース単位のSkill管理、履歴の自動圧縮。Loop / Iteration の中で Human Input が使えるように

公式ドキュメントには日本語版があり、docs.dify.ai/ja/ 配下が英語版と同じ階層構造で読めます。ただし更新は英語版が先行します。

最初のアプリを公開するまでの手順（Cloud）

評価目的ならクラウド版が最短です。この順で進めれば公開URL取得まで一本道で通ります。

1. dify.ai から Sandbox（無料）でサインアップする
2. Integrations → Model Provider で使うLLMを設定する。Dify付属のクレジットで試すか、自社のAPIキーを登録する
3. 同じ画面で Embeddingモデルも設定する。ナレッジを高品質索引で作るときに必須になる
4. Studio で Workflow アプリを新規作成する（会話形式にしたいなら Chatflow）
5. キャンバスに User Input → LLM → Output の3ノードを置いてつなぐ
6. Test Run で実行する。詰まったノードは Single Node 実行と Variable Inspector で変数の中身を確認する
7. Publish を押し、Access Point タブから WebアプリURL・APIキー・埋め込みコード・MCPサーバーURLを取得する

注意点が1つ。公式ドキュメントは「Publishすると現在の構成でライブのアプリが置き換わり、ユーザーは次の操作から即座に変更を見る」と警告しています。Webアプリ・API・埋め込み・MCPサーバーは同じアプリ構成を共有するため、本番稼働中のアプリを触ったまま勢いでPublishしないのが鉄則です（Publish Overview、参照日: 2026-09-03）。アプリが増えたら ⌘K（Windows / Linux は Ctrl+K）でコマンドパレットから各所へ直接飛べます。

Workflow・Chatflow・Agent の使い分け

違いは「誰がどう起動するか」

アプリ種別で迷うポイントは機能差ではなく起動と終端の形です。

項目	Workflow	Chatflow
実行形態	入力を受けて最初から最後まで1回走り、結果を返す	チャットUI。メッセージごとにフローが走って応答を作る
開始ノード	User Input または Trigger	User Input のみ
終了ノード	Output ノード（任意）	Answer ノード（必須）
向いている用途	レポート自動生成、データ処理、バッチ処理	対話型アシスタント、ガイド付きQ&A
Trigger	使える	使えない（必ずユーザー発話が起点）

「Agent」が2種類あるのが分かりにくいところです。従来の Classic Agent（Agentノードの既定タブ）は、LLMにツール群を渡して自律的に呼ばせる方式で、戦略に Function Calling と ReAct を選べます。v1.16.0 で入った New Agent はベータで、Workflowアプリでのみ使えます。

New Agent の制約

New Agent は自分専用のサンドボックスの中でコマンドを実行し、パッケージを入れ、ファイルを読み書きします。「能力（役割・プロンプト・モデル・Skill・ツール）は Agents ページで一度作り込み、タスクはノード側で書く」という分け方です。ドキュメントに明記された制約は設計前に押さえておきましょう。

• 同じAgentを呼ぶ2つのノードは別々に動き、実行結果は互いに引き継がれない
• Agentタスクに差し込んだ変数はテキストとして渡り、2,000文字で切られる。長い内容はファイルとして渡す
• Agentが返すファイルは1ファイル50MBまで
• 既定の出力は text の1つ。個別に取り出す値は / から「New output」を宣言する

Trigger — ユーザーを待たずに動かす

Workflowアプリ限定で、Start ノードの代わりに Trigger を置けます。定期業務をDifyに寄せるときの主役です。

種類	起動条件	制約
Schedule Trigger	指定時刻・指定間隔で実行	1ワークフローにつき1つまで
Integration Trigger	外部サービスのイベント購読（Slackの新着メッセージなど）	対象サービスのトリガー統合が必要
Webhook Trigger	任意のHTTPリクエスト受信	外部側にWebhook設定が必要

Sandboxアカウントは1ワークフローあたりトリガー2つまで。トリガー起動による実行回数（Trigger Events）はプランごとの月次クォータ対象で、残量は Settings → Billing で確認します。

ノードの現行ラインナップと条件分岐

2026年9月時点で公式ドキュメントの Nodes 配下に並ぶノードを役割別に整理しました。

分類	ノード	使いどころ
起点	Start / User Input / Trigger	ユーザー入力かイベント起動かを決める
生成	LLM	テキスト生成・分析。画像ファイルをマルチモーダルモデルへ直接渡せる（v1.17.0）
自律実行	Agent	推論しながらツールを選ばせる。Classic と New の2タブ
検索	Knowledge Retrieval	ナレッジから関連チャンクを取り、後続ノードの文脈にする
分岐	If-Else / Question Classifier	条件分岐と、意図によるルーティング
繰り返し	Iteration / Loop	配列処理と、前回結果を踏まえた反復
データ加工	Code / Template / Parameter Extractor / List Operator / Document Extractor	Python・JS処理、Jinja2整形、自然言語からの構造化、配列操作、文書からのテキスト抽出
変数	Variable Aggregator / Variable Assigner	排他分岐の合流、Chatflowの会話変数の更新
外部接続	HTTP Request / Tool	任意のREST API、登録済みツールの実行
人の介在	Human Input	フォームを出して人の判断を待つ
終端	Answer / Output	Chatflowの応答、Workflowの返却値

If-Else の条件は2グループ

IF・複数のELIF・ELSE を並べられ、条件は AND / OR で組み合わせられます。演算子は文字列系（Contains / Not contains、Starts with / Ends with、Is / Is not）と値系（Is empty / Is not empty、Greater than / Less than、Equals / Not equals）の2グループ。変数は変数セレクタで選ぶか {{variable_name}} で直接書きます。ELSE を必ず置くと「どの条件にも当たらず止まる」事故が防げます。排他分岐の再合流は Variable Aggregator、Chatflowで値を持ち回るときは Variable Assigner です。

Human Input — 承認ステップをノードで作る

ワークフローを一時停止してフォームを出し、回答を受けて再開するノードです。配信は Web app（Trigger起動では使えない）と Emailの2種で、メールは外部アドレスにも送れ、受信者はDifyアカウントなしで回答できます。項目は Paragraph・Select・Single File / File List（画像10MB、文書ほか15MB、音声50MB、動画100MB）。最初の1件の回答でリクエストは閉じます。

Iteration と Loop を取り違えない

この2つを逆に選ぶと、動くけれど意図した結果にならない、というやっかいな失敗をします。判断軸は各回の処理が前の回の結果に依存するかどうかの1点です。

観点	Iteration	Loop
処理の性質	配列の各要素を独立に処理	各サイクルが前回の結果の上に積み上がる
並列	並列モードで最大10件同時	順次のみ
状態	要素間で持ち越さない	ループ変数が反復をまたいで残り、終了後も参照できる
終了条件	配列を処理し切ったら終了	終了条件式、最大ループ回数、Exit Loop ノードのいずれか
典型用途	データ変換、一括処理、並列分析	文章の推敲、品質が閾値を超えるまでの作り直し

Iteration の中では items[object]（現在の要素）と index[number]（0起点の添字）が使えます。エラー処理は3種類で、入力 [1, 2, 3] の2番目が失敗したときの出力が変わります。Terminate は停止、Continue on Error は [result-1, null, result-3]、Remove Failed Results は [result-1, result-3]。出力は配列なので、文字列に畳むには Code ノードか Template ノードを挟みます。

# Code ノード（Python）で配列を1本のテキストに畳む
# 動作環境: Dify v1.17.0 / Code ノード（Python3）
def main(articleSections: list):
    return {
        "result": "\n".join(articleSections)
    }

Loop 側はループ変数・終了条件式（例: quality_score > 0.9）・最大ループ回数・Exit Loop ノードを組み合わせます。条件を1つも指定しないと最大回数に達するまで回り続けるため、最大回数は必ず入れるのが安全側の設計です。v1.17.0 からは Loop と Iteration の内側でも Human Input が使えるので、「3回まで自動で直し、閾値を超えなければ人に回す」構成が1つのワークフローで完結します。

ナレッジ（RAG）の設定 — チャンクと索引で精度が決まる

最初の2択が後で変えられない

ナレッジ構築でいちばん重要なのは、取り込むファイルの中身ではなく作成ウィザードの最初の2画面です。

設定	選択肢	後から変更
チャンクモード	General / Parent-child	作成後は変更不可（区切り文字と最大長は変更可）
索引方式	High Quality / Economical	Economical → High Quality は可。High Quality → Economical は不可

General モードは全チャンクが同じ設定で、ヒットしたチャンクがそのまま検索結果として返ります。区切り文字（\n\n で段落、\n で行）と最大チャンク長に加えてチャンクオーバーラップを指定でき、50文字なら前のチャンクの末尾50文字が次の先頭にも入り、境界で意味が切れるのを防ぎます。

Parent-child モードは2階層です。小さい子チャンクで検索精度を出し、ヒットしたら親チャンク全体を結果として返します。「小さいチャンクは当たるが文脈が足りない、大きいチャンクは文脈はあるが当たらない」というRAGの定番のジレンマへの解です。親チャンクは Paragraph（区切り文字と最大長で分割）か Full Doc（文書全体を1つの親にする）から選びます。

Full Doc には無視できない制約が2つあります。先頭10,000トークンまでしか処理されず、以降は切り捨てられること。そして作成後は親チャンクを編集できず、直すには文書を入れ直すしかないことです。長い規程集をFull Docで入れて後半が丸ごと落ちる、というのが典型的なつまずきです。また Parent-child は High Quality 索引でしか使えません。分割単位ごとの得失はRAGチャンキング戦略の解説記事で整理しています。

索引方式と検索方式

High Quality はEmbeddingモデルでチャンクをベクトル化し、生成されたベクトルはワークスペースのナレッジ保存容量を消費します。Economical は1チャンクあたり10個のキーワードを使う転置インデックス方式で、トークンを消費しない代わりに検索精度は落ちます。High Quality では検索方式を Vector Search（意味で拾う）・Full-Text Search（語で拾う）・Hybrid Search（両方を実行して並べ直す）の3つから選べます。

共通パラメータの既定値は TopK = 3、Score Threshold = 0.5。ここに重要な但し書きがあります。公式ドキュメントは「TopK と Score の設定はRerankフェーズでのみ有効。したがって効かせるにはRerankモデルの追加と有効化が必要」と明記しています。Rerankを設定しないまま TopK をいじって「変わらない」と悩むのは、この仕様を知らないためです。

Hybrid Search だけは、Rerankモデルなしでも重み設定で調整できます。セマンティック側を1にすればベクトル検索のみ、キーワード側を1にすれば全文検索のみ、中間の比率も自由です。日本語の社内文書のように表記ゆれ（「見積り／見積もり／御見積」）が多い一方で製品コードや型番の完全一致も必要、という混在ケースでは、この重み調整が現実的な着地点になります。効かせ方の詳細はリランク・ハイブリッド検索の実装ガイドで扱っています。

Embeddingモデルにマルチモーダル対応（Visionアイコン付き）を選ぶと文書中の画像も埋め込まれ、テキストと画像を横断して検索できます。この場合はRerankモデルもマルチモーダル対応にしないと結果から画像が除外されます（Embeddingモデル選定ガイド）。

取り込み前には、連続する空白・改行・タブの置換と、URL・メールアドレスの削除を有効にできます（後者は Full Doc では無視）。設定後は Preview で分割結果を確認します。元ファイルの構造をどこまで拾えるかはドキュメント抽出・パースの解説と合わせて設計すると失敗が減ります。

ツールとMCP — 外部サービスをつなぐ4つの型

ツールは Integrations → Tools で一元管理します。追加方法が4つあり、向き不向きがはっきりしています。

型	内容	選ぶ場面
Tool Plugin	Difyとコミュニティが提供する既成ツール。組み込み以外は Marketplace から導入	GoogleやGitHubなど、よく使うサービス
Swagger API	OpenAPI（Swagger）仕様を貼り付け・URL指定でインポートし、ツールインターフェースを自動生成	社内APIや、プラグインのないサービス
Workflow	User Input ノードで始まる Workflow をツール化して他アプリから再利用。Chatflow はツールにできない	複数アプリで使い回す多段ロジック
MCP	MCPサーバーを接続し、そのツール群をDifyに取り込む	DB・ファイルシステム・既存MCP資産の活用

MCPサーバーを取り込むときの注意点

最初に確認すべきはトランスポートがHTTPであることです。公式ドキュメントは「HTTPトランスポートのMCPサーバーのみサポート」と明記しており、stdio前提のサーバーは繋がりません。登録はURL・名前・一意のサーバー識別子の3つ。認証は Dynamic Client Registration が既定でオンで、サーバーが対応していればOAuth資格情報を自動取得します。非対応や既存OAuthアプリを使う場合はオフにし、Client ID と Secret を入れてDifyが表示するリダイレクトURLをサーバー側に登録します。権限設計の全体像はMCP認可の実装ガイドで押さえられます。

運用で刺さりやすいのが識別子の扱いです。アプリはサーバーを識別子で参照するため、後から変えると旧識別子を使っていたアプリでツールが動かなくなり、各アプリで追加し直す必要が出ます。エクスポートしたアプリも識別子で参照します。固定トークンで認証するサーバーには Custom Headers を使い、{{request.headers.X-Custom-Auth}} と書けば呼び出し元リクエストのヘッダーが差し込まれます（該当ヘッダーがなければ空値）。

逆向き — DifyアプリをMCPサーバーとして公開する

取り込むだけでなく、作ったDifyアプリをMCPサーバーとして外に出せます。アプリの Access Point タブの MCP Server カードで有効化すると（既定はオフ）、そのアプリ専用のMCPサーバーアドレスが生成されます。Cursor から使う場合はプロジェクトルートの .cursor/mcp.json に次を書きます。Claude Desktop なら、プロフィール → Settings → Integrations → Add integration で Integration URL に同じサーバーURLを入れます。

{
  "mcpServers": {
    "your-server-name": {
      "url": "your-server-url"
    }
  }
}

ここは事故が起きやすいので強調します。公式ドキュメントは「MCPサーバーURLには認証情報が含まれるのでAPIキーと同じように扱え。漏洩の疑いがあれば再生成ボタンで新しいURLを作れ（旧URLは即座に無効になる）」と警告しています。共有チャンネルに貼る類のURLではありません（公開側の作法はMCPサーバー公開の手順解説）。あわせて「アプリの処理に30秒かかるなら、その遅延はクライアント側で体感される」とも書かれており、進捗表示か、ワークフローの分割が要ります。

公開する — Webアプリ・埋め込み・API・MCPサーバー

公開方法は排他ではありません。Webアプリ（Publishしてリンクを共有するだけ）、Webサイト埋め込み（チャットウィジェットまたはインラインフレーム）、API（自社プロダクトへの組み込み）、MCPサーバー（Claude DesktopやCursorからネイティブツールとして）の4経路に、1つのアプリ構成が同時に反映されます。公開前に整える項目としてドキュメントが挙げているのは、アプリ説明・アイコンとブランディング・アクセス制御・レート制限の4つです。

Service API を叩く

公開したアプリはそのままREST APIになります。Cloudのベースは https://api.dify.ai/v1、セルフホストなら自分のインスタンスのAPIベースURLです。認証はBearerトークン。APIキーはアプリ内で発行し、フロントエンドには置きません。

# 動作環境: Dify Cloud / Service API v1（2026-09-03 時点）
export DIFY_API_KEY="app-xxxxxxxxxxxxxxxx"

# 1. 疎通確認（アプリ情報を取得）
curl https://api.dify.ai/v1/info \
  -H "Authorization: Bearer $DIFY_API_KEY"

# 2. Workflow を実行する
# inputs のキー名は Get App Parameters の user_input_form で確認できる
curl -X POST https://api.dify.ai/v1/workflows/run \
  -H "Authorization: Bearer $DIFY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": { "query": "先月の問い合わせ傾向を要約して" },
    "response_mode": "streaming",
    "user": "user-0001"
  }'

必須パラメータは inputs と user。response_mode は blocking（完了時に一括で返る）と streaming（Server-Sent Events でノード実行ごとにイベントが届く）で、blocking には Cloudflare のタイムアウト100秒が効くとAPIリファレンスに明記されています。時間のかかる処理は必ず streaming にします。user はエンドユーザー識別子でデータのスコープを決め、ある実行とそのファイルは同じ user を持つ後続リクエストからしか見えません。

レスポンスに含まれる2つのIDは役割が違います。task_id は実行中の制御用（Stop Workflow Task でキャンセル。streamingモードのみ有効）、workflow_run_id は永続化レコードの識別子で切断後の再接続に使います。再接続時に include_state_snapshot=true を付けると実行済みノードの状態を先に再生でき、continue_on_pause=true を付けると複数回の Human Input 停止をまたいでストリームを維持できます。なお v1.15.0 で追加された公式CLI difyctl を使えば、同じアプリをターミナルやCIから実行できます（Install difyctl）。

セルフホスト — Docker Composeの現行手順

公式ドキュメントの最小要件は CPU 2コア以上・RAM 4GiB以上です。

OS	必要なソフトウェア	補足
macOS 10.14 以降	Docker Desktop（Docker Compose 2.24.0 以上）	Dockerの仮想マシンに仮想CPU 2つ以上・メモリ8GiB以上を割り当てる
Linux 各ディストリビューション	Docker 19.03 以上、Docker Compose 2.24.0 以上	—
Windows（WSL 2 有効）	Docker Desktop（Docker Compose 2.24.0 以上）	ソースとデータはWindows側でなくLinuxファイルシステムに置く

# 動作環境: Docker Compose 2.24.0 以上（docker compose version で確認）
# 事前に git / curl / jq が必要

# 1. 最新リリースのタグを指定してクローンする（main を直接クローンしない）
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
cp .env.example .env

# 3. 起動して状態を確認する（init_permissions が Exited なのは正常）
docker compose up -d
docker compose ps

初版の記事では git clone をそのまま実行していましたが、現行ドキュメントは最新リリースのタグを指定してクローンする形に変わっています。開発中のmainブランチを引く事故を避けるためです。タグ指定が fatal: Remote branch null not found in upstream origin で失敗する場合は、リリースページのバージョン番号を直接指定します。

起動するのはコアサービス7つ（api、api_websocket、worker、worker_beat、web、plugin_daemon、agent_backend）、依存8つ（weaviate、db_postgres、redis、nginx、ssrf_proxy、agent_ssrf_proxy、sandbox、local_sandbox）、権限設定後に終了する init_permissions です。agent_backend と local_sandbox は新Agent機能に伴う追加なので、旧構成の記憶のまま数えると「余計なコンテナがある」と誤解します。初期化は http://localhost/install で管理者アカウントを作ります。

設定ファイルの構造が変わった

環境変数は2層です。起動に必須の値は docker/.env、オプションやプロバイダー固有の設定は docker/envs/ 配下のテンプレートを .example を外してコピーし、コピー側を編集します。

# 例: ベクトルストアを Milvus に切り替える場合
cd dify/docker
cp envs/vectorstores/milvus.env.example envs/vectorstores/milvus.env

# 設定変更後の再起動
docker compose down
docker compose up -d

docker/.env の値が docker/envs/*.env より優先されます。両方に同じキーを書いて「効かない」と悩むのはこの優先順位が原因です。アップグレード時は、各 .env.example と .env を比較して新規・変更された変数を確認し、docker-compose.yaml をカスタマイズしている場合は新しいリリースのファイルに自分の変更を当て直す、とドキュメントに明記されています。リリースによっては必要なサービスが追加されており、古いComposeファイルのままだと起動しません。

Cloud とセルフホストの判断

観点	Dify Cloud	Community Edition（自前運用）
初期コスト	Sandboxは無料、Professional 月$59から	ソフトウェア費用なし。サーバーと運用工数は自社負担
データの置き場所	Difyのクラウド	自社インフラ内で完結
アップグレード	自動	リリースごとに手作業。Compose差分の追従が必要
ライセンス	利用規約に従う	Apache 2.0の改変版。マルチテナント提供とロゴ除去に制限
向いている段階	評価・PoC・小規模本番	データを外に出せない、規模が読める、運用担当がいる

実務では「評価はCloudで進め、要件が固まってから自前運用を検討する」が扱いやすい順序です。CloudのアプリはDSLとしてエクスポートし自前運用側にインポートできます。オープンモデルを自前で回すならvLLMでのセルフホスト推論の運用ガイドで推論基盤側の要件も同時に見積もっておくと後戻りが減ります。

料金 — プランと「メッセージクレジット」の正体

項目	Sandbox	Professional	Team
価格	無料	月$59 / 年払い$590	月$159 / 年払い$1,590
メッセージクレジット	200	5,000 / 月	10,000 / 月
チームメンバー	1人	3人	50人
アプリ数	5	50	200
ナレッジ文書数	50	500	1,000
ナレッジ保存容量	50MB	5GB	20GB
トリガーイベント	—	20,000 / 月	無制限

年払いは月払い比で17%割引と表示されます。税は別途、チェックアウト時に加算される場合があります。この上に Enterprise（価格は問い合わせ）と、無料の Community Edition があります（Dify Pricing、参照日: 2026-09-03）。

クレジットを「実行回数」と読み替えない

料金まわりで最も誤解されやすい点です。公式の説明はこうです。「メッセージクレジットは、OpenAI、Anthropic、Gemini、xAI、Tongyi といったさまざまなモデルをDify上で手軽に試せるように提供されるもの。クレジットはモデルの種類に応じて消費される。使い切ったら自分のAPIキーに切り替えられる」。

つまりクレジットはDify側が用意した試用枠であって、アプリの実行回数の上限ではありません。自社のAPIキーを登録して使う場合、モデル呼び出しの費用は各社への直接課金になりクレジットは消費されないので、プラン選定で効くのはチームメンバー数・アプリ数・ナレッジ文書数と保存容量・トリガーイベント数のほうです。逆にクレジットで試している間は、高性能モデルで長文を扱えば想定より早く枯れます。

もう1つ、Sandboxの表記は「200 message credits」で月次の付与ではありません（Professional以降は明示的に「/ month」と書かれています）。初版の記事は「Sandboxは月200メッセージ」と書いていましたが、これは誤りでした。ナレッジ側も、高品質索引のベクトルが保存容量を消費し上限に達すると新しい文書がアップロードできなくなる点と、リクエストのレート制限（Professionalの表示は毎分100リクエスト）を先に見積もっておきます。

Difyが向かない場面

• AIをほとんど使わない業務自動化：SaaS間のデータ連携が主目的なら、コネクタ数と再試行の作り込みで n8n のほうが素直です（n8nのGitHub star は2026年9月3日時点で203,193）。構成はn8nでのAIエージェント構築ガイドで比較できます
• マルチテナントSaaSの基盤として組み込む：Community Edition のライセンス条件に抵触するため、商用ライセンスの取得が前提になります
• ミリ秒単位のレイテンシ要件：ノードを跨ぐ実行モデルなので、応答速度が最優先の経路には向きません
• 定義をコードでレビュー・テストしたい：GUIが主で差分レビューの粒度は粗くなります。Flowise AgentFlow V2（star 55,403）などと比較検討する価値があります

star数は活発さの目安であって機能の優劣を示す指標ではありません。判断は自社の要件（データの置き場所、担当者のスキル、既存システムとの接続点）に戻して行ってください。社内問い合わせ対応を最初の題材にするなら、社内FAQ AIエージェントの実装ガイドでナレッジ整備とエスカレーション設計まで確認できます。

つまずきやすい5つのポイントと回避策

失敗1：Sandboxの200クレジットを「月200回の会話」と読む

❌ 「月200件の問い合わせだからSandboxで足りる」と判断して見積もりを出す

⭕ クレジットはDify提供モデルの試用枠で月次付与ではないと理解し、自社APIキー運用を前提にモデル費用を別建てで見積もる

なぜ重要か：この読み違いは予算とプラン選定の両方を狂わせます。自社APIキーを使うなら、Difyのプランで見るべきは人数・アプリ数・ナレッジ容量・トリガー回数です。

失敗2：チャンクモードを後から変えようとする

❌ とりあえずGeneralで作り、精度が出なければParent-childに切り替える

⭕ 対象文書の性質（FAQ・用語集なら General、技術マニュアルや規程集なら Parent-child）を決めてから作成する

なぜ重要か：チャンクモードは作成後に変更できません。区切り文字と最大長は直せますが、モードは作り直しになります。

失敗3：TopKとScoreを調整しているのに結果が変わらない

❌ Rerankモデルを設定しないまま TopK と Score Threshold を触り続ける

⭕ Integrations → Model Provider でRerankモデルを設定・有効化してから TopK（既定3）と Score（既定0.5）を調整する

なぜ重要か：公式ドキュメントは「TopKとScoreの設定はRerankフェーズでのみ有効」と明記しています。Rerankを入れずに調整したいなら Hybrid Search の重み設定を使います。

失敗4：blockingモードで長いワークフローを叩く

❌ 処理に数分かかるワークフローを response_mode: blocking で同期呼び出しする

⭕ 長い処理は streaming にし、切断時は workflow_run_id でストリームを再開する

なぜ重要か：blockingにはCloudflareの100秒タイムアウトが効きます。ワークフロー側は動いているのにクライアントだけ切れる、という切り分けの難しい障害になります。

失敗5：OpenAIプラグインの設定が Chat Completions のまま残っている

❌ 以前にカスタムのOpenAI APIキーを保存したまま、新しいモデル系列に切り替えて謎のエラーに悩む

⭕ プラグイン設定のAPIタイプを確認し、Chat Completions のままなら Responses に切り替える

なぜ重要か：v1.16.0 のリリースノートに「新規設定の既定APIタイプを Chat Completions から Responses に変更した。ただし旧既定で保存済みのユーザーはその設定を保持するため、Difyが原因に見える予期しないエラーが起きうる」と明記されています。

よくある質問

Q1. Difyは無料でどこまで使えますか？

Cloudの Sandbox プランが無料で、200メッセージクレジット・チームメンバー1人・アプリ5個・ナレッジ文書50件・保存容量50MBまで使えます。自前運用する Community Edition はソフトウェア費用がかからず、サーバー費用と運用工数だけで動かせます。ただしライセンスはApache 2.0の改変版で、マルチテナント提供とフロントエンドのロゴ・著作権表示の除去に制限があります（2026年9月3日時点）。

Q2. Difyの月額料金はいくらですか？

2026年9月3日時点で Professional が月$59（年払い$590）、Team が月$159（年払い$1,590）です。年払いは月払い比で17%割引と表示されます。税は別途加算される場合があり、Enterprise は問い合わせ制です。

Q3. Difyの「メッセージクレジット」は会話回数のことですか？

いいえ。公式の説明では、OpenAI・Anthropic・Gemini・xAI・Tongyi などのモデルをDify上で手軽に試すために提供される枠で、モデルの種類に応じて消費されます。使い切ったら自分のAPIキーに切り替えられます。自社APIキーで運用する場合、モデル費用は各社への直接課金になります。

Q4. DifyとChatGPTは何が違いますか？

ChatGPTは完成した対話サービス、Difyはアプリを作って公開するためのプラットフォームです。Difyでは使うモデルを選べ（自社のAPIキーも使える）、社内文書をナレッジとして接続し、条件分岐や外部API呼び出しを含むワークフローを組み、Webアプリ・API・埋め込み・MCPサーバーとして公開できます。単体で高性能な対話をすぐ使いたいだけならDifyを挟む必要はありません。

Q5. Difyの弱点や注意点は何ですか？

チャンクモードと索引方式に作成後変更できないものがあること、blockingモードのAPIに100秒のタイムアウトがあること、MCPサーバーURLに認証情報が含まれること、Community Editionのライセンスに商用条件があることが挙げられます。いずれも仕様として公式に明記されているもので、事前に把握していれば回避できます。

Q6. Difyの読み方は何ですか？日本語ドキュメントはありますか？

読み方については、2026年9月3日時点で公式ドキュメントおよび公式サイト上に読み仮名の記載を確認できていません。日本語の解説記事では「ディファイ」「ディフィ」の両方が使われているため、社内資料では英字表記の Dify のままにすると表記ゆれを避けられます。ドキュメントの日本語版は docs.dify.ai/ja/ 配下にあり、英語版と同じ階層構造です。ただし更新は英語版が先行します。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• Workflow & Chatflow — Dify Docs（参照日: 2026-09-03）
• Agent Node — Dify Docs（参照日: 2026-09-03）
• Trigger — Dify Docs（参照日: 2026-09-03）
• Configure the Chunk Settings — Dify Docs（参照日: 2026-09-03）
• Specify the Index Method and Retrieval Settings — Dify Docs（参照日: 2026-09-03）
• MCP Server — Dify Docs（参照日: 2026-09-03）
• Get Started with the Dify API — Dify Docs（参照日: 2026-09-03）
• Deploy Dify with Docker Compose — Dify Docs（参照日: 2026-09-03）
• Releases — langgenius/dify — GitHub（参照日: 2026-09-03）
• Dify Pricing — Dify（参照日: 2026-09-03）

まとめ：今日から始める3つのアクション

1. 今日やること：Dify Cloud の Sandbox で User Input → LLM → Output の3ノードだけのWorkflowを Publish し、Access Point タブでWebアプリURLとAPIキーの場所を確認する
2. 今週中：社内文書を10件だけナレッジに入れる。チャンクモードと索引方式を意図して選び、Preview で分割結果を確認してから Knowledge Retrieval ノードにつなぐ
3. 今月中：この記事の「つまずきやすい5つのポイント」を自分の構成で点検し、本番想定のワークフローを1本、Human Input による承認ステップ込みで組み上げる

---

あわせて読みたい:

• Agentic RAG実践ガイド｜4つのRAGパターン比較と選び方 — Difyのナレッジ設計を一段深く詰めたい方向け
• ITヘルプデスクAIエージェント完全ガイド｜Slack+MCP+RAG — 最初の題材を社内ヘルプデスクにしたい方向け
• AgentIQとは？NVIDIA製AI運用見える化基盤 — AIエージェントの運用監視を強化したい方向け
• MCP Registry完全ガイド｜公開手順6ステップ — 自作ツールをMCPサーバーとして公開したい方向け

---

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書シリーズ累計5万部超。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

📚 公式リファレンス・出典

• Dify 公式ドキュメント
• Dify GitHub リポジトリ
• 総務省 情報通信白書 AI/DX 章
• 経済産業省 AI関連政策

このテーマの関連記事

• ▸ 【2026年10月】LM Studio Bionicの日本語化｜設定と注意点
• ▸ n8n AI Agent入門｜ノード基本編【2026年10月】
• ▸ LangGraph MCP連携3手順【2026年10月4日】
• ▸ ローカルLLM×RAGの作り方｜オフライン実装【2026年10月】
• ▸ LangGraph Studioの使い方｜可視化・デバッグ【2026年10月】