Azure | 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

Cosmos DB Shell はパブリックプレビューに — そして MCP サーバーが内蔵されている

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

1 つの Cosmos DB の質問に答えるだけのために、ポータルのタブ、SDK サンプル、そして書きかけのスクリプトを行き来した経験があるなら、このプロジェクトが解消しようとしている摩擦をすでに知っているでしょう。

Azure Cosmos DB Shell がパブリックプレビューに入りました。bash ライクな構文を持つオープンソース CLI であり、そして — これを面白くする部分 — 統合された MCP サーバーを備えています。

他のデータベース CLI との違い

CLI 自体は有用です：使い慣れたコマンド、スクリプトサポート、CI/CD 統合。この部分は開発者向けデータベースツールの最低限のものです。

興味深い部分は MCP サーバーの統合です。CLI が公開するすべてのコマンドが、AI エージェントが呼び出せる MCP ツールとして利用可能になります。カスタム API レイヤーはなく、書くべき統合コードもありません。エージェントは次のことができます：

cd、ls、pwd でデータベース階層を移動
query で SQL クエリを実行し、構造化された結果を取得
create item、update、rm でアイテムを作成・変更
mkdb、mkcon、rmdb、rmcon でデータベースとコンテナを管理
endpoint、pwd で現在のコンテキストを確認

重要な変化：エージェントは Cosmos DB API と話しているのではなく、あなたが使う同じシェルインターフェイスと話しています。コマンドは決定論的で監査可能であり、正確に何が起きているかを確認できるようオープンソースです。

オープンソースの基盤が重要

これはブラックボックスのマネージドサービスではありません。シェルはオープンソースであり、それが意味することは：

セキュリティチームが実装を監査できる
プラットフォームチームが特定の標準に合わせてフォークして拡張できる
開発者が全員のためになる改善を貢献できる

AI ツールを採用する企業チームにとって、「正確にどう動くか見られますか」はオプションの要件でなくなりつつあります。ここでのオープンソースは意味ある差別化要因です。

簡単になる 3 つのシナリオ

インテリジェントなデータ分析 — エージェントをシェルに接続し、自然言語で質問し、構造化されたクエリ結果を得る。クエリの構築はエージェントが担当し、実行はシェルが担当します。

自律的なデータ管理 — Cosmos DB でデータを作成、更新、削除する必要があるワークフローは、カスタム統合を必要とせず MCP ツールを通じて行えます。

リアルタイム監視とアラート — エージェントがコンテナを定期的にクエリし、結果を比較し、意味のある通知チャネルで異常を報告できます。

MCP インターフェイスにより、これらのシナリオは MCP を話す任意の AI プラットフォームと組み合わせ可能になります — Microsoft のツールだけでなく。

始め方

シェルはパブリックプレビュー中です。インストールし、Cosmos DB 接続を設定し、MCP サーバーを有効にします。そこから、MCP 互換の任意のエージェントホストがツールを発見して使用できます。

元の投稿：Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

あなたの AI エージェントにはアイデンティティの問題があります（そしてこれがそれを解決するテンプレートです）

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

すべての AI エージェントプロジェクトには、こんな瞬間があります: デモは完璧に機能し、エージェントは自然言語を解釈し、正しい API を呼び出し、正しいデータを返します。そして実際のユーザーについて考え始めます。

あるユーザーのエージェントセッションが別のユーザーのデータを見るのを何が防ぐのでしょうか？エージェントがプロンプトインジェクションで騙された場合はどうなるでしょうか？予期しない方法でツールを呼び出した場合はどうなるでしょうか？

これらはエッジケースではありません。これらはリリース前に行うべき設計上の決定です。

Curity と Microsoft による新しい azd テンプレートは、まさにこの問題に対して機能するリファレンスを提供します。

核心的な問題: 認証 ≠ 認可

ほとんどのエージェントサンプルはユーザー認証をうまく処理しています。認可の処理は不十分です。ユーザーが誰であるかを知っていても、彼らが見るべきデータが何かはわかりません。

従来のクライアントアプリは予測可能な API 呼び出しを行います。AI エージェントは非決定論的です — 自然言語を解釈し、何を呼び出すかを決定します。創造的になれます。また間違える可能性もあります。プロンプトインジェクションによって操作される場合、AI が適切に動作することに依存しないルールが必要です。

このテンプレートが示す解決策: 各ホップに正確に正しい情報を運ぶ短命のトークン。

トークンチェーンの仕組み

テンプレートは OAuth 2.0 アクセストークンとトークン交換を使用して、各ステップで権限を絞り込みます。ユーザートークンは MCP サーバーに到達する前に 2 回交換されます:

最初の交換 — スコープを絞り込み、不透明なトークンを JWT に変換
2 番目の交換 — エージェント ID と MCP サーバーホップのための新しいオーディエンスを追加

MCP サーバートークンがどのように見えるか:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id は認可サーバーによってトークンに組み込まれており、エージェントが制御するパラメータとして渡されません。API はエージェントの指示ではなく、トークンをチェックします。

これが意味すること: エージェントが別の顧客のデータを取得しようとするよう騙されたとしても、トークンはそれを認可しません。

テンプレートがデプロイするもの

いくつかの azd コマンドで次のものが得られます:

Microsoft Foundry 上のバックエンドエージェント（C#、Microsoft A2A および MCP SDK）
サンプルポートフォリオ API を公開する MCP サーバー
認可サーバーとして Curity Identity Server、認証のために Entra ID と並行して
トークン交換と監査ログを処理する外部および内部 API ゲートウェイ
Azure インフラストラクチャ全体の Bicep: Container Apps、VNet、ACR、Azure AI Foundry、Key Vault、Azure SQL Database、ストレージ

パターン全体は検査可能でカスタマイズ可能です。

借りる価値のある設計原則

Curity を使用しない場合でも、パターンは転用可能です: エージェントは永続的な API アクセスを決して持つべきではありません。すべてのアクションは、その特定の呼び出しに必要な最小スコープを持つ短命のトークンを使用し、特定のエージェント ID に対して発行され、API が認可の決定を行うために必要なクレームを運ぶべきです。

これは創造的なエージェント、ミス、プロンプトインジェクションに対して「エージェントが悪いことをしないようにするだけ」では決して耐えられない方法で耐えます。

まとめ

AI エージェントのセキュリティパターンは、業界全体でまだ整理されています。このテンプレートは私が見た中で最も完全なリファレンス実装の 1 つです — 認証だけでなく、実際の認可フローをカバーしています。

元の投稿: Least privilege AI agents: A new azd template from Curity and Microsoft

プライベート Endpoints、VNet、NSG — Aspire がネットワークを管理するように

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

このシナリオを何度も見てきました。アプリは完成しています。デモは素晴らしい。そしてセキュリティチェックリストが現れます: ストレージをパブリックインターネットから外す、VNet 内で実行する、パートナーのアローリスト用に送信 IP を提供する、正しいサブネットだけが正しいサービスと通信することを証明する。

この時点でアプリケーションモデルとインフラストラクチャモデルが乖離し始め、維持するのが辛くなります。

Aspire の新しい Azure エンタープライズネットワーキングサポートはこれに直接対処します。ネットワークの形状を AppHost 内で、それを使用するリソースの隣に記述します。

構成要素

各 Azure ネットワーキングの概念が何のためのものかを、要約してまとめます:

機能	使用するとき	重要な理由
仮想ネットワーク	プライベートアドレス空間が必要なとき	サブネット、プライベートエンドポイント、ルーティングのためのネットワーク境界
サブネット	VNet 内でワークロードを分離する必要があるとき	システムの各部分が独自のアドレス範囲とポリシーサーフェスを取得
委任サブネット	プラットフォームサービス（ACA など）がサブネットを管理する必要があるとき	サービスが管理されたインフラを VNet に安全に配置できる
NAT ゲートウェイ	予測可能な送信パブリック IP が必要なとき	アローリストと監査のための安定したアドレス
プライベートエンドポイント	PaaS リソースをプライベートにアクセスしたいとき	そのサービスのプライベート IP を VNet 内に配置し、公開露出を除去
NSG	サブネットレベルのトラフィックルールが必要なとき	サブネットごとの受信・送信トラフィックの明示的な許可/拒否

AppHost での記述

ここでの重要な変化は、ネットワークを使用するリソースの隣にモデル化していることです。時間の経過とともにアプリモデルから離れていく別の Bicep ファイルではありません。

AppHost から以下が可能です:

AddVirtualNetwork() と AddSubnet() で VNet とサブネットを作成
安定した送信 IP のためにサブネットに NAT ゲートウェイを付加
ストレージ、Key Vault、SQL、その他の PaaS サービスのプライベートエンドポイントを作成
受信・送信セキュリティルールで NSG を定義
クロスリソースポリシーのためのネットワークセキュリティ境界を構成

結果として azd up を実行すると、インフラストラクチャはアプリモデルが必要と言っているものと一致します。手動で維持されたテンプレートが言うものではありません。

実際のアプリケーションにとって重要な理由

Aspire でネットワークをモデル化すると大幅に楽になるいくつかのこと:

Key Vault とストレージのプライベートエンドポイント — これらのリソースに WithPrivateEndpoint() を記述すると、Aspire が DNS ゾーン設定とエンドポイントの接続を処理します。アプリは変更されません。

一貫した送信 IP — 関連するサブネットに NAT ゲートウェイを追加すると、アプリからのすべての送信リクエストが既知の安定した IP を通過します。パートナーはアローリストに登録できます。監査担当者は追跡できます。

コードからの NSG ルール — ポータルをクリックしたり Bicep スニペットを維持したりする代わりに、セキュリティルールは保護するリソースの隣に AppHost に存在します。

これは、デモを興奮させるものではありませんが、プロダクションシステムを保守可能にする種類の統合です。

まとめ

プロジェクトのライフサイクルの後半にネットワークセキュリティが現れるのは、最初からアプリと一緒にモデル化すれば解決済みの問題です。Aspire のエンタープライズネットワーキングサポートは、別のインフラストラクチャトラックを必要とせずにそれを可能にします。

完全な詳細は元の投稿で: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes サポート、ブラウザログ、Aspireify スキル

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

5週間はリリースとしては短い期間ですが、Aspire 13.3 はそのようには感じません。主要な項目は重要なものです: Helm による Kubernetes および AKS のファーストクラスデプロイ、Aspireify というエージェント支援のオンボーディングスキル、ダッシュボードへのブラウザログキャプチャ直接統合、構造化されたコマンド結果。さらに、45の新機能、134の改善、93のバグ修正も含まれています。

ハイライトを見ていきましょう。

Aspireify: エージェント支援のオンボーディング

Aspire を既存のプロジェクトに追加するのは簡単に聞こえます — AppHost を追加すれば完了。しかし実際には多くの調査が必要です: どのポートが重要か、どの環境変数が実際の依存関係か、どの Docker Compose サービスが Aspire のインテグレーションにマッピングされるべきか。

新しい Aspireify スキル は、コーディングエージェントにまさにそのためのガイド付きワークフローを提供します。aspire init がスケルトン AppHost を作成するとき、Aspireify スキルはエージェントがリポジトリを調査し、どのように動作しているかを理解し、アプリに合わせて AppHost を接続するのを助けます — その逆ではありません。

デフォルトのスタンスは「コードへの変更を最小化する」です。アプリがすでに DATABASE_URL を読み取っている場合、エージェントは設定を書き直すように求めるのではなく、WithEnvironment() でそれをマップします。ポートがハードコードされている場合、スキルはエージェントにそれを保持するタイミングを伝えます。

これは、レビューのための作業を増やすのではなく、実際に時間を節約する AI ツールの一例です。

ファーストクラスの Kubernetes と AKS デプロイ

これはウィッシュリストにしばらくありました。Aspire 13.3 では Helm を使用した Kubernetes と AKS のファーストクラスデプロイサポート が提供されます。Aspire ツールから直接 AKS をデプロイターゲットとして指定できるようになりました。

AKS で本番ワークロードをすでに実行しているチームにとって、これは重要なギャップを埋めます。Aspire のアプリモデルは、手動で Helm チャートを書く必要なく、ローカル開発から Kubernetes へのクリーンなパスを持つようになりました。

ダッシュボードのブラウザログ

これはフロントエンドの問題をデバッグするまでは小さく見える機能の一つです。

新しい WithBrowserLogs() API は、エンドポイント対応のリソースに追跡されたブラウザリソースを添付します。Aspire はプライベート CDP パイプを使用して Chromium を起動し、コンソールログ、ネットワークリクエスト、エラーをリソースのログストリームに直接ストリーミングします:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost も同様にサポートしています:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

