Microsoft Agent Framework Agent Harnessの本番移行手順｜state・telemetry・OpenTelemetryを統一する

Preview版で作ったAgent HarnessをGA runtimeへ移し、local・container・Foundryのどこで動かしても同じ観測性を保つには、単純なパッケージ更新だけでは不十分です。結論として、Agent Harness本体を安定版へ固定し、tool・state・telemetryの契約を回帰テストしたうえで、OpenTelemetryの出力経路をOTLP中心に共通化する必要があります。

特に重要なのは、Agent HarnessのGA化とFoundry Hosted Agentsの提供状態を分けて考えることです。Microsoftの発表ではAgent Harnessはstable releaseと位置付けられていますが、Microsoft LearnではFoundry Hosted Agentsは現在もpreviewと明記されています。そのため、Harness runtimeのGA移行と、Foundryへのホスティング移行は別リリースに分けるのが安全です。(Microsoft for Developers)

Azure Update ID 563546は移行を始めるきっかけになります。ただし、公開情報から旧preview runtimeの強制停止日や自動移行日は確認できません。公式発表を待つだけでなく、自社で移行期限と完了条件を定めることが重要です。(Microsoft Azure)

結論：GA runtime移行は3つの作業に分ける

Agent Harnessの本番移行は、次の3段階に分けます。

runtimeの移行：preview依存をGAパッケージへ置き換え、バージョンを固定する
contractの検証：tool、state、telemetryの互換性をテストする
実行環境の切替：local、container、Foundryの差を設定とadapterへ閉じ込める

Agent Harnessには、tool呼び出し、履歴保存、context compaction、todo管理、plan／executeモード、file memory、承認フロー、OpenTelemetry、Web検索などが組み込まれています。便利な一方、preview版や独自実装から移行すると、これらの既定機能が意図せず有効になる可能性があります。(Microsoft Learn)

したがって、「ビルドが通った」「応答が返った」だけでは移行完了とは判断できません。ツールの副作用、セッション再開、トレースのつながりまで確認する必要があります。

Agent HarnessのGA化とFoundry Hosted Agentsは別の話

関連コンポーネントの状態を整理すると、次のようになります。

対象	本番移行での扱い	確認ポイント
Microsoft Agent Framework本体	GA／stableを利用	preview、RC、betaの依存が残っていないか
Agent Harness	GAパッケージへ移行	既定のtool、state、telemetry動作を再確認
OpenTelemetry	共通の観測契約として利用	exporter、resource属性、sampling、秘匿化
自前のcontainer基盤	本番候補	durable state、identity、scale-out、shutdown処理
Foundry Hosted Agents	previewとして個別判断	制限、料金、リージョン、SLA、session管理
FoundryのResponses／Invocations protocol	hosting adapterとして扱う	履歴を誰が管理するか

Microsoft Agent Framework 1.0は.NETとPythonのproduction-ready releaseとして公開され、安定APIと長期サポート方針が示されています。一方、Foundry Hosted AgentsはAgent Frameworkとは別にpreview扱いです。(Microsoft for Developers)

つまり、Foundry Hosted Agentsの採用判断が終わっていなくても、Agent Harness本体のGA移行は先に進められます。

移行期限は公式日付ではなく、社内のリスクで決める

Azure Updateの告知だけでは、旧preview packageをいつまでに廃止すべきかまでは判断できません。実務では、次のように社内期限を設定します。

時点	実施すること
直ちに	preview依存の追加を停止し、現在の構成をlockする
次のスプリントまで	tool、state、telemetryのbaselineを取得する
次の通常リリースまで	GA runtimeをステージング環境へ展開する
次のモデル変更前	runtime移行を完了し、変更要因を分離する
本番切替後	旧runtimeを新規sessionに割り当てない
保持期間終了後	旧sessionとpreview依存を削除する

次の状態に当てはまる場合は、移行優先度を上げるべきです。

preview、rc、beta、--preを含む依存がある
sessionやtool状態をプロセス内メモリだけに保存している
agentとchat clientの両方でOpenTelemetryを有効にしている
productionでpromptやtool引数をそのままtraceへ記録している
clientから受け取ったservice session IDを検証せず再利用している
shell実行や書き込み系toolを自動承認している
runtimeとモデルを同時に更新しようとしている

移行前に固定すべき4つのcontract

移行対象はコードではなく、実行時の契約です。

