Microsoft Agent Frameworkとは｜使い方と向き不向き

Microsoft Agent Framework は、AIエージェントとマルチエージェントのワークフローを .NET・Python・Go で書くための、Microsoft 製のオープンソースフレームワーク（MITライセンス）です。Semantic Kernel と AutoGen を作ったチームがそのまま手がけた後継で、PyPI の agent-framework はバージョン1.0が2026年4月2日に公開されています。ただ「統合された後継です」と聞いただけでは、自分の案件で使うべきかは決まりません。この記事では、公式ドキュメントと GitHub・PyPI の公開情報を編集部で確認したうえで、Microsoft Agent Framework で何ができるのか、インストールから最初のエージェントが動くまでのコード、長時間タスク用の Harness と Agent Skills、そして採用してよい場面と見送ったほうがよい場面までをまとめます。既存コードの書き換え手順そのものはAutoGenからMicrosoft Agent Frameworkへの移行手順に分けてあります。

Microsoft Agent Frameworkとは？何ができるフレームワークか

ひとことで言えば、モデルにツールを持たせて仕事をさせる部分と、複数のエージェントを決まった順路でつなぐ部分を、同じSDKの中で書けるようにしたフレームワークです。単発のチャットボットから、承認を挟みながら何十ステップも進む業務処理まで、途中で別のライブラリに乗り換えずに書き切れる点が特徴といえます。

Agents・Harness・Workflows・Integrationsの4本柱

公式ドキュメントは機能を4つの領域に整理しています。どれを使うかで書き方がまるごと変わるため、最初にここを分けて覚えておくと迷いません。

領域	中身	使う場面
Agents	LLMが入力を処理し、ツールやMCPサーバーを呼んで応答を返す個々のエージェント	1回の呼び出しで片づく判断・生成
Harness Agent	計画とToDo管理、文脈の圧縮、ファイルアクセスとメモリ、ツール承認、可観測性まで最初から入ったエージェント	調査・コーディングなど長い多段タスク
Workflows	エージェントと関数を明示的な実行経路でつなぐ、関数型およびグラフ型のワークフロー	手順が決まった複数ステップの処理
Integrations	モデルプロバイダ、エージェントサービス、ツール、コンテキストプロバイダ、ミドルウェア、評価サービス、UIとの接続	既存のクラウドや社内基盤につなぐとき

土台になる部品はモデルクライアントとセッション

4本柱の下には、共通の基礎部品が置かれています。モデルクライアント（チャット補完とレスポンス）、状態を保つエージェントセッション、記憶を受け持つコンテキストプロバイダ、動作に割り込むミドルウェア、そしてツール連携のためのMCPクライアントです。ここが共通化されているため、Agent で試作したものを Harness や Workflows に載せ替えても、セッションやコンテキストプロバイダの扱いは変わりません。MCP そのものの仕組みはMCPの仕組みを図解した記事で整理しています。

対応言語とバージョンの現在地

対応言語は .NET・Python・Go の3つです。Python 版と .NET 版はバージョンの系列が分かれており、GitHub のリリース一覧では Python が1.17.0（2026年9月3日）、.NET が1.20.0（2026年8月31日）まで進んでいます。Python は3.10以上が必要です。Go 版だけは公式が「パブリックプレビュー」と明記しており、宣言的エージェント・RAG・CodeAct・関数型ワークフローがまだ使えません。同じ製品名でも言語によって届いている機能が違う、という前提は最初に押さえておく必要があります。

対応するモデルプロバイダの一覧

モデル側の選択肢は広く、Azure に閉じていません。ただし、どのプロバイダでも全機能が使えるわけではなく、この差がそのまま設計の前提になります。公式の対応表から主要なものを抜き出すと次のとおりです。

プロバイダ	関数ツール	構造化出力	MCPツール	備考
Azure OpenAI / OpenAI / Microsoft Foundry	◯	◯	◯	コードインタプリタとファイル検索も対応
Anthropic	◯	◯	◯	ファイル検索は非対応
Google Gemini	◯	◯	◯	バックグラウンド応答は非対応
Ollama	◯	◯	×	ローカル実行。MCPツールは使えない
Amazon Bedrock	◯	プロバイダ次第	×	AWS上の基盤モデル
Mistral / Foundry Local / ONNX / Dapr	一部	一部	×	ONNXは関数ツールも非対応

