LangGraphとAutoGenを比較：状態管理の違いと移行先の選び方

AutoGenとLangGraphの比較は、いまや移行先を決めるための比較です。2026年10月27日時点で、MicrosoftのAutoGen READMEには、プロジェクトはアーカイブされ、メンテナンスが終了したと明記されています。状態を持つワークフローの制御を明確にしたいならLangGraph、Microsoftのエージェント基盤との継続性を重視するならMicrosoft Agent Frameworkが候補です。既存のAutoGenプロトタイプは移行に役立つ資産ですが、新たな本番システムの土台には向きません。AutoGenの現在の状況を確認できます。

LangGraphとAutoGen、どちらを選ぶべきですか？

処理の進捗を追跡し、承認待ちで停止し、想定どおりに復旧できる新規システムには、LangGraphを選びます。 LangChainが開発するオーケストレーションの実行基盤であるLangGraphでは、明示的な状態を介してつながる処理ステップとしてアプリケーションを表現できます。たとえばサポート業務では、ワーカーの再起動後も、返信案、レビュー結果、承認を区別して保持する必要があります。そのようなワークフローに適しています。

Microsoftのエコシステムに依存するAutoGenアプリケーション、とくに既存の.NETアプリケーションの移行では、Microsoft Agent Frameworkを選びます。 Microsoftが後継として提供するこのフレームワークは、エージェントの抽象化とワークフローを組み合わせています。ただし、同じ系列に移る場合もオーケストレーションと状態管理の変更が必要です。パッケージ名を置き換えるだけでは移行できません。Microsoftのフレームワーク概要に説明があります。

既存のAutoGenプロトタイプは、移行中に用途を限定した参照実装としてのみ残します。 価値のあるプロンプト、ツールの入出力仕様、実例は保存します。開発元によるメンテナンスが続く前提で、担わせる役割を増やすことは避けてください。

判断の軸は、基盤を誰が保守するか、アプリケーションの状態をどこに置くか、停止した処理をどう再開するか、という3点です。本記事の評価はドキュメントに基づくもので、速度やモデルの品質を測定したベンチマークではありません。引用する各社のページとドキュメントは、2026年10月27日に確認しています。

表の実装上の根拠は、AutoGenのチームガイド、AutoGenの状態管理ガイド、LangGraph Graph API、LangGraphの永続化ドキュメントにあります。

AutoGenの現在地：保守モードを終え、アーカイブ済みに

Microsoftが提供してきた、複数のAIエージェントを連携させるフレームワークAutoGen。そのREADMEには現在、**「プロジェクトはアーカイブされ、メンテナンスは終了しています」という警告が掲載されています。同じ告知では、Microsoftはバグ修正、セキュリティ修正、新機能、サポートを提供しないと説明し、既存ユーザーに移行を促しています。新規ユーザーへの案内も明確で、「新規ユーザーはMicrosoft Agent Frameworkから始めてください」**とされています。MicrosoftのAutoGen READMEに記載されています。

以前の方針を記憶している開発者もいるでしょう。その理由は、Microsoftの過去の発表にあります。2025年10月1日の公開記事には、「両プロジェクトのサポートは継続しますが、投資の大半は現在Microsoft Agent Frameworkに集中しています」とありました。これは、AutoGenと、Microsoftが以前から提供していたエージェントおよびAIアプリケーション向けフレームワークSemantic Kernelについて、後継の発表時点で示された方針です。現在のAutoGenの警告より優先されるものではありません。Microsoftの紹介記事で当時の説明を読めます。

Microsoftの2026年6月3日のBUILD更新記事には、「MAFは2026年4月2日に1.0 GAに到達しました」とも記載されています。GAは一般提供を意味します。したがって、この後継フレームワークを、発表当初のプレビュー段階のままと説明するのは適切ではありません。MicrosoftのBUILD更新記事に経緯があります。

新規採用でAutoGenとLangGraphを比べるなら、選ぶのはLangGraphです。 AutoGenの会話APIを検討する前に、サポート状況だけでこの判断は決まります。Microsoft Agent Frameworkは、それとは別に検討すべき、現在も提供されている移行候補です。