contract	固定する内容	合格条件
tool contract	tool名、説明、引数schema、戻り値、error、承認条件	旧runtimeと同じ入力で同じ業務結果になる
state contract	session ID、履歴、provider state、file、TTL、schema version	再起動後も正しいユーザーのsessionを再開できる
telemetry contract	span構造、resource属性、correlation、sampling、秘匿化	どの実行先でも同じクエリで追跡できる
execution contract	identity、filesystem、network、同時実行、終了処理	scale-outや再起動で処理が壊れない

この4つを明文化せずに移行すると、「応答は返るが承認が抜けた」「containerを増やしたら会話履歴が消えた」「Foundryだけtool traceが途切れた」といった問題が起きやすくなります。

local・container・Foundryの役割を分ける

同じagentコードを使う場合でも、stateとtelemetryの責任範囲は実行先ごとに異なります。

実行先	主な用途	stateの持ち方	telemetryの経路
local	開発、デバッグ、contract test	in-memoryまたはローカルファイル	localのOTel Collector、Aspire Dashboard
container	自前本番、ステージング	外部DB、object storage、共有file store	sidecarまたは共通Collector
Foundry Hosted Agents	managed hostingの検証	platform管理のsessionと永続領域	Application Insightsまたは構成したOTel経路

Foundry Hosted Agentsでは、platformがscaling、session state persistence、security、lifecycleを管理します。また、$HOMEとuploadされたfileの永続化、agentごとのEntra identityも提供されます。ただし、これは業務データまで自動的に永続化されるという意味ではありません。注文、申請、承認結果などの業務stateは、引き続きアプリケーション所有のデータストアへ保存します。(Microsoft Learn)

Preview版からGA runtimeへ移行する手順

現在の依存関係を記録する

最初に、直接依存と推移依存を一覧化します。

# .NET
dotnet list package --include-transitive

# Python
python -m pip freeze

次の文字列を含むpackageを抽出します。

preview
prerelease
alpha
beta
rc
dev

さらに、次の項目を記録します。

Agent FrameworkとAgent Harnessのversion
model providerとmodel deployment
custom middleware、context provider、history provider
file memoryとfile accessの保存先
tool approvalの設定
OpenTelemetryの計装箇所
exporterと送信先
sessionのserialization形式
container image、OS、runtime version

この一覧がrollback時の基準になります。

旧runtimeのbaselineを取得する

移行前に、代表的なシナリオを固定して実行結果を保存します。

例えば、社内文書検索agentなら次のシナリオを用意します。

文書を検索する
検索結果を要約する
承認が必要な更新toolを呼び出す
sessionを保存する
processを再起動する
sessionを復元して続きから実行する
tool error発生時に再試行する

保存すべき情報は最終回答だけではありません。

呼び出されたtool名
tool引数と戻り値のschema
approvalの有無
session保存後のstate
trace IDとspan階層
model呼び出し回数
token使用量
p50、p95 latency
timeout、retry、errorの発生数

生成AIの回答文は完全一致しないことがあります。そのため、文章そのものよりも、tool選択、必要項目、業務結果、禁止操作の有無を検証します。

GAパッケージへ更新してversionを固定する

.NETでは公式ドキュメントでMicrosoft.Agents.AI.HarnessとAsHarnessAgentが案内されています。Pythonではagent-frameworkのcreate_harness_agentを利用します。Pythonの主要packageは安定版となり、通常は--preを付けずにinstallできます。(Microsoft Learn)

# .NET：NuGetで「-preview」のない承認済みversionを確認して指定
dotnet add package Microsoft.Agents.AI.Harness --version <approved-stable-version>

# Python：PyPIの承認済み安定版を固定
python -m pip install "agent-framework==<approved-stable-version>"

本番環境で、次のような更新は避けます。

pip install -U agent-framework

無条件のupgradeでは、検証していないminor versionまで取り込む可能性があります。lock fileや中央package管理を使い、CIと本番で同じ依存関係を再現できるようにします。

また、GA発表日とpackage registryへの反映日は一致しないことがあります。移行開始条件は「GAと発表された日」ではなく、自社が利用するすべての直接・推移依存に安定版が揃った日とするのが安全です。

Harnessの既定機能を明示する

Agent Harnessは多くの機能を既定で組み込みます。本番では、既定値に依存せず、有効・無効を明示します。

