5
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AutoGenがメンテナンスモード入り — 2026年AIエージェントフレームワーク選定ガイド

5
Posted at

はじめに

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つあります。

  1. 会話ベースの直感的なAPI — エージェント間のやり取りを会話として記述できた
  2. Microsoft Researchの信頼性 — 研究機関発のフレームワークとしての安心感
  3. 柔軟なエージェント定義 — コード実行、関数呼び出し、人間の介入を統一的に扱えた

特に「エージェント同士が会話する」というメタファーは強力でした。
複雑なワークフローを、人間同士の会議のように設計できたのです。

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.AssistantAgentAgent へのクラス置換。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_replyrecursion_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_modehuman_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両対応である点です。
移行作業の知見は、別の記事でまとめる予定です。


参考リンク:

5
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?