Microsoft Agent Framework入門｜AutoGenとSemantic Kernelの後継SDKを2026年最新版で徹底解説

Microsoft Agent Frameworkは、Microsoftが2026年4月にGAした、AIエージェントとマルチエージェントワークフローを構築するためのオープンソースSDKだ。これまで別々に提供されてきたAutoGenとSemantic Kernelを統合した「後継SDK」であり、.NETとPythonの両方で同じ設計のAPIを提供する。GitHubスター数は11.1k、ライセンスはMIT、開発は両プロダクトのコアチームが担う。

本記事では、公式リポジトリとMicrosoft Learnの移行ガイドを一次ソースに、Microsoft Agent Frameworkの位置づけ・移行手順・アーキテクチャ・実装コード・他フレームワーク比較までを2026年最新版でまとめる。

エージェントという概念そのものを整理したい場合は、まずAIエージェントとは？仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】を先に読むと、本記事の前提がつかみやすい。

30秒で理解する

時間がない読者向けに、要点を先に並べる。

旧来のAutoGenとSemantic Kernelは、いずれもメンテナンスモードへ移行した。バグ修正とセキュリティパッチは継続するが、新機能は本フレームワークにのみ追加される。混同しやすいので、まずこの関係を押さえておきたい。

Microsoft Agent Frameworkとは

Microsoft Agent Framework（以下MAF）は、本番投入を前提に設計された「production-grade」のエージェント構築SDKだ。公式は「.NETとPythonでプロダクション品質のAIエージェントとマルチエージェントワークフローを構築するための、オープンで多言語対応のフレームワーク」と説明している。

AutoGenとSemantic Kernelの統合

MAFが生まれた背景には、Microsoft社内に2つのエージェント系プロジェクトが並立していた事情がある。

MAFはこの両者の良いところを引き継ぐ。Semantic Kernel由来のクライアント・コネクタ層の上に、AutoGen由来のマルチエージェント・オーケストレーションをグラフベースのワークフローエンジンとして再構築した格好だ。開発はAutoGenとSemantic Kernelのコアチームが共同で担当している。

後継であることの意味

ここが最も誤解されやすい。AutoGenとSemantic Kernelは「廃止」されたわけではないが、新機能投資は止まった旧製品（メンテナンスモード）という位置づけになった。

つまり、いま動いているAutoGen/SKのコードがある日突然壊れることはない。ただし「最新機能を使い続けたい」のであれば、移行は時間の問題になる。新規プロジェクトでAutoGenやSemantic Kernelを選ぶ理由は、2026年時点ではほぼ無くなったと考えてよい。

Microsoft AIエコシステムでの位置づけ

MAFは単体のSDKにとどまらず、MicrosoftのAIスタック全体の中核に置かれている。Azure AI Foundryでのホスティング、Copilot Studioとの連携、そしてエンタープライズ向けのガバナンス基盤と接続する設計だ。

Microsoftのエージェント基盤の全体像はMicrosoft IQの4層を読み解く——Work/Web/Foundry/FabricとMCP・RAGの関係で4層構造として整理している。また、Microsoftが独自に開発するモデル群についてはMicrosoft MAI-Thinking-1とMAIファミリー7モデル——OpenAI依存を切る独自AI戦略が詳しい。MAFはこれらのモデル・サービスを束ねる「アプリケーション層のSDK」として位置づけられる。

AutoGen / Semantic Kernel からの移行

移行はMicrosoft Learnに専用ガイドが用意されている。ここでは要点となるマッピングと破壊的変更、段階的な手順を整理する。

移行マッピング（概要）

旧APIと新APIの対応は、次のように整理できる。

破壊的変更のポイント

完全な互換ではない点を、特につまずきやすい順に挙げる。

段階的移行の手順

一度に全部書き換える必要はない。互換レイヤーを活かしつつ段階的に進められる。

Semantic KernelのKernelFunctionはsemantic-kernel 1.38以降であればそのままMAFのツールに変換できる。VectorStore連携の検索関数もcreate_search_functionからツール化できるため、RAG基盤を作り直さずに移行できるのは実務上ありがたい。

アーキテクチャ

MAFのアーキテクチャは「チャットクライアント・ツール・MCP連携・コンテキストプロバイダー・ミドルウェア・マルチステップワークフロー」という層で構成される。下図に主要コンポーネントと.NET/Python両対応の関係を示す。

ポイントは2つある。第一に、すべてのモデルプロバイダーが共通のIChatClient（.NET）／ChatClient（Python）インターフェースに揃えられていること。第二に、Workflowがデータフロー型である点だ。

AutoGenの実験的なGraphFlowは、エッジが「遷移」を表しメッセージを全エージェントへブロードキャストする制御フロー型だった。対してMAFのWorkflowは、型付きエッジに沿ってメッセージをルーティングし、入力が揃ったexecutorが起動するデータフロー型で、並列実行・リクエスト/レスポンスの一時停止・checkpointingに対応する。

