Foundry | The .NET Blog

Microsoft Foundry 2026年4月: Foundry Local GA、GPT-5.5、HyperlightによるCodeAct

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Microsoft Foundryにとって忙しい月でした。最も重要なアナウンスをご紹介します。

Foundry Localが一般提供開始

Foundry Local — MicrosoftのクロスプラットフォームのローカルAIランタイム — がWindows、macOS（Apple Silicon）、Linux x64でプレビューからGAになりました。開発者向けSDKを備えた、本番環境対応のローカルモデル推論です。バージョン1.1では文字起こし、embeddings、Responses APIのサポートが追加されています。

GPT-5.5

GPT-5ファミリーの最新モデルがFoundryで利用可能になりました。Tier 5およびTier 6サブスクリプションのデフォルトクォータ。以前のGPT-5バリアントで作業していた場合、ユースケースに合わせて評価する価値があります。

FoundryでのAgent Frameworkトレーシング

今月、2つのトレーシング機能がプレビューとして提供されます：

Microsoft Agent Frameworkトレーシング — MAFエージェントがFoundryにOpenTelemetryトレースを送信できるようになりました。エージェントの動作をデバッグし、多段階実行をトレースし、ツール呼び出し全体の遅延とエラーを表面化させます。これは実際のギャップを埋めます：何を返したかだけでなく、エージェントが本番で実際に何をしたかを知ること。

ホステッドエージェントトレーシング — ホステッドエージェントのセッション、ツール呼び出し、実行ステップもFoundryトレースに表示されます。同じオブザーバビリティストーリーがホステッドティアにも拡張されます。

HyperlightによるCodeAct（Alpha）

これは技術的に最も興味深い追加機能です：Agent FrameworkがHyperlightマイクロ仮想マシン内でPythonコードを実行できるようになりました。

CodeActはエージェントがツールとしてPythonコードを生成して実行するパターンです。明らかな懸念はセキュリティ — モデルが生成したコードを実行しています。HyperlightのマイクロVMはネイティブに近い起動時間でプロセスレベルの隔離を提供し、フルコンテナやVMのオーバーヘッドなしでサンドボックスコード実行を実用的にします。

コード実行が必要なエージェントワークフローにとって、これはホストプロセスでコードを実行するよりも大幅なセキュリティ改善です。

エージェント監視ダッシュボード（プレビュー）

トークン使用量、遅延、実行成功率、エバリュエータースコアを1つのビューに組み合わせた統合オペレーションダッシュボード。通常のオブザーバビリティダッシュボードとの違い：オペレーションメトリクスとともに評価結果が含まれているため、「エージェントが遅くなっている」と「エバリュエータースコアが下がった」を相関させたり、関係ないことを確認したりできます。

継続的評価カスタムエバリュエーター（プレビュー）

独自のコードベースまたはプロンプトベースのエバリュエーターを継続的評価パイプラインに持ち込めるようになりました。以前は、継続的評価は組み込みエバリュエーターに限定されていました。カスタムエバリュエーターを使用すると、本番監視ループでチーム固有の品質基準を適用できます。

コントロールプレーンのエージェントインベントリ

FoundryコントロールプレーンのOperate ビューで、サブスクリプション全体のすべてのサポートされているエージェントが表示されるようになりました：Foundryエージェント、Azure SRE Agent、Logic Appsエージェントループ、および登録済みカスタムエージェント。何がどこにデプロイされているかを把握するための1つのビュー。

元の投稿：What’s new in Microsoft Foundry | April 2026

あなたのローカル MAF エージェントが本番環境の家を手に入れました

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

エージェントをローカルで動作させることは楽しい部分です。難しい部分はその後のすべてです：正気を保ちながらデプロイし、セッションを管理し、アイデンティティを設定し、可観測性を配線する。通常、これは多くのカスタムインフラの「接着剤」を意味します。

Foundry Hosted Agents は、Microsoft Agent Framework (MAF) ユーザーにとってそのような接着剤の大部分を取り除いてくれました。

Foundry Hosted Agents が実際に何をするか

MAF エージェントを Foundry Hosted Agents にデプロイすると、プラットフォームは驚くほど長いリストのことを処理してくれます。それを自分で構築する必要がなくなります：

ゼロへのスケール — アイドル時にコストがかからず、自動的に起動します
セッションごとの VM 分離サンドボックス — 各ユーザーセッションがスケールダウンイベントを乗り越えるファイルシステム永続性を持つ独自のサンドボックスを取得します
組み込み Entra ID — 各エージェントが Foundry モデル、Toolbox、Azure サービスをシークレットをイメージに焼き付けずに呼び出せる独自のアイデンティティを取得します
バージョン管理されたデプロイメント — 各デプロイメントが不変のスナップショットで、blue/green とカナリアロールアウトサポートがあります
設定不要の可観測性 — APPLICATIONINSIGHTS_CONNECTION_STRING が実行時に注入されるため、MAF の OpenTelemetry トレースが App Insights に自動的に流れます

