LangChain RAGとLlamaIndexを比較：検索・エージェント・料金の選び方

LangChain RAGとLlamaIndex、どちらを選ぶべきですか？

文書を中心に据えたアプリケーションにはLlamaIndex、複数のツールを連携させて仕事を進めるエージェントにはLangChainが適しています。 どちらでもRAG（検索拡張生成）を構築できます。RAGは、関連する資料を検索してから、その内容に基づいてモデルに回答させる仕組みです。

製品マニュアルを参照するサポートアシスタントを開発する創業者なら、LlamaIndexから始めるのがおすすめです。文書、インデックス、クエリエンジンという抽象化により、取り込みから回答までの流れをコードの中心に据えられます。「必要な記述が検索から漏れる」「文書構造をどう扱うか」「どの根拠をモデルに渡すか」が次の技術課題なら、ここから着手するとよいでしょう。

規約を読み、注文を確認し、承認を得てから返金するアシスタントを開発するなら、LangChainが適した出発点です。現行のエージェントAPIはツールとモデルの実行ループを中心に構成され、基盤となる実行フレームワークをLangGraphが担います。状態管理、承認、次に実行する処理が課題なら、こちらから始めるのが自然です。

既存のアプリケーションが検索とワークフローの要件を満たしているなら、そのまま使い続けてください。フレームワークを替えても、解析を誤った表や安全性に欠ける決済処理は直りません。何の不具合を解消するのかを明確にしてから、足りないコンポーネントを追加します。

本記事では、文書の扱い、エージェント実行の制御、コンポーネント間の連携の境界、継続的なコストを比較します。判断はドキュメントに基づくもので、速度や精度の実測ランキングではありません。

出典：LlamaIndexのドキュメント、LangChainのドキュメント、LlamaIndexパッケージ、LangChainパッケージ、各社のLlamaParse料金表とLangSmith料金表。料金欄のホステッドサービスは用途が異なるため、同等のサブスクリプションとして比較することはできません。

現在のLlamaIndexとLangChainは何を担うのか

LlamaIndexは単なるインデックスではなく、LangChainもチェーンを集めただけのものではありません。 現行のドキュメントでは、どちらのエコシステムもエージェントを扱っています。違いは、どの用途で開発の土台が役立つかにあります。

LlamaIndex：データパイプラインと文書を扱うエージェント

LlamaIndexは、自社データを活用するエージェント向けのオープンソースフレームワークです。文書の読み込み、検索可能な表現への変換、根拠の検索、回答の生成を担う部品がそろっています。Workflowsでは、分岐、リトライ、人によるレビューを含むイベント駆動の処理も構築できます。公式のフレームワーク概要でも、この幅広い役割が明示されています。

契約書を扱うアシスタントでは、文書中の個々の記述を単位に考えると役立ちます。どこから取得した記述か、どの版に属するか、前後の節によって意味が変わるか、といった点です。LlamaIndexのNodeは、メタデータや関連情報を持つ原文のチャンクであり、こうした根拠を管理する場所になります。クエリエンジンは、その検索結果と回答生成を結び付けます。詳しくはVectorStoreIndexガイドを参照してください。

限界を左右するのは、入力する資料の品質です。ローダーが表を単純なテキストに変換し、価格と列見出しの対応を失ってしまうと、インデックスにもその誤りがそのまま残ります。LlamaIndexのドキュメントでも、構造が整ったテキスト向けの組み込みリーダーと、扱いが難しい文書向けの商用サービスLlamaParseは区別されています。データの抽象化を評価してフレームワークを選び、文書解析は別途評価してください。

保守の観点も欠かせません。現行のパッケージ説明では、開発元の主な注力先がLlamaParseと関連する文書ツールへ移った一方、フレームワークはオープンなツールキットとして引き続き提供されると説明されています。長期間依存するなら、採用を決める前に、必要な個々の連携機能の保守状況を確認しましょう。

LangChain：LangGraphを基盤に動くエージェント

LangChainはオープンソースのフレームワークです。現行のcreate_agent APIは、モデルが仕事を進めるためのツール、指示、周辺の実行ロジックをまとめた、設定可能なエージェント実行基盤を提供します。ミドルウェアで、そのループの前後の動作を調整できます。公式概要では、これらのエージェントの土台としてLangGraphが位置付けられています。

注文に関するサポートエージェントでは、検索は複数あるツールの一つにすぎないかもしれません。配送状況の照会や、返金案の作成も必要になるでしょう。こうしたツール間の連携が製品の中心になるなら、LangChainから始めるのが自然です。

