Claude CodeのAzureプラグインでazure-prepareからデプロイまで進める

Azureプラグインは、MicrosoftがClaude Code向けに配布している公式のプラグインです。入れると、Azure向けの28本のスキルと、Azure MCPサーバー、Microsoft Foundry向けのMCPが一度に使えるようになります。

中心になるのは、azure-prepare、azure-validate、azure-deploy の3つのスキルです。この順に通すことでアプリをAzureへ載せます。この記事では、入れ方、3スキルがそれぞれ何をして何で止まるか、承認の挟まり方、Claude Code側で足しておきたい権限の設定をまとめます。MCPサーバー単体の使い方はAzure MCPサーバーの記事にあります。

Azureプラグインは何が入るのか

プラグインの本体は、スキルの束、MCPサーバーの定義、フックの定義です。Claude Code向けのマニフェスト(plugin.json)の名前は azure で、スキル・MCP設定・フックをそれぞれ指しています。

スキルの役割は、リポジトリの説明では「頭脳」、MCPは「手」と書かれています。スキルが手順と判断基準を与え、MCPがAzureの実リソースに触れるという分担です。

スキルは系統ごとに次のように並んでいます。

リポジトリの skills/ には、ここに挙がっていない azure-reliability や python-appservice-deploy、discover-azure-skills なども置かれています。説明文に載る名前と、ディレクトリにある名前は完全には一致しません。

入れる前に揃えるもの

前提は4つです。

• Azureのアカウントまたはサブスクリプション
• Node.js 18以上(MCPサーバーを npx で起動するため)
• Azure CLIと、az login による認証
• Azure Developer CLI(azd)と azd auth login(デプロイ系を使う場合)

Azure MCPサーバーは npx 経由で起動するので、Node.jsが入っていないとツールが一覧に出ません。この症状はトラブルシューティングの節にも載っています。

Claude Codeへの入れ方

Claude Code向けの手順は、公式マーケットプレイスからの1行です。

/plugin install azure@claude-plugins-official

更新は /plugin update azure@claude-plugins-official です。/plugin を開いて「azure」を検索しても入れられます。プラグインの入れ方の全般はClaude Codeのプラグインとマーケットプレイスの記事で扱っています。

認証はAzure CLI経由が推奨です。ターミナルで先に済ませておきます。

az login
azd auth login

サービスプリンシパルを使う場合は、AZURE_TENANT_ID、AZURE_CLIENT_ID、AZURE_CLIENT_SECRET の3つの環境変数でも認証できます。Azure上で動かすなら、マネージドIDも使えます。

入れ終えたら、3つの質問で動作を確かめます。

1. 「このプロジェクトのデプロイにはどのAzureサービスが必要？」と聞く。一般論でなく、構造化された回答が返ればスキルが効いています
2. 「Azureのリソースグループを一覧して」と聞く。実アカウントの結果が返ればAzure MCPが動いています
3. 「Microsoft Foundryで使えるモデルは？」と聞く。Foundry MCPの確認です

3つのスキルは、なぜ順番に通すのか

3スキルは azure-prepare → azure-validate → azure-deploy の一本道です。各スキルの本文に、前のスキルが済んでいなければ止まるという前提確認が書かれています。

azure-prepare — 計画を書いて承認を取る

最初の仕事は、コードを書くことではなく計画を書くことです。スキル本文には、ワークスペースのルートに .azure/deployment-plan.md の骨組みを「最初の行動として」書き出すよう指示があります。以降のスキルはこのファイルを根拠に動き、無ければ失敗します。

フェーズ1(計画)の中身は次のとおりです。

1. ワークスペースを分析して、新規・変更・近代化のどのモードかを決める
2. 分類、規模、予算などの要件を集める
3. コードベースを走査して、構成要素と依存を洗い出す
4. デプロイの方式(レシピ)を選ぶ。AZD、AZCLI、Bicep、Terraformのいずれか
5. Azureのどのサービスに何を載せるか、アーキテクチャを決める
6. 計画ファイルを仕上げる
7. 計画をユーザーに見せ、承認を取る

承認が出るまで、コードやインフラ定義は生成されません。レシピは既定がAZDで、「Terraformと言われたらazd+Terraform」が既定だとリファレンスに書かれています。既存のワークスペースに azure.yaml があればAZD(Bicep)が、*.tf だけがあればAZD(Terraform)が候補になります。

承認後のフェーズ2では、Azureのコンテキスト(サブスクリプションとリージョン)の確認、生成、セキュリティ強化、動作確認と進み、計画ファイルの状態を Ready for Validation に書き換えてからazure-validateに渡します。ここでは azd up などのデプロイ実行をしません。スキル本文に、実行はazure-deployの担当だと明記されています。

