Difyナレッジの使い方｜PDFでRAGを作る手順と検索精度を上げる設定

2026年5月6日2026年8月10日

SkillStack Lab（スキスタ）運営者のスタックです。

Difyを使って、「就業規則や社内マニュアルを検索して答えてくれる社内AIを作りたい」と考えていませんか。

Difyには「Knowledge（ナレッジ）」という機能があり、PDFやWord、Excelなどの自社データを検索対象にしたRAG（検索拡張生成）を構築できます。

ただし、ファイルをアップロードしただけで高精度な社内AIが完成するわけではありません。

回答品質を左右するのは、元データの整理、チャンク構造、インデックス方法、検索方式、TopK、Score Threshold、Rerank、検索テストなどの組み合わせです。

さらに2026年現在のDifyには「Knowledge Pipeline」があり、データの取得から抽出、チャンク分割、インデックス、検索テストまでを一つの処理フローとして設計できるようになっています。

この記事では元情シス・管理部門の実務視点から、Difyナレッジの基本的な使い方、PDFを使ったRAGの作り方、Parent-childやHybrid Searchの選び方、検索精度を改善する手順、運用開始後の更新・権限管理まで順番に解説します。

※本記事には広告・アフィリエイトリンクが含まれています。Difyの画面、機能、プラン、上限などは変更される場合があります。

この記事で分かること

Dify KnowledgeとRAGの基本的な仕組み
PDFなどの社内文書からナレッジを作る手順
General・Parent-child・Q&Aの使い分け
Vector Search・Full-text Search・Hybrid Searchの違い
Retrieval Testingで検索精度を改善する方法
Metadata・更新・アクセス権まで含めた実務運用の注意点

Difyを活用して独自の資料から正確に回答する社内専用AIを構築する手順の解説資料タイトル

Difyナレッジとは？RAGの基本を理解する

DifyのKnowledgeは、自社が持っている文書や外部データを検索可能な状態にし、AIアプリから利用するための機能です。

たとえば通常の生成AIは、あなたの会社の就業規則や経費精算ルールを自動的に知っているわけではありません。

そこで、質問に関連する自社文書を先に検索し、その検索結果をLLMへ渡して回答を生成させます。

この仕組みがRAG（Retrieval-Augmented Generation／検索拡張生成）です。

処理	役割
1．質問	社員が「結婚した場合の慶弔見舞金はいくら？」などと質問する
2．Retrieval	Difyが質問と関連する社内文書のチャンクを検索する
3．Context	検索結果を質問と一緒にLLMへ渡す
4．Generation	LLMが取得した情報を参考に回答を生成する

最新のKnowledge機能は、Dify公式Knowledgeドキュメントで確認できます。

RAGを使ってもハルシネーションはゼロにならない

ここは最初に理解しておきたいポイントです。

RAGを使えばAIが絶対に正しい回答を返すわけではありません。

RAGでは質問に関連する情報をLLMへ追加できるため、自社ルールに基づいた回答を作りやすくなります。

しかし、次のような原因があれば誤回答は起こり得ます。

必要な文書がナレッジへ登録されていない
古い規程が残っている
適切なチャンクが検索されない
関係の薄いチャンクまで取得している
取得した情報をLLMが誤って解釈する
ナレッジに答えがないのにLLMが一般知識から補ってしまう

「古い規程を答えた」＝すべてハルシネーションではない

古い文書が正常に検索され、その内容に沿って回答している場合、主な問題はAIの幻覚ではなく「データの鮮度・版管理」です。RAGではモデルだけでなく、検索対象となるデータの品質管理が重要です。

Difyナレッジの作り方は2通りある

2026年現在、Difyで自社用のKnowledgeを作る場合、初心者向けの「Ready-to-use Knowledge Base」と、処理方法を細かく設計する「Custom Knowledge Base（Knowledge Pipeline）」があります。

方法	向いているケース	特徴
Ready-to-use	まずRAGを試したい	データを取り込み、チャンクや検索方式を設定して短時間で作成できる
Knowledge Pipeline	本格運用・複雑な文書処理	データ取得、抽出、加工、チャンク、Knowledgeへの登録まで視覚的に設計できる

初めてDifyを触る場合は、まずReady-to-useでRAGの基本を理解する方法で十分です。

大量のOffice文書を整形したい、複数のデータソースを統合したい、独自の前処理を行いたい、といった要件が出てきたらKnowledge Pipelineを検討します。

知識の登録、AIの構築、質問と回答の3つの手順で自社専用AIを構築する全体フロー

