LangGraph とは｜LangChain との違いと「状態を持つエージェント」を業務目線で整理

「LangChain は名前を聞いたことがあるけれど、LangGraph って何が違うんだろう」。AI のフレームワーク周りは似た名前が多くて、ここでつまずく方は多いと思います。私自身、最初は両者の線引きが曖昧で、なんとなく使い分けていた時期がありました。

「LangGraph とは」は月間およそ 480 回検索されています（ラッコキーワード実測、2026年6月時点）。私は業務で LangChain / LangGraph を部分的に使っていますが、フル依存ではなく、必要な場面だけ使う立場です。結論から言うと、一直線の処理なら LangChain や直 API で足り、行ったり来たり・ループ・状態の持ち回りが必要になったら LangGraph が筋、という使い分けになります。この記事では、読み方・LangChain との違い・State とグラフ・Python の最小サンプル・料金までを、未経験のあなたにも届くように整理していきます。

とりあえず「LangGraph がどんな道具か一行だけ掴みたい」という方は、次のセクション1だけ読めば十分です。手を動かしたい方はセクション 5の最小サンプルへ、使うべきか迷っている方はセクション 6の判断軸へ飛んでみてください。

01 — 結論｜LangGraph は「状態を持つ AIエージェント」をグラフで組む道具

📖 この章で使う用語

  • LangGraph（ラングラフ）：LLM を使ったアプリで「状態を持つ・分岐する・ループする」フローを、グラフの形で組むためのフレームワーク。状況によって対応が枝分かれする商談フローのイメージ。
  • LangChain（ラングチェーン）：LLM アプリの部品（プロンプト・モデル・ツール）を直線的に連結するための、関連ツール群。レゴブロックを並べていくイメージ。
  • フレームワーク：よくある処理の「型」をあらかじめ用意してくれる土台。毎回ゼロから組まなくて済む道具箱のようなもの。
  • LLM（大規模言語モデル）：ChatGPT や Claude の正体。膨大な文章を学習した「次の言葉を予測する装置」。詳しくはLLM とはへ。

迷ったら、この一行だけ覚えてください。**「一直線の処理なら LangChain や直 API、行ったり来たり・ループ・状態の持ち回りが要るなら LangGraph」**です。

LangGraph は、公式ドキュメントでは「長く動き続ける、状態を持つエージェントを作るための低レベルなオーケストレーション（指揮）の枠組み」と説明されています（LangGraph 公式ドキュメント、取得：2026-06-03）。少し堅い言い方ですが、要は「AI に複雑な仕事を任せるとき、その仕事の流れを、行き来や枝分かれも含めて組み立てる土台」だと思ってください。

ここで先に、私の立ち位置をお伝えしておきます。私は LangChain / LangGraph を業務で部分的に使っています。メインは公式 SDK（Anthropic / OpenAI 直）と自前で組んだ流れの組み合わせで、LangGraph はそこに「状態やループが必要になった場面」で足す、という使い方です。だからこの記事は、フレームワークの全機能を網羅するチュートリアルではなく、**「使うとき・使わないときの判断軸」**を背骨にして書きます。コードの細かい仕様や Platform（後述）の細部は、公式ドキュメントを確認しながら、概論として誠実に整理する形にします。

この記事のスコープと、深掘りの送り先も先に示しておきます。

  • 概念・LangChain との違い・State とグラフ・最小サンプル・料金 → 本記事で扱います
  • AIエージェント構築の全体像（4 つの作り方の比較） → AIエージェント 作り方へ
  • RAG（外部文書を検索して回答に使う仕組み） → RAG とはへ
  • MCP（AI に外部ツールを繋ぐ標準仕様） → AIエージェント MCPへ
  • LLM そのものの基礎 → LLM とはへ

02 — LangGraph とは何か／読み方

