Dify用語集：LLM・RAG・Agent・MCP・トークンを整理

LLMは文章を生成・分析するモデル、RAGは検索した情報を回答の根拠に加える方法、Agentは目的に応じてツールなどを選びながら処理を進める仕組み、MCPは外部のツールや情報を接続する共通の通信規約です。

トークンは、モデルが扱う情報量を数える単位で、文字数や利用クレジットとは異なります。

Difyの学習で迷いやすいのは、これらが同じ階層の言葉ではないことです。

本記事では用語を5つの役割に分け、意味、Difyでの確認先、架空の問い合わせ対応の例を対応付けます。

読み終えたら、自分が知りたい言葉が「モデル」「処理の流れ」「根拠」「接続」「運用」のどれに関わるかを説明できることを目指します。

対象はDifyをこれから学ぶ方です。公式資料の確認日は2026年10月26日。

主にDify Cloudの資料を参照していますが、実際の環境・稼働版・モデルID・プラグイン版は未確定です。

画面の確認先は公式資料に基づく案内で、実画面を操作して確認した記録ではありません。

日本語の説明語を、公式UIの日本語ラベルとは扱いません。

最初に、用語を5つの役割に分ける

用語をすべて暗記する必要はありません。

作業中に分からない言葉が出たら、まず次の表で役割を選び、該当する節へ進んでください。

たとえば「MCPを入れれば正しく答えられる」という説明では、接続方法と回答品質が混ざっています。

接続できた後も、参照した情報、モデルへの指示、返答内容をそれぞれ確認する必要があります。

文章を作る用語：LLM・プロンプト・トークン

LLMの名称だけで、アプリ全体の役割は決まりません。

同じモデルでも、渡す資料、指示、処理の組み方によって結果は変わります。

DifyのLLMノードと、選択したモデル提供元の仕様を一緒に確認します。

トークン、文字数、認証トークンは別のもの

「おはようございます」のような文章を何トークンと数えるかは、モデルの分割方法に依存します。

日本語と英語の文章を、同じ文字数だから同じ費用と見積もることはできません。

この記事では特定モデルでの計数をしていないため、具体的なトークン数は示しません。

モデル提供元の用語説明などを参照し、対象モデルで確かめます。

APIの説明で見かける「Bearer token」などの認証用トークンは、アクセスのための資格情報です。

文章量を数えるトークンとは別の意味で使われています。

認証用の値を、学習記録や記事へ貼り付けないでください。

コンテキストが大きいことと、覚え続けることは別

コンテキストウィンドウは、モデルが今回の応答で扱う作業領域と考えると理解しやすくなります。

学習済みの知識や、アプリが永続保存する履歴とは別です。

入力だけで枠を使い切らず、出力などに必要な容量も確認します。

具体的な計算方法はモデルによるため、Context windowsの公式説明を起点に対象モデルの仕様を読みます。

Temperatureを低くしても、入力にない事実が正しく補われるわけではありません。

0に設定できるモデルでも、常に同じ出力になると保証しないことが大切です。

処理をつなぐ用語：Workflow・Chatflow・変数

WorkflowとChatflowは、ノードをつなぐ共通の考え方を持ちます。

「会話を続けるか」「一つの依頼を処理するか」を先に考えると、用語を整理しやすくなります。

queryという名前はこの記事の説明用です。

実際には変数選択で参照元を確認し、文字列として名前を書いただけで値が渡ったと思い込まないようにします。

Key Conceptsでは、入力、ノード出力、環境変数などの違いを確認できます。

IterationとLoop、集約と代入を分ける

詳細はIteration、Loop、Variable Aggregator、Variable Assigner、Document Extractorの各仕様で確認します。

初学者は用語の区別を先に押さえ、すべてのノードを一度に使う必要はありません。

根拠を探す用語：RAG・Knowledge・検索設定

RAGはRetrieval-Augmented Generationの略です。

Difyでは、Knowledgeに用意した情報を検索し、取得した内容をモデルの文脈として使う構成を作れます。

資料を登録することを、LLMそのものの追加学習と同一視しないでください。

Knowledge Retrievalでは、検索対象と検索結果の後処理を確認します。

索引・検索設定にあるTop Kなどの値を、すべての検索方式で同じ条件で有効と考えないでください。

対象画面、索引方式、Rerankの有無によって適用条件が変わります。

ここでは万能な推奨値は置きません。

資料加工の流れはKnowledge Pipelineの説明で確認できます。

取り込みに成功しただけでは、質問に必要な根拠が検索されるかまでは分かりません。

外部の機能を使う用語：Agent・Tool・Plugin・MCP

Agentは「高性能なチャットボット」という呼び名だけでは説明できません。

どのモデルが、どのツールを、どの条件で使うかを見る必要があります。

Agentノードの説明と、別の新Agentの構築資料を混同しないようにします。

後者は確認日時点でベータと明記されています。

