【2025年版】Difyの「ナレッジ」完全ガイド｜PDF・Web取り込みからRAG設定、運用・セキュリティまで徹底解説

（最終更新日: 2025年11月24日）

Difyの「ナレッジ」で社内FAQや問い合わせボットを作りたいけれど、設計や紐づけ方、最初の一歩に迷っていませんか。

本記事は2025年の最新仕様を踏まえ、PDFやWeb、Notionの取り込みから検索設定、ボットへのつなぎ方までを平易な手順で示します。

まず「できること／できないこと」とプラン別に試せる範囲を先に明確化し、セキュリティや権限の要点も押さえます。

さらに、更新が反映されない・日本語PDFが読めない・検索が外れるなど、よくあるつまずきをまとめて解決します。

読み終えれば、自社マニュアルをどう分けて登録し、どのワークフローに結びつけるかまで具体案が描け、明日から検証を進められます。

Difyナレッジとは何か：プロンプトやツールとの違いと、RAGのイメージ

当セクションでは、Difyの「ナレッジ」の正体と、プロンプトやツールとの違い、さらにRAGの基本的な動きを整理して説明します。

なぜなら、三者の役割を取り違えると精度・コスト・運用すべてに悪影響が出て、改善が進まなくなるからです。

ナレッジ＝LLMの「外付け社内Wikipedia」。プロンプト・ツールとの役割分担
RAGの基本：『探してから答える』ので、元データの質がすべて
Difyナレッジの種類と制限（対応フォーマット・容量・プラン差）
どんなユースケースに向いているか：社内FAQ・カスタマーサポート・マニュアル検索

ナレッジ＝LLMの「外付け社内Wikipedia」。プロンプト・ツールとの役割分担

結論として、ナレッジは長期記憶の検索元であり、業務ルールの指示や計算処理の場ではありません。

この分離が崩れるとシステムプロンプトが肥大化し、モデル切り替えや規程改定のたびに保守負荷が跳ね上がります。

FAQボットなら「システムプロンプト＝回答方針とトーン」「ツール＝API呼び出しや計算・ワークフロー」「ナレッジ＝PDF規程やヘルプ記事」と配置すると安定します。

下図に役割分担の全体像を示します。

私の案件でも当初はプロンプトに根拠テキストや手順まで詰め込んでいましたが、ナレッジへ分離してからは改版が「差し替えと再インデックス」だけになり運用が一気に楽になりました。

役割を「プロンプト＝方針」「ツール＝操作」「ナレッジ＝根拠」に固定すると品質と運用性が両立しますので、詳しい書き分けはプロンプトエンジニアリング入門も参考にしてください。

RAGの基本：『探してから答える』ので、元データの質がすべて

結論はシンプルで、RAGは「まず探してから答える」方式であり、元データの質がすべてです。

流れはクエリ解析→検索→関連チャンク取得→LLM生成で、どこかが粗いと正しい文章を組み立てられません。

例えば「出張の日当はいくら？」に対し、古い版の規程が混在したり分割が粗いPDFだと、誤額を引用する確率が上がります。

表現が「手当」「日当」「日額」とバラついても、適切なチャンキングとハイブリッド検索、リランク設定で回収率は改善します。

下図のフローを意識しつつ、インジェスト前のクリーニングと分割設計を行うのが成功の近道です。

実装手順の全体像はRAG構築のベストプラクティスや、Dify固有の手順はDify×RAG完全ガイドが参考になります。

Difyナレッジの種類と制限（対応フォーマット・容量・プラン差）

結論として、Difyはファイル、SaaS、Webクロールまで取り込めますが、PoCはプラン上限を前提に設計する必要があります。

容量やファイル数を見積もらずに試すと、再インデックスや分割戦略の見直しが発生し、スケジュールに響きます。

対応フォーマットと代表的な連携は以下のとおりです。

種別	代表フォーマット／ソース	補足
ファイル	PDF／TXT／Markdown／HTML／DOCX／JSON・JSONL／CSV／Excel	非構造・構造テキスト双方に対応
SaaS	Notion／GitHub.com	Notionは内部・パブリック連携、GitHub Enterpriseは現状注意
Web	Firecrawl／Jina Reader／WaterCrawl など	公式ドキュメントやヘルプサイトの定期同期に有効

プランごとの目安は次表のとおりで、詳細仕様は都度公式を確認してください（数値は2025年11月時点）。

プラン	ナレッジドキュメント数	ベクトルストレージ容量	ナレッジリクエスト制限
Sandbox（Free）	50ファイル	50 MB	10回／分
Professional	500ファイル	5 GB	100回／分
Team	1,000ファイル	20 GB	1,000回／分
Enterprise	カスタム	カスタム	カスタム

(出典: Plans & Pricing – Dify)
(参考: Create an AI Chatbot with Business Data in Minutes – Dify Docs)
(参考: Introducing Knowledge Pipeline – Dify Blog)
(参考: Dify x Tavily: Build Knowledge Pipelines from Live Web Data)

まずは高品質インデックスで小さく始め、上限に近づいたらEnterpriseやセルフホスト検討が現実的です。

どんなユースケースに向いているか：社内FAQ・カスタマーサポート・マニュアル検索

結論として、ナレッジは反復質問に根拠付きで即答する用途に強く、社内FAQや製品サポート、手順マニュアル検索に最適です。

社内総務・情シスFAQでは就業規則やIT手順書、ナレッジを最新化して従業員が自己解決できるようにします。

カスタマーサポートではヘルプセンター、リリースノート、障害情報を取り込んで一次回答の品質と速度を上げます。

営業向け提案資料検索では過去提案や事例スライドをナレッジ化し、提案の下書き生成を加速します。

技術者向けエラーコード対処集ではログや手順書の該当箇所を素早く参照し、ダウンタイム短縮に寄与します。

私のチームでも社内FAQ検索ボットを短期間でPoCし、問い合わせの3割がセルフサービス化できました（実装の要点はDify×RAG完全ガイドが参考になります）。

体系的に学びながら社内展開を急ぐなら、実務寄りカリキュラムのDMM 生成AI CAMPの活用も有効です。

PDF・Web・Notionなどからナレッジを登録する具体的な手順

当セクションでは、PDF・Web・Notion・GitHub・CSV/Excelといった多様な情報源から、Difyの「ナレッジ」へ登録・同期する具体的な手順を解説します。

なぜなら、RAGの精度はインジェスチョンとインデックス設計で大きく決まり、最初の設定で迷いをなくすことが成果に直結するからです。

Difyでナレッジベースを新規作成する手順（画面イメージ付き）
PDF・Word・テキストファイルからのアップロードとチャンキング設定
Webサイト・既存ヘルプセンターをまとめてナレッジ化する方法
Notion・GitHub・CSV/Excelなど外部SaaS／構造化データの取り込み
ナレッジパイプラインで取り込みと更新を自動化する

Difyでナレッジベースを新規作成する手順（画面イメージ付き）

サイドバーから数クリックで新規ナレッジを作成できるため、初期設定を正しく押さえると後工程が安定します。

理由は、名前・説明・インデックスモード（高品質／経済）などの基礎項目が、その後の検索方式と運用コストに直結するからです。

画面では「左サイドバー＞Knowledge＞New Knowledge」を開き、名称と説明を入力し、一般用途では高品質モードを選択します。

「作成」後に「検索設定」からハイブリッド検索やリランクの有効化も行え、精度・速度・コストのバランスを調整できます（参考: Create an AI Chatbot with Business Data in Minutes – Dify Docs）。

ナレッジの基本操作は全体像の記事も併読すると迷いが減ります（例: Difyの使い方・機能・料金ガイド）。

PDF・Word・テキストファイルからのアップロードとチャンキング設定

ローカルのPDF／Word／TXTはドラッグ＆ドロップで追加でき、アップロード直後に自動ETLが実行されます。

抽出・クリーニング・チャンキングの品質が検索精度を左右するため、チャンク戦略を明確にすることが重要です。

自動モードは汎用に適し、専門文書やFAQではカスタムモードでセパレータとサイズを調整します。

著者検証では日本語FAQは500〜800字、オーバーラップ50〜120字が回答の一貫性とコストのバランスに優れました。

図表の多い長大PDFは章見出しで大きく区切り、段落単位で再分割すると再現率が向上しました。

ETLの自動処理とチャンキングの考え方は公式ドキュメントと更新情報を確認してください（参考: Dify Docs・Releases · langgenius/dify）。

RAG全体の設計やパラメータ最適化の流れは解説記事が役立ちます（例: 【ノーコードでOK】Dify×RAG完全ガイド）。

体系的に学ぶなら実務向けのオンライン講座で基礎を固めるのも近道です（例: DMM 生成AI CAMP）。

Webサイト・既存ヘルプセンターをまとめてナレッジ化する方法

Webサイトやヘルプセンターはクローラー連携でまとめて取り込むのが最短です。

手作業のURL登録は抜け漏れと更新遅延を招くため、サイトマップや範囲指定で自動化する方が運用に強いからです。

