2026年6月の Foundry ウェーブは単なる毎月のダイジェストではない。「クールなエージェントを構築する」から「エージェントをガバナンスされたエンタープライズシステムとして運用する」への成熟の移行を示している。その区別は、個々の機能よりも重要である。
オリジナルソース: https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/
3つのアップデートがそのシフトを定義している。第一に、Microsoft 365 Copilot と Teams へのエージェント公開が GA に達し、配布がカスタム統合プロジェクトから意見を持ったデプロイレーンへと移行した。第二に、Toolboxes はツール検索とルーティンを含む、より強力な発見と実行制御を得た。第三に、可観測性と最適化が、後付けではなく意図的なクローズドループになった。
私の見解: これがこのリリースで最も重要なパターンである。トレーシング、評価、最適化、制御されたロールアウトは、非決定論的システムのための最小 viable 運用モデルを形成する。これらのうちひとつしか持っていなければ、テレメトリかチューニングはあっても、ガバナンスはない。
Foundry 内部の Claude GA も戦略的だが、主にモデル品質のためではない。より大きな価値はエンタープライズ統合である: Entra 認証、RBAC、課金の継続性、ポリシー整合性。ダイレクトモデルエンドポイントから Foundry に移行するチームは、これを単なるプロバイダー交換ではなく、運用統合として捉えるべきである。
Autopilot エージェントは有望だが、組織は冷静なアーキテクチャ上の選択をもってアプローチすべきである。Teams での共有スペースコラボレーションは生産性を解放できるが、ID、権限、アカウンタビリティの複雑さを急速に高める。広範なデプロイの前に、境界のあるスコープと厳格な承認チェックポイントから始めること。
実践的推奨:
- すでにパイロット中であれば、機能拡張よりも計装を優先する。まず GenAI トレーシングを配線する。次に、汎用的なモデルメトリクスではなく、ビジネス成果に結びついた評価スイートを確立する。その後でのみ、オプティマイザーループとプロモーションワークフローを実行する。
- Toolbox 中心のエージェントの場合、カタログが成長するにつれてコンテキストノイズと誤ったツール選択リスクを減らすために、早期にツール検索を有効にする。
- メモリ対応エージェントの場合、TTL と保持ポリシーを事前に定義する。ライフサイクル制御のないメモリはコンプライアンス負債になる。
私が導き出せる最も意見を持った結論はこれである: Foundry は今や「どのモデルを選ぶか？」というよりも、「エージェント動作を管理されたライフサイクルとして実行できるか？」に関するものである。2番目の問いにうまく答えるチームは、モデルの変動に容易に適応できる。モデルランキングに固執するチームは、四半期ごとに脆弱なスタックを再構築し続けるだろう。
6月のリリースはひとつのことを明確にしている。Foundry は、単なる開発ツールキットではなく、AI システムのための運用プラットフォームになりつつある。それは構築するのがより難しいプロダクトであり、採用するにははるかに価値のあるものである。