ただし、エージェントの抽象化だけでは、業務上必ず守るべきルールまでは決まりません。誰が返金対象なのか、どの承認が必要なのか、処理を再実行しても二重返金しないためにどうするかは、自分たちで定義する必要があります。フレームワークは実行の仕組みを提供し、ルールはアプリケーション側が担います。

LangChainとLangGraphはどう使い分けるか

モデルがツールを選ぶ進め方が用途に合うなら、LangChainのエージェント抽象化を使います。ワークフローの状態と遷移を、より明示的に定義したいならLangGraphを直接使います。現行のLangChainエージェントにはすでにLangGraphが組み込まれているため、メモリや人によるレビューを追加するだけで、必ず全面的な書き直しが必要になるわけではありません。この判断は、別記事のLangChainとLangGraphの比較で詳しく扱っています。

確認時点のPythonバージョンとライセンス

2026年10月13日時点の確認では、公開されているPythonパッケージはllama-index 0.14.25、llama-index-core 0.14.25、langchain 1.4.5、langgraph 1.2.15でした。これは各パッケージを個別に確認した時点のバージョンです。エコシステム内のすべての連携パッケージが同じバージョンを共有しているわけではありません。

両フレームワークのリポジトリはMITライセンスです。LlamaIndexのライセンスとLangChainのライセンスで確認できます。ホステッド製品には別の商用利用条件が適用されます。フレームワークのライセンス料が無料でも、モデル推論、ホステッドのベクトルデータベース、アプリケーションサーバーは含まれません。

同じ小規模RAGを両方で実装する

どちらの例も、ローカルのテキストファイルを読み込み、メモリ内にインデックスを作成し、検索した資料を使って同じ質問に答えます。 APIの構成を示すための例であり、ドキュメントとの照合は行っていますが、本比較では有料のモデルAPIに接続して実行していません。

dataディレクトリを作り、自分の規約文書をUTF-8の.txtファイルとして保存します。OPENAI_API_KEYを設定し、RAG_MODELには、自分のアカウントで利用できる同じOpenAIのチャットモデルを両スクリプトで指定してください。埋め込みモデルは、どちらもtext-embedding-3-smallを明示的に選んでいます。埋め込みとは、似た内容を検索するための数値表現です。LlamaIndexの入門チュートリアルでも、埋め込みモデルを明示的に指定することが推奨されています。

LlamaIndexの実装例

llama-index-core、llama-index-readers-file、llama-index-llms-openai、llama-index-embeddings-openaiをインストールします。これらのコンポーネントを含むllama-indexスターターバンドルを使ってもかまいません。インストールガイドを参照してください。

import os
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

docs = SimpleDirectoryReader("data", required_exts=[".txt"]).load_data()
embed = OpenAIEmbedding(model="text-embedding-3-small")
index = VectorStoreIndex.from_documents(docs, embed_model=embed)
llm = OpenAI(model=os.environ["RAG_MODEL"])
engine = index.as_query_engine(llm=llm, similarity_top_k=3)
print(engine.query("What is the refund window?"))

この例では、from_documentsが文書からノードへの変換とインデックス作成を担います。検索と、検索結果をまとめた回答の生成はクエリエンジンが担当します。小規模なナレッジアシスタントでは、文書に対する処理をそのままコードで表せる点が利点です。変更が必要になれば、より低いレベルのコンポーネントにもアクセスできます。

LangChainの実装例

langchain-core、langchain-openai、langchain-text-splittersをインストールします。この固定の検索フローはLangChainのコンポーネントパッケージを使っているため、エージェントを追加するまでは、最上位のlangchainエージェントパッケージは不要です。各APIはRAGガイド、インメモリストアのリファレンス、OpenAI連携のドキュメントで説明されています。

import os
from pathlib import Path
from langchain_core.documents import Document
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
files = Path("data").glob("*.txt")
docs = [Document(page_content=p.read_text(encoding="utf-8"), metadata={"source": str(p)}) for p in files]
chunks = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100).split_documents(docs)
index = InMemoryVectorStore.from_documents(chunks, OpenAIEmbeddings(model="text-embedding-3-small"))
question = "What is the refund window?"
context = "\n\n".join(d.page_content for d in index.similarity_search(question, k=3))
llm = ChatOpenAI(model=os.environ["RAG_MODEL"])
print(llm.invoke(f"Answer only from this context; if absent, say unknown.\n{context}\nQuestion: {question}").content)

