LangChain v1とは｜最新1.4の変更点とcreate_agent・ProviderStrategy・langchain-classic移行

LangChain v1は、エージェント構築をcreate_agentに一本化したLangChainのメジャー版です。2026年10月時点の最新はlangchain 1.4.7で、1.x系の公開APIは互換性を保つ方針で機能が足されてきました（例外は後述）。本記事では、Pythonでlangchain 1.4.7・langchain-core 1.7.3・langgraph 1.2.19を入れ、フェイクモデルでAPIキーなしに動かした結果をもとに、版ごとの変更点、create_agentの使い方、構造化出力でProviderStrategyとToolStrategyのどちらが選ばれるかの条件、langchain-classicへの移行で実際に落ちる箇所を説明します。LangGraphとの関係はLangChainとLangGraphの違いと使い分け｜v1.0以降の関係をコードで確認【2026年10月】で扱っています。

まとめ：LangChain v1（最新1.4.7）の要点

• 最新バージョン：langchain 1.4.7（PyPI公開は2026年10月21日）。langchain-coreは1.7.3、langchain-classicは1.0.8で、番号はパッケージごとに独立しています。Python 3.10以上が必要です。
• create_agent：from langchain.agents import create_agentで読み込みます。langgraph.prebuilt.create_react_agentの後継で、戻り値はLangGraphのグラフです。
• 構造化出力：Pydanticモデルをresponse_formatに渡すと、モデルのprofileがstructured_output: Trueか、モデル名が組み込みのリストに一致すればProviderStrategy、どちらでもなければToolStrategyが選ばれます（Gemini 3未満をツールと併用する場合は除外）。
• ミドルウェア：組み込みは16種。要約・PII秘匿・人間の承認・リトライなどをmiddleware=[...]に並べます。
• 移行：チェイン・Retriever・hubはlangchain-classicへ移りました。prompt=はsystem_prompt=に改名され、旧名のままだとTypeErrorになります。

LangChainの最新バージョンとv1のリリース履歴

v1系の最新はlangchain 1.4.7です。1.0.0から1.4.7までに59本の正式版がPyPIに出ています。主なマイナー版で増えた機能は次のとおりです（日付はPyPIへの公開日。公式changelogの日付とは1〜2日ずれることがあります）。

1.x系の中では、langchainとlangchain-coreの公開APIを壊す変更はしない方針です。破壊的変更は2.0のようなメジャー版に限られ、1.0は2.0が出るまで積極的に保守され、2.0の公開後も少なくとも1年はセキュリティ修正と重大なバグ修正が続きます（公式のバージョニング方針）。例外もあり、langchain-core 1.6.13ではストリーミング中にmessage.tool_callsを反復したときの中身が「その時点までの引数全体」から「新しく届いた差分」に変わり、公式changelogはこれをBreaking changesとして載せています。

1.0の公開日は資料によって3つあります。PyPIへの1.0.0の登録が2025年10月17日、公式changelogの記載が10月20日、告知ブログの公開が10月22日です。記事や社内資料で日付を書くときは、どれを指すかを添えると食い違いを避けられます。

1.4.0で入ったlangchain.mcpは、別パッケージだったlangchain-mcp-adaptersの置き換えで、pip install "langchain[mcp]"で入ります。読み込むとLangChainBetaWarningが出るベータ扱いです。MCPそのものはMCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方で解説しています。

バージョンの確認とインストール

pip install -U langchain "langchain[openai]"
python -c "import langchain, langchain_core; print(langchain.__version__, langchain_core.__version__)"
# 1.4.7 1.7.3

v1のパッケージはすべてPython 3.10以上を要求します。macOS標準のPython 3.9でpip install langchainを実行すると1.x系が候補から外れ、古い0.x系が入るので、先にpython --versionを確かめてください。

langchain-core 1.7.0（2026年10月22日公開）では、イベントストリーミングでツール呼び出しの引数が差分のtool-call-deltaイベントで届くようになりました。公式changelogは、ストリームを読むクライアント側のlangchain-coreを1.6.13以上に上げてから、サーバー側を上げる順序を指示しています。

create_agentによるエージェント作成の手順

