LangChainの代替：選択肢の比較

私たちの立場：私たちはGeonodeであり、プロキシを売っています。LLMフレームワークとは無関係です。どれを選んでも私たちは何も得ません。結果に利害のない人間が書いた比較であり、ほとんどの比較がベンダーの一方から来るこのカテゴリでは珍しい立場です。以下のバージョン、ライセンス、リポジトリの活動はすべて2026年9月に確認しました。

なぜ代替を探すのか

実際の不満を名前で挙げる価値があります。どれが助けになるかがそれで決まるからです。

抽象化の深さ。 チェーンのデバッグは、実際に送られたプロンプトを知るためにフレームワークのソースを読むことをしばしば意味します。デモを短くする間接化は、本番のインシデントを長くします。

APIの変動。 フレームワークは寿命の間に大きく動き、チュートリアルはすぐに古くなります。あるメジャーバージョン向けに書いたコードは見直しが必要です。

依存関係の重さ。 大きな表面積は大きな依存ツリーをもたらし、制約のあるデプロイとセキュリティレビューでは重要です。

やりすぎ。 Chains、agents、memory、retrieval、tooling、evaluation。ほとんどのプロジェクトはうち二つを必要とし、全部を継承します。

これらの不満はアイデアそのものではありません。LangChainの抽象化は問題空間の妥当な記述であり、コピーされた理由はまさにそこです。不満は、一部を使うためにフレームワーク全体を採用するコストについてです。

プロジェクトが止まっていないことも述べておく価値があります。langchainは1.3.18、langchain-coreは1.6.1で、どちらも2026年8月末にリリースされ、MITライセンス、リポジトリはこのカテゴリで最も活発な部類です。多くの批判は古いバージョンを述べています。

全体像

数値はすべてPyPIと各プロジェクト自身のリポジトリから、2026年9月に確認しました。

すべて活発に開発されています。確認の数日前以内にすべてプッシュされていました。すべて寛容なライセンスです。違いは存続可能性ではなく、範囲と哲学にあります。

LlamaIndex：検索が先

最も近い汎用の代替であり、別の方向から来ます。

LangChainがLLM呼び出しの合成から始めたのに対し、LlamaIndexはLLMをデータにつなぐところから始めました。自身の要約は "interface between LLMs and your data" です。その出自は得意なことに表れます。非常に幅広いソースからのドキュメント読み込み、チャンキング戦略、インデックス構築、単純なtop-k類似を超える検索パターンです。

選ぶべきときは、検索品質が問題の難しい部分である場合です。インデックス抽象とquery enginesは汎用フレームワークの同等物より洗練されており、loaderのエコシステムは十分広く、珍しいソースへの接続はたいてい一行です。

留保はLangChainと同じ形です。汎用フレームワークに成長したため、検索のために採用すると、望まないかもしれないagents、ワークフロー、toolingがついてきます。

Haystack：本番パイプライン

Deepsetのフレームワークであり、このグループで最も明示的に本番志向です。自らを "to build customizable, production-ready LLM applications" のフレームワークと述べています。

区別点は、パイプラインが宣言された入出力を持つコンポーネントの明示的なグラフであり、YAMLにシリアライズできることです。method-chainingでは得られない形で実行内容を検査でき、パイプラインをバージョン管理し、diffし、レビューできるものにします。

選ぶべきときは、デモではなく運用されるものを作っている場合です。パイプライン構造を見ること、シリアライズすること、レビューで推論することが、動くプロトタイプへの最短経路より重要なときです。

このリストでMITではなくApache-2.0の唯一のプロジェクトでもあります。実務上の差は大きくありません。どちらも寛容です。ただし好みのある法務レビューでは時に問題になります。

DSPy：本当に異なる発想

最も興味深い代替であり、他の変種ではありません。

DSPyの前提は、手書きプロンプトが誤った抽象だということです。モジュールが何をすべきかを入出力で宣言し、フレームワークがあなたが定義した指標に対してプロンプトを最適化します。few-shotの例も含みます。

