Microsoft Agent Frameworkとは？使い方や料金、移行方法を解説

「MicrosoftのAIエージェント開発をもっと簡単にしたい」「複数のAIエージェントを連携させた高度なワークフローを構築したい…」と感じていませんか？Microsoftはそんなニーズに応えるべく、2025年10月にオープンソースの新フレームワーク「Microsoft Agent Framework」を発表し、2026年4月にはVersion 1.0（production-ready release）へ到達しました。本記事では、このフレームワークの全貌を徹底的に解説します。
✅Microsoft 365 Copilotの最新エージェント機能「Copilot Cowork」については、以下の記事をご覧ください。
Copilot Coworkとは？機能や料金、Claude Coworkとの違いを解説

Microsoft Agent Frameworkとは

Microsoft Agent Frameworkとは、AIエージェントやマルチエージェントのワークフローを構築・統合・実行できるオープンソースの開発フレームワークです。

Microsoftが提供するこのフレームワークは、Azure OpenAIなどの大規模言語モデル（LLM）を活用した「エージェント型システム」の開発を支援します。ユーザー入力への応答だけでなく、外部ツールの呼び出し、状態管理、マルチステップ処理の制御など、高度な自律処理を前提とした設計が特徴です。

従来、AIエージェントを構築する際には、Semantic KernelやAutoGenといった複数のOSS（オープンソースソフトウェア）を組み合わせる必要がありました。Agent Frameworkは、これらの機能的要素を再構成し、一貫性のあるAPI設計と型安全性のある実行環境に統合しています。特に以下のようなニーズに対応する形で設計されています。

Agent Frameworkは、Semantic KernelとAutoGenの思想を統合した後継フレームワークとして、Microsoft AIエコシステムにおけるエージェント開発の中核を担う位置づけです。

Microsoft Agent Framework（Microsoft GitHub）

主なユースケース

Agent Frameworkは、単体のチャットボットに留まらず、業務自動化やマルチエージェント連携まで広範な場面で活用が進んでいます。代表的な用途を以下の図で整理しました。

以下は、Agent Frameworkが特に力を発揮する主要ユースケースです。

• Azure OpenAIやOpenAI APIを活用した高度なチャットボットやエージェント構築
• 外部APIや社内ツールとの統合を伴う業務自動化フローの構築
• 複数エージェントの対話や協調を伴うマルチエージェント・システムの設計
• Copilot StudioやAzure AI Foundryとの連携（連携経路はすでに提供されており、今後さらに相互運用が進む方向）

いずれのケースでも「単発応答」ではなく「自律的な複数ステップ処理」が前提になる点が共通しています。

提供状況とライセンス

Agent FrameworkのPreviewからGAまでの歩みと、現時点の提供状況を以下の図で整理しました。

Agent Frameworkは2025年10月1日に**Public Preview（一般公開プレビュー）として発表され、その後2026年4月3日にVersion 1.0（production-ready release）**へ到達しました。

現在は1.0が公開済みで、本番運用を想定した利用が可能な段階にあります。ただし周辺機能のうち一部（Responsible AI系の機能やサンプル統合など）はpreview段階のものが残っており、利用時は対象機能の提供状況を公式ドキュメントで個別に確認する必要があります。GitHub上でコード・サンプル・開発ガイドが公開されており、オープンソースとして自由に活用できます（MITライセンス）。

※MITライセンス：ソフトウェアの使用、コピー、変更、統合、公開、配布、サブライセンス、販売を無制限に許可するオープンソースライセンス。ただし、著作権表示と許諾表示を含める必要があります。

背景にあるニーズとMicrosoftの狙い

LLMの普及に伴い、単一のチャットボットを超えた「タスク分解」「自律判断」「複数エージェント連携」などを必要とするユースケースが増加しています。Microsoftはそのニーズに応えるために、Semantic KernelとAutoGenの思想を内包しつつ、より再利用性と構成性に優れた新たな基盤としてAgent Frameworkを位置づけています。

加えてMicrosoftは、AutoGenをmaintenance modeに移行済みで、新規プロジェクトではMicrosoft Agent Frameworkを推奨する方針を公式READMEで明示しています。一方、Semantic Kernelは現行のSDKとして引き続き提供中で、.NET公式の案内でも「新規のagenticアプリではAgent Frameworkを第一候補に」という位置づけにとどまります。既存プロジェクトで新しい要件や機能拡張が発生する場合は、Agent Frameworkへの移行を検討する必要があります。

Copilot StudioおよびAzure AI Foundryとの連携経路はすでに公式ドキュメントで案内されており、今後さらに相互運用が進む方向にあります。Microsoftエコシステム全体における「エージェント開発の中核フレームワーク」としての役割が期待されています。

関連記事：
・Microsoft Copilot Studioとは？できることや使い方、料金体系を解説！
・Azure AI Foundryとは？できることや使い方、料金を徹底解説！

Microsoft Agent Frameworkの主な特徴と構成要素

Microsoft Agent Frameworkは、単一エージェントから複雑なマルチエージェント構成まで柔軟に設計できる、高い拡張性と統合性を持ったAIエージェント開発基盤です。

このフレームワークは、従来のチャットボットやスクリプト処理を超え、「意思決定→ツール実行→状態保持→対話継続」までの一連のプロセスを自律的に処理する仕組みを提供します。以下に主要な構成要素を整理します。

この図の通り、Agent／Workflow／Tool／Session／Middleware／DevUIという6つの構成要素が有機的に連携する設計です。次項から個別に見ていきます。

エージェント（Agent）

Agent Frameworkの中核を担う存在が「エージェント」です。エージェントは以下の機能を備えたAI主体であり、LLMと外部環境との橋渡し役を担います。

LLMのプロバイダーとしては、Azure OpenAI、OpenAI API、Azure AI が公式にサポートされています。

ワークフロー（Workflow / GraphFlow）

上図は、複数エージェント・関数・ツールをノードとして繋げていく「GraphFlow」のイメージです。Microsoft公式ドキュメントで示される全体像も合わせて参考にしてください。

ワークフローイメージ(参考Microsoft)

複数のエージェント・関数・ツールを統合し、条件分岐やループ処理を含むグラフ構造のワークフローとして構築できます。

主な特徴：

• ノードベースの構成：各ノードにエージェントや関数を割り当て、順序・条件分岐を設定
• 型安全な入出力管理：各ノードは入力型・出力型を明示し、安全に連携できる
• チェックポイント機能：途中状態の保存・復元により、長時間対話や障害対応が容易
• Human-in-the-loop（HITL）対応：必要に応じて人間による承認や選択を挟むことも可能
• 非同期／並列実行：複数のノードを同時実行し、実行効率を高める

Agent Frameworkのワークフローは、AutoGenの「GroupChat」やSemantic Kernelの「Planner」よりも明示的で再利用可能な設計が可能です。

ツール（Tools）と関数連携

Agent Frameworkでは、既存の関数に軽いメタ情報を添えるだけでツールとして扱える設計になっています。具体的な使い方を見ていきましょう。

エージェントは事前定義された関数（Function）を「ツール」として呼び出せます。

• 関数には スキーマ情報（引数の型、説明など） を付与でき、LLMがより正確に呼び出せるよう設計されています。
• Pythonでは @tool デコレーターを付けるか、通常の関数をそのまま tools=[...] に渡す形でツール化します。
• .NETでも類似の属性ベースの記述が可能です。

この形式はAutoGenの FunctionTool や SK の Plugin よりも、一貫性と型安全性が高い設計となっています。

セッション（Session）と状態管理

セッションは、マルチターン対話と文脈保持を両立させる中核機構です。ユーザー・ワークフロー単位で分離される点も踏まえ、詳細を整理します。

エージェントはセッション単位で状態（履歴・出力・中間変数）を保持します（1.0以降、旧称のスレッドからセッションに整理されました）。

• 各セッションは一連の実行履歴を含むデータ構造であり、外部ストレージやメモリストアへの永続化も可能です。
• セッションはユーザー単位やワークフロー単位で分離され、LLMの文脈処理に適した構造を提供します。

ミドルウェア（Middleware）

上図のように、エージェント実行の前後に共通処理を差し込める仕組みが整備されています。実行前は検証やパラメータ整形、実行後は結果検証や異常検知を担うのが典型です。

Agent Frameworkでは、エージェントの実行前後に共通処理を挟むミドルウェア機構が提供されます。

• 実行前の検証・ロギング・パラメータ整形
• 実行後の結果検証・モニタリング・異常検知

などを、個々のエージェント実装に手を加えることなく適用でき、再利用性の高い処理分離が実現されています。

DevUIと観測機能

上図のように、DevUIはブラウザベースで実行ログやチェックポイントを確認でき、OpenTelemetryと組み合わせるとメトリクスやトレースの集約も可能です。

開発者向けのWeb UI（DevUI）が提供されており、以下のような作業を視覚的に行えます。

• エージェントやワークフローの実行ログの閲覧
• 入力と出力のステップごとの確認
• チェックポイントの確認とリトライ
• ワークフローのノード構造の可視化

さらに、OpenTelemetryベースのロギング・トレース・メトリクスも統合可能で、エンタープライズレベルの可観測性もサポートしています。

Microsoft Agent Frameworkのユースケース

代表的な3ユースケース（出張手配／旅行サポート／開発支援）を上図で俯瞰できます。以下で各シナリオを順に掘り下げます。

