LangChain v1.0とは｜create_agent・ミドルウェア・langchain-classicを実装例で解説

LangChain v1.0は2025年10月22日にLangGraphと同時リリースされた、エージェント開発フレームワークのメジャー更新です。中心にあるのは、エージェント構築の新標準API create_agent、振る舞いを差し込むミドルウェア、そしてプロバイダ非依存でモデル出力を扱う標準コンテンツブロックの3つ。加えてlangchainパッケージが整理され、旧来の機能はlangchain-classicへ切り出されました。2026年7月時点の最新はlangchain 1.3系で、v1.0で入った構造はそのまま維持されています。本記事はGoogle検索で実際に問い合わせの多いPython APIを軸に、コードとともに変更点を整理します。LangGraphとの関係整理はLangChainとLangGraphの違い｜v1.0で逆転した関係と使い分けを先に読むと理解が早まります。

まとめ：LangChain v1.0で押さえる要点

• リリースと最新版： v1.0は2025年10月22日公開。2026年7月時点の最新はlangchain 1.3系（langchain-coreは1.4系、langchain-classicは1.0系）。
• create_agent： from langchain.agents import create_agent。LangGraphのcreate_react_agentを置き換える標準API。
• 構造化出力： Pydanticモデルをresponse_formatに渡すと、ネイティブ対応モデルはProviderStrategy、非対応はToolStrategyが自動選択される。
• ミドルウェア： 要約・人間の承認・PII秘匿などをエージェントループに差し込む仕組み。langchain.agents.middlewareから読み込む。
• パッケージ分割： レガシーなチェイン・Retriever・インデクシングはlangchain-classicへ移動。使うなら別途pip install langchain-classicが必要。

以降で各項目のコードと注意点を掘り下げます。

LangChain v1.0のリリース時期と最新バージョンの確認

LangChain v1.0はLangGraph v1.0と同じ2025年10月22日に公開されました。以後もマイナー更新が続き、2026年7月時点ではlangchain 1.3系が最新です。土台のインターフェースを担うlangchain-coreは独立して更新され1.4系、レガシー機能を集めたlangchain-classicは1.0系となっています。バージョン番号はパッケージごとに独立して進むため、3つを同じ番号だと考えないことが移行時の混乱を避けるコツです。

インストールと現在のバージョン確認は次のとおりです。最新の細かい番号は変動するため、正確な値はpip showやPyPIで確認してください。

pip install -U langchain
python -c "import langchain; print(langchain.__version__)"

v0.xからv1.0への主な変更点

v0.x時代のLangChainは機能が肥大化し、どのクラスが現役かが分かりにくい状態でした。v1.0はエージェント構築に必要な要素へlangchainパッケージを絞り込み、それ以外を切り離す方向に舵を切っています。主要な変化は次の表のとおりです。

読者が探している「最新バージョン」「create_agent」「langchain-classic」といったクエリは、いずれもこの整理の結果として生まれた要素です。次章から順に見ていきます。

create_agentの使い方｜v1.0標準のエージェント構築API

create_agentは、モデル・ツール・システムプロンプトを渡すだけで、モデル呼び出しとツール実行を繰り返すエージェントを組み立てる関数です。v0.xでLangGraphが提供していたcreate_react_agentを置き換える標準の入口で、内部はLangGraphランタイム上で動きます。

基本コードと主要パラメータ

最小構成は、モデル指定とツールのリストだけです。ツールは@toolデコレータを付けたPython関数をそのまま渡せます。

from langchain.agents import create_agent
from langchain_core.tools import tool

@tool
def get_weather(city: str) -> str:
    """指定した都市の天気を返す"""
    return f"{city}はいつも晴れです"

agent = create_agent(
    model="openai:gpt-5.6",
    tools=[get_weather],
    system_prompt="あなたは天気に答えるアシスタントです。",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "東京の天気は？"}]}
)
print(result["messages"][-1].content)

モデルは"provider:model"形式の文字列か、生成済みのチャットモデルを渡せます。上の例のモデルIDは記事執筆時点のものなので、実際には各プロバイダの最新IDに置き換えてください。主要な引数は次のとおりです。

引数名はすべてスネークケース（system_prompt・response_format）です。JavaScript版のキャメルケースとは異なるため、Pythonで書く際に取り違えないよう注意してください。JavaScriptで実装する場合はLangChain.jsとは？その概要と特徴を詳しく解説を参照してください。

エージェントループの仕組み

create_agentが生成するのは、モデル呼び出しとツール実行を繰り返すループです。モデルに会話履歴を渡し、応答にツール呼び出し（tool_calls）が含まれていればツールを実行し、その結果を履歴へToolMessageとして追加して再びモデルを呼びます。ツール呼び出しが無くなった時点でループは終了し、その応答が最終出力になります。開発者はこのループを自前で書く必要がなく、ツールとプロンプトの設計に集中できます。ツール実行の内部挙動を深く知りたい場合はLangGraphのTool Callingとは｜仕組みとToolNodeでの実装・create_agentとの使い分けが参考になります。

