LangChainとLangGraphの違い：使い分け・Python実装・料金を比較

LangChainとLangGraphの違いは？選ぶ基準を整理

設定可能なエージェントの実行ループが必要ならLangChain、その周囲の業務プロセスまで設計するならLangGraphを直接使います。 判断の軸は、次のステップを誰が決めるか、中断後も何を残す必要があるか、どこまで運用責任を引き受けるかです。

注文を検索して問い合わせに答えるサポートアシスタントを作るなら、LangChainのcreate_agentが出発点になります。モデル、ツール、指示を渡すと、モデルとツールのやり取りを繰り返す処理はエージェントの仕組みが担います。ポリシーの適用や承認チェックが必要になったら、そのやり取りの前後で動くコードであるミドルウェアを追加します。

すでにLangChainのアプリがあるなら、今の仕組みでは表現しにくいワークフロー要件を具体的に挙げられるまでは、そのまま使うのがよいでしょう。会話の記憶を追加したい、実行予定のツール呼び出しを確認したい、という理由だけでは移行の根拠として不十分です。現在のLangChainエージェントは、どちらにもLangGraphを基盤とする機能を提供しています。LangChainエージェントのドキュメント。

リクエストの検証、根拠の収集、担当者の判断待ち、承認済みの操作、結果の照合までアプリで管理するなら、独自のLangGraphワークフローを検討します。こうした段階は業務ルールとして明示し、各段階の中で柔軟な判断が必要な作業をエージェントに任せられます。

ライブラリの利用条件は、LangChainの製品ページとLangGraphの製品ページに記載されています。機能の比較は、開発元のランタイム概要と承認ミドルウェアのドキュメントに基づきます。ここで示すのはアーキテクチャの選び方であり、速度の順位ではありません。

現在のLangChainとLangGraphは、どんな関係にあるのか

LangChainは部品とエージェントの抽象化を提供し、LangGraphはその下で状態を管理しながら処理を進めるランタイムを提供します。 互いを置き換える競合製品だと考えると、不要な移行作業が生まれます。

LangChain：設定しやすいエージェントの層

LangChainはcreate_agentを「最小限の構成で、高度に設定可能なハーネス」と説明しています。ハーネスとは、指示、呼び出せるツール、動作の制御など、モデルを取り囲む実行の仕組みです。同じ概要ページには、「LangChainのエージェントはLangGraph上に構築されています」とも明記されています。LangChainの概要。

強みは、実用的な構成から開発を始められることです。注文サポートのアシスタントなら、既存の検索関数をツールとして公開し、その利用にポリシーを加えられます。製品の中身に取りかかる前に、ループを自作する必要がありません。

一方、その構成が業務に合わなくなると限界が見えてきます。名前の付いた業務段階をまたいで長く続く案件では、遷移をすべてプロンプト、ツールの取り決め、ミドルウェアに埋め込むと、処理を理解しにくくなることがあります。これは保守性の判断であり、LangChainエージェントに分岐や状態保持ができないという意味ではありません。ライブラリ自体は無料ですが、モデルの利用料や選択したインフラの費用は別途かかります。

LangGraph：ワークフローを自分で制御するランタイム

LangGraphは、状態を持ちながら長時間動くエージェント向けの「低レベルのオーケストレーションフレームワークおよびランタイム」と位置付けられています。ノードは作業の単位、エッジは次の実行先を決めるつながり、状態はステップ間で引き継ぐ情報です。通常のアプリケーションロジックと、モデルによる判断を組み合わせられます。LangGraphの概要。

ワークフロー自体が製品の一部なら、LangGraphが力を発揮します。たとえばモデルに返信案を作らせつつ、承認が必要か、承認済みの操作をすでに実行したかは、アプリケーションのコードで判断できます。

その分、自分で引き受ける設計も増えます。意味のある状態、遷移、失敗時の振る舞いを決めなければなりません。境界が曖昧なグラフは、結局わかりにくいソフトウェアです。LangGraphも無料のライブラリで、LangChainなしでも使えます。ただし、LangChainのモデルやツールの部品を引き続き使うと便利な場面は多くあります。

実務で取りやすい中間の構成は、大きな業務プロセスの中にLangChainエージェントを置く方法です。柔軟なツール操作には便利な抽象化を残し、その周囲の業務手順を必要な部分だけ明示します。

LangChainエージェントとLangGraph：どこまで制御するか

エージェントループ内の手軽さではLangChain、業務段階をまたぐ明示的な制御ではLangGraphが優位です。 中断後も処理を継続する仕組みと人によるレビューは、どちらにもあります。ただし、いずれも適切な設定が必要です。

エージェントループとツールの承認はLangChainが得意

注文を読み取り、状況を説明し、返信案を出すアシスタントは、モデルとツールのループに収まります。ツールが返信を送信する前にレビューを挟んでも、この構成で対応できます。HumanInTheLoopMiddlewareは、設定したツール呼び出しを一時停止し、承認、引数の編集、却下を受け付けます。中断した状態の保持には、LangGraphの永続化機能を使います。Human-in-the-loopのドキュメント。

既存のLangChainアプリなら、次の変更は比較的小さく済みます。承認ポリシーと永続化用のチェックポインターを設定し、判断待ちの情報をアプリにつなぎます。ただし、ミドルウェアがレビュー用の受信箱を作ったり、どの従業員に承認権限があるかを決めたりするわけではありません。その部分はアプリ側の責任です。

業務段階を明示するならLangGraphが得意

次に行うべき処理が、モデルの次のツール提案ではなく業務記録から決まる場合は、独自のグラフを選びます。仕入先登録のプロセスを考えてみてください。根拠資料を集め、必須項目を検証し、例外を担当者に回し、承認されてから仕入先を有効にします。

グラフなら、こうした遷移をそのまま表現できます。資料収集ノードの中ではLangChainエージェントを呼び出せます。検証と有効化は、結果が明確な通常の関数にできます。決められた手順とエージェントによる柔軟な処理を組み合わせられるという、LangGraphのドキュメントにある性質がここで生きます。LangGraphの概要。

切り替えの基準は具体的です。アプリが次に何をしてよいか迷う場面が繰り返し生じ、それを明示的な状態と遷移で解消できるなら、下の層に降りて制御します。 プロンプトが長くなった、ツールが増えた、モデルの応答が遅いという事情だけでは、その必要性は判断できません。

中断後の継続：基盤は共通、設計の負担は異なる

チェックポインターは、スレッドのワークフロー状態を保存し、後で実行を続けられるようにします。一方、ストアは、別々の会話で使う好みの情報など、アプリが定義した情報をスレッド間で保持します。それぞれが解決する永続化の課題は異なります。永続化のドキュメント。

どちらの構成でも、どの障害から復旧したいかに合わせて保存先を選びます。InMemorySaverは、実行中のプロセス内にチェックポイントを保持するため、再起動すると失われます。会話の状態や中断の動作は示せても、ワーカーが消えた後の復旧を保証するものではありません。その保存要件には、本番向けのデータベースを使うセーバーや、Agent Serverが管理する永続化で対応します。

チェックポイントと、外部で操作が受け付けられた記録も区別してください。「仕入先を有効化する準備ができた」と保存しても、仕入先システムが有効化を受け付けた証拠にはなりません。外部識別子と処理結果は、後から照合できるアプリ側の記録に残します。

開発元は、この再開時の挙動と、副作用のある操作を冪等にする必要性を説明しています。冪等とは、処理が繰り返されても業務上の効果が重複しないことです。たとえば操作に固定の識別子を付ければ、再開したジョブが同じ仕入先を重複登録するのを防げます。中断と再実行のルール。

LangChainとLangGraphをPythonで比較：同じ小さな処理を実装

単純な注文状況の検索なら、LangChainのほうが処理の流れを制御するコードを少なくして、同じ目的を表現できます。 独自のグラフではモデルとツールの経路が見える形になり、その経路を変更する必要が出てきたときに意味を持ちます。

以下の例は、モデル、プロンプト、読み取り専用のツール、入力が共通です。注文記録には、架空であることを明示したローカルのテストデータを使います。langchain[anthropic]とlanggraphをインストールしてください。実際のモデルを呼び出すには、アプリのANTHROPIC_API_KEYが必要です。モデル識別子は、開発元の現在のLangChain概要とLangGraphクイックスタートに沿っています。両方のコードは、応答をあらかじめ定義したモデルを使ってローカルで確認し、ツールの実行と状態の保存を検証済みです。確認したのは処理の接続であり、実際のモデルの挙動や性能ではありません。

共通の設定をcommon.pyとして保存します。

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain：用意されたループを使う

common.pyと同じ場所で、次のコードを別のスクリプトとして実行します。

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

このエージェントの下では、すでにグラフのランタイムが動いています。チェックポインターを渡すために、create_agentを自作のグラフへ置き換える必要はありません。エージェントの設定。

LangGraph：同じループを明示的に定義する

同じcommon.pyとともに使う、もう一方のスクリプトです。

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

条件付きエッジは、モデルがツール呼び出しを要求したらtoolsへ進み、最終回答を出したら終了します。ツールのノードは、処理をモデルに戻します。これはLangGraphクイックスタートの明示的なループ構成を、付属のツールノード用ヘルパーで実装したものです。

どちらのコードも、意図的にプロセス内のメモリを使い、読み取りが成功する経路だけを示しています。デプロイ手順、永続化用データベースの構成、網羅的なエラー処理方針を示すものではありません。また、設定が同じでも、モデルの出力が一字一句同じになる保証はありません。

この用途ならLangChainを選びます。独自のグラフが役立つのは、検索前の必須検証、独立した例外処理キュー、固有の状態と結果を持つ承認段階など、次の要件によってプロセスが変わるときです。

LangSmithの料金とLangGraphのデプロイ費用

どちらのライブラリを選んでも、それだけでホスティングの料金体系が変わるわけではありません。 有料サービスについて判断すべきなのは、必要なLangSmithの機能とデプロイ環境です。以下の料金と製品ドキュメントは、2026年10月13日に開発元の公開ページで確認した内容です。

LangChain・LangGraph・LangSmithの役割の違い

LangSmithは、アプリのトレーシング、評価、デプロイを支えるプラットフォームです。トレースはアプリの実行を記録するもので、モデル呼び出しやほかのステップを含められます。アプリを再開するためのチェックポイントとは別のものです。LangSmithの料金と用語の定義。

ライブラリはどちらも無料で使えます。自分たちで運用するインフラ上で動かす場合も、モデル呼び出し、コンピューティング、ストレージ、運用には予算が必要です。LangSmithを購入するかどうかは別の判断であり、デプロイのドキュメントはLangGraphとLangChainのアプリを明示的にサポートしています。

これはlangchain.com/pricingに記載されたプラン条件です。同ページの計算ツールでは、Plusに含まれるトレースを合計10Kトレースと説明しています。席数を増やしても、席ごとに同じ枠が追加されるという意味ではありません。また、表示されているオブザーバビリティの設定では、追加トレースあたり0.005 LSUとなっています。この計算ツールの値を、すべてのトレース保持オプションに当てはめてはいけません。

ベーストレースの保持期間は14日、拡張トレースは180日で、拡張トレースには追加料金がかかります。保持期間の延長や評価サービスは、グラフを選べば無料で付いてくるものではなく、別途予算を決める項目です。料金FAQ。

デプロイ環境の選択肢と制約

Cloudはマネージド型の選択肢で、Plus以上で利用できます。インフラを運用するのはLangChainです。公開料金ページでは、Cloud内にServerlessとDedicatedがあり、それぞれSmall、Medium、Largeのサイズが用意されています。デプロイ環境。

Serverlessは、断続的な処理、バックグラウンド処理、待ち時間を許容できる処理に向いています。 アイドル時にはゼロまで縮小し、Plusには小規模なデプロイが含まれます。Dedicatedは、安定した可用性を求める顧客向けの処理に向いており、常時稼働のインフラ、自動スケーリング、バックアップ、高可用性を備えます。これは開発元が示す想定用途であり、本記事で性能を計測した結果ではありません。デプロイ料金のFAQ。

移行計画に関わる実務上の制約もあります。作成後にデプロイのサイズは変更できますが、種類は変更できません。 そのため、ServerlessからDedicatedへ移るには、サイズを調整するだけでは済まず、デプロイ先の切り替えが必要です。また、Serverlessのリソースは確保されている間は課金され、縮小するまでのアイドル時間も含まれます。「ゼロまで縮小する」からといって、リクエストがない時間がすべて無料になるわけではありません。Cloudプラットフォームの機能。

Hybridでは、マネージドのコントロールプレーンを使いながら、エージェントのインフラを自分たちで運用します。 コントロールプレーンはデプロイを管理するサービス、データプレーンはエージェントとその基盤サービスを動かす部分です。コントロールプレーンを含むセルフホスト構成では、両方を自分たちの環境に置きます。料金ページではハイブリッドとセルフホストの選択肢はEnterpriseに分類され、料金は個別見積もりです。代わりに当てはめられる固定の月額料金は公開されていません。料金とデプロイ環境。

Standalone Agent Serverも運用上の選択肢です。 コントロールプレーンはなく、基盤サービスは自分たちで用意します。ドキュメントではLangSmithのライセンス、PostgreSQL、Redisを必須としています。無料のLangGraphライブラリを自分のアプリに組み込むこととは別です。また、このサーバーをゼロまで縮小するサーバーレス環境にデプロイしないよう、ドキュメントは注意を促しています。マネージドのCloud Serverlessは、これとは別の構成です。Standalone Agent Server。

同じ処理量なら、どちらのフレームワークでも費用は同じ

公開ページでは、LSU（LangChain Standard Unit）の価格をLSUあたり$1.00と定め、デプロイの課金単位を次のように示しています。

• ランタイムのコンピューティング：0.0675 LSU / vCPU-hr。
• ランタイムのメモリ：0.0090 LSU / GiB-hr。
• データベースのコンピューティング：0.177 LSU / vCPU-hr。
• データベースのメモリ：0.025 LSU / GiB-hr。

この単価は、追加のServerlessおよびDedicatedデプロイにおける、課金対象のリソース消費量に適用されます。公開されているデプロイ単価。

LangChainエージェントでも独自のLangGraphアプリでも、同じ条件にそろえたPlusの月額計算は、$39 × 席数に、各リソースの課金対象時間と上記単価の積を加え、さらにモデル、トレーシング、そのほか該当する従量料金を足したものです。課金対象リソースを数える前に、プランに含まれるデプロイ枠を適用します。計測せずに、リクエスト数やグラフのノード数をリソース時間へ換算しないでください。

開発元の公開サイズを使って計算してみます。以下は公表されたプラン料金ではなく、単価から算出した金額です。追加のSmall Serverlessデプロイは、ランタイムのリソースが1 vCPUと2 GiBなので、リソース確保中の時間単価は1 × 0.0675 + 2 × 0.0090 = $0.0855となります。Small Dedicatedデプロイは、ランタイムが3 vCPUと6 GiB、データベースが1 vCPUと4 GiBと記載されているため、リソース確保中の時間単価は3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335です。サイズ表と公開単価に基づく、サイズ別のリソース費用の見積もりであり、追加のスケーリングやほかのサービスは含みません。

Plusをひとつの席で利用し、このDedicatedのリソース構成を一定に保つ場合、月額小計は**$39 + $0.5335 × リソース確保時間**です。上記のその他の料金はまだ含みません。計算式は両フレームワークで同じです。月額請求を確定するには、実際にリソースを確保した時間とスケーリングの状況が必要です。

処理量が同じなら、フレームワークの違いによって料金の有利不利が逆転する境目はありません。 席数、課金対象リソース、モデルとツールの使用量、トレースの方針を同じにすれば、計算上の差額は$0です。ワークフローの再設計によって使用量は変わり得ますが、ライブラリの名前だけで割引になったり、トークン料金が下がると判断できたりするわけではありません。

全面改修せずにLangChainからLangGraphへ移行するには

制御が必要な処理の境界を移し、引き続き役立つ部品は残します。 移行で大きなコストになるのは、import文の変更ではなく、状態、挙動、復旧方法の再設計です。

まず、古いAPIの更新と、独自のグラフを採用する判断を分けて考えます。現在の移行ガイドは、従来のlanggraph.prebuilt.create_react_agentコンストラクターの代わりに、langchain.agents.create_agentを推奨しています。この移行に従っても、内部のLangGraphを使わなくなるわけではありません。古いアプリでは、独自の処理制御に進む前に、現在のLangChainの機能を取り入れるだけでも改善できる可能性があります。LangChainの移行ガイド。

グラフのほうが本番向けに見えるという理由だけで、動いているLangChainアシスタントを切り替える必要はありません。ループ、ミドルウェア、永続ストレージで要件を満たしているなら、独自のグラフは、効果が確認できないまま設計作業を増やすことになります。

ロックインにも複数の層があります。グラフの状態や制御フローを変えても、再利用可能なモデルやツールの部品は残せます。一方、ホスト型インフラには固有の制約があります。Cloudの永続化にはAgent Serverを通じてアクセスし、ホストされているデータベースには直接アクセスできません。将来のデータエクスポートやホスティング先の変更では、このアクセス境界も考慮してください。Cloudの永続化の詳細。

グラフによる処理制御と、専門家チームとしてエージェントを組み立てる抽象化を比べたい場合は、LangGraphとCrewAIの比較をご覧ください。この技術スタック以外も検討するなら、より広く扱うAIエージェントフレームワーク比較が参考になります。

導入前によくある疑問

処理制御を変更する前に、AI業務ワークフロー監査チェックリストを使って、対象業務、レビューを挟む範囲、運用責任者を明確にしましょう。