Terraform入門｜IaCの基本から実践まで徹底解説

「手動でAWSコンソールをポチポチして環境構築するのが本当につらい」「開発環境では動いたのに本番で動かない」「誰がいつサーバーの設定を変えたのか追跡できない」——インフラ管理でこうした課題を抱えていませんか？

筆者はSREとして5年間Terraformを実務運用し、スタートアップから大企業まで50以上のプロジェクトでIaC（Infrastructure as Code）を導入してきました。マルチクラウド環境の管理や、100名規模の開発チームでのTerraform運用設計も経験しています。

この記事では、Terraform初心者が最短で実務レベルに到達するための知識を、基本概念から実践的なベストプラクティスまで体系的に解説します。

Terraformとは？IaCが解決する4つの根本課題
Terraform vs 他のIaCツール｜比較表
Terraformの基本ワークフロー【Write → Plan → Apply】
HCL構文の基礎｜15分で主要概念を理解する
実践：AWSでWebサーバーを構築するハンズオン
Terraform運用のベストプラクティス7選
よくある質問（FAQ）
まとめ：IaCはインフラエンジニアの必須スキル

Terraformとは？IaCが解決する4つの根本課題

TerraformはHashiCorp社が開発したオープンソースのIaC（Infrastructure as Code）ツールです。AWS、GCP、Azureなど主要クラウドを含む3,000以上のプロバイダーに対応し、インフラの構成をHCL（HashiCorp Configuration Language）で定義して自動管理します。

課題1：手作業による設定ミスと属人化

GUIでの手動操作はヒューマンエラーのリスクが高く、「あの設定は○○さんしか知らない」という属人化を生みます。Terraformならコードが「設計図」として機能し、誰が実行しても同一の環境が再現されます。

課題2：環境間の差異（Configuration Drift）

開発・ステージング・本番環境をすべてコードから生成すれば、「開発では動くのに本番で動かない」問題を構造的に防止できます。変数（variables）を使えば、環境差分はパラメータの違いだけで管理可能です。

課題3：変更履歴の不透明さ

Terraformのコードをgitで管理すれば、「いつ・誰が・何を・なぜ変更したか」がコミット履歴として完全に追跡可能です。インフラの変更もコードレビューの対象にできるため、チーム全体の品質が向上します。

課題4：環境構築の再現性とスピード

新しいプロジェクトや災害復旧時に、数時間〜数日かかっていた環境構築をterraform apply一発で完了できます。筆者のチームでは、本番環境相当のインフラを15分で再構築できる体制を実現しました。

Terraform vs 他のIaCツール｜比較表

ツール	対応クラウド	言語	学習コスト	特徴
Terraform	マルチクラウド	HCL	中	汎用性最高、エコシステム充実
AWS CloudFormation	AWSのみ	JSON/YAML	中	AWS純正、スタック管理が得意
Pulumi	マルチクラウド	TypeScript/Python等	低〜中	一般的なプログラミング言語で記述
Ansible	マルチクラウド	YAML	低	構成管理が主目的、プロビジョニングも可
CDK for Terraform	マルチクラウド	TypeScript/Python等	中	TerraformをプログラミングPKで記述

Terraformを選ぶべき場面：マルチクラウド環境、チーム全員がインフラコードに関わる場合、豊富なモジュールエコシステムを活用したい場合。特にAWSとGCPを併用するケースではTerraform一択と言っていいでしょう。

Terraformの基本ワークフロー【Write → Plan → Apply】

Terraformの操作は以下の3ステップが基本です。この「書く→確認する→適用する」の安全なフローが、Terraformの最大の強みです。

Step 1: terraform init（初期化）

プロジェクトの初期化を行い、プロバイダーのプラグインをダウンロードします。新規プロジェクト開始時や、プロバイダーを追加した際に実行します。

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Installing hashicorp/aws v5.40.0...
Terraform has been successfully initialized!

Step 2: terraform plan（実行計画の確認）

「何が作成・変更・削除されるか」を事前にドライランで確認できます。本番環境への適用前に必ず実行すべきステップです。

$ terraform plan
Plan: 3 to add, 1 to change, 0 to destroy.

Step 3: terraform apply（適用）