コンソールエラー、失敗したネットワークリクエスト、クライアントサイドの例外 — すべて、すでにトレースとメトリクスを監視しているのと同じダッシュボードで可視化できます。基本的なことのためにブラウザ DevTools にタブを切り替える必要はもうありません。

構造化されたコマンド結果

リソースコマンドが大幅にアップグレードされました。これまで、コマンドは成功/失敗を返していました。今では構造化された結果を返します: モデル、ダッシュボード UI、CLI、MCP ツールを流れるテキスト、JSON、または Markdown です。

ダッシュボードはこれをヘッダーの新しい通知センターでまとめています。コマンド結果は Markdown レンダリングと「応答を表示」アクションを持つタイムスタンプ付き通知として表示されます。

これにより、リソースコマンドが真に組み合わせ可能になります。インテグレーションは、単にどこかの状態を変更するのではなく、トンネル URL などの意味のある出力を返すコマンドを公開できるようになりました。

まとめ

Aspire 13.3 は Kubernetes サポートだけでもアップデートする価値があります。ブラウザログと構造化されたコマンド結果は、日常の開発ワークフローで素早く積み重なる生活の質向上の改善の一種です。

完全なリリースノート: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 は 2026年5月11日〜15日 に ロンドンの Barbican Centre で開催されます。3日間のメインカンファレンスは火曜日から木曜日で、月曜日と金曜日にはオプションの終日ワークショップがあります。

78セッション と 14ワークショップ を擁し、ヨーロッパで最も充実した開発者カンファレンスの一つです。

トピック

アーキテクチャ的思考
C# 13 における関数型コード
サーバーレスデザイン
セマンティック AI
Azure Kubernetes Services
リーン DevOps 戦略
The Model Context Protocol (MCP)
.NET におけるエージェント AI
モノリスのリファクタリング
LLM でより速くコーディング
ポスト量子世界における暗号技術
ローカルファースト開発

スピーカー

Kevlin Henney、Neal Ford、Sander Hoogendoorn、Andrew Clymer、Jacqui Read、Christian Weyer、Jeff Prosise、Jules May、Oliver Sturm、Raju Gandhi を含むワールドクラスのラインナップ。

チケットと情報

SDD 2025 参加者の98%が全体的な体験を「良い」、「とても良い」、「素晴らしい」と評価しました。

Agentic Platform Engineering で移行の繰り返し作業をなくす

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちら。

Removing the Monkey Work of Migration with Agentic Platform Engineering — Git-Ape（git アジェンティック・プラットフォーム・エンジニアリングツール）が実際の AWS Terraform リポジトリを Azure に移行するウォークスルーで、行単位の変換ではなくデプロイメントの意図抽出に焦点を当てています。

入力: contoso-migration

ソースは、AWS 上に Next.js アプリをデプロイする実際の Terraform プロジェクト（contoso-migration）です — コンピュートに EC2、ロードバランシングに ALB、アーティファクトに S3、アイデンティティに IAM キー。コスト: 月額約 34 ドル。目標は Azure で同じインフラを再現することではなく、デプロイメントが実際に何をしようとしているのかを把握し、Azure ネイティブサービス上でそれを再構築することです。

ステップ 1: 検証と認証

Git-Ape は、何かに触れる前にすべての必要な CLI ツール — az、aws、gh、jq、git — を検証し、アクティブな認証セッションを確認することから始めます。部分的な実行はありません。

ステップ 2: 意図の抽出

エージェントは GitHub API を通じてソースリポジトリ全体を読み込み、デプロイメントの意図を抽出します: ランタイム (Node.js)、コンピュートタイプ、イングレスパターン、アーティファクト処理、アイデンティティモデル、ネットワーキング、そしてモニタリング。これが重要なステップです — Terraform のキーワードではなく、デプロイメントが何をするかのセマンティックモデルを構築しています。

ステップ 3: サービスマッピング

AWS サービスが Azure の同等物にマッピングされます:

EC2 → App Service (Linux, Node 20 LTS)
ALB → App Service 組み込みロードバランシング
IAM ロール/キー → Managed Identity
Terraform → Bicep + GitHub Actions

ステップ 4: 批評エージェント

出力を生成する前に、批評エージェントが実行され、2 つのブロッキング問題を検出します:

起動時ビルドのアンチパターン — 元の Terraform は EC2 の起動時に npm install && npm run build を実行していました。修正: CI でビルドし、準備済みアーティファクトをデプロイする。
不要な Blob Storage — S3 は適切な CI/CD で排除できるアーティファクトステージングに使用されていました。批評エージェントがそれを完全に削除しました。

ステップ 5: 生成された出力

結果は元の 200 行以上の Terraform の代わりに約 80 行の Bicep です。エージェントは infra/main.bicep と .github/workflows/deploy.yml を含む新しい GitHub リポジトリを作成し、すべての AWS 固有ファイルを削除しました。

セキュリティ体制の比較

移行により、セキュリティも大幅に改善されました:

AWS オリジナル	Azure 出力
HTTP のみ	HTTPS のみ、TLS 1.2
SSH が 0.0.0.0/0 に開放	SSH 露出なし
IAM アクセスキー	OIDC + Managed Identity
モニタリングなし	Application Insights

コスト: 元の 34 ドル/月に対して約 13 ドル/月。

構文コンバーターとの違い

批評エージェントのステップが、これを機械的な変換と区別するものです。AWS では機能するが Azure では誤りとなるパターンを検出し、それを複製する代わりに修正しました。出力は「Azure 構文の AWS」ではなく、同じ目標をよりクリーンに達成する Azure ネイティブのデプロイメントです。

完全なエージェントトレースと生成されたファイルについては、完全なウォークスルーをご覧ください。

SQL MCP ServerをAzure App Serviceで動かす — コンテナ不要

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

正直に言うと、チュートリアルで「コンテナが必要」という言葉を見るたびに少しため息が出ます。コンテナは素晴らしいのですが、チームにコンテナ戦略がない場合、シンプルに見えた機能が予期しないオーケストレーションの複雑さに阻まれることになります。

だからこそ、これは注目に値します。SQL MCP ServerがAzure App Serviceで動作するようになりました — DockerもKubernetesも不要で、MCP、REST、GraphQLを通じてSQLデータベースを公開する同じData API Builder（DAB）の設定ファイルだけで動きます。

SQL MCP Serverとは？

まだご存知でない方への簡単な説明です。SQL MCP ServerはAIエージェントとSQLデータベースの間に位置します。エージェントにデータベースへの直接アクセスを与える（これはひどいアイデアです）代わりに、テーブルやビューを権限が定義されたエンティティという抽象化レイヤーとして公開します。

Data API Builder上に構築されており、1つの設定ファイルがMCP と REST と GraphQLを同時に管理します。エージェントはMCPエンドポイントと通信し、従来のアプリケーションはRESTまたはGraphQLと通信します。同じ設定、同じランタイム、異なるインターフェース。

これは本当に便利です。2つの別々なAPIレイヤーを管理する必要がありません。

コンテナの問題（と解決策）

SQL MCP Serverの元のデプロイモデルはコンテナでした。多くのチームではうまく機能しますが、すべてのチームではありません。多くの.NETチームはAzure App ServiceやVMに標準化しています。SQLエンドポイントを公開するためだけにコンテナランタイムを必要とするのは、誰も求めていない摩擦を生み出します。

新しいウォークスルーではコンテナを完全にスキップする方法を示しています。すべてdab startコマンドで動作し、標準の.NET 8 Webプロセスとして App Serviceにホストされます。

# Data API Builderをインストール
dotnet tool install microsoft.dataapibuilder --prerelease -g

# 設定を初期化
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# エンティティを追加
dab add products --source dbo.products --permissions "authenticated:*"

# App Service認証プロバイダーを設定
dab configure --runtime.host.authentication.provider AppService

# サーバーを起動
dab start

この時点で、/mcpでMCP、同じプロセスからRESTとGraphQLが利用可能になり、コンテナは一切不要です。

共有APIキーなしの認証

これが私が最も評価する部分です。App Serviceにデプロイする際、Microsoft Entra IDを認証プロバイダーとして設定します。設定ファイルに共有シークレットを埋め込む必要はなく、APIキーをローテーションする必要もありません。

接続文字列はApp Serviceの環境変数に保持され（dab-config.jsonには含まれません）、MCPエンドポイントはプラットフォーム認証で保護されます。Azure AIのワークロードでEntra IDにすでに対応している場合、これは自然に統合されます。

ローカル開発ではSimulatorモードとSTIOトランスポートに切り替えます。デプロイ前にAppServiceモードに戻します。クリーンで明示的な設定です。

App Serviceへのデプロイ

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

その後、チームがすでに使用しているコードデプロイ方法でDABプロジェクトをデプロイします。重要なポイント：これはコードのデプロイであり、コンテナのデプロイではありません。

.NET開発者にとって重要な理由

.NETでAIエージェントを構築している場合、エージェントはいずれデータベースと通信する必要があります。SQL MCP Serverは、生の接続文字列を公開したりカスタムAPIレイヤーを書いたりすることなく、それを行う構造化された方法を提供します。

完全なウォークスルーは元のブログ記事とGitHubのサンプルリポジトリでご確認ください。

まとめ

App Service上のSQL MCP Serverは、コンテナ戦略なしにエージェントに構造化されたSQLデータアクセスを提供したい.NETチームにとって、実用的な選択肢です。ぜひ試してみてください — エージェントはクリーンなAPIサーフェスを高く評価するでしょう。

SQL Server 2025 エージェント対応データベース：1つのエンジンでセキュリティ、バックアップ、MCP

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

Aditya BadramrajuのPolyglot Taxシリーズを興味深く読んできました。パート4はシリーズを締めくくり、この架構を本番環境で信頼できるかどうかを実際に決める部分に取り組みます。

すべてのデータモデルに対する1つのセキュリティモデル

1つのRow-Level Securityポリシーがすべてのデータモデルをカバー。監査人への証明が1つで済む。

統一バックアップ = アトミックリカバリ

ポリグロットスタックでは、5つのデータベースのPoint-in-Timeリカバリを協調させることは一貫性の悪夢です。1つのデータベースなら、定義上アトミックです。

MCP統合：ハンドコードされたミドルウェア不要

SQL Server 2025はSQL MCPサーバーを直接サポート。エージェントはツールを呼び出し、エンジンが自動的にテナント分離とカラムマスキングを強制します。

オリジナルポスト（Aditya Badramraju著）: The Polyglot Tax – Part 4。

Azure MCP Server が .mcpb になった — ランタイムなしでインストール

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

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

MCP サーバーのセットアップで面倒だったこと、ご存知ですか？ランタイムが必要でした。npm 版には Node.js、pip/uvx には Python、dotnet 版には .NET SDK。

Azure MCP Server がその問題を解決しました。.mcpb — MCP Bundle — として利用可能になり、セットアップはドラッグ＆ドロップです。

MCP Bundle とは？

VS Code 拡張機能（.vsix）やブラウザ拡張機能（.crx）のようなものですが、MCP サーバー用です。.mcpb ファイルはサーバーバイナリとすべての依存関係を含む自己完結型の ZIP アーカイブです。

インストール方法

1. プラットフォーム用バンドルをダウンロード

GitHub Releases ページで、OS とアーキテクチャに合った .mcpb ファイルをダウンロードします。

2. Claude Desktop にインストール

最も簡単な方法：拡張機能の設定ページ（☰ → ファイル → 設定 → 拡張機能）を開きながら、.mcpb ファイルを Claude Desktop ウィンドウにドラッグ＆ドロップします。サーバーの詳細を確認し、インストールをクリックして確認します。

3. Azure で認証

az login

以上です。Azure MCP Server は既存の Azure 認証情報を使用します。

できること

AI クライアントから直接 100 以上の Azure サービスツールにアクセス：

Cosmos DB、Storage、Key Vault、App Service、Foundry のクエリと管理
任意のタスクの az CLI コマンド生成
Bicep・Terraform テンプレートの作成

はじめるには

ダウンロード: GitHub Releases
リポジトリ: aka.ms/azmcp
ドキュメント: aka.ms/azmcp/docs

完全な記事もご確認ください。

Azure SDK 2026年4月: AI Foundry 2.0と.NET開発者が知るべきこと

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

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

月次SDKリリースはよく見落とされがちですが、今回は特に注意すべき点があります。

Azure.AI.Projects 2.0.0 — 意味のある破壊的変更

