Microsoft Foundry Agent Service SDK移行方法｜Responses・Invocations置換表

旧azure-ai-agentserver-agentframeworkやazure-ai-agentserver-langgraphを更新したあと、ModuleNotFoundError、importエラー、起動メソッドの欠落が発生する場合、原因は単純なバージョン不一致ではありません。初期プレビューで使われていたフレームワーク別adapterが廃止され、ResponsesまたはInvocationsというプロトコル単位のライブラリへ構成が変更されたためです。

解決策は、旧adapterの新しいimport先を探すことではありません。Microsoft Agent Frameworkではagent-framework-foundry-hostingのResponsesHostServerを使用し、LangGraphや独自実装ではResponsesAgentServerHostまたはInvocationAgentServerHostへエントリーポイントを書き換えます。.NETでは、旧Azure.AI.AgentServer.AgentFrameworkをAzure.AI.AgentServer.ResponsesまたはAzure.AI.AgentServer.Invocationsへ置き換えます。Microsoftはこの移行方法を公式に公開しています。(Microsoft Learn)

また、初期プレビューのホスティングバックエンドから新しいバックエンドへの移行は自動ではありません。旧バックエンド上の既存デプロイは2026年8月20日までのサポートとされているため、対象環境ではパッケージ更新だけでなく再デプロイまで必要です。(Microsoft Learn)

azure-ai-agentserver-agentframework／langgraph廃止対応の結論

今回の変更で最も重要なのは、パッケージの分割基準が変わった点です。

従来は、Agent Framework用、LangGraph用というように、利用するフレームワークごとのadapterが用意されていました。新しい構成では、フレームワークではなく、外部に公開するHTTPプロトコルによってライブラリを選びます。

旧構成
Agent Framework／LangGraph
        ↓
フレームワーク専用adapter
        ↓
Hosted Agent

新構成
Agent Framework／LangGraph／独自実装
        ↓
ResponsesまたはInvocationsプロトコル
        ↓
Hosted Agent

そのため、次のような対応は正しくありません。

# 旧パッケージを最新版へ更新すれば動く、という考え方
from azure.ai.agentserver.agentframework import from_agent_framework

azure-ai-agentserver-agentframework自体が移行先ではないため、import文と起動処理を新しいホスト方式へ変更する必要があります。

旧パッケージからResponses・Invocationsへの置換表

本記事で扱う公式移行表の基準バージョンは、Pythonのazure-ai-agentserver-core 2.0.0b1、.NETのAzure.AI.AgentServer.Responses 1.0.0-beta.1、Azure.AI.AgentServer.Invocations 1.0.0-beta.1です。

言語・構成	旧パッケージ／旧方式	新しいパッケージ／方式	主な起動方法
Python共通基盤	`azure-ai-agentserver-core`旧世代	`azure-ai-agentserver-core 2.0.0b1`世代	通常はプロトコルパッケージから自動導入
Python Agent Framework	`azure-ai-agentserver-agentframework`	`agent-framework-foundry-hosting`	`ResponsesHostServer(agent).run()`
Python LangGraph	`azure-ai-agentserver-langgraph`	`azure-ai-agentserver-responses`	`ResponsesAgentServerHost`
Python独自会話エージェント	旧Coreや独自adapter	`azure-ai-agentserver-responses`	`ResponsesAgentServerHost`
Python Webhook・任意JSON	旧Coreや独自HTTP処理	`azure-ai-agentserver-invocations`	`InvocationAgentServerHost`
.NET共通基盤	`Azure.AI.AgentServer.Core`旧世代	`Azure.AI.AgentServer.Core 1.0.0-beta.21`	Responses／Invocationsの依存関係として導入
.NET Agent Framework	`Azure.AI.AgentServer.AgentFramework`	`Azure.AI.AgentServer.Responses 1.0.0-beta.1`または`Azure.AI.AgentServer.Invocations 1.0.0-beta.1`	Framework拡張または各Protocol Server
.NET旧モデル定義	`Azure.AI.AgentServer.Contracts`	削除し、Responsesへ統合	`using Azure.AI.AgentServer.Responses`