起動の仕方にも癖があります。azure-prepareの説明文は、ユーザーがazdを使いたいと明示した場合か、プロジェクトに azure.yaml がある場合に使うと書いています。一方で、PythonのコードだけをApp Serviceに載せる場合は python-appservice-deploy、AWSやGCPからの移行は azure-cloud-migrate へ回します。

azure-validate — 通らなければ先へ進まない

検証は、スクリプトが一歩ずつ案内する形で進みます。Windowsなら workflow.ps1、macOS/Linuxなら workflow.sh を呼び、出力された次の指示をこなして、また呼ぶ。それを繰り返し、進捗は .azure/validate-status.json に記録されます。

見る対象は、設定、Bicep/Terraform、RBACのロール割り当て、マネージドIDの権限、前提条件です。スキル本文には、全チェックが通らなければデプロイしないというルールがあります。

計画ファイルの状態を Validated にできるのは、このスキルだけです。azure-deploy側にも「状態を手で書き換えるのは禁止」と書かれています。ユーザーがデプロイまで頼んでいればazure-deployへ進み、検証だけ頼まれた場合はここで止まります。

azure-deploy — 実行はここだけ

azd up、azd deploy、terraform apply、az deployment を実行するのは、azure-deployです。計画ファイルが Validated で、検証の証跡の節に実際のコマンドと結果が入っているかを、最初に見ます。空なら検証が飛ばされたものとして、azure-validateに戻ります。

実行前にはチェックリストを終えます。最初の2手は次のとおりです。

1. 現在のサブスクリプションを mcp_azure_mcp_subscription_list(失敗時は az account show)で取得する
2. 見つけた既定のサブスクリプションを選択肢として見せ、ユーザーに確認する

実行後は、エンドポイントのURLを https:// 付きの完全な形で報告します。Azure CLIが素のホスト名を返すことが多いので、スキルが補う決まりになっています。

承認が入る場所を整理する

この仕組みは、スキル側に確認の関所がいくつもあります。

破壊的な操作は、「デプロイを頼まれた」ことを理由に進めてはならず、複数まとめての承認も認めない、と共通ルールにあります。

ただ、これはスキルの文面による自制であって、Claude Codeの権限機構とは別の層です。スキルの指示が効かなかった場合の保険として、settings.json の権限で azd down やリソースグループの削除を塞いでおく手があります。例えば次のような形です。

{
  "permissions": {
    "ask": [
      "Bash(azd up:*)",
      "Bash(azd deploy:*)"
    ],
    "deny": [
      "Bash(azd down:*)",
      "Bash(az group delete:*)"
    ]
  }
}

これは筆者が組んだ一例で、プラグインに同梱された設定ではありません。権限を境界にする考え方は、BicepとAzureのwhat-ifの記事でも扱っています。

計画ファイルを残す運用が効く場面

.azure/deployment-plan.md は、会話の記憶でなくファイルで状態を持たせる作りです。そのため、セッションが切れても、別の日に続きから再開できます。「状態がどこまで進んだか」はファイルを見ればわかります。

チームで使うなら、このファイルをレビューの対象にできます。承認前の計画をPRに載せ、アーキテクチャの選択(どのサービスを使うか、BicepかTerraformか)を人が見てから Ready for Validation へ進める、という運用も取れます。

つまずきやすい点

ソブリンクラウド(Azure ChinaやAzure US Government)を使う場合は、Azure MCPサーバーの起動引数に --cloud を足し、az cloud set と azd config set cloud.name も合わせます。リポジトリの手順はGitHub Copilot CLI向けの例で書かれており、Claude Codeでの設定の書き方は示されていません。

フックはテレメトリ用

プラグインのフックは、SessionStart と PostToolUse に track-telemetry.sh を登録しているだけです。業務を止めたり書き換えたりするフックではありません。

スクリプトの冒頭コメントによれば、記録の対象はスキルの呼び出し(スキル名とバージョン)、Azure MCPツールの呼び出し、スキルに同梱されたリファレンスファイルの読み取りです。止めたいときは、環境変数を設定します。

export AZURE_MCP_COLLECT_TELEMETRY=false

スクリプトはこの値が false なら記録をスキップします。READMEにも、Azure MCPのテレメトリを止める方法として同じ設定が載っています。

まとめ

入れるのは1行で、本番に近い判断はスキル側の計画・検証・実行の三段に分かれています。使い始めるときは、まず既存のサンドボックス用サブスクリプションで「このアプリをAzureに載せる準備をして」と頼み、.azure/deployment-plan.md が先に書かれること、承認前に何も生成されないことを見てください。そのうえで、azd up を ask、azd down を deny にしておくと、スキルの文面だけに頼らない構成になります。