create_agentは、モデル・ツール・システムプロンプトを受け取り、モデル呼び出しとツール実行を繰り返すエージェントを返す関数です。

基本コードと主要な引数

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"形式の文字列か、生成済みのチャットモデルを渡します。文字列は内部でinit_chat_modelに通され、"openai:gpt-5.6"ならChatOpenAIになります。実行には環境変数OPENAI_API_KEYが必要です。本記事の実行結果は、このモデルをフェイクモデル（GenericFakeChatModel）に差し替えてAPIを呼ばずに取ったものです。モデルIDは執筆時点のものなので、各社の最新IDに置き換えてください。

引数名はスネークケースです。JavaScript版のcreateAgentはsystemPrompt・responseFormatとキャメルケースなので、両方を書くチームは取り違えに注意してください。JavaScript版はLangChain.jsとは？npm導入からcreateAgent・構造化出力・会話メモリまで【v1.5対応】にまとめています。

エージェントループの中身

create_agentの戻り値はlanggraph.graph.state.CompiledStateGraphで、ノードはmodelとtoolsの2つです。上のコードをフェイクモデルで実行すると、result["messages"]はHumanMessage→AIMessage（tool_callsあり）→ToolMessage→AIMessageの順に並びました。

戻り値がLangGraphのグラフなので、stream・チェックポイント・interruptなどLangGraphの機能がそのまま使えます。ツール実行の制御を細かく書きたい場合はLangGraphのTool Calling実装｜ToolNode・create_agent・エラー処理とループ上限【2026年10月】を参照してください。

構造化出力：ProviderStrategyとToolStrategyの選び方

エージェントの最終結果を型付きデータで受け取るには、response_formatにスキーマを渡します。結果はresult["structured_response"]に入ります。v0.xのように別ノードで整形し直すのではなく、メインのループの中で生成されるため、そのぶんモデル呼び出しが減ります（公式の移行ガイド）。

response_formatの渡し方

from pydantic import BaseModel, Field
from langchain.agents import create_agent
from langchain.agents.structured_output import ProviderStrategy, ToolStrategy

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

# 1. スキーマをそのまま渡す（戦略は自動選択）
agent = create_agent(model="openai:gpt-5.6", tools=[], response_format=ContactInfo)

# 2. プロバイダのネイティブ機能を明示（strictは1.2以降）
agent = create_agent(model="openai:gpt-5.6", tools=[],
                     response_format=ProviderStrategy(ContactInfo, strict=True))

# 3. ツール呼び出しで構造化（ツール呼び出しに対応したモデルなら使える）
#    事前に pip install "langchain[ollama]" と ollama pull qwen3、Ollamaの起動が必要
agent = create_agent(model="ollama:qwen3", tools=[],
                     response_format=ToolStrategy(ContactInfo))

# 実行するのは最後に作った3のagent
result = agent.invoke({"messages": [{"role": "user", "content": "John Doe, [email protected]"}]})
print(result["structured_response"])
# ContactInfo(name='John Doe', email='[email protected]')

ProviderStrategyは、OpenAIのJSONスキーマ指定のようにモデル側の構造化出力機能を使います。ToolStrategyはスキーマを1本のツールに変換し、モデルにそのツールを呼ばせて引数を結果として取り出します。ToolStrategyで終わった場合、メッセージの末尾にはReturning structured response: ...というToolMessageが付きます。v0.xにあった("指示文", スキーマ)のタプル形式は廃止され、渡すとValueError: Unsupported schema typeになります。

自動選択の判定条件：model profileとモデル名リスト

公式のStructured outputページは、1.1以降は対応可否をモデルのprofileから読むこと、profileを自分で指定できること、ツールを渡すならツールと構造化出力の同時利用に対応している必要があることを説明しています。langchain 1.4.7のlangchain/agents/factory.pyを読むと、実際の判定は次の順です。

1. モデルの.profile["structured_output"]がTrueならProviderStrategy。profileは1.1.0で追加され、models.devのデータから作られます。
2. ただしモデル名にgeminiを含み、gemini-3を含まず、ツールも渡している場合は除外します（Gemini 3未満はツールと構造化出力を同時に使えないため）。
3. 1でProviderStrategyにならなければ、profileが無い場合もFalseの場合も、gpt-4o・gpt-5系・claude-sonnet-4-5などを並べたモデル名の正規表現リストに一致するかで決めます。
4. どれにも当たらなければToolStrategyです。

