jpskill.com
🛠️ 開発・MCP コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して azure-infra-engineer.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → azure-infra-engineer フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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)

  1. 管理グループ: ポリシー継承のための階層 (ルート > 地域 > ランディング ゾーン)。
  2. Azure Policy: 非準拠リソースを「拒否」する (例: 東日本リージョンのみ)。
  3. RBAC: Entra ID グループを介した最小特権アクセス。
  4. ブループリント: 準拠した環境の迅速なデプロイ (Template Specs + Stacks に置き換えられつつあります)。

危険信号 → security-engineer にエスカレート:

  • ストレージ アカウントまたは SQL データベースでパブリック アクセスが有効になっている
  • 管理ポート (RDP/SSH) がインターネットに公開されている
  • 個々のユーザーにサブスクリプション所有者権限が付与されている (共同作成者/PIM を使用する)
  • コスト管理/予算が構成されていない


4. コア ワークフロー

ワークフロー 1: Bicep リソース デプロイ

目標: プライベート エンドポイントを持つセキュアなストレージ アカウントをデプロイする。

手順:

  1. 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
  2. メイン デプロイ (main.bicep)

    module storage './modules/storage.bicep' = {
      name: 'deployStorage'
      params: {
        name: 'stappprod001'
      }
    }
  3. CLI 経由でデプロイする

    az deployment group create --resource-group rg-prod --template-file main.bicep


ワークフロー 3: ランディング ゾーン セットアップ (CAF)

目標: 基本的な階層を確立する。

手順:

  1. 管理グループを作成する

    • MG-Root
      • MG-Platform (ID、接続、管理)
      • MG-LandingZones (オンライン、企業)
      • MG-Sandbox (プレイグラウンド)
  2. ポリシーを割り当てる

    • MG-Root に「許可された場所」を割り当てる。
    • MG-LandingZones に「Azure Monitor を有効にする」を割り当てる。
  3. ハブ ネットワークをデプロイする

    • 接続サブスクリプションに VNet をデプロイする。
    • Azure Firewall と VPN Gateway をデプロイする。


5. アンチパターンと注意点

❌ アンチパターン 1: 「ClickOps」

どのようなものか:

  • Azure Portal でリソースを手動で作成する。

なぜ失敗するのか:

  • 再現性がない。
  • 構成ドリフト。
  • 災害復旧が不可能 (再デプロイするコードがないため)。

正しいアプローチ:

  • すべてをコードとして: プロトタイプを作成する場合でも、ARM テンプレートをエクスポートするか、基本的な Bicep を記述します。

❌ アンチパターン 2: 1 つの巨大なリソース グループ

どのようなものか:

  • rg-production に、5 つの異なるプロジェクトの VNet、VM、データベース、Web アプリが含まれている。

なぜ失敗するのか:

  • IAM の悪夢 (プロジェクト B にアクセス権を付与せずにプロジェクト A にアクセス権を付与できない)。
  • タグ付けとコスト分析が困難になる。
  • 誤って削除するリスク。

正しいアプローチ:

  • ライフサイクル グループ化: ライフサイクルを共有するリソースをグループ化する (例: rg-networkrg-app1-prodrg-app1-dev)。

❌ アンチパターン 3: 命名規則の無視

どのようなものか:

  • myvm1test-storagesql-server

なぜ失敗するのか:

  • 名前からリソースの種類、環境、リージョンを識別できない。
  • 名前が衝突する (ストレージ アカウントはグローバルに一意である必要があります)。

正しいアプローチ:

  • CAF 命名標準: [リソースの種類]-[ワークロード]-[環境]-[リージョン]-[インスタンス]
  • 例: st-myapp-prod-eus-001 (ストレージ アカウント、MyApp、本番、米国東部、001)。


7. 品質チェックリスト

ガバナンス:

  • [ ] 命名: リソースが CAF 命名規則に従っていること。
  • [ ] タグ付け: リソースに CostCenterEnvironmentOwner のタグが付いていること。
  • [ ] ポリシー: 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)

  1. Management Groups: Hierarchy for policy inheritance (Root > Geo > Landing Zones).
  2. Azure Policy: "Deny" non-compliant resources (e.g., only East US region).
  3. RBAC: Least privilege access via Entra ID Groups.
  4. 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:

  1. 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
  2. Main Deployment (main.bicep)

    module storage './modules/storage.bicep' = {
      name: 'deployStorage'
      params: {
        name: 'stappprod001'
      }
    }
  3. 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:

  1. Create Management Groups

    • MG-Root
      • MG-Platform (Identity, Connectivity, Management)
      • MG-LandingZones (Online, Corp)
      • MG-Sandbox (Playground)
  2. Assign Policies

    • Assign "Allowed Locations" to MG-Root.
    • Assign "Enable Azure Monitor" to MG-LandingZones.
  3. 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-production contains 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:

  1. Management Group Hierarchy: Root > Organization > Environments > Workloads
  2. Network Design: Hub-and-spoke with Azure Firewall, separate VNets per environment
  3. Policy Enforcement: Azure Policy to enforce HIPAA compliance (encryption, backup, private endpoints)
  4. 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:

  1. Private Endpoints: All PaaS services accessed via Private Endpoints (SQL, Storage, Key Vault)
  2. Identity-Based Access: Conditional Access policies requiring compliant device and MFA
  3. Micro-segmentation: NSG rules denying all traffic by default, allowing only required flows
  4. 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:

  1. Auto-Shutdown: Dev VMs auto-shutdown evenings and weekends via Automation Runbooks
  2. Reserved Capacity: Prod-like dev environments use Reserved Instances
  3. Dev-Optimized SKUs: Development uses Dev/Test SKUs where available
  4. 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