Microsoft Foundry Agent Optimizerは、hosted agentを固定datasetで評価し、instruction、skill、tool description、model selectionの候補を作り、baselineと比較するpreview機能である。promptを書き換えるだけの自動化ではなく、同じtaskとcriteriaで候補を再評価し、composite scoreの高いconfigurationを選ぶ。ただしdatasetが業務を代表していなければ、数値だけ改善して本番品質が下がる。評価設計と副作用隔離が導入の中心になる。

何が変わったか

Agent Optimizerはbaselineを実行・採点し、alternative configurationを生成して同じdatasetで評価し、0～1のcomposite scoreで順位付けする。対象はsystem instruction、SKILL.mdのskill body、tool・parameter description、model search spaceである。winning candidateはlocal configurationへapplyし、再deployできる。

変更前後の差

従来は担当者がpromptを修正し、限られた会話例で良し悪しを判断する反復が中心だった。Optimizerではdataset、evaluator、baseline、candidateを記録したclosed loopになる。一方、production trafficから自動学習して即時反映する機能ではなく、候補を人が選びdeployする工程が残る。

誰に影響するか

Foundry hosted agentをResponses protocolで運用し、instruction tuning、skill改善、tool選択精度、modelとcostの比較を行うチームが対象となる。previewはhosted agent提供regionの一部で利用でき、Norway Eastは除外される。quickstartではsubscriptionがallow listに必要と案内されている。

期限

強制導入期限はない。previewでSLAがなく、本番推奨ではない。評価環境で候補を生成し、既存のrelease approvalを通してから段階配備する。

必要な対応

代表task、成功条件、禁止事項、cost・latencyを含むdatasetを準備する。外部API、database、ticket作成など副作用を持つtoolはmockまたはtest endpointへ切り替える。Optimizerは各task・candidateでAgentを実行するため、同じ副作用が繰り返され、費用とrate limitが増える可能性がある。

実装・移行手順

  1. 現行Agent configurationをbaselineとして固定する
  2. 代表taskと評価criteriaをdatasetへ登録する
  3. 外部toolをmock・sandbox・test tenantへ切り替える
  4. eval.yamlでeval modelとoptimization modelを指定する
  5. 少数candidateでoptimizationを実行する
  6. baselineとcandidateのtask別score、cost、tokenを比較する
  7. winning candidateをapplyし、追加回帰評価を行う
  8. canary deploy後に本番指標を確認して昇格する

失敗しやすい点

composite scoreだけを見てtask別退化を見落とす、datasetへ簡単な質問だけを入れる、外部toolを本番endpointのまま反復実行する、長いinstructionによるtoken増を無視する、candidateを自動的に全量deployする、といった問題が起きやすい。0.03未満のscore差はnoiseの可能性があるという公式目安も参考にする。

リスク

評価modelのbias、dataset leakage、過学習、tool副作用、optimization実行費用、長文化によるlatency増がある。skill本文だけが変わりdescriptionが維持されるなど、optimization targetごとの変更範囲も理解する。model selectionでは品質とcostのtrade-offを別指標で確認する。

評価方法

  • baselineとcandidateのtask別score差
  • composite scoreの信頼区間・再現性
  • safety・禁止taskの違反率
  • tool選択精度と不要呼出率
  • response token・latency・費用の増減
  • 人手reviewでの受入率
  • canary後の本番成功率とrollback率

ロールバック

winning candidate適用前のbaseline configurationをversion管理し、Agent versionを直前へ戻す。Optimizer jobやcandidateを消すだけでなく、azure.yaml、instruction、skill、tool description、model deploymentの変更を一単位でrollbackする。外部toolで発生した副作用は別途補償処理が必要になる。

編集部分析

Optimizerはprompt engineeringを不要にするのではなく、個人の勘から評価dataset中心の工程へ変える。最も重要な資産は生成されたpromptではなく、業務を代表し退化を検出できるdatasetである。scoreを上げる目的関数へcost、latency、安全性を入れなければ、品質だけ高く運用不能なcandidateを選ぶ可能性がある。

実務チェックリスト

  • [ ] baseline configurationをversion固定した
  • [ ] 代表taskと禁止taskをdatasetへ含めた
  • [ ] 外部toolをmockまたはtest endpointへ切り替えた
  • [ ] task別scoreとcost・latencyを比較した
  • [ ] 小さなscore差を過大評価しない
  • [ ] candidateを人手reviewした
  • [ ] canaryとconfiguration rollbackを用意した

一次情報