Difyナレッジの基本的な使い方

Step1：Knowledgeを新規作成する

Dify上部の「Knowledge」から「Create」を選択します。

最初に簡単なRAGを作るなら「Create a ready-to-use knowledge base」を選びます。

現在のDifyでは、Ready-to-use Knowledge Baseを作成した後にデータソースそのものを変更することはできないため、ファイルアップロードなのか、別のデータソースを使うのかは作成時に確認してください。

最新手順はDify公式「Upload Local Files」で確認できます。

Step2：PDF・Word・Excelなどを取り込む

ファイルをデータソースにする場合は、対象ファイルをアップロードします。

Difyの現在のKnowledge Pipelineでは、PDF、XLSX、DOCXなどのOffice系ファイルを扱えます。

Difyの画面から対象のPDFを選択してアップロードし、自動分割・保存される手順の図解

ただし、「ファイルをアップロードできる」と「中身をきれいに抽出できる」は別の話です。

複雑な表、図、段組み、スキャン画像を多く含むPDFでは、抽出結果を実際に確認してください。

Knowledge PipelineではDocument Extractorを選択でき、用途によってMarketplaceの抽出ツールを組み合わせることもできます。

PDFだからそのままでよいとは限らない

表組みが崩れている、ヘッダー・フッターが毎ページ混入する、画像として保存された文字が多い、といった文書では検索用データの品質が下がる場合があります。アップロード後のチャンク内容まで確認してください。

Step3：チャンク構造を決める

次に、文書をどの単位で検索するかを決めます。

Difyでは現在、代表的に次のような構造があります。

チャンク構造	仕組み	向いているデータ
General	文書を1階層のチャンクへ分割して、そのチャンクを直接検索・取得	FAQ、短い規程、独立した説明文
Parent-child	小さな子チャンクで検索し、該当する大きな親チャンクをLLMへ返す	マニュアル、規程、技術資料など前後の文脈が重要な文書
Question & Answer	質問と回答の組で検索	FAQ一覧、問い合わせ履歴など

Parent-childは非常に便利ですが、すべてのKnowledgeで最初から選べばよいわけではありません。

Dify公式でもGeneralはシンプルで自己完結した内容、Parent-childは文脈を必要とする情報密度の高い文書に向くと説明しています。

現在の詳細はDify公式「Configure the Chunk Settings」で確認できます。

Parent-childはなぜ検索精度を改善しやすい？

Parent-childでは、検索に使う部分とLLMへ渡す文脈を分けられます。

たとえば就業規則の「慶弔休暇」という章が長い場合、章全体を1つの大きなチャンクとして検索すると、ユーザーの短い質問との意味的な距離が大きくなる場合があります。

逆に1文ずつ細かく分割すると検索しやすくなりますが、「誰が対象なのか」「何日取得できるのか」といった前後関係が欠ける場合があります。

Parent-childでは、小さな子チャンクを検索に利用し、ヒットした子チャンクを含む大きな親チャンクを回答用のコンテキストとして返します。

小さく探して、大きく渡す

これがParent-childの基本的な考え方です。細かな検索精度と、回答に必要な文脈の両立を狙います。

ただし、短いFAQや1項目で意味が完結している文書までParent-childにする必要はありません。

まずGeneralと比較し、Retrieval Testingで実際の質問に対する検索結果を確認して決める方法をおすすめします。

Index Methodと検索方式を設定する

チャンク構造を決めたら、検索するためのインデックス方法を設定します。

High QualityとEconomicalの違い

DifyのReady-to-use Knowledge Baseには「High Quality」と「Economical」の2種類のIndex Methodがあります。

Index Method	特徴
High Quality	Embeddingモデルでチャンクをベクトル化し、Vector・Full-text・Hybrid Searchなどを利用できる
Economical	チャンクごとのキーワードを利用したInverted Indexを中心に検索する

社内RAGで意味の近い表現まで検索したい場合は、まずHigh Qualityを比較しやすいです。

なお、High Qualityで作成したKnowledgeを後からEconomicalへ変更することはできないなど、変更方向にも制約があります。作成時の最新仕様を確認してください。

Vector Search・Full-text Search・Hybrid Search

High Qualityでは現在、主に3つの検索方式を選択できます。

検索方式	特徴	向いている質問
Vector Search	質問とチャンクの意味的な近さで検索する	言い換えや曖昧な自然文が多い
Full-text Search	文字列・キーワードを中心に検索する	製品名、規程名、社員コードなど正確な単語が重要
Hybrid Search	VectorとFull-textを組み合わせる	自然文と固有名詞が混在する社内検索

