Difyでチャットボットを作る手順｜種別の選び分けと社内公開・ナレッジ設定【1.18対応】

Difyでチャットボットを作る操作は、アプリを作ってプロンプトを書き、ナレッジをつないで公開するだけです。問題になるのは公開した後です。会話が続くと前半の指示を忘れる、社内文書を入れたら無料枠が埋まる、公開URLが社外からも開ける、APIから呼んだら400が返る。どれも公式ドキュメントに上限や仕様として書かれていることです。この記事では、アプリ種別の選び分けから社内公開・API連携までを、2026年10月23日リリースのDify 1.18.0時点の公式ドキュメントとソースコードに沿って整理します。

まとめ：Difyでチャットボットを作る前に決める5点

最初に決めておくと後戻りしないのは次の5点です。

• アプリ種別：プロンプトとナレッジで答えるだけならChatbot、質問の種類で処理を分けるならChatflow。ChatbotはあとからChatflowへ変換できますが、Agentは変換できません。
• ナレッジの種類：1.18.0で加わったAgent Knowledge Base（ベータ）は、Chatbotからは検索できません。Chatbotで作るならクラシックナレッジを使います。
• 索引方法と容量：High Qualityはベクトルが容量を消費し、無料のSandboxは50MBです。High Qualityで作ったナレッジはEconomicalへ戻せません。
• 公開範囲：WebアプリはURLを知っていれば誰でも開ける状態で公開されます。社内限定にするなら、CloudではProfessional以上のIPアクセス制御を使います。
• 会話履歴の上限：Chatbotは1会話あたり500メッセージか2,000トークンのどちらかを超えると古い順に履歴を捨てます。長い質問や回答が続くと、数往復でも2,000トークンに届く場合があります。

チャット型アプリ4種類の選び分け（1.18.0時点）

Difyで会話形式のアプリになるのは、Chatbot（チャットボット）・Chatflow（チャットフロー）・Agent（ベータ）・legacy Agent（従来のエージェント）の4種類です。Service APIのチャットメッセージ送信も、対象を「Chatflow, Agent, Chatbot, Legacy Agent apps」と明記しています。WorkflowとText Generatorは一問一答で終わる処理で、会話履歴を持ちません。

Chatbot：プロンプトとナレッジだけで答える最小構成

公式ドキュメントはChatbotの用途として「an internal Q&A assistant grounded in your team’s knowledge base」を挙げています。社内規程や手順書に答えさせるボットは、この標準ケースそのものです。ツール呼び出しや多段処理が要らなければ、フローを組む必要はありません。

プロンプトには {{role}} のような変数を置けます。変数は会話開始前の入力欄になり、型はShort Text（256文字まで）・Paragraph・Select・Number・Checkbox・API-based Variableの6種類です。部署ごとに口調を変えるなら、Selectで部署を選ばせ、その値をプロンプトへ渡せます。ただし、利用者が変更できる部署選択を、機密文書の閲覧権限の判定には使いません。

Chatflow：質問の種類で処理を分ける場合

問い合わせ内容によって処理を変えたいならChatflowです。メッセージを受けるたびにノードで組んだフローを実行してから応答します。公式チュートリアルのナレッジベース付き顧客サポートボットは、質問分類ノードで用件を振り分け、「無関係な質問」と「コミュニティ参加の案内」はLLMを通さずAnswerノードで直接返す構成です。この構成でも質問分類にはLLMを使いますが、定型回答の分岐では回答生成のLLM呼び出しを省けます。分類に成功した場合は、生成による回答の揺れも避けられます。

ChatflowはUser Inputで始まりAnswerノードが必須で、Trigger（スケジュールやWebhookでの起動）を持ちません。定時実行や外部イベント起動が要るならWorkflow側で設計します。ノードの組み方はDifyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】で扱っています。

Agent（ベータ）とlegacy Agent：ツール選択をモデルに任せる場合

1.18.0のドキュメントではエージェントが2系統あります。従来の「legacy Agent」はモデルが設定済みのツールを自分で選び、新しいAgent（ベータ）は専用サンドボックスでコマンド実行やファイル操作まで行い、単体のチャットアプリにもワークフローのノードにもなります。

