azure-enterprise-infra-planner
企業向けの Azure 基盤を設計させ、Bicep か Terraform まで書かせる。7 段の関門つきで、承認とセキュリティ点検を通らないと先へ進まない
npx skills add microsoft/azure-skills/azure-enterprise-infra-planner入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 446,574
- 実用度
- 77
- GitHub star
- 1,623
- 最終更新
- 2026/11/7
頼み方の例
そのままコピーして使えますazure-enterprise-infra-plannerスキルを使って、ハブ＆スポーク構成のネットワークを持つ本番環境を設計してください。第 4 段の計画（.azure/infrastructure-plan.json）まで作って、そこで止めてください。IaC の生成とデプロイはまだ行わないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: mermaid
いつ使うか
アプリではなく、会社の Azure 基盤そのものを設計するときに効きます。description は対象を「クラウドの設計者と基盤の技術者」と書いています。
頼めること
- 着地点（landing zone）の設計例: サブスクリプション単位の構成
- ネットワーク例: ハブ＆スポーク、VNet、ファイアウォール、プライベート接続、VPN
- 権限と準拠例: ID、ロールの割り当て、規制に沿った構成
- 災害対策例: 複数リージョンの切り替え、バックアップ
- IaC の生成例: Bicep か Terraform を直接書く（
azdは使わない）
7 段の関門を順に通る
一番の特徴は、段ごとに関門があって、通らないと次へ進まない作りです。
| 段 | すること | 関門 |
|---|---|---|
| 1 | 既存の環境から手がかりを集める | — |
| 2 | 最良の実践を調べる | — |
| 3 | 使う資源を調べる | 資源の一覧を利用者が承認 |
| 4 | 計画を作る（.azure/infrastructure-plan.json） | — |
| 5 | 計画を確かめる | 利用者の明示的な承認 |
| 6 | IaC を生成する | 検証がエラー 0 で、checkov の高・重大が 0 |
| 7 | デプロイする | 危険を承知したうえでの確認 |
第 6 段はコマンドの出力をそのまま見せる
第 6 段では、生成したコードが az bicep build か terraform validate をエラー 0 で通り、セキュリティ点検の checkov で高・重大の指摘が残っていないこと、さらにコマンドの出力をそのまま見せることが求められています。
「通しました」と言うだけでは先へ進めません。道具がどうしても無いときは、そう明言したうえで安全側の既定の一覧に照らして自分で見直す、という扱いです。
生成するコードの既定も決まっています。データ系のサービスは公開の入口を閉じてプライベート接続にし、認証はマネージド ID とロールの割り当てで行い、キーや接続文字列は使いません。TLS は 1.2 以上、Key Vault は論理削除と消去保護を有効にします。
既存の環境に足すときは、足すだけ
すでにある資源を渡した場合（既存のリソースグループや IaC）は、それを参照するだけで作り直さないと書かれています。第 7 段のデプロイも追加のみで、既存の資源を変えたり消したりしない決まりです。Bicep は増分モードに限り、--mode Complete は使いません（テンプレートに無い資源を消すため）。
使わないほうがいいとき
アプリを Azure に載せたいだけのとき
description の最後に「アプリ中心の流れなら azure-prepare を優先」と明記されています。こちらは基盤の設計者向けで、azd も使いません。
既存の構成を点検したいだけのとき
準拠の点検なら azure-compliance、デプロイ前の構成と権限の確認なら azure-validate のほうが目的に合います。
小さな構成
VNet を 1 つ作るだけ、のような作業に 7 段の関門は重すぎます。
注意点
第 7 段はシェルコマンドで実際にデプロイする
SKILL.md の解析では、シェルコマンドの実行の記述が見つかっています。本文の早見表に az deployment group create、terraform apply などが並んでいて、第 7 段はそれで実際にデプロイします。
第 7 段の確認は厳しめです。危険を示したあとの返事で、利用者が危険を承知したと述べない限り進みません。最初の依頼文に「デプロイまで」と書いてあっても、「はい」「進めて」だけの返事でも、関門は満たされないと書かれています。
外部通信の記述は見つかっていませんが、デプロイ自体が Azure への通信です。
同梱ファイルは 40 件
同梱ファイルは 40 件と多く、段ごとの手順、資源の分野ごとの手引き、組み合わせの制約（使えない SKU の組み合わせなど）、Well-Architected の確認表に分かれています。
費用が発生します
ファイアウォール、VPN ゲートウェイ、複数リージョンの構成はそれ自体が高価な資源です。
プロジェクトの中にファイルを書きます
.azure/insights.json、.azure/infrastructure-plan.json、infra/main.bicep（または infra/main.tf）と infra/modules/ です。
計画の状態は draft → approved → deployed と進み、承認されていない計画から IaC を作ろうとすると止める、と誤りの表に書かれています。
MCP の道具が無いときは同梱で代用します
道具の呼び出しが失敗したら 1 回だけやり直し、だめなら同梱ファイルに切り替えて利用者に知らせる、という扱いです。調べた結果の鮮度は下がります。
インストール数と組み合わせ
インストール数は約 40 万件です。同じリポジトリの 28 件は約 8 万〜57 万件に散っていて（2026-09-07 の上流集計）、全部まとめて入っている形ではありません。組で入れないと止まるものがあるので、Azure を任せる 28 件の地図で組み合わせを確かめてください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
azure-compliance
azqr で Azure の構成を点検させ、Key Vault の期限切れを先に見つけさせる
azure-deploy
準備済みの Azure プロジェクトに対して azd up や terraform apply を実行させ、失敗の復旧まで面倒を見させる
azure-prepare
Azure へのデプロイ用に、azure.yaml と Bicep/Terraform を作らせる。計画書を先に書かせる型つき
azure-validate
デプロイの前に構成と権限を点検させる。検証を通したことにして先へ進む抜け道を塞いである
よくある質問
azure-prepare とどちらを使えばいいですか
アプリを載せるなら azure-prepare、基盤を設計するならこちらです。description が「アプリ中心の流れなら azure-prepare を優先」と名指ししています。こちらは azd を使わず、Bicep か Terraform を直接書きます。
途中で止められますか
止められます。第 3 段で資源の一覧、第 5 段で計画の承認が無いと先に進まず、第 7 段も改めて確認を取ります。計画だけ欲しいなら、第 4 段で止めるよう最初に頼んでください。計画は .azure/infrastructure-plan.json に残ります。
既存の環境を壊しませんか
既存の資源を渡した場合、それを参照するだけで作り直さず、デプロイは追加だけ（変更・削除をしない）と本文に書かれています。本文はデプロイ前に what-if（変更の予告）か terraform plan を必ず流すとしています。その結果を自分でも見て確かめてください。
Bicep と Terraform はどちらになりますか
どちらも書けます。同梱に生成の手引きが両方あり（bicep-generation.md と
terraform-generation.md）、検証もそれぞれ az bicep build と terraform validate です。すでに使っているほうを最初に伝えてください。