The .NET Blog

NDC Oslo 2026

Mon, 14 Sep 2026 00:00:00 +0000

NDC Oslo 2026 は 2026年9月14日〜18日 にノルウェー、オスロの Oslo Spektrum で開催されます。

NDC Oslo はヨーロッパで最も大きく、最も定評のある開発者カンファレンスの一つで、.NET、クラウド、セキュリティ、アーキテクチャ、AI など多岐にわたるテーマをカバーしています。2026年版は現在ブッキング中で、大規模なラインナップが形成されています。

数字で見る

160 セッション（ブッキング中）
150 スピーカー（ブッキング中）
15 ワークショップ（ブッキング中）
5 日間 — ワークショップ + カンファレンス

確定スピーカー

スピーカーリストは構築中で、確定した名前には以下が含まれます：

Nick Chapsas
Maddy Montaquila
Troy Hunt
Kevlin Henney
Venkat Subramaniam
Jeff Fritz
Philippe De Ryck
Nhlanhla Lucky Nkosi
Aleksander Stensby

チケット

Early Bird チケットが販売中 — Early Bird 特典は 2026年5月22日 まで。

CFP（Call for Papers）も受付中です。

2026年の他の NDC イベント

NDC Sydney — 2026年4月22日〜24日
NDC Toronto — 2026年5月5日〜8日
NDC Copenhagen — 2026年6月1日〜4日
NDC AI — 2026年6月8日〜10日
NDC TechTown — 2026年9月21日〜24日

リンク

.NET Day Switzerland 2026

Tue, 25 Aug 2026 00:00:00 +0000

.NET Day Switzerland 2026 は 2026年8月25日 に Arena Cinemas Sihlcity（Kalanderplatz 8, 8045 チューリッヒ）で開催されます。

開発者、アーキテクト、エキスパートが .NET、C#、ASP.NET Core、Azure、そしてMicrosoft開発エコシステム全体について議論するための、独立した非営利コミュニティカンファレンスです。すべてのスピーカーとスタッフはボランティアで参加し、チケット販売の余剰金は慈善活動またはスイスの .NET コミュニティに還元されます。

参加者へのメリット

国際的な専門家による高品質なセッション
他の参加者とのネットワーキング
休憩時間、ランチ、アペロ中の食事、スナック、飲み物
スポンサーとの交流によるキャリア機会
休憩中にスピーカーと直接対話

チケット

カテゴリ	価格	販売状況
Very Early Bird（4月1日〜30日）	299 CHF	最大100枚
Early Bird	399 CHF	最大100枚
通常	449 CHF	売り切れまで

スピーカーとスケジュールはまだ発表されていません — スピーカー募集は Sessionize で受付中です。

主催者

リンク

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%が全体的な体験を「良い」、「とても良い」、「素晴らしい」と評価しました。

Azure DevOps MCP Server 4月アップデート: WIQLクエリ、PAT認証、実験的MCP Apps

Emiliano Montesdeoca — Mon, 27 Apr 2026 00:00:00 +0000

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

Azure DevOps MCP Serverは着実に改善されています。Dan Hellemの4月アップデートは両方のサーバーをカバーしています。

WIQLクエリサポート

新しいwit_query_by_wiqlツールにより、MCPクライアントから直接Work Item Query Languageクエリを実行できます。

Personal Access Tokens

ローカルサーバーでのPAT認証 — インタラクティブ認証が利用できない統合シナリオに重要。

MCPアノテーション

読み取り専用、破壊的、オープンワールドツールのメタデータタグ — エージェントの信頼性の基盤。

Wikiツールの統合

5つの別々のWikiツール → 2つのより有能なツール。ツールが少ない = LLMパフォーマンスが向上。

実験的: MCP Apps

MCSサーバー環境内でパッケージ化されたワークフロー。方向性は正しい。

Dan Hellemのオリジナルポスト: Azure DevOps MCP Server April Update。

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。

.NET 10 が Ubuntu 26.04 LTS に搭載 — 新機能まとめ

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

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

Ubuntu LTS の日です。Ubuntu 26.04 (Resolute Raccoon) が今日リリースされ、すべての Ubuntu LTS と同様に最新の .NET LTS — この場合 .NET 10 — を搭載しています。

.NET 10 を 2 つのコマンドでインストール

sudo apt update
sudo apt install dotnet-sdk-10.0

.NET は Ubuntu 公式サポートのツールチェーンの一つです。サードパーティのアドオンではありません。

コンテナ：`-noble` を `-resolute` に更新

sed -i "s/noble/resolute/g" Dockerfile

Chiseled を含む既存のすべてのイメージバリアントが利用可能です。

Native AOT：3ms 起動、1.4MB バイナリ

apt install -y dotnet-sdk-aot-10.0 clang
dotnet publish app.cs
# artifacts/app/app — 1.4MB ネイティブバイナリ
# real 0m0.003s

コールドスタート時間が重要なクラウドネイティブワークロード — Functions、コンテナ、サーバーレス — にとって真のゲームチェンジャーです。

.NET 8 または 9 が必要な場合

apt install -y software-properties-common
add-apt-repository ppa:dotnet/backports
apt install -y dotnet-sdk-8.0

完全な記事で cgroup v2、ポスト量子暗号、Linux 7.0 の詳細を確認してください。

Agent FrameworkのCodeAct：エージェントのレイテンシを半分にする方法

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

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

エージェントプロジェクトの開発中、トレースを見て「なぜこんなに時間がかかるんだろう？」と思う瞬間があります。モデルは問題ない。ツールも動いている。でも、1回で計算できる結果を得るのに7回のラウンドトリップが発生している。

これがまさにCodeActが解決する問題です。Agent FrameworkチームはHyperlightパッケージでのアルファサポートをリリースしました。

CodeActとは？

CodeActパターンはエレガントにシンプルです。モデルにツールリストを渡して1つずつ呼び出させる代わりに、単一のexecute_codeツールを与え、計画全体を短いPythonプログラムとして表現させます。エージェントはコードを1回書き、サンドボックスがそれを実行し、1つの統合された結果を得ます。

方式	時間	トークン
従来型	27.81秒	6,890
CodeAct	13.23秒	2,489
改善	52.4%	63.9%

セキュリティ：Hyperlightマイクロ-VM

agent-framework-hyperlightパッケージはHyperlightのマイクロ-VMを使用します。各execute_code呼び出しは独自の新しいマイクロ-VMを取得します。起動はミリ秒単位で計測されます。分離はほぼコストゼロです。

ツールはホストで実行し続けます。モデルが生成したグルーコードはサンドボックスで実行されます。これが正しい分離です。

最小セットアップ

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

いつCodeActを使うか（使わないか）

CodeActを使う場合：

タスクが多くの小さなツール呼び出しを連鎖させる（ルックアップ、結合、計算）
レイテンシとトークンコストが重要
モデル生成コードに強力な分離が必要

従来のtool-callingを使う場合：

エージェントがターンごとに1〜2回しかツールを呼び出さない
各呼び出しに個別の承認が必要な副作用がある
ツールの説明が乏しいか曖昧

今すぐ試す

pip install agent-framework-hyperlight --pre

Agent Frameworkブログの完全な投稿でより詳しい解説をご覧ください。

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");

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

VS Code 1.118: Copilot CLI にセッション名、モデルバッジ、TypeScript 7.0 ナイトリーオプトイン

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

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

Visual Studio Code 1.118 は小さめで焦点を絞ったリリース — 主に Copilot CLI の改良 — ですが、いくつか注目すべき点があります。

Copilot CLI: セッションに実際の名前が付く

Copilot CLI SDK のセッションタイトル API がセッション名の情報源として使用されるようになりました。自動生成されたラベルではなく、SDK の実際の名前が表示されます。

キーボードショートカットで素早くセッション切り替え

Agents アプリに Ctrl+1、Ctrl+2 などのセッション切り替えキーが割り当てられました。複数の Copilot CLI セッションを並行して実行している場合、マウスクリックが大幅に減ります。

チャットにモデルバッジ表示

チャットパネルの Copilot CLI レスポンスにモデルバッジが表示されるようになりました — どのモデルが各リクエストを処理したかひと目でわかります。

Copilot CLI に自動モデル選択

自動モデル選択機能 — 以前は Copilot の他の部分で使用可能だった — が Copilot CLI エージェントでも機能するようになりました。

TypeScript 7.0 ナイトリーのオプトイン

VS Code の設定から TypeScript 7.0 ナイトリーをテストするオプトインが可能になりました。TypeScript 7.0 は大規模リリースです（ベータ版が数日前にリリース）。

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

あなたのエージェントはどこで物事を覚えているか？チャット履歴ストレージの実践ガイド

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

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

AIエージェントを構築する際、ほとんどのエネルギーをモデル、ツール、プロンプトに費やします。会話履歴がどこに保存されるかという問題は実装の詳細に見えますが、実は最も重要なアーキテクチャ上の決定の一つです。

これにより、ユーザーが会話を分岐させたり、回答を元に戻したり、再起動後にセッションを再開したりできるかどうか、そしてデータがインフラから出るかどうかが決まります。Agent FrameworkチームはLデープな分析を公開しました。

2つの基本パターン

サービス管理型: AIサービスが会話状態を保存します。アプリは参照（スレッドID、レスポンスID）を保持し、サービスは各リクエストに関連する履歴を自動的に含めます。

クライアント管理型: アプリが完全な履歴を管理し、各リクエストに関連メッセージを送信します。サービスはステートレスです。すべてを制御できます。

Agent Frameworkによる抽象化

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("私の名前はAliceです。", session);
var second = await agent.RunAsync("私の名前は何ですか？", session);

session = agent.create_session()
first = await agent.run("私の名前はAliceです。", session=session)
second = await agent.run("私の名前は何ですか？", session=session)

セッションが基礎的な違いを処理します。プロバイダーを切り替えてもアプリケーションコードは変わりません。

プロバイダー早見表

プロバイダー	ストレージ	モデル	圧縮
OpenAI/Azure Chat Completions	クライアント	N/A	開発者
Foundry Agent Service	サービス	線形	サービス
Responses API（デフォルト）	サービス	分岐型	サービス
Anthropic Claude, Ollama	クライアント	N/A	開発者

選び方

会話の分岐や「やり直し」が必要？ → サービス管理型のResponses API
データ主権が必要？ → データベースバックドプロバイダーのクライアント管理型
シンプルなチャットボット？ → サービス管理型の線形で十分

完全な記事で意思決定ツリー全体を確認してください。

Aspire 13.2: Bun サポート、コンテナ改善、デバッグの摩擦軽減

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

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

.NETバックエンドとJavaScriptフロントエンドをAspireで構築しているなら、13.2は静かにあなたの一日を良くする種類のアップデートです。

Bunがファーストクラスになりました

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

チームがすでにBunを使用している場合、Aspireはもはや逆流を強いません。

Yarnの信頼性向上

withYarn()とaddViteApp()での謎のエラーが減少します。

コンテナの改善

ImagePullPolicy.Neverでレジストリに行かずにローカルイメージを使用。PostgreSQL 18+のデータボリュームが正しく動作するようになりました。

デバッグの改善

コアタイプへのDebuggerDisplayAttribute、WaitForの改善されたエラーメッセージ、適切なタイミングで発火するBeforeResourceStartedEvent。

オリジナルポスト（David Pine著）: Aspire 13.2: Bun Support and Container Enhancements。

1日68分もコードを再説明している？解決策があります

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

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

Copilotセッションが/compactに達し、エージェントが何をしていたか完全に忘れてしまう瞬間を知っていますか？次の5分間、ファイル構造、失敗したテスト、すでに試した3つのアプローチを再説明します。そしてまた同じことが起きます。

Desi Villanueva が計測しました：1日68分 — 再オリエンテーションだけに。コードを書くのでも、PRをレビューするのでもなく、AIがすでに知っていたことを再び教えるだけに。

コンテキストウィンドウの嘘

実際の計算：200Kのうち、MCAツールで65K、インストラクションファイルで10K消費され、言葉を入力する前に125Kしか残りません。そして60%の容量で壁に当たります。

有効な制限：45Kトークン — これが実際の制約です。

コンパクション税

