2026年3月10日 2026年3月10日ながみえ

Dify用語集｜初心者向けに基本用語をやさしく解説

ながみえ

Difyを学び始めると、似たような言葉が次々に出てきて、「結局これは何を指しているのだろう」と手が止まってしまうことがあります。

この記事では、Difyでよく出てくる用語をカテゴリごとに分けて、初心者の方でも意味をつかみやすいようにやさしく整理していきます。

まずは言葉の意味をざっくり押さえ、そのあと必要に応じて関連記事で理解を深められるような、辞書のように使いやすい構成を目指します。

Dify学習館｜生成AIアプリ開発の基礎から実践まで

“Dify学習館” はDifyを用いた生成AIアプリ開発を体系的に習得できる学習サイトです。

初心者でも手順に沿って進めるだけでアプリを作れるようになり、業務効率化や副業にも活かせる内容になっています。

ぜひ、ご活用ください^^

Dify学習館｜生成AIアプリ開発の基礎から実践まで

【Dify】OpenAIの各LLMの違いと選び方｜GPT-5系やoシリーズ等の使い分け【2026年版】

【Dify】LLMノードの詳細設定方法と考え方｜チャットフローとワークフロー

【Dify】入力フォーム設計入門｜変数・フィールド設計ミニ講座

【Dify】定型文が崩れる原因｜敬語・トーン・禁止表現のガード設計

【Dify】LLMに任せないほうがいい文章と安全な扱い方

Difyの用語一覧

※ 以下のリンクは全て手作業で繋いでいます。もしミスを見つけた場合は問い合わせフォームからお知らせいただけると大変助かります。

索引	用語
A～C	Agent、Answer、API、API Access、APIキー、App、Authentication、Built-in Tools、Chatbot、Chatflow、Citation、Code、Content Moderation、Custom Tools
D~F	Dashboard、Dify、Dify Cloud、Dify DSL、Document Extractor、Draft、ELIF、ELSE、Embedding、End、Export、Few-shot、File Upload、Follow-up、Full-text Search
H~M	HTTP Request、Hybrid Search、If-Else、Import、Iteration、JSON、Knowledge Retrieval、Latest Version、LLM、LLMノード、Loop、MCP、MCP Tools、Metadata、Metadata Filtering、Model Provider
O～S	OAuth、OpenAPI、Parameter Extractor、Plugin、Preview、Publish、Publish Update、Question Classifier、RAG、Rerank、Score Threshold、Start、Studio、Swagger、sys.dialogue_count、sys.files、sys.user_id
T~Y	Template、Text Generator、Tool Calling、Tools、Top K、TTS、User Input、userinput.query、Variable Assigner、Vector Search、Version Control、Vision、Web App、Weighted Score、Workflow、Workflow Tools、Workspace、YAML
カナ	アクセス権限、インデックス、エンドポイント、ガードレール、コンテキスト、システムプロンプト、システム変数、セッション、セルフホスト、チャンク、チャンク分割、データ型、ナレッジ、ナレッジベース、ノード、ハルシネーション、ファイルアップロード、フロー、プロンプト、メモリ、モニタリング、レスポンス、ロールバック、ログ、ワークフロー変数
漢字	永続化、画像入力、会話ターン、会話開始メッセージ、会話変数、環境構築、環境変数、禁止表現、検索クエリ、構造化出力、出力、出力変数、接続、入力、入力変数、配列処理、分岐、変数、変数スコープ、変数参照、埋め込み

Difyの基本概念

Difyを使ううえで土台になる言葉から整理していきます。

この章では、「Difyとは何か」「どこでアプリを作るのか」「モデルとはどう接続するのか」「どんな形で利用するのか」といった、最初に押さえておきたい基本用語を見ていきます。

Difyそのものを理解する用語

Difyは機能が多いため、最初は画面の名前や場所の名前だけでも少し混乱しやすいです。

ここでは、Difyそのものと、アプリを作る場所に関わる用語をやさしく整理します。

用語	意味
Dify	AIアプリやエージェンティックなワークフローを視覚的に構築できるプラットフォームです。コードをたくさん書かなくても、処理の流れを組み立てたり、外部ツールやデータとつないだりしながら、実用的なAIアプリを作れるのが大きな特徴です。ひとことでいうと、AIアプリ開発を進めやすくするための土台と考えると分かりやすいでしょう。
Workspace	チームや個人でDifyを使うための作業スペースです。モデルの設定やメンバー管理、アプリの共有などは、このWorkspaceを単位として行います。単なる保存場所ではなく、Difyを使うための“作業の拠点”のようなものだと考えるとイメージしやすいです。
Studio	Difyでアプリやワークフローを作成するための画面や制作環境を指します。ドラッグ&ドロップでノードをつなぎ、AIアプリの流れを組み立てられる場所なので、実際に手を動かして作る中心のエリアだと考えておくとよいです。
App	Dify上で作成するアプリそのものです。 Difyでは、作ったものを単なる設定ファイルとして持つのではなく、公開して使えるアプリとして扱います。あとで出てくるWorkflowやChatflow、Chatbotなどは、このAppの種類だと理解しておくと整理しやすくなります。

モデルや接続の基本用語

Difyは単体ですべてが完結するわけではなく、AIモデルや外部サービスと接続しながら使います。

そのため、「どのモデルを使うのか」「どうやって認証するのか」といった接続まわりの用語も、早い段階で意味を押さえておくのがおすすめです。

用語	意味
LLM	大規模言語モデルのことです。 ChatGPTのように文章を生成したり、質問に答えたり、要約や分類をしたりするAIの中心部分を指します。 Difyは、このLLMをうまく活用してアプリを作るための仕組みを提供していると考えると分かりやすいです。
Model Provider	OpenAIやAnthropic、Googleのように、AIモデルを提供しているサービスや提供元のことです。 DifyではWorkspace単位でModel Providerを設定し、そのモデルを各アプリから利用できるようにします。つまり、Difyが“アプリを組み立てる場所”だとすると、Model Providerは“頭脳を提供する相手”です。
API	サービス同士が機能やデータをやり取りするための仕組みです。Difyでは、外部のモデルやツールとつなぐときにもAPIの考え方が出てきますし、逆に自分が作ったDifyアプリをAPIとして公開して使うこともできます。初心者のうちは、“別のサービスとやり取りするための窓口”くらいの理解で十分です。
APIキー	APIを使うときに必要になる認証情報です。 DifyのWorkspaceでModel Providerを設定するときも、OpenAIなどのAPIキーを入力して接続する場面がよくあります。ひとことでいえば、外部サービスを安全に利用するための“利用者確認用の鍵”です。

利用形態に関わる用語

Difyは、どこで使うか、どのように運用するかによっても見え方が少し変わります。

ここでは、初心者の方が最初に迷いやすい利用形態まわりの言葉を整理しておきます。