.NETでは、例えば次のように設定します。

AIAgent agent = chatClient.AsHarnessAgent(new HarnessAgentOptions
{
    DisableWebSearch = true,
    DisableFileMemory = true,
    DisableFileAccess = true,
    DisableToolAutoApproval = true,
    DisableOpenTelemetry = false
});

Pythonでも同様に明示します。

agent = create_harness_agent(
    client=client,
    disable_web_search=True,
    disable_file_memory=True,
    disable_file_access=True,
    disable_tool_auto_approval=True,
)

実際の設定値は用途によって異なります。重要なのは、preview版の暗黙動作をGA版の暗黙動作へ置き換えないことです。

context compactionについても、最大context token数と最大output token数を指定するか、独自strategyを設定します。公式ドキュメントでは、必要なtoken budgetを指定しない場合、Pythonのcompactionは自動的に無効になります。(Microsoft Learn)

Tool contractを検証する

toolは、移行で最も業務事故が起きやすい部分です。最低限、次の項目をテストします。

tool名とschema

tool名、引数名、必須項目、型、enum、default値をsnapshotとして保存します。

例えば次の変更は、コード上は小さくてもagentの挙動を変えます。

send_mail → send_email
customer_id → customerId
required → optional
integer → string

モデルはtoolの説明文も判断材料にします。descriptionを変更した場合もcontract変更として扱います。

副作用と冪等性

メール送信、データ更新、発注、削除などのtoolには、request IDやidempotency keyを渡します。

同じtool呼び出しがretryされたときに、処理が二重実行されないことを確認してください。

承認条件

次の操作は、原則として明示的なapproval対象にします。

外部への送信
データの追加、更新、削除
課金が発生する操作
shell commandの実行
fileの上書き
権限変更
個人情報の取得

Agent Harnessにはtool approval機能がありますが、既定の自動承認に依存せず、自社のリスク区分と対応付けます。

shellのdeny-listを境界にしない

Agent Harnessの公式ドキュメントでも、shell commandのdeny-listはUX上の事前filterであり、security boundaryではないと説明されています。productionでは、containerやsandbox、network制限、read-only filesystem、最小権限identityを組み合わせる必要があります。(Microsoft Learn)

Stateを4種類に分けて移行する

stateをひとまとめにすると、実行環境を変えた際に責任範囲が分からなくなります。少なくとも次の4種類に分けます。

会話履歴

ユーザーとagentのmessage履歴です。

Agent Frameworkでは、local session stateに履歴を持つ方式と、service側がconversationを管理する方式があります。in-memory履歴はprocess再起動で失われるため、productionでは永続化先を明確にします。(Microsoft Learn)

Harness内部のprovider state

todo、plan／executeモード、context providerの状態などです。

Pythonではprovider stateのscopingがsource_id単位へ変更された例があります。custom providerがsession全体のdictionary構造に依存している場合は、GA版のstate構造に合わせた修正が必要です。(Microsoft Learn)

業務state

注文番号、申請状況、承認結果、ユーザー設定などです。

これはAgentSessionだけに保存せず、業務DBへ記録します。AgentSessionは会話の継続に使い、業務上の正本にはしない方が安全です。

fileとartifact

生成文書、分析結果、一時file、skill、作業用directoryなどです。

local filesystemは、containerの再作成やscale-outで共有されません。複数replicaで実行する場合は、共有volume、object storage、または独自のAgentFileStoreを利用します。Agent Harnessではfile storeを差し替えられる設計が案内されています。(Microsoft for Developers)

Sessionをそのまま引き継げるとは限らない

AgentSessionはagent runをまたいで利用される会話stateのcontainerです。ただし、sessionはagentやserviceの構成に依存します。Microsoft Learnでも、異なるagent設定やproviderでsessionを再利用すると、無効なcontextになる可能性があると説明されています。(Microsoft Learn)

最も安全な移行方法は次の構成です。

新規sessionはGA runtimeで開始する
旧sessionはpreview runtimeで一定期間継続する
session IDごとにruntime versionを記録する
旧sessionの利用がなくなってからpreview runtimeを停止する

既存sessionをGAへ移す必要がある場合は、version付きのenvelopeへ保存します。

{
  "schemaVersion": 2,
  "agentVersion": "2026.07",
  "runtimeFamily": "agent-harness-ga",
  "tenantKey": "hashed-tenant-key",
  "session": {}
}

