Difyのメタデータ条件で0件｜文書の値・型・検索結果を確認

Difyでメタデータ条件を付けると検索結果が0件になる場合は、先に文書の属性値・型・条件の組合せを確認します。 質問文を何度も言い換える前に、その条件へ合う文書が存在するかを調べると、確認する場所を絞れます。

対象は、ナレッジを使うWorkflowやChatflowを学習中で、条件を一つ加えた後に結果が返らなくなった人です。今回はClassicナレッジとClassic Knowledge Retrievalを対象にします。現行公式資料ではAgentナレッジ向けの検索ノードが別に案内されているため、同じ設定画面があるとは限りません。

公式資料の確認日は2026年11月2日です。記事内の6文書と結果の確認票は編集部作成の架空教材です。Pythonの例は条件の意味を紙上で検算する参照実装で、Dify Cloud・外部API・LLMを実行したログではありません。画面の配置は利用環境で確認してください。

検索前に、文書のメタデータと条件を照合する

ClassicとAgentを確認し、調べる範囲を揃える

2026年11月2日に確認したClassic Knowledge Retrievalの公式資料では、Classicナレッジを検索するノードと、Agentナレッジを検索するノードが区別されています。本稿の条件表や操作の説明は、前者に範囲を絞っています。

最初に、自分が使っているナレッジの種類、アプリがWorkflowかChatflowか、検索ノードの名前を記録します。セルフホストなら利用版も添えます。別の環境の古い画面と名前が違うだけで、設定が消えたと判断しないようにしてください。

次に、対象のナレッジと検索ノードを対応させます。同じ名前のナレッジを複製していたり、テスト版と公開版が別だったりすると、文書を直した場所と検索している場所が一致しない場合があります。名前だけでなく、画面で確認できる識別情報もメモします。

今回の練習では、6文書を入れた一つの架空ナレッジを使う想定にします。公開中の社内資料へ条件を付け足す作業ではありません。対象を小さく揃えた上で、文書の属性と条件を人が確認できるようにすることが目的です。

「Difyで検索できない」という広い症状の中には、文書の準備、検索語、条件、取得後のLLMへの渡し方など、別の原因が含まれます。本稿では、メタデータの条件を変えた場面へ絞って考えます。最初からすべての設定を変更せず、何を変えた直後かを残してください。

フィールドを作っただけか、文書へ値を付けたかを見る

メタデータの「項目」と「値」は別です。deptというフィールドを用意したことと、各文書のdeptへsalesを付けたことは同じではありません。検索条件に項目名が出ていても、対象文書に意図した値があるかは、文書側で確かめます。

公式のメタデータ管理では、String・Number・Timeの型、項目の作成、文書への付与、編集範囲が説明されています。フィールドの変更にはナレッジ全体へ関わる操作もあるため、今回の確認では自作の少数文書を対象に、値がどう入っているかを見ます。

項目名を作成する際の現行資料には、小文字の英字・数字・アンダースコアという命名規則があります。教材ではdept、edition、stateを使います。画面上の表示名を覚えるだけでなく、どの項目へ何を入れたかを原表へ記録してください。

複数文書へ値を付けた場合は、一つだけを開いて全件が同じだと判断しないようにします。例えば年度が2025の文書と2026の文書に同じ値を付けてしまうと、条件が通っても期待する資料を選んだことになりません。文書名と値の組を確認します。

この段階では、検索スコアの高低はまだ調べません。まず「項目がある」「値がある」「想定の型である」という三つを揃えます。本文の中に「営業向け」と書かれていることと、dept=salesという属性が付いていることも別です。本文の言葉から、付与済みの値を推測しないでください。

架空6文書を、文書IDと三つの属性で並べる

練習の目的は「営業向け・2026年版・承認済みの資料」を候補にすることです。6文書を次の表で表します。A〜Fは教材内の識別子です。Difyが自動で発行するIDや、実際の社内文書名ではありません。Fの年度は値が未設定という想定です。

まず紙や表計算で、条件に合う文書を選びます。三つすべてを満たすのはAです。Bは年度、Cは承認状態、Dは部署が異なります。EはsalesとSalesの大文字小文字が違い、Fは年度が未設定です。単に「営業資料がある」という確認より、選ばれる理由が具体的になります。