公式移行表では、Pythonのazure-ai-agentserver-coreは引き続き必要とされていますが、ResponsesやInvocationsの依存関係として自動的にインストールされる構成へ変わっています。.NETでもResponsesとInvocationsがCoreへ依存するため、通常はCoreだけを先に個別導入する必要はありません。(Microsoft Learn)

なお、2.0.0b1や1.0.0-beta.1は公式移行表で示された置換開始時点のバージョンです。プレリリース版は更新が続いており、Pythonのパッケージレジストリにも後続betaが公開されています。新規構築では依存関係が解決する組み合わせを使用し、既存環境を再現する場合だけロックファイルや明示的なバージョン指定で固定するのが安全です。(PyPI)

ResponsesとInvocationsのどちらを選ぶべきか

旧adapterを削除したあと、最初に決めるべきなのは利用するプロトコルです。

判断項目	Responses	Invocations
主な用途	チャット、会話型エージェント	Webhook、バッチ処理、任意JSON API
エンドポイント	`/responses`	`/invocations`
リクエスト形式	OpenAI Responses API互換	実装側で自由に定義
ストリーミング	SSEに対応	実装方式に応じて制御
会話履歴	Responsesの履歴・conversationを利用可能	プラットフォームは会話履歴を自動保存しない
長時間処理	backgroundモードなどを利用	取得・キャンセル用ハンドラーを実装可能
Pythonホスト	`ResponsesAgentServerHost`	`InvocationAgentServerHost`
Agent Framework向け	基本はこちらから開始	非会話型や独自形式の場合に検討

一般的なチャットエージェント、ストリーミング応答、OpenAI互換クライアントとの接続が必要ならResponsesを選びます。

一方、次のような処理はInvocationsが適しています。

外部サービスから任意のJSONを受け取るWebhook
会話形式ではないドキュメント変換やデータ処理
独自の入力・出力スキーマを維持したいAPI
長時間処理の状態取得やキャンセルが必要な処理

Microsoftのドキュメントでも、多くの会話エージェントではResponsesから始め、カスタムJSONや非会話型処理ではInvocationsを使う方針が示されています。(Microsoft Learn)

PythonのAgent FrameworkをResponsesHostServerへ移行する

Python版Microsoft Agent Frameworkでは、旧from_agent_framework()を新しい名前へ置き換えるだけでは不十分です。クライアント、Agentクラス、ツールデコレーター、起動方法も更新します。

パッケージを入れ替える

旧adapterを削除します。

python -m pip uninstall -y azure-ai-agentserver-agentframework

Agent FrameworkとFoundryホスティング連携を導入します。

python -m pip install -U \
  agent-framework \
  agent-framework-foundry-hosting \
  azure-identity \
  python-dotenv

Responsesのプロトコル処理は、agent-framework-foundry-hostingを通じて利用します。azure-ai-agentserver-coreだけを入れても、Agent Frameworkとの接続部分は復元されません。

importと起動方法を変更する

旧コードは次のような構成です。

from azure.ai.agentserver.agentframework import from_agent_framework
from agent_framework import ChatAgent
from agent_framework.azure import AzureAIAgentClient

agent = ChatAgent(
    chat_client=client,
    instructions="You are a helpful assistant.",
)

from_agent_framework(agent).run()

新しい構成では、FoundryChatClient、Agent、ResponsesHostServerを使用します。

import os

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from agent_framework_foundry_hosting import ResponsesHostServer
from azure.identity import DefaultAzureCredential

client = FoundryChatClient(
    project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
    credential=DefaultAzureCredential(),
)

agent = Agent(
    client=client,
    instructions="You are a helpful assistant.",
    default_options={"store": False},
)

server = ResponsesHostServer(agent)
server.run()

主な置換点は次のとおりです。

