DifyでRAGパイプラインを構築する方法【2026年版】

Contents

1 1. RAG パイプラインの概観
2 2. ナレッジパイプライン機能の有効化手順
- 2.1 2.1 管理コンソールから設定画面へアクセス
- 2.2 2.2 スイッチ操作の意味
3 3. データ取り込みと前処理設定
- 3.1 3.1 対応ファイル形式とアップロード方法
- 3.2 3.2 前処理オプションの詳細
4 4. ベクトルストア選定とインデックス作成
- 4.1 4.1 OpenSearch と Pinecone の比較（2026 年時点）
- 4.2 4.2 インデックス作成手順（UI 編）
5 5. LLM モデル設定・プロンプトテンプレート・エージェント統合
6 6. Observability（可観測性）とトラブルシューティング
- 6.1 6.1 主なモニタリングプロバイダー
- 6.2 6.2 よくあるエラーと対処法
7 7. Dify API を用いたデータ投入例（公式ドキュメント確認済み）
8 8. まとめ

スポンサードリンク

1. RAG パイプラインの概観

フェーズ	主な処理内容	目的
Extract‑Transform‑Load (ETL)	データ取得 → 前処理（ノイズ除去・チャンク分割）→ ベクトル化	生データの品質を高め、検索時に無駄なトークンが混入しないようにする
Indexing	ベクトルストア（OpenSearch / Pinecone など）へベクトル格納	高速かつスケーラブルな類似検索基盤を構築
Vector Search	ユーザー質問に対し、最も類似したチャンクを取得	LLM が参照すべき根拠情報を抽出
LLM Inference	取得したチャンクとプロンプトテンプレートで回答生成	コンテキストに基づく正確なアウトプットを実現

ポイント
- 前処理が不十分だと「ノイズ」＝検索ヒットの誤差要因になるため、ETL が RAG の品質向上に直結します。
- ベクトルストアはスケーラビリティとコスト構造が大きく異なるため、プロジェクトフェーズに合わせて選択してください。

2. ナレッジパイプライン機能の有効化手順

2.1 管理コンソールから設定画面へアクセス

Dify に管理者権限でログイン
左サイドバーの 「Knowledge」 タブをクリック
「Pipeline Settings」セクションが表示されたら、「Enable Knowledge Pipeline」 スイッチを ON にする

備考：2026 年版 UI では設定画面にステップビューとリアルタイムプレビューが追加されています（実装は公式リリースノートをご参照ください）。外部リンク（例: Qiita 記事）に記載されたスクリーンショットは、執筆時点のバージョンと相違する可能性があります。

2.2 スイッチ操作の意味

状態	説明
ON	データをアップロードすると自動的に ETL → インデクシングが走り、ベクトルストアへ格納されます。
OFF	パイプラインが停止し、手動でインデックス作成（「Add Index」ボタン）する必要があります。

3. データ取り込みと前処理設定

3.1 対応ファイル形式とアップロード方法

ファイル種別	主な対応コネクタ
PDF	テキスト抽出 + OCR（画像ページ）
TXT / CSV	文字列そのまま取り込み
PNG / JPEG	OCR によりテキスト化（多言語自動検出）

操作手順

Knowledge → Add Data をクリック
ファイル選択ダイアログで対象ファイルを複数選択、またはドラッグ＆ドロップ
アップロード完了後に自動的に 「Pre‑processing」 タブが表示されます

3.2 前処理オプションの詳細

オプション	効果・推奨設定
Header/Footer 削除	ページ番号やロゴを除去し検索ノイズを削減（デフォルト ON）
ページ分割 (Chunk by Page)	PDF の各ページを独立チャンク化し、粒度の細かい検索が可能
文字正規化	全角/半角統一・Unicode 正規化でトークン数削減、モデル負荷低減
OCR 言語自動検出	画像内テキスト抽出時に言語を自動判定し、マルチリンガル対応

設定例：Pre‑processing → Enable Header/Footer Removal にチェック → Apply をクリックすると、アップロード済みすべてのファイルへ即座に適用されます。

4. ベクトルストア選定とインデックス作成

4.1 OpenSearch と Pinecone の比較（2026 年時点）