create_react_agentからの移行

v0.xで推奨されていたlanggraph.prebuilt.create_react_agentは、v1.0でcreate_agentに統合され非推奨になりました。移行はインポート行の差し替えが基本です。

# 旧
from langgraph.prebuilt import create_react_agent
# 新
from langchain.agents import create_agent

両者ともエージェントループの考え方は同じですが、create_agentはミドルウェアと構造化出力を正式にサポートする点が異なります。新規開発ではcreate_agentを選び、既存のcreate_react_agentは段階的に置き換えるのが安全です。

構造化出力｜ProviderStrategyとToolStrategyの使い分け

エージェントの応答を自由文ではなく型付きデータで受け取りたい場合は、response_formatにスキーマを渡します。PydanticモデルをそのままResponse formatに指定すると、モデルの対応状況に応じて戦略が自動選択されます。結果はresult["structured_response"]から型付きで取得できます。

from pydantic import BaseModel, Field
from langchain.agents import create_agent

class ContactInfo(BaseModel):
    name: str = Field(description="氏名")
    email: str = Field(description="メールアドレス")
    phone: str = Field(description="電話番号")

agent = create_agent(
    model="openai:gpt-5.6",
    tools=[],
    response_format=ContactInfo,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "John Doe, [email protected], 03-1234-5678"}]}
)
print(result["structured_response"])
# ContactInfo(name='John Doe', email='[email protected]', phone='03-1234-5678')

戦略を明示したいときは、langchain.agents.structured_outputから2つのクラスを読み込みます。

from langchain.agents.structured_output import ProviderStrategy, ToolStrategy

# プロバイダのネイティブ構造化出力を使う
agent = create_agent(model="openai:gpt-5.6", tools=[], response_format=ProviderStrategy(ContactInfo))

# ツール呼び出しでスキーマを満たす（ネイティブ非対応モデル向け）
agent = create_agent(model="ollama:some-model", tools=[], response_format=ToolStrategy(ContactInfo))

使い分けの基準ははっきりしています。ProviderStrategyはモデル側がネイティブに構造化出力へ対応している場合に使い、対応するのはOpenAI・Anthropic（Claude）・Google（Gemini）・xAI（Grok）などです。ToolStrategyはネイティブ非対応のモデルで、ツール呼び出しの仕組みを使ってスキーマに沿った出力を得ます。素のPydanticモデルを渡した場合は、モデルがネイティブ対応ならProviderStrategy、そうでなければToolStrategyがLangChainによって自動で選ばれるため、通常は戦略を意識せずスキーマだけ渡せば十分です。どのモデルでも動く汎用性を優先するなら明示的にToolStrategyを指定するとよいでしょう。

ミドルウェア｜エージェントの振る舞いを差し込むv1.0の目玉

ミドルウェアは、エージェントループの特定タイミングに処理をフックする仕組みで、v1.0で最も実務に効く追加機能です。会話が長くなったら要約する、機密情報を秘匿する、重要な操作の前に人間の承認を挟む——こうした横断的な処理を、エージェント本体のコードを汚さずに追加できます。

主なプリビルトミドルウェア

よく使うパターンは組み込み済みで、langchain.agents.middlewareから読み込んでmiddleware引数に並べるだけです。

from langchain.agents import create_agent
from langchain.agents.middleware import (
    SummarizationMiddleware,
    HumanInTheLoopMiddleware,
    PIIMiddleware,
)

agent = create_agent(
    model="anthropic:claude-sonnet-5",
    tools=[read_email, send_email],  # @toolで定義済みのツール
    middleware=[
        PIIMiddleware("email", strategy="redact", apply_to_input=True),
        SummarizationMiddleware(
            model="anthropic:claude-sonnet-5",
            trigger=("tokens", 4000),
            keep=("messages", 20),
        ),
        HumanInTheLoopMiddleware(
            interrupt_on={
                "send_email": {"allowed_decisions": ["approve", "edit", "reject"]},
            }
        ),
    ],
)

SummarizationMiddlewareのtriggerは要約を発火させる条件（例：トークン4000超）、keepは要約後に残す量を指定します。旧来のドキュメントにあったmaxTokensBeforeSummaryのようなキャメルケース引数はPython版には存在しないので、混同しないでください。

フックのタイミングとカスタムミドルウェア

ミドルウェアは、モデル呼び出しの前後・ツール実行の前後といったループの各段階にフックできます。組み込みで足りない場合は独自ミドルウェアを定義し、入力の検査や外部システム連携、独自ガードレールを差し込めます。設計指針として、業務ロジック（ツール）と横断処理（要約・秘匿・承認）を分離できるのがミドルウェアの利点です。逆に、単発のツールにしか関係しない処理まで無理にミドルウェア化すると見通しが悪くなるため、複数ツールに共通する関心事だけをミドルウェアへ寄せるのが実装の勘所です。

