LangGraphとは？LangChain・CrewAI・MAFとの使い分けと本番設計【2026年版】

最終更新：2026年5月13日
※本記事は継続的に「最新情報にアップデート」を実施しています。

---

LangGraphとは、AIエージェントの状態管理・条件分岐・HITL・中断再開・本番運用を制御するためのフレームワークです。

この記事では、LangGraphのAPIを細かく追うのではなく、実際の開発現場でLangChain、LangGraph、CrewAI、MetaGPT、Microsoft Agent Frameworkをどう使い分けるかを整理します。

単純なLLMアプリならLangChain、状態管理と本番制御が必要ならLangGraph、業務PoCならCrewAI、Microsoft環境での本番基盤ならMAFという判断軸を示します。

まず全体像：LangChain・LangGraph・CrewAI・MetaGPT・MAFの違い

これらは横並びの競合ではありません。役割と得意分野が明確に異なるため、企業の開発フェーズや目的に応じて最適なものを選択する必要があります。

現代のAIエージェント開発において、主要となる5つのフレームワークの立ち位置は以下の通りに整理できます。

• LangChain：LLMアプリの「部品箱」。モデル呼び出し、プロンプト、ツール連携、基本的なRAGを最速で組むための基礎レイヤー。
• LangGraph：状態管理と実行フローの「制御基盤」。条件分岐、ループ、HITL、中断再開など、本番運用に必要な強固な骨組みを作る。
• CrewAI：役割ベースの「AIチーム」。調査、分析、レポート作成など、業務PoCを最速で形にしたいときに強みを発揮。
• MetaGPT：ソフトウェア開発工程の「組織化」。要件定義から設計、実装、テストまでのステップをAIチームで再現することに特化。
• Microsoft Agent Framework（MAF）：Microsoft系の「本番エージェント基盤」。AzureやMicrosoft 365環境、企業統制を前提としたエンタープライズ向け。

Microsoft Agent Frameworkは、AutoGenのエージェント抽象とSemantic Kernelのエンタープライズ機能を統合したMicrosoft公式のエージェント基盤です。
一方、LangGraphはクラウドやランタイムを選ばずに状態管理・分岐・HITLを実装したい場面で有力な選択肢になります。

また、より高レベルな抽象化として、LangGraphの上に計画・サブエージェント・ファイルシステム利用などを載せたDeep Agentsも登場しています。ただし、本番エージェントの基盤としてはまずLangGraphそのものの状態管理・分岐設計を理解し、その上でDeep Agentsのような上位抽象に進む方が設計がブレにくくなります。

本記事では、その土台となるLangGraphの使いどころと本番設計に絞って解説します。

開発場面別：どんなときに何を使うべきか

実際の開発では、ツール名ではなく「どんな問題を解くのか」から選ぶべきです。単純なLLMアプリならLangChain、状態管理が必要ならLangGraph、業務PoCならCrewAI、本番のMicrosoft環境ならMAFが候補になります。

開発場面別のフレームワーク選定

開発場面	まず使うもの	理由
シンプルなチャットボットを作りたい	LangChain	モデル呼び出し、プロンプト、ツール連携だけで足りる
基本的なRAGアプリを作りたい	LangChain + RAG基盤	まず検索・生成の基本構成を作る
RAGに再検索・人間確認・例外処理を入れたい	LangGraph	分岐・状態管理・ループが必要になる
承認フロー付きの業務AIを作りたい	LangGraph	HITL、中断・再開、監査ログと相性が良い
調査・分析・レポート作成をAIチームで回したい	CrewAI	役割ベースのPoCを速く作りやすい
要件定義からコード生成までAIチームにやらせたい	MetaGPT	ソフトウェア開発工程の再現に特化している
Microsoft 365 / Azure環境で本番運用したい	MAF	Microsoftエコシステム、統制、運用との親和性が高い

LangChain vs LangGraph：LangChainの限界と導入サイン5つ

LangChainは「LLMアプリの部品をつなぐ」道具であり、LangGraphは「状態を見ながら処理を制御する」道具です。処理が複雑化し、LangChainだけで耐えられなくなったときが、LangGraph導入のサインです。

推論能力の高いLLMが普及したことで、モデル自身が複雑な手順を考えられる場面は増えています。しかし企業の本番業務では、AIの内部思考にすべてを委ねることはできません。承認、監査、権限、停止条件、再実行ポイントは、モデルの内側ではなく、外側の実行レイヤーとして明示的に設計する必要があります。