結果は別の開発ループです。プロンプトの文言を手で反復する代わりに、評価セットを作り、指標を定義し、最適化器に探索させます。プロンプトエンジニアリングを工芸から、訓練手順に近いものへ変えます。

選ぶべきときは、測定可能な品質のタスク、評価セット、系統的最適化が報われる十分な量がある場合です。分類、抽出、構造化推論が当てはまります。

選ぶべきでないときは、指標を定義できない場合、またはタスクが一度きりの場合です。アプローチ全体は出力を自動採点できることに依拠し、その評価セットを作ることが本当の仕事です。

37,000 starsと活発な開発で実験段階はとっくに過ぎていますが、ここにある他のどの選択肢より、事前に多くを求めます。

Pydantic AIとInstructor：意図的に狭い

意図的に少なく解決する二つのプロジェクトです。

Instructor は一つのことだけをします。構造化出力です。Pydanticモデルを定義すると、スキーマ、検証、無効時のリトライループを扱います。それがライブラリ全体です。

LLMアプリケーションコードの膨大な割合は「この形に合う有効なJSONをモデルから得る」ことであり、Instructorは数行で、実質フレームワークのオーバーヘッドなしに完全な答えになります。それが要件なら、得るために汎用フレームワークを採用するのは悪い交換です。

Pydantic AI はより広い——"the Pydantic way" のagentフレームワーク——で、型安全性、依存性注入、構造化出力をagent構築に持ち込みます。他より若く急速に成長し、すでにPydanticと型チェックに投資しているチームに特に訴えます。

これらを選ぶべきときは、問題がよく定義されており、フレームワークよりライブラリが欲しい場合です。区別は重要です。ライブラリはあなたが呼ぶもの、フレームワークはあなたを呼ぶものであり、後者は離れるのがはるかに難しいです。

Semantic Kernel：エンタープライズと多言語

Microsoftのフレームワークであり、Pythonが全体ではないときに検討すべきものです。

区別点は、.NET、Python、Javaにわたる第一級のサポートと、プラグインとプランナーを中心に構築され、エンタープライズ統合パターンに写像されるアーキテクチャです。

選ぶべきときは、.NETショップにいる場合、複数言語で同じ概念が必要な場合、組織のプラットフォーム判断がそちらを指している場合です。これらは本物の制約であり、技術的な優劣にかかわらずしばしば決定的です。

そうした制約のないPythonのみのプロジェクトでは、Pythonネイティブの選択肢の方がエコシステムで勢いがあるのが一般的です。

LangGraph：LangChain内部の代替

切り分けて述べる価値があります。代替が欲しいと言うとき、人々が実際に欲しいのはしばしばこれだからです。

LangGraph——同じチーム、MITライセンス、1.2.11——は "building stateful, multi-actor applications with LLMs" 向けだと述べています。チェーン抽象ではなく、明示的な状態を持つグラフ実行モデルです。

区別が重要なのは、LangChainへの苦情の多くが隠れた制御フローに関するからです。LangGraphは制御フローをあなたが書くものにします。ノード、辺、条件付き遷移、あなたが定義する状態オブジェクトです。午前三時に何かがうまくいかないとき、はるかに読みやすいです。

選ぶべきときは、アプリケーションに本物の状態、分岐、サイクルがある場合です。ループするagent、承認ステップのあるワークフロー、「次に何が起きるか」が「前に何が起きたか」に依存するものです。残りのLangChainを採用せずに使えます。

フレームワークなし：賛成の理由

比較記事のほとんどが省く選択肢であり、相当な割合のアプリケーションにとって正しい答えです。

モデル提供者のSDKは今では良いです。直接呼ぶのは数行で、完全に透明です。

response = client.messages.create(
    model=MODEL,
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)

手放すもの： 提供者抽象、既製の統合、出来合いの検索コンポーネント、agentループ。

得るもの： 自分のコードが読めます。送られるプロンプトはファイル内のプロンプトです。デバッグはフレームワーク層を辿ることではなく、リクエストとレスポンスを読むことです。依存ツリーは一つのSDKです。アップグレードはフレームワークの移行ガイドではなく、提供者のリリースノートです。