旧API	新API
`AzureAIAgentClient`	`FoundryChatClient`
`ChatAgent`	`Agent`
`@ai_function`	`@tool`
`from_agent_framework(agent).run()`	`ResponsesHostServer(agent).run()`
Agent側での会話保存	ホスティング側の履歴管理に合わせて`store: False`を設定

ツール関数を使っている場合は、@ai_functionを@toolへ変更します。

from agent_framework import tool

@tool(approval_mode="never_require")
def get_weather(location: str) -> str:
    return f"{location}の天気は晴れです。"

Agent Frameworkのエージェント定義や指示、ツール処理の大部分は維持できますが、ホストとの接続部分はResponsesHostServerへ変更する必要があります。(Microsoft Learn)

LangGraphをResponsesAgentServerHostへ移行する

LangGraphでは、旧azure-ai-agentserver-langgraphが廃止されています。グラフの定義を作り直す必要はありませんが、from_langgraph(graph).run()を明示的なResponsesハンドラーへ変更します。

パッケージを入れ替える

python -m pip uninstall -y azure-ai-agentserver-langgraph

python -m pip install -U \
  azure-ai-agentserver-responses \
  langgraph \
  langchain-openai \
  azure-identity \
  httpx

azure-ai-agentserver-responsesをインストールすると、対応するazure-ai-agentserver-coreが依存関係として導入されます。(PyPI)

起動部分を書き換える

旧構成は次のようなコードです。

from azure.ai.agentserver.langgraph import from_langgraph

graph = create_react_agent(llm, tools=tools)

if __name__ == "__main__":
    from_langgraph(graph).run()

新しい構成では、ResponsesAgentServerHostにハンドラーを登録します。

import asyncio

from azure.ai.agentserver.responses import (
    CreateResponse,
    ResponseContext,
    ResponsesAgentServerHost,
    TextResponse,
)
from langchain_core.messages import HumanMessage

app = ResponsesAgentServerHost()

@app.response_handler
async def handle(
    request: CreateResponse,
    context: ResponseContext,
    cancellation_signal: asyncio.Event,
):
    user_input = await context.get_input_text() or ""

    result = await graph.ainvoke(
        {"messages": [HumanMessage(content=user_input)]}
    )

    output = result["messages"][-1].content
    return TextResponse(
        context,
        request,
        text=output if isinstance(output, str) else str(output),
    )

if __name__ == "__main__":
    app.run()

この例は単一ターンの最小構成です。複数ターンの会話を維持する場合は、context.get_history()で履歴を取得し、HumanMessageやAIMessageへ変換してからLangGraphへ渡します。

移行後も、次の部分は基本的に維持できます。

create_react_agent()によるグラフ作成
LangGraphのツール定義
システムプロンプト
グラフ内のノードやエッジ
モデル呼び出し後の独自処理

変更対象は主に、入力の取得、履歴の変換、出力のResponses形式への変換、サーバー起動部分です。(Microsoft Learn)

独自実装ではプロトコルホストを直接使う

CrewAI、Semantic Kernel、独自オーケストレーターなど、専用adapterがない構成ではプロトコルライブラリを直接利用します。

Responsesの最小実装

import asyncio

from azure.ai.agentserver.responses import (
    CreateResponse,
    ResponseContext,
    ResponsesAgentServerHost,
    TextResponse,
)

app = ResponsesAgentServerHost()

@app.response_handler
async def handler(
    request: CreateResponse,
    context: ResponseContext,
    cancellation_signal: asyncio.Event,
):
    text = await context.get_input_text()
    return TextResponse(
        context,
        request,
        text=f"受信内容: {text}",
    )

if __name__ == "__main__":
    app.run()

TextResponseには文字列だけでなく、非同期イテレーターを渡してストリーミングできます。関数呼び出し、reasoning item、複数種類の出力などを細かく制御する場合は、ResponseEventStreamを使用します。

Invocationsの最小実装

from azure.ai.agentserver.invocations import InvocationAgentServerHost
from starlette.requests import Request
from starlette.responses import JSONResponse, Response