こちらの実装では、テキストの読み込み、分割、埋め込みと保存、関連する記述の検索、チャットモデルの呼び出しという手順が明示されます。部品をつなぐコードは増えますが、検索が大きなアプリケーションの一部にすぎない場合には、その明示性が役立ちます。

検索とエージェント制御、それぞれに向いているのは？

文書検索の出発点としてはLlamaIndexの抽象化が優れています。処理を連携させるエージェントの出発点としてはLangChainが優れています。 これは開発用途との相性についての判断であり、互いの領域を実装できないという意味ではありません。

文書の取り込みと検索にはLlamaIndex

主な変更箇所が、元の文書からモデルに渡す根拠までの間に集中するなら、LlamaIndexを選びます。インデックスとクエリエンジンの構造により、その作業をまとめて扱えます。たとえば契約の変更条項を横断して回答する調達アシスタントでは、ツール呼び出しのループを追加する前に、出典同士の関係を保つ必要があります。

LangChainでも同じ検索フローは構築できます。RAGのドキュメントでは、インデックス作成と、検索・生成を分けて説明しており、先ほどのコードはその基本形です。すでに十分な検索サービスがあるなら、別のフレームワークを導入するより、LangChainからそのサービスを呼び出すほうが手間を抑えられる場合があります。

検索が難しいサブシステムでなくなれば、判断は変わります。整備されたナレッジベースと複数の業務ツールがあるなら、エージェントのワークフローに開発労力を割くほうが有効です。

ツールを使うエージェントとワークフロー制御にはLangChain

規約を読む、顧客情報を取得する、不足情報を尋ねる、承認に回す処理案を準備する、というように根拠の確認と処理を交互に進めるなら、LangChainを選びます。設定可能なエージェントループとLangGraphの基盤が、この構成に適しています。

LlamaIndexもエージェントに対応しています。公式のエージェントガイドはツールを使うエージェントを説明しており、入門チュートリアルでは検索を呼び出し可能なツールとして追加しています。検索し、計算し、回答する文書アシスタントなら、すべてLlamaIndexの中で完結させることもできます。

すでにLlamaIndexで文書中心のワークフローを構築しているなら、製品が「エージェント」になったという理由だけで移行する必要はありません。新たに必要になったワークフロー制御が、実行層を変更するだけの理由になるときに移行します。

LlamaIndexとLangGraphの役割の違い

LlamaIndexとLangGraphは、異なる層を担当することがよくあります。LlamaIndexは根拠の準備と検索を担い、LangGraphはその結果を受け取った後、状態を持つワークフローをどう進めるかを制御できます。LlamaIndex自身のWorkflowsも実行層の選択肢になるため、両者の併用は機能不足を補うために必須なのではなく、アーキテクチャ上の選択です。

判断の軸は、どのコンポーネントが何を担当するかです。文書検索を担当するコンポーネントと、アプリケーションの実行状態を管理するコンポーネントを、それぞれ明確にします。双方が独立してリトライや会話状態を制御すると、処理が重複したときの原因究明が難しくなります。

検索品質は、製品名ではなく失敗の中身で評価する

機能一覧だけで、どちらのフレームワークの精度が高いかは決まりません。同じ資料群と質問を使い、回答の文章を評価する前に、正しい根拠を検索できているかを調べます。

規約を扱うアシスタントなら、通常の返金に関する質問、改定条項だけに答えがある質問、資料に答えがない質問、ユーザーが閲覧できない文書に関する質問を含めます。流暢な回答だけでは不十分です。出典の版、アクセス権限の境界、回答を裏付ける根拠を確認してください。

まずは固定の検索フローから始めます。追加の根拠収集で失敗した回答を修正できる場合に限り、状況に応じて検索を変える仕組みを加えます。エージェンティックRAGの解説では、その判断ループの追加がコストに見合う条件を扱っています。

どこまで無料で、何に料金がかかるのか？

フレームワークは無料ですが、ホステッドの文書処理、可観測性、デプロイは別途契約するサービスです。 以下の料金は、2026年10月13日に各社の米国向け公式料金ページで確認したものです。

LlamaCloudとLlamaParse

LlamaParseは、LlamaIndexの公開料金ページで現在使われているホステッド文書プラットフォームの名称で、LlamaCloudのダッシュボードから利用します。文書の解析、抽出、インデックス作成を担います。オープンソースのフレームワークと並行して提供される商用サービスであり、llama_indexをインポートするために契約が必要なわけではありません。

公開プランは、Freeが月額$0で10,000クレジット、Starterが月額$50で40,000クレジット、Proが月額$500で400,000クレジットです。Enterpriseは個別見積もりです。標準の従量料金は1,000クレジットあたり$1.25です。

