LLMオーケストレーションフレームワーク比較：LangChain vs. LlamaIndex vs. 生API呼び出し

LLMアプリケーションがプロトタイプから本番へ移行する際、開発者は重要なアーキテクチャ上の決定を迫られる：LangChain、LlamaIndex、または生のAPI呼び出しのいずれを使用するか。これらの3つの方法は異なる抽象化レベルに対応しており、選択を誤ると、数か月後に本番システムの保守が困難になる可能性がある。

LangChain は、2022年10月に誕生した汎用オーケストレーションフレームワークで、119KのGitHubスターと500以上の統合を誇る。中核となるのは、プロンプトテンプレート、モデル呼び出し、出力パーサー、メモリ、ツール使用など、複数のステップを組み合わせる能力である。最新バージョンのLangGraph（v1.0、2025年10月安定版）は、ステートフルでグラフベースのエージェントワークフローをサポートし、SQLite/PostgreSQL/Redisへの永続化機能により、エージェントが一時停止して数時間後に再開できる。これは複雑なエージェントシナリオで非常に価値が高い。ただし、LangChainはステップあたり約10ms（LangGraphは約14ms）のフレームワークオーバーヘッドを導入し、高スループットのパイプラインでは累積する可能性がある。さらに、スタックトレースが40層に及ぶこともあり、デバッグが困難になる。ある比較では、単純なRAGパイプラインでLangChainのコストがネイティブ実装の2.7倍になったと報告されており、不要なトークン消費が原因である。LangChain v1.0はAPIの安定性を約束しているが、初期バージョン（v0.1〜v0.3）では複数の破壊的移行が発生しており、既存プロジェクトにとって移行コストは現実的な問題である。

LlamaIndex（44Kスター、300以上のデータコネクタ）はデータ層に特化している：取り込み、チャンク分割、埋め込み、インデックス作成、検索。LLMがユーザー自身のデータについて推論できるようにすることが目的であり、ステップのオーケストレーションではない。その設計は検索の精度と効率を高めることに重点を置いており、強力なRAGを必要とするアプリケーションに最適である。LlamaIndexの強みは、豊富なコネクタ（Notion、Google Drive、Slack、PDF、データベースなど）と検索に最適化されたアルゴリズムにあるが、多ステップワークフローやエージェントの柔軟性ではLangChainに劣る。

生API呼び出し とは、OpenAIやAnthropicなどのSDKを直接使用し、追加のオーケストレーション層を挟まない方法である。これは原始的でない戦略であり、フレームワークの複雑さがペイしなくなった場合に本番チームがますます回帰している。最小限の抽象化、完全な制御、フレームワークオーバーヘッドゼロ、明確なデバッグパスを提供する。単純なクエリやパイプラインでは、通常より低コストで高速である。ただし、メモリやツール使用、RAGなどの機能は組み込まれておらず、チームがそれらを自力で構築する必要があり、開発初期の作業負荷が増大する。

選択のフレームワーク として、プロジェクトの要件に基づいて選ぶことを推奨する：多ステップワークフロー、エージェント、ステート永続化が必要ならLangChain/LangGraphを検討する；主な要件がRAGやデータ検索ならLlamaIndexが適切；単純なユースケース、高性能追求、またはコスト最小化なら生API呼び出しが最良の出発点である。多くの本番システムは両方を組み合わせて使用しており、例えばLlamaIndexで検索データを提供し、LangChainで後続のステップをオーケストレーションする。

抽象化レベルの選択にあたっては、長期コストを考慮することが重要である。LLM API支出は2024年末の35億ドルから2025年半ばには84億ドルに倍増しており、フレームワークのオーバーヘッドは予算とシステム信頼性に直接影響を与える。各オプションの実際のトレードオフを理解し、不要な抽象化にコストを支払わないようにすることが、堅牢なLLMアプリケーションを構築する鍵である。