Azure Developer CLI（azd）にGitHub Copilotが統合された。バージョン1.23.11以降、azd initでのプロジェクト自動スキャフォールディングと、デプロイ失敗時のインテリジェントなエラー解決支援という2つの機能が追加されている。地味なアップデートに見えて、実際に使ってみると開発体験が大きく変わる。

azd × GitHub Copilot統合の概要

今回の統合は大きく2つの機能からなる。

① Copilotによるプロジェクト初期化（azd init）

azd initを実行すると「Set up with GitHub Copilot (Preview)」というオプションが表示される。これを選ぶと、Copilotがリポジトリのコードを解析し、言語・フレームワーク・依存ライブラリをもとにazure.yamlとBicepインフラテンプレートを自動生成してくれる。

たとえばExpress.jsとPostgreSQLを使ったNode.jsアプリなら、以下を自動で生成する：

  • azure.yaml（ホストタイプや言語設定）
  • Azure Container Apps用のBicepモジュール
  • Azure Database for PostgreSQL用のBicepモジュール

従来は「Container AppにすべきかApp Serviceにすべきか」をドキュメントで調べ、Bicepを手書きする必要があった。この判断と実装をCopilotが引き受けてくれる形だ。

重要なのは変更前にpreflight checkが走る点。gitの作業ディレクトリがクリーンであることを確認し、MCP（Model Context Protocol）サーバーへのアクセス許可を事前に確認する。何が書き換わるかをユーザーが承認してから初めてファイルが更新される設計は、AIツールとして誠実なアプローチだ。

② デプロイエラーの自動トラブルシューティング

azd provisionやazd upが失敗したとき、従来は「エラーメッセージをコピー → Stack Overflow検索 → az CLIで修正 → 再実行」という手順を踏んでいた。この作業ループが、Copilot統合によってターミナル内で完結する。

エラー発生時は4つの選択肢が表示される：

選択肢 内容

Explain エラーの平易な解説

Guidance 修正手順のステップバイステップ案内

Diagnose and Guide 原因特定＋修正の自動適用（要承認）＋再実行

Skip 自分で対処

対応可能なエラーにはMissingSubscriptionRegistration（サブスクリプションにリソースプロバイダーが未登録）、SkuNotAvailable（該当リージョンにSKUが存在しない）、StorageAccountAlreadyTaken（ストレージアカウント名の重複）などが含まれる。これらはAzureデプロイ初心者がよく踏む落とし穴であり、対応方法を検索する時間を大幅に削減できる。

利用条件

  • azd 1.23.11以降（azd versionで確認、azd updateで更新）
  • GitHub Copilotサブスクリプション（Individual / Business / Enterprise）
  • GitHub CLI（gh）がインストール済みでログイン済みであること

実務への影響

日本のエンジニアが特に恩恵を受けるのはオンボーディング局面だ。

Azureへのデプロイに慣れていないメンバーでも、既存のコードベースを渡せばCopilotがAzure構成を提案してくれる。BicepやARM templateの深い知識がなくても最初の一歩を踏み出せるようになる。

IT管理者・インフラ担当者向けには、エラートラブルシューティング機能が特に有効だ。MissingSubscriptionRegistrationのようなエラーは「どのリソースプロバイダーを登録すればいいのか」を調べる手間が意外と大きい。これがインライン解決できるのは実際の業務時間削減につながる。

「道のド真ん中を歩く」観点では、azdはMicrosoftが推奨する標準的なAzure開発ツールチェーンに完全に乗った存在だ。このツールを軸にした開発フローは、再現性が高く、チーム展開にも向いている。今回のCopilot統合はその価値をさらに高めている。

筆者の見解

azd自体、リリース当初から「これが標準になる」と感じていたツールだ。今回のCopilot統合は、その方向性をさらに強固にするアップデートだと評価している。

とりわけ評価したいのが「ターミナルから出ない」という設計哲学だ。AIアシスタントに頼るたびにブラウザへ切り替え、コンテキストが切れる——この繰り返しが思考の流れを断ち切る。ターミナル完結のトラブルシューティングは、単なる利便性の話ではなく開発者の集中を守る設計として正しい。

プロジェクト初期化についても、生成された構成を「レビューしてから適用」というフローを守っていることが重要だ。AIが書いたインフラコードをそのまま適用するのではなく、人間が目を通す機会が設けられている。特権アクセスと同様に、AIの自動操作にも適切なチェックポイントが必要だという考え方と一致している。

一方で、「Preview」という位置づけはまだ実力を出し切れていない段階であることを示唆している。複雑なマルチサービス構成や、既存のBicepモジュールと組み合わせた場合にどこまで対応できるか、現時点では未知数だ。Azureのプラットフォームとしての底力は間違いないのだから、このCopilot統合もその実力に見合った完成度に育てていってほしいと期待している。

現時点でも、新規プロジェクトの立ち上げや小〜中規模のデプロイには十分実用的だ。azdを使ったことがない方にとっては、このCopilot統合を入り口に試してみるタイミングとして悪くない。

出典: この記事は GitHub Copilot meets Azure Developer CLI: AI-assisted project setup and error troubleshooting の内容をもとに、筆者の見解を加えて独自に執筆したものです。