残酷な部分：記憶はすでに存在します。 Copilot CLIは~/.copilot/session-store.dbにすべてのセッションを書き込みます。エージェントはただ読めないだけです。

auto-memory：リコールレイヤー

pip install auto-memory

~1,900行のPython。依存関係ゼロ。30秒でインストール完了。

grepの洪水の代わりに、10,000トークンではなく50トークンで昨日触れたファイルへの外科的アクセスを提供します。

まとめ

コンテキストロットは本物のアーキテクチャ的制約です。auto-memoryはエージェントに安価で正確なリコールメカニズムを与えることでこれを回避します。

チェックしてみてください：GitHubのauto-memory。オリジナル記事（Desi Villanueva著）：I Wasted 68 Minutes a Day。

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ネイティブな設計は既に構築しているツールで機能することを意味する。公式発表で詳細を確認しよう。

Python、TypeScript、.NETでazdフックを書く：シェルスクリプトとの決別

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

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

完全に.NETで書かれたプロジェクトを持ちながら、azdのフックのためにBashスクリプトを書かなければならなかった経験はないだろうか。あの苦痛を知っている人は多いはず。C#でプロジェクト全体を書いているのに、なぜpre-provisioningのステップだけシェル構文に切り替えなければならないのか。

その不満がついに公式に解決された。Azure Developer CLIがフックのマルチ言語サポートを発表し、想像通りの素晴らしい機能となっている。

フックとは

フックはazdのライフサイクルの重要なポイントで実行されるスクリプト — プロビジョニング前、デプロイ後など。azure.yamlで定義され、CLIを変更せずにカスタムロジックを注入できる。

これまではBashとPowerShellのみサポートされていた。今やPython、JavaScript、TypeScript、.NETが使えるようになり、azdが残りを自動で処理する。

検出の仕組み

フックをファイルに向けるだけで、azdが拡張子から言語を推論する：

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

追加設定は不要。拡張子が曖昧な場合はkind: python（または対応する言語）を明示的に指定できる。

言語別の重要な詳細

Python

スクリプトと同じディレクトリ（または親ディレクトリ）にrequirements.txtやpyproject.tomlを置くだけ。azdが自動的に仮想環境を作成し、依存関係をインストールしてスクリプトを実行する。

JavaScriptとTypeScript

同じパターン — スクリプトの近くにpackage.jsonを置くとazdがまずnpm installを実行する。TypeScriptの場合はnpx tsxを使用し、コンパイルステップもtsconfig.jsonも不要。

.NET

2つのモードが利用可能：

プロジェクトモード：スクリプトの隣に.csprojがあれば、azdが自動的にdotnet restoreとdotnet buildを実行。
シングルファイルモード：.NET 10以降では、スタンドアロンの.csファイルをdotnet run script.csで直接実行可能。プロジェクトファイル不要。

エグゼキューター固有の設定

各言語はオプションのconfigブロックをサポート：

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET開発者にとっての重要性

フックはazd基盤のプロジェクトで言語切り替えを強制する最後の場所だった。これで、アプリコード、インフラスクリプト、ライフサイクルフックを含むデプロイパイプライン全体を1つの言語で管理できる。既存の.NETユーティリティをフックで再利用し、共有ライブラリを参照し、シェルスクリプトの保守から解放される。

まとめ

小さな変更のように見えるが、azdの日常ワークフローから多くの摩擦を取り除く変更の一つ。フックのマルチ言語サポートは今すぐ利用可能 — 公式ポストで全ドキュメントを確認してほしい。

Windows App Dev CLI v0.3: ターミナルからF5デバッグとエージェント向けUIオートメーション

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

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

Visual StudioのF5体験は素晴らしいです。しかし、パッケージ化されたWindowsアプリを起動してデバッグするためだけにVSを開くのは、CIパイプライン、自動化ワークフロー、またはAIエージェントがテストを実行しているときには過剰です。

Windows App Development CLI v0.3がリリースされ、2つの主要機能でこれに直接対応します：winapp runとwinapp uiです。

winapp run: どこからでもF5

winapp runはアンパッケージのアプリフォルダーとマニフェストを受け取り、VSがデバッグ起動時に行うすべてを実行します：ルーズパッケージを登録し、アプリを起動し、再デプロイ間でLocalStateを保持します。

# アプリをビルドし、パッケージアプリとして実行
winapp run ./bin/Debug

WinUI、WPF、WinForms、コンソール、Avaloniaなどで動作します。各モードは開発者と自動化ワークフローの両方を想定しています：

--detach: 起動後すぐにターミナルに制御を返します。CI/自動化に最適です。
--unregister-on-exit: アプリ終了時に登録済みパッケージを削除します。
--debug-output: OutputDebugStringメッセージと例外をリアルタイムでキャプチャします。

新しいNuGetパッケージ: パッケージアプリ向けdotnet run

.NET開発者向けに新しいNuGetパッケージが登場しました：Microsoft.Windows.SDK.BuildTools.WinApp。インストール後は、dotnet runがインナーループ全体を処理します：ビルド、ルーズレイアウトパッケージの準備、Windowsへの登録、起動 — すべて1ステップで。

winapp init
# または
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: コマンドラインからUIオートメーション

エージェント型シナリオを切り開くのがこの機能です。winapp uiはターミナルから、実行中のあらゆるWindowsアプリ（WPF、WinForms、Win32、Electron、WinUI3）への完全なUIオートメーションアクセスを提供します。

できること：

すべてのトップレベルウィンドウを一覧表示
ウィンドウの完全なUIオートメーションツリーをナビゲート
名前、タイプ、オートメーションIDで要素を検索
クリック、呼び出し、値の設定
スクリーンショットの取得
要素の表示を待機 — テスト同期に最適

winapp uiとwinapp runを組み合わせると、ターミナルから完全なビルド→起動→検証ワークフローが実現します。エージェントがアプリを実行し、UIの状態を検査し、プログラムで操作して結果を検証できます。

その他の新機能

winapp unregister: テスト終了後にサイドロードされたパッケージを削除します。
winapp manifest add-alias: ターミナルからアプリ名で起動できるエイリアスを追加します。
タブ補完: 1つのコマンドでPowerShell補完を設定します。

インストール方法

winget install Microsoft.WinAppCli
# または
npm install -g @microsoft/winappcli

CLIはパブリックプレビュー中です。完全なドキュメントはGitHubリポジトリを、すべての詳細は元のアナウンスをご覧ください。

今すぐパッチを: .NET 10.0.7 OOBセキュリティアップデート (ASP.NET Core Data Protection)

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

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

このアップデートはオプションではありません。アプリケーションがMicrosoft.AspNetCore.DataProtectionを使用している場合、10.0.7に更新する必要があります。

何が起きたか

Patch Tuesday .NET 10.0.6リリース後、一部のユーザーが復号化の失敗を報告しました。調査中にCVE-2026-40372が発見されました：HMAC検証タグが誤ったバイトで計算されており、権限昇格につながる可能性がありました。

修正方法

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

その後、アプリケーションを再ビルドして再デプロイしてください。

Rahul Bhandariによるオリジナルアナウンス: .NET 10.0.7 Out-of-Band Security Update。

.NET Native AOT を使って C# で Node.js ネイティブアドオンを書く

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

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

こんなシナリオが好きです。.NET ツールを開発するチームが、C++ で書かれネイティブ Node.js アドオンを node-gyp でコンパイルして使っていました。動いてはいました。でも、誰もが直接触らないパッケージをビルドするためだけに、チーム全員の開発マシンに Python（しかも古いバージョン）をインストールする必要がありました。

そこで、チームはとても合理的な疑問を持ちました。「.NET SDK はもうインストールされているのに、なぜ C++ を書いているのか？」

答えは Native AOT でした。結果は本当にエレガントです。

基本的なアイデア

Node.js ネイティブアドオンは、Node.js が実行時にロードできる共有ライブラリ（Windows では .dll、Linux では .so、macOS では .dylib）です。インターフェースは N-API — 安定した ABI 互換の C API です。N-API はどの言語がライブラリを作ったかを気にせず、正しいシンボルをエクスポートするかどうかだけを確認します。

.NET Native AOT はまさにそれを作れます。C# コードを事前にネイティブ共有ライブラリにコンパイルし、任意のエントリーポイントを持たせることができます。これがトリックのすべてです。

プロジェクトのセットアップ

プロジェクトファイルはシンプルです：

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <TargetFramework>net10.0</TargetFramework>
 <PublishAot>true</PublishAot>
 <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
 </PropertyGroup>
</Project>

PublishAot は dotnet publish 時に共有ライブラリを生成するよう SDK に指示します。AllowUnsafeBlocks は N-API の interop で関数ポインタと固定バッファを使うために必要です。

エントリーポイントのエクスポート

Node.js はライブラリが napi_register_module_v1 をエクスポートすることを期待します。C# では [UnmanagedCallersOnly] がまさにそれを行います：

public static unsafe partial class RegistryAddon
{
 [UnmanagedCallersOnly(
 EntryPoint = "napi_register_module_v1",
 CallConvs = [typeof(CallConvCdecl)])]
 public static nint Init(nint env, nint exports)
 {
 Initialize();
 RegisterFunction(env, exports, "readStringValue"u8, &ReadStringValue);
 return exports;
 }
}

注目点：nint はネイティブサイズの整数 — intptr_t のマネージド等価物です。u8 サフィックスは UTF-8 文字列リテラルを含む ReadOnlySpan<byte> を生成し、エンコーディングアロケーションなしで直接 N-API に渡します。[UnmanagedCallersOnly] は Node.js が探す正確なエントリーポイント名でメソッドをエクスポートします。

N-API をホストプロセスに対して解決する

N-API 関数は別のライブラリではなく node.exe 自身がエクスポートします。そのため、何かにリンクする代わりに、起動時に実行中のプロセスに対して解決します：

