AutoGenでマルチエージェントを組んできたものの、Microsoft Agent Framework(MAF)が新しい基盤として案内され、どう移せばいいか迷っている方は多いはずです。結論から言えば、AutoGen Microsoft Agent Framework 移行の勘所は、AssistantAgentをAgentへ、Teamベースの制御をWorkflowへ置き換え、既定がマルチターンに変わる点を押さえることに尽きます。基礎の考え方(モデルクライアントを中心にエージェントを作り、指示を与え、ツールを付ける)は共通なので、丸ごと作り直す必要はありません。この記事では、公式の移行ガイドに沿って、変わらない部分と変わる部分、コードの対応、そして筆者が自社の自動化エージェントを移すときの実践手順まで、コードつきでまとめます。
この記事の要点
- Microsoft Agent Framework(MAF)は、MicrosoftのAutoGenチームとSemantic Kernelチームが開発した後継SDKで、AutoGenで培った設計を発展させた「今後の基盤」に位置づけられています。
- 移行の中心は3つの置き換えです。
AssistantAgent→Agent、FunctionTool→@tool、Teamベースの制御→型付きグラフのWorkflow。引数名もmodel_client→client、system_message→instructionsと変わります。 - 最大の落とし穴は既定の挙動が変わることです。AutoGenの
AssistantAgentは既定シングルターン(max_tool_iterations=1)ですが、MAFのAgentは既定でマルチターンになり、最終回答までツールを呼び続けます。
01AutoGenからMicrosoft Agent Frameworkへの移行とは|何が変わるのか
AutoGenからMicrosoft Agent Frameworkへの移行とは、AutoGenで書いたエージェントのコードを、後継SDKであるMAFのAPIに置き換える作業です。公式ドキュメントによると、MAFはMicrosoftのコアAutoGenチームとSemantic Kernelチームが開発した多言語SDKで、AutoGenで開拓されたアイデアを大きく発展させ、今後AIアプリケーションを構築するための新しい基盤として設計されています。両チームの知見が1つに統合されたため、これからマルチエージェントを新規に組むならMAFが標準の入口になります。
Microsoft Agent Framework(MAF)はAutoGenの後継
MAFは、AutoGenとSemantic Kernelという2つの流れを1本化した後継SDKです。AutoGenが持っていたイベント駆動のマルチエージェント設計と、Semantic Kernelのエンタープライズ寄りの作りを取り込み、エージェント・ワークフロー・ツール・状態・ホスティングを1つのモデルの裏にそろえる方向でまとめられています。既存のAutoGen資産をすぐ捨てる必要はありませんが、新機能は今後MAF側で進むため、長く使うコードほど早めの移行が現実的です。MAF自体の全体像はMicrosoft Agent Framework とは?AutoGenとの違いで解説しています。
移行で「変わらない部分」と「変わる部分」
移行で安心してよいのは、基礎の考え方がそのまま使える点です。公式ガイドも「基礎は使い慣れている」と述べており、モデルクライアントを中心にエージェントを作り、指示を与え、ツールを付ける、という組み立ては両者で共通します。関数スタイルのツール、トークンストリーミング、マルチモーダル入力、非同期I/Oも、どちらも対応しています。変わるのは、オーケストレーションの仕組み、ツールの定義方法、エージェントの既定動作、ランタイムの4点です。この4点が、移行でコードに手を入れる中心になります。
02AutoGenとMicrosoft Agent Frameworkの違い【比較表】
AutoGenとMAFの違いは、APIが「似ているが同一ではない」という表現がいちばん近いです。呼び出しの形は近いものの、クラス名・引数名・既定の挙動が変わります。移行前に押さえるべき差分を表にまとめます。
移行でアウトプットはどう変わると想定されるか?
この仕様差から、移行後は「エージェントが1回の指示でどこまで自走するか」が変わると想定されます。AutoGenの既定はツール呼び出し1回で止まるため、多段の処理は自分でループを組む前提でした。MAFは既定でマルチターンになり、最終回答が返るまでツールを呼び続けるので、同じコードでも呼び出し回数やトークン消費が増える方向に振れる想定です。ここで述べた変化は仕様差から見込まれる想定で、実測した数値ではありません。移行直後は、既定動作の違いが出力や課金に響かないかを小さな範囲で確かめるのが安全です。
03移行の準備|パッケージとモデルクライアントの確認
移行の第一歩は、MAFのパッケージを入れ、モデルクライアントを置き換えることです。ここではPythonを前提に、導入とクライアント差し替えの勘所を説明します。
agent_framework パッケージの導入
MAFのPython SDKはagent_frameworkというモジュールで提供されます。インストールは公式のセットアップ手順に従い、OpenAIやAzure OpenAIなど使うプロバイダー向けの構成を合わせます。移行の初期は、AutoGenの環境をいきなり置き換えず、別の仮想環境にMAFを入れて動作を見比べると安全です。読み込みは、AutoGenのfrom autogen_agentchat.agents import AssistantAgentに対して、MAFではfrom agent_framework import Agent, toolのように変わります。
モデルクライアントの置き換え(OpenAIChatClientなど)
どちらのフレームワークも主要プロバイダー向けのモデルクライアントを持ちますが、APIは似ていても同一ではありません。MAFでは、OpenAIのチャット補完ならOpenAIChatClient、Azure OpenAIやFoundryプロジェクト向けには専用のチャットクライアントや応答(Responses)クライアントが用意されています。OpenAI Assistants固有の面はMAFのPythonガイドでは中心から外れ、直接のOpenAI/Azure利用にはResponsesクライアント、サービス管理のエージェントにはFoundryのエージェントへ寄せる形が案内されています。
# AutoGen: モデルクライアントとエージェント
from autogen_agentchat.agents import AssistantAgent
agent = AssistantAgent(name="assistant", model_client=client, tools=[my_tool])
result = await agent.run(task="Help me with this task")
# MAF: モデルクライアントとエージェント
from agent_framework import Agent, tool
from agent_framework.openai import OpenAIChatClient
client = OpenAIChatClient(model="gpt-5")
agent = Agent(name="assistant", client=client, tools=[my_tool])
result = await agent.run("Help me with this task")
04基本エージェントの移行手順|AssistantAgentからAgentへ
単一エージェントの移行は、クラス名と引数名の対応さえ押さえれば、機械的に進められます。まずは置き換えの対応表を見てから、AutoGen版とMAF版のコードを並べて確認します。
AutoGen版のコード
AutoGenではAssistantAgentにモデルクライアントとシステムメッセージ、ツールを渡し、max_tool_iterations=1で既定のシングルターンを指定していました。実行はagent.run(task="...")の形です。
from autogen_agentchat.agents import AssistantAgent
agent = AssistantAgent(
name="assistant",
model_client=client,
system_message="You are a helpful assistant.",
tools=[my_tool],
max_tool_iterations=1 # 既定はシングルターン
)
result = await agent.run(task="What's the weather?")
Microsoft Agent Framework版のコード
MAFではAgentにclientとinstructions、ツールを渡します。ツールは@toolデコレータで定義し、スキーマは自動で推論されます。実行はagent.run("...")のように、タスクを位置引数で渡します。client.as_agent(...)というファクトリメソッドを使うと、より簡潔に書けます。
from agent_framework import Agent, tool
from agent_framework.openai import OpenAIChatClient
@tool
def get_weather(location: str) -> str:
"""Get weather for a location."""
return f"Weather in {location}: sunny"
client = OpenAIChatClient(model="gpt-5")
agent = Agent(
name="assistant",
client=client,
instructions="You are a helpful assistant.",
tools=[get_weather], # 既定でマルチターン
)
result = await agent.run("What's the weather?")
引数名の対応(model_client→client / system_message→instructions)
移行で最初に直すのは引数名です。model_clientはclientに、system_messageはinstructionsに変わります。実行時のtask=は位置引数に変わり、agent.run("...")と書きます。ここは対応表どおりに置換すれば済む範囲です。
既定がマルチターンに変わる点に注意
いちばん注意したいのは既定動作です。AutoGenはmax_tool_iterations=1でシングルターンでしたが、MAFのAgentは既定でマルチターンになり、最終回答が返るまでツールを呼び続けます。従来シングルターン前提で組んでいた処理は、そのまま移すと想定より多くツールを呼ぶ可能性があります。移行後は、この差が出力や実行回数に影響しないかを確かめる工程を挟みます。
05ツールとマルチエージェントの移行|@toolとWorkflow
単一エージェントの次は、ツール定義とマルチエージェントの制御を移します。ここが移行の山場で、書き方の発想がいちばん変わる部分です。
FunctionToolから@toolへ
AutoGenでは関数をFunctionToolでラップしてツール化していました。MAFでは関数に@toolを付けるだけで、引数の型からスキーマを自動で推論します。公式ガイドによると、コードインタープリターやWeb検索などのホスト型ツールも追加できます。既存のツール関数は、ラップ処理を外して@toolを付ける形へ書き換えるのが基本です。
TeamベースのオーケストレーションをWorkflowに置き換える
AutoGenのマルチエージェントは、イベント駆動コアと高レベルのTeamを組み合わせて制御していました。MAFは、入力がそろったらエッジに沿ってデータを流し、Executorを起動する型付きグラフのWorkflowが中心です。Teamで書いていた会話の回し方や引き継ぎは、Workflowのグラフとして組み直します。ここは単純な置換では終わらないため、まず処理の流れを図にしてから、ノードとエッジに落とすと迷いません。エージェントフレームワークの比較全体はMastra LangChain 違いでも整理しています。
06自社の自動化エージェントをMAFへ移す実践手順【実践】
ここからは、筆者が社内の自動化エージェント(記事の下調べや定型処理を回すもの)をMAFへ移すときに使っている進め方を、そのまま真似できる粒度で紹介します。いきなり全体を移さず、影響範囲を絞って段階的に切り替えるのが要点です。
①小さなエージェント1つで移行を試す
最初に移すのは、ツールを1〜2個しか使わない小さなエージェントです。別の仮想環境にagent_frameworkを入れ、AssistantAgentをAgentへ、引数名を対応表どおりに置き換えます。ツール関数はFunctionToolのラップを外して@toolを付けます。移行前後で同じ入力を与え、出力が実務で使える範囲で一致するかを見ます。ここで挙動の癖をつかんでから、規模の大きいエージェントに進みます。
②マルチターン化による副作用を検証する
小さなエージェントが動いたら、既定のマルチターン化が悪さをしないかを確認します。従来シングルターン前提だった処理をそのまま動かし、ツールの呼び出し回数や外部APIへのリクエスト数が想定内に収まるかを見ます。増えすぎる場合は、ツールの設計や終了条件を見直します。外部サービスに副作用のある操作(メール送信・データ更新など)を含むエージェントは、この検証を必ず本番前に通します。
そのまま使える移行チェックリスト
移行を漏れなく進めるために、この記事では次の順で確認しています。項目は自分のコードに合わせて足し引きしてください。
- 別環境に
agent_frameworkを入れ、AutoGen環境は残す AssistantAgent→Agent、model_client→client、system_message→instructionsを置換- ツールを
FunctionToolから@toolへ書き換える - 既定マルチターン化でツール呼び出し回数が増えないか計測する
Teamの制御をWorkflowのグラフへ組み直す- 副作用のある操作は本番前に必ず動作確認する
この順序なら、単一エージェント→挙動検証→マルチエージェントの順で影響範囲が広がるため、問題が起きても切り分けやすくなります。社内ツールにAIエージェントを組み込む考え方はMastra 使い方でも扱っています。
07移行でつまずきやすい注意点|drop-in replacementではない
MAFはAutoGenの後継ですが、そのまま差し替えれば動く「drop-in replacement」ではありません。公式ガイドも「後継は完全な置き換えを意味しない」と明言しています。似ているのはあくまで発想で、クラス名・引数名・既定動作・オーケストレーションの書き方は変わります。とくに既定のマルチターン化と、TeamからWorkflowへの組み直しは、単純な文字列置換では終わりません。移行は「翻訳」ではなく「設計の見直しを含む書き換え」だと捉えると、想定外のつまずきを避けられます。分散ランタイム前提で組んでいたコードも、MAFが現状シングルプロセス中心である点をふまえて設計を見直します。
よくある質問
AutoGenはもう使えなくなりますか?
すぐ使えなくなるわけではありません。ただしMicrosoftはMAFを今後の基盤と位置づけており、新機能はMAF側で進みます。既存のAutoGenコードは動かせても、長く保守するなら早めの移行が現実的です。
AutoGenからMAFへは自動で移行できますか?
クラス名や引数名の対応は機械的に置換できますが、TeamからWorkflowへの組み直しや既定動作の検証は手作業が必要です。公式は変わる点と変わらない点を並べた移行ガイドを提供しているため、まずはそれに沿って単一エージェントから移すのが確実です。
移行するとコストや速度は変わりますか?
仕様上、MAFの既定はマルチターンで最終回答までツールを呼び続けるため、同じ処理でも呼び出し回数が増える方向に振れる想定です。これは仕様差からの想定で、実測値ではありません。移行後に小さな範囲で計測し、想定内かを確認してください。
Pythonと.NETのどちらでも移行できますか?
MAFは多言語SDKで、Pythonと.NETに対応しています。本記事のコード例はPythonを前提にしていますが、考え方(クラス・引数・既定動作の置き換え)は共通です。使う言語のサンプルに合わせて読み替えてください。
Semantic Kernelからも同じように移行できますか?
MAFはAutoGenとSemantic Kernelの両方を統合した後継のため、Semantic Kernel向けの移行ガイドも別に用意されています。AutoGenとは対応関係が異なる部分があるので、Semantic Kernelから移す場合はそちら専用のガイドを参照してください。
08まとめ:AutoGenから移行するかの判断基準
AutoGenから移行するかは、「そのエージェントを今後も保守し続けるか」で決まります。使い捨ての検証コードなら急ぐ必要はありませんが、長く運用する本番エージェントほど、新機能が進むMAFへ早めに移す価値があります。進め方は、小さなエージェント1つを対応表どおりに置き換え、既定のマルチターン化を検証し、それからTeamをWorkflowへ組み直す順が安全です。MAFの全体像はMicrosoft Agent Framework とは?AutoGenとの違い、他フレームワークとの比較はMastra LangChain 違いでまとめています。
09出典
・Microsoft Learn「AutoGen から Microsoft Agent Framework への移行ガイド」(learn.microsoft.com/ja-jp/agent-framework/migration-guide/from-autogen/)
・Microsoft Agent Framework 公式リポジトリ(github.com/microsoft/agent-framework)
・Microsoft Agent Framework 公式サンプル(python/samples)