用語	意味
Dify Cloud	Difyが用意しているクラウド環境上で利用する形です。自分でサーバーを立てたり保守したりしなくても始めやすいため、まず試したい人や、早く触ってみたい人に向いています。最初の学習段階では、こちらから入るほうが理解しやすいことも多いです。
セルフホスト	自分のサーバーやローカル環境にDifyを構築して運用する形です。クラウド版より設定や管理の手間は増えますが、環境を自分でコントロールしやすいのが特徴です。社内利用や検証環境の都合で、セルフホストを選ぶケースもあります。
環境構築	Difyを実際に使い始めるための準備全体を指す言葉です。クラウド版ならアカウント作成やモデル接続、セルフホストならサーバー準備や起動設定などがここに含まれます。初心者にとっては少しハードルが高く見える言葉ですが、実際には“使い始めるための初期設定”と考えれば十分です。

アプリタイプと画面でよく見る用語

Difyでは、アプリを作り始めるときにまず「どの種類のアプリにするか」を選びます。

ここで出てくる用語を先に整理しておくと、あとからWorkflowの設計画面を見たときや、Chatflowの設定を触ったときにも迷いにくくなります。

この章では、アプリの種類そのものを表す言葉と、作成画面や公開画面でよく見かける基本用語を順番に確認していきます。

Difyのアプリ種類に関わる用語

Difyで作れるアプリの種類に関する言葉を見ていきます。

Dify公式では、主なアプリタイプとしてWorkflowとChatflowが案内されており、それに加えてChatbot、Agent、Text Generatorといった、よりシンプルなアプリタイプも用意されています。

用語	意味
Workflow	単発の処理を順番に進めるのが得意なアプリタイプです。たとえば、入力された文章を要約する、分類する、複数ステップで整形するといった、一回ごとに完結する処理に向いています。 Dify公式でも、Workflowは single-turn tasks を扱うアプリとして説明されており、Dify内の他のアプリタイプの土台にもなっています。
Chatflow	会話の各ターンごとに動く、会話型のアプリタイプです。 Workflowの機能を持ちながら、会話ごとの変数を持てたり、LLMノードでメモリを使えたり、途中でテキストや画像、ファイルを返したりできるのが特徴です。ひとことでいうと、Workflowが処理中心なのに対して、Chatflowは会話中心の設計に向いています。
Chatbot	チャット形式でやり取りするシンプルなアプリタイプです。現在のDifyでは、WorkflowやChatflowの利用が推奨されていますが、Chatbotも基本的な会話アプリとして用意されています。より細かくフローを組む前に、まずチャット形式のAIを試したいときにイメージしやすい種類です。
Agent	AIが必要に応じてツールを呼び出しながら応答することを意識したアプリタイプです。こちらもWorkflowやChatflowよりはシンプルな入り口として用意されており、複雑なフローを自分で組む前に、エージェント的な振る舞いを扱いやすい形で試せます。
Text Generator	文章生成に特化したシンプルなアプリタイプです。記事文の下書き、要約、翻訳のように、入力を受けてテキストを返す用途と相性がよく、会話の履歴管理よりも、一回の生成結果を重視したいときに使いやすい種類です。

アプリの入口で出てくる用語

アプリを作るときの開始地点や、出力の終わり方に関わる用語を整理します。

これらはキャンバス上で直接目にすることが多く、意味が分かるだけで画面の見え方がかなり変わります。

用語	意味
Start	処理の始まりを表す入口のノードです。 Difyでは、特にWorkflowでこの開始方法が重要で、どのようにアプリが動き始めるかをここで決めます。スタート地点の役割だと考えると分かりやすいでしょう。
User Input	ユーザーの入力やAPI呼び出しによってアプリを開始する方式です。フォームのように情報を受け取ってから処理を始めるイメージで、通常の利用画面やAPI経由で使うアプリでは、この形が入口になることが多いです。 Workflowだけでなく、Chatflowでも入力変数の受け取り口として重要な考え方です。
Trigger	スケジュール実行や第三者サービスのイベントをきっかけに、自動でアプリを動かす開始方式です。人が毎回ボタンを押して始めるのではなく、条件がそろったときに自動実行するイメージです。なお、公式ではChatflowはTriggerでは開始できず、この点もWorkflowとの大きな違いになっています。
End	Workflowで処理の終点になるノードです。最終的にどの結果を返すのかを決める場所で、処理全体の出口にあたります。あとで出てくるChatflowの「Answer」と似ていますが、WorkflowではEnd、ChatflowではAnswerという使い分けになります。
Answer	Chatflowでユーザーに見せる返答内容を定義するノードです。テキストだけでなく、変数を差し込んだり、画像やファイルを交えたりしながら、会話の途中で返答を出せるのが特徴です。公式でも、AnswerはChatflow専用で、WorkflowではEndノードを使うと整理されています。

会話型アプリで知っておきたい用語

Chatflowやチャット向けの公開画面を使うと、単なる「入力して返す」以上の機能がいくつも出てきます。

ここでは、会話の自然さや使いやすさに関わる用語をまとめて押さえておきましょう。

用語	意味
会話ターン	ユーザーの発言とAIの応答をひとまとまりとして数える考え方です。 Chatflowは会話のターンごとに動くアプリとして説明されており、単発処理のWorkflowとはここが大きく異なります。会話が1往復進むたびに処理が走る、と考えるとイメージしやすいです。
メモリ	会話の流れを踏まえて次の返答に反映するための仕組みです。 Dify公式では、ChatflowではLLMノードなどでメモリを有効にでき、過去のやり取りを後続の応答に含められると説明されています。会話の文脈を覚えておく機能、と考えると分かりやすいでしょう。
会話開始メッセージ	チャットを始めたときにAI側から先に表示される案内やあいさつです。公式では Conversation Opener として案内されており、何を質問すればよいか分からないユーザーの助けになります。最初の空白を埋めてくれる導入メッセージだと思うと自然です。
Follow-up	AIの返答のあとに表示される次の質問候補です。公式のChat Web Appsでは、各応答のあとに文脈に合った次の質問候補が自動生成される仕組みとして説明されています。ユーザーが次に何を聞けばよいか迷いにくくなるため、会話を続けやすくする機能です。

ノード・処理の流れに関わる用語

DifyでWorkflowやChatflowを作り始めると、画面の上にはさまざまな「ノード」が並びます。

最初はどれも似たように見えますが、それぞれ役割が少しずつ違っていて、処理の流れを組み立てるうえで大切な意味を持っています。

この章では、ノードそのものの考え方から、よく使う基本ノード、条件分岐、繰り返し処理、補助ノードまで、実際の制作画面をイメージしながら整理していきます。

ノード全体を理解するための用語

個別のノードの名前に入る前に、処理の流れ全体をどう見るのかを押さえておきましょう。

ここが分かると、Difyの編集画面を見たときに「今どこで何をしているのか」がかなり読み取りやすくなります。