private static void Initialize()
{
 NativeLibrary.SetDllImportResolver(
 System.Reflection.Assembly.GetExecutingAssembly(),
 ResolveDllImport);

 static nint ResolveDllImport(
 string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
 {
 if (libraryName is not "node") return 0;
 return NativeLibrary.GetMainProgramHandle();
 }
}

これにより、P/Invoke 宣言が [LibraryImport] とソース生成マーシャリングで正しく動作します。

実際のエクスポート関数

チームが作ったレジストリリーダーの完全な関数：

[UnmanagedCallersOnly(CallConvs = [typeof(CallConvCdecl)])]
private static nint ReadStringValue(nint env, nint info)
{
 try
 {
 var keyPath = GetStringArg(env, info, 0);
 var valueName = GetStringArg(env, info, 1);

 if (keyPath is null || valueName is null)
 {
 ThrowError(env, "Expected two string arguments: keyPath, valueName");
 return 0;
 }

 using var key = Registry.CurrentUser.OpenSubKey(keyPath, writable: false);

 return key?.GetValue(valueName) is string value
 ? CreateString(env, value)
 : GetUndefined(env);
 }
 catch (Exception ex)
 {
 ThrowError(env, $"Registry read failed: {ex.Message}");
 return 0;
 }
}

try/catch に関する重要な注意：[UnmanagedCallersOnly] メソッドで未処理の例外が発生するとホストプロセスがクラッシュします。常に例外をキャッチし、ThrowError で JavaScript に転送してください。

TypeScript から呼び出す

const registry = require('./native/win32-x64/RegistryAddon.node') as RegistryAddon;
const sdkPath = registry.readStringValue(
 'SOFTWARE\\dotnet\\Setup\\InstalledVersions\\x64\\sdk', 'InstallLocation');

TypeScript → C#、Python なし、C++ なし。

何を得たか

即時のメリットはコントリビューター体験の向上です。特定の Python バージョンが不要になり、yarn install は Node.js と .NET SDK だけで動作します。CI パイプラインも簡素化されました。パフォーマンスは C++ 実装と同等でした。

まとめ

C# Dev Kit チームは Python/C++ の複雑さを、チーム全員がすでに書けてデバッグできる Clean な C# コードに置き換えました。文字列マーシャリングヘルパーを含む完全なウォークスルーは、.NET ブログのオリジナル記事をご覧ください。

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統合です。

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

VS Code 1.117：エージェントが専用のGitブランチを持つようになった、これは最高だ

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

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

「AIアシスタント」と「AIチームメイト」の境界線はどんどん薄くなっている。VS Code 1.117がリリースされ、完全なリリースノートは盛りだくさんだが、ストーリーは明確だ：エージェントが開発ワークフローのファーストクラスの市民になりつつある。

本当に重要なことはこれだ。

Autopilotモードがついに設定を記憶するように

以前は、新しいセッションを開始するたびにAutopilotを再度有効にする必要があった。面倒だった。今では権限モードがセッション間で保持され、デフォルトも設定できる。

Agent Hostは3つのセッション設定をサポートしている：

Default — ツールは実行前に確認を求める
Bypass — すべてを自動承認する
Autopilot — 完全自律型、自分の質問に答えて作業を続ける

.NETプロジェクトをマイグレーション、Docker、CIと一緒にスキャフォールディングするなら、Autopilotに一度設定すればあとは忘れていい。その設定はそのまま維持される。

エージェントセッションのworktreeとgit分離

これが本命だ。エージェントセッションが完全なworktreeとgit分離をサポートするようになった。つまり、エージェントがタスクに取り組むとき、専用のブランチと作業ディレクトリが割り当てられる。メインブランチは一切影響を受けない。

さらに良いことに、Copilot CLIがこれらのworktreeセッションに意味のあるブランチ名を生成してくれる。もうagent-session-abc123は終わりだ。エージェントが何をしているかを実際に説明する名前が付けられる。

複数のフィーチャーブランチを管理したり、長いスキャフォールディングタスクの実行中にバグを修正している.NET開発者にとって、これはゲームチェンジャーだ。あるworktreeでエージェントにAPIコントローラーを構築させながら、別のworktreeでサービスレイヤーの問題をデバッグできる。コンフリクトなし。スタッシュなし。混乱なし。

サブエージェントとエージェントチーム

Agent Host Protocolがサブエージェントをサポートするようになった。エージェントがタスクの一部を処理するために他のエージェントを起動できる。委任と考えればいい — メインエージェントが調整し、専門エージェントが各部分を担当する。

まだ初期段階だが、.NETワークフローへの可能性は明らかだ。あるエージェントがEF Coreのマイグレーションを処理し、別のエージェントが統合テストをセットアップする姿を想像してみてほしい。まだ完全には到達していないが、プロトコルサポートが今入ったということは、ツールもすぐに続くということだ。

エージェントが入力を送信するとターミナル出力が自動的に含まれるように

小さいが意味がある。エージェントがターミナルに入力を送信すると、ターミナル出力が自動的にコンテキストに含まれるようになった。以前は、エージェントが何が起きたかを読むために余分なターンが必要だった。

エージェントがdotnet buildを実行し、失敗し、エラーを確認するためだけにもう一回往復するのを見たことがあるなら — そのフリクションはなくなった。出力を即座に確認して反応する。

macOSのAgentsアプリが自動更新に

macOSのスタンドアロンAgentsアプリが自動更新されるようになった。新しいバージョンを手動でダウンロードする必要はもうない。常に最新の状態が保たれる。

知っておく価値のある小さなこと

package.jsonのホバーがインストール済みバージョンと最新の利用可能なバージョンの両方を表示するようになった。.NETプロジェクトと一緒にnpmツールを管理している場合に便利。
JSDocコメント内の画像がホバーや補完で正しくレンダリングされるようになった。
Copilot CLIセッションがVS Codeで作成されたか外部で作成されたかを表示するようになった — ターミナル間を行き来するときに便利。
Copilot CLI、Claude Code、Gemini CLIがシェルタイプとして認識されるようになった。エディタが何を実行しているか把握している。

まとめ

VS Code 1.117は派手な機能のダンプではない。インフラだ。worktree分離、永続的な権限、サブエージェントプロトコル — これらは、エージェントがコードを踏むことなく実際の並列タスクを処理するワークフローのための基盤だ。

.NETで開発していてエージェント型ワークフローにまだ踏み込んでいないなら、正直、今が始めるときだ。

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 は サラゴサ、テネリフェ、セビリア でも開催されます。

Docker Sandboxで、Copilotエージェントがマシンをリスクにさらさずにコードをリファクタリングできるようになった

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

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

Copilotのエージェントモードを小さな編集以上のことに使ったことがあるなら、あの煩わしさは知っているはずです。ファイルへの書き込みのたびに、ターミナルコマンドのたびに、また許可プロンプト。これを50プロジェクトで想像してみてください。楽しくないですよね。

AzureチームがGitHub CopilotエージェントのためのDocker Sandboxに関する記事を公開しました。正直に言って、これはエージェンティックツーリングで見た中で最も実用的な改善の一つです。マイクロVMを使ってCopilotに完全に隔離された環境を提供し、パッケージのインストール、ビルドの実行、テストの実行まで、ホストシステムに一切触れずに自由に作業できます。

Docker Sandboxが実際に提供するもの

コアのアイデアはシンプルです：完全なLinux環境を持つ軽量なマイクロVMを起動し、ワークスペースをその中に同期させ、Copilotエージェントを内部で自由に動かす。完了したら変更が同期されて戻ってくる。

単なる「コンテナ内で実行する」以上のものにしているポイントはこちらです：

双方向ワークスペース同期で絶対パスが保持されます。プロジェクト構造はサンドボックス内でも同一に見えます。パス関連のビルドエラーはありません。
プライベートDockerデーモンがマイクロVM内で稼働。エージェントはホストのDockerソケットをマウントすることなくコンテナのビルドと実行が可能です。セキュリティ面で大きな進歩です。
HTTP/HTTPSフィルタリングプロキシがエージェントのネットワークアクセスを制御。どのレジストリとエンドポイントを許可するかはあなたが決められます。サンドボックス内の悪意あるnpm installによるサプライチェーン攻撃？ブロックされます。
YOLOモード — はい、本当にそう呼ばれています。エージェントは許可プロンプトなしで実行されます。なぜなら、文字通りホストを壊すことができないからです。すべての破壊的アクションが封じ込められています。

.NET開発者が注目すべき理由

今まさに多くのチームが直面しているモダナイゼーション作業を考えてみてください。30プロジェクトを含む.NET Frameworkソリューションがあり、.NET 9に移行する必要がある。数百のファイル変更が必要です — プロジェクトファイル、名前空間の更新、APIの置き換え、NuGetの移行。

Docker Sandboxを使えば、CopilotエージェントをプロジェクトにポイントしてマイクロVM内で自由にリファクタリングさせ、dotnet buildとdotnet testで検証し、実際に動作する変更だけを受け入れることができます。実験中にローカル開発環境を誤って壊してしまうリスクはありません。

記事では並列エージェントのフリートの運用も説明されています — それぞれが独自のサンドボックスで、異なるプロジェクトに同時に取り組みます。大規模な.NETソリューションやマイクロサービスアーキテクチャにとって、これは膨大な時間の節約になります。サービスごとに1エージェント、すべて隔離して実行、すべて独立して検証。

セキュリティの観点が重要

多くの人が見落としているポイントがあります：AIエージェントに任意のコマンドの実行を許可するということは、マシン全体を信頼して預けるということです。Docker Sandboxはそのモデルを逆転させます。エージェントは使い捨て環境内で完全な自律性を得ます。ネットワークプロキシが承認されたソースからのみダウンロードできることを保証します。ホストのファイルシステム、Dockerデーモン、認証情報は手つかずのままです。

コンプライアンス要件を持つチーム — そしてそれはほとんどのエンタープライズ.NET企業に当てはまります — にとって、これは「エージェンティックAIは使えない」と「安全に導入できる」の違いです。

まとめ

Docker Sandboxはエージェンティックコーディングの根本的なジレンマを解決します：エージェントは有用であるために自由が必要ですが、ホストマシンでの自由は危険です。マイクロVMは両方を実現します。大規模な.NETリファクタリングやモダナイゼーションを計画しているなら、今すぐセットアップする価値があります。Copilotのコードインテリジェンスとセキュアな実行環境の組み合わせは、まさにプロダクションチームが待ち望んでいたものです。

ターミナルの見張り番はもう終わり：Aspireのデタッチモードがワークフローを変える

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

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

AspireのAppHostを実行するたびに、ターミナルが奪われます。ロックされて、Ctrl+Cを押すまで占有されたまま。ちょっとしたコマンドを実行したい？別のタブを開く。ログを確認したい？もう一つタブを開く。小さなストレスですが、積み重なると大きくなります。

Aspire 13.2がこれを解決します。James Newton-Kingが詳細を書いていますが、正直なところ、これは使い始めた瞬間にワークフローが変わる機能の一つです。

デタッチモード：コマンド一つでターミナルが戻る

aspire start

これはaspire run --detachのショートカットです。AppHostがバックグラウンドで起動し、ターミナルがすぐに戻ってきます。余計なタブは不要。ターミナルマルチプレクサも不要。プロンプトがそのまま使える状態です。

実行中のプロセスを管理する

ポイントはこうです — バックグラウンド実行は、実行中のものを管理できて初めて意味があります。Aspire 13.2はまさにそのためのCLIコマンド一式を提供します：

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

これによりAspire CLIが本格的なプロセスマネージャーになります。複数のAppHostを起動し、ステータスを確認し、ログを追跡し、シャットダウンできます — すべて一つのターミナルセッションから。

分離モードと組み合わせる

デタッチモードは分離モードと自然に組み合わせられます。同じプロジェクトの2つのインスタンスをポート競合なしにバックグラウンドで実行したい場合は？

aspire start --isolated
aspire start --isolated

それぞれがランダムなポート、個別のシークレット、独自のライフサイクルを持ちます。aspire psで両方を確認し、aspire stopで不要な方を停止できます。

コーディングエージェントにとってなぜこれが重要か

ここからが本当に面白いところです。ターミナルで作業するコーディングエージェントが以下のことをできるようになります：

aspire startでアプリを起動
aspire describeで状態を確認
aspire logsでログをチェックして問題を診断
完了したらaspire stopで停止

すべてターミナルセッションを失うことなく実行できます。デタッチモード以前は、AppHostを実行したエージェントは自分自身のターミナルをロックしてしまいました。今では起動、観察、反復、クリーンアップが可能です — 自律エージェントに期待する動作そのものです。

Aspireチームはこれに本気で取り組みました。aspire agent initを実行すると、エージェントにこれらのコマンドを教えるAspireスキルファイルが設定されます。これにより、CopilotのコーディングエージェントなどのツールがすぐにAspireワークロードを管理できます。

まとめ

デタッチモードはシンプルなフラグに見せかけたワークフローのアップグレードです。ターミナル間のコンテキスト切り替えがなくなり、エージェントが自分自身をブロックしなくなり、新しいCLIコマンドで実行中のものをリアルに把握できます。実用的で、クリーンで、日々の開発サイクルが明らかにスムーズになります。

完全な記事で詳細を確認し、aspire update --selfでAspire 13.2を入手してください。

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ポータルへのコンテキストスイッチの理由がまた一つ減りました。正直なところ、タブの切り替えは少なければ少ないほど良いですからね。

ピンクラスタリングがついに .NET MAUI Maps に登場 — プロパティ1つ、手間ゼロ

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

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

マップに100個のピンを読み込んだら、全体が読めない塊になった — そんな経験ありませんか？そう、これまでの .NET MAUI Maps はまさにそんな感じでした。もう終わりです。

David Ortinau が発表しました。.NET MAUI 11 Preview 3 では、Android と iOS/Mac Catalyst でピンクラスタリングがすぐに使える状態で搭載されています。そして最高なのは — 有効にするのが驚くほど簡単だということです。

すべてを支配する1つのプロパティ

<maps:Map IsClusteringEnabled="True" />

これだけです。近くのピンがカウントバッジ付きのクラスターにグループ化されます。ズームインすると展開。ズームアウトすると折りたたみ。モダンなマップならどれでも期待される動作 — それがたった1つのプロパティで手に入ります。

独立したクラスタリンググループ

ここからが面白いところです。すべてのピンが一緒にクラスタリングされるべきではありません。コーヒーショップと公園は別物で、マップもそれを知っているべきです。

ClusteringIdentifier プロパティを使えば、ピンを独立したグループに分けられます：

map.Pins.Add(new Pin
{
 Label = "Pike Place Coffee",
 Location = new Location(47.6097, -122.3331),
 ClusteringIdentifier = "coffee"
});

map.Pins.Add(new Pin
{
 Label = "Occidental Square",
 Location = new Location(47.6064, -122.3325),
 ClusteringIdentifier = "parks"
});

同じ識別子を持つピンは一緒にクラスタリングされます。異なる識別子は、地理的に近くても独立したクラスターを形成します。識別子なし？デフォルトグループです。シンプルで予測可能。

クラスタータップの処理

ユーザーがクラスターをタップすると、必要なものがすべて揃った ClusterClicked イベントを受け取ります：

map.ClusterClicked += async (sender, e) =>
{
 string names = string.Join("\n", e.Pins.Select(p => p.Label));
 await DisplayAlert(
 $"Cluster ({e.Pins.Count} pins)",
 names,
 "OK");

 // Suppress default zoom-to-cluster behavior:
 // e.Handled = true;
};

イベント引数には Pins（クラスター内のピン）、Location（地理的中心）、Handled（デフォルトのズーム動作をオーバーライドしたい場合は true に設定）が含まれます。シンプルで実用的、まさに期待通り。

知っておくべきプラットフォームの詳細

Android では、クラスタリングはズーム変更時に再計算するカスタムのグリッドベースアルゴリズムを使用します — 外部依存なし。iOS と Mac Catalyst では、MapKit のネイティブ MKClusterAnnotation サポートを活用しており、スムーズでプラットフォームネイティブなアニメーションを実現しています。

これは MAUI チームが正しい判断をしたケースの1つです — プラットフォームの力を活かすべきところで活かす。

なぜこれが重要なのか

ピンクラスタリングは .NET MAUI で最もリクエストの多かった機能の1つです（issue #11811）。それも当然です。マップ上に場所を表示するすべてのアプリ — 配送追跡、店舗検索、不動産 — に必要です。以前は自分で実装するか、サードパーティライブラリを使う必要がありました。今は組み込みです。

クロスプラットフォームモバイルアプリを構築する .NET 開発者にとって、これはまさに MAUI をマップ中心のシナリオで実用的な選択肢にする生活の質の向上です。

始めよう

.NET 11 Preview 3 をインストールして .NET MAUI ワークロードを更新してください。Maps サンプルには新しいクラスタリングページが含まれており、すぐに試すことができます。

何か作ってみてください — そしてマップにやっと余裕を持たせましょう。

.NET 2026年4月サービシング — 今すぐ適用すべきセキュリティパッチ

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

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

.NETと.NET Frameworkの2026年4月サービシングアップデートがリリースされました。今回はすぐに適用したいセキュリティ修正が含まれています。6件のCVEがパッチされ、そのうち2件はリモートコード実行（RCE）の脆弱性です。

パッチされた内容

簡単なまとめはこちらです：

CVE	種類	影響範囲
CVE-2026-26171	セキュリティ機能のバイパス	.NET 10, 9, 8 + .NET Framework
CVE-2026-32178	リモートコード実行	.NET 10, 9, 8 + .NET Framework
CVE-2026-33116	リモートコード実行	.NET 10, 9, 8
CVE-2026-32203	サービス拒否	.NET 10, 9, 8 + .NET Framework
CVE-2026-23666	サービス拒否	.NET Framework 3.0–4.8.1
CVE-2026-32226	サービス拒否	.NET Framework 2.0–4.8.1

2件のRCE CVE（CVE-2026-32178とCVE-2026-33116）は最も広範囲の.NETバージョンに影響し、優先的に対応すべきです。

更新されたバージョン

.NET 10: 10.0.6
.NET 9: 9.0.15
.NET 8: 8.0.26

すべて通常のチャネルから入手できます — dotnet.microsoft.com、MCR上のコンテナイメージ、Linuxパッケージマネージャー。

対応すべきこと

プロジェクトとCI/CDパイプラインを最新のパッチバージョンに更新してください。コンテナを使用している場合は、最新のイメージをプルしてください。.NET Frameworkを使用している場合は、対応するパッチについて.NET Frameworkリリースノートを確認してください。

.NET 10を本番環境で実行している方（現行リリースです）にとって、10.0.6は必須アップデートです。LTSトラックの.NET 9.0.15や.NET 8.0.26も同様です。2件のRCE脆弱性は後回しにできるものではありません。

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 DevOps Server 2026年4月パッチ — PRの完了修正とセキュリティアップデート

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

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

セルフホストでAzure DevOps Serverを運用しているチームへの簡単なお知らせです。Microsoftが2026年4月のパッチ3をリリースしました。3つの修正が含まれています。

修正内容

Pull Requestの完了失敗 — ワークアイテムの自動完了時にnull参照例外が発生し、PRのマージが失敗することがありました。ランダムなPR完了エラーに遭遇した方は、これが原因の可能性が高いです
サインアウト時のリダイレクト検証 — 悪意のあるリダイレクトを防止するため、サインアウト時の検証が改善されました。早めに適用すべきセキュリティ修正です
GitHub Enterprise Server PATの接続 — GitHub Enterprise ServerへのPersonal Access Tokenの接続作成が壊れていましたが、復元されました

アップデート方法

パッチ3をダウンロードしてインストーラーを実行してください。パッチが適用されたことを確認するには：

<patch-installer>.exe CheckInstall

Azure DevOps Serverをオンプレミスで運用している場合、Microsoftはセキュリティと信頼性の両面から、最新のパッチを維持することを強く推奨しています。詳細はリリースノートをご確認ください。

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 が対応していることを示しています。「エンタープライズ対応」シグナルを待っていたなら — これです。

.NET Aspire 13.2はあなたのAIエージェントの親友になりたがっている

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

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

AIコーディングエージェントがしっかりしたコードを書いて興奮した後、実際にそれを実行しようとした途端に全てが崩壊する瞬間、知っていますか？ポート競合、ゴーストプロセス、間違った環境変数 — 突然エージェントが機能を構築する代わりに起動トラブルシューティングにトークンを消費し始めます。

Aspireチームがまさにこの問題について非常によく考えられた記事を公開しました。彼らの答えは説得力があります：Aspire 13.2は人間だけでなく、AIエージェントのためにも設計されています。

問題は現実のもの

AIエージェントはコードを書くのに驚異的です。しかし、動作するフルスタックアプリを出荷するには、ファイルを生成する以上のことが必要です。正しい順序でサービスを起動し、ポートを管理し、環境変数を設定し、データベースを接続し、何かが壊れた時にフィードバックを得る必要があります。現在、ほとんどのエージェントはこれらすべてを試行錯誤で処理しています — コマンドを実行し、エラー出力を読み、再試行します。

Markdownの指示、カスタムスキル、プロンプトを重ねてガイドしようとしますが、それらは予測不可能で、コンパイルできず、パースするだけでトークンがかかります。Aspireチームは本質的な洞察を突きました：エージェントにはコンパイラと構造化されたAPIが必要であり、もっとMarkdownではありません。

エージェントインフラとしてのAspire

Aspire 13.2がエージェンティック開発にもたらすもの：

スタック全体を型付きコードで。 AppHostがアプリの完全なトポロジー — API、フロントエンド、データベース、キャッシュ — をコンパイル可能なTypeScriptまたはC#で定義します：

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

エージェントはこれを読んでアプリのトポロジーを理解し、リソースを追加し、接続を配線し、検証のためにビルドできます。コンパイラが何か間違っていればすぐに教えてくれます。推測不要、設定ファイルでの試行錯誤不要です。

すべてを支配する一つのコマンド。 エージェントがdocker compose up、npm run dev、データベース起動スクリプトをジャグリングする代わりに、すべてがaspire startだけ。すべてのリソースが正しい順序で、正しいポートで、正しい設定で起動します。長時間実行プロセスもエージェントをハングさせません — Aspireが管理します。

並列エージェント用の分離モード。 --isolatedを使えば、各Aspire実行が独自のランダムポートと分離されたユーザーシークレットを取得します。複数のエージェントがgit worktreeで作業している？衝突しません。これはVS Codeのバックグラウンドエージェントのような並列環境を立ち上げるツールにとって非常に重要です。

テレメトリによるエージェントの目。 ここが本当に強力になるところです。Aspire CLIは開発中に完全なOpenTelemetryデータを公開します — トレース、メトリクス、構造化ログ。エージェントはコンソール出力を読んで最善を祈るだけではありません。サービス間で失敗したリクエストをトレースし、遅いエンドポイントをプロファイリングし、問題の正確な箇所を特定できます。開発ループにプロダクショングレードの可観測性があるのです。

ボウリングのバンパーの例え

Aspireチームは素晴らしい例えを使っています：AspireをAIエージェントのためのボウリングレーンのバンパーだと思ってください。エージェントが完璧でない場合（そして完璧にはなりません）、バンパーがガーターに落ちるのを防ぎます。スタック定義が誤設定を防ぎ、コンパイラがエラーをキャッチし、CLIがプロセス管理を行い、テレメトリがフィードバックループを提供します。

これをPlaywright CLIのようなものと組み合わせれば、エージェントは実際にアプリを使うことができます — フローをクリックし、DOMをチェックし、テレメトリで壊れた箇所を見つけ、コードを修正し、再起動してテストし直す。ビルド、実行、観察、修正。これが私たちが追い求めてきた自律的な開発ループです。

始め方

Aspire初心者？get.aspire.devからCLIをインストールし、入門ガイドに従ってください。

すでにAspireを使っている？aspire update --selfで13.2を取得し、お気に入りのコーディングエージェントをリポジトリに向けてください。Aspireのガードレールがあることで、エージェントがどれだけ先まで進めるか驚くかもしれません。

まとめ

Aspire 13.2はもはや単なる分散アプリフレームワークではありません — 不可欠なエージェントインフラになりつつあります。構造化されたスタック定義、ワンコマンド起動、分離された並列実行、リアルタイムテレメトリが、AIエージェントにコードを書くことからアプリを出荷することへ移行するために必要なものを提供します。

Aspireチームの完全な記事ですべての詳細とデモ動画をご覧ください。

Aspireの分離モードが並列開発のポート競合の悪夢を解決する

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

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

同じプロジェクトの2つのインスタンスを同時に実行しようとしたことがあるなら、あの苦痛を知っているでしょう。ポート8080は既に使用中。ポート17370は取られている。何かをkillして、再起動して、環境変数をジャグリングする — 生産性のキラーです。

この問題は改善ではなく悪化しています。AIエージェントは独立して作業するためにgit worktreeを作成します。バックグラウンドエージェントは別々の環境を立ち上げます。開発者はフィーチャーブランチのために同じリポジトリを2回チェックアウトします。これらのシナリオはすべて同じ壁にぶつかります：同じアプリの2つのインスタンスが同じポートを奪い合うのです。

Aspire 13.2はたった一つのフラグでこれを解決します。AspireチームのJames Newton-Kingが詳細を書いています。「なぜこれがもっと早くなかったの？」という機能の一つです。

解決策：`--isolated`

aspire run --isolated

これだけです。各実行は以下を取得します：

ランダムポート — インスタンス間のコリジョンなし
分離されたユーザーシークレット — 接続文字列とAPIキーがインスタンスごとに分離

手動のポート再割り当ては不要。環境変数のジャグリングも不要。各実行は自動的にクリーンでコリジョンフリーの環境を取得します。

これが輝く実際のシナリオ

複数チェックアウト。 あるディレクトリにフィーチャーブランチ、別のディレクトリにバグフィックスがある場合：

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

両方とも競合なしで実行されます。ダッシュボードで何がどこで実行されているか確認できます。

VS Codeのバックグラウンドエージェント。 Copilot Chatのバックグラウンドエージェントがコードに独立して作業するためにgit worktreeを作成する場合、Aspire AppHostを実行する必要があるかもしれません。--isolatedなしでは、プライマリworktreeとのポート競合が発生します。これがあれば、両方のインスタンスが問題なく動作します。

aspire agent initに付属するAspireスキルは、worktreeで作業する際に--isolatedを使うようエージェントに自動的に指示します。そのため、Copilotのバックグラウンドエージェントはこれをネイティブに処理するはずです。

開発と並行した統合テスト。 機能の構築を続けながらライブのAppHostに対してテストを実行する必要がありますか？分離モードは各コンテキストに独自のポートと設定を提供します。

内部の仕組み

--isolatedを渡すと、CLIはその実行のためにユニークなインスタンスIDを生成します。これにより2つの動作が駆動されます：

ポートのランダム化 — AppHost設定で定義された予測可能なポートにバインドする代わりに、分離モードはすべてに対して利用可能なランダムポートを選択します — ダッシュボード、サービスエンドポイント、すべて。サービスディスカバリが自動的に調整されるため、どのポートに割り当てられても、サービスは互いを見つけることができます。
シークレットの分離 — 各分離実行はインスタンスIDでキー付けされた独自のユーザーシークレットストアを取得します。ある実行の接続文字列やAPIキーが別の実行に漏れることはありません。

コードの変更は不要です。Aspireのサービスディスカバリがランタイムでエンドポイントを解決するため、ポートの割り当てに関係なくすべてが正しく接続されます。

いつ使うべきか

同じAppHostの複数インスタンスを同時に実行する場合に--isolatedを使用してください — 並列開発、自動テスト、AIエージェント、git worktreeのいずれの場合でも。予測可能なポートを好む単一インスタンス開発では、通常のaspire runで問題ありません。

まとめ

分離モードは、現実の、ますます一般的になる問題を解決する小さな機能です。AI支援開発がより多くの並列ワークフロー — 複数のエージェント、複数のworktree、複数のコンテキスト — に向かって推し進める中、ポートを奪い合うことなく別のインスタンスを立ち上げる能力は不可欠です。

完全な記事ですべての技術的詳細を確認し、aspire update --selfで13.2を試してみてください。

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拡張機能を入手して自分のコードベースで試してみてください。

MCP AppsにFluent APIが登場 — .NETでリッチなAIツールUIを3ステップで構築

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

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

MCPツールはAIエージェントに機能を与えるのに最適です。でも、ツールがユーザーに何かを表示する必要がある場合はどうでしょう？ダッシュボード、フォーム、インタラクティブなビジュアライゼーション。そこで登場するのがMCP Appsで、構築がずっと簡単になりました。

Azure SDKチームのLilian Kasemが、.NET Azure Functions上のMCP Apps向け新しいFluent設定APIを発表しました。なぜ最初からこんなにシンプルじゃなかったのかと思うような、開発者体験の改善です。

MCP Appsとは？

MCP AppsはModel Context Protocolを拡張し、ツールが独自のUIビュー、静的アセット、セキュリティコントロールを持てるようにします。テキストを返すだけでなく、MCPツールは完全なHTMLエクスペリエンスをレンダリングできます — インタラクティブなダッシュボード、データビジュアライゼーション、設定フォーム — すべてAIエージェントから呼び出し可能で、MCPクライアントを通じてユーザーに表示されます。

問題は、これらを手動で配線するにはMCP仕様を深く理解する必要があったことです：ui:// URI、特殊なMIMEタイプ、ツールとリソース間のメタデータ調整。難しくはないけど、面倒でした。

Fluent APIの3ステップ

ステップ1：関数を定義する。 標準的なAzure Functions MCPツール：

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

ステップ2：MCP Appに昇格させる。 プログラムのスタートアップで：

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

ステップ3：HTMLビューを追加する。 必要なUIでassets/hello-app.htmlを作成します。

以上です。Fluent APIがMCPプロトコルの配管をすべて処理します — 合成リソース関数の生成、正しいMIMEタイプの設定、ツールとビューを接続するメタデータの注入。

APIの設計が秀逸

特に気に入っている点がいくつかあります：

ビューソースが柔軟。 ディスク上のファイルからHTMLを提供したり、自己完結型デプロイのためにリソースをアセンブリに直接埋め込んだりできます：

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSPがコンポーザブル。 最小権限の原則に従い、アプリが必要とするオリジンを明示的に許可します。WithCspを複数回呼び出すとオリジンが蓄積されます：

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

可視性制御。 ツールをLLMのみ、ホストUIのみ、または両方に表示できます。UIのみをレンダリングし、モデルから呼び出されるべきでないツールが欲しい場合は簡単：

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

始め方

プレビューパッケージを追加：

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

すでにAzure FunctionsでMCPツールを構築している場合、これはパッケージの更新だけです。コンセプトが初めての方はMCP Appsクイックスタートが最適な出発点です。

まとめ

MCP AppsはAIツーリング分野で最もエキサイティングな開発の一つです — 物事を行うだけでなく、ユーザーに物事を見せることができるツール。Fluent APIはプロトコルの複雑さを取り除き、重要なことに集中させてくれます：ツールのロジックとそのUI。

完全なAPIリファレンスと例については完全な記事をお読みください。

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の規範的アプローチです。始めるには完全な記事とドキュメントをご覧ください。

VS Code 1.116 — Agentsアプリがキーボードナビゲーションとファイルコンテキスト補完を獲得

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

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

VS Code 1.116は2026年4月のリリースで、最近のいくつかのアップデートよりは軽めですが、変更点は的を絞った意味のあるものです — 特にAgentsアプリを日常的に使っている方にとっては。

公式リリースノートに基づいて、何が追加されたか見ていきましょう。

Agentsアプリの改善

Agentsアプリは、日常のワークフローに本当の違いをもたらすユーザビリティの磨き上げで成熟を続けています：

専用キーバインド — Changesビュー、Changes内のファイルツリー、Chat カスタマイズビューに専用のコマンドとキーボードショートカットでフォーカスできるようになりました。Agentsアプリ内をクリックして回っていた方には、これで完全にキーボード駆動のワークフローが実現します。

アクセシビリティヘルプダイアログ — チャット入力ボックスでAlt+F1を押すと、利用可能なコマンドとキーバインドを表示するアクセシビリティヘルプダイアログが開くようになりました。スクリーンリーダーユーザーはアナウンスの詳細度も制御できます。良いアクセシビリティはすべての人に利益をもたらします。

ファイルコンテキスト補完 — Agentsアプリのチャットで#を入力すると、現在のワークスペースにスコープされたファイルコンテキスト補完がトリガーされます。これはすべてのインタラクションを加速するあの小さなクオリティ・オブ・ライフの改善の一つです — コードを参照する際にフルファイルパスを入力する必要はもうありません。

CSS `@import`リンク解決

フロントエンド開発者にうれしいニュース：VS Codeがnode_modulesパスを使用するCSS @import参照を解決するようになりました。バンドラーを使用している場合、@import "some-module/style.css"のようなインポートをCtrl+クリックで辿れます。小さいですがCSSワークフローの摩擦点を解消します。

まとめ

VS Code 1.116は洗練がテーマです — Agentsアプリをより操作しやすく、よりアクセシブルに、よりキーボードフレンドリーにすること。Agentsアプリでかなりの時間を過ごしているなら（そして多くの方がそうだと思いますが）、これらの変更は積み重なっていきます。

完全なリストはフルリリースノートをご確認ください。

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — 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プロトコルリポジトリをチェックして、さらに深く掘り下げてください。

知らなかったVisual Studioのフローティングウィンドウ設定（でも知るべき）

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

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

Visual Studioで複数モニターを使っている方（正直に言って、今どきそうじゃない人っていますか？）は、おそらくこの煩わしさを経験したことがあるでしょう：フローティングツールウィンドウがメインIDEを最小化すると消えてしまう、常に他のすべての上に表示される、そしてタスクバーに別々のボタンとして表示されない。一部のワークフローには機能しますが、マルチモニター環境では苛立たしいものです。

Visual Studioチームの Mads Kristensen が、フローティングウィンドウの動作を完全に変えるあまり知られていない設定を共有しました。ドロップダウン一つ。それだけです。

設定

Tools > Options > Environment > Windows > Floating Windows

ドロップダウン「These floating windows are owned by the main window」には3つのオプションがあります：

None — 完全な独立性。すべてのフローティングウィンドウが独自のタスクバーエントリを持ち、通常のWindowsウィンドウとして動作します。
Tool Windows（デフォルト）— ドキュメントは自由にフロート、ツールウィンドウはIDEに紐づけられます。
Documents and Tool Windows — クラシックなVisual Studioの動作、すべてがメインウィンドウに紐づけられます。

マルチモニター環境で「None」が最適な理由

Noneに設定すると、すべてのフローティングツールウィンドウとドキュメントが本物のWindowsアプリケーションのように動作します。タスクバーに表示され、Visual Studioのメインウィンドウを最小化しても表示され続け、すべての前面に無理やり表示されることがなくなります。

これをPowerToys FancyZonesと組み合わせると、まさにゲームチェンジャーです。モニター全体にカスタムレイアウトを作成し、ソリューションエクスプローラーを一つのゾーンに、デバッガーを別のゾーンに、コードファイルを好きな場所に配置できます。すべてがその場に留まり、すべてが独立してアクセスでき、ワークスペースが混沌ではなく整理されたものに感じられます。

クイック推奨事項

マルチモニターのパワーユーザー：Noneに設定し、FancyZonesと組み合わせる
たまにフロートする方：Tool Windows（デフォルト）が良いバランス
従来のワークフロー：Documents and Tool Windowsでクラシックな動作を維持

プロのコツ：ツールウィンドウのタイトルバーをCtrl + ダブルクリックで即座にフロートまたはドッキングできます。設定変更後の再起動は不要です。

まとめ

これは典型的な「なんで今まで知らなかったんだ」系の設定です。Visual Studioのフローティングウィンドウに少しでも苛立ちを感じたことがあるなら、今すぐ変更しに行きましょう。

詳細とスクリーンショットは完全な記事をご覧ください。

VS Code 1.115 — バックグラウンドターミナル通知、SSHエージェントモードなど

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115がリリースされました。目玉機能という点では軽めのリリースですが、AIコーディングアシスタントを日常的に使っている方にとって、エージェント関連の改善は本当に役立つものです。

実際に知っておく価値のあるポイントを紹介します。

バックグラウンドターミナルがエージェントに通知するように

これが今回の目玉機能です。バックグラウンドターミナルが、コマンド完了時に終了コードとターミナル出力を含めて、エージェントに自動通知するようになりました。バックグラウンドターミナルでの入力プロンプトも検出されてユーザーに表示されます。

なぜこれが重要なのか？Copilotのエージェントモードでビルドコマンドやテストスイートをバックグラウンドで実行したことがあるなら、「あれ、もう終わった？」という苦痛を知っているはずです。バックグラウンドターミナルは基本的に撃ちっぱなしでした。今ではエージェントがdotnet buildやdotnet testの完了時に通知を受け取り、出力を確認して適切に対応できます。小さな変更ですが、エージェント駆動のワークフローの信頼性が大幅に向上します。

また、新しいsend_to_terminalツールにより、エージェントがユーザーの確認付きでバックグラウンドターミナルにコマンドを送信できるようになりました。これにより、run_in_terminalでタイムアウトを設定するとターミナルがバックグラウンドに移動して読み取り専用になってしまう問題が解決されました。

SSHリモートエージェントホスティング

VS Codeが SSH経由でリモートマシンに接続し、CLIを自動インストールしてエージェントホストモードで起動できるようになりました。これにより、AIエージェントセッションがリモート環境を直接ターゲットにできます。LinuxサーバーやクラウドVMでビルド・テストを行う.NET開発者にとって便利です。

エージェントセッションでの編集追跡

エージェントセッション中に行われたファイル編集が、diff、元に戻す/やり直し、状態復元とともに追跡・復元されるようになりました。エージェントがコードを変更して何か問題が起きた場合、何が変わったかを正確に確認してロールバックできます。エージェントにコードベースを変更させる際の安心感が得られます。

ブラウザタブの認識とその他の改善

その他のクオリティ・オブ・ライフの向上：

ブラウザタブの追跡 — チャットがセッション中に開いたブラウザタブを追跡・リンクできるようになり、エージェントが閲覧中のWebページを参照できます
ターミナルへのファイル貼り付け — Ctrl+V、ドラッグ&ドロップ、右クリックでターミナルにファイル（画像含む）を貼り付け可能
ミニマップでのテストカバレッジ — テストカバレッジインジケーターがミニマップに表示され、視覚的な概要を素早く確認できます
Macでのピンチズーム — 統合ブラウザがピンチズームジェスチャーをサポート
セッションでのCopilot使用権限 — ステータスバーのセッションビューに使用状況が表示されます
ファイルに移動でのファビコン — 開いているWebページがクイックピックリストにファビコンを表示

まとめ

VS Code 1.115はインクリメンタルなリリースですが、エージェントの改善 — バックグラウンドターミナル通知、SSHエージェントホスティング、編集追跡 — が合わさって、AI支援開発の体験が目に見えてスムーズになりました。.NETプロジェクトでCopilotのエージェントモードを使っているなら、日々の摩擦を減らすクオリティ・オブ・ライフの改善そのものです。

すべての詳細は完全なリリースノートをご覧ください。

C# 15にユニオン型が登場 — まさに私たちが求めていたもの

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

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

これこそ待ち望んでいたものです。C# 15がunionキーワードを導入しました — コンパイラが強制する網羅的パターンマッチングを備えた本格的な判別共用体です。F#の判別共用体やRustのenumを羨ましく思ったことがあるなら、これがなぜ重要かすぐにわかるでしょう。

Bill Wagnerが.NETブログで詳細な解説を公開しました。正直なところ、設計はクリーンで実用的、そしてとてもC#らしいです。実際に何があるのか、そしてなぜ一見した印象以上に大きな意味があるのかを見ていきましょう。

ユニオンが解決する問題

C# 15以前では、メソッドから「複数の可能な型のうちの1つ」を返すことは常に妥協の産物でした：

object — 制約なし、コンパイラの助けなし、あらゆるところで防御的キャスト
マーカーインターフェース — より良いが、誰でも実装できる。コンパイラはセットが完全だと判断できない
抽象基底クラス — 同じ問題、さらに型に共通の祖先が必要

これらのどれも本当に欲しいものを提供してくれません：コンパイラがすべてのケースを処理したことを保証する閉じた型のセット。ユニオン型がそれを実現します。

構文は美しくシンプル

public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);

