2026年のLangChain v1:エージェント構築の新しい基盤(RedditとXでの評判)

Surya Pratap
By Surya Pratap

2026年4月20日

10 min read

AI & Technology
LangGraphとLangSmithを組み合わせたLangChain v1のエージェント基盤LangChain v1Hover to explore
一つのエージェント抽象化、ミドルウェアの層、そしてグラフのランタイム。LangChainはようやく自らの形を決めました。

2023年から2024年の大半、r/LangChain、r/LocalLLaMA、X/TwitterでのLangChainに対する最も大きな声は、どれも同じように聞こえました。「デモには最高、本番ではつらい」。ラッパーの上にラッパーを重ね、本物のループが必要になった途端に破綻する抽象化があり、ロードマップは毎週火曜日に新しいチェーンを出しているように見えました。**LangChain v1(2025年末から安定版)**で、その状況は変わりました。フレームワークはいまや公然とエージェントの形をしています。高レベルの入り口であるcreate_agentが一つ、ミドルウェアの仕組み、そして内部の標準ランタイムとしてのLangGraphです。

本記事の情報源には、公式のLangChain v1の発表、LangChainのエージェントのドキュメント、r/LangChainとr/LocalLLaMAで繰り返されている議論、そしてXでの@LangChainAIと@hwchase17のスレッドが含まれます。都合のよい引用より、全体の傾向を重視しています。

1. LangChain v1で実際に何が変わったのか

最大の変化は、LangChainがもはやチェーンの寄せ集めではないことです。トップレベルのパッケージは、いまや3つの要素を中心にしています。

  • create_agent:モデル、ツール、システムプロンプト、構造化出力、ミドルウェアを指定して、ツールを使うエージェントを作るための単一の関数。
  • ミドルウェア:モデルの呼び出しとツールの呼び出しの前後に入るフック(レート制限、個人情報のマスキング、人間による承認、リトライ、要約、ガードレール)。
  • LangGraphのランタイム:すべてのエージェントの下に、チェックポイントで保存される永続的なステートがあります。そのため、一時停止と再開、人間による承認、タイムトラベルデバッグが、後付けではなく最初から組み込まれています。

古い部品(LLMChain、AgentExecutor、initialize_agent、旧形式のcreate_react_agent)はまだインポートできますが、レガシー扱いです。新しいコードはlangchain.agentsとlangchain.messagesに置き、プロバイダーとの統合はlangchain-openaiやlangchain-anthropicなどのパッケージを使うことが想定されています。

2. 最小構成のv1エージェント(新しい「hello world」)

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

@tool
def get_weather(city: str) -> str:
    """Return the current weather for a given city."""
    return f"It's 24C and sunny in {city}."

agent = create_agent(
    model="anthropic:claude-sonnet-4-5",   # or "openai:gpt-5", "google:gemini-2.5-pro"
    tools=[get_weather],
    system_prompt="You are a concise travel assistant.",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "Weather in Lisbon?"}]}
)
print(result["messages"][-1].content)

注目すべき点は3つあります。モデルは文字列で指定する(どのプロバイダーかはLangChainが解決する)、ツールは@toolでデコレートした普通のPython関数である、そして明示的なReActプロンプトもパーサーもない、という点です。エージェントのループ、ツール呼び出しのプロトコル、メッセージのリデューサーは、すべてランタイムの中にあります。

3. 2回目のLLM呼び出しなしの構造化出力

r/LangChainで最も支持されているv1の機能の一つがresponse_formatです。Pydanticのモデルを渡せば、エージェントは同じループの中で検証済みのオブジェクトを返します。追加のパーサーも、「では、これをJSONで抽出して」という追加の呼び出しも要りません。

from pydantic import BaseModel
from langchain.agents import create_agent

class TripPlan(BaseModel):
    city: str
    days: int
    must_do: list[str]

agent = create_agent(
    model="openai:gpt-5",
    tools=[get_weather],
    response_format=TripPlan,
)

out = agent.invoke({"messages": [
    {"role": "user", "content": "Plan 3 days in Lisbon."}
]})

plan: TripPlan = out["structured_response"]
print(plan.must_do)

4. ミドルウェア:Xの開発者がひそかに期待している部分

ミドルウェアによって、v1はラッパーに見えなくなり、本物のエージェントフレームワークに見えてきます。before_model、after_model、before_tool、after_toolにフックを掛けられ、次のような再利用可能な振る舞いを組み込めます。

  • SummarizationMiddleware:コンテキストが大きくなったら、長い履歴を自動で圧縮します。
  • HumanInTheLoopMiddleware:破壊的なツール呼び出しの前に一時停止し、承認、編集、却下を待ちます。
  • PIIMiddleware:メールアドレス、名前、カード番号を、プロバイダーに届く前にマスクします。
  • ModelFallbackMiddleware:メインのモデルが失敗したら、より安いモデルや予備のモデルで自動的にやり直します。
from langchain.agents import create_agent
from langchain.agents.middleware import (
    HumanInTheLoopMiddleware,
    SummarizationMiddleware,
    PIIMiddleware,
)