用語	意味
ノード	ワークフローの中のひとつひとつの処理ブロックのことです。たとえば、文章を生成する、条件で分岐する、外部APIに問い合わせる、といった作業をそれぞれ別のノードとして配置します。 Difyでは、このノードをつないでいくことで処理全体を組み立てていきます。
接続	ノード同士を線でつないで、どの順番で処理を進めるかを示す考え方です。前のノードの結果を次のノードに渡すことで、単発の処理ではなく、一連の流れとしてアプリを動かせるようになります。 Difyのワークフローは、この接続の関係を見るだけでもだいたいの設計意図が読み取れます。
入力	ノードが受け取るデータのことです。 Startノードではユーザー入力やアップロードファイルなどの初期情報を受け取り、各ノードはその情報や前段の結果を材料にして処理を行います。何を入力として受け取るのかを意識すると、ノードの使い分けがしやすくなります。
出力	ノードが処理した結果として次のノードに渡すデータです。たとえばCodeノードでは、処理結果を出力変数として返し、Answerノードでは前段の変数を組み合わせて最終的な返答を作れます。 Difyでは、この入出力のつながりを意識することが、フロー設計の基本になります。
フロー	こうしたノード、接続、入出力をまとめた処理全体の流れを指す言葉です。どの順番で何を行い、どこで分岐し、どの結果を返すのかという設計そのものを表します。 Difyはこのフローを視覚的に組み立てやすいことが大きな特徴です。
分岐	条件に応じて処理ルートを切り替える考え方です。たとえば、質問の種類によって別のナレッジを検索したり、入力内容によって返答方法を変えたりするときに使います。あとで出てくるIf-Elseノードは、この分岐を実現する代表的なノードです。

基本ノードの用語

実際によく使う基本ノードを見ていきます。

Difyのワークフローでは多機能なノードもありますが、まずは「生成する」「整える」「返す」という基本の役割を持つノードから理解すると全体像がつかみやすくなります。

用語	意味
LLMノード	Difyの中核になるノードです。公式では、テキスト、画像、文書を処理し、構造化出力やコンテキスト管理、マルチモーダル入力にも対応するノードとして説明されています。要するに、実際にAIへ考えさせたり文章を書かせたりする中心の場所です。
Answer	ユーザーに返す内容を組み立てるノードです。固定文だけでなく、前のノードで作られた変数を差し込んで、状況に応じた返答を作れます。 Chatflowでは特に重要なノードで、会話の途中や最後に、ユーザーへ何を見せるかをここで決めます。
Template	複数の変数をまとめたり、指定した形に整えたりするためのノードです。 DifyのTemplateノードはJinja2ベースで動き、文章やデータの形式をきれいにそろえて、下流のノードに渡せます。 LLMに渡す前の整形や、検索結果を読みやすくまとめるときに便利です。
Code	標準ノードだけでは扱いにくい処理を、PythonやJavaScriptで補うためのノードです。公式でも、JSON変換、数値計算、文字列処理などに向いていると案内されています。ノーコードだけでは少し足りない場面で、ピンポイントに柔軟さを足せるノードだと考えると分かりやすいです。
出力変数	各ノードが処理した結果を名前付きで保持し、次のノードから参照できるようにしたものです。たとえばCodeノードでは、返した辞書のキーが出力変数になり、AnswerノードやTemplateノードからその値を利用できます。 Difyでは、ノード単体よりも、この出力変数がどうつながっていくかを見ると設計が理解しやすくなります。

条件分岐と制御に関わる用語

実際のアプリでは、すべての入力に対して同じ処理を返すとは限りません。

質問の種類やユーザーの状況に応じて、処理のルートを変えたい場面がよくあります。

ここでは、そのために使う制御系の用語を見ていきます。

用語	意味
If-Else	条件に応じて実行するルートを切り替えるノードです。公式では、定義した条件に基づいて実行経路を振り分ける意思決定ロジックのノードとして説明されています。入力内容が一定条件を満たすならAへ、そうでなければBへ、という形でフローを分岐させたいときに使います。
ELIF	If-Elseの途中で追加する“それ以外で、この条件なら”にあたる考え方です。たとえば、最初の条件には当てはまらないが、二つ目の条件には当てはまる場合に使います。分岐が二択では足りないときに必要になる考え方で、複数パターンを丁寧に切り分けたいときに役立ちます。 If-Elseノードの設計を理解していれば、この考え方も自然に理解できます。
ELSE	どの条件にも当てはまらなかった場合の逃げ道になるルートです。現実のユーザー入力は想定外の内容も多いため、最後の受け皿を作っておくことで、処理が不自然に止まるのを防ぎやすくなります。分岐を作るときは、条件に合わない場合の扱いまで考えておくことが大切です。
Question Classifier	ユーザーの質問を意味ベースで分類し、適切なルートへ振り分けるノードです。複雑な条件式を自分で細かく書かなくても、カテゴリを定義しておけば、LLMが内容を見て近い分類に振り分けてくれます。問い合わせの種類ごとに別のフローへ流したいときなどに便利です。
Parameter Extractor	自然文から必要な項目を取り出して、構造化された形に整えるノードです。公式では、ツール呼び出しやHTTP Requestの前処理として、自然文をJSONのような扱いやすいパラメータに変換する用途が案内されています。ユーザーが自由文で入力した内容を、そのまま外部連携に渡したいときに重宝します。

繰り返し処理や外部通信に関わる用語

ワークフローを少し本格的に組み始めると、同じ処理を複数回まわしたり、外部サービスと通信したりする場面が増えてきます。

ここでは、初心者の方が「ここから少し難しく感じる」と思いやすい用語を、できるだけかみ砕いて整理します。

用語	意味
Iteration	配列データの各要素に対して、同じ処理を順番に、あるいは並列で適用するノードです。公式でも、配列に対して同一のワークフロー手順を適用するためのノードとして説明されています。たとえば、複数の見出しごとに本文案を作る、複数の商品データを順番に整形する、といった場面で使います。
Loop	広い意味では繰り返し処理の考え方を指す言葉です。 Difyで実際に配列を対象にした繰り返しを組むときはIterationノードが代表的ですが、初心者の方は“同じ処理を何度かまわす発想”をLoopとして覚えておくと整理しやすいです。特に、ひとつの入力を一回で処理するのではなく、まとまったデータを順に処理したいときに意識する用語です。
HTTP Request	外部APIやWebサービスに直接リクエストを送るノードです。 URL、ヘッダー、クエリパラメータ、認証情報、リクエストボディなどを設定でき、Webhook送信や外部データ取得にも使えます。 Difyの外側にあるサービスとやり取りしたいときの基本的な橋渡し役です。
レスポンス	HTTP Requestなどで外部サービスから返ってくる結果のことです。取得したJSONやステータス、返答本文などを、その後のTemplateノードやCodeノード、Answerノードへつなげて利用します。外部通信では、送る内容だけでなく、返ってきた結果をどう扱うかまで見ておくことが大切です。
配列処理	複数の要素がまとまったデータをひとつずつ扱う考え方です。 IterationノードはArray型の入力を前提としているため、前段でParameter Extractorなどを使って配列形式に整える場面もあります。初心者のうちは少し難しく感じますが、「データがひとつではなく複数あるときの扱い方」と考えると分かりやすいです。

補助ノードとして知っておきたい用語

毎回必ず使うわけではないものの、実務的なフローを作ろうとすると出番が増える補助ノードを見ておきます。

こうしたノードを知っておくと、「標準の流れだけでは少し足りない」と感じたときに、どこを補えばよいかが分かりやすくなります。

