はじめに
- 対象: DifyでRAGを触ったことがある／これからGraphRAGを試したい人
- 前提: DifyをセルフホストまたはCloudで基本操作・HTTP API公開まで触ったことがある
- ゴール: グラフDB特有の環境構築で増える作業を掴み、グラフDBとDifyの連携方式を整理する
要点
- Dify標準RAGは「チャンク + Embedding + ベクトルストア（
VECTOR_STORE）」前提で設計され、選択肢はベクトル検索向けストアのみ。Neo4jなどのグラフDBは差し替え対象に入っていない - GraphRAGをやると 外部で検索処理を実装し、Difyには“検索結果=チャンク”を返す構成になりやすい → 「DB」だけでなく API・取り込みETL・運用 が増える（ネットワーク/認証/監視/更新含む）
A: なぜグラフDBはベクトルDBのようにDifyと素直に連携できないか
A-1. Dify標準RAGの“差し替えポイント”は VECTOR_STORE
- Dify標準RAGは Knowledge/Dataset に取り込んだデータを チャンク化 → Embedding → ベクトル検索 の流れで扱う。セルフホスト設定では検索バックエンド（ベクトルストア）を
VECTOR_STOREで指定する前提 -
VECTOR_STOREの選択肢は weaviate / qdrant / milvus / pgvector / opensearch などの“ベクトル検索向けストア”。Neo4jなどのグラフDBはVECTOR_STOREの対象として想定されていない
A-2. GraphDBで欲しい検索は「ベクトル検索だけ」では閉じにくい
GraphDBでよく欲しくなる例:
- グラフ探索で関係性を辿る（引用、前提、同一概念、上下位など）→ 候補集合を組み立て
- 必要なら候補集合へベクトル検索やランキングを適用
- 最終的に「LLMに渡すチャンク」を整形
しかしDify標準RAGは、探索戦略や候補集合の組み立てを設定だけで差し替える設計ではない。そのためGraphRAGは 外部で検索処理を実装し、結果=チャンクを返す 形が現実的になりやすい。
A-3アーキテクチャ比較：増えるのは「API」と「DB」と「運用」
Dify標準（ベクトル検索RAG）
Dify（Knowledge / Dataset）
├─ チャンク化
├─ Embedding生成
├─ Vector Store（VECTOR_STOREで選択）
└─ 検索→LLM
Dify標準RAGは、チャンク化・Embedding・検索までをDify側の機能で進めやすい構造です。
セルフホストでは VECTOR_STORE に対応する値が多数あり、いずれもベクトル検索ストアとして扱える前提です。
GraphRAG（外部APIで接続：External Knowledge）
Dify（App / Workflow）
└─ External Knowledge API 呼び出し
│
▼
あなたのAPIサーバ（FastAPI等）
├─ 認証（API Key）
├─ 検索（グラフ探索＋必要ならベクトル検索＋リランキング等）
└─ 結果（チャンク）をDify仕様で返却
│
▼
グラフDB（例：Neo4j）＋（必要なら）ベクトル索引/別ストア
External Knowledge APIは「Difyとは独立して開発者が維持管理するナレッジベースに接続する」ためのAPIで、Difyは検索結果を受け取る側になります。
B: グラフDBをDifyから使う連携方式（HTTP Request / External Knowledge）
B-1. HTTP Request（Workflowで任意APIを叩く）
やること
- Dify Workflowの HTTP Request ノードで、自作APIや既存APIを呼ぶ
- 返ってきたデータをプロンプトに埋め込んで回答させる
良いところ
- API仕様を自由に決められる。Dify専用レスポンス形式に縛られない
- 取得→整形→プロンプト投げをWorkflow側で柔軟に組める
注意点
- Knowledgeの「検索」として統合されない。ワークフロー側で“精度”を組み上げる
- ネットワーク到達性（Dockerネットワーク、localhost問題、FW/Proxy/SSRF）に詰まりやすい
- 引用（chunk_id/page等）やスコアの扱いを自前で設計する
向いているケース
- PoCで自由度優先で試したい
- 取得結果を独自フォーマットで使いたい、Workflowで加工・合流して使いたい
B-2. External Knowledge（外部ナレッジベースとして登録）
やること
- Difyの Knowledge に「外部ナレッジベース」を登録
- Difyが外部APIの
POST /retrievalを呼び、返ってきた 検索結果=チャンク を利用する
良いところ
- Dify側で「外部ナレッジ」として扱える。アプリ側の取り回しが揃いやすい
- “検索結果=チャンク”を返す契約が固定されるため、利用の形が統一しやすい
注意点
- Dify仕様に合わせた
/retrievalAPI 実装が必要 - 認証（例:
Authorization: Bearer {API_KEY}）、エラーコード、返却JSONをDifyの期待に合わせる必要がある - Dify本体と外部API/DBの組み合わせで、更新時に確認が増える（運用に影響する）
向いているケース
- GraphRAGの検索を「ナレッジ」として複数アプリで再利用したい
- Dify側の使い方を標準に揃え、運用/説明を簡単にしたい
C: 普通のRAGとGraphRAGの違い
GraphRAG として「External Knowledge に外部検索APIを設定し、グラフDBで取得処理を実装する」ケースとする
| 領域 | Dify標準RAG | External KnowledgeによるGraphRAG |
|---|---|---|
| PDF取り込み・抽出 | Difyが標準で機能を用意 | 実装が必要 |
| チャンク設計 | Difyが標準で機能を用意 | 実装が必要 |
| Embedding生成 | Difyが標準で機能を用意 | 実装が必要 |
| Index作成/更新 | Difyが標準で機能を用意 | 実装が必要（例: Neo4jなど） |
| 検索API | 不要 | 実装が必要（/retrieval を実装） |
| 返却形式・整形 | Difyが標準で機能を用意 | 実装が必要（Dify仕様で返す） |
| ネットワーク到達性 | 自身で完結しがち | 公開疎通が必要（Dify→API） |
カテゴリD: 環境構築で増える作業（差し替えポイント）
D-1. 必須: Difyが呼べる検索APIの用意
External Knowledge を使うなら最低限これを用意する。
-
POST /retrievalを実装（Dify仕様） - 認証（例:
Authorization: Bearer {API_KEY}）を実装 - 入出力JSONをDify期待形式に合わせる（スコア/メタデータ/テキストなど）
- 失敗時の戻り値・エラーハンドリングも設計
D-2. 必須: ネットワーク到達性（Dify → API）
最初に疎通を確認。ここが最も詰まりやすい。
- Dify Cloud: 外部APIはインターネット到達できるURLにする
- セルフホスト: Difyコンテナから外部APIへ到達できるネットワーク設計にする
- HTTPS/証明書、FW、DNS、リバースプロキシ、SSRF対策の影響を確認
D-3. 必須: 取り込み・Ingestを自前で作る
External Knowledge は「検索結果=チャンクを返す」だけ。よって外部で用意する。
- PDF取り込み・テキスト抽出
- チャンク設計（粒度、かぶり、メタデータ）
- Embedding生成（モデル選定、再生成方針）
- グラフ格納（ノード/エッジ/ID設計、重複排除）
- 更新運用（差分取り込み、再索引）
D-4. 必須: Index設計・更新はDifyに任せられない
- 標準RAGではDifyが担う「検索に必要な索引作成/更新」が外部側へ移る
- Neo4j等でベクトル索引を作るなら、Embedding次元・索引設定との整合を取る
- 索引更新のタイミング（バッチ/イベント/再計算）を決める
D-5. 必須: 運用・監視（ログ・回帰）
- APIログ（query/top_k/件数/レイテンシ/エラーなど）
- タイムアウト・リトライ方針
- Dify更新時の回帰確認（I/O仕様・認証・ネットワーク）
カテゴリE: まず動かすための最小構成（PoCチェックリスト）
E-1. External Knowledge で試す
- Dify を起動（Cloudでもセルフホストでも可）
- グラフDB（例: Neo4j）を起動
- 外部APIを起動（例: FastAPI）
-
POST /retrievalを実装 - 認証（例: Bearer API Key）を通す
- Difyに外部ナレッジベースとして登録し、疎通を確認
- 固定データ（例: TSV/CSV）で“検索結果=チャンク”が返ることを確認
- Embedding/索引の高度化を段階的に進める
E-2. HTTP Request で試す
- Workflowの HTTP Request ノードで外部APIを呼ぶ
- 返却JSONをプロンプトに埋め込める形に整形
- Dockerネットワーク/到達性を確保
- エラー時の挙動（空返し/フォールバックなど）を決める
カテゴリF: よくある落とし穴 / FAQ
F-1. 「Neo4jをDifyのVECTOR_STOREに設定すればよいのでは？」→ できない
-
VECTOR_STOREはベクトル検索ストアの選択肢を前提としている - Neo4jなどのグラフDBは想定外。External Knowledge / HTTP Request に切り替える
F-2. 「どちらの連携方式を選ぶべき？」
- PoCで自由度優先: HTTP Request
- “ナレッジとして”統合したい: External Knowledge
- どちらでも、最初に疎通（ネットワーク/認証）を通す
まとめ
- Dify標準RAGは
VECTOR_STORE前提で整備され、グラフDBは差し替え対象に含まれない → グラフDBを使うGraphRAGは 外部実装API が前提になりやすい - 連携方式は2つ（HTTP Request / External Knowledge）。PoC自由度ならHTTP、ナレッジ統合ならExternal
- 増える作業は主に 外部API・疎通・取り込みETL・索引更新・運用