言語資源の「文書の参照」を試す：4つの設定で、RAG が「別の資料を見てください」の先を探す

初めに

資料を検索する RAG で、こんな回答を見たことはないでしょうか。

「接続先を登録して、接続テストを行うには？」
→ 検索で案内文書が見つかる
→ そこには「設定マニュアルの第3章を参照してください」とだけ書いてある
→ AI も「設定マニュアルの第3章を見てください」と答える
→ 結局、利用者が手でマニュアルを探し直す

検索は間違っていません。質問に関係する案内は見つかっています。ただし、実際の操作手順は、その案内が参照している別の文書にあります。

ここで必要なのは、案内を言い換えることではなく、「どの文書の、どこを見るのか」を読み取り、その先の内容も回答の材料に入れることです。

Production Ready RAG には、この文書の参照をたどる仕組みがあります。この記事では、言語資源の設定を 4 項目に絞って、次の 2 つの書き方を試します。

1. 文書と章を指定する：「設定マニュアルの第3章を参照してください。」
2. 文書だけを指定する：「設定マニュアルを確認してください。」

参照されるマニュアルは、あえて後から取り込みます。文書の取込では何を保存し、回答の検索では何を探すのかを、実際の画面と処理記録で確かめます。

文書・質問・画面の操作手順・入力値は、すべてこの記事のために作った合成データです。実在のシステムの操作手順ではありません。2026 年 10 月 25 日に実機で確認しました。

先に結論

項目	内容
何のために使うか	「別の資料を見てください」で回答を終わらせず、その資料の内容まで探すため
言語資源を置く場所	「取込・検索・回答設定 › 言語資源 › 文書を読む › 参照の書き方」
文書の取込で行うこと	Chunk の本文から参照を識別し、文書名・章などの情報を保存する
回答の検索で行うこと	見つかった Chunk の参照情報から、実際の文書と必要な Chunk を探す
章が指定されているとき	参照先の文書で、その章を探す
文書名だけのとき	参照先の文書の中で、質問に関係する箇所を検索する
参照先を後から取り込んだとき	元の文書に参照情報が保存されていれば、元の文書を再処理せずに、後の回答で参照先を探せる

流れはこうです。

ここでいう「回答の検索」は、チャットの回答や、RAG 検索で 「LLM で回答を生成する」を ON にした処理です。回答を作らない通常の検索だけの経路では、この参照先の補足は行いません。

テスト用のデータ

ナレッジベースと検索・回答プロファイル

ナレッジベースと検索・回答プロファイルは、どちらも「Qiita検証_文書参照」を新しく作りました。プロファイルの検索対象は、このナレッジベースだけです。FAQ・回答ルール・業務ガイドは登録していません。

文書は3件

今回は内容を確認しやすい Markdown ファイルを使い、文書ごとの処理レシピで解析エンジンを Unstructured にしました。分割方式は既存の設定を使っています。この組合せでは構造認識による分割に切り替わるため、Chunk の画面には「構造認識で分割しました」と表示されます。

ファイル	役割	取り込む順序
接続案内.md	「設定マニュアルの第3章」を参照する案内	先に取り込む
表示案内.md	「設定マニュアル」全体を参照する案内	先に取り込む
設定マニュアル.md	実際の操作手順がある参照先	後から取り込む

接続案内.md の本文です。

接続先を登録して接続テストを行いたい場合は、設定マニュアルの第3章を参照してください。
この案内には接続先の入力値やボタンの操作順序は記載していません。

表示案内.md の本文です。

画面の文字を大きく表示したい場合は、次の資料を使います。
設定マニュアルを確認してください。
この案内には表示倍率の値や保存の操作は記載していません。

参照先の 設定マニュアル.md には、次の 3 章を用意しました。

章	内容
第1章 概要	合成の設定画面であることと、説明の対象
第2章 表示の設定	「表示設定」→「表示倍率」で 125% →「適用」→ 文字が欠けないか確認
第3章 接続の設定	「接続設定」→ 接続先に demo-target →「保存」→「接続テスト」→「接続成功」を確認

