LangGraphがGitHubで3万3千スターを突破した。エージェント構築基盤としてエンタープライズ採用の本命とされるが、スター数の勢いに乗って導入を急ぐ前に問うべきことがある。本当にあなたの会社にエージェント基盤は要るのか。OSSの本命に張る前に、足元のPoC墓場を見直す方が先ではないか。辛口評論家として、この熱狂に冷や水を浴びせておく。
何が起きたか
LangChain社が提供するLangGraphが、GitHubで33,197スターに到達した。複数ステップの業務を最後までやり切るAIエージェントを構築するためのライブラリで、人間の承認をフローに挟む「human-in-the-loop」や、失敗時に処理を巻き戻す「チェックポイント」機能を備える。問い合わせ対応や社内申請のような承認フロー込みの業務に向くとされ、堅牢性の高さからエンタープライズ導入の第一候補に挙げられるようになった。LangChain本体が「プロトタイプ向け」と揶揄されてきた反省を受け、LangGraphは本番運用に耐える設計を前面に出している。スター数3.3万という数字は、Pythonエコシステムの主要OSSと比べても上位圏に入る規模で、開発者コミュニティの注目が一段ギアを上げたことを示す。
なぜこのニュースが重要か
重要だが、それは「LangGraphを今すぐ使え」という意味ではない。重要なのは、エージェント基盤の標準争いが事実上の決着フェーズに入りつつあるという構造変化だ。OpenAIのAssistants API、AWSのBedrock Agents、MicrosoftのSemantic Kernel、そしてLangGraph。どれに張るかで、今後3年間の人材調達コストと外注単価が変わる。ここで読み違えると、自社だけ独自フレームワークで塩漬けになり、エンジニア採用のたびに学習コストを払う羽目になる。スター数は人気投票でしかないが、人気投票の結果が標準を作るのもまた事実だ。さらに警告すべきは、LangGraphの「堅牢性」という売り文句を真に受けて、本来エージェント化すべきでない業務までエージェント化しようとする経営判断が出てくるリスクだ。承認フローを挟めるからといって、すべての業務にAIを噛ませる必然性はない。基盤が成熟したことと、自社でbuildすべきかは別問題である。
過剰評価への反論
ナレーションは「OSSの本命にあらかじめ張れ」と言う。だが本命がコケた事例を私は何度も見てきた。LangChain本体は2023年に同じ熱狂の中心にいたが、APIの破壊的変更を繰り返し、本番投入した企業の多くが保守地獄に陥った。LangGraphが同じ轍を踏まない保証はどこにもない。むしろ、LangChain社のビジネスモデル自体がまだ確立していない以上、有償マネージドサービスLangGraph Platformへの誘導と引き換えに、OSS側の機能が後回しになる可能性は十分ある。スター数3.3万という数字も、AIブームの追い風と、開発者の「とりあえずスター」文化を差し引いて読むべきだ。実運用に乗せている企業数とは桁が違う。
そしてもうひとつ。「失敗時に巻き戻せる仕組みがないとPoC止まり」という主張は半分しか正しくない。PoCが止まる本当の理由は、巻き戻し機構の不在ではなく、業務オーナーがAI出力の責任を引き受けたがらないという組織問題だ。LangGraphを入れてもこの壁は超えられない。技術で解ける問題と、組織で解くべき問題を混同した瞬間、また一つPoC墓場が増える。基盤選定の前に、AIの誤判定が出たとき誰が腹を切るのかを決めておけ。
経営者として次に取るべき動き
第一に、LangGraphをbuildする前に、社内に「AI誤動作時の責任者」を一人指名せよ。技術選定より先に、これが決まっていないPoCは100%死ぬ。第二に、エージェント基盤の比較表を3ヶ月以内に作成し、LangGraph・Bedrock Agents・Semantic Kernelの3つを同一業務で並行検証せよ。スター数ではなく、自社の人材プールとクラウド契約に最適なものを選ぶ。第三に、最初に任せる業務は「失敗しても顧客に直接被害が出ない、社内向けの承認フロー」に限定せよ。経費精算、稟議の一次チェック、議事録からのタスク抽出。ここで巻き戻し機能を実地で叩いた上で、外部接点の業務に広げる。順序を間違えると、最初の事故で社内のAI推進派が全員失職する。