Microsoft FoundryでAIエージェントを運用している場合、今回の「Outcome-driven learning systems: Enterprise RL with OpenEnv and Foundry」は、すぐに既存環境の設定変更を迫る更新というより、エージェントを“回答するAI”から“業務成果に向けて改善し続ける学習システム”へ進めるための設計方針を示したNoticeとして捉えるのが適切です。
確認すべきポイントは、OpenEnvによる強化学習環境、Agent Optimizer、評価ルーブリック、Hosted Agents、Foundry IQ、Memory、Toolboxes、Managed Compute、post-trainingをどのように組み合わせるかです。特に、PoC段階のAIエージェントを本番運用に近づけたいチームは、「評価基準を先に作る」「安価な非パラメトリック改善から始める」「重みを変える学習は費用対効果を見て判断する」という順序を確認しておきましょう。Microsoft Foundry Blog上の掲載日は2026年6月18日ですが、管理通知や日本時間で2026年6月19日公開・更新分として扱われる場合があります。(Microsoft for Developers)
Outcome-driven learning systems: Enterprise RL with OpenEnv and Foundry は何が変わった？
今回の内容は、Microsoft Foundryに単一の新ボタンが追加されたというより、エンタープライズ向けAIエージェントを継続的に改善するための全体像を整理したものです。
公式ブログでは、Microsoft Foundryを使って「業務成果に対して改善する学習ループ」を構築する考え方が示されています。中心になるのは、エージェントが業務を練習するための環境、結果を判定する評価、評価結果をもとに改善する最適化、必要に応じてモデルの重みまで更新するpost-trainingです。(Microsoft for Developers)
重要なのは、AIエージェントの価値を「どのモデルを使っているか」だけで判断しない点です。Microsoftは、モデル自体は交換可能な部品であり、企業側が持つべき資産は業務フロー、評価基準、ツール、記録、改善ループだと説明しています。(Microsoft for Developers)
今回の変更点を短く整理
| 観点 | 変更・注目点 | Microsoft Foundry利用者が見るべきポイント |
|---|---|---|
| 学習システムの考え方 | エージェントを一度作って終わりではなく、業務成果に向けて改善する仕組みとして扱う | チャット品質ではなく、業務結果を評価する指標を用意しているか |
| OpenEnv | MicrosoftがOpenEnvコミュニティに参加し、エンタープライズ向けの学習環境との接続を重視 | 自社ワークフローをOpenEnv互換の環境として表現できるか |
| 評価とルーブリック | 環境に評価基準を組み込み、エージェントの成否を判定する | 「正しい完了条件」を明文化できているか |
| Agent Optimizer | プロンプト、スキル、ツール説明、モデル選択などを改善対象にする | まず重みを変えずに改善できる余地を確認する |
| post-training | 必要に応じてモデルの重みを更新し、業務特化の挙動をモデルに取り込む | コスト、データ管理、再現性、検証手順を事前に決める |
| ACA Sandbox | Hosted AgentsやOpenEnv環境を分離されたサンドボックスで扱う考え方 | ネットワーク、シークレット、セッション分離を確認する |
影響を受ける対象者
今回のNoticeは、Microsoft Foundryを使うすべての管理者が即対応すべき障害対応ではありません。ただし、AIエージェントを本番業務に組み込んでいる、または組み込もうとしている組織には影響があります。
| 対象者 | 影響度 | 確認すべきこと |
|---|---|---|
| Microsoft Foundry管理者 | 中 | Hosted Agents、評価、権限、ネットワーク分離、監査ログの運用方針 |
| AIエージェント開発者 | 高 | 評価データセット、ルーブリック、ツール定義、スキル定義の整備 |
| データサイエンティスト・MLエンジニア | 高 | 非パラメトリック改善とpost-trainingの使い分け |
| セキュリティ担当者 | 中〜高 | サンドボックス、外部通信、機密情報、ツール実行権限 |
| 業務部門の責任者 | 中 | AIエージェントに任せる業務の成功条件と失敗時の扱い |
| 既存のチャットボット運用担当者 | 中 | 単純なFAQ応答から、業務完了型エージェントへ移行できるか |
特に影響が大きいのは、問い合わせ対応、契約確認、請求照合、社内申請、運用監視、ナレッジ検索など、結果の良し悪しを業務基準で判定できる領域です。
まず押さえたいキーワード
Enterprise RLとは何か
Enterprise RLは、企業業務の文脈で使う強化学習の考え方です。一般的な強化学習のようにゲームスコアを最大化するのではなく、請求書を正しく照合できたか、ポリシーに違反しなかったか、必要な根拠を提示できたかといった業務成果を評価します。
Microsoft Foundry Blogでは、エージェントが練習する場所を「environment」、結果を判定する仕組みを「eval」、評価の中心になる採点基準を「rubric」として説明しています。たとえば「契約条項を引用して回答したか」「対象外の依頼を拒否したか」「社内規定に沿ってエスカレーションしたか」といった条件を点数化します。(Microsoft for Developers)
OpenEnvとは何か
OpenEnvは、AIエージェントが操作する実行環境を標準的に扱うための仕組みです。OpenEnvのGitHubリポジトリでは、reset()、step()、state()のようなGymnasium風のAPIで、エージェント向けの実行環境を扱うと説明されています。(GitHub)
Microsoft Foundryの文脈では、OpenEnvが「モデル」「エージェントの実装」「トレーナー」「業務環境」を疎結合にする役割を持ちます。これにより、特定のモデルや特定の学習基盤に閉じず、企業側が学習ループを持ちやすくなります。
ただし、OpenEnvはGitHub上でearly development、つまり実験的な段階であり、バグや未完成機能、API変更の可能性があると明記されています。すぐに基幹業務へ直結させるのではなく、検証環境で仕様変更に耐えられる形から始めるのが安全です。(GitHub)
Agent Optimizerとは何か
Agent Optimizerは、Hosted Agentを評価基準に照らして実行し、より良い設定候補を作り、スコアを比較して改善案を選べるようにする仕組みです。Microsoftの説明では、システムプロンプト、スキル、ツール説明、モデル選択などを改善対象にできます。(Microsoft for Developers)
ここで重要なのは、最初からモデルの重みを変えないことです。プロンプトの改善、ツール説明の見直し、スキルの追加、モデル選択の変更だけで改善できるなら、その方が速く、安く、運用リスクも抑えられます。
Microsoft Foundry利用者がすぐ確認したい項目
評価基準を「感想」ではなく「合否条件」にしているか
AIエージェントの改善では、「なんとなく良い回答だった」では運用に使えません。業務で必要なのは、合格・不合格を判断できる基準です。
たとえば問い合わせ対応エージェントなら、以下のように分解します。
| 悪い評価基準 | 良い評価基準 |
|---|---|
| 回答が親切か | 注文番号を確認してから配送状況を調べたか |
| 内容が正しいか | 保証対象期間、購入日、製品カテゴリを確認したか |
| 安全に回答したか | 医療・電気工事など専門家対応が必要な内容を拒否したか |
| 役に立つか | 次の手続き、期限、問い合わせ先を提示したか |
Microsoft Learnのエージェント評価ドキュメントでも、デプロイ前に品質や安全基準を満たすかを確認するため、評価を開発ワークフローに組み込む重要性が説明されています。(Microsoft Learn)
Hosted Agentsの分離と実行環境を確認する
今回の学習ループは、エージェントがツールを使い、ファイルを扱い、場合によってはコードを実行する前提に近づいています。そのため、従来のチャットボットよりも実行環境の分離が重要です。
Microsoft FoundryのHosted Agentsでは、各エージェントセッションに専用の分離サンドボックス、永続ファイルシステム、スケールトゥゼロ、バージョン管理、ロールアウトなどが説明されています。(Microsoft for Developers)
確認すべきポイントは次の通りです。
| 確認項目 | 見るべき理由 |
|---|---|
| セッション分離 | ユーザーAのファイルや状態がユーザーBに混ざらないようにするため |
| 外部通信 | ツール呼び出し経由で不要な外部送信が起きないようにするため |
| シークレット管理 | APIキーや接続文字列をエージェントに不用意に渡さないため |
| ロールアウト | 最適化後のエージェントを一気に全ユーザーへ出さないため |
| ロールバック | 改善候補が一部ケースで悪化した場合に戻せるようにするため |
まず非パラメトリック改善から始める
公式ブログでは、学習の方法を大きく2つに分けています。1つは、モデルの重みを変えずに、プロンプト、スキル、ツール説明、コンテキスト取得、モデル選択を改善する方法です。もう1つは、post-trainingでモデルの重みを更新する方法です。(Microsoft for Developers)
実務では、次の順序が現実的です。
| 順序 | 取り組み | 判断基準 |
| -: | —————— | ————————— |
| 1 | 評価データセットとルーブリックを作る | 業務上の成功・失敗を採点できるか |
| 2 | プロンプトとツール説明を改善する | 誤ったツール選択や手順漏れが減るか |
| 3 | スキルを追加する | 定型的な業務手順を安定して実行できるか |
| 4 | モデル選択を比較する | 品質とコストのバランスが改善するか |
| 5 | post-trainingを検討する | 推論コスト、応答速度、業務特化の必要性が投資に見合うか |
最初からpost-trainingに進むと、評価基準が曖昧なまま学習してしまい、改善したのか、単に特定データに過剰適合したのか判断しにくくなります。まずは「重みを変えない改善」で限界を見極めることが重要です。
運用上の注意点
Noticeだからといって無視しない
分類がNoticeの場合、すぐに障害が起きる更新や破壊的変更とは限りません。しかし今回の内容は、Microsoft FoundryでAIエージェントを本番化する組織にとって、今後の設計方針に関わります。
特に、今のエージェント運用が次の状態に当てはまる場合は、見直し対象です。
| 現在の状態 | 起きやすい問題 | 見直しポイント |
|---|---|---|
| プロンプトを手作業で直している | 改善理由が残らず、品質が再現しない | 評価と最適化の履歴を残す |
| 本番ログを評価に使っていない | 実際の失敗パターンが改善されない | トレースと評価データを結び付ける |
| 成功条件が業務部門に依存している | 開発者だけでは合否判断できない | 業務部門とルーブリックを作る |
| ツール権限が広すぎる | 誤操作や情報漏えいのリスクが増える | 最小権限とサンドボックス分離を確認する |
| モデル変更だけで改善しようとしている | コスト増の割に業務品質が上がらない | 先にプロンプト、スキル、ツール説明を改善する |
ルーブリックは業務担当者と一緒に作る
AIエンジニアだけで評価基準を作ると、技術的には自然な回答でも、業務上は不合格というケースが起きます。
たとえば契約確認エージェントでは、「該当条文を引用している」「最新版の契約書を参照している」「例外条件を見落としていない」「法務確認が必要な場合に自動判断しない」といった条件が必要です。これらは業務担当者や法務担当者の知識なしでは定義しにくい項目です。
Microsoft FoundryでOutcome-driven learningを進めるなら、最初に作るべきものは高度な学習コードではなく、業務上の合格条件を文章化した評価表です。
OpenEnv互換環境は小さく始める
OpenEnvは、実際の業務環境に近い「練習場」を作るための考え方として有用です。一方で、実験的な段階の要素も含まれるため、最初から複雑な基幹業務全体を環境化するのは避けた方が安全です。(GitHub)
最初の検証では、次のような範囲に絞ると進めやすくなります。
| 小さく始めやすい業務 | 理由 |
|---|---|
| FAQからの回答生成 | 正解例を作りやすい |
| 社内申請の入力チェック | 合否条件を定義しやすい |
| チケット分類 | 過去データと比較しやすい |
| ナレッジ検索の根拠提示 | 参照文書の有無で評価しやすい |
| 定型レポート作成 | 出力フォーマットを採点しやすい |
逆に、法的判断、医療判断、大規模な自動発注、権限変更など、失敗時の影響が大きい業務は、評価と監査が整うまで人間の承認を挟むべきです。
管理者向けチェックリスト
Microsoft Foundry管理者は、今回のNoticeを受けて以下を確認しておくと、今後のエージェント改善基盤を整えやすくなります。
| チェック項目 | 確認内容 |
|---|---|
| 評価データ | 本番ログ、合成データ、代表的な失敗ケースを評価に使えるか |
| ルーブリック | 業務部門が合否を説明できる基準になっているか |
| 権限 | エージェント、ツール、データソースのアクセス権が最小化されているか |
| サンドボックス | セッション分離、ファイル永続化、外部通信制御を理解しているか |
| 監査 | 最適化前後の設定、評価結果、デプロイ履歴を追跡できるか |
| ロールバック | 改善版エージェントに問題があった場合に戻せるか |
| コスト | 評価実行、モデル比較、post-training、Managed Computeの費用を見積もれるか |
| プレビュー条件 | Agent Optimizerなどの利用可否、リージョン、テナント条件を確認しているか |
Agent Optimizerは、2026年6月3日のMicrosoft Foundry Blogでprivate previewとして紹介され、30日後のpublic previewが予告されていました。実際の利用可否は、利用中のテナント、リージョン、プレビュー参加状況、Microsoftからの最新案内で確認する必要があります。(Microsoft for Developers)
実務での進め方
PoC中のチーム
PoC段階なら、まず評価データセットを作ることが最優先です。デモでよく見える回答ではなく、実際に失敗しやすいケースを10〜30件程度集めます。
例として、社内問い合わせエージェントなら次のようなケースを含めます。
| ケース | 評価観点 |
|---|---|
| 曖昧な質問 | 追加確認を行うか |
| 権限外の依頼 | 拒否または担当部署へ誘導するか |
| 古い規定に基づく質問 | 最新情報を参照できるか |
| 複数条件がある申請 | 手順を漏らさず案内できるか |
| 回答できない質問 | 無理に推測しないか |
この段階では、post-trainingよりも評価、プロンプト改善、ツール説明の見直しを優先します。
本番運用中のチーム
すでにMicrosoft Foundryでエージェントを運用している場合は、トレースと評価の接続を確認します。ユーザーからの苦情、手戻り、誤回答、エスカレーション漏れを評価データに変換し、改善前後を比較できるようにします。
本番運用では、改善版を即時に全ユーザーへ展開しないことも重要です。Hosted Agentsのバージョン管理やロールアウトの考え方を使い、限定ユーザー、限定業務、限定時間で検証してから広げる方が安全です。(Microsoft for Developers)
post-trainingを検討するチーム
post-trainingは、モデルの重みを変えるため、プロンプト改善よりも慎重に扱うべきです。検討する価値があるのは、以下のような場合です。
| post-trainingを検討しやすい条件 | 理由 |
|---|---|
| 同じ業務を大量に処理する | 推論コストや応答速度の改善効果が出やすい |
| 業務固有の判断手順が多い | プロンプトだけでは安定しにくい |
| 小型モデルで十分な品質を出したい | 運用コストを下げられる可能性がある |
| データと評価基準が整っている | 学習結果を検証しやすい |
| モデルの挙動を自社で管理したい | 外部API依存を減らす判断材料になる |
一方で、評価データが少ない、成功条件が曖昧、業務例外が多すぎる、セキュリティレビューが終わっていない場合は、post-trainingより前に運用設計を固めるべきです。
今回のNoticeから読み取れる今後の方向性
今回のMicrosoft Foundry Blogから読み取れる大きな方向性は、AIエージェント開発が「単発のプロンプト作成」から「評価・最適化・学習・再デプロイを回す運用」へ移っていることです。
これまでのAI導入では、より高性能なモデルへ切り替えることが改善策になりがちでした。しかし今後は、自社の業務プロセスを環境として定義し、自社の成功条件で評価し、その結果をもとにエージェントを改善する力が重要になります。
Microsoft Foundry利用者にとって、次に取るべき行動は明確です。まず、現在運用している、またはPoC中のエージェントを1つ選びます。次に、そのエージェントの成功条件を5〜10個の評価項目に分解します。そのうえで、プロンプト、スキル、ツール説明、モデル選択の順に改善できる余地を確認します。
今回のNoticeは、今すぐ全システムを作り替える合図ではありません。むしろ、Microsoft FoundryでAIエージェントを本番運用するために、評価と改善の土台を先に整えるべきだと知らせる内容です。最初の一歩は、モデル選定ではなく、自社業務にとって「正しく完了した」と言える条件を明文化することです。
コメント