Dotnet | The .NET Blog

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

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リポジトリを、すべての詳細は元のアナウンスをご覧ください。

ターミナルの見張り番はもう終わり：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を入手してください。

ピンクラスタリングがついに .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脆弱性は後回しにできるものではありません。

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リファレンスと例については完全な記事をお読みください。

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

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

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に移行する予定なら — プラットフォームは大幅にプロダクションレディになりました。

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内からヘルプ > 更新の確認で更新してください。

Dotnet | The .NET Blog

SDD Conference 2026

トピック

スピーカー

チケットと情報

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

フックとは

検出の仕組み

言語別の重要な詳細

Python

JavaScriptとTypeScript

.NET

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

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

まとめ

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

winapp run: どこからでもF5

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

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

その他の新機能

インストール方法

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

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

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

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

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

まとめ

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

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

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

クラスタータップの処理

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

なぜこれが重要なのか

始めよう

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

パッチされた内容

更新されたバージョン

対応すべきこと

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

Azure MCP Server とは？

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

セキュリティの強化

どこで使用できますか？

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

はじめに

まとめ

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

問題は現実のもの

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

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

始め方

まとめ

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

解決策：--isolated

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

内部の仕組み

いつ使うべきか

まとめ

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

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

認証オプション

セットアップ

私の見解

まとめ

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

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

2つの始め方

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

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

私の見解

まとめ

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

MCP Appsとは？

Fluent APIの3ステップ

APIの設計が秀逸

始め方

まとめ

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

ユニオンが解決する問題

構文は美しくシンプル

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

解決策：`--isolated`