Microsoft Agent Framework 1.0入門2026｜料金と使い方

結論から書く。Microsoft Agent Framework 1.0 は「Semantic Kernel でプロトタイプを作り、本番は AutoGen で回す」という二重管理をやめるための統合フレームワークだ。2026年4月3日に1.0が GA（一般提供）となり、両者を同じ API に畳み込んだ。エージェントを1体から始めても、後でマルチエージェントに広げるときに書き直しが発生しない。

本稿では、ローカルに Python SDK を入れて最小のエージェントを動かす手順、Azure OpenAI に繋いだときに実際にかかる料金、そして既存 LangChain / LangGraph / AutoGen ユーザーが移行する価値があるのかを、公式ドキュメントと実際のコードで確認した範囲でまとめる。

Microsoft Agent Framework 1.0 とは｜SK+AutoGen統合の全貌

Microsoft Agent Framework は、Microsoft が社内で別々に育ててきた2つの AI エージェントライブラリを、1本の SDK に畳み込んだオープンソース製品だ。公式ブログは2026年4月3日に「1.0 GA」を告知している。リポジトリは GitHub の microsoft/agent-framework で、1.0 リリース時点でスター数は 1万2000 を超えた。

片方の親は Semantic Kernel。エンタープライズ向けで .NET が本拠地、プラグイン構造が整理されていて企業のコードレビューに通しやすい。もう片方は AutoGen。Microsoft Research 発のマルチエージェント向けで、研究者がチャットのやり取りで複雑なタスクを解かせたい時に使ってきた。この2つは機能が被りつつ API が全然違い、PoC で AutoGen、本番で Semantic Kernel に移植するたびにコード書き直しが発生していた。1.0 で明示的にそれをやめる。

正式リリース版の特徴を3点に絞ると以下になる。

• Python と .NET の両方が正式サポート：同じ概念（Agent / Workflow / Context）を両言語で実装。プロトタイプは Python、本番は .NET という社内あるあるに対応する
• Workflow クラスがマルチエージェント設計の共通単位：AutoGen の「会話」と Semantic Kernel の「プランナー」を Workflow という1つの抽象に統一。人間の承認を挟む human-in-the-loop も標準機能として内蔵
• モデルプロバイダーは差し替え可能：Azure OpenAI がデフォルトだが、OpenAI 本家、Anthropic Claude、ローカル Ollama などを同じインターフェースで繋げる

Semantic Kernel と AutoGen は何がどう統合されたのか

API レベルで一番大きく変わったのは「エージェント定義の書き方」だ。Semantic Kernel はプラグイン（スキル）を Kernel に登録する手順が必須だった。AutoGen は AssistantAgent と UserProxyAgent を会話させる独自の世界観を持っていた。Agent Framework ではこの2系統が ChatAgent という1クラスに吸収される。

具体的にはこうなる。

# Microsoft Agent Framework 1.0 の最小エージェント
from agent_framework import ChatAgent
from agent_framework.openai import OpenAIChatClient

agent = ChatAgent(
    name="researcher",
    instructions="技術記事のファクトチェックをする。出典URLを必ず付ける。",
    chat_client=OpenAIChatClient(model="gpt-5.4"),
)

response = await agent.run("Microsoft Agent Framework の GA 日付は？")
print(response.text)

従来の Semantic Kernel ではカーネル生成 → プラグイン登録 → プランナー生成の3ステップが必要で、最小でも20行は書いていた。それが5行に縮む。AutoGen の UserProxyAgent のような受け手役も不要で、agent.run() が直接応答を返す。

Microsoft Agent Framework の料金｜本体は無料、かかるのは推論コスト

本体は MIT ライセンスのオープンソースで、フレームワーク自体に費用は発生しない。発生するのは背後で呼び出す LLM の API コストだけだ。デフォルトの Azure OpenAI で接続した場合のざっくり感を表にする（公式料金ページを元に2026年4月時点の値を反映）。

実体感として、1日あたり1000件のユーザー問い合わせを GPT-4o で処理し、1リクエストあたり平均4000トークン（入力3000 + 出力1000）を消費するエージェントを1ヶ月回すと、ざっくり月額 $900 前後になる。推論コストで破産したくないなら、ロジックの大半を o3-mini に委ね、最終生成だけ GPT-4o に渡す「モデルのルーティング」を Workflow 内で組むのが定石だ。

公式の料金表では、Anthropic Claude・Google Gemini・AWS Bedrock 経由でも同じフレームワークから呼べるので、Azure OpenAI 必須ではない。既に契約済みの LLM API があるなら、その推論コストがそのままエージェントの月額に乗る。

使い方｜Python で最小のエージェントを15分で動かす

手元の Windows / macOS / Linux いずれでも同じ手順で動く。Python 3.10 以上と OpenAI もしくは Azure OpenAI の API キーを用意する。