Microsoft Agent Frameworkの使い方｜最初のエージェントが動くまで

ここからは Python で、パッケージを入れてエージェント1体が返事をするところまでを追います。手数が一番少ないのが Python のため、まずこちらから示します。

①インストールとPythonの最小コード

メタパッケージ agent-framework を入れると、コアと主要プロバイダのパッケージがまとめて入ります。使うプロバイダが決まったあとで、個別パッケージだけに絞る形に変えられます。

pip install agent-framework

エージェントは Agent にチャットクライアントと指示文を渡して作り、run で呼びます。Kernel の組み立てもプラグインの登録もありません。

from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient

agent = Agent(
    client=OpenAIChatClient(model="gpt-4o"),
    name="HelloAgent",
    instructions="あなたは簡潔に答えるアシスタントです。",
)

result = await agent.run("フランスで一番大きい都市は？")
print(result.text)

最初につまずきやすいのが環境変数です。公式は「Agent Framework は .env ファイルを自動では読み込まない」と明記しています。APIキーを .env に置いているなら、アプリの先頭で load_dotenv() を呼ぶか、シェルやIDE側で環境変数を設定してください。

②ツールは普通の関数を渡すだけで増える

ツールの追加は、Python の関数を書いて tools に渡すだけで終わります。関数名がツール名、docstring が説明として使われるため、専用のクラスや属性でラップする作業は不要です。

from typing import Annotated
from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient
from pydantic import Field

def get_weather(
    location: Annotated[str, Field(description="天気を調べたい地域名")],
) -> str:
    """指定した地域の天気を返す。"""
    return f"{location}は曇りで、最高気温は15度です。"

agent = Agent(
    client=OpenAIChatClient(model="gpt-4o"),
    name="WeatherAgent",
    instructions="天気の質問に答えます。",
    tools=[get_weather],
)

ツールが増えて名前だけでは選び分けられなくなったら、@tool デコレータで名前と説明を明示できます。モデルに見せるスキーマを完全に握りたい場合は、schema に Pydantic モデルか生のJSONスキーマを渡す方法も用意されています。

from agent_framework import tool

@tool(name="weather_tool", description="任意の地域の天気情報を取得する")
def get_weather(location: str) -> str:
    return f"{location}は曇りで、最高気温は15度です。"

説明文はAnnotatedとdocstringで渡す

モデルがツールを正しく選べるかどうかは、名前より説明文で決まります。Python では引数に Annotated と Pydantic の Field(description=...) を付け、関数本体には docstring を書くのが公式のやり方です。@tool で name と description を省略した場合は、関数名と docstring がそのまま使われます。認証情報のようにモデルに渡したくない値が必要なときは、ツールをクラスのメソッドとして書き、束縛したメソッドを tools に渡します。接続やシークレットはクラス側の属性に持たせたまま呼び出せます。

③会話を続けるにはセッションを持たせる

「さっきの続き」を理解させたいときはセッションを作り、run に渡します。呼び出し側で履歴の配列を組み立てて詰め直す必要はありません。

session = agent.create_session()

r1 = await agent.run("この議事録を3行に要約して", session=session)
r2 = await agent.run("さっきの要約を箇条書きに直して", session=session)
print(r2.text)

会話履歴をサービス側が保持するか、アプリ側で持つかはプロバイダで変わります。OpenAI や Azure OpenAI の Responses 系はサービス側が履歴を持てますが、Chat Completions 系や Anthropic はアプリ側で持つ形になります。長期間の会話を残す要件があるなら、この違いは設計を始める前に確認しておきたい箇所です。

.NETとGoでの始め方

.NET と Go も考え方は同じで、使うプロバイダのパッケージを1つ入れて、クライアントからエージェントを作ります。公式のクイックスタートは Microsoft Foundry を前提にしており、次のコマンドが案内されています。

# .NET（Microsoft Foundry プロバイダ）
dotnet add package Microsoft.Agents.AI.Foundry --prerelease

# Go（パブリックプレビュー）
go get github.com/microsoft/agent-framework-go

.NET では IChatClient を実装した推論サービスであれば ChatClientAgent の裏側に置けます。関数ツールは AIFunctionFactory.Create でメソッドから作り、DescriptionAttribute で説明を添える形です。C# を主戦場にしているチームにとっては、.NET が後回しにされていないことがそのまま選定理由になります。