最後のものは本当に便利です。追加の配線なし、追加の設定なし。トレースがただ表示されます。

コードの違いは最小限

この統合で最も気に入っているのはこれです。エージェントを書き直す必要はありません。ただラップするだけです：

.NET の場合：

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Python の場合：

server = ResponsesHostServer(agent)
server.run()

それだけです。ローカルでテストしたのと同じロジックが本番環境で実行されます。プラットフォームはセッション管理、アイデンティティ、スケーリングインフラでそれをラップします。

2 つのプロトコル、1 つのエージェント

Hosted Agents は 2 つのエンドポイントスタイルをサポートします：

Responses (/responses) — OpenAI 互換、会話履歴とストリーミングを管理します。チャット形式のエージェントの良いデフォルト。
Invocations (/invocations) — リクエスト/レスポンススキーマを定義します。非会話的なワークフローに適しています。

会話のように見えるものを構築している場合は、Responses から始めてください。構造化された入力を受け取り、構造化された出力を返す API 形式のエージェントを構築している場合は、Invocations が柔軟性を提供します。

`azd` を使ったデプロイフロー

MAF エージェントで azd up を実行すると：

オプションで Foundry プロジェクトを作成してモデルをデプロイ
コードをパッケージ化して Azure Container Registry にイメージをプッシュ
ACR イメージからコンピューティングをプロビジョニング
エージェントに専用の Entra ID を割り当て
安定したエンドポイントを公開 (https://{project_endpoint}/agents/{agent_name})
それ以降はすべてを処理

セッションは最大 30 日間持続します。アイドル状態のコンピューティングは 15 分後にデプロビジョニングされ、次のリクエスト時に透過的に復元されます。エージェントの観点からは、何も変わっていません。

まとめ

「ローカルで動作している」から「本番で実行されている」までの距離は、AI エージェントにとって歴史的に長くて辛いものでした。Foundry Hosted Agents + MAF はそのギャップを大幅に縮めます。Agent Framework で構築されたローカルエージェントがすでにある場合は、今日試す価値があります。

チームは GA が近いと言っています — これは現在プレビュー中です。始めるには MAF Hosted Agent 統合ドキュメントと .NET サンプルを確認してください。

元の記事: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Foundry Local 1.1: リアルタイム文字起こし、Embeddings、Responses API

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 はコンセプトを証明しました：開発者フレンドリーな SDK で Windows、macOS（Apple Silicon）、Linux x64 上で AI モデルをローカルで実行できること。バージョン 1.1 は多くの実際の本番ユースケースをカバーする 3 つの機能を追加しています。

ライブ音声文字起こし

最も重要な新機能：マイクから直接リアルタイムで音声をテキストにストリーミング変換。字幕、音声 UI、会議の文字起こし、アクセシビリティツール — すべてクラウド依存なしでローカル実行されます。

API はセッションベースで、結果が到着するとすぐに送信し、中間テキストと確定テキストを区別するための is_final マーカーを使用します。JavaScript、C#、Python、Rust のすべての言語バインディングで利用可能です。

カタログからストリーミング音声モデルを読み込み、音声設定（サンプルレート、チャンネル、言語）でセッションを作成し、起動し、生の PCM オーディオチャンクをプッシュして、結果の非同期ストリームを消費します。投稿には Python と C# の完全な例があります。

テキスト Embeddings

セマンティック検索、RAG パイプライン、クラスタリング、類似性マッチング — これらすべてに embeddings が必要です。Foundry Local 1.1 は embedding モデルのサポートを追加し、クラウドエンドポイントにデータを送信せず、同じ SDK からローカルでベクターを生成できます。

データの居住性が重要なアプリケーションや機密コンテンツを処理する場合、ローカルでの embedding 生成は重要な機能です。

Responses API

Foundry Local は Responses API — エージェント的インタラクションのために設計された構造化インターフェース — をサポートするようになりました。これにより追加されるのは：

ツール呼び出し — ローカルで実行中のモデルが定義したツールを呼び出すことを可能にします
マルチモーダルビジョン-言語入力 — ビジョン対応モデルに画像 + テキストを渡します
標準 API 形式と互換性があるため、OpenAI の Responses API を対象とした既存のエージェントがローカルモデルに対して動作します

パッケージサイズの改善

2 つの変更により JavaScript パッケージサイズが削減されます：

koffi FFI レイヤーがカスタム Node-API C アドオンに置き換えられました
WebGPU 実行プロバイダーは別のプラグインとして配布されるため、GPU アクセラレーションを必要としないアプリケーションはサイズコストを支払う必要がありません

C# SDK は .NET の幅広い互換性のためにより低いフレームワークバージョンをターゲットとするようになりました。

なぜこれが重要か

3 つの機能 — 文字起こし、embeddings、ツール呼び出し — は多くの AI アプリケーションのコアビルディングブロックをカバーしています。これらをローカルで実行することは以下を意味します：

インターネット不要
トークンコストなし
データがマシンを離れない
ネットワーク状態に関わらず一定の遅延

Foundry Local は、エッジシナリオ、プライバシーに敏感なワークロード、オフラインアプリケーション、または開発中にクラウド依存を避けたいあらゆるものに適しています。

元の投稿：Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

GPT-5.5 が Azure Foundry に登場 — .NET 開発者が知っておくべきこと

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

MicrosoftはGPT-5.5がMicrosoft Foundryで一般提供開始したと発表しました。Azureでエージェントを構築してきた方にとって、これが待ち望んでいたアップデートです。

GPT-5 の進化

GPT-5: 推論と速度を1つのシステムに統合
GPT-5.4: より強力なマルチステップ推論、企業向けエージェント機能
GPT-5.5: より深い長コンテキスト推論、信頼性の高いエージェント実行、トークン効率の向上

実際に何が変わったか

エージェントコーディングの向上: GPT-5.5は大規模なコードベース全体でコンテキストを保持し、アーキテクチャ上の障害を診断し、テスト要件を予測します。修正が他に何に影響するかを行動前に推論します。

トークン効率: 少ないトークンと少ない再試行でより高品質な出力。本番デプロイメントでコストとレイテンシが直接削減されます。

長コンテキスト分析: 膨大なドキュメントやマルチセッション履歴をスレッドを失わずに処理。

価格

モデル	入力 ($/M tokens)	キャッシュ入力	出力 ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Foundry が重要な理由

Foundry Agent Serviceでは、YAMLでエージェントを定義するか、Microsoft Agent Framework、GitHub Copilot SDK、LangGraph、またはOpenAI Agents SDKで接続できます。永続的なファイルシステム、独自のMicrosoft Entraアイデンティティ、ゼロスケール価格を持つ孤立したホステッドエージェントとして実行します。

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "あなたは役立つアシスタントです。", name: "MyAgent");

