---
title: "LangChain v1とは｜最新1.4の変更点とcreate_agent・ProviderStrategy・langchain-classic移行"
url: "https://www.issoh.co.jp/tech/details/9663/"
published: 2025-11-06
updated: 2026-10-31
categories: ["AIエージェント・MCP"]
publisher: "株式会社一創"
---

# 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月】](/tech/details/4059/)で扱っています。

## まとめ：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](https://docs.langchain.com/oss/python/releases/changelog)の日付とは1〜2日ずれることがあります）。

| 版     | PyPI公開日    | 主な追加                               |
| ----- | ---------- | ---------------------------------- |
| 1.0.0 | 2025-10-17 | create\_agent・ミドルウェア・標準コンテンツブロック   |
| 1.1.0 | 2025-11-24 | model profile・ModelRetryMiddleware |
| 1.2.0 | 2025-12-15 | ProviderStrategyのstrict・ツールのextras |
| 1.3.0 | 2026-05-12 | stream\_eventsのversion=”v3″        |
| 1.4.0 | 2026-09-03 | MCP対応を本体に内蔵（langchain.mcp・ベータ）     |
| 1.4.6 | 2026-10-14 | 人間の承認をツール呼び出しごとに止めるper\_call       |
| 1.4.7 | 2026-10-21 | 最新（langchain-core 1.6.13以上が必要）     |

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

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

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

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

```
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に置き換えてください。

| 引数                   | 役割                       |
| -------------------- | ------------------------ |
| model                | チャットモデル（文字列かインスタンス）      |
| tools                | エージェントが呼べるツール            |
| system\_prompt       | 文字列かSystemMessage（1.1以降） |
| middleware           | ループに差し込むミドルウェアの並び        |
| response\_format     | 構造化出力のスキーマか戦略            |
| checkpointer / store | 会話履歴と長期記憶の保存先            |

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

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

`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月】](/tech/details/5428/)を参照してください。

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

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

### 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, john@example.com"}]})
print(result["structured_response"])
# ContactInfo(name='John Doe', email='john@example.com')
```

**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](https://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とは通信しません）。

| モデル                            | profileのstructured\_output | 選ばれる戦略                  |
| ------------------------------ | -------------------------- | ----------------------- |
| gpt-5.6                        | True                       | ProviderStrategy        |
| claude-sonnet-5                | True                       | ProviderStrategy        |
| claude-haiku-4-5               | True                       | ProviderStrategy        |
| gpt-4o-mini（profileをFalseに上書き） | False                      | ProviderStrategy（名前リスト） |
| 独自のOpenAI互換モデル                 | なし                         | ToolStrategy            |

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='j@x.com')`が得られました。再生成のたびにモデル呼び出しが1回増えるので、項目の多いスキーマでは`Field(description=...)`で各項目の意味を書いておくと失敗が減ります。挙動の詳細は[公式のStructured outputページ](https://docs.langchain.com/oss/python/langchain/structured-output)にあります。

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

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

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

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

| クラス                            | 用途                     |
| ------------------------------ | ---------------------- |
| SummarizationMiddleware        | 履歴が閾値を超えたら要約           |
| HumanInTheLoopMiddleware       | 指定ツールの実行前に承認を求める       |
| PIIMiddleware                  | メール・カード番号などを秘匿         |
| ModelRetryMiddleware           | モデル呼び出しの失敗を再試行         |
| ModelFallbackMiddleware        | 失敗時に別モデルへ切り替え          |
| ModelCallLimitMiddleware       | モデル呼び出し回数の上限           |
| ToolCallLimitMiddleware        | ツール呼び出し回数の上限           |
| ToolRetryMiddleware            | ツールの失敗を再試行             |
| ToolErrorMiddleware            | ツールの例外を処理              |
| LLMToolSelectorMiddleware      | モデルに渡すツールを事前に絞る        |
| ProviderToolSearchMiddleware   | プロバイダ側のツール検索           |
| ContextEditingMiddleware       | 古いツール結果を履歴から消す         |
| TodoListMiddleware             | 計画用のwrite\_todosツールを足す |
| LLMToolEmulator                | ツールの応答をLLMで模擬          |
| FilesystemFileSearchMiddleware | ファイル検索ツールを足す           |
| ShellToolMiddleware            | シェル実行ツールを足す            |

要約・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": "a@example.comに送って"}]}, 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との違い・承認の実装と導入判断](/tech/details/11415/)で扱っています。

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

カスタムミドルウェアのフックは`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`になりました。

| 機能        | v0.xのimport               | v1のimport                          |
| --------- | ------------------------- | ---------------------------------- |
| チェイン      | langchain.chains          | langchain\_classic.chains          |
| Retriever | langchain.retrievers      | langchain\_classic.retrievers      |
| インデクシング   | langchain.indexes         | langchain\_classic.indexes         |
| hub       | from langchain import hub | from langchain\_classic import hub |

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

### 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で動かしたときに、エラーや警告になった箇所をまとめます。

| v0.xの書き方                       | 1.4.7での結果                      | 直し方                       |
| ------------------------------ | ------------------------------ | ------------------------- |
| create\_react\_agent           | LangGraphDeprecatedSinceV10の警告 | create\_agentへ            |
| prompt=”…”                     | TypeError                      | system\_prompt=”…”        |
| response\_format=(指示, スキーマ)    | ValueError                     | スキーマか戦略を渡す                |
| pre\_model\_hook=…             | TypeError                      | ミドルウェアへ                   |
| from langchain.chains import … | ModuleNotFoundError            | langchain\_classic.chains |
| ストリームのノード名”agent”              | “model”に改名                     | 判定する文字列を変更                |
| message.text()                 | 非推奨の警告                         | message.text              |

`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エージェント開発](/service/ai/agent/)の支援内容をご覧ください。

## よくある質問

### 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のページ](https://pypi.org/project/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月】](/tech/details/4059/)
- [LangGraphのTool Calling実装｜ToolNode・create\_agent・エラー処理とループ上限【2026年10月】](/tech/details/5428/)
- [LangChainでRAGを構築する手順｜v1.4系の2-Step・エージェント方式とPGVectorStore移行](/tech/details/2332/)
- [LangChain.jsとは？npm導入からcreateAgent・構造化出力・会話メモリまで【v1.5対応】](/tech/details/3590/)
- [LangGraph Platform（旧LangGraph Cloud）とは？現LangSmith Deploymentのデプロイ手順と料金【2026年10月】](/tech/details/6175/)

---

出典: [LangChain v1とは｜最新1.4の変更点とcreate\_agent・ProviderStrategy・langchain-classic移行](<https://www.issoh.co.jp/tech/details/9663/>)（株式会社一創）