DifyでPDFの表の行列が崩れるときの確認手順

2026 10/25

2026年10月7日 2026年10月25日

著者: Walkers編集部公開: 2026年10月7日最終更新: 2026年10月25日

DifyでPDF内の表の行列が崩れるときは、対象表に文字層があるかの確認、抽出ノードの出力テキストの点検、そしてチャンク分割やプロンプト投入などの後続処理の確認を順に進めます。文字抽出の失敗と後続処理での対応関係の欠落を混同せず、実際のワークフロー構成に存在する工程ごとにデータの変化を追うことで、どの段階で表構造が崩れたかを切り分けることができます。

本稿は2026年10月7日時点の公式資料に基づく確認手順の設計ガイドであり、特定の実機環境における実行結果を記録したものではありません。

文字層の有無と抽出出力の照合

PDFを処理して期待する表情報が得られないときは、文字自体が取り出せていないのか、文字は得られているものの行列の対応関係が崩れているのかを区別します。

手元のPDFビューアで対象の表を開き、テキストを選択してコピーできるかを調べます。ただし、この操作は対象表に文字層が存在するかを調べる目安であり、OCR文字層付きのスキャンPDFや、テキストと画像が混在したPDFも存在します。そのため、対象表のコピー結果と抽出ノードの出力を照合して状況を把握します。文字が空という理由だけで直ちに別の処理経路への切り替えを必須とするのではなく、入力ファイルの状態とノードの設定が一致しているかを点検します。請求書や領収書のスキャンデータをAI-OCRで読み取る際も同様に、経理業務のAI活用を念頭に人が点検すべき工程と自動化の境界を定めます。

ワークフローのDocument Extractorノードは、Document Extractorの説明にある通りテキストベースのPDFを主な対象としています。一方、ナレッジ機能のKnowledge Pipelineでは、Knowledge Pipelineの構成に示されているようにUnstructuredなどの外部パーサーを選択でき、OCRを伴う処理経路も利用できます。

テキストとして文字が取り出せているにもかかわらず、表の縦横の組み合わせが崩れている場合は、利用しているパイプラインの工程に沿って調査を進めます。

ワークフローの構成に合わせた段階別の確認

表構造の追跡は、ナレッジ検索を利用する構成例では原本、抽出テキスト、チャンク（検索用に分割した文章片）、検索結果、回答の順に入出力を照合します。Document Extractorから直接LLMへ渡す構成ではチャンク分割や検索が存在しないため、実際のパイプラインに存在する工程だけを確認対象とします。なお、パーサーはファイル内容を読み出す処理、コンテキストはLLMへ渡される参照情報を指します。チャンクや検索結果を組み合わせて回答を導くRAGの構造に迷った際は、AI用語集で定義や実務上の注意点を確かめると理解が深まります。

DifyにおけるPDF表処理のパイプライン別確認工程

【共通工程】

PDF原本の確認 セルの並びや見出しの配置を目視確認。複雑な結合セルや多段組の有無を把握します。
抽出テキストの照合 パーサーが出力したプレーンテキストを確認。改行により行列の対応が失われていないかを点検します。

経路A：直接渡す構成（Document Extractor）

プロンプト投入と回答 抽出テキストがそのままLLMへ渡されます。プロンプト内の表情報が行列として正しく読めているかを照合します。

経路B：ナレッジ検索構成（Knowledge Pipeline）

保存済みチャンクの点検 知識ベース内で分割された断片を確認。最大長や区切り設定で見出し行とデータ行が分離していないかを点検します。
検索結果とプロンプト照合 検索ノードが出力したコンテキストを確認。見出しと対象データ行の両方がそろってLLMへ渡されているかを検証します。
回答生成の確認 コンテキスト内の表情報をLLMが正しく解釈し、行列の関係に沿った回答を出力できているかを確認します。

抽出テキスト確認後は、採用している構成（直接渡す構成またはナレッジ検索構成）に応じた経路のみを確認対象とします（実機検証結果を示すものではありません）。

