AIエージェントフレームワーク比較2026: LangGraph vs CrewAI vs Dapr 選択基準

「どのエージェントフレームワークを使えばいいですか？」

今年に入って最も多く聞かれる質問だ。2025年までは「LangGraphかCrewAIか」程度の話だったのに、Dapr Agents v1.0がKubeCon Europe 2026でGAを発表したことで選択肢がひとつ増えた。そして3つのフレームワークすべてがv1.0以上の安定版になったため、「実験的すぎてプロダクションには難しい」という言い訳も通用しなくなった。

正直に言うと、私はこの比較記事を書くのが少し気が進まない。3つともを使ってみたが、3つとも使える。だから「Xが最高」という結論は嘘になる。代わりに「どの状況でどれがマシか」を話したい。

LangGraph v1.0 — すべてのトランジションを制御したいなら

LangGraphはエージェントを有向グラフのノードとしてモデル化する。ノードは実行単位、エッジは遷移条件、状態（state）はノード間で共有されるデータだ。このアプローチの強みは「実行フローの完全な可視性」にある。

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    next_step: str

def research_agent(state: AgentState):
    result = llm.invoke(state["messages"])
    return {"messages": [result], "next_step": "writer"}

def writer_agent(state: AgentState):
    result = llm.invoke(state["messages"])
    return {"messages": [result], "next_step": "END"}

def should_continue(state: AgentState):
    return state["next_step"]

graph = StateGraph(AgentState)
graph.add_node("researcher", research_agent)
graph.add_node("writer", writer_agent)
graph.add_conditional_edges("researcher", should_continue)
graph.add_edge("writer", END)

これはシンプルに見えるが、実際のプロダクションでは60〜100行になる。分岐条件が多くなり、状態スキーマが複雑になるほどコードは増える。これはLangGraphの弱点でもあり、同時に強みでもある。コードが長いということは制御フローが明示的だということだからだ。

実際に使って一番良かった点：LangSmithとの統合。エージェントがなぜこのノードに移動したのか、どんな状態値を持って移動したのかをトレースできる。プロダクションでエージェントがおかしな動作をした際にデバッグできるフレームワークはLangGraphだけだと感じた。

LangGraph v1.0の主な特徴：

• Durable Checkpointing: 実行中の状態を保存し、中断後に再開可能
• Human-in-the-Loop: グラフの途中に人の承認ステップを自然に挿入
• ストリーミング対応: 各ノードの中間出力をリアルタイムでストリーミング
• LangSmith統合: プロダクショントレーシングとエラー分析

残念な点もある。初期学習曲線が急だ。 TypedDictで状態スキーマを定義し、グラフ構造を頭の中で描きながらコードを書くことに慣れるには時間がかかる。またLangChainエコシステムに縛られているため、他のLLMクライアントを使いたいときはラッパー作業が必要になる。

LangGraphが適した状況：

• 承認ゲート、条件分岐、ループが複雑なワークフロー
• プロダクションでエージェントの動作を追跡・監査する必要がある場合
• チームが大きく、エージェントロジックを明示的に文書化する必要がある場合

CrewAI v1.10 — 役割ベースで素早く作りたいなら

CrewAIのコアアイデアはシンプルだ：「エージェント問題を役割とチームで考えよ。」リサーチャー、ライター、エディターをそれぞれ定義し、協力して目標を達成する。

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role='Senior Research Analyst',
    goal='Find accurate, up-to-date information on AI frameworks',
    backstory='You have 10 years of experience analyzing AI tools and frameworks.',
    verbose=True,
    tools=[search_tool, web_scraper]
)

writer = Agent(
    role='Technical Writer',
    goal='Write clear, developer-friendly comparison guides',
    backstory='You specialize in translating complex technical concepts.',
    verbose=True
)

research_task = Task(
    description='Research LangGraph, CrewAI, Dapr Agents current capabilities',
    agent=researcher,
    expected_output='Structured comparison data with key metrics'
)

write_task = Task(
    description='Write a developer guide based on research findings',
    agent=writer,
    expected_output='Complete comparison guide in markdown'
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential
)

これで30分以内に動作するマルチエージェントシステムが作れる。Claude Codeエージェントワークフローパターンで紹介した役割ベースのエージェントパターンと非常によく似たアプローチだ。

CrewAI v1.10.1で追加された機能：

• MCPネイティブサポート: MCPサーバーをツールとして直接接続
• A2A（Agent-to-Agent）プロトコル: 他のフレームワークのエージェントと通信
• ストリーミング: エージェント応答のリアルタイム受信
• 階層的プロセス: Managerエージェントが他のエージェントを指揮する構造

2026年のベンチマークでは、CrewAIはLangGraph比で開発時間40%短縮、同じ5ステップのリサーチワークフローで45秒対68秒のレイテンシ優位を示した。ただし同じ作業でトークンを約18%多く消費する。これはCrewAIのrole/backstory定義と内部プロンプトオーバーヘッドが原因だ。

CrewAIの限界として正直に感じた点：失敗シナリオの処理が弱い。 エージェントが例外を投げると、クルー全体が止まるか、想定外の方向で再試行する。プロダクションでここが最も不安だった。LangGraphの条件エッジのように失敗を捕捉して別のノードにルーティングする仕組みがない。

また、メモリ管理がクルー単位のため、長時間実行エージェントには向かない。一日以上動き続けるエージェントが必要なら、最初からDaprかLangGraphを選んだほうがいい。

CrewAIが適した状況：

• 素早くプロトタイプを作る必要がある場合
• 役割が明確に定義されたワークフロー（コンテンツパイプライン、カスタマーサポートトリアージ等）
• チームがAIエージェントに不慣れで、直感的なAPIが必要な場合

Dapr Agents v1.0 — Kubernetesで生き残らなければならないなら

Dapr Agentsは哲学が違う。LangGraphやCrewAIが「エージェントをどう賢くするか」を考えるなら、Dapr Agentsは「エージェントをどう生かし続けるか」を考える。

2026年4月時点のMCPプロダクション環境調査では、2,181エンドポイントのうち52%がデプロイ後に死亡状態だったという数字を見た。Dapr Agentsが存在する理由はこの数字にある。

from dapr_agents import Agent, tool
from dapr_agents.workflow import AgentWorkflow

@tool
def search_documentation(query: str) -> str:
    """Search technical documentation"""
    return search_api.search(query)

@tool
def create_ticket(title: str, description: str) -> str:
    """Create a support ticket"""
    return jira_api.create(title=title, description=description)

# Daprのdurable workflowの上で実行
workflow = AgentWorkflow(
    agents=[
        Agent(name="triage", tools=[search_documentation]),
        Agent(name="creator", tools=[create_ticket])
    ],
    workflow_id="support-pipeline-001"
)

# ノードが再起動されても workflow_id で状態を復元
result = await workflow.run("Handle customer support ticket #4521")

核心的な差別点はワークフローIDだ。プロセスが死んでも、Podが再起動しても、同じworkflow_idで実行すると中断した地点から再開する。RedisやPostgreSQLなどの外部ストアに状態を保存するからこそ可能なことだ。Daprは30以上の状態ストアをプラグイン方式でサポートする。

Dapr Agents v1.0 GA分析記事で詳しく取り上げたが、核心はCNCFエコシステムとの統合だ。Prometheus、OpenTelemetry、Kubernetes RBAC — Daprをすでに使っているチームならエージェントレイヤーを追加するコストは非常に低い。

ただし、Dapr Agentsを勧めない状況も明確だ。Kubernetesをまだ使っていないチームにはオーバーキルだ。 Dapr自体のインストール、サイドカーパターンの理解、状態ストアの設定だけで週単位の作業になり得る。またPythonベースのエージェントロジックのみをサポートしており、TypeScriptやGoで直接エージェントを書くことはまだ制限されている。

Dapr Agentsが適した状況：

• すでにKubernetes + Daprを使用しているインフラチーム
• SLAが要求される24時間365日稼働の長時間実行エージェント
• エージェントの障害回復がビジネスクリティカルな環境

3フレームワーク一目比較

項目	LangGraph v1.0	CrewAI v1.10	Dapr Agents v1.0
コード複雑度	高（60〜100行）	低（20〜30行）	中（40〜60行）
学習曲線	急	緩やか	中（Dapr知識が必要）
プロトタイプ速度	遅い	速い（40%優位）	中
プロダクション耐久性	高い	中	最高（durable workflow）
長時間実行	可能	不適	最適
可観測性	LangSmith統合	基本ログ	OpenTelemetry完全統合
Kubernetes依存	なし	なし	強い
MCPサポート	外部ツール経由	v1.10.1ネイティブ	プラグイン方式
A2Aプロトコル	計画中	v1.10.1対応	ネイティブ
トークンオーバーヘッド	低	中（+18%）	低

自分の基準で選ぶ方法

フレームワーク選択を聞かれたとき、私は3つの質問を投げかける。

1. 今すぐ動くものが必要か、それとも6か月後も生きていることが必要か？

今すぐならCrewAI。6か月後が重要ならLangGraphかDapr。その2択は次の質問で分かれる。

2. Kubernetesをすでに運用しているか？

YesならDapr Agentsを真剣に検討してほしい。Daprがすでにデプロイされていれば、エージェントレイヤーの追加コストはほぼゼロだ。NoならLangGraph。

3. エージェントワークフローに条件分岐とループが多いか、それとも順序的な役割分担か？

前者ならLangGraphのグラフモデルが必要だ。後者ならCrewAIとDapr Agentsのどちらでも問題ない。

私は現在、このブログの自動化システムでLangGraphベースのアプローチを最も参考にしている。Stripeが1,300件のPRを自律エージェントで処理した事例を見ると、複雑な分岐処理が必要な箇所でグラフベースのアプローチを選んでいる。グラウンドトゥルースは常に「どのフレームワークを使うか」ではなく「どう使うか」にある。

マイグレーション戦略 — 素早く始めて必要な部分だけ強化する

3つすべてから最初に選ぶのが負担なら、この順序が現実的だ。

Phase 1: CrewAIで素早くプロトタイプ（1〜2週間） Phase 2: 失敗が多かったり複雑な分岐が必要な部分をLangGraphでリファクタリング（2〜4週間） Phase 3: SLAが要求される長時間実行エージェントをDapr Agentsへ移行（必要に応じて）

CrewAIはLangChain互換なので、LangGraphと混用できる。これが段階的な移行を可能にする重要な特性だ。最初からすべてを決めなくてもいい。

結論 — 正解はないが基準はある

率直に言って、2026年基準で3つのフレームワークはすべてプロダクションで使える。LangGraph v1.0、CrewAI v1.10.1、Dapr Agents v1.0 — すべてGAを発表した安定版だ。

私が強く言えることはひとつだ：MCPと統合されていないエージェントシステムを運用中なら、今が見直しのタイミングだ。 CrewAIがv1.10.1でMCPをネイティブサポートしたことで、エージェントフレームワークと外部ツールエコシステムの境界が急速に崩れつつある。

どのフレームワークを選んでも、経験から言える共通のアドバイスはひとつだ：状態管理戦略から先に決めよ。 エージェントがどこで状態を読み、どこに書くか、失敗時にどう復元するか — これをフレームワーク選択より先に決めておくと、後から変更するコストが下がる。