📖 この章で使う用語

  • OSS（オープンソースソフトウェア）：ソースコードが公開され、無料で使えるソフトウェア。
  • オーケストレーション：複数の処理を「いつ・どの順で・どう連携させて動かすか」を指揮すること。オーケストラの指揮者が各楽器に合図を出すイメージ。
  • エージェント：AI が自分で手順を考えて、ツールを使いながらタスクを進める仕組み。詳しくはAIエージェント とはへ。

まず読み方から。LangGraph は 「ラングラフ」 と読みます。この記事を書くにあたって周りに聞いてみても、ここで一瞬止まる方が意外と多かったので、最初に書いておきます。

名前の由来はシンプルです。「Lang」は LangChain と同じく言語（Language）／LangChain を指し、「Graph」は後ほど出てくるグラフ構造（点と線で表す仕組み）を指します。LangChain を開発している LangChain 社が作っている OSS フレームワークで、ライセンスは MIT、無料で使えます（langchain-ai/langgraph｜GitHub、取得：2026-06-03）。

一言でいうと何の道具か

一言でいえば、LangGraph は 「LLM アプリで、状態を持つ複雑なフローを組むための道具」 です。「状態を持つ」「複雑なフロー」と聞くと身構えてしまうかもしれませんが、営業のたとえで考えるとイメージしやすいと思います。

台本どおり一直線に進む商談を思い浮かべてください。「挨拶 → ヒアリング → 提案 → クロージング」。これは LangChain が得意とする、一方向の流れです。

一方で、実際の商談はそんなに素直に進みません。「ヒアリングで予算が合わなさそうなら、提案を一段下げる」「お客様が迷っていたら、前のステップに戻ってもう一度ヒアリングする」。状況を見て枝分かれしたり、前に戻ったりします。この「状況に応じて行ったり来たりする対応フロー」を AI で組めるようにするのが LangGraph です。

03 — LangGraph と LangChain の違い

📖 この章で使う用語

  • チェーン（chain）：処理を一方向に数珠つなぎにした流れ。台本どおりに進む商談のイメージ。
  • グラフ（graph）：処理を「点（ノード）と線（エッジ）」で表した構造。行ったり来たり・枝分かれができる。
  • ステートフル／ステートレス：状態（途中経過）を覚えているか／覚えていないか。前のお客様のカゴを覚えていないレジ＝ステートレス。
  • DAG（有向非巡回グラフ）：一方向で、ぐるっと戻ってこないグラフ。LangChain のチェーンに近い構造。

ここが、この記事でいちばん伝えたいところです。結論から言うと、**LangChain は「部品とチェーン」、LangGraph は「状態とグラフ」**と捉えると、両者の役割がすっきり整理できます。

LangChain は、LLM アプリの部品（プロンプト・モデル・外部ツールの呼び出しなど）を用意して、それらを直線的に連結するための関連ツール群です。レゴブロックを順番に並べて、一本のラインを作るイメージに近いです。

LangGraph は、その上で「状態を持ち、条件で枝分かれし、ぐるっとループする」流れをグラフの形で組むための土台です。公式ドキュメントでも、LangGraph は LangChain より低い層（土台側）に位置づけられていて、「LangChain を使わなくても LangGraph は使える」と明記されています（LangGraph 公式ドキュメント、取得：2026-06-03）。つまり、片方がもう片方の上位互換というより、役割が違う別の道具だと捉えるのが正確です。

比較表で整理する

観点LangChainLangGraph
処理構造チェーン（一方向の連結）グラフ（行き来・枝分かれ・ループ可）
状態管理基本は持ち回らないState として持ち回る（ステートフル）
ループ・分岐苦手（一直線が前提）得意（条件分岐・繰り返しを組める）
向く用途一本道の処理の組み立て複雑なエージェント・人間の介在が要るフロー
学習コスト比較的とっつきやすいグラフの概念に慣れる必要がある

※両者とも頻繁にバージョンが更新されるため、細かい機能の対応状況は公式ドキュメントで都度ご確認ください（取得：2026-06-03）。