app = InvocationAgentServerHost()

@app.invoke_handler
async def handle(request: Request) -> Response:
    data = await request.json()

    return JSONResponse(
        {
            "message": f"{data['name']}さん、こんにちは"
        }
    )

if __name__ == "__main__":
    app.run()

InvocationsではStarletteのRequestとResponseを直接扱えるため、既存のWebhookや独自JSON APIを移植しやすい構成です。

長時間処理が必要な場合は、通常の呼び出しハンドラーに加えて、結果取得用のget_invocation_handlerやキャンセル用のcancel_invocation_handlerを実装できます。(Microsoft Learn)

.NETをResponses・Invocationsへ移行する

.NETでは、旧Azure.AI.AgentServer.AgentFrameworkやAzure.AI.AgentServer.Contractsをそのまま残すと、名前空間の競合、型の解決失敗、起動APIの欠落が発生しやすくなります。

パッケージ参照を変更する

Responsesを使う場合は、旧パッケージを削除してResponsesを追加します。

dotnet remove package Azure.AI.AgentServer.AgentFramework
dotnet remove package Azure.AI.AgentServer.Contracts

dotnet add package Azure.AI.AgentServer.Responses \
  --version 1.0.0-beta.1

Invocationsを使う場合は、代わりに次を追加します。

dotnet add package Azure.AI.AgentServer.Invocations \
  --version 1.0.0-beta.1

両方のプロトコルを同じサーバーで公開する場合だけ、両パッケージを追加します。

Azure.AI.AgentServer.ResponsesとAzure.AI.AgentServer.Invocationsは、Azure.AI.AgentServer.Coreへ依存します。そのため、通常はCoreを別途追加する必要はありません。公式移行ガイドでは、Coreの新しいパッケージ構成は1.0.0-beta.21から導入されています。(GitHub)

Responsesの起動方法を変更する

旧構成では、AgentServerApplication.RunAsync()へサービスを登録して起動していました。

await AgentServerApplication.RunAsync(
    new ApplicationOptions(
        ConfigureServices: services =>
            services.AddSingleton<IAgentInvocation, MyAgent>()
    )
);

新しいResponsesでは、次のように起動できます。

using Azure.AI.AgentServer.Responses;

ResponsesServer.Run<MyAgent>();

MyAgentはResponseHandlerを継承して実装します。

using Azure.AI.AgentServer.Responses;

public class MyAgent : ResponseHandler
{
    public override async IAsyncEnumerable<ResponseStreamEvent> CreateAsync(
        ResponseContext context,
        CreateResponse request,
        [System.Runtime.CompilerServices.EnumeratorCancellation]
        CancellationToken cancellationToken = default)
    {
        string input = await context.GetInputTextAsync(
            cancellationToken: cancellationToken
        );

        var stream = new ResponseEventStream(context, request);

        yield return stream.EmitCreated();

        await foreach (
            var item in stream.OutputItemMessage(
                $"受信内容: {input}",
                cancellationToken
            )
        )
        {
            yield return item;
        }

        yield return stream.EmitCompleted();
    }
}

単純なテキスト応答だけなら、より短く記述できます。

ResponsesServer.Run<TextResponse>(
    async context => "Hello!"
);

複数プロトコルを公開する

ResponsesとInvocationsを一つのプロセスで公開する場合は、AgentHostを構成します。

var builder = AgentHost.CreateBuilder();

builder.AddResponses<MyResponseHandler>();
builder.AddInvocations<MyInvocationHandler>();

var app = builder.Build();
app.Run();

新しい.NET構成では、Responsesのモデル型やイベント型がAzure.AI.AgentServer.Responsesへ統合されています。旧Azure.AI.AgentServer.Contracts.Generated.*のusingを残さず、名前空間も更新してください。(GitHub)

.NET版Agent FrameworkはResponsesHostServerを使わない