用語	意味
Variable Assigner	会話変数に値を書き込むためのノードです。公式では、Workflow変数は一回の実行で消えるのに対し、Conversation Variablesは同じチャットセッションの中で保持されると説明されています。つまり、一時的な処理結果ではなく、次の会話にも残したい情報を保存したいときに使うノードです。
Document Extractor	アップロードされたPDFやDOCXなどの文書ファイルからテキストを取り出すノードです。 LLMはそのままでは文書形式を読めないため、このノードが橋渡し役になります。ファイルをアップロードして要約したり、内容を質問回答に使ったりしたいときに欠かせないノードです。
File Upload	ユーザーがチャット画面やアプリ画面からファイルを渡せる機能です。公式の追加機能では、アップロードされたファイルは `sys.files` に入り、ファイルの種類に応じて処理を分ける必要があると説明されています。 Document ExtractorやLLMノードと組み合わせることで、文書や画像を扱うアプリが作りやすくなります。

変数・入力・会話管理に関わる用語

Difyでフローを作っていると、ほぼ必ず意識することになるのが「変数」です。

ノード同士が情報を受け渡したり、ユーザーの入力内容をあとで参照したり、会話の途中で覚えておきたい情報を保存したりするときに、変数の考え方が土台になります。

この章では、変数の基本から、Dify特有のシステム変数や会話変数まで、初心者の方が混乱しやすいポイントを順番に整理していきます。

まず押さえる変数の基本用語

どの種類の変数にも共通する基本的な考え方から見ていきます。

ここが分かると、Difyの画面で変数を選ぶ場面や、ノード同士のつながりを読む場面で迷いにくくなります。

用語	意味
変数	Difyの中でデータを一時的に入れておく箱のようなものです。ユーザーが入力した内容、LLMが生成した文章、外部APIの返り値、ファイル情報などを保持し、別のノードへ渡す役割があります。 Difyの公式ドキュメントでも、変数はノード間で動的な内容を格納・送信・参照するためのデータコンテナとして説明されています。
入力変数	ノードが受け取る側の変数です。たとえばStartノードで受け取ったユーザー入力や、前のノードが出した結果を、次のノードが入力として使う場面で登場します。どのデータを受け取って処理するのかを明確にするための入口だと考えると分かりやすいです。
出力変数	ノードが処理した結果を名前付きで返す変数です。 LLMノード、Codeノード、HTTP Requestノードなどは、それぞれ処理結果を出力変数として持ち、その値を後続のノードから参照できます。フロー設計では、この出力変数が次のノードの入力につながっていくことで全体の処理が成り立っています。
変数参照	すでに存在している変数の値を別のノードで呼び出して使うことです。 Difyでは、入力欄のプルダウンから選んだり、テキスト入力中にスラッシュを入力して候補から選んだりして変数を差し込めます。つまり、前のノードの結果を使い回すための仕組みが変数参照です。
データ型	変数の中にどんな種類の値が入るかを表す考え方です。 Difyの変数では、文字列、数値、オブジェクト、真偽値、配列などが使われます。特に配列やオブジェクトは、IterationやParameter Extractor、HTTP Requestなどと組み合わせる場面でよく出てくるので、文字列だけでなく複数の型があることを知っておくと理解しやすくなります。

Difyで特に重要な変数の種類

Difyでよく出てくる「変数の種類」を整理します。

初心者の方が混同しやすいのは、普通のワークフロー内で一時的に使う変数と、会話の中で持ち続ける変数、そして設定情報として固定しておく変数の違いです。

用語	意味
システム変数	Difyがあらかじめ用意している、アプリ内で共通に使える変数です。すべて `sys.` で始まり、ユーザーIDやアプリID、会話回数、アップロードファイル情報など、アプリの動作状況や利用状況に関わる値を持っています。自分で自由に名前を付けて作る変数とは違い、Dify側が提供している“最初から使える情報”だと考えると分かりやすいです。
会話変数	Chatflowで使える、会話ごとに保持される変数です。通常のワークフロー変数は実行が終わるとリセットされますが、会話変数は同じチャットセッション内で値を持ち続けられます。そのため、ユーザーの好み、途中経過、メモのような情報を保存して、次のターンでも参照したいときに便利です。
環境変数	アプリ内で使う設定値や秘密情報を保持するための変数です。 APIキーや接続先の設定値のように、フローのたびに変わるものではなく、あらかじめ固定しておきたい値を管理するのに向いています。公式では、環境変数は秘密情報とアプリ本体を分離し、DSL共有時にパスワードやキーを露出させないためにも役立つと説明されています。
変数スコープ	その変数がどこまで参照できるか、どの範囲で有効かを表す考え方です。たとえば、一回の実行中だけ使えるワークフロー変数と、同じ会話の中で残り続ける会話変数では、使える範囲が異なります。この違いを理解しておくと、「前のターンの情報が残らない」「別のノードから見えない」といった混乱を減らせます。
ワークフロー変数	一回の実行の中で使われる通常の変数で、実行が終わるとリセットされます。会話変数との違いは、値が次のターンまで残るかどうかにあるので、Difyではこの2つをセットで理解するのが重要です。

初心者が見かけやすい具体的な変数

抽象的な説明だけだとイメージしにくいので、ここでは実際にDifyでよく見かける具体的な変数を確認します。

特に sys. で始まるシステム変数は、画面上で見かけても意味が分からず戸惑いやすいので、先に役割をつかんでおくと安心です。

用語	意味
sys.user_id	アプリを使っているユーザーを識別するための一意のIDです。公式では、各アプリケーションユーザーに自動的に割り当てられる識別子として説明されています。ユーザーごとの利用状況を分けたり、会話履歴や設定をひも付けたりするときに重要になる変数です。
sys.dialogue_count	会話が何ターン目まで進んでいるかを表すシステム変数です。公式では、たとえばLLMが何ターン目の会話かを見ながら会話履歴をレビューし、分析に使える例が示されています。会話の回数に応じて処理を変えたいときや、一定回数ごとに案内を出したいときに役立ちます。
sys.files	ユーザーがアップロードしたファイルの情報を保持するシステム変数です。 WorkflowやChatflowでファイルアップロードを使う場合、この変数を通じてファイル情報を後続ノードに渡します。 Document ExtractorやLLMノードと組み合わせる場面でよく登場するので、ファイル系のアプリを作るときは特に重要です。
userinput.query	ユーザーが入力したテキストを表す代表的な入力変数です。 StartノードやUser Inputで受け取った質問文を、LLMノードやParameter Extractorへ渡すときによく使われます。初心者の方にとっては、まず“ユーザーが入力した本文そのもの”を指す変数として覚えると扱いやすいです。

会話変数を扱うときに知っておきたい用語

Difyの変数まわりで特に便利なのが、会話の中で値を保存し続ける仕組みです。

ここを理解しておくと、単発のQ&Aではなく、前のやり取りを踏まえた少し賢いアプリを作りやすくなります。

用語	意味
Variable Assigner	会話変数へ値を書き込むためのノードです。公式では、Chatflowの中で会話変数を更新し、通常のワークフロー変数では残らない情報を会話セッション内に保持するためのノードとして説明されています。つまり、会話中に覚えておきたい情報を保存するための書き込み口です。
永続化	会話変数を理解するときによく出てきます。ここでは、単なる一時保存ではなく、同じチャットセッションの次のターンでも値を使い続けられることを指します。たとえば、ユーザーの好みや途中の選択結果を残しておくと、会話の流れに沿った自然な返答を作りやすくなります。
セッション	ひとつながりの会話の単位です。会話変数は、この同じセッションの中で持続するのが特徴で、別のユーザーや別の会話にはそのまま引き継がれません。会話変数が“どこまで残るのか”を理解するうえで、このセッションという考え方は大切です。