私の判断軸：どちらを使うか

私の場合、ここはわりと割り切っています。一直線で済む処理なら、LangChain か、いっそ直 API（公式 SDK を直接呼ぶ）で十分だと感じています。フレームワークを挟むぶんの学習コストや依存が増えるのが見合わない場面が、実際にはけっこうあるからです。

逆に、**「途中の状態を覚えておきたい」「条件で枝分かれする」「人間の確認を一回挟みたい」「同じ処理を条件が満たされるまで繰り返したい」**といった要素が出てきたら、LangGraph に寄せると流れがきれいに整理できます。営業時代に、複雑な商談ほど「次にどう動くかを場合分けして整理したメモ」が効いたのと同じ感覚です。場合分けが多い仕事ほど、構造で持っておいたほうが結果的にラクでした。

04 — LangGraph の核｜State（状態）とノード・エッジ

📖 この章で使う用語

  • State（状態）：処理の途中経過を持ち回す入れ物。買い物カゴや、商談の進捗メモのイメージ。
  • ノード（node）：グラフの中の「1 つの処理ステップ」。電車の駅のイメージ。
  • エッジ（edge）：あるノードから次のノードへ進む「線路」。条件によって行き先が変わることもある。
  • 条件分岐：状態を見て「次はこっちへ」と進路を決める枝分かれ。

LangGraph を理解する鍵は、State（状態）・ノード・エッジの 3 つです。ここを押さえると、後のコードがぐっと読みやすくなります。公式ドキュメントでも「グラフを定義するとき、最初にやるのは State を決めることだ」と説明されています（LangGraph 公式ドキュメント（Graph API）、取得：2026-06-03）。

State（状態）とは何か

State とは、処理の途中経過を持ち回す入れ物です。買い物カゴを想像してください。商品を1つカゴに入れ、別の棚でもう1つ入れ、レジに着くころにはカゴの中身が増えています。この「カゴ」が State です。

AI のフローでも同じで、「ユーザーの質問」「途中で調べた情報」「これまでのやり取り」などを State に入れて持ち回ります。各ステップは、このカゴの中身を見て次の動きを決め、必要なら中身を足していきます。状態を持ち回せる＝**処理が前のステップを「覚えていられる」**ということです。

ノードとエッジ

ノードは、グラフの中の 1 つの処理ステップ です。電車の駅をイメージしてください。「質問を受け取る駅」「AI に答えさせる駅」「結果を整える駅」のように、それぞれの駅で1つの仕事をします。

エッジは、駅と駅をつなぐ 線路 です。「この駅の次はこの駅へ」という進む先を指定します。面白いのは、条件によって線路を切り替えられるところです。「State の中身がこうなら A の駅へ、そうでなければ B の駅へ」と、状況を見て進路を分けられます。これが、LangGraph が「枝分かれ・ループ」を扱える正体です。

グラフの可視化（「グラフ 出力」）

組んだグラフは、図として出力して目で確認できます。「どの駅から、どの条件で、どの駅へ向かうのか」を線でつないだ路線図のようなものが出せる、というイメージです。フローが複雑になるほど、頭の中だけで追うのは大変になるので、図にして「ここで戻る線が抜けていた」といった抜け漏れに気づけるのはありがたい仕組みです（出力形式の詳細は公式ドキュメントを参照、取得：2026-06-03）。

05 — Python で最小サンプル｜状態を持つ簡単なグラフを動かす

📖 この章で使う用語

  • pip：Python のライブラリ（部品）を入れるための道具。アプリストアからアプリを入れる感覚に近いです。
  • TypedDict：Python で「この入れ物には、この名前でこの型の値が入る」と決めておく書き方。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 を実際に呼ぶサンプルにする場合は、別途 API キーの準備が必要です。今回は 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 らしさの体感）

