「LangChain は名前を聞いたことがあるけれど、LangGraph って何が違うんだろう」。AI のフレームワーク周りは似た名前が多くて、ここでつまずく方は多いと思います。私自身、最初は両者の線引きが曖昧で、なんとなく使い分けていた時期がありました。
「LangGraph とは」は月間およそ 480 回検索されています(ラッコキーワード実測、2026年6月時点)。私は業務で LangChain / LangGraph を部分的に使っていますが、フル依存ではなく、必要な場面だけ使う立場です。結論から言うと、一直線の処理なら LangChain や直 API で足り、行ったり来たり・ループ・状態の持ち回りが必要になったら LangGraph が筋、という使い分けになります。この記事では、読み方・LangChain との違い・State とグラフ・Python の最小サンプル・料金までを、未経験のあなたにも届くように整理していきます。
一行だけ掴みたい方は次の章だけで十分です。手を動かしたい方は最小サンプルへ、使うべきか迷っている方は判断軸へ飛んでください。
結論と読み方|「状態を持つ AIエージェント」をグラフで組む道具・ラングラフ・LangChain 社製 OSS
📖 この章で使う用語
- LangGraph(ラングラフ):LLM アプリで「状態を持つ・分岐する・ループする」フローをグラフの形で組むフレームワーク。状況で対応が枝分かれする商談フローのイメージ。
- LangChain(ラングチェーン):LLM アプリの部品(プロンプト・モデル・ツール)を直線的に連結する関連ツール群。レゴブロックを並べるイメージ。
- フレームワーク:よくある処理の「型」を用意してくれる土台。毎回ゼロから組まずに済む道具箱。
- LLM(大規模言語モデル):ChatGPT や Claude の正体。膨大な文章を学習した「次の言葉を予測する装置」。詳しくはLLM とはへ。
迷ったら、この一行だけ覚えてください。「一直線の処理なら LangChain や直 API、行ったり来たり・ループ・状態の持ち回りが要るなら LangGraph」です。
LangGraph は公式ドキュメントで「長く動き続ける、状態を持つエージェントを作るための低レベルなオーケストレーション(指揮)の枠組み」と説明されています(LangGraph 公式ドキュメント、取得:2026-06-03)。要は「AI に複雑な仕事を任せるとき、その流れを行き来や枝分かれも含めて組み立てる土台」です。
先に立ち位置をお伝えします。私のメインは公式 SDK(Anthropic / OpenAI 直)と自前で組んだ流れで、LangGraph は「状態やループが必要になった場面」で足す使い方です。だからこの記事は全機能を網羅するチュートリアルではなく、「使うとき・使わないときの判断軸」を背骨に、要点を公式ドキュメントに沿って整理します。
スコープと深掘りの送り先も先に示します。概念・LangChain との違い・State とグラフ・最小サンプル・料金は本記事で扱い、それ以外は次へ送ります。
- AIエージェント構築の全体像(4 つの作り方の比較) → AIエージェント 作り方
- RAG(外部文書を検索して回答に使う仕組み) → RAG とは
- MCP(AI に外部ツールを繋ぐ標準仕様) → AIエージェント MCP
- LLM そのものの基礎 → LLM とは
LangGraph とは何か/読み方
まず読み方から。LangGraph は 「ラングラフ」 と読みます。周りに聞いても一瞬止まる方が多かったので、最初に書いておきます。「Lang」は LangChain と同じく言語(Language)/LangChain を、「Graph」は後述のグラフ構造(点と線で表す仕組み)を指します。LangChain 社が作る OSS フレームワークで、ライセンスは MIT、無料で使えます(langchain-ai/langgraph|GitHub、取得:2026-06-03)。
一言でいえば LangGraph は 「LLM アプリで、状態を持つ複雑なフローを組むための道具」 です。営業のたとえで考えるとイメージしやすいと思います。台本どおり一直線に進む商談(挨拶 → ヒアリング → 提案 → クロージング)は LangChain が得意とする一方向の流れです。
一方、実際の商談はそう素直に進みません。「予算が合わなさそうなら提案を一段下げる」「迷っていたら前のステップに戻ってもう一度ヒアリングする」と、状況を見て枝分かれしたり前に戻ったりします。この「状況に応じて行ったり来たりする対応フロー」を AI で組めるようにするのが LangGraph です。
LangChain との違いと核|部品とチェーン対 状態とグラフ・State/ノード/エッジ・Python 最小サンプル
📖 この章で使う用語
- チェーン(chain):処理を一方向に数珠つなぎにした流れ。台本どおりに進む商談のイメージ。
- グラフ(graph):処理を「点(ノード)と線(エッジ)」で表した構造。行ったり来たり・枝分かれができる。
- ステートフル/ステートレス:状態(途中経過)を覚えているか/覚えていないか。前のお客様のカゴを覚えていないレジ=ステートレス。
- State(状態):処理の途中経過を持ち回す入れ物。買い物カゴや商談の進捗メモのイメージ。
- ノード(node)/エッジ(edge):グラフの中の「1 つの処理ステップ(駅)」と、次のノードへ進む「線路」。条件で行き先が変わることもある。
LangChain と LangGraph の違いが、この記事でいちばん伝えたいところです。LangChain は「部品とチェーン」、LangGraph は「状態とグラフ」と捉えると、両者の役割がすっきり整理できます。
LangChain は、LLM アプリの部品(プロンプト・モデル・外部ツールの呼び出しなど)を直線的に連結する関連ツール群です。レゴブロックを順番に並べて一本のラインを作るイメージです。
LangGraph は、その上で「状態を持ち、条件で枝分かれし、ぐるっとループする」流れをグラフの形で組む土台です。公式ドキュメントでも LangGraph は LangChain より低い層(土台側)に位置づけられ、「LangChain を使わなくても LangGraph は使える」と明記されています(LangGraph 公式ドキュメント、取得:2026-06-03)。上位互換というより役割が違う別の道具です。LangChain 単体の役割(Models / Chains / LCEL / RAG / Agent)を詳しく押さえたい方はLangChain とは|LangGraph との違い・Python の始め方 へ。
比較表で整理する
| 観点 | LangChain | LangGraph |
|---|---|---|
| 処理構造 | チェーン(一方向の連結) | グラフ(行き来・枝分かれ・ループ可) |
| 状態管理 | 基本は持ち回らない | State として持ち回る(ステートフル) |
| ループ・分岐 | 苦手(一直線が前提) | 得意(条件分岐・繰り返しを組める) |
| 向く用途 | 一本道の処理の組み立て | 複雑なエージェント・人間の介在が要るフロー |
| 学習コスト | 比較的とっつきやすい | グラフの概念に慣れる必要がある |
※両者とも頻繁にバージョンが更新されるため、細かい機能の対応状況は公式ドキュメントで都度ご確認ください(取得:2026-06-03)。
私の判断軸:どちらを使うか
一直線で済む処理なら、LangChain か、いっそ直 API(公式 SDK を直接呼ぶ)で十分だと感じています。フレームワークを挟むぶんの学習コストや依存が見合わない場面が、実際にけっこうあるからです。
逆に、「途中の状態を覚えておきたい」「条件で枝分かれする」「人間の確認を一回挟みたい」「条件が満たされるまで繰り返したい」という要素が出てきたら、LangGraph に寄せると流れがきれいに整理できます。複雑な商談ほど「次にどう動くかを場合分けしたメモ」が効いたのと同じで、場合分けが多い仕事ほど構造で持っておくとラクでした。
LangGraph の核|State(状態)とノード・エッジ
LangGraph を理解する鍵は State(状態)・ノード・エッジの 3 つです。ここを押さえると後のコードが読みやすくなります。公式ドキュメントでも「グラフを定義するとき、最初にやるのは State を決めることだ」と説明されています(LangGraph 公式ドキュメント(Graph API)、取得:2026-06-03)。
State は処理の途中経過を持ち回す入れ物です。買い物カゴを想像してください。商品を棚ごとに足していき、レジに着くころには中身が増えています。この「カゴ」が State で、AI のフローでも「ユーザーの質問」「途中で調べた情報」「これまでのやり取り」などを入れて持ち回ります。状態を持ち回せる=処理が前のステップを覚えていられるということです。
ノードはグラフの中の 1 つの処理ステップ(電車の駅)で、「質問を受け取る駅」「AI に答えさせる駅」のように各駅で1つの仕事をします。エッジは駅と駅をつなぐ線路で、進む先を指定します。面白いのは条件によって線路を切り替えられるところで、「State の中身がこうなら A、そうでなければ B」と進路を分けられます。これが LangGraph が「枝分かれ・ループ」を扱える正体です。
組んだグラフは図として出力でき、「どの駅から、どの条件で、どの駅へ向かうのか」を線でつないだ路線図が出せます。フローが複雑になるほど図にして「戻る線が抜けていた」と抜け漏れに気づけます(出力形式の詳細は公式ドキュメントを参照、取得:2026-06-03)。
Python で最小サンプル|状態を持つ簡単なグラフを動かす
📖 この章で使う用語
- pip:Python のライブラリ(部品)を入れる道具。アプリストアからアプリを入れる感覚。
- TypedDict:「この入れ物には、この名前でこの型の値が入る」と決めておく書き方。State の形を決めるのに使います。
- compile / invoke:組んだグラフを「完成形にする(compile)」「実際に走らせる(invoke)」操作。
- LLM API キー:OpenAI / Anthropic / Google などの AI を呼ぶ鍵。詳しくはAnthropic Console 使い方やGemini API 使い方へ。
ここからは「State を持つ、ごく簡単なグラフ」を、写経しやすい最小の形で動かします。以下は執筆時点(2026-06-03)の公式ドキュメント(Graph API)の書き方に沿った最小例です。LangGraph は更新が速く書き方が変わる可能性があるので、動かないときは公式の最新版を確認してください(API の細かい仕様は公式ドキュメントからの整理です)。
インストールと前提
まずはライブラリを入れます。
# LangGraph 本体を入れる(-U は最新版に更新する指定)
pip install -U langgraph
今回は LLM を呼ばずに「State を持ち回す流れ」だけを体感する最小例なので、LangGraph だけで動きます。API キーが必要になったらAnthropic Console 使い方やGemini API 使い方を参照してください。
最小グラフのコード
やることは「State を決める → ノードを2つ作る → エッジでつなぐ → 完成させて走らせる」だけです。
# State(カゴ)の形を決める。今回は count という数字を1つ持つだけ
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
class State(TypedDict):
count: int # カゴに入れる「数字」。各ステップでこれを更新していく
# ノード(駅)その1:カゴの数字に 1 を足す処理
def add_one(state: State) -> State:
# state["count"] が今のカゴの中身。+1 して返すと、カゴが更新される
return {"count": state["count"] + 1}
# ノード(駅)その2:今のカゴの中身を表示するだけの処理
def show(state: State) -> State:
print(f"いまの count は {state['count']} です")
return state
# グラフ(路線図)を組み立てる
builder = StateGraph(State)
builder.add_node("add_one", add_one) # 駅その1 を登録
builder.add_node("show", show) # 駅その2 を登録
# 線路をつなぐ:スタート → add_one → show → 終わり
builder.add_edge(START, "add_one")
builder.add_edge("add_one", "show")
builder.add_edge("show", END)
# compile で完成形にして、invoke で走らせる
graph = builder.compile()
result = graph.invoke({"count": 0}) # カゴの初期値は count=0
実行すると「いまの count は 1 です」と表示され、result には {"count": 1} が入ります。たったこれだけですが、「カゴ(State)を駅から駅へ持ち回って中身を更新していく」という LangGraph の基本動作が全部入っています。
条件分岐を 1 つ足す(LangGraph らしさの体感)
最小グラフだけだと「関数を順番に呼ぶだけで良くない?」と感じるかもしれません。真価が出るのは 条件分岐 を足したときです。
# 「カゴの数字が 3 未満なら add_one に戻る、3 以上なら終わる」という分岐を足す
# 分岐の判定をする関数。State を見て「次はどこへ行くか」の名前を返す
def route(state: State) -> str:
if state["count"] < 3:
return "add_one" # まだ 3 未満なら、もう一度 add_one へ戻る(ループ)
return END # 3 以上になったら終わり
builder = StateGraph(State)
builder.add_node("add_one", add_one)
builder.add_edge(START, "add_one")
# 条件分岐の線路:add_one のあとに route で行き先を決める
builder.add_conditional_edges("add_one", route)
graph = builder.compile()
result = graph.invoke({"count": 0}) # 0 → 1 → 2 → 3 と、3 になるまで繰り返す
ここでやっているのは「State を見て、条件を満たさなければ前の駅に戻る」というループで、add_conditional_edges が状況に応じて線路を切り替える部分です。「行ったり来たり・条件で枝分かれ」という LangGraph ならではの動きが体感できます。新しいフレームワークは「最小で1回動かす」を起点にすると、その後の理解が一気にラクになります。
判断軸・Studio・料金|直 API + 自前実装との比較・可視化デバッグ・本体無料/周辺は有料
📖 この章で使う用語
- 直 API:Anthropic / OpenAI などの公式 SDK を直接呼ぶこと。フレームワーク(包み)を挟まない方法。
- オーバーエンジニアリング:必要以上に複雑に作り込んでしまうこと。
- LangGraph Studio:組んだグラフを目で見て、ステップごとに実行し、State の中身を確認できる可視化・デバッグ用の環境。
- LangGraph Platform / LangSmith:作ったアプリを動かす・公開するマネージドサービスと、LLM アプリの動きを記録・観測・評価する SaaS。いずれも有料枠があります。
私の業務での主軸は公式 SDK(直 API)+ 自前で組んだ流れで、LangGraph は「必要になったら足す」適材適所です。「全部 LangGraph で組むべき」と身構える必要はなく、大事なのはいま組もうとしている処理に LangGraph が向いているかを見極めることです。
寄せると楽になる場面・直 API で足りる場面
以下の要素が出てきたら LangGraph に寄せたほうが流れが整理できます。逆に右の列に当てはまるなら、無理にフレームワークを挟まず直 API + 自前実装で十分なことが多いです。
| LangGraph に寄せると楽 | 直 API + 自前実装で足りる |
|---|---|
| 状態を持ち回したい(調査結果ややり取りを覚えておく) | 一直線の処理(入力 → AI → 結果を整えるで完結) |
| 条件で枝分かれする/ループが必要 | 薄い処理(AI を1〜2回呼ぶだけで状態管理が不要) |
| 人間の確認を一回挟みたい | 学習コストが見合わない(使う場面が限定的) |
| チームで流れの組み方を揃えたい | 後から読み返す見通しを優先したい |
特に「人間の確認を一回挟む」フローは自前だと煩雑になりがちで、土台に乗せる価値を感じやすい場面です。逆にシンプルな処理にまでフレームワークを被せると、かえって複雑になる(オーバーエンジニアリング)こともあります。「LangGraph が絶対に必要」とは言いません。状態・分岐・ループ・人間の介在が増えたサインを感じたら選択肢として思い出す——その距離感がしっくりきています。全体像を比べたい方はAIエージェント 作り方も合わせてどうぞ。
LangGraph Studio とグラフ可視化
組んだグラフを目で見ながら確認・デバッグできる「LangGraph Studio」という環境があります(ここからは業務常用ではなく公式情報からの整理です)。公式ドキュメントによると、グラフの構造を視覚的に確認したり、ステップごとに実行して途中の State の中身を見たりできる開発支援の仕組みです(LangGraph 公式ドキュメント、取得:2026-06-03)。
State とノード・エッジで触れた「路線図」を紙の上で眺めるだけでなく、「実際に電車を1駅ずつ走らせて、各駅でカゴ(State)の中身を覗ける」道具です。フローが複雑になるほど「どこで意図しない動きをしているか」が掴みにくくなるので、こうした可視化ツールの価値が出てきます。機能の細部や対応状況は公式ドキュメントで最新情報をご確認ください(取得:2026-06-03)。
LangGraph の料金|本体は無料、Platform/LangSmith は有料枠
LangGraph 本体(OSS ライブラリ)は無料で使えます。 ライセンスは MIT で、学ぶ・自前で動かすぶんには費用はかかりません(langchain-ai/langgraph|GitHub、取得:2026-06-03)。費用が関わるのは本体ではなく周辺サービスです。
- LangGraph Platform:作ったアプリを動かす・公開する(デプロイ)マネージドサービス。本格運用の段階で関わります。
- LangSmith:LLM アプリの動きを記録・観測・評価するサービス。無料枠(Developer プラン)から始められ、チーム向けの有料プランもあります。
公式の料金ページによると、LangSmith には無料の Developer プランがあり、その上にチーム向けの Plus プラン(執筆時点で 1 席あたり月 $39 から、従量課金)などが用意されています(LangChain 料金ページ、取得:2026-06-03)。料金体系やプラン内容は変更される可能性があるため、具体的な金額・無料枠の上限は必ず公式の料金ページでご確認ください。学ぶ・最小サンプルを動かす段階ではお金の心配は不要で、まずは無料の本体で最小サンプルを動かすところから始めてみてください。
全体像・つまずき・非エンジニア視点|AI 開発での位置づけ・失敗パターン 5 個・行き来のある業務の見つけ方
📖 この章で使う用語
- RAG(検索拡張生成):外部の文書を検索して、その内容を LLM の回答に使う仕組み。詳しくはRAG とはへ。
- MCP(Model Context Protocol):AI に外部のツールやデータを繋ぐための標準仕様。詳しくはAIエージェント MCPへ。
最後に、LangGraph が「AI 開発全体の中でどこに位置するのか」を整理し、未経験でハマりやすい点と非エンジニア視点での捉え方まで触れます。
エージェント構築の実装ルートの 1 つ
LangGraph は AIエージェントを作る 実装ルートの 1 つで、具体的には「Python + LangChain/LangGraph + 直 API」の組み合わせにあたります。これ以外にもノーコードのツールや別の構築プラットフォームを使うルートがあり、どのルートが向いているかを比べたい方は 4 つの作り方を俯瞰するAIエージェント 作り方へ。本記事はその中の「コードで組むルート」で登場する LangGraph に絞った位置づけです。
RAG・MCP・LLM との関係
LangGraph は他の要素と組み合わせて使われることも多いです。
- RAG と組み合わせる:外部文書の検索結果を State に持ち回りながら複雑な回答フローを組みます。RAG の基礎はRAG とは、検索を担うベクトル検索ライブラリはFAISS とはへ。
- MCP と組み合わせる:エージェントが外部ツールを呼ぶ繋ぎ込みは MCP が担います。基礎はAIエージェント MCPへ。
- LLM が土台にある:LLM が曖昧な方は先にLLM とはを押さえると記事全体が読みやすくなります。
クラウド基盤(AWS など)経由で AI を呼ぶ実装に興味がある方はAWS Bedrockも参考になります。
つまずきポイント・失敗パターン 5 個
未経験のうちにハマりやすいポイントを、対処とセットで挙げます。
- 最初から複雑なグラフを組んで挫折する → 分岐もループも人間の介在もある立派なエージェントをいきなり組むと迷子になります。最小サンプルのような 1〜2 駅の小さなグラフから始め、少しずつ足すのが近道です。
- State に何を入れるか設計せず破綻する → 後から「あの情報も持ち回りたかった」と崩れがち。コードを書く前に「カゴに何を入れるか」を一度紙に書き出します(買い物前のメモと同じ)。
- LangChain と LangGraph の責務を混同する → 最初は誰もが通る道。LangChain との違いの「LangChain は部品とチェーン、LangGraph は状態とグラフ」に立ち返ると整理し直せます。
- バージョン差で API が動かない → ネットで見つけたコードがそのまま動かないことがあります。まず公式ドキュメントで自分が入れたバージョンの書き方を確認します(取得:2026-06-03)。
- 「とりあえず LangGraph」でオーバーエンジニアリング → 一直線で済む処理に被せるとかえって複雑に。判断軸に立ち返り「本当に状態・分岐・ループが要るか?」を自問してください。
エンジニアでない人がどう捉えればいいか
LangGraph 自体はコードを書くエンジニア向けの道具で、「非エンジニアが明日から使いこなす」話ではありません。ただ「AI に複雑な業務フローを任せる仕組みの裏側」を概念として知っておくことは、生成AIエンジニアを目指す方の土台になります。
ポイントは、一直線では済まない「行き来・枝分かれ・差し戻しのある業務」を見つけられるかです。
| 業務(職種) | フローの形 |
|---|---|
| 問い合わせ一次対応(営業・個人事業主) | 質問の種類を判定 → 定型で返す → 込み入った内容だけ自分に回す(枝分かれ) |
| 申請の振り分け(事務) | 内容を判定 → 条件で振り先を分ける → 不備があれば差し戻す(分岐) |
| リサーチ → 下書き → チェック(副業ライター) | 不足があればリサーチに戻る(行き来のある多段フロー) |
いずれも Before は「毎回その場の判断で手作業」、After は「枝分かれ・差し戻しを含む設計を AI に任せる構想が描ける」。ただし実際に組むにはコードが必要でエンジニアの領域です(簡単な自動化なら、まずはAIエージェント とは レベルの理解から)。共通する「最初の壁」は技術ではなく 判定基準・「戻る」条件を言葉で明確にすること——これが State と条件分岐の考え方そのものです。
まとめ|複雑なフローを状態で扱うときの選択肢・本体無料・判断軸で測る
この記事の背骨をもう一度だけ。「一直線の処理なら LangChain や直 API、行ったり来たり・ループ・状態の持ち回りが要るなら LangGraph」。これだけ覚えて帰っていただければ十分です。
LangGraph は万能の正解ではなく、状態・分岐・ループ・人間の介在が増えてきたときに思い出す「選択肢の 1 つ」です。本体は無料なので、まずは最小サンプルを 1 回動かし、そこから「本当に必要か」を判断軸で測る。この順番がいちばん無理がないと感じています。
次の一歩として、AIエージェントの作り方全体を俯瞰したい方はAIエージェント 作り方へ、Claude を使って同じくエージェントを実装する選択肢としては Anthropic 公式の Claude Agent SDK もあります。そもそも LangGraph の土台にあたる LangChain 本体の役割から押さえたい方はLangChain とはへ、基礎を固めたい方はLLM とはやAIエージェント とはへ進んでみてください。こうして身につく実装スキルを仕事にする道筋は生成AIエンジニアになるにはに地図があります。あなたのペースで、一歩ずつで大丈夫です。
よくある質問
Q1: LangGraph の読み方は?
A. 「ラングラフ」と読みます。「Lang」は LangChain と同じく言語/LangChain を指し、「Graph」は点と線で表すグラフ構造を指します。
Q2: LangGraph と LangChain は、どちらを使えばいいですか?
A. 用途次第です。一直線の処理なら LangChain や直 API で足りることが多く、状態の持ち回り・条件分岐・ループ・人間の確認が必要なフローなら LangGraph が向きます。どちらが絶対に優れている、という話ではありません。
Q3: LangGraph は無料で使えますか?
A. ライブラリ本体(OSS、MIT ライセンス)は無料です。費用が関わるのは、デプロイ用の LangGraph Platform や観測用の LangSmith といった周辺サービスです。金額やプランは変更される可能性があるため、公式の料金ページでご確認ください(取得:2026-06-03)。
Q4: Python が必須ですか?
A. 本記事は Python を前提に書いています。JavaScript / TypeScript 版も存在しますが、まずは Python で最小サンプルを動かすのが分かりやすいと思います。
Q5: 未経験でも触れますか?
A. 最小サンプルなら、未経験でも動かせます。ただし、LLM・API・エージェントの基礎があると理解が早いので、不安な方は先にLLM とはやAIエージェント とはに目を通しておくのがおすすめです。
Q6: LangChain と LangGraph の違いは何ですか?
A. 一言でいうと、LangChain は部品を一方向につなぐ「部品とチェーン」、LangGraph は状態(State)を持ち回して条件分岐・ループできる「状態とグラフ」です。上位互換ではなく役割が違う別の道具で、公式ドキュメントでも「LangChain を使わなくても LangGraph は使える」と明記されています。詳しくは比較表を、LangChain 側の全体像はLangChain とはをご覧ください。
この記事は、営業出身の現役生成AIエンジニア aikun が、自身の業務経験をもとに整理しました。LangGraph は更新が速く、API の書き方・LangGraph Platform / LangSmith の料金やプラン構成は時期によって変更される可能性があります。コードや金額は、必ず公式ドキュメント・料金ページでその時点の最新情報をご確認ください。記載内容の誤りや古くなった情報にお気づきの際は、send@bon-bon-tools.com までご連絡いただけると助かります。
出典
- LangGraph 公式ドキュメント(Overview)|LangChain(取得:2026-06-03)
- LangGraph 公式ドキュメント(Graph API)|LangChain(取得:2026-06-03)
- langchain-ai/langgraph|GitHub(取得:2026-06-03)
- LangChain / LangSmith 料金ページ|LangChain(取得:2026-06-03)