Difyの実際の使い方：ワークフローを作って動かす、自分の文書をナレッジにして答えさせる、Agentを作る、公開する、Webhookで起動する──画面の順に

3行でいうと

アプリは「Studio」から作ります。公式のクイックスタートは「Create from Blank」→「Workflow」の順に選び、名前をつけて「Create」を押します。ワークフローは「User Input」ノード（または Trigger）から始まり、「Output」ノード（任意）で終わる形です（公式のワークフローとチャットフローのページ）。
試すときは右上の「Test Run」→「Start Run」。ノードごとの結果は「Last Run」、途中の変数は「View cached variables」で見ます（公式のクイックスタート）。
自分の文書を読ませる「ナレッジ」は、「Knowledge」→「Create」→「Create a ready-to-use knowledge base」から。文書は分割（チャンク）され、索引の方式と検索の設定を決めます。
新しい「Agent」は、公式がベータと書いています。作成は「Agents」→「Create」→「Create from Blank」で、Editor 以上の権限が要ります。
作ったアプリの公開（Webアプリ）は、公式の設定のページによると、初期状態で公開（URLを知っていれば誰でも開ける）です。共有の前に確かめてください。

この記事は、公式の資料を2026年10月25日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。

先に結論

最初の1本は、公式のクイックスタートの手順をなぞるのが、読んだ範囲では一番はっきりしています。 ノードの種類、入れる項目、テスト用の入力例まで書かれています。
作る道具は3つに分かれます。 手順を決めて動かす Workflow、会話の窓口を作る Chatflow、道具を使いこなさせる Agent（ベータ）。違いは02を参照。
ナレッジは、作ったあとで「アプリに差す」ところまでが1セットです。 作っただけでは、アプリは文書を読みません。ワークフローやチャットフローに「Knowledge Retrieval」ノードを足して、結果を LLM ノードの「Context」に渡します（公式）。
公式のページに書かれていない画面の操作は、このページにも書いていません。 たとえば Chatflow を作るときのボタンの名前や、ナレッジを作る画面の細かい項目の名前は、読んだページに書かれていませんでした。手元の画面と照らしてください。

前提：用語をそろえる

ノード：ワークフローの1つ1つの部品（入力、LLM、条件分岐、出力など）です。キャンバスの上でつなぎます。
変数：ノードの出力や入力の値です。LLM ノードのメッセージなどで、User Input/draft のように前のノードの値を参照します（公式のクイックスタートの書き方）。
LLM：文章を作るAIモデルです。Dify が、LLM ノードとして呼びます。
チャンク：ナレッジで、文書を分けた小さな塊です。検索はチャンクを単位に行います。
RAG：検索で見つけた内容を材料にして、AIが答える仕組みです（01、02を参照）。
Test Run / Publish：下書きを試す操作と、本番として反映する操作です。公式のクイックスタートは、公開（Publish）のあとに変更したら、もう一度 Publish が要る、と書いています。

たとえ話：レシピカードを作って、台所に置く

ワークフローは、「材料を入れたら、手順どおりに料理ができるレシピカード」です。Test Run は試作、Publish は台所に置く本番のカード。ナレッジは、そのカードが引く「料理の辞書」です（たとえは僕らの整理で、公式の説明ではありません）。

最初の1時間の順番（この記事の案）

公式の手順ではなく、このページの案です。

時間の目安	やること	このページの場所
最初の10分	モデルを入れる（05のA-2、A-3、またはセルフホストの起動）	05
次の30分	クイックスタートのワークフローを作り、Test Run	場面1
次の10分	ノードごとの結果を見て、直す	場面6
残り	小さな文書をナレッジにして、答えさせる／公開してみる	場面2、3、5

時間の目安は、公式のクイックスタートの題名（30-Minute）に合わせた、この記事の案で、実際に測ったものではありません。

場面1：複数のSNS向けの文章を作るワークフロー（公式のクイックスタート）

公式のクイックスタートの題材は、下書きの文章から、指定したSNSごとの投稿文を作るワークフローです。ここでは、公式のページが挙げる構成と手順を並べます。

1-1 作る

「Studio」を開き、「Create from Blank」→「Workflow」を選びます。
名前に Multi-platform content generator と入れ、「Create」を押します。
キャンバスの「User Input」ノードを選びます。

1-2 ノードを作る（公式の構成）