ResponsesHostServerはPython版Agent Frameworkのホストクラスです。.NET版Agent Frameworkでは、ASP.NET Core向けの拡張を利用します。

Responsesでは、主に次の拡張が使われます。

builder.Services.AddFoundryResponses();
app.MapFoundryResponses();

Invocationsでは、次の構成を使用します。

builder.Services.AddInvocationsServer();
builder.Services.AddScoped<InvocationHandler, MyInvocationHandler>();

app.MapInvocationsServer();

Pythonの移行例をそのままC#へ読み替えないことが重要です。(Microsoft Learn)

importや起動が失敗する主な原因

症状	主な原因	対処
`No module named azure.ai.agentserver.agentframework`	Agent Framework用adapterが削除された	`agent-framework-foundry-hosting`と`ResponsesHostServer`へ変更
`No module named azure.ai.agentserver.langgraph`	LangGraph用adapterが削除された	`azure-ai-agentserver-responses`と明示的なハンドラーへ変更
`cannot import name from_agent_framework`	旧起動APIを参照している	`ResponsesHostServer(agent).run()`へ変更
Coreを更新したらResponses型が見つからない	Coreが共通ホスト基盤へ縮小された	ResponsesまたはInvocationsパッケージからimport
`Azure.AI.AgentServer.Contracts`の型が見つからない	Contractsが廃止された	`Azure.AI.AgentServer.Responses`へ名前空間を変更
ローカル起動後に`/responses`が404	Responsesホストを起動していない	`ResponsesAgentServerHost`またはFrameworkホストを使用
`/invocations`が404	Invocationsホストが未登録	`InvocationAgentServerHost`などを起動
`/responses`へ任意JSONを送ると400	Responsesの入力形式と一致しない	`input`形式に直すかInvocationsを選ぶ
会話内容が次の要求に残らない	履歴IDやセッションIDを引き継いでいない	Responsesではconversation等、Invocationsでは`agent_session_id`を再利用
ローカルでは動くがFoundryで起動しない	`startupCommand`、ポート、環境変数が不一致	`azure.yaml`とエントリーポイントを確認
ツールやStorageへのアクセスが403	旧Project Managed Identityへ権限を付けている	専用のAgent Entra IDへRBACを付与

特にCoreの役割変更には注意が必要です。Pythonのazure-ai-agentserver-coreは、ヘルスチェック、終了処理、OpenTelemetry、ASGIサーバーなどの共通基盤を担当します。/responsesや/invocationsのエンドポイントは、それぞれのプロトコルパッケージが追加します。(PyPI)

azure.yamlのversionをパッケージバージョンと混同しない

移行時に失敗しやすいのが、次の3種類のバージョンを混同するケースです。

PythonやNuGetのパッケージバージョン
Responsesなどのエンドポイントプロトコルバージョン
Hosted Agentコンテナーのランタイムプロトコルバージョン

公式移行ガイドでは、旧ProtocolVersionRecordの"v1"をSemVer形式の"1.0.0"へ変更する例が示されています。一方、現在のazure.yaml作成ガイドでは、Hosted Agentのプロトコル例として2.0.0が使われています。コンテナープロトコル2.0.0では、要求ごとのユーザーコンテキストやx-agent-foundry-call-idの転送方法も変更されています。(Microsoft Learn)

現在の公式作成例は次の形式です。

services:
  my-agent:
    host: azure.ai.agent
    project: src/my-agent
    language: docker
    kind: hosted
    name: my-agent

    protocols:
      - protocol: responses
        version: 2.0.0

    startupCommand: python main.py

古いサンプルからversion: v1やversion: 1.0.0だけをコピーするのではなく、次の方法で現在の構成を生成するのが安全です。

azd ext install azure.ai.agents
azd ai agent init

そのうえで、生成されたazure.yaml、利用中のazd拡張、ホストライブラリの世代をそろえます。

また、旧agent.manifest.yamlや単独のagent.yamlは非推奨となり、Hosted Agentの設定は一つのazure.yamlへ統合される方向です。(Microsoft Learn)