完全な詳細は完全発表をご覧ください。

FoundryのRFTがより安く、よりスマートに — 変更点まとめ

Emiliano Montesdeoca — Sat, 18 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

ファインチューニングされたモデルに依存する.NETアプリを開発しているなら、今月のFoundryアップデートは注目に値します。Reinforcement Fine-Tuningがより利用しやすく、大幅に安くなりました。

詳細は公式発表にありますが、ここでは実用的なポイントをまとめます。

o4-miniのグローバルトレーニング

o4-miniは推論重視のワークロードやエージェント型ワークロードに最適なモデルです。大きなニュース：13以上のAzureリージョンからファインチューニングジョブを起動でき、Standardトレーニングと比較してトークンあたりのトレーニングコストが低くなりました。同じインフラ、同じ品質、より広い対応範囲。

チームが複数の地域に分散している場合、これは重要です。トレーニングのために少数のリージョンに縛られることはもうありません。

グローバルトレーニングジョブを開始するREST APIコールはこちらです：

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

このtrainingType: globalstandardフラグが重要な違いです。

新しいモデルグレーダー：GPT-4.1ファミリー

グレーダーはモデルが最適化する報酬シグナルを定義します。これまで、モデルベースのグレーダーは限られたモデルセットに制約されていました。今回、GPT-4.1、GPT-4.1-mini、GPT-4.1-nanoの3つの新しいオプションが追加されました。

決定的グレーダーの代わりにモデルグレーダーを使うべきなのはどんな時でしょうか？タスクの出力がオープンエンドの場合、複数の次元で部分的なスコアリングが必要な場合、またはツール呼び出しの正確さがセマンティックコンテキストに依存するエージェント型ワークフローを構築している場合です。

ポイントは、ティアリング戦略が実用的であること：

GPT-4.1-nano 初期のイテレーション用。低コスト、高速なフィードバックループ。
GPT-4.1-mini 評価ルーブリックが安定し、より高い精度が必要になったら。
GPT-4.1 本番環境の評価や、すべてのスコアリング判断が重要な複雑なルーブリック用。

単一のRFTジョブでグレーダータイプを混在させることもできます。「正解」の次元にはstring-matchを使い、推論品質の評価にはモデルグレーダーを使う。この柔軟性が、実際のワークロードで本当に役立つ理由です。

RFTデータフォーマットの落とし穴

ここでつまずく人が多いです。RFTのデータフォーマットはSFTとは異なります。各行の最後のメッセージはUserまたはDeveloperロールでなければなりません — Assistantではありません。期待される回答は、グレーダーが直接参照するreference_answerのようなトップレベルのキーに入れます。

これまでSupervised Fine-Tuningを行っていてRFTに切り替えたい場合は、トレーニングデータを再構築する必要があります。このステップを飛ばすと、ジョブがサイレントに失敗します。

.NET開発者にとってなぜ重要か

Azure OpenAI SDKを通じて.NETアプリからファインチューニングされたモデルを呼び出している場合、トレーニングコストの低下はより積極的にイテレーションできることを意味します。モデルグレーダーのオプションにより、完全一致シナリオだけでなく、ニュアンスのあるタスクに対してファインチューニングが可能になります。そしてGitHubのベストプラクティスガイドは、実際のデバッグ時間を節約してくれます。

