初めに
RAG の「取込・検索・回答設定 › 文書解析」を開くと、「解析後の処理」にこんな項目が番号つきで並んでいます。
1 番の「図・画像を AI で読み取る」は名前のとおりですが、2〜5 番は名前だけでは何が変わるのか分かりにくい設定です。
- 図・画像を AI で読み取る
- 見出しの階層の推定（AI）
- メタデータ/項目抽出
- 章節の抽出規則
- 章節の要約
有効にすると、検索や回答の何が変わるのか？
無効のままだと、何が起きないのか？
「章節の抽出規則」と「章節の要約」は、どう関係するのか？
この記事では、Production Ready RAG のこの 4 つの設定を、自分で作った合成のテスト文書で実際に切り替えて、画面で何が変わるのかを確かめます。並びは画面と同じ 2 → 5 の順にします。
この記事のテスト文書・会社名・部署名・内線番号は、すべて記事のために作った架空のものです。
2026 年 10 月 22 日時点の機能で確かめています。
先に結論
先に結論を書くと、4 つの設定の役割はこうなります。
| # | 設定 | 一言で言うと | AI | 効く場所 | 変えたとき |
|---|---|---|---|---|---|
| 2 | 見出しの階層の推定（AI） | 平らな見出しに、章・節の深さを付ける | テキストの LLM（文書ごとに通常 1 回） | 章節の木・chunk の見出しの階層（section_path）・分割の境界 | 解析からやり直し |
| 3 | メタデータ/項目抽出 | 本文から「文書番号・発行日」などの値を取り出す | テキストの LLM | 文書の「抽出項目」・検索の絞り込み・値の検索用 chunk | 抽出から再処理 |
| 4 | 章節の抽出規則 | どの行を「章節」にするかの規則 | 使わない | 章節ナビゲーション・章節の構成を読むツール・章節の要約の単位 | 取込なしで反映（要約は抽出から再処理） |
| 5 | 章節の要約 | 「章節の抽出規則」で作った章節ごとに 1〜2 文の要約を付ける | テキストの LLM（章節ごと・上限あり） | 章節ナビゲーションの要約・要約の検索用 chunk | 抽出から再処理 |
誤解しやすい点も、先に書いておきます。
- 4 と 5 は独立した設定です。 章節の木（章節ナビゲーション）は、章節の要約が無効でも作られます。章節の要約は、その木の各章節に「要約を足すかどうか」だけを決めます。
-
ただし、要約を付ける章節は「章節の抽出規則」で作った章節です。 規則を「公用文」にした文書なら、
第1第2… の章節ごとに要約が付きます。取込の後で規則を変えると、要約と章節が合わなくなるので、抽出から再処理します。 - 項目の値と章節の要約は、検索用の chunk にもなります。 値や要約に検索で当たると、その元になった原文の chunk を根拠にします。
処理の順番は、画面の並びと同じです。
設定する場所
4 つとも、全体の既定と文書ごとの上書きの 2 段で設定します。
全体の既定
冒頭の「取込・検索・回答設定 › 文書解析 › 解析後の処理」です。番号の順が、そのまま取込の処理の順です。
AI を使う 3 つ（見出しの階層の推定・項目抽出・章節の要約）には、それぞれ「〇〇プロンプト」の欄があり、モデルに渡す指示をこの画面で直せます。保存した指示は次の処理から使い、処理済みの文書には再処理するまで反映しません。
「設定の概要」の「2. 抽出」でも、全体の既定の値を一覧できます。
2026 年 10 月 22 日時点では、「設定の概要」と文書のレシピの画面では「章節の要約」が「章節の抽出規則」より前に並んでいます。処理の順は「解析後の処理」の画面のとおり、規則 → 要約です（Issue #3050）。
文書ごとの上書き（処理レシピ）
文書の詳細の「処理設定を編集」で、項目ごとに「グローバルを継承 / 上書き」を選べます。
さらに、1 つの文書に複数の処理レシピを持てます。今回はこれを使って、同じ文書を「既定のまま（AI の 3 つは無効）のレシピ1」と「3 つを有効にしたレシピ2」で取り込み、並べて比べました。
テスト用のデータ
ナレッジベースと検索・回答プロファイル
テスト用のナレッジベース「Qiita検証_解析後の処理」と、それだけを検索する検索・回答プロファイル「Qiita検証_プロファイル」を作りました。
項目抽出で取り出す項目は、ナレッジベースごとに定義できます。今回は 4 つを定義しました。
| 項目名 | 値の型 | 説明 |
|---|---|---|
| 文書番号 | 文字列 | 表紙などに書かれた文書の番号 |
| 発行日 | 日付 | 文書の発行日・施行日 |
| 発行元 | 文字列 | 文書を発行した会社・部署 |
| 文書の種類 | 文字列 | 規程・ガイド・手順書などの文書の種類 |
テスト文書
設定ごとに差が出るように、5 つの文書を作りました。PDF はブラウザで HTML から書き出し、しおり（PDF のアウトライン）を付けていません。文書解析はすべて Docling です。
| 文書 | 作りの特徴 | 確かめる設定 |
|---|---|---|
| 社内 Wi-Fi 利用ガイド | 表紙に文書番号・発行日・発行元。見出しは番号なしで、大見出しと小見出しの違いは文字の大きさだけ | 見出しの階層の推定・項目抽出・章節の要約 |
| 会議室予約システム 操作手順書 |
1. / 1.1 / 1.1.1 の番号の行を本文と同じ書式で書く |
章節の抽出規則「番号付き」 |
| 社内交流イベント開催要領 |
第1 / 1 / (1) / ア の番号の行を本文と同じ書式で書く |
章節の抽出規則「公用文」 |
| 備品貸出の案内 |
【概要】 と ◆ 予約する のような記号の見出し |
章節の抽出規則「独自の規則」 |
| 情報セキュリティ研修 実施要領 |
第1〜第5 の章ごとに 250 字以上の本文 |
章節の抽出規則「公用文」＋ 章節の要約 |
2. 見出しの階層の推定（AI）
何をするか
PDF を Docling で解析すると、しおりが無い文書では、見出しの深さ（章か節か）が分からないことがあります。見出しが全部同じ階層に並んでしまうのです。
番号（「第1章」「1.1」など）があれば、その番号の体系から深さを決められます。しかし番号の無い見出しは、文字の大きさのような見た目でしか区別できません。
「見出しの階層の推定（AI）」は、見出しの文字列だけをまとめて LLM に送り、章・節の深さを推定させます。 本文は送りません。
ただし、どの文書にも動くわけではありません。次の条件をすべて満たす文書だけが対象です。
- 解析エンジンが Docling
- PDF のしおりの階層を使えない
- 番号から深さを決められない見出しの割合が一定以上（既定 50%）
- 見出しの数が一定の範囲（既定 3〜300 件）
無効のとき
レシピ1（無効）の章節ナビゲーションです。表紙の題名の下に、11 個の見出しが全部同じ深さで並んでいます。
有効のとき
レシピ2（有効）です。「対応端末」「証明書の取得」が「接続の準備」の下に入り、「つながらないとき」「速度が遅いとき」が「トラブルシューティング」の下に入りました。
（各章節の下の文は、後で説明する「章節の要約」です。）
ただし、本来は大見出しの「接続の手順」が「接続の準備」の下に入り、その下にあるはずの「社内ネットワーク」「来客用ネットワーク」は 1 段上に残りました。AI の推定は完全ではありません。 大事な文書は結果を確かめ、必要なら章節ナビゲーションの「編集」で直します。
章節の表示だけではない
この設定は、章節ナビゲーションの見た目だけでなく、chunk に付く見出しの階層（section_path） も変えます。「Chunk / Citation」タブで、同じ「対応端末」の chunk を比べました。
無効のとき：
有効のとき：
「社内 Wi-Fi 利用ガイド（サンプル） > 対応端末」が「社内 Wi-Fi 利用ガイド（サンプル） > 接続の準備 > 対応端末」に変わっています。見出しの階層は検索結果の表示や分割の境界にも使われるので、変えると解析からやり直しになります。
3. メタデータ/項目抽出
何をするか
本文から、定義した項目の値を LLM で取り出します。取り出した値は、次の 2 つに使われます。
- 検索で文書を絞り込む条件
- 値そのものを検索する chunk（後述）
項目は全体の既定（標準は「文書の種類」「文書タイトル」「発行日・作成日」「発行元・作成部署」）か、ナレッジベースごとの定義を使います。今回はナレッジベースで 4 項目を定義しました。
有効のとき
レシピ2 の「構造化要素」タブに「抽出項目」が出ました。表紙の 4 つの値が、型と確からしさつきで取り出されています。
「発行日」は表紙の「2026年4月1日」から、日付型の 2026-04-01 になっています。
無効のとき
レシピ1 には「抽出項目」の欄自体が出ません。値が無いので、次の絞り込みの対象にもなりません。
検索での使い方：絞り込み
「RAG 検索」の「詳細条件 › 抽出項目の値で絞り込む」で、項目と条件を指定します。日付型の項目は開始日・終了日で範囲を指定できます。
「問い合わせ先の内線番号は？」で検索すると、条件なしでは 41 件が見つかり、テスト用の文書のうち 5 件が結果に入りました（イベント開催要領や研修の実施要領の問い合わせ先も含みます）。「発行日 ≥ 2026-01-01」を付けると 24 件になり、発行日を取り出せた Wi-Fi 利用ガイドだけが残りました。
値の無い文書は、絞り込みの条件を付けると除かれます。 項目抽出を有効にしていない文書や、値が書かれていない文書は、どんな条件でも結果に出なくなります。絞り込みを使うなら、対象の文書すべてで項目抽出を有効にしておきます。
検索での使い方：値の chunk
取り出した値は、「文書番号: IT-GUIDE-0042」のような 1 行の chunk にもなり、本文の chunk と一緒に検索されます。レシピ2 の「Chunk / Citation」タブを見ると、本文の chunk（#0〜#12）の後ろに、field の chunk が 4 件（#13〜#16）と、後で説明する章節の要約の chunk（section_summary）が並んでいます。
この値や要約の chunk に検索で当たったときは、その元になった原文の chunk を回答の根拠にします（値・要約の文そのものは根拠にしません）。実際に「IT-GUIDE-0042」で検索すると、結果に出たのは値の chunk ではなく、表紙の原文の chunk でした。
値の chunk の見出しの階層が、値を読み取った表紙（p.1）ではなく、文書の最後の章節「問い合わせ先」になっています。表示だけの問題ではなく、見出しの階層を使う処理にも影響するため、Issue にしました（#3054）。
4. 章節の抽出規則
何をするか
章節ナビゲーションの章節を、どの行から作るかを決めます。
| 方式 | 章節にする行 |
|---|---|
| 解析エンジンの見出し（既定） | 解析エンジンが「見出し」と判定した行 |
| 公用文（第1・1・(1)・ア・(ア)） |
第1 → 1 → (1) → ア → (ア) で始まる行を、この順の階層に |
| 番号付き（1. / 1.1 / 1.1.1） |
1. → 1.1 → 1.1.1 で始まる行を、この順の階層に |
| 独自の規則 | 自分で書いた正規表現と階層 |
（画面では、このほかのプリセットも選べます。）
ポイントは 3 つです。
- AI を使いません。 規則（正規表現）を各要素の 1 行目に当てるだけです。
- 取込をやり直さずに反映します。 保存すると、次に章節を表示したときから新しい章節になります。
- chunk の本文や embedding は変わりません。変わるのは章節ナビゲーションと、章節の単位で文書を読む仕組み（章節の構成を返す MCP ツールなど）、そして次に取り込むときの章節の要約の単位です。
解析エンジンは、本文と同じ書式で書かれた番号の行を見出しと判定しないことがあります。そういう文書でも、規則を当てれば章節を作れます。
番号付き：会議室予約システムの操作手順書
「解析エンジンの見出し」では、章節は「1. 概要」「1.1 対象者」の 2 個だけでした。1.2 利用できる時間 以降の行は、Docling が見出しではなく「番号付きのリスト」と判定したためです。
方式を「番号付き」にすると、取込なしで、10 個の章節が 3 段の木になりました。
以前のバージョンでは、Docling がリストと判定した行の番号（1.2 など）が抽出結果から消え、「番号付き」でも拾えませんでした。今は番号が残るので、PDF でも規則が効きます。古いバージョンで取り込んだ文書は「抽出から再処理」すると反映されます。
公用文：社内交流イベント開催要領
「解析エンジンの見出し」では 5 個で、「第3」「第4」の章と「(1) 本社会場」が抜けています。
「公用文」にすると 12 個になり、第N → N → (N) → ア の階層がそろいました。
左の原本と並べると、本文の番号の構造がそのまま章節になっているのが分かります。
独自の規則：備品貸出の案内
プリセットに無い書き方は、独自の規則で正規表現を書きます。今回は次の 2 つにしました。
| 名前 | 正規表現 | 階層 |
|---|---|---|
| 【】で囲んだ見出し | ^【.+】$ |
1 |
| ◆で始まる見出し | ^◆\s*\S |
2 |
「解析エンジンの見出し」では【】の 3 つだけで、しかも 2 つ目以降が 1 つ目の下に入っていました。
独自の規則にすると、【】の下に ◆ の小見出しが入った 9 個の木になりました。
独自の規則は全体で 1 組です。文書のレシピで「独自の規則」を選ぶと、全体の設定画面で保存した規則を使います。
規則が効かないときは
規則は「解析結果の要素の文字」の 1 行目に当てます。規則が効かないときは、「構造化要素」タブで、要素の文字が規則の書き方で始まっているかを確かめるのが近道です。80 字を超える行と、文で終わる行は見出しにしません。
5. 章節の要約
何をするか
「章節の抽出規則」で作った章節ごとに、LLM で 1〜2 文の要約を付けます。
- 章節の木そのものは、この設定に関係なく作られます（AI は使いません）。
- 要約するのは、その章節が直接持つ本文がある程度の長さ（既定 200 字）以上の章節だけです。
- 要約する章節の数には上限があります（既定は前から 24 件）。
- 要約は章節ナビゲーションに出るだけでなく、検索用の chunk にもなります（項目抽出の値と同じく、当たったら原文を根拠にします）。
有効のとき（解析エンジンの見出し）
Wi-Fi 利用ガイドのレシピ2 では、「はじめに」「対応端末」「社内ネットワーク」「つながらないとき」の下に要約が出ました（「2. 見出しの階層の推定」の画面の再掲）。
「証明書の取得」「来客用ネットワーク」などには要約がありません。テスト文書でこれらの本文は 170〜190 字ほどで、200 字に届かなかったためです。本文の短い章節には要約が付きません。
有効のとき（規則で作った章節）
情報セキュリティ研修の実施要領は、レシピで「章節の抽出規則 = 公用文」「章節の要約 = 有効」にしてから取り込みました。第1 目的 〜 第5 問い合わせ先 の 規則で作った 5 つの章節すべてに要約が付いています。
要約は AI の言い換えなので、原文と言い回しが違うところがあります。たとえば「第4 受講の期限」の原文は「部署の責任者の承認を得たうえで」ですが、要約では「上司の承認のもと」になっていました。正確な内容は原文で確かめます。
取込の後で規則を変えると
要約は、取り込んだときの規則の章節に付きます。取込の後でレシピの規則を「解析エンジンの見出し」に変えると、章節ナビゲーションに次の案内が出て、要約は表示されなくなりました。
今回は、解析エンジンの見出しでも同じ 5 つの名前の章節ができましたが、それでも要約は付け替えられません（名前やページが似ているだけで、別の章節に要約を付けることはしない仕組みです）。規則を変えたら「抽出から再処理」 すると、今の規則の章節で要約を作り直します。規則を元に戻せば、保存済みの要約がまた表示されます。
無効のとき
Wi-Fi 利用ガイドのレシピ1 の画面のとおり、章節の木（見出しの一覧）は出ますが、要約はありません。要約の chunk も作られません。
気をつけたいこと
- 章節の数だけ LLM を呼ぶので、章節の多い文書ほど時間とトークンがかかります。
- 先に「章節の抽出規則」を決めてから取り込みます。後で規則を変えると、要約のために抽出から再処理が要ります。
反映に必要な操作
設定を変えたときに何をし直せばよいかを、まとめておきます。
| 設定 | 反映に必要な操作 |
|---|---|
| 見出しの階層の推定（AI） | 解析からやり直し（「ファイル準備から再処理」か「抽出から再処理」） |
| メタデータ/項目抽出 | 「抽出から再処理」 |
| 章節の抽出規則 | 不要（保存するだけ）。ただし要約を今の規則の章節で作り直すなら「抽出から再処理」 |
| 章節の要約 | 「抽出から再処理」 |
| 各機能のプロンプト | 次の処理から（処理済みの文書は再処理） |
| ナレッジベースの「抽出する項目」の変更 | 次の取込から（抽出済みの値は再処理まで変わらない） |
「Chunk から再処理」は抽出の結果を使い回すので、上の AI の設定は反映されません。ただし、抽出の結果に値・要約がすでにある古い文書は、「Chunk から再処理」で値・要約の chunk を検索に加えられます。
使い分けの目安
最後に、私ならこう使い分けます。
- まず「章節の抽出規則」を試す。 AI を使わず、取込もやり直さないので、試すコストがいちばん小さいからです。番号の体系がはっきりした文書なら、プリセットか独自の規則で章節が整います。
- 番号の無い見出しの PDF には「見出しの階層の推定」。 見た目でしか階層が分からない文書に効きます。結果は完全ではないので確かめます。
- 文書を属性で絞り込みたい・番号で探したいなら「メタデータ/項目抽出」。 発行日や文書番号で絞り込めるうえ、値そのものも検索に入ります。値の無い文書は絞り込みで除かれる点に注意します。
- 長い章節が多い文書には「章節の要約」。 章節ナビゲーションで中身をつかみやすくなり、要約も検索に入ります。規則を決めてから有効にし、必要な文書のレシピだけで有効にします。
全体の既定は無効のままにして、効果がありそうな文書のレシピだけで有効にする、という使い方もできます。今回のように同じ文書に 2 つのレシピを作って比べると、自分の文書で効くかどうかをすぐに確かめられます。
気になった点（作成した Issue）
今回の確認で見つかった点は、Issue にしました。
| Issue | 内容 |
|---|---|
| #3050 | 設定の概要と処理レシピで「章節の要約」が「章節の抽出規則」より前に並び、解析後の処理の順と逆になる |
| #3054 | 項目抽出の値の chunk に、値を読み取った箇所ではなく文書の最後の章節の見出しの階層が付く |
まとめ
- 「見出しの階層の推定（AI）」は、番号の無い見出しの深さを AI で推定し、章節の木と chunk の見出しの階層を変える
- 「メタデータ/項目抽出」は、本文から定義した項目の値を取り出し、絞り込みと、値そのものの検索に使えるようにする
- 「章節の抽出規則」は、どの行を章節にするかの規則。AI を使わず、取込なしで反映し、章節の要約の有無に関係なく効く。今は PDF のリストの番号も拾える
- 「章節の要約」は、規則で作った章節に要約を足し、検索にも使う。木そのものは無効でも作られる。規則を変えたら抽出から再処理する
設定の名前だけでは、何が変わるのかは分かりにくいものです。
でも、小さなテスト文書を作って、同じ文書のレシピを 2 つ並べれば、違いはすぐに目で確かめられます。
迷ったら、まず自分の文書で 1 つ試してみるのがおすすめです。