ローカルで起動確認する方法

Responsesホストは、既定でポート8088を使用します。

python main.py

別のターミナルからResponsesへ送信します。

curl -X POST http://localhost:8088/responses \
  -H "Content-Type: application/json" \
  -d '{"input":"Hello"}'

Invocationsの場合は、実装したJSON形式を送信します。

curl -X POST http://localhost:8088/invocations \
  -H "Content-Type: application/json" \
  -d '{"name":"Alice"}'

azdで構成したプロジェクトでは、次の方法でも確認できます。

azd ai agent run
azd ai agent invoke --local "Hello"

ローカル確認では、単にプロセスが終了しないことだけでなく、次の項目をチェックします。

/readinessが正常応答する
選択したプロトコルのエンドポイントが404にならない
ストリーミングが途中で切れない
複数ターンで履歴またはセッションが維持される
Ctrl+CやSIGTERMで正常終了する
Application Insightsを使う場合にトレースが出力される

Hosted Agentのホストは既定で0.0.0.0のポート8088へバインドし、Coreがreadinessや終了処理を提供します。(PyPI)

デプロイ後も旧呼び出し方法を残さない

ホスト側を移行しても、クライアント側が旧agent_reference方式のままだと正常に呼び出せません。

旧方式では、共有プロジェクトエンドポイントに対して、リクエスト本文のextra_bodyでエージェント名を指定していました。

openai_client = project.get_openai_client()

response = openai_client.responses.create(
    input="Hello",
    extra_body={
        "agent_reference": {
            "name": "my-agent",
            "type": "agent_reference",
        }
    },
)

新しい方式では、SDK作成時にエージェント名を指定します。

openai_client = project.get_openai_client(
    agent_name="my-agent"
)

response = openai_client.responses.create(
    input="Hello"
)

print(response.output_text)

各エージェントには専用エンドポイントが割り当てられるため、旧agent_referenceを送る必要はありません。(Microsoft Learn)

実務で安全に移行する手順

現在のパッケージとimportを洗い出す

次の文字列をリポジトリ全体で検索します。

azure-ai-agentserver-agentframework
azure-ai-agentserver-langgraph
from_agent_framework
from_langgraph
Azure.AI.AgentServer.AgentFramework
Azure.AI.AgentServer.Contracts
AgentServerApplication.RunAsync
agent_reference
version: v1

依存関係ファイルだけでなく、Dockerfile、起動スクリプト、CI/CD、テストコードも確認します。

ResponsesかInvocationsかを決める

チャットやストリーミングならResponses、任意JSONやWebhookならInvocationsを選びます。

「旧パッケージがAgent FrameworkだったからResponses」という決め方ではなく、外部クライアントが必要とするHTTP契約で判断します。

旧adapterを削除する

旧adapterと新プロトコルパッケージを同居させると、名前空間や依存バージョンの競合原因になります。移行用ブランチで旧パッケージを明示的に削除してください。

importと起動コードを同時に変更する

パッケージだけを先に更新すると、旧importの時点でアプリが停止します。

次の三つを同じ変更単位で修正します。

パッケージ参照
importまたはusing
サーバー起動方法

azure.yamlを現在の形式へ更新する

古いmanifestを手作業で部分修正するより、azd ai agent initで現在の構成を生成し、既存設定を移植する方が安全です。

startupCommandが実際のエントリーポイントと一致しているかも確認します。

ローカルでプロトコル単体をテストする

Foundryへデプロイする前に、curlまたは統合テストで/responses、/invocationsを直接呼び出します。

この段階で404になる場合、Azure側ではなくホスト登録や起動コードの問題です。

再デプロイ後に権限と呼び出し先を確認する

新しいHosted Agentでは、エージェントごとに専用のEntra IDと専用エンドポイントが作成されます。

