はじめに：Agentic BIツールを作る中で出会ったLangGraph

最近、Agentic BIツールのプロトタイプを作っていて、その実装にLangGraphを採用しました。

きっかけは、最初にシンプルな「自然言語 → SQL → 結果返却」のText-to-SQLパイプラインを組んでみたものの、すぐに壁にぶつかったことでした。

SQLが一発で正しく出ない（スキーマを見直して再生成したい）
結果が空だったり想定外だった場合に「なぜ？」を深掘りしたい
グラフ化が必要か、テキスト要約で良いかをエージェントに判断させたい
重要な操作の前には人間に確認させたい（Human-in-the-loop）

要するに、「一本道のパイプラインでは表現しきれない、ループと条件分岐とリトライが必要な世界」 にBIエージェントは突入する。

これを素直に書けるのがLangGraphだった、というのが個人的な結論です。

この記事では、その過程で改めて整理したLangChainとLangGraphの違い・関係性・使い分け をまとめておこうと思います。

なお、2025年10月22日に LangChain v1.0 / LangGraph v1.0 が同時GAされ、両者の関係がかなりクリアになりました。

古い記事だと「どっちを使えばいいの？」という議論がよく出てくるが、現時点（2026年）ではその問いの立て方自体が少し変わっているので、その点も触れていきたいと思います。

1. LangChainとは

LangChainは、**LLMアプリケーションを作るための高レベルなツールキット（フレームワーク）**です。

2022年末頃から急速に広がり、今では事実上の業界標準ライブラリのひとつになっています。

提供している主なコンポーネントはざっくり以下のとおりです。

モデル抽象：OpenAI / Anthropic / Google / ローカルLLMなどを統一インターフェースで扱える
プロンプトテンプレート：プロンプトを再利用・テスト可能な単位にする
Tools / Tool Calling：外部API、SQL、検索などをLLMから呼ばせる
Retriever / VectorStore連携：RAG（検索拡張生成）の基盤
メモリ：会話履歴の保持
Integrations：数百種類のSaaS・DB・ベクトルストアとの統合

ひと言で言えば、「LLMアプリを最短距離で組み立てるためのレゴブロック集」 です。

LangChainが得意なこと

入力 → LLM → 出力 のような、DAG（有向非巡回グラフ）で表現できる線形フローが得意領域です。

具体的には次のようなケースですね。

シンプルなRAGチャットボット
要約 / 翻訳 / 分類など、1〜数ステップで完結するタスク
外部APIを1回呼んで結果を整形するエージェント

v1.0で何が変わったか

ここが非常に重要なポイントなのですが、LangChain v1.0（2025年10月）のリリースに伴い、これまでの主力だった AgentExecutor や LLMChain といった古い仕組み（レガシーなAPI）は、別パッケージ（langchain-classic）へと完全に分離されました。

新しい標準APIはcreate_agent()になっており、これは内部的にLangGraphの実行エンジンの上で動いています。

# v1.0以降のシンプルなエージェント
from langchain.agents import create_agent

agent = create_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[search_tool, sql_tool],
    system_prompt="あなたはデータ分析アシスタントです。",
)

result = agent.invoke({"messages": [{"role": "user", "content": "..."}]})

つまり今のLangChainは、「初心者でもすぐに動くエージェントを書けるための高レベルAPI層」という位置付けに整理されました。

2. LangGraphとは

LangGraphは、LangChainと同じ会社が開発した複雑なAIエージェントを動かす専用エンジンとして後から作ったフレームワークです。

LangChainが便利な部品（レゴブロック）の集まりだとしたら、LangGraphはそれらの部品をどういう順番で、どうループさせて動かすかという「設計図と制御システム」を提供する役割を持っています。

2025年10月にv1.0がGAされ、Klarna / Uber / LinkedInなどの本番システムで採用されていることも公式に発表されました。

その設計思想を一言でいうと、「LLMアプリの複雑な動きを、"状態（State）を持つグラフ（ネットワーク図）"として明示的にコントロールしよう」というものになります。

コアコンセプト

StateGraph：処理全体を、状態（State）を共有するノードとエッジのグラフで表現する
Nodes：関数 or LLM呼び出し。Stateを受け取り、Stateの一部を更新して返す
Edges：ノード間の遷移。条件分岐（Conditional Edges）が書ける
Checkpointer：各ノード実行後に状態を永続化（SQLite / Postgres / Redisなど）
Human-in-the-loop：途中で実行を一時停止し、人間の入力を待てる
Streaming：ノード単位 / トークン単位の両方でストリーミング可能
Time travel：過去の状態に戻ってリプレイ・デバッグできる

イメージとしては、「LLMアプリ版のワークフローエンジン（AirflowやTemporalのようなもの）」が一番近いです。

あらかじめ決められたタスクを順番にこなす従来のワークフローとは違い、「ノードがLLMになり、エッジ（分岐）がLLMの判断で動的に切り替わり、必要なら前の工程へループする」という点が、LangGraphならではの面白さであり、圧倒的な強みです。

最小サンプル

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class State(TypedDict):
    question: str
    sql: str
    result: str
    needs_retry: bool

def generate_sql(state: State) -> State:
    # LLMでSQL生成
    ...

def execute_sql(state: State) -> State:
    # SQL実行
    ...

def should_retry(state: State) -> str:
    return "generate_sql" if state["needs_retry"] else END

graph = StateGraph(State)
graph.add_node("generate_sql", generate_sql)
graph.add_node("execute_sql", execute_sql)
graph.add_edge(START, "generate_sql")
graph.add_edge("generate_sql", "execute_sql")
graph.add_conditional_edges("execute_sql", should_retry)

app = graph.compile(checkpointer=...)

ここで重要なのは、execute_sql から generate_sql に戻るループが自然に書けていることで、これがDAGベースのLangChainでは素直に表現できなかった部分です。

LangGraphが得意なこと

ループや条件分岐を含むエージェントの実装
マルチエージェント（複数の専門エージェントが協調するシステム）
長時間実行 / 中断・再開（数日かかる承認フローなど）
Human-in-the-loop が必須なフロー（金融、医療、社内承認系）
失敗時のリトライや復旧をきちんとやりたいプロダクション用途

3. 両者の関係性

ここが混乱しがちなところですが、LangGraphはLangChainの代替ではありません。

LangChain ＝豊富な外部連携（数々のDBやLLMとのコネクタ）と、サクッと動かすための高レベルAPI

LangGraph ＝それらをどう動かすかを制御する、低レベルな実行ランタイム（状態管理・永続化・ループ）

という2層構造になっています。

v1.0以降、LangChainのcreate_agent()は内部的にLangGraphで動きます。

つまり create_agent()を呼んだ瞬間、あなたは知らないうちにLangGraphユーザーになっています。

いつ「自分でグラフを組む」フェーズに移行するのか？

公式やコミュニティの実務的な目安をまとめると、以下のような使い分けになります。

ケース	推奨
シンプルなRAG / Q&A / 要約Bot	LangChain（`create_agent`）
標準的なツール呼び出しエージェント	LangChain（`create_agent`）
ループ・分岐・リトライが必要	LangGraphを直接書く
マルチエージェントのオーケストレーション	LangGraphを直接書く
Human-in-the-loopが必要	LangGraphを直接書く
長時間実行・中断再開が必要	LangGraphを直接書く

ざっくりした指針としては、「まずは手軽な create_agent() から始めて、ループや複雑な条件分岐など、痒いところに手が届かなくなったら StateGraph を使った手書きの制御に切り替える」が現実的だと思います。

両者は地続きなので、後から書き直すコストも比較的小さくて済むのが良い点です。

関連プロダクト

LangChainエコシステムには、本体以外にも本番運用を支える周辺ツールがあります。

LangSmith：トレーシング・評価・モニタリング（観測性のデファクト）
LangGraph Platform：LangGraphアプリのマネージドデプロイ環境
LangGraph Studio：グラフを可視化してデバッグできるIDE

「本格的にプロダクション運用するなら LangGraph + LangGraph Platform + LangSmith の3点セット」というのが2026年時点の鉄板構成になりつつあるようです。

4. ユースケース

1. Agentic BIツール（私が作っていたもの）

今回作っていたものはまさにこれ。アーキテクチャをざっくり書くと以下のようなマルチエージェント構成にした。

[ユーザーの質問]
        ↓
  [Routerノード]  ← 質問のタイプを判定（探索的 / 定型 / メタ）
        ↓
  ┌─────┴─────┐
  ↓                 ↓
[Semantic Layer] [SQL Generator]
  ↓                 ↓
  └──→ [SQL Executor] ←┐
            ↓                   │
       [Validatorノード]   │
            ↓                   │
       OK? ─ No ─────────┘ (retry)
            ↓ Yes
       [Visualizer / Summarizer]
            ↓
        [Reflection]  ← "Why?"を深掘りする
            ↓
          [回答]

特にValidatorからSQL Generatorへのループ、そしてReflectionノードによる「なぜそうなったのか」の深掘りは、LangGraphのループとconditional_edgeなしには素直に書けなかったです。

2. その他の典型的ユースケース

Deep Research系：複数の検索クエリを並列発行し、結果を統合してレポート生成
カスタマーサポートエージェント：FAQ参照 → エスカレーション判定 → 必要なら人間にHand-off
コーディングエージェント：コード生成 → テスト実行 → 失敗ならデバッグループ
業務承認フロー：申請 → AI下書き → 人間レビュー → 修正 → 承認、というマルチデイのフロー

5. 代替技術 / 競合フレームワーク

LangGraphが事実上のスタンダードになりつつあるとはいえ、他にも選択肢はあります。

2026年時点で名前を聞く主要なものを整理しておきます。

CrewAI

「役割（Role） + ゴール + バックストーリー」を与えてエージェントの "クルー" を作るというメンタルモデル
学習コストが低く、ビジネス側のメンバーにも理解されやすい
Fortune 500の約60%が何らかの形で採用しているという調査もある
一方で、細かい制御や複雑な分岐は苦手

Microsoft Agent Framework（旧AutoGen）

AutoGenはメンテナンスモードに移行し、Microsoftの戦略は Microsoft Agent Framework に統合された
会話ベースのエージェント間コミュニケーションが強み
Azureとの統合が前提なら有力

OpenAI Agents SDK

OpenAIが2025年に出した公式SDK
ハンドオフ、ガードレール、トレーシングが組み込み
OpenAIモデルに最適化されている分、ロックインのリスクはある

Google ADK (Agent Development Kit)

Google製。Vertex AIとの統合前提
まだ新しく、エコシステムは発展途上

Smolagents（HuggingFace）

「エージェントはコードを書けばいい」という思想のミニマルライブラリ
軽量で、フレームワーク疲れした開発者からの支持が厚い

フレームワークを使わないという選択肢

最近、海外のエンジニアの間で「フレームワークなしで素のSDKで書いた方が早い」という揺り戻しの議論もよく目にします。

特にAnthropicが公開している "Building Effective Agents" というエッセイは、

「複雑なフレームワークに頼らず、シンプルなパターンを組み合わせる」ことを推奨しており、これに共感する声が大きいようです。

私の実感としても、プロトタイプ段階ではLangGraphが圧倒的に楽だが、本番で性能チューニングしたくなるとフレームワークの抽象が邪魔になってくる場面もある、というのは事実だと思います。

6. 海外エンジニアの見方（私の観測範囲）

Reddit / Hacker News / X / DEVあたりを眺めていると、LangChain/LangGraphへの評価はおおむね以下のような傾向があります。

ポジティブ寄りの意見

「LangGraphはv1.0以降、本当に安定して使えるようになった」
「Klarna / Uber / LinkedInが本番で使ってるという事実は重い」
「LangSmithのトレーシングなしではデバッグできる気がしない」

ネガティブ寄りの意見

「LangChainは抽象が多すぎて、内部で何が起きているか分かりにくい」
「依存関係が重い」「破壊的変更が多い」
「結局SDK直叩きで十分な場面が多い」

両論ありますが、「複雑なエージェントを本番運用するなら今のところLangGraphが最有力」という点では合意があるように見えます。

一方で、「シンプルなユースケースにLangChainを使うのはオーバーキル」という意見も根強いようです。

7. 所感

実際にAgentic BIのプロトタイプを組んでみて、ループや条件分岐、人間介入（Human-in-the-loop）が必須になる領域におけるLangGraphのパラダイムは強力だと確信しました。最初からこの抽象で設計していなければ、後から状態管理の複雑性に押しつぶされていたはずです。
一方で、State（状態）の設計センスが問われるフレームワークでもあります。初期設計を間違えると、ノードを増やすたびに状態のコンフリクトに苦しむことになるため、「最初は小さく作り、何度か書き直す」割り切りが必要だと感じました。
2025年末のv1.0コンポーネント整理によって「古いコードが腐っていく時期」を脱し、エコシステムとしての標準が見えたのは大きな収穫です。周辺ツール（LangSmith等）への依存度や、Anthropicが提唱する「フレームワークなし（素のSDK）」の揺り戻し議論も意識しつつ、「チームが2週間後に何を保守できるか」を基準に現実的なラインを見極めていきたいところです。

まとめ

LangChain = エージェントを最速で組み立てる高レベルAPI
LangGraph = 状態を持つグラフとして本格的なエージェントを構築するランタイム
両者は対立ではなく 2層構造。v1.0以降、create_agentは内部でLangGraphの上に乗っている
シンプルなものはcreate_agent、複雑になったらLangGraphを直接書くという使い分けが現実的
BIのようなループと判断が絡む領域では、LangGraphの恩恵を強く感じる