langchain-openai 1.7.3とlangchain-anthropic 1.7.7でChatOpenAI・ChatAnthropicを生成し、判定関数を直接呼んだ結果です（APIとは通信しません）。

gpt-4o-miniのようにprofileをFalseにしても、モデル名がリストに一致すればProviderStrategyになります。逆に、自社でホストしたOpenAI互換モデルのようにprofileもリストも当たらないモデルはToolStrategyになります。そのモデルが構造化出力に対応していると分かっている場合は、profileを渡して判定に使わせます。profileは能力の情報を補うもので、モデルが持たない機能を使えるようにするものではありません。

from langchain.chat_models import init_chat_model

model = init_chat_model("openai:gpt-5.6")
print(model.profile.get("structured_output"))  # True

# profileが無いモデルに能力情報を与える
model = init_chat_model(
    "openai:my-company-llm",
    base_url="http://localhost:8000/v1",
    profile={"structured_output": True, "max_input_tokens": 128000},
)
print(model.profile)  # {'max_input_tokens': 128000, 'structured_output': True}

profileを渡すと、元のprofileとは合成されず渡した辞書だけになります（gpt-5.6に{"structured_output": True}だけを渡すとmax_input_tokensなども消えました）。SummarizationMiddlewareを("fraction", 0.8)のように割合で動かす場合は入力上限の値が要るので、必要なキーを一緒に書いてください。結果の取り出し先はどちらの戦略でもresult["structured_response"]で同じです。差し替え候補のモデルがすべてツール呼び出しに対応しているなら、ToolStrategyを明示すると、モデルを替えても構造化の方式そのものが変わりません。

ToolStrategyのスキーマ違反と再生成

ToolStrategyは、モデルが返した引数がスキーマに合わないとき、検証エラーをToolMessageでモデルへ返して作り直させます（handle_errors=Trueが既定）。必須のemailを欠いた応答を1回目に返すフェイクモデルで試すと、1つ目のToolMessageにError: Failed to parse structured output for tool 'ContactInfo': ... email Field requiredが入り、2回目の応答からContactInfo(name='John', email='[email protected]')が得られました。再生成のたびにモデル呼び出しが1回増えるので、項目の多いスキーマではField(description=...)で各項目の意味を書いておくと失敗が減ります。挙動の詳細は公式のStructured outputページにあります。

ミドルウェアによる要約・承認・PII秘匿の実装

ミドルウェアは、エージェントループの決まったタイミングに処理を挟む仕組みです。v0.xのpre_model_hook・post_model_hookは、v1ではミドルウェアに置き換わりました。

組み込みミドルウェアの一覧

langchain.agents.middlewareが公開する組み込みは、1.4.7で次の16種です。

要約・PII秘匿・承認を組み合わせた構成例です。pip install "langchain[anthropic]"と環境変数ANTHROPIC_API_KEY、@toolで定義したread_email・send_emailを前提にしています。承認で止めた実行を再開するには、中断時の状態を保存するcheckpointerと、初回と再開で同じthread_idが要ります。

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.types import Command
from langchain.agents.middleware import (
    HumanInTheLoopMiddleware,
    PIIMiddleware,
    SummarizationMiddleware,
)

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"]},
            },
            interrupt_mode="per_call",  # 1.4.6以降
        ),
    ],
    checkpointer=InMemorySaver(),  # 検証用。本番は永続化できるcheckpointerを使う
)

config = {"configurable": {"thread_id": "1"}}
result = agent.invoke({"messages": [{"role": "user", "content": "[email protected]に送って"}]}, config)
interrupt = result["__interrupt__"][0]  # send_emailの承認待ち
agent.invoke(Command(resume={interrupt.id: {"type": "approve"}}), config)

checkpointerを付けずにCommand(resume=...)で再開しようとすると、RuntimeError: Cannot use Command(resume=...) without checkpointerで止まります。フェイクモデルで同じ構成を動かすと、checkpointerありではsend_emailの承認待ちで中断し、承認後にToolMessage→最終応答まで進みました。