public union Pet(Cat, Dog, Bird);

1行だけ。PetはCat、Dog、またはBirdを保持できます。暗黙的な変換は自動的に生成されます：

Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }

そしてここが魔法です — コンパイラが網羅的マッチングを強制します：

string name = pet switch
{
 Dog d => d.Name,
 Cat c => c.Name,
 Bird b => b.Name,
};

ディスカード_は不要です。コンパイラはこのswitchがすべての可能なケースをカバーしていることを知っています。後から4番目の型をユニオンに追加すると、それを処理しないすべてのswitch式が警告を生成します。不足しているケースがランタイムではなくビルド時にキャッチされます。

実用的になるところ

Petの例はかわいいですが、ここからがユニオンが本当のコードで輝くところです。

異なる形状を返すAPIレスポンス

public union ApiResult<T>(T, ApiError, ValidationFailure);

これですべてのコンシューマは成功、エラー、バリデーション失敗を処理することを強制されます。「エラーケースのチェックを忘れた」バグはもうありません。

単一値またはコレクション

OneOrMore<T>パターンは、ユニオンがヘルパーメソッドを持つボディを持てることを示しています：

public union OneOrMore<T>(T, IEnumerable<T>)
{
 public IEnumerable<T> AsEnumerable() => Value switch
 {
 T single => [single],
 IEnumerable<T> multiple => multiple,
 null => []
 };
}