工程	確認対象	対応が失われた場合の次の確認
原本	PDF上のセルの並びと見出しの配置	目視で複雑な結合セルや多段組がないか確認する
抽出テキスト	パーサーが出力したプレーンテキスト	改行で行列の対応が失われていないか確認する
チャンク	知識ベース内で分割された断片	見出し行とデータ行が別ブロックに分かれていないか確認する
検索結果	検索ノードの出力および後続へ渡されたコンテキスト	必要な行と見出しの両方が同時に取得されているか確認する
回答	LLMが出力した最終テキスト	コンテキスト内の情報を行列として正しく読めているか確認する

抽出テキストの段階では、横並びだったセルが縦一列の改行区切りテキストに変換されていないかなどを確認します。

ナレッジ機能を経由している場合は、テキストの分割とクリーニングで説明されている有効な分割設定や前処理を確認します。知識ベースでは、該当設定が有効な場合に連続する空白や改行の整理、タブから空白への置換といった前処理が適用されます。表の途中で最大長に達して分割された場合、後続のチャンクに見出しが含まれなくなる原因候補となるため、抽出テキストと保存済みチャンクを比較して判定します。

検索ノードを利用している構成では、検索ノードの出力内容と、実際に後続ノードへ渡されたプロンプト内容の双方を確認し、コンテキストに表の見出しとデータ行がそろって渡されているかを確かめます。

業務で利用しているPDFやデータ連携の設計を見直したい場合は、AI診断を活用して現在の構成を整理することもできます。

入力形式と抽出経路を組み合わせた比較

実業務の複雑なPDFで原因を特定しにくいときは、簡素な表データを用いて挙動を切り分けます。以下の表はDifyで選択可能な代表的な入力形式と抽出経路の組み合わせ候補です。原因特定のための対照比較を行う際は、入力形式と抽出経路を同時に変えず、「同一の抽出経路（例: Document Extractor）でファイル形式だけを変える」か、「同一のPDFで抽出経路やパーサー設定だけを変える」ように条件を1点ずつ切り替えます。

| 商品 | 数量 | 単価 |
| 製品A | 10 | 1000 |
| 製品B | 5 | 2000 |

上記の表をテキストPDF、スキャンPDF、Excel形式で準備し、まずは抽出出力の段階で行列構造がどのように保持されるかを比較します。

入力形式	抽出経路	関連設定	見出しと値の対応
テキストPDF	Document Extractor	標準設定	実機にて要確認
画像PDF	Knowledge Pipeline	Unstructured OCR	実機にて要確認
Excelファイル	Document Extractor	標準設定	実機にて要確認

Document ExtractorはExcel（.xls/.xlsx）やCSVをMarkdownの表形式テキストへ変換する機能を備えていますが、PDFから抽出されるテキストはレイアウト情報が削ぎ落とされたプレーンテキストになる傾向があります。チャンク以降の挙動を比較する際は下流の設定条件をそろえ、どの処理段階で行列構造が変化したかを観察します。

崩れが発生した工程に応じた修正候補

表の構造が崩れた工程が特定できたら、その段階に対応した設定や設計の見直しを検討します。

抽出段階で行列が崩れている場合は、パーサーや抽出オプションの変更を検討します。Unstructuredのパーティショニング仕様には表構造の抽出に対応するhi_res戦略がありますが、利用中のDify環境のUI設定やプラグインから該当パラメータを指定可能か個別に確認する必要があります。Unstructuredライブラリ単体の機能がDifyのUIからそのまま呼び出せるとは限らない点に留意します。

チャンク分割の段階で見出しとデータが分離している場合は、表全体が収まるようにチャンク最大長を調整するか、区切り文字の指定を見直します。ただし、最大長を広げても表全体の保持が保証されるわけではないため、プレビュー機能で分割結果を確認します。連続空白や改行の整理設定が意図した表区切りに影響していないかも点検します。

検索の段階で見出しが抜け落ちている場合は、取得件数（Top K）の見直しや、メタデータ・プレフィックスとして見出し情報を保持させる設計を検討します。ただし、メタデータとして保存するだけではLLMへの入力プロンプトに含まれるとは限りません。検索ノードの出力からどの項目がコンテキストとしてLLMへ渡されるかを確認し、必要な行と見出しの両方がそろって渡っているかを合格条件として検証します。

システムの制約や連携フローの課題を把握した上で設計を進めたい場合は、AI診断で自社の利用要件を確認することもできます。