Developer Tools | The .NET Blog

VS Code 1.119：エージェントセッションの OpenTelemetry、ブラウザー統合、セキュリティ

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

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

VS Code 1.119 は 2026 年 5 月 6 日にリリースされました（その後すぐに 1.119.1 セキュリティパッチも公開）。このリリースはエージェントの可観測性、ブラウザーとの連携、割り込みの削減に重点を置いています。

エージェントセッションの OpenTelemetry トレーシング

本番環境でエージェントを実行している方や、エージェントワークフローをデバッグしている方にとって注目の機能です。2 つの設定で有効化します：

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

トレースは GenAI セマンティック規約に従います。各エージェントリクエストは invoke_agent ルートスパンを生成し、ネストされた子スパン（chat、execute_tool、execute_hook）を持ちます。トークン使用量はリクエストごとに報告されます — キャッシュ読み取りと作成のカウントも含みます。

ローカルエージェント、Copilot CLI バックグラウンドエージェント、Claude エージェントと連携します。OTLP 対応バックエンドでトレースを受信できます — ローカル開発には Aspire Dashboard スタンドアロンが便利です。

エージェントがブラウザータブにアクセス可能に

エージェントは統合ブラウザーのタブへのアクセスを要求できるようになりました — ただし自動ではありません。コンテキストピッカー、ドラッグアンドドロップ、または提案されたコンテキストを通じてタブを明示的に共有する必要があります。ブラウザーにアクセスを取り消すための共有ボタンがあります。エージェントが既に開いている（共有されていない）タブと同じドメインの新しいタブを開こうとすると、VS Code は既存のタブを再利用するよう促します。

トークン使用量の最適化

実験的な軽量モデルがエージェントのタスクリスト管理を担うようになり、この管理作業を高コストなメインモデルから切り離します。フルの推論能力を必要としないタスクのトークン消費を削減します。

信頼とセキュリティ

割り込みの削減：VS Code 1.119 はエージェントによるネットワークアクセス要求と一時フォルダーへの書き込みのプロンプトを削減します。1.119.1 パッチは特定のセキュリティ問題に対処しています — まだ更新していない場合は更新することをお勧めします。

Markdown プレビューへのクイックスワップ

小さいながら便利：ナビゲートせずに現在のエディターを Markdown プレビューに素早く切り替えられるようになりました。

VS Code Agents (Insiders プレビュー)

再設計されたエージェントセッション UI — 新しいリポジトリピッカー（ローカル/リポジトリ/リモート）、サブセッションの改善、Web とモバイルの改善、進捗アニメーション — は Insiders の insiders.vscode.dev/agents で利用可能です。

完全な変更履歴：code.visualstudio.com/updates/v1_119。

Azure Data Studio は廃止されました：Azure SQL ワークフローを VS Code に移行する

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

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

Azure Data Studio は 2025 年 2 月 6 日に廃止されました。サポートは 2026 年 2 月 28 日に終了します。推奨される代替ツールは MSSQL 拡張機能を備えた VS Code です。

インストールするもの

開始するために必要な 3 つのもの：

MSSQL 拡張機能 — VS Code Marketplace で「SQL Server (mssql)」を検索
SQL Database Projects 拡張機能 — コードとしてのスキーマ、ビルド検証、ガイド付き公開
.NET 8 SDK — ビルドシステムに必要。SDK が見つからないのは初回起動時の最も一般的な問題

ADS の接続と設定の移行

MSSQL 拡張機能には ADS Migration Toolkit が同梱されており、ガイド付きフローで一度きりの移行を処理します。保存された接続、接続グループ、設定、キーバインドがすべて自動的にインポートされます。

F5 のクセを取り戻す

ADS ユーザーはクエリ実行に F5 を使用します。MSSQL Database Management Keymap 拡張機能をインストールすると、F5 を含む ADS スタイルのキーバインドが復元されます。

SQL Database Projects：コードとしてのスキーマ

プロジェクトを右クリック → 公開 → ターゲットを設定 → 生成された T-SQL スクリプトを確認 → デプロイ。デプロイ前のスクリプトプレビューが主要な安全機能です。アイテムテンプレートはテーブル、ストアドプロシージャ、ビューのスタブを生成します。SSDT と同じワークフローです。

よくある問題：.sqlproj ファイルのターゲットプラットフォームの不一致は、プロジェクトが別の SQL Server バージョン用に作成された場合にビルドエラーを引き起こします。

Schema Compare と Schema Designer

拡張機能には Schema Compare（プロジェクトとデプロイ済みデータベースの差分）と Schema Designer（DDL を手書きせずに視覚的にスキーマを編集）も含まれています。

Microsoft Fabric 開発者向け

セットアップは同一ですが、VS Code で開く前に Fabric ポータルからデータベースを Git に接続することから始めてください。Microsoft には専用ガイドがあります：Azure Data Studio to VS Code — What it means for SQL database in Fabric developers。

まとめ

移行は手動での再構築ではなく、一度きりのガイド付きフローです。3 つのツールをインストールし、ADS Migration Toolkit を実行し、キーバインドを復元すれば、10 分以内に通常の作業に戻れます。

ステップバイステップのスクリーンショットと Fabric 固有のウォークスルーについては、完全な記事をご覧ください。

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

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

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 は大規模リリースです（ベータ版が数日前にリリース）。

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

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

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で開発していてエージェント型ワークフローにまだ踏み込んでいないなら、正直、今が始めるときだ。

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

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の詳しい解説をご覧ください。

.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を試してみてください。

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アプリでかなりの時間を過ごしているなら（そして多くの方がそうだと思いますが）、これらの変更は積み重なっていきます。

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

知らなかった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のエージェントモードを使っているなら、日々の摩擦を減らすクオリティ・オブ・ライフの改善そのものです。

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

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リファレンスをチェックしてください。

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をダウンロードしてお試しください。

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