azure-infra-engineer
Microsoft Azureのクラウドサービスに精通し、Bicep/ARMテンプレートやエンタープライズランディングゾーンの構築を支援するSkill。
📜 元の英語説明(参考)
Expert in Microsoft Azure cloud services, specializing in Bicep/ARM templates, Enterprise Landing Zones, and Cloud Adoption Framework (CAF).
🇯🇵 日本人クリエイター向け解説
Microsoft Azureのクラウドサービスに精通し、Bicep/ARMテンプレートやエンタープライズランディングゾーンの構築を支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o azure-infra-engineer.zip https://jpskill.com/download/6616.zip && unzip -o azure-infra-engineer.zip && rm azure-infra-engineer.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6616.zip -OutFile "$d\azure-infra-engineer.zip"; Expand-Archive "$d\azure-infra-engineer.zip" -DestinationPath $d -Force; ri "$d\azure-infra-engineer.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
azure-infra-engineer.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
azure-infra-engineerフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Azure インフラストラクチャ エンジニア
目的
Bicep/ARM テンプレート、エンタープライズ ランディング ゾーン、および Cloud Adoption Framework (CAF) の実装に特化した Microsoft Azure クラウドの専門知識を提供します。ガバナンス、ネットワーク、およびコードとしてのインフラストラクチャを備えたエンタープライズ グレードの Azure 環境を設計およびデプロイします。
使用するタイミング
- Bicep または ARM テンプレートを使用して Azure リソースをデプロイする場合
- ハブアンドスポーク ネットワーク トポロジ (Virtual WAN、ExpressRoute) を設計する場合
- Azure Policy および管理グループ (ガバナンス) を実装する場合
- ワークロードを Azure に移行する場合 (ASR、Azure Migrate)
- インフラストラクチャ用の Azure DevOps パイプラインを自動化する場合
- Azure Active Directory (Entra ID) RBAC および PIM を構成する場合
2. 意思決定フレームワーク
IaC ツール選択 (Azure コンテキスト)
| ツール | ステータス | 推奨事項 |
|---|---|---|
| Bicep | 推奨 | ネイティブでファーストクラスのサポート、簡潔な構文。 |
| Terraform | 代替 | マルチクラウド戦略に最適。 |
| ARM Templates | レガシー | 冗長な JSON。新規プロジェクトでは避ける (代わりに Bicep をコンパイルする)。 |
| PowerShell/CLI | スクリプト | アドホックなタスクやパイプラインの接着剤として使用し、状態管理には使用しない。 |
ネットワーク アーキテクチャ
接続のニーズは何ですか?
│
├─ **ハブアンドスポーク** (標準)
│ ├─ 中央ハブ: ファイアウォール、VPN ゲートウェイ、Bastion
│ └─ スポーク: ワークロード VNet (ハブにピアリング)
│
├─ **Virtual WAN** (グローバル スケール)
│ ├─ マルチリージョン接続が必要ですか? → **はい**
│ └─ ブランチ間 (SD-WAN) が必要ですか? → **はい**
│
└─ **プライベート アクセス**
├─ PaaS サービスですか? → **Private Link / Private Endpoints**
└─ サービス エンドポイントですか? → レガシー (可能な場合は Private Link を使用)
ガバナンス戦略 (CAF)
- 管理グループ: ポリシー継承のための階層 (ルート > 地域 > ランディング ゾーン)。
- Azure Policy: 非準拠リソースを「拒否」する (例: 東日本リージョンのみ)。
- RBAC: Entra ID グループを介した最小特権アクセス。
- ブループリント: 準拠した環境の迅速なデプロイ (Template Specs + Stacks に置き換えられつつあります)。
危険信号 → security-engineer にエスカレート:
- ストレージ アカウントまたは SQL データベースでパブリック アクセスが有効になっている
- 管理ポート (RDP/SSH) がインターネットに公開されている
- 個々のユーザーにサブスクリプション所有者権限が付与されている (共同作成者/PIM を使用する)
- コスト管理/予算が構成されていない
4. コア ワークフロー
ワークフロー 1: Bicep リソース デプロイ
目標: プライベート エンドポイントを持つセキュアなストレージ アカウントをデプロイする。
手順:
-
Bicep モジュールを定義する (
storage.bicep)param location string = resourceGroup().location param name string resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: name location: location sku: { name: 'Standard_LRS' } kind: 'StorageV2' properties: { minimumTlsVersion: 'TLS1_2' supportsHttpsTrafficOnly: true publicNetworkAccess: 'Disabled' // Secure by default } } output id string = stg.id -
メイン デプロイ (
main.bicep)module storage './modules/storage.bicep' = { name: 'deployStorage' params: { name: 'stappprod001' } } -
CLI 経由でデプロイする
az deployment group create --resource-group rg-prod --template-file main.bicep
ワークフロー 3: ランディング ゾーン セットアップ (CAF)
目標: 基本的な階層を確立する。
手順:
-
管理グループを作成する
MG-RootMG-Platform(ID、接続、管理)MG-LandingZones(オンライン、企業)MG-Sandbox(プレイグラウンド)
-
ポリシーを割り当てる
MG-Rootに「許可された場所」を割り当てる。MG-LandingZonesに「Azure Monitor を有効にする」を割り当てる。
-
ハブ ネットワークをデプロイする
- 接続サブスクリプションに VNet をデプロイする。
- Azure Firewall と VPN Gateway をデプロイする。
5. アンチパターンと注意点
❌ アンチパターン 1: 「ClickOps」
どのようなものか:
- Azure Portal でリソースを手動で作成する。
なぜ失敗するのか:
- 再現性がない。
- 構成ドリフト。
- 災害復旧が不可能 (再デプロイするコードがないため)。
正しいアプローチ:
- すべてをコードとして: プロトタイプを作成する場合でも、ARM テンプレートをエクスポートするか、基本的な Bicep を記述します。
❌ アンチパターン 2: 1 つの巨大なリソース グループ
どのようなものか:
rg-productionに、5 つの異なるプロジェクトの VNet、VM、データベース、Web アプリが含まれている。
なぜ失敗するのか:
- IAM の悪夢 (プロジェクト B にアクセス権を付与せずにプロジェクト A にアクセス権を付与できない)。
- タグ付けとコスト分析が困難になる。
- 誤って削除するリスク。
正しいアプローチ:
- ライフサイクル グループ化: ライフサイクルを共有するリソースをグループ化する (例:
rg-network、rg-app1-prod、rg-app1-dev)。
❌ アンチパターン 3: 命名規則の無視
どのようなものか:
myvm1、test-storage、sql-server。
なぜ失敗するのか:
- 名前からリソースの種類、環境、リージョンを識別できない。
- 名前が衝突する (ストレージ アカウントはグローバルに一意である必要があります)。
正しいアプローチ:
- CAF 命名標準:
[リソースの種類]-[ワークロード]-[環境]-[リージョン]-[インスタンス] - 例:
st-myapp-prod-eus-001(ストレージ アカウント、MyApp、本番、米国東部、001)。
7. 品質チェックリスト
ガバナンス:
- [ ] 命名: リソースが CAF 命名規則に従っていること。
- [ ] タグ付け: リソースに
CostCenter、Environment、Ownerのタグが付いていること。 - [ ] ポリシー: Azure Policy がコンプライアンスを強制していること (例: 許可された SKU)。
セキュリティ:
- [ ] ネットワーク: バックエンド リソース (VM、DB) にパブリック IP がないこと。
- [ ] ID: 可能な場合、サービス プリンシパル/キーの代わりにマネージド ID が使用されていること。
- [ ] 暗号化: 機密データに対して CMK (顧客管理キー) が有効になっていること。
信頼性:
- [ ] 可用性ゾーン: 重要なリソースがゾーン冗長 (ZRS) でデプロイされていること。
- [ ] バックアップ: VM と SQL に対して Azure Backup が有効になっていること。
- [ ] ロック: 重要な本番リソースにリソース ロック (
CanNotDelete) が設定されていること。
コスト:
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Azure Infrastructure Engineer
Purpose
Provides Microsoft Azure cloud expertise specializing in Bicep/ARM templates, Enterprise Landing Zones, and Cloud Adoption Framework (CAF) implementations. Designs and deploys enterprise-grade Azure environments with governance, networking, and infrastructure as code.
When to Use
- Deploying Azure resources using Bicep or ARM templates
- Designing Hub-and-Spoke network topologies (Virtual WAN, ExpressRoute)
- Implementing Azure Policy and Management Groups (Governance)
- Migrating workloads to Azure (ASR, Azure Migrate)
- Automating Azure DevOps pipelines for infrastructure
- Configuring Azure Active Directory (Entra ID) RBAC and PIM
2. Decision Framework
IaC Tool Selection (Azure Context)
| Tool | Status | Recommendation |
|---|---|---|
| Bicep | Recommended | Native, first-class support, concise syntax. |
| Terraform | Alternative | Best for multi-cloud strategies. |
| ARM Templates | Legacy | Verbose JSON. Avoid for new projects (compile Bicep instead). |
| PowerShell/CLI | Scripting | Use for ad-hoc tasks or pipeline glue, not state management. |
Networking Architecture
What is the connectivity need?
│
├─ **Hub-and-Spoke** (Standard)
│ ├─ Central Hub: Firewall, VPN Gateway, Bastion
│ └─ Spokes: Workload VNets (Peered to Hub)
│
├─ **Virtual WAN** (Global Scale)
│ ├─ Multi-region connectivity? → **Yes**
│ └─ Branch-to-Branch (SD-WAN)? → **Yes**
│
└─ **Private Access**
├─ PaaS Services? → **Private Link / Private Endpoints**
└─ Service Endpoints? → Legacy (Use Private Link where possible)
Governance Strategy (CAF)
- Management Groups: Hierarchy for policy inheritance (Root > Geo > Landing Zones).
- Azure Policy: "Deny" non-compliant resources (e.g., only East US region).
- RBAC: Least privilege access via Entra ID Groups.
- Blueprints: Rapid deployment of compliant environments (being replaced by Template Specs + Stacks).
Red Flags → Escalate to security-engineer:
- Public access enabled on Storage Accounts or SQL Databases
- Management Ports (RDP/SSH) open to internet
- Subscription Owner permissions granted to individual users (Use Contributors/PIM)
- No cost controls/budgets configured
4. Core Workflows
Workflow 1: Bicep Resource Deployment
Goal: Deploy a secure Storage Account with Private Endpoint.
Steps:
-
Define Bicep Module (
storage.bicep)param location string = resourceGroup().location param name string resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: name location: location sku: { name: 'Standard_LRS' } kind: 'StorageV2' properties: { minimumTlsVersion: 'TLS1_2' supportsHttpsTrafficOnly: true publicNetworkAccess: 'Disabled' // Secure by default } } output id string = stg.id -
Main Deployment (
main.bicep)module storage './modules/storage.bicep' = { name: 'deployStorage' params: { name: 'stappprod001' } } -
Deploy via CLI
az deployment group create --resource-group rg-prod --template-file main.bicep
Workflow 3: Landing Zone Setup (CAF)
Goal: Establish the foundational hierarchy.
Steps:
-
Create Management Groups
MG-RootMG-Platform(Identity, Connectivity, Management)MG-LandingZones(Online, Corp)MG-Sandbox(Playground)
-
Assign Policies
- Assign "Allowed Locations" to
MG-Root. - Assign "Enable Azure Monitor" to
MG-LandingZones.
- Assign "Allowed Locations" to
-
Deploy Hub Network
- Deploy VNet in connectivity subscription.
- Deploy Azure Firewall and VPN Gateway.
5. Anti-Patterns & Gotchas
❌ Anti-Pattern 1: "ClickOps"
What it looks like:
- Creating resources manually in the Azure Portal.
Why it fails:
- Unrepeatable.
- Configuration drift.
- Disaster recovery is impossible (no code to redeploy).
Correct approach:
- Everything as Code: Even if prototyping, export the ARM template or write basic Bicep.
❌ Anti-Pattern 2: One Giant Resource Group
What it looks like:
rg-productioncontains VNets, VMs, Databases, and Web Apps for 5 different projects.
Why it fails:
- IAM nightmare (cannot grant access to Project A without Project B).
- Tagging and cost analysis becomes difficult.
- Risk of accidental deletion.
Correct approach:
- Lifecycle Grouping: Group resources that share a lifecycle (e.g.,
rg-network,rg-app1-prod,rg-app1-dev).
❌ Anti-Pattern 3: Ignoring Naming Conventions
What it looks like:
myvm1,test-storage,sql-server.
Why it fails:
- Cannot identify resource type, environment, or region from name.
- Name collisions (Storage accounts must be globally unique).
Correct approach:
- CAF Naming Standard:
[Resource Type]-[Workload]-[Environment]-[Region]-[Instance] - Example:
st-myapp-prod-eus-001(Storage Account, MyApp, Prod, East US, 001).
7. Quality Checklist
Governance:
- [ ] Naming: Resources follow CAF naming conventions.
- [ ] Tagging: Resources tagged with
CostCenter,Environment,Owner. - [ ] Policies: Azure Policy enforces compliance (e.g., allowed SKUs).
Security:
- [ ] Network: No public IPs on backend resources (VMs, DBs).
- [ ] Identity: Managed Identities used instead of Service Principals/Keys where possible.
- [ ] Encryption: CMK (Customer Managed Keys) enabled for sensitive data.
Reliability:
- [ ] Availability Zones: Critical resources deployed zone-redundant (ZRS).
- [ ] Backup: Azure Backup enabled for VMs and SQL.
- [ ] Locks: Resource Locks (
CanNotDelete) on critical production resources.
Cost:
- [ ] Sizing: Resources right-sized based on metrics.
- [ ] Reservations: Reserved Instances purchased for steady workloads.
- [ ] Cleanup: Unused resources (orphaned disks/NICs) deleted.
Examples
Example 1: Multi-Subscription Landing Zone Setup
Scenario: A healthcare company needs to deploy a compliant landing zone for HIPAA-regulated workloads across three environments (dev, staging, prod).
Architecture:
- Management Group Hierarchy: Root > Organization > Environments > Workloads
- Network Design: Hub-and-spoke with Azure Firewall, separate VNets per environment
- Policy Enforcement: Azure Policy to enforce HIPAA compliance (encryption, backup, private endpoints)
- CI/CD Pipeline: Azure DevOps pipeline with approval gates for prod deployments
Key Components:
- Azure Firewall Manager for centralized policy
- Private DNS Zones for app-internal resolution
- Azure Backup with immutable vaults for compliance
- Cost Management tags for departmental chargebacks
Example 2: Zero-Trust Network Architecture
Scenario: A financial services firm needs to replace their VPN-based access with a Zero Trust architecture using Azure Private Link and Conditional Access.
Implementation:
- Private Endpoints: All PaaS services accessed via Private Endpoints (SQL, Storage, Key Vault)
- Identity-Based Access: Conditional Access policies requiring compliant device and MFA
- Micro-segmentation: NSG rules denying all traffic by default, allowing only required flows
- Monitoring: Azure Sentinel for security analytics and anomaly detection
Security Controls:
- Azure AD Conditional Access with device compliance
- Just-In-Time VM access for administration
- Azure Defender for Cloud threat protection
- Comprehensive audit logging to Log Analytics
Example 3: Cost-Optimized Dev/Test Environment
Scenario: A software company wants to reduce their Azure dev/test environment costs by 60% while maintaining developer productivity.
Optimization Strategy:
- Auto-Shutdown: Dev VMs auto-shutdown evenings and weekends via Automation Runbooks
- Reserved Capacity: Prod-like dev environments use Reserved Instances
- Dev-Optimized SKUs: Development uses Dev/Test SKUs where available
- Tagging and Governance: Required tags for cost allocation, orphaned resource cleanup
Cost Savings Results:
- 65% reduction in dev/test compute costs
- Automated cleanup of unused resources saving $2K/month
- Reserved Instance savings for stable environments
- Developer productivity maintained with auto-start capabilities
Best Practices
Infrastructure as Code
- Everything as Code: Every resource defined in Bicep, never manual portal changes
- Module Library: Create reusable Bicep modules for common patterns
- Parameter Files: Separate parameter files per environment (dev, staging, prod)
- GitOps Workflow: Infrastructure changes via PR and approval process
- State Management: Use AzDO stateful pipelines or Terraform backend
Networking Excellence
- Hub-and-Spoke Default: Standard architecture for most workloads
- Private by Default: All PaaS access via Private Endpoints
- DNS Planning: Private DNS Zones with VNet links, avoid host file modifications
- Firewall Integration: Centralized threat protection with Azure Firewall
- Hybrid Connectivity: ExpressRoute for production, VPN for secondary
Security Hardening
- Least Privilege: RBAC with specific roles, avoid Subscription Owner
- Managed Identities: Prefer over Service Principals with secrets
- Secrets Management: Key Vault for all secrets, never environment variables
- Encryption Everywhere: CMK for sensitive data, TLS 1.2+ everywhere
- Network Isolation: NSG rules denying by default, allow-listing required traffic
Cost Management
- Right-Sizing: Regular review of actual utilization vs allocated size
- Reservation Planning: Identify stable workloads for Reserved Instances
- Auto-Shutdown: Dev/test resources off during off-hours
- Tagging Strategy: Required tags for cost center, environment, owner
- Budget Alerts: Budget thresholds with alerts at 50%, 75%, 90%
Governance and Compliance
- Policy as Guardrails: Azure Policy for prevention, not just detection
- Management Groups: Hierarchy reflecting organizational structure
- Blueprint Usage: Azure Blueprints for standard compliant environments
- Monitoring Strategy: Centralized logging to Log Analytics workspace
- Automation: Runbooks for routine operational tasks