--- title: "RAGのIndexingとは？インデックスの種類と構築手順・作り直しの判断【2026年版】" url: "https://www.issoh.co.jp/column/details/2672/" published: 2024-06-20 updated: 2026-10-26 categories: ["AI"] publisher: "株式会社一創" --- # RAGのIndexingとは？インデックスの種類と構築手順・作り直しの判断【2026年版】 RAG（Retrieval-Augmented Generation）のIndexingは、社内文書などを読み込み、チャンクに分割し、埋め込みベクトルに変換して索引（インデックス）へ登録するまでの工程です。質問が来る前に済ませておく準備工程で、ここで索引に載らなかった情報は、その索引を検索しても根拠として取得できません。 この記事では、索引に何が保存されるか、ベクトル以外にどんな種類の索引があり構築にどれだけLLMを呼ぶか、文書の追加・更新・削除をどう索引へ反映するかを、2026年10月26日に llama-index-core 0.14.25 と langchain-core 1.7.0 で実行した結果とともに示します。なお「インデキシング（インデクシング）」は一般には索引づけ全般を指す言葉で、検索エンジンがWebページを登録するSEOの「インデックス」とは別の話です。 ## まとめ：RAGのIndexingで先に決める4つのこと - **索引に載せる中身**：チャンクごとに埋め込みベクトル・元テキスト・メタデータ・文書IDを持たせます。メタデータや文書IDの後付けで必要になる作業は、保存先の更新APIとID管理方式によって異なります。 - **索引の種類**：基本はベクトル索引です。型番や条文番号で引く質問が多いならキーワード索引を併設し、文書群全体の傾向、長文書の階層構造、エンティティ間の関係をたどる質問では、要約・ツリー・グラフの索引を検討します。 - **構築コスト**：19チャンクの実測で、ベクトル索引の構築時のLLM呼び出しは0回、LLMでキーワードやエンティティを抽出する索引は19回でした。後者はチャンク数に比例して費用が増えます。 - **更新の方式**：LangChainの `index()` は、変わっていない文書を飛ばし、変わった文書だけを入れ替えます。ただし `cleanup="incremental"` では、元文書そのものを消しても索引からは消えません。削除を反映するなら、全件を渡す `full` か、対象IDを指定した明示的な削除を使います。 回答の精度が出ないとき、再ランキングを足す前に、正解のチャンクが索引に存在するかを確かめるのが先です。 ## RAGのIndexingの定義と索引に保存される中身 RAGの3分類を整理したGaoらのサーベイ（[arXiv:2312.10997](https://arxiv.org/abs/2312.10997)）は、最小構成のRAGのIndexingを次の流れで説明しています。PDF・HTML・Word・Markdownなどの生データを整形して共通のプレーンテキストにし、言語モデルの文脈長に収まるようチャンクへ分割し、埋め込みモデルでベクトルに変換してベクトルデータベースへ保存する。質問が来たときは、同じ埋め込みモデルで質問をベクトルにして近いチャンクを探します。索引側と質問側で同じモデルを使うことが前提になっている点が、後で述べる「作り直し」の条件につながります。 ### チャンクごとに保存する4つの要素 | 要素 | 中身の例 | 使われる場面 | | --------- | --------------- | -------------- | | 埋め込みベクトル | 1536次元の浮動小数点の配列 | 意味の近さで候補を探す | | 元テキスト | チャンクの本文 | LLMへ文脈として渡す | | メタデータ | 部署・文書種別・版・有効期限 | 検索範囲の絞り込み・権限制御 | | 文書IDとハッシュ | 元ファイル名・内容のハッシュ値 | 更新・削除の反映 | 容量の見積もりは単純な掛け算で出せます。1536次元のベクトルを32ビット浮動小数点で持つと1チャンクあたり6,144バイトになり、10万チャンクならベクトルだけで約614MBです。実際には近似最近傍探索のグラフ構造や元テキスト、メタデータの分がこれに上乗せされます。索引の内部構造はベクトルDBの解説記事[ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】](/tech/details/7691/)で扱っています。 ## インデックス構築の4工程と各工程で決まる精度の上限 | 工程 | 入力 | 出力 | 典型的な失敗 | | ------ | --------------- | -------- | ----------- | | 読み込み | PDF・Office・HTML | プレーンテキスト | 表と見出しの崩れ | | チャンク分割 | プレーンテキスト | 断片の配列 | 文の途中で切断 | | 埋め込み | 断片の配列 | ベクトル | 質問側とのモデル不一致 | | 索引登録 | ベクトルとメタデータ | 検索可能な索引 | メタデータの欠落 | 読み込みでPDFの表を1行ずつのテキストに潰すと、表の意味は後段で復元できません。スキャンPDFや段組みの多い資料では、レイアウトを保ったままMarkdown化するツールを挟むかどうかで結果が変わります。手順は[Doclingとは？PDFをMarkdown化してRAGに載せる実装手順と採用判断](/tech/details/17736/)で示しています。 チャンク分割では、既定値を出発点に、対象文書で文の切断や検索漏れが起きないかを評価して調整します。2026年10月時点で llama-index-core 0.14.25 の `SentenceSplitter` は1024トークン、langchain-text-splitters 1.1.3 の `RecursiveCharacterTextSplitter` は4000文字が既定で、単位が違います。後者の既定の区切り文字は段落区切り・改行・半角スペース・空文字の4つで句点を含まないため、日本語の長い段落は文の途中で切れます。切り方の比較と日本語での実測は[チャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測【2026年版】](/tech/details/8016/)にまとめました。 埋め込みモデルの選定は[埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準【2026年版】](/tech/details/16044/)、索引登録で使う近似最近傍探索のアルゴリズム（HNSW・IVF・PQ）は[近似最近傍探索とは？HNSW・IVF・PQの選び分けとRecall調整を実装目線で解説【2026年版】](/tech/details/16466/)を参照してください。 ## RAGで使うインデックスの種類と構築コストの違い 「RAGのインデックス」と言うとベクトル索引を指すことがほとんどですが、索引の作り方はほかにもあります。LlamaIndexの[索引の解説ページ](https://developers.llamaindex.ai/python/framework/module%5Fguides/indexing/index%5Fguide/)は、Summary Index・Vector Store Index・Tree Index・Keyword Table Index・Property Graph Indexを並べて仕組みを図示しています。違いがはっきり出るのは、構築時にLLMを何回呼ぶかです。 同じ規程風の文書1本を64トークンずつ19チャンクに分け、呼び出し回数を数えるダミーのLLMと埋め込みモデルを差し込んで各索引を構築しました（llama-index-core 0.14.25・各クラスの既定設定・ダミーのLLMは出力8トークン・埋め込みは8次元）。PropertyGraphIndexは既定で非同期に処理するため、同期と非同期の両方の呼び出しを数えています。 | 索引の種類 | LlamaIndexのクラス | 検索の仕方 | 構築時のLLM呼び出し | 埋め込み件数 | | -------------- | ----------------------- | ------------- | ----------- | ------------- | | ベクトル索引 | VectorStoreIndex | 意味の近い上位k件 | 0回 | 19件 | | 全件リスト | SummaryIndex | 全チャンクを順に渡す | 0回 | 0件 | | キーワード索引（正規表現） | SimpleKeywordTableIndex | キーワードの一致 | 0回 | 0件 | | キーワード索引（LLM抽出） | KeywordTableIndex | キーワードの一致 | 19回 | 0件 | | ツリー索引 | TreeIndex | 要約ノードを上からたどる | 2回 | 0件 | | 文書要約索引 | DocumentSummaryIndex | 要約で文書を選ぶ | 1回 | 1件 | | グラフ索引 | PropertyGraphIndex | エンティティと関係をたどる | 19回 | 19件＋新規エンティティ分 | KeywordTableIndexとPropertyGraphIndexは、チャンク1つにつきLLMを1回呼んでキーワードやエンティティを抽出します。今回と同じ抽出器で各チャンクを1回ずつ処理するなら、1万チャンクの新規構築は1万回が目安です。実際の回数と費用は、再試行、キャッシュ、入出力トークン数にも左右されます。TreeIndexの2回は、19チャンクを既定の10件ずつ束ねて親ノードの要約を2つ作った回数で、DocumentSummaryIndexの1回は文書ごとの要約です。PropertyGraphIndexの既定の抽出器は `SimpleLLMPathExtractor` と `ImplicitPathExtractor` の2つで、旧来の `KnowledgeGraphIndex` はバージョン0.10.53で非推奨になり、PropertyGraphIndexへの移行が案内されています。抽出結果が空でも、既定設定では元の19チャンクを埋め込みます。エンティティを抽出した場合は、重複排除後の新規エンティティの埋め込みも加わります。 ### ベクトル索引を基本にしてキーワード索引を併設する場面 ベクトル索引は構築時にLLMを使わず、埋め込みの費用だけで作れます。一方で、「KX-3200の保証期間」「第14条の改正内容」のように型番や条文番号で引く質問は、意味の近さより文字列の一致が効きます。こうした質問が多い社内文書では、BM25などのキーワード索引を同じチャンクに対して作り、検索時に結果を統合します。統合の方法は[ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード](/tech/details/8014/)、日本語での設定は[LangChain BM25Retrieverの使い方｜インストール・日本語対応・ハイブリッド検索](/tech/details/3751/)で扱っています。 ### 要約・ツリー・グラフの索引が必要になる質問 Gaoらのサーベイは索引の構造の改良として、ファイルを親子関係に並べて各ノードに要約を持たせる階層型の索引と、概念とエンティティのつながりを記録するナレッジグラフの索引を挙げています。どちらも、上位k件のチャンクを集めるだけでは答えられない質問のためのものです。チャンクを再帰的に要約して木を作るRAPTOR（[arXiv:2401.18059](https://arxiv.org/abs/2401.18059)、2024年1月31日公開）は前者、文書群の「主要なテーマは何か」に答えるために作られたGraphRAG（arXiv:2404.16130、2024年4月24日公開）は後者の代表です。 判断基準ははっきりしています。質問の大半が「この手続きの期限は」のように1〜3チャンクで答えが揃うなら、ベクトル索引で足ります。「過去3年の議事録で繰り返し出た論点は」のように文書群全体を見渡す質問に加え、階層構造やエンティティ間の関係をたどる必要がある場合に、評価結果と構築費用を比べて索引の追加を判断します。実装例は[GraphRAGをAzureで動かす方法｜graphrag 3.3の設定とAccelerator終了後の選択肢【2026年10月】](/tech/details/8326/)、長い単一文書を章立てでたどる方式は[BookRAGとは？階層ツリーとナレッジグラフで長文書を検索するRAGの仕組みと実装【VLDB 2026】](/tech/details/10269/)と[PageIndexとは？ベクトル不要の推論型RAGの仕組みと使い方【v0.2.19対応】](/tech/details/8760/)にあります。 ## LangChainのindex APIによる差分インデキシングの実行例 文書は毎日のように追加・改訂されます。そのたびに全件を埋め込み直すと、埋め込みの費用と時間が文書の総量に比例して膨らみます。langchain-core には、文書の内容をハッシュ化して記録し、変わったものだけを入れ替える [index() 関数](https://reference.langchain.com/python/langchain-core/indexing/api/index)があります。記録を受け持つのがRecordManagerで、次のコードはメモリ上の実装で動作を確かめたものです（langchain-core 1.7.0、埋め込みは動作確認用の決定的なダミー。実行にはnumpyが必要です）。 ``` from langchain_core.documents import Document from langchain_core.embeddings import DeterministicFakeEmbedding from langchain_core.indexing import InMemoryRecordManager, index from langchain_core.vectorstores import InMemoryVectorStore store = InMemoryVectorStore(DeterministicFakeEmbedding(size=256)) rm = InMemoryRecordManager(namespace="kitei") rm.create_schema() kw = dict(cleanup="incremental", source_id_key="source", key_encoder="sha256") docs = [ Document(page_content="経費精算は翌月5営業日までに申請する。", metadata={"source": "keihi.md"}), Document(page_content="出張旅費は役職に応じた上限額を適用する。", metadata={"source": "ryohi.md"}), Document(page_content="在宅勤務は週3日まで認める。", metadata={"source": "zaitaku.md"}), ] print(index(docs, rm, store, **kw)) # 1回目：全件登録 print(index(docs, rm, store, **kw)) # 2回目：変更なし docs[2] = Document(page_content="在宅勤務は週4日まで認める。", metadata={"source": "zaitaku.md"}) print(index(docs, rm, store, **kw)) # 1件を改訂 print(index(docs[:2], rm, store, **kw)) # zaitaku.mdを外してincremental print(index(docs[:2], rm, store, **{**kw, "cleanup": "full"})) # 同じ入力でfull ``` | 実行 | num\_added | num\_skipped | num\_deleted | | ----------------- | ---------- | ------------ | ------------ | | 1回目の全件登録 | 3 | 0 | 0 | | 2回目（変更なし） | 0 | 3 | 0 | | 1件を改訂 | 1 | 2 | 1 | | 文書を外してincremental | 0 | 2 | 0 | | 同じ入力でfull | 0 | 2 | 1 | 2回目は3件とも埋め込みが走らず、改訂した1件だけが新しいベクトルに入れ替わり、古いベクトルは削除されました。同じ本文に部署のメタデータを1項目足しただけでも、結果は「追加1・削除1」で、埋め込みのやり直しになりました。`index()` はハッシュを本文とメタデータの両方から計算するためです。ベクトルを変えずにメタデータだけを更新できる保存先もありますが、`index()` 経由で管理している限りは再登録になります。 ### incrementalで反映されない元文書の削除 表の4行目が落とし穴です。在宅勤務規程のファイルを入力から外して `incremental` で実行しても、削除は0件で、廃止したはずの規程が検索に出続けます。関数の説明にあるとおり、`incremental` が掃除するのは「今回の実行で見たソースIDに属し、更新されなかった文書」だけだからです。同じ入力で `full` にすると、ようやく1件が消えました。 ただし `full` は「今回渡されなかった文書を全部消す」動作なので、同じ説明に、ローダーがデータセットの一部だけを返すと消してはいけない文書まで消えるという警告があります。差分だけを取り込む日次ジョブでは `incremental`、週1回など全件を渡せるタイミングでは `full` を使います。`scoped_full` は、今回渡したソースIDの範囲だけで `full` と同じ掃除をする方式です。同じ3文書を登録した後に在宅勤務規程を外して `scoped_full` で実行すると、削除は0件で3件とも残りました。一方、2チャンクに分かれていた在宅勤務規程を1チャンクだけ渡すと、渡さなかった1チャンクが削除されました。一部のソースを処理するときは、そのソースの全チャンクを渡したうえで、入力から消えたソースは別途削除します。なお `key_encoder` を省略するとSHA-1でハッシュを取り、衝突耐性がないという警告が出るため、上のコードでは `sha256` を指定しています。本番では `InMemoryRecordManager` ではなく、SQLなどの永続化できるRecordManagerを使います。 索引をまるごと作り直して無停止で入れ替える手順や、削除を冪等に伝える文書IDの設計は[RAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断](/tech/details/16473/)で扱っています。LlamaIndexとLangChainのどちらで組むかは[LlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断を実装者向けに解説](/tech/details/15836/)と[LangChainでRAGを構築する手順｜v1.4系の2-Step・エージェント方式とPGVectorStore移行](/tech/details/2332/)が参考になります。 ## インデックスを作り直す変更と差分更新で済む変更 | 変更の内容 | 必要な作業 | | --------------- | -------------------------- | | 埋め込みモデルの変更・更新 | 全件の作り直し | | チャンクサイズや分割方針の変更 | 全件の作り直し | | メタデータ項目の追加 | 保存先で更新、またはindex()で変更対象を再登録 | | 文書の追加・改訂 | 差分更新で済む | | 文書の削除 | 全件入力でfull、または対象IDの明示的な削除 | 最も見落とされやすいのは埋め込みモデルの更新です。モデルが変わるとベクトルの空間そのものが変わるため、新旧のベクトルが同じ索引に混ざると、距離の計算が意味を持たなくなります。同じ次元数なら登録時にエラーが出なくても検索品質が低下するおそれがあり、次元数が異なれば登録や検索時にエラーになる場合があります。モデルを変えるときは新しい索引を別に作り、評価用の質問集で比べてから切り替えます。 ## Naive・Advanced・Modular RAGとインデックス側の改良 Naive RAG・Advanced RAG・Modular RAGの3分類は、Gaoらのサーベイ（arXiv:2312.10997、v1は2023年12月18日公開）が研究の発展段階を後から整理した呼び名で、製品名や規格ではありません。RAGという名前そのものは、Lewisらの原論文（[arXiv:2005.11401](https://arxiv.org/abs/2005.11401)、2020年5月22日公開・NeurIPS 2020採択）から来ています。 Indexingとの関係で読むと、3分類の違いは次のように整理できます。サーベイはAdvanced RAGについて、索引の問題に対処するためにスライディングウィンドウ、細かい粒度の分割、メタデータの付与を使うと述べ、検索前の処理として索引の最適化を「データの粒度の改善・索引構造の最適化・メタデータの追加・アラインメントの最適化・混合検索」の5つに分けています。Advanced RAGでは、検索処理だけでなく、チャンクの粒度・索引構造・メタデータなどIndexing側も改良対象になります。 | 分類 | Indexingの扱い | 主な出典 | | ------------ | ------------------- | ---------------- | | Naive RAG | 分割して埋め込んで保存するだけ | arXiv:2312.10997 | | Advanced RAG | 粒度・構造・メタデータ・混合検索を改良 | arXiv:2312.10997 | | Modular RAG | 索引や検索を交換可能なモジュールにする | arXiv:2407.21059 | Modular RAGは、同じGaoらが2024年7月26日に公開した論文（arXiv:2407.21059）が独立して扱っています。検索してから生成するという一直線の流れを前提にせず、モジュールに分解してルーティングや融合を組み込む考え方で、論文は実際の構成に繰り返し現れる型として直線型・条件型・分岐型・ループ型の4つを挙げています。社内文書の質問応答では、まずAdvanced RAGの構成で評価し、正答率・根拠の妥当性・応答時間が業務要件を満たすかを確認します。そのうえで、Modular RAGが要るのは、データベースと文書検索を質問の種類で切り替えるなど経路そのものを分けたい場合です。RAG全体の仕組みから知りたい場合は[RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説](/column/details/12919/)を先に読んでください。 ## インデックス設計で失敗する3つの場面 **再ランキングを索引の見直しより先に入れる。** 再ランキングは検索結果の並べ替えで、候補に入らなかったチャンクを呼び戻す機能はありません。例えば再ランキング対象を上位50件とした場合、そこに正解チャンクがなければ、分割・埋め込みに加えてクエリ、フィルタ、近似検索の設定も確認します。この候補集合に対して、[リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方【2026年版】](/tech/details/4413/)で扱う再ランキングを足しても推論費用が増えるだけです。正解チャンクの順位の測り方は[RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】](/tech/details/15935/)にあります。 **グラフ索引を全文書に一括で作る。** 先の実測のとおり、LLMでエンティティを抽出する索引はチャンク数だけLLMを呼びます。全社の文書に一度に適用すると、構築費用だけでなく、分割方針や抽出プロンプトを変えるたびに同じ回数の再構築が発生します。グラフ索引は、文書群を横断する質問が実際に出る範囲に絞って作るべきです。 **削除の反映を設計しないまま運用に入る。** 改訂は差分更新で入れ替わっても、廃止した規程が索引に残ると、RAGは古い規程を根拠に回答します。日次の取り込みと別に、全件を照合して消すジョブを用意してください。索引の設計から評価・運用まで外部の手を借りる場合は、弊社の[RAG構築支援](/service/ai/rag/)でも、文書の棚卸しと索引の作り直し方針から相談を受けています。 ## よくある質問 ### RAGのIndexingとRetrievalの違いは何ですか？ Indexingは質問が来る前に実行する準備工程で、文書を読み込み、チャンクに分割し、埋め込みに変換して索引へ登録します。Retrievalは質問が来てから実行する検索工程で、登録済みの索引から関連するチャンクを取り出します。回答の精度が出ないときは、正解チャンクが索引に存在するか（Indexing）を先に確かめ、次にそれが検索の上位に来ているか（Retrieval）を見ます。 ### RAGのインデックスには何が保存されているのですか？ チャンクごとの埋め込みベクトル、元のテキスト、メタデータ、文書IDとハッシュが基本です。ベクトルは意味の近さで候補を探すため、元テキストはLLMへ渡すため、メタデータは部署や版での絞り込みのため、文書IDとハッシュは更新・削除の反映のために使います。 ### インデキシング（インデクシング）とはどういう意味ですか？ 英語のindexingで、後から素早く引けるように索引を作る作業全般を指します。データベースでは検索を速くするための索引の作成、SEOでは検索エンジンがページをデータベースに登録すること、RAGでは文書を分割・埋め込みして検索できる索引に登録することを指し、分野によって対象が違います。 ### RAGのインデックスはどのタイミングで作り直せばよいですか？ 埋め込みモデルや分割方針を全体に変更するときは、対象文書群を再処理します。メタデータの追加は、保存先の更新APIまたは変更対象の再登録で対応します。文書の追加や改訂は、LangChainの `index()` のような差分更新で変わった文書だけを入れ替えれば済みます。文書の削除は差分更新の `incremental` では反映されないため、全件を渡す `full` か、削除対象IDを指定した明示的な削除で反映します。 ### Naive RAG・Advanced RAG・Modular RAGの違いは何ですか？ Gaoらのサーベイ（arXiv:2312.10997、2023年12月18日公開）が示した研究段階の分類です。Naive RAGは分割・埋め込み・検索・生成を一直線に行う最小構成、Advanced RAGは索引の粒度やメタデータ、検索の前後処理を改良した段階、Modular RAGは工程を交換可能なモジュールに分けて経路を組み替える段階を指します。新しいほど良いという序列ではなく、どの制約を解こうとしたかの違いです。 ## 関連記事 - [RAGパイプラインとは？取り込み系と推論系に分ける工程設計と再索引の実装判断](/tech/details/16473/) - [チャンクとトークンの違いとは？チャンク分割の手法とRAGのサイズ設計を日本語で実測【2026年版】](/tech/details/8016/) - [ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】](/tech/details/7691/) - [ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード](/tech/details/8014/) - [RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説](/column/details/12919/) --- 出典: [RAGのIndexingとは？インデックスの種類と構築手順・作り直しの判断【2026年版】]()（株式会社一創）