指定した社内規程を検索して回答するだけなら、まずChatbotを選びます。複数のシステムを調べたり、回答後に手続きを実行したりする要件がある場合にAgentを検討します。Agentは応答の経路が毎回変わるため、同じ質問に同じ答えが返る再現性が下がります。手順を固定できるならChatflow、手順が要らないならChatbot、手順を事前に決められないときだけAgentです。

会話履歴の上限：Chatbotとlegacy Agentは500メッセージ／2,000トークン

ChatbotとAgentのドキュメントには同じ注記があります。「keep up to 500 messages or 2,000 tokens of history per conversation. If either limit is exceeded, the oldest messages will be removed」。500メッセージと2,000トークンのどちらか一方を超えた時点で、古いメッセージから落ちます。

先に効くのはトークン側です。長い質問や回答が続くと、数往復でも2,000トークンを超える場合があります。古いメッセージが履歴から外れると、「さっき伝えた条件で」という参照が通じなくなることがあります。対処はFAQに書いたとおりです。一方、新しいAgentは「how much the agent keeps in mind depends on the model’s context window」とされ、固定の上限ではなくモデルのコンテキスト長で決まります。1.17.0で長い会話を古いツール結果の削除と要約で詰める仕組みが入ったのもこちらの系統です。

Chatbotから後で作り直せる範囲

アプリをフロー型へ変換する機能の対象は、1.18.0のソース（api/controllers/console/app/workflow.py）でもChatbot（chat）とText Generator（completion）だけで、ChatbotはChatflowになります。変換は名前に「(workflow)」が付いた新しいアプリを作る処理なので、公開URLとAPIキーは引き継がれず、社内に配布した後なら配り直しです。legacy Agentは変換できません。迷ったらChatbotで始めるのが、後戻りしやすい選び方です。

Chatbotを作成してナレッジにつなぐ手順

アプリ作成とプロンプトに書く3要素

スタジオで「最初から作成」を選び、種類に「チャットボット」を指定します（「テンプレートから作成」もありますが、社内向けならプロンプトはどのみち書き直します）。プロンプトに書くのは役割・出力形式・制約の3点です。社内ボットでは「ナレッジに書かれていない内容は推測せず、担当窓口を案内する」と制約に書かないと、モデルが一般論で答えを埋めます。右側のプレビューでは「Debug as Multiple Models」で最大4モデルを並べて試せます。モデルプロバイダーはプラグインとして追加する形式で、一覧に目的のモデルが出ない場合はDifyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】を先に確認してください。

クラシックナレッジとAgent Knowledge Baseの選び方

1.18.0からナレッジベースは2種類になりました。ナレッジの概要ページの比較表では、新しいAgent Knowledge Baseを使えるのは「Workflow and Chatflow apps, the new Agent」、クラシックナレッジは「Chatbot, Text Generator, legacy Agent, Workflow, and Chatflow apps」です。Agent Knowledge Base側のページには「Chatbot, legacy Agent, and Text Generator apps can’t search an agent knowledge base」とあり、使うならChatflowかAgentで作り直すよう案内しています。

クラシックからAgent Knowledge Baseへは移行できますが、逆はできません。1.18.0のリリースノートでは、セルフホストでは既定オフ（別サービスと別データベースが必要）、Cloudへの提供は「Will soon be available」です。Chatbotで作るなら、現時点ではクラシックナレッジ一択です。

チャンク設定と索引方法（High Qualityは戻せない）

「ナレッジ」からナレッジベースを作り、ファイル・Notion・Webサイトのいずれかを取り込みます。Webサイトの取り込みにはFirecrawlかJina Readerを使い、APIキーは画面右上のアバターから開くデータソース設定で登録します。公式チュートリアルはWebサイト取り込みの上限を50ページと案内しています。

索引方法はHigh QualityとEconomicalの二択です。High Qualityは埋め込みモデルのトークンを消費してベクトル検索・全文検索・ハイブリッド検索が使え、Economicalはチャンクごとに10個のキーワードで引く転置インデックスだけでトークンを消費しません。索引方法のドキュメントには「Once a knowledge base is created in the High Quality index method, it cannot switch to Economical later」とあり、EconomicalからHigh Qualityへの切り替えはできても逆はできません。容量の小さいプランで迷うなら、精度を落としてよい参考資料だけEconomicalの別ナレッジに分けておきます。

