7月10日、Shittu Olumideが「LLM Orchestration Frameworks Compared: LangChain vs. LlamaIndex vs. Raw API Calls」と題した記事を公開した。この記事では、LangChain・LlamaIndex・生APIの3つのアプローチをスタック層ごとに整理し、プロジェクトの要件に応じた選定基準を示している。

LLMアプリケーション開発では、プロトタイプが動いた後の「次の一手」でフレームワーク選定が問題になる。メモリ、RAG（検索拡張生成）、ツール呼び出し——これらが加わった瞬間、client.chat.completions.create() 一行では足りなくなる。

最も高価な間違いは、プロトタイプ段階でフレームワークを固定してしまい、本番で外せなくなることだと記事は冒頭から指摘する。選択を誤ってもプロトタイプは壊れない。壊れるのは6ヶ月後の本番システムだ——スタックトレースが40フレームの深さになり、トークンコストが本来の2.7倍に膨らみ、破壊的API変更の移行に1スプリントを費やすことになる。

背景として、元記事によればLLM APIへの支出は2024年末から2025年半ばにかけて35億ドルから84億ドルへと倍増している。フレームワーク層のコード——アプリとモデルの間に挟まる部分——が、その支出のどれだけが実際の処理に使われるかを直接決める。

3つの選択肢が解決する問題は別々だ

まず、この比較の前提として理解しておくべき重要な点がある。3つの選択肢は同じ次元で競合していない。

• LangChain（2022年10月〜）：LLM操作を連鎖させる汎用オーケストレーションフレームワーク。GitHubスター11.9万、500以上のインテグレーションを持つ最大のLLMフレームワーク
• LlamaIndex（2022年11月〜、当初はGPT Indexとして公開）：自前のデータに対してLLMを推論させることに特化。データ取り込み・チャンキング・埋め込み・インデックス・検索の設計が中心。GitHubスター4.4万、LlamaHubで300以上のデータコネクタを提供
• 生APIコール：OpenAIやAnthropicのSDKを直接使用。オーケストレーション層なし、プロバイダーが提供する範囲のみ

LangChainは「ステップ間で何が起きるか」のオーケストレーション、LlamaIndexは「検索ステップそのもの」の精度と効率、生APIコールは「どれだけの抽象化が必要か」というスタンスだ。多くの本番システムはこのうち2つを組み合わせて使う。

LangChain：複雑な組み合わせを組み立てる層

LangChainの強みは、複数ステップ・複数ツール・条件分岐・ターン間メモリ・エージェントといった複雑さを組み立てることにある。

同チームが開発した**LangGraph**は、エージェントワークフローを有向グラフとしてモデル化する。ノードがPython関数、エッジが状態遷移、型付きのstateオブジェクトが全実行を流れる構造だ。SQLite・PostgreSQL・Redisへのチェックポインタによる組み込み永続化も備えており、エージェントがワークフローの途中で一時停止し、状態を保存して数時間後に再開できる。これは自前で実装するには相当な手間がかかる機能だ。なお、元記事ではLangGraph v1.0の安定版公開時期について言及があるが、記事公開日（2026年7月）時点の記述に依拠しているため、正確な公開日はLangChainの公式ブログで確認されたい。

正直なコスト面も挙げておく：

• フレームワークオーバーヘッド：LangChainは1ステップあたり約10ms、LangGraphは約14msを追加する。LLM呼び出しが1〜3秒かかる人間向けアプリでは無視できる範囲だが、毎分数千リクエストを処理する高スループットパイプラインでは積み重なる
• デバッグの複雑さ：LangChainの本番エラーのスタックトレースは15〜40フレームのフレームワーク内部コードを含む
• トークンコスト：元記事が引用する比較では、基本的なRAGパイプラインでLangChainが生実装の2.7倍のコストを生じさせた

