Microsoft Agent Framework for Goを試す：public previewで作れるもの・まだ選ばない方がよいもの

Posted at 2026-08-16

Go版はもう評価を始められるか

Microsoft Agent Framework（MAF）のGo実装である agent-framework-go は、単純なチャット呼び出しだけでは物足りず、GoのサービスにAgent、tool、workflowを組み込みたいときに気になる選択肢です。

結論から言うと、社内検証や限定的な新規開発なら試し始められるが、未実装機能を前提にした本番採用はまだ早い段階です。

Go版はpublic previewで、Python/.NETを管理する本体リポジトリとは別のリポジトリで開発されています。2026-08-16時点ではGitHub Releasesもタグもありません。依存関係を安定版として固定できないため、評価では導入したコミットを記録しておく必要があります。

go get ...@latest を後日あらためて実行すると、異なるコミットが解決されます。preview版を評価する間は、利用したコミットSHAを固定し、更新を意図的な作業に分けるのが安全です。

できることと、まだできないこと

READMEとSDK比較表から、現時点の範囲を採用判断向けにまとめます。

領域	Go版の状況	判断
Agent / tool / middleware	利用可能。自動tool呼び出し、tool approval、logging、OpenTelemetryなどを扱える	単一Agentや外部APIを呼ぶAgentに向く
Workflow	sequential、concurrent、group collaboration、条件分岐、subworkflow、checkpoint、human-in-the-loopなどを扱える	複数Agentの制御をGoで持ちたい場合に試せる
接続先	Microsoft Foundry、Azure OpenAI、OpenAI、MCP、A2A、AG-UI、GitHub Copilot SDKなどをサポートする	既存の接続先と必要なprovider packageを確認する
Skills	file、inline定義、scriptから構築できる	ドメイン知識をファイルとして渡す構成を評価できる
Foundry hosted deployment	未実装	FoundryにAgentをホストする前提なら選ばない
Handoff orchestration	未実装	handoffを設計の中心に置くなら待つ
Declarative Agents / Functional Workflows	未実装	YAML定義やFunctional APIを求めるならPython/.NETを検討する
RAG / CodeAct / AF Labs / DevUI	未実装	UI付きの試作、RAG、コード実行環境が必要な案件には不足する

「Python/.NET版と同じものがGoでも使える」と考えると期待を外しやすいです。Go版は基礎的なAgentとworkflowはすでに扱えますが、プロダクト統合や開発支援機能のカバー範囲はまだ狭い、という見方が実態に合います。

なぜGo版なのか

Microsoft Agent Frameworkは、Semantic Kernelのエンタープライズ向け基盤と、AutoGenのマルチAgentオーケストレーションを統合し、実験から本番運用までをつなぐ共通基盤を目指しています。Agent、tool、workflow、観測性を個別に組み合わせるのではなく、一つのモデルで扱えるようにするのが中心的な考え方です。

Go版は、その基盤をGoのアプリケーションへ持ち込むためのSDKです。既存のAPI、worker、CLIがGoで動いているなら、Agentやworkflowのためだけに別の実行環境を増やさず、サービスの近くで組み立てられます。Goを主要言語にするチームにとっては、ここが一番わかりやすい利点です。

現在はpublic previewとして本体リポジトリとは別に開発されており、利用とフィードバックを通じてMAFエコシステムとの整合を深めていく方針です。Python/.NET版と同じ成熟度や機能範囲をすぐに期待する段階ではありませんが、必要な機能が揃うGoサービスから評価を始めるには十分に筋のよい位置づけです。

commitを固定して最小のAgentを動かす

以下は、2026-08-16に確認した main のコミット 726b03baa4f8fe5eacd8ec78b08c0b6b37b9c31e を固定する例です。この時点のリポジトリは go 1.25.0 を指定しています。実行環境もGo 1.25以上にそろえます。

mkdir maf-go-preview
cd maf-go-preview
go mod init example.com/maf-go-preview
go get github.com/microsoft/agent-framework-go@726b03baa4f8fe5eacd8ec78b08c0b6b37b9c31e