インストール

pip install agent-framework agent-framework-openai

Azure OpenAI を使うなら agent-framework-azure を追加する。

最小エージェント

import asyncio
from agent_framework import ChatAgent
from agent_framework.openai import OpenAIChatClient

async def main():
    agent = ChatAgent(
        name="summarizer",
        instructions="与えられた記事を3行で日本語要約する。専門用語は中学生でもわかる言い換えにする。",
        chat_client=OpenAIChatClient(model="gpt-5.4"),
    )
    result = await agent.run("Microsoft Agent Framework 1.0 は Semantic Kernel と AutoGen を統合したフレームワークだ……")
    print(result.text)

asyncio.run(main())

これで動く。Semantic Kernel に馴染みのある人は「え、Kernel インスタンスは？プランナーは？」と戸惑うはずだが、1.0 では全部 ChatAgent に内包された。

ツール（関数呼び出し）を持たせる

from agent_framework import ChatAgent, tool
from agent_framework.openai import OpenAIChatClient

@tool
def get_current_time() -> str:
    """現在のJST時刻を返す"""
    from datetime import datetime, timezone, timedelta
    jst = timezone(timedelta(hours=9))
    return datetime.now(jst).strftime("%Y-%m-%d %H:%M:%S")

agent = ChatAgent(
    name="clock_assistant",
    instructions="ユーザーの質問に日本語で答える。時刻を聞かれたらツールを使う。",
    chat_client=OpenAIChatClient(model="gpt-5.4"),
    tools=[get_current_time],
)

関数に @tool をつけて tools= に渡すだけ。LangChain の StructuredTool.from_function のような遠回りは不要になった。手元の M2 Mac で最小エージェントをゼロから動かすまで実測 8分。asyncio に慣れていれば躓くポイントはほぼない。逆に同期的な書き味が欲しいなら agent.run_sync() も用意されているので、Jupyter での試行錯誤も楽だ。

主要機能｜単一・ワークフロー・マルチエージェント・DevUI

Agent Framework には4つのレイヤーがある。どこまで使うかでコードの複雑さが決まる。

レイヤー1: ChatAgent（単体）

1体のエージェントが会話・ツール呼び出し・コンテキスト管理をまとめて担当する。「特定のドキュメントに対する Q&A bot」や「社内FAQ返答」など、単一タスクはここで完結する。

レイヤー2: Workflow（ワークフロー）

複数のステップを明示的に並べる構造。LangGraph の StateGraph に近い。条件分岐・並列実行・人間の承認待ちを記述できる。

from agent_framework import Workflow

wf = Workflow()
wf.add_agent("researcher", researcher_agent)
wf.add_agent("writer", writer_agent)
wf.add_agent("editor", editor_agent)

wf.add_edge("researcher", "writer")
wf.add_edge("writer", "editor")
wf.add_human_approval_before("editor")  # 編集前に人間チェック

await wf.run("AI エージェントの記事を書いて")

承認待ちの状態は永続化される。承認までの時間は数秒でも数日でも問題ない。AWS Step Functions と似た発想だが、トリガーが LLM 応答なのが違い。

レイヤー3: マルチエージェント対話（4パターン）

AutoGen 由来の「エージェント同士の自由な会話」も残っているが、1.0 では4つのパターンに整理された。

Group Chat は本番投入するとトークンが溶けるので max_rounds 指定は必須。業務用途なら Sequential か Handoff に寄せた方が安定する。

レイヤー4: DevUI・チェックポイント・A2A プロトコル

1.0 で地味だが実務に効く追加機能が3つ入った。

• DevUI：ブラウザベースのローカルデバッガ。agent-framework devui でサーバーが立ち、エージェントの思考過程・ツール呼び出し・会話履歴を GUI で追える。print デバッグの往復が減る
• チェックポイント：Workflow の実行状態を保存して中断・再開できる。長時間の処理、承認待ちで数日止まるフローで活きる
• A2A（Agent-to-Agent）プロトコル：別フレームワーク（LangGraph、CrewAI 等）で作られたエージェントと相互通信するための規格。1.0 時点で仕様が公開され、段階的に実装が乗っていく

LangChain / LangGraph との違い｜選び分けの軸

現場の採用判断では LangChain / LangGraph との比較が避けられない。ざっくり使い分けるとこうなる。

自分ならどう選ぶか。Azure 上に AI 基盤を組むなら迷わず Agent Framework を選ぶ。Azure AI Foundry との統合が深すぎて、LangChain を選ぶ積極的理由が見当たらない。一方、AWS や GCP メインのスタック、または細かいインテグレーション（Notion、Slack、各種 SaaS）が必要なら LangChain の生態系は無視できない。LangChain 入門記事や LangGraph 入門と読み比べると選択軸がはっきりする。