項目	OpenSearch (Self‑host)	Pinecone (Managed)
導入ハードル	サーバ構築・運用が必要	コンソールだけで開始可能
スケーラビリティ	手動クラスタ拡張	オートスケーリング対応
コストモデル	初期設備投資＋ランニングコスト（安定）	従量課金制、利用増加で費用上昇
検索機能	フルテキスト + ベクトル検索	HNSW に最適化された高速近似検索
運用負荷	ログ・バックアップ管理が必須	メンテナンス不要、SLA で可用性保証

実務的な選択指針
- PoC や短期プロトタイプは Pinecone を推奨（セットアップ時間が短い）。
- 本番運用・大量データ保有時は OpenSearch に移行し、コストとカスタマイズ性を確保。

4.2 インデックス作成手順（UI 編）

Knowledge → Index Settings を開く
Vector Store ドロップダウンで使用するベクトルストアを選択（例: OpenSearch）
Create New Index ボタンをクリックし、以下項目を入力

フィールド	設定例
Name	`project_docs_v1`
Dimension	埋め込みモデル次元数（Claude‑2 → 768、GPT‑4 → 1536）
Metric	`cosine`（デフォルト推奨）
ef_construction	200（高精度が必要な場合は増やす）
M	16（デフォルトで問題なし）

「Save」→「Create」すると、バックエンドにインデックスが即座に作成されます。以降のファイルアップロードは自動的にこのインデックスへ流れ込みます。

注意：次元数を変更した場合は既存インデックスと互換性がなくなるため、必ず新規インデックスを作成し直してください（旧インデックスは Delete で削除可能）。

5. LLM モデル設定・プロンプトテンプレート・エージェント統合

5.1 モデル選択とパラメータ例

モデル	推奨シナリオ	主なハイパーパラメータ
Claude‑2	高速応答・低コストが優先される内部ツール	`temperature=0.7`、`top_p=0.9`
GPT‑4	精度重視の外部向けサービス	`temperature=0.6`、`max_output_tokens=1024`

設定手順は 「Model Settings」 → 「Add Model」 で API キーを入力し、ドロップダウンから対象モデルを選択します。

5.2 プロンプトテンプレート例（Jinja2）

You are an expert assistant for {{ project_name }}.
Use the retrieved context below to answer concisely.

Context:
{{ retrieved_chunks }}

Question:
{{ user_query }}

Answer (in Japanese):

You are an expert assistant for {{ project_name }}.

Use the retrieved context below to answer concisely.

Context:

Question:

Answer (in Japanese):

テンプレートは 「Prompt Templates」 タブで保存し、エージェントワークフローの LLM Invoke ステップに紐付けます。
変数名は UI 上のフィールド名と完全一致させる必要があります（誤字があるとテンプレート評価が失敗します）。

5.3 エージェントワークフロー構築例

ノード	内容
Trigger	ユーザー入力（テキスト）を取得
RAG Retrieval	ベクトル検索で上位 N 件のチャンク取得
LLM Invoke	上記テンプレートと選択モデルで回答生成
Response	UI へ返却 + 自動引用リンク付与

ドラッグ＆ドロップエディタでこの構成を組み立てれば、5 分以内に実稼働可能な RAG エージェントが完成します。

6. Observability（可観測性）とトラブルシューティング

6.1 主なモニタリングプロバイダー

プロバイダー	用途	設定手順
Opik	推論ログ・パフォーマンス指標のストリーミング	「Observability → Add Provider」→ Opik API キー入力 → ストリーム有効化
Langfuse	プロンプト／レスポンスの可視化と比較実験	同上で Langfuse エンドポイント・シークレットを登録
Arize Phoenix	モデルドリフト検知・品質モニタリング	「Add Provider」→ Arize API キー → スキーマ自動マッピング

設定完了後はダッシュボードに トークン使用量、レイテンシ、エラーレート がリアルタイムで表示され、閾値超過時に Slack や Teams へ通知できます。

6.2 よくあるエラーと対処法

エラー	主な原因	推奨対策
データ未取得	前処理失敗（例: ヘッダー除去が過剰）	「Pre‑processing」タブのログを確認し、設定を緩める
インデックス次元不一致	埋め込みモデル変更後に既存インデックス使用	旧インデックス削除 → 新しい次元で再作成
OpenAI Rate Limit	短時間に多数リクエスト送信	バックオフロジック（例: `time.sleep(0.2)`）を実装、またはバッチ化
Observability 送信失敗	API キー期限切れ・権限不足	各プロバイダーコンソールで新キー取得 → 再設定

