Cloud | The .NET Blog

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でのAI実験がお金を燃やしている — その解決方法はこちら

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

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

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

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

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

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

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

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

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

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

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

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

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

実際に効果があること

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

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

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

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

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

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

まとめ

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

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