たとえば「パソコンが壊れた」と「PC故障対応マニュアル」のように表現が異なる場合は、意味を使うVector Searchが役立ちます。

一方、「旅費規程第12条」「AB-1234」のように文字列そのものが重要ならFull-text Searchも有効です。

実際の社内質問では両方が混ざるため、Hybrid Searchを候補にし、検索テストで比較すると判断しやすくなります。

TopK・Score Threshold・Rerankを調整する

検索方式だけでなく、どれだけのチャンクをLLMへ渡すかも回答品質に影響します。

設定	役割	注意点
TopK	何件の検索結果を取得するか	増やしすぎると関係の薄い情報まで渡る場合がある
Score Threshold	一定の関連スコア未満を検索結果から除外する	高くしすぎると必要な情報まで落とす可能性がある
Rerank	一度取得した候補を別モデルで並べ替える	精度改善が期待できる一方、別途モデル利用コスト等が発生する場合がある

Dify公式の現在のVector SearchではTopKの初期値は3、Score Thresholdの初期値は0.5ですが、「0.7以上なら正しい」「0.5なら危険」といった共通の安全基準ではありません。

文書、Embeddingモデル、質問の種類によってスコアの出方は変わるため、次に説明するRetrieval Testingで調整してください。

現行の設定項目はDify公式「Specify the Index Method and Retrieval Settings」で確認できます。

Retrieval Testingで検索精度を確認する

Knowledgeを作ったら、すぐに全社員へ公開するのではなく、必ず検索テストを行います。

Difyには現在「Retrieval Testing」があり、実際の質問を入力して、どのチャンクが検索されるか確認できます。

事実に基づく回答と、資料にない場合に「わかりません」と正しく答えるAIの動作確認例

検索テストでは、管理者が考えたきれいな質問だけでなく、実際の社員が入力しそうな表現を試してください。

正式名称：「育児介護休業規程の対象者は？」
会話表現：「子どもが生まれたら休める？」
省略語：「育休って何日？」
表記揺れ：「PC」「パソコン」「端末」
答えが存在しない質問

現行DifyではRetrieval Testingで変更した検索設定はテストセッションだけに適用されるため、複数条件を試して比較できます。

また、KnowledgeのRecordsにはテストだけでなく、連携したアプリから実際に行われた検索も記録されます。

詳細はDify公式「Test Knowledge Retrieval」を確認してください。

検索で外れたら「原因」を分けて考える

欲しい文書が上位に出なかったとき、すぐにScore Thresholdだけを変更するのはおすすめしません。

次の順番で切り分けると改善しやすくなります。

そもそも正しい文書が登録されているか
抽出されたテキストが壊れていないか
チャンクが適切な位置で分割されているか
GeneralとParent-childのどちらが合うか
Vector・Full-text・Hybridのどれが合うか
TopK・Thresholdを調整する必要があるか
Rerankを利用すると改善するか

RAGのチューニングは、1つの数字を探す作業ではなく、「なぜ欲しい情報が検索されなかったのか」を順番に確認する作業です。

検索しやすい元文書を作ることも重要

目次の整理、文章による説明、一問一答形式の追加など、AIが情報を探しやすくするための資料作成のポイント

Dify側の設定だけで解決しようとせず、元文書そのものも見直してください。

人間にとって読みにくい文書は、RAGでも扱いにくくなりがちです。

見出しを明確にする
「これ」「その場合」など参照先が曖昧な表現を減らす
重要な条件を表だけに閉じ込めない
文書タイトル・対象者・改定日を明記する
同じ内容の旧版を混在させない
FAQなら質問と回答を明確に分ける

DifyのKnowledge Pipelineには、Office文書をMarkdownへ変換する組み込みテンプレートや、Q&Aデータを処理するテンプレートも用意されています。

たとえばCSVやExcelで「質問」「回答」が整理されている過去のFAQなら、通常の長文チャンクよりQuestion & Answer形式が合うケースがあります。

Metadataで検索対象を絞り込む

Knowledgeが大きくなってきたら、Metadataも重要になります。

Difyでは文書へMetadataを設定し、検索対象を条件で絞り込めます。

Metadata例	用途
department	総務、人事、経理などを区別
document_type	規程、マニュアル、FAQなどを区別
status	現行、廃止、下書きなどを区別
effective_date	施行日・改定日を管理

