これは非常に典型的な問題で、コミュニティでの同様の議論（特にこのユーザー自身が別のスレッド /t/topic/683 で提供したフィードバック）によると、主な原因は 標準のドキュメント抽出ノード（Doc Extractor）が、スキャン版PDF（純粋な画像PDF）のOCR文字認識をデフォルトでサポートしていないこと です。
以下は、この問題に対する分析と提案される解決策です。
主要な原因分析
- スキャン版PDFにはテキストレイヤーがない: ユーザーがアップロードしたのはスキャンされたものであり、本質的には複数の画像がPDFにまとめられたものです。
- エクストラクターの制限: Difyに組み込まれている「ドキュメント抽出ノード」（Document Extractor）は、PDFを処理する際に通常
pypdfium2などのツールをデフォルトで使用します。これらのツールはファイル内の選択可能なテキストのみを抽出でき、画像に対してOCR認識を実行することはできません。 - 結果: エクストラクターが出力する
text変数は空文字列になります。 - LLMの反応: プロンプトに渡される変数コンテンツが空であるため、LLMは実際に何も「見ていない」ため、その回答（「アップロードされたドキュメントは受信していません」）は完全に正直で正しいものです。
推奨される解決策
ユーザーには、組み込みの「ドキュメント抽出ノード」を使用せず、以下のいずれかの代替ソリューションを採用するようお勧めします。
解決策1：Unstructuredプラグインを使用する（推奨）
Difyプラグインマーケットプレイスには、より高度な解析戦略をサポートする Unstructured プラグインが提供されています。
- ワークフローから既存の「ドキュメント抽出ノード」を削除します。
- 右側の「プラグイン」または「ツール」で Unstructured プラグインを検索して追加します。
- プラグインを設定する際に、OCRをサポートする戦略（例：
hi_resまたはOCR関連のパラメーターの設定）を有効にするか選択してください。 - 注意: これには通常、ユーザーがUnstructuredサービスを自分でデプロイするか、そのAPIキーを使用し、Difyの設定で認証情報を正しく構成する必要があります。
解決策2：専用のOCRプラグインを使用する
Unstructuredを使用しない場合でも、プラグインマーケットプレイスで OCR 関連ツール（General OCR、Aliyun OCRなど）を検索し、まずファイルをOCRツールに渡してテキストを取得し、その後OCRが出力したテキストをLLMに渡すことができます。
ユーザーへの返信例のまとめ
ユーザーには次のように返信できます。
この問題の原因は特定されました。Difyに組み込まれている「ドキュメント抽出ノード」は、スキャン版PDF（純粋な画像）のOCR文字認識をデフォルトでサポートしていません。そのため、抽出された
textは実際には空であり、LLMは文字コンテンツを一切受け取っていませんでした。解決策：
プラグインマーケットプレイス (Marketplace) にアクセスし、既存のドキュメント抽出ノードの代わりにOCR機能をサポートするプラグインを探してください。
- Unstructured プラグインを試すことをお勧めします（対応するサービスまたはAPIの設定が必要です）。
- または、他の OCR 関連のプラグインを検索してください。
ユーザー様ご自身が別のスレッド (Topic 683) で既に核心に触れていましたが、ローカルデプロイされたETL設定は主にナレッジベース用であり、ワークフロー内の組み込みノードには直接作用しません。ワークフローでスキャンされたドキュメントを処理するには、OCRをサポートするツールノードを明示的に使用する必要があります。
関連ドキュメントと議論：
- Unstructured プラグイン - Dify Marketplace
- 関連コミュニティ議論：/t/dify/683 (ユーザー自身の別の関連質問)