DifyでExcelを扱った際に件数が合わないときは、数字だけを見て原因を推測せず、入力データ、抽出結果、検索結果、回答の各段階を順に確認します。あわせて、条件に合う行の行IDを照合し、欠落や取り違えが生じている段階を絞り込みます。
表全体の件数を正確に求める業務では、曖昧な検索に頼らず全件集計の処理を分ける判断が有効です。
紹介する確認手順は、Difyの公式ドキュメントや関係データベースの仕様に基づく調査の整理案です。掲載している基準値は架空データをもとに計算したものであり、Dify実機での動作検証結果や精度の向上を保証するものではありません。調査を行う際は、利用環境のバージョンやノード構成を記録して照合してください。
最初に、Excelをどの経路で渡しているか確認する
DifyでExcelファイルを扱う経路には、Document Extractorノードを経由する方法と、ナレッジへ直接登録する方法があります。不一致の原因を調べるには、まず構築したワークフローがどちらの経路を使っているかを確認します。
Document Extractorノードは、受け取ったファイルをテキストデータに変換する機能です。Excel（.xls/.xlsx）やCSVを読み込むと、Markdown形式の表などに変換して後続ノードへtext変数として出力します。このノードはテキスト変換を行うもので、表の完全な保持や集計の正確性を担保する仕組みではありません。後続のLLM（大規模言語モデル）ノードへtextを渡して件数を数えさせる構成では、変換された表テキストをもとにモデルが推論して回答を作成します。
一方、Excelをナレッジに直接登録する経路では、アップロード時に文書がチャンク（分割されたテキストの塊）単位に分けられて保存されます。Knowledge Retrievalノードは、質問に関連するチャンクを検索してresult配列として取得し、後続ノードへ渡します。質問への関連度で絞り込む仕組みであるため、元の表の全行がモデルに届くとは限りません。
ファイル変換後にテキストをナレッジへ登録するような構成であっても、変換段階と検索段階を分けて記録することが大切です。各処理の役割と全件集計での注意点は、次のように整理できます。
| 処理・経路 | 役割 | 確認する内容 | 全件集計での注意 |
|---|---|---|---|
| Document Extractorを使う経路 | Excel/CSVをMarkdown表へ変換してtextを出力 | 出力内のID、行数、条件列と元表の対応 | 変換機能であり、完全な抽出や集計の正確性を保証する記述はない |
| ナレッジへ直接登録して検索する経路 | 登録文書から関連チャンクを取得 | 登録後のチャンク、検索返却内容、両段階の設定 | 関連チャンクの取得結果を、そのまま全行の一覧とは扱えない |
| SQLなどの集計処理 | 取り込んだ表から条件に合う行を数える | 入力行数、条件、型、重複、該当ID | 正しい結果には完全な取り込みと正しい集計条件が必要 |
- 1. 元データ（Excel） シート選択、見出し除く12行、判定列の空欄・空白を確認
- 2. Document Extractor text出力を確認。Markdown表内に全ID（R01〜R12）を保持しているか検証
- 3. LLM入力 プロンプトへ渡されたコンテキストに対象行テキストが含まれているか確認
- 4. 回答生成 出力件数と列挙行ID（不足・余分・重複）を正解と照合
- 1. 元データ（Excel） シート選択、見出し除く12行、判定列の空欄・空白を確認
- 2. ナレッジ登録・チャンク確認 分割設定とチャンク詳細を確認。最大チャンク長による分断や欠落を検証
- 3. Knowledge Retrieval 検索テストとresult配列を確認。Top Kや閾値による足切り・重複を照合
- 4. LLM入力 取得チャンクが欠落なくLLMプロンプトへ引き渡されているか確認
- 5. 回答生成 出力件数と列挙行ID（不足・余分・重複）を正解と照合
LLM回答生成の後に実行する工程ではなく、推論や検索に依存しない独立した処理系統として設計します。
経路Aと経路Bでは確認すべき中間データ（text出力かresult配列か）が異なります。厳密な全件集計が必要な場合は、上記のように独立した集計処理を切り分ける構成を推奨します。
12行の表で、質問と正解の行IDを固定する
集計のずれを調べる際は、数え方の認識違いを避けるために正解が決まっている基準データを用意します。ここでは、12行4列で構成された架空の業務チケット一覧「tickets」を使用します。実在のデータは含まない合成データです。
| row_id | region | status | amount_yen |
|---|---|---|---|
| R01 | 関東 | 未対応 | 12000 |
| R02 | 関西 | 完了 | 9000 |
| R03 | 関東 | 対応中 | 21000 |
| R04 | 関東 | 未対応 | 18000 |
| R05 | 東北 | 未対応 | 8000 |
| R06 | 関東 | 未対応 | 22000 |
| R07 | 九州 | 完了 | 7000 |
| R08 | 関東 | 未対応 | 15000 |
| R09 | 関西 | 未対応 | 11000 |
| R10 | 関東 | 完了 | 16000 |
| R11 | 関東 | 未対応 | 10000 |
| R12 | 東北 | 対応中 | 13000 |
この表に対し、次の2つの質問を設定します。ユニークな顧客数ではなく、条件に合致するデータ行の総数を数えるルールとします。
- Q1: 未対応の行IDと件数をすべて返してください。
- Q2: 地域が関東、かつ未対応の行IDと件数をすべて返してください。
この表から条件を満たす行を論理的に照合した正解値は次のとおりです。Q1（未対応）の期待値は7行で、合致するIDはR01, R04, R05, R06, R08, R09, R11です。Q2（関東かつ未対応）の期待値は5行で、合致するIDはR01, R04, R06, R08, R11です。これは入力データから定めた基準値であり、Difyでの実行結果ではありません。
ここで用いるrow_idは、元の表の各行を識別するための固有記号です。CSVやMarkdown、Excel形式で処理の違いを比較する場合は、必ず同一の行、同一の値、同一のIDを用います。形式とシステム構成を同時に変更すると、どの要素が件数の不一致を引き起こしたか特定できなくなるためです。
元データと抽出結果に、必要な行がそろっているか確認する
検索やプロンプトの設定を調べる前に、取り込みと抽出の段階で行が欠落していないかを確認します。入力データ自体が欠けていれば、後続の処理で正しい結果を得ることは困難です。
元となるExcelファイルでは、対象のシートが正しく選ばれているか、見出し行を除いたデータ行が12行あるかを確認します。あわせて、判定に使うregionやstatusの値に意図しない空欄、余分な空白、表記揺れがないかを点検します。
Document Extractorを利用する構成では、ノードの実行ログから出力されたtextの内容を確認します。Markdown表として出力された文字列の中に、R01からR12までの行がすべて存在しているか、列の対応関係が崩れていないかを調べます。
ナレッジへ直接登録する構成では、登録後の文書一覧やチャンク詳細を開き、元表の行が取り込まれているかを確認します。チャンク分割の仕様により、最大チャンク長を超えると自動で分割されます。調査時はDifyの利用環境（Cloud版かセルフホスト版か、バージョン）、処理経路、抽出・分割設定、使用モデルを記録し、確認できなかった項目は推測せずに「未確認」として残します。
検索テストで、返ったチャンクと行IDを確認する
ナレッジを用いた構成では、Knowledge Retrievalノードが登録文書から質問に関連するチャンクを取り出し、result配列として後続ノードへ渡します。チャンクはテキストを一定の規則で分けた単位であり、Excelの1行単位と一致するケースもありますが、必ずしも一致するわけではありません。
不一致を調査する際は、ナレッジ画面の検索テスト機能を使います。質問文を入力してテストを実行し、返却されたチャンクに対象の行IDが含まれているか、同じIDが複数のチャンクに重複して現れていないかを確認します。あわせて、ワークフロー実行時のresult配列と、後続のLLMノードに実際に渡された入力内容も照合します。
検索設定のTop Kは返却するチャンク数の上限であり、Excelの行数指定ではありません。リランキング（検索結果の関連度を並べ直す再スコアリング）モデルを設定している場合は、モデルの最大入力容量に合わせてTop Kが自動調整される仕様があります。また、類似度スコアの閾値（Score Threshold）を満たさないチャンクは除外されます。索引方式や検索設定によって動作条件が異なるため、Top Kを増やしても元の表の全行が届くとは限らない点に注意が必要です。
なお、検索テスト画面で変更したTop Kや検索方式は、テスト実行時の一時的な設定です。実際のワークフロー内のRetrievalノード設定へ自動で保存・反映されるわけではないため、ノード側の設定値を別途確認します。
表形式データを分割させずに1つのチャンクへ収めてナレッジに登録する工夫もあります。IDNETの当事者検証記事では、Excel直接登録からMarkdown形式の1チャンク構成へ変更した際に、回答の正確性が改善した事例が報告されています。ただし、この事例は形式変換とチャンク分割の両方を同時に変更した比較であり、表の行数（12件）も小規模です。大規模な表では最大チャンク長による強制分割やコンテキスト上限の影響を受けるため、すべての表で適用できる汎用策とは言えません。
件数だけでなく、回答に列挙された行IDを照合する
出力された件数が正解と一致していても、対象の行が正しく選ばれているとは限りません。漏れた行と余計な行が相殺され、見かけの数字だけが一致することもあるためです。調査時は、プロンプトで条件に合致する件数とともに、対象となった行IDの一覧を出力させる指定を行います。ただし、列挙されたIDはモデルの自己申告であり、内部の参照履歴や実際の判断根拠を証明するものではありません。実態を伴わない回答に惑わされないためにも、AIの「完了しました」を信じないという姿勢を前提に実物の出力を突き合わせて検収します。
調査の際は、以下の項目を記録して照合します。
- 正解ID: 元データから導かれる本来の行ID（Q1なら7件、Q2なら5件）
- 抽出結果にあるID: Document Extractorなどの変換後テキストに存在するID
- 検索返却チャンクにあるID: Knowledge Retrievalで取得されたチャンク内のID
- 回答に列挙された行ID: モデルが出力文の中に書き出したID
記録を照合する際は、正解にあるのに回答に含まれない「不足ID」、正解にないのに含まれた「余分なID」、回答内で重複して書かれた「重複ID」を整理します。IDを集合（セット）として扱うと重複記載が見落とされるため、各IDの列挙回数も別途確認します。
検索段階では、正解IDがすべて含まれているかを確認します。条件外のIDが含まれて集合全体が一致しなくても、それだけで検索失敗とは判定しません。あわせて、IDだけでなく対応する条件列の値も確認します。検索結果には存在するのにLLMへの入力に含まれていない場合は、後続への受け渡し設定やコンテキスト上限を調べます。
また、同一プロンプトで複数回実行して結果のばらつきを確認することも役立ちます。ただし、複数回同じ件数が出ても計算の正確性が担保されたわけではありません。行IDを突き合わせることで、不一致が生じた段階を絞り込みやすくなります。
全件集計が必要なら、集計処理を分ける
業務で厳密な行数や合計値が求められる場合は、検索と自然言語生成に頼る構成を見直し、表全体から条件に合う行を計算する集計処理を独立させる構成を検討します。ただし、自然言語から集計条件への変換でも誤りが生じ得るため、対象表、条件値、集計ルールを事前に確定させたうえで、データベースやコード実行環境に集計を任せる境界設計が重要です。誤りが許されない集計は失敗の影響が大きいため、AI導入はどこから始める？最初の1業務の選び方が示すように影響の小さい別の業務を優先する選択肢もあります。
集計処理を分ける場合でも、元データが漏れなく取り込まれていることや、条件列のデータ型、重複の扱いが適切であることを前提とします。
以下のSQLは、あらかじめ「tickets」表がデータベースへ取り込まれている前提で、SQLiteを想定して集計条件と基準値を確認する構文例です。これは要件定義や基準値確認のための参考例であり、Difyの特定連携機能で直接動作確認を行ったパイプラインではありません。
-- 取り込まれた行数とIDの種類数を確認
SELECT COUNT(*) AS total_rows,
COUNT(DISTINCT row_id) AS distinct_ids
FROM tickets;
-- Q1: 未対応の行数と対象ID
SELECT COUNT(*) AS matched_rows
FROM tickets
WHERE status = '未対応';
SELECT row_id
FROM tickets
WHERE status = '未対応'
ORDER BY row_id;
-- Q2: 関東かつ未対応の行数と対象ID
SELECT COUNT(*) AS matched_rows
FROM tickets
WHERE region = '関東'
AND status = '未対応';
SELECT row_id
FROM tickets
WHERE region = '関東'
AND status = '未対応'
ORDER BY row_id;
SQLiteの集計関数仕様において、行数全体の集計にはCOUNT(*)を使用します。これはNULLを含む行も対象になります。一方、COUNT(column)は指定列がNULLではない行のみを数えます。空文字（”）はNULLとは異なりカウントされるため注意が必要です。WHERE句による抽出と合わせて、条件が意図どおりに機能しているか確認します。
今回の基準表では、全行数とIDの種類数はともに12です。ただし、行数とID数が一致していても各列の値が正しく取り込まれているとは限らないため、元データとの照合が必要です。Q1では7行と合致する7件のID、Q2では5行と合致する5件のIDが基準値となります。
業務における自動化の進め方や要件整理を検討する際は、選択式で自社の状況を確認できるAI自動化診断も活用できます。
よくある質問
Top KをExcelの行数に合わせれば直りますか？
Top Kは取得するチャンク数の上限であり、Excelの行数指定ではありません。リランキング設定による自動調整や、類似度スコアの閾値（Score Threshold）による足切りがあるため、Top Kを増やしても全行が取得できるとは限りません。チャンクの分割状況や検索ノードの設定を合わせて確認する必要があります。
ExcelをMarkdownの1チャンクにすれば解決しますか？
表を分割せずに保持して改善した検証報告はありますが、あらゆる表で解決する保証はありません。ファイル形式の変更とチャンク設定の変更が複合している点に注意が必要です。また、最大チャンク長を超えると自動分割されるため、対象の行IDが保持されているかを照合する必要があります。
Document Extractorを使えば正確に集計できますか？
このノードの役割は、ファイル内容をMarkdownなどのテキスト形式へ変換することです。全セルの保持や集計の正確性を保証する仕様ではないため、出力テキスト内のデータ完全性と、後段における集計処理の仕組みを個別に確認する必要があります。
同じ件数が3回出れば、正しいと判断できますか？
複数回の実行で同じ件数が出力されても、誤った行のカウントが含まれている可能性があり、正確性の証明にはなりません。正解となる件数および対象行IDの一覧と突き合わせ、入力や条件が変わるたびに確認することが大切です。
参考資料
- Dify公式ドキュメント: Knowledge Retrieval Node（確認日: 2026-10-07） 関連チャンクの取得仕様、result配列の構造、Top KやScore Threshold、リランキング時の入力制限に関する仕様が記載されています。
- Dify公式ドキュメント: Document Extractor Node（確認日: 2026-10-07） ExcelやCSVをMarkdown表へ変換しtextとして出力する仕様が説明されています。
- Dify公式ドキュメント: Chunking and Cleaning Text（確認日: 2026-10-07） 文書分割の規則、最大チャンク長による制限、テキストクリーニングの仕組みが解説されています。
- Dify公式ドキュメント: Setting Indexing Methods（確認日: 2026-10-07） 索引方式や検索方式、リランキング設定ごとの適用条件の違いについて記載されています。
- Dify公式ドキュメント: Test Retrieval（確認日: 2026-10-07） ナレッジ設定内での検索テスト手順と、返却されるチャンクの確認方法が示されています。
- SQLite公式ドキュメント: Aggregate Functions（確認日: 2026-10-07） 行全体を数えるCOUNT(*)と、特定列の非NULL値を数えるCOUNT(column)の仕様差が定義されています。
- SQLite公式ドキュメント: The SELECT Statement（確認日: 2026-10-07） WHERE句を用いた条件に基づく対象行のフィルタリング仕様が記載されています。
- IDNET技術検証報告: DifyナレッジにおけるExcelデータ参照の検証（公開日: 2026-04-30、確認日: 2026-10-07） Excel直接登録からMarkdown1チャンク構成へ変更した際の回答変化と、大規模表における制約に関する当事者による検証事例です。
自社の業務プロセスにおける自動化の余地や要件を整理したい場合は、選択式で手軽に確認できるAI自動化診断を試してみてください。
