LlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断を実装者向けに解説

LlamaIndexは、社内に散らばったドキュメントやデータベースの中身をLLMから引ける形に変換し、質問に応じて必要な断片だけを取り出して回答を組み立てるためのPython製データフレームワークです。PyPI上の現行系列は0.14系で、最新版は0.14.23、対応するPythonは3.10以上4.0未満です（2026年7月時点）。この記事では、LlamaIndexが引き受ける取り込み・索引・検索・生成の4工程、DocumentとNodeという2つの単位の分け方、VectorStoreIndexと永続化の実装、別パッケージへ切り出されたWorkflowsの位置づけ、そしてLangChainとの使い分けまでを、実際にRAGを組む立場から整理しました。

まとめ：LlamaIndexを採用する条件と設計で先に決めること

LlamaIndexが向くのは、社内文書やナレッジベースを対象にした検索と回答生成が主目的で、取り込みから索引作成、検索、回答合成までの定型処理を短いコードで組み上げたい場合です。読み込みリーダーとベクトルストア接続のバリエーションが揃っているため、PDFやNotion、各種DBを対象にした初期構築の速度で優位に立ちます。

逆に、外部APIの呼び分けや複数エージェントの制御そのものが主題なら、フレームワークの選定より先に処理フローの設計が問われます。LlamaIndexならWorkflows、LangChain系ならLangGraphが担う領域で、ここは「検索を組むための道具」としてのLlamaIndexの中心からは外れます。

設計で最初に決めるべきは、チャンク幅と埋め込みモデルの2つです。この2つは後から変えると保存済みベクトルが使えなくなり、全件の再インデックスが発生します。件数が数万を超えてから見直すと、費用と時間の両方が跳ね上がるため、小さな検証データで先に確定させてから本番データへ広げる進め方をおすすめします。

LlamaIndexの定義とRAGパイプラインにおける守備範囲

取り込み・索引・検索・生成という4工程でLlamaIndexが担う範囲

LlamaIndexが引き受けるのは、外部データをLLMに渡せる状態にするまでの一連の工程です。PyPIのパッケージ説明も “Interface between LLMs and your data”、つまりLLMと手元のデータをつなぐ層だと明示しています。具体的には、ファイルやAPIからテキストを読み込む取り込み、テキストを小さな単位に割って数値ベクトルに変換し保存する索引作成、質問文に近い断片を引き当てる検索、引き当てた断片をプロンプトに詰めて回答を作る生成、この4つです。

この4工程はRAG（検索拡張生成）そのものの構成と一致します。RAGという仕組み自体の考え方や、ファインチューニングとの使い分けについてはRAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例で整理しているので、そもそもRAGでよいのかを判断する段階の方はそちらを先に読んでください。本記事はRAGを採ると決めた後の実装フレームワーク選定の話に絞ります。

0.14系という現行系列を使うためのPythonの前提条件と導入手順

2026年7月時点でPyPIに公開されている最新版は0.14.23です。requires_pythonは3.10以上4.0未満と指定されており、3.9以前の環境では入りません。社内の既存アプリへ後付けする場合、この下限が実質的な足かせになるケースがあるため、着手前にランタイムのバージョンを確認しておきましょう。

llama-index というパッケージ名はメタパッケージに近い扱いで、実体は llama-index-core と各種の統合パッケージに分かれています。ベクトルストアやLLMプロバイダとの接続は個別パッケージとして独立しており、必要なものだけを追加していく形です。この分割構造は、後述するimportパスの移動という落とし穴の原因にもなります。

取り込みの設計：DocumentとNodeという2つの単位を分ける基準

SimpleDirectoryReaderで読み込み、Documentとして受け取る

公式のスターター例では、SimpleDirectoryReader("data").load_data() でディレクトリ配下のファイルを読み込みます。返ってくるのはDocumentオブジェクトのリストで、ファイル1つがDocument 1つに対応するのが基本形です。PDFやWord、テキスト、CSVといった一般的な形式は拡張子から判別され、追加のコードなしで読めます。

ディレクトリ以外のデータ源に対しては、SlackやNotion、各種データベース向けのリーダーが統合パッケージとして用意されています。ここが初期構築の速度に効く部分で、社内システムの数だけ変換コードを書く手間を減らせるのがLlamaIndexを選ぶ実利のひとつでしょう。

Nodeへの分割幅と重なり幅が検索精度を左右する仕組みと設定基準

