LangChain と LangGraph とは？

LangChain と LangGraph は、Python向け（JavaScript も対応）のオープンソースフレームワークで、大規模言語モデル上のアプリを組み立てます。単純な RAG から、ツール・メモリ・分岐付きの AIエージェント まで。LangChain は部品（モデル、プロンプト、チェーン、リトリーバ）を提供し、LangGraph は制御・ループ・人手確認が必要な複雑なエージェントフロー向けの状態グラフです。以下では違い、選び方、ビジネス側の注意点を整理します。

• LangChain - コンポーネントライブラリ：LLM、プロンプト、チェーン、埋め込み、ベクトル検索、ツール
• LangGraph - ノードグラフによるオーケストレーション：状態、分岐、ループ、リトライ、human-in-the-loop
• チェーン（chain） - 固定パイプライン「入力 → ステップ → 回答」
• エージェント - モデル自身がツール呼び出しと停止を決める
• モデルの代替ではない - フレームワークは GPT/Claude を「賢く」しない。API・データ・ロジックをつなぐ
• 実務 - 単純な RAG/FAQ は LangChain で十分なことが多い。複雑なサポート経路やマルチエージェントは LangGraph の領域

LangChain をやさしく言うと

モデル API の一回呼び出しは「聞く → 答える」です。実プロダクトはもっと広く、ナレッジベースから文書を取り、CRM を呼び、注文を確認し、履歴を残し、トークンを数え、モデルの幻覚を抑えます。

LangChain は各プロバイダ（OpenAI、Anthropic、Gemini、ローカル LLMなど）の上の抽象で、同じ glue コードを手書きしなくてよくします。

典型的な LangChain の流れ：ユーザーが質問 → リトリーバがドキュメント断片を取得 → プロンプトが質問＋文脈を結合 → モデルが出典付きで回答。これが古典的な RAG で、多くのビジネス案件には十分です。

LangGraph とは何か、LangChain をどう補うか

LangGraph は同じ LangChain エコシステムのライブラリで、エージェントアプリをグラフとして構築します。ノードがステップを実行し、エッジが遷移を定義し、共有の 状態（state） が途中で更新されます。

チェーンがあるのにグラフが必要な理由：

1. 分岐 - 確信度が低い → 人へエスカレーション；返金希望 → 別シナリオ。
2. ループ - エージェントがツールを呼び、結果を読み、再考し、また呼ぶ。
3. 制御 - 明確な停止点、リトライ、ステップ上限；「ブラックボックス」を減らす。
4. マルチエージェント - 複数の役割（調査・編集・モデレーション）が結果を渡す。
5. Human-in-the-loop - 顧客メール送信や課金の前にオペレーター確認を待つ。

要するに：LangChain = ブロックの部品、LangGraph = 複雑な機械の組み立て図。よく併用され、グラフのノードが LangChain のモデル・リトリーバ・ツールを呼びます。

LangChain vs LangGraph：どちらを選ぶか

実務ルール：最も単純なパイプラインから始める。すでに条件とループのあるフローチャートに見えるなら、1ファイルに if を積み上げずグラフへ移る。

典型的なスタック

ビジネス向けの最小セット：

• モデル - GPT / Claude / Gemini、または Ollama 経由のローカル；
• LangChain - プロンプト、リトリーバ、ツール；
• ベクトルストア - 埋め込みと知識検索用；
• LangGraph（必要時） - エージェントと分岐のオーケストレーション；
• オブザーバビリティ - ステップログ、レイテンシ、トークン費用、エラー追跡；
• 連携 - CRM、ヘルプデスク、Telegramボット、社内DB。

重要：フレームワークはきれいなデータとプロダクト設計の代わりにはなりません。弱いナレッジ＋強い LangGraph でも弱い回答になります。RAGシステムの費用やAIエージェントの受託開発の見積もりは、ほぼ常にデータ・連携・品質管理にぶつかります。ライブラリ選択だけではありません。