小さく始めましょう。10から100サンプル。シンプルなグレーダー。ループを検証。そしてスケール。

Azure FunctionsのMCPサーバーをFoundryエージェントに接続する方法

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

MCPエコシステムで私が大好きなことがあります：サーバーを一度構築すれば、どこでも動作するということです。VS Code、Visual Studio、Cursor、ChatGPT — すべてのMCPクライアントがあなたのツールを発見して使用できます。そして今、Microsoftはそのリストにもう一つの消費者を追加しています：Foundryエージェントです。

Azure SDKチームのLily Maが、Azure FunctionsにデプロイされたMCPサーバーをMicrosoft Foundryエージェントに接続する実践ガイドを公開しました。すでにMCPサーバーをお持ちなら、これは純粋な付加価値です — 再構築は不要です。

この組み合わせが理にかなう理由

Azure Functionsは、MCPサーバーのホスティングにスケーラブルなインフラ、組み込みの認証、サーバーレス課金を提供します。Microsoft Foundryは、推論、計画、行動ができるAIエージェントを提供します。この2つを接続すると、カスタムツール — データベースのクエリ、ビジネスAPIの呼び出し、バリデーションロジックの実行 — がエンタープライズAIエージェントが自律的に発見して使用できる機能になります。

重要なポイント：MCPサーバーはそのままです。Foundryをもう一つの消費者として追加するだけです。VS Codeのセットアップで動作している同じツールが、チームや顧客が対話するAIエージェントを動かすようになります。

認証オプション

ここが記事の真価が発揮されるところです。シナリオに応じた4つの認証方法：

方法	ユースケース
キーベース（デフォルト）	開発またはEntra認証なしのサーバー
Microsoft Entra	マネージドIDによる本番環境
OAuthアイデンティティパススルー	各ユーザーが個別に認証する本番環境
認証なし	開発/テストまたは公開データのみ

本番環境では、エージェントIDを使用したMicrosoft Entraが推奨パスです。OAuthアイデンティティパススルーは、ユーザーコンテキストが重要な場合に使用します — エージェントがユーザーにサインインを求め、各リクエストがユーザー自身のトークンを運びます。

セットアップ

大まかな流れ：

MCPサーバーをAzure Functionsにデプロイ — .NET、Python、TypeScript、Javaのサンプルが利用可能
Function Appで組み込みMCP認証を有効化
エンドポイントURLを取得 — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
FoundryにMCPサーバーをツールとして追加 — ポータルでエージェントに移動し、新しいMCPツールを追加、エンドポイントとクレデンシャルを提供

その後、Agent Builderのプレイグラウンドでツールをトリガーするプロンプトを送信してテストします。

私の見解

ここでのコンポーザビリティの話は本当に強力になっています。MCPサーバーを.NET（またはPython、TypeScript、Java）で一度構築し、Azure Functionsにデプロイすれば、すべてのMCP互換クライアントが使用できます — コーディングツール、チャットアプリ、そして今やエンタープライズAIエージェント。実際に機能する「一度書いて、どこでも使う」パターンです。

特に.NET開発者にとって、Azure Functions MCP拡張機能がこれを簡単にしてくれます。ツールをAzure Functionsとして定義し、デプロイすれば、Azure Functionsが提供するすべてのセキュリティとスケーリングを備えた本番グレードのMCPサーバーが手に入ります。

まとめ

Azure FunctionsでMCPツールを実行している場合、Foundryエージェントへの接続はクイックウィンです — カスタムツールが適切な認証付きでエンタープライズAI機能になり、サーバー自体のコード変更は不要です。

各認証方法のステップバイステップの手順は完全ガイドを、本番セットアップについては詳細ドキュメントをご覧ください。

Microsoft Foundry 2026年3月 — GPT-5.4、Agent Service GA、そしてすべてを変えるSDKリフレッシュ

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

毎月の「Microsoft Foundryの新着情報」記事は、通常インクリメンタルな改善と時折のヘッドライン機能の組み合わせです。2026年3月版はどうでしょう？基本的にすべてがヘッドライン機能です。Foundry Agent ServiceがGAに、GPT-5.4が本番環境向けにリリース、SDKがメジャーな安定版リリースを受け、Fireworks AIがオープンモデル推論をAzureに提供します。.NET開発者にとって何が重要かを詳しく見ていきましょう。

Foundry Agent Serviceが本番環境対応に

これが最大のニュースです。次世代エージェントランタイムが一般提供開始されました — OpenAI Responses APIの上に構築され、OpenAIエージェントとワイヤー互換性があり、複数のプロバイダーのモデルに対応しています。今日Responses APIで構築している方は、Foundryに移行することでエンタープライズセキュリティ、プライベートネットワーキング、Entra RBAC、完全なトレーシング、そして既存のエージェントロジック上での評価が追加されます。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

主な追加機能：エンドツーエンドのプライベートネットワーキング、MCP認証の拡張（OAuthパススルーを含む）、音声対音声エージェント向けVoice Liveプレビュー、6つの新リージョンでのホスティングエージェント。

