Microsoft Foundry 大型アップデートまとめ：モデル選択・音声エージェント・継続的最適化まで

エージェントは「作る」より「回し続ける」方が難しい

エージェントのプロトタイプは半日で作れます。問題はその先です。モデルは数週間でより良いものに置き換わり、ユーザーはテキストではなく音声で話しかけ、リサーチエージェントは1リクエストでは終わらず、コンプライアンス部門は「このエージェントのオーナーは誰か」と問い合わせてきます。

今回 Microsoft Foundry に投入された一連のアップデートは、まさにこの地点を狙っています。要するに 「特定モデルに依存しないエージェント基盤」 を作り、モデルが変わってもチームがアーキテクチャを作り直さなくて済むようにする、という方針です。根拠資料は Microsoft Azure 公式ブログ で確認できます。

本記事では、実務で効果が見えやすい5つの軸で整理します。モデル選択、音声、長時間実行、継続的最適化、ガバナンスです。

1. モデル選択は「プロジェクト開始時の決定」ではなく「継続的な優位」

今週 Foundry には GPT-6 ファミリー（Sol / Luna 含む） と Claude Opus 5.5 が同時に追加されました。重要なのは特定モデルではなく、フロンティア全体が 「数か月」ではなく「数日」単位で入れ替わる という事実です。

実務的な意味は明確です。

• コーディングエージェントに最適なモデルが、リサーチ・CS・大量推論にも最適とは限りません。
• 「うちは OpenAI だけ使う」といったロックイン宣言は、半年後に技術的負債になります。
• そこで Foundry は、自社データ・ワークロードでモデルを評価 し、品質・レイテンシ・コストのトレードオフを比較してから本番投入する流れを前提に設計されています。

# Foundry で複数モデルを同一プロンプトで評価する概念例
# （実際の SDK 呼び出しは Foundry ドキュメントの最新 API を参照してください）

from foundry import ModelClient

candidates = ["gpt-6-sol", "gpt-6-luna", "claude-opus-5.5"]
client = ModelClient(endpoint="https://<your-foundry>.ai.azure.com")

for model in candidates:
    result = client.evaluate(
        model=model,
        dataset="my-agent-golden-set.jsonl",  # 自チームの実データ
        metrics=["quality", "latency_p95", "cost_per_1k"],
    )
    print(model, result.summary)  # 品質・レイテンシ・コストを一括比較

ポイントは 「評価せずにモデルを差し替えない」 ことです。モデル切り替えはもはやリリースイベントではなく、常時運用タスクです。

2. 音声エージェントは「テキストに音声を被せる」ものではなくなった

従来の音声ボットは、テキストエージェントに STT/TTS を後付けする構成が主流でした。その結果、オーケストレーション・監視・デプロイが別々になりがちでした。Foundry Agent Service の Voice Agents（パブリックプレビュー） は、これをエージェント基盤の一級市民に引き上げます。

特に AZD AI（ソース管理ベースのデプロイ）、VS Code Foundry Toolkit（近日）、音声ネイティブの可観測性 がセットで出てくる点が実務的に大きいです。「デモは動くが運用できない」音声ボットの典型的な落とし穴を、ツールレベルで減らせます。

日本のエンタープライズでは、音声チャネルがコールセンターや金融窓口に直結することが多いため、個人情報の取り扱い・通話録音・トランスクリプト保管ポリシー を Foundry のガバナンス層と一緒に設計しておくことが特に重要です。

3. 長時間実行と継続的最適化、そしてガバナンス

長時間実行ホスト型エージェント

リサーチやレポート生成のように1リクエストで終わらない処理のために、Long-running resilience（パブリックプレビュー） が入りました。リクエストが切断されても処理が継続し、ホストプロセスが落ちても復旧します。Microsoft Agent Framework のワークフロー状態とチェックポイントを組み合わせれば、「最後の durable checkpoint から再開」が可能です。さらに Agent Channel（メッセージング）、AG-UI（インタラクティブアプリ）、CodeAct / Hyperlight（分離コード実行）、episodic procedural memory も追加されています。

本番の証拠を改善ループへ

• Insights（プレビュー）: 本番トレースから反復的な問題と「気づいていなかった問題」を表面化。
• Rubric evaluator（今月 GA）: 「良い状態」を測定可能な基準として定義。
• Synthetic / traces-to-dataset（今月 GA）: 実トラフィックに基づく評価データを生成。
• Agent optimizer（今月 GA）: 指示文・ツール・スキル・モデル選択の変更を、出荷前に検証。

観察 → 理解 → 評価 → 最適化 → 検証 → 反復。このループが「エージェントは長く動かすほど良くなる」という言葉を実際に成立させます。

ガバナンス

Entra / Agent 365 由来のブロック・無効化・削除・復元・オーナー再割当といった操作が、Foundry ランタイム側で強制されるようになりました。ネットワーク egress 制御 でホスト型エージェントの外部宛先を allow/deny/ヘッダー変更/リダイレクトでき、監査モードでポリシーを事前検証できます。10月には Azure API Management の AI Gateway ティア プレビュー連携により、ハブアンドスポーク型のガバナンスが Foundry の開発体験に統合されます。

注意点と限界

• プレビュー機能が多いです。 Voice Agents、Long-running resilience、Insights、AI Gateway 連携はプレビュー段階であり、SLA・リージョン・API 安定性を必ず確認してください。
• ベンチマークは文脈依存です。 ツール検索が入力トークンを 60〜97% 削減したという数値は、特定ベンチマーク（44,000+ ツール）での結果です。自社ワークロードでの再測定が必須です。
• モデル選択の自由は評価負担でもあります。 候補が増えた分、ゴールデンセット・回帰テスト・コストガードレールをチーム標準にしてください。

次の学習ステップ

1. ai.azure.com でモデルを1つ選び、エージェントを1つ立ち上げる。
2. ゴールデンセット 20〜50 件で Rubric evaluator を試す。
3. 音声エージェントを Teams または Twilio インバウンドに接続し、割り込みシナリオをテスト。
4. Agent optimizer で指示文の A/B 検証。
5. Entra / Agent 365 のガバナンス操作がランタイムで強制されるか確認。

あわせて読みたい

• Amazon Macie + Step Functions でカスタム PII 検出を自動化する — 3バケットパイプライン完全攻略 — エージェントが扱うデータに PII が混ざる場合、パイプライン側で自動検出・隔離するパターンが特に有効です。
• NVIDIA Blackwell Ultra、AI 推論の隠れたボトルネック Softmax を解消する — エージェント推論コストを下支えするハードウェア／カーネル観点の対になる記事です。