# 架空の原表を検算する参照データ。Difyの出力ではありません。
docs = [
    {"id": "A", "dept": "sales", "edition": 2026, "state": "approved"},
    {"id": "B", "dept": "sales", "edition": 2025, "state": "approved"},
    {"id": "C", "dept": "sales", "edition": 2026, "state": "draft"},
    {"id": "D", "dept": "support", "edition": 2026, "state": "approved"},
    {"id": "E", "dept": "Sales", "edition": 2026, "state": "approved"},
    {"id": "F", "dept": "sales", "edition": None, "state": "approved"},
]

このような少数の原表を先に用意すると、「検索結果に出なかった文書」と「最初から条件に合わなかった文書」を分けられます。大量の資料を一度に登録して、結果だけを眺めるよりも、どこで意図と違ったかを調べやすくなります。

原表にない文書を後から足した場合は、期待する候補の一覧も更新します。例えば、新しい営業資料が入ったのに期待候補をAだけのままにしておくと、正しい追加結果を異常だと思ってしまいます。検算表にも確認日と対象文書数を残しましょう。

文字列の一致と数値の比較を、同じものとして扱わない

現行のナレッジとアプリの統合資料には、文字列の完全一致や部分一致、数値の比較など、型に応じた条件が案内されています。まず、フィールドの型に合う演算子を選んでいるかを確認します。

例えばdeptが文字列なら、今回の目的はsalesとの一致です。「営業」という日本語を条件へ入れたり、Salesへ書き換えたりすれば別の値を指定したことになります。現行資料では大文字小文字を区別するため、見た目が近いだけで同じと判断しないでください。

editionは今回、数値型の2026です。文字列型の"2026"と、数値の2026を同じ仕様だと決めず、文書側の型と検索条件の型を揃えます。Pythonの原表で見分けられたことだけで、実際のDifyの設定が揃った証拠にはしません。画面とノードの実行詳細でも確認します。

文字列の部分一致へ変えて結果が返るようになっても、それが目的どおりかは別です。例えばsalesを含む値なら、完全一致では選ばなかった別の区分を候補へ入れる可能性があります。条件を緩めた後は、結果の件数だけでなく、選ばれた文書の識別子を原表と照合してください。

未設定の値についても、「空」と「文字列で未設定と書いてある」を区別します。表示用の表ではFを「未設定」と説明していますが、参照コードではNoneです。その文字を実際のメタデータへ入力する手順ではありません。説明のラベルを、そのまま検索条件の値へ貼り付けないようにします。

ANDで条件を一つずつ足し、減った文書を追う

三つの条件を一度に設定する前に、部署だけ、部署と年度、部署と年度と承認状態の順に候補を比べます。今回、部署だけならA・B・C・F、年度も加えるとA・C、承認状態まで加えるとAになります。どの条件で候補が減ったかが分かります。

dept_ids = [d["id"] for d in docs if d["dept"] == "sales"]
year_ids = [d["id"] for d in docs
            if d["dept"] == "sales" and d["edition"] == 2026]
approved_ids = [d["id"] for d in docs
                if d["dept"] == "sales" and d["edition"] == 2026
                and d["state"] == "approved"]
assert dept_ids == ["A", "B", "C", "F"]
assert year_ids == ["A", "C"]
assert approved_ids == ["A"]

ここで確認しているのは、教材の条件へ合う文書の候補です。Difyが質問に対して必ずAを返すと予測した結果ではありません。候補がAだけであっても、その文書に質問へ答える内容があるか、検索設定によって返るかは次の確認になります。

条件を足したら0件になったときは、その直前の候補と、新たに加えた条件を見ます。例えば年度を2027へすると、この原表には該当文書がありません。この場合、質問の言い方を変え続けても、2027年版の資料が存在することにはなりません。

実際の文書の値が想定と違う場合は、どちらが正しいかを原資料と照合します。結果を返すためだけに年度や承認状態を変更すると、候補にしたい資料の意味が変わります。条件式を直す作業と、文書の管理情報を更新する作業を混ぜないようにしましょう。

定数・変数・返却結果を分けて、0件の場所を調べる

ORへ変えると、必要な条件まで外れる場合がある

ANDはすべての条件、ORはいずれかの条件に合う場合を考えます。今回の三条件をORにすると、6文書すべてがいずれかを満たします。Dは部署が違っても年度や承認状態が合い、Eも年度と承認状態が合います。Fは年度が未設定でも部署が合います。

def checks(document):
    return [document["dept"] == "sales",
            document["edition"] == 2026,
            document["state"] == "approved"]