GPT-5.4 — 純粋な知性より信頼性

GPT-5.4はより賢くなることが目的ではありません。より信頼性が高くなることが目的です。長い対話での強力な推論、より良い指示への忠実度、ワークフロー中の障害の減少、そして統合されたコンピュータ使用機能。本番環境のエージェントにとって、その信頼性はベンチマークスコアよりもはるかに重要です。

モデル	価格（100万トークンあたり）	最適な用途
GPT-5.4 (≤272K)	$2.50 / $15 出力	本番エージェント、コーディング、ドキュメントワークフロー
GPT-5.4 Pro	$30 / $180 出力	深い分析、科学的推論
GPT-5.4 Mini	コスト効率的	分類、抽出、軽量なツール呼び出し

賢い戦略はルーティングです：GPT-5.4 Miniが高ボリューム・低レイテンシーの作業を処理し、GPT-5.4が推論の重いリクエストを担当します。

SDKがついに安定版に

azure-ai-projects SDKが全言語で安定版をリリースしました — Python 2.0.0、JS/TS 2.0.0、Java 2.0.0、そして.NET 2.0.0（4月1日）。azure-ai-agentsの依存関係はなくなり、すべてがAIProjectClientの下に統合されました。pip install azure-ai-projectsでインストールでき、パッケージはopenaiとazure-identityを直接の依存関係としてバンドルしています。

.NET開発者にとって、これはFoundry全体の機能に対する単一のNuGetパッケージを意味します。別々のエージェントSDKを使い分ける必要はもうありません。

Fireworks AIがオープンモデルをAzureに提供

おそらくアーキテクチャ的に最も興味深い追加：Fireworks AIが毎日13兆以上のトークンを~180Kリクエスト/秒で処理し、Foundryを通じて利用可能になりました。DeepSeek V3.2、gpt-oss-120b、Kimi K2.5、MiniMax M2.5がローンチ時に利用可能です。

本当の注目点はbring-your-own-weights — サービングスタックを変更せずに、どこからでも量子化またはファインチューニングされた重みをアップロードできます。サーバーレスのペイパートークンまたはプロビジョニングされたスループットでデプロイ可能です。

その他のハイライト

Phi-4 Reasoning Vision 15B — チャート、ダイアグラム、ドキュメントレイアウト向けのマルチモーダル推論
Evaluations GA — Azure Monitorに連携した継続的な本番モニタリング付きのすぐに使えるエバリュエーター
Priority Processing（プレビュー）— レイテンシーに敏感なワークロード向けの専用コンピュートレーン
Voice Live — Foundryエージェントに直接接続する音声対音声ランタイム
Tracing GA — ソートとフィルター付きのエンドツーエンドエージェントトレース検査
PromptFlowの非推奨化 — 2027年1月までにMicrosoft Framework Workflowsへの移行

まとめ

2026年3月はFoundryにとって転換点です。Agent Service GA、全言語での安定SDK、信頼性の高い本番エージェント向けGPT-5.4、そしてFireworks AIによるオープンモデル推論 — プラットフォームは本格的なワークロードに対応する準備が整っています。

完全なまとめを読んで、最初のエージェントを構築して始めましょう。

Azure DevOps MCPサーバーがMicrosoft Foundryに登場：AIエージェントにとっての意味

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

MCP（Model Context Protocol）が注目を集めています。AIエージェントのエコシステムを追っているなら、MCPサーバーがあちこちで登場しているのに気づいているでしょう — 標準化されたプロトコルを通じて、エージェントが外部ツールやサービスとやり取りする能力を提供しています。

Azure DevOps MCPサーバーがMicrosoft Foundryで利用可能になり、これは実用的な可能性について考えさせられる統合の一つです。

実際に何が起きているのか

MicrosoftはすでにAzure DevOps MCPサーバーをパブリックプレビューとしてリリースしています — これがMCPサーバー本体です。新しいのはFoundryとの統合です。ツールカタログから直接、Azure DevOps MCPサーバーをFoundryエージェントに追加できるようになりました。

Foundryをまだ知らない方へ：これはMicrosoftのAIアプリケーションとエージェントを大規模に構築・管理するための統合プラットフォームです。モデルアクセス、オーケストレーション、評価、デプロイ — すべてが一か所に。

セットアップ

セットアップは驚くほどシンプルです：

Foundryエージェントで Add Tools > Catalog に移動
“Azure DevOps"を検索
Azure DevOps MCP Server（preview）を選択して Create をクリック
組織名を入力して接続

以上です。エージェントがAzure DevOpsツールにアクセスできるようになりました。

エージェントがアクセスできるものを制御する

ここが評価できるポイントです：オール・オア・ナッシングのアプローチに縛られません。エージェントに利用可能なツールを指定できます。ワークアイテムの読み取りだけを許可してパイプラインには触れさせたくない場合、そのように設定できます。最小権限の原則を、AIエージェントに適用するわけです。

