同じ架空の社内規程をGemini NotebookとDifyに登録し、根拠の提示や資料の不一致、更新時の扱いを検証しました。そのうちDifyでは、資料に書かれている承認手続や精算期限について「記載がない」「不明」と回答される問題がありました。
そこで、回答だけでなく検索結果と資料の分割を確認し、分割方法と取得件数を見直しました。承認手続を回答できるようになった一方、精算期限の回答には問題が残りました。
この記事では、その設定と確認手順を紹介します。同じ資料で試せる無料サンプルも公開しています。
検証環境と資料
検証全体ではGemini Notebook（無料）とDifyで、それぞれ40回答を記録しました。この件数には再実行や設定調整後の回答も含まれ、40種類の質問を一度ずつ試したという意味ではありません。この記事では、その中からDifyの設定変更前後の代表例を取り上げます。
2026年9月30日に、Dify CloudのSandbox、Chatflow、gpt-5-miniで検証しました。Difyのビルド番号とモデルの詳細パラメータは未記録です。画面や利用可能なモデルは環境によって異なります。
用いた初期資料は、次の6文書です。すべて架空の制度であり、実在企業の規程や法令の説明ではありません。
| ファイル | 内容 |
|---|---|
| TRV_v1.txt | 出張旅費規程 |
| EXP_v1.txt | 経費精算手順 |
| ELG_v1.txt | 雇用区分別対象条件 |
| EXC_v1.txt | 事前承認例外表 |
| FAQ_v1.txt | FAQ・問合せ先 |
| REG_v1.txt | 文書台帳と優先順位 |
FAQには「帰着から2週間以内」、正式文書には「終了日の翌日から10暦日以内」という不一致を意図的に含めています。正式文書を優先できるかも確認するためです。
本文に登場するEXC-2やEXP-1は、文書内の記述を探すための識別子です。EXC-2は事前承認の手続、EXP-1は精算期限に対応します。
Gemini Notebookでも確認した観点
Gemini Notebookでは、初期資料に加え、旧版と新版が併存する資料セット、旧版の金額を参照できない資料セットも使い、次の点を確認しました。
- 結論の根拠となる文書・版・条文を示せるか。
- FAQの「2週間」と正式文書の「10暦日」が異なるときに、正式文書を優先できるか。
- 改定後の出張で、予約日ではなく出張開始日を基準に適用版を判断できるか。
- 旧版の金額が資料にないときに、推測で補わず確認を促せるか。
記録には、改定後の宿泊費13,000円を実費として回答した例や、旧版が必要な出張について金額を特定せず確認を促した例がありました。ただし、これらの例からすべての質問で同じ判断ができるとは言えません。
Gemini NotebookとDifyで、利用モデルや検索設定をそろえた比較実験ではありません。ここでは製品の優劣や正答率を示す目的ではなく、資料を登録した後に確認すべき観点を共有します。以降は、検索resultとチャンク設定を確認したDifyの経過を詳しく扱います。
なお、無料サンプルに収録しているのは初期6文書です。上記の更新版併存・旧版欠落の検証には追加資料が必要で、今回の配布物には含めていません。
最初に区別したこと
「資料にない」という回答だけでは、登録資料そのものに記述がないのか、必要な箇所が検索されなかったのかを区別できません。
次の順に確認しました。
-
原文に必要な記述があるか。
-
登録後、その記述がどのチャンクに入ったか。
-
該当する質問の検索resultに、その記述が含まれるか。
-
取得された記述が回答に正しく使われたか。
チャンクは、検索に使う文書のかたまりです。回答の引用欄にファイル名が表示されても、そのファイルの全文がLLMに渡ったとは限りません。
初期の検索出力には、EXC-4、REG-3、FAQ-4、ELG-3という短い条文だけが返った記録がありました。その出力には宿泊上限や申請項目の条文はありませんでした。ただし、この検索記録を以下の代表質問の変更前後に直接対応するものとしては扱っていません。
分割方法と取得件数を変更
短い資料なのに、文書名や版情報と各条文が分かれていたため、6文書それぞれが1チャンクに収まるように設定を変更しました。同時に、取得件数の上限も増やしました。
| 設定 | 変更前 A | 変更後 B |
|---|---|---|
| チャンク構造 | General／汎用 | 同じ |
| チャンク識別子 | \n |
\n\n |
| 最大チャンク長 | 1024 characters | 同じ |
| オーバーラップ | 50 characters | 1 character |
| ナレッジベース側のトップK | 3 | 6 |
| 知識検索ノード側のトップK | 4 | 6 |
検証画面ではオーバーラップに0を指定できなかったため、1を使いました。TRVの分割は変更前が9チャンク、変更後のプレビューが1チャンクでした。変更後は文書名・版・条文が同じチャンクに含まれることを確認しました。
以下の条件は維持しました。
-
経済的インデックス、キーワード数10、逆インデックス検索
-
Rerank OFF
-
連続するスペース・改行・タブの置換ON、URL・メールアドレス削除OFF
-
資料本文、モデル、SYSTEMの回答指示、質問文
分割と取得件数を同時に変えたため、改善原因をどちらか一方に限定することはできません。 また、トップKの6は上限であり、6文書すべてを必ず取得させる設定ではありません。
改善した例 承認手続
質問E05は次のとおりです。
正社員の2026年9月開始の国内出張です。会場併設の指定ホテルへの宿泊が業務上必須で1泊16,000円です。予約前に必要な承認と提出内容は。
根拠となるEXC_v1.txt「事前承認例外表」版1.0の原文です。
[EXC-2] 予約前に、税込実費・宿泊日・理由・上限内候補を確認した記録を提出し、所属部長と経理責任者の両方の承認を得る。直属上司だけの口頭了解は満たさない。
変更前の回答には、次の記述がありました。以下は回答原文の抜粋です。
宿泊上限超過申請の具体的な提出書類・提出先・承認フロー（申請書の様式、必要添付資料、決裁者、申請タイミング等）は提供資料に記載がありません。
しかし、予約前に提出する内容と承認者はEXC-2に書かれています。様式など未定義の部分と、資料に記載済みの手続が一緒に「記載がない」と扱われていました。
設定変更後の回答には、次の記述が現れました。以下も回答原文の抜粋です。
予約前に「税込実費・宿泊日・理由・上限内候補を確認した記録」を提出し、所属部長と経理責任者の両方の事前承認を得る必要があります。
予約前というタイミング、提出内容、二者の承認を回答できるようになりました。根拠欄にもEXC 1.0とEXC-2が示されました。
これは必要事項の回答が改善した例です。回答全文の表現すべてが正確になった、という意味ではありません。
問題が残った例 精算期限
質問E12では、意図的にFAQの記述を示して確認しました。
FAQには精算は帰着から2週間とあります。正社員の国内出張が2026年9月12日に終了した場合、9月26日まででよいですか。
EXP_v1.txt「経費精算手順」版1.0の原文は次のとおりです。
[EXP-1] 出張終了日の翌日を1日目として10暦日以内に経費システムへ申請する。土日・祝日も数え、期限の休日繰越はない。
この架空規程では、9月13日が1日目なので、期限は9月22日です。
変更前の回答原文の抜粋です。
はい。FAQの「帰着から2週間以内」をそのまま適用すると、2026年9月12日帰着の場合は2026年9月26日までに精算を出せばよいです。
設定変更後も、次の回答が残りました。回答原文の抜粋です。
提供資料だけに基づくと、「帰着から2週間以内を目安に出せば大丈夫です」（FAQ-1.0・FAQ-2）なので、帰着日が2026年9月12日であれば2026年9月26日までに出すのは FAQ に沿えば「目安としては」問題ありません。
後半では正式な期限を確定できないと留保していましたが、9月22日という期限を回答できていません。冒頭の「目安としては問題ありません」も、利用者の判断を誤らせるおそれがあります。
変更後の引用欄にはFAQ、REG、EXC、TRV、ELGが並び、EXPは表示されていませんでした。回答自身もEXPの具体的内容が提示されていないと述べています。ただし、引用欄だけでは検索結果全体を確定できません。この代表回答に対応する検索result全文をこの記事では示していないため、取得漏れの断定と、回答上の不足の確認は分けて扱います。
無料サンプルで試す手順
GitHubの配布ページからZIPをダウンロードできます。
ナレッジに登録するのは、upload_only内の6文書だけです。手順書、質問集、回答指示を一緒に登録しないでください。
検索とLLMを接続
Chatflowを、ユーザー入力、知識検索、LLM、回答の順に接続します。
-
知識検索のクエリには、ユーザー入力のquery変数を選びます。
-
LLMのコンテキストには、知識検索のresultを選びます。
-
SYSTEM欄に共通指示を貼り、同じ欄へUIからコンテキスト変数を挿入します。
-
USER欄にはquery変数を設定します。
-
回答ノードにはLLMのtext出力を設定します。
コンテキストという文字を手入力するだけではなく、変数を選択します。この接続はDify公式ドキュメントでも説明されています。
検証で使ったSYSTEMの共通指示は以下です。
提供された資料だけを根拠に日本語で回答してください。結論、根拠の文書名・版・条番号、適用条件や例外を示してください。判断に必要な条件が不足する場合は確認質問をしてください。資料に記載がない事項は不明とし、資料にある問合せ先を示してください。矛盾する資料は優先順位と適用日を確認し、解消できなければ断定しないでください。外部知識で金額や制度を補わないでください。
共通指示を質問の先頭に付ける方法ではなく、SYSTEM欄へ設定した条件です。質問欄には質問本文だけを入れます。
同じ質問で変更前後を確認
まず設定AでE05、E12、E02を試します。E02は検索の確認に使う質問です。
国内出張の精算申請に必要な入力項目と添付物を教えてください。
その後、6文書の分割設定と両方のトップKを設定Bへ変更し、処理完了を待って同じ質問を試します。各質問は新しい会話で実行し、確認質問が返っても追加情報は返さず、最初の回答を記録します。
知識検索ノードの「最後の実行」では、入力が該当質問であることを確かめてから、出力resultのtitleまたはdocument_nameとcontentを確認します。
| 質問 | 検索結果で見る箇所 |
|---|---|
| E05 | EXC-2の承認者と予約前の提出内容 |
| E12 | EXP-1の期限と、正式文書を優先する規定 |
| E02 | EXP-2の入力項目と添付物 |
必要な条文がresultにあるのに回答が誤る場合と、resultに条文がない場合では、次に確認する場所が異なります。前者はLLMへの受け渡しや回答指示、後者は文書の状態、分割、検索条件などを確認する出発点になります。
ナレッジ側の検索テストも使えますが、アプリ経由とは設定や経路が異なり得ます。検索テストの結果だけで、実際の回答時にも同じ資料が渡ったと判断しないようにします。
このサンプルで確認できる範囲
今回の1文書1チャンクは、短い架空資料に対して試した方法です。長い規程全体を1チャンクにすればよい、という結論ではありません。
無料サンプルは、代表3問を設定AとBで比較する体験版です。更新版の併存や旧版欠落を扱う追加資料、内部評価ログ、全質問・期待回答・採点表は含めていません。
同じ検索結果・回答・所要時間を保証するものではありません。配布ZIPのダウンロードと内容の整合性は確認済みですが、新規環境でのパッケージの追試と第三者による追試は未実施です。
資料自体は無料です。Difyやモデルの利用料金・利用枠は別途確認してください。利用・改変・再配布の条件は同梱のUSE_TERMS.txtに記載しています。
次に検証したいこと
残った課題は、精算期限のように必要な文書を回答へ反映できないケースです。次は分割方法を固定して取得件数だけを変えるなど、条件を一つずつ切り分けて確かめたいと考えています。
目指しているのは、社内AI検索を導入するときに「資料を登録した後、何を確認すればよいか」を試せる手順にすることです。今回のサンプルでも、回答の良し悪しだけでなく、必要な条文がどこまで届いたかを見ていただければと思います。