検索設定2層とリランクの有無

回答が的外れなときに見落とされやすいのが、検索設定が2か所にあることです。ナレッジ側の設定が候補の母集団を決め、アプリ側の「Retrieval Setting」がそれを並べ替え・絞り込みます。片方だけ調整しても効かないのはこの関係のためです。

アプリ側のWeighted Score（意味の近さとキーワード一致の重み）は、追加した全ナレッジがHigh Qualityのときしか選べません。Economicalを1つ混ぜると選択肢から消えます。Top K（既定3）とScore Threshold（既定0.5）は、ナレッジ側の検索方式がベクトル検索か全文検索なら、ドキュメントに「only effective during the Rerank phase」とあるとおりリランクモデルを追加して有効にしないと効きません（リランクモデルは既定で無効）。ハイブリッド検索ならリランクモデルなしの重み設定でも指定でき、EconomicalではTop Kだけが使えます。人事規程と技術文書を同じナレッジに入れている場合は、メタデータで検索対象の文書を絞らないと精度が安定しません。

検索テストによる取得チャンクの確認

ナレッジの画面にある「検索テスト」に想定質問を入れ、実際に返るチャンクを見ます。答えてほしい段落がここで出てこないなら、回答生成用のプロンプトより先に、文書の処理状態、分割・索引、検索方式、Top Kやスコアしきい値を確認します。取り込み時の「Preview」でチャンクの切れ方を確かめ、規程の条文や表が途中で分断されていれば分割規則を変えて取り込み直します。検索テストも1回ごとにナレッジ操作レートに数えられ、Sandboxでは1分に10回が上限です。ここが通ったら、Chatbotの編集画面に戻り、回答に使うモデルを選んでから「コンテキスト」にクラシックナレッジを追加します。公開するのは、右側のプレビューで想定質問への回答と参照元を確かめた後です。

文書量と利用頻度に応じたプラン別容量・レート制限の比較

社内利用でつまずく原因は、機能より枠です。Difyの料金ページに数値が出ているので、載せる文書量と利用人数から先に逆算できます（2026年11月1日確認）。

容量を消費するのは元ファイルではなく索引後のチャンクとベクトルで、容量のドキュメントは「Your original files don’t count」と明記しています。チャンクが細かいほど、埋め込みの次元が大きいほど（text-embedding-3-large は -small の2倍）消費が増え、Economical索引は数えられません。

ナレッジ操作レートに何が数えられるかは、アプリ種別で変わります。レート制限のドキュメントでは、Chatbot・Text Generator・legacy Agentからのナレッジ検索は数えず、数えるのはWorkflowとChatflowのKnowledge Retrievalノードがクラシックナレッジを検索したときです。ノードがIterationやLoopの中にあれば1周ごとに1回と数えます。同じ社内ボットでも、Chatbotなら利用が増えてもこの枠を消費せず、Chatflowに変換すると質問1回ごとに枠を使う設計になります。Sandboxの10回／分でChatflowを社内公開すると、昼休みの数人の同時利用で上限に達します。

文書のアップロード・削除・有効化、チャンクの編集、検索テストはどの種別でも数えられます。上限に当たった後の要求は拒否されたものも数えられるため、すぐ再試行すると止まり続けます。1分待ってから再開します。Sandboxのメッセージクレジットも初回付与の200クレジットを使い切ると補充されず、以降は自社のモデルプロバイダーのAPIキーで動かすことになります。

ナレッジが「インデックス中」「同期中」のまま終わらないときの確認順

文書が処理中のまま進まない、または一覧には見えるのに検索に出ない場合は、次の順で確認します。

