LangChain と LangGraph とは
LangChainは、LLMアプリケーションを構築するための、MITライセンスのPythonおよびJavaScriptフレームワークです。同じチームによるLangGraphは、ステートフルなエージェント向けの低レベルなオーケストレーションフレームワークで、グラフをコードで定義します。障害後に再開できる永続的な実行と、エージェントの状態を確認・変更できるヒューマン・イン・ザ・ループのチェックポイントを備えます。LangSmithはトレーシング、評価、オブザーバビリティのための商用製品で、LangSmith Deploymentは長時間稼働するエージェントをホストします。連携の範囲はエコシステム内で最も広いものです。
ライブラリかプラットフォームか、という問題です
EDDIは競合するフレームワークではありません。EDDIは内部で、LangChainのJava版であるLangChain4jを使用しています。本当の問いは、どちらの抽象化が優れているかではありません。制御フローを、LangGraphのグラフとして自分で書くコードに置くのか、デプロイする宣言的な設定に置くのか、そしてその周辺（REST層、認証、テナンシー、状態、監査、非開発者が使うインターフェース）を誰が構築し所有するのか、という点です。
構築するものとデプロイするもの
| 観点 | LangChain / LangGraph | EDDI |
|---|---|---|
| 提供形態 | アプリケーションにインポートするライブラリ | デプロイ可能なミドルウェア。Dockerが動く場所ならどこでも稼働 |
| オーケストレーションのロジック | リポジトリ内のPythonまたはTypeScriptのグラフ | JSON設定と決定論的なBehavior Rules。再デプロイなしで変更可能 |
| ヒューマン・イン・ザ・ループ | インタラプトで状態を確認・変更できる。承認UIとポリシーは自分で構築 | ターン、ツール呼び出し、グループのフェーズにゲートを設け、タイムアウトポリシー、ManagerとSlackでの承認を備える |
| 耐久性 | 設定した永続化による永続的な実行 | プラットフォームが永続化する会話メモリ。AWAITING_HUMANなどの明示的な状態 |
| REST APIとルーティング | 自分で構築、またはLangSmith Deploymentでホスト | 標準搭載。OpenAPI 3.1、A2Aプロトコル、SSEストリーミングにも対応 |
| 認証とRBAC | 自分で構築 | オプションのOIDC/Keycloakと、eddi-adminおよびeddi-approverロール |
| 非開発者向けインターフェース | 自分で構築（LangSmith Studioは開発者向け） | EDDI Manager。11言語に対応した本番品質のReact UI |
| シークレット管理 | 自分で構築、またはVaultを持ち込む | 組み込みのAES-256-GCM Secrets Vault。${vault:key}として参照 |
| オブザーバビリティ | LangSmith（商用）または独自の計装 | Prometheusメトリクスと、自動プロビジョニングされるGrafanaダッシュボード |
| 監査とコンプライアンス | 自分で構築 | HMAC署名付き、追記専用、連番検証付きの監査台帳、データ主体の権利API、15+のフレームワークに対応 |
| 反復のサイクル | コードを変更し、レビューし、テストし、デプロイする | UIまたはAPIで設定を変更。即時に反映 |
| 制御の上限 | 上限なし。コードで表現できることはすべて可能 | 設計上、設定で表現できる範囲に限られる |
他ツールに関する内容は、2026年10月時点の公式ドキュメントとリポジトリで確認しています。これらのプロジェクトは変化が速いため、判断する前にベンダーに最新の挙動をご確認ください。
選び方
LangChain と LangGraph が適している場面
- オーケストレーションそのものが競争優位であり、設定ストアではなくコードベースに置くべき場合。
- カスタムのグラフ構造、独自のリトライ動作、特殊なステートマシンなど、宣言的な設定では表現できない制御フローが必要な場合。
- PythonまたはTypeScriptのチームで、エージェントを既存サービスの外ではなく内部に置きたい場合。
- 新しい連携が登場したその週に使いたい場合。LangChainはどのプラットフォームよりも速く進化します。
- チームが1、2名のエンジニアで、コンプライアンス担当者もテナンシーの要件も、アクセスを必要とする非開発者もいない場合。
EDDIが適している場面
- Day 2オペレーションの項目が、チームが製品開発の代わりに行っている作業だと感じる場合。
- プロンプトエンジニアや運用担当者が、プルリクエストなしでエージェントの挙動を変更する必要がある場合。
- 複数のチームや顧客が1つのデプロイを共有し、分離、クォータ、コストの帰属が必要な場合。
- 出荷前に、調達部門が監査証跡、データ所在地、フレームワークのカバレッジについての回答を求める場合。
- オーケストレーション層を、保守するコードベースではなく、アップグレードする依存関係にしたい場合。
LangChain または LangGraph からのアプリケーション移行
ロジックは多くの場合そのまま活かせます。保守しなくて済むようになるのは、その周辺のインフラです。チェーンまたはグラフの定義から外側に向かって作業を進めます。任意のPythonに依存する制御フローは、Behavior Rulesまたは宣言したツールに置き換える必要があります。
| LangChain / LangGraph | EDDI |
|---|---|
| チェーンまたはLangGraphのグラフ | EDDIのパイプライン設定とBehavior Rules |
| ツールと関数呼び出し | MCPツール定義またはhttpCall宣言 |
| 人手レビューのためのインタラプト | PAUSE_CONVERSATIONルール、またはtoolApprovalsのglob。ManagerまたはSlackで承認 |
| チェックポインターとメモリのクラス | step、conversation、longTermの各スコープを持つ会話メモリ |
| リトリーバーとベクトルストアの設定 | 8の埋め込みプロバイダーと6のベクトルストアにまたがるRAG設定 |
| プロンプトテンプレート | バージョン管理されたプロンプトスニペット。名前で参照 |
| FastAPIラッパー | 組み込みのREST API、OpenAPI 3.1、SSEストリーミング |
| LangSmithのトレーシング | Prometheusメトリクス、Grafanaダッシュボード、監査台帳 |
よくある質問
EDDIはLangChainを使っていますか？
EDDIは内部でJava実装のLangChain4jを使用しています。これは競合する抽象化ではありません。EDDIは、この種のライブラリを中心に構築されたデプロイ可能なプラットフォームであり、ライブラリが意図的に利用者に委ねているAPI層、認証、状態管理、管理UI、コンプライアンス基盤を提供します。
LangChainとLangGraphの違いは何ですか？
LangChainは、LLMアプリケーション向けのコンポーネントと連携を提供します。LangGraphは、グラフとして定義するステートフルで長時間稼働するエージェント向けの、より低レベルの層で、永続的な実行とヒューマン・イン・ザ・ループのチェックポイントを備えます。どちらも自社のサービスに組み込むライブラリです。EDDIとの比較は両方に当てはまります。
Day 2オペレーションのギャップとは何ですか？
Day 1は、エージェントが正しく応答するようにすることで、ライブラリはこれをうまく扱います。Day 2はその後のすべてです。認証、マルチテナンシー、再起動をまたぐ会話状態、監査ログ、シークレットのローテーション、水平スケーリング、コスト追跡、そしてPythonを書かない人のためのインターフェースがあります。チームは、エージェント本体よりもDay 2に多くの時間を費やすのが常です。
設定はコードより表現力が低いのですか？
はい。そしてこのトレードオフは意図的です。設定は、コードにできるすべてを表現することはできません。その代わりに、再デプロイなしの変更、非エンジニアでもレビューできる挙動が得られ、セキュリティレビューで守るべき実行時のコード実行もありません。コードが提供する上限が必要なら、ライブラリを使ってください。
LangChainを使い続けながらEDDIも使えますか？
はい。EDDIはMCPサーバーとREST APIを公開しているため、LangChainアプリケーションはEDDIのエージェントをツールとして呼び出せます。また、EDDIはhttpCall経由でLangChainのサービスを呼び出せます。差別化の源泉となる部分とインフラの部分で分担する設計は、妥当な選択です。