エージェント作成の基本（.NET）

.NETではMicrosoft.Agents.AI名前空間を使う。まずパッケージを追加する。

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Foundry
dotnet add package Azure.AI.Projects
dotnet add package Azure.Identity

最小のエージェント生成は、ChatClientの拡張メソッドAsAIAgentで完結する。Semantic KernelのようにKernelを構築する必要はない。

using Microsoft.Extensions.AI;
using Microsoft.Agents.AI;

AIAgent agent = new AIProjectClient(
        new Uri(endpoint),
        new DefaultAzureCredential())
    .AsAIAgent(
        model: deploymentName,
        instructions: "You are an upbeat assistant that writes beautifully.",
        name: "HaikuAgent");

Console.WriteLine(
    await agent.RunAsync("Write a haiku about Microsoft Agent Framework."));

ツールを持たせる場合も、エージェント生成時に一括で渡せる。SKのように属性付与・Plugin化・Kernelへの登録という4ステップは不要だ。

AIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a helpful assistant.",
    tools: [AIFunctionFactory.Create(GetWeather)]);

ストリーミングはRunStreamingAsyncを使い、AgentResponseUpdateを逐次受け取る。非ストリーミングのRunAsyncが単一のAgentResponseを返すのと対になっている。

await foreach (AgentResponseUpdate update
    in agent.RunStreamingAsync(userInput, session))
{
    Console.Write(update); // update は ToString() フレンドリー
}

なおDefaultAzureCredentialは開発には便利だが、本番ではManagedIdentityCredentialなど明示的な資格情報を使うほうが、レイテンシと意図しない資格情報探索のリスクを避けられる。

エージェント作成の基本（Python）

Pythonはagent-frameworkパッケージを使う。メタパッケージを入れるとコアとよく使うプロバイダーが揃う。

pip install agent-framework

最小のエージェントは、Agentを直接生成するか、ChatClientのas_agent()で作る。どちらも内部的には同じ経路を通る。

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

agent = Agent(
    client=FoundryChatClient(credential=AzureCliCredential()),
    name="HaikuAgent",
    instructions="You are an upbeat assistant that writes beautifully.",
)
print(await agent.run("Write a haiku about Microsoft Agent Framework."))

ツールは関数に@toolを付けるだけでよい。スキーマは型ヒントとdocstringから自動推論される。AutoGenのFunctionToolラップは不要になった。

from typing import Annotated
from agent_framework import tool
from pydantic import Field

@tool
def get_weather(
    location: Annotated[str, Field(description="天気を取得する地名")]
) -> str:
    """指定した地名の天気を返す。"""
    return f"{location}は晴れです"

agent = client.as_agent(name="assistant", tools=[get_weather])

会話状態はAgentSession（またはget_new_thread()）で管理する。MAFのAgentは既定でステートレスなので、文脈を継続したいときはセッションを明示的に渡す。

session = agent.create_session()
r1 = await agent.run("2+2は？", session=session)
print(r1.text)  # "4"
r2 = await agent.run("その数を10倍すると？", session=session)
print(r2.text)  # "40"（"その数"が4を指すと理解できる）

グラフベースワークフロー

単一エージェントを超えて、複数のexecutorを型付きエッジで接続するのがWorkflowだ。WorkflowBuilderに開始executorとエッジを宣言し、build()する。state machine的なオーケストレーションをコードで明示できる。

from agent_framework import WorkflowBuilder, executor, WorkflowContext
from typing_extensions import Never

@executor(id="writer")
async def writer_exec(task: str, ctx: WorkflowContext[str]) -> None:
    await ctx.send_message(f"Draft: {task}")

@executor(id="reviewer")
async def reviewer_exec(draft: str, ctx: WorkflowContext[str]) -> None:
    decision = "approve" if "solar" in draft.lower() else "revise"
    await ctx.send_message(f"{decision}:{draft}")

@executor(id="editor")
async def editor_exec(msg: str, ctx: WorkflowContext[Never, str]) -> None:
    if msg.startswith("approve:"):
        await ctx.yield_output(msg.split(":", 1)[1])  # 最終出力
    else:
        await ctx.yield_output("Needs revision")

workflow = (
    WorkflowBuilder(start_executor=writer_exec)
    .add_edge(writer_exec, reviewer_exec)
    .add_edge(reviewer_exec, editor_exec)
    .build()
)
# result = await workflow.run("Draft a paragraph about solar power")

executorはエージェントだけでなく、純粋な関数やサブワークフローも置ける。逐次・条件分岐に加え、A→(B, C)→集約という分岐合流（ALL/ANY結合）もactivation_groupとactivation_conditionで表現できる。

逐次・並列・ハンドオフ・グループ協調という代表的なオーケストレーションパターンは、このWorkflowの上に統一的に乗る。AutoGenのRoundRobinGroupChatやMagenticOneGroupChatに相当するパターンも順次サポートされている。

MCP/A2A/AG-UI 連携