復元時には、最低限次を検証します。

schemaVersionが対応範囲内か
agentとproviderの組み合わせが一致するか
sessionの所有tenantが一致するか
service-side IDが現在のprojectで有効か
fileやartifactへの参照が残っているか

Pythonのcheckpointでは、security hardeningによりcustom typeのdeserializationを明示的なallow-listへ追加する必要がある場合があります。旧checkpointを利用している場合は、allowed_checkpoint_typesの要否も確認します。(Microsoft Learn)

Service session IDを認可に使わない

service_session_id、previous_response_id、conversation IDなどは、ユーザー認証や認可の代わりにはなりません。

複数ユーザーが同じprojectやcredentialを利用する構成では、次のように管理します。

clientには自社発行のsession IDだけを返す
service側のconversation IDはtrusted storageへ保存する
自社session IDからservice IDへserver側で変換する
復元前にuserまたはtenantの所有権を確認する

Microsoft Learnでも、rawなservice-side IDをclientから受け取り、そのままsession再開に使わないよう注意されています。(Microsoft Learn)

Foundryでは履歴の二重保存を避ける

Foundry Hosted AgentsのResponses protocolでは、hosting infrastructureがconversation historyを管理します。この構成でprovider側の保存も有効にすると、履歴が二重に保持される可能性があります。

公式例では、Python agentのdefault_optionsで次のように設定しています。

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

これは、Foundry側が履歴を管理するため、provider側で同じ履歴を重複保存しないための設定です。(Microsoft Learn)

一方、Invocations protocolでcustom handlerを実装する場合は、session管理を自分で担当する構成もあります。公式例のin-memory session storeは再起動で失われるため、productionではdurable storageを使用するよう警告されています。(Microsoft Learn)

OpenTelemetryを実行環境から分離する

local、container、Foundryで同じ観測性を保つには、agentコードから監視backendへの依存を減らします。

推奨する経路は次のとおりです。

Agent Harness
    ↓
OpenTelemetry SDK
    ↓ OTLP
OpenTelemetry Collector
    ↓
Application Insights／Azure Monitor／既存の観測基盤

Agent FrameworkはOpenTelemetryと統合され、GenAI Semantic Conventionsに沿ったtrace、log、metricを出力します。(Microsoft Learn)

「同じ観測性」とは、すべての環境で同じdashboardを使うことではありません。次の契約が同じであることを指します。

service.name
service.version
environmentとruntime targetの属性
traceとtool呼び出しの親子関係
errorの記録方法
sampling方針
sensitive dataの除外方針
sessionとrequestのcorrelation方法

共通の環境変数を用意する

例えば、次のような設定を各targetへ渡します。

OTEL_SERVICE_NAME=customer-support-agent
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
OTEL_EXPORTER_OTLP_PROTOCOL=grpc
OTEL_RESOURCE_ATTRIBUTES=service.version=2026.07.1,deployment.environment=prod,agent.runtime.target=container

ENABLE_SENSITIVE_DATA=false

service.nameは論理的に同じagentで統一し、local、container、Foundryの違いは別属性で識別します。

実行先ごとにservice.nameを変えると、環境横断の比較がしにくくなります。逆にtarget属性を付けないと、どこで発生した問題か判別できません。

.NETではsourceNameを一致させる

.NETでは、計装時に指定したsourceNameと、OpenTelemetry providerのAddSourceに指定する値を一致させます。

const string SourceName = "Contoso.CustomerSupportAgent";

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .SetResourceBuilder(
        ResourceBuilder.CreateDefault()
            .AddService("customer-support-agent"))
    .AddSource(SourceName)
    .AddOtlpExporter()
    .Build();

公式ドキュメントでも、計装側のsource nameとexporter側のAddSourceが一致していないと、想定したtraceを取得できない点が説明されています。(Microsoft Learn)

Pythonでは標準OTel環境変数を読む

Pythonでは、標準のOpenTelemetry環境変数からexporter設定を読み込めます。

from agent_framework.observability import configure_otel_providers

configure_otel_providers()

Python packageにはOpenTelemetry APIやSDKが含まれますが、OTLPやAzure Monitorのexporterは既定ではinstallされません。利用するbackendに応じて、gRPC、HTTP、Azure Monitor用のexporterを明示的に追加します。(Microsoft Learn)

二重計装を避ける