最小グラフだけだと、正直「これなら関数を順番に呼ぶだけで良くない？」と感じるかもしれません。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回動かす」を起点にすると、その後の理解が一気にラクになりました。

06 — 使うとき・使わないときの判断軸｜直 API + 自前実装との比較

📖 この章で使う用語

  • 直 API：Anthropic / OpenAI などの公式 SDK を直接呼ぶこと。フレームワークというラッパ（包み）を挟まない方法。
  • 自前パイプライン：フレームワークに頼らず、必要な処理だけを自分のコードで組んだ流れ。
  • オーバーエンジニアリング：必要以上に複雑に作り込んでしまうこと。

ここが、私がいちばん自分の言葉で語れる部分です。先にお伝えしたとおり、私の業務での主軸は公式 SDK（直 API）+ 自前で組んだ流れで、LangGraph はそこに「必要になったら足す」という関わり方をしています。フル依存ではなく、適材適所です。

「LangGraph を学ぶなら、全部 LangGraph で組むべき」と身構える必要はないと思っています。大事なのは、いま組もうとしている処理に、LangGraph が向いているかどうかを見極めることです。

LangGraph に寄せると楽になる場面

私の感覚では、以下のような要素が出てきたら、LangGraph に寄せたほうが流れが整理できて結果的にラクでした。

  • 状態を持ち回したい：途中の調査結果ややり取りを覚えておきたい
  • 条件で枝分かれする：State の中身を見て進路を分けたい
  • ループが必要：条件を満たすまで同じ処理を繰り返したい
  • 人間の確認を挟みたい：途中で一回、人が承認するステップを入れたい
  • チームで共通の型が欲しい：複数人で触るとき、流れの組み方を揃えておきたい

特に「人間の確認を一回挟む」フローは、自前で書くと意外と煩雑になりがちなので、こうした土台に乗せる価値を感じやすい場面です。

直 API + 自前実装で足りる場面

一方で、以下のような場合は、無理にフレームワークを挟まず直 API + 自前実装で十分なことが多いです。

  • 一直線の処理：「入力 → AI に投げる → 結果を整える」で完結する
  • 薄い処理：AI を1〜2回呼ぶだけで、複雑な状態管理がいらない
  • 学習コストが見合わない：使う場面が限定的で、フレームワークを覚えるコストのほうが重い

私の場合、ちょっとした業務の自動化なら、直 API を素直に呼ぶコードのほうが見通しが良くて、後から自分や同僚が読み返すときもラクでした。

「フル依存ではなく適材適所」の実感

正直に言うと、「LangGraph を使えば何でも良くなる」という話ではありません。むしろ、シンプルな処理にまでフレームワークを被せると、かえって複雑になってしまう（オーバーエンジニアリング）こともあります。

なので、私としては「LangGraph が絶対に必要」とは言いません。状態・分岐・ループ・人間の介在が増えてきたサインを感じたら、選択肢として思い出す。その距離感が、いまのところ自分にはいちばんしっくりきています。AIエージェントを構築する作り方には他のルートもあるので、全体像を比べたい方はAIエージェント 作り方も合わせて読んでみてください。

07 — LangGraph Studio とグラフ可視化

📖 この章で使う用語

  • LangGraph Studio：組んだグラフを目で見て、ステップごとに実行し、State の中身を確認できる可視化・デバッグ用の環境。
  • デバッグ：プログラムの不具合（バグ）を見つけて直す作業。

LangGraph には、組んだグラフを 目で見ながら確認・デバッグできる「LangGraph Studio」 という環境があります。ここからは、私が業務で常用している部分ではなく、公式情報からの整理としてお伝えします。

公式ドキュメントによると、LangGraph Studio はグラフの構造を視覚的に確認したり、ステップごとに実行して途中の State の中身を見たりできる開発支援の仕組みです（LangGraph 公式ドキュメント、取得：2026-06-03）。