Documentはそのままでは索引に入りません。Node Parserを通してNodeと呼ばれる小さな断片に分割してから、ベクトル化して保存します。この分割幅（チャンクサイズ）と、隣り合う断片をどれだけ重ねるか（オーバーラップ）が、後段の検索精度をほぼ先に決めてしまいます。

幅を広く取ると1件の断片に文脈が多く残る反面、質問と無関係な文章まで一緒に引き当てられ、プロンプトが冗長になります。狭く取ると狙った文が正確に当たる一方、前後の文脈が切れて回答が断片的になりがちです。日本語のマニュアルや規程類では、見出し単位で切ってから幅の上限を設ける方針が扱いやすいと感じます。

埋め込みモデルの選択も同じ段階の判断です。公式スターターの既定はOpenAIのtext-embedding-ada-002ですが、日本語の精度やコストを考えると他モデルへ差し替える判断は十分あり得ます。ベクトル化そのものの仕組みとPythonでの実装はPythonでembedding（ベクトル化）を生成する方法で扱っているので、モデル差し替えを検討する際の下地にしてください。

索引と保存：VectorStoreIndexと永続化の実装を選ぶ基準

VectorStoreIndexで最小構成のRAGを組み立てる

読み込んだDocumentから索引を作るのは1行です。VectorStoreIndex.from_documents(documents) を呼ぶと、内部で分割・ベクトル化・格納までが走ります。あとは index.as_query_engine() でクエリエンジンを取り出し、await query_engine.aquery(query) で質問を投げれば回答が返ります。

この短さがLlamaIndexの入口の強みですが、裏返せば分割幅も埋め込みモデルも保存先も既定値が使われているということです。検証段階ではこの最小構成で十分でも、本番へ持っていく前に3つとも明示的に指定し直す前提で考えておくほうが安全です。

ローカル永続化と外部ベクトルDBを切り替える運用条件と判断基準

索引をメモリ上に置いたままだと、プロセスを再起動するたびに全ファイルを読み直して再ベクトル化することになります。これを避けるのが index.storage_context.persist("storage") による永続化で、再読み込みは StorageContext.from_defaults(persist_dir="storage") で行います。

ただしこのローカル永続化が現実的なのは、件数が小さく単一プロセスで完結する構成までです。複数インスタンスから同じ索引を引く、あるいは索引の一部だけを差分更新する要件が出た時点で、外部のベクトルデータベースへ移す判断になります。外部ストアを使う場合、永続化ファイルを介さずストアから直接読み直せる構成になると公式も説明しています。

移行先の候補としては、既存のPostgreSQLをそのまま使えるpgvectorによるベクトル検索が運用コストの面で扱いやすく、AWS側で完結させたいならAmazon S3 Vectors APIのように保管費用を抑える選択肢もあります。どちらもLlamaIndex側は接続用の統合パッケージを足すだけで済むので、フレームワークを変えずに保存先だけ差し替えられます。

検索と回答生成：クエリエンジンの内部で起きている処理の流れと役割

as_query_engineが担う検索と回答合成の2段構えと処理の流れ

クエリエンジンは、質問文をベクトル化して近い断片を上位k件取り出すRetrieverと、取り出した断片をプロンプトへ組み立てて回答文を作るResponse Synthesizerの2段で構成されています。既定では上位数件をまとめて1回のプロンプトに詰める方式ですが、断片数が多い場合には逐次的に回答を練り直す合成モードへ切り替えられます。

この2段が分かれていることが実務では効きます。回答が的外れなとき、原因が「そもそも正しい断片を引けていない」のか「引けているのに文章化で落としている」のかを、Retrieverの返り値を直接見れば切り分けられるからです。

検索精度が出ないときに原因を切り分けて手を入れる順番と判断基準

精度改善の打ち手は複数ありますが、着手する順番を間違えると徒労になります。まず確認するのはRetrieverが正解を含む断片を返しているかどうかで、返していないなら分割幅と埋め込みモデルの問題です。返しているのに順位が低いなら、検索後に並べ替えるリランクの導入が効きます。

リランクは検索で広めに拾ってから精度の高いモデルで並べ直す二段構えで、ベクトル検索単体の弱点を補います。モデルの種類と選び方はリランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方にまとめました。プロンプト文言の調整は最後で構いません。検索が外れている状態でプロンプトを練っても改善幅はごくわずかです。

Workflowsによるエージェント化と設計方式を分ける判断基準

別パッケージへ切り出されたWorkflowsの役割と導入時の位置づけ