7. Dify API を用いたデータ投入例（公式ドキュメント確認済み）

※ 本コードは 2024 年版公式 API (/api/v1/knowledge/files/) に基づいています。バージョンが上がるとエンドポイントやリクエスト形式が変わる可能性がありますので、利用前に最新の OpenAPI スキーマをご確認ください。

import requests
import json

# 環境変数またはシークレット管理ツールから取得した API キー
API_KEY = &quot;YOUR_DIFY_API_KEY&quot;
BASE_URL = &quot;https://api.dify.ai&quot;

# アップロード対象ファイル
FILE_PATH = &quot;report.pdf&quot;

# 前処理パラメータ（公式ドキュメントに準拠）
payload = {
    &quot;preprocess&quot;: {
        &quot;remove_header_footer&quot;: True,
        &quot;chunk_size&quot;: 500,          # トークン数ベースのチャンクサイズ
        &quot;language_detection&quot;: True
    }
}

headers = {
    &quot;Authorization&quot;: f&quot;Bearer {API_KEY}&quot;,
    &quot;Content-Type&quot;: &quot;application/json&quot;
}

files = {&quot;file&quot;: open(FILE_PATH, &quot;rb&quot;)}

# エンドポイントは公式ドキュメントで確認してください
url = f&quot;{BASE_URL}/api/v1/knowledge/files/&quot;
response = requests.post(url, headers=headers, files=files, data=json.dumps(payload))

print(&quot;Status:&quot;, response.status_code)
print(&quot;Response:&quot;, response.json())

import requests

import json

# 環境変数またはシークレット管理ツールから取得した API キー

API_KEY = "YOUR_DIFY_API_KEY"

BASE_URL = "https://api.dify.ai"

# アップロード対象ファイル

FILE_PATH = "report.pdf"

# 前処理パラメータ（公式ドキュメントに準拠）

payload = {

"preprocess": {

"remove_header_footer": True,

"chunk_size": 500, # トークン数ベースのチャンクサイズ

"language_detection": True

}

headers = {

"Authorization": f"Bearer {API_KEY}",

"Content-Type": "application/json"

}

files = {"file": open(FILE_PATH, "rb")}

# エンドポイントは公式ドキュメントで確認してください

url = f"{BASE_URL}/api/v1/knowledge/files/"

response = requests.post(url, headers=headers, files=files, data=json.dumps(payload))

print("Status:", response.status_code)

print("Response:", response.json())

重要ポイント
Content-Type は JSON に固定しつつ、files パラメータでバイナリを送信します。
preprocess のキーは公式ドキュメントに記載されたものと同一である必要があります（スペルミスや余計なパラメータがあると 400 エラーになります）。

8. まとめ

RAG の全体フロー は「ETL → Indexing → Vector Search → LLM Inference」の四段階。前処理の品質が最終回答精度を決定付けます。
ナレッジパイプラインの有効化 は管理コンソールの Knowledge タブからスイッチ操作だけで完了。UI の変更点は公式リリースノートで随時確認してください。
データ取り込みと前処理 では PDF・テキスト・画像を UI または API 経由でアップロードし、ヘッダー除去や OCR 設定を適切に行うことが重要です。
ベクトルストア選択 はスケール要件と運用コストで決め、インデックス作成時の次元数・メトリック設定は埋め込みモデルと合わせて正確に指定します。
LLM とプロンプトテンプレート を組み合わせたエージェントワークフローを構築すれば、RAG によるコンテキスト参照が自動化されます。
Observability（Opik・Langfuse・Arize）で推論ログと品質指標を可視化し、典型的なエラーに対するトラブルシューティング手順を事前に整備しておくことで運用リスクを低減できます。
API 利用 は公式 OpenAPI スキーマに沿って実装し、エンドポイントやリクエスト形式の変更があった場合は必ず最新版ドキュメントで検証してください。

上記手順とベストプラクティスをプロジェクトに適用すれば、2026 年版 Dify の RAG パイプラインを 迅速かつ安定的に デプロイでき、AI 検索体験の向上が期待できます。ぜひ本記事を実装ガイドとして活用し、貴社のナレッジマネジメントに革新をもたらしてください。

スポンサードリンク