順	ノード	設定（公式の記載）
1	User Input	項目：`draft`（Paragraph、必須、最大2048）、`user_file`（File list、任意、10まで）、`voice_and_tone`（Paragraph、任意）、`platform`（Short Text、必須、ラベル「Target Platform (≤ 10)」）、`language`（Select、必須：English／日本語／简体中文）
2	Parameter Extractor	入力は `User Input/platform`。抽出する項目 `platform`（Array[String]、必須）。公式が用意した指示文を貼る
3	IF/ELSE	条件：`Parameter Extractor/platform` が、エラーメッセージを含む（contains）。IF側に「Output」ノードを置く
4	List Operator ×2	ELSE側。1つは「Image」（フィルター：`type` が `Image`）、もう1つは「Document」（`type` が `Doc`）。入力は両方とも `User Input/user_file`
5	Doc Extractor	Documentノードの後ろ。入力は `Document/result`
6	LLM（名前は `Integrate Info`）	「VISION」をオンにし、`Image/result` を指定。公式の指示文を貼り、「Add Message」でユーザーメッセージに `User Input/draft` と `Doc Extractor/text` を参照
7	Iteration	入力は `Parameter Extractor/platform`、出力は `Create Content/structured_output`。「Parallel Mode」をオンにし、最大並列は10。中に LLM を2つ（`Identify Style`、`Create Content`）。`Create Content` は「Structured」をオンにし、「Configure」→「Import From JSON」で、`platform_name` と `post_content`（どちらも文字列）のスキーマを貼る
8	Template	入力は `Iteration/output`。変数名は `output`。公式のJinja2のコードを貼る
9	Output	出力の変数は `Template/output`

指示文（プロンプト）とコードは、公式のページに全文があります。このページでは写していません（内容の確認は公式で）。ノードをつなぐ操作そのもの（右クリックの項目など）は、読んだページに書かれていませんでした。

1-3 テストする

「Checklist」に残りがないことを確かめます。
右上の「Test Run」を押し、項目を入れて「Start Run」を押します。
公式のページの入力例は次のとおりです（公式のサンプル）。

項目	入力
Draft	`We just launched a new AI writing assistant that helps teams create content 10x faster.`
Upload File	空
Voice & Tone	`Friendly and enthusiastic, but professional`
Target Platform	`Twitter and LinkedIn`
Language	`English`

期待される結果は、公式のページによると、プラットフォームごとの見出しと投稿文が並ぶ出力です。出力の細かい形は、モデルと設定によって変わります（公式のクイックスタートも、結果は使うモデルによると書いています）。
別の入力を試すときは、キャンバス下の「View cached variables」で、ノードの値を直接書き換えられます。エラーのときは、そのノードの「Last Run」のログを見ます。

1-4 公開する

「Publish」→「Publish Update」を押します（公式のクイックスタート）。
あとで変更したら、もう一度公開します。公開しないと、変更は本番に反映されません。

場面2：自分の文書をナレッジにする

2-1 作る

「Knowledge」→「Create」→「Create a ready-to-use knowledge base」を選びます。
データの出どころを選びます。公式のページが挙げるのは、ローカルのファイル、Notion、Webページ、空のナレッジです。
ローカルのファイルなら「Import from file」で、ファイルを上げます。公式のページの制限は次の表のとおり（表示のまま）。

	Sandbox	Professional・Team
1回にあげられるファイル数	1	50
1ファイルの大きさ	15 MB	50 MB

対応する形式の全部の一覧は、そのページにはありません。DOCX、XLSX、PDF、画像（JPG、JPEG、PNG、GIF）への言及があります。
公式の注記：データの出どころは、ナレッジを作ったあとで変えられません。
DOCX と XLSX の中の画像（JPG・JPEG・PNG・GIF、2 MB未満）は、チャンクに添付されます。PDF など DOCX・XLSX 以外の画像は、ナレッジパイプラインの文書抽出プラグインで取り出せる、と書かれています（自動で取り出されるとは書かれていません）。

2-2 チャンクを決める

公式の「Configure the Chunk Settings」のページの内容です。

項目	公式の説明
General	すべてのチャンクが同じ設定で、一致したチャンクがそのまま返る。High Quality と Economical のどちらの索引でも使える。用語集やFAQのような単純な内容向け、と書かれている
Parent-child	小さい子チャンクで照合し、一致したら大きい親チャンクを返す。High Quality の索引のみ。技術マニュアルなど情報が詰まった内容向け、と書かれている
Delimiter（区切り）	分割する文字。`\n\n`（段落）、`\n`（行）など。区切りの文字は、分割のときに取り除かれる
Maximum chunk length	最大の文字数。長いと強制的に分割される
Chunk overlap	隣のチャンクと重ねる文字数（General）。例：50文字なら、前のチャンクの最後の50文字が、次の先頭になる
前処理	連続する空白・改行・タブの置き換え。URLとメールアドレスの削除（Full Doc では無視される）

チャンクの方式（モード）は、作ったあとで変えられません。
「Preview」で、一部のチャンクを確かめられます。複数の文書があるときは、プレビューの上のファイル名で切り替えます。
既定値は、読んだページに書かれていませんでした。結果がよくなければ、近い設定を選び、あとで「Manage Knowledge Content」で調整する、と公式は書いています。

2-3 索引と検索の設定

公式の「Specify the Index Method and Retrieval Settings」のページの内容です。