いわゆるReasoning LLM時代であっても、「考える」のはLLM、「いつ・どこまで実行させるか」を決めるのはLangGraphのような外部制御レイヤーという役割分担が基本になります。

LangChainは、モデル呼び出し、プロンプト、ツール連携、RAGなどを素早く組み立てるための優れた部品箱です。しかし、実務の業務フローにAIを組み込み、AIの振る舞いを制御・監査・永続化しようとすると、一本道の処理だけでは限界を迎えます。以下の5つの挙動が求められ始めたときこそが、実行レイヤーをLangGraphへ移行すべきサインです。

なお、LangGraphはLangChainエコシステムの一部として設計されていますが、LangChainなしでも単体利用できます。LangChainはモデル・ツール・RAG部品を素早く組み立てるための選択肢であり、LangGraphはそれらを含む処理全体を状態付きワークフローとして制御するための独立した実行レイヤーとして使えます。

v1.0以降のLangGraphは、この実行レイヤーとしての役割を明確にし、PersistenceやPlatform / Studioを通じて本番運用を前提とした機能強化が続いています。

• サイン1（状態管理）：会話履歴や途中成果などの「状態（State）」を、複雑な分岐をまたいで保持・更新したい
• サイン2（条件分岐とループ）：検索結果の信頼度に応じて「再検索」や「回答生成」へループさせたい
• サイン3（HITL / 人間承認）：外部ツール実行（メール送信や決済など）の直前で処理を一時停止し、人間の承認を待ちたい
• サイン4（中断と再開）：Checkpointerを活用し、エラー落ちや数日間の承認待ち状態からでも「その時点から再開」したい
• サイン5（本番運用の監査ログ）：どの判断ノードを経て結果に至ったか、実行経路を1ステップずつ追跡・監査したい

LangChainとLangGraphの根本的な違い

観点	LangChain	LangGraph
中心的な設計単位	Prompt, Model, Tool, Chain	State, Node, Edge, Checkpointer
向いている処理	一方向のチャット、基本RAG、単純なツール呼び出し	複雑な条件分岐、ループ処理、人間が介在するフロー（HITL）
本番運用の強み	シンプルなタスクにおける低レイテンシ実装	長期実行タスクの永続化、エラーからのレジューム、監査対応

StateGraphとは？状態・ノード・エッジの基本

StateGraphは、LangGraphにおける中心的な設計単位です。処理の途中状態を共有しながら、ノードとエッジで実行フローを定義します。

StateGraphでは、AIエージェントが扱う会話履歴、検索結果、ツール実行結果、人間承認の有無などを「State」として保持します。各処理はノードとして定義し、状態に応じて次に進むノードを切り替えます。

StateGraphの基本要素

要素	意味	実務での例
State	グラフ全体で共有する状態	会話履歴、検索結果、承認ステータス、エラー情報
Node	処理の単位	検索、回答生成、レビュー、承認依頼、ログ保存
Edge	処理の流れ	検索後に回答へ進む、失敗時に再検索へ戻る
Conditional Edge	状態に応じた分岐	信頼度が低ければ再検索、リスクが高ければ人間承認

条件分岐・ループをどう設計するか

LangGraphの強みは、状態に応じて処理を分岐できることです。検索するか、再検索するか、人間に確認するかを明示的に設計できます。

たとえば、ユーザーの質問に対して、外部検索が必要か、回答の信頼度が十分か、人間承認が必要かを状態として持たせると、AIエージェントの次の行動を制御できます。

def route(state):
    if state["needs_human_review"]:
        return "human_review"
    if state["needs_search"]:
        return "search"
    if state["is_low_confidence"]:
        return "retry"
    return "answer"

実務では、このようなルーター関数によって、AIエージェントの次の行動を状態に応じて制御します。信頼度の判定はルーター内で数値比較するのではなく、前段の「評価ノード」で is_low_confidence のようなフラグに変換しておくと、実装も運用も安定します。とくにRAGでは「検索結果の評価ノード」でこのフラグをセットし、ルーターで再検索・回答・人間承認に振り分けるのが典型的なパターンです。重要なのは、AIに自由に行動させることではなく、許可された経路の中で判断させることです。

RAGでLangGraphが効く場面

LangGraphは、RAGそのものを作るためというより、「検索するか」「再検索するか」「人間に確認するか」といった分岐制御に向いています。