Harnessエージェントは通常のAgentと何が違う？

違いは「自分で組む部分がどこまで済んでいるか」です。通常の Agent は、渡したツールだけを使い、承認やメモリや可観測性は自分で足します。Harness は、長い多段タスクで結局は必要になるそれらを最初から組み合わせた状態で渡してくれます。

既定で入っている機能とオプトインの機能

公式は Harness を「調査・コーディング・データ分析などの長時間の作業向けの、意見のはっきりした全部入り」と説明しています。何が最初から動き、何を自分で有効にするのかを分けると次のようになります。

機能	既定の状態	何が起きるか
ToDo追跡・プラン/実行モード	既定でON	作業を分解して進捗を保持する
ツール承認（自動承認ルール付き）	既定でON	実行前に人へ確認を求められる
OpenTelemetry	既定でON	実行の中身をトレースとして取り出せる
セッションのファイルメモリ	既定でON	作業の途中結果をファイルに残す
文脈の圧縮（コンパクション）	トークン上限か戦略を指定するとON	長い会話でも文脈が溢れにくくなる
Web検索	クライアントが対応していればON	外部情報を取りに行ける
Agent Skills	.NETは既定でON／Pythonはオプトイン	手順書をエージェントが読み込む
共有ファイルアクセス・バックグラウンドエージェント・ループ	オプトイン（実験的）	並列委譲や再実行を足せる

Python の create_harness_agent 自体はリリース済みですが、バックグラウンドエージェント・ファイルアクセス・ループは実験的な扱いで、シェル実行はプレリリースの agent-framework-tools から来ます。Go には現時点でパッケージ化された Harness がなく、コンテキストプロバイダやミドルウェアを自分で組み合わせる必要があります。

create_harness_agentでHarnessエージェントを作る

作り方は関数を1つ呼ぶだけです。Harness の運用方針と、エージェント個別の役割を別々の引数で書き分けられます。

from agent_framework import create_harness_agent
from agent_framework.openai import OpenAIChatClient

agent = create_harness_agent(
    client=OpenAIChatClient(model="gpt-4o"),
    name="research-agent",
    harness_instructions="ツールは慎重に使い、確認できた結果だけ報告してください。",
    agent_instructions="あなたは一次情報を重視する調査担当です。",
    max_context_window_tokens=128_000,
    max_output_tokens=16_384,
)

session = agent.create_session()
response = await agent.run("この製品の公式仕様を洗い出して表にまとめて", session=session)
print(response.text)

注意点が1つあります。Harness はツール承認ミドルウェアを既定で入れるため、実行のたびにセッションを渡さないと動きません。承認の仕組みが不要なら disable_tool_auto_approval=True を指定します。逆に disable_todo や disable_compaction のように、要らない機能だけを個別に外す設計にもなっています。

SKILL.mdで手順書をエージェントに持たせる

Agent Skills は、指示・スクリプト・参考資料をひとまとまりにした持ち運び可能なパッケージです。agentskills.io のオープン仕様に沿っており、実体は SKILL.md を含むディレクトリになります。

expense-report/
├── SKILL.md      # 必須。YAMLフロントマター＋手順の本文
├── scripts/      # エージェントが実行できるコード
├── references/   # 必要になったときだけ読む参考資料
└── assets/       # テンプレートなどの静的ファイル

この仕組みの要は段階的な読み込みです。起動時にシステムプロンプトへ入るのはスキル名と説明だけで、公式はここを1スキルあたり約100トークンと見積もっています。タスクが合致したときに load_skill で本文を読み、資料が要れば read_skill_resource、スクリプトを動かすなら run_skill_script と、必要になった分だけ文脈に載せる設計です。SKILL.md は500行以内に収め、細かい資料は別ファイルに逃がすことが推奨されています。Python では skills_paths にディレクトリを渡せば、ファイルベースのスキルを読み込めます。

from pathlib import Path
from agent_framework import SkillsProvider, create_harness_agent

agent = create_harness_agent(
    client=client,
    agent_instructions="タスクに合うスキルがあれば使ってください。",
    skills_paths=Path(__file__).parent / "skills",
    # load_skill と read_skill_resource だけ自動承認し、スクリプト実行は承認を求める
    auto_approval_rules=[SkillsProvider.read_only_tools_auto_approval_rule],
)

3つのスキルツールはいずれも既定で承認が必要です。信頼できるスキル置き場に限って自動承認ルールを当てる、という運用が想定されています。スキルとサブエージェントの役割の切り分けはClaude Codeのスキルとサブエージェントの使い分けと考え方が共通しているので、あわせて読むと設計の見通しが立ちます。

Workflowsで複数のエージェントを1本の処理につなぐ

Workflows は、エージェントと関数をノードとして並べ、明示的な経路で結ぶ仕組みです。会話の流れに任せるのではなく、どこからどこへ値が渡るかをコードとして固定できます。すべてのSDKがグラフ型APIを備え、Python にはこれに加えて実験的な関数型API（@workflow と @step）が用意されています。

WorkflowBuilderの最小コード

開始ノードを決め、辺を足し、ビルドするだけです。実行は非ストリーミングとストリーミングのどちらも選べます。

from agent_framework import WorkflowBuilder

builder = WorkflowBuilder(start_executor=collector)
builder.add_edge(collector, drafter)
builder.add_edge(drafter, reviewer)
workflow = builder.build()

# 完了まで待って結果を受け取る
events = await workflow.run("今週の社内向け週報を作って")
print(events.get_outputs())

# 途中経過を受け取りたい場合
async for event in workflow.run("今週の社内向け週報を作って", stream=True):
    if event.type == "output":
        print(event.data)

人の確認を挟みたい箇所は、Pythonならエグゼキュータから直接 ctx.request_info() を呼び、@response_handler で受け取ります。C#とGoでは RequestPort を使います。承認待ちを例外や外側のループで無理やり作らずに済むのが、この設計の実利です。

スーパーステップ実行が保証すること

Workflows は Pregel 由来のスーパーステップ方式（Bulk Synchronous Parallel）で動きます。1つのスーパーステップ内で対象ノードが並列に走り、全員が終わるまで次へ進みません。この同期バリアがあるおかげで、同じ入力なら常に同じ順序で実行される決定性、スーパーステップ境界での確実なチェックポイント、スーパーステップ間で競合状態が起きないという3点が保証されます。

裏返すと、扇形に分岐したうちの1本に長時間かかるノードがあると、もう1本のチェーンもそこで足止めされます。本当に独立して走らせたい経路は、複数ノードに刻まず1つのノードにまとめる、という回避策が公式に示されています。ビルド時には型の互換性、開始ノードからの到達性、ノードの束縛、辺の重複までが検証されるため、つなぎ間違いは実行前に落ちます。

Semantic Kernel・AutoGen・LangChainとの関係と使い分け

選定で一番よく詰まるのがここです。名前が似た選択肢が並んでいるので、まず Microsoft 陣営の中の整理から始めます。

Semantic KernelとAutoGenの後継という位置づけ

公式は Agent Framework を「両者の直接の後継」と言い切っています。AutoGen の単体・複数エージェントの素直な抽象化に、Semantic Kernel のセッションベースの状態管理・型安全・フィルタ・テレメトリ・幅広いモデル対応を合わせ、さらに実行経路を明示できるワークフローを足した、という構成です。したがって「Semantic Kernel と AutoGen のどちらを選ぶか」という問いは、新規案件ではもう立てなくてよくなりました。すでに動いているコードをどう移すかは論点が別なので、AutoGen 側の書き換えはAutoGenからMicrosoft Agent Frameworkへの移行手順にまとめてあります。

LangChain・Mastraと並べたときの立ち位置

Microsoft 以外の選択肢と比べると、差が出るのは言語と、本番運用向けの部品が最初から入っているかどうかです。LangChain は Python と JavaScript の両方に厚みがあり、周辺ライブラリの数で優位に立ちます。Mastra は TypeScript で完結させたいときの選択肢です。Agent Framework は .NET を一級の対象に据えている点と、ツール承認・OpenTelemetry・チェックポイントといった監査まわりが標準で入っている点が持ち味になります。TypeScript側の比較はMastraとLangChainの使い分けで扱っています。

TypeScriptで書きたい場合はどうするか

Agent Framework には TypeScript / JavaScript のSDKがありません。公式が示している言語は .NET・Python・Go の3つだけです。フロントエンドと同じ言語で完結させたいなら、MastraでAIエージェントを動かす手順のような TypeScript 製のフレームワークを選ぶか、エージェント本体を Python で立ててHTTP経由で呼ぶ構成にします。どうしても社内標準がNode.jsという事情があるなら、後者は現実的な折衷案です。

向き不向き｜採用してよい場面と見送ったほうがよい場面

ここまでの仕様から、判断の材料を両側に振り分けます。「多機能だから良い」ではなく、自分の案件の条件と噛み合うかどうかで決めるのが安全です。

採用してよい5つの場面

#	場面	根拠になる仕様
01	C#／.NET でエージェントを書く必要がある	.NET が公式SDKの対象で、リリースも Python と並走している
02	調査やコード生成など、長い多段タスクを回したい	Harness に ToDo管理・文脈圧縮・ファイルメモリが既定で入る
03	手順が固まった処理を型検証つきで固定したい	Workflows がビルド時に型互換性と到達性を検証する
04	実行ログの監査や人の承認が要件に入っている	ツール承認と OpenTelemetry が既定で有効
05	Semantic Kernel や AutoGen の資産がすでにある	公式が直接の後継と位置づけ、移行ガイドを用意している

見送ったほうがよい4つの場面

逆に、次の条件に当てはまるなら別の手段を先に検討したほうが早く着地します。

#	場面	理由
01	TypeScript／Node.js で完結させたい	公式SDKは .NET・Python・Go のみ
02	Go で長時間タスクや宣言的エージェントを書きたい	Go はパブリックプレビューで、Harness・RAG・CodeAct・関数型ワークフローが未提供
03	Ollama のローカルモデルで MCP サーバーも併用したい	公式の対応表で Ollama は MCPツールが非対応
04	入力も処理も完全に決まっている定型処理	公式が「関数で書けるならエージェントではなく関数で書け」と明記

4つ目は特に軽視されがちです。エージェント化すると、確率的な出力とAPI課金という不確実性が2つ増えます。判断が要る箇所だけをエージェントに任せ、残りは普通の関数として書くほうが、運用に入ってからの手当てが減ります。

料金とライセンス

フレームワーク自体は MIT ライセンスのオープンソースで、利用に追加料金は発生しません。費用がかかるのは裏で呼ぶモデルのAPI利用分だけです。Ollama や Foundry Local でローカルのモデルを動かせば、その分のクラウド費用は生じません。

もう1点、責任範囲について公式がはっきり書いている箇所があります。Azure 直提供以外のサーバー・エージェント・コード・モデル（公式の言い方では「Third-Party Systems」）と組み合わせて使う場合は自己責任であり、それらは Microsoft 製品条項でいう非Microsoft製品として、各社のライセンス条項に従います。やり取りされるデータが組織のコンプライアンス境界や地理的境界の外に出るかどうかは、利用者側が管理する責任だと明記されています。社内データを扱う案件では、この一文を要件定義の段階で共有しておくのが安全です。

よくある質問

まとめ：導入するかを決める3つの問い

Microsoft Agent Framework を採用するかは、次の3つで判断できます。1つ目は「その案件を .NET か Python で書くか」です。TypeScript で完結させたいなら、この時点で別の選択肢になります。2つ目は「1回のLLM呼び出しで終わらないか」です。長い多段タスクなら Harness、手順が固まった複数ステップなら Workflows と、既製の受け皿が用意されています。3つ目は「承認や監査のログが要件に入っているか」で、ツール承認と OpenTelemetry が既定で入る点は自作すると重い部分です。

3つとも当てはまるなら、まずは pip install agent-framework で最小のエージェントを1体だけ動かし、社内の関数を1つツールとして渡してみるのが失敗しない入り方です。すでに AutoGen で組んだ資産があるならAutoGenからMicrosoft Agent Frameworkへの移行手順を、TypeScript側の選択肢と比べたいならMastraとLangChainの使い分けをあわせてご覧ください。

出典

• Microsoft Agent Framework Overview｜Microsoft Learn
• Agent Harness｜Microsoft Learn
• Agent Skills｜Microsoft Learn
• Using function tools with an agent｜Microsoft Learn
• Workflow Builder & Execution｜Microsoft Learn
• Model providers｜Microsoft Learn
• microsoft/agent-framework｜GitHub
• agent-framework｜PyPI