案内には実際の入力値や手順を書いていません。案内だけを読んでも、具体的な操作を答えられないようにしています。

今回使う設定は4つ

置き場所

「取込・検索・回答設定 › 言語資源」を開き、「文書を読む › 参照の書き方」を選びます。

今回は次の 4 項目だけを変更し、それぞれ 1 行に絞って保存しました。

画面の項目名	今回の値	何を見分けるか
参照の手がかりの語	を参照	「ここで何かを参照している」という手がかり
文書名の語尾	マニュアル	章の表記の前にある文字から、文書名の候補を見分ける
文書名と表記の間に置ける語	の	「設定マニュアル の 第3章」の接続
文書名だけの参照の述語	を確認	章を指定しない「設定マニュアル を確認」という書き方

「4 項目だけ変更する」のであって、ほかの設定を空にするわけではありません。 「第」「章」の番号の読み方、句読点、文書名に使う文字などは、既存の設定を使っています。

また、言語資源の全体設定はほかの文書にも関係します。今回のように値を絞る確認は検証環境で行い、既存文書を一括で再分割しないようにします。この検証の終了後、全体設定は開始前の値に戻しました。

「文書名の語尾」は、文書を命名する設定ではない

「マニュアル」という語をファイル名に付ける設定ではありません。また、「この文書のタイトルは設定マニュアルです」と登録する欄でもありません。

たとえば次の文では、まだ文書名は確定していません。

設定マニュアル の 第3章 を参照してください。

プログラムは「を参照」を見つけ、その前の「第3章」を読みます。さらに前の文字を調べ、「マニュアル」で終わり、その後ろが「の」でつながっているので、「設定マニュアル」を文書名の候補にする、という順です。

設定マニュアル  の  第3章  を参照してください。
────────────  ──  ────  ──────
文書名の候補   接続  位置   参照の手がかり

タイトルと先に分かっているわけではなく、この書き方から「別の文書の名前らしい」と判断しているのがポイントです。実在するどの文書かは、回答するときに照合します。

保存前後の「試す」で確かめる

同じ画面の「試す」に、次の 2 行を入れました。

設定マニュアルの第3章を参照してください。
設定マニュアルを確認してください。

結果には、第3章への参照と、文書全体への参照の 2 件が出ました。

この画面で確かめられるのは、文から参照の情報を取り出せるかどうかです。実際にその文書が入っているか、回答で使えるかまでは確認していません。

例1 文書と章を指定する

取込時は参照情報を保存する

最初に、接続案内と表示案内だけをアップロードし、処理を開始しました。設定マニュアルはまだアップロードしていません。

接続案内の「Chunk / Citation」には、次の本文が入りました。

保存された Chunk の metadata も確認しました。reference_targets_json の文字列を JSON として読み直すと、次の内容です。

[
  {
    "label": "第3章",
    "kind": "chapter",
    "key": "3",
    "document_title": "設定マニュアル",
    "section_path": null,
    "resolved": false
  }
]

「設定マニュアルの第3章を見る」という情報は保存できています。 ただし、参照先の文書と実際の章の場所は、この段階では決めていません。

resolved: false は、他の文書への参照を未解決のまま保存している状態です。それだけで取込の失敗を意味するものではありません。

参照先がまだ無いとき

RAG 検索でプロファイルを選び、「LLM で回答を生成する」を ON にして質問しました。

接続先を登録して接続テストを行うには、どのように操作すればよいですか？

この時点では、具体的な操作手順を確定できない回答になりました。

処理記録では、接続案内から第3章への参照を見つけていますが、参照先は not_found、追加した Chunk は 0 件でした。

参照の書き方を正しく識別できても、参照先の内容が検索できなければ、そこにある操作手順までは答えられません。

マニュアルを後から取り込む

続いて設定マニュアルをアップロードし、Unstructured で解析・分割・索引化しました。タイトルの Chunk と、第1章・第2章・第3章の Chunk、合計 4 件になりました。

接続案内と表示案内は再処理していません。 保存済み Chunk の内容も、マニュアルの取込前後で変わっていないことを確認しました。

同じ質問をもう一度送ると、今度は具体的な操作を答えました。実行履歴で確認した回答です。

「接続設定」を開き、demo-target を入力し、保存して接続テストを行い、「接続成功」を確認する、という内容です。根拠は 設定マニュアル.md に変わりました。

例2 文書名だけを指定する

取込時に章は決めない

表示案内の参照は、次の書き方です。

設定マニュアルを確認してください。

この例は 「文書名だけの参照の述語」＝「を確認」 で拾います。「第3章」のような位置の指定はありません。

保存された参照情報はこうなりました。

[
  {
    "label": "設定マニュアル",
    "kind": "document",
    "key": "",
    "document_title": "設定マニュアル",
    "section_path": null,
    "resolved": false
  }
]

例1の kind: chapter と違い、今回は kind: document です。

この文書名だけの参照は、章付きの参照とは別の識別規則です。「文書名の語尾」を必ず通るわけではなく、文書名に使う文字や一般語の除外など、既存の設定も使います。今回は漢字とカタカナの「設定マニュアル」で確認しています。

回答時に、その文書の中を探す

設定マニュアルが索引済みの状態で、次の質問を送りました。

画面の文字を大きく表示するには、どのように操作すればよいですか？

回答には、「表示設定」→「表示倍率」で 125% →「適用」 という、第2章の手順が出ました。

文書全体への参照では、取込のときに「第2章」と決めていません。回答時に文書名を照合し、その文書の中を質問に合わせて検索します。 文書の先頭から順に貼り付ける処理ではありません。

本当に参照をたどったのかを確かめる

ここは、答えが合っているだけでは判断できません。

今回の資料は 3 件しかないため、普通に検索すると、案内だけでなく設定マニュアルの該当箇所も最初から見つかりました。画面で確認した 2 つの回答では、参照先が present（すでに候補にある） となり、参照による追加は 0 件でした。

「マニュアルを取り込むと回答できた」ことと、「参照をたどって追加した」ことは分けて確かめる必要があります。

そこで、同じシステムの検索 API で、最初の検索だけを案内文書に限定する追加確認をしました。

項目	例1	例2
API	POST /rag/api/search	同左
generate_answer	true	true
検索・回答プロファイル	今回の検証用プロファイル	同左
filters.document_id	接続案内の文書 ID	表示案内の文書 ID
質問	接続先の登録と接続テスト	文字を大きく表示する操作

これは画面の設定を追加する操作ではなく、参照による追加を、最初の検索での命中から区別するための API 検証です。文書 ID を限定しても、参照先を探す範囲には同じ KB と利用者の権限などの制約が残ります。

結果は次のとおりでした。

処理記録	例1 章を指定	例2 文書名だけ
最初の検索候補	接続案内の 2 Chunk	表示案内の 2 Chunk
参照をたどった結果	added	added
参照で追加した数	1 Chunk	2 Chunk
追加された場所	設定マニュアルの 第3章	設定マニュアルの 第2章と第1章
操作手順の根拠	設定マニュアルの第3章	設定マニュアルの第2章

例1は指定された章、例2は文書内の検索と並べ替えで選んだ箇所です。文書名だけの参照では、今回の第1章のように、実際の操作手順以外の候補も一緒に入ることがあります。

これで、案内の Chunk を入口にして、最初の検索対象に入れていない別文書の Chunk を、参照によって追加できたことを確認できました。

追加確認で気になった点

案内だけに絞った API 検証では、参照先の Chunk と操作手順を取得できましたが、回答の末尾に 「原文の一部だけを取得したため未確認の範囲が残っています」 という案内も出ました。

参照先を取得する処理は元文書の ID の制限を外しますが、その後で章節を読み直す処理には元の絞り込みが残ります。取得済みの参照先を読み直す段階で条件が食い違う問題として、Issue #3325 にしました。通常の画面検索では、この案内は出ませんでした。

設定を変えると何が変わるか

設定の役割を確かめるため、「試す」と同じプレビュー API でも比較しました。比較用の値は保存していません。