単純なRAGは、質問を受け取り、検索し、回答するだけで成立します。しかし実務では、検索結果が弱い場合の再検索、回答前の人間確認、引用不足時の再生成、機密情報を含む場合の停止など、状態に応じた制御が必要になります。

このようなAgentic RAGでは、LangGraphのStateGraphを使って、検索・評価・再検索・回答・承認の流れを明示的に設計できます。具体的なRAG実装はAgentic RAGとは？AIエージェントでRAGを強化する実践ガイドで整理しています。

HITL・中断再開・再実行をどう設計するか

LangGraphの本番価値は、処理をただ流すことではなく、途中で止め、再開し、人間承認を挟み、失敗時に戻れる状態を設計できる点にあります。

AIエージェントを業務で使う場合、外部送信、削除、契約、支払い、個人情報処理などの操作を完全自動化するのは危険です。LangGraphでは、こうした高リスク操作の前に人間承認ノードを挟み、承認後に次の処理へ進める設計ができます。

また、Checkpointerを使えば、処理途中の状態を保存し、中断・再開・再実行が可能になります。これは、長期実行タスク、承認待ちタスク、エラー復旧、監査対応で重要です。

HITL・中断再開・再実行の設計ポイント

設計項目	目的	実務での例
HITL	重要操作の前に人間判断を入れる	外部送信、契約、支払い、削除、個人情報処理
Checkpointer	途中状態を保存する	承認待ち、長期タスク、障害復旧
Retry	失敗時に再実行する	検索失敗、APIタイムアウト、回答信頼度不足
Audit Log	判断と実行の証跡を残す	誰が承認し、どのツールを呼び、何を返したかの記録

AIエージェントの停止・承認・人間レビュー設計は、Guardrails / Human Reviewでも詳しく整理しています。

本番運用で見るべきログ・失敗・コスト

LangGraphを本番で使うなら、グラフの実行経路、ツール呼び出し、HITL承認、エラー、レイテンシ、コストを継続的に観測する必要があります。

LangGraph本番運用で見るべき観測ポイント

観測項目	見る理由	関連する設計
実行経路	どのノードを通ったかを追跡する	状態遷移・条件分岐
ツール呼び出し	外部APIやDBアクセスの内容を確認する	最小権限・監査ログ
HITL承認	どこで人間判断が入ったかを残す	承認フロー・責任分界
エラーと再実行	どこで失敗し、どこから再開したかを見る	Checkpointer・リトライ設計
レイテンシとコスト	LLM呼び出しや検索回数の増加を把握する	モデル選定・RAG設計

LangSmithを使うと、エージェントがどのノードを通り、どのツールを呼び出し、どのような結果を得たかをトレースできます。ただし、観測性はツールを入れれば終わりではありません。何を異常とみなし、誰が確認し、どの条件で停止するかまで設計する必要があります。

より広い本番運用・品質監視・コスト管理の考え方は、LLMOps完全ガイドで整理しています。

コード例でStateGraphの考え方だけ確認する

本記事ではコードを最小限にとどめます。重要なのはAPIの暗記ではなく、状態を定義し、ノードを追加し、条件分岐で次の行動を決めるという設計の流れです。

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

class AgentState(TypedDict):
    user_input: str
    needs_search: bool

def agent_node(state: AgentState):
    return {"needs_search": "検索" in state["user_input"]}

def search_node(state: AgentState):
    return state

def route(state: AgentState):
    return "search" if state["needs_search"] else END

workflow = StateGraph(AgentState)
workflow.add_node("agent", agent_node)
workflow.add_node("search", search_node)
workflow.add_edge(START, "agent")
workflow.add_conditional_edges("agent", route)
workflow.add_edge("search", END)

app = workflow.compile()

この短い例では、状態を定義し、ノードを登録し、ルーター関数で次の遷移先を決めています。START と END は「グラフの入り口と出口」を表す特殊ノードで、実際にはHTTPリクエストやジョブキューなどの外部イベントと接続されます。

いわば「State（状態）＋Node（処理）＋Edge（遷移）」というLangGraph特有の設計パターンを最小構成で表現したものです。実務ではここにHITL、再検索、ログ保存、Checkpointerなどを組み込みますが、基本構造は同じです。

導入チェックリスト

LangGraphを導入する前に、状態・分岐・人間承認・監査・運用の5点を確認してください。ここが曖昧なまま実装すると、本番移行で詰まります。

