2026年に入って、エージェント構築用のフレームワークが急速に「統合（コンソリデーション）」へ向かっている。Microsoftは Semantic Kernel と AutoGen を一本化した Microsoft Agent Framework（2026年2月19日に .NET / Python の Release Candidate を公開）を「両者の直接の後継」と位置づけた。OpenAI も実験的な Swarm を Agents SDK に置き換え、Swarm リポジトリは教育用としてアーカイブ済みだ。
これは単なる新製品の話ではない。自分が今使っている SDK が「後継」に巻き取られ、新機能はそちらにしか来なくなるという、本番コードに直接効く移行イベントである。本稿では、確認できる一次情報だけを並べた上で、「で、どのクラスを何に書き換え、何を抽象化して次の統合に備えるか」を整理する。
結論
| 確認項目 | ニュースの含意 | 直すこと |
|---|---|---|
| Semantic Kernel / AutoGen | 公式が Agent Framework を「次世代」と明言。新機能は後継に集約される方針 | 新規は Agent Framework で書く。既存は移行コストを見積もる |
AutoGen AssistantAgent
|
Agent Framework の Agent は既定でマルチターン（ツールを呼び切る） |
max_tool_iterations 前提の制御ロジックを見直す |
AutoGen Team（イベント駆動） |
型付きグラフの Workflow（チェックポイント・HITL内蔵）へ |
オーケストレーションを明示的なエッジで書き直す |
| OpenAI Swarm | アーカイブ済み・本番非対応。後継は Agents SDK | ガードレール / トレーシング / セッションを持つ SDK へ移す |
| ベンダー横断の移植性 | MCP・A2A など標準対応が各社の共通言語に | モデルクライアントとツール定義を薄く抽象化しておく |
Microsoft Agent Framework：Semantic KernelとAutoGenの後継
確認できる事実
Microsoft は 2026年2月19日、Agent Framework の .NET / Python Release Candidate を公開した。公式ドキュメントはこのフレームワークを次のように位置づけている。
原文: "The Agent Framework is the direct successor, created by the same teams. ... In short, Agent Framework is the next generation of both Semantic Kernel and AutoGen."
日本語訳: 「Agent Framework は（Semantic Kernel と AutoGen の）直接の後継であり、同じチームが開発している。……要するに Agent Framework は両者の次世代版である」（Microsoft Learn / Agent Framework Overview）
構成は2系統だ。LLM が入力を処理しツールや MCP サーバーを呼ぶ Agents と、型安全なルーティング・チェックポイント・human-in-the-loop を持つグラフベースの Workflows。AutoGen の素朴なエージェント抽象に、Semantic Kernel 由来のセッション状態管理・型安全性・ミドルウェア・テレメトリを組み合わせた、というのが公式の説明である。標準対応として MCP（Model Context Protocol）・A2A（Agent-to-Agent）・AG-UI を挙げている。
導入は以下のとおり。Python は安定版パッケージ名で入るが、本稿執筆時点（2026年6月）で .NET 版は --prerelease 付きである点に注意。
# Python
pip install agent-framework
# .NET（執筆時点では prerelease）
dotnet add package Microsoft.Agents.AI.Foundry --prerelease
モデルプロバイダーは Microsoft Foundry / Azure OpenAI / OpenAI / Anthropic / Ollama などをサポートする（Python 版のモデルクライアントは一部 🚧 Planned のものがある。後述）。
実務解釈
移行で効くのは「既定の挙動が変わる」点だ。AutoGen の AssistantAgent は既定で単発（max_tool_iterations=1）で、ツールを複数回呼ばせたい場合に明示設定が要る。一方 Agent Framework の Agent は既定でマルチターン——最終回答を返せるまでツールを呼び続ける。max_tool_iterations を前提に「1回だけ呼ぶ」設計をしていたコードは、移行時に無限ループや想定外コストを生みやすい。
主要なクラスの対応関係を、AutoGen → Agent Framework（Python）で並べる。
| 役割 | AutoGen | Agent Framework |
|---|---|---|
| 単体エージェント |
AssistantAgent（既定で単発） |
Agent（既定でマルチターン） |
| マルチエージェント |
Team（イベント駆動） |
Workflow（型付きグラフ） |
| OpenAI クライアント | OpenAIChatCompletionClient |
OpenAIChatCompletionClient |
| OpenAI Responses | ❌ なし | OpenAIChatClient |
| Azure OpenAI | AzureOpenAIChatCompletionClient |
OpenAIChatCompletionClient |
| Azure AI | AzureAIChatCompletionClient |
FoundryChatClient / FoundryAgent
|
| Anthropic / Ollama | 各 *ChatCompletionClient
|
🚧 Planned |
もう一つの落とし穴が状態管理だ。AutoGen の AssistantAgent は会話履歴を自身の状態として保持するが、Agent Framework の Agent は既定でステートレスで、呼び出し間に履歴を持たない。マルチターン会話には agent.create_session() で得た AgentSession を明示的に渡す。
from agent_framework import Agent, tool
from agent_framework.openai import OpenAIChatClient
client = OpenAIChatClient(model="gpt-5")
agent = client.as_agent(
name="assistant",
instructions="You are a helpful assistant.",
tools=[get_weather], # 既定でマルチターン
)
# セッション無し：2回の呼び出しは独立（前の文脈を引き継がない）
r1 = await agent.run("What's 2+2?") # "4"
r2 = await agent.run("times 10?") # 文脈不明で曖昧
# セッション有り：文脈を共有
session = agent.create_session()
await agent.run("What's 2+2?", session=session) # "4"
await agent.run("times 10?", session=session) # "40"
「AutoGen ではエージェントが履歴を持っていた」前提でセッションを渡し忘れると、移行後に会話が突然“健忘症”になる。ここはテストで早めに気付ける部分なので、移行時の回帰テストに必ず入れる。
OpenAI：SwarmのアーカイブとAgents SDKへの一本化
確認できる事実
OpenAI が2024年10月に公開した Swarm は、軽量なマルチエージェント・オーケストレーションを探求する「教育用フレームワーク」だった。現在そのリポジトリはアーカイブされ、本番用途の後継として OpenAI Agents SDK（2025年3月に公開）が位置づけられている。Agents SDK は Swarm と同じ handoff（エージェント間の受け渡し）モデルを引き継ぎつつ、ガードレール・トレーシング・セッション・ホスト型ツール・Responses API 対応を加え、継続的にバージョンを重ねている。
Swarm 側のリポジトリ説明自体が「Educational framework exploring ergonomic, lightweight multi-agent orchestration」と明記しており、本番運用を意図したものではない。
実務解釈
Swarm で PoC を作っていたチームは、そのまま本番に乗せてはいけない。Swarm にはセッション管理・ガードレール・可観測性がなく、活発なメンテナンスもされていない。Agents SDK は handoff の概念がほぼそのまま移るため、移行の主作業は「足りていなかった本番要素（観測・ガードレール・状態）の追加」になる。逆に言えば、Swarm 時代に独自実装していたトレーシングやセッション層は、SDK 標準に寄せて捨てられる可能性が高い。
Microsoft と OpenAI で固有名は違うが、方向は同じだ——「実験用の薄いライブラリ」から「観測・ガードレール・状態・標準対応を内蔵した本番ランタイム」への一本化。2026年のエージェント開発は、この本番要素を自前で持つかフレームワークに預けるかの選択になっている。
実装チェックリスト
移行前の棚卸し:
- 自分の依存が Semantic Kernel / AutoGen / Swarm のどれか、バージョンと最終更新日を確認する
- そのフレームワークの新機能が後継側にしか来ていないか（changelog の更新が止まっていないか）を確認する
- エージェントの「ツール呼び出し回数」を制御しているコードを洗い出す（既定マルチターン化の影響範囲）
Agent Framework へ移す場合:
-
AssistantAgent→Agent、Team→Workflowの対応表を作り、1機能ずつ置換する -
マルチターン会話は
AgentSession（create_session()）を必ず渡す。渡し忘れの回帰テストを追加する -
モデルクライアントを
OpenAIChatClient（Responses 系）かOpenAIChatCompletionClient（chat 系）かで選ぶ - Anthropic / Ollama を使うなら、Python 版が 🚧 Planned のため対応状況を最新ドキュメントで再確認する
Agents SDK へ移す場合:
- Swarm の handoff 構成をそのまま写し、欠けていたガードレール・トレーシング・セッションを追加する
- 独自実装の観測・状態層を SDK 標準に置き換えられないか検討する
統合に強い設計（次の波に備える）:
- モデルクライアントとツール定義を薄いアダプタ層に隔離し、フレームワーク直結を避ける
- ツールは MCP サーバーとして切り出し、エージェント本体から疎結合にする（MCP / A2A はベンダー横断の共通語）
- オーケストレーションの「グラフ」をコードに直書きせず、設定/宣言で持てるようにする
失敗パターン
パターン1：PoC のフレームワークをそのまま本番化 → Swarm のような教育用ライブラリには観測・ガードレール・状態がない。本番要素を持つ後継（Agents SDK / Agent Framework）に移すか、自前で同等品を持つ前提で計画する。
パターン2：max_tool_iterations 前提のまま Agent に移行 → Agent Framework の Agent は既定でツールを呼び切る。回数制御を入れていたロジックが意図せず多重実行され、レイテンシとコストが膨らむ。移行時に挙動差を明示的にテストする。
パターン3：セッションの渡し忘れ → ステートレス既定の Agent にセッションを渡さず、マルチターン会話が成立しない。「前のターンの数字を参照する」系のテストを回帰に入れて検出する。
パターン4：フレームワークに密結合したまま → 次の統合（さらなる後継）でまた全面書き換えになる。モデルクライアント・ツール・オーケストレーションを薄い抽象で挟み、MCP のような標準にツールを逃がしておくと、移行コストが局所化できる。
参考リンク
- Microsoft Agent Framework Overview（Microsoft Learn）
- Migrate your Semantic Kernel and AutoGen projects to Microsoft Agent Framework Release Candidate（Microsoft DevBlogs）
- AutoGen to Microsoft Agent Framework Migration Guide（Microsoft Learn）
- microsoft/agent-framework（GitHub）
- openai/swarm（GitHub・アーカイブ済み）
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。