2026年 最適なAIエージェント基盤：LangGraph・CrewAI・n8n

スター数ではなく、制御モデルと「誰がワークフローを書くか」で選んでください。 以下を上から読み、自分に当てはまる最初の行で止めてください。

エージェントのオーケストレーション基盤は、複数のLLM呼び出しにまたがる制御フロー・状態・調整を引き受けます。ループも再試行もメッセージの受け渡しも自分で書かずに済むということです。 次にどのエージェントが動くか、それぞれが何を見られるか、ある手順が失敗したらどうなるか、長時間の処理が中断後どう再開するかを扱います。

これは、複数のエージェント、分岐するロジック、再起動をまたいで残る必要のある状態がある場合には本当に有用です。一方、エージェント1つがツールを1回呼ぶだけなら余計な負担でしかありません。この分野で最も多い誤りが、問題がまだ求めていない段階で基盤を導入することなのは、そのためです。

すべてで勝つ基盤はありません。制御はLangGraph、速さはCrewAI、AzureスタックはMicrosoft Agent Framework、間口の広さはn8nです。 スター数・ライセンス・活動状況は2026年8月28日にGitHub APIから、料金は同日に各社の公式料金ページから取得しました。

エージェントがデモで見栄えするだけでなく、検査でき、再開でき、正しくある必要があるときに選ぶのがLangGraphです。 ワークフローを共有状態つきの明示的な有向グラフとして表現します。最初の手間は増えますが、深夜三時に何かが壊れたときの手間は大きく減ります。

CrewAIは、着想から動くものまでの距離で勝ります。 その抽象は、人が口頭でマルチエージェントの仕事を説明するときの言い方にそのまま重なります。調査担当のエージェントが執筆担当へ引き継ぎ、それぞれにタスクがあり、合わせて一つのクルーになる、という具合です。

インフラがMicrosoft中心なら、現時点の答えはこれです。しかもAutoGenと並立したのではなく、置き換えました。 MicrosoftはAutoGenからの移行ガイドを公開し、Agent Frameworkを企業向けの後継と説明しています。

ワークフローを作る人がPythonを書かない場合、あるいはエージェントがはるかに大きな業務プロセスの一手順にすぎない場合の答えがn8nです。 これはAIエージェントのノードを備えた汎用のワークフロー自動化基盤であって、エージェント基盤が外側へ広がったものではありません。

AutoGenで新規に始めないでください。そして、いまだにそれを勧める案内には注意してください。 リポジトリ`microsoft/autogen`にはメンテナンスモードの告知が掲げられ、AutoGenは「新機能や機能強化は行われず、今後はコミュニティ管理となる」と明記されたうえで、新規利用者はMicrosoft Agent Frameworkへ案内されています。Microsoftは既存利用者向けに正式な移行ガイドを公開しています。

リポジトリのスターは依然6.07万と表示されており、この数字が広く見られる誤りの源になっています。複数の比較記事が約6万スターをコミュニティ版フォークのAG2に帰し、繁栄している後継として描いています。実際のAG2はスター0.49万でライセンスはApache-2.0、MITではありません。確かに活発ではあり、確認した当日にも更新され、未解決の課題は本家よりはるかに少ないのですが、そうした記事が示唆するよりずっと小さなプロジェクトです。

ライセンスについて知っておく価値のある細かな点もあります。AutoGenのリポジトリにはライセンスファイルが二つあります。`LICENSE-CODE`がMITでコードを対象とし、`LICENSE`がCreative Commons Attribution 4.0でコード以外の内容を対象とします。リポジトリのメタデータはCreative Commonsのほうを報告するため、表によってはAutoGenがコンテンツ用ライセンスで掲載されます。

ここに挙げたオーケストレーションのライブラリはすべて無料です。支払うのはマネージドなホスティング、トレース、ガバナンスであって、エージェントのロジックそのものではありません。 つまり本当の予算上の問いは、結局どのマネージド層が必要になるかであり、それはたいていモデルのトークン費用より小さく収まります。

この4つのうち3つはMITによるOSI承認のオープンソースですが、n8nは違います。そしてこの違いは、どの機能よりも重要になりうるものです。 LangGraph、CrewAI、Microsoft Agent FrameworkはいずれもMITライセンスで、表示義務を除けばほぼ制約なく商用利用・改変・再配布ができます。

n8nはSustainable Use Licenseを採用しています。Community Editionは無料でソースも読めますが、ライセンスはn8n自体の再販を制限しており、ホスティングされたn8nを中核的な価値とする製品を作るつもりなら、これは実質的な制約です。ライセンスへの批判ではありません。意図的で理にかなった事業モデルです。ただしアーキテクチャを決める前に、後ではなく先に片づけておくべき法務の論点です。マーケティングのページではなくライセンス本文を読んでください。

AG2フォークはApache-2.0で、これもOSI承認ですが、MITにはない明示的な特許許諾を含みます。多くのチームには実務上の違いはありませんが、大企業の法務レビューでは違いが出ることがあります。

求める制御の水準と、誰がワークフローを書くかで決まります。 次の5つの類型でほとんどの読者を説明できます。

エージェント基盤は、プロンプト、ツールの出力、途中の推論がどこへ行くかを決めます。そのためホスト型か自社運用かという問いは、主要3市場では運用上の好みではなくコンプライアンスの問題になります。

用途がエージェント1つでツールを1〜2個ループ呼び出しするだけなら、4つとも見送り、モデルプロバイダーの関数呼び出しAPIに対して直接書いてください。 依存は減り、壊れたときのスタックトレースは短くなり、基盤が抽象を変えても移行するものがありません。今年のAutoGenの件が示すとおり、抽象は変わるのです。

待つ価値のある閾値は具体的です。調整し合う複数のエージェント、プロセスの再起動を越えて残る必要のある状態、あるいは実行の途中に入る人の承認手順。このいずれか一つでもあれば基盤は正当化されます。どれもないなら、その基盤は抱えていない問題を解く代わりに、追い続けねばならない依存を増やすだけです。