LangChain / LlamaIndex / フレームワークなし：LLMアプリの構成はどう選ぶべきか

大規模言語モデル（LLM）を活用したアプリケーション開発をスタートする際、多くのエンジニアやプロジェクトリーダーが最初に直面するのが「どの開発フレームワークを採用すべきか、あるいはフレームワークを使わずに構築すべきか」というアーキテクチャ上の選択です。

開発初期のプロトタイピングを大幅に加速させるツールとして「LangChain」や「LlamaIndex」といった専門フレームワークが急速に普及した一方で、本番運用を見据えた段階で「フレームワークの過剰な抽象化によってコードのブラックボックス化が進み、デバッグが極めて困難になった」「ライブラリの破壊的変更に追従するメンテナンスコストが膨らんでしまった」という理由から、各モデル事業者の公式SDKを直接利用する構成（いわゆるVanilla構成）へ回帰する開発チームも増えています。

本記事では、LangChain、LlamaIndex、そして公式SDK直接利用という3つの主要なアプローチの特徴を客観的に比較し、プロジェクト規模や開発フェーズに応じた現実的な選定方針を提示します。

1. 3つの主要アプローチの設計思想と得意領域

LLMアプリケーションの構成アプローチは、何を最重要視するかによって設計思想が大きく異なります。

① LangChain：多様なツールを束ねる汎用オーケストレーション

LangChainは、LLMの呼び出し、プロンプトテンプレート、メモリ（対話履歴管理）、ベクトルストア、外部ツールの実行（Tool Calling）などを一元的に連携させる汎用オーケストレーションフレームワークです。

強み: 多数のサードパーティ製品（ベクターDB、クラウドサービス、SaaS等）に対する公式インテグレーションが極めて豊富であり、自律型AIエージェントや複雑なワークフローを迅速に組み立てられる点にあります。
特徴的な設計: 近年では「LCEL（LangChain Expression Language）」と呼ばれる宣言的なパイプライン構文や、マルチエージェントオーケストレーション向けの「LangGraph」などが中核を担っています。

② LlamaIndex：データ接続と検索（RAG）の専門特化

LlamaIndexは、社内文書や各種データソースをLLMに効率的に接続すること（Data-to-LLM）に焦点を絞って開発されたフレームワークです。

強み: PDF、Notion、Slack、Google Driveなどの多様な形式からテキストを読み込むローダー群（LlamaHub）や、ドキュメントの高度なチャンク分割、メタデータ付与、親子インデックス構造の構築といった「RAGパイプラインの前処理と検索アルゴリズム」が非常に充実しています。
特徴的な設計: データのインデックス化とクエリエンジン層の設計に特化しており、純粋な文書検索・質問応答システムの構築において高い生産性を発揮します。

③ フレームワークなし（Vanilla SDK）：公式SDKと標準ライブラリの直接利用

各LLMプロバイダ（OpenAI、Anthropic、Google GenAI等）が公式に提供しているSDKを直接呼び出し、プロンプト管理やデータ処理はPython/TypeScriptの標準構文やPydanticなどの汎用ライブラリを用いて自前で実装するアプローチです。

強み: 余分な抽象化レイヤーが存在しないため、コードの見通しが極めて良く、各モデルベンダーの最新API仕様（最新のStructured Outputs機能やプロンプトキャッシュ等）をリリース当日から即座に活用できます。
特徴的な設計: リトライ処理、履歴の保存、エラーハンドリングなどを明示的に書く必要がありますが、予期せぬ内部挙動に悩まされるリスクが極小化されます。

2. フレームワーク導入が孕む「過剰な抽象化」のトレードオフ

フレームワークの導入は開発生産性を向上させる一方で、長期的な保守フェーズにおいてはいくつかの潜在的な課題をもたらす傾向が指摘されています。

【アーキテクチャの比較イメージ】

[Vanilla SDK構成]
アプリケーションコード ──(直接呼び出し)──> [公式SDK] ────> [LLM API]
※処理の流れが完全に可視化され、ブレークポイントでの追跡が容易