これはエンタープライズシナリオで重要です。誰かが「リリースを手伝って」と頼んだだけで、エージェントが誤ってデプロイパイプラインを起動するのは避けたいですよね。

.NETチームにとってなぜ興味深いのか

実践的に何が可能になるか考えてみてください：

スプリント計画アシスタント — ワークアイテムを取得し、ベロシティデータを分析し、スプリントキャパシティを提案できるエージェント
コードレビューボット — リポジトリやリンクされたワークアイテムを実際に読めるため、PRのコンテキストを理解するエージェント
インシデント対応 — ワークアイテムを作成し、最近のデプロイを照会し、バグと最近の変更を相関させるエージェント
開発者オンボーディング — 「何に取り組むべき？」に対して、実際のプロジェクトデータに基づいた本物の回答が得られる

CI/CDパイプラインやプロジェクト管理にすでにAzure DevOpsを使用している.NETチームにとって、これらのシステムと直接やり取りできるAIエージェントは、有用な自動化への大きな一歩です。

MCPの全体像

これはより広いトレンドの一部です：MCPサーバーはAIエージェントが外部世界とやり取りする標準的な方法になりつつあります。GitHub、Azure DevOps、データベース、SaaS APIで見かけるようになり、Foundryはこれらすべての接続が集まるハブになりつつあります。

.NETエコシステムでエージェントを構築しているなら、MCPに注目する価値があります。プロトコルは標準化され、ツールは成熟し、Foundry統合によりサーバー接続を手動で配線することなくアクセスしやすくなっています。

まとめ

FoundryのAzure DevOps MCPサーバーはプレビュー中なので、進化が期待されます。しかし、コアワークフローはしっかりしています：接続し、ツールアクセスを設定し、エージェントにDevOpsデータを操作させる。すでにFoundryエコシステムにいるなら、数クリックで始められます。試してみて、どんなワークフローが構築できるか確認してください。

詳しいセットアップ手順については完全なアナウンスをご覧ください。

Foundry Agent ServiceがGA：.NETエージェント開発者にとって本当に重要なこと

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

正直に言いましょう — AIエージェントのプロトタイプを作るのは簡単な部分です。難しいのはその後のすべて：適切なネットワーク分離で本番に乗せること、実際に意味のある評価を実行すること、コンプライアンス要件に対応すること、そして午前2時にものを壊さないこと。

Foundry Agent ServiceがGAになりました。そしてこのリリースは「その後のすべて」のギャップにレーザーのように集中しています。

Responses APIの上に構築

見出し：次世代のFoundry Agent ServiceはOpenAI Responses APIの上に構築されています。すでにそのワイヤープロトコルで開発しているなら、Foundryへの移行は最小限のコード変更で済みます。得られるもの：エンタープライズセキュリティ、プライベートネットワーキング、Entra RBAC、完全なトレーシング、評価 — 既存のエージェントロジックの上に。

アーキテクチャは意図的にオープンです。一つのモデルプロバイダーや一つのオーケストレーションフレームワークに縛られません。プランニングにDeepSeek、生成にOpenAI、オーケストレーションにLangGraph — ランタイムが一貫性レイヤーを処理します。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

azure-ai-agentsパッケージから来ている場合、エージェントはazure-ai-projectsのAIProjectClientでファーストクラスの操作になりました。スタンドアロンの依存関係を削除し、get_openai_client()でレスポンスを駆動してください。

プライベートネットワーキング：エンタープライズのブロッカー除去

これはエンタープライズ採用のブロックを解除する機能です。FoundryはBYO VNetで完全なエンドツーエンドのプライベートネットワーキングをサポートするようになりました：

パブリックエグレスなし — エージェントのトラフィックはパブリックインターネットに触れない
コンテナ/サブネットインジェクション — ローカル通信のためにネットワークに注入
ツール接続性も含む — MCPサーバー、Azure AI Search、Fabricデータエージェントすべてがプライベートパスで動作

最後のポイントが重要です。プライベートのままなのは推論呼び出しだけではありません — すべてのツール呼び出しと検索コールもネットワーク境界内にとどまります。外部ルーティングを禁止するデータ分類ポリシーの下で運用しているチームにとって、これが欠けていたものです。

MCP認証を正しく

MCPサーバー接続は認証パターンの全スペクトルをサポートするようになりました：

認証方法	使用タイミング
キーベース	組織全体の内部ツール向けシンプルな共有アクセス
Entra Agent Identity	サービス間；エージェントがそれ自体として認証
Entra Managed Identity	プロジェクト単位の分離；クレデンシャル管理不要
OAuth Identity Passthrough	ユーザー委任アクセス；エージェントがユーザーに代わって行動

OAuth Identity Passthroughが興味深い。ユーザーがエージェントに個人データへのアクセスを許可する必要がある場合 — OneDrive、Salesforce org、ユーザースコープのSaaS API — エージェントは標準のOAuthフローでユーザーに代わって行動します。全員のふりをする共有システムIDはありません。

Voice Live：配管なしの音声対音声

エージェントに音声を追加するには、STT、LLM、TTSを組み合わせる必要がありました — 3つのサービス、3つのレイテンシホップ、3つの課金サーフェス、すべて手動で同期。Voice Liveはこれを単一のマネージドAPIに凝縮します：

セマンティック音声アクティビティとターンエンド検出（沈黙だけでなく意味を理解）
サーバーサイドのノイズ抑制とエコーキャンセル
割り込みサポート（ユーザーが応答中に割り込める）

音声インタラクションはテキストと同じエージェントランタイムを通過します。同じ評価者、同じトレース、同じコスト可視性。カスタマーサポート、フィールドサービス、アクセシビリティシナリオで、以前はカスタムオーディオパイプラインが必要だったものを置き換えます。

評価：チェックボックスから継続的モニタリングへ

ここでFoundryが本番品質について本気になります。評価システムには3つのレイヤーがあります：

組み込み評価者 — 一貫性、関連性、根拠性、検索品質、安全性。データセットまたはライブトラフィックに接続してスコアを取得。
カスタム評価者 — 独自のビジネスロジック、トーン標準、ドメイン固有のコンプライアンスルールをエンコード。
継続的評価 — Foundryがライブ本番トラフィックをサンプリングし、評価者スイートを実行し、ダッシュボードに結果を表示。根拠性が低下したりセキュリティ閾値を超えた場合のAzure Monitorアラートを設定。

すべてがAzure Monitor Application Insightsに公開されます。エージェント品質、インフラ健全性、コスト、アプリテレメトリ — すべて一か所に。

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

ホステッドエージェント向け6つの新リージョン

ホステッドエージェントがEast US、North Central US、Sweden Central、Southeast Asia、Japan Eastなどで利用可能になりました。これはデータレジデンシー要件と、エージェントがデータソースの近くで実行される場合のレイテンシ圧縮に重要です。

.NET開発者にとってなぜ重要か

GAアナウンスのコードサンプルはPythonファーストですが、基盤となるインフラストラクチャは言語に依存しません — そしてazure-ai-projectsの.NET SDKも同じパターンに従います。Responses API、評価フレームワーク、プライベートネットワーキング、MCP認証 — これらすべてが.NETから利用可能です。

AIエージェントが「かっこいいデモ」から「実際に仕事で出荷できる」に変わるのを待っていたなら、このGAリリースがそのシグナルです。プライベートネットワーキング、適切な認証、継続的評価、本番モニタリングが欠けていたピースです。

まとめ

Foundry Agent Serviceは今すぐ利用可能です。SDKをインストールし、ポータルを開いて構築を始めましょう。クイックスタートガイドで数分でゼロから動くエージェントに到達できます。

すべてのコードサンプルを含む完全な技術的ディープダイブはGAアナウンスメントをご覧ください。

ラップトップから本番へ：2つのコマンドでAIエージェントをMicrosoft Foundryにデプロイ

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

「自分のマシンでは動く」と「デプロイされてトラフィックを処理している」の間のギャップを知っていますか？AIエージェントにとって、そのギャップは痛いほど広かった。リソースのプロビジョニング、モデルのデプロイ、IDの設定、モニタリングの構築 — これら全ては、誰かが実際にエージェントを呼び出せるようになる前の話です。

Azure Developer CLIがこれを2つのコマンドで済む話にしました。

新しい`azd ai agent`ワークフロー

実際にどんな感じか見せましょう。AIエージェントプロジェクトがあるとします — ホテルのコンシェルジュエージェントとしましょう。ローカルで動いています。Microsoft Foundry上で実行したい。

azd ai agent init
azd up

以上です。2つのコマンド。azd ai agent initがリポジトリにInfrastructure as Codeを生成し、azd upがAzure上で全てをプロビジョニングしてエージェントを公開します。Foundryポータルでエージェントへの直接リンクが得られます。

裏側で何が起きているか

initコマンドはリポジトリに実際の、検査可能なBicepテンプレートを生成します：

Foundry Resource（トップレベルコンテナ）
Foundry Project（エージェントが存在する場所）
モデルデプロイメント設定（GPT-4oなど）
適切なRBACロール割り当てを持つマネージドID
サービスマップ用のazure.yaml
エージェントメタデータと環境変数を持つagent.yaml

重要なポイント：これは全てあなたのものです。リポジトリ内のバージョン管理されたBicepです。検査し、カスタマイズし、エージェントコードと一緒にコミットできます。魔法のブラックボックスはありません。

開発の内部ループ

本当に気に入っているのはローカル開発の体験です。エージェントのロジックを反復しているとき、プロンプトを変更するたびに再デプロイしたくないですよね：

azd ai agent run

これでエージェントをローカルで起動します。azd ai agent invokeと組み合わせてテストプロンプトを送信すると、タイトなフィードバックループが得られます。コード編集、再起動、呼び出し、繰り返し。

invokeコマンドはルーティングも賢く — ローカルエージェントが実行中なら自動的にそちらをターゲットにします。実行中でなければリモートエンドポイントにアクセスします。