Semantic Kernel / AutoGen からの移行ポイント

Semantic Kernel ユーザー向け

既存の Semantic Kernel コードはそのまま動く。公式が後方互換パッケージを提供している。ただし新規開発は Agent Framework に寄せた方がいい。Kernel.InvokeAsync が agent.run に置き換わり、プラグイン登録は tools= 引数に集約される。移行の実作業は1画面あたり30分程度。

AutoGen ユーザー向け

AutoGen v0.2 のコードは agent-framework-autogen-compat パッケージ経由で動かせる。新規は ChatAgent + Workflow で書き直すのが速い。GroupChat の会話ループは Workflow のエッジ記述に置き換えると制御が明示的になり、デバッグが楽になる。

実務でハマる典型ユースケース3つ

1. 社内ドキュメントQAボット（RAG型）

Azure AI Search + Agent Framework の組み合わせが最短経路。検索ツールを @tool で定義し、ChatAgent に渡すだけ。PoC なら半日で動く。社内で多言語対応が必要な場合は、エージェントの instructions に言語指示を入れるだけで済む。

2. 承認フロー付きの業務自動化

Workflow の add_human_approval_before を使うと、契約書草案 → 人間レビュー → 最終出力、のような段階承認が簡単に組める。Power Automate のフローエンジンと繋げて Teams に通知、承認ボタンで再開、まで公式サンプルに載っている。

3. コード生成のマルチエージェント

プランナー・実装者・レビュアーの3体構成。AutoGen 時代から定番のパターンだが、Agent Framework では Workflow のグラフで明示的にできるので、どこで失敗したかのトレースが楽になった。GitHub Copilot のエージェントモード相当を自前で組むなら有力な選択肢になる。GitHub Copilot エージェントモード 料金の記事と比較すると、内製のメリット・デメリットが見えてくる。

よくある質問（FAQ）

Q1. Semantic Kernel は廃止されるのか？

いいえ。Semantic Kernel はメンテナンスが続く。ただし新機能は Agent Framework 側に先行実装される。既存プロジェクトは無理に動かす必要はないが、3年スパンで見るなら移行計画を立てておくのが安全だ。

Q2. Azure OpenAI 以外でも使えるのか？

使える。OpenAIChatClient で OpenAI 本家、AnthropicChatClient で Claude、OllamaChatClient でローカルモデルに繋がる。API は同じなので、PoC を OpenAI で作って本番を Azure OpenAI に差し替える動きも1行変更で済む。

Q3. 日本語でちゃんと動くのか？

フレームワーク自体は多言語対応なので、日本語プロンプト・日本語応答は問題ない。品質は内部で呼ぶ LLM 次第。GPT-4o / o3 系は日本語が安定しているので、体感で英語とほぼ同等の精度が出る。

Q4. LangGraph と比べて学習コストはどうか？

Agent Framework の方が低い。LangGraph は StateGraph の概念に慣れる必要があるが、Agent Framework は ChatAgent.run() が直感的で、Python の関数呼び出しに近い書き味だ。ただしグラフ全体の表現力は LangGraph の方が細かい。複雑な条件分岐が多い業務では LangGraph が向く。

Q5. どのくらいのプロジェクト規模から採用する価値がある？

1体のエージェントで終わる単機能ボットなら、正直どのフレームワークでもいい。3体以上のマルチエージェントや、human-in-the-loop を入れたい業務自動化から、Agent Framework の API 統一のメリットが効いてくる。

Q6. MCP（Model Context Protocol）との関係は？

Agent Framework は MCP サーバーをツールとして接続できる。MCPTool 経由で Claude やローカル MCP サーバーを取り込めるので、既存の MCP サーバー資産をそのまま活用できる。

まとめ｜どの層が採用すべきか

Microsoft Agent Framework 1.0 は、Semantic Kernel と AutoGen の往復移植で消耗してきたチームにとっては、待ち望んだリリースだ。特に以下に該当する人は今すぐ触る価値がある。

• Azure 上で AI エージェント基盤を構築する予定の日本企業
• .NET が主力で、Python で書かれた AutoGen を諦めていたチーム
• LangChain のバージョン破壊的変更に疲れたエンジニア
• マルチエージェント + human-in-the-loop を1つの SDK で書きたい開発者

逆に、AWS / GCP がメインのスタック、あるいは個人開発で手早くプロトタイプを作りたい場合は、生態系の厚い LangChain が依然として有力な選択肢だ。関連する AIエージェント完全ガイドや Claude Agent SDK 入門も併せて検討材料に加えると、選び分けの軸がより明確になる。

まずは pip install agent-framework で入れて、5行のサンプルを動かしてみる。それだけで「どこに効くフレームワークか」の手応えは掴める。