[フレームワーク導入構成]
アプリケーションコード ──> [LCEL / Chain] ──> [抽象化Wrapper] ──> [公式SDK] ──> [LLM API]
※内部でプロンプトやパラメータが動的変換されるため、デバッグ時に階層を潜る必要がある

① デバッグと性能最適化の難易度上昇

フレームワークが多重のクラスで内部処理を隠蔽している場合、「モデルに実際に渡された完全なプロンプト文字列」「正確な消費トークン数」「どこでレイテンシが発生しているか」を追跡するために、ライブラリ内部の深いコールスタックを読み解く必要があります。ミリ秒単位のレスポンス改善や微妙なハルシネーションの調査において、このブラックボックス性が障壁となる場合があります。

② 依存関係の肥大化と破壊的変更（Breaking Changes）のリスク

生成AI技術は変化が激しいため、フレームワーク側も頻繁にアーキテクチャの刷新（例: 古いチェーン構文の非推奨化と新記法への移行など）を行います。これにより、フレームワーク自体のバージョン更新に伴うリファクタリング工数が継続的に発生するリスクを内包しています。

3. 3大アプローチの総合比較

各手法の特性を以下のマトリクスに整理します。

評価項目	LangChain	LlamaIndex	フレームワークなし（Vanilla SDK）
初期プロトタイプ開発速度	高	高（RAG特化）	中
コードの透明性・可読性	低〜中	中	極めて高い
デバッグ・トラブルシュート	難（多層抽象化）	普〜難	容易（標準的な例外処理）
最新API機能への追従速度	追従にタイムラグあり	追従にタイムラグあり	即時利用可能
外部コネクタ・統合の豊富さ	非常に豊富	豊富（データ系）	自前実装が必要
長期的な保守性・依存リスク	バージョン追従負荷あり	バージョン追従負荷あり	最小限の依存関係で安定

4. プロジェクト規模とフェーズに応じた選定指針

以上の得失を踏まえると、技術選定においては「現在のプロジェクトがどのフェーズにあり、何を重視すべきか」を基準に判断することが合理的です。

パターンA：PoC・ハッカソン・要件探索フェーズ

【LangChain または LlamaIndexの積極採用】 アイデアの実現可能性を数日〜数週間で素早く検証したい段階では、コネクタやチェーンが整備されたフレームワークの利用価値が極めて高くなります。ゼロからデータローダーやリランカーを自作する時間を省き、コアアイデアの検証にリソースを集中できます。

パターンB：複雑な文書検索が主体のナレッジベース構築

【LlamaIndexの活用】 大量の非構造化ドキュメントを階層的に管理し、高度な検索戦略（クエリ変換、ルーターエンジン等）を組み込むことがシステムの成否を分けるユースケースでは、LlamaIndexが提供する洗練されたデータ構造が強力な武器となります。

パターンC：大規模エンタープライズ運用・基幹サービスへの組み込み

【Vanilla SDK または薄い自社内ラッパーの構築】 数千人以上のユーザーが常時アクセスする本番サービスや、SLA（サービス品質保証）が厳格な業務システムにおいては、Vanilla構成、または必要な最小限の機能だけをラップした自社製軽量モジュールの採用が好まれる傾向にあります。外部ライブラリへの依存を最小化することで、予期せぬ挙動を防ぎ、長期的な保守性を確保しやすくなります。

まとめ：抽象化のコストと恩恵を冷静に見極める

「有名なフレームワークだから導入する」「フレームワークを使わないと開発が遅くなる」といった固定観念にとらわれることなく、それぞれの構成がもたらす「開発生産性」と「長期的な保守性・制御性」のトレードオフを客観的に評価することが重要です。

初期のプロトタイプはフレームワークを活用して最速で立ち上げ、製品化や本番スケールの段階でボトルネックとなった部分を段階的にネイティブな実装へと切り出していくという、柔軟なアーキテクチャ戦略が実務において成功を収めやすいアプローチと言えるでしょう。