ナレッジ・RAGに関わる用語

Difyで「社内資料をもとに答えるAI」や「マニュアルを参照して返答するチャット」を作ろうとすると、必ず出てくるのがナレッジとRAGに関する用語です。

ここは最初少し難しく感じやすいですが、流れとしてはそれほど複雑ではありません。

文書を取り込み、検索しやすい形に整え、質問に関連する部分だけを取り出して、LLMの回答に活かすという考え方です。

この章では、その流れに沿って、初心者の方が最初に知っておきたい言葉を整理していきます。

RAGの基本を理解する用語

ナレッジ活用の全体像をつかむための基本用語から見ていきましょう。

ここが分かると、DifyでKnowledge Retrievalノードを使う意味や、なぜ文書をそのままLLMに渡さず検索を挟むのかが理解しやすくなります。

用語	意味
RAG	Retrieval-Augmented Generationの略で、必要な情報を検索してから、その内容をもとにLLMに回答を生成させる考え方です。 DifyではKnowledge Retrievalノードを使って関連情報を取り出し、その結果をLLMノードのコンテキストとして渡す流れが基本になります。つまり、最初から全部をAIに覚えさせるのではなく、その都度必要な情報を探してから答えさせる仕組みです。
ナレッジ	AIアプリに参照させたい知識データ全体を指す言葉です。社内文書、FAQ、マニュアル、製品情報、議事録など、回答の根拠として使いたい情報をまとめて管理する対象だと考えると分かりやすいです。 Difyでは、この知識をKnowledgeとして登録し、アプリ側から検索して使えるようにします。
ナレッジベース	こうした知識データを検索できる形で保存・管理する場所です。 DifyのKnowledge Retrievalノードでは、まず「どのナレッジベースを検索するか」を指定してから検索を実行します。複数のナレッジベースを同時に検索できるので、用途ごとに知識を分けて管理することもできます。
Knowledge Retrieval	Difyでナレッジベースを検索するための専用ノードです。公式でも、ChatflowやWorkflowに既存のナレッジベースを統合し、クエリに関連する情報を探して、下流のLLMノードで使えるコンテキストとして出力するノードと説明されています。 RAGをDifyで実装するときの中心になるノード、と考えておくと自然です。
コンテキスト	LLMが回答を作るときに参考にする前提情報のことです。 Knowledge Retrievalノードで見つかった内容は、そのまま `result` 変数として出力され、LLMノードのContext欄に渡して回答生成に使えます。ユーザーの質問だけでなく、関連文書の抜粋も一緒に見せて答えさせることで、より根拠のある返答を作りやすくなります。

文書処理でよく出る用語

RAGは、文書をそのまま丸ごと検索しているわけではありません。

実際には、文書を読み取り、扱いやすい単位に分け、検索しやすい形に整える工程があります。

ここで出てくる用語を押さえると、「なぜ検索精度が変わるのか」も見えやすくなります。

用語	意味
チャンク	文書を小さく分けたひとかたまりのことです。 Knowledge Retrievalノードの出力も、取得された文書全体ではなく、関連すると判断された文書チャンクの配列として返されます。長い文書をそのまま扱うのではなく、意味のまとまりごとに分けることで、必要な箇所だけを見つけやすくしています。
チャンク分割	文書を複数の小さな単位に切り分ける処理です。 Difyのナレッジパイプラインでは、文書取り込み後のデータ処理の中にChunkerがあり、構造化された内容を管理しやすいセグメントへ分割します。ここがうまくいくと、検索で必要な部分が見つかりやすくなり、逆に分割が粗すぎたり細かすぎたりすると精度に影響が出やすくなります。
Embedding	テキストや画像の意味をベクトルとして表現するための仕組みです。 Knowledge Retrievalでは、単なる文字列一致だけでなく意味の近さでも検索できるようにするため、Embeddingモデルが使われます。初心者のうちは、“文章の意味を検索しやすい数字の形に変換する仕組み”くらいに捉えると十分です。
インデックス	検索を速く正確に行うために、文書やチャンクを整理しておく仕組みです。ナレッジパイプラインの流れでも、データソースから取り込んだ内容を処理し、検索できる知識ベースとして使えるように整える工程が示されています。裏側では、この整理された状態があるからこそ、質問に対して関連情報を素早く取り出せます。
検索クエリ	ナレッジベースに対して何を探すかを伝えるための検索文です。 Knowledge Retrievalノードでは、どのテキスト変数をクエリとして使うかを指定でき、Chatflowなら `userinput.query` を使うのが代表例です。つまり、ユーザーの質問そのものが検索クエリになって、関連文書を探しにいく形です。

検索精度に関わる用語

RAGでは、ただ検索するだけでなく、「どれくらい関連性の高い結果を返すか」がとても重要です。

DifyのKnowledge Retrievalノードには、その精度を調整するための設定がいくつも用意されています。

ここを知っておくと、検索結果がずれているときにどこを見直せばよいかが分かりやすくなります。

用語	意味
Vector Search	意味の近さにもとづいて検索する考え方です。単語が完全に一致していなくても、意味的に近い内容を探しやすいのが特徴で、RAGでは非常によく使われます。たとえば、表現が少し違っていても、内容として近い説明文を拾える可能性があります。
Full-text Search	キーワードの一致を重視して検索する考え方です。こちらは、意味の近さよりも、実際にその単語が文書内に含まれているかを重視するので、固有名詞や型番、社内独自の用語などを探したいときに役立ちます。意味検索とは得意分野が少し違うため、両方の特徴を知っておくと使い分けしやすくなります。
Hybrid Search	意味の近さとキーワード一致の両方を活かして検索する考え方です。 Difyのノード設定でも、意味的な関連性とキーワード一致のバランスを後段で調整できるようになっており、実務ではこの中間的な考え方が役立つ場面が多くあります。意味だけに寄せすぎず、単語一致も取りこぼしたくないときに意識したい用語です。
Rerank	いったん取得した検索結果を、クエリとの関連性に応じて並べ替え直す処理です。 Knowledge Retrievalノードでは、Rerank Modelを使って結果を再評価し、より適切な順番に整えられます。検索で拾えた候補の中から、本当に上に出したいものを選び直す工程だと考えると分かりやすいです。
Weighted Score	再ランキング時に、意味の近さとキーワード一致のどちらを重視するかの比重を表す設定です。公式では、意味重視を高めると semantic relevance を優先し、キーワード側を高めると exact matches を優先すると説明されています。検索精度の調整では地味ですがかなり重要で、どんな質問を想定するかによって向き不向きが変わります。

結果の絞り込みに関わる用語

RAGでは、見つけた結果をそのまま全部LLMに渡せばよいわけではありません。

関係の薄い情報が混ざると回答がぶれやすくなるため、どこまで絞り込むかも大切です。

ここでは、その調整に関わる用語を見ていきます。