Integrationsにはモデル提供元、ツール、データソースなど異なる種類があります。

MCPも接続経路の一つであり、APIの代わりにすべてを実現する魔法の部品ではありません。

MCPサーバーの内部で既存APIを呼ぶ構成も考えられます。

DifyでMCPを使う方向は2つある

前者はDify Tools、後者はMCP Serverの公開資料で説明されています。

後者で発行されるURLには認証情報が含まれるため、一般公開する記事リンクやスクリーンショットに載せません。

MCPのアーキテクチャは、モデルの回答品質や業務上の操作許可そのものを決める仕様ではありません。

接続できたことと、更新・削除・送信を許可してよいことは別です。

最初は模擬データや許可された読み取り機能で役割を理解します。

また、Dify APIの開始ガイドはAPIキーをバックエンド側で扱うよう案内しています。

ブラウザーへ配るコードや本文に、実際のキーを埋め込まないでください。

状態と利用量を管理する用語

アプリを作る作業と、利用者が使う状態を分けて考えるための用語です。

用語が分かっても、公開や復旧の実施条件を満たしたことにはなりません。

Version Controlで対象となる版を確認し、試験した設定と公開中の設定を混同しないようにします。

DSLのexportを、Knowledgeの実データやログまで含む完全バックアップと扱うこともできません。

形式はKey Conceptsで確認します。

Run Historyと公開後のLogsは、用途と対象を分けて見ます。

Workflow／Chatflowのエディター内Preview・Test Runは、通常のLogs一覧には含まれません。

Model ProvidersとCloud料金ページを確認し、creditsと自分のAPIキーの利用順や支払先を把握します。

1トークン＝1creditとは計算しません。料金比較や無料枠だけでの完了は、この記事では断定しません。

架空のFAQで、用語と処理を対応付ける

ここからは紙やメモだけでもできる学習課題です。

Difyで構築・実行した例ではなく、次の資料と質問を使う設計例です。

時刻は同じ架空のローカル時間として扱います。

資料ID：KB001
架空の問い合わせ窓口の対応時間：月曜〜金曜09:00〜18:00。
土日・祝日および料金の案内は未記載。

1. この資料を「Knowledgeに登録する資料」として位置付けます。
2. 「平日の対応時間は？」という質問を、User Inputから受け取る値と考えます。
3. Knowledge RetrievalがKB001の該当内容を探す役割を担当します。
4. LLMに質問と検索結果を渡し、Promptで「根拠の範囲で答える」と指定する設計にします。
5. 回答をAnswerまたはOutputなど、選んだアプリ形式に合う方法で返すと考えます。

この構成を説明するために、AgentやMCPを必ず追加する必要はありません。

外部照会や動的なツール選択が必要かどうかで、追加する理由を考えます。

構造化出力を考える場合は、次のような形が一案です。

これは「土曜日も対応するか」という質問への期待形式で、Difyが実際に返した結果ではありません。

{"answer":"資料から確認できません。","source_ids":["KB001"],"needs_confirmation":true}

source_idsは、この学習例で参照した資料を記す自作フィールドです。

Difyが自動的に生成する標準フィールドではありません。

needs_confirmationも人が確認するための設計上の印で、これだけで通知や承認処理が動くわけではありません。

画面で確かめるなら、まず権限のある環境でアプリ種類・ノード名・変数の参照元を読み取るところまでにします。

公開、キーの発行、外部接続、モデル実行は用語確認の必須条件ではありません。

実行へ進む場合は、モデルと利用枠、支払先、費用上限を確認し、架空データで別途試験します。

混同しやすい言い方を、自分の説明に直す

自分のノートには、「用語」「何をする役割か」「どの画面・設定で確かめるか」「何とは違うか」の4欄を作ってみてください。

定義を一字一句暗記するより、作りたいアプリの例で説明できることが次の学習につながります。

次に学ぶことと公式資料

まずはLLM、Prompt、Variable、Knowledge Retrievalの4つを、上の架空FAQに当てはめて説明してみましょう。

次にアプリ種類の違い、検索の評価、料金の確認へ進みます。

MCPやAgentは、それが必要となる用途を言える段階で追加すると整理しやすくなります。

教材を選ぶときは、用語の定義だけでなく、対象版、画面との対応、入力例、不明な結果の扱いが説明されているか確認してください。

特定の有料教材の購入を、学習の前提にはしません。

公式資料は各節のリンクから確認できます。

特に再確認に使いやすい入口は次のとおりです。確認日はいずれも2026年10月26日です。

• Dify Key Concepts：アプリ・変数・DSL
• Dify Workflow & Chatflow：アプリの構成
• Dify Knowledge：RAGと資料の役割
• Dify Integrations：拡張機能の分類
• Dify Tools：ツールと外部MCP接続
• MCP Architecture：host・client・server
• Claude Glossary：トークンなどの基礎概念
• Dify API Get Started：APIとキーの区別