入力文	比較した設定	結果
設定マニュアルの第3章を参照してください。	文書名の語尾＝マニュアル	第3章に加えて、文書名「設定マニュアル」も取れる
同じ文	文書名の語尾を空にする	第3章は取れるが、文書名が取れず null になる
設定マニュアルを確認してください。	文書名だけの参照の述語＝を確認	文書全体への参照が取れる
同じ文	文書名だけの参照の述語を空にする	参照は取れない

つまり「文書名の語尾」は、章の番号を見つける設定ではありません。見つけた第3章が、別のどの文書のものかを読み取るために使います。

また、2つの書き方は同じ設定を全部まとめて使うわけではありません。

文書＋章の参照
  を参照 → 第3章 → その前の「設定マニュアルの」から文書名を識別

文書名だけの参照
  を確認 → その直前から文書名を識別 → 文書全体への参照として保存

保存先をもう少し詳しく

参照情報は、別のファイルに書き出すのではなく、Chunk と一緒に DB に保存します。

RAG_CHUNKS                 ← テーブル
└─ METADATA_JSON           ← カラム
   └─ reference_targets_json ← JSON の中のキー

reference_targets_json は独立したカラムではありません。現在は、参照情報の配列を JSON 文字列にして、metadata の中に入れています。前の例の JSON は、その文字列を読み直した内容です。

このため、参照先の文書がまだ無くても「どの名前の、どの章を見るか」は保存できます。回答時に現在の文書を探すので、今回のように後から参照先を取り込めます。

試した結果のまとめ

確かめたこと	結果
文書名＋章の参照を識別できるか	設定マニュアル、第3章として保存できた
文書名だけの参照を識別できるか	設定マニュアル全体への参照として保存できた
参照先が無くても元文書を取り込めるか	取り込めた。回答時の参照先は not_found
後から参照先を取り込めるか	取り込めた。元文書の Chunk は変更・再処理していない
普通の検索で参照先がすでに見つかったら	present。重複して追加しなかった
最初の検索を案内だけに限定したら	参照をたどって、章指定は 1 件、文書全体は 2 件を追加した
制限した検索での注意点	参照先の章節読み取りに不整合があり、Issue #3325 を登録した

試すときのコツ

1. 最初は「文書名＋章」と「文書名だけ」の2例に絞る。 「前条」「別紙」「略称」は、基本の流れを確かめてから足します。
2. 案内と、実際の答えがある文書を分ける。 案内にも答えを書くと、参照をたどる必要がなくなります。
3. 「試す」で識別を確かめてから取り込む。 文書名や章が想定どおり取れるかを先に見ます。
4. 参照先も解析だけでなく索引まで完了させる。 未アップロード・未索引・権限外・検索対象外では、内容を追加できません。
5. 回答だけでなく、追加したかどうかも確かめる。 not_found・present・added を区別すると、どこまで動いたかが分かります。

今回の実行環境では参照をたどる機能は有効で、1 回の検索で参照によって補う上限は 4 Chunk でした。参照が識別できても、すべての文書や章を無制限に読みに行く仕組みではありません。

まとめ

• 文書の参照をたどる目的は、「別の資料を見てください」で止まらず、その先の実際の内容を回答に使うこと
• 取込時は Chunk の本文から文書名と位置を保存し、回答時に現在の検索範囲で参照先を探す
• 章を指定する参照と、文書名だけの参照では、使う識別規則と内容の探し方が違う
• 参照情報が保存されていれば、参照先を後から取り込んでも、元の文書を再処理せずに使える
• 正しい回答が出たことだけで判断せず、参照先が無かったのか、すでに候補にあったのか、参照で追加したのかを分けて確認する

まずは、資料にある「詳しくは○○を参照」という1文を選び、その先の文書とセットで試してみるのがおすすめです。

関連記事

• 検索・回答プロファイルの「Approved FAQ（類似問）」を試す
• 検索・回答プロファイルの「回答ルール」を試す
• 検索・回答プロファイルの「業務ガイド」を試す