1. 容量の上限：クラシックナレッジは索引前に必要容量を見積もり、超える文書を「Error」のまま残します。請求画面でKnowledge Data Storageを確認し、空きを作ってから「Retry」を押します。使用量の表示は数分遅れます。
2. ナレッジ操作レート：アップロードは1ファイルごとに数えられ、Sandboxでは10回／分に当たるとその後の操作が拒否されます。拒否された要求も数えられるので、1分以上空けてから分けて投入します。
3. 埋め込みモデル：High Qualityの索引は埋め込みモデルを呼び出します。モデルプロバイダーのAPIキーと残高を確認します。
4. 同期の方式：クラシックナレッジのNotionとWebサイトは自動では更新されません。Notion側を直したら文書一覧で対象ページの「Sync」を押します。
5. セルフホストのworker：索引処理はAPIコンテナではなく worker コンテナが dataset キューから取り出して実行します。docker compose ps で worker が Up か確認し、docker compose logs -f worker でエラーを見ます。1.17.1より前の版では、相対パスや data: 形式など取得できない画像リンクを大量に含むMarkdown文書が索引用のworkerを長時間占有し、後続の文書まで待たされる不具合がありました（1.17.1のリリースノートで修正済み）。

セルフホストでNotionをつなぐ場合、連携のトラブルシューティングにあるとおりNotionのOAuthはHTTPSでしか動かないため、ローカル環境では NOTION_INTEGRATION_TYPE=internal と内部インテグレーションのシークレットを使います。Podman環境での設定場所はDifyをPodmanのrootlessで動かす手順とNotion連携の設定にまとめています。

社内公開時のWebアプリの既定公開範囲とアクセス制限

「公開する」を押すとWebアプリのURLが発行されます。Webアプリ設定のドキュメントは「Web apps are public by default. Anyone with the URL can access them」と明記しています。アクセス制限を設定していないボットは、URLが社外へ転送されると社外の人も開けます。公開URLを配布する前に制限を設定し、許可したネットワークと範囲外のネットワークの両方からアクセスを確認します。

URL共有・iframe・チャットバブルの使い分け

社内ポータルにリンクを置くだけなら、発行されたURLで足ります。ページに組み込むなら、アプリの「アクセスポイント」から「ウェブサイトに埋め込む」を開きます。iframe・スクリプト・Chrome拡張の3つが選べ、常に表示しておきたいページにはiframe、既存ページの邪魔をしたくない場合は右下に丸いボタンを出すチャットバブル（スクリプト）を使います。1.18.0の管理画面がコピーさせるスクリプトは次の形です（ソースの app-card-utils.ts から抜粋）。

<script>
 window.difyChatbotConfig = {
  token: 'YOUR_APP_TOKEN',
  baseUrl: 'https://udify.app',
  inputs: {},
  systemVariables: {
    // user_id: 'YOU CAN DEFINE USER ID HERE',
  },
 }
</script>
<script
 src="https://udify.app/embed.min.js"
 id="YOUR_APP_TOKEN"
 defer>
</script>

token は埋め込み画面に表示される値です。セルフホストでは、その環境の管理画面が生成した埋め込みコードを使い、baseUrl とスクリプトの src が自社環境のURLを指していることを確認します。inputs にはアプリの入力変数を事前に入れられ、ログイン情報から部署を埋めておけば利用者に選ばせる手間が消えます。埋め込みのドキュメントによると、ボタンが出ないときの確認項目として、トークンが埋め込み画面の値と一致しているか、設定オブジェクトが埋め込みスクリプトより先に読み込まれているかを挙げています。

公開範囲を絞る手段：CloudはIPアクセス制御、セルフホストはEnterprise

Cloudでは、ProfessionalとTeamでIPアクセス制御が使えます。「設定」の「IP ポリシー」で許可するIPアドレスやCIDR範囲を登録し、アプリの「アクセスポイント」右上の「アクセス制御」で、ポリシーで保護するアクセスポイントを選びます。ポリシーを作れるのはOwnerとAdminだけです。サブスクリプションが切れるとIP保護も止まるので、契約更新の失念がそのまま公開状態につながります。

セルフホストのCommunity版にはこの機能がありません。セルフホスト版のドキュメントは、認証やメンバー単位のアクセス制限を「On Dify Enterprise」の機能として案内しています。Community版で社内限定にするなら、Difyの前段のリバースプロキシやVPNで到達できるネットワークを絞るのが現実的です。

ワークスペースの4ロールと招待リンクの72時間

