LangChain（ラングチェーン）とは、LLM（大規模言語モデル）を組み込んだアプリケーションの開発を支援するオープンソースのフレームワークです。RAGやAIエージェントといったLLM応用システムを、部品の組み合わせで効率よく構築できることから、この分野の代表的な開発基盤として広く使われています。本記事の内容は、LangChainの定義と1.x系に至る経緯、LangGraph・LangSmithを含むエコシステムの全体像、RAG構築・エージェント開発などできることの整理です。あわせて、インストールから最小エージェントを動かすまでのコードと、あえてLangChainを使わないほうがよい場面まで含めた採用判断の基準を解説します。
まとめ：LangChainの要点と採用・不採用の結論
LangChainの価値は、LLMアプリ開発で毎回必要になる定型部品（モデル接続・文書処理・検索連携・ツール呼び出し）を、共通の書き方で組み合わせられる点にあります。特定のモデルに依存しない抽象化が根幹の思想で、GPTからClaudeへの切り替えのような変更も小さな修正で吸収可能です。2025年10月の1.0正式リリース以降はエージェント開発基盤としての性格を強め、ワークフロー制御のLangGraph、運用監視のLangSmithと組み合わせて使う形が標準になっています。
版番号の現在地も押さえておきます。PyPIのlangchainパッケージでは、2026年9月時点の最新が1.4.0（2026年9月3日公開）、要求Pythonは3.10以上4.0未満、ライセンスはMITです。1.0以降はエージェントを作るcreate_agentと、その挙動に割り込むミドルウェアが中核APIとして整理されました。
一方で、LangChainは万能の選択ではありません。単一モデルへの単純な呼び出しだけなら各社SDKを直接使うほうが薄くて速く、フレームワークの抽象化がかえってデバッグを難しくする場面もあります。採用の目安は「複数モデルの併用・切り替え」「RAGやエージェントのような多段構成」「将来の組み替え」のいずれかを見込むかどうかです。本文の判断基準の章で、この線引きを具体化します。
LangChainの定義：LLMアプリケーション開発を支えるOSSフレームワーク
名前は聞くが実体がつかみにくい、という声の多いツールです。何を提供するもので、どんな経緯で現在の形になったのかを最初に固定します。
LangChainの定義と役割：モデル・データ・ツールをつなぐ部品群
LangChainは、LLMを使うアプリケーションに共通して必要となる処理を、再利用可能な部品として提供するライブラリ群です。具体的には、各社LLM（大規模言語モデル）への接続、プロンプトの組み立て、文書の読み込みと分割、ベクトル検索などの検索基盤との連携、外部ツールの呼び出し、処理の連結（チェーン）といった要素が揃っています。名前の由来もこの「処理を鎖のようにつなぐ」発想にあります。
位置づけとしては、Webアプリ開発におけるフレームワークと同じ役割をLLMアプリ開発で担うものです。ゼロから書けば数百行になる定型処理を部品の組み合わせに置き換え、開発者はアプリ固有のロジックに集中できます。プログラミング言語はPython版とJavaScript版が提供されており、本記事は利用者の多いPython版を前提に解説します。
公式の自己紹介も1.0前後で変わりました。GitHubの公式リポジトリは、自らを「エージェントエンジニアリングのプラットフォーム」と説明しています。単なるチェーンの道具箱という初期の紹介は、すでに現行の実態と合いません。
1.x系までの経緯：2022年公開からエージェント基盤への再定義
LangChainは2022年10月にオープンソースとして公開され、ChatGPT登場直後のLLM開発ブームの中で急速に普及しました。初期は機能追加のペースが速く、破壊的変更の多さが批判されることもありましたが、2025年10月にPython版・JavaScript版の1.0が正式リリースされ、APIの安定性を重視する段階に入りました。前述のとおり本記事執筆時点（2026年9月）のPython版最新は1.4系です。
1.0前後で明確になったのが、エージェント開発基盤への再定義です。公式のv1リリースノートは、変更点の筆頭にcreate_agentという単一の入口を据え、コアのlangchainパッケージをlangchain.agents・langchain.messages・langchain.tools・langchain.chat_models・langchain.embeddingsの5系統に絞り込んだと説明しています。古い記事や書籍は0.x時代の書き方で解説されているものが多いため、学習時はまず対象バージョンを確認してください。情報の鮮度は公式ドキュメントを基準にします。
エコシステムの全体像：LangGraph・LangSmithとの役割分担
現在のLangChainは単一ライブラリではなく、役割の異なる複数のプロダクト群です。①LangChain本体：モデル接続や部品群を提供する中核ライブラリで、共通基盤のlangchain-coreと各サービス連携パッケージに分割されています。②LangGraph：エージェントの処理フローをグラフ（状態遷移）として設計・制御するライブラリで、分岐・繰り返し・人の承認を挟む複雑なフローを扱います。③LangSmith：動作の記録・デバッグ・評価を行う運用支援サービスです。④Deep Agents：長時間動く自律型エージェントを組むための上位レイヤで、公式リポジトリの説明にも並記されています。
使い分けの目安は開発の段階です。試作段階はLangChain本体だけで足り、エージェントの挙動を厳密に制御したくなったらLangGraphを導入し、本番運用で品質を監視する段階でLangSmithを検討する、という積み上げが自然な流れになります。全部をまとめて学ぼうとすると挫折しやすいので、段階ごとに必要な範囲だけ触れてください。なお1.x系のcreate_agentは内部がLangGraphで実装されており、永続化・ストリーミング・人の承認による中断・実行履歴の巻き戻しは標準機能として使えます。
LangChainでできること：RAG・エージェント・LLM切り替えの実装
「何ができるか」を、企業システムでの利用が多い3つの用途に絞って具体化します。いずれも受託開発の現場で実際に構築依頼の多い構成です。
RAG構築の部品：文書読み込み・分割・検索連携を短いコードで組む
LangChainの代表的な用途がRAG（検索拡張生成）の構築です。RAGでは、文書の読み込み、検索しやすい単位への分割、ベクトル化と検索基盤への格納、質問時の検索と回答生成という一連の工程が必要になります。LangChainには各工程の部品が揃っており、PDFやオフィス文書の読み込み、分割方法の選択、主要なベクトルデータベースとの接続を、少ないコードで差し替え可能な形に組めます。
特に効くのが、検索基盤や埋め込みモデルの比較検証です。RAGの精度は部品の組み合わせで大きく変わるため、構築初期には複数の構成を試す工程が発生します。部品が共通インタフェースで抽象化されているLangChainなら、この差し替え実験を低コストで回せます。RAGの工程全体の設計はRAG構築の手順の解説で扱っているので、あわせて参照してください。接続先をAzure OpenAIにする場合の初期化引数とキーレス認証は、LangChainとAzure OpenAIの連携手順で整理しています。
エージェント開発：ツール呼び出しと処理フローをLangGraphで制御
2つ目の用途が、AIが状況を判断してツールを使い分けるエージェントの開発です。検索・計算・社内API呼び出しといったツールをAIに持たせ、「どのツールをいつ使うか」の判断をLLMに委ねるアプリケーションを、ツール定義と実行ループの部品で構築できます。ツール接続の標準規格であるMCPに対応したツール群も利用できます。エージェントという概念自体の整理はAIエージェントとは？仕組みと導入判断の解説を参照してください。
業務システムで問われるのは、AIの自由度と業務の統制の両立です。LangGraphを使うと、処理の流れを「この工程の後は必ず人の承認を挟む」「失敗したらこの分岐に戻る」といったグラフ構造で明示的に設計でき、AI任せにできない業務要件をフローに固定できます。自律性の高いデモを作るのは簡単でも、統制の効いた本番システムに仕上げる部分にこそ設計力が要る、というのが実務の勘所です。
モデルの抽象化：GPT・Claude等の切り替えを吸収する共通インタフェース
3つ目が、特定のLLMベンダーへの依存を薄める抽象化です。LangChainでは各社モデルの呼び出しが共通のインタフェースに揃えられており、GPT・Claude・Gemini・ローカルLLMの切り替えを、アプリ本体のロジックをほぼ変えずに行えます。モデルの進化と価格改定が数か月単位で起きる現状では、この乗り換え自由度が保険として機能します。
1.x系ではこの抽象化が応答の中身にまで及びました。v1リリースノートによれば、推論過程・テキスト・ツール呼び出しといった応答の構成要素はcontent_blocksという共通形式で取り出せるようになり、Anthropic・OpenAI・Google・AWS・Ollamaの各連携パッケージが対応しています。プロバイダごとに応答の分解処理を書き分けていた部分が消える変更です。
実務での使い方は2通りです。1つは開発初期の比較検証で、同じ処理を複数モデルで走らせて精度と費用を比べる用途です。もう1つは本番でのモデル併用で、難しい判断は上位モデル・大量の定型処理は軽量モデル、と処理内容ごとにモデルを使い分けてコストを抑える構成が組めます。単一モデル前提で直書きされたシステムでは、この柔軟性は後付けしにくいものです。
インストールから最小エージェントまで：手元で動かして挙動を確かめる
ここからは動くコードで確認します。いずれも公式ドキュメントの記載に沿った最小構成で、モデル名は契約中のプロバイダとモデルに置き換えて実行してください。
導入と最小実行：langchainを入れてモデルを1回呼び出すまで
公式のインストール手順は、本体パッケージと利用するプロバイダの連携パッケージを入れるだけで、Python 3.10以上が前提です。バージョンの取り違えが最大の詰まりどころなので、入れた直後に版番号を出力して手元の環境を確定させます。
pip install -U langchain langchain-openai
# 入った版番号をその場で確認する
python -c "import langchain; print(langchain.__version__)"
# 1.4.0
モデル呼び出しはinit_chat_modelにプロバイダ名とモデル名を渡すだけで、公式リポジトリのクイックスタートもこの3行です。接頭辞を差し替えれば呼び先が変わる、というのが前章の抽象化の実体になります。
from langchain.chat_models import init_chat_model
model = init_chat_model("openai:gpt-5.5")
result = model.invoke("Hello, world!")
print(result.content_blocks)
エージェント実装：create_agentにツールを渡して実行ループを回す
1.x系でエージェントを作る入口はcreate_agentに一本化されました。モデル・ツールの一覧・システムプロンプトを渡すと、モデルを呼んでツール実行を選ばせ、結果を戻して再び判断させる実行ループが組み上がります。0.x時代に手で書いていたチェーン定義は不要です。
from langchain.agents import create_agent
agent = create_agent(
model="claude-sonnet-4-6",
tools=[search_web, analyze_data, send_email],
system_prompt="You are a helpful research assistant.",
)
result = agent.invoke(
{"messages": [{"role": "user", "content": "Research AI safety trends"}]}
)
ツール側はlangchain.toolsの@toolデコレータを関数に付けるだけで定義できます。関数のシグネチャとdocstringがそのままモデルへの説明になるので、社内APIを呼ぶ薄いラッパ関数を並べれば業務システム連携のエージェントは形になります。
ミドルウェア：承認の割り込みと個人情報の伏せ字を実行ループへ差し込む
1.0で加わったミドルウェアは、エージェントの実行ループの各段に処理を割り込ませる仕組みです。公式のミドルウェア解説には、エージェント開始前のbefore_agent、モデル呼び出し前のbefore_model、呼び出しを包むwrap_model_call、ツール実行を包むwrap_tool_call、応答後のafter_model、終了後のafter_agentという6つのフックが定義されています。
from langchain.agents import create_agent
from langchain.agents.middleware import (
HumanInTheLoopMiddleware,
PIIMiddleware,
SummarizationMiddleware,
)
agent = create_agent(
model="claude-sonnet-4-6",
tools=[read_email, send_email],
middleware=[
PIIMiddleware("email", strategy="redact", apply_to_input=True),
SummarizationMiddleware(
model="claude-sonnet-4-6", trigger={"tokens": 500}
),
HumanInTheLoopMiddleware(
interrupt_on={
"send_email": {"allowed_decisions": ["approve", "edit", "reject"]}
}
),
],
)
この3つは、業務でエージェントを本番投入するときに必ず要求される要件そのものです。個人情報をモデルに渡す前に伏せ字へ置き換え、会話が長くなったら自動で要約し、メール送信のような取り返しのつかない操作の前で処理を止めて人の承認を待つ。自前で作れば相応の工数がかかる部分が、標準ミドルウェアの指定だけで入ります。フレームワークを採用する理由として、いま最も説明しやすいのはこの層です。
学習で迷わない情報の追い方：0.x系の記事とコードを見分ける
導入自体は難しくありませんが、情報の追い方に癖があります。つまずきやすい点に絞って要点を示します。
導入の流れ：パッケージ構成の理解と公式ドキュメントの読み進め方
導入は、①Python環境にlangchain本体と利用するモデルの連携パッケージを追加する、②利用するLLMのAPIキーを設定する、③公式チュートリアルの最小構成（モデル呼び出し→ツール定義→エージェント化）を順に動かす、という流れです。パッケージが中核と連携部分に分割されている構成を最初に理解しておくと、「どれを入れればよいか」で迷いません。
読む順番にもコツがあります。1.x系の公式ドキュメントはエージェントを軸に再編されているため、create_agentのページを起点にし、ミドルウェア・構造化出力・ストリーミングへ広げる読み方が合います。
移行の実務：旧importをlangchain-classicへ置き換える手順
検索して出てくる数年前の記事のコードが動かない原因の多くは、1.0でコアパッケージから外に出された機能を呼んでいることです。公式の移行ガイドによると、レガシーなチェーン実装、MultiQueryRetrieverなどのレトリーバー、インデックスAPI、hubモジュール、langchain-community由来のエクスポートはlangchain-classicパッケージへ移設されました。動かないコードに当たったら、まずimport文の先頭を疑ってください。
# 0.x系の記事に載っているimport
from langchain.chains import RetrievalQA
from langchain.retrievers import MultiQueryRetriever
# 1.x系での移設先（pip install langchain-classic が必要）
from langchain_classic.chains import RetrievalQA
from langchain_classic.retrievers import MultiQueryRetriever
既存システムを1.x系へ上げる場合の判断は単純です。動いているコードを延命したいならlangchain-classicを入れてimportだけ書き換える。エージェント化の恩恵を取りにいくなら、その機能だけcreate_agentで書き直す。全面書き換えを前提にすると移行が止まるので、部分的な併存を許す進め方を勧めます。
JS版との関係：LangChain.jsを選ぶ場面とPython版の使い分け
LangChainにはJavaScript／TypeScript版のLangChain.jsがあり、概念と主要機能はPython版と共通です。選び分けは開発チームの主戦場で決まります。データ処理や機械学習の資産があるチーム、RAGの検証を重ねる案件はPython版が有利です。一方、Webフロントエンドやサーバーレス環境を含むWebサービスにLLM機能を組み込む場合は、既存のJavaScript資産に乗れるLangChain.jsが自然な選択になります。
機能の充実度は歴史の長いPython版がやや先行する傾向がありますが、主要用途では差が縮まっています。LangChain.jsの特徴と使いどころはLangChain.jsとは？概要と特徴の解説で個別に扱っているので、JavaScript環境での採用を検討する場合はそちらを参照してください。
LangChainを採用すべき場面と使わないほうがよい場面の判断基準
LangChainには「学習コストが高い」「抽象化が過剰」という批判も一定数あり、検索結果にも入門を勧めない論調の記事が並びます。批判には正当な部分があるため、擁護でも否定でもなく、条件で線を引きます。
採用が効く条件：複数モデル併用・複雑なフロー・将来の組み替え前提
採用が合理的なのは次の条件に当てはまる開発です。①複数のLLMを比較・併用する、またはモデル乗り換えの可能性を残したい。②RAGやエージェントのように、検索・ツール・多段の処理を組み合わせる構成である。③構築後も部品の差し替えや構成変更を繰り返す見込みがある。これらは抽象化の恩恵が学習コストを上回る典型条件で、企業のRAG・エージェント案件の多くが該当します。
この条件下では、自前で同等の抽象化層を書く選択は再発明になりがちです。ベクトルデータベースや文書形式ごとの接続コードを自作・保守する工数を考えれば、実績のある部品群に乗るほうが総コストは下がります。前章で見た承認の割り込みや個人情報の伏せ字のように、監査で必ず問われる仕組みが標準で用意されている点も、本番運用を見据えた案件では効いてきます。
不要な場面：単一モデルの単純呼び出しと抽象化がデバッグを妨げる状況
逆に、次の場合はLangChainを使わない判断が正解です。第1に、単一モデルへの単純なAPI呼び出しで完結する用途です。チャット応答や1回の文章生成だけなら、各社の公式SDKを直接使うほうがコードは短く、依存も薄く、公式情報だけで完結します。単一モデルの呼び出しだけで足りるかは、ChatGPT APIとは何か・料金と使い方を確認すると判断しやすくなります。足りるのであれば、フレームワークの流儀を学ぶ時間は純粋な無駄です。
第2に、処理の中身を細部まで制御・追跡したい高度なチューニング局面です。抽象化は内部で何が起きているかを隠すため、プロンプトの微調整やトークン単位の挙動を詰める段階では、層をはがして直接実装したほうが速いことがあります。「まず素のSDKで小さく作り、構成が複雑化した時点でLangChainに載せ替える」という順番も現実的な戦略で、最初からフレームワークありきで考える必要はありません。
開発体制の判断：内製時の学習コストと外部委託を選ぶ場合の進め方
内製する場合、PythonエンジニアがLangChainで実用的なRAGを組めるようになるまでの学習は、フレームワーク自体よりも「検索設計・評価・運用」というLLMアプリ固有の周辺知識に時間がかかります。フレームワークは道具にすぎず、精度の出る構成を設計する経験値が本体です。この経験値を社内で育てる時間を確保できるかが、内製判断の実質的な分かれ目になります。
開発体制やスケジュールの制約で内製が難しい場合は、設計段階から外部の開発会社と組む選択肢があります。LangChainを含む技術選定からRAG・AIエージェントの構築・運用までを一貫して請け負うのが、株式会社一創の生成AI開発・AI受託開発です。フレームワークを使うべきかどうかの判断を含め、要件整理の段階から相談できます。
よくある質問
LangChainの検討時によく出る質問に答えます。
LangChainは無料ですか？商用利用はできますか？
LangChain本体とLangGraphはオープンソースで、MITライセンスのもと商用利用を含めて無償で使えます。PyPIのパッケージページにもMITと明記されています。費用が発生するのは、組み合わせて使うLLMのAPI利用料と、運用支援サービスLangSmithの有料プランなど周辺サービスです。LangSmithの料金ページによると、2026年9月時点でDeveloperプランは月額0ドル・月5,000トレースまで、Plusプランは1シートあたり月39ドル・月10,000トレースまでで、超過分は従量課金になります。導入判断の際は、フレームワーク自体ではなく、モデル利用料と開発・運用工数を予算の中心に置いてください。
LangChainを使わずにRAGは作れますか？
作れます。RAGの構成要素（文書処理・ベクトル検索・LLM呼び出し）はそれぞれ個別のライブラリやサービスで実装でき、LangChainは必須ではありません。小規模で構成が固定的なRAGなら直接実装のほうが見通しがよい場合もあります。LangChainが効くのは、部品の比較検証や構成変更を繰り返す開発です。RAG自体の仕組みは規模を問わず共通なので、まず要件を固めてから道具を選ぶ順序を守ってください。
LangChainの学習にはどの程度のPythonスキルが必要ですか？
Pythonの基礎文法に加えて、パッケージ管理と仮想環境、APIキーの扱いといった開発環境まわりの基本操作ができれば入門できます。動作環境としてはPython 3.10以上が要件です。難所は言語スキルよりも、バージョンごとの書き方の違いを見分けて公式ドキュメントを読み解く力にあります。プログラミング未経験の場合は、コードを書かずにLLMアプリを組めるノーコード系ツールから試すほうが目的に合うことがあります。
LlamaIndexとの違いは何ですか？
LlamaIndexは、データの取り込みと検索（RAGのデータ側）に特化したフレームワークで、LangChainより守備範囲を絞った設計です。RAGのデータ処理だけが目的ならLlamaIndexのほうが直線的に書ける場面があり、エージェントやツール連携まで含む広い用途ではLangChainが選ばれる傾向があります。両者は併用も可能なため、二者択一で悩むより、まず用途の範囲を確定させるのが先です。LlamaIndex側の実装と採用判断はLlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断で整理しています。
LangChainとDifyはどう違いますか？
DifyはLLMアプリを画面操作中心で構築できるプラットフォームで、コードで組むLangChainとは対象ユーザーが異なります。標準機能の範囲で済むチャットボットやRAGを素早く立ち上げるならDify、細かな制御・独自の業務ロジック・既存システムとの深い連携が要るならLangChainという住み分けです。試作をDifyで行い、要件が固まった本番をLangChainで作り込む使い分けも実務では見られます。
関連記事
- RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方：LangChainの代表用途であるRAGの工程全体を解説しています。
- RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説：RAGという手法自体の基礎を押さえたい方向けの解説です。
- LangChain.jsとは？その概要と特徴を詳しく解説：JavaScript環境でLangChainを使う場合の個別解説です。
- AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説：LangGraphで構築するエージェントの概念面の整理です。
- LLMとは？大規模言語モデルの仕組み・生成AIとの違いと企業導入の判断基準を解説：LangChainが接続するLLMそのものの基礎と実装形態の解説です。