呼び出し側は便利な方の形式を渡します：

OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };

foreach (var tag in tags.AsEnumerable())
 Console.Write($"[{tag}] ");
// [dotnet]

無関係な型の合成

これは従来の階層に対するキラー機能です。共通点のない型をユニオンにできます — stringとException、intとIEnumerable<T>。共通の祖先は不要です。

既存ライブラリ用のカスタムユニオン

ここにはスマートな設計判断があります：基本パターン（ケース型のパブリックコンストラクタとValueプロパティ）に従っている限り、[Union]属性を持つ任意のクラスやstructがユニオン型として認識されます。すでにユニオンライクな型を提供しているOneOfのようなライブラリは、内部を書き直すことなくコンパイラサポートにオプトインできます。

値型を使うパフォーマンスに敏感なシナリオでは、ライブラリはHasValueとTryGetValueメソッドによるボックス化なしのアクセスパターンを実装できます。

より大きな視点

ユニオン型はC#に来るより広い網羅性ストーリーの一部です：

ユニオン型 — 閉じた型セットに対する網羅的マッチング（プレビューで利用可能）
閉じた階層 — closed修飾子が定義アセンブリ外の派生クラスを防止（提案中）
閉じたenum — 宣言されたメンバー以外の値の作成を防止（提案中）