PDFのページあたりの消費量は解析ティアによって異なり、Fastは1クレジット、Cost-effectiveは3、Agenticは10、Agentic Plusは45を使います。次の図は、同じ量の文書を処理したときの消費クレジットを、これらの公開単価で金額に換算したものです。プランに含まれる利用枠、最低契約料金、追加オプションは含めていないため、月々の請求額を示すものではありません。

Fastが出力するのはMarkdownではなく、空間的な配置を保ったテキストです。その形式が取り込み処理に合う場合に選んでください。クレジットがあっても、プランごとの上限はなくなりません。解析ジョブの同時実行数はFreeとStarterが5、Proが20です。アップグレードは必要な処理能力や機能に応じて判断します。クレジットの付属量が増えるだけで、必ず単価が下がるわけではありません。出典：従量料金、プラン比較。

LangSmith

LangSmithは、LangChainのエコシステムで提供される商用の可観測性・評価・デプロイ用プラットフォームです。LlamaIndexなど、ほかのフレームワークで構築したアプリケーションのトレースも取得できるため、フレームワークの選定とは別に採用を決められます。開発元もフレームワークをまたぐ対応について説明しています。

LangSmithの料金表では、Developerは1席で月額$0、5,000件のベーストレースを含みます。Plusは1席あたり月額$39で、合計10,000件のベーストレースが含まれます。追加の使用量には料金がかかります。Enterpriseは個別見積もりです。

トレースはアプリケーションの実行を記録したもので、複数のモデル呼び出しやツールのイベントを含むことがあります。トークンや、検索で取得した個々の記述と同じ単位ではありません。Plusには小規模なサーバーレスデプロイが含まれますが、追加のデプロイ使用量は別に予算化する必要があります。提供元は、顧客向けエージェントには専用デプロイを推奨しています。

同じ月間利用量なら、料金はいくらになるのか？

同じサービスを同じ量だけ使うなら、フレームワークを替えてもサブスクリプション料金は下がりません。 ここでは条件を絞り、アプリケーションとインデックスを別途ホストする、次の月間利用を想定します。

• 開発者3人がLangSmith Plusの席を必要とします。
• アプリケーションは20,000件のベーストレースを生成します。
• LlamaParseのAgenticティアで、新規のPDF 1,000ページを解析します。
• どちらの実装でも、同じチャットモデル、埋め込みモデル、トークン使用量とします。
• この想定では、ホステッドのIndex、ファイル保持用ストレージ、その他のクレジットを消費する文書操作は使いません。

解析の消費量は1,000 × 10 = 10,000クレジットです。ほかで使っていなければ、Freeの月間利用枠に収まります。消費クレジットを通常単価で換算すると**$12.50ですが、実際の請求額は$0**です。この二つは区別が必要です。クレジットに換算上の価値があっても、Freeプランでその金額が請求されるわけではありません。計算の根拠：LlamaParseのプラン、従量単価。

現行のLangSmith料金計算ツールでは、追加トレースあたり0.005 LSU、1 LSUあたり$1と表示されています。3席分は3 × $39 = $117です。共有の利用枠を超えるトレースの料金は**(20,000 − 10,000) × $0.005 = $50**になります。選んだサービスの小計は、LlamaIndexでも月額$167、LangChainでも月額$167です。

この小計には、モデル推論、埋め込み、自前のホスティング費用は含まれていません。アプリケーション全体の予算は、選んだサービスの料金にそれらを加えたものです。モデルの処理量をそろえれば、これらの費用条件もそろえられます。フレームワークによって検索やモデル呼び出しが増えるなら処理量自体が変わるため、別途測定する必要があります。

この条件では、フレームワークの違いによって料金の有利不利が逆転するポイントはありません。フレームワーク自体の料金はどちらもゼロのままで、同じ有料サービスを利用できます。文書処理の$50と可観測性の$39を並べても、比較している仕事が違います。支出を決めるのは、アプリケーションに必要なサービスと、その消費量です。

課金単位の違い：検索クエリとチャットターン

LlamaParseのホステッドIndex v2では、関連する解析・ストレージ料金に加え、検索クエリは1クレジット、チャットターンは100クレジットです。標準単価で1,000回の操作を換算すると、利用枠を考慮する前のクレジット相当額は、検索なら$1.25、ホステッドチャットなら$125になります。同じ回答に二つの価格があるのではなく、異なる操作への課金です。出典：Indexの料金。