ワークスペースのロールはOwner（1名・全権）、Admin（メンバーとモデルプロバイダーの管理＋Editorの権限）、Editor（アプリとナレッジの作成・編集・削除）、Normal（公開済みアプリの利用のみ）の4種類で、ボットを使うだけの社員はNormalで足ります。招待リンクは72時間で失効します。所有権を移譲すると元のOwnerはNormalになるので、管理者として残るには新しいOwnerにAdminへ変えてもらいます。

社員ごとに会話を分けるuser識別子

Service APIの user パラメータは、仕様上「Conversations, messages, and files are visible only to requests carrying the same user」です。全社員のリクエストに同じ固定値を渡すと、会話履歴が全員から見える状態になります。社内システムに組み込むなら、サーバー側で社員を認証し、その認証結果に対応する user を設定します。Difyはこの値自体を認証しないため、利用者が任意の社員IDを指定できる実装にはしません。チャットバブルの systemVariables の user_id も利用者ごとに会話を追うのに使えますが、ブラウザ側で書き換えられる値なので閲覧制限の代わりにはなりません。

APIから呼ぶ実装：公式Python SDKよりREST直叩き

出回っている import dify_sdk で始まるコードは動きません。PyPIの dify_sdk は第三者製で、モジュール名は dify、create_bot() や add_faq() というメソッドもありません。

公式の dify-client はPyPIの最新版が0.1.10（2023年11月15日公開）のままで、ベースURLが https://api.dify.ai/v1 に固定されているためセルフホストに向けられません。ソースは2025年12月9日に本体リポジトリからlanggenius/dify-python-sdkへ分離され、そちらの pyproject.toml は0.1.12ですが、2026年11月1日時点でPyPIには公開されていません。確実なのはREST APIを直接呼ぶ実装です。アプリの「API アクセス」で app- で始まるキーを発行し、Bearerトークンとして送ります。

import requests

API_BASE = "https://api.dify.ai/v1"
API_KEY = "app-XXXXXXXXXXXXXXXXXXXXXXXX"

res = requests.post(
    f"{API_BASE}/chat-messages",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "query": "経費精算の締め日はいつですか",
        "inputs": {},
        "response_mode": "blocking",
        "user": "emp-0142",
        "conversation_id": "",
    },
    timeout=60,
)
print(res.status_code)
try:
    print(res.json())
except requests.exceptions.JSONDecodeError:
    print(res.text)

キーが不正なら 401 {'code': 'unauthorized', 'message': 'Access token is invalid', 'status': 401} が返り、経路は正しくキーだけが問題だと切り分けられます。conversation_id を空文字にすると新しい会話になり、応答に含まれる値を次のリクエストに渡すと会話が続きます。inputs・query・user の3つは必須です。

Agentとlegacy Agentでblockingが400になる条件

response_mode は省略すると blocking になりますが、API仕様には「Legacy Agent and Agent apps support streaming only」とあります。上のコードをエージェント系のアプリに向けると、bad_request（「Agent App only supports streaming response mode.」）の400で失敗します。新しいAgentでは、Agentが紐付いていない場合の invalid_param と、公開されていない場合の agent_not_published も400で返ります。Chatbotでも、Cloudではエッジプロキシのタイムアウトで長い生成が切られることがあるため、仕様は streaming を推奨しています。

運用開始後のログ確認と注釈返信による回答管理

公開後は、アプリの「ログ」で実際の質問と回答、利用者の評価を確認します。間違えた回答には、その場で注釈（改善した回答）を付けられます。「注釈の返信」を有効にすると、質問が登録済みの注釈と意味的に一致してしきい値を超えたとき、回答生成のLLMを呼ばずに注釈の回答をそのまま返します。社内規程の締め日や申請窓口のように答えが1つに決まる質問に向いています。照合には埋め込みモデルを使うので、その料金はかかります。しきい値を下げすぎると別の質問に注釈が誤って当たるため、ログで当たり方を見ながら調整します。登録できる件数はSandbox 10件、Professional 2,000件、Team 5,000件です。

ログのドキュメントによると、Sandboxのログは30日で消え、後からプランを上げても戻りません。ProfessionalとTeamでは会話ログを契約期間中保持します。

Cloudとセルフホストの選定基準：データの保管先と外部送信先

