エージェントフレームワークの選び方：候補を消す5つの質問

順位づけではなく、消去から始めてください。このカタログでエージェントのループを担いうる候補は8件あり、機能表を作っても決着はつきません。丁寧に文書化しているプロジェクトの行にはチェックが並び、誰も文書化していない行は空欄になるだけで、3か月目に効いてくる項目の列は最初から存在しないからです。

frameworksを主カテゴリとするのはLangChain（MIT、144,288スター）、deepseek-harness（MIT、116,370スター）、LangGraph（MIT、39,751スター）、OpenAI Agents SDK（MIT、28,662スター）、Pydantic AI（MIT、19,318スター）の5件です。カテゴリは別でも同じ枠を争うのがCrewAI（MIT、57,126スター）、AutoGen（60,436スター）、LlamaIndex（MIT、51,662スター）の3件です。以下の5つの質問は、順位をつけるのではなく候補を消していきます。

質問1：その実行は、クラッシュや人間の承認をまたぐ必要がありますか

50分かかる処理の40分目でプロセスが落ちる。あるいは、8番目のステップが本番システムに書き込む前に、7番目を人が承認しなければならない。そのフレームワークは途中から再開しますか、それとも最初からやり直しますか。

大半はやり直します。LangGraphはやり直さないことを軸に設計されています。durable executionがグラフの進行に合わせて状態を永続化するので、途中で落ちたエージェントはまさに中断した地点から再開します。interruptsは選んだ地点で実行を止め、人がエージェントの状態を確認して書き換えられます。記述量が多いという不満は、この仕組みの対価です。

Pydantic AIは逆方向から同じ地点に着きます。TemporalDurability()を付けるとモデル呼び出しとツール呼び出しがTemporalのアクティビティになり、バックグラウンドのキューで進む実行が再起動や失敗、長い待ち時間をまたいで続きます。DBOSとPrefectも同じ差し込み方で、人間による承認も自分で発明せずに済む文書化された機能です。耐久性はライブラリではなく、運用するエンジンの側にあります。

会話の永続化は別物です。OpenAI Agents SDKのSessionsは実行をまたいで履歴を管理しますが、再開されるのは会話であって、走っていた処理ではありません。

私の選び方はこうです。Temporalをまだ運用していないならLangGraph、動かすシステムは2つより1つのほうが良いからです。プラットフォーム側がTemporalやDBOS、Prefectを既に運用しているならPydantic AI、耐久性の面倒がそちらの守備範囲に移るからです。そして失敗した実行をやり直すコストが低く、ツールが冪等なら、この軸は飛ばしてください。不要な耐久性は、エージェントのコードベースに余計な構造を持ち込む最大の原因です。

質問2：難所は推論側ですか、コーパス側ですか

誤った答えが出たとき、それはモデルの推論が悪かったからですか。それとも、正しい文書が一度も目に入らなかったからですか。

後者なら、フレームワークの選択はほとんど効かず、問題のすべては検索設計です。LlamaIndexはエージェントのループではなくデータから出発します。取り込み、インデックス戦略、そして回答が根拠を持つかどうかを決める検索パターンが中心です。検索だけLlamaIndexに任せ、制御フローは別のフレームワークに持たせる。私ならこれを既定にします。

そのうえでコーパス自体に工数を確保してください。この種のプロジェクトが実際に失敗するのはそこです。Firecrawl（AGPL-3.0、167,800スター）はJavaScriptを描画し、コーパスを汚染するナビゲーションや定型部分を落とします。Crawl4AI（Apache-2.0、78,234スター）は寛容なライセンスの代替で、成果物をサービスとして外に出すつもりなら差が出ます。その形でFirecrawlを使う前に、AGPLの条項を読んでください。

質問3：そのエージェントを抱えるサービスは、どの言語で書かれていますか

軽く見られがちで、外したときの費用が最も高い問いです。修正がリファクタリングではなく、デプロイ構成の変更になります。

Pythonのみなのは、CrewAIとPydantic AIです。OpenAI Agents SDKもPythonで、READMEはJS/TS利用者を別リポジトリのopenai-agents-jsへ案内します。バインディングではなく、独自のリリース間隔を持つ別のコードベースです。

PythonとTypeScriptを同じ設計で書けるのは3件です。LangGraphはLangGraph.jsとnpmの@langchain/langgraph、LangChainはLangChain.jsとnpmのlangchain、LlamaIndexはllamaindexがあります。AutoGenはPythonとC#の組み合わせで、.NETから到達できます。

TypeScriptのみなのがdeepseek-harnessです。Pythonをまったく持ち込まずにNodeのサービスが採用できる唯一の候補ですが、それでも後述のショートリストには入れません。理由は言語と無関係です。READMEが説明しているのは動かすためのハーネスで、npx @deepseek-ai/dsh webがhttp://127.0.0.1:3080にWeb UIを立ち上げることと、ソースからのチェックアウトの2つだけです。スクリプトから呼ぶ、あるいは既存のプロセスに埋め込むための入り口は文書化されておらず、開発ガイドとアーキテクチャ文書へのリンクはあってもREADMEはその中身に触れていません。既存のTypeScriptサービスの内側にエージェントを置くという用途は、この公開範囲では埋まりません。