LangChain公式ドキュメントによれば、v1.0ではAPI安定性が確約されている。v0.1〜v0.3の間は破壊的変更が相次ぎ、複数回の強制移行が発生した歴史がある。新規プロジェクトでは安定性の懸念はほぼ解消されているが、v0.x系を本番で動かしているチームにはv1.0への移行コストが存在する。

以下はLangChainのLCEL（LangChain Expression Language）チェーンの実装例だ：

# langchain_chain.py
import os
from dotenv import load_dotenv
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI

load_dotenv()

llm = ChatOpenAI(
    model="gpt-4o",
    temperature=0.2,
    api_key=os.getenv("OPENAI_API_KEY")
)

prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a concise technical explainer. Keep answers under 100 words."),
    ("human", "Explain {topic} in simple terms.")
])

parser = StrOutputParser()

# パイプ演算子(|)で prompt → llm → parser を直列に接続
chain = prompt | llm | parser

if __name__ == "__main__":
    result = chain.invoke({"topic": "vector embeddings"})
    print(result)

    print("\n--- Streaming response ---")
    for chunk in chain.stream({"topic": "RAG pipelines"}):
        print(chunk, end="", flush=True)
    print()

| 演算子で3つのオブジェクトを接続するだけで、.invoke()・.stream()・.batch()・.ainvoke() がチェーン定義の変更なしに使える。このインターフェースの統一性が、複数の実行パターンを必要とするプロジェクトでLangChainを選ぶ最も明確な理由になる。

LlamaIndex：検索精度に集中する層

LlamaIndexが本領を発揮するのは、企業内文書・データベース・外部ソースに対してLLMを推論させる用途だ。PDFのロード・チャンク分割・埋め込み生成・ベクトルインデックスへの保存・意味的検索という一連のRAGパイプラインを、最小限のコードで実装できる。

LlamaIndexが提供する高度な検索機能——クエリルーティング、マルチステップ検索、ハイブリッド検索——は、LangChainのLCELで同等のものを組み立てるより少ないコードで実現できる。LlamaIndex公式ドキュメントでは、これらの検索戦略の実装例が詳しく解説されている。

ただし、元記事ではLlamaIndexのコード例は掲載されていない。実装の具体的なイメージをつかみたい場合は、LlamaIndexの公式クイックスタートを参照するとよい。

エージェント機能やLLMチェーンのオーケストレーションはLangChainの方が充実している。「検索の精度を上げたい」ならLlamaIndex、「複数ツールを組み合わせたエージェントを作りたい」ならLangChainというのが現実的な使い分けだ。また、300以上のデータコネクタを集めたLlamaHubを活用することで、外部データソースとの接続をほぼコードなしで追加できる点もLlamaIndexの実用上の強みだ。

生APIコール：抽象化を最小にする選択

生APIコールは「原始的なフォールバック」ではない。フレームワークの複雑さがコストに見合わなくなった本番チームが移行先として選ぶアプローチとして位置づけられている。

デバッグが簡潔で、トークン消費が予測しやすく、APIの変更が直接見える。フレームワークのオーバーヘッドがないため、シンプルなユースケースでは最も安く、最も速い。代償は、メモリ管理・ツール呼び出し・エラーハンドリングを自前で組む必要があることだ。OpenAI APIリファレンスやAnthropic APIドキュメントは、この選択肢を選んだ際の実装の出発点になる。

どれを選ぶか：実践的な判断基準

記事が提示するフレームワーク選定の基準を整理すると：

プロトタイプ段階でフレームワークを固定してしまい、本番で外せなくなること——記事が最も強調するのはこのリスクだ。3つの選択肢はそれぞれ解決する問題が異なる。スタックが固まる前に「自分のシステムが本当に何を必要としているか」を問い直すことが、後の移行コストを避ける最短経路になる。

詳細はLLM Orchestration Frameworks Compared: LangChain vs. LlamaIndex vs. Raw API Callsを参照していただきたい。