リアルタイムモニタリング

これが私を納得させた機能です。エージェントがデプロイされたら：

azd ai agent monitor --follow

エージェントを通過する全てのリクエストとレスポンスがリアルタイムでターミナルにストリームされます。本番環境の問題デバッグには計り知れない価値があります。Log Analyticsを掘り返す必要なし、メトリクス集計を待つ必要なし — 今何が起きているかが見えます。

コマンドの完全セット

クイックリファレンスはこちら：

コマンド	機能
`azd ai agent init`	IaCでFoundryエージェントプロジェクトをスキャフォールド
`azd up`	Azureリソースをプロビジョニングしてエージェントをデプロイ
`azd ai agent invoke`	リモートまたはローカルエージェントにプロンプトを送信
`azd ai agent run`	開発用にエージェントをローカルで実行
`azd ai agent monitor`	公開エージェントからリアルタイムログをストリーム
`azd ai agent show`	エージェントの健全性とステータスを確認
`azd down`	全てのAzureリソースをクリーンアップ

.NET開発者にとってなぜ重要か

アナウンスのサンプルはPythonベースですが、インフラストラクチャの話は言語に依存しません。あなたの.NETエージェントも同じBicepスキャフォールディング、同じマネージドID設定、同じモニタリングパイプラインを受け取ります。そして、すでに.NET Aspireアプリやazureデプロイメントにazdを使っているなら、既存のワークフローにそのまま組み込めます。

AIエージェントのデプロイメントギャップはエコシステムで最大の摩擦ポイントの一つでした。動くプロトタイプから適切なID、ネットワーキング、モニタリングを備えた本番エンドポイントへの移行に1週間のDevOps作業は必要ないはずです。今は2つのコマンドと数分で済みます。

まとめ

azd ai agentは今すぐ利用可能です。インフラストラクチャ設定が大変そうだからとAIエージェントのデプロイを先延ばしにしていたなら、試してみてください。フロントエンドチャットアプリ統合を含む完全なステップバイステップガイドは完全なウォークスルーをご覧ください。

Foundry | The .NET Blog

Microsoft Foundry 2026年4月: Foundry Local GA、GPT-5.5、HyperlightによるCodeAct

Foundry Localが一般提供開始

GPT-5.5

FoundryでのAgent Frameworkトレーシング

HyperlightによるCodeAct（Alpha）

エージェント監視ダッシュボード（プレビュー）

継続的評価カスタムエバリュエーター（プレビュー）

コントロールプレーンのエージェントインベントリ

あなたのローカル MAF エージェントが本番環境の家を手に入れました

Foundry Hosted Agents が実際に何をするか

コードの違いは最小限

2 つのプロトコル、1 つのエージェント

azd を使ったデプロイフロー

まとめ

Foundry Local 1.1: リアルタイム文字起こし、Embeddings、Responses API

ライブ音声文字起こし

テキスト Embeddings

Responses API

パッケージサイズの改善

なぜこれが重要か

GPT-5.5 が Azure Foundry に登場 — .NET 開発者が知っておくべきこと

GPT-5 の進化

実際に何が変わったか

価格

Foundry が重要な理由

FoundryのRFTがより安く、よりスマートに — 変更点まとめ

o4-miniのグローバルトレーニング

新しいモデルグレーダー：GPT-4.1ファミリー

RFTデータフォーマットの落とし穴

.NET開発者にとってなぜ重要か

Azure FunctionsのMCPサーバーをFoundryエージェントに接続する方法

この組み合わせが理にかなう理由

認証オプション

セットアップ

私の見解

まとめ

Microsoft Foundry 2026年3月 — GPT-5.4、Agent Service GA、そしてすべてを変えるSDKリフレッシュ

Foundry Agent Serviceが本番環境対応に

GPT-5.4 — 純粋な知性より信頼性

SDKがついに安定版に

Fireworks AIがオープンモデルをAzureに提供

その他のハイライト

まとめ

Azure DevOps MCPサーバーがMicrosoft Foundryに登場：AIエージェントにとっての意味

実際に何が起きているのか

セットアップ

エージェントがアクセスできるものを制御する

.NETチームにとってなぜ興味深いのか

MCPの全体像

まとめ

Foundry Agent ServiceがGA：.NETエージェント開発者にとって本当に重要なこと

Responses APIの上に構築

プライベートネットワーキング：エンタープライズのブロッカー除去

MCP認証を正しく

Voice Live：配管なしの音声対音声

評価：チェックボックスから継続的モニタリングへ

ホステッドエージェント向け6つの新リージョン

.NET開発者にとってなぜ重要か

まとめ

ラップトップから本番へ：2つのコマンドでAIエージェントをMicrosoft Foundryにデプロイ

新しいazd ai agentワークフロー

裏側で何が起きているか

開発の内部ループ

リアルタイムモニタリング

コマンドの完全セット

.NET開発者にとってなぜ重要か

まとめ

`azd` を使ったデプロイフロー

新しい`azd ai agent`ワークフロー