LangChainが開発する agent framework「LangGraph」のGitHubスターが31,623に到達した。「多段ワークフロー」「失敗時の自動復旧」「TypeScript対応」を売りに、企業の本番運用で標準化しつつあると喧伝される。だが、スター数の急増は採用の証拠ではなく、注目の証拠に過ぎない。前作LangChainが辿った「PoCでは輝き、本番で破綻する」轍を、LangGraphは本当に避けられるのか。
何が起きたか
langchain-ai/langgraph のスター数が3.1万を超えた。LangGraphは、LLM agentを「ノードとエッジで構成されるグラフ」として記述するためのフレームワークだ。問い合わせ対応、リサーチ、コード生成といったマルチステップのタスクを、状態機械のように設計できる。途中で例外が発生してもチェックポイントから再開できる「durable execution」を特徴とし、TypeScript版もリリース済み。
提唱されている要点は、業務AIが単発のchat応答からワークフロー型へ移行していること、失敗時の自動復旧が本番運用の決め手になること、TypeScript対応で社内エンジニアが扱いやすいこと、の三点に集約される。表層的には、確かに合理的な訴求である。
なぜこのニュースが重要か
重要なのは、LangGraphそのものよりも「agent framework市場が成熟フェーズに入った」というシグナルだ。2023年のLangChain熱狂、2024年のCrewAI・AutoGenブーム、そして2025年以降のOpenAI Agents SDK、Anthropic純正のagent SDK、Google ADKの登場。プレイヤーは出揃い、各社が「durability(耐久性)」「observability(可観測性)」「human-in-the-loop」といった、PoCを越えるための地味な機能で殴り合うフェーズに入った。
つまり、派手なデモ動画でアテンションを取る時代は終わり、SREやプラットフォームエンジニアが評価指標を握る時代になった。LangGraphのスター急増は、その潮目を象徴している。
過剰評価への反論：スター数は採用ではない
ここから辛口に行く。
第一に、GitHub starsは「ブックマーク」であって「production deployment」ではない。LangChain本体は10万スターを超えてなお、本番運用で「抽象化が深すぎてデバッグできない」「breaking changeが多すぎる」と批判され続けてきた。Octomind社が2024年にLangChainを捨てた経緯をブログで公開したのは記憶に新しい。LangGraphはその反省から生まれた弟分だが、DNAは同じだ。抽象化レイヤーが薄くなったとはいえ、フレームワークに乗ること自体のロックインリスクは消えていない。
第二に、「durable execution」は新しい概念ではない。Temporal、AWS Step Functions、Airflow、Prefect——ワークフロー耐久性は10年以上前から成熟領域だ。LangGraphの「checkpoint & resume」は、これらの分散ワークフロー基盤と比べて運用ノウハウが圧倒的に薄い。本番でPostgresのcheckpoint storeが詰まったとき、社内に対応できるエンジニアはいるか。Temporal経験者を雇うほうが現実的、というケースは多いはずだ。
第三に、TypeScript対応を「web系エンジニアでも導入しやすい」と読むのは早計だ。agent開発の難所は言語ではなく、prompt engineering、評価設計、コスト管理、そしてLLM自体の非決定性にある。TypeScriptが書けることと、agentを本番で安定稼働させられることの間には、グランドキャニオン級の谷がある。
第四に、最大の競合は同業フレームワークではなく、「フレームワークを使わない」選択肢だ。OpenAIやAnthropicのSDKは year-on-yearで高機能化しており、tool calling、構造化出力、parallel execution、prompt cachingまで純正で揃う。シンプルなloopで十分なケースで、LangGraphの状態機械を持ち出すのはオーバーエンジニアリングである。Anthropicが自社ブログで「Building effective agents」と題し、「多くのユースケースでフレームワークは不要」と明言したのは、業界への重要な警告だった。
経営者が取るべき現実的な動き
スター数に煽られて「うちもLangGraphで内製agent基盤を」と号令をかけるのは、最も避けるべき判断だ。代わりに、次の順序で意思決定すべきである。
一つ、業務の切り分けを先にやる。 自動化したいのが「定型ワークフロー」なのか「探索的なreasoning」なのかで、必要な道具は変わる。前者ならTemporalや既存BPMに LLM nodeを足すほうが安全だ。LangGraphが効くのは、明確に後者の領域である。
二つ、PoCと本番運用を別予算で扱う。 LangChain系の失敗事例の多くは、PoCで動いたコードをそのまま本番に上げて崩壊している。本番投入時には、observability(LangSmith等)、評価パイプライン、コストモニタリング、人間によるreview gateを別途設計する。これらの工数はagent本体の3〜5倍を見ておくべきだ。
三つ、ロックインを最小化する設計を要求する。 LLM呼び出し部分、tool定義、prompt管理は、フレームワーク非依存な形で抽象化しておく。LangGraphがbreaking changeを連発しても、あるいは2027年に別のフレームワークが覇権を握っても、コア資産は移植可能にしておく。これはLangChain時代に多くの企業が学んだ、痛い教訓である。
四つ、「フレームワークを使わない選択肢」を必ず比較対象に入れる。 ベンダー提案やエンジニアの推薦を鵜呑みにせず、「素のSDK + 100行のorchestrationコード」で同じことができないか、必ず検証させる。できるなら、そちらのほうが長期的に保守可能だ。
LangGraphは優れたフレームワークだ。だがスター数3.1万は「みんなが試している」という意味であって、「みんなが成功している」という意味ではない。この区別を見失った瞬間に、また一つPoC墓場が増える。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。