🧠

LangGraphとは何か

に公開
AI
Model Context Protocol
LangGraph
AIエージェント
tech

― 複雑で「やり直し前提」の業務プロセスを制御するためのAIワークフレーム ―

LangGraphは、
「何度も試行錯誤する」「分岐とループが当たり前」「途中で人間が介入する」
といった 実務そのもの を、破綻なくAIシステムとして記述・実行するためのフレームワークです。

ChatGPTや単純なChainが
「質問 → 回答」で完結する ワンショット処理 を得意とするのに対し、
LangGraphは 業務フロー全体を“状態機械（State Machine）”として管理 します。

言い換えるなら、LangGraphは
AIを現場で安全に動かすための「運行管理センター」 です。

LangGraphの基本構造

まず理解すべきは、たった3つの要素

LangGraphを理解するうえで、最初に押さえるべき概念は以下の3つだけです。

  • State（状態）
  • Node（処理単位）
  • Edge（遷移ルール）

この3点を正しく捉えれば、
どれだけ複雑なエージェントでも「構造」として分解できるようになります。

1. State（状態）：システム全体の唯一の真実

LangGraphの中核は State です。
これは、グラフ全体で共有される 単一の状態オブジェクト を意味します。

直感的な理解

Stateは、
全員が共有して回し読み・書き込みを行う「一冊の業務ノート」 です。

各Nodeは、

  • ノートを読む
  • 必要な処理をする
  • 結果をノートに追記する

この流れだけを行います。

Stateに含まれる典型例

  • 会話履歴（messages）
  • 中間推論結果
  • ツール実行結果
  • ループ回数・フラグ
  • 次に進むべきノード名

なぜ重要か

LangGraphでは、
「Stateを見れば、システムの現在地が完全にわかる」
という Single Source of Truth を意図的に作ります。

これにより、

  • デバッグが容易
  • 再現性が高い
  • 暴走原因を追跡可能

という、実運用で極めて重要な特性が得られます。

実務上の注意点

Stateは必ず初期化・リセット戦略を設計する必要があります。
古い状態を残したままループさせると、
AIは「過去のノイズ」を根拠に誤判断し、自滅します。

2. Node（ノード）：責務が明確な処理単位

Nodeは、グラフ上の「点」にあたります。
本質的には Stateを入力として受け取り、Stateを部分的に更新して返す関数 です。

Nodeの役割

  • LLMに推論させる
  • 外部ツールを実行する
  • 状態を評価し、次の方針を決める
  • 人間の確認を待つ

比喩的に言うと

Nodeは、
それぞれ専門領域を持つ担当者（あるいは部署） です。

  • 調査担当
  • 判断担当
  • 出力担当
  • 監督（Supervisor）

全員が Stateという共通ノート を参照し、
自分の責務だけを果たします。

設計上の原則

  • 1 Node = 1責務
  • Node同士は直接会話しない
  • 情報共有は必ずState経由

この制約が、システム全体の可読性と保守性を保証します。

3. Edge（エッジ）：処理の流れを定義するルール

Edgeは、NodeとNodeをつなぐ「線」です。
「次にどのNodeへ進むか」 を定義します。

Edgeの種類

Normal Edge

単純な直列遷移です。

  • 「Aが終わったら必ずBへ進む」

Conditional Edge（条件付き遷移）

LangGraphの核心部分です。

Stateの内容を評価し、
どのNodeへ遷移するかを“明示的なルール”として決定 します。

重要なのは、
分岐条件はPython関数として決定論的に記述される 点です。

LLMは判断材料を生成できますが、
「どこへ進むか」を最終的に決めるのは制御ロジックです。

これにより、

  • 予測不能な分岐
  • 無限ループ
  • 説明不能な挙動

を防げます。

全体像のまとめ

LangGraphとは、要するに次の構造です。

共通のState（業務ノート）を中心に、
責務を分離したNode（担当者）が、
明示されたEdge（業務ルール）に従って処理を進めるフレームワーク

これは、
個人プレーではなく「チームプレー前提」でAIを動かすための設計思想
そのものです。

実装イメージ（最小構成）

1. State定義

from typing import TypedDict, List

class AgentState(TypedDict):
    messages: List[str]
    next_agent: str
    loop_count: int

2. Node定義

def supervisor(state: AgentState):
    # 状態を評価して次の担当を決める
    if state["loop_count"] > 3:
        return {"next_agent": "END"}
    return {"next_agent": "researcher"}

def researcher(state: AgentState):
    # 調査結果を追記
    new_messages = state["messages"] + ["天気は晴れです"]
    return {
        "messages": new_messages,
        "loop_count": state["loop_count"] + 1
    }

3. Graph構築

from langgraph.graph import StateGraph, END

workflow = StateGraph(AgentState)

workflow.add_node("supervisor", supervisor)
workflow.add_node("researcher", researcher)

workflow.set_entry_point("supervisor")

workflow.add_edge("researcher", "supervisor")

workflow.add_conditional_edges(
    "supervisor",
    lambda state: state["next_agent"],
    {
        "researcher": "researcher",
        "END": END
    }
)

4. 運用と強靭化（Ops & Resilience）

ここからは「動いた後」の話だ。実務で使うなら、ここが一番重要になる。
今回のエラー対応で学んだことを、運用ルールとして定着させろ。

(1) Stateのゴミ掃除（Cleanup Strategy）

LangGraphの永続化機能（Checkpointer）は強力だが、諸刃の剣だ。
「前回の失敗した状態」まで律儀に引き継ぐと、システムは無限に失敗し続ける。

  • 対策: 新しいセッションの開始時には、必ず主要なカウンターやフラグを初期化するロジック（loop_count = 0 など）を組み込むこと。

(2) 無限ループへの安全装置（Safeguards）

AIは平気で同じことを繰り返す。「検索結果が見つかりません」→「じゃあもう一回検索」→「見つかりません」の地獄だ。

  • 対策: Stateに必ず loop_count を持たせ、閾値（例えば15回）を超えたら強制的に FINISH させる「ブレーカー」を設置しろ。これはAIの判断ではなく、コードによる絶対的な制約として書くんだ。

(3) 死活監視と自動復旧（Self-Healing）

外部API（GeminiやGroq）は必ず落ちるものと思え。

  • 対策: エラーが出た時に単に終了するのではなく、「別のモデルに切り替えて再トライ」するロジックを組み込む。これが真の「自律エージェント」だ。

最後に

LangGraphを理解せずにエージェントを書こうとするのは、
ルールを知らずに複雑な業務を回そうとするのと同じ です。

まずは、

  • Stateを中心に考える
  • Nodeの責務を分離する
  • Edgeで制御を明示する

この3点を意識して、既存のコードを読み直してください。

そうすれば、
「なぜそのエージェントがそう振る舞うのか」
を、構造として説明できるようになります。

Discussion