会話を軸にするか、状態を持つグラフを軸にするか

AutoGen AgentChatは会話を扱いやすい単位にまとめ、LangGraphはアプリケーションの状態とその遷移を明示します。 どちらもエージェントを連携させられます。実務で差が出るのは、障害が起きたり、人の介入が必要になったりしたときに、何を定義しなければならないかです。

AutoGen：エージェントが順番に発言し、メッセージを読む

AutoGen AgentChatは、イベント駆動のAutoGen Coreランタイム上に構築された、より高水準のチームAPIです。RoundRobinGroupChatでは、参加者が順番に発言し、応答をグループ全体に配信します。下書き担当が回答案を出し、レビュー担当がその内容に異議を示す、といった構成にできます。一方、SelectorGroupChatでは、モデルが次の発言者を選びます。AutoGenのチーム構成パターンで説明されています。

すでに把握している会話の流れを表すには、直感的な方法です。ただし、会話ログを業務の実行記録としても使おうとすると、話は複雑になります。「承認済み」という一文が、下書きの事実確認を指すのか、顧客の同意を指すのか、人による実行許可を指すのかは、それだけでは分かりません。外部への操作に進む前に、アプリケーションはそれらを区別する必要があります。

AutoGenで課題になるのは、有用な会話と、中断後に再開できる業務プロセスとの隔たりです。 現在はそこに、アーカイブ済みという事情も加わります。プロンプトを増やしても、保存した成果物のどれが正なのか、どの操作がすでに実行されたのかは定義できません。

なお、AutoGenではグラフを表現できない、とするのも誤りです。実験的なGraphFlowは、順次実行、分岐、並列処理、ループに対応しています。より注意すべきなのは、実行グラフだけでは各エージェントが閲覧するメッセージは決まらない点です。メッセージはデフォルトで全体に配信され、フィルタリングは別に行います。「次はレビュー担当が動く」というエッジを設けても、それがデータへのアクセスを制限する境界にはなりません。GraphFlowのドキュメントに説明があります。

既存の会話型プロトタイプを理解するには、AutoGen AgentChatが適しています。 チームという抽象化によって、そのプロトタイプの仕組みを簡潔に説明できます。これは移行前にコードを理解しておく理由にはなりますが、AutoGenで新規の運用を始める理由にはなりません。

LangGraph：処理の記録をアプリケーションが管理する

LangGraphは、状態を持つワークフローのための低水準ランタイムです。ノードが処理を実行し、エッジが次のステップを選び、状態がアプリケーションを通じて受け渡される構造化された作業記録になります。ノードにはモデル呼び出しも通常の関数も含められます。LangGraphの概要に基本概念がまとまっています。

サポート返信なら、状態にはチケット識別子、利用が承認された参照テキスト、現在の下書き、レビューの指摘、人の判断などを持たせられます。レビューノードが指摘内容を更新し、条件付きエッジが、不合格の下書きを修正に戻すか、問題のない下書きを承認へ進めるかを決めます。どのフィールドを用意し、どの方針で動かすかは、アプリケーション側の設計です。

リデューサーとは、更新内容を既存の状態フィールドとどう組み合わせるかを定めるルールです。たとえば、現在の下書きは上書きし、レビューのメモは蓄積する、といった使い分けができます。選択を誤ると、修正後の回答に古い指摘が残ることがあります。状態の更新とリデューサーで詳しく説明されています。

LangGraphで課題になるのは、明示的に設計する範囲の広さです。 スキーマ、ルーティングのルール、障害時の挙動は開発側が担います。グラフにモデルによる判断やループを含めることもできますが、グラフを描いただけで、生成文の再現性や正しさが保証されるわけではありません。

ワークフローの業務上の状態を制御するなら、LangGraphが適しています。 エージェントの会話から進捗を推測する必要がなく、記録を直接確認できることが利点です。

LangGraphとLangChain：必要なレイヤーを選ぶ

LangChainは、モデル、ツール、エージェントのループを扱う高水準のフレームワークです。LangGraphはその下でオーケストレーションを担います。LangChainのコンポーネントを採用せずに、LangGraphだけを利用することもできます。スタックの構成で関係を確認できます。