langchain-classicとlangchain-coreへのパッケージ分割

v1.0ではlangchainパッケージがエージェント構築のコアに絞り込まれ、それ以外は再編されました。読者が検索する「langchain-classic」「langchain-core」は、この分割で生まれた2つのパッケージです。

langchain-classicへ移動した機能とimportの書き換え

v0.xでlangchain本体にあったレガシー機能の多くはlangchain-classicへ移りました。使う場合は追加インストールとインポート先の変更が必要です。

pip install langchain-classic

パッケージ名はハイフン区切りのlangchain-classicですが、Pythonのインポート時はアンダースコアのlangchain_classicになる点に注意してください。エージェントだけを作るならレガシー機能は不要で、langchain-classicを入れずに軽量な構成のまま運用できます。

langchain-coreと標準コンテンツブロック

langchain-coreはメッセージやツールなど土台となる抽象を提供するパッケージで、v1.0で標準コンテンツブロックが加わりました。これはメッセージのcontent_blocksプロパティから、推論経路（reasoning）・引用（citations）・ツール呼び出しといった要素を、プロバイダを問わず同じ型付きインターフェースで取得できる仕組みです。従来はOpenAIとAnthropicで取り出し方が違いましたが、標準コンテンツブロックを使えば、モデルを切り替えても取得コードを書き換えずに済みます。後方互換のため既存のcontent参照はそのまま動き、必要なときだけcontent_blocksを使う設計です。

v0.xからv1.0への移行チェックリスト

移行は一度に全部を書き換えるより、次の順で進めると安全です。

1. pip install -U langchainで本体を更新し、動かなくなったインポートを洗い出す。
2. チェインやRetrieverなどレガシー機能を使っていればlangchain-classicを入れ、インポートをlangchain_classic.*へ変更する。
3. エージェントはcreate_react_agentをcreate_agentへ置き換える。
4. 構造化出力やガードレールを自前実装していた箇所は、response_formatとミドルウェアへ寄せられないか検討する。

一方で、全プロジェクトを急いでv1.0へ上げるべきではありません。安定稼働中でレガシーチェインに深く依存したシステムは、langchain-classicで現状維持しつつ、新規機能だけcreate_agentで書くのが現実的です。移行の目的が「新APIを使うこと」自体になると、動いている資産をわざわざ壊す事故につながります。判断基準は、ミドルウェアや標準コンテンツブロックといったv1.0の新機能を実際に使う予定があるかどうかです。

よくある質問

LangChainの最新バージョンはいくつですか？

v1.0は2025年10月22日に公開され、2026年7月時点の最新はlangchain 1.3系です。langchain-coreは1.4系、langchain-classicは1.0系と、パッケージごとに番号が独立して進みます。正確な番号はpip show langchainかPyPIで確認してください。

create_agentとcreate_react_agentは何が違いますか？

どちらもモデル呼び出しとツール実行のループを作りますが、create_react_agentはv0.x時代のlanggraph.prebuiltのAPIで、v1.0で非推奨になりました。後継のcreate_agent（langchain.agents）はミドルウェアと構造化出力を正式サポートし、新規開発の標準です。

langchain-classicは必ずインストールが必要ですか？

いいえ。create_agentでエージェントを作るだけなら不要です。langchain-classicが必要になるのは、LLMChainなどのレガシーチェイン・Retriever・インデクシングAPI・Hubといったv0.x由来の機能を使う場合だけです。

ProviderStrategyとToolStrategyはどちらを選べばよいですか？

通常はスキーマ（Pydanticモデル）を渡すだけで自動選択されます。OpenAI・Anthropic・Google・xAIなどネイティブ対応モデルはProviderStrategy、それ以外はToolStrategyが使われます。使うモデルを固定せず汎用性を優先するなら、明示的にToolStrategyを指定すると安定します。

LCELはv1.0でも使えますか？

使えます。パイプ演算子で処理をつなぐLCEL（LangChain Expression Language）はv1.0でも廃止されていません。ただしエージェント構築の主役はcreate_agentとLangGraphランタイムに移っており、複雑な制御フローはグラフで書く流れになっています。単純な前処理・整形の連結にはLCELが引き続き有効です。

関連記事

• LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け
• LangGraphのTool Callingとは｜仕組みとToolNodeでの実装・create_agentとの使い分け
• LangGraph Platform（旧 LangGraph Cloud）とは？デプロイ手順・Studio・料金を実践解説【2026年版】
• LangChain.jsとは？その概要と特徴を詳しく解説
• プロンプトキャッシュ（Prompt Caching）とは｜仕組みと主要APIの使い方