用語	意味
Top K	最終的に返す検索結果の上限件数を表す設定です。 Knowledge Retrievalノードでは、再ランキング後に上位何件まで返すかをここで決めます。大きくしすぎると関係の薄い情報まで入りやすくなり、小さすぎると必要な情報を取りこぼすことがあるので、ちょうどよい件数を探ることが大切です。
Score Threshold	どの程度関連性が高い結果だけを返すかを決める下限値です。公式では、この値より低いスコアの結果は除外されると説明されており、高くすると厳しめに絞り込み、低くすると広めに拾う方向になります。検索結果がノイズだらけのときに、最初に見直したい設定のひとつです。
Metadata	文書そのものの本文とは別に持たせる付加情報です。たとえば、部署名、作成日、カテゴリ、製品名などをメタデータとして付けておくことで、文書を条件付きで絞り込みやすくなります。本文検索だけでは探しにくい条件を扱いたいときに、とても便利な考え方です。
Metadata Filtering	メタデータの条件を使って、検索対象を最初から絞る方法です。 Knowledge Retrievalノードでは、指定したメタデータ条件に一致する文書だけを検索対象にできるため、大きくて多様なナレッジベースでも、より狙った文書に絞って検索しやすくなります。社内資料が多いほど、この考え方の重要性が上がります。
Citation	回答の根拠として、どの文書やどの部分を参照したかを示す考え方です。 Difyのナレッジ関連機能では、取得した結果のタイトルやメタデータなどを保持して後段で利用できるため、回答に根拠を持たせたい場面と相性がよいです。初心者のうちは、「AIがどこを見て答えたのかを示すための考え方」と理解しておくと十分です。

ツール・外部連携に関わる用語

Difyの魅力のひとつは、文章を生成するだけで終わらず、外部サービスやAPIとつないで実用的な処理まで広げられることです。

たとえば、Web検索の結果を使ったり、社内システムへ問い合わせたり、別のワークフローを部品として再利用したりできます。

この章では、Difyで外部機能を使うときによく出てくる「Tools」まわりの用語を整理しながら、HTTP Requestとの違いも含めて分かりやすく見ていきます。

Toolsの基本用語

まずは、Difyにおける「ツール」とは何かを押さえておきましょう。

ここが分かると、ノード一覧やワークスペース設定画面で見かける言葉がかなり整理しやすくなります。

用語	意味
Tools	Difyアプリの中から呼び出して使える外部機能の総称です。公式のToolsノードでは、認証済みのツールやカスタムツール、MCPサーバー経由のツール、公開したワークフローのツールなどを扱えると案内されています。ひとことで言えば、AIに“外で何かをさせる”ための道具です。
Tool Calling	LLMやAgentが必要に応じてツールを呼び出し、その結果をもとに次の処理や回答を行う考え方です。 DifyのAgentノードでは、利用可能なツール一覧を設定し、エージェント戦略に沿ってどのツールを使うかを判断させられます。つまり、AIが文章を返すだけでなく、状況に応じて機能を実行できるようにする仕組みです。
Built-in Tools	Dify側であらかじめ用意されている組み込みツールです。公式でも、まずは認証してすぐ使えるツール群として案内されており、ゼロから外部連携を作らなくても、必要な機能を比較的すぐ試せます。初心者の方にとっては、外部連携の最初の入口になりやすい種類です。
Custom Tools	自分で追加・取り込みして使うツールです。公式では、Built-in Toolsで足りない場合にカスタムツールをインポートして使えると説明されています。既存の組み込みツールにないAPIや社内向け機能を使いたいときに登場する用語で、外部連携を本格化させるとよく目にするようになります。

再利用や拡張に関わる用語

Difyのツール機能は、単に外部APIを叩くだけではありません。

作ったワークフローを再利用したり、MCPの仕組みを使って外部ツール群をまとめて接続したりと、少し大きな設計にも広げられます。

ここでは、その発展的な用語を見ていきます。

用語	意味
Workflow Tools	Difyで作成したワークフローをツールとして公開し、別のアプリや別のフローから呼び出せるようにしたものです。公式でも、ワークフローをツールとして公開できることが案内されています。ひとつの処理を部品化して使い回せるので、同じロジックを何度も作り直さずに済むのが大きな利点です。
MCP Tools	MCPサーバーから提供されるツールをDifyで使う仕組みです。公式では、ワークスペースの Tools → MCP から外部MCPサーバーを管理し、成長中のMCPエコシステムのツールをDifyアプリに接続できると説明されています。つまり、Difyの外にあるツール群を、標準化された形でまとめて利用しやすくする考え方です。
MCP	Model Context Protocol の略で、LLMアプリが外部ツールやデータソースとやり取りするための共通的な接続方式として広がっている考え方です。 DifyでもMCPサーバーの管理機能が用意されており、組み込みツールだけでは足りない機能を外から取り込みやすくしています。初心者のうちは、“外部ツールをまとめてつなぎやすくする仕組み”と理解しておくと十分です。
Plugin	Difyの機能拡張を支えるモジュラーな部品です。日本語ドキュメントでは、モデルプロバイダー、外部API、カスタムツールなどに接続する方法としてプラグインが説明されており、ワークスペース単位でインストールして利用できます。学習中は「Tool」と「Plugin」が近い意味で見えることがありますが、Pluginはワークスペース全体の拡張単位、Toolはアプリから呼び出す実行機能、と捉えると整理しやすいです。

外部API接続で出てくる用語

ツールや外部連携を使うと、認証やAPI仕様に関する用語も増えてきます。

最初は少し専門的に見えますが、意味を一度つかんでおくと設定画面の理解がかなり楽になります。

用語	意味
Authentication	外部サービスを安全に利用するための認証設定です。公式のTools管理では、認証情報を管理できることが明記されており、Built-in ToolsやCustom Toolsを使う前にAPIキーなどを設定する場面があります。要するに、そのツールを使ってよい利用者かどうかを確認するための仕組みです。
OAuth	外部サービスの認可方式のひとつです。細かな仕組みまで最初から理解しなくても構いませんが、Google系サービスや一部のSaaS連携では、単純なAPIキーではなくOAuth認可が使われることがあります。初心者の段階では、“サービスに安全に接続するための少し本格的な認証方法”くらいに捉えておくと十分です。これは一般的な技術用語としての説明であり、Difyでも認証方式の理解が外部連携設定で役立ちます。
OpenAPI	APIの仕様を機械的に表せる形式です。 Difyの周辺ドキュメントでは、カスタムツールやAPI連携の理解に関係する用語として重要で、外部APIの入出力構造を明確にするのに役立ちます。難しく見えますが、要するに「このAPIはどんな入力を受け取り、どんな結果を返すのか」を整理した設計書のようなものです。
Swagger	OpenAPI仕様を扱うときによく一緒に出てくる名前です。初心者向けには、API仕様を見たり試したりしやすくするための周辺ツールや表現として覚えておけば十分です。 Difyでカスタムツールや外部API仕様を理解する場面でも、関連語として目にすることがあります。これは一般的な技術用語としての補足です。
エンドポイント	APIへリクエストを送る具体的なURLのことです。 HTTP Requestノードでも外部サービスへ接続するときはURLを設定しますし、DifyのWebhook Triggerでは一意のWebhook URLが生成されると公式で説明されています。外部連携では、「どこに送るか」を示す基本の言葉だと考えると分かりやすいです。

公開・運用・改善に関わる用語