and_ids = [d["id"] for d in docs if all(checks(d))]
or_ids = [d["id"] for d in docs if any(checks(d))]
assert and_ids == ["A"]
assert or_ids == ["A", "B", "C", "D", "E", "F"]

「結果が空だからORに変えたら返った」という確認だけでは、営業向けの承認済み2026年版を選べているか分かりません。件数が増えた理由を文書ごとに説明できるかを見ます。今回なら、Cという下書きも候補へ入り、当初の目的から範囲が広がっています。

同じように、空欄を含む条件を足す場合も目的を言葉で書きます。「年度が2026、または年度未設定も含める」という条件は、未設定を許可する方針です。単に画面の選択肢を変えるのではなく、含める理由を確認してから使ってください。

権限や閲覧範囲のために設けた条件は、動作確認のために公開環境で外しません。教材の複製で値の一致を確認することと、誰に何を見せるかを変更することは別の作業です。今回の6文書はすべて架空なので、既存のアクセス範囲を変えずに論理を学べます。

定数で確認してから、変数の実際の値へ進む

現行資料の手動フィルタでは、値を定数で指定する方法と、既存のWorkflow・Chatflow変数から選ぶ方法が案内されています。初めは定数のsalesで候補を確認し、その後に同じ値が入る想定の変数へ切り替えると、比較する条件を小さくできます。

変数名がdeptだからといって、中にsalesが入っているとは限りません。入力が空だった、別のノードが値を作った、同名の別の変数を選んだ、といった可能性があります。実行詳細で、選んだ変数の値と型、どのノードの出力かを確認します。

比較用の記録には「定数で指定した値」「変数で観測した値」「型」「元のノード」を残します。画面に表示された変数の名前だけでは、定数と同じ値を渡せたことを確認できません。改行や前後空白がある場合も、表示の見た目だけで一致と判断しないようにします。

例えば、原表の部署はsalesなのに、変数の実際の値が"sales\n"なら、末尾の改行も確認対象です。一方、その差が見つかったからといって、すべての入力を小文字化したり削除したりしてよいわけではありません。値の意味を保つ整形ルールを決めてから、架空データで確認します。

公式資料ではTime型のフィルタ値について、定数による指定という制約も案内されています。数値の年度を使う本稿の例と、日付フィールドの比較を混同しないでください。利用環境の型と選択できる値の方式を確認し、使えない選択肢を無理に同じ手順へ合わせないようにします。

自動モードは、手動条件と同じ結果の別名ではない

自動モードは、検索ノードへ渡されるクエリ変数に基づいて条件を自動設定する方式として、現行公式資料に案内されています。また、モデルの選択が必要です。手動の三条件をそのまま固定した状態とは異なるため、モードを変えた後も同じ候補になると決めません。

例えば「今年の営業向け資料を探して」という質問には、今年が何年か、営業をどの部署値へ対応させるか、承認済みだけを対象にするか、といった判断が含まれます。教材の目的が三条件の確認なら、まず手動で条件の意味を揃えます。自動モードの評価は、その後の別の課題にします。

自動モードを検討する際は、質問ごとに意図した条件を人が用意し、実際に生成・適用された条件と照合します。「営業資料を返した」という一件の成功だけでは、部署を変えた質問や年度未指定の質問にも対応できるか分かりません。少数の比較用質問を作る方が確認しやすくなります。

今回の記事では、自動モードやLLMによる条件生成を実行していません。PythonのAND・OR参照コードで確かめた結果を、Difyの自動モードの精度や再現性の実績として扱いません。原表を使う検算と、サービスの実行を分けて記録してください。

また、モデルを変えることと、メタデータの値を直すことを同時に行わないようにします。結果が変わっても、どちらが影響したのかを説明しづらくなるためです。手動の定数で一つずつ確認した記録があると、自動モードとの比較の出発点になります。

候補があっても0件なら、返却チャンクまで段階を分ける

三条件に合うAが原表に存在していても、質問に関連する検索結果が返るかは別です。Classic Knowledge Retrievalでは、検索するクエリ、対象ナレッジ、検索設定を指定し、結果をresultという配列で後段へ渡します。候補の文書一覧と、返された文書チャンクの一覧は同じものではありません。

一つの文書から複数のチャンクが返る場合もあるため、「候補文書1件なら結果配列も長さ1」と決めないでください。返された文書名や、実行詳細で確認できる文書の識別情報を使い、どの文書から来た内容かを確認します。配列の長さだけでは対象を照合できません。

