8月7日、LangChainが「Deep Agents vs LangChain vs LangGraph」と題した記事を公開した。「どのフレームワークを使えばいいのか」という混乱に終止符を打つべく、LangChain自身が明快な答えを出した——まずDeep Agentsを使え。複雑なワークフローや完全な制御が必要になったとき初めて、LangChainやLangGraphに手を伸ばせばいい。この記事では、3つのフレームワークの役割の違いと具体的な使い分けについて詳しく解説されている。
3層構造で理解するLangChainのエージェントスタック
LangChainのエージェント構築ツールは現在、以下の3層で構成されている。
- LangGraph:グラフベースのエージェントランタイム(最も低レベル、最も高い制御性)
- LangChain:エージェントフレームワーク(抽象化とインテグレーション層)
- Deep Agents:エージェントハーネス(最も高レベル、すぐに使える)
「ランタイム」「フレームワーク」「ハーネス」という区分が核心だ。3つは完全にコンポーザブル(組み合わせ可能)であり、排他的な選択ではない。
「まずDeep Agentsから始めよ」という結論
記事が最初に伝えたいことはシンプルだ。
Rule of thumb
Start with Deep Agents. It's a very powerful agent harness with all of the bells and whistles included. When you need to model a complex workflow or want complete control of every step, reach for LangChain and LangGraph.
Deep AgentsはClaude CodeやManusに触発された汎用エージェントハーネスで、コンテキストエンジニアリング(モデルに適切なタイミングで適切なコンテキストを渡すこと)のベストプラクティスを標準搭載している。
主な標準機能は次のとおりだ:
- Filesystem:コンテキストウィンドウに直接載せたくないデータの読み書き
- Subagents:メインのコンテキストを肥大化させずに専門的な処理を委任
- Skills:エージェントがオンデマンドで読み込める手順書やスクリプト
- Memory:実行をまたいだ学習と改善
セットアップはcreate_deep_agent一発で済む:
from deepagents import create_deep_agent
agent = create_deep_agent(
model="anthropic:claude-sonnet-5",
tools=[web_search],
system_prompt="you are a research agent...",
skills=["./skills/"],
)
LangChain自身のGTMエージェント(営業支援)もDeep Agentsで構築されており、週約1万リクエスト、150名以上のアクティブユーザーを処理している。トラフィックの74%はスケジュール実行やイベントトリガーによるアンビエント実行だという。
まとめ:選択の基準
| ケース | 選択 |
|---|---|
| とにかく強力なエージェントをすぐ動かしたい | Deep Agents |
| シンプルなループ+自前のコンテキスト管理 | LangChain |
| LLMと固定コードを混在させた複雑なワークフロー | LangGraph |
3つはコンポーザブルなので、create_deep_agentの中でカスタムLangGraphワークフローをサブエージェントとして動かす、といった組み合わせも可能だ。
LangChainとLangGraphはどこで使うか
LangChain:シンプルなループが欲しいとき
LangChainのcreate_agentは、「LLMがループしながらツールを呼ぶ」という最小限のエージェントループを提供する。Deep Agentsのような豊富なコンテキスト管理機能は持たないが、その分だけ余計な抽象化がない。
from langchain.agents import create_agent
agent = create_agent(
model="anthropic:claude-sonnet-5",
tools=[send_email],
prompt="you are my email assistant...",
middleware=[...]
)
RAGを使ったドキュメントQ&Aボットのように、「ベクトルストアを検索して回答を返す」程度のシンプルなフローならLangChainで十分だ。サブエージェントやファイルシステムは不要なケースがこれにあたる。
また、LangChainにはミドルウェアという仕組みがあり、コアのエージェントループに承認ステップやコンプライアンスチェックなどの確定的な処理を差し込める。Deep Agentsの各機能は、実はこのLangChainエージェント+ミドルウェアの組み合わせで実装されている。
LangGraph:決定論的なステップが必要なとき
LangGraphはグラフ構造でワークフローを定義する。LLMを使う箇所と固定コードを使う箇所を明示的に分けられるのが特徴だ。
記事では賃貸審査パイプラインを例に挙げている:
- 申請書から収入・信用・賃貸履歴を抽出(LLM使用)
- 家主の基準でスコアリング(固定コード)
- 明確な合格者を自動承認、不合格者を却下、境界事例を人間にエスカレーション(固定コード)

LLMはステップ1だけで、残りは決定論的な処理だ。このように「一部だけLLMを使いたい」複合ワークフローがLangGraphの本領だ。
決定論とエージェント性のトレードオフ
3つのフレームワークは「決定論(確実性)」と「エージェント性(自律性)」のスペクトラム上に並んでいる。

- LangGraph:最も決定論的。グラフのトポロジーにドメイン知識を直接エンコードする
- LangChain:中間。コアループは非決定論的だが、ミドルウェアで確定的なステップを挿入できる
- Deep Agents:最も自律的。要約やサブエージェントにより長時間・大規模に実行できる
自律性が高いほど潜在的な価値は大きくなるが、信頼性とのトレードオフが生まれる。センシティブなワークフローや繰り返し処理には決定論の方が適している、というのが記事の見立てだ。
デプロイと監視はどれを選んでもLangSmithで対応できる。
詳細はDeep Agents vs LangChain vs LangGraphを参照していただきたい。