Infrastructure as Code

Terraform でインフラをコードとして管理し、再現可能・バージョン管理可能な環境を作る

よくあるシナリオ：「誰がこの設定変えたの？」問題

製造業クライアントで本番サーバーの設定が「なぜか動いている」状態。担当者が退職したら誰も全体像を把握できず。新しい環境を作るたびに2週間かかり、毎回微妙に違う設定でバグが発生。「設定変更した人に聞けばわかる」文化が5年続いていた。

よくある課題

誰がいつどのサーバーを変更したか追跡不能
同じ環境を再現するのに数週間かかる
開発・ステージング・本番で設定が微妙に違う
担当者退職でインフラの知識が会社から消える

Terraform ワークフロー

Write

HCL でインフラを宣言的に記述

resource "aws_s3_bucket" "app" {
  bucket = "my-app-bucket"
}

→

Plan

実行前に変更差分を確認

+ aws_s3_bucket.app (create)
~ aws_instance.web (update)
- aws_sg.old (destroy)

→

✅Apply

確認後に実際のインフラを変更

Apply complete!
Resources: 1 added
           1 changed
           1 destroyed

terraform.tfstate — 状態ファイル

Terraform が「現在のインフラの状態」を記録するJSONファイル。これを元に差分を計算する。チームで使う場合は S3 + DynamoDB（State Lock）でリモート管理が必須。

核心概念を押さえる

IaC（Infrastructure as Code）たとえるなら「設計図をコードで書く」

サーバー・ネットワーク・データベースなどのインフラをコードで定義・管理する手法。手動クリック操作を排除。

例：AWS EC2インスタンスの設定をTerraformファイルに記述→git管理→誰でも同じ環境を再現可能

宣言的 vs 命令的たとえるなら「「何を作るか」vs「どう作るか」」

宣言的IaC（Terraform/Pulumi）は「あるべき状態」を記述。差分を自動計算して適用。命令的スクリプトより保守が楽。

例：宣言的: 「EC2 t3.medium が3台ある状態にして」→Terraformが差分を計算して実行

冪等性（Idempotency）たとえるなら「何度実行しても同じ結果」

同じコードを何度適用しても同じ状態になる性質。手動スクリプトにない強み。安全に繰り返し実行できる。

例：Terraform apply を10回実行しても環境は同じ。リソースの重複作成や設定の上書きが起きない

モジュール化たとえるなら「インフラのレゴブロック」

再利用可能なインフラパターンをモジュール化。VPC・EKSクラスター・RDSなどを組み合わせて環境を構築。

例：「本番VPC」モジュール→ステージングでも再利用→変数だけ変えて同じ構成を展開

状態管理（State）たとえるなら「インフラの現在地図」

Terraformは現在のインフラ状態をstateファイルに記録。次回実行時に差分を計算して最小限の変更のみ適用。

例：S3 + DynamoDBでstateをチーム共有→複数人が同時に変更しても競合を防止

Plan / Applyたとえるなら「設計図の確認→施工」

terraform plan: 変更内容をプレビュー（何が作成/変更/削除されるか確認）。terraform apply: 実際に適用。破壊的変更を事前に把握。

例：terraform plan で「EC2インスタンス3台追加、古いSGを削除」を確認してからapply

手動管理の 3 大問題 → IaC で解決

スノーフレークサーバー

手作業で構築した環境は「その人しか知らない」独自構成になりがち

設定ドリフト

時間とともに本番・ステージング・開発の環境がズレていく

手順書陳腐化

Wikiの手順書は更新されず、実際の手順と乖離が生まれる

✅ IaC で解決

• コードがドキュメント代わり

• Git で変更履歴を管理

• 環境を何度でも再現可能

AI で SRE の仕事はどう変わるか

これまで人がしていた作業

Terraformコードをゼロから手書き（ドキュメント参照が必須）
セキュリティグループルールを目視でレビュー
コスト見積もりをスプレッドシートで手動計算
IaCのベストプラクティスを個人が調査・適用

AI が担う作業

「RDS + ElastiCache構成のTerraformを生成して」で即コード化（GitHub Copilot）
IaCコードのセキュリティリスクを自動スキャン・修正提案（Checkov AI）
インフラ変更のコスト影響をPR時に自動算出（Infracost）
設定ドリフト（実態とコードの乖離）を自動検出・修正（Pulumi AI）

人に残る役割

アーキテクチャ設計の方向性判断
セキュリティポリシー・コンプライアンス要件の確認
コスト承認とリソース削減の最終判断
マルチクラウド戦略の設計と実装方針決定

主なツール：Terraform、Pulumi AI、Crossplane、Infracost、Checkov、GitHub Copilot

この先の見通し：2027年にはAIがアーキテクチャ要件（「マルチAZで高可用性、月コスト10万円以内」）を読んでTerraformコードを自動生成・最適化する時代へ。セキュリティ・コスト・パフォーマンスの三角形をAIが自動バランス調整し、SREはインフラ設計の哲学者として戦略立案に専念。

導入による効果の目安（業界の一般的な傾向）

環境構築時間: -90%; 数週間→数分へ
環境再現性: 100%; コードから完全再現
設定ドリフト: -70%; コードとの乖離防止
変更追跡: 全履歴; git logで完全把握