Azure.AI.Projects NuGetパッケージが安定版2.0.0に到達。名前空間の分割、型の名前変更、ブール値プロパティのIs*規則の統一。

Cosmos DB Java: 重大なセキュリティ修正（RCE）

バージョン4.79.0で**リモートコード実行脆弱性（CWE-502）**の重大な修正。Azure Cosmos DBを使用しているJavaサービスがあれば直ちに更新してください。

.NET向け新しいProvisioningライブラリ

オリジナルポスト: Azure SDK Release (April 2026)。

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 Toolboxes: AIエージェントツールのための統一エンドポイント

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちらをクリックしてください。

退屈に聞こえるが実際に直面すると深刻な問題がある：組織が複数のAIエージェントを構築し、それぞれがツールを必要とし、各チームがゼロから設定している。同じWeb検索統合、同じAzure AI Searchの設定、同じGitHub MCPサーバーの接続 — でも別のリポジトリに、別のチームが、別の認証情報で、ガバナンスの共有なしに。

Microsoft FoundryがPublic PreviewでToolboxesを公開した。これはその問題への直接的な答えだ。

Toolboxとは

ToolboxはFoundryで一度定義し、単一のMCP互換エンドポイントを通じて公開する、名前付きの再利用可能なツールバンドルだ。MCPを話す任意のエージェントランタイムが消費できる — Foundry Agentsへのロックインはない。

提案はシンプルだ：build once, consume anywhere。ツールを定義し、認証を一元設定（OAuthパススルー、Entraマネージドアイデンティティ）し、エンドポイントを公開する。そのツールが必要な各エージェントはエンドポイントに接続して全てを取得する。

4つの柱（今日は2つが利用可能）

柱	ステータス	何をするか
Discover	近日公開	手動検索なしで承認済みツールを発見
Build	利用可能	ツールを再利用可能なバンドルにまとめる
Consume	利用可能	単一MCPエンドポイントが全ツールを公開
Govern	近日公開	全ツール呼び出しの一元認証+可観測性