このセクションでは、Microsoft Agent Frameworkで構築したAIエージェントの活用が期待できる具体的な例をご紹介します。

従業員の出張手配エージェント

上図のように、ユーザー指示からフライト・ホテル・経費の各ツール呼び出しへ自動で展開され、費用超過時は人間の承認を挟む設計です。

従業員が「来週、東京へ出張」と指示するとエージェントが起動し、定義されたワークフローに従って、フライト検索ツール、ホテル予約ツール、社内経費システムを順次呼び出して手続きを自動化します。

費用が規定額を超える場合はガードレールが作動して上司に承認依頼を送り、承認が得られると予約が確定します。

旅行サポートエージェント

会話文脈を維持したまま、認証・予約照会・変更処理までを一貫して進める流れを上図で示しています。

顧客から「予約情報を確認したい」と依頼された場合、エージェントはまず顧客認証を行い、認証後にツールを呼び出してデータベースから予約情報を取得して提示します。

さらに顧客が「フライトを変更したい」と追加で依頼した際も、会話の文脈を維持したまま必要な承認や確認を行い、予約内容の変更という実務タスクを完了させます。

専門的な分析と開発支援

Issue起票をトリガーに、分類エージェント→RAG検索→担当者提案という連携フローが自動で走ります。詳細を以下で解説します。

開発リポジトリに新しいIssueが作成されると、エージェントが内容を確認します。まず分類エージェントを呼び出して、Issueを「バグ報告」「機能要望」などに振り分けます。

次に、RAGエージェントで過去の類似Issueをベクトル検索して関連情報でグラウンディングします。最後に、これらの結果をもとに、対応に適した担当者候補を自動で提案します。

Microsoft Agent Frameworkの活用デモ

デモの流れは上図の通りです。関数定義→ツール登録→自律的な呼び出し→結果出力、という基本パターンを実地で確認していきます。

ここでは、Microsoft Agent Frameworkを活用し、外部ツールと連携して気象情報を取得するエージェントのデモをご紹介します。

まずは前のセクションに沿ってMicrosoft Agent Frameworkをセットアップします。

以下は、httpxを使用してWeatherAPIを非同期で呼び出し、必要な情報を抽出する関数です。APIキーは環境変数 WEATHER_API_KEYとして設定します。

async def get_weather(
location: Annotated[str, Field(description="天気予報を取得したい都市名。例: '東京', 'サンフランシスコ'")]
) -> str:
    """
    指定された場所の現在の気象情報を取得します。
    """
    api_key = os.environ.get("WEATHER_API_KEY")

    base_url = "http://api.weatherapi.com/v1/current.json"
    params = {"key": api_key, "q": location, "aqi": "no"}

    async with httpx.AsyncClient() as client:
        response = await client.get(base_url, params=params)

    data = response.json()
    
    # 必要なデータを抽出
    loc_name = data.get("location", {}).get("name", "不明な場所")   # 都市
    condition = data.get("current", {}).get("condition", {}).get("text", "不明")    # 天気
    temp_c = data.get("current", {}).get("temp_c", "N/A")   # 気温

続いて、以下のコードでエージェントを定義します。tools 引数に先ほど作成した get_weather を渡し、同じエージェントを run() で実行します。

async def main():
    # エージェントの設定（tools引数に関数オブジェクトをリストで渡す）
    agent = AzureOpenAIResponsesClient(credential=AzureCliCredential()).as_agent(
        name="weather_agent_demo",
        instructions=(
            "あなたは役立つアシスタントです。ユーザーから天気を尋ねられた場合は、"
            "利用可能な `get_weather` ツールを積極的に使用して、具体的で実用的な回答を提供してください。"
        ),
        tools=[get_weather],
    )

    # 同じエージェントを run() で実行
    result = await agent.run("大阪の天気はどうですか？")
    print(result.text)

if __name__ == "__main__":
    asyncio.run(main())

実際にエージェントを実行し、「大阪の天気はどうですか？」というプロンプトに対して、以下の結果が得られました。

大阪の現在の天気は曇り、気温は18.0°Cです。

上記のように、事前定義した関数を自律的に選択し、自動で実行するエージェントを作成できます。

Microsoft Agent Frameworkの使い方：クイックスタート

Microsoft Agent Frameworkは、数行のコードでAIエージェントを起動できる軽量設計が特徴です。
ここでは、最も基本的なエージェントの作成と実行までを、.NETおよびPythonで順に解説します。

クイックスタートの全体像は上図のとおりです。前提条件を整えた上で、.NET と Python のどちらからでも数分でエージェントを起動できます。

前提条件の確認

.NETとPython共通の認証要件と、言語別のランタイム要件を以下の通り整理しました。詳細は次の一覧で確認してください。

共通要件