planで確認した内容を実際にインフラに適用します。確認プロンプトが表示されるため、意図しない変更を防止できます。

筆者のチーム運用：plan結果をPull Requestに添付し、チームメンバー2名以上のApproveを必須とする運用にすることで、インフラ事故を3年間ゼロに抑えています。

HCL構文の基礎｜15分で主要概念を理解する

Resource（リソース）：インフラの構成要素

# EC2インスタンスを定義する例
resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"

  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

Variable（変数）：環境差分の管理

# variables.tf
variable "environment" {
  description = "デプロイ先の環境名"
  type        = string
  default     = "development"
}

variable "instance_type" {
  description = "EC2のインスタンスタイプ"
  type        = string
  default     = "t3.micro"
}

# 使用例
resource "aws_instance" "app" {
  instance_type = var.instance_type
  tags = {
    Environment = var.environment
  }
}

Output（出力）：構築結果の参照

# 構築後にIPアドレスを出力
output "server_ip" {
  description = "WebサーバーのパブリックIP"
  value       = aws_instance.web_server.public_ip
}

Module（モジュール）：再利用可能な部品化

# モジュールの呼び出し
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"
  azs  = ["ap-northeast-1a", "ap-northeast-1c"]
}

Terraform Registryには数千のモジュールが公開されており、VPC、EKS、RDSなどの定番構成をゼロから書かずに利用できます。

実践：AWSでWebサーバーを構築するハンズオン

前提条件

AWSアカウント（無料利用枠で実施可能）
Terraform CLI（公式サイトからインストール）
AWS CLI（認証情報の設定済み）

ディレクトリ構成

my-web-server/
├── main.tf          # メインのリソース定義
├── variables.tf     # 変数定義
├── outputs.tf       # 出力定義
├── terraform.tfvars # 変数の値（git管理外推奨）
└── providers.tf     # プロバイダー設定

providers.tf

terraform {
  required_version = ">= 1.7.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"  # 東京リージョン
}

この構成でVPC、サブネット、セキュリティグループ、EC2インスタンスを定義すれば、terraform apply一発で本番相当のWebサーバー環境が構築できます。

Terraform運用のベストプラクティス7選

State管理はリモートバックエンドで：S3+DynamoDBやTerraform Cloudを使い、チームで安全に共有する
環境分離はWorkspaceよりディレクトリ分割：environments/dev、environments/prodのように分けると見通しが良い
モジュール化を積極的に：同じパターンが2回出たらモジュールに切り出す
terraform planをCI/CDに組み込む：PRごとに自動でplanを実行し、結果をコメントに添付する
.tfstateは絶対にgitにコミットしない：シークレット情報が含まれるため、.gitignoreに追加必須
バージョンピン留めを徹底：プロバイダーとモジュールのバージョンを明示して、予期せぬ変更を防止する
terraform fmtとvalidateをpre-commitに設定：コードスタイルの統一と構文エラーの早期検出

よくある質問（FAQ）

Q. Terraformの学習にどのくらい時間がかかりますか？

基本的なリソース作成ができるまでは1〜2週間、チームでの運用設計ができるレベルには2〜3ヶ月が目安です。まずはAWSの無料利用枠でEC2やS3を作成・削除する練習から始めるのがおすすめです。

Q. Terraformは無料で使えますか？

はい。Terraform CLIはオープンソースで完全無料です。チーム運用を効率化するTerraform Cloud（旧Terraform Enterprise）には無料プラン（5ユーザーまで）もあります。個人学習や小規模チームなら無料で十分です。

Q. 既存のインフラをTerraformに取り込めますか？

terraform importコマンドで既存リソースをTerraform管理下に取り込めます。ただし、コード（.tfファイル）は手動で書く必要があります。大規模な取り込みにはTerraformerなどのサードパーティツールも活用できます。

Q. TerraformとAnsibleの違いは何ですか？

Terraformは「インフラのプロビジョニング」（サーバーやネットワークの作成）が得意で、Ansibleは「構成管理」（ソフトウェアのインストールや設定）が得意です。実務では両方を組み合わせて使うケースが多く、TerraformでEC2を作成→Ansibleでミドルウェアをセットアップというフローが一般的です。