フレームワークを組み合わせる際は、この区別が設計に関わります。呼び出し元のエージェントがすでに最終回答を生成するなら、その検索ツールから欲しいのは根拠そのものなのか、別サービスが生成した回答なのかを決めます。その選択はインターフェースと課金の両方に影響します。ローカルでquery_engine.query()を呼び出すだけで、ホステッドIndexのチャットターン料金が自動的に発生するわけではありません。この料金が関係するのは、そのマネージドサービスが実際のリクエスト経路に含まれる場合です。

LlamaIndexとLangChainを併用すべきなのはどんな場合か？

文書検索と処理の連携が、それぞれ独立して難しい場合に併用します。 規約の改定内容を読み解きながら承認ワークフローも進めるサポートエージェントは、その候補です。整ったテキストに対する単純な質問回答欄であれば、通常はそこまで必要ありません。

文書の取り込みと検索はLlamaIndexに任せます。関連する記述を、出典の識別子やメタデータとともに返す、役割を絞った関数またはサービスを公開します。LangChainのエージェントはそれをツールとして呼び出し、実行の基盤をLangGraphが担います。提供元のフレームワーク併用ガイドでも、この分担が説明されています。

先ほどのサポートの例なら、規約の該当箇所、文書ID、改訂情報のメタデータを返します。エージェントは注文情報と照合し、実行する処理の案を作成できます。最終回答まで出典の参照情報を保ち、アプリケーションが回答の根拠を確認できるようにしてください。

生成済みの完成した回答を、意図せず別の回答生成ループに渡す構成は避けます。クエリエンジンが返す文字列は便利ですが、呼び出し元のエージェントから、その元になった記述が見えなくなる場合もあります。出典の確認が重要なら、根拠が明示された検索結果を優先します。生成済みの部分回答を使うのは、そこを意図的なタスクの境界として設計した場合に限ります。

フレームワークを二つ使う追加コストは、保守に表れます。連携箇所が二系統になり、依存パッケージの更新が増え、監視すべき境界も一つ増えます。どちらも「エージェントを担当する」という説明で済ませず、それぞれの責務を説明できる場合に、併用する価値があります。

フレームワーク移行で引き継げるもの、壊れやすいもの

移行コストがかかるのは、import文の置き換えよりも、データの取り決めとワークフローの状態です。 LlamaIndexからLangChainへ移行するときも、LangChainの検索コンポーネントをLlamaIndexに置き換えるときも、まず既存アプリケーションが外部に公開しているインターフェースの取り決めを確認します。

元の文書と、エクスポート可能なメタデータを保持します。文書ID、アクセス権限を示すラベル、出典の改訂情報、引用の参照情報を維持してください。これらはアプリケーションの資産です。フレームワーク固有の文書やノードのオブジェクトは、その資産を扱うためのアダプターです。

埋め込みモデル、次元数、保存したテキスト、データベースのスキーマに互換性があれば、既存の埋め込みを引き続き使える可能性があります。ただし、新しいアダプターが全フィールドをそのまま読めるとは限りません。チャンクの区切り方や埋め込みモデルを変えるなら、該当するインデックスの再構築と検索結果の再評価を計画します。LlamaIndexのベクトルストアガイドでは、標準のインメモリストアと永続化対応の連携機能が区別されています。

ワークフローでは、会話状態、承認待ちの案件、未完了の処理を、データとは別の移行対象として扱います。状態を再構築するためだけに過去のツール呼び出しを再実行してはいけません。会話の見た目が正しくても、外部への処理を繰り返せば影響が生じることがあります。トラフィックを切り替える前に、既存セッションの終え方と新規セッションの始め方を定義してください。

安定して動いているLlamaIndexの文書エージェントを、「エージェント」という呼び名のためだけに移行しないでください。別のサンプルの行数が少ないというだけで、動いているLangChainの検索フローを置き換える必要もありません。現在の抽象化では、繰り返し求められる具体的な要件を表現しにくい、あるいは保守しにくいときが、移行を検討するタイミングです。

よくある質問

次の開発で、何から着手すべきか

まず、プロトタイプで解決すべき失敗を特定します。正しい出典箇所を見つけることが課題なら、LlamaIndexで小さな検索フローを作ります。ツールや承認済みの処理の連携が課題なら、LangChainから始め、ステップ間で保持しなければならない状態を定義します。最初の動作版は、検索した出典と提案された処理をすべて確認できる程度の範囲に絞ってください。

フレームワークを選ぶ前に、AI業務ワークフロー監査チェックリストを使って、実行する業務、必要な根拠、承認が必要になる範囲を定義してください。