• 状態設計：会話履歴、検索結果、承認状態、エラー情報など、何をStateとして持つか決めたか
• 分岐設計：どの条件で検索・回答・再検索・人間承認へ進むか定義したか
• HITL設計：どの操作を人間承認必須にするか決めたか
• 再実行設計：失敗時にどこから再開するか決めたか
• 監査設計：どのログを残し、誰が確認するか決めたか
• コスト設計：LLM呼び出し回数、検索回数、再試行回数を監視できるか
• 運用設計：異常時にエージェントを止める手段を用意したか

まとめ：LangGraphは「複雑なAI処理を安全に制御する」ための基盤

LangGraphは、AIエージェントを何でも自動化する魔法の道具ではありません。状態・分岐・承認・再実行を設計し、本番で安全に動かすための制御基盤です。

単純なLLMアプリや基本的なRAGであれば、LangChainだけで十分な場面も多いです。一方で、処理が分岐し、途中で人間承認を挟み、失敗時に再実行し、実行ログを残す必要があるなら、LangGraphの出番です。

2025年以降は、海外の大規模なSaaSや金融・インフラ系エンタープライズなどで、長期ワークフローやHITL付きエージェントの実運用にも採用されるケースが増えています。

LangGraphを選ぶべきかどうかは、「AIに何をさせたいか」ではなく、「AIの行動をどこまで制御・監査する必要があるか」で決まります。

専門用語まとめ

LangGraph

処理の流れをグラフ構造で定義するAIエージェント開発用ライブラリ。複雑な条件分岐や状態管理を得意とする。

StateGraph

LangGraphにおける中心的な設計単位。共有Stateを持ちながら、ノードとエッジで処理フローを定義する。

Checkpointer / Persistence

エージェントの状態をデータベースなどに保存する仕組み。中断・再開、長期ワークフロー、障害復旧、監査対応を支える。

HITL（Human-in-the-Loop）

AIの処理途中に人間の確認・承認を入れる設計。高リスクな操作の前に人間判断を挟む。

LangSmith

LangChain / LangGraphで構築したアプリケーションの実行過程を可視化・デバッグ・評価するための観測プラットフォーム。

よくある質問（FAQ）

Q1. LangChainとLangGraphの最も大きな違いは何ですか？

A1. 状態管理とフロー制御の柔軟性です。LangChainはLLMアプリの部品をつなぐためのフレームワークで、LangGraphは処理の状態を管理しながら条件分岐・ループ・中断再開・HITLを設計するための基盤です。

Q2. どのような場合にLangGraphを使うべきですか？

A2. 条件分岐が多数ある場合、処理を中断・再開する必要がある場合、複数のAIエージェントや外部ツールを制御する場合に有効です。特にHITL、監査ログ、再実行が必要な本番向けAIエージェントで真価を発揮します。

Q3. Checkpointerは必ず使うべきですか？

A3. 短時間で完了する単純な処理であれば必須ではありません。しかし、ユーザーとの対話が続くチャットボット、承認待ちが発生する業務AI、完了までに時間がかかるタスクでは、状態を失わないために実質的に重要です。

Q4. LangGraphはRAGに必要ですか？

A4. 単純なRAGには必須ではありません。ただし、検索するかどうかの判断、検索結果の評価、再検索、人間承認、回答後の監査ログなどが必要になると、LangGraphで状態と分岐を制御する価値が高まります。

Q5. LangGraphとCrewAI、MetaGPT、Microsoft Agent Frameworkの違いは？

A5. LangGraphは状態管理・分岐・HITL・中断再開を制御する基盤です。CrewAIは役割ベースの業務PoC、MetaGPTはソフトウェア開発工程のAIチーム化、Microsoft Agent FrameworkはAzure / Microsoft 365環境での本番エージェント基盤に向いています。全体の選定はAIマルチエージェント開発フレームワーク選定ガイドで整理しています。

Q6. LangGraph PlatformやStudioは使うべきですか？

A6. 本番運用やチーム開発を前提にするなら、導入を検討する価値があります。LangGraph Platform / Studioは、グラフの実行経路、ツール呼び出し、HITL承認、エラー、コストを可視化し、テスト・デバッグ・段階的リリースを支援するマネージド環境です。小規模な検証はOSS版だけでも始められますが、複数エージェントを継続運用する中〜大規模プロジェクトでは、観測性と運用負荷の観点からPlatformやLangSmithとの組み合わせを検討するとよいでしょう。

参考サイト・出典

あわせて読みたい

更新履歴

以上