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

Azure Developer CLI (azd) 2026年4月アップデート

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

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

Azure Developer CLI (azd) は2026年4月に5つのリリースを公開しました（1.23.14 から 1.24.2 まで）。最大のテーマは、Bash と PowerShell だけでなく Python、JavaScript、TypeScript、.NET でも実行できるようになったフックです。

azure.yaml のマルチ言語フック

フックはシェルスクリプトに加えて .py、.js、.ts、.cs ファイルを指定できるようになりました。各言語で依存関係の自動解決が行われます。

Python — requirements.txt または pyproject.toml を検出し、virtualenv を作成して実行前に依存関係をインストールします。env 名は virtualEnvName で設定します。
JavaScript / TypeScript — package.json を検出して npm install を自動実行します。TypeScript はコンパイル不要で npx tsx 経由で実行されます。パッケージマネージャは packageManager 設定ブロックで選択できます。
.NET — .cs ファイルを dotnet run で実行します。.NET 10+ ではシングルファイルスクリプトをサポートします。ターゲットフレームワークは configuration/framework ブロックで設定します。

これにより、これらの言語ですでに作業しているチームは、プロビジョニングのライフサイクルイベントを接続するためだけに別の Bash または PowerShell フックを管理する必要がなくなります。

azd update がパブリックプレビューに

azd update がすべてのプラットフォームでパブリックプレビューに移行しました。azd が最初にどのようにインストールされたかに関わらず、単一のコマンドでアップデートを処理できます。Homebrew、WinGet、MSI のパスを個別に追跡する必要はありません。

AZD_NON_INTERACTIVE による非インタラクティブモード

AZD_NON_INTERACTIVE=true を設定する（または --non-interactive / --no-prompt を使用する）と、必要な入力を自動的に解決できない場合に CI/CD パイプラインで一貫した決定論的な失敗が発生するようになりました。以前はコマンドごとに動作が一致していませんでした。

AI モデルクォータのプリフライトチェック

azd provision は AI モデルリソースのプロビジョニングを試みる前に Azure Cognitive Services のクォータを検証します。クォータ制限により失敗するデプロイは、プロビジョニングの途中ではなく、プロセスの早い段階でエラーが表示されるようになりました。

Copilot トラブルシューティングの「このエラーを修正する」

azd の Copilot トラブルシューティング統合が、提案された修正を直接適用する機能を獲得しました。説明するだけでなく、エージェントが修正可能な問題を特定した場合、その場で変更を加えることができます。

カスタムプロビジョニングプロバイダーと Key Vault シークレットリゾルバー

拡張機能の作成者は WithProvisioningProvider() を使用して代替インフラストラクチャバックエンドを登録できるようになりました。また、azd は設定を拡張機能に渡す前に @Microsoft.KeyVault(...) 参照を自動的に解決するため、カスタムプロバイダーでの手動シークレット解決が不要になります。

テンプレートと watch モードの除外

2 つの新しい ignore ファイルでファイル処理をより細かく制御できます。

.azdignore — コントリビューター専用のファイル（ドキュメント、CI 設定）をテンプレートのコピーから除外し、エンドユーザーがクリーンなプロジェクトスキャフォルドを取得できるようにします。
.azdxignore — azd x watch 中のリビルドトリガーからディレクトリを除外し、反復開発中のノイズを軽減します。

予約名プリフライトと docker.network オプション

azd はプロビジョニング開始前に、予測されるリソース名が Azure の予約語（MICROSOFT、WINDOWS、または LOGIN プレフィックス）を含む場合に警告するようになりました。新しい docker.network オプションは docker build に --network を渡します。これは特定の Docker ネットワークを必要とする企業プロキシ環境で役立ちます。

セキュリティ修正

Windows MSI パッケージにコード署名検証が追加されました。別の修正で、拡張機能コマンドの境界をまたいで値が漏洩する可能性のある環境変数リークが解消されました。

忙しい月でした。特にマルチ言語フックサポートは、主に Bash で作業しないチームにとっての真の摩擦点を解消します。5 つのリリースすべての完全な変更履歴については完全なリリースノートを参照してください。

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はセキュリティと信頼性の両面から、最新のパッチを維持することを強く推奨しています。詳細はリリースノートをご確認ください。

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — 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とポリシーがエージェントに安全に使われるためにどうあるべきか考え始めてください。

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

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修正です。

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エコシステムにいるなら、数クリックで始められます。試してみて、どんなワークフローが構築できるか確認してください。

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