これら3つの機能が合わさることで、C#はあらゆるメインストリーム言語の中で最も包括的な型安全パターンマッチングシステムの1つを手に入れることになります。

今日試してみよう

ユニオン型は.NET 11 Preview 2で利用可能です：

.NET 11 Preview SDKをインストール
プロジェクトでnet11.0をターゲットに設定
<LangVersion>preview</LangVersion>を設定

1つ注意点：Preview 2では、ランタイムにまだ含まれていないため、プロジェクトでUnionAttributeとIUnionを宣言する必要があります。docsリポジトリからRuntimePolyfill.csを取得するか、以下を追加してください：

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
 AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;

 public interface IUnion
 {
 object? Value { get; }
 }
}

まとめ

ユニオン型は、それなしでどうやってきたのか不思議に思わせる機能の1つです。コンパイラが強制する網羅的マッチング、クリーンな構文、ジェネリックサポート、既存のパターンマッチングとの統合 — 私たちが求めていたすべてが、C#のやり方で実現されています。

.NET 11 Preview 2で試して、壊して、GitHubでフィードバックを共有してください。これはプレビューであり、C#チームは積極的に耳を傾けています。あなたのエッジケースとデザインフィードバックが最終リリースを形作ります。

完全な言語リファレンスについては、ユニオン型のドキュメントと機能仕様をご覧ください。

Aspire 13.2にドキュメントCLIが搭載 — AIエージェントも使えます

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

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

Aspire AppHostの奥深くでインテグレーションを接続していて、Redisインテグレーションが正確にどのパラメータを期待しているかを確認する必要がある、あの瞬間を知っていますか？ブラウザにAlt-Tabして、aspire.devを探し回り、APIドキュメントに目を細め、エディタに戻る。コンテキストが失われて、フローが途切れる。

Aspire 13.2がまさにその解決策をリリースしました。aspire docs CLIを使えば、ターミナルから直接Aspireの公式ドキュメントを検索、閲覧、そして読むことができます。そして再利用可能なサービスに支えられているため、AIエージェントやスキルも同じコマンドを使ってドキュメントを参照できます。存在しないAPIを幻覚する代わりに。

これが本当に解決する問題

David Pineがオリジナルの記事で的確に指摘しています：AIエージェントはAspireアプリの構築を支援する点でひどいものでした。aspire runの代わりにdotnet runを推奨し、aspire.devにあるドキュメントに対してlearn.microsoft.comを参照し、古いNuGetパッケージを提案し、そして——個人的に一番のお気に入り——存在しないAPIを幻覚していました。

なぜか？Aspireがポリグロットになるよりもはるかに長い間.NET専用だったからです。そしてLLMは最新機能よりも前のトレーニングデータで動作しています。AIエージェントに現在のドキュメントを実際に検索する能力を与えると、推測をやめて役に立つようになります。

3つのコマンド、ブラウザタブはゼロ

CLIは爽快なほどシンプルです：

すべてのドキュメントを一覧表示

aspire docs list

aspire.devで利用可能なすべてのドキュメントページを返します。マシンリーダブルな出力が必要ですか？--format Jsonを追加してください。

トピックを検索

aspire docs search "redis"

タイトルとコンテンツの両方を重み付けされた関連性スコアリングで検索します。内部的にドキュメントツールを支えているのと同じ検索エンジンです。タイトル、スラグ、関連性スコアを含むランク付けされた結果が得られます。

ページ全体を読む（またはセクションだけ）

aspire docs get redis-integration

ページ全体をマークダウンとしてターミナルにストリーミングします。セクションだけ必要ですか？

aspire docs get redis-integration --section "Add Redis resource"

外科的精度。500行をスクロールする必要はありません。必要な部分だけ。

AIエージェントの視点

ここからがAIツールで開発している私たち開発者にとって面白くなるところです。同じaspire docsコマンドが、スキル、MCPサーバー、またはシンプルなCLIラッパーを通じて、AIエージェントのツールとして機能します。

あなたのAIアシスタントが古いトレーニングデータに基づいてAspire APIを捏造する代わりに、aspire docs search "postgres"を呼び出して、公式のインテグレーションドキュメントを見つけ、正しいページを読み、ドキュメントに記載されたアプローチを提供できます。リアルタイムで最新のドキュメント——モデルが6ヶ月前に記憶したものではありません。

この背後のアーキテクチャは意図的なものです。Aspireチームは一回限りのインテグレーションではなく、再利用可能なサービス（IDocsIndexService、IDocsSearchService、IDocsFetcher、IDocsCache）を構築しました。つまり、同じ検索エンジンがターミナルの人間、エディタのAIエージェント、CIパイプラインの自動化のために機能します。

実世界のシナリオ

ターミナルでの素早い検索： 3ファイルの深さに入っていて、Redisの設定パラメータが必要。2つのコマンド、90秒、仕事に戻る：

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI支援開発： VS CodeスキルがCLIコマンドをラップします。「AppHostにPostgreSQLデータベースを追加して」と聞くと、エージェントが回答する前に実際のドキュメントを参照します。幻覚なし。

CI/CDバリデーション： パイプラインがAppHost設定を公式ドキュメントに対してプログラム的に検証します。--format Jsonの出力はjqやその他のツールにきれいにパイプできます。

カスタムナレッジベース： 独自のAIツールを構築していますか？構造化されたJSON出力をナレッジベースに直接パイプ：

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Webスクレイピングなし。APIキーなし。内部的にドキュメントツールが使用しているのと同じ構造化データ。

ドキュメントは常に最新

これが私が最も評価している部分です。CLIはスナップショットをダウンロードしません——ETagベースのキャッシュでaspire.devにクエリを実行します。ドキュメントが更新された瞬間、あなたのCLIとその上に構築されたすべてのスキルがそれを反映します。古いコピーも、「でもwikiには書いてあった…」という瞬間もありません。

まとめ

aspire docsは、実際の問題をきれいに解決する、そんな小さな機能の一つです。人間はターミナルネイティブなドキュメントアクセスを得ます。AIエージェントは推測をやめて実際のドキュメントを参照する方法を得ます。そしてすべてが同じ信頼の源に支えられています。

.NET Aspireで構築していてまだCLIを試していないなら、aspire docs search "あなたのトピック" を実行して、どう感じるか確かめてください。そして、使っているAIスキルや自動化セットアップにそれらのコマンドをラップすることを検討してください——あなたのエージェントが感謝するでしょう。

ドキュメントツールがどのように構築されたかについてのDavid Pineの詳細記事と、すべての詳細が記載された公式CLIリファレンスをチェックしてください。

Microsoft Agent Frameworkが1.0に到達 — .NET開発者にとって本当に重要なこと

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

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

Semantic KernelやAutoGenの初期からAgent Frameworkの歩みを追ってきた方にとって、今回のニュースは大きいです。Microsoft Agent Frameworkがバージョン1.0に到達しました — 本番環境対応、安定したAPI、長期サポートのコミットメント。.NETとPythonの両方で利用可能で、実際のワークロードに本当に対応できる状態です。

発表のノイズを切り抜けて、.NETでAI搭載アプリを構築している方にとって重要なポイントに集中しましょう。

短いまとめ

Agent Framework 1.0は、かつてSemantic KernelとAutoGenだったものを単一のオープンソースSDKに統合します。1つのエージェント抽象化。1つのオーケストレーションエンジン。複数のAIプロバイダー。エンタープライズパターン向けのSemantic Kernelと研究グレードのマルチエージェントワークフロー向けのAutoGenを行き来していた方は、もうその必要はありません。これが唯一のSDKです。

はじめるのはほぼ不公平なほど簡単

.NETで動作するエージェントはこちら：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

これだけです。数行でAzure Foundryに対して実行されるAIエージェントが完成します。Pythonの同等コードも同様に簡潔です。関数ツール、マルチターン会話、ストリーミングは必要に応じて追加できます — APIサーフェスは奇妙になることなくスケールアップします。