• Azure OpenAI Service もしくは OpenAI API の利用権（エンドポイント／APIキー）
• 対応モデル（例：gpt-4o、gpt-4、gpt-3.5-turbo など）

.NET 環境

• .NET SDK 8.0 以上
• Azure CLI（az login 実行済み）
• 任意のIDE（Visual Studio、Rider、VS Code など）

Python 環境

• Python 3.10 以上
• pip（パッケージ管理）
• 任意のエディタ（VS Code など）

環境変数には、利用するサービス（Azure AI Foundry か Azure OpenAI か）に応じて適切な値を設定します。

# Azure AI Foundry を利用する場合（Foundry project endpoint + モデル名）
export FOUNDRY_PROJECT_ENDPOINT="https://<your-project>.services.ai.azure.com/api/projects/<project-id>"
export FOUNDRY_MODEL="<your-deployment-name>"   # 例: gpt-4o

# Azure OpenAI を直接利用する場合
export AZURE_OPENAI_ENDPOINT="https://<your-resource>.openai.azure.com/"
export AZURE_OPENAI_DEPLOYMENT_NAME="<your-deployment-name>"

FOUNDRY_MODEL は API バージョン文字列ではなく、Azure AI Foundry側で作成したモデルのデプロイ名を入れる点に注意してください。

.NETで始めるクイックスタート

.NETでは、プロジェクト作成→パッケージ追加→エージェント実行までを3ステップで完了できます。各手順を順に見ていきましょう。

手順1：プロジェクトの作成

dotnet new console -n AgentQuickStart
cd AgentQuickStart

手順2：必要なパッケージを追加

dotnet add package Azure.AI.OpenAI
dotnet add package Azure.Identity
dotnet add package Microsoft.Agents.AI.OpenAI --prerelease

手順3：エージェントを作成して実行

以下のようなコードを Program.cs に記述します。

using Azure.Identity;
using Microsoft.Agents.AI;

var agent = new AzureOpenAIClient(
    new Uri("https://ai-agent-0529-resource.services.ai.azure.com/"), // 自身のAzureエンドポイント
    new AzureCliCredential()
)
.GetChatClient("gpt-4o") // モデル名
.CreateAIAgent(instructions: "あなたは優秀な雑談相手です。");

string result = await agent.RunAsync("こんにちは。元気ですか？");
Console.WriteLine(result);

この例ではAzure CLIの認証情報を使用していますが、AzureKeyCredential などを使って明示的にAPIキーを設定することも可能です。

Pythonで始めるクイックスタート

Pythonの手順はさらにシンプルで、pipでのインストールから2ステップで動きます。以下で実際のコマンドとコードを確認します。

手順1：インストール

pip install agent-framework
pip install azure-identity

手順2：エージェントを作成して実行

import asyncio
from agent_framework.foundry import FoundryChatClient
from azure.identity.aio import AzureCliCredential

async def main():
    async with (
        AzureCliCredential() as credential,
        FoundryChatClient(credential=credential).as_agent(
            instructions="You are good at telling jokes."
        ) as agent,
    ):
        result = await agent.run("Tell me a joke about a pirate.")
        print(result.text)

if __name__ == "__main__":
    asyncio.run(main())

実行結果（例）：

実行結果

((.venv) )  AgentQuickStart % python main.py                                                                      
Why did the pirate go to the gym?  

To improve his **ARRR-ms**! 🏴‍☠️

より実践的なステップ

基本エージェントを動かしたあとは、ツール追加・セッション管理・Workflow設計・DevUI活用という4つの拡張方向があります。次のリストで概要を見ていきましょう。

• ツールの追加：通常のPython関数を tools=[...] に渡すか、@tool デコレーターを付けてエージェントから呼び出し可能に
• セッションの管理：複数ターンのやりとりを AgentSession で管理（1.0 RCで AgentThread から改称）
• Workflowの定義：複数のエージェント・関数を連携して処理を自動化
• DevUIの利用：エージェントとワークフローの実行結果を可視化・確認可能（起動コマンドや環境構築は後述）

今回はチャット風に続けられるように調整もしました。

import asyncio
from agent_framework.foundry import FoundryChatClient
from azure.identity.aio import AzureCliCredential

async def main():
    async with (
        AzureCliCredential() as credential,
        FoundryChatClient(credential=credential).as_agent(
            instructions="あなたはフレンドリーなAIアシスタントです。"
        ) as agent,
    ):
        print("💬 AI Agent Chat (終了するには 'exit' と入力)\n")

        while True:
            user_input = input("👤 You: ")
            if user_input.lower() == "exit":
                break

            result = await agent.run(user_input)
            print("🤖 Agent:", result.text, "\n")

if __name__ == "__main__":
    asyncio.run(main())

そうするとより、AIとの対話が続けられます。

対話イメージ

