LLMアプリを作ろうとすると、必ず名前が挙がる2つの道具が LangChain と LlamaIndex です。どちらも「生成AIにアプリの仕事をさせる」ためのフレームワークですが、生まれた目的が違うため得意分野がはっきり分かれます。ざっくり言えば、LangChain は「行動するAI（エージェント）を組み立てる」のが得意で、LlamaIndex は「自社データを検索して答えさせる（RAG）」のが得意。この記事は、両者の現在地（2026年）を踏まえて、初めての人でも迷わず選べるように整理します。
FIG.1 LangChain＝「考えて行動する」連鎖／LlamaIndex＝「探して根拠を渡す」検索
01そもそも何のための道具か
両者の違いを理解する一番の近道は、「最初に何を解こうとして作られたか」を知ることです。出自が今でも設計思想に色濃く残っています。
LangChain
LLMに複数の手順や外部ツールをつなげて行動させるための土台。API呼び出し・DB更新・Web検索などを「連鎖（chain）」させるのが原点。
LlamaIndex
大量の社内文書を取り込み・索引化して検索し、その結果を根拠にLLMへ渡すための土台。RAG（検索拡張生成）に最適化されている。
共通点
どちらも「LLMを単体で呼ぶ」より一段上のアプリの骨組みを提供する。最終的に裏で呼ぶのは同じ生成AIモデル。
つまり、「AIに何かをさせたい」のか、「AIに自社の情報で答えさせたい」のか。この問いの答えが、最初の分かれ道になります。
022026年の現在地：両者とも大きく進化した
この分野は変化が速いので、「昔こう聞いた」は当てになりません。2026年時点の実態を押さえておきます。
LangChain は2025年10月に v1.0 を迎え、構成が整理されました。特に LangGraph（状態を持つエージェントを「グラフ＝状態機械」として組む仕組み）が、複雑なエージェントを作る際の主役という位置づけになっています。create_agent という標準の作り方と、処理の各段に割り込める ミドルウェア という考え方が加わり、「ループして考え直す」「人間が途中で承認する」といった挙動を組みやすくなりました。動作の記録・評価には LangSmith が併せて使われます。
LlamaIndex 側は、文書解析エンジン LlamaParse が v2 になり、用途に応じて精度とコストを選べる段階（Fast / Cost Effective / Agentic / Agentic Plus）が用意されました。クラウド基盤（LlamaCloud／LlamaAgents）では、抽出結果にページ単位の出典（引用）を付けられるなど、「どこから取ってきたか」を追える方向に進んでいます。検索まわりの API が安定していて、RAG をすばやく組めるのが引き続き強みです。
どちらも「LLMの薄いラッパー」から、本番運用を支える基盤へと成熟した。
03正面から比較する
初学者がまず押さえるべき軸だけに絞って並べます。細部より「どちらに体重が乗っているか」を見てください。
| LangChain（＋LangGraph） | LlamaIndex |
|---|---|
| 得意：ツール連携・多段の判断・エージェント | 得意：データ取り込み・索引・検索（RAG） |
| 「行動させる」＝API実行・DB更新・自動化 | 「答えさせる」＝Q&A・社内検索・要約 |
| 分岐・ループ・人間の承認を組みやすい | 高度な検索パターンが標準で使える |
| 複雑になりやすく、状態設計の理解が要る | 検索特化ゆえ複雑な自動化は別途必要 |
注意したいのは、これは「優劣」ではなく「重心の違い」だということ。LangChain でも検索はできますし、LlamaIndex でもエージェント的な処理は組めます。あくまでどちらが楽に・素直に書けるかの差です。
04選び方：3つの質問に答えるだけ
迷ったら、次の順で自分のプロジェクトに問いかけてください。上から見ていくと自然に決まります。
主目的は「自社データに答えさせる」ことか？
社内FAQ、製品マニュアル、契約書などを根拠に答えるのが中心なら LlamaIndex 寄り。検索品質がそのまま製品価値になる用途に向く。
主目的は「複数ツールを使って行動させる」ことか？
APIを叩く・予約を取る・データを書き込む・複数手順を判断しながら進める——こうした自動化や多段の意思決定が中心なら LangChain／LangGraph 寄り。
要件はそもそも薄くないか？
「1回プロンプトを投げて答えを得る」程度なら、フレームワーク無しで素のAPIを直接呼ぶ方が単純で壊れにくい。道具は必要になってから足す。
05併用という現実解
実務では「どちらか一方」に固執しないケースも増えています。よくある形は、LlamaIndex を「検索の層」として使い、LangGraph を「行動・判断の層（オーケストレーション）」として上に重ねる構成です。検索の質は LlamaIndex に任せ、その結果を使って何をするかの段取りは LangGraph が回す、という役割分担です。
FIG.2 検索は LlamaIndex、段取りは LangGraph——層で分けて組み合わせる
逆に言えば、小さく始めるなら無理に両方入れる必要はありません。まずは主目的に合う片方で動かし、足りなくなった部分だけもう一方を足す。最初から複雑な構成を組むと、得られる価値より保守の負担が先に来ます。
06共通の注意点
どちらを選んでも、フレームワークを使う以上ついて回る落とし穴があります。先に知っておくと事故を避けられます。
- 抽象化が厚い＝中身が見えにくい：便利な反面、不具合が出たとき「どこで何が起きているか」を追いにくい。動作ログ（LangSmith など）や検索結果の可視化を最初から入れておく。
- API・推奨パターンの移り変わりが速い：本やブログの手順がすぐ古くなる。実装前に必ず公式ドキュメントの最新版で確認する。バージョンを固定しておくと再現性が保てる。
- 料金は変動する：クラウド機能（解析・索引・ホスティング等）の価格やプランは頻繁に変わる。コスト試算は必ず公式の最新情報で行う。
- 過剰な抽象化は負債になる：薄い要件にフルスタックの構成を被せると、理解・保守・デバッグのコストが膨らむ。要件 → 必要な機能 → 最小の道具の順で選ぶ。
07まとめ
「とりあえずフレームワーク」で始めるのではなく、解きたい仕事の重心から逆算するのが正解です。自社データに答えさせたいなら LlamaIndex、ツールを使って行動させたいなら LangChain／LangGraph、要件が薄いなら素のAPI。大きく育ってきたら、検索は LlamaIndex・段取りは LangGraph という併用に進めばよい。どちらも進化が速い領域なので、最後は必ず公式の最新情報で裏を取る——この一手間が、後々の手戻りを大きく減らします。
