LLMアプリ開発のフレームワーク選定は、しばしば「LangChainかLlamaIndexか」という二択の議論に収束します。結論を先に言うと、エージェント中心ならLangChain、RAG中心ならLlamaIndex、現実には両方を併用するのが現代的な解答です。本記事では、両フレームワークの設計思想と使い分けを、コード例と比較表で整理します。2026年時点では「フレームワークを使うかどうか」よりも「どのレイヤーでどちらを使うか」が論点となっています。
LLMアプリ開発フレームワークの必要性
LLMアプリは一見シンプルです。APIを叩いて、文字列を返すだけ。しかし本番化を進めると、プロンプト管理、メモリ管理、ツール呼び出し、ベクトル検索、キャッシュ、リトライ、ロギング、評価といった横断的な課題が一気に積み上がります。これらを毎回ゼロから書くのは生産的ではありません。
フレームワークの価値は「接続・組み合わせの定型化」にあります。ベクトルDB、LLMベンダー、埋め込みモデル、プロンプトテンプレート、エージェントのツールといった部品を標準化されたインターフェイスで接続できるため、ベンダー乗り換えや構成変更のコストが大幅に下がります。逆に、小規模・単機能のアプリではフレームワークのオーバーヘッドがむしろ開発を遅らせることもあるため、選定判断は規模と複雑度の両面から行う必要があります。
LangChainの特徴と強み
LangChainは2022年末にリリースされた、LLMアプリ開発のデファクト的フレームワークです。最大の特徴は守備範囲の広さで、プロンプトテンプレート、チェーン、エージェント、メモリ、ツール、ベクトル検索までほぼすべてをカバーしています。LangGraphというエージェント向けのサブプロジェクトも成熟してきており、複雑なワークフローを状態機械として記述できます。
一方で、歴史的にAPIの破壊的変更が多く、「昨年書いたコードが動かない」問題がコミュニティで繰り返し話題になりました。2024年以降はLCEL(LangChain Expression Language)とLangGraphを中心に整理されつつあります。
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.chains import RetrievalQA
docs = TextLoader("docs.txt").load()
splits = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50).split_documents(docs)
vectorstore = Chroma.from_documents(splits, OpenAIEmbeddings())
qa = RetrievalQA.from_chain_type(
llm=ChatOpenAI(model="gpt-4o-mini"),
chain_type="stuff",
retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
return_source_documents=True,
)
result = qa.invoke({"query": "この文書の要点を教えてください"})
print(result["result"])LlamaIndexの特徴と強み
LlamaIndexは、当初「GPT Index」という名前でリリースされた、RAGに特化したフレームワークです。LangChainがあらゆる方向に枝を伸ばしているのに対し、LlamaIndexはデータ取り込み・インデクシング・検索・再ランキングといったデータ中心の領域を深掘りしています。
特筆すべきはデータコネクタの豊富さです。LlamaHub経由で数百種類のデータソース(Notion、Slack、Salesforce、各種DB)を取り込めます。また、Query Engineと呼ばれる高度な検索機構があり、サブクエリへの分解やルーティング、ツリー要約といった複雑なRAGパイプラインを宣言的に書けます。近年はAgent機能も強化されていますが、エージェント領域ではLangChainに追いついているという印象です。
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.openai import OpenAI
from llama_index.embeddings.openai import OpenAIEmbedding
Settings.llm = OpenAI(model="gpt-4o-mini")
Settings.embed_model = OpenAIEmbedding(model="text-embedding-3-small")
documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine(
similarity_top_k=4,
response_mode="tree_summarize",
)
response = query_engine.query("この文書の要点を教えてください")
print(response)
for node in response.source_nodes:
print(node.node.metadata.get("file_name"), node.score)詳細比較
両フレームワークを7つの評価軸で比較します。なお本比較は2026年初頭時点のものであり、両者とも開発が活発なためバージョンによって評価が変わる点にご注意ください。
| 比較軸 | LangChain | LlamaIndex |
|---|---|---|
| RAG機能 | 標準的(基本〜中級) | 非常に強力(高度なクエリ分解・再ランキング) |
| エージェント機能 | 強力(LangGraph、ツール統合が豊富) | 中程度(追従中) |
| データコネクタ | 多数(Community経由) | 非常に多数(LlamaHubが強力) |
| 学習曲線 | やや急(概念が多い) | 比較的緩やか(RAGに集中) |
| コミュニティ規模 | 最大級 | 大規模 |
| エコシステム連携 | LangSmith、LangGraphで強力 | LlamaCloud、LlamaParseで強化中 |
| TypeScript対応 | 公式サポート(機能は一部制限) | 公式サポート(Python版より機能少) |
| ユースケース | 推奨 | 理由 |
|---|---|---|
| 社内ドキュメントQ&A(RAG中心) | LlamaIndex | データ取り込みとクエリ機能が豊富 |
| マルチステップのタスク自動化エージェント | LangChain(LangGraph) | 状態管理とツール連携が強力 |
| カスタマーサポートチャットボット | LangChain | メモリ・チェーン・ツールの統合が容易 |
| 大量文書からの情報抽出バッチ | LlamaIndex | バッチ処理とインデックス管理が得意 |
| 複雑なワークフロー自動化 | LangChain(LangGraph) | 状態機械としての表現力 |
| 学術論文検索・要約 | LlamaIndex | ツリー要約とサブクエリ分解 |
併用パターンと代替選択肢
実務では「どちらか一方」ではなく、両者を併用する設計が増えています。典型パターンはLlamaIndexで構築したRAGパイプラインをLangGraphのエージェントからツールとして呼び出す構成です。これにより、データ層はLlamaIndexの強力なクエリ機能を活用し、オーケストレーション層はLangGraphの状態管理を活用するという、いいとこ取りが可能になります。
また、代替選択肢として次のようなフレームワークも台頭しています。
- Vercel AI SDK――TypeScript/Next.jsでのストリーミングUIに特化。フロントエンド統合なら第一選択肢
- Semantic Kernel――Microsoft製。C#/Python対応でエンタープライズ向け
- Haystack――deepset製の成熟したパイプラインフレームワーク。プロダクション志向
- DSPy――プロンプトではなく「コンパイル可能な宣言的仕様」からLLMプログラムを生成する新しいアプローチ
まとめ
LangChainとLlamaIndexは競合ではなく補完関係にあります。エージェントとオーケストレーションはLangChain、データ層の高度なRAGはLlamaIndex、フロントエンド連携はVercel AI SDK、というように役割分担する設計が現代的です。関連記事としてRAGとは、AIエージェントフレームワーク比較、LLMオブザーバビリティ、RAGアーキテクチャもあわせてご参照ください。
よくある質問(FAQ)
Q1. LangChainとLlamaIndexの違いは?
A. LangChainは汎用的なLLMアプリ開発フレームワークでエージェント機能が充実しており、LlamaIndexはRAG/データ検索に特化したフレームワークです。RAG中心ならLlamaIndex、エージェントも含む総合的な開発ならLangChainが適しています。両者は設計思想が異なるため、競合というよりは補完関係にあります。
Q2. 両方使うことは可能ですか?
A. はい、併用可能です。LlamaIndexでRAGパイプラインを構築し、LangChainのエージェントからLlamaIndexの検索をツールとして呼び出すパターンが実用的です。データ層とオーケストレーション層を分離することで、各フレームワークの強みを活かせます。
Q3. フレームワークなしで開発すべきですか?
A. 小規模でシンプルなアプリならフレームワークなしの直接API呼び出しでも十分です。RAG、エージェント、複数モデル統合など複雑な構成になる場合はフレームワークの利用が開発効率の面で有利です。迷った場合はまず薄い自前ラッパーから始め、必要が出たらフレームワーク導入を検討する段階的アプローチをおすすめします。