.NETではchat clientとagentの両方にOpenTelemetryを設定すると、promptやresponseが重複して記録される可能性があります。

次のいずれかを基本方針にします。

agent全体の動作を見たい場合はagent側を計装する
provider呼び出しだけを詳しく見たい場合はchat client側を計装する
両方必要な場合は、重複spanを識別できるqueryとsamplingを用意する

Microsoft Learnでも、chat clientとagentを同時計装するとcontextが重複する可能性があるため、必要に応じて片方だけを有効にするよう案内されています。(Microsoft Learn)

Pythonでは、version更新の過程でinstrumentationの既定動作が変更されています。既存のcustom telemetry pipelineがある場合、暗黙のdefaultに頼らず、有効・無効を明示して重複を検証してください。(Microsoft Learn)

Promptやtool引数をproduction traceへ出さない

sensitive dataを有効にすると、次の情報がtraceやlogへ記録される可能性があります。

prompt
model response
function callの引数
toolの実行結果
文書や検索結果の内容

公式ドキュメントでも、sensitive dataは開発またはテスト環境だけで有効にし、productionでは利用しないよう警告されています。(Microsoft Learn)

productionでは、次の方針が現実的です。

prompt本文ではなくtemplate IDを記録する
user IDはhash化または内部IDへ置き換える
tool引数は項目名と件数だけを記録する
error messageからcredentialや個人情報を除去する
metricには高cardinalityなsession IDを付けない
詳細調査が必要な場合だけ、期限付きのdebug設定を適用する

MCPのtraceがFoundryだけ途切れる理由

Agent Frameworkでは、agent process自身が開いたMCP sessionに対して、W3C Trace Contextのtraceparentやtracestateを自動伝播できます。

ただし、Foundryのmanaged toolboxなど、provider側runtimeがMCP toolを呼び出す構成では、Agent Frameworkのprocessからtrace contextを注入できません。この場合、下流MCP serverまでのtrace伝播はservice runtime側の責任になります。(Microsoft Learn)

localではtraceがつながるのにFoundryでは途切れる場合、次を確認します。

client-opened MCPかprovider-managed MCPか
traceparentが実際のrequestへ付与されているか
tool service側のOpenTelemetry instrumentationが有効か
Foundry側spanとtool側spanを別のcorrelation IDで結べるか

end-to-end traceが必須なら、client-opened MCP transportを使うことも代替策になります。

Foundry Hosted Agentsへ展開するときの追加確認

Foundry Hosted Agentsを利用する場合は、次の点を別途検証します。

ResponsesとInvocationsのどちらを使うか

Responses protocolは、OpenAI互換endpoint、streaming、conversation history、session lifecycleをplatformへ任せたい場合に向いています。

Invocations protocolは、custom payload、非会話型処理、独自streaming、独自session管理が必要な場合に向いています。

identityを環境ごとに変える

localではdeveloper credentialを利用しても、productionではmanaged identityなどの明示的なcredentialを使います。

同じagentコードでも、次の権限は環境ごとに分けます。

modelへのアクセス
storageへのread／write
tool APIへのアクセス
secret storeへのアクセス
telemetry送信権限

Foundry固有コードをadapterへ閉じ込める

agent本体にFoundry固有処理を埋め込まず、hosting部分を分離します。

src/
  agent/
    tools
    prompts
    state_contract
    telemetry_contract

hosts/
  local
  container
  foundry

この構成なら、Foundry Hosted Agentsのpreview仕様が変わっても、toolや業務logicへの影響を抑えられます。

Canary releaseの合格条件を決める

GA runtimeは、いきなり全trafficへ切り替えず、段階的に展開します。

推奨する順序は次のとおりです。

CI上のcontract test
localでのgolden scenario
containerでの再起動試験
stagingでのparallel run
内部ユーザー限定のcanary
新規sessionの一部をGAへ割り当て
25％、50％、100％へ段階拡大

合格条件の例は次のとおりです。

指標	合格条件の例
tool成功率	旧runtime比で2ポイント以上低下しない
session再開error率	0.5％未満
trace取得率	99％以上
duplicate span率	1％未満
p95 latency	旧runtime比20％以内
1成功処理あたりのcost	旧runtime比15％以内
無承認の書き込みtool	0件
tenantをまたぐsession復元	0件

数値は公式基準ではなく、自社SLOに合わせて調整するための例です。