Difyでは、アプリを作って終わりではなく、それを実際に公開し、必要に応じて更新し、利用状況を見ながら改善していく流れがとても大切です。

ここでは、アプリをユーザーに届けるときに出てくる用語と、公開後の管理・運用で知っておきたい言葉を整理していきます。

制作中は意味が分かりにくかった用語も、この章でまとめて押さえておくと全体像がかなり見えやすくなります。

公開まわりの基本用語

作ったアプリを実際に使ってもらうための公開まわりの用語から見ていきます。

Difyでは、公開方法がいくつか用意されており、同じアプリをWebアプリとして使うことも、APIとして組み込むこともできます。

用語	意味
Publish	現在のアプリ設定を実際に利用できる状態へ反映する操作です。 Difyの公開ドキュメントでは、アプリを公開すると最新の設定を使ったWeb AppとAPIエンドポイントが利用可能になり、埋め込み表示やMCPサーバー側にもその変更が反映されると説明されています。ひとことでいうと、作成中の内容を“外に出す”ための反映操作です。
Web App	Difyが自動生成する共有用のアプリ画面です。公開後はURLをそのまま配布でき、特別な実装をしなくても、ブラウザからすぐ使ってもらえます。公式でも、どのアプリも最も手早く共有する方法はWeb Appだと案内されています。
API Access	作成したDifyアプリをAPIとして利用するための入口です。アプリの左サイドバーからAPI Accessに進むと、認証情報を発行したり、そのアプリ専用のAPIドキュメントを確認したりできます。つまり、Web画面ではなく、自分のサービスやシステムからDifyを呼び出したいときに使う機能です。
埋め込み	公開済みのWeb Appを自分のWebサイトに組み込んで使うことです。 Dify公式では、同じWeb Appをそのまま使いながら、チャットバブル、iframe、カスタム統合といった形で表示方法だけを変えられると説明されています。新しく別のアプリを作るのではなく、既存の公開アプリをサイト内に見せる方法だと考えると分かりやすいです。
エンドポイント	APIリクエストを送る先となるURLのことです。 DifyのAPI公開では、アプリをバックエンドAPIとして利用でき、`chat-messages` や `completion-messages` のようなAPIにアクセスして応答を受け取ります。初心者のうちは、“APIの窓口になるURL”と理解しておけば十分です。

開発中によく見る用語

公開前の調整段階では、ただ作るだけでなく、試しながら直していく作業が続きます。

Difyにはそのためのドラフトやプレビュー、バージョン管理の仕組みが用意されているので、ここで意味を整理しておくと安心です。

用語	意味
Preview	公開前にアプリの動作を確認するための試験的な表示や実行モードです。 Difyのデバッグ機能では、会話型アプリではPreview、WorkflowではRunからデバッグに入り、公開前に挙動を確かめられるようになっています。つまり、ユーザー公開前の確認画面だと考えると分かりやすいです。
Draft	いま作業中の未公開バージョンです。 Version Controlの説明では、Current Draft は作業中の版であり、まだユーザーには公開されていない状態とされています。変更を加えるのはこのドラフト側で、公開後の最新版とは分けて管理されます。
Latest Version	ユーザーが実際に見ている最新の公開版です。 Version Controlでは、公開された版が Latest Version として扱われ、そのあと新しい修正を始めると別のドラフトが作られます。作業中の内容と公開中の内容が分かれていることが、Difyのバージョン管理のポイントです。
Publish Update	ドラフトを新しい公開版として反映する操作です。公式では、Publish → Publish Update を押すと現在のドラフトが新しい Latest Version になり、その後また作業用の新しいドラフトが作られると説明されています。単に保存するのではなく、“公開中の版を入れ替える”操作だと理解すると自然です。
ロールバック	問題が起きたときに以前の版へ戻す考え方です。DifyのVersion Controlでは、古いバージョンをドラフトへ復元し、その内容を再公開できます。画面上の用語としては “Restore a version” が近く、実務上はこれがロールバックにあたります。

管理・共有の用語

アプリを継続的に使っていくと、自分だけでなくチーム内で共有したり、別ワークスペースへ移したりしたくなる場面も出てきます。

ここでは、そうした管理や再利用に関わる用語を見ていきます。

用語	意味
Dify DSL	Difyアプリの構成を持ち運ぶための専用形式です。公式では、DSL は Domain Specific Language の略で、アプリ設定やワークフロー構成、ノード設定などをまとめて共有できる形式として案内されています。アプリそのものの設計図をやり取りするための形式、と考えると分かりやすいです。
YAML	Dify DSLが保存されるときのファイル形式です。 Manage Appsの説明では、DSLファイルはYAML形式でエクスポート・インポートされると案内されています。初心者の方は、難しい記法として捉える必要はなく、“アプリ設定を書き出すためのテキスト形式”くらいの理解で問題ありません。
Version Control	ChatflowやWorkflowの変更履歴を管理する仕組みです。現在のドラフト、公開中の最新版、過去の公開版を分けて保持し、必要に応じて古い版を復元できます。変更を安全に進めたいときや、更新の履歴を残したいときに重要になる機能です。
Export	アプリの設定を外部へ書き出すことです。 DifyではDSL形式でエクスポートでき、別ワークスペースへの移動やバックアップに使えます。ただし、公式ではナレッジベースそのものの中身や一部の秘密情報はそのまま含まれない点にも注意が必要です。
Import	DSLファイルを読み込んでアプリを取り込むことです。公式では、YAML形式のDSLをアップロードすると互換性が確認され、その内容をもとにアプリが作成されると説明されています。既存アプリの再利用や配布を考えるときによく出てくる用語です。

運用で知っておきたい用語

アプリを公開したあとは、実際にどう使われているかを見て、必要に応じて改善していく段階に入ります。

ここでは、公開後の確認や改善に役立つ用語を押さえておきましょう。

用語	意味
ログ	ユーザーとのやり取りやシステムの動作記録です。 DifyのLogs機能では、Web AppやAPI経由の会話、入出力履歴、応答時間、トークン消費、エラーや警告、ユーザーフィードバックなどを確認できます。公開後に問題を見つけたり、改善点を探したりするときの基本になる情報です。
Dashboard	アプリの利用状況をまとめて確認する分析画面です。 Dify公式では、Total Messages、Active Users、Average User Interactions、Token Usage などの指標を時系列で確認できるとされています。細かな会話内容を見るログに対して、全体の傾向を見るのがDashboardだと整理すると分かりやすいです。
モニタリング	公開後のアプリの状態を継続的に確認する考え方です。 DifyではLogsやDashboardを通じて、応答品質、利用量、反応速度、ユーザー行動などを見て改善につなげられます。アプリは公開して終わりではなく、使われ方を見ながら育てていくものだと考えると、この言葉の意味がつかみやすくなります。
アクセス権限	公開したWeb Appを誰が使えるかを制御する考え方です。現在の公式ドキュメントでは、Enterprise向けの Web App Access Control として、特定メンバーのみ、外部認証ユーザー、誰でも利用可といった公開範囲を設定できます。公開URLがあるからといって、必ずしも全員に開放されるわけではない点は初心者の方も知っておくと安心です。

出力品質・安全性に関わる用語

