私が 3 年前から続けているいつもの Update 速報です。Microsoft Foundry における Microsoft Build 2026 アップデートは、単なる新機能追加ではなくエージェント開発を「試作」から「本番運用」へ移すための基盤整理と見ることができます。今回 Microsoft は Foundry をモデル、エージェント、ツール、ナレッジ、メモリ、評価、ガードレール、監視、デプロイを一体で扱うプラットフォームとして再定義しています。
今回の中心メッセージは次の 3 つです。
- Build: Microsoft Agent Framework、Foundry Toolkit for VS Code、Toolboxes、Foundry IQ、Voice Live、Content Understanding により、開発者が使うフレームワークやツールの選択肢を保ったまま、エージェントを作りやすくする。
- Deploy: Hosted Agents、ソース コードデプロイ、Teams / Microsoft 365 Copilot への公開、Agent 365、A2A により、エージェントを利用者の業務画面へ届けやすくする。
- Operate: トレース、評価、ASSERT、Agent Control Specification、ガードレール、Rubric、Agent Optimizer、Purview 連携により、本番で起きた失敗を観測し、評価し、改善へ戻すループを作る。
アップデートサマリー
Build: エージェント開発
| 対象 | Build 2026 Updates | 状態 |
|---|---|---|
| Microsoft Agent Framework | Agent Harness にスキル、メモリ、ミドルウェア対応を追加 | 安定リリース |
| GitHub Copilot SDK / Claude Agent SDK との統合を追加 | 安定リリース | |
| Magentic-One を含む多エージェント オーケストレーション パターンを追加 | 安定リリース | |
| ファイル システム ツール、メモリ ツール、Deep Research Agent を追加 | パブリック プレビュー | |
| Foundry Toolkit for VS Code | 一般提供。作成、デバッグ、Toolbox 接続、Hosted Agents デプロイを VS Code 内で完結 | GA |
| Toolboxes in Foundry | Toolboxes in Foundry を追加。MCP 互換エンドポイントとしてツールを一元管理 | パブリック プレビュー |
| プロジェクト スコープのスキル カタログ。スキルを MCP Resources として検出 | プレビュー | |
| Tool Search。タスクに応じてツールを動的に選択 | プレビュー | |
| Work IQ、Fabric IQ、Foundry IQ、Web IQ 連携を追加 | Work IQ / Fabric IQ: プレビュー、Foundry IQ: GA | |
| Foundry IQ | Serverless Tier、新ナレッジソース (Work IQ / Fabric IQ / Azure SQL / File / MCP Server)、Web IQ、Agentic Retrieval 品質改善 | Foundry IQ 自体は GA。Serverless Tier はパブリック プレビュー |
| Memory | Procedural Memory を追加。繰り返し手順を学習し再利用 | パブリック プレビュー |
| User Memory、Session Memory | パブリック プレビュー | |
| Voice Live | Prompt Agent 対応を一般提供。最短の音声導入パス | GA |
| Hosted Agents + Voice Live 連携 | パブリック プレビュー | |
| Content Understanding | 事前構築済みアナライザーを Foundry に追加。文書/画像/音声/動画を構造化 | パブリック プレビュー |
Deploy: 本番デプロイと配布
| 対象 | Build 2026 Updates | 状態 |
|---|---|---|
| Hosted Agents ランタイム | 管理ランタイムとして GA 間近（2026 年 7 月初旬予定） | パブリック プレビュー → 早期 GA 予定 |
| ソース コードデプロイ（ZIP アップロード、コンテナー不要） | パブリック プレビュー | |
| 組み込みガードレール（Content Safety ベース、入出力検査） | パブリック プレビュー | |
invocations_ws WebSocket プロトコル追加 |
パブリック プレビュー。North Central US のみ | |
| 長時間自律エージェント対応（Durable state / ファイル システム） | パブリック プレビュー | |
| Routines（タイマー / スケジュール実行） | パブリック プレビュー | |
| 配布: Teams / M365 Copilot | Foundry Agent を Microsoft Teams / Microsoft 365 Copilot へ公開 | 2026 年 6 月 GA 予定。Learn は Early Access Preview 表記 |
| 配布: Agent 365 | Autopilot Agents を追加（Entra Agent ID、メール、Teams プレゼンス付き） | パブリック プレビュー。UI なし、サンプル コード経由 |
| 相互運用: A2A | Incoming A2A を追加。Foundry Agent を A2A エンドポイントとして公開 | パブリック プレビュー。Entra ID 認証必須 |
Operate: 観測・評価・ガバナンス
| 対象 | Build 2026 Updates | 状態 |
|---|---|---|
| トレース / 評価基盤 | トレースと評価（非 Hosted Agent 向け）が春に GA 到達 | GA |
| Hosted Agents 向けトレースと評価 | 2026 年 6 月後半 GA 予定 | |
| 任意フレームワーク向けトレース / 評価（LangChain、Semantic Kernel 等） | パブリック プレビュー | |
| AZD observability 開発体験（CLI からトレース / ログ / 洞察） | パブリック プレビュー | |
| 評価機能拡張 | Rubric evaluator（エージェント定義から重み付き評価基準を自動生成） | パブリック プレビュー |
| Multi-turn evaluation（複数ターン会話の品質評価） | パブリック プレビュー | |
| User Simulation（現実的な多ターン会話を自動生成） | パブリック プレビュー | |
| Evaluations with Intelligent Sampling（本番トレースから信号豊富なサンプルを抽出） | パブリック プレビュー | |
| Traces to dataset（本番トレースを評価データセットへ変換） | パブリック プレビュー | |
| Trace replay and visualization（実行トレースを可視的に再生） | パブリック プレビュー | |
| Agent Optimizer | プロンプト、スキル、モデル、ツール説明の改善候補を生成・比較・デプロイ | プライベート プレビュー → 30 日以内にパブリック プレビュー |
| Agent ROI | タスク完了率、時間削減、コスト効率のビジネス価値測定 | プライベート プレビュー |
| ASSERT | オープンソースの方針駆動評価フレームワーク。任意フレームワーク対応 | OSS（フレームワーク非依存） |
| Agent Control Specification | 8つの介入ポイント（startup/input/pre_model/post_model/pre_tool/post_tool/output/shutdown）への決定論的制御仕様 | オープン仕様（YAML、フレームワーク非依存） |
| Guided Guardrail Setup | 質問形式でリスク評価し、適切なガードレールを提案 | パブリック プレビュー |
| Runtime DLP | Microsoft Purview DLP をエージェント対話に拡張、リアルタイム検知 | パブリック プレビュー |
| Purview Insights | Foundry Control Plane に Purview データ セキュリティ洞察を埋め込み | GA |
Models: モデル運用
| 対象 | Build 2026 Updates | 状態 |
|---|---|---|
| MAI-Thinking-1 | 35B アクティブ / ~1T 総パラメーターの MoE 推論モデル。SWE-Bench Pro で Claude Opus 4.6 相当 | プライベート プレビュー |
| MAI-Code-1-Flash | 5B アクティブ パラメーターのエージェンティック コーディング モデル。GitHub Copilot 統合 | パブリック プレビュー（VS Code 展開中） |
| MAI-Image-2.5 | 画像生成 + 画像編集。Arena Image Edit #2、Text-to-Image #3 | パブリック プレビュー |
| MAI-Image-2.5-Flash | MAI-Image-2.5 の高速・低コスト バリアント | パブリック プレビュー |
| MAI-Transcribe-1.5 | 43 言語対応の SOTA 音声→テキスト。1 時間の音声を 15 秒以内で変換。キーワード バイアス対応 | パブリック プレビュー |
| MAI-Voice-2 | 15 言語対応の表現豊かな TTS。ゼロショット音声プロンプティング | パブリック プレビュー |
| MAI-Voice-2-Flash | MAI-Voice-2 の高効率バリアント | 近日提供予定 |
| Fireworks AI on Foundry | 一般提供。オープン モデル推論を Azure エンドポイントで利用 | GA |
| Managed Compute | リージョン GPU 制約をルーティングで回避。推論 / Fine-tuning 用 | パブリック プレビュー |
| Fine-tuning Developer Tier | ホスティング費なしで実験可能な新ティア | パブリック プレビュー |
| Frontier Tuning | 顧客ワークフロー上の強化学習で特化。GPT-5.4 相当を 10 倍のコスト効率で達成 | パブリック プレビュー |
3. Build: エージェントを作るためのアップデート
3.1 Microsoft Agent Framework と Foundry Toolkit for VS Code
Build 2026 では、Microsoft Agent Framework（MAF）が Foundry 上のコード ファーストなエージェント開発の中心として位置づけられました。MAF は 2026 年 4 月 2 日に 1.0 GA に到達しており、AutoGen と Semantic Kernel を統合した単一プラットフォームです。Build 2026 の時点で、dotnet-1.9.0、python-1.7.0 に到達しています。
新機能が大量に追加されており、急いでワークショップもアップデートしなくては…
Agent Harness: 本番パターンを組み込みで提供
Agent Harness はモデル推論と実行を接続するレイヤーとして追加されました。以下のビルディング ブロックが組み込みで提供されます。
コンテキスト管理:
- 自動コンテキスト圧縮: トークン使用量を監視し、長いツール呼び出しチェーン中に会話履歴を圧縮してコンテキスト ウィンドウのオーバーフローを防止
- 既定のシステム指示と指示マージ: タスク分解、ツール使用、推論パターン向けの意見付きシステム指示を同梱
組み込みプロバイダーとツール:
-
FileMemoryProvider: セッション スコープのファイルベース メモリ（agent-file-memory/{session}/に保存） -
FileAccessProvider: エージェントがファイルへアクセス・変更するための汎用ファイル アクセス -
TodoProvider: マルチ ステップ タスク管理向けの作業項目追跡 -
AgentModeProvider: "plan" vs "execute" モードの切り替え -
AgentSkillsProvider: ファイル システムからのスキル発見と実行 -
BackgroundAgentsProvider: 子エージェントへのサブタスク委任（並列ファンアウト） -
Web Search: 組み込み Web 検索ツール（DisableWebSearchで無効化可能） -
Shell Execution(.NET のみ): サンドボックス化されたShellExecutorによるシェル コマンド実行
ミドルウェアとカスタマイズ:
-
ToolApprovalAgent: 機密ツール呼び出しの「今後は確認しない」承認ルール -
OpenTelemetryAgent: OpenTelemetry Semantic Conventions による自動トレース - プラガブル ストレージ バックエンド:
FileMemoryStore/FileAccessStoreを任意のAgentFileStore実装（ファイル システム、Blob Storage 等）に差し替え可能
CodeAct: モデル ターン数を削減し高速化
多くのエージェントはモデル品質ではなく、オーケストレーション オーバーヘッドがボトルネックです。CodeAct は、モデルが個別のツール呼び出しを順次選択する代わりに、call_tool(…) を呼ぶ短い Python プログラムを 1 回生成し、サンドボックス内で実行して結果をまとめて返します。
CodeAct は agent-framework-hyperlight（アルファ）パッケージとして提供され、生成されたコードは Hyperlight micro-VM 内で実行されるため、呼び出しごとに強力な分離が実質無料で得られます。ブログでは、代表的なマルチ ステップ ワークロード（多数のユーザーにまたがる注文合計計算、数十のツール呼び出し）で有意な差が確認されたと報告されています。
from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider
@tool
def get_weather(city: str) -> dict[str, float | str]:
"""Return the current weather for a city."""
return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}
codeact = HyperlightCodeActProvider(
tools=[get_weather],
approval_mode="never_require",
)
agent = Agent(
client=client,
name="CodeActAgent",
instructions="You are a helpful assistant.",
context_providers=[codeact],
)
Foundry Hosted Agents へのデプロイ: 数行で本番化
ローカルの MAF エージェントを Hosted Agent にするのは数行でOK。
Python:
server = ResponsesHostServer(agent)
server.run()
.NET:
builder.Services.AddFoundryResponses(agent);
app.MapFoundryResponses();
Hosted Agent としてデプロイすると、スケール ツー ゼロ（アイドル時はコストゼロ、次のリクエストでスケール アップ）、ファイル システムとディスク状態を含む再開、セッションごとの VM 分離サンドボックス、OpenTelemetry トレースの Application Insights 自動連携が得られます。
GitHub Copilot SDK 統合
MAF は GitHub Copilot SDK をバックエンドとしてサポートし、Copilot のコーディング向け機能（シェル実行、ファイル操作、URL フェッチ、MCP サーバー統合）を標準の MAF プログラミング モデルに取り込めます。Copilot エージェントは標準の MAF エージェントであるため、ツール、指示、ストリーミング、セッション、MCP サーバー、組み込み OpenTelemetry 観測性をサポートします。
Foundry Toolkit for VS Code
Foundry Toolkit for VS Code は一般提供となり、テンプレートまたは GitHub Copilot からのエージェント作成、ローカルでの実行とデバッグ、トレース可視化、Toolboxes への接続、Foundry Agent Service へのデプロイまでを VS Code 内で扱えるようになります。
3.2 Toolboxes: ツール統合を MCP エンドポイントへ集約
Toolboxes は Web Search、Azure AI Search、Code Interpreter、File Search、MCP Server、OpenAPI ツールなどをまとめる管理されたツール バンドルです。Toolboxes は MCP 互換エンドポイントを公開するため、Microsoft Agent Framework、LangGraph、GitHub Copilot SDK、カスタム コードなど、MCP に対応する実行環境から利用できます。
今回ツールのスケール問題に対する対処が中心です。5 個のツールから始まった Toolbox が 50 や 200 に成長すると、コスト（全定義を毎ターン送信するトークン消費）、コンテキストの混雑、モデルの混乱という 3 つの問題が生じます。
Build 2026 の更新では、Toolboxes に次の機能が加わりました。
- ツール設定を 1 回作成し、複数のエージェントから再利用する。
- Toolbox のバージョンを作成し、検証後に既定バージョンとして昇格する。
- 認証、資格情報注入、トークン更新、ポリシー適用を中央で扱う。
- スキルを Toolbox バージョンへ接続し、MCP Resources として検出する。
Tool Search: インテント ベースのツール発見
Tool Search が有効な Toolbox では、すべてのツール定義をモデルのコンテキストに一括で送る代わりに、2 つのメタ ツールのみ公開されます。
-
tool_search— 意図を記述し、最も関連性の高いツールを取得 -
call_tool— 発見したツールを名前で呼び出し
さらに、ツール サーフェシング制御として次の機能が提供されます。
-
Pin: 特定ツールを
tool_searchの前に常時公開 - 追加コンテキスト: チームの利用パターンに合うようにツール説明を補完
- Auto-pin: 頻繁に使用されるツールを自動的に常時公開
Browser Automation（プレビュー）
Browser Automation は、Playwright ワークスペースを使った MCP ネイティブの Web 自動化です。Hosted Agents に Web ブラウザー操作を持ち込み、エッジ ケースではリアルタイムの可視性と制御を備えます。複雑な Web タスクをエージェントが自律的に自動化できるようになります。
Managed MCP Servers from Azure Connector Namespace（プレビュー）
Foundry Tools Catalog には、SaaS およびビジネス アプリケーションへの事前構築済み統合が含まれます。コネクタを追加すると、Foundry が Managed MCP server をプロビジョニングし、Jira、Confluence、LinkedIn、Box などのシステムでのアクションをカスタム統合なしで実行できます。
Work IQ と Fabric IQ
Work IQ は、エージェントに Microsoft 365 全体の組織データとコンテキストへのアクセスを提供します。既存の権限とポリシーに基づいて継続的に更新される理解を構築し、生データを公開せずに複雑なマルチ ステップ タスクを処理します。
Fabric IQ は、エージェントをビジネスの運用・分析状態に接続します。Ontology、Fabric Data Agents、Power BI Semantic Models を通じて、自然言語でビジネス データをクエリできます。
Guardrails と Toolbox の統合
ツールと Toolbox の使用がスケールするにつれて、管理者はエージェントの行動を明確にガバナンスする必要があります。Foundry Control Plane の Guardrails により、ツール入力とツール出力の両方にポリシーを適用し、コンプライアンス違反、機密データ漏洩、安全でないコンテンツ、意図外のタスク逸脱をブロックできます。
注意点として、Toolboxes はパブリック プレビューであり、一部 API は実験的です。また、スキルは同じ Foundry プロジェクト内にある必要があり、プロジェクトをまたいだスキル参照はサポートされません。
Skills: Foundry プラットフォームのスキル カタログ（プレビュー）
Build 2026 で追加された Skills in Foundry は、エージェントの行動ガイドラインをコードから分離し、Foundry プロジェクト内でバージョン管理付きで一元管理するプラットフォーム機能です。Skills API は Foundry Control Plane の一部として実装されており、REST API / Python SDK / .NET SDK / JavaScript SDK / Azure Developer CLI のすべてから操作できます。
配信モード 1: Toolbox 接続（MCP Resources として公開）
スキルを Toolbox バージョンに接続すると、MCP クライアントはスキルを MCP Resources として発見・読み込みできます。この仕組みは Skills extension for MCP（SEP-2640）仕様に準拠しています。
MCP クライアント（GitHub Copilot / Claude Code / 任意の Agent Harness）
↓ resources/list
Toolbox MCP エンドポイント
↓ resources/read
スキル コンテンツ取得（SKILL.md 内容）
配信モード 2: Hosted Agent へのダイレクト インジェクション
Toolbox を使わず、Foundry Skills API からスキル コンテンツを直接ダウンロードし、エージェント プロジェクトのローカル skills/ ディレクトリに配置する方式です。エージェントは起動時に SKILL.md を読み込み、セッションごとの追加システム指示として注入します。
Microsoft Agent Framework では一足早く Skills が実装されていましたが、やっと Foundry でも使えるようになりました。
3.3 Foundry IQ: エージェント向けナレッジ レイヤー
Build 2026 では、Foundry IQ が Foundry エージェントの背後にあるナレッジ レイヤーとして強調されました。Foundry IQ は、Work IQ、Fabric IQ、Azure SQL、File Search、MCP Source などを 1 つの SLA 付き Retrieval エンドポイントにまとめ、エージェントが企業内外の知識を安全に取得できるようにします。Serverless tier はパブリック プレビューです。
特に重要な点は、RAG の実装責務がアプリケーション側から Foundry IQ / Azure AI Search 側へ移っていることです。従来は、チャンク分割、インデックス作成、権限同期、再ランキング、引用、複数データ ソース統合を個別に作る必要がありました。Build 2026 の Foundry IQ 更新では、これらをナレッジ ベース、ナレッジ ソース、Agentic Retrieval、MCP エンドポイントとして管理できます。
Foundry IQ のすべてのアップデート情報は以下を参照ください。
3.4 メモリ: 会話の継続性から手順の学習へ
Memory は、エージェントがセッションをまたいで保持する長期記憶を実現できます。
| メモリ種別 | 内容 | 実務上の使い方 |
|---|---|---|
| User profile memory | ユーザーの好み、既定設定、アクセシビリティ要件など | 会話開始時に取得し、パーソナライズの前提として使う。 |
| Chat summary memory | 過去の会話トピックやスレッドの要約 | 各ターンで関連する継続文脈を取得する。 |
| 🆕 Procedural memory | 繰り返し使える作業手順や運用パターン | 定型ワークフローや過去に教えた手順を再利用する。 |
Procedural Memory: エージェントの信頼性向上
エンタープライズ展開で頻出する失敗パターンとして、「正しい事実を知っていても正しい手順を実行しない」問題が指摘されています。Procedural Memory はこのギャップを埋めるために設計されており、2 段階で動作します。
- 取り込みと監査: エージェントの軌跡（trajectories）を取り込み、成功パターン、非効率なルート、欠落ステップを特定。構造化された手順的メモリ項目として抽出し、「いつ使うか」（タスク コンテキスト、前提条件、シグナル）と「何をするか」（順序付きアクション、必要なチェック、ツール使用方法）を記録。
- 検索と注入: 類似タスクに遭遇したとき、関連する手順を検索し、エージェントのコンテキストに注入。必要なバリデーション、正しいツール パラメーター、ポリシー強制などの明示的なステップ レベル制約を含め、エージェントが実績あるパスに従うようガイド。
Agent Optimizer と組み合わせることで、設計時のプロンプト・ツール最適化と、ランタイムでの実タスク実行からの学習を統合した自己改善エージェントを構築できます。
そういえば去年、私は「AutoGen の実験的機能 Task-Centric Memory によるAIエージェントの記憶の保存」という記事を書いていますが、それとの共通点は以下となります。
| 観点 | Task-Centric Memory | Foundry Procedural Memory |
|---|---|---|
| タスク紐づけ | タスク + インサイトのペア | タスク コンテキスト + 手順のペア |
| 検索方式 | 類似タスクのベクトル検索で取得 | 類似タスクに遭遇時に関連手順を検索・注入 |
| 目的 | 経験から学んで次回改善 | 成功パターンを再利用し信頼性向上 |
| 自己学習 |
train_on_task で失敗から学習 |
Agent Optimizer と組み合わせて自己改善 |
AutoGen 時代の Task-Centric Memory が「一般的な教えの記憶と再利用」だとすると、Foundry の Procedural Memory は「実行手順書の自動生成・検索・注入」に焦点を絞った、より構造化されたプロダクション版と言えるかなと思います。MAF が AutoGen を統合した経緯を考えると、Task-Centric Memory の研究がそのまま Procedural Memory の設計基盤になったのでは？と思います。
新しい管理体験とメモリ機能
以下の機能が追加されました。
-
ポータル UI でのメモリ管理: Foundry ポータルで保存されたメモリを直接閲覧し、個別のメモリ項目を CRUD 操作で管理できる新 UX/UI。メモリをブラック ボックスではなく、検査・調整可能なものとして扱える。
-
Memory TTL（Time-to-Live）: メモリ ストア作成時に既定 TTL を設定し、古い低価値のメモリを自動的に廃棄。検索品質の向上とストレージ コストの制御に有効。
-
Multimodal Memory: 画像からの情報を理解・記憶する機能。特に EC やカスタマー サポートのシナリオで有用。
-
Direct Memory Commands: ユーザーがエージェントに「これを覚えて」「これを忘れて」と明示的に指示でき、透明性とユーザー コントロールを向上。
# メモリ ストア オプションの指定例 options = MemoryStoreDefaultOptions( chat_summary_enabled=True, user_profile_enabled=True, procedural_memory_enabled=True, default_ttl_seconds=30 * 24 * 60 * 60, user_profile_details=( "年齢や財務情報など、本題と関係のない情報や機密性の高い情報は避けてください" "あるいは、今後の会話のパーソナライズに役立たない情報はすべて避けてください。" ), )
Microsoft Agent Framework 向けファイルベース メモリ
Microsoft Agent Framework にファイルベース メモリサポートが追加されたことも発表されています。ローカルの Markdown（.md）ファイルから始めて、開発モデルを変えずにスケールできます。
from agent_framework import Agent, MemoryContextProvider, MemoryFileStore
store = MemoryFileStore(
base_path=Path("./memory"),
owner_state_key=MEMORY_OWNER_STATE_KEY,
)
memory_provider = MemoryContextProvider(store=store)
agent = Agent(
client=client,
name="MemoryDemoAgent",
instructions="You are a helpful assistant.",
context_providers=[memory_provider],
)
ただし、メモリは利便性と同時にリスクも持ちます。プロンプト インジェクションやメモリ汚染を防ぐため、Azure AI Content Safety によるプロンプト検証と、制御下での敵対的テストの実施が推奨されています。また、メモリ管理機能として、ストア レベルの既定 TTL 設定、項目レベルの CRUD（作成・読み取り・更新・削除）、スコープによるユーザー単位のデータ分離、ダイレクト メモリ コマンド（即時の記憶・忘却）が提供されています。メモリを使う場合は、ナレッジ ベースとは別に、ユーザー単位・エージェント単位のデータ境界を設計する必要があります。
ちなみに数日前、私は以下のような記事を書いたばかりなんですよね…まぁ記憶の忘却の考え方は当然ですよね。
3.5 Voice Live と Content Understanding
Voice Live は、音声認識、テキスト読み上げ、ターン検出、割り込み処理、アバター、リアルタイム会話機能を 1 つの API にまとめるものです。Prompt Agent 向け Voice Live は一般提供、Hosted Agents と Voice Live の組み合わせはパブリック プレビューとなりました。
Hosted Agents のリアルタイム音声ワークロードは invocations_ws WebSocket プロトコルを使うと説明されています。ただし、2026-06-03 時点では invocations_ws はパブリック プレビューで、North Central US のみ利用可能とされています。WebRTC を使ったリアルタイム音声シナリオもサポートされており、Invocations (WebSocket) プロトコルと Voice Live、Pipecat、LiveKit などのフレームワークをコンテナー内で組み合わせることで、マイク入力から音声出力までの完全なリアルタイム音声エージェントを構築できます
Content Understanding（CU）
Content Understanding については、請求書、文書、画像、音声、動画などから構造化情報を抽出し、RAG、インテリジェント ドキュメント処理、エージェント フローのツールとして使えます。
GPT 5.2 による抽出品質の向上:
CU のアナライザーは Foundry にデプロイした LLM で駆動されます。Build 2026 では GPT 5.2 のサポートが追加され、カスタム フィールド抽出が強化されました。混合レイアウト、ドメイン固有言語、多言語文書でも、プロンプト エンジニアリングの工夫なしにより正確な抽出が可能です。既存の GPT 4.1 ベースのアナライザーは変更なく継続動作します。
Foundry ポータルでの統合:
Content Understanding は Foundry ポータルに統合されました。Foundry モデル、事前構築済みアナライザー、エージェント統合を 1 つの環境でアクセスでき、翻訳、PII 検出、検索などとツールを切り替えずに組み合わせられます。プレイグラウンドでドキュメントをアップロードし、構造化出力を即座に確認できます。カスタム アナライザーの構築は Content Understanding Studio で行えます。
新しいファイル形式のサポート:
- メール / メッセージ形式:
.eml、.msg - レガシーおよびオープン Office 形式:
.doc、.xls、.ppt、OpenDocument（.odt、.ods、.odp）— 事前の変換ステップ不要 - Office ファイル内の埋め込み画像抽出:
.docx、.pptx、.xlsxに埋め込まれた図表、チャート、ダイアグラムを取得可能
エージェント ワークフローとの統合:
CU は Microsoft Agent Framework、Foundry IQ（Standard）、LangChain、MarkItDown と統合されています。
-
Microsoft Agent Framework:
agent-framework-azure-contentunderstandingパッケージにより、ContentUnderstandingContextProviderをエージェントにセットすると、エージェントが会話中に PDF や画像を渡された際に自動でanalyze_documentを呼び出し、構造化フィールドまたはレイアウト対応 Markdown を返します。# pip install agent-framework-azure-contentunderstanding from agent_framework_azure_contentunderstanding import ( ContentUnderstandingContextProvider, AnalysisSection, ContentLimits, ) cu = ContentUnderstandingContextProvider( endpoint="https://my-resource.cognitiveservices.azure.com/", credential=DefaultAzureCredential(), analyzer_id="my-custom-analyzer", output_sections=[ AnalysisSection.MARKDOWN, AnalysisSection.FIELDS, AnalysisSection.FIELD_GROUNDING, ], content_limits=ContentLimits(max_pages=50, max_file_size_mb=50), ) async with cu: agent = Agent(client=llm_client, context_providers=[cu]) response = await agent.run(...) -
MarkItDown:
pip install 'markitdown[az-content-understanding]'で、任意のファイルを CU 経由でレイアウト対応 Markdown に変換。ドキュメント、動画、音声をファイル種別に自動で適切なアナライザーに振り分け。出力は見出し、表、図表説明を含む Markdown で、ダウンストリームのチャンカーや埋め込みモデルが好む形式です。 -
LangChain: 非構造化コンテンツを構造化された Document オブジェクトに変換。
-
Foundry IQ (Standard): Microsoft の Retrieval およびエージェント ワークフローでの組み込みコンテンツ抽出。
SDK の GA: Python、Java、.NET、JavaScript、TypeScript 向け SDK が一般提供に到達しています。
2026 年 7 月予定の機能（プレビュー）:
- 同期 API for Read / Layout（リアルタイム結果、非同期ワークフロー管理不要）
- Agentic Understanding Mode（複雑なドキュメントへの深い推論）
- Data Zone / Global Zone サポート（データ常駐要件対応）
- カスタム アナライザーのトレーニング改善
- プライバシー ファーストのトレーニング（ラベル付きトレーニング データを CU 側に保存せず、ユーザー自身のストレージを使用）
- グラウンディングとフィールド正規化の改善
- GPT-5 ファミリのより幅広いサポート
- 新しい事前構築済みアナライザーとデジタル専用バリアント
4. Deploy: 本番へデプロイし、利用者の業務へ届ける
4.1 Hosted Agents: 本番エージェント用の管理ランタイム
Build 2026 の Hosted Agents アップデートでは、Foundry Agent Service の中でも特に重要です。Hosted Agents は本番エージェント用の管理ランタイムであり、各セッションが独自のサンドボックスで実行され、専用のコンピューティング、メモリ、ファイル システムを持つようになりました。Hosted Agents は 2026 年 7 月初旬に一般提供予定 と明記されており、現在 20 の Azure リージョンでパブリック プレビュー として提供されています。
Hosted Agents の価値は、エージェント本体のコード以外の周辺責務を Azure プラットフォームに委譲できることです。また、ランタイムはフレームワーク非依存であり、Microsoft Agent Framework、GitHub Copilot SDK、LangGraph などのエージェントを書き換えなしでデプロイできます。単一の Hosted Agent が複数のプロトコルを同時に公開でき、Responses API を Teams / Microsoft 365 配信用の Activity プロトコルへ自動公開する機能も備えています。
- セッション分離
- 専用ファイル システム
- Microsoft Entra ID によるエージェント ID
- OpenTelemetry ベースのトレース
- スケールとアイドル コスト管理
- Responses API、Invocations、WebSocket などのプロトコル対応
4.2 ソース コードデプロイ: コンテナーなしの内側ループ
この機能は Python または .NET のソース コードを ZIP してアップロードし、コンテナー イメージを手作業で作って Push せずに Hosted Agent としてデプロイできます。
デプロイモードには、依存関係を Foundry 側で解決する remote_build と、事前に依存関係をまとめた成果物を動かす bundled の考え方があります。対応ランタイムとして python_3_13、python_3_14、dotnet_10 が示されています。
4.3 Built-in Guardrails: Hosted Agents ランタイム側で安全性を適用
Hosted Agents の Build 2026 アップデートでは、Content Safety に基づく組み込みガードレールも追加されました。これによりユーザープロンプトがエージェントコードへ届く前、またエージェントの応答が利用者へ届く前に評価されます。
エージェントの利用者、入力元、機密データ、外部ツール、現実世界への影響を持つアクション、コード生成 / 実行の有無を質問し、Foundry が適切なリスク カテゴリと介入ポイントを提案する流れが示されています。介入ポイントは、ユーザー入力、ツール呼び出し、ツール応答、出力です。
4.4 長時間実行、Routines、Agent Optimizer
Hosted Agents が OpenClaw や Hermes のような長時間実行の自律エージェントをサポートし、状態とファイル システム アクセスを保持できます。
Routines: スケジュール / イベント駆動のエージェント実行
エージェントが開発で動作した後、多くのチームが運用の壁にぶつかります。エージェントをスケジュールで実行したり、イベントに反応させたり、新しいレコード・メッセージ・ファイルの到着で起動させるには、従来はスケジューラー、Webhook、Logic Apps / Azure Functions、キュー、ストレージ、認証コードを組み合わせる必要がありました。
Routines はこの運用レイヤーを Foundry プロジェクト内に統合します。トリガー（スケジュールまたはイベント）とエージェント アクションを宣言すると、Foundry が呼び出し、権限、接続、実行履歴をエージェント自体と同じプロジェクト内で管理します。
Routines の用途は軽量なエージェント自動化（日次サマリー、ワンタイム リマインダー、定期的チェック）です。分岐、複数エージェント、人間の承認ステップ、複雑な状態管理が必要な場合はワークフローを使います。
具体例として、「GitHub リポジトリを夜通し監視し、朝までに新しい Issue をトリアージし、スタンドアップ前に Teams へサマリーを投稿するエージェント」が実現できます。
Agent Optimizer
Agent Optimizer は、評価データや本番トレースを使って、プロンプト、スキル、モデル、ツール説明の候補改善を生成し、比較評価し、最良候補をデプロイできる改善ループです。Agent Optimizer はプライベート プレビューで、30 日以内にパブリック プレビューへ移行予定です。Agent Optimizer と Procedural Memory を組み合わせることで、設計時の最適化とランタイムの学習を統合した自己改善エージェントが構築可能になります。
これは先進的ですね。エージェント改善を「手でプロンプトを直して動かす」作業から、評価基準、候補生成、比較、監査、ロールバックを持つ運用プロセスへ変えることができるようになります。
4.5 Microsoft 365 Copilot / Teams への公開
Foundry Agent を Microsoft 365 Copilot と Microsoft Teams に公開し、利用者が既存の業務 UI からエージェントを使えるようになります。公開されるのは、エージェントの Stable Endpoint となります。これにより、利用者側には一貫したエージェントとして見せながら、Foundry 側では新しいエージェント バージョンへトラフィックを切り替えられます。
重要な注意点は以下となります。
- 2026-06-03 時点では Early Access Preview
- 組織全体へ公開する場合は Microsoft 365 管理者の承認が必要
- メタデータにはシークレット、API キー、機密情報を含めるのは NG
- Microsoft 365 側では、ファイル アップロードと画像生成が動作しない。Teams では動作する。
- 公開済みエージェントは、ストリーミング応答と引用をサポートしない
- Private Link は Teams / Azure Bot Service 連携ではサポートしない
4.6 Agent 365 と Autopilot Agents
Build 2026 では Assistive Agents、Autonomous Agents に続く第 3 の形として Autopilot Agents が紹介されました。Autopilot Agents は、Entra Agent ID、メール アドレス、Teams プレゼンス、組織図上の位置を持ち、人間と長期的に協働するエージェントです。Autopilot Agents は「会話を開始し、共有ファイルで作業し、アクション アイテムをフォローアップし、時間をかけて人間と協力できる」エージェントです。すべてのアクションは帰属可能、監査可能であり、Agent 365 in Microsoft Admin Center を通じてガバナンスされます。
Microsoft Agent 365 は AI エージェントの IT 管理コントロール プレーンであり、ID、セキュリティ、ガバナンス、ライフサイクル管理を適用するものです。Foundry で作成したエージェントは、自動的に Agent 365 のレジストリに表示されます。
Autopilot 作成については、次の制約があります。
- Foundry Hosted Agent を Agent 365 に Autopilot として Push するユース ケースがある
- 承認後、組織内のユーザーがそのエージェントを「採用」できる
- 現在 UI がなく、コード サンプルを使う必要がある
- Microsoft 365 E7、Azure サブスクリプション、Owner 権限、Foundry User または Cognitive Services User、テナント管理者権限などが前提
4.7 A2A: エージェント間相互運用
Build 2026 では、既存の Outbound A2A に加えて、Incoming A2A がパブリック プレビューとして追加されました。これにより、Foundry エージェントを A2A エンドポイントとして公開し、他のエージェントから発見・呼び出しできるようになります。
主な制約は次のとおりです。
- Microsoft Entra ID 認証が必須です。匿名アクセスやキー ベース認証はサポートされない
- 呼び出し元 ID には対象 Foundry プロジェクトで Foundry User 以上のロールが必要
- A2A v1.0 は JSONRPC のみ対応
- テキスト モダリティのみ対応し、ファイルや非テキスト モダリティは非対応
- ストリーミング応答は非対応
- Incoming A2A には Responses Protocol が必要
エージェントが自社内だけでなく、他チーム、パートナー、他クラウドのエージェントと連携することが可能になりますが、認証、権限、監査、データ境界の設計が必須になります。
5. Operate: 観測、評価、制御、改善
5.1 Observability: 評価、監視、トレースを統合
Foundry の観測性は評価、監視、トレースの 3 つで構成されます。
- 評価: 応答の品質、安全性、信頼性を測る。Coherence、Fluency、Groundedness、Relevance、安全性、ツール呼び出し精度、タスク完了などを評価
- 監視: Azure Monitor Application Insights と統合し、運用メトリック、トークン消費、遅延、エラー率、品質スコアを追跡
- トレース: OpenTelemetry 標準に基づき、LLM 呼び出し、ツール呼び出し、エージェント判断、サービス間依存関係を追跡
Build 2026 では、非 Hosted Agent 向けのトレースと評価は 2026 年春に一般提供になりました。Hosted Agents 向けのトレースと評価は 2026 年 6 月後半に一般提供予定です。また、任意フレームワーク向けのトレースと評価はパブリック プレビューです。
エージェント評価のライフサイクル全体をカバーする 5 つの新しい評価機能がパブリック プレビューとして追加されました。これらは「本番データ → 評価データセット → 評価実行 → 改善」のループを自動化するための部品です。
5.1.1 Multi-turn Evaluation（会話レベル評価）
従来の評価は個々のクエリ→レスポンスのペア（シングルターン）を対象としていたが、エージェントの品質問題の多くは複数ターンにわたる会話の中で発生する。Multi-turn Evaluation はこのギャップを埋める。
5.5.2 User Simulation（ユーザー シミュレーション）
本番デプロイ前にエージェントの振る舞いをテストするための合成会話生成機能。LLM がユーザー役を演じ、シナリオ記述に基づいてエージェントとの複数ターン会話を自動生成する。
用途:
- デプロイ前テスト: 実ユーザー トラフィックなしで多様なシナリオのエージェント挙動を検証
- エッジケース カバレッジ: 自然に発生しにくいが重要なシナリオ（エラー復旧、曖昧入力の解消、マルチステップ タスク）をテスト
- リグレッション テスト: エージェント更新後に既知シナリオの品質劣化がないことを確認
- スケール テスト: 大量の会話を素早く生成してエージェントの限界をテスト
5.5.3 Evaluations with Intelligent Sampling（インテリジェント サンプリング）
本番トレースから「評価に値するサンプル」を自動抽出するアルゴリズム。評価コストを抑えつつ代表性を確保する。評価は高コスト（LLM-as-a-Judge を使用）だが、大半の本番トレースは類似のリクエストの繰り返しであり、全件評価は非効率。少数の代表セットで同等の評価品質を得られることが研究で示されている。
5.5.4 Traces to Dataset（本番トレースから評価データセットを生成）
本番で収集されたトレースを、バージョン管理されたデータセットに変換する機能。「本番の振る舞いをテスト セットにする」ことで、観測→評価ループを閉じる。
5.5.5 Trace Replay and Visualization（トレース再生と可視化）
Trace Replay は、エージェント実行のトレースを対話的に再生し、ステップごとに検査できる UI 機能。Conversation ID または Trace ID から開ける。
2 つのビューが選択可能:
| ビュー | 内容 | 用途 |
|---|---|---|
| 軌跡 | スパン階層をウォーターフォール（時間 or トークン コスト）で表示 | エラー、ハルシネーション、異常に長い / 高コストなインタラクションの特定 |
| User | ユーザーが見たチャット形式で会話を再現。横にスパン ツリーを展開可能 | ユーザー体験の再構築、会話フローの確認 |
再生コントロール:
- Play/Pause で全スパンを順次ハイライト
- Skip で任意のスパンにジャンプ
- 速度調整（1x / 2x / 4x）
- タイムライン スクラバーで任意の時点へシーク
フィルター:
- スパン タイプ別（Chat / Agent / Tool / Conversation）
- トークン消費量別（Low: <500、Medium: 500-2K、High: >2K）
- スパン名のテキスト検索
私自身、Microsoft Agent Framework ワークショップにおいてもトレースを含めた Agent Observability の重要性について主張してきました。今回、Foundry Agent のトレースにグラフビューが追加されたのは非常にうれしく思います。
5.2 ASSERT と Agent Control Specification
Build 2026 の信頼性発表では、ASSERT と Agent Control Specification が中心に置かれています。
ASSERT は、組織のポリシーや要件を具体的な評価に変換し、エージェントの安全性と品質の欠陥を本番前に見つけるオープンソースの評価フレームワークです。LangChain、CrewAI、LiteLLM、OpenAI など、Microsoft Foundry に限定されない環境で使える点が強調されています。
Agent Control Specification は、エージェントのライフサイクルにおける 5 つのチェックポイント、つまり入力、LLM、状態、ツール実行、出力に、決定的な安全・セキュリティ制御を配置するためのオープンな仕様です。YAML で表現され、バージョン管理、監査、フレームワーク非依存の適用を狙っています。ACS は Agent Governance Toolkit の一部として位置づけられ、「エージェント安全性の MCP や A2A」と表現されています。
ACS 介入ポイント（8 箇所）:
エージェントのライフサイクル全体をカバーする 8 つの介入ポイントが定義されています。
agent_startup → input → pre_model_call → post_model_call → pre_tool_call → post_tool_call → output → agent_shutdown
| 介入ポイント | 評価対象 |
|---|---|
agent_startup |
エージェント/セッション起動メタデータ（実行開始前） |
input |
外部リクエストの受信（エージェント ループ開始前） |
pre_model_call |
モデル リクエストのメッセージ、コンテキスト、ツール定義（モデル呼び出し前） |
post_model_call |
モデル応答（ホストがアクションを実行する前） |
pre_tool_call |
具体的なツール呼び出し 1 件（実行前） |
post_tool_call |
具体的なツール結果 1 件（エージェントまたは呼び出し元に返す前） |
output |
組み立てられた最終ユーザー向け応答 |
agent_shutdown |
エージェント/セッション終了メタデータとサマリー |
判定（Verdict）の種類:
ポリシー評価は 5 種類の判定を返せます。
| 判定 | 意味 |
|---|---|
allow |
許可 |
deny |
拒否 |
warn |
警告（実行は継続するがログ記録） |
escalate |
人間への承認エスカレーション |
transform |
ポリシー ターゲットを変換して続行（例: リダクション） |
両者を組み合わせると、次のループになります。
- ASSERT でポリシー違反や失敗点を見つける。
- Agent Control Specification で適切な制御を適切な場所に置く。
- ASSERT を再実行し、改善を確認する。
- Foundry のトレース、評価、ガードレール、監視へつなげる。
この考え方は、ガードレールをプロンプトだけに閉じ込めず、エージェントの実行過程全体に持ち込むための重要な設計となります。
5.3 Guided Guardrail Setup と Rubric
Guided Guardrail Setup（プレビュー）は、エージェントの利用者、入力、データ、ツール、実世界アクション、コード生成の有無を質問し、Foundry がガードレールを提案する機能です。
Rubric は、エージェントの定義やユース ケースに基づいて評価基準を自動生成する Foundry の評価機能です。Rubric は、静的なベンチマークだけでは捕らえにくい、ユース ケース固有の品質、トーン、安全性、コスト、遅延などを重み付きで評価する方向です。ASSERT はオープンソースの安全性重視ツールで開発内側ループ（inner-loop）向け、Rubric は Foundry ネイティブの評価ツールで本番スケールの品質測定・改善向けです。
これにより、評価は「一般的なモデルスコア」から「自社のエージェントが、その業務で、どの程度よい仕事をしたか」へ発展していきます。
5.4 Agent Optimizer と ROI
Agent Optimizer は、トレースと評価を使い、改善候補を生成し、評価し、最良候補を提示する機能です。プロンプト、スキル、モデル、ツール説明が最適化対象です。候補ごとの品質、コスト、回帰を比較し、昇格した候補は新しいバージョンとしてデプロイできます。
Agent ROI は、タスク完了率、時間削減、コスト効率などのビジネス価値を測るプライベート プレビュー機能です。これは、エージェントが「動くか」だけではなく、「投資に見合う業務価値を出しているか」を測るための機能です。
6. Models: モデル選定から運用へ
6.1 Foundry Models の位置づけ
Foundry Models はモデルの発見、比較、評価、デプロイのための統合カタログです。Microsoft、OpenAI、DeepSeek、Hugging Face、Meta などのモデルを含み、11,000 以上のモデルがあります。
Build 2026 では、課題は「モデルにアクセスできるか」ではなく、「どのモデルをどのタスクに使い、どう評価し、どうコストと品質を運用するか」に移ったと述べられました。これは、モデル選定を一度きりの意思決定ではなく、継続的な運用規律（discipline）として扱う考え方です。
モデル運用で見るべき軸は、次の 4 つです。
- Capability: タスクを達成する能力
- Safety: 安全性、ポリシー遵守、禁止事項への耐性
- Latency: 体験上許される遅延
- Cost: 1 タスクあたり、または全体運用としてのコスト
6.2 新しい MAI モデル
Build 2026 では、Microsoft AI の社内開発モデルファミリーとして 7 つ の新モデルが発表されました。すべて第三者モデルからの蒸留なし、クリーンで適切にライセンスされたデータのみで1から学習されています。Maia 200 シリコンとの共同設計により 1.4 倍の効率向上も実現しています。
| モデル | アーキテクチャ / 位置づけ | 主要ベンチマーク |
|---|---|---|
| MAI-Thinking-1 | 35B アクティブ / ~1T 総パラメーター、スパース MoE 推論モデル | SWE-Bench Pro で Claude Opus 4.6 相当。AIME 2025: 97.0%、AIME 2026: 94.5% |
| MAI-Code-1-Flash | 5B アクティブ パラメーター、エージェンティック コーディング特化 | SWE-Bench Pro で Claude Haiku 4.5 に +16pt（51.2% vs 35.2%）。最大 60% 少ないトークンで解決 |
| MAI-Image-2.5 | 画像生成 + 画像編集、Flash バリアント付き | Arena Image Edit #2、Text-to-Image #3。MAI-Image-2 から +75pt |
| MAI-Image-2.5-Flash | MAI-Image-2.5 の高速・低コスト バリアント | 同品質を低レイテンシー・低コストで提供 |
| MAI-Transcribe-1.5 | 43 言語対応の音声→テキスト モデル | FLEURS SOTA（WER 2.4%）。1 時間音声を 15 秒以内で変換 |
| MAI-Voice-2 | 15 言語対応の表現豊かな TTS（日本語✖） | MAI-Voice-1 に対し 72% の選好率。人間の録音と区別不能 |
| MAI-Voice-2-Flash | MAI-Voice-2 の高効率バリアント | 近日提供予定 |
モデルは Foundry に加え、OpenRouter、Fireworks、Baseten でも提供されます。初めて開発者がモデルの重みを自分でチューニングすることも可能になります。
参考: MAI-Image-2 画像生成モデル テスト
6.3 Fireworks AI on Foundry
Build 2026 では、Fireworks AI on Foundry が一般提供になったと発表されました。Fireworks モデルのプレビュー期間中に 17 の S&P 500 企業が利用し、1,760 億トークン以上を処理した実績もあるとのことです。
6.4 Managed Compute、Fine-tuning、Frontier Tuning
Managed Compute、Fine-tuning、Frontier Tuning もモデル運用のアップデートとして発表されました。
Managed Compute: オープン モデル向け GPU Platform-as-a-Service
Managed Compute が Foundry の 3 番目のデプロイ タイプとして発表されています。Pay-per-tokenと Provisioned Throughput（予測可能なフロンティア モデル負荷向け）に加え、オープンソース / カスタム モデルを専用 GPU キャパシティ上でマネージドに運用するための基盤です。
Foundry の 3 つのデプロイ タイプ:
| デプロイ タイプ | 用途 |
|---|---|
| Pay-per-token (Standard) | フロンティアモデルを最も手軽に利用開始できる従量課金 |
| Provisioned Throughput | フロンティアモデルの予測可能な本番負荷 |
| Managed Compute | オープンソース / カスタムモデルを専用 GPU で運用 |
選択項目:
- モデル: Hugging Face Collection（Foundry Model Catalog 内）から選択
- デプロイ テンプレート: ランタイム、GPU 数、コンテキスト長、量子化、レイテンシー vs スループットの事前チューニング済み設定
-
アクセラレーター ファミリー:
A100_80GB、H100_80GB、MI_300_192GB（MI300X はロードマップ）
VM SKU ではなくアクセラレーター ファミリーを選ぶだけで、Foundry が適切な GPU 数をプロビジョニングします。
キャッシュ対応ルーティング:
- 並行度認識負荷分散: インフライト リクエスト数に基づいてインスタンス間に分散
- プロンプト プレフィックス アフィニティ: 共有システム プロンプト、ツール定義、RAG コンテキストを同一インスタンスにルーティングし、KV キャッシュを活用して TTFT を削減
- マルチターン セッション アフィニティ: セッション ID を渡すと同一インスタンスに固定し、セッション内でキャッシュ ヒットを累積
いずれも「できるだけ同じインスタンスに振る」という優先ルールであり、負荷が上限に達した場合は別のインスタンスへ自動的に振り分けられます。
また、Managed Compute デプロイは、admin-connected model として Foundry Agents に接続し、Responses API 経由で利用できます。CognitiveServicesManagementClient。ネイティブ統合（追加ステップ不要）は近日対応予定。
Fine-tuning
Fine-tuning は、プロンプト エンジニアリングだけでは得にくい品質、トークン削減、低遅延を、より小さなモデルや特定タスク向けに実現する手段です。Fine-tuning Developer Tier はホスティング費なしで実験可能な新ティアとして提供されています。
このようなモデルチューニングを実施するモチベーションとしては、プロンプト改善や RAG ではタスク完了率が根本的に足りない場合、大量推論でチューニング済み小モデルに置き換える経済合理性がある場合、誤回答のコストが極めて高く利用者が万単位で投資回収できる場合、ローカルデバイス上で実行する必要がある等が挙げられます。一方で、次世代の汎用モデルがチューニング済みモデルの精度を上回ってくるリスク（モデル世代交代の速さ）は常に念頭に置く必要があり、チューニング投資の回収期間との兼ね合いで判断すべきです。
Frontier Tuning: 強化学習によるカスタム モデル
顧客のワークフロー上で強化学習を行い、汎用モデルを特定業務に最適化する新しいアプローチです。MAI では AI の次のフェーズと位置づけ、「AI に自社の仕事の仕方を教える」ことができるようになります。
3 つの構成要素:
- 継続的に進化する環境（RLE）: マネージドな強化学習環境で学習と推論の両方を実行。学習時はリアル ワークフロー、ツール使用、評価シグナルから本番に影響を与えずに学習。推論時は Microsoft AI と OpenAI の複数フロンティア / ファインチューンド モデルをターンごとに探索し、より強い候補パスを見つけてから回答を返す。インタラクションごとに継続改善。
- 顧客のデータ、ドメイン知識、ワークフロー: ビジネス データ、プロセス、慣例、用語、ワークフローを RLE に持ち込む。データ サイエンスの学位は不要で、ガイド付きの簡単なアプローチでチューニングを開始できる。
- チューニングされたモデル、スキル、ハーネス: 出力はチューニング済みモデル、エンベディング、スキル、オーケストレーション ロジック、ランタイム ハーネス。すべて顧客のデータ上で、顧客のコントロール下で、コンプライアンス境界内で動作。アクセス制御は元データの権限を継承。
実績:
- Microsoft HR: タスク完了率が 13% → 87% に向上。現在他の HR ワークフローに拡大中
- Excel 向け MAI チューニング モデル: GPT 5.4 に匹敵する品質を 最大 10 倍のコスト効率 で達成
- 市場リーダー企業: 厳格なエンタープライズ基準で全モデル中 最高の勝率 を約 10 倍低いコスト で実現
提供形態:
- 現在: プライベート プレビュー（Forward Deployed Engineers 経由。シナリオ定義、評価基準設定、チューニング実行、エージェント納品をエンドツーエンドで支援）
- 今後: Microsoft Copilot Studio で RLE アクセスとチューニングを提供予定。Microsoft Foundry でもモデル（MAI モデル含む）とランタイム動作のチューニングを提供予定
🎉Foundry IQ / Azure AI Search の Build 2026 Updates
参考
今月は様々なパートナー様と Build 2026 Update Recap ができることを楽しみにしています。