Rollbackではstateの互換性が問題になる

packageを元に戻せても、GA runtimeが書き込んだstateをpreview runtimeが読めなければrollbackできません。

次のいずれかを採用します。

新旧runtimeが読めるstate形式を一定期間維持する
stateをversion別の保存領域へ分離する
GAへの切替後は旧runtimeへsessionを戻さない
新規sessionだけGAへ移し、旧sessionは旧runtimeで終了させる
書き込み時に旧形式と新形式を一時的にdual-writeする

dual-writeは有効ですが、保存量、個人情報の複製、整合性管理が増えます。短期間に限定し、終了日を決めて実施します。

Foundry Hosted Agentsを使えない場合の代替策

Foundry Hosted Agentsがpreviewであることを理由に、本番採用できない組織もあります。その場合でもAgent HarnessのGA移行を止める必要はありません。

自前のcontainer基盤へ配置する

GA版Agent Harnessをcontainer化し、任意のcontainer基盤へ展開します。

必要になるのは次の構成です。

statelessなagent process
durable session store
object storageまたは共有file store
managed identityまたはworkload identity
OpenTelemetry Collector
readiness、liveness、graceful shutdown
queueまたはretry制御
scale-out時の排他制御

旧sessionだけpreview runtimeに残す

state互換性が低い場合は、既存sessionを無理に変換しません。

新規session → GA runtime
既存session → preview runtime

session routing tableにruntime versionを記録し、旧sessionが自然に終了した段階でpreview runtimeを停止します。

Tool adapterで旧schemaを維持する

GA版でtool APIを変更したい場合でも、agentから見えるtool名とschemaは一度維持します。

旧tool contract
    ↓ adapter
新しい業務API

tool contractとbackend APIの変更を同時に行わないことで、問題の切り分けが容易になります。

Collectorでtelemetryを正規化する

環境ごとにspan属性やresource属性が異なる場合は、agentコードへ条件分岐を増やすのではなく、OpenTelemetry Collectorのprocessorで補正します。

属性名の追加・変換
environment名の統一
sensitive属性の削除
sampling
複数backendへのrouting

一時的なdual exportも可能ですが、traceの重複、保存cost、個人情報の複製に注意してください。

移行で失敗しやすいポイント

失敗例	問題	対策
packageとmodelを同時更新する	回帰原因を特定できない	model、runtime、hostingを別releaseにする
Harnessの既定値に任せる	Web検索やfile accessが意図せず有効になる	disable設定を明示する
in-memory stateのままscale-outする	replica間でsessionを共有できない	durable storageへ外出しする
session IDをclientへそのまま返す	他ユーザーのconversationへ接続される恐れ	server側mappingとtenant検証を行う
agentとchat clientを二重計装する	span、prompt、costが重複する	計装レイヤーを1つに決める
localと本番でservice.nameを変える	環境横断で比較できない	service.nameを統一しtarget属性を付ける
productionでsensitive dataを有効にする	promptやtool結果が保存される	productionでは無効化する
shell deny-listだけで防御する	bypass可能なため境界にならない	sandboxと最小権限を使う
Foundry Hosted AgentsもGAだと判断する	preview制約を見落とす	hostingを別のrisk review対象にする
rollback時のstate形式を考えない	packageを戻してもsessionを復元できない	state versionとroutingを管理する

本番移行で最後に確認すること

Agent HarnessをGA runtimeへ移す際は、次の順番で進めてください。

previewを含む直接・推移依存を一覧化する
現行runtimeのgolden scenarioを保存する
modelとhostingを変えず、Harness packageだけを更新する
built-in機能の有効・無効を明示する
tool schema、approval、冪等性を検証する
session、business state、fileを分離する
service session IDのtenant所有権を検証する
OpenTelemetryのresource属性とexporterを共通化する
duplicate spanとsensitive dataを確認する
local、container、Foundryで同じtrace queryを実行する
新規sessionから段階的にGAへ切り替える
stateを含むrollback手順を実地確認する

最初に行うべき作業は、現在のpackage一覧と代表的な1つの実行traceを保存することです。そのうえで、GA packageだけを更新した検証branchを作り、tool・state・telemetryの差分を確認します。Foundry Hosted Agentsへの移行は、その検証が完了してから独立した判断として進めると、安全に本番運用へ移行できます。

この記事を書いた人

佐藤健司

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