agent = create_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[refund_order, send_email, query_db],
    middleware=[
        PIIMiddleware(strategy="redact"),
        SummarizationMiddleware(max_tokens_before_summary=12_000),
        HumanInTheLoopMiddleware(
            interrupt_on={"refund_order": True, "send_email": True}
        ),
    ],
)

私たち自身のクライアントワークでも、最近のXのスレッドでも、LangChainがようやく本番に出せると感じられるようになったのは、この部分のおかげです。厄介な本番の課題を、プロンプトのレベルで継ぎはぎするのではなく、組み合わせて扱えるようになりました。

複数ステップのエージェントのためのLangGraphの状態グラフ標準でステートを持つHover to explore
すべてのv1エージェントの下にはLangGraphのグラフがあります。だからこそ、一時停止、再開、人間による承認が後回しにならないのです。

5. マルチエージェント:スーパーバイザー、スウォーム、あるいは単なるサブグラフ

マルチエージェント構成では、LangChainはLangGraphと、Redditで繰り返し話題に上る2つの既製コンポーネントに頼ります。

  • langgraph-supervisor:ルーター役のエージェントが、次のステップをどの専門エージェント(調査、コーディング、サポート)に任せるかを決めます。役割分担が明確な場合に最適です。
  • langgraph-swarm:対等なエージェントが、コンテキストに応じて互いに作業を引き継ぎます。CrewAIやAutoGenのグループチャットに近い感覚です。
  • 独自のサブグラフ:エッジとステートの形を完全に制御したいなら、create_agentの出力をStateGraphに組み合わせるだけです。

6. RedditとXで実際に語られていること(率直なまとめ)

ここ数か月のr/LangChain、r/LocalLLaMA、そしてXのAIエンジニアリング界隈で、繰り返し出てくるテーマは次のとおりです。

  • 肯定的: 「create_agentは2年前にこうあるべきだった姿だ。」最も多く挙がる利点はミドルウェアと構造化出力です。LangSmithのトレースは、面倒な手順なしに「とにかく動く」。
  • 賛否両論: パッケージの分割(langchain、langchain-core、langgraph、各プロバイダーのパッケージ)は、いまも新しく来た人をつまずかせます。0.x系のコードからの移行は「ほとんど機械的だが、ときどき外科手術が必要」です。
  • 批判的: 完全にオープンウェイトのモデルに移行するチームや、レイテンシーに極めて敏感なチームは、いまも手書きのループ、Pydantic AI、プロバイダーのSDKを好みます。論点はもはや「LangChainは肥大化している」ではなく、「3ステップのパイプラインにグラフは要らない」です。もっともな話です。
  • 比較: CrewAIと比べると、LangChainは耐久性、可観測性、ツール呼び出しの厳密さで勝り、CrewAIは役割とタスクの扱いやすさで勝ります。AutoGenと比べると、LangChainは本番向けの基本機能で勝り、AutoGenは自由形式のマルチエージェントの会話で勝ります。OpenAI Agents SDKと比べると、LangChainはプロバイダー間の移植性とミドルウェア/人間による承認で勝り、OpenAIのSDKは一つのプロバイダーに全面的に乗るなら最初のデモまでの速さで勝ります。

「2026年に面白い問いは、もはや『どのフレームワークか』ではない。同じエージェントを3つのプロバイダーで、人間による承認付きで、すべての失敗にトレースを残して出荷できるのはどれか、だ。」

7. 採用を決める前の創業者向けチェックリスト

  1. 自分のエージェントを、動詞と結果を含む一文で説明できますか(「返金を処理し、顧客にメールを送る」)?できないなら、いったん止まって、まず範囲を絞ってください。
  2. 最小限の部品を選ぶ:create_agent + ツール2〜5個 + response_format。初日はミドルウェアを使わなくて構いません。
  3. 最初のコミットからLangSmithを有効にする。後で行う最適化(コスト、レイテンシー、評価)は、すべて手元にあるトレースから始まります。
  4. ツールがお金を使う、メッセージを送る、データベースの行を変更する、のいずれかができるようになった瞬間に、HumanInTheLoopMiddlewareを追加する。本番のエージェントで、最も効果の大きい1行です。
  5. スーパーバイザーやスウォームに手を伸ばすのは、単一エージェントの版がしっかり動いた後にする。「マルチエージェント」の問題の多くは、実際にはツールの範囲の決め方がまずいという問題です。

まとめ

LangChain v1は、フレームワークの形が、チームが本番で実際にエージェントを作るやり方と一致した最初のバージョンです。下にグラフを持つツール利用のループ、地味な課題(個人情報、承認、要約、リトライ)のためのフック、そしてどのプロバイダーでも同じコードの流れ。RedditとXでの議論は、「LangChainはネタなのか」から「そのエージェントは観測でき、復旧でき、移植できるか」へと移りました。2026年にMVPを出す創業者にとって、こちらのほうがずっと有意義な議論です。

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :