Azd | The .NET Blog

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の日常ワークフローから多くの摩擦を取り除く変更の一つ。フックのマルチ言語サポートは今すぐ利用可能 — 公式ポストで全ドキュメントを確認してほしい。

azd + GitHub Copilot: AIによるプロジェクトセットアップとスマートなエラー解決

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

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

既存のアプリをAzureにデプロイしようとして、空の azure.yaml を眺めながら「Express APIにはContainer AppsとApp Serviceのどちらを使えばいいんだっけ？」と頭を抱えた経験はありませんか？そんな場面が、これからは格段に短くなります。

Azure Developer CLI（azd）がGitHub Copilotと2つの形で統合されました。azd init 実行時のAIによるプロジェクトスキャフォールディングと、デプロイ失敗時のインテリジェントなエラートラブルシューティングです。どちらの機能もターミナル内で完結します。

azd init でのCopilotセットアップ

azd init を実行すると、「Set up with GitHub Copilot (Preview)」という選択肢が表示されます。選択すると、Copilotがコードベースを分析し、実際のコードに基づいて azure.yaml、インフラテンプレート、Bicepモジュールを生成します。

azd init
# 選択: "Set up with GitHub Copilot (Preview)"

必要なもの：

azd 1.23.11以降 — azd version で確認、azd update で更新
有効なGitHub Copilotサブスクリプション（Individual、Business、またはEnterprise）
GitHub CLI（gh） — 必要に応じてログインを求められます

この機能の優れた点は双方向に機能することです。ゼロから構築する場合はAzureサービスの適切なセットアップを支援し、既存のアプリをデプロイしたい場合はコードを分析して設定を生成します。構造を変更する必要はありません。

実際に何をするのか

Node.js ExpressのAPIにPostgreSQLの依存関係がある場合を例にしましょう。Container AppsかApp Serviceかを手動で決め、BicepをゼロからT書く代わりに、Copilotはスタックを検出して以下を生成します：

適切な language、host、build 設定を持つ azure.yaml
Azure Container Apps用のBicepモジュール
Azure Database for PostgreSQL用のBicepモジュール

変更前に事前チェックも実行されます。gitの作業ディレクトリがクリーンかどうか確認し、MCPサーバーツールへの同意を事前に求めます。何が変わるか把握した上でのみ処理が進みます。

Copilotによるエラートラブルシューティング

デプロイエラーは避けられません。パラメーターの欠落、権限の問題、SKUの可用性問題など。エラーメッセージが修正方法を教えてくれることはほとんどありません。

Copilotなしの場合のループ：エラーをコピー → ドキュメントを検索 → 関係ないStack Overflowの回答を3つ読む → az CLIコマンドを実行 → 再試行して祈る。azd にCopilotが統合されると、このループが消えます。azd コマンドが失敗すると、即座に4つの選択肢が提示されます：

Explain — 何が起きたかをわかりやすく説明
Guidance — 修正のステップバイステップの手順
Diagnose and Guide — 完全な分析 + Copilotが修正を適用（承認後）+ 再試行オプション
Skip — 自分で対処

重要な点：Copilotはすでにプロジェクト、失敗したコマンド、エラー出力のコンテキストを持っています。提案は あなたの状況 に特化したものです。

デフォルト動作の設定

常に同じオプションを選ぶなら、インタラクティブなプロンプトをスキップできます：

azd config set copilot.errorHandling.category troubleshoot

値：explain、guidance、troubleshoot、fix、skip。自動修正と再試行も有効にできます：

azd config set copilot.errorHandling.fix allow

いつでもインタラクティブモードに戻せます：

azd config unset copilot.errorHandling.category

まとめ

azd update で最新バージョンに更新し、次のプロジェクトで azd init を試してみてください。本当に価値のあるCopilot統合です。

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

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

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

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

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