LangChainとは？「止めて、承認して、再開する」で読むLangGraph・LangSmith・Deep Agents

エージェントのデモは、早ければ1日で動きます。むずかしいのはその先です。承認が要る操作の手前で処理を止め、人間が確認し、同じ状態から続きを再開する。この要求がいつ生まれ、LangChain・LangGraph・LangSmith・Deep Agents のどの層がその面倒を引き受けるのかは、実際に手を動かすまで見えてきません。

この記事はその一点だけを軸に、現行の公式 docs を読み直します。人気やスター数の話は脇に置き、「止めて、承認して、同じ状態から再開する」必要が生まれた瞬間にどの層が何を肩代わりするかで、4つのレイヤーを切り分けます。

この記事を書いている理由も先に書いておきます。LangChain は v1 で create_agent へ入口が集約され、legacy 機能の namespace 整理も入りました。今は手元の古いサンプルコードと現行 docs との距離が、ここ数年でいちばん開いているタイミングだと見ています。この読み直しの姿勢は、以前書いたAIエージェント開発に役立つ一次文献11選で立てた「二次解説は言い切りごと陳腐化するから、残る設計語彙を一次情報で読む」という立場の延長です。

この見立ては思いつきで言っているわけではありません。以前 Swarm を扱った記事では、機能一覧や framework の人気ではなく、README のサンプルを「どこで責任（承認者・正データ・実行できる操作・失敗時の担当）が変わるか」という一つの軸で読み直しました。一次文献11選でも、二次解説は「その時点でうまくいった設定」を要約するために前提条件を省きがちで、その省略が実装や前提モデルの変わった瞬間に事故の種になり得ると書いています。LangChain も、v1 で create_agent に入口が集約されたばかりの今読むなら、同じ理由で「人気か複雑か」ではなく、公式 docs が LangChain・LangGraph・LangSmith・Deep Agents にどう責務を割っているかを軸に読み直す方が、次のリリースが来ても崩れにくい読み方になる、と考えています。

ただし断っておきます。私自身に、LangGraph を数か月規模の本番運用に載せた一次経験はまだありません。ここから先は、公式 docs とサンプルコードの読解として読んでください。実機での追試はまだできていません。

前提: 4つの層の定義

現行 docs は、LangChain を agent を素早く組み始めるための framework、LangGraph を長時間・状態付きの orchestration runtime、LangSmith を observability と eval、Deep Agents をそれらを束ねた配線済みの harness として整理しています。また、現行 docs は、まず Deep Agents、より細かく組みたいなら LangChain、さらに低レイヤー制御が必要なら LangGraph という順で読むことを勧めています。以降、この記事では次の呼び方で通します。

LangChainエコシステム

この記事では以降、再開境界という言葉を使います。同じ thread_id の checkpoint から処理を続けられる範囲、つまり承認・障害・長時間実行をまたいでどこまで状態を保てるかの単位を指します。この境界が要るかどうかが、LangChain 単体で足りるか、LangGraph まで踏み込むべきかを分ける、いちばん太い線です。

なお、4層を全部同時に採用する必要はありません。PoC なら LangChain だけで始めてもよいですし、すでに独自の runtime を持っているなら LangSmith だけで observability を足す選択もあります。

LangChain 層: create_agent と middleware

LangChain overview は、LangChain を prebuilt agent architecture と integrations for any model or tool を備えた open source framework と説明しています。最初の価値は、複雑な graph を自作する前に、tool-calling agent を短いコードで組めることです。

現行 docs の最小例は次の形です。

from langchain.agents import create_agent


def get_weather(city: str) -> str:
    return f"It's always sunny in {city}!"


agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

このレイヤーで実務上効くのは、派手な benchmark の数字ではありません。次の4点です。

1. model をどう差し替えるか
2. tool をどの責務単位で許可するか
3. messages と short-term memory をどう扱うか
4. middleware でどこまで制御を差し込むか

middleware が実務での入口になる

middleware docs は、LangChain の middleware を agent 実行の各段階を制御する仕組みとして説明しています。logging、tool selection、retries、fallbacks、rate limits、PII detection、human approval を agent loop の中に差し込めるのがポイントです。

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


agent = create_agent(
    model="openai:gpt-4.1",
    tools=[search_docs, send_email],
    middleware=[
        SummarizationMiddleware(...),
        HumanInTheLoopMiddleware(...),
    ],
)