規程や顧客情報をDify Cloudに置いてよいかは、機能比較ではなくデータの所在で決まります。社外に出せないならCommunity版を自社インフラに立て、出せるならCloudの方が運用はずっと軽く済みます。ただしセルフホストでも、モデルのAPIを外部プロバイダーに向ける限り、質問文とナレッジの抜粋はそのプロバイダーへ送られます。

Docker Composeでの構築手順の最小要件はCPU 2コア以上・メモリ4GiB以上・Docker Compose 2.24.0以降で、macOSのDocker Desktopでは仮想マシンに2 vCPUと8GiBを割り当てるよう案内されています。1.18.0では手順が1つ増え、.env の DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN に openssl rand -base64 32 の出力を設定しないと、エージェントのバックエンドとサンドボックスが起動しません。起動後は http://localhost/install で管理者アカウントを作ります。

この値は「minimum system requirements」で、本番負荷の想定ではありません。AWSでの構築手順はDifyをAWS EC2に構築しBedrockへIAMロール接続する手順【Dify 1.18.0対応】、可用性を求める構成はDifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.39.0のvalues設定と落とし穴で扱っています。社内規程の整理から検索精度の検証、公開範囲の設計までまとめて任せたい場合は、一創のAIチャットボット開発でも対応しています。

よくある質問

Difyの読み方は？

開発元LangGenius, Inc.の日本語サイトと日本語ドキュメントにはカタカナ表記がなく、表記は英字の「Dify」で統一されています。日本語の解説記事では「ディファイ」と「ディフィー」が併存しており、どちらかを公式の読みとする根拠は見当たりません。社内資料で表記をそろえるなら、読み仮名を付けず「Dify」と書くのが無難です。

Difyでチャットボットを作るのにコードは必要ですか？

不要です。作成から公開まで画面操作で完結します。コードが要るのは、自社システムからREST APIで呼ぶ場合と、サイトにチャットバブルのスクリプトを貼る場合です。

無料のSandboxプランだけで社内チャットボットを運用できますか？

試作までは可能ですが、常用には向きません。ナレッジ容量が50MB、ナレッジ文書が50件、メンバーが1名、Dify APIが月5,000回で、メッセージクレジットも初回の200クレジットだけで、利用できる回数はモデルごとの消費量によって変わります。ログも30日で消えます。社内で継続的に使うなら、5GB・100回／分・3名のProfessionalが実質的な下限で、IPアクセス制御もProfessionalから使えます。

Difyの類似サービスにはどのようなものがありますか？

ノーコードでLLMアプリを組む領域では、Microsoft Copilot Studio、Langflow、n8nなどが比較対象になります。オープンソースでよく並べられていたFlowiseは、GitHubリポジトリが2026年8月13日にアーカイブされています。Difyの特徴は、ナレッジ・ワークフロー・公開・APIが1つの画面にまとまっていることと、Community版を自社インフラに置けることです。個別のボットではなく社内向けの汎用チャット画面が要件なら、LibreChatとは？Docker構築手順と社内AIチャット基盤の採用判断も比較に入ります。

会話の途中で前の指示を忘れてしまうのはなぜですか？

ChatbotとLegacy Agentが、1会話あたり500メッセージまたは2,000トークンまでしか履歴を保持しない仕様のためです。設定で緩める項目はありません。前提を保たせたいなら、会話開始時のプロンプト変数で固定するか、Chatflowの会話変数に保存します。Chatflowの会話変数はAPIからも読み書きできるので、社内システム側の申請状況などを同じ会話セッション内の複数ターンで参照できます。別の会話でも引き継ぐには、外部に保存した状態を取得して新しい会話へ設定する実装が必要です。

関連記事

• Difyワークフローの作り方と使い方｜ノード選定・ループ・トリガーを実装手順で解説【2026年版】
• Difyのプラグインがインストールできない原因と対処法｜bad signature・依存エラー・容量【1.17.1対応】
• RAGとファインチューニングの違いと使い分け｜判断基準とコストで選ぶ2026年の実装方針
• DifyをAWS EC2に構築しBedrockへIAMロール接続する手順【Dify 1.18.0対応】
• DifyをHelm chartでAWS EKSに構築する手順｜コミュニティ版0.39.0のvalues設定と落とし穴