よくあるエラーと対処

主要なエラーは3パターンに大別できます。原因の切り分けから解決策まで、以下の表で整理しました。

よくあるエラーとその対処法を以下にまとめます。

このような場合には、一つずつ原因を切り分けて確認することが重要です。
ChatGPTに聞くのも有効です。

Semantic Kernelからの移行ガイド

上図のように、Semantic KernelはAgent Frameworkへ統合される位置づけで、新規のagenticアプリではAgent Frameworkが第一候補となります。

Semantic Kernel（SK）とは、Microsoftが開発した軽量なAIオーケストレーションフレームワークで、プラグインやプロンプト連携に優れた構造を持つOSSです。
Agent Frameworkは、そのSKの長所を継承しつつ、エージェント中心の構成・型安全なワークフロー・複雑なタスク分解に対応した次世代フレームワークとして設計されています。

この章では、SKユーザーがAgent Frameworkへスムーズに移行できるよう、構成の違いや具体的なコード対応例を交えて解説します。

なぜ移行が必要か

SKの4つの課題が、Agent Frameworkでどのように改善されたのかを上図で俯瞰できます。以下の対比表も合わせて確認してください。

Semantic Kernelは柔軟でシンプルな設計が魅力でしたが、以下の課題が存在していました。

Microsoft自身が新規のagenticアプリにおける次世代の中核候補としてAgent Frameworkを位置づけており、今後の機能拡張の主軸になる方向で案内されています。

主な違いと対応関係

6つの主要機能について、SKとAgent Frameworkの呼び方と実装の対応関係を以下の表で整理しました。

以下に、SKからAgent Frameworkへの移行で想定される機能の対応関係を示します。

表の通り、SKで分散していたPlugin／Plannerといった概念がAgent FrameworkではAgent／Workflowという統一された抽象に整理されています。既存のSK資産を段階的にマッピングしていくのが現実的です。

AutoGenからの移行ガイド

上図は、AutoGenのマルチエージェント設計をAgent Frameworkが継承しつつ、型安全性やセッション管理を加えた進化の構図です。

AutoGenは、マルチエージェントによるタスク分担と自律的な対話を設計できるPythonライブラリであり、ChatGPT APIやツール呼び出しを組み合わせたエージェント設計が特徴です。
一方、Microsoft Agent Framework は、AutoGenの柔軟なマルチエージェント設計を継承しつつ、型安全性・セッション管理・ワークフロー構造・ミドルウェア制御といったエンタープライズ用途を見据えた仕組みに発展しています。

なぜAutoGenから移行するのか

主な5項目について、AutoGenの設計とAgent Frameworkの設計を比較整理しました。以下の表も合わせて確認してください。

AutoGenはPoCや研究用途に最適なフレームワークですが、Agent FrameworkはAzureエコシステムと統合可能な商用グレードの構造と開発体験を提供します。

主な機能マッピングと違い

6つの機能カテゴリについて、AutoGen固有のクラス名とAgent Frameworkの対応APIを以下の表で対比しました。

マルチエージェント構成の違いと移行

AutoGenの暗黙的な進行と、Agent FrameworkのWorkflowによる明示的な構造化を対比する形で示しました。以下、具体的なコードで違いを確認します。

AutoGenのGroupChat

from autogen import GroupChat, AssistantAgent

agents = [AssistantAgent(name="Agent1"), AssistantAgent(name="Agent2")]
group = GroupChat(agents=agents, messages=[], max_round=5)
group.run()

Agent FrameworkでのWorkflow構成

from agent_framework.workflow import WorkflowBuilder, AgentNode

workflow = WorkflowBuilder() \
    .with_node("agent1", AgentNode(agent1)) \
    .with_node("agent2", AgentNode(agent2)) \
    .with_connection("agent1", "agent2") \
    .build()

result = await workflow.run("はじめましょう")

Agent FrameworkのWorkflowでは、ノードの型定義、順序制御、チェックポイント、並列化などの制御が可能です。

移行時の注意点

移行時に見落としやすい4つのポイントを上図で整理しました。以下で個別に確認していきます。

• GroupChatによる自動進行は Agent FrameworkではWorkflowで明示的に構築する必要があります。
• FunctionToolの柔軟性は高い反面、Agent Frameworkではスキーマ定義が必須となるため、関数の見直しが必要です。
• AutoGen特有の応答調停やリトライ戦略は、Agent FrameworkではMiddlewareを通じて実装可能です。
• ロギング・可視化の導入はDevUIやOpenTelemetryで大幅に簡略化されます。

Microsoft Agent Frameworkの料金

Microsoft Agent Frameworkはオープンソースとして提供されており、無料で利用可能です。

上図のように、フレームワーク本体は無料で使えますが、実際の運用ではLLMやホスティングのコストが発生する点に留意が必要です。