候補があるのに空の場合は、文書が検索可能な状態か、検索クエリが意図した文字列か、スコアのしきい値や取得設定によって落ちていないかを分けて見ます。いきなりLLMへの指示を長くするより、検索ノード自体の入力と出力を確認すると、空になった段階を調べやすくなります。

反対に、検索ノードの出力には内容があるのに回答へ反映されない場合は、後段へ渡した変数を確認します。今回のメタデータ条件だけの問題とは分け、LLMのコンテキストや回答ノードへの接続を調べます。段階が違えば、修正する場所も変わります。

複数のナレッジを検索対象にする場合は、フィールド名の一覧にも注意します。現行資料では、複数選択時は共通のメタデータ項目が表示されると説明されています。一方だけに作った項目が見えないときに、値の入力ミスと決める前に対象の組合せを確認してください。

確認票に条件と実行結果を残し、質問先へ渡す

確認票は、環境・対象ナレッジ・ノード名・質問・条件・期待候補・実際の返却文書を一組にします。実行前の期待を書き、実行後に観測した値を足すと、「返った結果に合わせて期待を作り直した」状態を避けられます。候補が0件のケースも教材として残してください。

不一致がある場合は、一つの条件だけを変更して比較します。例えば部署の定数を確認した次に年度を加え、その次に状態を加えます。実行結果が想定と異なったら、直前の変更と文書側の値を見直します。全設定を一度に入れ替えると、再現例を小さくできなくなります。

過去の不具合記事が見つかっても、同じ版・構成・入力かを確認せずに原因と決めません。利用版、定数と変数の差、型、実行時の値を添えた小さな再現例にしてから、公式の案内や質問先へ照合します。「過去に似た相談がある」と「今の自分の原因が同じ」は別です。

独学では、原表の候補を手で説明できること、実際の検索結果に含まれる文書を確認できることを最初の到達点にします。複雑な自動条件や大量文書を増やすのは、その後です。6文書のどれが条件へ合うか分からないまま、資料だけを増やさないようにしましょう。

講座や個別支援を比較する場合は、Difyの操作紹介だけか、文書管理・RAGの評価・条件の確認まで扱うかを相談します。持ち込み資料を使えるか、版の違う環境へ対応できるか、質問できる期間と総額は別に確認してください。特定の講座でこの事例の添削を受けられると、本稿から断定するものではありません。

Difyを講座で学ぶ選択肢として、バイテックの公式案内にはDifyマスター講座があります。今回のような条件の確認を学びたい人は、「Classicナレッジで、文書ごとの値から候補を説明する課題を扱いたい」と伝えると、相談内容を具体化できます。利用するDifyの版、メタデータやRAG評価の扱い、持ち込み課題への対応、質問期間と受講総額を申込前に確認してください。この6文書の添削が受講内容に含まれると保証するものではありません。確認日：2026年11月2日。

広告：バイテックの講座・無料カウンセリングの内容を確認する

よくある質問

Q. メタデータの項目はあるのに検索が0件です。

A.

対象文書に意図した値が付いているか、型と条件が一致するかを確認します。フィールドの作成と、各文書への値の付与は別です。まず定数一つで原表の候補と比べてください。

Q. salesとSalesは同じ部署として検索できますか？

A.

現行の公式フィルタ説明では大文字小文字を区別します。本稿の原表でも別の値です。同じ意味に揃える場合は、文書管理のルールを決めた上で確認し、検索結果を返すためだけに値を変えないようにします。

Q. ANDで0件ならORへ変えればよいですか？

A.

ORへ変えると対象が広がります。今回の三条件では、下書き・旧版・他部署も含む全6文書が候補になります。元の目的を満たすか、文書IDで確認してから判断してください。

Q. 候補の文書が1件なら、resultも1件になりますか？

A.

同じとは限りません。resultは検索された文書チャンクの配列で、一つの文書から複数チャンクが返る場合があります。配列の長さだけでなく、どの文書の内容かを確認します。

Q. 定数だと動くのに変数だと動きません。

A.

変数の名前ではなく、実行時の値・型・参照元ノードを調べます。定数と同じ値か、空白や改行がないかを確認し、利用版と小さい再現例を残します。過去の相談だけで現行の不具合とは断定しません。

Q. Agentナレッジでも同じ手順ですか？

A.

本稿はClassicナレッジとClassic Knowledge Retrievalを対象にしています。現行公式資料ではAgentナレッジ向けの検索ノードが別に案内されています。対象の種類とノードを確認してから、それぞれの資料を参照してください。