Microsoft Foundryのproject endpointとmodel deploymentを環境変数へ設定します。認証には DefaultAzureCredential を使うため、ローカル開発ではあらかじめ az login を済ませておきます。

export FOUNDRY_PROJECT_ENDPOINT='https://<project>.services.ai.azure.com/api/projects/<project>'
export FOUNDRY_MODEL='<deployment-name>'

次のコードは、Foundry上のモデルを使う最小のAgentです。Collect() はストリーミングではない実行結果をまとめて受け取ります。

main.go

package main

import (
	"cmp"
	"context"
	"fmt"
	"os"

	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/microsoft/agent-framework-go/provider/foundryprovider"
)

func main() {
	endpoint := os.Getenv("FOUNDRY_PROJECT_ENDPOINT")
	model := cmp.Or(os.Getenv("FOUNDRY_MODEL"), "gpt-4o-mini")

	token, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
		panic(err)
	}

	agent := foundryprovider.NewAgent(
		endpoint,
		token,
		foundryprovider.ModelDeployment(model),
		foundryprovider.AgentConfig{
			Instructions: "You are a helpful assistant.",
		},
	)

	response := agent.RunText(
		context.Background(),
		"Microsoft Agent Frameworkを17音の日本語で説明して",
	).Collect()

	fmt.Println(response)
}

go run .

認証エラーになった場合は、まず az login のアカウントと FOUNDRY_PROJECT_ENDPOINT が同じFoundry projectを指しているかを確認します。モデルのデプロイ名を渡す点にも注意が必要です。

公式リポジトリの examples/02-agents/agents/step01_running は、上記と同じFoundry providerを使う基本例です。2026-08-16に Go 1.26.4 でこのサンプルのビルドを確認しました。ただし、実際のモデル呼び出しにはAzure側の認証と利用料金が必要です。

採用候補になるケース

次の条件なら、previewであってもPoCから評価へ進める理由があります。

Goで常駐するAPIやworkerに、toolを使うAgentを直接組み込みたい
Agent間の逐次・並列・条件分岐をworkflowとして明示したい
OpenTelemetryで通常のGoサービスとAgent実行を同じ基盤で観測したい
必要な機能がAgent、tool、MCP、A2A、workflowの範囲に収まる

特に、LLM呼び出しをHTTP handlerやqueue consumerへ散らす代わりに、Agentとworkflowの抽象を置きたい場合は相性がよさそうです。既存サービスがGoで、Pythonの実行環境を別途運用したくない事情も十分な理由になります。

まだ選ばない方がよいケース

一方で、次の条件があるなら現時点でGo版へ寄せる理由は薄いです。

Foundry hosted deploymentが必須
handoff orchestration、Declarative Agents、Functional Workflowsを使う設計
RAG、CodeAct、DevUIを使い、短期間に試作とデバッグを回したい
API互換性を長期契約や厳格な変更管理の前提にする

最後の項目は特に重要です。Releaseもタグもない段階では、preview SDKがどの範囲で後方互換性を保つかを、利用者側がコミット固定と回帰テストで補う必要があります。機能が不足している案件では、Go版を無理に選ぶより、成熟度の高いPython/.NET版を使う方が総コストを下げやすいです。

preview版を評価するときの運用

採用を検討するなら、SDKの便利さだけで決めず、更新の扱いを先に決めます。

go.mod に記録された疑似バージョンと、対応するコミットSHAを残す。
Agentのtool呼び出し、workflowのcheckpoint復元、失敗時の再実行をテストで固定する。
SDK更新は通常の依存更新と分離し、公式のIssue、PR、READMEのfeature comparisonを確認する。
本番利用するprovider、MCP server、A2A agentについて、データの送信先と利用料金を個別に確認する。

Go版は本体リポジトリの機能をそのまま移植する段階ではなく、GoのエコシステムでAgent workflowを育て始めた段階に見えます。だからこそ、今は「採用を決める」より「自分たちのworkflowに足りるかを小さく測る」用途が向いています。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up