2026年のエージェントフレームワークを取り巻く環境は、2年前より成熟しましたが、選択が明快になったわけではありません。LangChain/LangGraphは依然として優勢ですが、その妥当性を問う声は増えています。CrewAIは独自の地位を築きました。Pydantic AIは型安全性によって支持を集めています。OpenAIのAgents SDKとAnthropicのClaude SDKも普及しつつあります。そして特に本番環境では、直接API呼び出しへ回帰するチームが静かに増えています。
どのフレームワークにも支持者と批判者がいます。議論は盛んですが、選択は客観的というより個人的なものになりがちです。
この記事では、実務に携わるアーキテクトの視点から雑音を取り除きます。各フレームワークが実際に何を行い、どこに適し、本番環境でどのように使われているのかを率直に解説します。宗派争いではなく、トレードオフを扱います。
エージェントフレームワークの役割
比較の前に、何を選ぼうとしているのかを明確にしましょう。「エージェントフレームワーク」は一般に、次の機能を提供します。
- エージェントを定義する方法 — エージェントの役割、利用できるツール、振る舞いを定義します。
- 実行ループ — LLMを呼び出し、出力を解析し、次の処理を決め、ツールを呼び出して繰り返します。
- 状態管理 — エージェントが何を記憶し、それをどのように整理するかを管理します。
- ツール統合 — ツールを定義し、エージェントへ公開する方法を提供します。
- オーケストレーション — 複数エージェントの連携、ワークフローの分岐、再試行を扱います。
- 可観測性のフック — トレース、ログ、デバッグを可能にします。
- 便利なユーティリティ — プロンプトテンプレート、一般的なパターン、ヘルパーを提供します。
どの機能を重視するかはフレームワークごとに異なります。オーケストレーションを重視するもの、エージェント定義に重点を置くもの、モデルAPIの上に最小限のレイヤーだけを設けるものがあります。
フレームワークの概観
LangChain / LangGraph
最大手です。LangChainはLLM呼び出しを連結するPythonライブラリとして始まり、多くのAIプロジェクトで事実上の標準フレームワークとなりました。LangGraphは、その上に構築されたエージェント専用フレームワークです。
優れている点：
- ステートマシンにはLangGraph。 グラフモデル（処理を表すノード、遷移を表すエッジ、その間で受け渡される状態）は、複雑なエージェントワークフローに適しています。
- 豊富なエコシステム。 ベクトルDB、モデルプロバイダー、ツール、可観測性など、多数の統合があります。
- 可観測性にはLangSmith。 成熟したトレース機能とデバッグUIを提供します。
- 広範な採用。 例やドキュメントが多く、扱える人材も豊富です。
不得意な点：
- 抽象化のコスト。 特にLangChainには抽象化のレイヤーが多数あります。デバッグが難しく、実際に何が起きているのかを理解するには労力がかかります。
- APIの頻繁な変更。 破壊的変更が多く、12か月前のコードには更新が必要な場合がよくあります。
- パフォーマンスのオーバーヘッド。 間接層が増えるほど、レイテンシーとトークンのコストが増します。
- 学習曲線。 実務で自在に使えるようになるには数週間かかります。
選ぶべき場面：
- 状態が分岐する複雑なエージェントワークフロー。
- 標準フレームワークの恩恵を受けるチーム（多数のエンジニア、共通パターン）。
- LangSmithの可観測性を利用したい場合。
避けるべき場面：
- 単純なチャットボットや単一エージェントのループ（直接APIの方がシンプルです）。
- 過去にLangChainの変更の多さで苦労したチーム。
- 1ミリ秒単位のレイテンシーが重要なプロジェクト。
CrewAI
役割ベースのエージェントに重点を置くマルチエージェントフレームワークです。各エージェントに役割、目標、背景設定があり、タスクに協力して取り組みます。
優れている点：
- マルチエージェントのオーケストレーション。 エージェント同士の対話、委任、協働を標準でサポートします。
- 役割ベースのメンタルモデル。 「リサーチャーエージェントはXを行い、ライターエージェントはYを行う」と考えやすい設計です。
- マルチエージェント用途ではLangGraphよりシンプル。 素早く使い始められます。
- 活発なコミュニティ。
不得意な点：
- 単一エージェントを深く扱う機能が限定的。 タスクが複雑な単一エージェントを必要とする場合、CrewAIの抽象化は適合しないと感じることがあります。
- パフォーマンス。 マルチエージェント構成ではLLM呼び出しが増え、コストとレイテンシーが急速に拡大します。
- 成熟度の差。 LangChainより新しく、未成熟な部分が残っています。
- 規約が強い。 汎用的なフレームワークより柔軟性が低くなります。
選ぶべき場面：
- 役割分担に意味があるマルチエージェントワークフロー。
- エージェントのチームが協力する「Crew」という枠組み。
- マルチエージェントのアイデアを素早く試作する場合。
避けるべき場面：
- 単一エージェントのタスク（過剰です）。
- パフォーマンスが重要な本番環境（マルチエージェントは高コストです）。
- 「エージェントの協働」という枠組みが実質よりも演出にすぎないタスク。
Pydantic AI
型安全性と開発者体験に重点を置いた、比較的新しいフレームワークです。
優れている点：
- 強い型付け。 全体を通してPydanticを基盤とし、入力と出力に型があります。エラーを開発時に検出できます。
- 明快なAPI。 LangChainより抽象化が少なく、モデルAPIに近い設計です。
- モダンなPython。 非同期処理、型ヒント、Pydantic v2に対応しています。
- モデル非依存。 ほとんどのプロバイダーで利用できます。
不得意な点：
- 小規模なエコシステム。 LangChainより統合が少なくなります。
- 大規模運用での実績が少ない。 比較的新しく、本番パターンはまだ発展途上です。
- オーケストレーションツールが少ない。 複雑なワークフローではLangGraphほど機能が充実していません。
選ぶべき場面：
- 型安全性を重視するPythonチーム。
- 単一エージェントまたは単純なマルチエージェント構成。
- 最小限の抽象化を好むチーム。
避けるべき場面：
- 非常に複雑なオーケストレーション（LangGraphの方が適している可能性があります）。
- Python以外のプロジェクト（Python専用です）。
- 構築済み統合の巨大なエコシステムが必要な場合。
OpenAI Agents SDK
OpenAIモデル向けに調整された、OpenAI公式のエージェントフレームワークです。
優れている点：
- OpenAI向けに最適化。 GPT-5/o3のパターンを念頭に設計されています。
- シンプルなAPI。 LangChainより抽象度が低い設計です。
- 組み込みのハンドオフ。 マルチエージェントのハンドオフが第一級の機能です。
- 成熟したトレース。 OpenAIダッシュボードと連携する可観測性が組み込まれています。
不得意な点：
- OpenAIへのロックイン。 OpenAIのモデル向けに設計されているため、他のプロバイダーは扱いにくくなります。
- 柔軟性が低い。 より汎用的なフレームワークの方が実装しやすいパターンもあります。
- LangChainより新しい。 コミュニティは小規模です。
選ぶべき場面：
- OpenAIモデルに全面的に統一する場合。
- ベンダーがサポートする道筋を望む場合。
- 単純から中程度の複雑さを持つエージェント。
避けるべき場面：
- マルチプロバイダー戦略（より汎用的なフレームワークか直接APIの方が適しています）。
- 主にAnthropicまたはGoogleを使用している場合。
Anthropic Claude SDK
同様に、Claudeでエージェントを構築するためにAnthropicが提供する手段です。
優れている点：
- Claude向けに最適化。 特にClaudeのextended thinking、computer use、MCP統合との相性に優れています。
- Claudeモデルに自然な設計。
- 強力なMCPサポート。
不得意な点：
- Claudeへのロックイン。 OpenAI Agents SDKと同じトレードオフがあります。
選ぶべき場面：
- Claudeに全面的に統一する場合。
- Claude固有の機能を多用する場合。
避けるべき場面：
- マルチプロバイダー戦略。
直接API
フレームワークを一切使わず、OpenAI / Anthropic / GeminiのAPIを直接呼び出し、ループを自分で実装します。
優れている点：
- 完全な制御。 システムのあらゆる側面を自分たちで管理できます。
- 抽象化のコストがない。 見えているものが、そのまま実行されます。
- デバッグしやすい。 掘り下げる必要のあるレイヤーがありません。
- 最適化しやすい。 フレームワークのオーバーヘッドがありません。
- バージョン変更に振り回されない。 自分たちの判断でアップグレードできます。
不得意な点：
- コードが増える。 フレームワークが扱うパターンを自分たちで実装します。
- 再発明が生じる。 一般的なパターンをプロジェクトごとに再実装することになります。
- 標準化しにくい。 異なるチームが類似システムを異なる方法で構築します。
選ぶべき場面：
- 利便性より信頼性を重視し、本番システムを提供する成熟したチーム。
- フレームワークの柔軟性を必要としない、焦点の明確なユースケース。
- パフォーマンスが重要な処理経路。
- フレームワークで試作し、パターンを習得した後。
避けるべき場面：
- 新規かつ探索的で、「何を構築すべきか」を検討する段階（フレームワークはパターンの発見に役立ちます）。
- エンジニアリング能力が限られているチーム。
LlamaIndex
RAGに重点を置くライブラリとして始まり、より広範なエージェント領域へ拡大してきました。
優れている点：
- RAG中心のシステム。 検索中心のエージェントでは最高水準です。
- データコネクタ。 データソース向けの統合が多数あります。
- 成熟した検索の抽象化。
不得意な点：
- エージェントの抽象化が弱い。 汎用エージェントよりRAGに適しています。
- LangChainのエコシステムと重複する部分があります。
選ぶべき場面：
- 検索 / RAGを特に重視する場合。
- 多数のデータソースコネクタが必要な場合。
避けるべき場面：
- RAG以外のエージェント開発。
Microsoft Autogen、Semantic Kernel
Microsoftが提供する選択肢です。Autogenはマルチエージェント向け、Semantic Kernelは一般的なAIアプリケーション向けです。
優れている点：
- Microsoftエコシステムとの統合。 Azure、.NET、Microsoft 365との相性に優れています。
- Semantic Kernel： 他の選択肢よりエンタープライズ志向です。
- Autogen： マルチエージェント研究に強みがあります。
不得意な点：
- Microsoft中心ではない組織ではコミュニティが小規模です。
- LangChain/LangGraphほど勢いがありません。
選ぶべき場面：
- Microsoft製品を中心に利用するチーム。
- Azureとの密接な統合。
検討すべき観点
選択とは勝者を決めることではなく、プロジェクトにトレードオフを適合させることです。
観点1：オーケストレーションの複雑さ
エージェントワークフローはどの程度複雑でしょうか。
- 単純（チャットボット、単一エージェント、直線的なフロー）： 直接APIまたはPydantic AI。
- 中程度（単一エージェント、分岐ロジック）： Pydantic AI、LangGraph、直接API。
- 複雑（複数エージェント、ステートマシン、再試行）： LangGraph、CrewAI、カスタム実装。
- 非常に複雑（大規模なステートマシン、並列エージェント、複雑なルーティング）： LangGraphまたはカスタム実装。
観点2：本番運用の成熟度
実験より信頼性がどの程度重要でしょうか。
- 実験 / 試作： どのフレームワークでも迅速な開発に役立ちます。
- 顧客向けの本番環境： 十分に理解されているフレームワークを優先します（LangChainには最も多くのパターンがあり、直接APIには最も高い制御性があります）。
- ミッションクリティカルな本番環境： 直接APIが有利なことがよくあります。すべてのコード行を把握できるためです。
観点3：チームの規模とスキル
- 小規模チーム（エンジニア1～3人）： フレームワークのオーバーヘッドが少ない方が適しています。直接APIまたはシンプルなフレームワークを選びます。
- 中規模チーム（5～15人）： フレームワークが標準化に役立ちます。LangChainまたはPydantic AIが候補です。
- 大規模チーム（20人以上）： 共通パターンのためにフレームワークが不可欠です。LangGraphまたは社内フレームワークが適しています。
観点4：ベンダー戦略
- マルチプロバイダー： 汎用フレームワーク（LangChain、Pydantic AI）または直接API。
- 単一ベンダー： ベンダーSDK（OpenAI Agents SDK、Anthropic Claude SDK）。
観点5：パフォーマンスへの感度
- レイテンシー重視（リアルタイムUX）： 直接API。フレームワークはレイテンシーを増やします。
- コスト重視（大規模利用）： 直接API。フレームワークはトークン数を増やす可能性があります。
- 標準的： どのフレームワークでも問題ありません。
観点6：可観測性の要件
- 標準機能が充実： LangChain + LangSmith。
- 自前で構築： 任意のフレームワーク + 独自の可観測性レイヤー。
直接APIへの移行
2026年に増えているパターンとして、成熟したチームが本番環境でフレームワークから直接APIへ移行する動きがあります。
その理由は次のとおりです。
- エージェント開発を1～2年経験すると、チームはパターンを習得します。パターンを教えるというフレームワークの価値を得切った状態になります。
- フレームワークは変わりますが、直接APIは変わりにくいものです。本番の安定性では直接APIが有利です。
- パフォーマンス：フレームワークにはオーバーヘッドがありますが、直接APIにはありません。
- デバッグ可能性：障害が起きたとき、直接APIなら「何が起きたか」が明確です。
- カスタマイズ：本番システムにはそれぞれ固有の要件があります。フレームワークはカスタマイズと衝突しやすい一方、直接APIなら自由に対応できます。
これはフレームワークへの批判ではありません。学習、試作、中程度に複雑な本番システムには優れています。しかし、成熟した本番システムでは、直接APIの方が適していることがよくあります。
移行は次のように進みます。
- LangChainなどから始めます。
- 初期バージョンを構築します。
- パターンを学びます。
- 問題点（デバッグ、パフォーマンス、カスタマイズ）に気づきます。
- ホットパスを直接APIへ移行します。
- 最終的に、本番コードの大半が直接APIになります。
これはフレームワークの失敗ではありません。一部のチームにとって自然なライフサイクルです。
実践的な意思決定フレームワーク
新しいプロジェクト向けに選ぶ場合は、次の手順を使います。
ステップ1：プロジェクトを定義します。
- エージェントはどの程度複雑ですか。
- エンジニアは何人ですか。
- 本番環境ですか、試作ですか。
- 単一プロバイダーですか、マルチプロバイダーですか。
ステップ2：ヒューリスティックを適用します。
| シナリオ | 推奨 |
|---|---|
| 試作、複雑なオーケストレーション | LangGraph |
| 試作、マルチエージェント | CrewAI |
| 本番環境、単純なエージェント | 直接APIまたはPydantic AI |
| 本番環境、複雑なオーケストレーション | LangGraphまたはカスタム実装 |
| 単一ベンダー（OpenAI / Anthropic） | ベンダーSDK |
| 型安全性を重視するPythonチーム | Pydantic AI |
| RAG中心 | LlamaIndex + 任意の選択肢 |
| Microsoft中心の組織 | Semantic Kernel / Autogen |
ステップ3：試作してから評価します。
選んだフレームワークを1週間使い、代表的な機能の一部を構築します。次の点を評価してください。
- 自分たちのパターンに適合しますか。
- フレームワークに逆らっていますか、それとも活かせていますか。
- デバッグは現実的ですか。
- パフォーマンスは許容できますか。
問題がなければ続行します。問題があれば、別の選択肢を試すか、直接APIへ移行します。
ステップ4：不可逆的なロックインを避けます。
フレームワーク内でも、置き換えられるようコードを構成してください。フレームワークの利用を薄いレイヤーに隔離し、ロジックはフレームワークに依存しないコードで構築します。
フレームワークを越えて通用するパターン
どのフレームワークを選んでも、共通して使えるパターンがあります。
関心の分離。 プロンプト管理、エージェントロジック、ツール定義、実行ループをそれぞれ分離します。フレームワークはいくつかを支援しますが、残りは自分たちで扱います。
可観測性。 すべてのLLM呼び出しとツール呼び出しをトレースし、メトリクスを集約します。フレームワークにかかわらず、自分たちの責任です。
ステップ上限と脱出手段。 すべての本番エージェントに必要です。フレームワークは強制しないため、自分たちで追加する必要があります。
評価スイート。 フレームワークに本格的な評価ツールは含まれていません。別途構築します（Promptfoo、Braintrust、カスタム実装）。
本番環境向けの堅牢化。 レート制限、冪等性、エラー処理、フォールバックが必要です。フレームワークはいくつかのプリミティブを提供しますが、残りは自分たちで構築します。
こうした共通パターンに注力すれば、個々のフレームワークの選択はさほど重要ではなくなります。より重要なのはチームの規律です。
フレームワークごとの評価
多くのフレームワークを扱った経験に基づく、あえて主観を交えた見解です。
LangChain/LangGraph： 強力ですが重量級です。学ぶ価値はあります。本番環境では、ホットパスから外されることがよくあります。
CrewAI： マルチエージェントのアイデアを試すのに向いています。本番環境では、必要のないタスクにマルチエージェントの枠組みを使ってしまうことがよくあります。選択的に利用してください。
Pydantic AI： 過小評価されています。型安全性は長期的な効果をもたらします。試す価値があります。
OpenAI Agents SDK / Anthropic Claude SDK： そのベンダーに統一するなら有力です。そうでなければロックインのリスクがあります。
LlamaIndex： RAG中心の開発では依然として最有力です。汎用エージェントでは魅力が薄れます。
直接API： 成熟したチームが行き着く選択肢です。ここから始める必要はありませんが、本番の重要コードでは最終的にここへ行き着くと考えてください。
Microsoft Autogen / Semantic Kernel： Microsoftエコシステムでは有力ですが、その外では魅力が薄れます。
ある移行事例
具体的な実例として、次のような変遷があります。
1～3か月目： チームはLangChainで最初のAI機能を構築します。短期間でリリースでき、多くのパターンを学びます。
4～6か月目： 可観測性、評価、パフォーマンスなど、本番レベルの要件が現れます。チームはこれらをLangChainの上に構築します。
7～9か月目： LangChainの一部の抽象化が障害になります。チームは独自インターフェースでLangChainをラップし始めます。
10～12か月目： LangChainのバージョンアップによって複数のシステムが壊れます。チームはホットパスを直接APIで書き直し、コールドパスはLangChainに残します。
2年目： 本番コードの大半は直接APIになります。LangChainはときどき試作に使われます。直接API上に構築したチーム内部の「エージェントフレームワーク」が標準になります。
これは有効な変遷の一例です。ほかにも正解はあります。LangChainを満足して使い続けるチームもあれば、初日から使わないチームもあります。
別の視点：実際には何を選んでいるのか
フレームワークのほかに、次のものも選んでいます。
- 学びを得るコミュニティ。
- 対応し続けるAPI変更の頻度。
- 標準化の対象とするパターン一式。
- デバッグ体験。
- 可観測性のあり方。
- 将来の移行コスト。
フレームワークは、これらを具体化する一つの形にすぎません。しかし、日々のチームに影響するのはこうした要素です。
自分たちのコミュニティ、変更への許容度、パターン、デバッグ方法、可観測性のニーズに合うフレームワークが、適切な選択です。これらが合わなければ、最も人気のあるフレームワークでも自分たちには不適切です。
まとめ
2026年に、あらゆる状況に最適なエージェントフレームワークは存在しません。適切な選択は、プロジェクトの複雑さ、チーム規模、本番運用の成熟度、ベンダー戦略、チームの好みによって決まります。
実践的な進め方は次のとおりです。
- 上記のヒューリスティックを使い、フレームワークをプロジェクト要件に適合させます。
- 採用を決める前に試作します。
- 置き換えられるようにコードを構成します。
- フレームワークにかかわらず、共通パターンに注力します。
- 変化を前提にします。現在適しているものが12か月後にも適しているとは限りません。
成熟したチームの多くは、本番環境の重要なコードで直接APIへ収束します。フレームワークは、試作、学習、中程度に複雑なオーケストレーションで引き続き有用です。これは信仰の問題ではなく、状況に応じた選択です。
今の状況に適したものを選び、合わなくなったら調整してください。どのフレームワークを使うかより、何を構築するかの方が重要です。