項目	公式の説明
High Quality	埋め込みモデルで意味による検索。ベクトル、全文、ハイブリッドが使える。作ったあとで Economical には戻せない
Economical	チャンクごとにキーワード10個。トークンを使わず、精度は低め。転置索引のみ。あとで High Quality に上げられる
Multimodal	「Vision」アイコンの付いた埋め込みモデルを選ぶと、文字と画像の両方を検索できる
検索の方法	Vector Search、Full-Text Search、Hybrid Search。Rerank Model は既定でオフ、TopK の既定は3、Score Threshold の既定は0.5
Hybrid の重み	「Weight Settings」で、意味と文字列のどちらを優先するかを決める。Rerank のAPIの設定なしで動く

High Quality には埋め込みモデルが必要で、ベクトルは、ワークスペースのナレッジの容量に数えられます。
Rerank のモデルは、「Integrations」→「Model Provider」で設定し（APIキーが要る）、使うとそのトークンを消費します。
公式のページは、TopK と Score の設定は Rerank の段階だけで効く、と書いています。VectorとFull-Textでは、Rerank のモデルをオンにしたときに効きます。

2-4 処理を待つ

公式の手順の最後は「データの処理が終わるのを待つ」です。終わった表示の見た目は、読んだページには書かれていませんでした。

2-5 検索を試す・中身を直す

公式のナレッジのページは、「Test and validate retrieval」（質問をまねて、何が返るかを確かめる）と「Manage content」（文書とチャンクの追加・変更・削除）、「Adjust knowledge base settings」（索引の方式、埋め込みモデル、検索の方針をあとから変える）を挙げています。具体的な画面の操作は、そのページには書かれていませんでした。

場面3：ナレッジを使って答えるチャットフローを作る

ここは、公式の「Knowledge Retrieval」ノードのページの手順です。

チャットフロー（またはワークフロー）に、「Knowledge Retrieval」ノードを足します。先に、ナレッジが1つ以上できている必要があります。
「Query Text」に、テキストの変数を選びます（チャットフローでは userinput.query が例）。
使うナレッジを選びます（複数も可）。同時に探して、結果をまとめます。
「Retrieval Setting」で、Rerank、Top K、Score Threshold を決めます。複数のナレッジでの重みづけ（Weighted Score）は、すべてのナレッジが High Quality のときだけ使えます。
ノードの出力は result（チャンクの配列）です。
LLM ノードの「Context」に、この result を選び、システムの指示文のなかで Context の変数を参照します。
チャットフローでは、ナレッジに基づく返答に、出典の表示（citations）が初期状態でつきます。「Features」でオフにできます。

指示文の例（この記事の例。公式の文面ではありません）：

あなたは社内の問い合わせ係です。次の資料だけを根拠に、日本語で短く答えてください。資料に書かれていないときは「資料にはありません」と答えてください。

資料：
{{Context}}

{{Context}} の部分は、LLM ノードの画面で変数として差し込む部分です。画面での差し込み方（書き方）は、手元の画面と公式のページで確かめてください。

Chatflow を新しく作るときのボタンの名前は、読んだページに書かれていませんでした（公式のページは、ワークフローを作る手順だけ、はっきり書いています）。

場面4：Agent（ベータ）を作る

公式の「Build an Agent」のページの手順です。このAgentは、公式がベータと書いています。作成と管理には Editor 以上の権限が要ります。

「Agents」→「Create」→「Create from Blank」を選びます。DSLファイルから始めるなら「Import DSL file」。DSLに、スキルとファイルは含まれません。
名前を入れます（役割と説明は任意）。
「Configure」で、次の項目を決めます。

項目	公式の説明
Model	ツール呼び出し（native tool calling）が使える、推論が強く、ネイティブなツール呼び出しが使える、新しめのチャットモデルを選ぶ
Prompt	役割と目的、よくある作業の進め方、ツールやファイルをいつ使うか、出力の形式。`/` を打つと、スキル・ファイル・ツールを参照できる
Skills	「Add」で、`SKILL.md` を含む `.zip` か `.skill` を上げる（50 MBまで）
Files	エージェントが読む資料。大きさの上限：文書15 MB、画像10 MB、動画100 MB、音声50 MB
Tools	ワークスペースのDifyのツール（プラグイン、独自のAPI、ワークフロー、MCPサーバー）。認証が要るものもある
Advanced Settings > Environment Variables	エージェントのサンドボックスが読める、キーと値。`.env` を取り込める

「Build」モードで話しかけて設定させることもできます。変更は「Build draft」に出て、「Apply」で残し、「Discard」で捨てます。「Discard」は、会話と、永続のサンドボックスのファイルも消します。「Apply」のあとの会話の扱いは、読んだページでは確認できていません。
右のパネルを「Build」から「Preview」に切り替えると、利用者から見える形で試せます。Preview での会話は、設定を変えません。
編集は下書きに自動で保存されます。準備ができたら公開します。バージョンの履歴から、前の版に戻せます。
「Access Point」のタブで、Webアプリ、サイトへの埋め込み、サービスAPIを使えます（07を参照）。

公式の実行の上限：1回の実行は1時間で止まり、未完の返答は捨てられます。モデルの呼び出しは、1回の実行で500回まで。返答のファイルは、1つ50 MBまで。サンドボックスはクラウドにあり、社内のURLには届かないので、社内の資料は「Files」に上げる、と書かれています。