妥当な中間位置： 特定の問題には狭いライブラリを使う——構造化出力にInstructor、検索にベクトルデータベースのclient、ツール呼び出しにHTTP client——オーケストレーションは自分で書く。オーケストレーションはたいてい五十行で、自分が書いた五十行は、書いていないフレームワークより保守しやすいです。

フレームワークが本当に場所を得るとき： 多くの提供者統合が必要なとき、複雑なツール使用のagentsを構築してループを処理してほしいとき、チームが共有の慣習から恩恵を受けるとき、プロトタイプ速度が本番の可読性より重要なときです。これらは本物の理由であり、本物のプロジェクトに当てはまります。

避けるべき失敗モードは、デモのためにフレームワークを採用し、本番で何をしているか見えないことに気づくことです。

フレームワークからの移行

すでにLangChainアプリケーションがあり、移動を検討しているなら、作業は見た目より予測可能です。順序が重要です。

まず実際に送っているものを知る。 何かを変える前に、本物のプロンプトとパラメータを捕捉します。ほとんどのフレームワークはこれ用のcallbackやdebugフラグを公開しており、それを立てると演習全体で最も有用な成果物が出ます。メソッド呼び出しではなくHTTPリクエストとして表された、アプリケーションが何をしているかの記録です。半分の場合、これだけでフレームワークが意図しないことをしていると分かります。

一度に一つのコンポーネントを動かし、アプリケーション全体は動かさない。 部品は分離できます。検索ステップをベクトルデータベースclientの直接呼び出しに置き、残りはそのまま。出力品質が変わっていないことを確認してから次を動かします。一括の書き換えは「新しいコードが間違っている」と「新しいコードが違う」を混同し、どちらなのか言えなくなります。

出力比較のハーネスを保つ。 同じ入力で両方の実装を走らせ、結果をdiffします。検索と生成は十分に非決定的で、「良さそう」は証拠になりません。百組の対になった出力は、抜き打ち確認では見えない回帰を示します。

プロンプトテンプレートが難しい部分だと覚悟する。 フレームワークのプロンプトテンプレートは、あなたが書いておらず、読んでいないかもしれない定型をしばしば含みます。書式指示、output parsers、few-shotの足場です。振る舞いを再現することはそれらを再現することであり、だから実際に送られたプロンプトの捕捉が先です。

そして、やる価値があるか正直になる。 少し不透明だと感じる動いているアプリケーションは、理解できて新しいバグがある書き換えより明らかに劣るわけではありません。移行の根拠は、フレームワークが積極的にコストになっているとき——デバッグ時間、アップグレードの変動、依存の衝突——に強く、動機が美的なときに弱いです。好みで正当化された書き換えの記録は悪いです。

ほとんどのチームにとって現実的な中間は、既存の表面を取り除くのではなく、新しいフレームワーク表面を足すのをやめることです。新しいコンポーネントは直接書き、古いものはどうせ変える必要が出るまで放っておく。

選び方

ほとんどの場合を解決する短い手順です。

本当に必要なものを書き出す。 構造化出力か。検索か。ツール付きの多段階agentsか。提供者の切り替えか。ほとんどのプロジェクトはうち一つまたは二つを必要とします。一つのために汎用フレームワークを採用するのが後悔の出所です。

まずフレームワークなしで試す。 SDKに直接半日書くと、問題の本当に難しい部分が分かり、その答えはたいてい汎用フレームワークではなく特定のライブラリを指します。

難しい部分に道具を合わせる。 検索品質はLlamaIndexを指します。評価セット付きの測定可能なタスク品質はDSPyを指します。構造化抽出はInstructorまたはPydantic AIを指します。状態付きの多段階ワークフローはLangGraphまたはHaystackを指します。エンタープライズの多言語はSemantic Kernelを指します。

退出コストを量る。 外したらコードのどれだけが変わるか。呼ぶライブラリは去るのが安く、制御フローを所有するフレームワークはそうではありません。その問いは採用の後ではなく前に聞く価値があります。