イメージとしては、セクション 4で触れた「路線図」を、紙の上で眺めるだけでなく、**「実際に電車を1駅ずつ走らせて、各駅でカゴ（State）の中身を覗ける」**ような道具だと思ってください。フローが複雑になるほど「どこで意図しない動きをしているのか」が掴みにくくなるので、こうした可視化ツールの価値が出てきます。

ただし、機能の細部や最新の対応状況は更新されることがあるため、実際に使う際は公式ドキュメントで最新情報をご確認ください（取得：2026-06-03）。

08 — LangGraph の料金｜本体は無料、Platform/LangSmith は有料枠

📖 この章で使う用語

  • LangGraph Platform：LangGraph で作ったアプリを動かす・公開する（デプロイ）ためのマネージドサービス。有料枠があります。
  • LangSmith：LLM アプリの動きを記録・観測・評価する SaaS（クラウドサービス）。無料枠と有料枠があります。
  • デプロイ：作ったプログラムを、実際に動く環境に配置・公開すること。

料金について不安に感じている方も多いと思うので、先に結論をお伝えします。LangGraph 本体（OSS ライブラリ）は無料で使えます。 ライセンスは MIT で、学ぶ・自前で動かすぶんには費用はかかりません（langchain-ai/langgraph｜GitHub、取得：2026-06-03）。

費用が関わってくるのは、LangGraph 本体ではなく、その周辺のサービスです。

  • LangGraph Platform：作ったアプリを動かす・公開する（デプロイ）ためのマネージドサービス。本格的に運用する段階で関わってきます。
  • LangSmith：LLM アプリの動きを記録・観測・評価するためのサービス。無料枠（Developer プラン）から始められ、チーム向けの有料プランも用意されています。

公式の料金ページによると、LangSmith には無料から始められる Developer プランがあり、その上にチーム向けの Plus プラン（執筆時点で 1 席あたり月 $39 から、利用量に応じた従量課金）などが用意されています（LangChain 料金ページ、取得：2026-06-03）。

ただし、料金体系やプラン内容は変更される可能性があります。具体的な金額・プラン構成・無料枠の上限は、必ず公式の料金ページで最新情報をご確認ください（取得：2026-06-03）。

未経験のあなたに伝えたいのは、**「LangGraph を学ぶ・最小サンプルを動かす段階では、お金の心配はいらない」**ということです。費用が発生するのは、本格的にチームで運用・観測したくなった段階の周辺サービスからです。まずは無料の本体で、セクション 5の最小サンプルを動かすところから始めてみてもいいと思います。

09 — AIエージェント構築・RAG の中での LangGraph の位置づけ

📖 この章で使う用語

  • RAG（検索拡張生成）：外部の文書を検索して、その内容を LLM の回答に使う仕組み。詳しくはRAG とはへ。
  • MCP（Model Context Protocol）：AI に外部のツールやデータを繋ぐための標準仕様。詳しくはAIエージェント MCPへ。

ここで一度、LangGraph が「AI 開発全体の中でどこに位置するのか」を整理しておきます。読者の方が迷子にならないように、本記事のスコープと、深掘りの送り先をはっきりさせておきたいからです。

エージェント構築の実装ルートの 1 つ

LangGraph は、AIエージェントを作るときの 実装ルートの 1 つです。具体的には「Python + LangChain/LangGraph + 直 API」という組み合わせのルートにあたります。

AIエージェントの作り方には、このルート以外にも、ノーコードのツールを使うルートや、別の構築プラットフォームを使うルートなど、いくつかの選択肢があります。どのルートが自分に向いているかを比べたい方は、4 つの作り方を俯瞰しているAIエージェント 作り方を読んでみてください。本記事は、その中の「コードで組むルート」で登場する LangGraph に絞って深掘りしている、という位置づけです。

RAG・MCP・LLM との関係