プロジェクトの利点と欠点

利点：

• Python での試作が速い；
• 人気 LLM・ベクトルDBとの連携が用意済み；
• プロンプト・ツール・RAG で一貫した書き方；
• LangGraph はエージェント図を明示 - 顧客説明とデバッグがしやすい；
• エコシステムが成熟し、例と文書が多い。

欠点とリスク：

• 抽象化税：初心者が層に溺れ、実際は直 API の数十行で足りることがある；
• エコシステム API は変わる - バージョン固定と breaking changes への注意；
• ループ付きエージェントは制限なしでトークンを燃やす；
• テストと eval がないと製品が静かに劣化する；
• すべての案件にエージェントは不要 - 決定論スクリプト＋1ステップ LLM が良いことも多い。

ビジネスが必要なとき - まだ早いとき

意味がある場合：

• 自社データと API 上で RAG・アシスタント・エージェントを作る；
• チームが既に Python/JS を書き、場当たりスクリプトではなく標準骨格が欲しい；
• 分岐・人手承認・多段シナリオが必要（LangGraph）；
• 数ヶ月運用する予定 - 明示アーキテクチャが報われる。

先延ばしできる場合：

• 良いプロンプト付きの API 呼び出し1〜2回で足りる；
• 安定したナレッジや連携がない - フレームワークは空データを救えない；
• チームがまだ基本的な LLM 呼び出しと埋め込みを習得していない；
• カスタムロジックなしのノーコードチャットボットだけで足りる。

まとめ

LangChain は完成ブロックで LLM アプリを組み立てる方法：モデル、プロンプト、RAG、ツール。LangGraph は分岐・ループ・チェックポイント付きの状態グラフで複雑なエージェント論理をオーケストレーションします。FAQ と文書検索は LangChain で十分なことが多く、サポートエージェント・多段プロセス・human-in-the-loop は最初から LangGraph で流れを設計するのが合理的です。データ品質・指標・トークン予算に比べライブラリ選択は二次的ですが、正しい骨格は何ヶ月もの混乱コードを省きます。

よくある質問

LangChain と LangGraph は別製品？それとも一体？

つながったエコシステムです。LangChain が部品、LangGraph が複雑なフローのオーケストレーションを担当します。別々にも使えますが、実務ではグラフノードが LangChain のモデルとツールを呼ぶことが多いです。シナリオが複雑になったら「部品＋設計図」で考え、「どちらか一方」にこだわらない方がよいです。

普通の RAG に LangGraph は必要？

必ずしも必要ではありません。 古典的 RAG（質問 → 検索 → 回答）は LangChain、あるいは直 API＋ベクトルDBでも十分です。RAG の上に分岐、再質問、複数エージェント、検証ループ、必須の人手承認が出てくるときに LangGraph の価値が上がります。

LangGraph エージェントと「ChatGPTを呼ぶだけ」の違いは？

ChatGPT の一回呼び出しは、1つのコンテキストウィンドウ内のモデル回答です。LangGraph エージェントはツールを何度も呼び、状態を更新し、条件で分岐し、オペレーター待ちで止まれます。通常のチャットより、LLM を内蔵したワークフローエンジンに近いです。

Python と JavaScript、どちらがよいか？

バックエンド、データパイプライン、エコシステムの例は Python が多いです。エージェントがサイトの Node スタック隣にあるなら JavaScript/TypeScript が合います。機能は似ています。チーム言語と、LLM を埋め込むサービスを基準に選んでください。

LangChain / LangGraph 導入の費用は？

フレームワーク自体はオープンソースです。費用はモデルAPI、インフラ（ベクトルDB、ホスティング）、開発・運用です。RAG プロトタイプは数日と控えめなトークン予算で足りることがあり、CRM・監視・eval 付きの本番エージェントは数週間のプロジェクトで、エージェント予算も目立ちます。最大の隠れコストは無制限ループと膨らんだコンテキストです。