AutoGenから移行する際は、まず独自のワークフローが必要かどうかを判断します。ツールを呼び出して回答を返す小規模なアシスタントなら、その追加構造は不要かもしれません。この選び分けは、LangChainとLangGraphの比較で詳しく扱っています。

同じ2エージェントのタスクを、それぞれどう組むか

下書き担当とレビュー担当で連携の仕組みを比較し、送信は両エージェントの担当から外します。 固定の顧客チケットと、利用が承認されたナレッジの抜粋に基づくサポート返信を考えます。下書き担当が回答案を作成し、レビュー担当が各記述を抜粋と照合して、修正を求めるか、下書きを受け入れます。送信の許可は、別途、人が出します。

これは設計を説明する例であり、実行済みのベンチマークではありません。どちらの実装にも、同じ入力、プロンプト、レビュー基準を与えます。どちらのエージェントにも送信ツールは渡しません。そうすることで、フレームワークが作業と停止地点をどう表現するかに比較を絞れます。

これらは、ドキュメントにあるAutoGenの相互レビュー型チームのパターン、実行の合間のフィードバック、LangGraphのルーティング、割り込みを使った設計です。

AutoGenでは何を設定するか

下書き担当とレビュー担当に別々の指示を設定して作成し、RoundRobinGroupChatに配置します。公式チュートリアルでは、TextMentionTerminationを使い、エージェントの応答に特定の語が現れたら停止します。このアプリケーションでは、その停止を自動レビューの終了として扱い、送信許可として扱ってはいけません。結果を確認し、レビュー担当が評価した下書きを保存します。

アプリケーションには、修正をどこまで続けるかという上限を設けます。レビュー担当が根拠のない記述を見つけ続けるなら、指摘を添えて人に戻します。未解決の会話を、成功を示すトークンが出るまで終わらない処理にしてはいけません。

追加の実装が必要になるのは、対話の外側です。処理中のチケットを記録し、レビュー結果を保存し、安全に停止できる時点でチームの状態を永続化し、後から届く人の入力を正しい下書きにひも付けます。状態管理のチュートリアルが提供するのはシリアライズの基本機能であり、アプリケーションの復旧方針全体ではありません。

LangGraphでは何を設定するか

ticket_id、source_text、draft、review、approved、send_receiptなどのアプリケーション用フィールドを定義します。下書きからレビューへつなぎ、レビューで不合格になった場合は、修正方針が許す間は修正へ戻します。許容範囲を超えたら停止し、手動対応に回します。レビューを通過した下書きは、人による承認ステップへ進めます。

実装時には、下書きが変わるたびに以前の承認を無効化する、というルールが役立ちます。そうしないと、人が承認した文章とは別の文章をアプリケーションが後から送信しかねません。これはフレームワークの機能ではなく、アプリケーションが常に守るべき業務上の不変条件です。

送信は承認後に、独立した通常の関数で行います。その関数が、外部システムの送信受付記録をチケットおよび承認済みの下書きにひも付けて保存します。エージェントのレビュー結果と、人による実行許可は、別々のフィールドに保持します。

後からの承認と復旧が重要になるこのタスクでは、LangGraphが適しています。 AutoGenでもやり取りは分かりやすく表現できますが、業務の実行記録と、その前後に置く承認などの条件は、グラフのほうが直接的に表せます。未送信の下書きで完了し、やり直しも容易なタスクなら、移行時に解決すべきワークフローの要件は少なくなります。

チェックポイントと人による割り込み：復旧はどこまでできるか

会話の状態を保存できることと、ワークフローを再開できることは、保証する範囲が異なります。 AutoGenのエージェントとチームには、save_state()とload_state()があります。アプリケーションは、その状態をファイルやデータベースに保存できます。AutoGenには「記憶がない」と説明するのは、利用可能なAPIを正しく伝えていません。AutoGenの状態管理で確認できます。

