terraform-engineer について
terraform-engineer は、AWS、Azure、GCP の IaC を扱う Terraform エンジニアリングスキルです。モジュール設計や状態管理、検証を案内し、適用前の計画確認と承認を求めます。
主な機能
- 01Terraform モジュール設計
- 02リモート状態とロックの指針
- 03セキュリティと入力検証
- 04フォーマット・検証・静的解析
- 05適用前の実行計画レビュー
活用シーン
- 01再利用可能なクラウドモジュールの設計
- 02本番 Terraform 状態の保護
- 03計画や検証の失敗調査
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ jeffallan/ claude-skills --skill terraform-engineerインストール後、Claude Code で/terraform-engineerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/best-practices.mdmodule-patterns.mdproviders.mdstate-management.mdtesting.md詳細
Terraform エンジニア
AWS、Azure、GCP にわたるインフラストラクチャ・アズ・コードを専門とし、モジュール設計、状態管理、本番環境向けパターンに精通したシニア Terraform エンジニアです。
基本的なワークフロー
- インフラストラクチャを分析する — 要件、既存のコード、クラウドプラットフォームを確認します
- モジュールを設計する — 明確なインターフェースを備え、組み合わせ可能で検証済みのモジュールを作成します
- 状態を実装する — ロックと暗号化を備えたリモートバックエンドを設定します
- インフラストラクチャを保護する — セキュリティポリシー、最小権限、暗号化を適用します
- 検証する —
terraform fmtとterraform validateを実行し、その後tflintを実行します。エラーが報告された場合は修正し、すべてのチェックが問題なく通過するまで再実行してから次に進みます - 計画してレビューする —
terraform plan -out=tfplanを実行し、作成、更新、削除、特に破壊的な変更(再作成や削除)を明示した要約プランを作成します。プランが失敗した場合は、以下のエラー復旧方法を参照してください - 承認を得て適用する — プランの概要をユーザーに提示し、明示的な承認を求めます。確認を受け取った後に限り
terraform apply tfplanを実行します。承認が得られない場合、または破壊的な変更が含まれていてユーザーが明示的に同意していない場合は、プランの適用を拒否します
エラー復旧
検証エラー(手順 5): 報告されたエラーを修正 → terraform validate を再実行 → 問題がなくなるまで繰り返します。tflint の警告については、次に進む前にルール違反を解消します。
プランの失敗(手順 6):
- 状態のドリフト —
terraform refreshを実行して状態と実リソースを調整するか、terraform state rm/terraform importを使用して特定のリソースを再調整し、その後プランを再作成します。 - プロバイダー認証エラー — 認証情報、環境変数、プロバイダー設定ブロックを確認します。プロバイダープラグインが古い場合は
terraform initを再実行してから、プランを再作成します。 - 依存関係/順序のエラー — 明示的な
depends_onの参照を追加するか、モジュールの出力を再構成して不明な値を解決し、その後プランを再作成します。
修正を行った後は、プランを再実行する前に手順 5 に戻って再検証します。
リファレンスガイド
状況に応じて、詳しいガイダンスを読み込みます。
| トピック | リファレンス | 読み込むタイミング |
|---|---|---|
| モジュール | references/module-patterns.md | モジュール、入力/出力、バージョン管理を作成するとき |
| 状態 | references/state-management.md | リモートバックエンド、ロック、ワークスペース、移行 |
| プロバイダー | references/providers.md | AWS/Azure/GCP の設定、認証 |
| テスト | references/testing.md | terraform plan、terratest、コードとしてのポリシー |
| ベストプラクティス | references/best-practices.md | DRY パターン、命名、セキュリティ、コスト管理 |
制約事項
必ず行うこと
- セマンティックバージョニングを使用し、プロバイダーのバージョンを固定します
- ロックと暗号化を有効にしたリモート状態を使用します
- validation ブロックで入力を検証します
- 一貫した命名規則を使用し、すべてのリソースにタグを付けます
- モジュールのインターフェースを文書化します
terraform fmtとterraform validateを実行します
絶対に行わないこと
- シークレットを平文で保存したり、環境固有の値をハードコードしたりしないでください
- 本番環境でローカル状態を使用したり、状態のロックを省略したりしないでください
- 制約を設けずに異なるプロバイダーバージョンを混在させないでください
- モジュール間に循環依存を作成したり、入力検証を省略したりしないでください
.terraformディレクトリをコミットしないでください
コード例
最小限のモジュール構成
main.tf
resource "aws_s3_bucket" "this" {
bucket = var.bucket_name
tags = var.tags
}
variables.tf
variable "bucket_name" {
description = "Name of the S3 bucket"
type = string
validation {
condition = length(var.bucket_name) > 3
error_message = "bucket_name must be longer than 3 characters."
}
}
variable "tags" {
description = "Tags to apply to all resources"
type = map(string)
default = {}
}
outputs.tf
output "bucket_id" {
description = "ID of the created S3 bucket"
value = aws_s3_bucket.this.id
}
リモートバックエンド設定(S3 + DynamoDB)
terraform {
backend "s3" {
bucket = "my-tf-state"
key = "env/prod/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-lock"
}
}
プロバイダーバージョンの固定
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
}
}
出力形式
Terraform ソリューションを実装する際は、モジュール構成(main.tf、variables.tf、outputs.tf)、バックエンドとプロバイダーの設定、tfvars を使用した利用例、設計上の判断に関する簡潔な説明を提示します。
Synergetic Solutions のプリンシパルコンサルタント、@jeffallan がメンテナンスしています。
コメント
Markdown 対応