DifyはFirecrawlやTavily／WaterCrawlと統合でき、ルートURLやsitemap.xml、クロール深さ、除外パスを指定して同期します（参考: Dify x Tavily・WaterCrawl連携 Issue）。

更新頻度はドキュメントの改訂リズムに合わせ、日次や週次などでスケジュールすると鮮度を維持できます。

方法	メリット	デメリット	向き
URL単位で区切る	ページ境界がそのまま文脈単位になり、引用元の提示が明瞭	ページ分割が細かすぎると検索の網羅性が落ちる	FAQ、製品別・機能別ヘルプ
巨大ページをチャンキング	セマンティックに広い範囲をカバーでき、同義語にも強い	引用範囲が広くなり、出典の粒度が荒くなる	概念説明、チュートリアル、長文ドキュメント

定期クロールの設計が実運用の鍵であり、FAQはURL単位、ナレッジ探索は巨大ページのチャンキングを選ぶと安定します。

セットアップ全体像は併読資料がわかりやすいです（例: Difyの使い方ガイド）。

Notion・GitHub・CSV/Excelなど外部SaaS／構造化データの取り込み

SaaSや構造化データは公式連携とファイル取り込みを使い分けると運用がシンプルになります。

NotionとGitHubは差分同期に強く、CSV／Excelは定型テーブルの検索や引用に適するからです。

Notionは内部インテグレーションまたはパブリックインテグレーションを設定し、対象ページに権限を付与して同期します（参考: Can’t connect to Notion・Cannot link Notion）。

GitHubは現状github.comのみ対応で、DocsやIssuesをFAQ源として活用できます（参考: GitHub Datasource Plugin）。

CSV／Excelは製品一覧や料金表の取り込みを想定し、列そのものを検索したい場合はナレッジへ、複雑なクエリは別ワークフローから参照する方式を併用します。

まず「検索に入れるか、API／ワークフローで引くか」を決めると、設計と運用コストがぶれません。

テーブル活用の考え方は周辺ノウハウも参考になります（例: Excel×AIデータ分析徹底ガイド）。

ナレッジパイプラインで取り込みと更新を自動化する

本番運用ではKnowledge Pipelineで取り込みからインデックスまで自動化するのが定石です。

手動アップロードはスケールせず、変更検知や再インデックスの抜け漏れが品質劣化を招くからです。

パイプラインではデータソース→ETL→インデックスをつなぎ、スケジュールやWebhookで定期同期します。

Introducing Knowledge Pipeline・Create Knowledge Pipeline – Dify Docs・Dify x Tavily）。

運用自動化はワークフロー連携でさらに広がるため、関連機能の理解も役立ちます（例: Dify Workflow完全ガイド）。

回答精度を上げるナレッジ設計：ベクトル／キーワード／ハイブリッド検索とチャンキングのベストプラクティス

当セクションでは、Difyのナレッジで回答精度を上げるために必要なインデックス設計、検索方式の使い分け、リランク設定、チャンキングの考え方、ユースケース別の構成パターンを体系的に解説します。

なぜなら、RAGは「正しいチャンクを正確に見つけて正しく渡す」工程が品質の大半を決めており、ここを最適化しない限りモデル性能を活かせないからです。

高品質インデックスと経済インデックスの違いと選び方
ベクトル検索・全文検索・ハイブリッド検索の使い分け
リランク（Rerank）モデルでノイズを減らし、正しいチャンクを選び抜く
良いチャンキング／悪いチャンキング：FAQ・マニュアルをどう分割するか
ナレッジ構成のパターン集：社内FAQ／カスタマーサポート／技術マニュアル

高品質インデックスと経済インデックスの違いと選び方

基本方針は「曖昧に問われる場面では高品質（ベクトル）を標準、明確な識別子前提のみ経済（キーワード）を選択」します。

高品質は埋め込み＋ベクトルDBで同義語や文脈の近さを捉え、FAQや規程のような自然文質問に強いからです。

一方で経済は転置インデックス中心でコストは安いものの、表記ゆれや言い換えで取りこぼしやすく、再現率の低下がUXを損ねるためです。

実務では「社内QA・契約レビュー＝高品質」「製品型番やエラーコードの完全一致検索＝経済」という切り分けが判断を早めます。

モード	技術基盤	得意	苦手	コスト	典型用途
高品質	Embedding + ベクトルDB	同義語・文脈一致	厳密完全一致のみの照合	中〜高	FAQ、社内規程、ナレッジ検索
経済	キーワード/転置インデックス	型番・固有名詞の一致	言い換え・曖昧表現	低	ログ検索、SKU/エラーコード