LangGraphでは、スレッドのグラフ状態を保存するコンポーネントであるチェックポインターを使います。スレッドは、継続して扱うひとまとまりの作業を識別します。それとは別のストアには、複数のスレッドから利用するアプリケーションデータを格納します。現在のチケットを続行するには前者を、必要に応じて共有情報を永続的に保持するには後者を使います。永続化の概念に説明があります。

保存先の選択は重要です。InMemorySaverとMemorySaverはチェックポイントをRAMに保持するため、プロセスが再起動すると消えます。インメモリの保存先を使った割り込みのデモだけでは、再起動後に復旧できることは示せません。その要件には永続ストレージを使います。永続化のトラブルシューティングを参照してください。

後からレビューを受ける場合、LangGraphのinterrupt()で実行を一時停止し、外部入力を待ちます。再開にはCommand(resume=...)と、停止した実行と同じthread_idを使います。この識別子が、届いた判断を保存済みの作業に結び付けます。LangGraphの割り込みの挙動に詳細があります。

AutoGenのUserProxyAgentも、実行中に人のフィードバックを求められます。ただしドキュメントには、待機中のチームはブロックされ、その状態では保存も再開もできないという警告があります。人が後から戻る想定なら、いったん実行を終了し、状態を保存し、後の実行でフィードバックを渡して続ける方法が案内されています。AutoGenの人によるフィードバックを参照してください。

サポート返信の例では、アプリケーションが管理するリクエスト識別子と、保存した送信受付記録を使って送信を制御します。送信処理は承認後に配置し、リクエストが繰り返されても問題が起きないように設計します。承認ゲートを置くだけで、別サービスであるメール送信までトランザクションとして扱えるようになるわけではありません。

時間を置いて行う承認を、永続化と復旧を含めて扱うなら、LangGraphが適しています。 ただし、永続ストレージを設定し、再実行時の動作を意図して設計することが条件です。チェックポイントも会話ログも、それだけでは外部への操作が厳密に1回だけ実行された証拠にはなりません。

移行先はLangGraphか、Microsoft Agent Frameworkか？

どこまで自分で制御する必要があるかを基準に移行先を選び、現在のアプリケーションにどのような書き換えが必要かを比較します。 AutoGenを離れることが、そのままLangGraphを選ぶことを意味するわけではありません。

既存のAutoGenプロトタイプをLangGraphへ移す場合

プロトタイプの問題が状態の曖昧さにあるなら、LangGraphを選びます。どの成果物が最新なのか、失敗したジョブをどこから続けるべきか、現在の版を人が承認したのかが分からない、といった問題です。プロンプトを移植する前に、その不明点を明示的なフィールドと状態遷移に落とし込みます。

移行の価値は、こうした要件を直接確認できるようにすることにあります。従来の会話ログをグラフの中に再現しても、重要な判断がすべてメッセージに埋もれたままなら、依存先が増えるだけで運用上の改善はあまり得られません。

プロトタイプ内のエージェントに、固有のツール、コンテキスト、レビュー責任が割り当てられていないなら、移行時に構成を簡素化します。単一のエージェントのほうが適する条件は、マルチエージェントシステムのガイドで説明しています。

Microsoftの基盤との継続性ならMicrosoft Agent Framework

Microsoft Agent Frameworkは、AutoGenとSemantic Kernelの直接の後継です。エージェントに加え、エージェントと通常の関数をつなぐワークフローを提供します。アプリケーションや運用チームが、すでにMicrosoftのエージェント基盤や.NETに依存しているなら、まず検討する有力候補です。これは既存環境との統合を踏まえた判断であり、LangGraphでは同じ業務プロセスを実装できないという主張ではありません。Agent Frameworkの概要で確認できます。

現在のガイドは、AssistantAgentからAgentへの対応、AgentSessionによる会話の継続、チームの連携をワークフローのパターンに置き換える方法を説明しています。これらのワークフローは、型付きのデータフロー、人への入力要求、チェックポイントに対応しています。ツール呼び出しの反復動作も異なるため、移行時には実際のツール呼び出しの流れを再現して確認してください。AutoGenからの移行ガイドに詳細があります。

