Microsoft Agent Framework 1.0完全ガイド|AutoGen統合の全貌と選定基準
「AutoGenとSemantic Kernel、結局どっちを使えばいいんだ?」
Microsoftのエージェント開発で、この問いに振り回された開発者は多い。片方で書いたコードがもう片方では動かない。APIの設計思想が違う。ドキュメントも別々。2つのフレームワークが微妙に重複しながら並走する状況が1年以上続いた。
2026年4月3日、その答えが出た。Microsoft Agent Framework 1.0のGA(正式リリース)だ(出典:Microsoft DevBlog「Microsoft Agent Framework Version 1.0」、2026年4月3日)。AutoGenの会話ベースのオーケストレーションと、Semantic Kernelのエンタープライズ機能を1つのフレームワークに統合した。.NETとPythonの両方で使える。
- AutoGenかSemantic Kernelか迷っていたエンジニア
- AIエージェント開発のフレームワーク選定を行うPM・テックリード
- MCP・A2Aの実装先を探しているフリーランスエンジニア
- LangChainやCrewAIとの違いを把握したい開発者
Microsoft Agent Framework 1.0は、AutoGenとSemantic Kernelを統合したオープンソース(MIT)のAIエージェントフレームワークだ。.NETとPythonで使え、MCP・A2A・OpenTelemetryが標準装備。5行のコードでエージェントが動く。C#/.NET環境やAzure連携が前提なら第一候補。Pythonのみなら、CrewAIやLangGraphも選択肢に入る。
なぜ統合されたのか:AutoGenとSemantic Kernelの問題
背景を整理する。
Microsoftには2つのAIエージェントフレームワークがあった。AutoGenはリサーチ寄りで、エージェント同士が会話を通じてタスクを進める「会話オーケストレーション」が特徴だった。Semantic Kernelはエンタープライズ寄りで、型安全性やミドルウェア、テレメトリなどの堅牢な機能を備えていた。
問題は、どちらを使えばいいか誰にもわからなかったことだ。
Medium記事でPedro Savelis氏が書いた一言が状況をよく表している。「Finally, Real AI Agents in Pure C#」(出典:Medium、2026年4月)。C#でAIエージェントを組もうとすると、AutoGenのPython寄りの設計と、Semantic Kernelのやや冗長なAPIの間で板挟みになっていた。
Agent Framework 1.0は、この統合に明確な答えを出した。AutoGenはメンテナンスモードに入り、バグ修正とセキュリティパッチのみが提供される(出典:Microsoft Learn「AutoGen Migration Guide」)。新規プロジェクトではAgent Frameworkが推奨されている。Semantic Kernelも同様にメンテナンスモードへ移行済みだ。
Agent Framework 1.0の主要機能
5行でエージェントが動く
公式ドキュメントが「zero to agent in 5 lines of code」と謳っている。実際のPythonコードはこうだ。
from agent_framework import Agent, OpenAIChatCompletion
agent = Agent(
name="assistant",
instructions="You are a helpful assistant.",
client=OpenAIChatCompletion(model="gpt-4o"),
)
response = await agent.invoke("東京の天気を教えて")
PMとしての率直な感想を言えば、この手の「N行で動く」は常にデモ用の最小構成だ。本番では認証、エラーハンドリング、ロギングが加わって膨らむ。とはいえ、開発者の初期体験(最初に触ってから動くまでの時間)が短いのは正しい設計判断だと思う。
MCP + A2A がデフォルト装備
Agent Framework 1.0の設計思想で注目すべきは、MCPとA2Aが組み込み済みである点だ。
MCP(Model Context Protocol) は、エージェントとツール・データソースを繋ぐプロトコルだ。Agent FrameworkではMCPサーバーを動的に検出・呼び出しできる。GA4やNotionのデータを引っ張ってくる、という操作がMCPサーバー経由で統一的に処理される。MCPの基本は「MCP実践入門|Claude Code × GA4 × Search Consoleで始めるAI連携」に詳しく書いた。
A2A(Agent-to-Agent Protocol) は、エージェント同士が協調するプロトコルだ。Agent FrameworkのA2A対応により、C#で書いたエージェントがPythonのLangChain製エージェントとプロトコルベースで通信できる。異なるフレームワーク間の壁が消える設計だ。MCPとA2Aの違いは「MCP vs A2A完全比較 2026」で整理した。
Microsoft DevBlogの表現を借りれば、「MCPはリソース層(エージェントとツールを繋ぐ)、A2Aはネットワーキング層(エージェント同士を繋ぐ)」だ。Agent Framework 1.0は両方のレイヤーを最初からサポートしている。
ワークフローエンジン
旧AutoGenのグループチャットパターン(RoundRobinGroupChat、SelectorGroupChat)は、Agent Framework 1.0でワークフローAPIに置き換わった。
対応するオーケストレーションパターンは4つだ。
| パターン | 概要 | 使いどころ |
|---|---|---|
| Sequential | エージェントが順番に処理 | パイプライン型の処理 |
| Concurrent | 複数エージェントが同時実行 | 独立した情報収集 |
| Handoff | エージェント間のタスク引き継ぎ | 専門分野ごとの分業 |
| Group Chat | エージェント同士が議論 | ブレインストーミング |
Scott Logic社のチームがユーザーオンボーディング用のエージェントをAgent Frameworkで構築した際、「決定論的なワークフローとエージェント間のハンドオフを、かなりモジュラーな形で素早く定義できた」と報告している(出典:Scott Logic Blog、2026年3月6日)。
DevUI:ブラウザベースのデバッガ
ローカルで使えるブラウザベースのデバッガが同梱されている。エージェントの実行フロー、メッセージのやり取り、ツール呼び出し、オーケストレーション判断をリアルタイムで可視化できる。
PMの立場から言えば、これは地味だが重要な機能だ。マルチエージェントシステムは「なぜその判断になったか」が外から見えにくい。DevUIがあることで、デモや社内説明の場で「ここでこのエージェントがこう判断して、こちらにハンドオフした」と説明できる。
対応モデルプロバイダー
Agent Framework 1.0はモデル非依存だ。対応プロバイダーは以下の通り。
- Azure OpenAI
- OpenAI
- Anthropic(Claude)
- Ollama(ローカルモデル)
- GitHub Copilot
- Microsoft Foundry / Foundry Local
Google GeminiやAmazon BedrockもIChatClient実装経由で利用可能だが、公式のファーストパーティコネクタとしては上記が提供されている(2026年4月時点)。
同じエージェントのコードで、プロバイダーだけ差し替えられる設計になっている。コスト最適化やレイテンシ要件に応じて、タスクごとにモデルを使い分けることも可能だ。
エンタープライズ向け機能
本番運用を意識した機能が複数ある。
OpenTelemetry統合: エージェントの実行ログ、トークン消費、レイテンシをOpenTelemetry経由で既存の監視基盤に流せる。Datadog、Grafana、Azure Monitorなどとの連携が容易だ。
Microsoft Entra統合: Azure ADによる認証・認可がフレームワークレベルで組み込まれている。
Responsible AI機能: タスク遵守モニタリング(エージェントが指示から逸脱していないか)とプロンプトインジェクション防御が内蔵されている。
Agent Governance Toolkit: 2026年4月にプレビュー公開された別プロジェクト。実行時のポリシー強制、安全な通信、コンプライアンス監視を提供する(出典:InfoWorld、2026年4月)。
光と影:正直な評価
強み
- 統合の決断: AutoGenとSemantic Kernelの並走をやめ、1つに絞った判断は正しい。開発者の迷いが消えた
- プロトコル先行設計: MCP・A2Aが最初から入っている。後付けではない
- .NET + Python両対応: C#開発者にとって有力な選択肢
- 無料・MIT: フレームワーク自体に課金がない
弱み
- Pythonエコシステムでは後発: LangChain(GitHub Stars 133,000以上)、CrewAI(48,000以上)と比べて、Pythonコミュニティでの存在感はまだ薄い(2026年4月時点)
- Azure寄りのドキュメント: Azure Foundry前提の解説が多く、AWS・GCP環境で使いたい場合は自力で補う必要がある
- 既存プロジェクトの移行コスト: AutoGenからの移行ガイドはあるが、ワークフローAPIへの書き換えはそれなりの工数が必要
- エコシステムの成熟度: 対照的に、LangChainのLangSmith(オブザーバビリティ)やLangServe(デプロイ)のような周辺ツール群はまだ追いついていない
Qiitaの記事でHosted Agents(Azure上でのマネージド実行)を試したレポートでは、「コンテナレジストリを含む複数のAzureサービスのセットアップが必要で、プレビュー段階では既存のFoundry環境への展開よりも新規構築が推奨」と指摘されている(出典:Qiita、2026年)。本番運用にはAzure周辺の知識が暗黙に求められる点は留意すべきだ。
フレームワーク選定の指針
PMとしての判断基準を整理する。
| 条件 | 推奨 |
|---|---|
| C#/.NETプロジェクト | Agent Frameworkが有力 |
| Azure・Microsoft 365連携が前提 | Agent Framework |
| Python + 素早いプロトタイプ | CrewAI |
| 細かいワークフロー制御が必要 | LangGraph |
| ローコード・ノーコード志向 | Dify |
重要なのは、これらのフレームワークがMCP・A2Aで相互接続できる時代に入っていることだ。「どれか1つを選んで永遠に使う」ではなく、「チームのスキルセットと既存インフラに合うものから始めて、プロトコルで繋ぐ」が正しいアプローチだ。
AIエージェントフレームワーク全体の動向は「AIコーディングエージェント比較 2026」でも整理している。
電脳狐影の判断
PMとして、自分ならどうするか。
正直に言えば、自分の日常業務ではClaude CodeとMCPの組み合わせで十分間に合っている。Claude Managed Agentsが出た今、Anthropicエコシステムの中で完結する選択肢もある。
ただ、Microsoft Agent Framework 1.0がMCP・A2Aを標準装備したことの意味は大きい。クライアントワークで「うちはAzure環境です」と言われたときに、Agent Frameworkで組んだエージェントがClaude CodeのMCPサーバーと同じツールにアクセスでき、A2A経由で他のフレームワークのエージェントと連携できる。エコシステムをまたいだ設計の選択肢が増えた。
フリーランスとして案件を受ける立場なら、Agent Framework 1.0は「知っておくべきもの」のリストに入れておくべきだ。特に.NET案件やAzure案件では、提案時の引き出しが1つ増える。
Microsoft Agent Framework 1.0はGitHubで公開されている(MIT License)。公式ドキュメントはMicrosoft Learnで読める。
関連記事:
- MCP実践入門|Claude Code × GA4 × Search Consoleで始めるAI連携
- MCP vs A2A完全比較 2026|AIエージェントの「手」と「チームワーク」はどう違うか
- Claude Managed Agents完全ガイド|インフラ不要でAIエージェントを本番運用
- AIコーディングエージェント徹底比較 2026
※ 本記事の情報は2026年4月10日時点のものだ。Agent Frameworkはオープンソースプロジェクトであり、機能・API・対応プロバイダーは変更される可能性がある。本番導入前に公式ドキュメントおよび最新のRelease Notesを必ず確認してほしい。