ただし、Azure AI Foundryなどのクラウドサービスと連携して利用する場合は、それらのサービスに対して別途課金が発生する可能性があります。Agent Framework自体は無料ですが、利用するLLM（Azure OpenAI、OpenAIなど）やホスティングサービスのコストは別途計上が必要です。

最新情報は、Microsoft Agent Framework公式リポジトリをご覧ください。

Microsoft Agent FrameworkとResponsible AIの組み合わせ運用

上図の通り、Agent Frameworkは「安全な土台」を提供する存在であり、具体的なガバナンス機能はAzure AI FoundryやContent Safetyなど周辺サービスとの組み合わせで構築します。

Microsoftの公式ドキュメントでは、Agent Frameworkは「安全なエージェントを構築するためのbuilding blocksを提供する」フレームワークと位置づけられており、実際の mitigations（攻撃対策・PII制御・逸脱監視など）は開発者側の設計責任となります。以下では、Agent FrameworkにAzure AI FoundryやAzure AI Content Safetyを組み合わせて実現できる、代表的なガバナンス機能を紹介します。

タスク遵守の監視（Task Adherence）

Agent Frameworkのミドルウェアと Foundry Evaluators を組み合わせることで、エージェントの行動がタスクから逸脱していないかを常時監視できます。

エージェントが割り当てられたタスクから逸脱していないかを監視する考え方で、Agent Frameworkのミドルウェアや Foundry の Evaluators を組み合わせることで、タスク焦点の維持と予期しない動作の検知が可能になります。意図しない目的でツールを呼び出すケースの抑制にも有効です。

プロンプトインジェクション対策（Prompt Shields with Spotlighting）

上図のように、入力検査→Prompt Shields→Spotlighting→監査ログという4層の防御設計で、不正な指示埋め込みを段階的に検知・遮断します。

プロンプトインジェクション攻撃への防御は、**Azure AI Content Safetyが提供する「Prompt Shields」**として別サービス側で提供される機能です。Agent Frameworkから Foundry / Content Safety を呼び出して組み込むことで、悪意あるユーザーが巧妙に指示を埋め込もうとする試みを検出できます。Spotlighting機能により、検出された攻撃の詳細情報が得られ、セキュリティ監視に活用できます。

PII検出（PII Detection）

入力データがFoundry／Azure OpenAIのコンテンツフィルタを通過する過程で、個人情報が自動的にマスキングされる流れを示しています。

PII（個人識別情報）の検出は、Azure AI Foundry／Azure OpenAIのコンテンツフィルタ機能として提供されており、Agent Framework本体の標準機能ではありません。エージェント経由で Foundry / OpenAI のフィルタを呼び出すことで、名前・メールアドレス・クレジットカード番号などの機密データがエージェントの出力や記録に含まれないように制御でき、GDPR等の規制要件への対応に役立てられます。

以上のように、Agent Frameworkは安全性実装の土台を提供する一方、実際のガバナンス対策は Foundry / Content Safety / Evaluators など周辺サービスと組み合わせて設計する必要があります。特に金融・ヘルスケア・法務といった規制が厳しい業界では、この組み合わせ運用の設計がAgent Framework導入可否の鍵となります。

開発・運用上のベストプラクティス

Microsoft Agent Frameworkは、高機能で柔軟な反面、設計や運用を誤ると応答遅延やコスト超過といった課題につながります。
この章では、エンタープライズ用途を想定した導入・運用の観点から、効果的に活用するためのベストプラクティスを紹介します。

ベストプラクティスは「設計／セキュリティ／パフォーマンス／チーム運用」の4軸で整理できます。以下で各軸の要点を掘り下げます。

設計上の留意点

責務の明確化・モデル選定・ツール化徹底という3ステップで、応答遅延とコスト超過を防ぎます。

1. エージェントの責務は明確に分ける

• 各エージェントには「専門性」を与える：例「商品説明役」「契約処理役」「リスク評価役」など
• 役割を曖昧にするとプロンプトが冗長化し、応答の一貫性が下がる
• ワークフロー上で「どこで・なぜ・何を処理するか」を明示する設計が重要

2. LLMモデルと出力のバランス設計

• 出力品質が不要に高い場合、モデルコスト・応答時間が無駄に増える
• タスク内容に応じて gpt-3.5 / gpt-4 / gpt-4o などを使い分ける
• Tool使用時はモデルの選定以上に引数スキーマ設計と関数粒度が鍵になる

3. 再利用可能なツール化を徹底

• 共通処理（検索、日付処理、ステータス分類など）は関数として切り出し、ツール登録
• なるべく副作用のない関数設計とすることで、テストと再利用が容易に

セキュリティとデータ保護

入力最小化・リージョン/権限分離・DevUIアクセス制御という3層で、機密情報を保護する設計を示しました。

1. LLMへの入力データは最小限に

• 機密データ・個人情報は原則マスキング、必要最小限の情報のみを送信
• 特に AgentSession（旧 AgentThread）に履歴が蓄積される場合、データスコープに注意

2. Azure環境での利用時はリージョン制限と権限分離を徹底

• Azure OpenAIはリージョン制御が可能なため、機密情報が国外流出しないように設計
• クライアントID/シークレットはマネージドIDやKey Vaultでの分離管理を推奨

3. DevUIのアクセス制御

• DevUIは非常に便利な反面、操作権限とログの機密性に注意が必要
• 実運用環境では閲覧ログの制御・IP制限を含む導入設計が望ましい

実行パフォーマンスの最適化

並列化→ストリーミング→チェックポイント復元という3点で、体感速度と堅牢性の両立を図ります。

1. 並列ノード設計の活用

• GraphFlowでは、独立処理は並列実行することで応答時間を短縮できる
• APIコール数は増えるが、実行時間の観点では有効

2. ストリーミング出力の活用

• 応答生成をストリーミングで受け取ることで、UX向上と早期フィードバックが可能に
• 特にユーザー向けUIがある場合は積極活用が推奨される

3. チェックポイントとセッション復元

• エージェント／ワークフローが長時間化する場合、中断復元に備えてチェックポイント設計を入れる
• 再試行や障害復旧時の冗長化にも有効

チーム開発・運用のための設計工夫

観測基盤統合・ステージング分離・プロンプトGit管理という3本柱で、チーム開発の品質と速度を両立させます。

1. DevUIとテレメトリの統合

• DevUIは以下のような作業に役立つ：

  • ステップ実行の可視化
  • エラー発生箇所の追跡
  • Tool呼び出しログの確認

• OpenTelemetryと連携すれば、Prometheus/Grafanaとの統合も可能

2. ステージング環境の構築

• 本番と検証用でモデルキー・エージェント構成を分離
• ステージング環境には負荷試験用のテストユーザーとダミーデータを利用

3. プロンプト変更とバージョン管理

• エージェントのプロンプトはGitで管理し、変更履歴と精度評価を記録
• プロンプトにコメントを付けて、「意図」をチームで共有する

Microsoft Agent Framework導入時の注意点と制限事項

企業導入時に押さえるべき主要な注意点を上図で俯瞰できます。以下で個別に深掘りします。

Microsoft Agent Frameworkは、AIエージェント開発の強力な基盤ですが、特に企業での導入を検討する上で、把握しておくべき重要な注意点と制限事項があります。ここでは、特に注意が必要なポイントをご説明します。

1.0到達済みだが一部機能はpreview段階

本体はGA済みでも、Responsible AI系の一部やサンプル統合などpreview段階が残っている点が上図で整理されています。

Agent Frameworkは2025年10月1日にPublic Previewとして発表され、2026年4月3日に**Version 1.0（production-ready release）**へ到達しました。Microsoftは、GitHubリポジトリを通じて、開発者コミュニティからの継続的なフィードバックを受け付けています。

本体は1.0到達により安定版が提供されている一方、周辺機能の一部（Responsible AIの一部機能やサンプル統合など）はpreview段階のものが残っており、本番利用の際は対象機能ごとに提供状況を公式ドキュメントで確認する必要があります。RC以降はAPI命名の整理（AgentThread → AgentSession、create_agent → as_agent など）も行われているため、古いサンプルをそのまま流用する際にも注意が必要です。

サードパーティ連携におけるデータコンプライアンスの責任

Azure／Foundryの契約範囲と、外部API連携の自己責任範囲の境界線を上図で示しました。地理的制限・監視ログ・ガードレール・契約精査の4領域が開発者の責任範囲です。

Agent Frameworkを使用して、サードパーティのサーバーやエージェントと連携するアプリケーションを構築する場合、その実行は利用者の自己責任となります。

AIエージェントは自律的にツールを呼び出すことができますが、開発者が予期しない形で機密データがプロンプトに含まれ、組織のコンプライアンス境界や地理的境界の外（例：GDPRや国内法規制の管轄外にあるサーバー）に送信されるリスクがあります。

開発者は、エージェントが外部とどのようなデータを共有しているかを厳密に監視し、必要に応じてガードレールを実装して、機密データの外部送信を制御する仕組みを構築する必要があります。

AIエージェントの適用限界

自律判断や複雑な連携が必要な業務はAIエージェントが活きる領域ですが、ルール固定・単純処理は従来型プログラムの方が適切という線引きを上図で示しました。

定義済みのルールに厳密に従う必要があるタスクや、簡潔にプログラムできるタスクにAIエージェントを適用することは避けましょう。