SummarizationMiddlewareのtriggerは要約を始める条件で、("tokens", 4000)・("messages", 50)・("fraction", 0.8)のいずれか（またはその並び）を取ります。keepは要約後に残す量です。JavaScript版の古い資料にあるmaxTokensBeforeSummaryのような引数はPython版にありません。

HumanInTheLoopMiddlewareのper_callモード

1.4.6でinterrupt_mode="per_call"が加わりました。既定の"batched"は、1回の応答に含まれる複数のツール呼び出しをまとめて1回の中断で承認させます。"per_call"は呼び出しごとに中断を起こし、中断IDを指定して答えます。各中断には、その呼び出しで選べる決定を並べたresponse_schemaが付き、editで別のツールへ差し替えることはできません。公式changelogは新規のエージェントにはper_callを使うよう勧めており、次のメジャー版で既定にする予定としています。承認フローの設計そのものはヒューマンインザループ（HITL）とは？意味・HOTLとの違い・承認の実装と導入判断で扱っています。

フックの位置とカスタムミドルウェア

カスタムミドルウェアのフックはbefore_agent・before_model・wrap_model_call・wrap_tool_call・after_model・after_agentの6つです。@before_modelのようなデコレータで関数1つから作れます。上のエージェントのグラフを出力すると、PIIMiddleware[email].before_model・SummarizationMiddleware.before_model・HumanInTheLoopMiddleware.after_modelがそれぞれノードとして加わっていました。

ミドルウェアに寄せるのは、要約・秘匿・承認・回数制限のように複数のツールにまたがる処理です。特定のツールだけに関係する入力チェックはツールの中に書いた方が、読む人が処理の場所を探さずに済みます。

langchain-classicとlangchain-coreの役割

v1でlangchainパッケージはエージェント構築の部品に絞られ、それ以外はlangchain-classicへ移りました。土台の抽象（メッセージ・ツール・Runnable）は以前からlangchain-coreにあり、v1でもそのままです。

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

公式の移行ガイドが挙げる移動先は、レガシーチェイン（LLMChain・ConversationChainなど）、Retriever、インデクシングAPI、hub、CacheBackedEmbeddingsなどのEmbeddings、langchain-communityの再エクスポートです。1.4.7で旧パスを読み込むと、langchain.chains・langchain.retrievers・langchain.hubはいずれもModuleNotFoundErrorになりました。

パッケージ名はハイフンのlangchain-classic、import名はアンダースコアのlangchain_classicです。最新のlangchain-classicは2026年6月10日公開の1.0.8で、本体（1.4系）とは番号が揃っていません。RAGでclassicのチェインを使わずに書く方法はLangChainでRAGを構築する手順｜v1.4系の2-Step・エージェント方式とPGVectorStore移行で紹介しています。

langchain_classic.indexesがImportErrorになる場合

Python 3.12の新しい仮想環境にlangchainとlangchain-classicを入れ、import langchain_classic.indexesを実行すると、ImportError: The SQLAlchemy asyncio module requires that the Python 'greenlet' library is installed.で止まりました。入っていたSQLAlchemy 2.1.6は、greenletをasyncioのextraでしか依存に入れていません。pip install greenlet（または"sqlalchemy[asyncio]"）を足すと読み込めます。同じ環境でlangchain_classic.chainsとhubは追加なしで読み込めました。この環境で確かめた範囲では、indexesの読み込みで起きる問題です。

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

langchain-core 1.0で、メッセージにcontent_blocksプロパティが加わりました。推論過程（reasoning）・テキスト・引用・ツール呼び出しを、プロバイダを問わず同じ形の辞書の並びで取り出せます。

from langchain_core.messages import AIMessage

msg = AIMessage(content=[{"type": "reasoning", "reasoning": "考え中"}, {"type": "text", "text": "答え"}])
print(msg.content_blocks)
# [{'type': 'reasoning', 'reasoning': '考え中'}, {'type': 'text', 'text': '答え'}]
print(msg.text)  # 答え

既存のcontentはそのまま使えます。テキストを取り出す.text()はプロパティの.textに変わり、メソッドとして呼ぶとLangChainDeprecationWarningが出ます（v2で削除予定）。

