10月19日、KDnuggetsにてVinod Chuganiが「LangChain vs. LlamaIndex vs. Building From Scratch: Here's What I Suggest」と題した記事を公開した。LLMアプリケーション開発における3つのアプローチ——LangChain、LlamaIndex、スクラッチ構築——それぞれのトレードオフと選択指針について、著者自身の意見を交えながら詳しく論じている。

LLMアプリ開発を始める際、「とりあえずLangChainを使う」という選択は珍しくない。GitHubスター数が多く、コミュニティも活発で、チュートリアルも豊富だからだ。しかしVinodは冒頭でこう釘を刺す。「どちらも、すべてのチーム・プロジェクト・開発フェーズに対して正解ではない」。スター数に引っ張られた選択ではなく、意図的な選択をするための判断軸を提供するのがこの記事の目的だ。

そもそも何を解決するツールか

LLM単体は、プロンプトを受け取って補完を返すだけのステートレスなテキスト予測器だ。その上に実用的なアプリケーション——文書QAシステム、マルチステップエージェント、RAG（検索拡張生成）パイプライン——を構築するには、コンテキスト管理、ツール間のルーティング、情報の検索・結合といったオーケストレーション層が必要になる。LangChainとLlamaIndexはそのオーケストレーション層を提供するフレームワークであり、スクラッチ構築とはそのオーケストレーション層を自前で実装することを指す。

LangChain：広く、柔軟で、ときに複雑すぎる

LangChainの強みは幅の広さだ。チェーン、エージェント、メモリ、ツール、リトリーバー、出力パーサー、プロンプトテンプレートに加え、ベクトルデータベースや外部APIとの統合も豊富に揃っている。

LLMをさまざまな外部ツールやデータソースと接続する必要があるチームには有用だ。また、LLMがツールを選択したり中間結果に基づいて行動を連鎖させるようなマルチステップのエージェント的ワークフローにも対応している。

一方で、その広さが裏目に出る場面もある。抽象化の層が深く、何かが壊れたとき、複数のラッパークラスをたどってエラーを追跡するのは容易ではない。「LangChainの抽象化は開発初期を加速させるが、デバッグとカスタマイズの段階で足枷になる」という報告は多い。また、フレームワークの進化が速いため、ドキュメントが現行APIに追いついていなかったり、古いチュートリアルが廃止済みのパターンを参照していたりするケースもある。なお、LangChainはLangChain Expression Language（LCEL）の導入など内部設計を継続的に刷新しており、2025〜2026年時点でもAPIの変化が速い状況は続いている。過去のサンプルコードをそのまま流用する際は、バージョンの確認が不可欠だ。

LangChainが向いている場面： 素早いプロトタイピング、LLMアプリの可能性を探る段階、幅広いインテグレーションが重要なプロジェクト。

LlamaIndex：RAGに特化した、より一貫性のある選択肢

LlamaIndex（旧称: GPT Index）はもともとRAGシステム構築に絞った設計で始まった。データコネクタ、インデックス戦略、クエリエンジンがこのユースケースのために設計されており、抽象化の一貫性がLangChainより高い。

再ランキング、ハイブリッド検索、階層的検索、クエリルーティングといった高度なRAGパターンへの対応も充実している。さらに、LlamaIndexが力を入れているのが評価ツールだ。検索システムが実際に有用なコンテキストを返しているかどうかを、ユーザーに影響が出る前に検証できる仕組みは、LLMアプリ開発において見落とされがちだが重要な機能だ。

ただし、文書検索を中心としないアプリケーション——リッチなエージェント動作や複雑なツール利用——には向かない。フレームワークの前提から外れようとすると、むしろ抵抗が大きくなる。

LlamaIndexが向いている場面： プロダクション品質の文書QAシステム、ナレッジベースアシスタント、エンタープライズ検索。

スクラッチ構築：聞こえるより現実的

「スクラッチで構築する」とはLLM自体を書くことではない。モデルプロバイダーのAPIを直接呼び出し、自分のアプリケーションに必要な抽象化だけを実装するということだ。

OpenAI、Anthropic、Googleのベース APIは成熟してきており、Pinecone、Weaviate、Qdrantといったベクトルデータベースも独自のSDKを持っている。インフラは揃っている——あとはフレームワークを通さずに自分で組み立てるかどうかの選択だ。

最大のメリットは完全な可視性だ。フレームワークによる隠れたプロンプト注入も、予期しないリトライロジックも、リクエストを横断する抽象化層もない。何か予期しない動作があっても、どこを見ればいいか明確だ。また、スクラッチ実装は「アプリケーションが実際に何を必要とするか」を強制的に明確にさせる効果もある。フレームワークは複雑なパターンを安易に使えるようにすることで、過剰設計を促すことがある。

デメリットは初期コストだ。記述するコードが増え、フレームワークが自動処理する部分も明示的に実装する必要がある。また、良質なRAGパイプラインをスクラッチで構築するには、埋め込みモデル、ベクトル類似度、チャンク戦略、コンテキストウィンドウ管理についての理解が前提となる。

どう選ぶか：3つの変数で決まる

Vinodは意思決定を「プロジェクトのフェーズ」「チームの技術力」「アプリケーションの種類」の3変数に整理している。選択の前提として、この3軸のどこに自分のプロジェクトが位置するかを確認することが出発点となる。

• 初期探索フェーズなら、フレームワークを使う。LangChainは要件がまだ不明確な場合、LlamaIndexは検索が明らかに中心の場合に向いている。
• 検索ヘビーなプロダクションシステムを作るなら、LlamaIndexが有力候補だ。評価ツールも含め、プロダクション移行での実用性が高い。
• 要件が明確で、エンジニアリング基盤が強いチームなら、スクラッチ構築が長期的に有利になりやすい。デバッグ容易性、パフォーマンス最適化、柔軟性のリターンが積み上がる。
• スタックの深い層でカスタマイズが必要になるとわかっているなら、最初からスクラッチ前提で設計した方が効率的だ。「結局フレームワークの抽象化を剥がす羽目になった」というチームは多い。

また、これらは排他的な選択ではない。「LangChainでプロトタイプ→要件を把握→コアロジックをスクラッチで再構築→周辺コンポーネントはフレームワーク統合を活用」という段階的な移行パターンは、現実的かつ合理的な選択肢として紹介されている。

詳細はLangChain vs. LlamaIndex vs. Building From Scratch: Here's What I Suggestを参照していただきたい。