移行時に注意すべき不足部分は、独自の分散ランタイムです。 現在のガイドでは、Agent Frameworkの構成は単一プロセスとされ、分散実行は計画段階と説明されています。AutoGenのプロトタイプで分散Coreランタイムを使っているなら、エージェント単位の移植だけでデプロイ構成も維持できると考えないでください。使う予定の実際のランタイムとホスティング方式に照らし、この要件を別途検証する必要があります。これは移行ガイドが示す制約であり、Microsoftのあらゆるホスティングサービスに当てはまると述べているわけではありません。

Microsoftの後継への継続性を重視するなら、Microsoft Agent Frameworkが適しています。 課題は互換性です。エージェントの概念が似ていても、メッセージのルーティング、セッションの挙動、実行構成まで同じとは限りません。一方、アプリケーションの状態を明確にするために設計を見直すことが移行の目的なら、LangGraphが適しています。

移行には何が必要か、急がなくてよいのはどんな場合か

移行コストの中心は、挙動の再現、状態の変換、運用上の検証です。 プロンプトやツールの実装は再利用できるかもしれませんが、実行順序、コンテキスト、永続化のルールは確認が必要です。importの書き換え数を基準にせず、ひとつの業務処理を最後まで動かすための作業として見積もります。

最初の対象には、サポート返信が適しています。入力、下書きという成果物、レビュー結果、人による承認、最後の送信受付記録を観察できるためです。エージェントの集まりを一括で移し、最終回答が以前と似ていることに期待するよりも、移行を検証しやすい単位になります。

1. 1

   現在の挙動を記録する

   代表的な入力、利用が承認された参照資料、プロンプト、ツールのスキーマ、出力、失敗例を保存します。モデルと依存ライブラリのバージョンも記録します。レビュー担当が却下するケースと、人への確認が必要になるケースを含めてください。これらを新しい実装の受け入れ確認に使います。

2. 2

   アプリケーションの記録を独立した形式でエクスポートする

   チケット識別子、下書き、レビューの指摘、人の判断、外部操作の受付記録を、アプリケーションが管理する形式で保存します。会話ログは経緯の参照用に残しますが、フレームワークがシリアライズした状態データを、そのまま移植可能な業務記録とは見なさないでください。処理の継続に必要なデータには、明示的な対応表を作ります。

3. 3

   最後まで完結する最小のワークフローを再構築する

   LangGraphでは、状態スキーマと経路を定義します。Microsoft Agent Frameworkでは、現在のガイドに従って、エージェント、セッション、ワークフローのエグゼキューターを対応付けます。タスクの入力と評価基準は変えず、オーケストレーションの変更による影響を、モデルやプロンプトの変更による影響と区別できるようにします。

4. 4

   障害が起きる境界で動作を確かめる

   ジョブが承認を待っている間にワーカーを停止します。再起動後に再開し、下書きの却下、再開リクエストの重複、外部操作の失敗を試します。保存されたアプリケーションの記録と、最後の受付記録を確認してください。もっともらしい最終回答が得られただけでは、ワークフローが正しく復旧した証拠にはなりません。

5. 5

   実行途中の処理をどう完了させるか決める

   保留中のジョブを旧実装で完了させるか、明示的に状態を変換して引き継ぐかを決めます。識別子と、承認がどの下書きに対応するかという関係を保持してください。互換性のない新しいワークフローに、古いチェックポイントをそのまま渡してはいけません。

LangGraphにも、導入後の変更に伴う制約があります。Graph APIのドキュメントは、中断中のスレッドが必要とするノードの名前を変えたり、ノードを削除したりしないよう警告しています。今後のデプロイでも、ワークフローの定義と保存済みの状態の間では、互換性を維持する必要があります。グラフの移行に関する制約に記載されています。

独立した研究用プロトタイプで、有用な出力をすでに保存しており、今後は廃止する予定なら、大規模な書き換えを急ぐ必要はありません。知見を取り出し、継続する用途だけを移行します。稼働中のAutoGenアプリケーションでは、検証を伴わない置き換えより、管理された段階的な移行が適切です。ただし、アーカイブ化は移行を計画する理由であり、古い依存先への用途を広げ続ける理由にはなりません。