Difyでアプリを作れるようになると、次に気になってくるのが「ちゃんと狙った形式で返ってくるか」「危ない出力を防げるか」という点です。

実際、実務で使うなら、ただ答えが返るだけでは足りません。

回答のぶれを減らしたり、JSONのような扱いやすい形で出したり、不適切な入力や出力に備えたりすることが大切になります。

この章では、出力品質と安全性に関わる基本用語を、初心者の方にも分かりやすい形で整理していきます。

出力を安定させる用語

AIの返答をできるだけ安定させ、意図した形に近づけるための用語から見ていきます。

DifyではLLMノードが構造化出力やコンテキスト管理、マルチモーダル入力に対応しており、単に文章を生成するだけでなく、後続処理しやすい出力を作ることも意識されています。

用語	意味
プロンプト	LLMに対して何をしてほしいかを伝える指示文です。要約、分類、言い換え、文章生成など、同じモデルでもプロンプトの書き方によって結果はかなり変わります。 DifyではLLMノードを通じてモデルに指示を送り、その応答を後続ノードやAnswerノードで活用していきます。
システムプロンプト	AIの役割や口調、守るべきルールを先に固定しておくための指示です。たとえば「丁寧な日本語で答える」「分からないときは推測しない」といった前提を与えることで、出力の方向性を安定させやすくなります。 DifyのLLMノードは、単なる生成だけでなくコンテキスト管理も含めて扱えるため、こうした前提づけが出力品質に大きく関わります。これは公式のLLMノードの機能説明をもとにした実務上の捉え方です。
コンテキスト	LLMが回答を作るときに参照する前提情報です。ユーザーの入力だけでなく、Knowledge Retrievalノードで取ってきた文書の抜粋や、前のノードの出力をコンテキストとして渡すことで、より根拠のある回答を作りやすくなります。公式でもLLMノードはコンテキスト管理をサポートすると案内されています。
Few-shot	望ましい出力例をいくつか先に見せて、モデルに答え方を寄せてもらう考え方です。 Difyのドキュメントで用語として大きく独立しているわけではありませんが、プロンプト設計ではよく使われる基本的な手法です。たとえば「入力例と出力例」を添えておくと、形式や文体のぶれを減らしやすくなります。これは一般的なLLM活用の考え方であり、DifyのLLMノード設計とも相性がよい実践テクニックです。
構造化出力	LLMの返答を決まった形式で返させる考え方です。 DifyのStructured Outputsでは、JSON Schemaを使って予測可能なJSON形式を返せるようにでき、後続のデータ処理や外部API連携がしやすくなります。文章としては自然でも、機械処理では扱いにくい出力を避けたいときに特に重要です。
JSON	構造化出力でよく使われるデータ形式です。 DifyのStructured Outputsでも、JSON Schemaに基づいて出力形式を定義することで、一貫したデータ形式を保ちやすくなると説明されています。初心者のうちは少し難しく見えるかもしれませんが、“項目ごとに整理された機械向けの返答形式”と考えると分かりやすいです。

安全設計に関わる用語

次に、安全性の観点でよく出てくる用語を見ていきます。

AIアプリは便利な反面、意図しない返答や不適切な入力への対応も考えておく必要があります。

DifyではChatflow向けの追加機能としてContent Moderationが用意されており、利用時の安全性を高める仕組みを組み込みやすくなっています。

用語	意味
ハルシネーション	AIがもっともらしい見た目で誤った内容を返してしまう現象です。たとえば、根拠のない事実を断定したり、実在しない情報を自然に作ってしまったりすることがあります。 Dify固有の用語ではありませんが、Knowledge Retrievalやコンテキスト管理を活用する理由のひとつは、このハルシネーションを減らしやすくするためでもあります。これはDifyのRAG系機能と一般的なLLM運用知識を踏まえた整理です。
Content Moderation	不適切な内容をフィルタリングするための機能です。 DifyのAdditional Featuresでは、Chatflowアプリで利用できる機能として案内されており、エンドユーザーとのやり取りで安全性や法令対応、利用体験を整える目的で使われます。つまり、危ない内容や扱いたくない内容への備えとして入れておく仕組みです。
禁止表現	アプリ側で出したくない言葉や、受け付けたくない入力をあらかじめ制限する考え方です。 Difyのチュートリアルでも、Content Moderationに特定キーワードを追加して、その入力に対して定型の拒否応答を返す例が紹介されています。業務用途では、危険ワードだけでなく、ブランド方針に合わない表現を避けたいときにも役立ちます。
ガードレール	AIの振る舞いを安全側に寄せるためのルールや制御全体を指す考え方です。 Difyの画面でそのまま大きく表示される単一機能名ではありませんが、システムプロンプト、構造化出力、Content Moderation、引用表示などを組み合わせて、出力の暴走や不適切応答を防ぐ設計思想として理解すると分かりやすいです。これは公式の各機能をまとめた実務上の整理です。
Citation	Knowledge Retrievalを使った回答で、どの情報源をもとに答えたのかを見せるための機能です。追加機能の説明では、Chatflowで Citation を有効にすると、知識検索を使う際にソースを表示できると案内されています。回答の根拠を見せられるので、ユーザーが内容を確認しやすくなり、信頼性の向上にもつながります。

マルチモーダル対応で出てくる用語

最後に、文章以外の入力や出力に関わる用語を見ていきます。

最近のDifyでは、画像や文書、音声といった要素も扱える場面が増えており、このあたりの用語も初心者のうちから知っておくと理解が広がりやすくなります。

LLMノードはテキスト、画像、文書を処理でき、Additional FeaturesではファイルアップロードやTTSなども追加できます。

用語	意味
Vision	画像を入力として扱える機能です。 Additional Featuresでは、画像アップロードを有効にし、Vision対応のLLMノードで `sys.files` を選択することで、画像を見て内容を分析するフローを作れると説明されています。文章だけでなく、画像も理解して返答できるようにするための入口と考えると分かりやすいです。
画像入力	ユーザーがアップロードした画像をAIが処理対象として受け取ることです。 Difyでは一部のLLMが画像を直接分析できるため、画像内容の説明、分類、要約のような使い方ができます。文書ファイルとは処理方法が違うので、画像と文書を同時に扱う場合は、公式でも別々に処理を分ける構成が案内されています。
ファイルアップロード	ユーザーがチャット画面から文書や画像などを渡せる機能です。 ChatflowではAdditional Featuresから有効化でき、アップロードされたファイルは `sys.files` に入ります。文書はそのままではLLMが読めないため、Document Extractorを挟む必要がある点も公式で説明されています。
Document Extractor	PDFやDOCXなどの文書ファイルからテキストを取り出すためのノードです。 Additional Featuresでも、文書ファイルを扱う場合は `sys.files` を入力にしてDocument Extractorを使い、その出力をLLMノードへ渡す流れが案内されています。文書をそのままAIに食べさせるのではなく、読める形に変換する前処理だと考えると自然です。
TTS	Text-to-Speech の略で、テキストの応答を音声で読み上げる機能です。 Difyの追加機能では、ChatflowでText-to-Speechを有効にすると、応答を読み上げられるようになり、利用にはModel Providers側でTTSのセットアップが必要と案内されています。チャット結果を“読む”だけでなく“聞ける”ようにする機能です。