※本記事は、Microsoft Agent Framework 1.0のGA、AutoGen / Semantic Kernelからの移行方針、Microsoft公式ドキュメントを踏まえて作成しています。
Microsoft Agent Framework（MAF）は、AutoGenのマルチエージェント協調力と、Semantic Kernelのエンタープライズ基盤を統合した、Microsoftの次世代AIエージェント開発フレームワークです。
2026年4月3日、MicrosoftはMicrosoft Agent Framework 1.0を正式リリースしました。これは単なる新しいOSSフレームワークではありません。AIエージェントを実験室のPoCから、本番運用・ガバナンス・Microsoft 365 / Azure AI Foundry連携へ進めるための統一基盤です。
AutoGenでPoCまでは作れたものの、「どこで止めるか」「どこに人間承認を挟むか」「障害時にどこから再開するか」で悩むチームは少なくありません。これまでMicrosoftのエージェント開発には、研究色の強いAutoGenと、エンタープライズ統合に強いSemantic Kernelという2つの流れがありました。Microsoft Agent Framework（MAF）は、この2つを一本化し、AIエージェントを本番運用へ進めるための統一基盤として登場しました。
本記事では、Microsoft Agent Frameworkとは何か、AutoGenとSemantic Kernelから何が引き継がれ、何が変わったのか、企業が導入時に何を見るべきかを実務目線で整理します。
Microsoft Agent Frameworkは、AutoGenとSemantic Kernelを統合し、Microsoftエコシステム上でAIエージェントを本番運用するための次世代基盤です。
- 要点1：MAFは、AutoGenのマルチエージェント協調力と、Semantic Kernelの状態管理・型安全性・テレメトリなどを統合したフレームワークです。
- 要点2：AutoGenはメンテナンスモードへ移行しており、新規長期プロジェクトではMAFを優先して検討すべき段階です。
- 要点3：企業導入では、状態耐久性、Human-in-the-loop、OpenTelemetryを中心とした観測性、Azure AI Foundry / Microsoft 365との統合が評価軸になります。
この記事の著者・監修者 ケニー狩野（Kenny Kano）
AIエージェントフレームワークシリーズにおける本記事の位置づけ
AIエージェント開発を体系的に理解するには、各フレームワークを「何に向いているか」で整理する必要があります。本記事は、Microsoftエコシステム上でAIエージェントを本番運用する統一基盤としてのMicrosoft Agent Frameworkを扱います。
役割ベースの業務PoCを素早く組むならCrewAI、状態管理と分岐を細かく制御するならLangGraph、ソフトウェア開発工程をAIチーム化するならMetaGPTが候補になります。一方、Azure AI Foundry、Microsoft 365、GitHub Copilot SDK、Agent 365などと接続し、企業全体でエージェントを統制・運用するなら、Microsoft Agent Frameworkが有力な選択肢になります。
- AIマルチエージェント開発フレームワーク選定ガイド ＝ フレームワーク選定の全体地図
- LangGraph完全ガイド ＝ 状態管理・分岐・再実行に強い本番運用基盤
- CrewAI実践ガイド ＝ 役割ベースで業務PoCを高速化するAIチーム基盤
- MetaGPT完全ガイド ＝ ソフトウェア開発工程をAIチーム化するフレームワーク
- Microsoft Agent Framework ＝ AutoGenとSemantic Kernelを統合するMicrosoft系エージェント開発基盤（本記事）
Microsoft Agent Frameworkとは何か
要約：Microsoft Agent Frameworkは、.NET / PythonでAIエージェントとマルチエージェントワークフローを構築するためのMicrosoft公式の統合フレームワークです。
Microsoft Agent Framework、略してMAFは、Microsoftが提供するAIエージェント開発の統一基盤です。単一のAIチャットボットだけでなく、複数のAIエージェント、外部ツール、業務ワークフロー、人間承認、監視、Azure / Microsoft 365連携までを扱うことを目的としています。
MAFの重要な特徴は、AgentとWorkflowを分けて設計する点です。AgentはLLMを使って状況を解釈し、必要なツールを呼び出す自律的な実行単位です。一方、Workflowは複数のAgent、関数、人間承認、外部システムを接続し、業務プロセス全体の流れを制御する仕組みです。
| 構成要素 | 役割 | 実務での意味 |
|---|---|---|
| Agent | LLMを使って入力を解釈し、ツールを呼び出してタスクを進める実行単位 | 調査担当、サポート担当、コード生成担当、承認前チェック担当など |
| Workflow | 複数のAgentや関数を接続し、実行順序・分岐・停止・再開を制御する仕組み | 承認フロー、長期実行プロセス、複数部署をまたぐ業務自動化 |
| Tool / MCP | Agentが外部システムやデータソースにアクセスするための接続口 | 社内DB、GitHub、CRM、Microsoft 365、業務APIなどとの連携 |
| A2A（Agent-to-Agent） | 異なるランタイムやフレームワーク上のAgent同士が通信するためのプロトコル | 他フレームワークや別環境で動くエージェントとの相互運用、マルチクラウド・異種システム横断のエージェント協調 |
| Observability | AgentやWorkflowの実行ログ、ツール呼び出し、失敗箇所を追跡する仕組み | 監査、改善、障害調査、コスト管理、セキュリティレビュー |
つまりMAFは、「AIに何かを答えさせる」ためだけのSDKではありません。AIエージェントを企業システムの一部として運用するために、推論、ツール実行、状態管理、人間承認、監視、デプロイ、外部エージェント連携を統合する基盤です。
なぜAutoGenとSemantic Kernelは統合されたのか
要約：AutoGenは革新的なマルチエージェント協調に強く、Semantic Kernelは安定した企業連携に強い。一方で、それぞれに限界があり、両者を統合する必然性が高まっていました。
Microsoft Agent Frameworkを理解するには、AutoGenとSemantic Kernelがそれぞれ何を担ってきたのかを押さえる必要があります。両者は似たAIエージェント関連技術に見えますが、出発点も、得意領域も、抱えていた課題も異なっていました。
研究向けのAutoGenに求められていたこと
AutoGenは、Microsoft Researchから派生した実験的なマルチエージェント・フレームワークです。複数のAIエージェントが自律的に話し合い、役割を分担し、柔軟に協調しながら問題を解く「会話型」のアプローチを探求することが主な役割でした。
特に、GroupChat、UserProxy、人間承認、エージェント同士の議論といった設計は、AIエージェントが単体のチャットボットを超えて、チームとして問題を解く可能性を示しました。一方で、AutoGenは研究・PoC色が強く、本番環境での運用機能には課題がありました。状態の永続化、エンタープライズ級のガバナンス、デバッグ、観測性、長時間実行時の停止条件などは、企業システムとして使うには追加設計が必要でした。
企業向けのSemantic Kernelに求められていたこと
Semantic Kernelは、エンタープライズアプリケーションへAI機能を安全に組み込むためのSDKとして発展してきました。既存のソフトウェアロジックにAIを組み込むプラグイン型のアプローチを採用し、セッション管理、型安全性、テレメトリ、フィルター、モデル接続など、企業システムに必要な堅牢な実行基盤を提供してきました。
一方で、Semantic Kernelは基本的にエンタープライズアプリケーションへAIを組み込む基盤として設計されており、AutoGenが得意としたような、複数エージェント間の柔軟な会話協調を直感的に扱う点では限界がありました。
統合の狙い：協調力と運用基盤を一本化する
つまり、AutoGenは「革新的なエージェント協調機能」を持つ一方で、運用基盤が薄い。Semantic Kernelは「安定した企業連携機能」を持つ一方で、マルチエージェント協調が限定的。この相互補完関係こそ、Microsoft Agent Frameworkが生まれた最大の理由です。
MAFは、AutoGenのマルチエージェント協調力と、Semantic Kernelのエンタープライズ基盤を統合し、実験的なPoCから本番運用へ進むための共通基盤として設計されています。AIエージェントを「試す」段階から、「止められる・承認できる・再開できる・観測できる」段階へ進めるための統合SDK。それがMicrosoft Agent Frameworkの本質です。
| 観点 | AutoGen | Semantic Kernel | MAFでの統合意味 |
|---|---|---|---|
| 主な役割 | 研究・PoC・マルチエージェント協調パターンの探求 | エンタープライズアプリケーションへのAI統合 | 実験から本番運用までをつなぐ |
| 強み | GroupChat、会話型協調、柔軟なオーケストレーション | 状態管理、型安全性、テレメトリ、フィルター、モデル接続 | 協調力と堅牢性を両立する |
| 課題 | 耐久性、ガバナンス、観測性、停止条件、コスト制御 | 高度なマルチエージェント協調を直感的に扱いにくい | Agent + Workflowとして統合する |
AutoGenとSemantic Kernelはどうなったのか：MAFへの移行と何が変わったか
要約：AutoGenはメンテナンスモードへ移行し、新機能の中心はMAFへ移りました。Semantic Kernelの主要な設計資産もMAFへ継承され、会話駆動型の設計はWorkflow中心の本番向け設計へ再構成されています。
AutoGenは現在、バグ修正・セキュリティパッチ・ドキュメント改善が中心のメンテナンスフェーズにあり、新機能への投資はMAFへシフトしています。Semantic Kernelについても、状態管理・型安全性・テレメトリといった主要な設計資産はMAFへ引き継がれ、新規エージェント開発ではMAFを優先的に検討する流れが強まっています。
ただし、AutoGenが示した会話設計、GroupChat、人間承認、観測性の考え方は、MAFへの移行時にも重要な設計知として残ります。旧APIを覚え直すのではなく、それらの設計パターンをMAFのAgent + Workflow設計にどう読み替えるかが移行の本質です。
最も大きい変化は、GroupChatやManagerによる会話中心の制御から、AgentとWorkflowを組み合わせた明示的な本番向け設計へ移行した点です。業務システムとして必要な「どこで止めるか」「どこで人間が承認するか」「どこから再開するか」をWorkflowの中へ組み込めるようになりました。
| 観点 | AutoGen | Microsoft Agent Framework | 改善・変更点 |
|---|---|---|---|
| 位置づけ | 研究・PoC色の強いマルチエージェント基盤 | 本番向けAIエージェント統一基盤 | PoCからproduction-grade agent systemsへ重点が移った |
| 設計思想 | 会話駆動・GroupChat中心 | Agent + Workflow中心 | 自然な会話協調に加え、実行経路を明示的に制御しやすくなった |
| 実行制御 | Manager、max_round、会話フローで制御 | Workflow、条件分岐、checkpointing、resumingで制御 | 長時間処理、再開、人間承認を業務フローに組み込みやすくなった |
| 状態管理 | 会話履歴や外部ログで補う場面が多い | Semantic Kernel由来の状態管理・型安全性・テレメトリを統合 | エンタープライズ運用に必要な堅牢性が増した |
| 人間承認 | UserProxyやhuman_input_modeで介在 | Human-in-the-loopをWorkflowの一部として設計 | 承認、保留、再開、却下を業務プロセスに組み込みやすくなった |
| 観測性 | ログやOpenTelemetry連携で補強 | OpenTelemetryを前提に、Foundryや監視基盤と接続 | トレース、障害調査、監査、コスト管理を行いやすくなった |
| 外部連携 | ツール連携は実装ごとに設計 | MCP、A2A、OpenAPI、各種業務APIとの接続を重視 | ツール接続とエージェント間通信を標準化しやすくなった |
AgentとWorkflowの違い
要約：MAFでは、Agentが推論し、Workflowが実行経路を制御します。この分離により、AIの柔軟性と業務システムの信頼性を両立しやすくなります。
MAFでは、Agentが推論し、Workflowが実行経路を制御します。Agentは曖昧な入力の解釈やツール選択に向き、Workflowは承認、分岐、再開、監査が必要な業務プロセスを制御します。
| 比較軸 | Agent | Workflow |
|---|---|---|
| 主な役割 | 入力の解釈、推論、ツール選択、回答生成 | 実行順序、分岐、承認、再開、例外処理の制御 |
| 向いている場面 | 曖昧な問い合わせ、調査、コード生成、対話型支援 | 承認フロー、長期処理、業務プロセス、監査が必要なタスク |
| 人間介入・状態管理 | 対話やセッション履歴を中心に管理 | チェックポイント、再開条件、RequestPortなどで管理 |
実務では、すべてをAgentに任せるのではなく、決定論的に処理できる部分はWorkflowや関数で制御し、曖昧な判断や非構造化情報の解釈だけをAgentに任せる設計が重要です。
Microsoftエコシステムとの統合：Foundry / Azure / Copilot SDK / Microsoft 365
要約：MAFの最大の差別化要因は、Azure AI Foundry、Microsoft 365、Copilot SDK、Agent 365など、Microsoftのエージェント開発スタック全体と接続する点です。
MAFは、単独のOSSフレームワークとして見るより、MicrosoftのAIエージェント開発スタック全体の入口として見るべきです。開発者はローカル環境でAgentやWorkflowを作り、Azure AI Foundryや関連サービスへ展開し、Microsoft 365やTeamsなどユーザーが日常的に使う環境へ接続することができます。
さらに、企業全体でエージェントを管理・運用するフェーズでは、組織内のエージェントを登録し、活動を可視化し、ポリシーで制御し、セキュリティを適用する「Observe / Govern / Secure」型のコントロールプレーンであるMicrosoft Agent 365との連携が鍵になります。これにより、シャドーAI化を防ぎつつ、エンタープライズ品質でエージェントを展開しやすくなります。
Agent 365は2026年5月1日に一般提供が開始され、Microsoft 365テナント向けの単体ライセンスとして提供されています。Microsoft公式ブログでは、Agent 365単体は月額15ドル/ユーザーとして案内されています。また、Microsoft 365 E7については、Microsoftのパートナー向け情報などで月額99ドル/ユーザーと整理されています。実際の契約条件や価格は、地域・契約形態・ボリュームライセンス条件によって変わる可能性があるため、導入時には最新のProduct Termsと販売パートナーへの確認が必要です。
| 領域 | 関連サービス | MAFとの関係 |
|---|---|---|
| 開発 | .NET / Python、GitHub、GitHub Copilot SDK | ローカル開発やコーディングエージェントとの連携 |
| モデル・実行基盤 | Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic Claude、Amazon Bedrock、Google Gemini、Ollama | Agent Frameworkのprovider（チャットクライアント）として案内されている複数の推論サービスやモデルプロバイダーへの接続、エージェント実行、評価、監視 |
| 業務アプリ | Microsoft 365、Teams、Outlook | エージェントを業務ユーザーの作業画面へ届ける |
| 統制・管理 | Microsoft Agent 365、Microsoft Entra、監視基盤 | エージェントの登録、権限、監視、ガバナンス |
| 外部連携 | MCP（ツール接続）、A2A（エージェント間通信）、OpenAPI、各種業務API | 外部ツール、他フレームワークのエージェント、クラウド横断のエージェント協調 |
MCPは、AIエージェントが外部ツールやデータソースへアクセスするための接続プロトコルです。一方、A2Aは、異なるランタイムやフレームワーク上のエージェント同士を接続するためのプロトコルです。MAFがこれらを重視していることは、AIエージェントを単一アプリの中だけで完結させず、組織やクラウドをまたいで協調させる方向を示しています。
LangGraph・CrewAI・MetaGPTとの違い
要約：MAFは、Microsoftエコシステム上でエージェントを本番運用する基盤です。LangGraph、CrewAI、MetaGPTとは得意領域が異なります。
| フレームワーク | 得意なこと | 向いている場面 | 注意点 |
|---|---|---|---|
| Microsoft Agent Framework | Microsoftエコシステム上のAgent + Workflow統合 | Azure / Microsoft 365 / Foundry前提の本番エージェント基盤 | Microsoft環境との親和性が強い。非Microsoft環境では要件比較が必要 |
| LangGraph | 状態管理、分岐、再実行、承認フロー | 複雑な状態遷移や例外処理が多いカスタムワークフロー | 設計難度は高め。LangSmithとの組み合わせで価値が出る |
| CrewAI | 役割ベースのAIチーム構築 | 調査、分析、レポート作成、営業支援、業務PoC | 本番運用ではFlows、Guardrails、監視設計が必要 |
| MetaGPT | ソフトウェア開発工程のAIチーム化 | 要件定義、設計、実装、テストを工程化したい場合 | 汎用業務PoCより、開発工程特化として扱う方が自然 |
ひとことで言えば、MAFは「Microsoftエコシステム上の本番向けエージェント統一基盤」、LangGraphは「状態管理エンジン」、CrewAIは「AIチーム編成ツール」、MetaGPTは「ソフトウェア開発工程のAIチーム化」です。
選定の判断軸を一言で言えば、Azure・Microsoft 365・Entra IDを業務基盤として使い、PoCを本番運用へ進めたい組織ではMAFが有力です。AutoGenやSemantic Kernelの既存資産がある場合も、公式移行ガイドをもとに設計を引き継げます。一方、クラウド非依存の軽量PythonワークフローならLangGraph、素早い業務PoCならCrewAIが適する場面もあります。重要なのは、MAFを流行として選ぶのではなく、自社のIT基盤と運用要件に合わせて選ぶことです。
企業導入で見るべき3つの評価軸
要約：MAFを企業で評価するなら、状態耐久性、Human-in-the-loop、Observabilityの3点を見るべきです。これはPoCと本番運用を分ける重要な境界です。
AIエージェントは、デモでは簡単に動きます。しかし企業の本番業務では、途中で止まる、再開する、人間が承認する、ログを追跡する、責任範囲を確認する、といった仕組みが必要になります。
| 評価軸 | 見るべきポイント | なぜ重要か |
|---|---|---|
| 状態耐久性 | チェックポイント、一時停止、再開、長時間実行への対応 | 業務プロセスは数分で終わらず、障害時の再開が必要になるため |
| Human-in-the-loop | RequestPort、人間承認、保留、差し戻し、再開条件 | 重要判断や外部送信をAI任せにしないため |
| Observability | OpenTelemetry、実行ログ、ツール呼び出し、失敗箇所、コスト | 監査、障害調査、改善、セキュリティレビューに必要なため |
この3点が弱いままAIエージェントを本番に入れると、便利な自動化ではなく、見えないブラックボックスが増えるだけになります。
経営会議やアーキテクチャレビューの場では、「このユースケースはどこでチェックポイントを切るか」「どこで誰が承認するか」「どのログを誰が追えるようにするか」の3問を、MAF設計レビューのチェックリストとして必ず問いかけることを勧めます。
ただし、MAFは万能ではありません。Agent、Workflow、HITL、Observability、Foundry連携を理解する学習コストがあり、Azure / Microsoft 365との統合が強みである一方、非Microsoft環境ではLangGraphやCrewAIとの比較も必要です。導入時には、承認ルール、ログ保存、責任分界、コスト管理をあらかじめ決めておくべきです。
既存AutoGenユーザーはどう移行を考えるべきか
要約：既存AutoGen資産は、コード単位ではなく、役割設計・会話設計・停止条件・承認ポイント・観測ログの単位で棚卸しすることが重要です。
AutoGenをすでに使っている組織は、いきなりすべてをMAFへ書き換える必要はありません。まずやるべきことは、既存AutoGen資産の棚卸しです。
棚卸しでは、コードの行数やクラス名だけを見るのではなく、どのエージェントが何を担当しているのか、誰が会話を進行しているのか、どこで人間承認を挟んでいるのか、何をログとして残しているのかを確認します。
| 確認項目 | AutoGenで見るもの | MAFでの読み替え |
|---|---|---|
| 役割設計 | AssistantAgent、UserProxyAgent、各Agentのsystem message | Agentの責任範囲、入力、出力、権限として整理 |
| 会話制御 | GroupChat、GroupChatManager、max_round | Workflow、条件分岐、終了条件、再試行条件へ読み替え |
| 人間承認 | human_input_mode、UserProxy、人間レビュー | RequestPortやHITLステップとして設計 |
| 状態管理 | 会話履歴、外部ログ、セッション管理 | checkpointing、resuming、長期状態管理として整理 |
| 観測性 | ログ、OpenTelemetry、エラー記録 | MAFのObservability、Foundry、監視基盤へ接続 |
移行は、単なるAPI名の置換ではありません。AutoGenの会話中心の設計を、MAFのAgent + Workflow中心の設計へ再構成する作業です。そのため、最初に設計単位で棚卸しし、小さなワークフローから段階的に移行するのが安全です。
まとめ：MAFはMicrosoftエージェント開発スタックの統一基盤へ
要約：Microsoft Agent Frameworkは、AutoGenとSemantic Kernelの成果を統合し、AIエージェントを本番運用へ進めるためのMicrosoft系統一基盤です。
Microsoft Agent Frameworkは、単なる新しいAIエージェントフレームワークではありません。AutoGenが切り拓いたマルチエージェント協調と、Semantic Kernelが育てたエンタープライズ基盤を統合し、企業がAIエージェントを本番環境で運用するための共通基盤として登場しました。
AutoGenは、会話駆動のマルチエージェント設計を広めました。しかし、今後の新規長期プロジェクトでは、MAFを中心に考えるべき段階です。AutoGenの価値は、旧APIの使い方ではなく、GroupChat、終了条件、人間承認、観測性といった設計知としてMAFへ受け継がれています。
Microsoft Agent Frameworkは、AIエージェントを「試す」段階から、「統制しながら業務に組み込む」段階へ進めるための基盤です。 Azure、Microsoft 365、Foundry、GitHub、Entra IDを中心に企業ITを構成している組織にとって、MAFは2026年以降のAIエージェント戦略で重要な選択肢になるでしょう。
よくある質問（FAQ）
Q1. Microsoft Agent FrameworkはAutoGenの後継ですか？
A1. はい。Microsoft公式では、Microsoft Agent FrameworkはSemantic KernelとAutoGenの両方の「直接の後継（direct successor）」であり、「次世代（next generation）」と説明されています。AutoGenのシンプルなエージェント抽象化と、Semantic Kernelの状態管理・型安全性・テレメトリなどのエンタープライズ機能を統合し、さらにグラフベースのWorkflowを加えたものと理解すると分かりやすいです。
Q2. AutoGenはもう使わない方がよいですか？
A2. 新規の長期プロジェクトでは、Microsoft Agent Frameworkを優先して検討する方が自然です。ただし、既存AutoGen資産に含まれる会話設計、GroupChat、HITL、観測性の考え方は、MAFへの移行時にも重要な設計資産になります。
Q3. Microsoft Agent Framework（MAF）はLangGraphやCrewAIと何が違いますか？
A3. MAFはMicrosoftエコシステム上でAgent + Workflowを本番運用する基盤です。LangGraphはクラウド非依存で状態遷移を細かく制御したい場合、CrewAIは役割ベースの業務PoCを素早く組みたい場合に向いています。
Q4. MAFを使うにはAzureが必須ですか？
A4. MAF自体はオープンなフレームワークであり、Agent Frameworkのprovidersを通じて、Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic、Ollamaなど複数の推論サービスやモデルプロバイダーに接続できます。Azure前提ではありませんが、Azure AI Foundry・Microsoft 365・Agent 365と組み合わせた場合に、状態管理やガバナンスまで含めて最大の価値が出る設計です。なお、非Azureモデルや外部システムと接続する場合は、データの流れ、権限、保持場所、コスト、契約条件を個別に確認する必要があります。
専門用語まとめ
- Microsoft Agent Framework（MAF）
- Microsoftが提供するAIエージェントおよびマルチエージェントワークフロー開発基盤。AutoGenとSemantic Kernelの成果を統合した次世代フレームワーク。
- AutoGen / Semantic Kernel
- AutoGenはMicrosoft Research由来のマルチエージェント協調フレームワーク。Semantic KernelはAIアプリケーション開発SDK。両者の設計資産はMAFへ統合されつつある。
- Agent / Workflow
- AgentはLLMを使って推論・ツール実行を担う単位。Workflowは複数のAgent、関数、人間承認、外部システムを接続し、実行順序や分岐、停止、再開を制御する仕組み。
- MCP / A2A
- MCPはAIエージェントが外部ツールやデータソースへアクセスするための接続プロトコル。A2Aは異なるランタイムやフレームワーク上のAIエージェント同士が通信するためのプロトコル。
- Human-in-the-loop / Observability
- Human-in-the-loopはAIの処理途中に人間の承認や判断を挟む設計。ObservabilityはAIエージェントの入力、出力、ツール呼び出し、エラー、判断経路を観測・追跡する考え方。
主な参考サイト
本記事は一次情報を軸に執筆しています。Microsoft公式ドキュメント、公式GitHub、公式ブログ、移行ガイドを優先し、検証可能性を担保します。
- Microsoft Agent Framework Version 1.0 – Microsoft DevBlogs
- Microsoft Agent Framework Overview – Microsoft Learn
- AutoGen to Microsoft Agent Framework Migration Guide
- Microsoft Agent Framework GitHub Repository
- AutoGen GitHub Repository
- Semantic Kernel GitHub Repository
- Microsoft Agent Framework Workflows
- Microsoft Agent Framework Providers
- Azure AI Foundry – Microsoft Learn
- Microsoft Agent 365 Generally Available – Microsoft Security Blog
あわせて読みたい
更新履歴
- 初稿公開。Microsoft Agent Framework 1.0 GA、AutoGen / Semantic Kernel統合、AutoGenメンテナンスモード、Agent + Workflow、A2A / MCP、状態耐久性、HITL、Observability、Microsoftエコシステム統合を中心に構成。