この層は、tool 実行の境界を制御する層として読むと、次の LangGraph の話につながります。ただし middleware が扱えるのはあくまで単発の承認です。処理を止めて、後から同じ状態に戻って再開する、というところまでは面倒を見ません。

LangGraph 層: 再開境界を持つ runtime

LangGraph overview は、LangGraph を long-running かつ stateful な agent のための low-level orchestration framework と説明しています。LangGraph が要るかどうかを分けるのは、途中停止・承認・履歴からの replay・失敗後の再開のどれかが必要かどうか、その一点です。機能の一覧ではありません。

LangGraph docs で繰り返し出てくるキーワードは次の通りです。

• durable execution
• persistence
• interrupts
• memory
• subgraphs
• thread_id

persistence が再開境界を実装する

persistence docs では、graph の state を step ごとに checkpoint として保存し、thread 単位で履歴を管理する仕組みが中心に置かれています。これは、前提で定義した再開境界をそのまま実装したものです。これにより次が可能になります。

1. human-in-the-loop: 人間が途中で state を確認し、承認して再開する
2. memory: 同じ thread に対して会話や実行状態を保持する
3. time travel: 過去の checkpoint から replay する
4. fault tolerance: 失敗後に最後の成功地点から再開する

つまり LangGraph 上の agent は、thread と checkpoint を持った runtime 上の process です。

interrupt は承認を後付けせずに設計できる

interrupt docs の実例では、interrupt() を呼ぶと graph execution が停止し、state が保存され、外部入力を受け取ってから Command(resume=...) で再開できます。

from langgraph.types import Command, interrupt


def approval_node(state):
    approved = interrupt("Do you approve this action?")
    return {"approved": approved}


config = {"configurable": {"thread_id": "thread-1"}}
graph.invoke({"input": "draft"}, config=config)
graph.invoke(Command(resume=True), config=config)

この仕組みから読み取れる設計原則は明快です。

• 危険な side effect の前で止める
• 同じ thread_id で再開する
• interrupt 前の処理は再実行されうるので idempotent にする

LangChain だけで prototype は組めても、本番の承認フローや長時間タスクで詰まるのはこのあたりです。再開境界を自分で作ろうとすると、たいていは checkpointer と interrupt の再発明になります。

Deep Agents: 配線済みのひな形

Deep Agents overview は、Deep Agents を planning、file systems、subagent-spawning、long-term memory を備えた agent harness と位置づけています。LangChain の agent loop を核にしつつ、LangGraph runtime 上で durable execution や human-in-the-loop を利用する構成です。Deep Agents は、LangChain の上に置く配線済みの運用ひな形です。

向くケース

• task planning を最初から built-in で使いたい
• subagent を責務単位で切って context を分離したい
• file system や long conversation compression を最初から持ち込みたい
• coding agent や research agent のような multi-step task をすぐ試したい

それでも消えない論点

Deep Agents を使っても、最終的に見るべき論点は残ります。

• tool 権限をどこで掛けるか
• 承認をどの action に置くか
• state をどの単位で thread 化するか
• subagent 間で何を共有し、何を共有しないか

この4つは、以前 Swarm の記事で立てた「境界は責任（誰が承認し、何を正データとし、失敗を誰が引き取るか）が変わる場所に引く」という話と、同じ形をしています（Swarm解説: agentの数ではなくhandoffの境界で設計を読む）。Swarm が扱ったのは複数 agent 間の handoff という横の境界でした。ここで問われているのは、単一 runtime 内の承認境界、つまり interrupt をどの action の手前に置き、どの thread_id 単位で状態を持つかという縦の境界です。Deep Agents を配線済みで始めても、この境界を決める作業そのものは肩代わりしてくれません。

Deep Agents階層構造

LangSmith: 悪化を検知する層

LangSmith observability docs は、tracing、view traces、dashboards、alerts、automations、feedback collection を中心機能として整理しています。LangSmith の eval docs は、offline eval と online eval を分けて、dataset、evaluators、experiments、feedback loop を回す流れを説明しています。

observability で見るべきもの

• trace: どの prompt、model、tool call で失敗したか
• monitoring: latency、error、quality drift をどう追うか
• alerts / automations: 閾値超過や evaluator 結果をどう通知するか
• feedback: 人手レビューをどう次の dataset に戻すか

eval で見るべきもの

1. offline eval: curated dataset で比較し、回帰を先に見つける
2. online eval: 実運用 traffic 上で quality と safety を監視する
3. feedback loop: 失敗 trace を dataset に戻し、evaluators を更新して再検証する