立場を述べます。NodeやTypeScriptのサービスがエージェントを自分の中に抱えるなら、候補はLangGraph.js、LangChain.js、LlamaIndexのTSパッケージです。Pythonのみのライブラリを選べばサイドカーになり、デプロイ対象が1つ、オンコール対象が1つ、依存関係のグラフが1本増えます。ライブラリの選定の顔をした、インフラの選定です。deepseek-harnessは隠さず例外として挙げておきます。呼び出すライブラリではなく拡張していくプラグインの土台が欲しいなら、TypeScriptネイティブでサイドカーは発生しません。ただし質問4を先に読んでください。

質問4：そのプロジェクトは1年後も新規採用に値しますか

AutoGenのREADMEにはメンテナンスモードのバナーが出ています。新機能はなく、コミュニティ管理に移り、新規利用者はMicrosoft Agent Frameworkへ案内され、受け付ける変更はバグ修正、セキュリティ修正、ドキュメントに限られます。GitHubが報告するライセンスもCC-BY-4.0で、OSI承認のソフトウェアライセンスではなくコンテンツ向けのライセンスです。本カタログの45件のうちOSI承認は41件で、AutoGenは残る4件の1つです。

deepseek-harnessは、同じ指標の逆向きの失敗です。注目は極めて大きく、その一方でプロジェクト自身が開発者プレビューを名乗り、互換性を壊す変更があると大文字で警告しています。これは欠点ではなく正確な自己申告です。今日書いたプラグインには、書き直しの工数を見込んでください。

Letta（Apache-2.0、24,259スター）は3つ目の形です。このスター数が属するのはV1 APIを提供する旧サーバーで、開発の主体はletta-ai/letta-codeへ移りました。機能一覧より先に、READMEが自分で掲げている状態表示を読んでください。3件とも最初の画面で正体を明かしています。

質問5：誤った出力を誰かに説明する場面がありますか

デバッグのしやすさは機能一覧にまず載りませんが、実在する選定基準です。顧客や監査担当、あるいは自社のPMから「なぜこの出力になったのか」と問われたとき、手元にあるのはトレースか謝罪のどちらかです。

各プロジェクトがこれをどこに置いているかで決まります。LangGraphのREADMEはデバッグをLangChainの別プロダクトであるLangSmithに委ねます。OpenAI Agents SDKは数少ないプリミティブの1つにtracingを数えます。Pydantic AIはOpenTelemetryネイティブで、任意のOTelバックエンドが使えます。CrewAIのREADMEは、トレースと可観測性を商用のAMP Suiteの側に置いています。

OTelネイティブを勧めます。トレースの保存先が交換可能な部品になり、2つ目のベンダーへの拘束にならないからです。Langfuse（MIT、33,155スター）はマネージドもセルフホストも同一のコードベースで、どちらの方向へ移っても費用は低いままです。MITのコアから外れる機能がどれかは先に確認してください。Phoenix（Elastic-2.0、11,065スター）はOpenTelemetryベースで、デバッグ対象のコードの隣でローカルに動きます。社内利用なら問題なく、サービスとして外販するなら制約になります。

判断材料にしてはいけないもの

スター数。deepseek-harnessの116,370はLangGraphの39,751の3倍近くありますが、自己申告の開発者プレビューです。スター数が測るのは集めた注目であって、来年それを運用できるかどうかではありません。本サイトが載せているのはリポジトリに関する事実としてであり、順位づけのためではありません。取得元は掲載基準に書いてあります。

ベンチマークの順位表。エージェントのベンチマークが採点しているのは、ハーネスとモデルとプロンプトの組です。モデルを差し替えれば順位は動きます。寄与が最も小さいのがフレームワークで、しかも読んでいる数値は他人のプロンプトで他人のタスクを解いた結果です。

連携先の数。LlamaHubには読み切れない数のコネクタが並び、LangChainは網羅性そのものを売りにしています。実際に使うのは3つから5つで、問うべきはその3つが保守されているかです。MCPがこの指標をさらに痩せさせました。AutoGenのMcpWorkbenchも、Pydantic AIのコアに含まれるMCPも、任意のMCPサーバーに到達できます。公開されているサーバーはMCP Registryに一覧があります。リファレンス実装のMCPサーバー群（MIT）はその窓口ではなく、掲載項目に書いたとおり、steering groupが保守する7つを本番向けではない教材例として置いているリポジトリです。連携とは、専用アダプタが用意されるのを待つものから、こちらからURLを指すだけのサーバーへと変わりつつあります。

3つの状況への答えと、補足が1つ

本番システムに触れ、人間の承認を挟む社内ワークフロー。LangGraphです。記述量の多さは受け入れてください。対価として買っているのがinterruptsとチェックポイントです。兄弟プロジェクトと迷うなら、LangChainとLangGraphの比較とLangGraphとOpenAI Agents SDKの比較が読むべきページです。

既存の、全体を型付けしたPythonサービスにエージェントを1つ置く。Pydantic AIです。不正な形式の出力は目に見える場所で失敗し、後から耐久性が要件になってもエンジンを差すだけで、周辺を書き直す話にはなりません。

自社ドキュメントへの質問応答。検索はLlamaIndex、ループは既にサービスが使っているもの、そして時間はエージェント側より取り込み工程に多く割いてください。

「マルチエージェントで」と言われた場合。まず、よく設計した単一エージェントを計測してください。CrewAIの項目にそのまま書いてあります。役割を演じる複数エージェントが単一エージェントを上回るかは計測に値し、答えが「否」であることは珍しくない、と。それでもチームを組みたいならAutoGenとCrewAIの比較を読んでください。結論はCrewAIか、どちらも採らないかです。AutoGen自身のREADMEが、新規プロジェクトを別の場所へ送っているからです。