LangGraph は、他の要素と組み合わせて使われることも多いです。

  • RAG と組み合わせる：外部文書の検索結果を State に持ち回りながら、複雑な回答フローを組む、といった使い方があります。RAG そのものの基礎はRAG とはへ、その「検索」を担うベクトル検索ライブラリはFAISS とはへ。
  • MCP と組み合わせる：エージェントが外部ツールを呼ぶ際の繋ぎ込みは MCP が担います。MCP の基礎はAIエージェント MCPへ。
  • LLM が土台にある：そもそも LLM が何かが曖昧な方は、先にLLM とはを押さえると、この記事全体がぐっと読みやすくなります。

クラウド基盤（AWS など）経由で AI を呼ぶ実装文脈に興味がある方は、AWS Bedrockも参考になります。

10 — つまずきポイント・失敗パターン 5 個

📖 この章で使う用語

  • （このセクションで新しく増える用語はありません。これまでに出た State・ノード・エッジ・直 API などの言葉で読み進められます。）

最後に、未経験のうちにハマりやすいポイントを 5 つ、対処とセットで挙げておきます。私自身や周りで「あ、ここでつまずくよね」と感じた順に並べました。

1. 最初から複雑なグラフを組もうとして挫折する

いきなり「分岐もループも人間の介在もある立派なエージェント」を組もうとすると、たいてい途中で迷子になります。対処はシンプルで、セクション 5のような最小グラフから始めること。1 駅・2 駅の小さなグラフを動かしてから、少しずつ駅と線路を足していくのが、結局いちばんの近道でした。

2. State に何を入れるか設計せず破綻する

State（カゴ）に何を持たせるかを決めずに書き始めると、後から「あの情報も持ち回りたかった」と崩れがちです。対処は、コードを書く前に「カゴに何を入れるか」を一度紙に書き出すこと。買い物前に買うものをメモするのと同じ感覚です。

3. LangChain と LangGraph の責務を混同する

「どっちで何をやるんだっけ」と混乱するのは、最初は誰もが通る道だと思います。セクション 3の「LangChain は部品とチェーン、LangGraph は状態とグラフ」という一行に立ち返ると、整理し直せます。

4. バージョン差で API が動かない

LangGraph は更新が速いので、ネットで見つけたコードがそのまま動かないことがあります。対処は、動かないときはまず公式ドキュメントで、自分が入れたバージョンの書き方を確認すること（取得：2026-06-03）。記事のコードは、書かれた時点の仕様であることを前提に読むのが安全です。

5. 「とりあえず LangGraph」でオーバーエンジニアリング

これは私自身も気をつけているところです。一直線で済む処理にまで LangGraph を被せると、かえって複雑になります。セクション 6の判断軸に立ち返り、「これは本当に状態・分岐・ループが要るか？」を一度自問してみてください。直 API で足りるなら、そのほうが見通しが良いことも多いです。

11 — LangGraph を、エンジニアでない人がどう捉えればいいか

📖 この章で使う用語

  • （このセクションでは、ここまでに出た「State・分岐・ループ」を、職種ごとの業務イメージに置き換えて捉え直します。新しい技術用語は増えません。）

LangGraph 自体は、コードを書くエンジニア向けの道具です。なので「非エンジニアが明日から LangGraph を使いこなす」という話ではありません。ただ、「AI に複雑な業務フローを任せる仕組みの裏側」を概念として知っておくことは、これから生成AIエンジニアを目指す方にとって確かな土台になります。

ここでは、私自身が経験のある職種を中心に、「LangGraph 的な考え方をすると、どんな業務が AI に任せられそうか」のイメージを、Before / After で示します。あくまで概念をつかむための例で、「誰でもすぐに自動化できる」という話ではない点はご注意ください。

