<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Toolboxes | The .NET Blog</title><link>https://thedotnetblog.com/ja/tags/toolboxes/</link><description>Articles, tutorials and insights from the .NET community.</description><generator>Hugo</generator><language>ja</language><managingEditor>@thedotnetblog (The .NET Blog)</managingEditor><webMaster>@thedotnetblog</webMaster><lastBuildDate>Sat, 18 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://thedotnetblog.com/ja/tags/toolboxes/index.xml" rel="self" type="application/rss+xml"/><item><title>Microsoft Foundry June 2026: From Feature Drops to a Governed Agent Platform</title><link>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/microsoft-foundry-june-2026-from-features-to-platform/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><author>Emiliano Montesdeoca</author><guid>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/microsoft-foundry-june-2026-from-features-to-platform/</guid><description>6月の Foundry アップデートはプラットフォームの移行を示している。配布、ツール、メモリ、可観測性、最適化が、エンタープライズ対応のエージェント運用スタックへと収束している。</description><content:encoded>&lt;p&gt;2026年6月の Foundry ウェーブは単なる毎月のダイジェストではない。「クールなエージェントを構築する」から「エージェントをガバナンスされたエンタープライズシステムとして運用する」への成熟の移行を示している。その区別は、個々の機能よりも重要である。&lt;/p&gt;
&lt;p&gt;オリジナルソース: &lt;a href="https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/"&gt;https://devblogs.microsoft.com/foundry/whats-new-in-microsoft-foundry-june-2026/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;3つのアップデートがそのシフトを定義している。第一に、Microsoft 365 Copilot と Teams へのエージェント公開が GA に達し、配布がカスタム統合プロジェクトから意見を持ったデプロイレーンへと移行した。第二に、Toolboxes はツール検索とルーティンを含む、より強力な発見と実行制御を得た。第三に、可観測性と最適化が、後付けではなく意図的なクローズドループになった。&lt;/p&gt;
&lt;p&gt;私の見解: これがこのリリースで最も重要なパターンである。&lt;strong&gt;トレーシング、評価、最適化、制御されたロールアウト&lt;/strong&gt;は、非決定論的システムのための最小 viable 運用モデルを形成する。これらのうちひとつしか持っていなければ、テレメトリかチューニングはあっても、ガバナンスはない。&lt;/p&gt;
&lt;p&gt;Foundry 内部の Claude GA も戦略的だが、主にモデル品質のためではない。より大きな価値はエンタープライズ統合である: Entra 認証、RBAC、課金の継続性、ポリシー整合性。ダイレクトモデルエンドポイントから Foundry に移行するチームは、これを単なるプロバイダー交換ではなく、運用統合として捉えるべきである。&lt;/p&gt;
&lt;p&gt;Autopilot エージェントは有望だが、組織は冷静なアーキテクチャ上の選択をもってアプローチすべきである。Teams での共有スペースコラボレーションは生産性を解放できるが、ID、権限、アカウンタビリティの複雑さを急速に高める。広範なデプロイの前に、境界のあるスコープと厳格な承認チェックポイントから始めること。&lt;/p&gt;
&lt;p&gt;実践的推奨:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;すでにパイロット中であれば&lt;/strong&gt;、機能拡張よりも計装を優先する。まず GenAI トレーシングを配線する。次に、汎用的なモデルメトリクスではなく、ビジネス成果に結びついた評価スイートを確立する。その後でのみ、オプティマイザーループとプロモーションワークフローを実行する。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Toolbox 中心のエージェントの場合&lt;/strong&gt;、カタログが成長するにつれてコンテキストノイズと誤ったツール選択リスクを減らすために、早期にツール検索を有効にする。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;メモリ対応エージェントの場合&lt;/strong&gt;、TTL と保持ポリシーを事前に定義する。ライフサイクル制御のないメモリはコンプライアンス負債になる。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;私が導き出せる最も意見を持った結論はこれである: Foundry は今や「どのモデルを選ぶか？」というよりも、「&lt;strong&gt;エージェント動作を管理されたライフサイクルとして実行できるか？&lt;/strong&gt;」に関するものである。2番目の問いにうまく答えるチームは、モデルの変動に容易に適応できる。モデルランキングに固執するチームは、四半期ごとに脆弱なスタックを再構築し続けるだろう。&lt;/p&gt;
&lt;p&gt;6月のリリースはひとつのことを明確にしている。Foundry は、単なる開発ツールキットではなく、&lt;strong&gt;AI システムのための運用プラットフォーム&lt;/strong&gt;になりつつある。それは構築するのがより難しいプロダクトであり、採用するにははるかに価値のあるものである。&lt;/p&gt;</content:encoded></item></channel></rss>