マルチエージェントオーケストレーション — これが本題

単一エージェントはデモには十分ですが、本番シナリオには通常、調整が必要です。Agent Framework 1.0は、Microsoft ResearchとAutoGenから直接もたらされた実戦テスト済みのオーケストレーションパターンを搭載しています：

シーケンシャル — エージェントが順番に処理（ライター → レビュアー → エディター）
コンカレント — 複数のエージェントに並列で展開し、結果を収束
ハンドオフ — 1つのエージェントがインテントに基づいて別のエージェントに委任
グループチャット — 複数のエージェントが議論し、解決策に収束
Magentic-One — MSRの研究グレードのマルチエージェントパターン

すべてがストリーミング、チェックポイント、ヒューマンインザループの承認、一時停止/再開をサポートしています。チェックポイントの部分は重要です — 長時間実行されるワークフローがプロセスの再起動を生き延びます。Azure Functionsで耐久性のあるワークフローを構築してきた.NET開発者にとって、これは馴染みのある感覚です。

最も重要な機能

知っておく価値があるものの私のリストはこちら：

ミドルウェアフック。 ASP.NET Coreにミドルウェアパイプラインがあるのをご存知ですか？同じコンセプトですが、エージェント実行用です。すべてのステージをインターセプト — コンテンツセーフティ、ロギング、コンプライアンスポリシーを追加 — エージェントのプロンプトに触れることなく。これがエージェントをエンタープライズ対応にする方法です。

プラガブルメモリ。 会話履歴、永続的なキーバリューステート、ベクトルベースの検索。バックエンドを選択：Foundry Agent Service、Mem0、Redis、Neo4j、またはカスタム実装。メモリは、ステートレスなLLM呼び出しを、実際にコンテキストを覚えているエージェントに変えるものです。

宣言的YAMLエージェント。 エージェントの指示、ツール、メモリ、オーケストレーショントポロジーをバージョン管理されたYAMLファイルで定義します。単一のAPI呼び出しでロードして実行。これは、コードを再デプロイせずにエージェントの動作をイテレーションしたいチームにとってゲームチェンジャーです。

A2AとMCPサポート。 MCP（Model Context Protocol）により、エージェントは外部ツールを動的に発見して呼び出すことができます。A2A（Agent-to-Agentプロトコル）はクロスランタイムコラボレーションを実現します — .NETエージェントは他のフレームワークで実行されているエージェントと連携できます。A2A 1.0サポートは近日対応予定です。

注目すべきプレビュー機能

1.0ではいくつかの機能がプレビューとして出荷されました — 機能は動作しますがAPIは変更される可能性があります：

DevUI — エージェントの実行、メッセージフロー、ツール呼び出しをリアルタイムで可視化するブラウザベースのローカルデバッガー。Application Insightsのようなものですが、エージェントの推論用です。
GitHub Copilot SDKとClaude Code SDK — オーケストレーションコードから直接CopilotまたはClaudeをエージェントハーネスとして使用。同じワークフロー内の他のエージェントと一緒にコーディング対応エージェントを構成できます。
Agent Harness — エージェントにシェル、ファイルシステム、メッセージングループへのアクセスを提供するカスタマイズ可能なローカルランタイム。コーディングエージェントや自動化パターンを想像してください。
Skills — エージェントに構造化された機能をすぐに提供する再利用可能なドメイン機能パッケージ。

Semantic KernelまたはAutoGenからの移行

既存のSemantic KernelまたはAutoGenコードがある場合、コードを分析してステップバイステップの移行プランを生成する専用の移行アシスタントがあります。Semantic Kernel移行ガイドとAutoGen移行ガイドがすべてを案内してくれます。

RCパッケージを使用していた場合、1.0へのアップグレードはバージョン番号の変更だけです。

まとめ

Agent Framework 1.0は、エンタープライズチームが待ち望んでいた本番環境のマイルストーンです。安定したAPI、マルチプロバイダーサポート、実際に大規模に機能するオーケストレーションパターン、そしてSemantic KernelとAutoGenの両方からの移行パス。

フレームワークはGitHubで完全にオープンソースで、dotnet add package Microsoft.Agents.AIで今日から始められます。クイックスタートガイドとサンプルをチェックして、実際に触ってみてください。

「本番環境で安全に使える」というシグナルを待っていた方へ — これがそのシグナルです。

Aspire 13.2のダッシュボードにテレメトリAPIが搭載 — これで全てが変わる

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

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

.NET Aspireで分散アプリケーションを構築しているなら、ダッシュボードが体験全体の中で最高のものだと既に知っているでしょう。すべてのトレース、ログ、メトリクスが一箇所に — 外部のJaegerも不要、Seqのセットアップも不要、「別のターミナルを確認させて」という瞬間もなし。

Aspire 13.2で大幅に改善されました。James Newton-Kingがアップデートを発表しましたが、正直なところ、テレメトリエクスポートとAPI機能だけでアップグレードの価値があります。

テレメトリをまともにエクスポートする

誰もが経験したシナリオ：分散問題をデバッグしていて、20分のセットアップの後にようやく再現でき、チームに何が起きたかを共有する必要がある。以前は？スクリーンショット。トレースIDのコピペ。いつもの混乱。

Aspire 13.2はログとテレメトリの管理ダイアログを追加しました：

すべてのテレメトリをクリア（再現前に便利）
選択したテレメトリを標準OTLP/JSON形式のZIPファイルにエクスポート
そのZIPを後で任意のAspireダッシュボードに再インポート

最後のポイントがキラー機能です。バグを再現し、テレメトリをエクスポートし、ワークアイテムに添付すれば、チームメイトが自分のダッシュボードにインポートして、あなたが見たものと全く同じものを見ることができます。「あなたのマシンで再現できる？」はもう不要です。

個々のトレース、スパン、ログにもコンテキストメニューに「Export JSON」オプションがあります。特定のトレースを共有する必要がある？右クリック、JSONをコピー、PRの説明に貼り付け。完了。

テレメトリAPIが本当のゲームチェンジャー

最もワクワクしているのがこれです。ダッシュボードが/api/telemetry配下でHTTP APIを公開し、テレメトリデータをプログラマティックにクエリできるようになりました。利用可能なエンドポイント：

GET /api/telemetry/resources — テレメトリ付きリソースの一覧
GET /api/telemetry/spans — フィルター付きスパンのクエリ
GET /api/telemetry/logs — フィルター付きログのクエリ
GET /api/telemetry/traces — トレースの一覧
GET /api/telemetry/traces/{traceId} — 特定トレースの全スパン取得

すべてOTLP JSON形式で返されます。これは新しいCLIコマンドaspire agent mcpとaspire otelを駆動しますが、本当の意味はもっと大きい：アプリのテレメトリを直接クエリするツーリング、スクリプト、AIエージェント統合を構築できるようになりました。

デバッグ中に実際の分散トレースを見ることができるAIコーディングエージェントを想像してください。それはもう仮説ではありません — このAPIが可能にするものです。

GenAIテレメトリが実用的に

Semantic KernelやMicrosoft.Extensions.AIでAI搭載アプリを構築しているなら、改善されたGenAIテレメトリビジュアライザーを評価するでしょう。Aspire 13.2の追加機能：

AIツールの説明がMarkdownでレンダリング
トレースページに専用のGenAIボタンで素早いアクセス
切り詰められた、または非標準のGenAI JSONに対するエラー処理の改善
ツール定義間のクリックでハイライトするナビゲーション

ブログ記事では、VS Code Copilot chat、Copilot CLI、OpenCodeのすべてがOTEL_EXPORTER_OTLP_ENDPOINTの設定をサポートしていると言及されています。Aspireダッシュボードに向ければ、テレメトリを通じてAIエージェントがリアルタイムで考えている様子を文字通り見ることができます。他では見つけられないデバッグ体験です。

まとめ

Aspire 13.2はダッシュボードを「便利なデバッグUI」から「プログラマブルなオブザーバビリティプラットフォーム」に変えます。エクスポート/インポートワークフローだけで分散デバッグの実際の時間を節約し、テレメトリAPIはAI支援診断への扉を開きます。

既にAspireを使っているなら、アップグレードしましょう。まだなら — aspire.devを試してみる良い理由です。

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エージェント — このアップデートは価値があります。

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

Azure DevOpsがついに全員が不満だったMarkdownエディタを修正

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

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

Azure Boardsを使っているなら、きっとこの経験があるでしょう：ワークアイテムの説明を読んでいて、受け入れ条件を確認している最中に、うっかりダブルクリックしてしまう。ドカン — 編集モードに入ってしまった。何も編集したくなかった。ただ読んでいただけなのに。

Dan Hellemが修正を発表しました。小さく聞こえる変更ですが、日常のワークフローから本当の摩擦を取り除くものです。

何が変わったか

ワークアイテムのテキストフィールド用Markdownエディタがデフォルトでプレビューモードで開くようになりました。コンテンツを読んだり操作したり — リンクをたどったり、フォーマットを確認したり — 誤って編集モードに入る心配なく行えます。

実際に編集したい時は、フィールド上部の編集アイコンをクリックします。終わったら、明示的にプレビューモードに戻ります。シンプル、意図的、予測可能。

なぜ見た目以上に重要か

コミュニティフィードバックスレッドは長いものでした。ダブルクリックで編集の動作は2025年7月のMarkdownエディタで導入され、苦情はほぼ即座に始まりました。

Azure Boardsでスプリント計画、バックログリファインメント、コードレビューを行うチームにとって、この種のマイクロ摩擦は積み重なります。

ロールアウト状況

すでに一部の顧客に展開中で、今後2〜3週間で全員に拡大されます。

まとめ

すべての改善がヘッドライン機能である必要はありません。時に最高のアップデートは、単に迷惑なものを取り除くことです。これはまさにそれ — ワークアイテムを静かに読みたい人にとってAzure Boardsをより親切にする小さなUX修正です。

Bookmark Studioがスロットベースのナビゲーションと共有をVisual Studioのブックマークに追加

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

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

Visual Studioのブックマークはずっと…まあまあでした。ひとつ設定して、次に移動して、どれがどれか忘れる。機能するけど、パワフルと呼べるものではありませんでした。

Mads KristensenがBookmark Studioをリリースしました。定期的にブックマークを使っているなら感じていたギャップを正確に埋める実験的な拡張機能です。

スロットベースのナビゲーション

ブックマークをスロット1〜9に割り当て、Alt+Shift+1からAlt+Shift+9で直接ジャンプできます。新しいブックマークは自動的に次の利用可能なスロットを取得します。

ブックマークマネージャー

新しいツールウィンドウですべてのブックマークを表示し、名前、ファイル、場所、色、スロットでフィルタリングできます。

ラベル、色、フォルダーで整理

ブックマークにラベル、色を付けてフォルダーにグループ化できます。メタデータはソリューションごとに保存されます。

エクスポートと共有

Bookmark Studioはプレーンテキスト、Markdown、CSVとしてブックマークをエクスポートできます。

コードの移動に追従するブックマーク

Bookmark Studioはアンカーされたテキストに対してブックマークを追跡するので、編集中に間違った行にずれることがありません。

まとめ

Bookmark Studioは何も再発明しません。何年も「十分」だった機能を本当に便利にします。Visual Studio Marketplaceからダウンロードしてください。

Visual Studioの3月アップデートでカスタムCopilotエージェントが作成可能に — find_symbolが大きな進化

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

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

Visual Studioが最も重要なCopilotアップデートを受けました。Mark Downieが3月リリースを発表し、見出しはカスタムエージェントですが、正直なところfind_symbolツールがワークフローを最も変える機能かもしれません。

リポジトリ内のカスタムCopilotエージェント

Copilotにチームのコーディング標準に従わせたい？カスタムエージェントはリポジトリの.github/agents/に.agent.mdファイルとして定義されます。各エージェントはワークスペース認識、コード理解、ツール、優先モデル、MCP接続へのフルアクセスを持ちます。

エージェントスキル：再利用可能なインストラクションパック

スキルはリポジトリの.github/skills/またはプロファイルの~/.copilot/skills/から自動的にロードされます。

find_symbol：言語対応ナビゲーション

