Terraform on Azure 完全ガイド｜AzureRM/AzAPI Provider・State 管理・Module 設計・CI/CD 統合

Terraform on Azure は、HashiCorp 製のマルチクラウド IaC ツール Terraform を Azure リソース管理に使用する組み合わせです。 Bicep が Azure 専用 DSL なのに対し、Terraform はマルチクラウド対応 (3,000+ Provider) で既存資産活用・OSS コミュニティ強いという特徴。 本記事では、Provider 選定・State 管理・Module 設計・CI/CD 統合を網羅的に整理します。

Bicep vs Terraform の選定基準

新規 Azure 専用プロジェクトは Bicep、マルチクラウド / 既存 Terraform プロジェクトは Terraform、というのが現代の選定基準。

AzureRM Provider と AzAPI Provider

標準パターン: AzureRM Provider をベースとして使用、Preview 機能や最新追加リソースのみ AzAPI Provider で対応。両者は同一 Terraform プロジェクト内で混在可能。

Terraform State の管理

Terraform State はインフラの現在状態を JSON で記録したファイル、terraform plan / apply の基準。デフォルトはローカル、本番は必ずリモート Backend に保管。

Azure 標準パターン

• Azure Storage Account の Blob Container を Backend として使用
• State Lock (同時更新防止) を Blob Lease で実現
• State 暗号化 (Customer-Managed Key)
• Versioning + Soft Delete で誤削除対策
• Microsoft Entra ID 認証で State へのアクセス制御

Backend 設定例

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-tfstate"
    storage_account_name = "stgtfstate001"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
    use_oidc             = true
  }
}

Terraform Cloud (有料 SaaS) も Backend として利用可能で、より高度な State 管理を提供します。

Module 設計

Terraform Module は再利用可能な Terraform コードユニット。

推奨ディレクトリ構造

infra/
├── main.tf              # エントリポイント・Provider 設定
├── variables.tf         # 入力変数
├── outputs.tf           # 出力値
├── modules/
│   ├── network/         # VNet / NSG / Subnet
│   ├── compute/         # VM / App Service / AKS
│   ├── storage/         # Storage Account / Container
│   └── identity/        # Managed Identity / Key Vault
└── environments/
    ├── dev.tfvars
    ├── stage.tfvars
    └── prod.tfvars

Module 呼び出しの例

module "network" {
  source              = "./modules/network"
  vnet_name           = var.vnet_name
  address_space       = ["10.0.0.0/16"]
  location            = var.location
  resource_group_name = azurerm_resource_group.main.name
}

module "compute" {
  source              = "./modules/compute"
  vm_name             = var.vm_name
  subnet_id           = module.network.app_subnet_id
  resource_group_name = azurerm_resource_group.main.name
  depends_on          = [module.network]
}

Azure Verified Modules (AVM)

Azure Verified Modules (AVM、2024 GA) は Microsoft が品質保証する Terraform Module セットで、業界ベストプラクティス準拠の参考実装です。

• Microsoft 公式メンテナンス
• Well-Architected Framework 準拠
• セキュリティベースライン適用済み
• Terraform Registry で公開
• Bicep 版 AVM も提供

エンタープライズでは AVM を基礎にカスタマイズが定石。Module 化により大規模 IaC のメンテナンス性が劇的向上します。

Bicep との併用

両者は競合せず併用可能。代表的な併用パターン:

1. Azure 専用リソースは Bicep、マルチクラウド要件 (AWS RDS など) は Terraform
2. 新規開発は Bicep、既存 Terraform 資産は維持
3. Microsoft の最新機能 (Preview 含む) は Bicep / AzAPI、安定機能は Terraform AzureRM

CI/CD パイプライン併用例

• Stage 1: Bicep で Hub VNet 構築
• Stage 2: Terraform で AWS リソース + AKS
• Stage 3: Bicep で Azure SaaS 構成

Drift Detection

Drift Detection は、Terraform State と実際の Azure リソース状態の差分を検出する操作。Azure Portal や CLI でリソースが手動変更された場合、State と乖離が発生、次回 terraform apply で意図しない変更が発生するリスク。

対応コマンド

• terraform plan -refresh-only: State を最新リソースに合わせて更新
• terraform apply -refresh-only: 差分適用
• terraform import: 新規リソースを State に取り込み

定期的な Drift Detection を CI/CD パイプラインに組み込む (週次など) ことで、手動変更の早期発見が可能。Azure Policy の Deny Effect で手動変更そのものを禁止する組み合わせがエンタープライズの標準パターンです。

GitHub Actions / Azure Pipelines への統合

標準パターン

1. Lint: terraform fmt -check + terraform validate
2. Init: Backend 接続
3. Plan: terraform plan -out=tfplan、変更内容予測
4. Manual Approval (Production の場合)
5. Apply: terraform apply tfplan

GitHub Actions の例

name: Terraform Apply
on:
  push:
    branches: [main]

jobs:
  terraform:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: terraform init
      - run: terraform plan -out=tfplan
      - run: terraform apply tfplan

OIDC / Workload Identity Federation で AzureRM Provider 認証 (Secret 不要)、Backend 認証も同様。Pull Request 時に Plan 結果を PR コメントに自動投稿する Pattern も標準実装。

運用ベストプラクティス

1. State は必ず Azure Storage Backend に保管 (ローカル State 禁止)
2. State Lock + Versioning + Soft Delete で誤削除対策
3. Module 化で再利用性確保 (AVM 活用)
4. 環境別 tfvars で構成分離
5. OIDC / WIF で Secret 不要認証
6. CI/CD パイプラインに Plan → Approval → Apply を組み込み
7. 定期 Drift Detection で手動変更検知
8. Azure Policy で手動変更禁止
9. Pull Request 時の Plan 結果を PR コメント自動投稿
10. Provider バージョン固定 (terraform.tf で required_version + required_providers)

関連認定試験

• AZ-400 (DevOps Engineer Expert): ドメイン 3 で深く問われる本領域の本命認定
• AZ-104 (Administrator): IaC 基礎
• AZ-305 (Solutions Architect Expert): アーキテクト視点での IaC 戦略選定
• Microsoft 外: HashiCorp Certified: Terraform Associate (ベンダ中立)

よくある質問

本記事の技術情報は AzureRM Provider Documentation およびMicrosoft Terraform on Azure Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure は Microsoft group of companies の商標です。Terraform は HashiCorp の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。