実践的な例

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="ドキュメントを検索し、GitHubのissueに対応する",
 tools=[
 {"type": "web_search", "description": "公開ドキュメントを検索"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

公開後、Foundryは統一エンドポイントを提供する。1回の接続で全ツールが使える。

Foundry Agentsへのロックインはない

ToolboxはFoundryで作成・管理されるが、消費面はオープンなMCPプロトコルだ。Microsoft Agent FrameworkやLangGraphのカスタムエージェント、GitHub Copilotやその他のMCP対応IDE、あらゆるMCPランタイムから使用できる。

今なぜ重要か

マルチエージェントの波が本番環境に到達している。新しいエージェントが増えるたびに、重複した設定、古い認証情報、一貫性のない動作の新たな表面が生まれる。Build + Consumeの基盤は集中化を始めるには十分だ。Governの柱が来た時、エージェント全体に完全に可観測で一元管理されたツール層が得られる。

まとめ

まだ早い段階だ — パブリックプレビュー、Python SDK優先。しかし、モデルは確かで、MCPネイティブな設計は既に構築しているツールで機能することを意味する。公式発表で詳細を確認しよう。

azd + GitHub Copilot: AIによるプロジェクトセットアップとスマートなエラー解決

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。英語の原文はこちらからご覧いただけます。

既存のアプリをAzureにデプロイしようとして、空の azure.yaml を眺めながら「Express APIにはContainer AppsとApp Serviceのどちらを使えばいいんだっけ？」と頭を抱えた経験はありませんか？そんな場面が、これからは格段に短くなります。

Azure Developer CLI（azd）がGitHub Copilotと2つの形で統合されました。azd init 実行時のAIによるプロジェクトスキャフォールディングと、デプロイ失敗時のインテリジェントなエラートラブルシューティングです。どちらの機能もターミナル内で完結します。

azd init でのCopilotセットアップ

azd init を実行すると、「Set up with GitHub Copilot (Preview)」という選択肢が表示されます。選択すると、Copilotがコードベースを分析し、実際のコードに基づいて azure.yaml、インフラテンプレート、Bicepモジュールを生成します。

azd init
# 選択: "Set up with GitHub Copilot (Preview)"

必要なもの：

azd 1.23.11以降 — azd version で確認、azd update で更新
有効なGitHub Copilotサブスクリプション（Individual、Business、またはEnterprise）
GitHub CLI（gh） — 必要に応じてログインを求められます

この機能の優れた点は双方向に機能することです。ゼロから構築する場合はAzureサービスの適切なセットアップを支援し、既存のアプリをデプロイしたい場合はコードを分析して設定を生成します。構造を変更する必要はありません。

実際に何をするのか

Node.js ExpressのAPIにPostgreSQLの依存関係がある場合を例にしましょう。Container AppsかApp Serviceかを手動で決め、BicepをゼロからT書く代わりに、Copilotはスタックを検出して以下を生成します：

適切な language、host、build 設定を持つ azure.yaml
Azure Container Apps用のBicepモジュール
Azure Database for PostgreSQL用のBicepモジュール

変更前に事前チェックも実行されます。gitの作業ディレクトリがクリーンかどうか確認し、MCPサーバーツールへの同意を事前に求めます。何が変わるか把握した上でのみ処理が進みます。

Copilotによるエラートラブルシューティング

デプロイエラーは避けられません。パラメーターの欠落、権限の問題、SKUの可用性問題など。エラーメッセージが修正方法を教えてくれることはほとんどありません。

Copilotなしの場合のループ：エラーをコピー → ドキュメントを検索 → 関係ないStack Overflowの回答を3つ読む → az CLIコマンドを実行 → 再試行して祈る。azd にCopilotが統合されると、このループが消えます。azd コマンドが失敗すると、即座に4つの選択肢が提示されます：

Explain — 何が起きたかをわかりやすく説明
Guidance — 修正のステップバイステップの手順
Diagnose and Guide — 完全な分析 + Copilotが修正を適用（承認後）+ 再試行オプション
Skip — 自分で対処

重要な点：Copilotはすでにプロジェクト、失敗したコマンド、エラー出力のコンテキストを持っています。提案は あなたの状況 に特化したものです。

デフォルト動作の設定

常に同じオプションを選ぶなら、インタラクティブなプロンプトをスキップできます：

azd config set copilot.errorHandling.category troubleshoot

値：explain、guidance、troubleshoot、fix、skip。自動修正と再試行も有効にできます：

azd config set copilot.errorHandling.fix allow

いつでもインタラクティブモードに戻せます：

azd config unset copilot.errorHandling.category

まとめ

azd update で最新バージョンに更新し、次のプロジェクトで azd init を試してみてください。本当に価値のあるCopilot統合です。

元の発表はこちらをご覧ください。

AzureでのAI実験がお金を燃やしている — その解決方法はこちら

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

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

今AzureでAI搭載アプリを構築しているなら、おそらく気づいていることがあるでしょう：クラウドの請求書が以前と違って見えるということです。単に高くなっただけではなく、不思議な感じです。スパイクがあり、予測が難しい。

Microsoftが今でも重要なクラウドコスト最適化の原則に関する素晴らしい記事を公開しました。正直なところ、これ以上ないタイミングです。なぜなら、AIワークロードがコストに関するゲームのルールを変えてしまったからです。

AIワークロードが違う理由

ポイントはこうです。従来の.NETワークロードは比較的予測可能です。App Serviceのティアを把握し、SQLのDTUを把握し、月々の支出をかなり正確に見積もることができます。AIワークロードは？そうはいきません。

どのモデルが合うか、複数のモデルをテストしています。ファインチューニングのためにGPUバックのインフラを立ち上げています。Azure OpenAIへのAPI呼び出しでは、プロンプトの長さやユーザーの行動によってトークン消費量が大きく変動します。すべての実験に実際のコストがかかり、正しいアプローチにたどり着くまでに何十回も実行することになるかもしれません。

この予測不可能性こそが、コスト最適化を重要にする理由です — 後から考えるのではなく、初日から。

管理と最適化 — 違いを知る

記事の中で開発者が見落としがちだと思う区別があります：コスト管理とコスト最適化には違いがあるということです。

管理はトラッキングとレポーティングです。Azure Cost Managementで予算を設定し、アラートを受け取り、ダッシュボードを見ます。これは基本中の基本です。

最適化は実際に意思決定を行うところです。本当にそのS3ティアが必要ですか、それともS1で負荷に対応できますか？常時稼働のコンピューティングインスタンスが週末に何もしていませんか？トレーニングジョブにスポットインスタンスを使えませんか？

.NET開発者として、私たちはコードに集中し、インフラの決定を「運用チーム」に任せがちです。しかし、Azureにデプロイしているなら、それらの決定はあなたの決定でもあるのです。

実際に効果があること

記事と自分自身の経験に基づいて、これが実際に効果を生むことです：

何にいくら使っているか把握する。 リソースにタグを付けてください。本当に。どのプロジェクトや実験が予算を食っているかわからなければ、何も最適化できません。適切なタグ付けを行ったAzure Cost Managementが最強の味方です。

実験する前にガードレールを設置する。 Azure Policyを使って、dev/test環境で高価なSKUを制限しましょう。Azure OpenAIデプロイメントに支出上限を設定しましょう。誰かが週末にGPUクラスターを動かしっぱなしにしていたことに請求書が届いてから気づく、なんてことは避けましょう。

継続的にライトサイジングする。 プロトタイピング中に選んだVM？本番環境にはおそらく合っていません。Azure Advisorが推奨事項を提示してくれます — 実際に確認してください。年に一度ではなく、月に一度レビューしましょう。

ライフサイクルを考える。 開発リソースはシャットダウンすべきです。テスト環境は24時間365日稼働する必要はありません。自動シャットダウンポリシーを使いましょう。AIワークロードについては特に、コンピューティングを常時稼働させる代わりに実行ごとに課金されるサーバーレスオプションを検討しましょう。

コストだけでなく価値を測定する。 これは忘れがちです。コストは高いけれど大幅に優れた結果を出すモデルが正しい選択かもしれません。目標は最小限の支出ではなく、賢い支出です。

まとめ

クラウドコスト最適化は一度きりのクリーンアップではありません。習慣です。AIワークロードによって支出がかつてないほど予測しにくくなっている今、この習慣を早くから身につけることで、後の痛い驚きを避けることができます。

Azureで構築している.NET開発者なら、クラウドの請求書をコードと同じように扱い始めましょう — 定期的にレビューし、散らかってきたらリファクタリングし、コストを理解せずにデプロイしないようにしましょう。

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サンプル。シンプルなグレーダー。ループを検証。そしてスケール。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 は 2026年4月18日 にマドリード、Alcobendas の Kinépolis Diversia で開催されます。スペイン最大のコミュニティ主導のAzureイベントで、AIエージェント、Azureネットワーク、Cosmos DB、Fabric、IoT、セキュリティなどをカバーする3つの並行トラックに38名のスピーカーが登壇します。

イベントは 08:30 から 18:30 まで開催され、キーノート、コーヒーブレイク、ランチ、クロージングQ&Aセッションを含みます。

アジェンダのハイライト

Domando Agentes de IA: Azure AI FoundryとAzure API Managementによるガバナンス、ツール、API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: マルチエージェントシステムの実践
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

チケット

登録は象徴的な寄付です — チケット代金は全額 Plan International に寄付され、世界中の子どもの権利と平等を支援します。定員に限りがありますので、お早めにお申し込みください。

Azure Tour 2026

マドリード以外にも、Global Azure Tour 2026 は サラゴサ、テネリフェ、セビリア でも開催されます。

Azure MCPツールがVisual Studio 2022に組み込まれました — 拡張機能のインストール不要

Emiliano Montesdeoca — Thu, 16 Apr 2026 00:00:00 +0000

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

Visual Studioで別途拡張機能としてAzure MCPツールを使っていた方なら、あのお決まりの流れをご存知でしょう — VSIXをインストールし、再起動し、壊れないことを祈り、バージョンの不一致を管理する。その煩わしさはもう終わりです。

Yun Jung Choiが発表したとおり、Azure MCPツールはVisual Studio 2022のAzure開発ワークロードの一部として直接同梱されるようになりました。拡張機能なし。VSIXなし。再起動の手間なし。

これが実際に意味すること

Visual Studio 2022 バージョン17.14.30以降、Azure MCP ServerはAzure開発ワークロードにバンドルされています。すでにそのワークロードがインストールされていれば、GitHub Copilot Chatで有効にするだけで完了です。

45のAzureサービスにわたる230以上のツール — チャットウィンドウから直接アクセスできます。ストレージアカウントの一覧表示、ASP.NET Coreアプリのデプロイ、App Serviceの問題診断、Log Analyticsへのクエリ — すべてブラウザタブを開くことなく実行できます。

なぜこれが見た目以上に重要なのか

開発ツールについて言えることはこれです：余分なステップはすべて摩擦であり、摩擦は普及を妨げます。MCPが別の拡張機能だった頃は、バージョンの不一致、インストールの失敗、そしてもう一つアップデートを管理するものが増えるということを意味していました。ワークロードへの組み込みは以下を意味します：

単一の更新パス — Visual Studio Installerを通じて
バージョンのずれなし — 拡張機能とIDEの間で
常に最新 — MCP Serverは通常のVSリリースと一緒に更新

Azureを標準化しているチームにとって、これは大きな前進です。ワークロードを一度インストールし、ツールを有効にすれば、毎回のセッションで利用可能です。

これで何ができるか

ツールはCopilot Chatを通じて開発ライフサイクル全体をカバーします：

学ぶ — Azureサービス、ベストプラクティス、アーキテクチャパターンについて質問
設計・開発 — サービスの推奨を取得、アプリコードの設定
デプロイ — リソースのプロビジョニングとIDEからの直接デプロイ
トラブルシューティング — ログのクエリ、リソースの正常性チェック、本番環境の問題診断

簡単な例として、Copilot Chatで以下を入力してみてください：

List my storage accounts in my current subscription.

Copilotは裏側でAzure MCPツールを呼び出し、サブスクリプションを照会し、名前、場所、SKUが記載されたフォーマット済みリストを返します。ポータルは不要です。

有効にする方法

Visual Studio 2022 17.14.30以降にアップデート
Azure developmentワークロードがインストールされていることを確認
GitHub Copilot Chatを開く
Select toolsボタン（レンチアイコン）をクリック
Azure MCP Serverをオンに切り替え

以上です。セッション間で有効な状態が維持されます。

注意点

ツールはデフォルトで無効になっています — オプトインが必要です。また、VS 2026固有のツールはVS 2022では利用できません。ツールの利用可能性はAzureサブスクリプションの権限にも依存します。ポータルと同じです。

より大きな視点

これは明確なトレンドの一部です：MCPは開発者IDEにクラウドツールを提供するための標準になりつつあります。すでにAzure MCP Server 2.0の安定版リリースやVS Codeをはじめとする各種エディタでのMCP統合が進んでいます。Visual Studioのワークロードシステムへの組み込みは、その自然な進化です。

Visual Studioで日々開発している.NET開発者にとって、Azureポータルへのコンテキストスイッチの理由がまた一つ減りました。正直なところ、タブの切り替えは少なければ少ないほど良いですからね。

Aspire 13.2にMongoDB EF CoreとAzure Data Lakeが追加 — 試す価値のある2つのインテグレーション

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

Aspire 13.2が2つの新しいデータベースインテグレーションと共にリリースされました。注目すべきはMongoDB Entity Framework CoreとAzure Data Lake Storageです。AspireアプリでMongoDBとEF Coreを使いたかった方、あるいはサービスディスカバリ付きでData Lakeワークロードを接続したかった方にとって、今回のリリースはまさにそれを提供してくれます。

AspireでMongoDBとEF Coreが出会う

これが一番ワクワクしているインテグレーションです。AspireはMongoDBを以前からサポートしていましたが、常に生のドライバーでした — EF Coreなし、DbContextなし、ドキュメントに対するLINQクエリなし。今回から、MongoDBでフルのEF Core体験が得られるようになり、さらにAspireの自動ヘルスチェックとサービスディスカバリも付いてきます。

セットアップは典型的なAspireパターンです。AppHostで：

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

次に、コンシューマープロジェクトでEF Coreインテグレーションを追加します：

dotnet add package Aspire.MongoDB.EntityFrameworkCore

そしてDbContextを登録します：

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

あとは標準的なEF Coreです。エンティティを定義し、他のプロバイダーと同じようにDbContextを使います。コネクションプーリング、OpenTelemetryトレース、ヘルスチェックはインテグレーションがバックグラウンドで処理します。

生のドライバーでMongoDBを使い、コネクション文字列を手動で設定していた.NET開発者にとって、これは嬉しい改善です。Aspireのサービスディスカバリを失うことなく、EF Coreの完全な抽象化が手に入ります。

Azure Data Lake Storageが仲間入り

2つ目の大きな追加はAzure Data Lake Storage（ADLS）インテグレーションです。データパイプライン、ETLプロセス、分析プラットフォームを構築しているなら、他のAspire依存関係と同じ方法でData Lakeリソースを接続できるようになりました。

AppHostで：

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

コンシューマープロジェクトで：

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

コネクション文字列の手動管理も、資格情報の探索も不要です。Aspireがリソースをプロビジョニングして注入します。オペレーショナルデータと分析ワークロードの両方を扱うクラウドネイティブな.NETアプリを構築している私たちにとって、Data LakeがAspireモデルのファーストクラスシチズンのように感じられるようになります。

地味だけど大事な修正

メイン機能以外にも、いくつかの改善が注目に値します：

MongoDBコネクション文字列の修正 — データベース名の前のスラッシュが正しく処理されるようになりました。ワークアラウンドを使っていた方は、もう不要です
SQL Serverエクスポート — Aspire.Hosting.SqlServerが追加のサーバー構成オプションをエクスポートし、より細かい制御が可能に
エミュレーターの更新 — ServiceBusエミュレーター2.0.0、App Configurationエミュレーター1.0.2、CosmosDBのプレビューエミュレーターにレディネスチェックが追加
Azure Managed Redis — デフォルトでrediss://（Redis Secure）を使用するようになり、接続が最初から暗号化されます

最後のポイントは地味ですが重要です — デフォルトで暗号化されたRedisは、本番環境で設定すべきことが1つ減ることを意味します。

まとめ

Aspire 13.2はインクリメンタルなリリースですが、MongoDB EF CoreとData Lakeのインテグレーションは実際のギャップを埋めてくれます。AspireでのMongoDBに対する適切なEF Coreサポートを待っていた方、またはData Lakeをファーストクラスの依存関係として必要としていた方は、13.2にアップグレードして試してみてください。aspire addコマンドで必要なものがすべてスキャフォールドされます。

完全なリリースノートで詳細を確認し、インテグレーションギャラリーで完全なリストをチェックしてください。

azd update — すべてのパッケージマネージャーを統べる一つのコマンド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

数週間ごとに表示される「azdの新しいバージョンが利用可能です」というメッセージ、知っていますか？ azdをwingetでインストールしたのか、Homebrewなのか、それとも半年前に実行したcurlスクリプトなのか思い出せなくて、つい無視してしまうあのメッセージです。ついに解決しました。

Microsoftがazd updateをリリースしました — 元々のインストール方法に関係なく、Azure Developer CLIを最新バージョンにアップデートできる単一のコマンドです。Windows、macOS、Linux — 関係ありません。コマンド一つで完了です。

仕組み

azd update

これだけです。新機能に早くアクセスしたい場合は、デイリーのInsidersビルドに切り替えることもできます：

azd update --channel daily
azd update --channel stable

このコマンドは現在のインストール方法を自動検出し、裏側で適切なアップデートメカニズムを使用します。もう「この PC では winget を使ったっけ、choco だったっけ？」と悩む必要はありません。

一つだけ注意点

azd updateはバージョン1.23.x以降で利用可能です。それより古いバージョンを使っている場合は、元のインストール方法で最後の手動アップデートを行う必要があります。その後はazd updateがすべてのアップデートを引き受けてくれます。

azd versionで現在のバージョンを確認してください。新規インストールが必要な場合は、インストールドキュメントを参照してください。

なぜ重要なのか

これは小さなQOL改善ですが、AIエージェントやAspireアプリをAzureにデプロイするためにazdを毎日使っている私たちにとって、最新の状態を保つことは「そのバグは最新バージョンで修正済みでした」という場面を減らすことを意味します。考えることが一つ減るのです。

詳細は公式アナウンスとJon Gallantの詳しい解説をご覧ください。

Azure Smart TierがGAに — ライフサイクルルール不要でBlob Storageのコストを自動最適化

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

Azure Blob Storageのライフサイクルポリシーの調整に時間をかけた結果、アクセスパターンが変わった途端に全部崩れた経験があるなら、この記事はまさにあなた向けです。Microsoftは、Azure BlobおよびData Lake Storage向けのsmart tierの一般提供を発表しました — 実際の使用状況に基づいて、オブジェクトをhot、cool、coldティア間で自動的に移動するフルマネージドのティアリング機能です。

Smart tierが実際にやること

コンセプトはシンプルです。smart tierはストレージアカウント内の各オブジェクトの最終アクセス時刻を継続的に評価します。頻繁にアクセスされるデータはhotに留まり、非アクティブなデータは30日後にcoolへ、さらに60日後にcoldへ移動します。データが再びアクセスされると、すぐにhotに昇格します。サイクルが再開します。

設定するライフサイクルルールなし。アクセスパターンの予測なし。手動チューニングなし。

プレビュー期間中、Microsoftはsmart tierで管理された容量の50%以上が、実際のアクセスパターンに基づいて自動的にクールなティアに移行したと報告しています。大規模なストレージアカウントにとって意味のあるコスト削減です。

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

ログ、テレメトリ、分析データ、あるいは何らかの成長するデータ資産を生成するアプリケーションを構築しているなら — 正直なところ、そうでない人はいないでしょう — ストレージコストはすぐに膨れ上がります。従来のアプローチは、ライフサイクル管理ポリシーを書き、テストし、アプリのアクセスパターンが変わったら再調整することでした。Smart tierはそのワークフロー全体を排除します。

これが役立つ実用的なシナリオ：

アプリケーションのテレメトリとログ — デバッグ中はhot、数週間後にはほとんどアクセスされない
データパイプラインとETL出力 — 処理中は頻繁にアクセス、その後はほぼcold
ユーザー生成コンテンツ — 最近のアップロードはhot、古いコンテンツは徐々に冷却
バックアップとアーカイブデータ — コンプライアンスのため時々アクセス、ほとんどアイドル

セットアップ方法

Smart tierの有効化は一度きりの設定です：

新しいアカウント：ストレージアカウント作成時にsmart tierをデフォルトのアクセスティアとして選択（ゾーン冗長が必要）
既存のアカウント：blobアクセスティアを現在のデフォルトからsmart tierに切り替え

128 KiB未満のオブジェクトはhotに留まり、モニタリング料金は発生しません。それ以外は、ティア移行料金なし、早期削除料金なし、データ取得コストなしの標準hot/cool/cold容量料金を支払います。オブジェクトごとの月額モニタリング料金がオーケストレーションをカバーします。

知っておくべきトレードオフ

Smart tierのティアリングルールは固定です（30日→cool、90日→cold）。カスタムしきい値が必要な場合 — 例えば、特定のワークロードで7日後にcoolに移動したい場合 — ライフサイクルルールが引き続き正解です。そして両方を混ぜないでください：smart tierで管理されているオブジェクトにライフサイクルルールを使用すると競合する可能性があるため、避けてください。

まとめ

革命的ではありませんが、実際の運用上の頭痛の種を解決します。成長するBlob Storageアカウントを管理していて、ライフサイクルポリシーの維持に疲れているなら、smart tierを有効化してAzureに任せましょう。現在、ほぼすべてのゾーンパブリッククラウドリージョンで利用可能です。

AzureでAIエージェントをどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

今.NETでAIエージェントを構築しているなら、おそらく気づいていることがあるでしょう：Azureでホストする方法がたくさんあるということです。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents — どれも合理的に聞こえますが、実際に選ぶ段階になると困ります。MicrosoftがAzureでのAIエージェントホスティングに関する包括的なガイドを公開しました。これを.NET開発者の実践的な視点から整理します。

6つのオプション早見表

オプション	最適な用途	管理するもの
Container Apps	K8sの複雑さなしにコンテナを完全制御	オブザーバビリティ、状態、ライフサイクル
AKS	エンタープライズコンプライアンス、マルチクラスター、カスタムネットワーキング	すべて（それがポイント）
Azure Functions	イベント駆動の短時間エージェントタスク	ほぼなし — 真のサーバーレス
App Service	シンプルなHTTPエージェント、予測可能なトラフィック	デプロイ、スケーリング設定
Foundry Agents	ポータル/SDKによるコード不要エージェント	ほぼなし
Foundry Hosted Agents	マネージドインフラでカスタムフレームワークエージェント	エージェントコードのみ

最初の4つは汎用コンピュートです — エージェントを動かすことはできますが、そのために設計されたものではありません。最後の2つはエージェントネイティブで、会話、ツール呼び出し、エージェントのライフサイクルをファーストクラスの概念として理解しています。

Foundry Hosted Agents — .NETエージェント開発者にとってのスイートスポット

注目すべきはこれです。Foundry Hosted Agentsはちょうど中間に位置しています：自分のコード（Semantic Kernel、Agent Framework、LangGraph — 何でも）を実行する柔軟性がありながら、プラットフォームがインフラ、オブザーバビリティ、会話管理を処理します。

キーピースはHosting Adapterです — エージェントフレームワークをFoundryプラットフォームに接続する薄い抽象化レイヤーです。Microsoft Agent Frameworkの場合：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

これがホスティングの全体像です。アダプターがプロトコル変換、server-sent eventsによるストリーミング、会話履歴、OpenTelemetryトレーシングを自動的に処理します。カスタムミドルウェアも手動の配管作業も不要です。

デプロイは本当にシンプル

以前Container Appsにエージェントをデプロイしたことがありますが、状態管理やオブザーバビリティのためのグルーコードをたくさん書くことになります。Hosted Agentsとazdなら：

# AIエージェント拡張機能をインストール
azd ext install azure.ai.agents

# テンプレートから初期化
azd ai agent init

# ビルド、プッシュ、デプロイ — 完了
azd up

この1つのazd upがコンテナをビルドし、ACRにプッシュし、Foundryプロジェクトをプロビジョニングし、モデルエンドポイントをデプロイし、エージェントを起動します。5つのステップが1つのコマンドに凝縮されています。

組み込みの会話管理

本番で最も時間を節約するのはここです。独自の会話ステートストアを構築する代わりに、Hosted Agentsがネイティブに処理します：

# 永続的な会話を作成
conversation = openai_client.conversations.create()

# 最初のターン
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 2回目のターン — コンテキストが保持される
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redisなし。Cosmos DBセッションストアなし。メッセージシリアライゼーション用のカスタムミドルウェアなし。プラットフォームがすべて処理します。

私の判断フレームワーク

6つすべてのオプションを検討した結果、私のクイックメンタルモデルはこうです：

インフラゼロが必要？ → Foundry Agents（ポータル/SDK、コンテナなし）
カスタムエージェントコードがあるがマネージドホスティングが欲しい？ → Foundry Hosted Agents
イベント駆動の短期エージェントタスクが必要？ → Azure Functions
K8sなしで最大限のコンテナ制御が必要？ → Container Apps
厳格なコンプライアンスとマルチクラスターが必要？ → AKS
予測可能なトラフィックのシンプルなHTTPエージェント？ → App Service

Semantic KernelやMicrosoft Agent Frameworkで構築しているほとんどの.NET開発者にとって、Hosted Agentsが適切なスタート地点でしょう。scale-to-zero、組み込みOpenTelemetry、会話管理、フレームワークの柔軟性が得られます — Kubernetesの管理やオブザーバビリティスタックの構築なしに。

まとめ

AzureのエージェントホスティングランドスケープはFastに成熟しています。今日新しいAIエージェントプロジェクトを始めるなら、習慣でContainer AppsやAKSに手を伸ばす前に、Foundry Hosted Agentsを真剣に検討することをお勧めします。マネージドインフラは実際の時間を節約し、hosting adapterパターンでフレームワークの選択を維持できます。

Microsoftの完全ガイドとFoundry Samplesリポジトリで動作するサンプルを確認してください。

.NETのAgent Skillsが本気で柔軟になった

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

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

Microsoft Agent Frameworkでエージェントを構築しているなら、流れは分かっているはずです：スキルを定義し、プロバイダーに接続し、エージェントにどれを呼び出すか判断させる。新しいのはスキルの作り方であり、柔軟性の向上は大きなものです。

最新のアップデートでは、エージェントスキルの3つのオーサリングパターンが導入されました：ファイルベース、クラスベース、インラインコード定義。3つすべてが単一の AgentSkillsProviderBuilder に接続されるため、ルーティングロジックや特別なグルーコードなしで自由に組み合わせることができます。それぞれのパターンと、いつ使うべきかを説明します。

ファイルベースのスキル：出発点

ファイルベースのスキルはそのままの意味です — SKILL.mdファイル、オプションのスクリプト、参照ドキュメントを含むディスク上のディレクトリです。エージェントに新しい能力を与える最もシンプルな方法です：

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.mdのフロントマターでスキル名と説明を宣言し、指示セクションでスクリプトと参照の使い方をエージェントに伝えます：

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

そして SubprocessScriptRunner.RunAsync でスクリプト実行を接続します：

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

エージェントは自動的にスキルを発見し、アカウントステータスを確認する必要があるときにプロビジョニングスクリプトを呼び出します。クリーンでシンプルです。

クラスベースのスキル：NuGetで配布

ここからがチームにとって面白いところです。クラスベースのスキルは AgentClassSkill<T> から派生し、[AgentSkillResource] や [AgentSkillScript] などの属性を使用して、フレームワークがリフレクションですべてを発見します：

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

素晴らしいのは、チームがこれをNuGetパッケージとしてパッケージ化できることです。プロジェクトに追加し、ビルダーに入れるだけで、ファイルベースのスキルと一緒に調整なしで動作します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

両方のスキルがエージェントのシステムプロンプトに表示されます。エージェントは会話に基づいてどちらを使うか判断します — ルーティングコードは不要です。

インラインスキル：素早いブリッジ

別のチームがまさに必要なスキルを構築しているけど、次のスプリントまで完成しない、あの瞬間を知っていますか？AgentInlineSkill があなたのブリッジです：

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

他のスキルと同じようにビルダーに追加します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGetパッケージが最終的にリリースされたら、インラインスキルをクラスベースのバージョンに交換するだけです。エージェントは違いに気づきません。

ただし、インラインスキルはブリッジだけのものではありません。ランタイムで動的にスキルを生成する必要がある場合 — 設定からロードされるビジネスユニットごとのスキルを考えてみてください — やスクリプトがDIコンテナに属さないローカルステートをキャプチャする必要がある場合にも適切な選択です。

スクリプト承認：ヒューマンインザループ

本番エージェントを構築する.NET開発者にとって、これがデプロイメントの議論を本当に前進させる部分です。一部のスクリプトには実際の影響があります — 誰かを福利厚生に登録する、本番インフラを照会する。UseScriptApproval を有効にすると、エージェントはスクリプト実行前に一時停止します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

エージェントがスクリプトを実行したいとき、代わりに承認リクエストを返します。アプリが判断を収集し — 承認または拒否 — エージェントはそれに応じて続行します。規制環境では、これが「デプロイできる」と「法務がノーと言っている」の違いです。

なぜこの組み合わせが重要なのか

本当の力は個々のパターンにあるのではなく、構成にあります。以下が可能になります：

ファイルベースのスキルで小さく始めて、指示を反復し、C#を書かずに公開する
他のチームが1行で追加できるNuGetパッケージとして再利用可能なスキルを配布する
何か今すぐ必要なときにインラインスキルでギャップを埋める
エージェントが必要なものだけをロードするようにプレディケートで共有ディレクトリをフィルタリングする
本番システムに触れるスクリプトに人間の監視を追加する

これらすべてが AgentSkillsProviderBuilder を通じて構成されます。特別なルーティングなし、条件ロジックなし、スキルタイプチェックなし。

まとめ

.NETのエージェントスキルは、真に柔軟なオーサリングモデルを手に入れました。ファイルベースのスキルでプロトタイピングするソロ開発者であろうと、NuGet経由でパッケージ化された機能を配布するエンタープライズチームであろうと、パターンは適合します。そしてスクリプト承認メカニズムにより、人間のチェックポイントが必要な環境でも本番対応できます。

オリジナルの発表、Microsoft LearnのAgent Skillsドキュメント、GitHubの.NETサンプルをチェックして始めましょう。

Azure MCP Server 2.0 がリリース — セルフホスト型エージェンティッククラウドオートメーションがここに

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

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

最近 MCP と Azure で何かを構築している人なら、ローカル環境での体験がうまく機能していることはご存じでしょう。MCP サーバーを接続して、AI エージェントが Azure リソースと通信できるようにして、先へ進む。しかし、その設定をチーム全体で共有する必要が出た瞬間？そこが複雑になっていました。

もうそんなことはありません。Azure MCP Server が 2.0 安定版をリリースし、見出し機能はまさにエンタープライズチームが要望していたものです：セルフホスト型リモート MCP サーバーサポート。

Azure MCP Server とは？

簡単なおさらいです。Azure MCP Server は Model Context Protocol 仕様を実装し、Azure 機能を構造化された検出可能なツールとして公開します。AI エージェントがこれらを呼び出せます。これをエージェントと Azure 間の標準化された橋と考えてください — プロビジョニング、デプロイメント、監視、診断、すべて 1 つの一貫したインターフェース経由で。

数字を見ればわかります：57 の Azure サービス全体で 276 の MCP ツール。これは本格的なカバレッジです。

大きな変化：セルフホスト型リモート展開

ここが重要な点です。ローカルでマシン上で MCP を実行することは開発と実験には問題ありませんが、実際のチームシナリオでは以下が必要です：

開発者と内部エージェントシステム向けの共有アクセス
集中管理構成（テナントコンテキスト、サブスクリプションデフォルト、テレメトリ）
エンタープライズネットワークとポリシー境界
CI/CD パイプラインへの統合

Azure MCP Server 2.0 はこれらすべてに対応しています。HTTP ベースのトランスポート、適切な認証、一貫した統治を備えた集中管理内部サービスとしてデプロイできます。

認証には 2 つの確実なオプションがあります：

マネージド ID — Microsoft Foundry と並行して実行している場合
On-Behalf-Of（OBO）フロー — サインインしたユーザーのコンテキストを使用して Azure API を呼び出す OpenID Connect 委譲

この OBO フローは .NET 開発者にとって特に興味深いものです。これは、エージェンティックワークフローが過度な特権を持つサービスアカウントではなく、ユーザーの実際のアクセス許可で動作できることを意味します。最小権限の原則が組み込まれています。

セキュリティの強化

これは単なる機能リリースではなく、セキュリティリリースでもあります。2.0 リリースは以下を追加します：

より強いエンドポイント検証
クエリ指向ツールのインジェクションパターンに対する保護
開発環境用のより厳密な分離制御

MCP を共有サービスとして公開する場合、これらのセーフガードは重要です。本当に重要です。

どこで使用できますか？

クライアント互換性の状況は幅広いです。Azure MCP Server 2.0 は以下で動作します：

IDE：VS Code、Visual Studio、IntelliJ、Eclipse、Cursor
CLI エージェント：GitHub Copilot CLI、Claude Code
スタンドアロン：シンプルなセットアップ用のローカルサーバー
セルフホスト型リモート：2.0 の新しいスター

さらに、Azure US Government と 21Vianet が運用する Azure のソブリンクラウドサポートもあります。これは規制対象のデプロイメントに重要です。

.NET 開発者にとってこれが重要な理由

.NET でエージェンティックアプリケーションを構築している場合 — Semantic Kernel、Microsoft Agent Framework、または独自のオーケストレーションのいずれであっても — Azure MCP Server 2.0 は、エージェントが Azure インフラストラクチャと対話するための本番環境対応の方法を提供します。カスタム REST ラッパーは不要です。サービス固有の統合パターンは不要です。MCP があるだけです。

数日前にドロップされた MCP Apps 向けの Fluent API と組み合わせると、.NET MCP エコシステムは急速に成熟しています。

はじめに

パスを選択してください：

GitHub リポジトリ — ソースコード、ドキュメント、すべて
Docker イメージ — コンテナ化されたデプロイメント
VS Code 拡張機能 — IDE 統合
セルフホスティングガイド — 2.0 の旗艦機能

まとめ

Azure MCP Server 2.0 は、デモでは派手に見えないけれど、実際には万能を変えるようなインフラストラクチャアップグレードです。適切な認証、セキュリティ強化、ソブリンクラウドサポートを備えたセルフホスト型リモート MCP は、Azure でエージェンティックワークフローを構築している実際のチームに MCP が対応していることを示しています。「エンタープライズ対応」シグナルを待っていたなら — これです。

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機能になり、サーバー自体のコード変更は不要です。

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

GitHub Copilotのモダナイゼーション評価は、まだ使っていない最高の移行ツール

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

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

レガシーな.NET Frameworkアプリをモダンな.NETに移行することは、誰もがやるべきだと知っているのに誰も始めたがらないタスクの一つです。「ターゲットフレームワークを変えるだけ」では済みません。消えたAPI、もう存在しないパッケージ、まったく異なる動作をするホスティングモデル、そして何をコンテナ化し、何を書き直し、何をそのままにするかについての無数の小さな決断があります。

Jeffrey FritzがGitHub Copilotのモダナイゼーション評価の詳細な解説を公開しましたが、正直なところ、.NET向けで見た中で最高の移行ツーリングです。コード生成のためではありません — それは今や当たり前です。生成される評価ドキュメントのためです。

単なるコード提案エンジンではない

VS Code拡張機能は評価 → 計画 → 実行モデルに従います。評価フェーズはコードベース全体を分析し、すべてをキャプチャする構造化ドキュメントを生成します：何を変更する必要があるか、どのAzureリソースをプロビジョニングするか、どのデプロイモデルを使用するか。その後のすべて — Infrastructure as Code、コンテナ化、デプロイマニフェスト — は評価結果から流れます。

評価はプロジェクトの.github/modernize/assessment/に保存されます。各実行は独立したレポートを生成するため、履歴が蓄積され、Issueを修正するにつれて移行の態勢がどう進化しているか追跡できます。

2つの始め方

推奨評価 — 素早い方法。キュレーションされたドメイン（Java/.NETアップグレード、Cloud Readiness、セキュリティ）から選び、設定をいじらずに意味のある結果を得ます。アプリがどこにいるかの最初の確認に最適です。

カスタム評価 — ターゲットを絞った方法。何を分析するか正確に設定：ターゲットコンピュート（App Service、AKS、Container Apps）、ターゲットOS、コンテナ化分析。複数のAzureターゲットを選んで移行アプローチを並べて比較できます。

その比較ビューは本当に便利です。App Serviceで必須Issueが3つのアプリが、AKSでは7つかもしれません。両方を見ることで、移行パスにコミットする前にホスティングの決定を導けます。

Issueの内訳はアクション可能

各Issueには重大度レベルが付いています：

必須 — 修正しなければ移行が失敗
潜在的 — 移行に影響する可能性あり、人間の判断が必要
オプション — 推奨される改善、移行をブロックしない

そして各Issueは影響を受けるファイルと行番号にリンクし、何が問題でなぜターゲットプラットフォームにとって重要なのかの詳細な説明を提供し、具体的な修正手順を示し（「これを直して」だけでなく）、公式ドキュメントへのリンクを含みます。

個々のIssueを開発者に渡すことができ、彼らにはアクションに必要なすべてが揃っています。これが「問題がある」と伝えるツールと「解決方法」を伝えるツールの違いです。

カバーされるアップグレードパス

.NET向け具体的に：

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

各アップグレードパスには、どのAPIが削除されたか、どのパターンに直接の等価物がないか、どのセキュリティ問題に注意が必要かを知る検出ルールがあります。

複数のアプリを管理するチーム向けには、マルチレポのバッチ評価をサポートするCLIもあります — すべてのリポをクローンし、すべてを評価し、アプリごとのレポートと集約されたポートフォリオビューを取得できます。

私の見解

レガシーな.NET Frameworkアプリを抱えているなら（そして正直に言って、ほとんどのエンタープライズチームがそうです）、これが始めるための最適なツールです。評価ドキュメントだけでも時間の価値があります — 漠然とした「モダナイズすべき」を、明確な前進の道筋を持つ具体的で優先順位付けされた作業項目リストに変えてくれます。

コラボレーティブなワークフローも賢いです：評価をエクスポートし、チームと共有し、再実行せずにインポート。意思決定者がツールを実行する人ではないアーキテクチャレビュー？カバーされています。

まとめ

GitHub Copilotのモダナイゼーション評価は、.NETの移行を怖い未定義のプロジェクトから構造化された追跡可能なプロセスに変えます。推奨評価から始めて現在地を確認し、カスタム評価でAzureターゲットを比較して移行計画を構築しましょう。

完全なウォークスルーを読み、VS Code拡張機能を入手して自分のコードベースで試してみてください。

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によるオープンモデル推論 — プラットフォームは本格的なワークロードに対応する準備が整っています。

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

SQL MCP Server — AIエージェントにデータベースアクセスを与える正しい方法

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

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

正直に言いましょう：今日利用可能なほとんどのデータベースMCPサーバーは恐ろしいものです。自然言語のクエリを受け取り、その場でSQLを生成し、本番データに対して実行します。何がうまくいかないでしょうか？（全部です。全部うまくいかない可能性があります。）

Azure SQLチームがSQL MCP Serverを発表しましたが、根本的に異なるアプローチを取っています。Data API builder（DAB）2.0の機能として構築され、AIエージェントに構造化された決定的なデータベース操作アクセスを提供します — NL2SQLなし、スキーマの公開なし、そしてすべてのステップで完全なRBAC付き。

なぜNL2SQLを使わないのか？

これが最も興味深い設計判断です。モデルは決定的ではなく、複雑なクエリは微妙なエラーを生み出す可能性が最も高いです。ユーザーがAIに生成してほしいと思う正にそのクエリが、非決定的に生成された場合に最も精査が必要なものでもあります。

代わりに、SQL MCP ServerはNL2DABアプローチを使用します。エージェントはData API builderのエンティティ抽象化レイヤーと組み込みのクエリビルダーで作業し、正確で整形されたT-SQLを決定的に生成します。ユーザーにとっては同じ結果ですが、幻覚されたJOINや偶発的なデータ漏洩のリスクがありません。

7つのツール、700ではなく

SQL MCP Serverは、データベースのサイズに関係なく、正確に7つのDMLツールを公開します：

describe_entities — 利用可能なエンティティと操作を発見
create_record — 行を挿入
read_records — テーブルとビューをクエリ
update_record — 行を変更
delete_record — 行を削除
execute_entity — ストアドプロシージャを実行
aggregate_records — 集計クエリ

これは賢明です。コンテキストウィンドウはエージェントの思考空間だからです。何百ものツール定義で氾濫させると、推論のための空間が減ります。7つの固定ツールは、エージェントをナビゲーションではなく思考に集中させ続けます。

各ツールは個別に有効化・無効化できます：

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

3つのコマンドで開始

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

これでCustomersテーブルを公開するSQL MCP Serverが稼働します。エンティティ抽象化レイヤーにより、名前やカラムにエイリアスを設定し、ロールごとにフィールドを制限し、エージェントが見るものを正確に制御できます — 内部スキーマの詳細を公開することなく。

セキュリティストーリーは堅実

ここがData API builderの成熟さが活きるところです：

あらゆるレイヤーでRBAC — 各エンティティがどのロールが読み取り、作成、更新、削除できるか、どのフィールドが表示されるかを定義
Azure Key Vault統合 — 接続文字列とシークレットを安全に管理
Microsoft Entra + カスタムOAuth — 本番グレードの認証
Content Security Policy — エージェントは生のSQLではなく、制御されたコントラクトを通じてやり取り

スキーマの抽象化は特に重要です。内部テーブル名やカラム名はエージェントに露出しません。AI対話に意味のあるエンティティ、エイリアス、説明を定義します — データベースのERD図ではなく。

マルチデータベースとマルチプロトコル

SQL MCP ServerはMicrosoft SQL、PostgreSQL、Azure Cosmos DB、MySQLをサポートします。そしてDABの機能であるため、同じ設定からREST、GraphQL、MCPのエンドポイントを同時に取得できます。同じエンティティ定義、同じRBACルール、同じセキュリティ — 3つのプロトコルすべてで。

DAB 2.0の自動設定は、データベースを検査して設定を動的に構築することもできます。迅速なプロトタイピングのために抽象化を減らしても良い場合に便利です。

私の見解

これがAIエージェント向けのエンタープライズデータベースアクセスのあるべき姿です。「ねぇLLM、SQLを書いてプロダクションにYOLO」ではなく。代わりに：明確に定義されたエンティティレイヤー、決定的なクエリ生成、各ステップでのRBAC、キャッシュ、モニタリング、テレメトリ。最高の意味で退屈です。

.NET開発者にとって、統合ストーリーはクリーンです — DABは.NETツールで、MCP Serverはコンテナとして動作し、ほとんどの人がすでに使っているAzure SQLで機能します。データアクセスが必要なAIエージェントを構築しているなら、ここから始めましょう。

まとめ

SQL MCP Serverは無料、オープンソースで、どこでも動作します。AIエージェントに安全なデータベースアクセスを提供するためのMicrosoftの規範的アプローチです。始めるには完全な記事とドキュメントをご覧ください。

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — Git-APEがその方法を示す

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

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

プラットフォームエンジニアリングは、カンファレンスでは素晴らしく聞こえるけど、実際には「内部ポータルとTerraformラッパーを作りました」という意味になりがちな用語の一つです。本当の約束 — 安全で、ガバナンスが効いていて、高速なセルフサービスインフラ — はいつもあと数歩先にありました。

Azureチームがエージェンティックなプラットフォームエンジニアリングシリーズのパート2を公開しました。今回はハンズオンの実装がテーマです。彼らはこれをGit-APEと呼んでいます（はい、頭字語は意図的です）。これはGitHub CopilotエージェントとAzure MCPサーバーを使って、自然言語のリクエストを検証済みでデプロイされたインフラに変換するオープンソースプロジェクトです。

Git-APEが実際にやること

コアアイデア：開発者がTerraformモジュールを学んだり、ポータルUIをナビゲートしたり、プラットフォームチームにチケットを切る代わりに、Copilotエージェントに話しかけます。エージェントが意図を解釈し、Infrastructure-as-Codeを生成し、ポリシーに対して検証し、デプロイします — すべてVS Code内で。

セットアップはこちら：

git clone https://github.com/Azure/git-ape
cd git-ape

VS Codeでワークスペースを開くと、エージェント設定ファイルがGitHub Copilotによって自動検出されます。エージェントと直接やり取りします：

@git-ape deploy a function app with storage in West Europe

エージェントは内部でAzure MCPサーバーを使ってAzureサービスとやり取りします。VS Code設定のMCP構成で特定の機能を有効にします：

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

なぜこれが重要か

Azureで構築している私たちにとって、これはプラットフォームエンジニアリングの議論を「ポータルをどう構築するか」から「ガードレールをどうAPIとして記述するか」にシフトさせます。プラットフォームのインターフェースがAIエージェントになると、制約とポリシーの品質がプロダクトになります。

パート1のブログは理論を提示しました：よく記述されたAPI、コントロールスキーマ、明示的なガードレールがプラットフォームをエージェント対応にします。パート2は実際のツールを提供することでそれが機能することを証明しています。エージェントはリソースを盲目的に生成するのではなく、ベストプラクティスに対して検証し、命名規則を尊重し、組織のポリシーを適用します。

クリーンアップも同様に簡単です：

@git-ape destroy my-resource-group

私の見解

正直に言うと、これは特定のツールよりもパターンについてです。Git-APE自体はデモ/リファレンスアーキテクチャです。しかし根底にあるアイデア — プラットフォームへのインターフェースとしてのエージェント、プロトコルとしてのMCP、ホストとしてのGitHub Copilot — これがエンタープライズの開発者体験が向かう方向です。

内部ツールをエージェントフレンドリーにする方法を探しているプラットフォームチームなら、これ以上の出発点はありません。そして.NET開発者として自分の世界とどう繋がるか気になるなら：Azure MCPサーバーとGitHub Copilotエージェントはどんなのワークロードでも動作します。ASP.NET Core API、.NET Aspireスタック、コンテナ化されたマイクロサービス — すべてがエージェンティックなデプロイフローのターゲットになり得ます。

まとめ

Git-APEは、エージェンティックなプラットフォームエンジニアリングの実践における初期だが具体的な姿です。リポジトリをクローンし、デモを試し、プラットフォームのAPIとポリシーがエージェントに安全に使われるためにどうあるべきか考え始めてください。

完全な記事でウォークスルーとデモ動画をご覧ください。

ブラックボックスに感じないリアルタイムマルチエージェントUIを構築する

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

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

マルチエージェントシステムの問題点はこうです：デモでは信じられないほど素晴らしく見えます。3つのエージェントが作業を受け渡し、問題を解決し、意思決定を行う。でも実際のユーザーの前に置いてみると…沈黙。回転するインジケーター。どのエージェントが何をしているのか、なぜシステムが停止しているのか分からない。これはプロダクトではありません — 信頼の問題です。

Microsoft Agent Frameworkチームが、MAFワークフローとAG-UIを組み合わせる素晴らしいウォークスルーを公開しました。AG-UIはServer-Sent Eventsを介してエージェント実行イベントをフロントエンドにストリーミングするオープンプロトコルです。正直に言うと、これはまさに私たちに欠けていた架け橋です。

.NET開発者にとって重要な理由

AI搭載アプリを構築しているなら、おそらくこの壁にぶつかったことがあるでしょう。バックエンドのオーケストレーションは完璧に動作します — エージェント同士がタスクを受け渡し、ツールが実行され、意思決定が行われます。しかしフロントエンドは裏で何が起きているか全く分かりません。AG-UIは、エージェントイベント（RUN_STARTED、STEP_STARTED、TOOL_CALL_*、TEXT_MESSAGE_*など）をSSE経由でUIレイヤーに直接ストリーミングする標準プロトコルを定義することでこれを解決します。

デモは3つのエージェントを使ったカスタマーサポートワークフローです：リクエストをルーティングするトリアージエージェント、金銭関連を処理する返金エージェント、そして交換を管理する注文エージェント。各エージェントは独自のツールを持ち、ハンドオフトポロジーは明示的に定義されています — 「プロンプトから推測する」ようなことはありません。

ハンドオフトポロジーが真の主役

私の目を引いたのは、HandoffBuilderでエージェント間の有向ルーティンググラフを宣言できることです：

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

各add_handoffは自然言語の説明付きの有向エッジを作成します。フレームワークはこのトポロジーに基づいて各エージェントのハンドオフツールを生成します。つまり、ルーティングの決定はオーケストレーション構造に基づいており、LLMの気分次第ではありません。これは本番環境の信頼性にとって非常に大きな意味があります。

本当に機能するHuman-in-the-loop

デモでは、実際のエージェントアプリに必要な2つの割り込みパターンを紹介しています：

ツール承認割り込み — エージェントがapproval_mode="always_require"とマークされたツールを呼び出すと、ワークフローが一時停止してイベントを発行します。フロントエンドはツール名と引数を含む承認モーダルをレンダリングします。トークンを消費するリトライループはありません — クリーンな一時停止-承認-再開フローです。

情報リクエスト割り込み — エージェントがユーザーからより多くのコンテキスト（注文IDなど）を必要とする場合、一時停止して質問します。フロントエンドが質問を表示し、ユーザーが回答し、実行は停止した箇所からそのまま再開されます。

両方のパターンは標準のAG-UIイベントとしてストリーミングされるため、フロントエンドはエージェントごとのカスタムロジックを必要としません — SSE接続を通じて届くイベントをそのまま表示するだけです。

接続は驚くほど簡単

MAFとAG-UIの統合は単一の関数呼び出しで完了します：

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factoryはスレッドごとに新しいワークフローを作成し、各会話が分離された状態を持ちます。エンドポイントはすべてのSSE配管を自動的に処理します。すでにFastAPIを使っている（または軽量レイヤーとして追加できる）なら、ほぼゼロフリクションです。

私の見解

私たち.NET開発者にとって、すぐに浮かぶ質問は「C#でできるのか？」です。Agent Frameworkは.NETとPythonの両方で利用可能で、AG-UIプロトコルは言語に依存しません（ただのSSEです）。この特定のデモはPythonとFastAPIを使用していますが、パターンは直接転用できます。同じAG-UIイベントスキーマに従ったSSEエンドポイントを持つASP.NET Core最小APIを構築できるでしょう。

より大きなポイントは、マルチエージェントUIが後付けではなくファーストクラスの関心事になりつつあるということです。エージェントが人間と対話するものを構築しているなら — カスタマーサポート、承認ワークフロー、ドキュメント処理 — MAFオーケストレーションとAG-UIの透明性の組み合わせが、従うべきパターンです。

まとめ

AG-UI + Microsoft Agent Frameworkは、バックエンドでの堅牢なマルチエージェントオーケストレーションとフロントエンドでのリアルタイム可視性という、両方の良いところを提供します。もうブラックボックスのエージェントインタラクションとはお別れです。

完全なウォークスルーとAG-UIプロトコルリポジトリをチェックして、さらに深く掘り下げてください。

azdでAIエージェントをローカル実行・デバッグ可能に — 2026年3月の変更点まとめ

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

1ヶ月で7つのリリース。これがAzure Developer CLI（azd）チームが2026年3月に出荷したもので、メイン機能は私が待っていたもの：AIエージェントのローカル実行＆デバッグループです。

PC Chanが完全なまとめを公開しましたが、内容が多いので、AI搭載アプリを構築する.NET開発者にとって本当に重要なことにフィルタリングしましょう。

デプロイなしでAIエージェントを実行・デバッグ

これが一番大きいです。新しいazure.ai.agents拡張機能がAIエージェントの適切なインナーループ体験を提供するコマンドを追加します：

azd ai agent run — エージェントをローカルで起動
azd ai agent invoke — メッセージを送信（ローカルまたはデプロイ済み）
azd ai agent show — コンテナのステータスとヘルスを表示
azd ai agent monitor — コンテナログをリアルタイムでストリーミング

以前は、AIエージェントのテストは変更するたびにMicrosoft Foundryへのデプロイを意味しました。今ではローカルで反復し、エージェントの動作をテストし、準備ができたときだけデプロイできます。

GitHub Copilotがazdプロジェクトをセットアップ

azd initに「Set up with GitHub Copilot (Preview)」オプションが追加されました。プロジェクト構造についてのプロンプトに手動で回答する代わりに、Copilotエージェントが設定を生成します。コマンドが失敗した場合、azdがAI支援のトラブルシューティングを提供します。

Container App Jobsとデプロイの改善

Container App Jobs：azdが既存のhost: containerapp設定でMicrosoft.App/jobsをデプロイ可能に
設定可能なデプロイタイムアウト：azd deployの新しい--timeoutフラグとazure.yamlのdeployTimeoutフィールド
リモートビルドフォールバック：ACRビルドが失敗するとローカルDocker/Podmanビルドに自動フォールバック
ローカルプリフライト検証：デプロイ前にBicepパラメータをローカルで検証

DXの改善

pnpm/yarn自動検出 — JS/TSプロジェクト向け
pyproject.tomlサポート — Pythonパッケージング向け
ローカルテンプレートディレクトリ — azd init --templateがファイルシステムパスを受け入れ
改善されたエラーメッセージ — --no-promptモード
ビルド環境変数 — すべてのフレームワークビルドサブプロセスに注入（.NET、Node.js、Java、Python）

まとめ

ローカルAIエージェントデバッグループがこのリリースの主役ですが、デプロイ改善とDXポリッシュの積み重ねにより、azdはかつてないほど成熟しています。AzureにDotNetアプリをデプロイしているなら — 特にAIエージェント — このアップデートは価値があります。

完全なリリースノートで全詳細をご確認ください。

KubeCon Europe 2026：.NET開発者が本当に知るべきこと

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

巨大なアナウンス記事が出て、スクロールしながら「クール、でも実際に自分にとって何が変わるの？」と思うあの感覚、分かりますよね？毎回KubeConシーズンになると私はそうなります。

MicrosoftがKubeCon Europe 2026の完全なまとめを公開しました。Brendan Burns自身が執筆しています。正直に言うと、ここには本物の中身があります。機能のチェックリストだけでなく、本番環境での運用方法を変える運用面の改善です。

.NET開発者として本当に重要なことを整理しましょう。

サービスメッシュ税なしのmTLS

サービスメッシュの問題点：全員がセキュリティの保証を求めるけど、運用オーバーヘッドは誰も望まない。AKSがついにこのギャップを埋めています。

Azure Kubernetes Application Networkは、相互TLS、アプリケーション認識型の認可、トラフィックテレメトリを提供します。サイドカーの重いフルメッシュをデプロイする必要はありません。Advanced Container Networking ServicesのCilium mTLSと組み合わせれば、X.509証明書とSPIREによるID管理を使った暗号化されたpod間通信が実現します。

実際にはどういうことか：ASP.NET Core APIがバックグラウンドワーカーと通信する、gRPCサービスが相互に呼び出す — すべてがネットワークレベルで暗号化・ID検証され、アプリケーションコードの変更はゼロ。これは大きいです。

ingress-nginxから移行しているチームには、Meshless IstioによるApplication Routingもあり、Kubernetes Gateway APIの完全サポート付きです。サイドカーなし。標準ベース。段階的な移行のためのingress2gatewayツールも提供されています。

後付けではないGPUオブザーバビリティ

.NETサービスと並行してAI推論を実行している場合（正直、誰が始めていないでしょうか？）、GPUモニタリングの盲点に遭遇したことがあるでしょう。CPU/メモリのダッシュボードは素晴らしかったのに、GPUについては手動のエクスポーター設定なしでは何もなかった。

AKSはGPUメトリクスをネイティブにマネージドPrometheusとGrafanaに表示するようになりました。同じスタック、同じダッシュボード、同じアラートパイプライン。カスタムエクスポーターもサードパーティエージェントも不要。

ネットワーク側では、HTTP、gRPC、Kafkaトラフィックのフローごとの可視性がワンクリックAzure Monitor体験で追加されました。IP、ポート、ワークロード、フロー方向、ポリシー判定 — すべてが組み込みダッシュボードに。

そして二度見させられたもの：agentic container networkingは、クラスターのネットワーク状態について自然言語で質問できるWeb UIを追加します。「ポッドXがサービスYに到達できないのはなぜ？」→ ライブテレメトリからの読み取り専用診断。午前2時に本当に役立ちます。

博士号不要のクロスクラスターネットワーキング

マルチクラスターKubernetesは歴史的に「自分でネットワークの接着剤を持ってくる」体験でした。Azure Kubernetes Fleet Managerが、マネージドCiliumクラスターメッシュによるクロスクラスターネットワーキングを提供するようになりました：

AKSクラスター間の統一された接続性
クロスクラスター検出のためのグローバルサービスレジストリ
クラスターごとに繰り返すのではなく中央で管理される設定

レジリエンスやコンプライアンスのために複数リージョンで.NETマイクロサービスを実行しているなら、多くの脆弱なカスタムの接着剤が置き換えられます。West EuropeのサービスAがメッシュを通じてEast USのサービスBを発見して呼び出せます。一貫したルーティングとセキュリティポリシーが適用されます。

勇気を必要としないアップグレード

正直に言いましょう — 本番環境のKubernetesアップグレードはストレスフルです。「アップグレードして祈る」があまりにも多くのチームのデファクト戦略であり、クラスターがバージョンに遅れる主な理由です。

2つの新機能がこれを変えます：

Blue-greenエージェントプールアップグレードは新しい設定でパラレルなノードプールを作成します。動作を検証し、トラフィックを段階的に移動し、クリーンなロールバックパスを維持します。本番ノードでのインプレース変更はもう不要。

エージェントプールロールバックにより、アップグレードがうまくいかなかった場合、クラスターを再構築することなく、ノードプールを以前のKubernetesバージョンとノードイメージに戻せます。

組み合わせることで、オペレーターにアップグレードのライフサイクルに対する本当のコントロールを提供します。.NETチームにとっては、プラットフォームの速度が新しいランタイム、セキュリティパッチ、ネットワーク機能をどれだけ早く採用できるかを直接制御するため重要です。

AIワークロードがKubernetesのファーストクラス市民に

アップストリームのオープンソース作業も同様に重要です。Dynamic Resource Allocation (DRA)がKubernetes 1.36でGAになり、GPUスケジューリングがワークアラウンドではなく本物のファーストクラス機能になりました。

注目すべきプロジェクト：

プロジェクト	内容
AI Runway	推論のための共通Kubernetes API — K8sを知らなくてもモデルをデプロイ、HuggingFace検出とコスト見積もり付き
HolmesGPT	クラウドネイティブ向けのエージェント型トラブルシューティング — CNCF Sandboxプロジェクトに
Dalec	SBOM生成付きの宣言的コンテナイメージビルド — ビルド段階でのCVE削減

方向性は明確：あなたの.NET API、Semantic Kernelのオーケストレーション層、推論ワークロードはすべて一貫したプラットフォームモデル上で実行されるべきです。そこに向かっています。

今週から始めるなら

チームでこれらの変更を評価しているなら、私の正直な優先順位リスト：

まずオブザーバビリティ — 非本番クラスターでGPUメトリクスとネットワークフローログを有効にする。見逃していたものを確認する。
Blue-greenアップグレードを試す — 次の本番クラスターアップグレード前にロールバックワークフローをテストする。プロセスへの信頼を構築する。
ID認識型ネットワーキングをパイロット — 内部サービスパスを1つ選んでCiliumでmTLSを有効にする。オーバーヘッドを測定する（ネタバレ：最小限）。
Fleet Managerを評価 — 2つ以上のクラスターを運用しているなら、クロスクラスターネットワーキングはカスタムの接着剤削減だけで元が取れる。

小さな実験、素早いフィードバック。それが常に正しい手。

まとめ

KubeConのアナウンスは圧倒的になりがちですが、今回のバッチはAKS上の.NETチームにとって本当に針を動かします。メッシュオーバーヘッドなしのより良いネットワークセキュリティ、本物のGPUオブザーバビリティ、より安全なアップグレード、そしてより強力なAIインフラストラクチャの基盤。

すでにAKSを使っているなら、運用ベースラインを強化する絶好のタイミングです。.NETワークロードをKubernetesに移行する予定なら — プラットフォームは大幅にプロダクションレディになりました。

SQL MCP Server、SSMS の Copilot、AI エージェント付き Database Hub：SQLCon 2026 で本当に重要なこと

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft がアトランタの FabCon と併催で SQLCon 2026 をキックオフしました。内容盛りだくさんです。元の発表はコスト削減プランからエンタープライズコンプライアンス機能まで全部カバーしていますが、エンタープライズ価格のスライドは飛ばして、Azure SQL と AI で開発している人にとって本当に重要な部分にフォーカスします。

SQL MCP Server がパブリックプレビューに

これが僕にとってのヘッドラインです。Azure SQL Database Hyperscale に SQL MCP Server のパブリックプレビューが追加され、Model Context Protocol を使って SQL データを AI エージェントや Copilot にセキュアに接続できるようになりました。

MCP の波を追いかけている人なら — 正直、今は見逃すほうが難しいですよね — これは大きなニュースです。データベースからのコンテキストを AI エージェントに渡すためにカスタムデータパイプラインを構築する代わりに、SQL データを直接公開するための標準化されたプロトコルが手に入ります。エージェントがライブのデータベース情報をクエリし、推論し、アクションを起こせるようになります。

Semantic Kernel や Microsoft Agent Framework で AI エージェントを構築している人にとって、これはクリーンな統合パスを開きます。エージェントが在庫を確認する必要がある？顧客レコードを検索する？注文を検証する？MCP がシナリオごとにカスタムのデータ取得コードを書かなくても、構造化されたやり方を提供してくれます。

SSMS 22 の GitHub Copilot が GA に

SQL Server Management Studio を使っている人 — 正直に言うと、ほとんどの人がまだ使っていますよね — GitHub Copilot が SSMS 22 で正式に一般提供になりました。VS Code や Visual Studio で使っているのと同じ Copilot 体験が T-SQL で使えます。

実用的な価値はシンプルです：クエリの作成、ストアドプロシージャのリファクタリング、パフォーマンス問題のトラブルシューティング、管理タスクのためのチャットベースのアシスタンス。コンセプトとしては革命的ではないですが、SSMS の中にあるということは、データベース作業で AI の助けを得るためだけに別のエディタにコンテキストスイッチする必要がないということです。

ベクトルインデックスが本格的にアップグレード

Azure SQL Database のベクトルインデックスが高速化・高機能化し、insert、update、delete の完全サポートが追加されました。つまり、ベクトルデータがリアルタイムで最新の状態を保てます — バッチ再インデックスは不要です。

新機能はこちら：

量子化 でインデックスサイズを縮小（精度の大きな損失なし）
イテレーティブフィルタリング でより精密な結果
クエリオプティマイザーとの緊密な統合 で予測可能なパフォーマンス

Azure SQL をベクトルストアとして Retrieval-Augmented Generation (RAG) を行っている場合、これらの改善は直接的に役立ちます。リレーショナルデータと同じデータベースにベクトルを保持できるので、別のベクトルデータベースを運用するよりもアーキテクチャが大幅にシンプルになります。

同じベクトルの改善は Fabric の SQL Database でも利用可能です。どちらも同じ SQL エンジンで動いているからです。

Fabric の Database Hub：エージェント型管理

これはもう少し将来を見据えた話ですが、面白いです。Microsoft は Microsoft Fabric の Database Hub（早期アクセス）を発表しました。Azure SQL、Cosmos DB、PostgreSQL、MySQL、SQL Server via Arc を一元的に管理できるビューを提供します。

面白いのは統一ビューだけではなく、エージェント型の管理アプローチです。AI エージェントがデータベース環境を継続的に監視し、何が変わったかを示し、なぜそれが重要かを説明し、次に何をすべきかを提案します。エージェントが下調べをして、あなたが判断を下す human-in-the-loop モデルです。

複数のデータベースを管理しているチームにとって、これは運用ノイズを本当に減らせる可能性があります。ポータル間を行き来してメトリクスを手動で確認する代わりに、エージェントがシグナルを届けてくれます。

.NET 開発者にとっての意味

これらの発表をつなぐ共通のテーマは明確です：Microsoft はデータベーススタックのあらゆるレイヤーに AI エージェントを組み込んでいます。ギミックとしてではなく、実用的なツールレイヤーとして。

Azure SQL をバックエンドにした .NET アプリを構築しているなら、僕が実際にやることはこれです：

SQL MCP Server を試す — AI エージェントを構築しているなら。カスタムの配管なしでエージェントにデータベースアクセスを与える最もクリーンな方法です。
SSMS で Copilot を有効にする — まだなら。日常の SQL 作業のための無料の生産性アップです。
ベクトルインデックスを調べる — RAG をやっていて現在別のベクトルストアを運用しているなら。Azure SQL に統合すれば、管理するサービスが一つ減ります。

まとめ

完全な発表にはもっとあります — コスト削減プラン、移行アシスタント、コンプライアンス機能 — でも開発者向けのストーリーは MCP Server、ベクトルの改善、エージェント型管理レイヤーにあります。これらが変えるのは、予算の立て方ではなく、構築の仕方です。

完全な全体像は Shireesh Thota の完全な発表をチェックしてください。新しい管理体験を試したい場合は Database Hub の早期アクセスにサインアップしてください。

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アナウンスメントをご覧ください。

Microsoft Agent Frameworkのバックグラウンドレスポンス：タイムアウトの不安から解放

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

o3やGPT-5.2のような推論モデルで何かを構築したことがあるなら、その痛みを知っているでしょう。エージェントが複雑なタスクについて考え始め、クライアントは待ち続け、「大丈夫」と「クラッシュした？」の間のどこかで接続がタイムアウトする。あの作業は？全て消えます。

Microsoft Agent Frameworkがバックグラウンドレスポンスをリリースしました — 正直なところ、これは初日から存在すべきだった機能の一つです。

ブロッキング呼び出しの問題

従来のリクエスト-レスポンスパターンでは、エージェントが終了するまでクライアントはブロックされます。簡単なタスクには問題ありません。しかし、推論モデルに深い調査、多段階分析、20ページのレポート生成を依頼する場合は？実時間で数分かかります。その間：

HTTP接続がタイムアウトする可能性がある
ネットワークの途切れが操作全体を壊す
ユーザーはスピナーを見つめて何かが起きているか疑問に思う

バックグラウンドレスポンスはこれを逆転させます。

継続トークンの仕組み

ブロックする代わりに、エージェントタスクを起動して継続トークンを受け取ります。修理工場の引換券のようなものです — カウンターに立って待つ必要はなく、準備ができたら戻ってくればいいのです。

フローは単純です：

AllowBackgroundResponses = trueでリクエストを送信
エージェントがバックグラウンド処理をサポートしていれば、継続トークンを受け取る
トークンがnullを返すまでポーリング — 結果の準備完了を意味します

.NETバージョンはこちら：

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// 完了までポーリング
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

エージェントがすぐに完了する場合（簡単なタスク、バックグラウンド処理を必要としないモデル）、継続トークンは返されません。コードはそのまま動きます — 特別な処理は不要です。

再開付きストリーミング：本当のマジック

ポーリングはfire-and-forgetシナリオには良いですが、リアルタイムの進捗が欲しい場合は？バックグラウンドレスポンスは再開機能付きストリーミングもサポートしています。

各ストリーム更新は独自の継続トークンを持ちます。ストリーム中に接続が切れても、中断した正確な位置から再開できます：

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // ネットワーク中断をシミュレート
}

// 中断した正確な位置から再開
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

クライアントに何が起きてもサーバー側でエージェントは処理を続けます。リトライロジックやサーキットブレーカーを書くことなく、組み込みのフォールトトレランスが実現します。

実際にいつ使うべきか

すべてのエージェント呼び出しにバックグラウンドレスポンスが必要なわけではありません。高速な完了には無駄な複雑さを追加するだけです。しかし、ここで威力を発揮します：

複雑な推論タスク — 多段階分析、深い調査、推論モデルを本気で考えさせるもの
長文コンテンツ生成 — 詳細レポート、複数パートのドキュメント、広範な分析
信頼性の低いネットワーク — モバイルクライアント、エッジデプロイメント、不安定な企業VPN
非同期UXパターン — タスクを送信し、他のことをして、結果を取りに戻る

エンタープライズアプリを構築する.NET開発者にとって、最後のポイントは特に興味深いです。ユーザーが複雑なレポートを要求するBlazorアプリを想像してください — エージェントタスクを起動し、プログレスインジケータを表示し、作業を続けてもらう。WebSocketの曲芸なし、カスタムキューインフラなし、トークンとポーリングループだけです。

まとめ

バックグラウンドレスポンスはMicrosoft Agent Frameworkを通じて.NETとPythonの両方で今すぐ利用可能です。単純なQ&A以上のことをするエージェントを構築しているなら、ツールキットに追加する価値があります。継続トークンパターンはシンプルさを保ちながら、非常に現実的な本番環境の問題を解決します。

完全なAPIリファレンスとその他のより例については完全なドキュメントをご覧ください。

ラップトップから本番へ：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エージェントのデプロイを先延ばしにしていたなら、試してみてください。フロントエンドチャットアプリ統合を含む完全なステップバイステップガイドは完全なウォークスルーをご覧ください。

Azure | 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

パッケージサイズの改善

なぜこれが重要か

Cosmos DB Shell はパブリック プレビューに — そして MCP サーバーが内蔵されている

他のデータベース CLI との違い

オープン ソースの基盤が重要

簡単になる 3 つのシナリオ

始め方

あなたの AI エージェントにはアイデンティティの問題があります（そしてこれがそれを解決するテンプレートです）

核心的な問題: 認証 ≠ 認可

トークンチェーンの仕組み

テンプレートがデプロイするもの

借りる価値のある設計原則

まとめ

プライベート Endpoints、VNet、NSG — Aspire がネットワークを管理するように

構成要素

AppHost での記述

実際のアプリケーションにとって重要な理由

まとめ

Aspire 13.3: Kubernetes サポート、ブラウザログ、Aspireify スキル

Aspireify: エージェント支援のオンボーディング

ファーストクラスの Kubernetes と AKS デプロイ

ダッシュボードのブラウザログ

構造化されたコマンド結果

まとめ

SDD Conference 2026

トピック

スピーカー

チケットと情報

Agentic Platform Engineering で移行の繰り返し作業をなくす

入力: contoso-migration

ステップ 1: 検証と認証

ステップ 2: 意図の抽出

ステップ 3: サービスマッピング

ステップ 4: 批評エージェント

ステップ 5: 生成された出力

セキュリティ体制の比較

構文コンバーターとの違い

SQL MCP ServerをAzure App Serviceで動かす — コンテナ不要

SQL MCP Serverとは？

コンテナの問題（と解決策）

共有APIキーなしの認証

App Serviceへのデプロイ

.NET開発者にとって重要な理由

まとめ

SQL Server 2025 エージェント対応データベース：1つのエンジンでセキュリティ、バックアップ、MCP

すべてのデータモデルに対する1つのセキュリティモデル

統一バックアップ = アトミックリカバリ

MCP統合：ハンドコードされたミドルウェア不要

Azure MCP Server が .mcpb になった — ランタイムなしでインストール

MCP Bundle とは？

インストール方法

できること

はじめるには

Azure SDK 2026年4月: AI Foundry 2.0と.NET開発者が知るべきこと

Azure.AI.Projects 2.0.0 — 意味のある破壊的変更

Cosmos DB Java: 重大なセキュリティ修正（RCE）

.NET向け新しいProvisioningライブラリ

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

GPT-5 の進化

実際に何が変わったか

価格

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

Cosmos DB Shell はパブリックプレビューに — そして MCP サーバーが内蔵されている

オープンソースの基盤が重要

Azure MCP Server 2.0 がリリース — セルフホスト型エージェンティッククラウドオートメーションがここに