たとえば「現行の人事規程だけ」を検索対象にすると、旧版や別部門の文書が検索候補へ混ざるのを減らせます。

現在のMetadata機能ではカスタム項目を作成し、文書ごとに値を付与できます。詳しくはDify公式「Manage Document Metadata」で確認してください。

Metadata Filtering＝アクセス権限管理ではない

検索対象を絞るMetadataは検索精度の改善には役立ちますが、それだけで「一般社員は人事文書を絶対に取得できない」という認可設計になるとは考えないでください。機密情報はアプリ・Knowledge・データソース自体の分離を含めて設計します。

SharePointの文書を利用する場合の権限設計については、Dify×SharePoint連携と権限設定で詳しく解説しています。

KnowledgeをAIアプリへ接続する

検索テストで必要な情報を取得できることを確認したら、KnowledgeをChatbotやWorkflowなどへ組み込みます。

Ready-to-use Knowledge BaseをChatbotへ接続する基本的な流れは次のとおりです。

StudioでChatbotなどのアプリを作成する
Contextへ作成したKnowledgeを追加する
必要に応じてMetadata Filteringを設定する
Retrieval Settingsを設定する
Citation and Attributionを有効にする
Debug and Previewで質問をテストする
問題がなければPublishする

Dify公式でも、Knowledgeを利用するAIアプリではCitation and Attributionを有効にし、回答の元になった文書やチャンクを表示できます。

社内RAGでは、回答だけを表示するより「どの文書を根拠にしたのか」も確認できる設計にする方が実務で使いやすくなります。

現在の手順はDify公式「Integrate Knowledge within Apps」で確認してください。

「分からない」と答えられる設計にする

社内FAQでは、何でも回答するAIより「根拠がないときは回答しないAI」の方が安心して利用できます。

たとえばプロンプトに、取得したKnowledgeに十分な根拠がない場合は推測せず、担当部署への確認を案内するルールを設定します。

ただし、プロンプトを書くだけで誤回答を完全に防げるわけではありません。

検索設定、文書管理、プロンプト、モデル、テストを組み合わせて精度を上げていく必要があります。

管理部門向けRAGの基本方針

規程に書いてある事実はAIで一次回答
規程に答えがなければ推測しない
個別判断が必要なら担当部署へ案内
可能なら回答根拠の出典を表示

運用開始後は「最新データを保つ仕組み」が重要

RAGは一度作ったら完成ではありません。

就業規則、経費精算ルール、システム手順などは変更されます。

古い文書を残したまま新しい文書も追加すると、検索時に旧版が取得される可能性があります。

そこで本番運用では、少なくとも次のルールを決めておきます。

誰が文書を追加・更新するか
改定時に旧版をどう扱うか
ファイル名やMetadataのルール
更新後に誰がRetrieval Testingを行うか
誤回答を報告する窓口
定期的に検索ログを確認する担当者

Difyでは現在、文書やチャンクの追加・編集・削除ができ、Knowledge APIからプログラムで管理することもできます。

文書数が少ないPoCでは手動更新でも構いませんが、SharePointなどを正式な文書管理基盤として利用している場合は、自動連携まで検討すると運用負荷を下げられる可能性があります。

SharePointとの現在の連携方法は、Dify×SharePoint連携ガイドで詳しく解説しています。

社内で使うなら権限設計も忘れない

RAGの検索精度と同じくらい重要なのが、誰に何を検索させるかです。

全社員向け就業規則と、人事評価資料、給与情報、役員会議資料を同じKnowledgeへ安易に混在させるのは避けた方がよいでしょう。

AIに「機密情報は答えないで」とプロンプトで書くだけでは、認可の代わりにはなりません。

閲覧者によって情報範囲が違う場合は、Knowledgeやアプリを分ける、外部側の認証・権限と連携するなど、システム側で境界を作ります。

DifyをTeamsから社員に利用させる方法は、DifyとTeamsをPower Automate・APIで連携する方法で解説しています。

Difyナレッジでよくある失敗と改善方法

よくある状態	まず確認すること
欲しい文書が検索されない	抽出結果、チャンク、検索方式
関係ない文書が大量に出る	TopK、Threshold、Metadata、Rerank
回答が途中の文脈を失う	Parent-child、チャンクサイズ
固有名詞を拾えない	Full-textまたはHybrid Search
言い換えに弱い	VectorまたはHybrid Search
古い規程を回答する	旧版削除、Metadata、更新運用
答えがないのに推測する	検索品質、プロンプト、回答フロー