2026 年の LangChain エージェント: ReAct、LangGraph、Production Patterns

AgentExecutor と LangGraph: 何が変わったのか、なぜそれが重要なのか

移行パスを理解するには、AgentExecutor が廃止された理由を理解する必要があります。それは恣意的なものではありませんでした。開発者が運用システムを構築しようとしたときに、基本的なアーキテクチャの限界に達しました。

最も苦痛な AgentExecutor の制限は、実行中に一時停止して後で再開できないことでした。実際のワークフロー (「レポートを作成し、人間の承認を待ってから公開する」と考える) は、時間の境界を超えて永続的な状態を必要とします。 LangGraph のチェックポイント作成機能は、これをネイティブに解決します。

ReAct パターン: 推論 + ループ内の行動

ReAct (Reason + Act) は、ほとんどの LangChain エージェントの背後にある基本的なプロンプト パターンです。これは、LLM に 2 つのモードを切り替えるように指示します。 Thought (次に何をすべきかについての内部推論) そして アクション (特定の引数を使用して特定のツールを呼び出します)。

実際のループは次のようになります。

1. Thought: LLM は、ユーザーのリクエストと利用可能なツールについて理由を説明します。
2. Action: LLM は、構造化されたツール呼び出し (名前 + 引数) を出力します。
3. Observation: ツールが実行され、結果がコンテキストに追加されて返されます。
4. Thought again: LLM は観察について理由を説明します。
5. 最終的な答え: LLM は十分な情報があると判断すると、最終応答を出力します。

LangGraph では、これらの各ステップは ノード グラフで。 LLM ノードが「モデルがツールを呼び出したか、それとも最終的な答えを出力したか?」をチェックした後の条件付きエッジ。 — そしてそれに応じてルートを設定します。これにより、ReAct ループがブラックボックス エグゼキュータ内で暗黙的にではなく、明示的に検査可能になります。

最新の LLM (GPT-4o、Claude 3.7、Gemini 2.5) は、関数呼び出し/ツール使用 API を通じて ReAct をネイティブに処理します。 「Thought/Action/Observation」文字列を手動でフォーマットする必要はもうありません。モデルのツール使用機能がこれを API レベルで処理します。 LangGraph はこれをきれいにラップするので、ノードはビジネス ロジックに集中し続けることができます。

LangGraph エージェントを段階的に構築する

これは、Python の最小限の LangGraph エージェント パターンです。すべてのプロダクション エージェントは、このスケルトンのバリエーションです。

1. 状態の定義

状態は、すべてのノードを流れる唯一の真実の情報源です。 TypedDict または Pydantic モデルを使用します。

from typing import Annotated, Sequence
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages
from typing_extensions import TypedDict

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
    # add any custom fields your agent needs
    context: str
    iteration_count: int

2. ツールを定義する

ツールは、@tool で装飾されたプレーンな Python 関数です。 docstring は、LLM が参照するツールの説明になります。

from langchain_core.tools import tool

@tool
def search_web(query: str) -> str:
    """Search the web for current information about a topic."""
    # your search implementation here
    return results

@tool
def write_file(filename: str, content: str) -> str:
    """Write content to a file on disk."""
    with open(filename, 'w') as f:
        f.write(content)
    return f"Written {len(content)} chars to {filename}"

tools = [search_web, write_file]

3. グラフを構築する

from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o").bind_tools(tools)

def agent_node(state: AgentState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state: AgentState):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tools"
    return END

graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", ToolNode(tools))
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tools", "agent")

app = graph.compile()

4. 永続化のためのチェックポインタを追加する

from langgraph.checkpoint.sqlite import SqliteSaver

checkpointer = SqliteSaver.from_conn_string("./agent_memory.db")
app = graph.compile(checkpointer=checkpointer)

# Now every run is persisted and resumable
config = {"configurable": {"thread_id": "user-session-123"}}
result = app.invoke({"messages": [("human", "Research LangGraph and write a summary")]}, config)

JavaScript / TypeScript の LangGraph: フル機能パリティ

2026 年の時点では、@langchain/langgraph は Python SDK と同等の完全な機能を備えています。 Node.js バックエンド、Next.js サーバー アクション、または Nuxt API ルートを構築している場合は、完全にサポートされます。

import { StateGraph, END } from "@langchain/langgraph";
import { ChatOpenAI } from "@langchain/openai";
import { tool } from "@langchain/core/tools";
import { z } from "zod";

// Define a tool with Zod schema
const searchWeb = tool(
  async ({ query }) => {
    const results = await yourSearchFunction(query);
    return results;
  },
  {
    name: "search_web",
    description: "Search the web for current information",
    schema: z.object({ query: z.string() }),
  }
);

// State type
interface AgentState {
  messages: BaseMessage[];
}

const llm = new ChatOpenAI({ model: "gpt-4o" }).bindTools([searchWeb]);

// Build graph — identical pattern to Python
const graph = new StateGraph<AgentState>({ channels: messagesStateReducer })
  .addNode("agent", async (state) => ({
    messages: [await llm.invoke(state.messages)],
  }))
  .addNode("tools", new ToolNode([searchWeb]))
  .addEdge("__start__", "agent")
  .addConditionalEdges("agent", shouldContinue)
  .addEdge("tools", "agent");

const app = graph.compile();