create_react_agentからの移行で落ちる箇所

v0.xのコードを1.4.7で動かしたときに、エラーや警告になった箇所をまとめます。

create_react_agentの警告文は「Deprecated in LangGraph V1.0 to be removed in V2.0」で、今すぐ動かなくなるわけではありません。掲載例で変えるのは、import元、関数名、引数名（prompt→system_prompt）の3点です。

# v0.x
from langgraph.prebuilt import create_react_agent
agent = create_react_agent(model, tools, prompt="あなたは…")

# v1
from langchain.agents import create_agent
agent = create_agent(model, tools, system_prompt="あなたは…")

このほか、langchain-anthropicのmax_tokensの既定値が1024からモデルごとの大きな値に変わり、langchain-openaiはResponses APIの応答項目をcontentに入れるのが既定になりました。以前の出力形式に依存した処理があるなら、max_tokens=1024やoutput_version="v0"を明示します。

v1へ移行すべきか判断する基準

新規開発はcreate_agentで書くべきです。

一方、LLMChainやRetrievalQAで組んだ既存システムを急いで書き直す必要はありません。まずlangchain-classicを入れてimportを変え、そのうえでPython 3.10以上への更新、モデルの既定値の変化、削除されたAPIを確かめていけば、作り直さずに1.x系へ載せ替えられます。ただし0.x系に留まる場合は期限があり、LangChain 0.3とLangGraph 0.4のセキュリティ修正は2026年12月までです（公式のバージョニング方針）。年明け以降も0.3で運用する予定なら、classic経由で1.x系へ上げておくのが現実的です。書き直す価値があるのは、承認・要約・回数制限を自前で実装していて、それをミドルウェアに置き換えると保守の手間が減る場合です。逆に、Python 3.9から上げられない環境、langchain-community由来の部品に深く依存して検証の手間が大きい環境では、今すぐ移行しないことを選んでよいでしょう。LangChainでエージェントを業務システムに組み込む設計から相談したい場合は、AIエージェント開発の支援内容をご覧ください。

よくある質問

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

2026年10月31日時点ではlangchain 1.4.7（2026年10月21日公開）です。langchain-coreは1.7.3、langchain-classicは1.0.8、langgraphは1.2.19と、番号はパッケージごとに独立しています。手元の版はpip show langchainで、最新はPyPIのlangchainのページで確認できます。

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

create_react_agentはlanggraph.prebuiltの旧APIで、LangGraph 1.0から非推奨です。後継のcreate_agentはミドルウェアと構造化出力の戦略指定に対応し、prompt引数はsystem_promptに改名されています。

create_agentはLangGraphの機能ですか？

create_agentはlangchainパッケージ（langchain.agents）の関数です。ただし内部はLangGraphで動き、戻り値はLangGraphのCompiledStateGraphです。langchain 1.4.7はlanggraph>=1.2.12,<1.3.0に依存しているので、pip install langchainでLangGraphも入ります。

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

いいえ。create_agentでエージェントを作るだけなら不要です。LLMChainなどのレガシーチェイン、Retriever、インデクシングAPI、hubを使う場合にだけ入れます。インデクシングAPIを読み込んでgreenletが無いというImportErrorが出た場合は（SQLAlchemy 2.1.6で確認）、pip install greenletを足してください。

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

スキーマをそのまま渡せば、profileかモデル名リストで対応と判定されたモデルはProviderStrategyになります。ただしGemini 3未満のモデルにツールも渡す場合はToolStrategyです。複数のモデルを差し替えて使い、どれもツール呼び出しに対応しているなら、ToolStrategyを明示すると構造化の方式が揃います。

関連記事

• LangChainとLangGraphの違いと使い分け｜v1.0以降の関係をコードで確認【2026年10月】
• LangGraphのTool Calling実装｜ToolNode・create_agent・エラー処理とループ上限【2026年10月】
• LangChainでRAGを構築する手順｜v1.4系の2-Step・エージェント方式とPGVectorStore移行
• LangChain.jsとは？npm導入からcreateAgent・構造化出力・会話メモリまで【v1.5対応】
• LangGraph Platform（旧LangGraph Cloud）とは？現LangSmith Deploymentのデプロイ手順と料金【2026年10月】