インターネット上には2つのLangChainが存在します。公式ドキュメント版——そこではすべてのチュートリアルが「あなたはすでにLangChainを選んだ」ことを前提にしています。そしてコミュニティ批判版——そこでは「抽象化の漏れ（abstraction leakage）」が人格特性のように扱われています。このガイドの核心的な主張：LangChainの採用は「使うか使わないか」の二者択一ではありません——条件付きの意思決定であり、その条件は3つのシグナルであって、雰囲気ではありません。
両陣営は同じ仕方で間違っています：フレームワークの選択を、コスト関数を持つエンジニアリング上の意思決定ではなく、忠誠心のテストとして扱っているのです。
正直な立場を率直に述べます：ほとんどのプロジェクトは生のSDKから始めるべきであり、そのうちの一部は、3つのシグナルが現れたときにLangChain——より正確にはLangGraph——を採用すべきです。このガイドでは、シグナル、フレームワークの決定を可逆に保つ移行パス、そして両陣営が誤解している反論を整理します。これは、私たち自身が両方の失敗——早すぎる採用と遅すぎる採用——を犯す前に存在していればよかったと思う、フレームワーク選択のガイドです。
「使うか使わないか」が間違った問いである理由
要点：フレームワーク論争は、実は複雑さの税（complexity tax）の論争です——そしてその税を払う価値があるのは、マーケティングが決して言及しないしきい値を超えたときだけです。
2026年の証拠は異常なほど具体的です。LangChain 1.0の書き直しは、長年にわたる「肥大化している」という批判に、よりクリーンなコアで応えました——そして複雑さの税の判定は、フレームワークが解決しない問題のために採用するチームにも依然として当てはまります。一方、設定がフレームワークコードに勝るケースに関する移行記事は、逆の方向を記録しています：実際のアーキテクチャが「設定＋ループ」であることが判明したチームが、フレームワークから離れる方向へ移行する例です。
両方向の背後にあるパターン：**フレームワークは、システムがその提供するものを必要とするときにだけ、その税（学習曲線、抽象化の間接層、アップグレードの結合）を支払う価値が生じます。**2ステップのツール呼び出しループにグラフランタイムは必要ありません。リトライ、チェックポイント、承認付きの10ステップのステートフルワークフローには、本当に必要です。間違いはどちらかの側を選ぶことではなく、自分のシステムがどちらの側にいるかを知る前に決めてしまうことです。
その意味：フレームワークを正当化する3つのシグナル
要点：状態、分岐、コラボレーション——このうち1つで評価を検討、2つで採用を検討する価値があり、そしてどれも「デモが印象的だった」ではありません。
**シグナル1 — 生き残る必要のある状態。**ワークフローに永続化と復旧が必要な状態がある：中断したジョブが停止した場所から再開する、マルチターンセッションがクラッシュを乗り越える、承認によって実行が中断され後で再開される。これはグラフランタイムの中核的強みであり——LangGraphのチェックポインターモデルはまさにこのために存在します——自作ループが最も苦手とするシグナルでもあります。
**シグナル2 — 分岐の複雑さ。**条件パスが多数ある、動的な再プランニング、中間結果に依存するループ。制御フローが線形スクリプトとして読めなくなったとき、宣言型グラフは「ワークフローがコードそのもの」と「ワークフローがコード内に文書化されている」を分ける違いになります。
**シグナル3 — チームのコラボレーション。**複数のエンジニアが同じエージェントを保守し、共有の抽象化、バージョン管理されたワークフロー、可観測性フックが必要。フレームワークの規約はチームの契約になります——これは実際の利益であり、チームが存在して初めて現実のものとなります。
「まだ必要ない」リストも同じくらい率直に述べます：単一のツールループ、まだ検証中のプロトタイプ、フレームワークの学習曲線が残りのプロジェクト予算を超えるシステム。これらは生のSDKの領域です——本シリーズのエージェントアーキテクチャガイドは、フレームワークが必要になる前に素のループでどこまで行けるかを示しています。
実践への示唆：フレームワークに依存しない移行パス
要点：可逆的なパスは「生のSDK→シグナル→フレームワーク」の順であり、全体を交換可能に保つ統合モデル層が鍵です。
両方の失敗を避ける本番シーケンス：
- **生のSDKから始める。**ツール呼び出しループは約50行です。マルチモデルアーキテクチャパターンを使えば、初日からプロバイダー中立を保てます。ほとんどのプロトタイプはこれを超えることがありません——超えるものも、書き直しではなく移行元となる動作するベースラインをすでに持っています。
- **シグナルに注意を払う。**状態、分岐、コラボレーション——3つのうち2つ当てはまれば、フレームワークの税を払う価値が生まれます。ここが、LangGraphのエコシステム（チェックポインティング、トレーシング、デプロイツール）が学習曲線の投資を回収し始める地点です。
- **移行するのはモデルではなくワークフロー。**フレームワークはオーケストレーションを包みます。モデル層は統合エンドポイント、カスタムルーティング、モデルカタログの背後に残ります——つまりフレームワークの決定とプロバイダーの決定は独立したままで、どちらか一方を変えてももう一方を強制しません。LangChain SDKインテグレーションがこれを直接サポートします。
- **出口を開いておく。**採用するフレームワークの抽象化は、すべて置き換え可能なものであるべきです：ワークフローグラフは置き換え可能にし、データ契約やモデルルーティングはフレームワークに縛らない。フレームワークをアイデンティティではなくオーケストレーションとして扱うチームこそ、次の移行——自社のものであれ他社のものであれ——を乗り越えられるチームです。
クイックスタートで中立なベースラインを数分で起動できます。その後はシグナルが決めます。
採用前の10項目チェックリスト——フレームワークにコミットする前に実行しましょう：
- ワークフローに、クラッシュや再起動を乗り越える状態が必要か？
- 制御フローに5つ以上の条件パスがあるか？
- このエージェントを複数のエンジニアが保守するか？
- フレームワークの抽象化は、回避策なしでワークフローを表現できるか？
- チームは締め切り中ではなく今、学習曲線を払う用意があるか？
- チェックポイントとトレーシングの要件は文書化されているか？
- ワークフローはフレームワークから独立してテストできるか？
- モデル層は交換可能なエンドポイントの背後にあるか（フレームワークに縛られたキーではないか）？
- フレームワークが価値を生まなくなった場合の出口パスは文書化されているか？
- この複雑さでも、生のSDK版は保守可能か？
「はい」が5つ以上なら採用が正当化され、それ未満ならフレームワークの税は時期尚早です。
抽象化の中でのLangChainの位置づけ：
| 抽象化 | 担当するレイヤー | LangChainとの重複 |
|---|---|---|
| 生のSDK（OpenAI／Anthropicクライアント） | API呼び出し | すべてが包むベースレイヤー |
| LangChain／LangGraph | オーケストレーション：状態、グラフ、ツール | 本ガイドの主題 |
| Vercel AI SDK | UIとモデルをつなぐ配管、ストリーミングフック | 最小限——補完関係 |
| Pydantic AI | 型付きツールスキーマと出力モデル | 部分的——両方ともツールを扱う |
| LlamaIndex | 検索（retrieval）とドキュメントパイプライン | 部分的——RAG中心の重複 |
衝突を防ぐルール：各抽象化は1つのレイヤーを担当することで存在価値を得ます——そして2つが同じレイヤーを主張した瞬間、そのうち1つは冗長です。
反論：ドキュメントと批判者のそれぞれの誤り
要点：両陣営は互いにすれ違っています——ドキュメントは採用を前提とし、批判者は2023年版を前提としており、本番の真実はその中間にあります。
**公式ドキュメント陣営の誤り。**ドキュメントは「どう使うか」に答え、「使うべきか」には答えません。すべてのLangChainチュートリアルは、すでに決断した人に向けて書かれています——だからこそ、フレームワークが解決しない問題のために採用され続けるのです。複雑さの税の判定は、フレームワーク批判であると同時にドキュメントのギャップでもあります。
批判者の誤り。「抽象化の漏れ」の定説のほとんどは、1.0以前のスタックに対して書かれています。2026年のフレームワークは別物です：書き直しでコアが統合され、LangGraphがオーケストレーションを「何でもかんでも詰め込んだ構成」から分離し、「LangChainは肥大化している」は今や2026年のデータなしに使い回されている2023年の見解です。現在のバージョンを批判するか、さもなくば批判自体をやめるべきです。
**統合。**フレームワークはコスト関数を持つツールです——シグナルがシステムに必要だと示すときに税を払い、必要ないときはスキップし、決定は可逆に保ちます。これは妥協ではありません。ドキュメントも批判者も反論できない唯一の立場です。
FAQ
2026年、LangChainは終わったのですか？
いいえ——1.0の書き直しでコアは一新され、LangGraphはエコシステムで最も活発な本番エージェントランタイムのひとつです。実際に終わったのは「デフォルトで採用する」時代です：フレームワーク自身の勢いは、今やチュートリアルではなく本ガイドのシグナルの背後にあります。
LangChain 1.0への移行は価値がありますか？
シグナル——状態、分岐、コラボレーションのニーズ——が存在する場合のみです。「最新だから」という理由で動作中の生のSDKシステムを移行すると、便益なしに移行コストと複雑さの税を支払うことになります。リリースノートではなく、シグナルに照らして評価しましょう。
生のSDKはいつまでで十分ではなくなりますか？
状態が生き残る必要があるとき、分岐が読みにくくなったとき、またはチームが1人のエンジニアを超えて成長したときです。3つのシグナルのうち2つ当てはまればフレームワークの税を払う価値があります。それ以前は、素のループのほうが構築・デバッグ・理解が速いのです。
LangChainを使うとロックインされますか？
オーケストレーション層では、はい——それが採用という意味です。モデル層では、いいえ：モデルをカスタムルーティング付きの統合エンドポイントの背後に置いておけば、プロバイダーの変更は設定のままです。回避できるロックインこそが重要であり、本ガイドが開いたままにしているのもそれです。
まとめ
LangChainは条件付きの意思決定であり、忠誠心テストではありません：まず生のSDK、そして3つのシグナル——状態、分岐、コラボレーション——に注意を払い、そのうち2つが現れたらフレームワーク（具体的にはLangGraph）を採用します。モデル層を統合エンドポイントの背後に置いて、フレームワークの決定をオーケストレーションのみに限定し、出口を開いたままにします。ドキュメントは「どう使うか」を、批判者は「使うな」を教えます。本ガイドは「いつ使うか」を教えます——そしてそれが唯一意味のある問いです。
フレームワークにコミットする前に、3つのシグナルをテストしましょう。TokSpan APIキーを取得して——ベースライン用に無料クレジット$5付き——判断を下す生のSDKループを構築してください。