Storage、Key Vault、Search、Toolboxなどへアクセスする場合は、旧Project Managed Identityではなく、デプロイされたAgentのIDへ必要なRBACを付与します。バージョン状態がactiveになったことを確認してからトラフィックを切り替えてください。(Microsoft Learn)

まとめ

旧azure-ai-agentserver-agentframeworkやazure-ai-agentserver-langgraphでimport・起動が失敗する場合、同名adapterの新バージョンを探しても解決しません。フレームワーク別adapterから、ResponsesまたはInvocationsのプロトコルライブラリへ移行する必要があります。

最小限の判断基準は次のとおりです。

現在の構成	取るべき対応
Python Agent Framework	`agent-framework-foundry-hosting`と`ResponsesHostServer`へ変更
Python LangGraph	`azure-ai-agentserver-responses`と`ResponsesAgentServerHost`へ変更
独自の会話エージェント	`ResponsesAgentServerHost`を使用
Webhook・任意JSON処理	`InvocationAgentServerHost`を使用
.NET旧AgentServer	`Azure.AI.AgentServer.Responses`または`Invocations`へ変更
旧Contracts参照	削除してResponses名前空間へ変更

まず依存関係ファイルとエントリーポイントを確認し、旧adapterを削除してください。その後、必要なプロトコルを一つ選び、import、起動処理、azure.yaml、クライアントの呼び出し先をまとめて更新することが、最も手戻りの少ない移行方法です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Foundry Agent Service SDK移行方法｜Responses・Invocations置換表

azure-ai-agentserver-agentframework／langgraph廃止対応の結論

旧パッケージからResponses・Invocationsへの置換表

ResponsesとInvocationsのどちらを選ぶべきか

PythonのAgent FrameworkをResponsesHostServerへ移行する

パッケージを入れ替える

importと起動方法を変更する

LangGraphをResponsesAgentServerHostへ移行する

パッケージを入れ替える

起動部分を書き換える

独自実装ではプロトコルホストを直接使う

Responsesの最小実装

Invocationsの最小実装

.NETをResponses・Invocationsへ移行する

パッケージ参照を変更する

Responsesの起動方法を変更する

複数プロトコルを公開する

.NET版Agent FrameworkはResponsesHostServerを使わない

importや起動が失敗する主な原因

azure.yamlのversionをパッケージバージョンと混同しない

ローカルで起動確認する方法

デプロイ後も旧呼び出し方法を残さない

実務で安全に移行する手順

現在のパッケージとimportを洗い出す

ResponsesかInvocationsかを決める

旧adapterを削除する

importと起動コードを同時に変更する

azure.yamlを現在の形式へ更新する

ローカルでプロトコル単体をテストする

再デプロイ後に権限と呼び出し先を確認する

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Foundry Agent Service SDK移行方法｜Responses・Invocations置換表

azure-ai-agentserver-agentframework／langgraph廃止対応の結論

旧パッケージからResponses・Invocationsへの置換表

ResponsesとInvocationsのどちらを選ぶべきか

PythonのAgent FrameworkをResponsesHostServerへ移行する

パッケージを入れ替える

importと起動方法を変更する

LangGraphをResponsesAgentServerHostへ移行する

パッケージを入れ替える

起動部分を書き換える

独自実装ではプロトコルホストを直接使う

Responsesの最小実装

Invocationsの最小実装

.NETをResponses・Invocationsへ移行する

パッケージ参照を変更する

Responsesの起動方法を変更する

複数プロトコルを公開する

.NET版Agent FrameworkはResponsesHostServerを使わない

importや起動が失敗する主な原因

azure.yamlのversionをパッケージバージョンと混同しない

ローカルで起動確認する方法

デプロイ後も旧呼び出し方法を残さない

実務で安全に移行する手順

現在のパッケージとimportを洗い出す

ResponsesかInvocationsかを決める

旧adapterを削除する

importと起動コードを同時に変更する

azure.yamlを現在の形式へ更新する

ローカルでプロトコル単体をテストする

再デプロイ後に権限と呼び出し先を確認する

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル