AIエージェント開発フレームワークの現在地2026|LangGraph・CrewAI・Microsoft Agent Framework・Pydantic AIをどう選ぶか

AIエージェントを業務で組む段になると、必ず突き当たるのが「どのフレームワークを土台にするか」という問いです。2026年時点では選択肢が増える一方で、各フレームワークが目指す方向がはっきり分かれてきました。この記事では、LangGraph・CrewAI・Microsoft Agent Framework・Pydantic AI・LlamaIndex Workflowsを取り上げ、公式ドキュメントで確認できた特徴だけを使って位置づけを整理します。特定のフレームワークが一番だと断じるのではなく、状態管理・耐久実行・マルチエージェント・メモリ・MCP対応という観点で、自分たちの用途と制約から選ぶための材料をまとめます。
2026年、何が横並びになったか
数年前はフレームワークごとにできること・できないことの差が大きく、機能の有無が選定の主眼でした。2026年時点では、各社の公式ドキュメントを読む限り、以下の要素は主要フレームワークで概ね共通して提供されるようになっています。
- MCP対応: 外部ツールやデータへの接続を標準化するMCPに、いずれのフレームワークも対応しています。ツール連携の作法が揃ってきたため、道具立ての差は縮まりました。
- 耐久実行と状態の永続化: 長時間動くエージェントが途中で失敗しても、保存した状態から再開できる仕組み(チェックポイント/耐久実行)が一級の機能として整理されつつあります。
- 人間の承認をはさむ設計(human-in-the-loop): 取り消せない操作の前に人が確認する導線が、標準機能として組み込まれてきました。
機能の有無で優劣が決まる時代から、設計思想と自分たちの環境への合わせやすさで選ぶ時代に移っている、というのが全体像です。MCPそのものについては別記事で解説しています。
あわせて読みたい
MCP(Model Context Protocol)とは何か|AIと社内システムをつなぐ標準と業務での使いどころ
主要フレームワークの位置づけ
以下は各フレームワークの公式ドキュメントで確認できた範囲の特徴です。バージョン番号や提供時期は更新が速いため、ここでは設計思想と主な機能の方向性に絞って記述します。着手時には必ず最新の公式情報を確認してください。
- 1
LangGraph(低レベルなグラフ制御)
LangChainのドキュメントは、LangGraphを「長時間動く状態を持つエージェントを構築・運用するための低レベルなオーケストレーション基盤およびランタイム」と説明しています。処理をグラフのノードとして明示的に組み、実行状態を永続化するのが基本思想です。耐久実行によって、失敗しても中断した箇所から再開できること、短期の作業メモリと長期メモリの両方を扱えること、任意の地点で状態を人が確認・修正できる(human-in-the-loop)ことを前面に出しています。抽象化で楽をするより、実行フローを自分で握りたい場合に向く設計です。 - 2
CrewAI(役割ベースのマルチエージェント)
CrewAIの公式ドキュメントは、複数エージェントを協調させる「Crews」と、イベント駆動で順序を制御する「Flows」の2つの仕組みを軸に据えています。Crewsは役割(role)・目標(goal)・背景(backstory)を持つエージェントを組み合わせて自律的に協調させる考え方で、Flowsはstart/listen/routerといったステップで状態を管理し、実行を永続化して長時間の処理を再開できるとされています。ガードレール・メモリ・知識・可観測性を最初から組み込む方針を掲げており、役割分担のイメージからマルチエージェントを組み立てたいときに入りやすい設計です。 - 3
Microsoft Agent Framework(SKとAutoGenの後継)
Microsoft Learnの公式ドキュメントは、Agent FrameworkをSemantic KernelとAutoGenの直接の後継と位置づけ、両者を作った同じチームが統合したものだと明記しています。AutoGenの簡潔なエージェント抽象と、Semantic Kernelのセッションベースの状態管理・型安全・ミドルウェア・テレメトリといった企業向け機能を合わせ、さらに複数エージェントの実行経路を明示的に制御するグラフベースのワークフローを加えた構成です。個々のエージェント、長い多段タスク向けの「Harness」、型安全なルーティングとチェックポイントとhuman-in-the-loopを持つワークフローの3層で整理されています。既存のSemantic KernelやAutoGenからの移行ガイドも公式に用意されています。 - 4
Pydantic AI(型安全を土台にする)
Pydantic AIの公式ドキュメントは、Pydanticの型システムを土台にした型安全なエージェントフレームワークとして自らを説明し、FastAPIのような開発体験をうたっています。多数のモデル・プロバイダに対応するモデル非依存の設計、MCP対応、サブエージェントのオーケストレーション、途中の失敗や再起動をまたいで進捗を保てる耐久実行、検証付きの構造化出力・ストリーミング出力、評価(Evals)などを主要機能に挙げています。出力の検証や型の一貫性を重視する開発チームと相性がよい方向性です。 - 5
LlamaIndex Workflows(イベント駆動の細かな制御)
LlamaIndexのWorkflowsは、アプリケーションをステップに分け、各ステップがイベントを受け取って処理し、別のイベントを返す、というイベント駆動・ステップ指向の仕組みです。イベントはユーザーが定義するPydanticオブジェクトで、非同期を前提に、分岐・並列・ループ・状態の保持を組み立てられます。エージェント(ReActや関数呼び出しなど)はこのWorkflowsの上に構築されます。RAGで実績のあるLlamaIndexの検索・取り込み機能と地続きで、細かい制御を自分で書きたい場合に向きます。MCPについてはツール連携のパッケージが提供されています。
上記の特徴は各フレームワークの公式ドキュメント(Microsoft Learn、LangChain Docs、CrewAI Docs、Pydantic Docs、LlamaIndex Docs)で確認できた範囲に基づきます。バージョンや対応範囲は更新が続くため、具体的な版数・リリース時期はここでは断定していません。導入時は最新の公式情報で裏取りしてください。
観点別に俯瞰する
同じ土俵で並べると差が見えにくいので、設計思想・状態と耐久実行・マルチエージェントの組み方・メモリ・MCPの5観点で俯瞰します。表の内容は各公式ドキュメントで確認できた方向性の要約で、優劣を示すものではありません。
| 観点 | LangGraph | CrewAI | Microsoft Agent Framework | Pydantic AI | LlamaIndex Workflows |
|---|---|---|---|---|---|
| 設計思想 | 低レベルなグラフで実行フローを明示制御 | 役割ベースのCrewsとイベント駆動のFlows | SKとAutoGenを統合した企業向け基盤 | 型安全とデータ検証を土台にする | イベント駆動・ステップ指向で細かく制御 |
| 状態・耐久実行 | 状態の永続化と耐久実行を前面に | Flowsで状態管理と実行の永続化・再開 | セッション状態とチェックポイントを提供 | 失敗や再起動をまたぐ耐久実行に対応 | ステップ間で状態を保持、非同期前提 |
| マルチエージェント | グラフのノードとして明示的に接続 | Crewsで役割分担、Flowsで連携を制御 | ワークフローで実行経路を明示制御 | サブエージェントのオーケストレーション | Workflows上に多段の連携を構築 |
| メモリ | 短期の作業メモリと長期メモリ | メモリを組み込み機能として提供 | メモリ用のcontext providerを提供 | 公式overviewに個別のメモリ機能の明示なし(要確認) | ステップ設計で状態として保持 |
| MCP対応 | 対応 | 対応(エージェントにMCPを接続) | 対応(MCPクライアント・ホスト型ツール) | 対応(MCPを組み込み) | ツール連携パッケージで対応 |
| 主な言語 | Python | Python | .NET・Python(Goはpublic preview) | Python | Python・TypeScript |
メモ
どう選ぶか:用途と制約から逆算する
機能が横並びに近い以上、選定は「何ができるか」より「自分たちの状況にどれが馴染むか」で決めるのが実務的です。判断材料を整理します。
言語とエコシステムの制約
社内標準が.NETなら、.NETを一級で扱えるMicrosoft Agent Frameworkが自然な候補になります。Python中心なら、LangGraph・CrewAI・Pydantic AI・LlamaIndexのいずれも候補です。既にLangChainやLlamaIndexで検索基盤(RAG)を組んでいるなら、地続きのLangGraphやLlamaIndex Workflowsに寄せると学習コストと連携の手間を抑えられます。RAGの基礎はこちらで整理しています。
あわせて読みたい
コンテキストエンジニアリングとは|プロンプトの次に来る設計の基本
制御の粒度をどこまで握るか
実行フローを細部まで自分で設計したいなら、グラフやイベントで明示的に組むLangGraph・LlamaIndex Workflowsが向きます。逆に、役割を与えて手早く協調動作を立ち上げたいならCrewAIのCrewsが入りやすく、そこから順序制御が必要になった部分をFlowsで締める、という進め方ができます。抽象度が高いほど立ち上がりは速く、低いほど細かい挙動を制御できます。ここはトレードオフです。
型安全・検証をどれだけ重視するか
出力の型やデータ検証を厳密にしたい、LLMの構造化出力を検証込みで扱いたい、というチームにはPydantic AIの方向性が合います。既存のPydantic資産やFastAPI流の開発スタイルとも馴染みます。
注意
エージェント自体をどう設計し、何を任せてよいか(できること・できないこと・向かない場面)は、フレームワーク選定の前提として押さえておく価値があります。
あわせて読みたい
AIエージェントとは何か|従来の自動化との違いと任せてよい仕事
よくある質問
結局どのフレームワークを選べばよいですか
Microsoft Agent Frameworkが出たので、Semantic KernelやAutoGenはもう使えないのですか
MCP対応はフレームワーク選びの決め手になりますか
複数のフレームワークを併用してもよいですか
フレームワークを使わず自作するのはありですか
まとめ
エージェント開発フレームワークを選ぶときの確認事項
- チームが普段書いている言語(.NETやPythonなど)に一級で対応しているか確認した
- 実行フローをどこまで自分で制御したいか(高抽象で手早く/低レベルで細かく)を決めた
- 耐久実行・状態の永続化・human-in-the-loopが要件を満たすか確認した
- 既存のRAGやツール資産と地続きで使えるか、MCPで後から差し替えられるか検討した
- フレームワーク選定と、任せる仕事の選び方・権限設計・ログ設計を分けて考えた
- 具体的な版数・対応範囲は着手時に各公式ドキュメントで裏取りする段取りにした
2026年のエージェント開発フレームワークは、MCP対応や耐久実行といった基本機能が横並びに近づき、違いは設計思想の重心に集約されてきました。低レベルで握るLangGraph、役割ベースのCrewAI、企業向けに統合されたMicrosoft Agent Framework、型安全を突き詰めるPydantic AI、イベント駆動のLlamaIndex Workflows。どれも同じ課題を別の書き味で解けます。大切なのは流行で選ばないことです。言語・チームの慣れ・制御の粒度・既存資産との相性という自分たちの前提に照らせば、どれが業務に馴染むかは冷静に見えてきます。そして、安定して動くエージェントを作れるかどうかは、土台選びと同じくらい、任せる仕事の選び方と承認・権限・ログの設計にかかっています。
出典・参考
関連する記事
AIエージェントとは何か|従来の自動化との違いと任せてよい仕事
生成AIの活用で注目されるAIエージェントを冷静に解説します。チャットボットやRPAとの違い、自律性がもたらす利点とリスク、実務でエージェントに任せてよい仕事と任せるべきでない仕事の線引きをまとめます。
MCP(Model Context Protocol)とは何か|AIと社内システムをつなぐ標準と業務での使いどころ
MCP(Model Context Protocol)は、AIと社内システムやツールをつなぐための共通規格です。連携のNxM問題をどう解くのか、ホスト・クライアント・サーバーという基本構成、既製サーバーを選んで繋ぐ導入の仕方、そして権限や監査ログといった業務導入時の注意点を、冷静に整理します。
コンテキストエンジニアリングとは|プロンプトの次に来る設計の基本
プロンプトエンジニアリングの次の設計単位として注目される「コンテキストエンジニアリング」を、実務目線で整理します。コンテキストの劣化(context rot)という前提、渡す情報の構成と順序、長時間動くエージェントで使う圧縮・メモ・サブエージェントといった手法までをまとめます。