候補を広く比較するなら、ほかの選択肢も扱うAIエージェントのフレームワーク比較を参照してください。残る候補がCrewAIなら、LangGraphとCrewAIの比較がその判断に役立ちます。

**次に行うこと：**繰り返し発生する業務をひとつ選び、再起動しても残すべき記録と、最終操作を許可できる人を明確にします。その要件を最も分かりやすく表現できるフレームワークを選び、その業務を最初から最後まで検証してから、残りを移します。

よくある質問

AutoGenとLangChainの主な違いは何ですか？

AutoGen AgentChatは、チームとメッセージを軸に複数のエージェントを連携させます。LangChainは、モデル、ツール、エージェントの抽象化を提供し、その下でオーケストレーションを担うのがLangGraphです。状態を持つ独自のワークフローを比較するなら、LangGraphのほうが直接の比較対象になります。また、AutoGenがアーカイブ済みであることも、新規開発での選択を左右します。

2026年にLangChainを学ぶ価値はありますか？

モデルやツールの抽象化がアプリケーションに合うなら、学ぶ価値はあります。ワークフローの状態と遷移を自分で指定したい場合は、LangGraphを直接学びます。AutoGenのプロトタイプを移行するために、スタックのすべてのレイヤーを採用する必要はありません。

CrewAIはLangGraphより優れていますか？

どの用途でも優れるという答えはありません。明示的な状態、復旧の区切り、独自の承認ロジックがアプリケーションを左右するなら、まずLangGraphを評価します。同じ業務を最後まで実行する条件でCrewAIも比較してから選んでください。フレームワークの好みだけでは、タスクの品質は判断できません。

AutoGenとは何ですか？

本記事のAutoGenは、microsoft/autogenで公開されている、Microsoftのマルチエージェントアプリケーション向けフレームワークを指します。取り上げる実装はAgentChatのチームAPIで、必要に応じて、その下層のCoreランタイムや実験的なGraphFlowを区別しています。

AutoGenは非推奨になったのですか？

Microsoftの現在のREADMEでは、さらに踏み込んだ「アーカイブ済み」という状態が示され、メンテナンスが終了したと明記されています。新規ユーザーにはMicrosoft Agent Frameworkを案内し、既存ユーザーには移行を促しています。保守段階が続いていると考えず、現在の表記を基準にしてください。

AutoGenとMicrosoft Agent Frameworkは同じものですか？

同じものではありません。Microsoft Agent Frameworkは後継であり、エージェント、セッション、ツール、ワークフローのAPI変更を扱う移行ガイドがあります。移行にはアプリケーションの挙動の検証が必要で、インストール済みのAutoGenパッケージの名前が変わっただけではありません。

エージェント型AIのフレームワークはどれが最適ですか？

本記事の読者には、アプリケーションの状態の明示とワークフローの制御が決め手ならLangGraphを、Microsoftの後継への移行と既存のエコシステムが決め手ならMicrosoft Agent Frameworkを勧めます。そもそも対象のタスクに複数のエージェントが必要かどうかは、フレームワークだけでは判断できません。

AutoGenとSemantic Kernelの主な違いは何ですか？

Microsoftの紹介記事では、AutoGenがもたらしたものを実験的なマルチエージェントのオーケストレーション、Semantic Kernelがもたらしたものを企業向けアプリケーションSDKの基盤と説明しています。Microsoft Agent Frameworkは、その両者を統合しています。これからAutoGenを移行するなら、過去の区分だけに選択肢を限定せず、現在の後継を評価してください。

マルチエージェントのフレームワークはどれを選ぶべきですか？

必要な挙動を明確に表現でき、保守しやすいものが最適です。本記事のサポート業務では、レビュー、人による実行許可、送信を別々の状態にする必要があるため、LangGraphを推奨します。後継への継続性をより重視する場合は、Microsoft Agent Frameworkが代替候補です。

移行前に、AI業務ワークフロー監査チェックリストを使い、対象の業務、どこで承認が必要か、運用の責任者を定義してください。