LLM Frontline
ニュース・動向

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

イツキ編集長 / ニュース・動向担当
・ 約13分で読めます
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. 1

    LangGraph(低レベルなグラフ制御)

    LangChainのドキュメントは、LangGraphを「長時間動く状態を持つエージェントを構築・運用するための低レベルなオーケストレーション基盤およびランタイム」と説明しています。処理をグラフのノードとして明示的に組み、実行状態を永続化するのが基本思想です。耐久実行によって、失敗しても中断した箇所から再開できること、短期の作業メモリと長期メモリの両方を扱えること、任意の地点で状態を人が確認・修正できる(human-in-the-loop)ことを前面に出しています。抽象化で楽をするより、実行フローを自分で握りたい場合に向く設計です。
  2. 2

    CrewAI(役割ベースのマルチエージェント)

    CrewAIの公式ドキュメントは、複数エージェントを協調させる「Crews」と、イベント駆動で順序を制御する「Flows」の2つの仕組みを軸に据えています。Crewsは役割(role)・目標(goal)・背景(backstory)を持つエージェントを組み合わせて自律的に協調させる考え方で、Flowsはstart/listen/routerといったステップで状態を管理し、実行を永続化して長時間の処理を再開できるとされています。ガードレール・メモリ・知識・可観測性を最初から組み込む方針を掲げており、役割分担のイメージからマルチエージェントを組み立てたいときに入りやすい設計です。
  3. 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. 4

    Pydantic AI(型安全を土台にする)

    Pydantic AIの公式ドキュメントは、Pydanticの型システムを土台にした型安全なエージェントフレームワークとして自らを説明し、FastAPIのような開発体験をうたっています。多数のモデル・プロバイダに対応するモデル非依存の設計、MCP対応、サブエージェントのオーケストレーション、途中の失敗や再起動をまたいで進捗を保てる耐久実行、検証付きの構造化出力・ストリーミング出力、評価(Evals)などを主要機能に挙げています。出力の検証や型の一貫性を重視する開発チームと相性がよい方向性です。
  5. 5

    LlamaIndex Workflows(イベント駆動の細かな制御)

    LlamaIndexのWorkflowsは、アプリケーションをステップに分け、各ステップがイベントを受け取って処理し、別のイベントを返す、というイベント駆動・ステップ指向の仕組みです。イベントはユーザーが定義するPydanticオブジェクトで、非同期を前提に、分岐・並列・ループ・状態の保持を組み立てられます。エージェント(ReActや関数呼び出しなど)はこのWorkflowsの上に構築されます。RAGで実績のあるLlamaIndexの検索・取り込み機能と地続きで、細かい制御を自分で書きたい場合に向きます。MCPについてはツール連携のパッケージが提供されています。

上記の特徴は各フレームワークの公式ドキュメント(Microsoft Learn、LangChain Docs、CrewAI Docs、Pydantic Docs、LlamaIndex Docs)で確認できた範囲に基づきます。バージョンや対応範囲は更新が続くため、具体的な版数・リリース時期はここでは断定していません。導入時は最新の公式情報で裏取りしてください。

観点別に俯瞰する

同じ土俵で並べると差が見えにくいので、設計思想・状態と耐久実行・マルチエージェントの組み方・メモリ・MCPの5観点で俯瞰します。表の内容は各公式ドキュメントで確認できた方向性の要約で、優劣を示すものではありません。

観点LangGraphCrewAIMicrosoft Agent FrameworkPydantic AILlamaIndex Workflows
設計思想低レベルなグラフで実行フローを明示制御役割ベースのCrewsとイベント駆動のFlowsSKとAutoGenを統合した企業向け基盤型安全とデータ検証を土台にするイベント駆動・ステップ指向で細かく制御
状態・耐久実行状態の永続化と耐久実行を前面にFlowsで状態管理と実行の永続化・再開セッション状態とチェックポイントを提供失敗や再起動をまたぐ耐久実行に対応ステップ間で状態を保持、非同期前提
マルチエージェントグラフのノードとして明示的に接続Crewsで役割分担、Flowsで連携を制御ワークフローで実行経路を明示制御サブエージェントのオーケストレーションWorkflows上に多段の連携を構築
メモリ短期の作業メモリと長期メモリメモリを組み込み機能として提供メモリ用のcontext providerを提供公式overviewに個別のメモリ機能の明示なし(要確認)ステップ設計で状態として保持
MCP対応対応対応(エージェントにMCPを接続)対応(MCPクライアント・ホスト型ツール)対応(MCPを組み込み)ツール連携パッケージで対応
主な言語PythonPython.NET・Python(Goはpublic preview)PythonPython・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エージェントとは何か|従来の自動化との違いと任せてよい仕事

よくある質問

結局どのフレームワークを選べばよいですか
一律の正解はありません。社内標準が.NETならMicrosoft Agent Framework、Python中心で実行フローを細かく握りたいならLangGraphやLlamaIndex Workflows、役割分担で手早く組みたいならCrewAI、型安全を重視するならPydantic AIが候補になります。まず小さく試作し、落ちたときに再開できるか・権限を絞れるか・ログを追えるかを基準に比べるのが実務的です。
Microsoft Agent Frameworkが出たので、Semantic KernelやAutoGenはもう使えないのですか
公式ドキュメントはAgent Frameworkを両者の後継と位置づけ、Semantic KernelとAutoGenそれぞれからの移行ガイドを用意しています。新規に始めるなら後継のAgent Frameworkを検討し、既存資産がある場合は移行ガイドに沿って計画的に移す、という進め方が案内されています。最新の対応状況は公式情報で確認してください。
MCP対応はフレームワーク選びの決め手になりますか
2026年時点では主要フレームワークが軒並みMCPに対応しており、対応の有無だけで差はつきにくくなっています。むしろ、既存のツールやデータ基盤とどれだけ楽につながるか、権限やログをどう管理できるかで見るほうが実務的です。
複数のフレームワークを併用してもよいですか
技術的には可能ですが、状態管理や可観測性の作法が分散し、運用と学習のコストが増えます。まずは一つを主軸に据え、どうしても必要な部分だけ別の仕組みを足す、という順序が無難です。MCPのような標準に寄せておくと、後から差し替える余地を残せます。
フレームワークを使わず自作するのはありですか
要件が単純で、1回のモデル呼び出しやツール呼び出しで足りるなら、無理にフレームワークを入れず素直に関数として書くほうが見通しがよいこともあります。Microsoft公式ドキュメントも『関数で書ける処理は関数で書け』と述べています。多段の計画・再開・複数エージェントの協調が必要になった段階で、フレームワーク導入を検討するのが現実的です。

まとめ

エージェント開発フレームワークを選ぶときの確認事項

  • チームが普段書いている言語(.NETやPythonなど)に一級で対応しているか確認した
  • 実行フローをどこまで自分で制御したいか(高抽象で手早く/低レベルで細かく)を決めた
  • 耐久実行・状態の永続化・human-in-the-loopが要件を満たすか確認した
  • 既存のRAGやツール資産と地続きで使えるか、MCPで後から差し替えられるか検討した
  • フレームワーク選定と、任せる仕事の選び方・権限設計・ログ設計を分けて考えた
  • 具体的な版数・対応範囲は着手時に各公式ドキュメントで裏取りする段取りにした

2026年のエージェント開発フレームワークは、MCP対応や耐久実行といった基本機能が横並びに近づき、違いは設計思想の重心に集約されてきました。低レベルで握るLangGraph、役割ベースのCrewAI、企業向けに統合されたMicrosoft Agent Framework、型安全を突き詰めるPydantic AI、イベント駆動のLlamaIndex Workflows。どれも同じ課題を別の書き味で解けます。大切なのは流行で選ばないことです。言語・チームの慣れ・制御の粒度・既存資産との相性という自分たちの前提に照らせば、どれが業務に馴染むかは冷静に見えてきます。そして、安定して動くエージェントを作れるかどうかは、土台選びと同じくらい、任せる仕事の選び方と承認・権限・ログの設計にかかっています。

出典・参考

この記事をシェア

関連する記事

開発・エージェント

MCP(Model Context Protocol)とは何か|AIと社内システムをつなぐ標準と業務での使いどころ

MCP(Model Context Protocol)は、AIと社内システムやツールをつなぐための共通規格です。連携のNxM問題をどう解くのか、ホスト・クライアント・サーバーという基本構成、既製サーバーを選んで繋ぐ導入の仕方、そして権限や監査ログといった業務導入時の注意点を、冷静に整理します。

プロンプト実務

コンテキストエンジニアリングとは|プロンプトの次に来る設計の基本

プロンプトエンジニアリングの次の設計単位として注目される「コンテキストエンジニアリング」を、実務目線で整理します。コンテキストの劣化(context rot)という前提、渡す情報の構成と順序、長時間動くエージェントで使う圧縮・メモ・サブエージェントといった手法までをまとめます。