多くのチームがつまずくのは、いい demo を出すまでの速さと、悪化の検知が未設計なまま本番へ進んでしまう遅さの非対称です。LangSmith を読む理由はここにあります。

本当の難所は legacy 距離

legacy 距離は抽象的な話ではありません。具体例は、このブログの中に一つ既にあります。以前書いた ReAct の解説記事では、実装コードの節で from langchain.agents import create_agent の行に「# v1.0〜の新API」というコメントを添え、create_react_agent が2025年11月の LangGraph v1.0 で非推奨になり langchain.agents の create_agent に統合されたことを明記していました（ReActとは？AIエージェントの基礎フレームワークを図解）。ただし同じ記事は、「create_react_agentからcreate_agentへの移行は本記事の検証コードでは実施していない」とも断っています。つまり、移行の事実だけを先に書き、実測は保留にする、という同じ迷い方を、私は半年前の自分の記事の時点で既にしていたことになります。

今回 v1 docs を読み直すと、この移行はさらに一段進んでいます。LangChain v1 docs は、create_agent を標準の入口に寄せ、langchain namespace を agent building に集中させ、古い chains や retrievers などの legacy 機能を langchain-classic へ移したことを明示しています。legacy 距離とは、手元のサンプルコードと現行 docs が標準とする書き方との差分量を指す言葉です。LangChain の学習コストの正体は、理論の難度よりも、むしろこの距離から生まれています。

まず確認したい migration の観点

旧記事や notebook には、LLMChain、旧 OpenAI wrapper、古い retrieval API を中心にした例が今も多く残っています。これらが即座に無価値というわけではありませんが、今から新規導入するなら、現行 docs が何を標準としているかを優先した方が運用しやすくなります。

締め: どこまで採用するかを状況で並べ直す

ここまで4層を役割で見てきましたが、最後にもう一度並べ替えます。軸は「その層を抜いたときに、どの失敗が起きるか」です。

• 承認漏れを防ぎたいだけなら、LangChain の HumanInTheLoopMiddleware で足ります。フローを止めて人間に確認させる程度なら、失敗しても re-run すれば済むからです。
• 中断からの状態消失（プロセスが落ちた後、同じ状態から続きをやり直せない状態）を防ぎたいなら、LangGraph の persistence と thread_id まで必要です。ここを自作すると、たいてい checkpointer と interrupt の再発明になります。
• 品質劣化の見逃しを防ぎたいなら、LangSmith の offline / online eval と feedback loop が要ります。demo が動くことと、劣化に気づけることは別の能力だからです。
• そして、これら3つの配線そのものを自分で組みたくないなら、Deep Agents が最短の入口になります。ただし tool 権限と thread 単位の設計は、Deep Agents を使っても結局は自分で決めることになります。

私の採用判断はここに尽きます。採用判断は機能数の比較ではなく、止めて、承認して、同じ thread_id で再開する必要があるかの一点で切るべきだと考えています。承認と再開が要らないうちは create_agent 単体で足りますし、要るのに自作するのは persistence と interrupt の再発明です。

ここでもう一段、自分の境界を具体的にしておきます。私が実務のagent運用で日常的に使っているのは、LangChainスタックではなくClaude Code系のharnessです。Claude Codeを自分の日常業務で使っている立場からは、LangGraphやDeep Agentsを本番のagent基盤として採用した経験はありません。この記事の採用判断は、その意味で自分の運用実績から導いたものではなく、公式docsとサンプルコードの読解から導いたものだと考えています。

ただし繰り返しておくと、この判断は現行 docs の読解と、Swarm や ReAct の一次文献を読み解いてきたこのブログの延長線上のものであり、その境界はすぐ上に書いた通りです。docs の言い分をそのまま信じず、読者自身の環境で確かめてください。

関連記事

• Swarm解説: agentの数ではなくhandoffの境界で設計を読む
• ReActとは？AIエージェントの基礎フレームワークを図解【LangChainの原点】
• AIエージェント開発に役立つ一次文献11選｜基礎論文から最新仕様まで

参考リソース

公式 docs

• LangChain overview
• What’s new in LangChain v1
• LangChain middleware overview
• LangGraph overview
• LangGraph persistence
• LangGraph interrupts
• Deep Agents overview
• LangSmith Observability
• LangSmith pricing: LangChain と LangGraph は OSS ですが、LangSmith や managed deployment の料金・プランは変わりうるため、導入前にここで現行の pricing page を確認してください。

リポジトリ

• LangChain GitHub