営業職：状況で枝分かれする商談フローのイメージ

  • Before：問い合わせへの一次対応を、毎回その場の判断で手作業。
  • After：「予算を聞く → 条件で提案を出し分ける → 迷っていたら再ヒアリングに戻る」という枝分かれフローを、AI に任せる設計をイメージできる。
  • 所要時間・コストの目安：概念をつかむだけなら、この記事を読む 20 分ほど。実装は別途エンジニアの領域です。
  • 最初の壁：実際に組むにはコードが必要。まずは「分岐・ループという考え方がある」と知るところからで十分です。

事務職：申請の分岐処理のイメージ

  • Before：申請内容を見て、毎回「この場合はこっちの担当へ」と人が振り分け。
  • After：「内容を判定 → 条件で振り先を分ける → 不備があれば差し戻す」という分岐フローを、AI に組ませる発想が持てる。
  • 所要時間・コストの目安：考え方を知るだけなら追加コストはかかりません。
  • 最初の壁：判定基準を「言葉で明確にする」ところが、実は人間でも難しい部分。ここを言語化できると、AI に任せる設計に近づきます。

個人事業主：問い合わせ一次対応の分岐のイメージ

  • Before：問い合わせメールに、毎回ゼロから返信を考える。
  • After：「質問の種類を判定 → よくある質問は定型で返す → 込み入った内容だけ自分に回す」という枝分かれを AI に任せる構想が描ける。
  • 所要時間・コストの目安：概念理解は無料。簡単な自動化なら、まずはAIエージェント とはレベルの理解から。
  • 最初の壁：「自分でやるべき問い合わせ」と「任せていい問い合わせ」の線引きを決めること。

副業ライター：リサーチ→下書き→チェックの多段フローのイメージ

  • Before：リサーチ、下書き、推敲を、すべて一人で順番に手作業。
  • After：「リサーチ → 下書き → チェック → 不足があればリサーチに戻る」という、行き来のある多段フローを AI で組む発想が持てる。
  • 所要時間・コストの目安：考え方をつかむだけなら、この記事 1 本ぶん。
  • 最初の壁：「戻る」条件（どうなったらリサーチに戻すか）を自分の中で言語化すること。ここが State と条件分岐の考え方そのものです。

どの職種にも共通して言えるのは、「一直線では済まない、行き来や枝分かれのある業務」を見つけられる人ほど、LangGraph 的な発想が活きるということです。まずは概念だけ掴んでおいて、必要になったときにセクション 5の最小サンプルに戻ってくる、くらいの距離感でいいと思います。

12 — まとめ｜LangGraph は「複雑なフローを状態で扱う」ときの選択肢

最後に、この記事の背骨をもう一度だけ。「一直線の処理なら LangChain や直 API、行ったり来たり・ループ・状態の持ち回りが要るなら LangGraph」。これだけ覚えて帰っていただければ十分です。

LangGraph は万能の正解ではなく、状態・分岐・ループ・人間の介在が増えてきたときに思い出す「選択肢の 1 つ」です。本体は無料なので、まずはセクション 5の最小サンプルを 1 回動かしてみる。そこから「これは本当に必要か」をセクション 6の判断軸で測る。この順番が、私としてはいちばん無理がないと感じています。

次の一歩として、AIエージェントの作り方全体を俯瞰したい方はAIエージェント 作り方へ、そもそもの基礎を固めたい方はLLM とはや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. セクション 5の最小サンプルなら、未経験でも動かせます。ただし、LLM・API・エージェントの基礎があると理解が早いので、不安な方は先にLLM とはやAIエージェント とはに目を通しておくのがおすすめです。

この記事は、営業出身の現役生成AIエンジニア aikun が、自身の業務経験をもとに整理しました。LangGraph は更新が速く、API の書き方・LangGraph Platform / LangSmith の料金やプラン構成は時期によって変更される可能性があります。コードや金額は、必ず公式ドキュメント・料金ページでその時点の最新情報をご確認ください。記載内容の誤りや古くなった情報にお気づきの際は、send@bon-bon-tools.com までご連絡いただけると助かります。

出典

新しい記事のお知らせを受け取る → 登録（準備中）