Terraformでインフラコード化した全手順【IaC導入の実例】
記事作成日: 2025年11月
最終更新: 2025年11月9日(Terraform 1.6+ BSLライセンス、2024年最新プラクティス反映)

この記事で得られること

- Terraform導入の全プロセス(実例ベース)
- IaC化で運用工数70%削減した方法
- State管理のベストプラクティス(2025年版)
- Terraform 1.6以降のBSLライセンス対応
- 失敗から学んだセキュリティ対策
対象: インフラエンジニア、SRE、DevOpsエンジニア、情報システム部門
成果サマリー

プロジェクト規模: AWS 80リソース、3環境(dev/staging/prod)
導入期間: 半年程度
効果:
- 環境構築時間: 2週間 → 30分(96%削減)
- インフラ変更ミス: 月8件 → 0件
- 運用工数: 週20時間 → 6時間(70%削減)
- ドキュメント作成時間: ゼロ(コードがドキュメント)
Terraform最新状況(2025年)

ライセンス変更の影響(重要)
2023年8月: HashiCorp、Terraform v1.6.0以降を BSL(Business Source License) に変更
影響:
- 個人・企業での利用: 問題なし
- 競合サービスでの利用: 制限あり
- OpenTofu: MPL 2.0のオープンソースフォーク登場
対応策:
- v1.5系の継続利用
- OpenTofuへの移行検討
- BSLライセンスの範囲内で利用(ほとんどの企業は問題なし)
バージョン推奨(2025年11月)
- Terraform: v1.9.x(最新安定版)
- AWS Provider: v5.70+
- 推奨: 定期的なアップデート(四半期ごと)
Terraform導入の全6ステップ
ステップ1: 現状分析と目標設定(Week 1-2)
実施内容:
- 既存インフラの棚卸し(AWS 80リソース)
- 管理対象の優先順位付け
- チーム体制の確認(2名のインフラエンジニア)
優先順位:
- Priority 1: VPC、セキュリティグループ(基盤)
- Priority 2: EC2、RDS(主要サービス)
- Priority 3: Lambda、CloudFront(付随サービス)
ステップ2: ディレクトリ構成とベストプラクティス設計(Week 3-4)

採用した構成:
terraform/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── terraform.tfvars
│ │ └── backend.tf
│ ├── staging/
│ └── prod/
├── modules/
│ ├── vpc/
│ ├── ec2/
│ ├── rds/
│ └── s3/
├── .terraform-version # tfenvで管理
└── README.md
State管理:
- S3バックエンド + DynamoDBロック
- 環境ごとに別State(dev/staging/prod)
- バージョニング有効化
- 暗号化必須
ステップ3: 段階的なTerraform化(Week 5-12)
Phase 1: 新規リソースをTerraformで作成(Week 5-6)
Phase 2: 既存リソースをImport(Week 7-10)
Phase 3: 全環境統一とCI/CD構築(Week 11-12)
Import例:
# 既存VPCのImport
terraform import aws_vpc.main vpc-abc123
# 既存EC2のImport
terraform import aws_instance.web i-def456
注意点:
- Importは一気にやらず、1リソースずつ検証
- State破壊リスクあり、必ずバックアップ
ステップ4: CI/CDパイプライン構築(Week 13-16)
GitHub Actionsでの自動化:
name: Terraform CI/CD
on:
pull_request:
paths: ['terraform/**']
push:
branches: [main]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.9.0
- name: Terraform Format Check
run: terraform fmt -check -recursive
- name: Terraform Init
run: terraform init
working-directory: ./terraform/environments/dev
- name: Terraform Validate
run: terraform validate
- name: Terraform Plan
run: terraform plan -no-color
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
- name: Terraform Apply (main branch only)
if: github.ref == 'refs/heads/main'
run: terraform apply -auto-approve
効果:
- PRごとに
terraform plan自動実行 - レビュー時に変更内容が明確
- mainマージ後に自動Apply
ステップ5: セキュリティ対策(Week 17-20)
1. Secretsの管理:
# AWS Secrets Managerから取得
data "aws_secretsmanager_secret_version" "db_password" {
secret_id = "prod/db/password"
}
resource "aws_db_instance" "main" {
password = data.aws_secretsmanager_secret_version.db_password.secret_string
}
2. tfstateの暗号化:
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "ap-northeast-1"
encrypt = true # 暗号化必須
dynamodb_table = "terraform-lock"
}
}
3. tfsecによる静的解析:
# インストール
brew install tfsec
# スキャン実行
tfsec ./terraform/
# CI/CDに組み込み
ステップ6: 運用とモニタリング(Week 21~)
日常運用:
- 毎週terraform plan実行(drift検出)
- 月次でバージョンアップデート検討
- 四半期でモジュールのリファクタリング
Drift検出:
# 手動変更の検出
terraform plan -detailed-exitcode
# Exit code:
# 0 = 変更なし
# 1 = エラー
# 2 = 変更あり(drift検出)
失敗談と教訓
失敗1: State破壊
何をしたか: 複数人で同時にterraform apply
結果: State conflictで一部リソースが消失
教訓:
- DynamoDBロック必須
- Apply前に必ずPlan確認
- 本番環境は承認制
失敗2: ImportミスでEC2削除
何をしたか: Import時にリソースIDを間違えた
結果: 本番EC2が削除される重大事故
教訓:
- Import前に必ずdry-run
- 本番は必ず別環境で検証後
- State backupを毎回取得
失敗3: Secrets をコードに直書き
何をしたか: DB passwordをvariables.tfに記載
結果: GitHubに機密情報が漏洩
教訓:
- Secrets Managerを使用
- .tfvarsは.gitignoreに追加
- git-secretsで事前検知
成功要因
- 段階的導入: 一気にやらず、新規→既存の順
- チーム教育: 2週間の研修期間を確保
- CI/CD早期導入: 手動ミスを防止
- 定期的なPlan実行: drift早期発見
まとめ
Terraform導入は 初期投資(半年程度) がかかるが、長期的には圧倒的にROI高い。
特に:
- インフラ変更の安全性向上
- 環境の再現性
- チーム全体での情報共有
が大きなメリット。
すぐに実践できる3ステップ:
- 小さく始める(VPCのみTerraform化)
- State管理を最初から正しく
- CI/CDで自動化
Terraform導入支援が必要な方は、お問い合わせからご相談ください。
#Terraform #IaC #AWS #DevOps #インフラ自動化
著者について
DX・AI推進コンサルタント
大手企業グループのDX推進責任者・顧問CTO | 長年のIT・DXキャリア | AWS・GA4・生成AI活用を専門に実践ノウハウを発信中
#Terraform #IaC #インフラ自動化 #DevOps #AWS
最終更新: 2025年11月9日
この記事を書いた人
nexion-lab
DX推進責任者・顧問CTO | IT業界15年以上
大手企業グループでDX推進責任者、顧問CTOとして活動。AI・生成AI活用、クラウドインフラ最適化、データドリブン経営の領域で専門性を発揮。 実務で培った知識と経験を、ブログ記事として発信しています。