はじめに
2025年10月、MicrosoftはAutoGenのメンテナンスモード入りを発表しました。
2026年3月現在、AutoGenは既にメンテナンスモードに移行しています。
重要な新機能は追加されず、バグ修正と重要なセキュリティ修正は継続される状態です。
私自身、AutoGenでマルチエージェントの社内ツールを構築していました。
ドキュメント分析とSlack通知を組み合わせた業務自動化ツールです。
メンテナンスモード入りの発表を受け、移行先の検討を始めています。
この記事では、AutoGenに何が起きたのかを整理します。
その上で、2026年時点の主要フレームワークを比較し、選定基準を示します。
AutoGenメンテナンスモード移行の経緯
何が起きたのか
AutoGenはMicrosoft Researchが2023年に公開したフレームワークです。
マルチエージェント会話という概念を広め、多くの開発者に採用されました。
2025年10月、Microsoftは「Microsoft Agent Framework」を発表しました。
AutoGenとSemantic Kernelを統合した新しいSDKです。
これに伴い、AutoGenは段階的にメンテナンスモードへ移行しました。
AutoGenの既存ワークロードに破壊的変更は予定されていません。
ただし、重要な新機能は追加されず、バグ修正と重要なセキュリティ修正のみ継続されます。
既存プロジェクトがある場合は、計画的な移行を推奨します。
AutoGenの貢献 — マルチエージェントの概念を広めた功績
2023年9月、Microsoft ResearchがAutoGenを公開したとき、開発者コミュニティで大きな注目を集めました。
「エージェント同士が会話する」という概念を、実用的なフレームワークとして初めて形にしたのです。
公開から数ヶ月でGitHub Starsは30,000を超えました。
2024年末には38,000 Starsに到達し、AIエージェント分野で最も注目されるOSSの一つになりました。
Microsoft内部での活用はもちろん、Ally Financial、Accenture、Novo Nordiskといった企業での採用事例が報告されています。
AutoGenが広く採用された理由は主に3つあります。
- 会話ベースの直感的なAPI — エージェント間のやり取りを会話として記述できた
- Microsoft Researchの信頼性 — 研究機関発のフレームワークとしての安心感
- 柔軟なエージェント定義 — コード実行、関数呼び出し、人間の介入を統一的に扱えた
特に「エージェント同士が会話する」というメタファーは強力でした。
複雑なワークフローを、人間同士の会議のように設計できたのです。
v0.2からv0.4への転換 — 開発者を悩ませた設計変更
しかし、AutoGenの道のりは平坦ではありませんでした。
v0.2はConversableAgentを中心としたシンプルなAPIで人気を博しました。
ところが2024年後半に発表されたv0.4では、アーキテクチャが根本から刷新されます。
「Agentic API」と呼ばれる新設計では、非同期メッセージパッシング、イベント駆動型のランタイム、型付きメッセージが導入されました。
# v0.2 — シンプルな会話パターン
from autogen import AssistantAgent, UserProxyAgent
assistant = AssistantAgent("assistant", llm_config=llm_config)
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding"})
user_proxy.initiate_chat(assistant, message="Pythonでフィボナッチ数列を書いて")
# v0.4 — イベント駆動型に刷新
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient
model_client = OpenAIChatCompletionClient(model="gpt-4o")
agent = AssistantAgent("assistant", model_client=model_client)
team = RoundRobinGroupChat([agent])
result = await team.run(task="Pythonでフィボナッチ数列を書いて")
pyautogenパッケージ(PyPI)は、バージョン0.2.34以降Microsoft管理外となっています。Microsoft公式のパッケージはautogen-agentchat等の名前で公開されています。pyautogenを使用している場合は、パッケージの出所に注意してください。
v0.2で書いた既存コードはv0.4にそのまま移行できません。
クラス名、インポートパス、実行パターンのすべてが変わりました。
この破壊的変更により、多くの開発者が「せっかく学んだAPIが使えなくなった」という不満を抱えることになります。
さらに、ノーコードでマルチエージェントを構築できるAutoGen Studioも同様の運命をたどりました。
AutoGen Studioはプロトタイピングや教育用途で人気がありましたが、AutoGen本体と一緒にメンテナンスモードに移行しています。
v0.2系のAutoGen Studioを使っていたチームは、UIツールごと移行先を探す必要があります。
なぜ方向転換したのか
Microsoftはエンタープライズ市場でのAIエージェント統合を加速させています。
Azure AI、Copilot、Dynamics 365といった製品群との連携が優先事項です。
AutoGenは研究プロジェクトとしては成功しました。
しかし、プロダクション環境での運用、ガバナンス、スケーラビリティに課題がありました。
Semantic Kernelとの機能重複も整理が必要でした。
Microsoft Agent Frameworkは2026年3月時点でpublic previewの段階です。
public preview版ではグラフワークフロー、A2Aプロトコル、MCP対応が含まれます。
チェックポイント、ストリーミング、Human-in-the-Loopも標準サポートです。
主要フレームワークの比較
ここからは、2026年時点で選択肢となる4つのフレームワークを見ていきます。
LangGraph v1.0 — ステートフルなグラフ実行
LangGraphは2025年10月にv1.0に到達しました。
Uber、LinkedIn、Klarnaなど大規模なプロダクション環境での実績があります。
LangGraphの最大の特徴は「永続的な状態管理」です。
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import MemorySaver
# グラフの状態を定義
class AgentState(TypedDict):
messages: list
next_step: str
# グラフを構築
graph = StateGraph(AgentState)
graph.add_node("analyze", analyze_node)
graph.add_node("respond", respond_node)
graph.add_edge(START, "analyze")
graph.add_conditional_edges("analyze", route_decision)
graph.add_edge("respond", END)
app = graph.compile(checkpointer=MemorySaver())
強み:
- サーバー再起動時も実行状態を自動復元できる
- Human-in-the-Loopが第一級APIとしてサポートされている
- Python/JavaScript両対応で、チーム構成を選ばない
- LangChainエコシステムとの統合が自然
弱み:
- LangChainへの依存が完全には切れない
- グラフ定義の学習コストがやや高い
- 小規模なタスクにはオーバースペックになりがち
CrewAI — ロールベースのチーム編成
CrewAIはエージェントに「役割」を与えるアプローチを取ります。
2026年3月時点の最新版では、プロダクション向けのFlowsアーキテクチャが安定しました。
from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="リサーチャー",
goal="最新の技術トレンドを調査する",
backstory="10年の調査経験を持つアナリスト",
tools=[search_tool, scrape_tool]
)
writer = Agent(
role="ライター",
goal="調査結果を分かりやすい記事にまとめる",
backstory="テクニカルライティングの専門家"
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential
)
強み:
- 役割ベースの設計が直感的で、非エンジニアにも説明しやすい
- Flowsによるイベント駆動ワークフローが本番運用に耐える
- GPT-4.1、Gemini-2.5 Proなど最新モデルへの対応が速い
- トレーシング・オブザーバビリティが組み込まれている
弱み:
- 複雑な条件分岐やループの表現力ではLangGraphに劣る
- エンタープライズ機能はAMP Suite(有償)が前提になる場合がある
- Python専用で、JSエコシステムからは利用できない
Mastra — TypeScript/JSエコシステムの選択肢
MastraはGatsbyの開発チームが2026年1月に公開したフレームワークです。
Y Combinator W25卒業、$13Mの資金調達、GitHub Stars 22k超と勢いがあります。
import { Agent } from "@mastra/core";
const analyst = new Agent({
name: "data-analyst",
instructions: "データを分析し、要点をまとめてください",
model: "gpt-4.1",
tools: [fetchDataTool, chartTool],
});
const result = await analyst.generate(
"直近3ヶ月の売上データを分析してください"
);
強み:
- TypeScriptネイティブで、Webエンジニアが馴染みやすい
- Mastra Studioで、ローカル環境でのデバッグ・可視化ができる
- RAG、ワークフロー、メモリ管理が一体化している
- npm週間30万ダウンロード超と、JSエコシステムでの採用が急速に進んでいる
弱み:
- 2026年1月公開と歴史が浅く、大規模プロダクション事例が限られる
- Pythonの機械学習ライブラリとの連携は間接的になる
- 破壊的変更のリスクが他のフレームワークより高い
Microsoft Agent Framework — AutoGenの後継
AutoGenからの移行先として最も自然な選択肢です。
AutoGenの概念を引き継ぎつつ、Semantic Kernelの堅牢性を統合しています。
強み:
- AutoGenからの公式移行ガイドが提供されている
- Azure AI、Copilot等のMicrosoft製品群とのネイティブ統合
- エンタープライズ向けのガバナンス機能が充実
弱み:
- 2026年3月時点でpublic previewであり、正式リリース前の変動リスクがある
- Microsoftエコシステムへのロックインが進む
- OSSコミュニティの規模ではLangGraphやCrewAIに劣る
実践的ユースケースで比較する — ドキュメント分析パイプライン
ここまでの比較は抽象的な特徴の列挙でした。
実際のユースケースでコードを書くと、各フレームワークの設計思想の違いが鮮明に見えます。
以下のパイプラインを各フレームワークで実装してみます。
要件: PDFドキュメントを分析 → 要約を生成 → Slack通知を送信
LangGraph版 — グラフで制御フローを明示
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import MemorySaver
class PipelineState(TypedDict):
pdf_path: str
extracted_text: str
summary: str
slack_result: str
def extract_text(state: PipelineState) -> dict:
# PDF解析処理
text = parse_pdf(state["pdf_path"])
return {"extracted_text": text}
def summarize(state: PipelineState) -> dict:
# LLMで要約生成
summary = llm.invoke(f"以下を300字で要約:\n{state['extracted_text']}")
return {"summary": summary.content}
def notify_slack(state: PipelineState) -> dict:
# Slack通知
result = slack_client.chat_postMessage(
channel="#reports", text=f"要約完了:\n{state['summary']}"
)
return {"slack_result": "sent"}
# グラフ構築
graph = StateGraph(PipelineState)
graph.add_node("extract", extract_text)
graph.add_node("summarize", summarize)
graph.add_node("notify", notify_slack)
graph.add_edge(START, "extract")
graph.add_edge("extract", "summarize")
graph.add_edge("summarize", "notify")
graph.add_edge("notify", END)
app = graph.compile(checkpointer=MemorySaver())
result = app.invoke({"pdf_path": "report.pdf"})
LangGraphでは、各処理がノードとして独立し、エッジで実行順を定義します。
checkpointerを設定すれば、途中で失敗しても再開できます。
制御フローが可視化しやすい反面、単純なパイプラインでもグラフ定義のコード量がやや多くなります。
CrewAI版 — 役割を持ったエージェントチーム
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
from crewai import Agent, Task, Crew, Process
# エージェント定義
analyst = Agent(
role="ドキュメントアナリスト",
goal="PDFから重要な情報を抽出する",
backstory="10年の文書分析経験を持つ専門家",
tools=[pdf_parser_tool]
)
summarizer = Agent(
role="要約エディター",
goal="抽出された情報を簡潔に要約する",
backstory="テクニカルライティングの専門家"
)
notifier = Agent(
role="通知マネージャー",
goal="要約をSlackに通知する",
backstory="社内コミュニケーション担当",
tools=[slack_tool]
)
# タスク定義
extract_task = Task(
description="report.pdf の内容を分析し、主要な論点を抽出してください",
agent=analyst,
expected_output="主要な論点のリスト"
)
summary_task = Task(
description="抽出された論点を300字以内で要約してください",
agent=summarizer,
expected_output="300字以内の要約文"
)
notify_task = Task(
description="要約を #reports チャンネルに通知してください",
agent=notifier,
expected_output="送信完了の確認"
)
crew = Crew(
agents=[analyst, summarizer, notifier],
tasks=[extract_task, summary_task, notify_task],
process=Process.sequential
)
result = crew.kickoff()
CrewAIでは、「誰が何をするか」が自然言語で記述されます。
非エンジニアにもワークフローが説明しやすい設計です。
一方で、各エージェントがLLM呼び出しを行うため、単純なパイプラインではトークン消費が多くなる傾向があります。
開発体験(DX)の比較
| 観点 | LangGraph | CrewAI | Mastra |
|---|---|---|---|
| デバッグ | LangSmithで実行トレースを可視化。ノード単位でステップ実行可能 | CrewAI Enterpriseのダッシュボードでトレース確認。OSSではログ出力に依存 | Mastra Studioでローカルデバッグ。ブラウザ上でエージェントの動作を確認可能 |
| エラーメッセージ | 型ヒント活用でIDEレベルのエラー検出。グラフ定義ミスは実行時エラー | 自然言語ベースのため、意図と異なる動作の原因特定が難しい場合がある | TypeScriptの型システムにより、コンパイル時に多くのエラーを検出 |
| ドキュメント | 公式チュートリアル、APIリファレンス、cookbookが充実。LangChain Academy無料講座あり | 公式ドキュメントは整備されているが、高度なFlowsの事例が少ない | 急成長中でドキュメントの更新が追いつかない部分がある。コミュニティは活発 |
| 学習コスト | グラフ理論の基礎知識があると理解が早い。初学者にはやや敷居が高い | ロールベースの概念は直感的。プログラミング経験が浅くても入門しやすい | Web開発経験があれば自然に入れる。Python経験のみだと環境構築に時間がかかる |
用途別選定フローチャート
テーブル形式だけでは判断しにくいので、Mermaidフローチャートで選定フローを示します。
参考として、テーブル形式でも整理しておきます。
| 要件 | 推奨フレームワーク | 理由 |
|---|---|---|
| AutoGenからの移行で、Azure環境を使用 | Microsoft Agent Framework | 公式移行パス、Azure統合 |
| 長時間実行ワークフロー、複雑な状態管理 | LangGraph | 永続状態、チェックポイント |
| 役割分担が明確なチーム型エージェント | CrewAI | ロールベース設計、直感的API |
| TypeScript/Next.jsベースのWebアプリ | Mastra | TS ネイティブ、Web統合 |
| 研究・プロトタイピング目的 | LangGraph or CrewAI | エコシステムの厚さ |
| エンタープライズ・ガバナンス重視 | MS Agent Framework | 監査、コンプライアンス対応 |
フレームワーク選定で最も重要なのは「チームの技術スタック」です。
Pythonチームなら LangGraph か CrewAI、TypeScriptチームなら Mastra が自然です。
Microsoft環境に投資済みなら、Agent Frameworkが最もスムーズです。
移行パス: AutoGen → 各フレームワーク(コード例付き)
まず、AutoGenの典型的なパターンを確認します。
AssistantAgentとUserProxyAgentの組み合わせは、AutoGenで最も基本的な構成です。
# AutoGen v0.2 — 基本パターン(Before)
from autogen import AssistantAgent, UserProxyAgent
assistant = AssistantAgent(
"assistant",
llm_config={"model": "gpt-4o", "api_key": os.environ["OPENAI_API_KEY"]},
system_message="あなたはデータ分析の専門家です。"
)
user_proxy = UserProxyAgent(
"user_proxy",
human_input_mode="NEVER",
code_execution_config={"work_dir": "output", "use_docker": False},
max_consecutive_auto_reply=3
)
# 会話を開始
user_proxy.initiate_chat(
assistant,
message="売上データをCSVから読み込み、月次トレンドをグラフにしてください"
)
Microsoft Agent Frameworkへの移行
最も公式にサポートされたパスです。
Microsoftが移行ガイドを公開しています。
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
# Microsoft Agent Framework(After)
from agent_framework import Agent, AgentRuntime
from agent_framework.orchestration import SequentialOrchestrator
from semantic_kernel import Kernel
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(model="gpt-4o"))
analyst = Agent(
name="analyst",
kernel=kernel,
instructions="あなたはデータ分析の専門家です。",
plugins=[CodeExecutionPlugin(work_dir="output")]
)
orchestrator = SequentialOrchestrator(agents=[analyst])
result = await orchestrator.invoke(
"売上データをCSVから読み込み、月次トレンドをグラフにしてください"
)
主な変更点は以下の通りです。
-
autogen.AssistantAgent→Agentへのクラス置換。Semantic Kernelベースに変更 -
UserProxyAgentの概念は廃止。Human-in-the-Loopはオーケストレーターで制御 - 会話パターンはグラフワークフロー / オーケストレーターパターンとして再定義
LangGraphへの移行
AutoGenの会話フローを、LangGraphのグラフ構造にマッピングします。
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
# LangGraph(After)
from langgraph.graph import StateGraph, START, END
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
llm = ChatOpenAI(model="gpt-4o")
# ツール定義
@tool
def execute_code(code: str) -> str:
"""Pythonコードを実行して結果を返す"""
exec_result = run_in_sandbox(code, work_dir="output")
return exec_result
# ReActエージェントとして構築
agent = create_react_agent(
model=llm,
tools=[execute_code],
prompt="あなたはデータ分析の専門家です。"
)
# 実行
result = agent.invoke({
"messages": [{"role": "user",
"content": "売上データをCSVから読み込み、月次トレンドをグラフにしてください"}]
})
マッピングの要点は以下の通りです。
- エージェント間の会話 → ノード間のエッジとして定義
-
UserProxyAgent→ Human-in-the-Loopノード(interrupt_before)に置換 - コード実行機能 → ツール(
@toolデコレータ)として分離 -
max_consecutive_auto_reply→recursion_limitで制御
CrewAIへの移行
AutoGenのエージェント定義を、CrewAIのロール定義に変換します。
以下は概念を示すための簡略化したコードです。完全な実装は各フレームワークの公式ドキュメントを参照してください。
# CrewAI(After)
from crewai import Agent, Task, Crew, Process
analyst = Agent(
role="データ分析専門家",
goal="データを分析し、分かりやすいグラフを作成する",
backstory="統計学とデータ可視化の経験が豊富なアナリスト",
tools=[csv_reader_tool, chart_tool],
allow_code_execution=True
)
analysis_task = Task(
description="売上データをCSVから読み込み、月次トレンドをグラフにしてください",
agent=analyst,
expected_output="月次トレンドのグラフファイルと分析コメント"
)
crew = Crew(
agents=[analyst],
tasks=[analysis_task],
process=Process.sequential
)
result = crew.kickoff()
マッピングの要点は以下の通りです。
-
AssistantAgent(system_message=...)→Agent(role=..., goal=..., backstory=...)に対応 - グループチャット →
Crew(process=Process.sequential)に対応 -
human_input_mode→human_input=True/Falseで制御 - 複雑な条件分岐はFlowsで再実装する必要がある
移行パスの全体像
「フレームワーク疲れ」にどう向き合うか
ここまでフレームワーク比較をしてきましたが、率直に言って疲れます。
2023年にAutoGenを学び、2024年にv0.4への移行を検討し、2025年にメンテナンスモードを知る。
その間にLangChain、LlamaIndex、CrewAI、Mastraと新しいフレームワークが次々と登場しました。
「今選んだフレームワークは来年もあるのか」という問いは、冗談ではなく切実です。
現実的な生存戦略
この状況を嘆いても仕方がないので、現実的な対策を考えます。
1. フレームワーク固有のコードを最小化する
ビジネスロジック(ドキュメント分析、要約生成、通知送信)をフレームワーク非依存の関数として書きます。
フレームワークはそれらを「つなぐ糊」としてのみ使います。
# フレームワーク非依存のビジネスロジック
def analyze_document(pdf_path: str) -> str:
"""PDFを分析して要点を返す。フレームワークに依存しない。"""
text = extract_text_from_pdf(pdf_path)
return summarize_with_llm(text)
def send_notification(channel: str, message: str) -> bool:
"""通知を送信する。フレームワークに依存しない。"""
return slack_client.chat_postMessage(channel=channel, text=message)
# フレームワーク層は薄いラッパーのみ
# LangGraphで使う場合
def analyze_node(state):
result = analyze_document(state["pdf_path"])
return {"summary": result}
2. 標準プロトコルに賭ける
2025年から2026年にかけて、AIエージェント間の通信プロトコルが標準化に向かっています。
AnthropicのMCP(Model Context Protocol)やGoogleのA2A(Agent-to-Agent)プロトコルがその例です。
フレームワークは変わっても、プロトコルへの対応は引き継がれる可能性が高いです。
3. 「完璧な選択」を諦める
どのフレームワークも1〜2年後にはAPIが変わります。
重要なのは「今のチームが最も生産的に使えるもの」を選ぶことです。
移行コストを最小化する設計(上記のビジネスロジック分離)さえしておけば、フレームワークの乗り換えは致命的にはなりません。
フレームワーク選定に1週間かけるより、ビジネスロジックをフレームワーク非依存に設計する方が長期的なリターンは大きいです。
まとめ
AutoGenのメンテナンスモード入りは、一つの時代の区切りです。
2023年から2025年にかけて、AutoGenはマルチエージェントの可能性を示しました。
その成果は、後継のフレームワークにしっかり引き継がれています。
2026年のエージェントフレームワークは「整理と統合」のフェーズに入っています。
選択肢が絞られたことは、開発者にとってむしろ良い変化です。
自分のプロジェクトの要件とチームのスキルセットに合わせて選べば、大きく外すことはありません。
私自身のAutoGen製社内ツールは、LangGraphへの移行を進めています。
理由は、状態管理の堅牢さと、Python/JS両対応である点です。
移行作業の知見は、別の記事でまとめる予定です。
参考リンク: