LangChainとは、LLMを活用したアプリケーション・エージェント開発を大幅に簡素化するPythonフレームワークだ。GitHubで143,000スター超(2026年8月時点、MITライセンス)のコミュニティを持ち、2025年10月には待望のバージョン1.0安定版に到達した。インストールからRAGパイプライン構築、エージェント実装、LangGraphとの連携まで、実行可能なコードを使って順に見ていく。
RAG全般の仕組み・構築・ベクトルDB選定は RAGとは?仕組み・構築・ベクトルDB選定までの2026年実装マップ をご覧ください。
LangChainとは:エージェントエンジニアリングプラットフォームの概要
公式は2024年以降、LangChainを「The agent engineering platform(エージェントエンジニアリングプラットフォーム)」と位置づけている。単なるLLM呼び出しラッパーではなく、エージェントが自律的にツールを選択・実行し、複数ステップの推論を行う本格的なシステムを構築するためのインフラへと進化した経緯がある。
LangChainが解決する問題は明確だ。異なるLLMプロバイダーへの統一インターフェース、ドキュメントの取り込みとベクトル化、会話履歴の管理、外部ツールとの連携。これらをゼロから実装すると膨大なボイラープレートコードが必要になるが、LangChainはこれらのコンポーネントを標準化されたAPIとして提供し、開発者がアプリケーションのコアロジックに集中できるようにする。
「LangChain」という名称は実際には4つの製品群を指す。中核となる LangChain Core(モデル・エンベッディング・ベクトルストア等の抽象インターフェース、OSS)、複雑なエージェントをステートマシンとして制御する LangGraph(OSS)、エージェントの評価・観測・デバッグを担う LangSmith(有料SaaS)、サブエージェントとファイルシステムを扱う高度な実装を提供する Deep Agents(OSS)の4つだ。pip install langchain で手に入るのは最初のLangChain Coreのみで、複雑な条件分岐やループが必要になったらLangGraphを組み合わせる、という関係になる。
高レベルのチェーンAPIで十分なシンプルなRAGや単純なLLM呼び出しにはLangChainのみで対応できる。条件分岐・ループ・並列実行・ステート管理が必要な複雑なエージェントには、LangGraphを組み合わせることでより制御可能な実装になる。
2025年10月17日にリリースされたv1.0では、エージェント構築のコアAPIが安定化され、破壊的変更の少ない長期運用が可能になった。2026年8月時点の最新版は1.3系(PyPI実測)で、活発なマイナーアップデートが続いている。
公式ドキュメントはdocs.langchain.comにPython/JS共通で集約されており、コンセプト解説・移行ガイド・APIリファレンス(reference.langchain.com)がここから辿れる。
主な機能:LangChainが提供する6つの強み
公式READMEが掲げる強みを整理すると、次の6点に集約される。
・リアルタイムデータ拡張:モデルプロバイダー・ツール・ベクトルストア・リトリーバーの豊富な統合ライブラリを通じて、多様な外部データソースとLLMを接続できる
・モデル相互運用性:OpenAI・Anthropic(Claude)・Google Gemini・Ollama(ローカルLLM)など主要プロバイダーを、コードを書き換えずに切り替えられる
・迅速なプロトタイピング:モジュール化されたコンポーネント設計により、ゼロから作り直さずにアプローチを素早く検証できる
・本番運用機能:LangSmithとの統合で監視・評価・デバッグを標準サポートし、実戦で磨かれたパターンでスケールできる
・LCEL(LangChain Expression Language):パイプ演算子(|)でコンポーネントをつなぐ宣言的なAPIで、ストリーミング・非同期・バッチ処理を同じインターフェースで扱える
・活発なOSSコミュニティ:GitHub 143,000スター超、頻繁なリリースサイクルでインテグレーション数が拡大し続けている
クイックスタート:インストールから動作確認まで
基本インストール
公式READMEのクイックスタートは uv add を推奨している。
# uv(推奨・高速)
uv add langchain
# または pip
pip install langchain
LLMプロバイダーごとの追加パッケージ
# OpenAI(GPT系)
pip install langchain-openai
# Anthropic(Claude)
pip install langchain-anthropic
# Google Gemini
pip install langchain-google-generativeai
# Ollama(ローカルLLM)
pip install langchain-ollama
# ベクトルDB(Chroma)・ドキュメント処理
pip install langchain-chroma langchain-community
正式版APIに格上げされる前の実験的機能(研究段階のエージェントパターン等)を試したい場合は、pip install langchain-experimental で別パッケージとして導入する。本体の langchain より仕様変更が起きやすいため、本番コードに組み込む際はバージョン固定を推奨する。
最小動作確認(公式クイックスタート)
from langchain.chat_models import init_chat_model
# 統一インターフェースでモデルを初期化(プロバイダー名:モデル名の形式)
model = init_chat_model("openai:gpt-5.5")
result = model.invoke("Hello, world!")
print(result.content)
init_chat_model の第一引数は プロバイダー名:モデル名 の形式で、anthropic:claude-... や google_genai:gemini-... に差し替えるだけで同じコードが動く。これが「モデル相互運用性」の実体だ。対応プロバイダーは今も拡張が続いており、直近ではPR #38786(2026年7月10日マージ)でMeta系プロバイダーが init_chat_model に追加されている。
導入したバージョンを確認するには次のコマンドを実行する。
python -c "import langchain; print(langchain.__version__)"
# 2026年8月時点でpip/uvから新規インストールした場合の出力例: 1.3.14
実行前に
OPENAI_API_KEY や ANTHROPIC_API_KEY などの環境変数を設定する必要がある。複数プロバイダーを試す開発段階ではAPIコストが積み上がりやすいため、LangSmithのトレーシングでトークン使用量を監視するか、開発初期はOllama(ローカルLLM)でコストを抑えるとよい。実装手順:RAGパイプラインとエージェントを構築する
公式ドキュメントの手順に沿って、ドキュメントロード → チャンキング → エンベッディング → ベクトルストア格納 → リトリーバー → LLM生成、というRAGパイプラインを構築する。以下は公式README・ドキュメントのコード例をベースにした実装例で、実行結果はAPIキー・投入データに依存するため、手元の環境で置き換えて確認してほしい。
ステップ1:ドキュメントのロードと分割
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
loader = PyPDFLoader("./technical_manual.pdf")
docs = loader.load()
# 日本語テキスト対応の分割設定
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000, # チャンクの最大文字数
chunk_overlap=200, # 前後のチャンクとの重複文字数
separators=["\n\n", "\n", "。", "、", " ", ""],
)
chunks = text_splitter.split_documents(docs)
print(f"チャンク数: {len(chunks)}")
ステップ2:ベクトルストア格納とLCELチェーンの構築
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(
documents=chunks, embedding=embeddings, persist_directory="./chroma_db",
)
retriever = vectorstore.as_retriever(search_type="mmr", search_kwargs={"k": 5})
prompt = ChatPromptTemplate.from_template(
"以下のコンテキストに基づいて質問に答えてください。\n\nコンテキスト:\n{context}\n\n質問: {question}"
)
def format_docs(docs):
return "\n\n".join(doc.page_content for doc in docs)
# LCEL:パイプ演算子でチェーンを宣言的に組み立てる
rag_chain = (
{"context": retriever | format_docs, "question": RunnablePassthrough()}
| prompt
| ChatOpenAI(model="gpt-5.5", temperature=0)
| StrOutputParser()
)
answer = rag_chain.invoke("APIの認証方法を教えてください")
print(answer)
このパイプラインを実行すると、リトリーバーがMMR(最大境界関連性)で上位5件のチャンクを取得し、プロンプトに埋め込んでLLMへ渡す一連の流れがすべて | で可視化される。ステップごとに個別のクラスを呼び出す旧来のスタイルよりも、処理順序が読みやすい。
ステップ3:ツール呼び出し型エージェントの実行
from langchain_core.tools import tool
from langchain.agents import create_tool_calling_agent, AgentExecutor
@tool
def get_weather(city: str) -> str:
"""指定した都市の天気を取得する"""
return f"{city}の天気:晴れ、気温22°C"
tools = [get_weather]
agent_prompt = ChatPromptTemplate.from_messages([
("system", "あなたは役立つAIアシスタントです。必要に応じてツールを使ってください。"),
("human", "{input}"),
("placeholder", "{agent_scratchpad}"),
])
agent = create_tool_calling_agent(ChatOpenAI(model="gpt-5.5"), tools, agent_prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
result = agent_executor.invoke({"input": "東京の天気を調べて、明日の服装のアドバイスをください"})
print(result["output"])
verbose=True にすると、エージェントがどのツールを・どの引数で呼び出したかがログに出力される。ツール選択の妥当性をデバッグする際に最初に確認すべき箇所だ。OpenAIの関数呼び出し(Function Calling)と似て見えるが、OpenAIの機能はOpenAI API固有なのに対し、上記の @tool 定義はプロバイダーを問わない抽象化レイヤーで、Claude・Geminiに切り替えても同じツール定義がそのまま動く。
ストリーミングでの応答確認
LCELで組んだチェーンは、.invoke() を .stream() に置き換えるだけでストリーミング応答に切り替わる。個別の実装を追加する必要はない。
# invoke() と同じチェーン定義のまま、呼び出しだけをstream()に変更
for chunk in rag_chain.stream("会社の休暇ポリシーを教えてください"):
print(chunk, end="", flush=True)
print()
チャットUIのように逐次表示させたい場合に有効で、非同期実行が必要なら同じチェーンに .ainvoke() / .astream() を使う。呼び出し方法を変えるだけでモード切り替えができる点が、LCELを「宣言的」と呼ぶ理由だ。
アーキテクチャ:LCELとコンポーザブル設計の仕組み
LangChainの設計思想は「コンポーザブルなコンポーネント」にある。LLMプロバイダー、エンベッディングモデル、ベクトルストア、ドキュメントローダー、テキストスプリッター──これらが共通インターフェースを実装しており、自由に組み替えられる。
PDF・CSV・Web・DB等"] B["Text Splitters
チャンキング"] A --> B end subgraph "エンベッディング/ストレージ層" C["Embedding Models
OpenAI・HuggingFace等"] D["Vector Stores
Chroma・Pinecone・Weaviate等"] B --> C C --> D end subgraph "検索・生成層(LCEL)" E["Retrievers
MMR・類似度検索"] F["Chat Models
OpenAI・Claude・Gemini・Ollama"] G["Prompt Templates"] D --> E E --> H["RAG Chain
context + question"] G --> H F --> H end subgraph "エージェント層" I["Tools
検索・計算・API呼び出し"] J["Memory
会話履歴"] K["Agent
Tool Calling"] H --> K I --> K J --> K end K --> L["最終回答"] K -.複雑な分岐・ループ.-> M["LangGraph
StateGraph"]
ポイントはすべてのコンポーネントが Runnable という共通プロトコルを実装していることだ。このプロトコルは公式リポジトリの libs/core/langchain_core/runnables/base.py の class Runnable(133行目、2026年8月3日時点のコミットで固定)で定義されている。そのためLCELのパイプ演算子でどの組み合わせも接続でき、ストリーミング・非同期・バッチの3モードを個別実装せずに済む。複雑な条件分岐やループが必要になった時点で、同じコンポーネントをLangGraphの StateGraph に載せ替えられる設計になっている。
競合ツールとの比較:LlamaIndex・LangGraph・CrewAI・Difyとの違い
LangChainは最も広範なエコシステムを持つが、用途によっては他フレームワークが優れる場面もある。
| フレームワーク | 学習コスト | エージェント | RAG | ローカルLLM | 特徴 |
|---|---|---|---|---|---|
| LangChain | 中 | ✅ | ✅ | ✅ | 汎用・最多インテグレーション、143,000スター超 |
| LlamaIndex | 低〜中 | ✅ | ✅✅ | ✅ | RAG特化・高精度検索 |
| LangGraph | 高 | ✅✅✅ | ✅ | ✅ | LangChain上の複雑ステートフルエージェント制御 |
| CrewAI | 低 | ✅✅ | ✅ | ✅ | 役割分担型マルチエージェント |
| Dify | 低(GUI) | ✅ | ✅ | ✅ | ノーコード/ローコードLLMOps基盤 |
LangChainが優位な場面:主要LLM全社への統一インターフェース、既存エコシステム(Slack・Notion・S3・SQL等)との接続を大量に必要とするプロジェクト。
LlamaIndexが優位な場面:RAGの精度追求が最優先で、クエリデコンポジションやリランキングなど高度なリトリーバーが必要な場合。
LangGraphが優位な場面:条件分岐・ループ・複数エージェントの協調など、精密な制御フローが要件に含まれる場合。
GUIで組みたい場合:LangChain自体はコードファーストのフレームワークで、標準のGUIは提供していない。ドラッグ&ドロップでフローを組みたい場合は、LangChainをベースにしたビジュアルビルダー系OSS(Langflow等)を別途検討する選択肢がある。
実践的な使い方:3つのユースケース
ユースケース1:社内ドキュメントQ&Aシステム
from langchain_community.document_loaders import DirectoryLoader, PyPDFLoader
loader = DirectoryLoader("./company_docs", glob="**/*.pdf", loader_cls=PyPDFLoader)
docs = loader.load()
chunks = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=100).split_documents(docs)
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings(), persist_directory="./hr_docs_db")
retriever = vectorstore.as_retriever(search_kwargs={"k": 4})
rag_chain = (
{"context": retriever | format_docs, "question": RunnablePassthrough()}
| ChatPromptTemplate.from_template("コンテキスト:{context}\n質問:{question}")
| ChatOpenAI(model="gpt-5.5")
| StrOutputParser()
)
print(rag_chain.invoke("育児休業は何日取得できますか?"))
社内規程・マニュアルPDFをまとめてインデックス化し、自然言語で問い合わせるインターフェースを構築するケース。ディレクトリ単位のロードに対応しているため、既存の共有フォルダ構成をそのまま流用しやすい。
ユースケース2:構造化データ抽出
from pydantic import BaseModel, Field
class ProductInfo(BaseModel):
name: str = Field(description="製品名")
price: float = Field(description="価格(円)")
features: list[str] = Field(description="主要機能のリスト")
structured_llm = ChatOpenAI(model="gpt-5.5").with_structured_output(ProductInfo)
result = structured_llm.invoke(
"新製品XYZ-2026は価格49,800円。AI搭載、防水、バッテリー48時間持続が特徴。"
)
print(result.name, result.price) # → "XYZ-2026" 49800.0
非構造化テキストからJSON相当のオブジェクトを直接取得できる。with_structured_output はPydanticモデルをそのままスキーマとして使えるため、パース処理を自前で書く必要がない。
ユースケース3:LangGraphによる条件分岐エージェント
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from typing import TypedDict, Annotated
import operator
class AgentState(TypedDict):
messages: Annotated[list, operator.add]
workflow = StateGraph(AgentState)
workflow.add_node("agent", agent_node)
workflow.add_node("tools", ToolNode(tools))
workflow.set_entry_point("agent")
def should_continue(state):
return "tools" if state["messages"][-1].tool_calls else END
workflow.add_conditional_edges("agent", should_continue)
workflow.add_edge("tools", "agent")
app = workflow.compile()
条件分岐・ループを伴うエージェントは、LangChainのコンポーネント(ツール・モデル)をそのままLangGraphの StateGraph に載せ替えて実装する。基本パターンだけを示したが、より踏み込んだ構築手順は公式ドキュメントのLangGraphガイドを参照してほしい。
まとめ:LangChainを選ぶべき人・注意点
LangChainは「エージェントエンジニアリングプラットフォーム」として、2025年10月のv1.0安定版到達を経てLLMアプリ開発のデファクトスタンダードとしての地位を固めている。GitHub 143,000スター超・幅広い対応コンポーネント・主要LLM全社対応という層の厚さは他に並ぶものがない。
向いているのは、複数のLLMプロバイダーを切り替えながら開発したいチーム、既存のSaaS(Slack・Notion・S3等)と連携するRAG/エージェントを素早く組みたいチームだ。一方で、精密な条件分岐・ループ制御が必要になった時点でLangGraphの学習コストが発生する点、公式インテグレーション数が多い分だけ「どのパッケージを入れるか」の見極めが必要になる点は、正直に注意点として挙げておきたい。
RAGシステムの実装を始める際は、本記事のコードサンプルをベースに、MinerUでRAGの文書取り込みを高精度化でPDFを前処理してチャンキングの品質を高め、ゼロからRAGの各層を手を動かして理解したい場合はLangchain RAG From Scratch:ゼロからRAGシステムを構築、企業向けの本番運用を見据えるならRAGFlowとは|高精度な文書解析でRAGを組むOSSエンジンを組み合わせるのが2026年時点の現実的な構成だ。
LangChain本体は安定版だが、周辺インテグレーション(特にコミュニティ提供のconnector)は品質にばらつきがある。本番投入前には該当パッケージのメンテナンス状況・Issue数を確認し、langchain_experimental配下のAPIは仕様変更の可能性がある前提で扱うことを推奨する。
検証環境:Ubuntu 24.04 / Python 3.12 / langchain 1.3系(2026年8月時点のPyPI最新)。本記事のコード例は公式リポジトリ・公式ドキュメントの記載に基づく。langchain_experimentalとの違い・公式ドキュメントの場所・GUIの有無などの疑問は、本ページ末尾のFAQセクションにまとめている。