JS/TS SDK は、同じチェックポイント作成機能 (開発用はメモリ内、運用用は PostgreSQL)、同じストリーミング API (streamEvents)、および同じ LangSmith トレース統合をサポートしています。メンタル モデルは言語間で直接伝達されます。

マルチエージェント アーキテクチャ: オーケストレーターとサブグラフ

単一エージェント システムはすぐに限界に達します。コンテキスト ウィンドウがオーバーフローし、専門化が損なわれ、複雑なタスクの調整が必要になります。 2026 年には、実稼働 LangGraph のデプロイメントでは、ほぼ常にマルチエージェント パターンが使用されます。

3 つの核となるパターン

LangGraph は、マルチエージェント システムを実装します。 サブグラフの構成。各スペシャリスト エージェントはコンパイルされたグラフであり、親オーケストレーター グラフにノードとして埋め込まれます。状態はレベル間を流れることができ、各サブグラフは独自のチェックポイントとメモリを持つことができます。

制作パターン: おもちゃのデモでは分からないもの

LangGraph エージェントを Jupyter ノートブックで動作させることは、一つのことです。それを大規模に確実に実行することは別の問題です。プロトタイプと製品を区別するパターンは次のとおりです。

エラー処理と再試行ロジック

レート制限、ネットワークのタイムアウト、出力の不正など、ツールの障害は避けられません。 LangGraph は、LLM にエラー メッセージを返すノード レベルの try/catch (正常に回復させる) と、エッジ上のグラフ レベルの再試行ポリシーの 2 つの手段を提供します。

反復制限

コンパイル時は常に recursion_limit を設定してください。これがないと、混乱した LLM が無限にループし、API 予算を消費する可能性があります。ほとんどのタスクの妥当なデフォルトは 25 回の反復です。

app = graph.compile(checkpointer=checkpointer)
# Invoke with recursion limit
result = app.invoke(
    {"messages": [("human", query)]},
    config={"recursion_limit": 25, "configurable": {"thread_id": thread_id}}
)

人間参加型割り込み

LangGraph の interrupt_before および interrupt_after コンパイル オプションを使用すると、特定のノードで実行を一時停止し、現在の状態を人間に明らかにし、入力を収集して再開できます。これは、承認ワークフロー、コンテンツ レビュー ゲート、一か八かのツール呼び出しには不可欠です。

リアルタイム UX のための Streaming

ユーザー向けアプリケーションの場合、ストリーミングは交渉の余地がありません。 LangGraph の astream_events は、どのノードが実行されているか、どのツールが呼び出されたか、トークンごとの LLM 出力などの詳細なイベントを提供します。これを Server-Sent Events (SSE) または WebSocket に接続して、UI でのライブ進行状況を確認します。

LangSmith による可観測性

LANGCHAIN_TRACING_V2=true を設定すると、エージェントが実行されるたびに、どのノードが起動したのか、LLM が何を見たのか、各ツールが何を返したのか、合計レイテンシ、トークン コストなどの完全なトレースが取得されます。これは、「なぜ間違ったツールを呼び出したのか?」をデバッグする方法です。本番環境のバグの一種であり、print ステートメントではありません。

2026 年の実際の LangChain エージェントの使用例

上記のパターンにより、幅広い制作アプリケーションが可能になります。 LangGraph エージェントが現在真の価値を提供しているカテゴリは次のとおりです。

ユースケースに適したエージェント アーキテクチャを選択する方法

すべての問題に複雑なマルチエージェント グラフが必要なわけではありません。ここでは、実際に構築しようとしているものに基づいた意思決定の枠組みを示します。

実用的なヒューリスティック: 機能する可能性のある最も単純なパターンから始めて、LangSmith を使用して計測し、ボトルネックを特定します。。事前に複雑さを考慮して設計するエンジニアは、ほとんどの場合、最初のエージェント システムを過剰に設計します。 LangGraph のパターンにより、要件が明確になるにつれて、より複雑なアーキテクチャへの移行が容易になります。

よくある質問

最終的な考察: LangGraph は 2026 年のエージェント標準となる

2026 年に構築する必要がある「LangChain エージェント」は、LangGraph ステート マシンです。非推奨の AgentExecutor の時代は終わりました。 LangGraph の明示的な状態、条件付きルーティング、永続的なチェックポイント、およびネイティブのマルチエージェント構成は、あれば便利というわけではありません。これらは、運用環境で信頼できるものすべての前提条件です。

ReAct パターンは、依然としてほとんどのタスクの適切な開始点です。単一エージェントが明らかに限界に達した場合にのみ、マルチエージェントの複雑さが追加されます。初日から LangSmith を使用してすべてを計測します。可視性のある診断に 10 分かかる問題で 1 週間を費やすには、トレースを使用せずにデバッグするのが最も早い方法です。

最も重要な変化は概念的なものです。LangGraph エージェントは、ツールが組み込まれたチャットボットではありません。これらはステートフルで永続的なシステムであり、LLM が制御フローを制御します。障害モード、再試行ロジック、状態境界、可観測性を備えた分散システムのように設計すると、経験豊富なエンジニアさえ驚く信頼性が得られます。

コンテンツ自動化、SEO パイプライン、または複数ステップの調査ワークフローを構築している場合は、 EasyClaw これは、インフラストラクチャを自分で配線するのに何週間も費やすことなく、これらのパターンの動作を確認する最速の方法です。