迷ったら高品質をデフォルトにし、指標付きのPoCで経済モードの妥当性を検証してから切り替えると安全です。

参考: Dify Docs: Create an AI Chatbot with Business Data・GitHub Issue #8403: economicalモードのリコール問題・Dify Blog: Introducing Knowledge Pipeline

ベクトル検索・全文検索・ハイブリッド検索の使い分け

結論は「ハイブリッド検索を基本に、セマンティック0.7：キーワード0.3から開始し、データ特性で重みを微調整」します。

ベクトル検索は文章の意味理解に強く、全文検索は固有名詞やエラーコードの完全一致に強いため、併用が取りこぼしを最小化するからです。

例えば「PCの持ち出しルールは？」ではベクトルのみだと表現違いを拾えますが、下図のようにハイブリッドだと規程の厳密語も加点され該当条文が上位に安定します。

固有名詞や型番主体のコーパスではセマンティック0.4：キーワード0.6などキーワード寄りにすると命中精度が上がります。

まずはハイブリッドでの重み探索をワークフローに組み込み、最適点を記録して再現運用に落とし込むのが近道です。

参考: Dify Blog: Knowledge Pipelineと検索設定・Dify Docs: Knowledge Pipelineガイド

リランク（Rerank）モデルでノイズを減らし、正しいチャンクを選び抜く

検索後にリランクを挟むと無関係チャンクが大幅に削減され、引用精度と回答安定性が向上します。

初段の検索は「近いけれど答えを含まない段落」を拾うことがあり、クロスエンコーダ系のリランクで関連度を再採点すると順位が改善するためです。

例えば「出張時の日当上限は？」でTopK=8・閾値0.6を設定すると、リランクなしでは雑多な費用節約Tipsが上位でしたが、リランクありでは規程第5条が1位になり引用も正確になりました。

Cohere Rerankは英語混在に強く、Jina Rerankは高速でコスト効率が良く、BGE-Rerankerはローカル運用の柔軟性が高いと評価されています。

推奨の初期値はTopK=8・スコア閾値0.6で、回答の空振りや過剰引用を見ながら段階的にチューニングすると良いです。

参考: Support custom reranker (GitHub Discussion)・Rerank設定未指定時の警告 (Issue #10552)・OpenAI互換Providerでのリランク登録 (Issue #1730)

良いチャンキング／悪いチャンキング：FAQ・マニュアルをどう分割するか

良いチャンキングとは「想定される一問に必要十分な答えが1チャンクで完結する」状態を作ることです。

LLMのコンテキスト制約とリランクの粒度最適化の観点から、過大チャンクはノイズを増やし、断片チャンクは答えの統合を阻害するためです。

良い例は「Q&Aを1問1答で分割したFAQ」や「章＋小見出し単位で表と説明を同居させたマニュアル」です。

悪い例は「100ページを丸ごと1チャンク」や「表と注記が別チャンクで切り離される分割」で、引用の誤りやハルシネーションを誘発します。

日本語PDFはレイアウト崩れが起きやすいため、Difyのカスタム分割や親子チャンキングで周辺文脈を同送し、筆者検証でも命名規則の問い合わせ正答率が分割最適化後に明確に改善しました。

まずは小さめの意味単位で作り、必要に応じて親子チャンキングで文脈を補完する設計から始めると安定します。

参考: Dify Docs: Knowledge Pipelineのチャンキング・Dify Blog: Introducing Knowledge Pipeline

ナレッジ構成のパターン集：社内FAQ／カスタマーサポート／技術マニュアル

用途別に文書を分割しタグとメタを設計すると、検索精度と運用性の両方が一気に上がります。

理由は、重み付け・フィルタリング・アクセス制御をメタ情報に委ねられ、RAGの可観測性も保てるからです。

社内FAQは「カテゴリ（総務/人事/情シス）×Q&A単位」、カスタマーサポートは「製品カテゴリ×トラブル事例×バージョン」、技術マニュアルは「機能別×操作手順×前提条件」などが定番です。

まずは小スコープでテンプレートに当てはめ、効果検証後にカテゴリやタグ粒度を拡張すると無理がありません。

実装手順は【ノーコードでOK】Dify×RAG完全ガイドやRAG構築のベストプラクティスも参考になります。

社内教育やテンプレ設計の内製化を進めるなら、体系的に学べるDMM 生成AI CAMPを使って短期で共通言語を整えるのも有効です。

ナレッジを使ったエージェント／チャットボットの作り方と、RAG前提のワークフロー構成

当セクションでは、Difyのナレッジを活用したチャットボット／エージェントの作り方と、RAGを前提にしたワークフロー設計の要点を解説します。

なぜなら、プロトタイプから本番運用まで精度と再現性を担保するには、ナレッジの紐づけ位置と検索設定、そして条件分岐やツール連携を含むフロー分解が成功の分水嶺になるためです。

シンプルなチャットボットにナレッジを紐づける基本ステップ
ワークフロー内で『知識検索』ノードを使う：条件分岐やツール連携の例
エージェントから別ワークフローを『ツールとして呼び出す』高度な構成
PoC〜本番運用までのステップ：小さく試し、段階的に広げる

シンプルなチャットボットにナレッジを紐づける基本ステップ

最短の作り方は「チャットアプリ／エージェント作成画面で対象ナレッジを選び、検索モードとTopK・引用表示を設定して回答テンプレートに組み込む」ことです。

この流れにすると、ハルシネーションを抑えつつ根拠リンクを出せるため、ユーザー体験と運用検証が同時に進みます。

画面遷移の例は「アプリ作成 → データソースでナレッジを追加 → 検索設定でベクトル／全文／ハイブリッドから選択 → TopKを3〜5に設定 → リランクのスコア閾値を0.6前後に調整 → 回答テンプレートで引用の表示をON」にする流れです。

回答テンプレートでは「まず結論 → 要点箇条書き → 引用とリンク」の順に設計し、引用は検索結果のタイトルとURLを併記すると検証が高速化します。

最小構成は1つのナレッジと1つのチャットアプリで成立し、まずこの形で精度と使い勝手を見極めるのが安全です。

詳しい操作観は公式ガイドも併せて確認してください（参考: Create an AI Chatbot with Business Data in Minutes）。

あわせて実装のコツは、内部解説の入門記事も参考になります。例えばRAGの基本設計は【ノーコードでOK】Dify×RAG完全ガイドが実務目線でまとまっています。

ワークフロー内で『知識検索』ノードを使う：条件分岐やツール連携の例

結論として、ワークフローではLLMノードの前に「知識検索」ノードを置き、関連スコアに応じた分岐とツール呼び出しを組み合わせると堅牢に動きます。

理由は、回答根拠が薄い入力を早期に検知し、人間エスカレーションや別ルートの処理に切り替えられるからです。

実例としては「①質問受信 → ②知識検索（TopKと閾値設定） → ③If-Elseで“該当なし”は人間対応へ → ④該当ありはLLMで回答生成 → ⑤引用付きで返答」という直列分岐が扱いやすいです。

著者の現場構成では「ナレッジ検索のキーワードを鍵に、社内のMAツールAPIへ顧客IDを問い合わせ → 属性に応じてタグ更新 → 更新結果を回答に反映」という自動化が成果につながりました。

このパターンは問い合わせ対応の正答率と“人間へのエスカレーション率”を可視化しやすく、改善ループを回すのに向いています。

実装時のノード強化は最新版アップデートも参考にしてください（参考: Workflow Major Update）。

より体系的な設計手順は【2025年版】Dify Workflow完全ガイドに詳説があります。

エージェントから別ワークフローを『ツールとして呼び出す』高度な構成

結論は、エージェントが「Workflow as a Tool」で別ワークフローをツール化して呼び出せるようにすると、Q&Aを超えた業務自動化が実現します。

根拠として、ワークフロー側に業務ロジックや社内API連携を閉じ込め、エージェントは意思決定とオーケストレーションに専念できるからです。

例として「ナレッジで規約条件を取得 → 顧客属性が条件を満たす場合のみ“クーポン発行ワークフロー”を起動 → 発行APIの結果を回答に埋め込み」という分離は安全で再利用性も高いです。

この分割により、セキュリティレビューや変更管理の境界が明確になり、監査対応や権限設計が楽になります。

機能の背景は公式のメジャーアップデート記事を参照してください（参考: Workflow as a Tool）。

設計思想や戦略の比較は【2025年版】Dify Agent完全ガイドが参考になります。

PoC〜本番運用までのステップ：小さく試し、段階的に広げる

結論は「小さく始め、計測し、確信が持てたら横展開する」段階導入が最短距離です。

理由は、ナレッジ品質やチャンキング、検索ハイパーパラメータは実データでしか最適化できないためです。

実務では「①1部署の社内FAQを対象にPoC → ②誤答の原因分析とチャンキング・リランク閾値の改善 → ③対象部署の拡大 → ④Slackや社内ポータルへ埋め込み」の順で進めると安定します。

KPIは“正答率”“利用回数”“人間エスカレーション率”“引用クリック率”を基本とし、週次でモニタリングすると効果が見えます。

3カ月スパンのロードマップをチームで可視化し、意思決定を早回しにしてください。

社内のスキルトランスファーには実践型の学習サービスも有効ですので、必要に応じてDMM 生成AI CAMPのコース活用も検討すると良いでしょう。

よくあるつまずきとトラブルシューティング：日本語PDF・更新反映・検索ミスなど

当セクションでは、Difyのナレッジ運用で実際に起こりがちな不具合と、その原因と対処を体系立てて解説します。

なぜなら、PDFの日本語抽出や更新反映の遅れ、検索の取りこぼしなどは設定と運用の“あるある”で、コツを押さえれば短時間で改善できるからです。

日本語PDFがうまく読めない・レイアウトが崩れるときの対処法
ナレッジを更新したのに回答に反映されないときのチェックリスト
『関係ない文書が引用される』『古い版が出てくる』ときの原因と対策
無料プランの制限（ファイル数・容量・リクエスト数）でハマりがちなポイント
トラブル時に確認すべきログ・モニタリングと、問い合わせ先

日本語PDFがうまく読めない・レイアウトが崩れるときの対処法

結論は、PDFは前処理でテキスト化し、Difyのチャンキング設定を調整することが最短の改善策です。

日本語PDFは縦書きや二段組、埋め込みフォントが原因で抽出が破綻しやすいため、そのままでは分割もうまくいきません。

スキャン由来の画像ベースPDFはOCRなしではテキストが得られないので、先にOCRで文字起こしを行います。

実務ではOCRでテキスト化し、元データのWordやMarkdownを直接ナレッジ化し、表はCSVやExcelに分離するだけで検索品質が安定します。

筆者は社内規程の日本語PDFをWordから再書き出し、Markdownに分割して再インデックスしたところ、引用の精度が一気に改善しました。

前処理のあとでチャンクサイズやセパレータ、親子チャンキングを見直すと、段落が崩れた箇所の引用も安定します（参考: Introducing Knowledge Pipeline – Dify Blog）。

ナレッジを更新したのに回答に反映されないときのチェックリスト

最初に見るべきは「インデックス再生成」と「検索モードの確認」です。

まず、該当ドキュメントのインデックス再生成が完了しているかを確認します。

次に、ナレッジの検索モードが経済モードに切り替わっていないかを点検します。

経済モードでは新しい段落が拾えないリコール漏れが報告されているため、高品質モードでの再インデックスを推奨します（参考: Issue #8768、Issue #8403）。

会話履歴の影響やキャッシュで古い回答が固定化される場合もあるため、新規セッションで再質問して切り分けます。

最終的には高品質モードで再インデックスし、ハイブリッド検索とリランクを併用して反映性と適合性を上げます（参考: Create an AI Chatbot with Business Data in Minutes）。

参考: Dify knowledge base new paragraphs cannot be recalled
参考: Economical mode recall test could not recall contents
参考: Dify Docs – Create Knowledge Pipeline

『関係ない文書が引用される』『古い版が出てくる』ときの原因と対策

TopKを絞り、リランクのスコア閾値を上げ、最新版だけを対象に検索する設定が効果的です。

TopKが大きすぎると関連性の薄いチャンクが混入し、回答のブレにつながります。

リランクの閾値が低いと適合度の低い候補まで通過してしまい、誤引用の温床になります。

ナレッジに旧版と新版が併存すると、表現が似ていても古い条文が選ばれることがあります。

例えば「2024年版と2025年版の就業規則」が混在する場合は最新版にタグを付け、旧版をアーカイブ用ナレッジに分離すると誤引用が減ります。

加えて、ハイブリッド検索でキーワード重みを適度に上げ、引用時に発行年や版数の明示を促すと安全です（参考: Support custom reranker）。

無料プランの制限（ファイル数・容量・リクエスト数）でハマりがちなポイント

SandboxでのPoCは「対象範囲を絞り、ファイルを分割しすぎない」設計が要諦です。

無料はドキュメント50件、ベクトル容量50MB、ナレッジリクエスト10回/分の制限があるため、量を詰め込みすぎるとすぐ頭打ちになります（出典: Dify Pricing）。

以下の簡易表で、ナレッジ関連の主要上限を確認してください。

プラン	ナレッジドキュメント数	ベクトル容量	ナレッジリクエスト/分
Sandbox (Free)	50	50MB	10
Professional	500	5GB	100
Team	1,000	20GB	1,000
Enterprise	カスタム	カスタム	カスタム

PDFを細切れにアップロードしすぎるとファイル上限に先に到達するため、章ごとなど適度な粒度に留めます。

まずは特定部署のFAQなど小さな範囲で動作確認し、見込みが立ったらProfessionalやTeamで本格検証に進むのが効率的です。

判断に迷ったら、プラン別の条件とベクトル消費を見ながら早めに上位化を検討し、検証を止めない計画にしましょう（参考: Dify無料でできること・制限、Difyの料金プランを徹底比較）。

社内のルール整備や教育を並行するなら、実務寄りのオンライン講座を活用すると移行が滑らかです（例: DMM 生成AI CAMP）。

トラブル時に確認すべきログ・モニタリングと、問い合わせ先

トラブルは「質問→検索→生成」の三点で事象を固定し、Difyの検索ログとエージェント実行ログで切り分けます。

ナレッジ検索ログでは、入力クエリとヒットしたチャンク、スコアが確認でき、検索段階の不備を早期に発見できます。

エージェントやワークフローの実行ログでは、プロンプト、ツール呼び出し、例外の詳細を追跡でき、生成段階の問題を局所化できます。

以下の簡易トレース図を参考に、どの段で意図とズレたかを可視化してください。

調査や問い合わせは、公式ドキュメント、GitHub Issues、コミュニティフォーラムを起点にし、再現手順と設定のスクリーンショットを添えると解決が早まります（参考: Dify x Arize: モニタリングと評価）。

参考: Create an AI Chatbot with Business Data in Minutes
参考: Dify GitHub Issues
参考: Dify Releases

セキュリティ・権限・運用設計：社内データを安心してナレッジ化するために

当セクションでは、Difyで社内データを安全にナレッジ化するための「セキュリティ要件」「権限設計」「運用ルール」「コスト管理」の考え方と実装ポイントを解説します。

なぜなら、RAGは社内の規程・契約・人事情報など機微な文書を扱うため、導入前に配備モデルやアクセス制御、更新・廃棄ルールを決めておかないと情報漏えいや監査指摘のリスクが高まるからです。

Difyのセキュリティ認証とデプロイメントオプション
SSO・RBACで『誰がどのナレッジにアクセスできるか』を設計する
社内ポリシー的に『アップロードしてよいか』を判断するチェックリスト
ナレッジの更新・バージョン管理・廃棄のルール作り
BYOK（自社APIキー利用）とコスト・リスクの考え方

Difyのセキュリティ認証とデプロイメントオプション

結論は、認証と配備モデルを正しく理解し、データの機微度に応じてCloud・VPC・セルフホストを使い分けることが安全運用の近道です。

理由は、DifyがSOC 2 Type IIやISO 27001を取得しGDPRにも準拠している一方で、データ主権や所在要件に応じた3つのデプロイメントから選べるためです（出典: Get Compliance Report | Dify）。

また、SaaSの即時性、VPCのデータ管轄性、セルフホストの完全閉域性という特性差が、取り扱える情報の上限値を左右します（参考: AWS Marketplace: Dify Premium、参考: Dify Enterprise (Global) – Microsoft Marketplace）。

以下の目安を基に初期方針を決めると、情報システム部門との合意形成が速く進みます。

配備モデル	想定利用	取り扱い目安
Cloud / SaaS	PoC～本番のスピード重視	社内FAQ・公開予定資料・一般社内文書
Enterprise / VPC（AWS/Azure）	本番・監査対応・データ所在の明確化	社内機微情報・部門別ナレッジ・一部PII
Self-Hosted（オンプレ/プライベートクラウド）	閉域・厳格な主権・長期保管	高機密・未公開製品情報・規制データ

データ所在地: VPC/セルフホストは保存先リージョンやDCを自社で指定可能です。
ログ保管: 監査要件に合わせ、保持期間や匿名化を事前定義します。
暗号化: 伝送/保存の双方で暗号化有効化と鍵管理ポリシーを明確化します。

詳細はDifyの解説記事でも整理しているので、選定前に確認してください（参考: 【最新2025年版】Difyのセキュリティ徹底解説）。

SSO・RBACで『誰がどのナレッジにアクセスできるか』を設計する

結論として、SAML/OIDC/OAuth2のSSOで本人確認を一元化し、RBACで最小権限を徹底する設計が最も安全で運用負荷も低くなります。

理由は、退職や異動時のアカウント無効化をIdP側で完結でき、ナレッジの閲覧・編集・管理権限をロールで統制できるからです（参考: Plans & Pricing – Dify）。

例えば、ロールは「管理者（ワークスペース設定/権限付与）」「編集者（コンテンツ更新）」「閲覧者（参照のみ）」の3階層から始めるとシンプルに運用できます。

さらに、社内全体向けFAQと人事部門専用ナレッジの権限を分離すると、誤配布や不用意な露出が防げます。

下図のように対象ユーザーと許可操作の交点だけを許すマトリクス化が有効です。

運用上の注意として、ナレッジごとに「公開ロール」「機密ロール」を分け、承認フロー後に公開ロールへ移す段階制御を推奨します（関連記事: プロンプトインジェクション対策の決定版ガイド）。

社内ポリシー的に『アップロードしてよいか』を判断するチェックリスト

結論は、データ機微度×導入形態（Cloud/VPC/セルフホスト）のマトリクスで「どこまで上げてよいか」を即断できるチェックリストを用意することです。

理由は、個人情報や未公開情報の扱いは規制や社内規程の影響が大きく、配備モデルの違いで許容範囲が明確に変わるためです（参考: Get Compliance Report | Dify）。

まずは以下の早見表から運用基準を決め、例外は情報システム部・コンプラと合議にします。

データ種別	推奨導入形態	補足
一般社内FAQ・公開予定の製品情報	Cloud/SaaS 可	アクセス制御と公開前レビューを徹底
一部PIIを含む業務手順	VPC 推奨	保存先リージョン指定と暗号化を必須化
秘匿性の高い契約書・未公開財務・人事評価	セルフホスト必須	閉域・監査ログ・保持期限を厳格運用

視覚マトリクスも併用すると現場判断が速くなります。

大規模展開時はVPC版やセルフホストでの移行計画もセットにするとスムーズです（参考: Dify×AWS徹底解説、参考: ローカル導入ガイド）。

ナレッジの更新・バージョン管理・廃棄のルール作り

結論として、更新責任者・周期・審査・廃棄を含むライフサイクル設計を決め、RAGの再インデックスを運用フローに組み込むことが重要です。

理由は、規程改定やFAQ刷新が反映されないと誤回答や監査指摘につながり、検索精度や引用整合性も低下するからです。

ToDoは「最新版タグ付け」「旧版のアーカイブ」「変更履歴ログ」「更新後の再インデックス」「不要ナレッジの廃棄判定」「バックアップ保持」の6点が基本です。

公開前にレビュー者を設定し、ロールごとに承認フローを分けると品質とスピードの両立ができます。

月次で見るべき項目は下表を参考に標準化してください。

項目	確認内容	担当/頻度
最新性	改定日/版数の妥当性	オーナー/月次
参照率	未参照ナレッジの棚卸	アナリスト/月次
精度	誤回答/苦情のレビュー	QA担当/月次
権限	閲覧/編集ロールの棚卸	管理者/月次
バックアップ	取得/リストア試験	運用/四半期

RAG精度の改善策と合わせて運用を回すと効果が高まります（関連記事: Dify×RAG完全ガイド、参考: AIハルシネーション対策）。

BYOK（自社APIキー利用）とコスト・リスクの考え方

結論は、BYOKでモデル利用料を直接管理しつつ、鍵の保管・権限・ローテーションを仕組み化すれば、コスト透明性とセキュリティを同時に満たせます。

理由は、Dify側のトークン課金が発生せずプロバイダーに直接支払うため、社内契約の割引や利用制限が活かせる一方、鍵漏えいリスクは自社の運用で抑える必要があるからです。

実装例としては「鍵はシークレットマネージャーで保管」「環境ごとにキー分離」「月次のキー更新」「使用量のメトリクス化としきい値アラート」「異常時の自動無効化フロー」を推奨します。

筆者のワークフローではモデル別コストをダッシュボード化し、閾値超過でSlack通知することで、PoCから本番移行時の急激なトークン増を素早く検知できました（参考: OpenAI APIの使い方（Python））。

BYOKは小さく始めて上限を決めるガードレール運用にすると、費用の暴走と鍵管理事故の双方を未然に防げます（関連記事: 生成AIのセキュリティ完全解説）。

まとめと次の一歩

本記事では、Difyナレッジの要点（ハイブリッド検索・リランク・チャンキング）、PDF/Notion/Webの取り込み手順、エージェント/ワークフロー化、そしてエンタープライズ運用のセキュリティ設計までを一気通貫で整理しました。

もう迷う必要はありません、あなたのデータは今日から“使える知識”に変わります。

まずはDify Cloudの無料Sandboxで小さなナレッジを作り、この記事どおりにボットを1つ動かして、精度と運用感を数時間で確かめましょう。

実務の型を素早く身につけるなら生成AI 最速仕事術がおすすめです。

PoCから本番運用への事例と説得材料は生成AI活用の最前線で補完してください。