MAFは、エージェント相互運用の最新標準に正式対応している。これがエコシステムとして強い理由だ。

特にMCPは、CrewAI・Vercel AI SDK・Mastra・Microsoft Agent Frameworkがこの半年で相次いでネイティブ対応しており、2026年のデファクトになりつつある。MCPサーバー自体の仕組みと自作手順はMCPサーバーとは｜仕組み・代表的なサーバー一覧・自作手順を2026年最新で解説で詳述しているので、MAFと組み合わせる前提知識として参照してほしい。

Vercel AI SDK 6 / LangGraph / CrewAI / OpenAI Agents SDK との比較表

主要なエージェントフレームワークと並べると、MAFの立ち位置がわかりやすい。各フレームワークは「不正解」ではなく、得意領域が異なる。

TypeScript中心でストリーミングUIが主目的ならVercel AI SDKやMastra、Pythonで長時間ステートフルならLangGraph、そして.NET資産・Azure統合・エンタープライズ運用が要件ならMAF、という棲み分けになる。9種の比較はAIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証も合わせて参照したい。

本番デプロイ

MAFは「プロトタイプから本番へ」を明確に意識している。Azure AI Foundryとの連携が、その中心だ。

可観測性は実務で効く。LLMエージェントは挙動がブラックボックス化しやすいが、OpenTelemetryで「どのツールを何回呼び、どこで時間を使ったか」をトレースできれば、デバッグとコスト最適化の両方に直結する。

エンタープライズ用途

MAFがAutoGenやSKの単純な後継以上である理由が、ガバナンス機能だ。VentureBeatは本フレームワークを「エンタープライズAIエージェントを統合し統治する」ものと位置づけている。

SSOやRBAC、データガバナンスといった要件は、個人開発では見えにくいが、企業導入では最初に問われる項目だ。MAFはこれらをフレームワーク標準とAzure連携でカバーしようとしている点が、OSS単体のエージェントフレームワークとの大きな差になる。

よくある落とし穴

移行・導入の現場で繰り返し起きるつまずきを挙げておく。

いずれも「旧フレームワークの常識をそのまま持ち込む」ことが原因になりやすい。MAFは設計思想からして別物だと割り切り、移行ガイドのマッピング表を都度参照するのが安全だ。

FAQ

Q. AutoGenユーザーは今すぐ移行すべき？ 緊急ではない。AutoGen 1.xはメンテモードでパッチは継続し、破壊的変更も予定されていない。ただし新機能はMAFのみ。新規はMAF、既存は計画的移行が現実的だ。

Q. Semantic Kernelとの違いは？ SKはKernel・プラグイン中心。MAFはKernel不要でChatClientから直接エージェントを生成し、名前空間もMicrosoft.Agents.AIに統合された。SKもメンテモードだ。

Q. .NETとPythonどっちで始めるべき？ 既存資産で選ぶ。Azure統合・既存.NET基盤なら.NET、データ処理・ML連携中心ならPython。両者はAPI設計が揃い、概念を相互移植しやすい。

Q. 既存LangChain.NETから移行できる？ 自動移行ツールはないが、IChatClient基盤を活かしてクライアント層を差し替え、ツールを再登録すれば段階的に置換できる。オーケストレーションはWorkflowへ書き換えが必要だ。

Q. Vercel AI SDK 6とどう違う？ VercelはTypeScript中心でストリーミングUIに強い。MAFは.NET/Pythonでエンタープライズ運用・ガバナンス・Azure統合に強い。長時間ワークフローとcheckpointingはMAFが手厚い。

Q. Azure必須？ 必須ではない。OpenAI単体でも動く。ただしFoundry Hosted Agentsやガバナンス、可観測性の一部はAzure AI Foundryと組むと最大限活きる。

Q. ローカル開発は？ できる。pip install agent-frameworkまたはdotnet add packageで導入し、APIキーを環境変数に置けばよい。DevUIで対話検証、OpenTelemetryでトレース取得も可能だ。

まとめ

Microsoft Agent Frameworkは、AutoGenとSemantic Kernelという2つの資産を統合した、Microsoftのエージェント開発の本命SDKだ。.NETとPythonの両対応、グラフベースのWorkflow、MCP/A2A/AG-UI連携、そしてAzure AI Foundryによる本番運用とガバナンス——これらを1つのフレームワークに束ねた点が最大の価値になる。

旧フレームワークがメンテモードに入った以上、新規開発はMAFを起点に考えるのが妥当だ。既存資産は破壊的変更の心配なくパッチ追従しつつ、移行ガイドのマッピングに沿って段階的に移していけばよい。

参照ソース

・microsoft/agent-framework（GitHub公式リポジトリ）
・Microsoft Agent Framework Blog（公式devblogs）
・AutoGen to Microsoft Agent Framework Migration Guide（Microsoft Learn）
・Semantic Kernel to Microsoft Agent Framework Migration Guide（Microsoft Learn）
・Migrate your Semantic Kernel and AutoGen projects to Microsoft Agent Framework（公式blog）