これらのタスクにAIエージェントを使用すると、不必要なコストの発生、応答時間の遅延、そしてAIのハルシネーションによる不確実性といった問題を引き起こす可能性があります。

OSSフレームワークで構築したAgentを本番運用に載せるなら

Agent Frameworkで開発したプロトタイプは動く。問題はその先──権限管理、監査ログ、セキュリティチェックなしに本番環境へ展開できるか。

AI Agent Hubは、Agent Frameworkで構築したAgentを含め、全社のAIエージェントを1つのダッシュボードで一元管理できるエンタープライズAI基盤です。開発基盤を問わず、本番運用に必要なガバナンス機能を後付けで追加できます。

• Agent Framework製AgentもCopilot Studio製Agentも管理は1つ
  OSSフレームワークで構築したAgentも、Copilot Studioのノーコード製Agentも、1つの管理ダッシュボードで実行ログ・アクセス権限・セキュリティチェックを統合管理できます。
  
  
• Agentの開発に集中し、共通機能は基盤に任せる
  認証・ログ・Teams連携・承認フロー・エラーハンドリングなど共通処理は基盤が提供。業務固有のロジックだけを追加すれば新しいAgentが完成します。
  
  
• 使い慣れたMicrosoft環境をそのまま活用
  Teamsなど既存のMicrosoftツールの延長でAIエージェントが動作。新しいツールの学習コストはゼロです。
  
  
• データは100%自社テナント内に保持
  AIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、設計から運用まで伴走支援します。まずは無料の資料で、自社の業務にどう活用できるかご確認ください。

OSSエージェントを本番運用に直結

開発の先にある運用・ガバナンスを一元管理

Microsoft Agent Frameworkで構築したAIエージェントを、実行ログ・権限管理・セキュリティチェックつきで本番環境に展開。開発基盤を問わず、全Agentを1つのダッシュボードで統合管理できます。

▶ 無料で資料をダウンロード

今後の展望とまとめ

このようにMicrosoft Agent Frameworkは、単なるエージェント開発フレームワークを超え、今後のMicrosoft AIエコシステム全体に統合されていく中核的な技術要素です。
本章では今後の進化の方向性と、本記事の総まとめを行います。

今後の統合先と進化の方向性

1. Copilot Studioとの連携

Copilot Studioは、ノーコードで業務用Copilot（生成AIアプリ）を構築できるMicrosoftの製品です。Agent Frameworkは、Copilot StudioおよびM365 Agents SDKとの連携経路がすでに公式ドキュメントで案内されており、今後さらに相互運用が進む方向にあります。

• Agent Frameworkで構築したエージェントを、Copilot Studio側のフローから呼び出す構成が可能
• M365 Agents SDKとの組み合わせにより、Microsoft 365のワークフローへエージェントを組み込める
• 企業内アプリ（Power Platform、Dataverse等）との組み合わせも視野に入る

2. Azure AI Foundryとの連携

Azure AI Foundryは、エンタープライズ向けのAIアプリ開発基盤です。Agent Frameworkは、Foundry Agent Serviceとランタイムを共有する位置づけで公式ブログでも紹介されており、今後さらに深い相互運用が進むと案内されています。

• Foundry Agent Serviceとのshared runtimeを通じた、エージェント実行環境の統合
• Agent経由で社内SaaSやAPIを操作する「AIオーケストレーション層」としての利用
• RAG（検索拡張型生成）やベクトル検索との組み合わせも現実的な選択肢

3. オープンソースとしての発展

Agent FrameworkはMITライセンスで公開されており、公式リポジトリを軸にコミュニティ主導の改善や拡張も進んでいます。公開済みの一次情報からは、以下のような方向性が継続して強化されている点が読み取れます。

• Workflowによる複数エージェント連携・グラフ構造のオーケストレーション
• 複数プロバイダー（Azure OpenAI、OpenAI、Azure AI Foundry等）への対応
• Copilot StudioやFoundry Agent Serviceとの相互運用の深化

これ以外の将来要素（ツールスキーマ標準化、自然言語からのワークフロー自動生成、他社LLMやオンプレ環境対応など）は、今後の可能性として考えられる例であり、現時点の公式ロードマップで具体的に確約されているものではありません。

Agent Frameworkは、単なるAPIラッパーやチャットボット開発キットではなく、業務システムやエンタープライズAI統合の「基礎構造」として機能する可能性を秘めた存在です。
将来的にAIが「操作対象」でなく「自律的な業務担い手」となる世界において、こうしたフレームワークは重要な役割を果たすことになります。

本記事が、Agent Frameworkの技術的理解や導入の一助となれば幸いです。

AI総合研究所は、企業のAIエージェント開発・内製化支援を行っております。ご相談・お問い合わせはこちらからお願いいたします。