---
description: 'Azure用の現代的なTerraformコード生成のガイドライン'
applyTo: '**/*.tf'
---

## 1. 最新のTerraformとプロバイダーを使用

常に最新の安定版TerraformとAzureプロバイダーをターゲットにします。コードでは、必要なTerraformとプロバイダーのバージョンを指定してこれを強制します。新機能と修正を取得するため、プロバイダーバージョンを最新に保ちます。

## 2. コードを整理する

論理的なファイル分離でTerraform設定を構造化します：

- リソース用に`main.tf`を使用
- 入力用に`variables.tf`を使用
- 出力用に`outputs.tf`を使用
- 一貫した命名規則とフォーマット（`terraform fmt`）に従う

これにより、コードのナビゲートと保守が容易になります。

## 3. モジュールでカプセル化

再利用可能なインフラコンポーネントをグループ化するためにTerraformモジュールを使用します。複数のコンテキストで使用されるリソースセットに対しては：

- 独自の変数/出力を持つモジュールを作成
- コードの重複ではなくそれを参照
- これにより再利用性と一貫性が促進される

## 4. 変数と出力を活用

- すべての設定可能な値を型と説明を持つ変数を使用して**パラメータ化**
- オプション変数について適切な場合は**デフォルト値を提供**
- 他のモジュールやユーザー参照のため、キーリソース属性を公開するために**出力を使用**
- シークレットを保護するため、**機密値を適切にマーク**

## 5. プロバイダーの選択（AzureRM対AzAPI）

- ほとんどのシナリオでは**`azurerm`プロバイダーを使用** – 高い安定性を提供し、Azureサービスの大部分をカバー
- **`azapi`プロバイダーは**以下が必要な場合のみ使用：
  - 最新のAzure機能
  - `azurerm`でまだサポートされていないリソース
- コードコメントで**選択を文書化**
- 必要に応じて両方のプロバイダーを一緒に使用できるが、疑わしい場合は`azurerm`を優先

## 6. 最小限の依存関係

- プロジェクトの範囲を超えて確認なしに追加のプロバイダーやモジュールを**導入しない**
- 特別なプロバイダー（例：`random`、`tls`）や外部モジュールが必要な場合：
  - 説明するためのコメントを追加
  - ユーザーの承認を確保
- インフラストラクチャスタックを軽量に保ち、不要な複雑さを避ける

## 7. 冪等性を確保

- 同じ結果で繰り返し適用できる設定を作成
- **非冪等アクションを避ける**：
  - すべての適用で実行されるスクリプト
  - 二度作成されると競合する可能性があるリソース
- **複数の`terraform apply`実行によってテスト**し、2回目の実行がゼロ変更となることを確保
- ドリフトや外部変更を適切に処理するため、リソースライフサイクル設定や条件式を使用

## 8. 状態管理

- Terraform状態を安全に保存するために**リモートバックエンド**（状態ロック付きのAzure Storageなど）を使用
- チームコラボレーションを有効にする
- **状態ファイルをソース管理にコミットしない**
- これにより競合を防ぎ、インフラストラクチャ状態を一貫して保つ

## 9. ドキュメント化と図表化

- **最新のドキュメントを維持**
- コードが変更されるたびに新しい変数、出力、使用方法の指示で**README.mdを更新**
- 自動化のため`terraform-docs`のようなツールの使用を検討
- 各重要な更新後にインフラストラクチャ変更を反映するため**アーキテクチャ図を更新**
- よく文書化されたコードと図表により、チーム全体がインフラストラクチャを理解できる

## 10. 変更の検証とテスト

- 変更を適用する前に**`terraform validate`を実行**し、`terraform plan`出力をレビュー
- エラーや意図しない変更を早期に捕捉
- **自動チェックの実装を検討**：
  - CIパイプライン
  - プレコミットフック
  - フォーマット、リンティング、基本検証を強制