人気だけで選ばない。 ここにあるどの選択肢も活発に保守され、寛容にライセンスされています。エコシステムの大きさは例を見つけるのに重要であり、問題への適合と同じではありません。

よくある質問

LangChainの最良の代替は何ですか？

必要な部分によります。検索が重いアプリケーションにはLlamaIndex、検査可能な本番パイプラインにはHaystack、測定可能な品質のタスクにはDSPy、構造化出力にはInstructorまたはPydantic AI、状態付きワークフローにはLangGraph。多くのアプリケーションでは、提供者SDKを直接呼ぶのが最良の選択肢です。

LangChainはまだ保守されていますか？

大いに。2026年8月末時点でlangchainは1.3.18、langchain-coreは1.6.1、どちらもMITライセンス、リポジトリはこのカテゴリで最も活発な部類です。流通している批判の多くは以前のバージョンを述べています。

LLMで構築するのにフレームワークは必要ですか？

いいえ。提供者SDKは素直で、直接呼び出しは数行、送られるものが完全に透明です。フレームワークは多くの統合、複雑なagentループ、共有のチーム慣習で場所を得ます。そして何が起きているかを見る能力を犠牲にします。

LangChainかLlamaIndexか？

検索が難しい部分ならLlamaIndexです。document loaders、チャンキング戦略、インデックス抽象がより発達しています。多くの提供者とツールにわたる広い合成が必要ならLangChainです。どちらも汎用フレームワークに成長したので、区別はかつてのほど大きくありません。

DSPyとは何か、どう違いますか？

プロンプトを書くテキストではなく、最適化するパラメータとして扱います。入出力を宣言し、指標を定義すると、フレームワークが評価セットに対してプロンプトとfew-shot例を最適化します。評価セットが必要で、それが本当のコストであり、本当の利益でもあります。

LangGraphはLangChainの代替ですか？

同じチームからで、独立して使えます。チェーン抽象をノード、辺、状態の明示的なグラフに置き換え、LangChainへの最もよくある苦情——制御フローが隠れていること——に応えます。状態付きや分岐のあるアプリケーションでは、人々が実際に欲しかったものであることがよくあります。

本番に最適なLLMフレームワークはどれですか？

Haystackが最も明示的に本番志向で、バージョン管理とレビューができるシリアライズ可能なパイプラインがあります。LangGraphは状態付きワークフローに向きます。しかし最も本番に優しい選択はしばしば最も少ないフレームワークです。午前三時に読めるコードは、辿らなければならない抽象に勝ちます。

これらのフレームワークは無料でオープンソースですか？

すべてそうです。LangChain、LangGraph、LlamaIndex、DSPy、Semantic Kernel、Pydantic AI、InstructorはMITライセンス、HaystackはApache-2.0です。すべて寛容でコピーレフト制限はなく、2026年9月時点でいずれも活発に開発されていました。

まとめ

フレームワークの問いは、本当は範囲の問いです。ここにあるどのプロジェクトもよく保守され寛容にライセンスされているので、決定は品質についてではありません。アプリケーションの制御フローをどれだけ渡したいかについてです。

多く渡すと、最初の動く版までの速さ、書いていない統合、考えなくてよかったagentループが得られます。少なく渡すと、読めるコード、監査できる依存ツリー、リクエストとレスポンスを見るデバッグが得られます。

身につける価値のある習慣は、まずフレームワークなしで半日過ごすことです。問題の本当に難しい部分が分かります。たいていは検索品質、構造化出力の妥当性、評価であり、どれも汎用フレームワークが焦点を絞ったライブラリよりうまく解くものではありません。

それからその具体的な問題のために選びます。検索にはLlamaIndex、品質を測れるところにはDSPy、構造化出力にはInstructorまたはPydantic AI、状態と検査可能性が重要なところにはLangGraphまたはHaystack、プラットフォーム判断がすでに決まっているところにはSemantic Kernel。退出コストを視野に入れておいてください。ライブラリとフレームワークの違いは、それがあなたのために何をするかではなく、使うのをやめたときコードのどれだけが変わらなければならないかです。