複数ステップの処理や分岐、ツール呼び出しを含む構成を組む段になると、クエリエンジン1本では収まらなくなります。この領域をLlamaIndex側で担うのがWorkflowsで、現在は llama-index-workflows という独立パッケージとして提供されています。2026年7月時点の最新版は2.22.2、Pythonは3.10以上が条件です。

パッケージ説明は「イベント駆動・非同期優先・ステップ単位でAIアプリケーションの実行フローを制御する方式」とされており、処理をステップ関数として書き、ステップ間をイベント型で受け渡す構造になっています。RAGの検索フレームワークとは別軸の道具として切り出された、と捉えるのが実態に近いでしょう。

クエリエンジンで足りる場合とWorkflowが必要になる処理の境界

判断の境界は分岐の有無です。質問を受けて検索し回答を返すだけなら、クエリエンジンで完結します。質問の種類によって参照先を変える、回答の確からしさを評価して足りなければ再検索する、外部システムへの書き込みを伴う、といった条件が入った時点でWorkflowsの領域に入ります。

実装量は当然増えるので、最初からWorkflowsで組むのは避けたほうが無難です。まずクエリエンジンで動かして検索精度を確定させ、そのうえで分岐要件が確定してからWorkflowへ載せ替える順序なら、精度と制御フローの問題を切り分けながら進められます。

LangChainとの違いと併用が成立する構成を見極める条件

LangChainとLlamaIndexで守備範囲が重なる領域と実務上の分担

LlamaIndexとLangChainは競合として並べられがちですが、出発点が違います。LlamaIndexはデータをLLMから引ける形にする索引と検索が中心で、LangChainはLLM呼び出し・ツール・記憶・チェーンといった構成要素を組み合わせるアプリケーション側の枠組みが中心です。実際にはどちらもRAGを組めるので、機能表だけを見ると重なりが大きく見えます。

選定の実務的な問いは「主な課題が検索精度か、制御フローか」の1点に集約されます。社内PDF数千件から正しい記述を引き当てる精度が課題ならLlamaIndex、複数の外部システムを呼び分ける制御が課題ならLangChain側から入るのが素直です。LangChain側の全体像はLangChainとは？LLMアプリ開発フレームワークの仕組み・できること・採用判断に、複雑フローを担うLangGraphとの関係はLangChainとLangGraphの違いにまとめてあります。

併用が成立する構成と責務が重なって二重管理になる構成の違いと判断基準

併用は成立します。ただし成立する形は限られており、LlamaIndexをRetrieverとして呼び出し、その外側の制御をLangChainが持つ構成に限ると考えておくと事故が減ります。索引の作成と保持をLlamaIndexに寄せ、LangChain側は検索結果を受け取るだけにする分担です。

逆に避けたいのは、両方でドキュメント読み込みと分割を持つ構成です。分割幅が2系統に分かれ、片方だけを直したときに検索結果が説明できなくなります。LangChain単体でRAGを組む場合の実装はLangChainを使ったRAG（検索拡張生成）の概要と実践方法で扱っているので、どちらに寄せるかを比べたうえで一方に統一してください。

実装で踏みやすい落とし穴と運用コストを見積もる判断基準と注意点

統合パッケージの分割によって変わったimportパスと移行時の注意点

LlamaIndexは統合部分を細かなパッケージへ分ける方針を取っており、系列が上がるタイミングでパッケージの再編やimportパスの移動が起きます。0.14系への移行でも、非推奨だったエージェント系クラスの整理と統合パッケージの見直しが行われたとされています。ネット上のサンプルコードは古い系列で書かれたものが多く残っているため、動かないときはまずimport文の系列違いを疑ってください。

対策としては、llama-index本体と統合パッケージのバージョンをまとめて固定し、公式ドキュメントの現行ページだけを参照する運用が確実です。バージョンを上げる際は、検証環境で最小構成のクエリを1本通してからにしましょう。

埋め込み費用が発生する処理と再インデックスが起きる条件の整理

費用の中心はLLMの回答生成ではなく、初回の埋め込み処理に集まりがちです。数万ページ規模の社内文書を一度に投入すると、埋め込みAPIの呼び出しがまとまって発生します。ここは1回で終わるならまだしも、次の条件に当たると全件やり直しになります。

• 埋め込みモデルを別のものへ差し替えたとき（ベクトルの次元と意味空間が変わるため）
• チャンク幅や重なり幅を変えたとき（断片の切れ目が変わるため）
• 前処理を変えたとき（表や画像の扱いを変えると本文が変わるため）

この3つはいずれも設計の初期判断です。だからこそ、まず数十件の代表文書で検索精度を測って条件を固め、そのあとで全件を流す進め方を勧めています。逆に、文書が追加されただけなら差分の取り込みで済み、全件やり直しは起きません。

LlamaIndexの採用判断：選ぶ条件と見送る場面の見極め方

LlamaIndexを採用してよい要件と導入前に確認する判断条件

次の条件が揃っているなら、LlamaIndexを軸に据えて問題ありません。第一に、対象データが社内文書・マニュアル・過去案件資料といった非構造テキスト中心であること。第二に、実装言語がPython 3.10以上で固定できること。第三に、当面の要件が「質問に対して社内資料から根拠付きで答える」の範囲に収まっており、外部システムへの書き込みを伴わないこと。

この3つを満たす場合、初期構築は数日規模で立ち上がります。分岐要件が後から出てきてもWorkflowsへ載せ替えられるため、最初の選択が行き止まりになりにくいのも採用しやすい理由でしょう。

LlamaIndexを見送るべき場面と、そのときの代替の考え方

見送る判断になるのは3つの場面です。1つは、主題が検索ではなく複数システムの制御にある場合で、このときは制御フロー側の枠組みから設計を始めるべきです。2つ目は、実装言語をPythonに寄せられない場合。3つ目は、対象データがすでに構造化済みのRDBに収まっていて、SQLで正確に引けてしまう場合で、ここでベクトル検索を挟むと精度が落ちます。

また、フレームワークの選定以前に、社内文書の粒度や更新体制が定まっていないと検索精度は上がりません。文書整備と索引設計を含めて外部の手を入れたい場合は、RAG構築支援で、データ整備からチャンク設計、精度評価、本番運用までを一貫してご相談いただけます。

よくある質問

LlamaIndexの導入検討と実装で繰り返し出てくる質問をまとめました。

LlamaIndexは無料で使えますか？

フレームワーク本体はオープンソースとして公開されており、ライセンス費用はかかりません。費用が発生するのは、埋め込みと回答生成で呼び出すLLM APIの従量課金と、ベクトルデータベースを含む実行環境の運用費です。同社が提供するマネージドサービス群は本体とは別の課金体系なので、無料枠の有無は導入時点で公式の料金ページを確認してください。

OpenAI以外のLLMや埋め込みモデルも使えますか？

使えます。公式スターターの既定がOpenAIのモデルになっているだけで、LLMと埋め込みはそれぞれ差し替え可能な構成です。統合パッケージを追加して設定を切り替える形になります。ただし埋め込みモデルを途中で変えると保存済みベクトルが無効になるため、切り替えは初期段階で決めてください。

チャンクサイズはどのくらいにすればよいですか？

一律の正解値はありません。文書の性質で変わるためです。決め方としては、代表的な質問を20問ほど用意し、幅を数パターン振って正解の断片が上位に入る割合を測るのが確実でしょう。規程やマニュアルのように見出し構造が明確な文書なら、見出し単位で切ってから上限幅を設ける方針が扱いやすくなります。

日本語の文書でも検索精度は出ますか？

出ますが、埋め込みモデルの日本語対応度に左右されます。英語主体のモデルでも動作はするものの、専門用語や社内固有の言い回しが多い文書では取りこぼしが増えます。日本語を含む多言語モデルを選んだうえで、ベクトル検索とキーワード検索を併用するハイブリッド構成にすると安定しやすいでしょう。

既存のRAGをLlamaIndexへ移行する価値はありますか？

すでに動いていて精度に不満がないなら、移行の必要はありません。移行を検討する価値があるのは、読み込み対象のデータ源が増えて変換コードの保守が重くなってきた場合や、索引の作り方を差し替えながら精度を比較したい場合です。索引部分だけをLlamaIndexへ寄せ、外側の制御は現行のまま残す部分移行から始めるとリスクを抑えられます。

関連記事

• RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説：LlamaIndexが実装する仕組みそのものの全体像と、RAGを採るべきかの判断を整理しています
• LangChainとは？LLMアプリ開発フレームワークの仕組み・できること・採用判断を解説：LlamaIndexと並べて比較されるもう一方の枠組みで、選定時の対になります
• LangChainを使ったRAG（検索拡張生成）の概要と実践方法：LangChain単体でRAGを組む場合の実装で、本記事の構成と比べる材料になります
• LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け：Workflowsに相当する制御フロー側の枠組みの位置づけが分かります
• リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方【2026年版】：第4章で触れた精度改善の二段構えを詳しく扱っています
• pgvectorの基本概要とPostgreSQLにおけるベクトル検索の重要性：索引の保存先を外部DBへ移す際の第一候補です