新しいfind_symbolツールはCopilotのエージェントモードに言語サービスベースのシンボルナビゲーションを提供します。テキスト検索の代わりに、シンボルのすべての参照を見つけ、型情報やスコープにアクセスできます。

.NET開発者にとって、これは大きな改善です — 深い型階層を持つC#コードベースが大きく恩恵を受けます。

Copilotでテストをプロファイル

Test ExplorerのコンテキストメニューにProfile with Copilotが追加されました。Profiling Agentがテストを実行し、パフォーマンスを自動分析します。

ライブデバッグ中のPerf Tips

パフォーマンス最適化がデバッグ中に行われるようになりました。Visual Studioがインラインで実行時間を表示します。遅い行を見つけたら、Perf Tipをクリックして最適化の提案をCopilotに依頼できます。

Solution ExplorerからNuGet脆弱性を修正

NuGetパッケージの脆弱性が検出されると、Solution Explorerに直接Fix with GitHub Copilotリンクが表示されます。

まとめ

カスタムエージェントとスキルが見出しですが、find_symbolが隠れた逸品です — .NETコードのリファクタリング時のCopilotの精度を根本的に変えます。Visual Studio 2026 Insidersをダウンロードしてお試しください。

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リファレンスとその他のより例については完全なドキュメントをご覧ください。

VS Code 1.112：.NET開発者が本当に注目すべきこと

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

VS Code 1.112がリリースされました。正直に言うと、.NETの世界で日々過ごしているなら、このリリースは一味違います。公式リリースノートには多くの内容がありますが、スクロールの手間を省いて、私たちにとって本当に重要なことに焦点を当てましょう。

Copilot CLIがずっと便利になった

今回のリリースの大きなテーマはエージェントの自律性 — Copilotにもっと自由にやらせて、あなたが一つ一つのステップを見守る必要をなくすことです。

メッセージのステアリングとキューイング

Copilot CLIがタスクの途中で、何か言い忘れたことに気づく瞬間を知っていますか？以前は待つしかありませんでした。今はリクエストがまだ実行中でもメッセージを送れます — 現在のレスポンスを方向付けるか、フォローアップの指示をキューに入れるかのどちらかです。

dotnetのスキャフォールディングの長いタスクで、Copilotがプロジェクトをセットアップしているのを見ながら「あ、待って、MassTransitも必要だった」と思う時に、これは最高です。

パーミッションレベル

これが一番ワクワクするものです。Copilot CLIセッションが3つのパーミッションレベルをサポートするようになりました：

デフォルトパーミッション — ツールが実行前に確認を求める通常のフロー
承認バイパス — すべてを自動承認し、エラー時にリトライ
オートパイロット — 完全に自律：ツールを承認し、自分の質問に答え、タスクが完了するまで続行

ASP.NET Core APIをEntity Framework、マイグレーション、Dockerセットアップで新規作成するなら — オートパイロットモードは欲しいものを説明してコーヒーを取りに行くだけ。なんとかしてくれます。

chat.autopilot.enabled設定でオートパイロットを有効にできます。

デリゲーション前の変更プレビュー

Copilot CLIにタスクをデリゲートすると、ワークツリーが作成されます。以前は、コミットしていない変更がある場合、ソースコントロールを確認して何が影響されるかを見る必要がありました。今はチャットビューで保留中の変更がすぐそこに表示され、コピー、移動、無視を決められます。

小さなことですが、「待って、何をステージしてたっけ？」というモーメントから救ってくれます。

VS Codeを離れずにWebアプリをデバッグ

統合ブラウザがフルデバッグをサポートするようになりました。ブレークポイントの設定、コードのステップスルー、変数の検査 — すべてVS Code内で。Edge DevToolsに切り替える必要はもうありません。

新しいeditor-browserデバッグタイプがあり、既存のmsedgeやchromeのランチ設定がある場合、移行はlaunch.jsonのtypeフィールドを変更するだけです：

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor開発者にとって、これはゲームチェンジャーです。すでにターミナルでdotnet watchを実行しています — デバッグも同じウィンドウに留まります。

ブラウザには独立したズームレベル（やっと）、適切な右クリックコンテキストメニュー、Webサイトごとにズームが記憶される機能も追加されました。

MCPサーバーのサンドボックス

これは思っている以上に重要です。MCPサーバーを使っている場合 — Azureリソースやデータベースクエリ用にカスタムのものを設定しているかもしれません — これまでVS Codeプロセスと同じ権限で実行されていました。つまり、ファイルシステム、ネットワーク、すべてへのフルアクセスです。

今はサンドボックス化できます。mcp.jsonで：

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

サンドボックス化されたサーバーが持っていないものへのアクセスが必要な場合、VS Codeが権限の付与を促します。「誰も変なことをしないことを祈る」アプローチよりずっと良いです。

注意： サンドボックスは現在macOSとLinuxで利用可能です。Windowsサポートは準備中 — WSLのようなリモートシナリオは動作します。

モノレポのカスタマイゼーション発見

モノレポで作業している場合（正直に言うと、多くのエンタープライズ.NETソリューションはモノレポになります）、これは本当の痛みのポイントを解決します。

以前は、リポジトリのサブフォルダを開いた場合、リポジトリルートにあるcopilot-instructions.md、AGENTS.md、カスタムスキルをVS Codeが見つけませんでした。chat.useCustomizationsInParentRepositories設定により、.gitルートまで遡ってすべてを発見するようになりました。

これはチームがエージェントの指示、プロンプトファイル、カスタムツールをモノレポ内のすべてのプロジェクト間で共有できることを意味します。全員がルートフォルダを開く必要はありません。

エージェントデバッグ用の/troubleshoot

カスタム指示やスキルを設定して、なぜ検出されないか不思議に思ったことはありますか？新しい/troubleshootスキルはエージェントのデバッグログを読んで何が起きたかを教えてくれます — どのツールが使われたかスキップされたか、なぜ指示がロードされなかったか、何が遅い応答を引き起こしているか。

次の設定で有効にします：

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

チャットで/troubleshoot why is my custom skill not loading?と入力するだけです。

これらのデバッグログのエクスポートとインポートもできるようになり、何かが期待通りに動作しない場合にチームと共有するのに最適です。

画像とバイナリファイルのサポート

エージェントがディスクから画像ファイルとバイナリファイルをネイティブに読めるようになりました。バイナリファイルはhexdump形式で表示され、画像出力（統合ブラウザからのスクリーンショットなど）はカルーセルビューに表示されます。

.NET開発者の場合：UIバグのスクリーンショットをチャットに貼り付けてエージェントに何が問題かを理解させたり、Blazorコンポーネントのレンダリング出力を分析させたりできます。

自動シンボル参照

小さなクオリティオブライフの改善：シンボル名（クラス、メソッドなど）をコピーしてチャットに貼り付けると、VS Codeが自動的に#sym:Name参照に変換するようになりました。手動で追加することなく、エージェントにそのシンボルの完全なコンテキストを提供します。

プレーンテキストが欲しい場合はCtrl+Shift+Vを使用してください。

プラグインの有効/無効切り替え

以前はMCPサーバーやプラグインを無効にするには、アンインストールする必要がありました。今はオン/オフを切り替えられます — グローバルにもワークスペースごとにも。拡張機能ビューまたはカスタマイゼーションビューで右クリックするだけです。

npmとpypiのプラグインも自動更新できるようになりましたが、更新はマシン上で新しいコードを実行することを意味するので、まず承認を求めます。

まとめ

VS Code 1.112は明らかにエージェント体験を強力に推進しています — より多くの自律性、より良いデバッグ、より厳密なセキュリティ。.NET開発者にとって、統合ブラウザデバッグとCopilot CLIの改善が際立った機能です。

.NETプロジェクトでCopilot CLIのフルセッションをオートパイロットモードで試したことがないなら、このリリースが始めるのに良いタイミングです。パーミッションを設定して、あとはお任せしましょう。

VS Code 1.112をダウンロードするか、VS Code内からヘルプ > 更新の確認で更新してください。

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

Emiliano Montesdeoca

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog に投稿する

Mon, 01 Jan 0001 00:00:00 +0000

The .NET Blog は、開発者が .NET、Azure、AI、クラウドネイティブ開発に関する洞察、チュートリアル、ストーリーを共有するコミュニティ主導の出版物です。すべてのレベルの開発者からの投稿を歓迎します — 初めての技術記事を書く方も、経験豊富なスピーカーも大歓迎です。

参加方法

すべては GitHub 上にあり、プルリクエストのワークフローに従います。

1. リポジトリをフォークする

github.com/thedotnetblog/blog にアクセスし、あなたの GitHub アカウントにフォークしてください。

2. 著者プロフィールを作成する

初めての投稿の場合、content/authors/your-username/ フォルダを作成し、index.md ファイルに名前、役割、自己紹介を追加してください。アバター画像（正方形、最低 200×200px）を static/img/authors/ に追加してください。

3. 記事を書く

content/posts/your-username/your-post-slug/ に新しいフォルダを作成し、タイトル、日付、著者、説明、タグを含む index.md ファイルを追加してください。

4. プルリクエストを開く

変更をあなたのフォークにプッシュし、main ブランチへのプルリクエストを開いてください。チームが数日以内にレビューしてフィードバックを提供します。

求めているコンテンツ

チュートリアル — .NET、Azure、AI、Blazor、Aspire などのステップバイステップガイド
ディープダイブ — 技術、パターン、アーキテクチャの詳細な解説
コミュニティストーリー — 本番環境での .NET 活用経験
イベントレポート — カンファレンス、ミートアップ、ウェビナーのまとめ

ガイドライン

コンテンツは .NET エコシステムに関連する技術的なものであること
コード例は実際のプロジェクトで動作確認済みであること
意味のある説明と少なくとも 1 つの関連タグを含めること
記事はサポートされているすべての言語に自動翻訳されます

お問い合わせ

GitHub で Issue を開くか、X / Twitter でお気軽にご連絡ください。コミュニティでお会いできることを楽しみにしています！

The .NET Blog

NDC Oslo 2026

数字で見る

確定スピーカー

チケット

2026年の他の NDC イベント

リンク

.NET Day Switzerland 2026

参加者へのメリット

チケット

主催者

リンク

SDD Conference 2026

トピック

スピーカー

チケットと情報

Azure DevOps MCP Server 4月アップデート: WIQLクエリ、PAT認証、実験的MCP Apps

WIQLクエリサポート

Personal Access Tokens

MCPアノテーション

Wikiツールの統合

実験的: MCP Apps

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

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

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

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

.NET 10 が Ubuntu 26.04 LTS に搭載 — 新機能まとめ

.NET 10 を 2 つのコマンドでインストール

コンテナ：-noble を -resolute に更新

Native AOT：3ms 起動、1.4MB バイナリ

.NET 8 または 9 が必要な場合

Agent FrameworkのCodeAct：エージェントのレイテンシを半分にする方法

CodeActとは？

セキュリティ：Hyperlightマイクロ-VM

最小セットアップ

いつCodeActを使うか（使わないか）

今すぐ試す

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 の進化

実際に何が変わったか

価格

Foundry が重要な理由

VS Code 1.118: Copilot CLI にセッション名、モデルバッジ、TypeScript 7.0 ナイトリーオプトイン

Copilot CLI: セッションに実際の名前が付く

キーボードショートカットで素早くセッション切り替え

チャットにモデルバッジ表示

Copilot CLI に自動モデル選択

TypeScript 7.0 ナイトリーのオプトイン

あなたのエージェントはどこで物事を覚えているか？チャット履歴ストレージの実践ガイド

2つの基本パターン

Agent Frameworkによる抽象化

プロバイダー早見表

選び方

Aspire 13.2: Bun サポート、コンテナ改善、デバッグの摩擦軽減

Bunがファーストクラスになりました

Yarnの信頼性向上

コンテナの改善

デバッグの改善

1日68分もコードを再説明している？解決策があります

コンテキストウィンドウの嘘

コンパクション税

auto-memory：リコールレイヤー

まとめ

Foundry Toolboxes: AIエージェントツールのための統一エンドポイント

Toolboxとは

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

実践的な例

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

今なぜ重要か

まとめ

Python、TypeScript、.NETでazdフックを書く：シェルスクリプトとの決別

コンテナ：`-noble` を `-resolute` に更新